Sistema de Gestión de Pacientes

Modernización Arquitectónica para el Hospital Nacional Daniel Alcides Carrión.

Grupo 4 - Integrantes

Barzola Mendoza, Axel Benjamín

Caman Aguirre, Josué Sebastián

Cumpa Rodríguez, Johan Frank

Mendoza Torres, Jairo Daniel

Vega Gamarra, Diego Enrique

Contexto: La Transformación Digital en Salud

La tecnología es indispensable para optimizar la gestión hospitalaria, mejorar la atención al paciente y asegurar una toma de decisiones clínicas precisa. En el Perú, la digitalización del sector salud es una prioridad estatal, alineada con la Agenda Digital 2020-2025.

Sin embargo, muchas instituciones enfrentan el desafío de sistemas obsoletos que limitan la escalabilidad, seguridad e interoperabilidad. Este proyecto aborda esa necesidad de modernización.

La Problemática del Sistema Actual

⚙️

Tecnología Obsoleta

La plataforma actual no se adapta a las necesidades modernas, dificultando la escalabilidad.

🧱

Arquitectura Rígida

La estructura monolítica impide incorporar mejoras y nuevas funcionalidades fácilmente.

🧩

Falta de Integración

La comunicación entre módulos es deficiente, generando silos de datos e ineficiencias.

📉

Cobertura Parcial

Procesos clave en áreas críticas no están contemplados, afectando la atención.

Objetivos del Proyecto

Objetivo General

Desarrollar un sistema de gestión de pacientes que optimice los procesos clínicos y administrativos, mejore la atención y garantice la seguridad de la información.

Objetivos Específicos

Desarrollar módulos para triage, historias clínicas y hospitalización.
Implementar una arquitectura SOA escalable, segura y en capas.
Diseñar una interfaz intuitiva y accesible para el personal.
Garantizar la compatibilidad con infraestructuras limitadas.

Estilo Arquitectónico Elegido: SOA

Se propone una Arquitectura Orientada a Servicios (SOA). Este enfoque divide el sistema en servicios independientes y reutilizables (ej. Admisión, Triage, Historias Clínicas) que se comunican a través de APIs.

Modularidad

Desarrollo y mantenimiento autónomo de cada servicio.

Escalabilidad

Permite escalar servicios críticos de forma independiente.

Interoperabilidad

Facilita la integración con sistemas externos (laboratorio, farmacia).

Flexibilidad

Permite una evolución gradual hacia microservicios si es necesario.

Arquitectura Lógica en Capas

graph TD subgraph "Usuario Final" A[💻 Navegador Web] end subgraph "Capa de Presentación (Frontend)" B(Interfaz de Usuario) B -- Peticiones HTTP --> C end subgraph "Capa de Aplicación (Backend - SOA)" C(API Gateway / Controladores) C --> S1[Servicio de Pacientes] C --> S2[Servicio de Triage] C --> S3[Servicio de Historias Clínicas] C --> S4[Servicio de Hospitalización] C --> S_Auth[Servicio de Autenticación] end subgraph "Capa de Datos (Persistencia)" D[Base de Datos Relacional SQL] S1 --> D S2 --> D S3 --> D S4 --> D S_Auth --> D end style B fill:#38bdf8,stroke:#1e40af,color:#fff style C fill:#34d399,stroke:#065f46,color:#fff style D fill:#facc15,stroke:#92400e,color:#fff

Atributos de Calidad (Requisitos No Funcionales)

🛡️

Seguridad

Autenticación multifactor, cifrado de datos y control de acceso basado en roles (RBAC).

⚡️

Rendimiento

Respuestas en operaciones críticas en menos de 3 segundos mediante caching y consultas optimizadas.

✅

Disponibilidad

Disponibilidad del 99.5% con clustering, failover automático y backups diarios.

Vista de Componentes

El sistema se organiza en componentes lógicos que encapsulan funcionalidades específicas.

graph TD subgraph Presentación IW[Interfaz Web] end subgraph "Lógica de Negocio (Backend)" RP[Registros de Pacientes] HC[Historias Clínicas] HOSP[Hospitalización] TRIAGE[Triage] OM[Órdenes Médicas] AC[Agenda y Consultas] end subgraph Infraestructura BBDD[Base de Datos] SE[Servicios Externos] end IW --> RP IW --> HC IW --> TRIAGE RP -.-> BBDD HC -.-> BBDD HOSP -.-> BBDD TRIAGE -.-> BBDD OM -.-> BBDD AC -.-> BBDD OM -.-> SE;

