Saltar al contenido principal

HCE Ecuador — análisis y complemento del documento externo

Punto de partida: especificacion_hce_ecuador (1).md (documento externo, sin fecha de autor, encontrado en Descargas). Este archivo lo analiza sección por sección, señala dónde contradice decisiones ya tomadas en HEALTH-L10N-PLAN.md y PROGRAMAMED-ANALISIS.md (que son la referencia viva del módulo de salud de Xenpia), y añade lo que le falta para que la propuesta sea de verdad una Historia Clínica Electrónica completa y no solo un generador de formularios firmados.

No reemplaza los planes existentes. Es una capa de crítica + gap-analysis encima del documento pegado por el usuario, escrita para decidir qué de ese documento vale la pena incorporar y qué ya está resuelto de otra forma (mejor o peor) en el repo.

0. Veredicto en una frase​

El documento externo describe correctamente la superficie de una HCE ecuatoriana (multi-tenant, RBAC, escalas dinámicas, MSP, órdenes, firma, LOPDP), pero es un documento de arquitecto que nunca vio el sistema real: asume RBAC ya cerrado, propone la variante de firma más cara de las tres posibles sin comparar alternativas, cita formularios MSP con numeración que no coincide con la que ya se validó en el análisis de ProgramaMed, y no dice una palabra sobre buena parte de lo que hace que una historia clínica sea clínica y no solo documental: lista de problemas, medicación activa, alergias como dato estructurado con alertas, inmunizaciones, hospitalización, quirófano, referencia/contrarreferencia, ni interoperabilidad.

1. Reconciliación — dónde este documento choca con lo ya decidido en Xenpia​

Antes de complementar hay que resolver los choques, porque construir sobre un documento que contradice decisiones ya tomadas produce trabajo que se tira.

1.1. Firma electrónica (§5 del documento) — no es la decisión vigente​

El documento propone custodia server-side del .p12, cifrado AES-256, descifrado en RAM con el PIN del médico, estampado PAdES en el backend y validación autónoma contra listas de ARCOTEL/CRL. Esto es exactamente el diseño que Xenpia analizó y descartó el 2026-08-21 (HEALTH-L10N-PLAN.md §19, arquitectura completa archivada en §19.z). Motivo del descarte: custodiar certificados médicos mete gestión de secretos (KMS), TSA, almacén de raíces y responsabilidad legal por clave ajena — un costo que no se paga solo con "cumplir la ley", sino con vidas operativas cada vez que un médico cambia su PIN o su certificado expira.

Decisión vigente (variante B, §19): el sistema genera el PDF (con Chromium) y lleva la trazabilidad; el médico firma fuera, con su propio software (FirmaEC u otro) y su certificado acreditado; el PDF ya firmado se sube de vuelta y se adjunta como la versión válida del documento. No se valida criptográficamente la firma (eso sería la variante C, más cara, pendiente de si algún auditor la exige).

Si se quiere reabrir la variante de custodia propuesta en el documento externo, el disparador correcto es: el validador legal dice que el §3 del SRS exige que firme el sistema (§15, punto 3 de "abiertas"). No basta con que un documento externo la proponga de nuevo — hace falta esa respuesta legal primero, porque el costo (KMS, TSA, custodia) es real y ya se evitó una vez a propósito.

Lo que sí vale del documento (§5.5): el sello de inalterabilidad y el QR de verificación pública sin exponer la historia completa. El QR ya está en el plan (§19, "N0" sobrevive) — es el único mecanismo antifraude que aporta el software con la decisión B. Confirma que esa pieza es correcta; no aporta nada nuevo ahí.

1.2. Numeración de formularios MSP (§3 del documento) — verificar contra fuente oficial​

El documento cita MSP 001 (admisión), MSP 003 (anamnesis y examen físico) y MSP 005 (evolución y prescripción). El análisis de ProgramaMed (sistema real en producción, PROGRAMAMED-ANALISIS.md §5.b) y el checklist de cumplimiento de HEALTH-L10N-PLAN.md (§17) trabajan con MSP 001, 002, 005 y 024, y además con DNEAIS-HCU-FORM.053 (referencia/contrarreferencia) y 024 (consentimiento informado) como los formularios que de verdad se observaron en un sistema en uso.

