Introducción: Qué es HL7 v2.x y por qué es importante
Health Level Seven versión 2.x (HL7 v2.x) es el estándar de mensajería más ampliamente desplegado en la tecnología de la información sanitaria. A pesar de haber sido introducido a finales de los años 1980, HL7 v2 todavía transporta la gran mayoría de los datos electrónicos de salud intercambiados entre sistemas hospitalarios en todo el mundo. Las estimaciones sugieren que más del 95% de las organizaciones sanitarias en Estados Unidos utilizan HL7 v2.x para al menos parte de su comunicación entre sistemas.
HL7 v2.x permite que diferentes aplicaciones sanitarias — historias clínicas electrónicas (HCE), sistemas de información de laboratorio (LIS), sistemas de información de radiología (RIS), sistemas de farmacia y plataformas de facturación — intercambien datos clínicos y administrativos en un formato estructurado y predecible. Cuando un paciente es admitido, un resultado de laboratorio se finaliza, o un medicamento es prescrito, los mensajes HL7 transportan esa información entre sistemas en tiempo casi real.
Comprender la estructura interna de los mensajes HL7 v2.x es esencial para analistas de integración, informaticistas clínicos e ingenieros de TI sanitaria que construyen, mantienen y resuelven problemas de las interfaces que mantienen funcionando los hospitales. Esta guía desglosa la anatomía de un mensaje HL7 v2.x de arriba a abajo: segmentos, campos, componentes, delimitadores, tipos de mensaje, eventos disparadores y reglas de codificación.
Nota: Este artículo tiene fines educativos y no constituye asesoramiento médico ni legal. Siga siempre las políticas de su organización y las regulaciones aplicables al manejar datos sanitarios.
La anatomía jerárquica de un mensaje HL7
Un mensaje HL7 v2.x es un bloque estructurado de texto organizado en una jerarquía estricta. Comprender esta jerarquía es la clave para leer, escribir y depurar mensajes HL7 de manera efectiva.
Mensajes
En el nivel más alto, un mensaje es una unidad completa de datos intercambiada entre dos sistemas. Cada mensaje comienza con un segmento de Cabecera de Mensaje (MSH) y contiene uno o más segmentos adicionales organizados en un orden definido. Un mensaje representa un único evento sanitario — una admisión, un resultado de laboratorio, una orden — y transporta todos los campos de datos relevantes para ese evento.
Segmentos
Un segmento es una agrupación lógica de campos de datos relacionados. Cada segmento ocupa una sola línea en el mensaje, comienza con un identificador de segmento de tres caracteres (como MSH, PID o OBX) y termina con un carácter de retorno de carro (0x0D). Los segmentos están separados por retornos de carro: un segmento por línea, sin excepciones.
Campos
Cada segmento se divide en campos separados por un delimitador de campo — el carácter pipe (|) por defecto. Los campos se numeran secuencialmente comenzando desde 1 dentro de cada segmento. Por ejemplo, PID-3 se refiere al tercer campo del segmento PID, que contiene la lista de identificadores del paciente.
Componentes y subcomponentes
Los campos pueden dividirse aún más en componentes separados por el separador de componentes (acento circunflejo ^ por defecto), y los componentes pueden subdividirse en subcomponentes separados por el separador de subcomponentes (ampersand & por defecto). Por ejemplo, un campo de nombre de paciente podría contener García^Juan^M^^Dr, donde los componentes representan apellido, nombre, segundo nombre, sufijo y prefijo respectivamente.
Repeticiones
Algunos campos permiten repetición — múltiples valores para el mismo campo, separados por el separador de repetición (tilde ~ por defecto). Por ejemplo, un paciente podría tener múltiples números de teléfono almacenados en el mismo campo, cada uno separado por una tilde.
Segmentos comunes y su propósito
Aunque el estándar HL7 v2.x define docenas de segmentos, un puñado aparece en la mayoría de los mensajes. Conocer estos segmentos principales te permite leer y depurar la mayor parte del tráfico HL7 clínico.
MSH — Cabecera de mensaje
Todo mensaje HL7 comienza con un segmento MSH. Identifica las aplicaciones emisora y receptora, define los delimitadores utilizados en todo el mensaje, especifica el tipo de mensaje y evento disparador, y lleva un ID de control de mensaje único. Los campos clave incluyen:
- MSH-1 — Separador de campo (siempre el carácter pipe
|) - MSH-2 — Caracteres de codificación (separadores de componente, repetición, escape y subcomponente, típicamente
^~\&) - MSH-3 — Nombre de la aplicación emisora
- MSH-4 — Instalación emisora
- MSH-5 — Nombre de la aplicación receptora
- MSH-6 — Instalación receptora
- MSH-7 — Fecha/hora del mensaje
- MSH-9 — Tipo de mensaje (p.ej., ADT^A01 para Notificación de Admisión/Visita)
- MSH-10 — ID de control de mensaje (identificador único para acuses de recibo)
- MSH-11 — ID de procesamiento (P para producción, T para entrenamiento, D para depuración)
- MSH-12 — ID de versión (p.ej., 2.3, 2.5.1)
PID — Identificación del paciente
El segmento PID transporta información demográfica sobre el paciente. Está presente en casi todos los mensajes clínicos e incluye típicamente:
- PID-3 — Lista de identificadores del paciente (número de historia clínica, ID nacional, número de seguro)
- PID-5 — Nombre del paciente (apellido^nombre^segundo nombre^sufijo^prefijo)
- PID-7 — Fecha de nacimiento
- PID-8 — Sexo administrativo
- PID-11 — Dirección del paciente
- PID-13 — Número de teléfono (domicilio)
PV1 — Visita del paciente
El segmento PV1 describe el encuentro actual o más reciente — si el paciente está hospitalizado, en consulta externa o en urgencias. Los campos importantes incluyen la clase de paciente (PV1-2), ubicación asignada del paciente (PV1-3), médico tratante (PV1-7) y fecha/hora de admisión (PV1-44).
OBR — Solicitud de observación
El segmento OBR define una única orden de prueba diagnóstica o procedimiento. Contiene el número de orden del solicitante (OBR-2), número de orden del ejecutor (OBR-3), identificador universal del servicio que describe la prueba (OBR-4), fecha/hora de la observación (OBR-7) y estado del resultado (OBR-25). Los mensajes de laboratorio, radiología y patología utilizan segmentos OBR.
OBX — Resultado de observación
El segmento OBX transporta un único resultado de observación o prueba. Cada línea OBX representa un valor de resultado discreto. Los campos clave incluyen el tipo de valor (OBX-2), identificador de observación (OBX-3), valor de observación (OBX-5), unidades (OBX-6), rango de referencia (OBX-7) y bandera de anormalidad (OBX-8). Un único panel de laboratorio puede generar una docena de segmentos OBX, uno por cada analito.
NK1 — Familiar más cercano
El segmento NK1 identifica al contacto de emergencia o familiar más cercano del paciente, incluyendo nombre (NK1-2), relación (NK1-3), dirección (NK1-4) y número de teléfono (NK1-5). Pueden aparecer múltiples segmentos NK1 en un solo mensaje si el paciente ha indicado más de un contacto.
Delimitadores: Los caracteres que definen el mensaje
HL7 v2.x utiliza un conjunto de caracteres delimitadores especiales para separar los elementos estructurales dentro de un mensaje. Estos delimitadores se definen en los dos primeros campos del segmento MSH, lo que significa que técnicamente son configurables — aunque en la práctica casi todas las implementaciones utilizan los valores estándar por defecto.
| Carácter | Valor por defecto | Propósito | Posición MSH |
|---|---|---|---|
| Separador de campo | | (pipe) | Separa campos dentro de un segmento | MSH-1 |
| Separador de componente | ^ (acento circunflejo) | Separa componentes dentro de un campo | MSH-2, posición 1 |
| Separador de repetición | ~ (tilde) | Separa ocurrencias repetidas de un campo | MSH-2, posición 2 |
| Carácter de escape | \ (barra invertida) | Introduce secuencias de escape | MSH-2, posición 3 |
| Separador de subcomponente | & (ampersand) | Separa subcomponentes dentro de un componente | MSH-2, posición 4 |
El carácter de escape permite que los caracteres delimitadores aparezcan en los valores de datos. Por ejemplo, \F\ representa un pipe literal, \S\ representa un acento circunflejo literal, \T\ representa un ampersand literal, \R\ representa una tilde literal y \E\ representa una barra invertida literal. Cuando ves datos ilegibles en segmentos OBX, los delimitadores escapados suelen ser la causa — usa nuestro visor de mensajes HL7 para decodificar estas secuencias automáticamente.
Tipos de mensaje y eventos disparadores
Cada mensaje HL7 se clasifica por un tipo de mensaje y un evento disparador, especificados juntos en MSH-9. El tipo de mensaje identifica la categoría amplia del intercambio de datos, mientras que el evento disparador identifica el evento sanitario específico que causó que se generara el mensaje.
Tipos de mensaje comunes
- ADT (Admisión, Alta, Transferencia) — Eventos de registro y movimiento del paciente. El tipo de mensaje más común en la mayoría de los hospitales.
- ORM (Mensaje de Orden) — Órdenes clínicas para laboratorios, radiología, medicamentos y procedimientos.
- ORU (Resultado de Observación No Solicitado) — Resultados de laboratorio, informes de radiología y otros hallazgos diagnósticos enviados de sistemas auxiliares a la HCE.
- SIU (Información de Programación No Solicitada) — Creación, modificación y cancelación de citas.
- MDM (Gestión de Documentos Médicos) — Notificaciones de documentos clínicos como resultados de transcripción o resúmenes de alta.
- RDE (Orden Codificada de Farmacia/Tratamiento) — Órdenes de medicamentos transmitidas a sistemas de farmacia.
- DFT (Transacción Financiera Detallada) — Datos de captura de cargos y facturación de sistemas clínicos al sistema financiero.
Eventos disparadores comunes
Los eventos disparadores se identifican por un código de letra-número añadido al tipo de mensaje. Algunos de los eventos disparadores más frecuentes incluyen:
- A01 — Notificación de Admisión/Visita. Se genera cuando un paciente es formalmente admitido en una unidad de hospitalización.
- A02 — Transferencia. Se genera cuando un paciente se traslada de una unidad de enfermería a otra.
- A03 — Alta/Fin de Visita. Se genera cuando un paciente recibe el alta de una hospitalización o finaliza una visita ambulatoria.
- A04 — Registrar un Paciente. Se genera para registros ambulatorios y de urgencias.
- A08 — Actualizar Información del Paciente. Se genera cuando cambian datos demográficos (dirección, teléfono, seguro).
- A31 — Actualizar Información de Persona. Similar a A08 pero enfocado en datos a nivel de persona (no de visita).
- O01 — Mensaje de Orden. Se usa con ORM para transmitir órdenes clínicas.
- R01 — Resultado de Observación No Solicitado. Se usa con ORU para transmitir resultados de laboratorio y diagnósticos.
Un mensaje ADT^A01 completo, por ejemplo, podría contener segmentos MSH, EVN, PID, PV1, NK1 y de seguros — todo lo que el sistema receptor necesita para registrar la admisión e iniciar el flujo de trabajo clínico.
Reglas de codificación: Campos requeridos, opcionalidad y valores nulos
El estándar HL7 v2.x define reglas de opcionalidad para cada campo en cada segmento. Comprender estas reglas es fundamental para construir interfaces que pasen la validación y para depurar mensajes que fallan.
Códigos de opcionalidad
- R (Requerido) — El campo debe estar presente y poblado en cada mensaje que contenga este segmento. Los campos requeridos faltantes son una causa común de rechazos de interfaces.
- O (Opcional) — El campo puede estar presente o ausente a discreción del sistema emisor.
- C (Condicional) — El campo es requerido bajo ciertas condiciones definidas en el estándar o la guía de implementación.
- X (No usado) — El campo no debe enviarse. Los sistemas receptores pueden ignorarlo.
- B (Compatible hacia atrás) — El campo se conserva por compatibilidad hacia atrás pero ha sido reemplazado por otro campo en versiones posteriores.
Valores nulos vs. campos vacíos
HL7 v2.x distingue entre un campo vacío (sin datos entre delimitadores: ||) y un campo nulo (explícitamente establecido como nulo: |""|). Un campo vacío significa "no tengo nada que decir sobre este campo" y el sistema receptor debe mantener su valor actual sin cambios. Un campo nulo significa "estoy borrando explícitamente este campo" y el sistema receptor debe eliminar o blanquear el valor almacenado. Esta distinción es enormemente importante en mensajes de actualización como ADT^A08, donde un campo de teléfono vacío significa "sin cambios" pero un campo de teléfono nulo significa "eliminar el número de teléfono registrado".
Repetición y longitud máxima
Los campos que soportan repetición pueden transportar múltiples valores separados por la tilde (~). El estándar define un conteo máximo de repeticiones para cada campo (frecuentemente ilimitado) y una longitud máxima recomendada para cada campo y componente. Mientras que muchos motores de integración aplican los límites de longitud estrictamente, otros truncan silenciosamente — una fuente común de pérdida de datos en interfaces de producción.
Escenarios de integración comunes
HL7 v2.x impulsa una amplia gama de flujos de trabajo clínicos y administrativos. Estos son los patrones de integración más comunes que encontrarás en un hospital de atención aguda típico:
Flujo de resultados de laboratorio (ORU^R01)
El sistema de información de laboratorio (LIS) envía un mensaje ORU^R01 a la HCE cuando un resultado de prueba es finalizado. El mensaje contiene MSH, PID, PV1, OBR (describiendo el panel de pruebas) y uno o más segmentos OBX (uno por analito de resultado). La HCE analiza el mensaje, identifica al paciente y muestra los resultados en la historia clínica del paciente. Este es uno de los tipos de mensaje de mayor volumen en la mayoría de los hospitales, generando miles de mensajes por día.
Notificaciones ADT (ADT^A01, A02, A03, A04, A08)
La HCE o el sistema de registro difunde mensajes ADT a los sistemas dependientes cada vez que un paciente es admitido, transferido, dado de alta, registrado o actualizado. Los sistemas de farmacia, dietética, laboratorio, radiología y facturación se suscriben al flujo ADT para mantener actualizado su censo de pacientes. Un solo evento de admisión puede desencadenar una cascada de mensajes ADT a docenas de sistemas receptores.
Entrada de órdenes (ORM^O01)
Cuando un médico ingresa una orden para una prueba de laboratorio, estudio de radiología o medicamento, la HCE envía un mensaje ORM^O01 al sistema auxiliar correspondiente. El mensaje contiene la identificación del paciente, los detalles de la orden en segmentos OBR y cualquier información clínica relevante en segmentos OBX. El sistema auxiliar procesa la orden y eventualmente devuelve un resultado vía ORU^R01.
Flujo de trabajo de radiología
Las integraciones de radiología típicamente implican una cadena de mensajes HL7: ORM^O01 de la HCE al RIS (orden), mensajes SIU para programar el examen, actualizaciones de estado ORM mientras el paciente se prepara, y finalmente ORU^R01 del RIS de vuelta a la HCE con el informe del radiólogo. Las imágenes DICOM fluyen separadamente a través de la red PACS, pero la coordinación de metadatos es toda HL7.
Resolución de problemas en mensajes HL7
Cuando una interfaz HL7 falla o produce resultados inesperados, la resolución sistemática de problemas es esencial. Estos son los problemas más comunes y cómo diagnosticarlos:
Errores de análisis comunes
Los errores de análisis a menudo provienen de caracteres inesperados en los campos de datos. Un carácter pipe en un valor OBX de texto libre, un acento circunflejo en un nombre de paciente, o un retorno de carro dentro de un campo de observación puede hacer que el analizador divida el mensaje incorrectamente. La solución son las secuencias de escape apropiadas: \F\ para pipe, \S\ para acento circunflejo, \.br\ para saltos de línea dentro de campos.
Problemas de orden de segmentos
El estándar HL7 define un orden esperado para los segmentos dentro de cada tipo de mensaje. Mientras que algunos motores de integración son tolerantes con el orden de segmentos, otros rechazan mensajes donde los segmentos aparecen fuera de secuencia. Un problema común es colocar segmentos OBX antes de su segmento OBR padre, u omitir el segmento EVN que algunos sistemas receptores requieren en mensajes ADT.
Problemas de codificación de caracteres
Las diferencias de codificación de caracteres entre sistemas emisores y receptores son una fuente frecuente de corrupción de datos. Cuando un sistema envía texto codificado en UTF-8 (con caracteres acentuados, símbolos especiales o scripts no latinos) a un receptor que espera ASCII o ISO-8859-1, los caracteres pueden aparecer ilegibles o causar fallos de análisis por completo. Verifica MSH-18 (Conjunto de Caracteres) para confirmar que ambos lados concuerdan en la codificación.
Cómo ayuda nuestro visor HL7
Depurar mensajes HL7 leyendo texto crudo delimitado por pipes es tedioso y propenso a errores. Nuestro visor de mensajes HL7 gratuito analiza cualquier mensaje HL7 v2.x y lo muestra como un desglose estructurado y codificado por colores de segmentos, campos y componentes. Puedes pegar un mensaje crudo, ver instantáneamente cada campo etiquetado con su nombre oficial y posición, identificar secuencias de escape y comparar dos mensajes lado a lado para encontrar diferencias. Todo el procesamiento ocurre completamente en tu navegador — ningún dato de pacientes sale jamás de tu equipo.
Conclusión
HL7 v2.x sigue siendo la columna vertebral del intercambio de datos sanitarios en hospitales y sistemas de salud de todo el mundo. Dominar su estructura — la jerarquía de mensajes, segmentos, campos, componentes y subcomponentes — es una habilidad fundamental para cualquier persona que trabaje en informática clínica o integración de TI sanitaria. Ya sea que estés construyendo una nueva interfaz, depurando un problema de producción o validando la integridad de datos durante una migración de sistema, un sólido entendimiento de la anatomía de mensajes HL7 te ahorrará tiempo y frustración significativos.
Para práctica directa, pega cualquier mensaje HL7 v2.x en nuestro visor de mensajes HL7 gratuito para ver su estructura desglosada campo por campo. Es la forma más rápida de aprender cómo se construyen los mensajes reales — y la forma más rápida de encontrar qué salió mal cuando no lo están.
Aviso: Este artículo se proporciona únicamente con fines informativos y educativos. No reemplaza las especificaciones oficiales de HL7 International, las guías de implementación ni las políticas institucionales para el manejo de datos sanitarios.