Vista de Procesos: Flujo de Triage

sequenceDiagram participant Usuario as 👤 Usuario (Enfermería) participant Frontend as 💻 Interfaz Web participant Backend as ⚙️ API (Triage Service) participant DB as 🗄️ Base de Datos Usuario->>Frontend: Ingresa DNI del paciente Frontend->>Backend: GET /pacientes?dni=... Backend->>DB: Busca paciente DB-->>Backend: Retorna datos del paciente Backend-->>Frontend: Muestra información Usuario->>Frontend: Registra signos vitales y motivo Frontend->>Backend: POST /triages/add (datos) Backend->>Backend: Clasifica urgencia (Lógica) Backend->>DB: Guarda registro de triage DB-->>Backend: Confirma guardado Backend-->>Frontend: Respuesta HTTP 201 Created Frontend-->>Usuario: Muestra confirmación y prioridad

Vista de Despliegue

La arquitectura se despliega en una infraestructura web moderna, separando el cliente de los servidores de aplicación y base de datos para mayor seguridad y escalabilidad.

graph LR subgraph "Cliente" A[PC Cliente / Dispositivo] end subgraph "Infraestructura de Servidores" B["Servidor Web (Nginx)"] C{"Servidor de Aplicaciones (NestJS)"} D[(Servidor Base de Datos)] end A -- HTTPS --> B B -- API Request --> C C -- Query --> D style A fill:#a78bfa,stroke:#5b21b6,color:#fff style B fill:#60a5fa,stroke:#1e40af,color:#fff style C fill:#34d399,stroke:#065f46,color:#fff style D fill:#facc15,stroke:#92400e,color:#fff

Patrones Arquitectónicos Aplicados

Controller-Service-Repository

Separa las responsabilidades de recibir peticiones, ejecutar la lógica de negocio y acceder a los datos.

Dependency Injection (DI)

NestJS gestiona la creación e inyección de dependencias (servicios, repositorios) para un bajo acoplamiento.

Modular Architecture

El sistema se organiza en módulos funcionales (Pacientes, Médicos, Consultas) para alta cohesión.

API RESTful

La comunicación se realiza mediante una API REST, usando métodos HTTP estándar y JSON.

Trazabilidad y Gestión de Configuración

Git: Control de versiones con un flujo de ramas estructurado (main, develop, feature).
Commits Descriptivos: Cada commit está vinculado a un requisito o tarea.
Docker: Contenerización de la base de datos para entornos de desarrollo consistentes.
Documentación: Uso de README.md y diagramas para mantener la consistencia del proyecto.

Buenas Prácticas de Seguridad

Control de Acceso (RBAC): Roles definidos para médicos, enfermeros y administradores.
Autenticación Segura: Tokens JWT con expiración para proteger las sesiones.
Cifrado de Datos: HTTPS para datos en tránsito y cifrado para datos sensibles en reposo.
Validación de Entradas: Protección contra inyección SQL y otros ataques comunes.

Propuesta de Interfaz de Usuario

La interfaz se ha diseñado para ser intuitiva, limpia y eficiente, minimizando la curva de aprendizaje para el personal del hospital.

Dashboard Centralizado: Vista rápida de pacientes, citas y acciones importantes.
Navegación Clara: Menú lateral para acceder a todos los módulos.
Formularios Simplificados: Campos claros y validaciones para reducir errores.
Diseño Responsivo: Accesible desde diferentes dispositivos.

Impacto Esperado

⏱️

Reducción de Tiempos

Disminución en tiempos de espera para admisión, triage y acceso a historias clínicas.

🎯

Minimización de Errores

Reducción de errores clínicos y duplicidad de información gracias a la centralización de datos.

🤝

Mejor Coordinación

Potencia la interoperabilidad y comunicación entre las áreas médica, administrativa y diagnóstica.

📈

Mejora en la Atención

Una gestión más eficiente se traduce en una atención de mayor calidad y seguridad para el paciente.

¡Gracias!

La arquitectura de software no es solo una decisión técnica; es la base para construir un sistema resiliente, seguro y eficiente que pone la tecnología al servicio del bienestar humano. Este proyecto sienta las bases para una evolución continua, adaptándose a las futuras necesidades del hospital y del sector salud.

El futuro de la gestión hospitalaria es digital, integrado y centrado en el paciente.