HL7 v2 es la lengua franca de los hospitales: mensajes de texto, línea a línea, que salen cuando ocurre algo. Un ingreso dispara un mensaje ADT; una petición de analítica, un OML u ORM; un resultado validado, un ORU. Entender su anatomía (segmentos, campos y delimitadores) y sus eventos permite leer casi cualquier interfaz hospitalaria. Su gran debilidad es la variación: cada implementación lo interpreta a su manera.

Un estándar nacido de los eventos

HL7 v2 fue el primer estándar de intercambio de HL7 y es uno de los más adoptados, sobre todo en el ámbito hospitalario ⁵. La versión 2.9 del estándar data de 2019 ¹.

Su idea central es el evento disparador. El estándar parte de que un hecho real crea la necesidad de que los datos fluyan: «a patient is admitted» o que el resultado de una observación esté disponible ¹. Cuando el sistema que registra el hecho envía la información por su cuenta, el intercambio se llama actualización no solicitada ¹. El receptor responde con un acuse.

Cada mensaje tiene un tipo (ADT, ORU…) y un evento (A01, R01…). Un tipo puede ir con muchos eventos, pero un evento pertenece a un solo tipo ¹. La lista oficial de eventos es la tabla HL7 0003 ².

Anatomía de un mensaje

Un mensaje es texto. Cada línea es un segmento, que empieza por un identificador de tres caracteres y termina con un retorno de carro ¹. Dentro del segmento, los campos se separan con delimitadores declarados en la propia cabecera ¹:

Son los valores recomendados por HL7; el campo de cabecera «Encoding Characters» declara los que usa cada mensaje ¹. Los segmentos más frecuentes son estos ³:

ADT: el pulso del hospital

Los mensajes ADT (admission, discharge, transfer) avisan de todo lo que le pasa al paciente en el centro. Son los que más circulan: casi todos los sistemas necesitan saber quién está ingresado y dónde. Estos son los eventos más habituales, con su nombre oficial ²:

Un ingreso, inventado y simplificado, se vería así:

MSH|^~\&|ADMISION|HOSP01|LAB|HOSP01|20261026083000||ADT^A01^ADT_A01|MSG000123|P|2.5
EVN|A01|20261026082500
PID|1||123456^^^HOSP01^MR~XXXX000000000000^^^SNS^JHN||APELLIDO^NOMBRE||19440312|F
PV1|1|I|MEDINT^305^B|||||||||||||||EPI778899

Se lee así: el sistema de admisión avisa al laboratorio de un ingreso (ADT^A01). La paciente tiene dos identificadores: su número de historia del centro y uno de ámbito sanitario, separados por ~. Está ingresada (I) en medicina interna, habitación 305, cama B, con el episodio EPI778899. Los datos son ficticios.

Los eventos de anulación y de fusión son los más delicados. Si un sistema recibe el A01 pero se pierde el A11 que lo anula, tendrá un paciente fantasma ingresado. Si no procesa un A40, los resultados quedarán repartidos entre dos historias.

Peticiones: ORM y OML

Pedir una prueba también es un evento. La tabla 0003 recoge dos familias ²:

• ORM^O01, «Order message»: la petición general, válida para muchos tipos de servicio.
• OML^O21, «Laboratory order», y OML^O33, para varias peticiones sobre una misma muestra: los mensajes específicos de laboratorio.

Ambos están en la guía oficial que traduce v2 a FHIR, como «General Order Message» y «Laboratory order» ⁴. En una petición, el segmento ORC lleva los datos comunes de la orden y OBR la prueba concreta; en laboratorio, el segmento SPM describe la muestra ³.

La clave de una petición son sus dos números: el del peticionario (placer), que asigna quien pide, y el del ejecutor (filler), que asigna el departamento que la realiza. Ambos viajan en el mensaje y permiten casar después el resultado con lo que se pidió. Cómo se reparten esos papeles en radiología lo fija el perfil IHE que se ve en la lección de DICOM.

Resultados: ORU

Cuando el resultado está listo, el sistema departamental lo envía con ORU^R01, «Unsolicited transmission of an observation message» ². Un OBR identifica la prueba y le siguen tantos OBX como valores tenga:

MSH|^~\&|LAB|HOSP01|HCE|HOSP01|20261026113000||ORU^R01^ORU_R01|MSG000456|P|2.5
PID|1||123456^^^HOSP01^MR||APELLIDO^NOMBRE||19440312|F
OBR|1|PET-5521|LAB-99812|GLU^Glucosa^L|||20261026090000|||||||||||||||||F
OBX|1|NM|GLU^Glucosa^L||132|mg/dL|70-110|H|||F

El OBX dice: valor numérico (NM), 132 mg/dL, rango de referencia 70-110, marcado como alto (H) y final (F). Fíjese en el código de la prueba: GLU con el sufijo L, de «local». Es el código interno del laboratorio. Otro centro no sabría qué significa sin una tabla de equivalencias o sin un código estándar como los de LOINC, que se ven en la última lección.

ORU sirve para mucho más que el laboratorio: la misma estructura transporta constantes vitales de monitores, informes de anatomía patológica o resultados de microbiología.

Acuses, transporte y dialectos

Cada mensaje recibe un acuse (ACK). En el modo original del estándar, el campo MSA-1 vale AA si el receptor procesó bien el mensaje, AE si encontró un error en su contenido y AR si lo rechazó por motivos ajenos al contenido, como un sistema caído ¹. El emisor debe decidir si reintenta ¹.

Para el transporte por red se usa habitualmente el protocolo mínimo de capa inferior, MLLP, que los perfiles IHE de dispositivos dan por defecto ⁶.

Y aquí llega el problema. HL7 v2 permite extensiones mediante segmentos Z, cuyo significado es opaco sin una explicación previa del emisor ⁵. Muchos elementos son opcionales y se usan solo en circunstancias limitadas ⁵. Por eso HL7 reconoce que uno de los mayores retos de v2 es la variación de implementación ⁵. En la práctica, cada interfaz necesita su especificación pactada: qué eventos, qué campos y con qué códigos.

Caso práctico

En admisión se registra por error el ingreso de un paciente en la cama equivocada y, a los cinco minutos, se corrige con un traslado. Mientras tanto, la farmacia ya ha preparado la medicación para la cama original.

El sistema de admisión emitió un A01 y después un A02 ². Si el motor de integración entregó ambos en orden, la farmacia ve el traslado y redirige la medicación. Si el A02 se quedó en una cola porque el sistema de farmacia rechazó el mensaje con AR ¹, la unidad original recibirá una medicación que no le toca.

Por eso los hospitales vigilan las colas de mensajes ADT como un indicador de seguridad del paciente, y no solo como un asunto técnico.

Qué implica para los sistemas

Mensaje	Quién lo emite	Quién lo consume	Dato crítico
ADT (A01-A40)	Gestión de pacientes del HIS	Laboratorio, imagen, farmacia, dietética, facturación, historia clínica	Identificadores del paciente y número de episodio
ORM / OML	Petición electrónica de la historia clínica	Sistema departamental (laboratorio, imagen)	Número del peticionario, prueba pedida, prioridad
ORU	Sistema departamental o pasarela de equipos	Historia clínica, sistemas de alertas, repositorios	Código de la prueba, valor, unidad, estado final o preliminar
ACK	Cada receptor	El emisor o el motor	Aceptación o error, para reintentar o alertar