No tengo forma de verificar aquí cuál numeración es la oficial vigente del MSP — es exactamente el tipo de dato que HEALTH-L10N-PLAN.md §16 marca como "hay que averiguarlo fuera del código, con una fuente oficial y actualizada". Antes de construir contra cualquiera de las dos numeraciones, confirmar con la fuente MSP/ACESS real. Lo que sí es seguro, porque viene de un sistema en producción y no de una especificación de escritorio, es que 053 (referencia/contrarreferencia) y 024 (consentimiento informado) existen y se usan — y el documento externo no los menciona en absoluto. Eso sí es un hueco real, más allá de qué número tenga cada uno (ver §3 más abajo).

1.3. RLS "por JWT" (§1.2 y §6 del documento) — más débil que el patrón ya establecido​

El documento describe RLS como "políticas que garantizan que los datos solo puedan ser leídos por usuarios que compartan el mismo clinica_id en su JWT" — es decir, una política de SELECT filtrando por claim de tenant. Ese es el patrón RLS ingenuo. El patrón que Xenpia ya usa para todo lo clínico (20260815_health_clinical_records.sql en adelante, ver memoria del módulo) es más estricto: las tablas con PHI tienen RLS activado, REVOKE ALL FROM anon, authenticated y sin ninguna política de SELECT. Todo acceso pasa por funciones health_* SECURITY DEFINER que comprueban el permiso exacto (user_has_permission(tenant, perm)) y escriben auditoría en la misma transacción vía health_audit(...).

La diferencia importa: con una política de SELECT por tenant, cualquier query directa a la tabla desde un cliente autenticado del tenant correcto lee PHI sin dejar rastro de auditoría — basta con tener el permiso de tenant, no hace falta el permiso clínico específico, y no hay traza de quién leyó qué. Con el patrón de funciones, leer sin pasar por la función es imposible (no hay política que lo permita), y cada lectura queda auditada. Mantener el patrón de funciones, no adoptar el de políticas de SELECT del documento.

1.4. El backend hoy no aplica nada de esto — hueco P0, no de la ficha clínica​

