Interoperabilidad en Salud: HL7 FHIR y APIs para Hospitales en Chile

La historia: del papel a las APIs

Antes de HL7, cada hospital desarrollaba integraciones punto-a-punto entre sus sistemas. Un hospital con HIS + laboratorio + radiología + farmacia podía terminar con 12 interfaces personalizadas, cada una rota con cada actualización. En 1987, un grupo de profesionales de sistemas de salud fundó HL7 con un objetivo simple: crear un lenguaje común para el intercambio clínico.

La evolución ha pasado por tres grandes generaciones:

HL7 v2: el workhorse silencioso

A pesar de tener 35+ años, HL7 v2 sigue siendo el estándar de facto en integraciones hospitalarias. Es probable que hoy mismo, en cualquier hospital mediano de Chile, estén viajando miles de mensajes HL7 v2 entre HIS, laboratorio y radiología sin que nadie los vea.

Anatomía de un mensaje HL7 v2

Un mensaje HL7 v2 se compone de segmentos (líneas), cada uno con un código de 3 letras y múltiples campos delimitados:

MSH|^~\&|HIS|HOSPITAL|LAB|CENTRAL|202506120830||ADT^A01|MSG00001|P|2.5
EVN|A01|202506120830
PID|1||12345^^^HOSPITAL^MR||GONZÁLEZ^FELIPE||19800615|M|||AV. APOQUINDO 1234^^SANTIAGO^^7550000||+56912345678
PV1|1|I|CARDIO^301^A||||DR.SILVA||||||||||||

Tipos de mensajes HL7 v2 más usados

FHIR: la nueva generación

FHIR fue diseñado desde cero para la web moderna. En lugar de mensajes transaccionales, expone recursos clínicos como endpoints REST. Un desarrollador familiar con APIs web (Stripe, Twilio, GitHub) puede aprender FHIR en semanas, lo que contrasta con meses o años para HL7 v2/v3.

Principios de diseño de FHIR

• Recursos discretos: cada entidad (paciente, observación, medicamento) tiene un modelo formal reutilizable.
• RESTful: operaciones CRUD estándar (GET, POST, PUT, DELETE) y búsqueda parametrizada.
• Formatos múltiples: mismo contenido en JSON, XML, Turtle (RDF).
• Extensibilidad: mecanismo formal de extensiones para casos específicos sin romper interoperabilidad.
• Perfiles y guías de implementación: organizaciones/países publican "perfiles" que restringen o extienden FHIR para su contexto.
• Human-readable: cada recurso incluye una sección narrativa HTML para que no-técnicos entiendan el contenido.

Ejemplo: recurso Patient en FHIR

{
  "resourceType": "Patient",
  "id": "12345",
  "identifier": [{
    "system": "http://hospital.cl/mrn",
    "value": "12345"
  }],
  "name": [{
    "family": "González",
    "given": ["Felipe"]
  }],
  "gender": "male",
  "birthDate": "1980-06-15",
  "address": [{
    "line": ["Av. Apoquindo 1234"],
    "city": "Santiago",
    "postalCode": "7550000"
  }],
  "telecom": [{
    "system": "phone",
    "value": "+56912345678"
  }]
}

HL7 v2 vs FHIR: tabla comparativa

FHIR aplicado a trazabilidad de dispositivos médicos

La trazabilidad en salud es uno de los casos de uso donde FHIR brilla especialmente. Los recursos relevantes son:

Ejemplo práctico: Device con UDI

{
  "resourceType": "Device",
  "udiCarrier": [{
    "deviceIdentifier": "00614141999996",
    "issuer": "http://hl7.org/fhir/NamingSystem/gs1",
    "carrierHRF": "(01)00614141999996(11)230101(21)SN123456"
  }],
  "status": "active",
  "manufacturer": "MedDevices Inc.",
  "manufactureDate": "2023-01-01",
  "expirationDate": "2028-01-01",
  "lotNumber": "LOT-2023-789",
  "serialNumber": "SN123456",
  "modelNumber": "CX-300",
  "type": {
    "coding": [{
      "system": "http://snomed.info/sct",
      "code": "448596008",
      "display": "Coronary artery stent"
    }]
  }
}

Con este modelo, una consulta como GET /Device?lot-number=LOT-2023-789 devuelve todos los dispositivos de ese lote, y GET /DeviceUseStatement?device.lot-number=LOT-2023-789 devuelve todos los pacientes que los recibieron — en segundos. Esta capacidad es crítica para respuesta rápida ante recalls.

Arquitectura de integración: patrones comunes

Motor de integración (Integration Engine)

La pieza central en la mayoría de hospitales. Recibe mensajes HL7 v2 de un sistema, los transforma (si es necesario) y los reenvía a los destinos. Herramientas líderes:

