Salud — FHIR y HL7.
Datos clínicos que viajan entre HIS, EMR, lab, prepaga y app del paciente.
El sector salud opera con HL7 v2 hace décadas y con FHIR desde hace pocos años. Una red hospitalaria, una prepaga, un laboratorio: cada uno tiene sistemas distintos que tienen que intercambiar información clínica con seguridad, granularidad y trazabilidad. Con MuleSoft + módulo HL7 armás un hub que convierte HL7 v2 a FHIR como modelo canónico, expone APIs para apps de pacientes y prestadores, y mantiene audit trail clínico.
¿Qué resuelve un hub clínico con MuleSoft?
Hospitales, laboratorios, prepagas y aseguradoras intercambian información crítica con sistemas heterogéneos: HL7 v2 sobre MLLP, APIs SOAP custom, FHIR moderno, archivos planos. Sin un hub, cada nueva integración es un proyecto puntual que multiplica costos y riesgos. Con MuleSoft armás un punto único donde HL7 v2 se traduce a FHIR canónico, cada prestador se conecta una sola vez y los nuevos casos clínicos se montan sobre lo existente con trazabilidad regulatoria.
- HL7 v2 sobre MLLP recibido, parseado y traducido a FHIR Bundles.
- FHIR R4 como modelo canónico interno, expuesto a apps de paciente y prestadores.
- Audit trail clínico granular para cumplimiento regulatorio.
- Workflows de alerta clínica cuando un valor sale fuera de rango crítico.
Sistemas típicos involucrados
Las familias que conviven en un hub clínico serio.
HIS y EMR
Epic, Cerner Millennium, Phillips Tasy, MV, Dedalus y sistemas hospitalarios custom. Hablan HL7 v2 sobre MLLP, alguna API SOAP y crecientemente FHIR.
LIS, RIS y PACS
Sistemas de laboratorio (Mindray, Roche, custom), radiología y diagnóstico por imágenes. Generan resultados que tienen que llegar al EMR y a la aseguradora.
Prepagas y aseguradoras
OSDE, Sancor, Bradesco Saúde, Salud y equivalentes regionales: autorizaciones, gestión de afiliados, validación de cobertura, reporte de prácticas.
App de paciente y portales
Apps de paciente con turnos, historia clínica y resultados; portales de prestadores; sistemas gubernamentales de reporting epidemiológico.
Arquitectura objetivo
Cada sistema fuente entra por su adapter. Adentro todo es FHIR.
+----------------+ +----------------+ +----------------+
| HIS Hospital A | | LIS Lab B | | EMR Clínica C |
+--------+-------+ +--------+-------+ +--------+-------+
| HL7 v2 / TCP | HL7 v2 | FHIR
v v v
+----------------------------------------------------+
| Capa System APIs / Adapters |
| his-fhir-sapi / lis-fhir-sapi / |
| emr-fhir-sapi (transforman a FHIR común) |
+----------------------+-----------------------------+
|
v
+----------------------------------------------------+
| Process APIs (FHIR-aware) |
| patient-summary-pa / referral-pa / lab-pa |
+----------------------+-----------------------------+
|
v
+----------------------------------------------------+
| Experience APIs |
| patient-app-eapi / provider-portal-eapi |
| insurance-portal-eapi |
+----------------------------------------------------+System APIs
Una System API por sistema fuente: his-fhir-sapi, lis-fhir-sapi, emr-fhir-sapi, insurance-sapi. Reciben HL7 v2 o el formato custom y exponen FHIR R4 hacia adentro.
Process APIs
patient-summary-pa agrega la vista clínica resumida. referral-pa orquesta derivaciones entre prestadores. lab-result-pa ingesta resultados, los matchea con el ServiceRequest y los persiste.
Experience APIs
patient-app-eapi para apps de pacientes (turnos, estudios, historial). provider-portal-eapi para médicos y enfermería. insurance-eapi para portales de aseguradoras.
Flujo paso a paso
El laboratorio envía un resultado al hospital y a la aseguradora con audit trail clínico completo.
- 1 El LIS del laboratorio genera un mensaje HL7 v2 ORU^R01 con el resultado de un análisis del paciente y lo envía vía MLLP al endpoint del hub MuleSoft.
- 2 El módulo HL7 de MuleSoft escucha en el puerto MLLP, parsea el mensaje y valida estructura. Si la estructura es inválida, responde NAK con AE y deja el mensaje en quarantine para que operación lo revise.
- 3 El System API lis-fhir-sapi transforma el ORU^R01 a un FHIR Bundle con resources Observation, vinculado a Patient y al ServiceRequest original.
- 4 La Process API lab-result-pa recibe el Bundle y consulta service-request-sapi para encontrar el ServiceRequest del médico que pidió el lab.
- 5 La Process API persiste la Observation en el EMR del hospital vía his-fhir-sapi POST /Observation usando el FHIR canónico interno.
- 6 Notifica al médico solicitante: push a su app y alerta dentro del EMR. La Experience API provider-portal-eapi formatea el payload para el portal.
- 7 Si el valor de la Observation cae fuera del rango crítico, dispara workflow de alerta clínica: por ejemplo, leucocitos por debajo de umbral críticos llama al médico de guardia.
- 8 Genera reporte para la aseguradora con la práctica realizada vía insurance-sapi para cierre del circuito de cobertura.
- 9 Antes de cerrar, el adapter responde ACK con AA al LIS para confirmar recepción. Si MuleSoft no pudo procesar, responde AR (application reject) y dispara alerta crítica.
- 10 Cada paso queda en audit log granular con identificadores del mensaje, del paciente y del prestador. Logs ocultan o cifran datos sensibles para cumplir regulación de PHI.
Patterns aplicados
Los patrones que sostienen un hub clínico en producción.
FHIR como canónico
HL7 v2 entra por la puerta legacy y sale como FHIR R4 hacia adentro. Las Process y Experience APIs trabajan siempre en FHIR estándar.
Acknowledgment workflow
HL7 v2 exige ACK / NAK con MSH y MSA. El hub responde AA, AE o AR según el caso y deja trazabilidad de cada interacción.
Idempotency vía MSH-10
El Message Control ID identifica unívocamente cada mensaje HL7. Reentregas no duplican observaciones ni encuentros clínicos.
Encoding standardization
UTF-8 forzado en todo el hub, con alertas si una fuente envía con encoding distinto. Evita que tildes y ñ rompan campos clínicos.
Audit trail granular
Cada acceso y cada modificación queda registrada con identidad del actor, recurso tocado y timestamp. Insumo directo para auditoría regulatoria.
Anonymization on read
Para feeds de research o BI clínico, el Bundle sale con Patient anonimizado siguiendo políticas configurables sin perder utilidad estadística.
Cómo lo implementamos
Cinco fases con el equipo clínico y de IT del cliente, sin big bang sobre el HIS.
Mapeo de fuentes y mensajería clínica
Inventario de HIS, EMR, LIS, RIS, prepagas y portales en uso. Mapeo de mensajes HL7 v2 (ADT, ORM, ORU, MDM) y de los Z-segments custom de cada hospital. Identificación de los primeros casos clínicos a habilitar.
Modelo canónico FHIR y contratos
Definición del modelo canónico FHIR R4 interno, contratos de System APIs por sistema fuente, plan de manejo de Z-segments, política de PHI en logs, modelo de audit trail y reglas de alertas clínicas.
Hub HL7 y FHIR en marcha
Implementación del listener MLLP, parser HL7 v2, transformaciones a FHIR, System APIs por sistema, Process APIs (patient-summary, referral, lab-result), Experience APIs para app de paciente y portales. Tests MUnit y mensajes sintéticos.
Hardening clínico y go-live
Hardening, security review específico para PHI, load testing con volumen real, validación con equipos clínicos, runbooks para mesa de ayuda. Go-live por fuente (primero un hospital, luego una red) con hypercare.
Nuevos prestadores y casos clínicos
Cada nuevo prestador, lab o aseguradora se incorpora reusando las System APIs y el modelo canónico. Nuevos casos clínicos (telemedicina, derivaciones, programas de prevención) consumen el hub. Managed services y CoE.
Requisitos del proyecto
Lo que tiene que estar disponible del lado del cliente para arrancar.
Datos mínimos
Acceso al HIS / EMR / LIS, especificación de mensajes HL7 v2 y Z-segments en uso, endpoints FHIR cuando existen, accesos a portales de aseguradoras, mensajes de muestra para validación.
Licencias y capacidades
Anypoint Platform, módulo HL7 de MuleSoft, conectores para sistemas fuente cuando aplica, infraestructura para audit trail con retención ajustada a la regulación local.
Integraciones típicas
App de paciente, portales de prestadores, sistemas de aseguradoras, motores de reglas clínicas, sistemas gubernamentales de reporting epidemiológico, BI clínico anonimizado.
Pre-requisitos organizacionales
IT lead, referente clínico (médico CMIO o jefe de informática), equipo de seguridad y compliance, sponsor del negocio (dirección médica o gerencia de operaciones de la red).
KPIs operativos
Las métricas que típicamente mejoran al consolidar la integración clínica en un hub.
| KPI | Qué mide | Por qué importa |
|---|---|---|
| Mensajes por día por fuente | Volumen de HL7 v2 y FHIR ingestados, separados por hospital, lab y aseguradora. | Permite dimensionar capacidad y detectar caídas o cambios de comportamiento de cada fuente clínica. |
| Parse error rate | Porcentaje de mensajes que no pueden parsearse por estructura inválida o Z-segments no contemplados. | Indica problemas de configuración del lado del prestador y prioriza ajustes en el hub. |
| Quarantine count | Cantidad de mensajes que quedan en cuarentena por error de validación. | Carga operativa para el equipo clínico y de IT del cliente; tiene que tender a cero. |
| ACK response time P95 | Tiempo desde que llega el HL7 v2 hasta que se responde ACK al sistema fuente. | El sistema fuente exige ACK rápido para no bloquear su cola; cualquier degradación afecta al hospital o al lab. |
| Clinical alert dispatch time | Latencia desde que entra una observación crítica hasta que sale la alerta clínica. | Métrica directa sobre seguridad del paciente; valores fuera de rango deben llegar al médico en segundos. |
| PHI policy violations | Cantidad de eventos donde un log o un payload externo expuso datos sensibles más allá de lo permitido. | Indicador clave de cumplimiento regulatorio y de calidad del hub. |
Time-to-value: primer prestador conectado al hub en producción tras 14 a 18 semanas, con métricas observables a las 4 semanas siguientes.
Cómo se mide: dashboard sobre Anypoint Monitoring por fuente, integrado con Splunk, Datadog o Grafana cuando ya existe ese stack del lado del cliente, más reportes regulatorios específicos.
Preguntas frecuentes
Conviven. HL7 v2 sigue siendo el estándar dominante en hospitales LATAM y va a estar presente por años. FHIR es el estándar moderno y se usa para apps de paciente, intercambio entre instituciones y nuevos casos. La estrategia que usamos es tener FHIR R4 como modelo canónico interno y traducir HL7 v2 entrante a FHIR en la System API correspondiente, sin pelearle al hospital la migración de su HIS.
Los Z-segments son la realidad: cada hospital tiene los suyos y los usan para datos críticos. Se mapean uno a uno como parte del adapter del hospital, se documentan y se exponen como extensiones FHIR cuando aplica. Cuando aparece un Z-segment nuevo no contemplado, el mensaje queda en cuarentena con alerta para que el equipo lo revise antes de propagarlo.
El hub se diseña con esa regulación como requisito. Audit trail granular, encriptación en tránsito y reposo, política de PHI en logs (los datos clínicos no aparecen en logs operativos), retención configurable y trazabilidad completa de accesos. La parametrización se ajusta a la regulación específica del país (ANS Brasil, Superintendencia Argentina, MINSAL Chile y equivalentes).
La app del paciente consume patient-app-eapi, una Experience API en FHIR. Detrás, la Process API patient-summary-pa agrega Patient, Encounters, Conditions, Observations y MedicationRequests siguiendo el estándar International Patient Summary. La app no conoce el HL7 v2 ni los sistemas fuente; solo ve FHIR limpio y consistente entre todos los prestadores.
Los logs operativos del hub no contienen PHI. Los identificadores y los valores clínicos se reemplazan por hashes o se omiten directamente en los logs estándar. Cuando hace falta debug clínico, hay un canal separado, restringido por permisos, donde se puede acceder al payload completo siguiendo política de auditoría. Esto es requisito regulatorio y cuando no se respeta, abre exposición legal.
Datos clínicos donde tienen que estar, cuando se necesitan.
Hablemos de tu red hospitalaria o tu prepaga y diseñamos juntos el hub clínico.