El documento asume, implícitamente, que RBAC + JWT ya protegen cada endpoint. En el backend real de Xenpia (NestJS), no hay guard global de autenticación: main.ts solo configura CORS, y no hay APP_GUARD en app.module.ts. Se cerró PermissionGuard para /api/scheduling/* (2026-08-18/19); el resto de controladores —incluido casi todo lo que tocaría un módulo de salud nuevo— sigue sin identificar al llamante. Esto es exactamente P0 en HEALTH-L10N-PLAN.md §13.1, y es bloqueante: no importa cuán bien diseñado esté el motor de escalas o el módulo de firma si cualquier curl sin sesión puede leer o escribir la tabla que sea porque el backend usa la service-role key y no pasa por RLS. Cualquier lectura de este documento que planee "activar HCE" sin cerrar P0 primero está construyendo sobre una puerta abierta.

1.5. Clave por contact_id, no por patient_id aislado​

El documento trata al paciente como una entidad clínica aislada. En Xenpia el paciente es, antes que nada, un contacto del CRM (contact_id), porque la plataforma es multicanal (WhatsApp, X, email, webchat) y el mismo contacto que recibe una recordatorio de cita por bot es quien tiene la ficha clínica. La capa clínica ya está clavada por contact_id (consistente con clinical_encounters); health_patients existe pero no reemplaza esa clave. Cualquier "Datos del Acompañante / Representante" (§3.1 del documento) o portal del paciente que se diseñe debe apoyarse en esa unificación, no inventar una identidad de paciente paralela a la de contacto.

1.6. Ya construido — no repetir lo que el documento re-especifica desde cero​

Antes de tomar el documento como punto de partida, esto ya existe en el repo y funciona (ver detalle en memoria de sesión, fases F1–F3):

  • F1 — Recetas imprimibles: catálogo de medicamentos auto-alimentado, posología desglosada, vista de impresión fuera del dashboard, repetir última receta.
  • F2 — Motor de plantillas + documentos: exactamente el motor dinámico que el documento pide en su §2 pero aplicado a documentos, no solo a escalas — plantillas de sistema/tenant/profesional, versionado (editar = versión nueva, nunca UPDATE del cuerpo), emisión editable (se congela el texto final en body_snapshot). Decisión importante ya tomada: el cuerpo es texto con tokens {{origen.clave}}, no HTML libre — el proyecto no tiene sanitizador (ni dompurify), así que HTML de usuario en la vista de impresión sería XSS. Cualquier "editor" que proponga este documento nuevo debe respetar esa restricción o traer su propio saneado.
  • F3 (parcial) — Entrega al paciente por bot: enlace firmado de vida corta (7 días, hash SHA-256, sin guardar el token en claro), resumen por WhatsApp, ruta pública /d/[token] sin login. Esto es, de facto, un portal de paciente mínimo que el documento externo no contempla en absoluto (§6 más abajo).
  • P0 (parcial): PermissionGuard + AppointmentWriteGuard / SchedulingWriteGuard para agenda, con vocabulario "propio/todos" (*.manage vs *.manage_own) reutilizable para médicos que solo deben ver sus propios pacientes.

Pendiente real, ya identificado, y que sí conviene incorporar del documento donde aporta algo (motor de escalas, §2): F4 adjuntos/resultados, F5 formularios MSP estructurados, F6 ficha por especialidad.

2. Complemento sección por sección del documento original​

Sobre §1 (Arquitectura)​

Correcto en el nivel de enunciado, débil en el detalle de RLS (§1.3 arriba). Falta explícitamente:

  • Multi-tenancy jerárquico: el documento dice "Organizaciones/Sucursales" pero no dice qué pasa con un médico que atiende en más de una sucursal o más de un tenant (habitual en Ecuador: un médico con consultorio propio y turnos en una clínica). El modelo de permisos debe soportar membership-por-sucursal, no solo por organización.
  • Roles: faltan al menos Farmacia/Dispensación (si se despacha internamente) y Auditor/Calidad (rol de solo-lectura sobre todo, incluida la auditoría, para preparar inspecciones ACESS sin dar permisos clínicos). El documento tampoco resuelve qué ve un médico de otra sucursal del mismo tenant sobre un paciente compartido — ¿historia única por organización o por sucursal? Response típica en Ecuador: única por organización, con posible bloqueo por especialidad sensible (salud mental, ITS) incluso entre médicos del mismo tenant.
  • Logs de auditoría: el documento dice "solo lectura". Falta especificar qué se audita además de CRUD: impresión, exportación, envío por canal (WhatsApp/email) y intentos fallidos de acceso (permiso denegado), que son justo lo que un auditor pide ver primero.

Sobre §2 (Motor de escalas)​

Bien pensado, y coincide en espíritu con el motor de plantillas ya construido en F2. Le falta:

  • Versionado de la definición de la escala: si Glasgow o PHQ-9 cambian de puntos de corte (pasa: el PHQ-9 tiene variantes clínicas), una consulta antigua debe seguir mostrando la interpretación con la que se calculó, no recalcularse con la definición actual. Mismo patrón que ya se usa para plantillas de documentos (versión nueva, nunca editar la vieja).
  • Escalas seriadas / longitudinales: Glasgow y signos vitales se toman varias veces por turno en un paciente hospitalizado o en observación, no una vez por consulta. El modelo debe soportar una serie temporal por encuentro, no un valor único — si no, no sirve para hospitalización (§4 más abajo) ni para graficar tendencia (curva de temperatura, por ejemplo).
  • Alertas por umbral: el motor calcula e interpreta, pero el documento no dice qué pasa cuando el resultado cae en zona crítica (Glasgow ≤ 8, Silverman severo). Una HCE completa dispara una notificación visible al personal de turno, no solo un texto en la ficha.

Sobre §3 (Localización MSP/ACESS)​

Ya cubierto el choque de numeración (§1.2). Además:

  • 003 §3.2 menciona "Diagnóstico Codificado (CIE-10/CIE-11)" pero no dice qué pasa con el período de transición CIE-10→CIE-11 que Ecuador todavía no ha resuelto oficialmente — conviene que el catálogo soporte ambos con un mapeo, no una migración forzada.
  • Falta por completo la Ficha de Antecedentes como registro estructurado y reutilizable, no texto libre por consulta: alergias, antecedentes patológicos personales/familiares, quirúrgicos y gineco-obstétricos deben vivir como una lista activa que se hereda de consulta en consulta (con fecha de registro y quién la confirmó), no como un campo de texto que hay que volver a escribir cada vez. Esto es el gap clínico más importante del documento entero — ver §3 nueva sección abajo.
  • Falta el carné de vacunación / esquema PAI (Programa Ampliado de Inmunizaciones), obligatorio en control de niño sano y muy pedido en auditorías pediátricas ecuatorianas.
  • Falta antropometría con percentiles OMS para pediatría (el documento menciona "somatometría" de pasada en §1.2, rol de enfermería, pero no la desarrolla): peso/talla/perímetro cefálico graficados contra curvas de crecimiento, no solo el número crudo.

Sobre §4 (Órdenes de laboratorio/imagen)​

Sólido. Complementos:

  • Valores críticos / pánico: el documento valida rango por edad/sexo, pero no dice qué pasa si un valor es crítico (potasio, glucosa, hemoglobina en rangos que ponen en riesgo la vida). Eso debe generar una alerta activa al médico tratante, no solo resaltado visual pasivo en la ficha.
  • Catálogo de exámenes con código LOINC: el documento habla de "catálogo maestro" sin estandarizar. Usar LOINC como identificador interno (además del nombre local) es lo que permite interoperar después con laboratorios externos o el sistema nacional sin re-mapear todo.
  • Integración DICOM/PACS para imagen: el documento solo contempla "carga de PDF de resultados". Un HCE completo para imagenología necesita, como mínimo, un visor de imágenes (aunque sea básico) o un enlace a un visor externo — un PDF de informe sin la imagen es la mitad del resultado.

Sobre §5 (Firma electrónica)​

Ver §1.1 arriba — la variante propuesta no es la vigente. Lo reutilizable es el QR de verificación y el sellado de inalterabilidad conceptual (que en la variante B se logra con body_snapshot congelado + PDF firmado adjunto, no con PAdES generado por el servidor).

Sobre §6 (LOPDP)​

Correcto como principio, incompleto en mecánica:

  • "Firma simple en pantalla o verificación OTP/Check" es vago sobre no-repudio: el checklist de cumplimiento de Xenpia (HEALTH-L10N-PLAN.md §17) ya fija el estándar: trazo u OTP + hash + marca de tiempo del servidor, no solo un booleano de "aceptó". Sin hash+timestamp, el consentimiento no sirve como evidencia ante una auditoría.
  • Falta el derecho de acceso y rectificación además de portabilidad — el paciente debe poder ver su propia historia (parcialmente ya resuelto por el portal mínimo de F3) y pedir corrección de un dato erróneo, lo cual en una HCE nunca es "editar" sino anexar una corrección con referencia al dato original (la historia no se borra ni se reescribe, nunca — eso también es requisito de integridad médico-legal, no solo de LOPDP).
  • Falta la política de retención y eliminación al vencer la relación con el paciente o el tenant: LOPDP exige poder decir cuánto tiempo se conserva cada dato y qué pasa si el paciente pide eliminación (que en salud normalmente no aplica por obligación médico-legal de conservar el expediente — el documento no resuelve esa tensión, que es justo la que un auditor pregunta primero).

3. Lo que falta por completo: la ficha clínica longitudinal​

Esta es la brecha más grande del documento: describe bien documentos que se emiten (formularios, recetas, órdenes) pero no la memoria clínica que persiste entre consultas. Sin esto no hay HCE, hay un generador de PDFs con buena base de datos.

  • Lista de problemas activa (problem list): diagnósticos activos del paciente, independiente de la consulta que los originó, con estado (activo/resuelto/crónico) y fecha. Es lo primero que un médico mira al abrir una ficha que no es suya.
  • Medicación activa / conciliación: qué está tomando el paciente ahora, agregando todas las recetas vigentes (no solo la última), para poder detectar duplicidad terapéutica e interacciones al prescribir algo nuevo. Esto es distinto de F1 (que emite una receta puntual) — es la vista acumulada.
  • Registro de alergias y reacciones adversas como dato estructurado y con alerta activa: el documento lo menciona solo como campo que ve enfermería en triaje. Debe ser un dato que bloquee o advierta al prescribir un medicamento de la misma familia, visible en cualquier pantalla clínica, no solo en la de triaje.
  • Antecedentes reutilizables (ver §2 arriba): patológicos, quirúrgicos, familiares, gineco-obstétricos, tóxico-alérgicos, como registros con fecha, no texto libre reescrito cada vez.
  • Inmunizaciones (esquema PAI, carné de vacunación).
  • Curvas de crecimiento pediátrico con percentiles OMS.
  • Alertas clínicas básicas (CDS mínimo): interacción medicamento-alergia y medicamento-medicamento al guardar una receta. No hace falta un motor de reglas sofisticado para empezar — basta cruzar contra el registro de alergias y la medicación activa antes de guardar.

4. Lo que falta por completo: hospitalización y quirófano​

El documento asume consulta ambulatoria de principio a fin. Si el HCE debe cubrir clínicas u hospitales (el título del documento original dice "Manta Hospital Center" en la memoria del proyecto), faltan:

  • Admisión/hospitalización: nota de ingreso, cama/servicio asignado, médico tratante, evolución diaria (que si se hace bien es la escala §2 en modo serie temporal, no una nota aislada).
  • Hoja de enfermería / balance de turno: signos vitales seriados, balance hídrico, notas de enfermería — el rol "Enfermería/Triaje" del documento se queda corto si hay hospitalización: enfermería necesita su propio flujo de registro continuo, no solo el triaje de una cita.
  • Registro de administración de medicamentos (MAR): qué se administró, cuándo, quién lo administró — distinto de la receta (que es la orden).
  • Epicrisis / resumen de alta: documento obligatorio al dar de alta, resume el episodio completo; es, en la práctica, otra plantilla del motor de documentos (F2) pero con datos que vienen de todo el episodio, no de una sola consulta.
  • Módulo quirúrgico: nota operatoria, registro de anestesia, y el checklist prequirúrgico de seguridad que ProgramaMed ya tiene (ver PROGRAMAMED-ANALISIS.md §5.b, "Indicaciones de seguridad") — el documento externo no lo menciona pese a que ya está validado como necesario en el sistema de referencia.

Si el alcance real es solo ambulatorio, esta sección se puede posponer completa — pero hay que decirlo explícitamente, porque el documento no lo aclara y el nombre del tenant de referencia sugiere lo contrario.

5. Referencia, contrarreferencia y consentimiento informado​

Ya señalado en §1.2 y §1.6: 053 (referencia/derivación/contrarreferencia) y 024 (consentimiento informado) están validados contra un sistema real en producción y el documento externo no los menciona. Son, además, los dos formularios que more probablemente pida un auditor de ACESS antes que los de admisión: el 053 prueba continuidad de cuidado entre niveles de atención, y el 024 prueba no-repudio de consentimiento en procedimientos — que es exactamente el hueco que §6 (LOPDP) del documento deja abierto.

6. Interoperabilidad y portabilidad (más allá de "exportar un ZIP limpio")​

El documento resuelve portabilidad como "exportar en formato estándar". Falta decidir cuál:

  • CIE-10/11 ya está cubierto por diagnóstico codificado.
  • LOINC para exámenes de laboratorio (§4 arriba).
  • HL7 FHIR (recursos Patient, Condition, MedicationRequest, Observation, DocumentReference) como formato de exportación real si algún día hay que interoperar con otro sistema o con una red nacional de salud — no hace falta implementarlo ahora, pero el modelo de datos interno (ya bastante cercano: encuentros, recetas, documentos como entidades separadas) debería poder mapearse a FHIR sin rediseño, y conviene tenerlo en mente al nombrar campos.
  • Portal del paciente: el documento no lo menciona en absoluto, y Xenpia ya tiene la mitad construida (F3: enlace firmado + resumen por WhatsApp). Completar esto (ver ficha activa completa, no solo el último documento entregado) es más barato que construir un portal web nuevo desde cero, porque reutiliza la identidad de contacto multicanal que ya existe.

7. Seguridad operativa que el documento da por hecha​

  • 2FA obligatorio para médicos y administradores — ya está en el checklist de cumplimiento de Xenpia (P0) y el documento ni lo menciona.
  • Expiración de sesión y bloqueo tras intentos fallidos — estándar en cualquier HCE, ausente del documento.
  • Cifrado en tránsito y en reposo — el documento solo cifra el .p12 (que además ya no aplica, §1.1); el resto de PHI en Supabase depende de la configuración de la instancia, que conviene documentar explícitamente como requisito, no asumir.
  • Backup y continuidad: RPO/RTO para el expediente clínico — perder horas de historia clínica no es como perder horas de un CRM. El documento no lo toca.
  • Modo de baja conectividad: relevante para consultorios rurales ecuatorianos con internet inestable; ni el documento ni el plan actual de Xenpia lo resuelven. Vale la pena decidir explícitamente si queda fuera de alcance (probablemente sí, dado que el resto de la plataforma ya asume conexión permanente vía Supabase/BullMQ) en vez de dejarlo sin mencionar.

8. Reportería más allá de los 9 reportes de ProgramaMed​

El documento no toca reportería. ProgramaMed ya tiene 9 reportes fijos (PROGRAMAMED-ANALISIS.md §6). Para superarlo, no igualarlo, hace falta al menos:

  • EPI-1: notificación epidemiológica obligatoria al SIVE — ya identificado en HEALTH-L10N-PLAN.md §13.3 como parte de L6, ausente del documento externo pese a ser, junto con 053/024, de los requisitos más auditables.
  • Panel de cumplimiento para preparar una inspección ACESS: básicamente convertir la tabla de §17 de HEALTH-L10N-PLAN.md en una pantalla, no solo un documento interno.

9. Cómo encaja todo esto en las fases ya existentes​

No propongo una numeración de fases nueva — ya hay una (F1–F6 para el motor clínico, L0–L6 para localización, P0 para prerrequisitos de plataforma) y duplicarla solo generaría confusión. Ubicación sugerida de lo nuevo:

Lo que faltaEncaja en
Auth global del backend, 2FA, expiración de sesiónP0 (ya bloqueante, sin esto nada de lo demás es seguro)
Lista de problemas, medicación activa, alergias con alerta, antecedentes reutilizables, inmunizaciones, curvas de crecimientoNueva fase de ficha longitudinal, entre F3 y F4 — es más fundacional que adjuntos (F4) porque F4 cuelga adjuntos de algo, y hoy ese "algo" es solo el encuentro puntual
Formularios 053, 024 + resto de series MSPF5 / L5, ya previsto, solo hay que confirmar numeración real (§1.2)
Firma variante B (subir PDF firmado como adjunto)F4 + L6, tal como ya está decidido en §19
Referencia/contrarreferencia como flujo (no solo formulario)Junto con F5, porque implica estado (GENERADA→PROCESADA→COMPLETADA, mismo patrón que ya usan las órdenes de §4)
Hospitalización, quirófano, MARFuera de alcance salvo decisión explícita — no estaba en ningún plan anterior; preguntar primero si aplica antes de diseñar
EPI-1, panel de cumplimientoL6, ya previsto para EPI-1; el panel es nuevo, bajo costo, alto valor para venta a clínicas que necesitan pasar ACESS
FHIR / LOINC como convención de nombres internosNo es una fase, es una disciplina a aplicar ahora en F4–F6 para no re-nombrar campos después

10. Preguntas abiertas para el usuario (no las puede resolver el código)​

  1. ¿El alcance real incluye hospitalización (el nombre "Hospital Center" de la demo lo sugiere) o el sistema es y seguirá siendo ambulatorio? Cambia si vale la pena diseñar §4 de este documento (hospitalización/ quirófano) o se descarta explícitamente.
  2. ¿Numeración correcta de los formularios MSP — 001/003/005 (documento externo) o 001/002/005/024 + 053 (lo ya validado contra ProgramaMed)? Hace falta una fuente oficial, no otro documento de escritorio (mismo punto que ya estaba abierto en HEALTH-L10N-PLAN.md §16).
  3. ¿Quién es el validador legal que confirma si la variante B de firma (médico firma fuera, sube el PDF) satisface a la ACESS, o si de verdad hace falta que el sistema firme (lo que reabriría el diseño costoso que este documento propone en su §5)? Es la pregunta bloqueante más antigua del plan (§15, punto 3), y este documento nuevo es un buen motivo para por fin hacerla.