3). Requerimientos de Interfaces Externas - migueltovarb/ISWREQUERIMIENTOS202502-1nik129linux GitHub Wiki

3.1 Interfaces de Usuario

Características principales:

  • GUI web con dashboards basados en roles:

    • Paciente → vista calendario.
    • Admin → tablas CRUD.

  • Diseño según Material Design (limpio y accesible).

  • Botones estándar: Confirmar Cita, Cancelar, Guardar.

  • Mensajes de error: banners rojos con texto accionable (ejemplo: “Hora no disponible: Elija otra”).

Pantallas principales:

  • Login
  • Tablero
  • Formulario de reserva
  • Reportes

(No existe una especificación UI separada; se detalla en prototipos).

3. Especificaciones Específicas de Requerimientos

3.2 Interfaces de Hardware

La arquitectura del Sistema de Gestión de Citas Médicas (SGCM) está diseñada para minimizar dependencias de hardware propietario, priorizando accesibilidad y portabilidad en entornos clínicos heterogéneos. Esto se alinea con principios de diseño agnóstico de hardware, asegurando que el sistema opere en dispositivos estándar sin requerir inversiones adicionales en infraestructura especializada. A continuación, se detallan las interfaces de hardware identificadas:

  • Acceso Principal vía Protocolos Web Estándar: El sistema se accede exclusivamente mediante HTTP/HTTPS sobre navegadores web modernos, eliminando la necesidad de hardware dedicado como terminales de punto de venta o escáneres biométricos. Esto facilita el despliegue en dispositivos móviles (smartphones y tablets) y computadoras de escritorio, con soporte para resoluciones mínimas de 1024x768 píxeles.

  • Ausencia de Dependencias Especializadas: No se requiere hardware propietario o periféricos de alto costo. El SGCM opera en modo thin-client, delegando procesamiento intensivo al servidor backend, lo que reduce la carga en el hardware del cliente a procesadores de gama media (e.g., Intel Core i3 o equivalente) y memoria RAM de al menos 4 GB.

  • Soporte para Impresión y Exportación de Reportes: Se asume la disponibilidad de una impresora estándar para la generación de documentos en formato PDF o impresión directa.

    • Compatibilidad: Impresoras conectadas vía USB 2.0/3.0 o red (LAN/Wi-Fi), utilizando el diálogo nativo del navegador (e.g., window.print() en JavaScript para web).
    • Requisitos Mínimos: Soporte para formatos A4/Letter, resolución de 300 DPI, y drivers estándar (PCL o PostScript). No se integra con impresoras térmicas especializadas, pero permite exportación a PDF para impresión offline.
    • Consideraciones de Seguridad: La impresión se realiza localmente, sin transmisión de datos sensibles sobre la red, cumpliendo con normativas como HIPAA para minimizar exposición.

Esta aproximación garantiza escalabilidad y reduce barreras de adopción en clínicas con recursos limitados, con un enfoque en la resiliencia ante fallos de hardware periférico.

3.3 Interfaces de Software

