198 lines
7.2 KiB
Markdown
198 lines
7.2 KiB
Markdown
# 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`
|
||
|
||
- [ ] 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).
|