Plan de desarrollo

This commit is contained in:
2026-08-10 16:10:47 -03:00
parent 3b7e629f75
commit 5c0cce7c1f
5 changed files with 198 additions and 172 deletions
+194
View File
@@ -0,0 +1,194 @@
# Plan de Desarrollo — Sistema de Gestión Médica
> **Stack:** ASP.NET Core 6+ MVC · MySQL (Pomelo EF Core) · Google Calendar API · Chatwoot
> **Duración estimada total:** 1215 semanas
---
## Resumen de fases
| Fase | Nombre | Duración estimada |
|------|--------|-------------------|
| 1 | Infraestructura base y autenticación | ≈ 2 semanas |
| 2 | Gestión de usuarios y pacientes | ≈ 23 semanas |
| 3 | Gestión de citas y Google Calendar | ≈ 3 semanas |
| 4 | Historia clínica | ≈ 23 semanas |
| 5 | Dashboard e integración Chatwoot | ≈ 12 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 6+ 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`
- [ ] 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 24)
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).