Por Qué Importa la Migración de HL7 v2 a FHIR
HL7 v2.x ha sido la columna vertebral de la interoperabilidad sanitaria desde finales de los años 1980. Cientos de miles de interfaces hospitalarias en todo el mundo siguen intercambiando mensajes ADT, ORU, ORM y MDM sobre conexiones MLLP. Sin embargo, la industria está migrando progresivamente a FHIR R4 — impulsada por las regulaciones federales de EE.UU. (reglas de interoperabilidad CMS y ONC), los ecosistemas de aplicaciones SMART on FHIR y las plataformas EHR en la nube que funcionan nativamente con REST + JSON.
El Desafío Central del Mapeo
HL7 v2 y FHIR representan la información clínica de formas muy diferentes. Un mensaje ADT^A01 v2 codifica una admisión de paciente en una estructura plana delimitada por tuberías, con relaciones a nivel de segmento (PID → datos del paciente, PV1 → datos de la visita, EVN → metadatos del evento). FHIR R4 representa el mismo evento como un grafo de recursos enlazados: un recurso Patient referenciado por un recurso Encounter. El mapeo es conceptualmente sencillo pero operativamente complejo — cada campo componente en un tipo de datos XPN, XCN, CX o PL debe descomponerse y reensamblarse en el tipo de datos FHIR correcto.
ADT a Patient y Encounter
La tarea de migración más común es convertir mensajes ADT^A01 (admisión) y ADT^A03 (alta). El segmento PID se mapea a un Patient FHIR: PID-3 (lista CX) se convierte en Patient.identifier, PID-5 (XPN) en Patient.name con componentes family y given, PID-8 en Patient.gender usando el vocabulario administrative-gender, y PID-11 (XAD) en Patient.address. El segmento PV1 se mapea a un Encounter FHIR: PV1-2 (Clase de Paciente) se mapea a Encounter.class usando el sistema ActCode v3, PV1-7 (XCN) a Encounter.participant (attender), PV1-19 a Encounter.identifier, y PV1-44/PV1-45 a Encounter.period.start y .end.
ORU a DiagnosticReport y Observations
Los mensajes ORU^R01 transportan resultados de laboratorio, radiología y observaciones clínicas. El segmento OBR se mapea a un DiagnosticReport FHIR: OBR-4 (ID de Servicio Universal, CWE) se convierte en DiagnosticReport.code, OBR-7 en effectiveDateTime, y OBR-14 en issued. Cada segmento OBX se mapea a un recurso Observation FHIR separado, con el conjunto de resultados agrupado bajo referencias DiagnosticReport.result. El campo tipo de valor OBX (OBX-2) determina el tipo de valor de la observación FHIR: NM (Numérico) se mapea a valueQuantity con OBX-6 como unidad, CE/CWE a valueCodeableConcept, y ST/TX/FT a valueString.
ORM a ServiceRequest
Los mensajes ORM^O01 representan órdenes. El segmento ORC proporciona el control de orden (ORC-1), número de orden del solicitante (ORC-2 → ServiceRequest.identifier), número de orden del ejecutor (ORC-3), estado de la orden (ORC-5 → ServiceRequest.status) y proveedor solicitante (ORC-12 → ServiceRequest.requester). El segmento OBR aporta el código de procedimiento (OBR-4 → ServiceRequest.code), fecha/hora solicitada (OBR-6 → ServiceRequest.occurrenceDateTime) y prioridad (OBR-5 → ServiceRequest.priority).
Consideraciones Clave en la Migración
- Sistemas de identificadores: Los identificadores CX de HL7 v2 (PID-3, PV1-19) llevan una autoridad asignada. En FHIR, deben convertirse en URIs de Identifier.system — idealmente OIDs (urn:oid:...) o URLs canónicas de NamingSystem registradas en tu servidor FHIR.
- Terminología: Los valores de tablas v2 (0001 para sexo, 0004 para clase de paciente) deben mapearse a sistemas de códigos definidos por FHIR. Muchas organizaciones necesitan un servicio de terminología o tabla de consulta para gestionar códigos locales en OBR-4 u OBX-3.
- Z-segments: Los Z-segments personalizados (ZDG, ZPI, ZRX) no tienen equivalente FHIR y requieren extensiones o recursos contenidos, añadiendo complejidad al proyecto.
- Versionado: HL7 v2.3.1, v2.4, v2.5 y v2.5.1 difieren en posiciones de campo y tipos de datos disponibles. Un mapeador robusto debe gestionar múltiples versiones con gracia.
- Flujo bidireccional: Muchas arquitecturas de integración requieren tanto la traducción v2-a-FHIR como FHIR-a-v2. Diseña el esquema de mapeo para que sea reversible cuando sea posible.