# 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.

- [x] Crear solución ASP.NET Core 8+ con MVC  
  - Configurar `Program.cs`, inyección de dependencias, Pomelo MySQL y Migrations base

- [x] Implementar `ApplicationUser` con ASP.NET Identity  
  - Campos: `Nombre`, `Apellido`, `Documento`, `Dirección`, `Teléfono`, `RolPrincipal`

- [x] Definir roles y políticas de autorización  
  - Roles: `Administrador`, `Médico`, `Secretaria`, `Recepcionista`  
  - Implementar `RoleSeeder.cs`

- [x] Construir `AccountController` (login / logout / registro)  
  - Views con Bootstrap, validación del lado cliente y servidor

- [x] Layout compartido y navbar condicional por rol  
  - `_Layout.cshtml` con menú adaptado según claims del usuario autenticado

- [x] 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.

- [x] Módulo de usuarios (`UsuariosController`)  
  - Listar, crear, editar, deshabilitar  
  - Asignación de roles  
  - Perfil de médico: `Especialidad`, `MatriculaProfesional`, `HorarioAtencion`

- [x] CRUD de roles (`RolesController`)  
  - En el mismo index generar modales para poder editar los roles, y ademas poder habilitarlos o deshabilitarlos.

- [x] Modelo y migración de `Paciente`  
  - Campos: `Nombres`, `Apellidos`, `FechaNacimiento`, `Genero`, `DocumentoIdentidad` (único), `Direccion`, `Telefono`, `Email`, `ObraSocial`, `FechaRegistro`, FK a `UsuarioAlta`

- [x] 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).
