F1 - Autentcacion - Completa

This commit is contained in:
2026-08-10 15:54:42 -03:00
commit dd7f5b3bf6
245 changed files with 81985 additions and 0 deletions
+219
View File
@@ -0,0 +1,219 @@
🏗️ Visión General de la Arquitectura (Alto Nivel)
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.
Base de datos: MySQL (ya definida).
Servicios externos:
Google Calendar API para la gestión de citas (embebido o mediante integración).
Chatwoot para mensajería (solo redirección y notificaciones básicas).
Seguridad: Autenticación por Identity con roles (Administrador, Médico, Secretaria, Recepcionista, etc.) y autorización por políticas personalizadas.
📌 Módulos Funcionales
Basado en tu descripción, podemos desglosar la aplicación en estos módulos principales:
Gestión de Usuarios y Roles (ya iniciada).
Gestión de Pacientes (alta, baja, modificación, historial clínico).
Gestión de Citas / Agenda (integración con Google Calendar).
Historia Clínica (diagnósticos, tratamientos, evolución, recetas, etc.).
Dashboard / Resumen (vista rápida para secretarias y médicos).
Integración con Chatwoot (botón y contador de mensajes no leídos).
🧩 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.
Atributos sugeridos:
Id (int o guid)
Nombres
Apellidos
Fecha de Nacimiento
Género
Documento de Identidad (único)
Dirección (opcional)
Teléfono(s)
Email (opcional)
Obra Social / Plan de Salud (opcional, pero útil)
Fecha de Registro
Usuario que lo dio de alta (relación con ApplicationUser)
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
Matrícula Profesional
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.
4. Cita
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/
├── Controllers/
│ ├── AccountController (Identity)
│ ├── UsuariosController (gestión de usuarios)
│ ├── PacientesController
│ ├── CitasController
│ ├── HistoriaClinicaController
│ └── DashboardController
├── Models/
│ ├── ApplicationUser.cs
│ ├── Paciente.cs
│ ├── Cita.cs
│ ├── HistoriaClinica.cs
│ └── ViewModels/ (todos los ViewModels)
├── Data/
│ ├── ApplicationDbContext.cs
│ └── Seeders/
│ └── RoleSeeder.cs
├── Services/
│ ├── GoogleCalendarService.cs (para interactuar con Google Calendar)
│ ├── ChatwootService.cs (para obtener contador de mensajes no leídos, si es posible)
│ └── IUsuarioService.cs (si quieres separar lógica de negocio)
├── Views/
│ ├── Usuarios/
│ ├── Pacientes/
│ ├── Citas/
│ ├── HistoriaClinica/
│ └── Shared/
├── Helpers/ (clases utilitarias)
└── 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.