• Mirth Connect (NextGen) y Open Integration Engine: Mirth Connect fue open source de referencia en LATAM hasta que NextGen lo migró a licencia propietaria desde la versión 4.6 (marzo 2025). El fork comunitario continúa bajo el nombre Open Integration Engine, manteniendo licencia open source.
• Rhapsody (Lyniate, ahora Rhapsody Health Solutions): comercial enterprise, potente.
• Cloverleaf (InterSystems): motor histórico, robusto.
• IRIS for Health (InterSystems): evolución moderna con FHIR nativo.
• Apache Camel + HAPI: opción open source para equipos con capacidad de desarrollo.

Servidor FHIR

Expone APIs REST con los recursos FHIR. Puede ser el corazón de un nuevo sistema o un gateway frente a un sistema legacy. Opciones principales:

• HAPI FHIR (Java): open source líder, mantenido por Smile CDR.
• Medplum (TypeScript): moderno, cloud-first, ideal para startups.
• Microsoft Azure Health Data Services (FHIR): PaaS gestionado, ideal para hospitales con Azure.
• Google Cloud Healthcare API: PaaS similar en GCP.
• Firely Server (Vonk): servidor FHIR comercial sobre .NET de la empresa Firely (Países Bajos), con edición community.
• Aidbox (Health Samurai): servidor FHIR comercial de la empresa Health Samurai, con tier de desarrollo gratuito. (Nota: Aidbox no pertenece a Firely.)
• Blaze FHIR Server (Samply): open source, enfocado en investigación.

Gateway HL7 v2 ↔ FHIR

Traduce entre ambos mundos: recibe un ORU^R01 (resultado de laboratorio en HL7 v2) y lo convierte en un recurso Observation FHIR, disponible vía API para apps modernas. Permite modernizar progresivamente sin reemplazar integraciones existentes.

Seguridad: SMART on FHIR y OAuth 2.0

Una API FHIR pública sin autenticación es un desastre de seguridad (y legal) esperando ocurrir. El framework estándar es SMART on FHIR, que combina:

• OAuth 2.0: autorización delegada, el usuario no comparte contraseña con la app.
• OpenID Connect: autenticación de identidad.
• Scopes granulares FHIR: la app solicita permisos específicos (ejemplo: patient/Observation.read pero no user/*.write).
• Contexto de lanzamiento: la app recibe el paciente y encuentro actual del EHR.

IHE: integración lista para producción

IHE (Integrating the Healthcare Enterprise) no compite con HL7 o FHIR: los combina en "perfiles" específicos para casos reales. Un perfil IHE dice: "para resolver el caso X, usen estas operaciones de estos estándares de esta forma". Perfiles relevantes para trazabilidad:

FHIR en el ecosistema de salud chileno

Chile está adoptando FHIR progresivamente. Iniciativas relevantes:

• Registro Nacional de Prestadores Individuales de Salud (RNPI): registro de la Superintendencia de Salud que mantiene los datos de profesionales habilitados; servicios gubernamentales exploran FHIR (recursos Practitioner y Organization) para exponerlo vía API.
• Estrategia Nacional de Salud Digital y de Interoperabilidad (Minsal): recomienda estándares HL7 v2, CDA y FHIR. Documentación en el portal de Salud Digital del Minsal.
• HL7 Chile: capítulo nacional de HL7 International (hl7chile.cl) que promueve adopción y publica guías de implementación localizadas.
• Proyectos privados: varias clínicas privadas han implementado servidores FHIR internos para portal del paciente, integraciones con apps y APIs hacia laboratorios externos.
• IHE LAC y FHIR LATAM: capítulos regionales de IHE y comunidades que promueven perfiles comunes para intercambio transfronterizo de datos clínicos en urgencias.

Casos de uso concretos por área

Farmacia hospitalaria

Prescripción electrónica completa basada en FHIR: MedicationRequest del médico, MedicationDispense del químico, MedicationAdministration de la enfermera. Cada acción queda trazada, auditada y disponible para análisis. Integración con catálogos ATC y códigos ISP.

Laboratorio clínico

ServiceRequest desde el HIS, Specimen al recibir la muestra, DiagnosticReport con Observations al emitir resultado. Compatibilidad total con LOINC para codificación de exámenes.

Imagenología

Integración con RIS y PACS mediante el perfil IHE XDS-I, o directamente con ImagingStudy en FHIR. El recurso contiene referencias a las imágenes DICOM en el PACS.

Investigación clínica

Plataformas de investigación multicéntrica extraen datos anonimizados vía FHIR para entrenar algoritmos de IA o estudios clínicos. El recurso ResearchStudy modela el estudio y ResearchSubject los participantes.

Trazabilidad e implantes

Todos los implantes (stents, marcapasos, prótesis, válvulas) quedan registrados como Device con UDI. Ante un recall, una query FHIR identifica en segundos a todos los pacientes afectados. Para detalle ver artículos sobre stents coronarios y vasculares.

Checklist para implementar HL7 FHIR

Errores comunes al implementar HL7/FHIR

Glosario de términos clave

Fuentes y enlaces oficiales