F1 - Autentcacion - Completa v2

This commit is contained in:
2026-08-10 15:57:42 -03:00
parent dd7f5b3bf6
commit 3cfb4bb6f2
+96 -166
View File
@@ -1,219 +1,149 @@
🏗️ Visión General de la Arquitectura (Alto Nivel) # Arquitectura y Diseño de Sistema de Gestión Médica
Frontend: ASP.NET Core MVC (Razor Views) con Bootstrap (o cualquier otro framework CSS) para la interfaz de usuario.
Backend: ASP.NET Core 6+ con inyección de dependencias, Identity para autenticación, y Entity Framework Core (con Pomelo MySQL) para el acceso a datos. ## Visión General de la Arquitectura (Alto Nivel)
Base de datos: MySQL (ya definida). * **Frontend:** ASP.NET Core MVC (Razor Views) con Bootstrap (o framework CSS equivalente) para la interfaz de usuario.
* **Backend:** ASP.NET Core 6+ con inyección de dependencias, Identity para autenticación y Entity Framework Core (con Pomelo MySQL) para acceso a datos.
* **Base de Datos:** MySQL.
* **Servicios Externos:**
* **Google Calendar API:** Gestión e integración de citas de la agenda médica.
* **Chatwoot:** Mensajería (redirección y notificaciones básicas).
* **Seguridad:** Autenticación por Identity con roles (`Administrador`, `Médico`, `Secretaria`, `Recepcionista`, etc.) y autorización mediante políticas personalizadas.
Servicios externos: ---
Google Calendar API para la gestión de citas (embebido o mediante integración). ## Módulos Funcionales
Chatwoot para mensajería (solo redirección y notificaciones básicas). 1. **Gestión de Usuarios y Roles:** Administración del personal administrativo y médico.
2. **Gestión de Pacientes:** Alta, baja, modificación e historial general.
3. **Gestión de Citas y Agenda:** Sincronización e integración con Google Calendar.
4. **Historia Clínica:** Registro de diagnósticos, tratamientos, evolución y recetas.
5. **Dashboard / Resumen:** Vista ejecutiva rápida para secretarias y cuerpo médico.
6. **Integración con Chatwoot:** Acceso directo a mensajería y contador de mensajes no leídos.
Seguridad: Autenticación por Identity con roles (Administrador, Médico, Secretaria, Recepcionista, etc.) y autorización por políticas personalizadas. ---
📌 Módulos Funcionales ## Diseño de Datos (Entidades Principales)
Basado en tu descripción, podemos desglosar la aplicación en estos módulos principales:
Gestión de Usuarios y Roles (ya iniciada). ### 1. Usuario (`ApplicationUser`)
Gestión de Pacientes (alta, baja, modificación, historial clínico). Representa al personal del sistema. Extiende de la entidad Identity básica.
Gestión de Citas / Agenda (integración con Google Calendar). * `Nombre`
* `Apellido`
* `Documento`
* `Dirección`
* `Teléfono`
* `Email`
* `RolPrincipal`
Historia Clínica (diagnósticos, tratamientos, evolución, recetas, etc.). > **Nota:** El rol determina los permisos y accesos dentro del sistema.
Dashboard / Resumen (vista rápida para secretarias y médicos). ---
Integración con Chatwoot (botón y contador de mensajes no leídos). ### 2. Paciente
🧩 Diseño de Datos (Entidades Principales)
1. Usuario (ApplicationUser - ya extendido)
Campos actuales: Nombre, Apellido, Documento, Dirección, Teléfono, Email, RolPrincipal.
Nota: El rol define qué funciones puede ver/ejecutar (Administrador, Médico, Secretaria, etc.).
2. Paciente
Representa a la persona que recibe atención médica. Representa a la persona que recibe atención médica.
Atributos sugeridos: * `Id` (int o Guid)
* `Nombres`
* `Apellidos`
* `FechaNacimiento`
* `Genero`
* `DocumentoIdentidad` (único)
* `Direccion` (opcional)
* `Telefono`
* `Email` (opcional)
* `ObraSocial` / `PlanDeSalud` (opcional)
* `FechaRegistro`
* `UsuarioAltaId` (relación con `ApplicationUser`)
Id (int o guid) ---
Nombres ### 3. Médico
Apellidos Perfil extendido para usuarios con rol médico. Se recomienda extender `ApplicationUser` o mantener una relación 1 a 1.
Fecha de Nacimiento * `Especialidad`
* `MatriculaProfesional`
* `HorarioAtencion`
Género ---
Documento de Identidad (único) ### 4. Cita
Dirección (opcional) Entidad de control para agendas y sincronización externa.
Teléfono(s) * `Id`
* `PacienteId` (FK -> Paciente)
* `MedicoId` (FK -> ApplicationUser / Médico)
* `FechaHoraInicio`
* `FechaHoraFin` (o duración)
* `Motivo` (texto breve)
* `Estado` (`Programada`, `Confirmada`, `Cancelada`, `Atendida`)
* `GoogleCalendarEventId` (para sincronización bidireccional)
* `FechaCreacion`
* `UsuarioCreacionId` (FK -> ApplicationUser)
Email (opcional) ---
Obra Social / Plan de Salud (opcional, pero útil) ### 5. Historia Clínica
Fecha de Registro Registro médico agrupado por consulta realizada.
Usuario que lo dio de alta (relación con ApplicationUser) * `Id`
* `PacienteId` (FK -> Paciente)
* `MedicoId` (FK -> ApplicationUser / Médico)
* `FechaConsulta`
* `MotivoConsulta`
* `Diagnostico` (texto o código CIE-10)
* `TratamientoIndicado`
* `Observaciones` / `Notas`
* `ProximoControl` (fecha sugerida)
* `EstadoPaciente` (`Activo`, `En Tratamiento`, `Derivado`, etc.)
3. Médico (opcional si ya es un rol, pero si necesitas atributos específicos) ---
Si los médicos son también usuarios del sistema, puedes simplemente usar el rol "Médico" y extender su perfil con atributos como:
Especialidad ## Relaciones Principales
Matrícula Profesional * **Usuario -> Paciente:** `1 : N` (un usuario registra múltiples pacientes).
* **Médico -> Cita:** `1 : N` (un médico atiende múltiples citas).
* **Paciente -> Cita:** `1 : N` (un paciente puede tener múltiples citas).
* **Paciente -> HistoriaClinica:** `1 : N` (un paciente posee múltiples registros clínicos).
* **Médico -> HistoriaClinica:** `1 : N` (un médico registra múltiples historias clínicas).
Horario de atención (aunque la agenda esté en Google Calendar) ---
Si no todos los médicos son usuarios (por ejemplo, si trabajan en el consultorio pero no usan el sistema), podrías tener una tabla independiente de "Médico" que no herede de Identity. Pero por simplicidad, recomiendo que todos los médicos sean usuarios con rol "Médico" y agregar esos campos extra en ApplicationUser. ## Estructura del Proyecto
4. Cita ```text
Como usas Google Calendar, quizás solo necesites almacenar un enlace o ID de evento de Google, más algunos metadatos.
Atributos sugeridos:
Id
PacienteId (relación con Paciente)
MédicoId (relación con ApplicationUser - Médico)
Fecha/Hora de inicio
Fecha/Hora de fin (o duración)
Motivo de la cita (texto breve)
Estado (Programada, Confirmada, Cancelada, Atendida, etc.)
GoogleCalendarEventId (para sincronizar)
Fecha de creación
Usuario que la creó (Secretaria o Médico)
5. Historia Clínica (Registro médico del paciente)
Puede ser una tabla principal HistoriaClinica que agrupe todas las consultas.
Atributos sugeridos:
Id
PacienteId
MédicoId (quién atiende)
Fecha de consulta
Motivo de consulta
Diagnóstico (texto libre, o podrías usar códigos CIE-10 si es necesario)
Tratamiento indicado (texto)
Observaciones / Notas
Próximo control (fecha sugerida)
Estado del paciente (ej: activo, en tratamiento, derivado, etc.)
6. Detalle de Historia Clínica (opcional si necesitas más granularidad)
Si quieres separar por tipos (ej: Exámenes, Recetas, Procedimientos), podrías tener subentidades. Pero para empezar, un solo campo de texto "Observaciones" o "Notas" es suficiente.
🔗 Relaciones Principales
Usuario (ApplicationUser) → Paciente (1 a muchos: un usuario puede dar de alta a varios pacientes).
Usuario (Médico) → Cita (1 a muchos).
Paciente → Cita (1 a muchos).
Paciente → HistoriaClinica (1 a muchos).
Médico → HistoriaClinica (1 a muchos).
🗂️ Estructura de Carpetas (Proyecto)
Te sugiero esta organización:
text
TuProyecto/ TuProyecto/
├── Controllers/ ├── Controllers/
│ ├── AccountController (Identity) │ ├── AccountController.cs
│ ├── UsuariosController (gestión de usuarios) │ ├── UsuariosController.cs
│ ├── PacientesController │ ├── PacientesController.cs
│ ├── CitasController │ ├── CitasController.cs
│ ├── HistoriaClinicaController │ ├── HistoriaClinicaController.cs
│ └── DashboardController │ └── DashboardController.cs
├── Models/ ├── Models/
│ ├── ApplicationUser.cs │ ├── ApplicationUser.cs
│ ├── Paciente.cs │ ├── Paciente.cs
│ ├── Cita.cs │ ├── Cita.cs
│ ├── HistoriaClinica.cs │ ├── HistoriaClinica.cs
│ └── ViewModels/ (todos los ViewModels) │ └── ViewModels/
├── Data/ ├── Data/
│ ├── ApplicationDbContext.cs │ ├── ApplicationDbContext.cs
│ └── Seeders/ │ └── Seeders/
│ └── RoleSeeder.cs │ └── RoleSeeder.cs
├── Services/ ├── Services/
│ ├── GoogleCalendarService.cs (para interactuar con Google Calendar) │ ├── GoogleCalendarService.cs
│ ├── ChatwootService.cs (para obtener contador de mensajes no leídos, si es posible) │ ├── ChatwootService.cs
│ └── IUsuarioService.cs (si quieres separar lógica de negocio) │ └── IUsuarioService.cs
├── Views/ ├── Views/
│ ├── Usuarios/ │ ├── Usuarios/
│ ├── Pacientes/ │ ├── Pacientes/
│ ├── Citas/ │ ├── Citas/
│ ├── HistoriaClinica/ │ ├── HistoriaClinica/
│ └── Shared/ │ └── Shared/
├── Helpers/ (clases utilitarias) ├── Helpers/
└── Migrations/ └── Migrations/
🚀 Flujos de Trabajo (Casos de Uso)
Para Secretaria:
Gestión de Pacientes: Dar de alta, buscar, editar, ver historial resumido.
Agenda de Citas: Ver calendario (Google Calendar embebido), crear/editar/cancelar citas asignando paciente y médico.
Dashboard: Resumen de citas del día, pacientes nuevos, mensajes sin leer (Chatwoot).
Para Médico:
Ver su agenda (Google Calendar).
Acceder a Historia Clínica de sus pacientes (puede ver todas, pero quizás solo las que él atendió).
Cargar / actualizar historia clínica de sus pacientes (diagnóstico, tratamiento, etc.).
Comunicación: Botón para abrir Chatwoot (conversaciones con pacientes/secretarias).
Para Administrador:
Gestión de usuarios (altas, bajas, roles).
Parametrización (especialidades, configuraciones, etc.).
🔐 Seguridad y Autorización
Roles:
Administrador: Puede todo.
Médico: Puede ver su agenda, gestionar sus pacientes y cargar historias clínicas.
Secretaria: Puede gestionar pacientes y citas de todos los médicos, pero no puede cargar historias clínicas (quizás solo leer).
Recepcionista (opcional): Solo agenda y pacientes, sin historial clínico.
Políticas (si quieres más granularidad): por ejemplo, un médico solo puede editar historias clínicas que él creó, o las de sus pacientes asignados.
🧰 Tecnologías y Librerías Adicionales
Google Calendar API: Necesitas registrar la aplicación en Google Cloud Console, habilitar la API y usar la librería Google.Apis.Calendar.v3.
Chatwoot: Para el botón de acceso, podrías usar un widget de Chatwoot (código JavaScript) y para el contador de mensajes no leídos, Chatwoot tiene una API REST que puedes consultar desde el backend (usando su token de acceso).
Entity Framework Core (ya incluido).
Bootstrap / AdminLTE para un layout administrativo.
DataTables o similar para listados con búsqueda y paginación.