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.
Tres Flujos de Trabajo de Migración
El flujo más habitual empieza con una actualización demográfica sintética ADT^A08: pégala, revisa el recurso Patient generado en la tabla de mapeo para confirmar que los componentes family y given de PID-5 llegaron correctamente a Patient.name, y luego copia el JSON directamente al Validador de Recursos FHIR para atrapar cualquier problema estructural antes de que llegue a un servidor de pruebas.
Un segundo flujo convierte un resultado de laboratorio sintético ORU^R01. La tabla de mapeo es la forma más rápida de confirmar que el tipo de valor de OBX-2 produjo la forma FHIR correcta — un OBX NM (numérico) se convierte en Observation.valueQuantity con la unidad de OBX-6 adjunta, mientras que un resultado CWE se convierte en valueCodeableConcept — una distinción que vale la pena comprobar en cada interfaz nueva en lugar de dar por hecho que se mantuvo.
Un tercero convierte una orden sintética ORM^O01 e incluye deliberadamente un segmento NK1 (familiar) para ver cómo el panel de advertencias lo marca como no mapeado — una forma rápida de construir la lista de segmentos que tu proyecto de migración necesitará mapear con una extensión personalizada o un recurso contenido, antes de que una interfaz real entre en producción.
Cuándo No Usar Esta Herramienta
El conversor cubre solo eventos ADT de admisión/alta/actualización, resultados ORU de laboratorio y órdenes ORM — tipos de mensaje como SIU (programación de citas), MDM (documentos), BAR (facturación) y DFT (transacciones financieras) no se mapean y producen un bundle parcial solo con Patient desde el segmento PID. NK1, IN1, GT1, AL1, DG1 y cualquier Z-segment se marcan como no mapeados en lugar de traducirse. Vale la pena decirlo con claridad: seleccionar FHIR R5 en el control de versión cambia la etiqueta pero no la lógica de mapeo — las formas de recurso producidas están estructuradas como R4 sea cual sea la versión elegida, así que trata la salida como R4 y valídala como tal hasta que se añada un mapeo específico de R5. Para cualquier cosa más allá de estos tipos de mensaje, o para conformidad completa con un perfil, cuenta con un motor de interfaz dedicado o una herramienta de mapeo consciente de guías de implementación.
Ruta HL7 v2 → FHIR R4, en Breve
Un breve extracto de los mapeos a nivel de campo que aplica esta herramienta, útil como referencia rápida junto a la tabla completa de procedencia que genera para cada conversión:
| Campo HL7 v2 | Ruta FHIR R4 | Tipo de mensaje |
|---|
| PID-3 (CX) | Patient.identifier | ADT |
| PID-5 (XPN) | Patient.name | ADT |
| PV1-2 | Encounter.class | ADT |
| OBR-4 (CWE) | DiagnosticReport.code | ORU |
| OBX-5 | Observation.value[x] | ORU |
| ORC-5 | ServiceRequest.status | ORM |
La guía completa y acumulativa de mapeo a nivel de campo para la industria la mantiene HL7 como la Guía de Implementación oficial v2-a-FHIR, en la que se inspiran los mapeos de esta herramienta para los tipos de mensaje que soporta.
Procesamiento Local y Flujos de Trabajo Regulados por HIPAA
Un mensaje ADT u ORU que se está migrando es exactamente el tipo de registro que HIPAA clasifica como información sanitaria protegida — nombre del paciente, MRN, diagnósticos, valores de laboratorio. Enviar ese mensaje por una API de conversión en la nube significaría transmitir PHI real a un tercero en mitad de la migración. Como este conversor analiza y convierte por completo en el motor JavaScript del navegador, un ingeniero de integración puede convertir un mensaje real de producción en una estación de trabajo hospitalaria y saber que el contenido nunca salió de esa máquina — una diferencia relevante durante un corte de interfaz activo, cuando hay que comprobar mensajes reales, no solo muestras sintéticas.
Trabajar Junto a Otras Herramientas FHIR y HL7
Una comprobación de migración suele encadenar tres herramientas: inspecciona el mensaje origen en el Visor HL7 para confirmar qué segmentos y campos están realmente poblados, conviértelo aquí a FHIR R4, y luego pega el Bundle resultante en el Validador de Recursos FHIR para confirmar que la salida mapeada es estructuralmente correcta antes de que llegue a un servidor. Ejecutar las tres en secuencia convierte "¿sobrevivirá este mensaje a la migración?" en una respuesta concreta y privada.