Las interfaces de software del SGCM definen los puntos de interacción entre componentes internos (e.g., frontend, backend) y externos (e.g., bases de datos, servicios de terceros), promoviendo modularidad y reutilización de código bajo un paradigma RESTful. Se enfatiza la interoperabilidad mediante estándares abiertos, facilitando futuras extensiones como integraciones con sistemas de historia clínica electrónica (HCE). Los requerimientos se clasifican por criticidad (Alta/Media/Baja) para priorización en el desarrollo.

  • Base de Datos (Prioridad: Alta):

    • Tecnología: PostgreSQL versión 14 o superior, seleccionada por su robustez en manejo de datos transaccionales y soporte nativo para extensiones como PostGIS (para geolocalización de pacientes, si aplica en futuras iteraciones).
    • Esquema Conceptual: Modelado relacional con entidades principales como Paciente, Cita, Medico y Agenda. Se utiliza normalización 3NF para evitar redundancias, con índices en campos de consulta frecuentes (e.g., fecha_cita, id_paciente).
    • Acceso: Mediante ORM (Object-Relational Mapping) como SQLAlchemy en Python/Django, asegurando abstracción y portabilidad.

  • Estructura de Comunicación Interna/Externa (Prioridad: Alta):

    • Formato: JSON sobre REST API, con endpoints versionados (e.g., /api/v1/citas/). Esto permite stateless interactions, ideales para aplicaciones web escalables.
    • Ejemplo de Carga de Datos (Endpoint POST /citas): 
      {
  "idPaciente": 123,
  "idMedico": 456,
  "fecha": "2025-10-20T14:00:00Z",
  "especialidad": "Cardiología",
  "motivo": "Control rutinario",
  "duracionMinutos": 30
}
      • Respuesta Esperada: 
        {
  "idCita": 789,
  "estado": "confirmada",
  "mensaje": "Cita programada exitosamente"
}
      • Validaciones: Esquema JSON Schema para entrada, con manejo de errores HTTP (e.g., 400 Bad Request para datos inválidos).

  • Servicios de Notificación por Email (Prioridad: Media):

    • Tecnologías: Integración con Nodemailer (para entornos Node.js) o SendGrid API (para escalabilidad en producción), permitiendo envíos transaccionales con tasas de entrega >95%.
    • Funcionalidades: Envío automatizado de recordatorios, confirmaciones y reportes adjuntos en PDF.

  • Mecanismos de Autenticación y Autorización (Prioridad: Alta):

    • Tecnología: JWT (JSON Web Tokens) con firmas RS256, gestionados vía bibliotecas como PyJWT. Tokens expiran en 24 horas, con refresh tokens para sesiones prolongadas.
    • Flujo: Autenticación basada en credenciales (email/contraseña) con hashing bcrypt; roles RBAC (Role-Based Access Control) para diferenciar accesos (e.g., pacientes solo ven su historial).

  • Gestión de Concurrencia y Estado (Prioridad: Alta):

    • No se emplea un “área de datos global” compartida; en su lugar, se utilizan transacciones ACID en PostgreSQL para resolver conflictos (e.g., bloqueos optimistas en actualizaciones de agenda). Esto previene race conditions en escenarios de alta concurrencia, como múltiples reservas simultáneas.

Estas interfaces aseguran un diseño desacoplado, con pruebas unitarias para cada componente (cobertura >80%) y documentación en OpenAPI/Swagger para facilitación de integraciones.

3.4 Interfaces de Comunicaciones

Las interfaces de comunicaciones del SGCM priorizan la seguridad, eficiencia y conformidad con estándares de la industria (e.g., RFC 5321 para SMTP), minimizando latencia en interacciones críticas como notificaciones de citas. Se excluyen protocolos obsoletos para mitigar vulnerabilidades, con énfasis en cifrado end-to-end.

  • Protocolo Principal para Notificaciones (Prioridad: Alta):

    • SMTP con TLS: Puerto 587 para envíos autenticados, utilizando STARTTLS para upgrade a cifrado. Configuración por defecto: Servidor relay como Gmail SMTP o proveedores dedicados (e.g., Amazon SES).
    • Límites Operativos: Máximo 100 emails por hora por usuario para prevenir abuso, con backoff exponencial en reintentos fallidos.

  • Formato de Mensajes (Prioridad: Media):

    • Plantillas HTML Responsivas: Utilizando motores como Jinja2 o Handlebars, con personalización dinámica (e.g., nombre del paciente, detalles de cita). Soporte para adjuntos MIME (PDF de confirmación) y fallback a texto plano para clientes legacy.

  • Estándares de Transporte y Serialización (Prioridad: Alta):

    • HTTP/2 + JSON: Para APIs REST, habilitando multiplexación y compresión HPACK para reducción de overhead en redes de baja banda ancha comunes en entornos clínicos remotos.
    • Beneficios: Mejora en rendimiento (hasta 50% menos latencia) comparado con HTTP/1.1, con soporte para server push en actualizaciones en tiempo real (e.g., cambios de estado de cita).

  • Medidas de Seguridad (Prioridad: Alta):

    • HTTPS Obligatorio: Certificados TLS 1.3 via Let's Encrypt, con HSTS (HTTP Strict Transport Security) para forzar conexiones seguras.
    • Controles Adicionales: Límites de tasa en endpoints (e.g., 60 requests/minuto por IP), protección contra CSRF/XSS mediante tokens y sanitización de inputs.

  • Exclusiones y Opciones Avanzadas (Prioridad: Baja):

    • No se utiliza FTP ni protocolos legacy como Telnet, priorizando REST y WebSockets para comunicaciones bidireccionales.
    • Sincronización Opcional: Integración vía webhooks con calendarios externos (e.g., Google Calendar API), permitiendo pushes/pulls automáticos de disponibilidades. Configuración: Endpoint POST /webhooks/calendario con verificación HMAC para autenticidad.