Plan de Desarrollo — Sistema de Gestión Médica

Stack: ASP.NET Core 8 + MVC · MySQL (Pomelo EF Core) · Google Calendar API · Chatwoot
Duración estimada total: 12–15 semanas

Resumen de fases

Fase	Nombre	Duración estimada
1	Infraestructura base y autenticación	≈ 2 semanas
2	Gestión de usuarios y pacientes	≈ 2–3 semanas
3	Gestión de citas y Google Calendar	≈ 3 semanas
4	Historia clínica	≈ 2–3 semanas
5	Dashboard e integración Chatwoot	≈ 1–2 semanas
6	Calidad, seguridad y despliegue	≈ 2 semanas

Fase 1 — Infraestructura base y autenticación

Objetivo: Scaffolding del proyecto, modelos de datos, roles e Identity.

Crear solución ASP.NET Core 8+ con MVC
- Configurar Program.cs, inyección de dependencias, Pomelo MySQL y Migrations base
Implementar ApplicationUser con ASP.NET Identity
- Campos: Nombre, Apellido, Documento, Dirección, Teléfono, RolPrincipal
Definir roles y políticas de autorización
- Roles: Administrador, Médico, Secretaria, Recepcionista
- Implementar RoleSeeder.cs
Construir AccountController (login / logout / registro)
- Views con Bootstrap, validación del lado cliente y servidor
Layout compartido y navbar condicional por rol
- _Layout.cshtml con menú adaptado según claims del usuario autenticado
Migraciones iniciales y seeder de roles
- Verificar creación de tablas Identity en MySQL y usuario administrador inicial

Fase 2 — Gestión de usuarios y pacientes

Objetivo: CRUD completo de personal médico y pacientes.

Módulo de usuarios (UsuariosController)
- Listar, crear, editar, deshabilitar
- Asignación de roles
- Perfil de médico: Especialidad, MatriculaProfesional, HorarioAtencion
CRUD de roles (RolesController)
- En el mismo index generar modales para poder editar los roles, y ademas poder habilitarlos o deshabilitarlos.
Modelo y migración de Paciente
- Campos: Nombres, Apellidos, FechaNacimiento, Genero, DocumentoIdentidad (único), Direccion, Telefono, Email, ObraSocial, FechaRegistro, FK a UsuarioAlta
CRUD de pacientes (PacientesController)
- Alta, baja lógica, modificación
- Búsqueda por nombre / documento
- ViewModels y validaciones
Vista de perfil de paciente
- Resumen de datos, historial de citas y acceso rápido a historia clínica
Autorización por rol en vistas y acciones
- [Authorize(Roles = "...")] en controladores
- Ocultar botones según claims del usuario

Decisión pendiente: Definir si Médico extiende ApplicationUser (relación 1:1) o es una entidad separada. Resolverlo antes de las migraciones de Fase 3, ya que afecta todas las FK de Cita e HistoriaClinica.

Fase 3 — Gestión de citas y Google Calendar

Objetivo: Agenda médica con sincronización bidireccional.

⚠️ Fase de mayor riesgo. La integración OAuth2 y la sincronización bidireccional son los puntos más propensos a imprevistos. Reservar tiempo adicional.

Modelo y migración de Cita
- FK a Paciente y Médico
- Estados: Programada, Confirmada, Cancelada, Atendida
- Campo GoogleCalendarEventId para sincronización
CRUD de citas (CitasController)
- Crear, editar, cancelar
- Vista de agenda diaria/semanal (FullCalendar.js o similar)
Configurar OAuth2 con Google
- Credenciales en Google Cloud Console
- Flujo de autorización y almacenamiento seguro de tokens de refresco
Implementar GoogleCalendarService
- Crear, actualizar y eliminar eventos en Google Calendar
- Mapeo de campos Cita ↔ CalendarEvent
Sincronización bidireccional
- Webhook o polling para traer cambios externos
- Reconciliación de estado por GoogleCalendarEventId
Notificaciones y recordatorios de cita
- Envío de invitación por email al paciente al confirmar la cita

Fase 4 — Historia clínica

Objetivo: Registro de consultas, diagnósticos, tratamientos y recetas.

Modelo y migración de HistoriaClinica
- FK a Paciente y Médico
- Campos: MotivoConsulta, Diagnostico (texto o código CIE-10), TratamientoIndicado, Observaciones, ProximoControl, EstadoPaciente
CRUD de historia clínica (HistoriaClinicaController)
- Crear registro por consulta
- Edición restringida al médico autor
- Vista timeline por paciente
Vista de historial completo del paciente
- Timeline cronológico de consultas, diagnósticos y evolución
- Filtros por fecha y médico
Gestión de estados de paciente
- Activo / En tratamiento / Derivado — visible en perfil y dashboard
Exportación básica a PDF
- Resumen de historia clínica imprimible para el paciente o para derivación

Fase 5 — Dashboard e integración Chatwoot

Objetivo: Vista ejecutiva por rol y mensajería embebida.

Dashboard por rol (DashboardController)
- Médico: citas del día, próximos controles
- Secretaría: agenda general, pacientes registrados hoy, citas pendientes de confirmación
- Administrador: métricas globales del sistema
Widgets del dashboard
- Próximas citas, pacientes registrados hoy, citas pendientes de confirmación
Implementar ChatwootService
- Integración con API REST de Chatwoot
- Contador de mensajes no leídos y redirect a conversación
Ícono de mensajes en navbar con badge de no leídos
- Polling periódico o SignalR para actualizar el contador sin recargar la página

Fase 6 — Calidad, seguridad y despliegue

Objetivo: Testing, hardening y puesta en producción.

Tests unitarios e integración
- xUnit para servicios y controladores críticos (GoogleCalendarService, autenticación, citas)
Auditoría de seguridad
- Validar anti-CSRF, XSS, inyección SQL
- Rate limiting en login, HTTPS forzado
Logging y manejo de errores
- Serilog o NLog con niveles diferenciados
- Página de error amigable; alertas por excepción crítica
Optimización de consultas EF Core
- Revisión de N+1 queries
- Índices en MySQL: DocumentoIdentidad, MedicoId, FechaHoraInicio
Configuración de entorno productivo
- appsettings por entorno (Development / Production)
- Cadena de conexión segura, secrets management
- Deploy en servidor Linux o Azure App Service
Documentación técnica y manual de usuario
- README actualizado con instrucciones de setup
- Guía de roles y permisos
- Manual de onboarding para el equipo médico y administrativo

Dependencias entre fases

Fase 1 → Fase 2 → Fase 3 → Fase 4
                         ↘
                    Fase 5 (Dashboard consume datos de Fases 2–4)
                         ↘
                    Fase 6 (transversal a todo el proyecto)

La Fase 1 es prerequisito duro para todo lo demás.
La Fase 6 puede iniciarse parcialmente en paralelo desde la Fase 3 en adelante (testing y logging).

7.2 KiB Raw Permalink Blame History Unescape Escape