¿Qué es HL7 v2.x?
HL7 versión 2.x (a menudo llamado HL7 v2 o HL7 2.x) es el estándar dominante para el intercambio electrónico de datos entre sistemas de información sanitaria. A pesar de tener más de 30 años, sigue transportando la mayor parte del tráfico de mensajes clínicos en hospitales de todo el mundo: ingresos de pacientes, pedidos y resultados de laboratorio, eventos de programación, transacciones financieras y documentación clínica. La mayoría de los motores de interfaz hospitalarios (Mirth Connect, Rhapsody, Ensemble, Cloverleaf) siguen gestionando principalmente mensajes HL7 v2.x.
La Anatomía de un Mensaje HL7 v2.x
Un mensaje HL7 v2.x es un archivo de texto delimitado por tuberías donde cada línea es un segmento. Cada segmento comienza con un código de tres letras (p. ej., MSH, PID, OBX), seguido de campos separados por el carácter de tubería |. Los campos se numeran por posición: MSH.9 es el noveno campo y contiene el tipo de mensaje. Los campos pueden contener subcomponentes separados por circunflejos (^) y repeticiones separadas por tildes (~).
Los Segmentos Más Importantes
Aunque la especificación HL7 v2.x define cientos de tipos de segmentos, un pequeño grupo aparece en casi todos los escenarios de integración: MSH (siempre el primero, contiene el tipo de mensaje y el ID de control), PID (identificadores del paciente, nombre y fecha de nacimiento), PV1 (detalles de la visita: clase de paciente, ubicación asignada, médico tratante), OBR (solicitud de pedido en mensajes ORM y ORU), OBX (resultado u observación individual en mensajes ORU) y EVN (metadatos del tipo de evento para mensajes ADT).
Tipos de Datos HL7
Al igual que las Representaciones de Valor de DICOM, HL7 define tipos de datos que rigen cómo se codifican los valores de los campos. Los tipos más comunes son ST (cadena de texto libre), TS (marca de tiempo en formato YYYYMMDDHHMMSS), CX (identificador compuesto extendido, usado para NHC y números de cuenta), XPN (nombre de persona extendido con apellido, nombre, inicial, sufijo), CE/CWE (elemento codificado con sistema de codificación, como ICD-10 o LOINC) y NM (número decimal para resultados y medidas).
Estructura de Tipos de Mensaje
HL7 v2.x define tipos de mensaje como combinaciones de un código de mensaje y un código de evento, escritos como Código^Evento. Por ejemplo: ADT^A01 (Ingreso), ORM^O01 (Pedido), ORU^R01 (Resultado), SIU^S12 (Nueva Cita), MDM^T02 (Documento). Cada tipo de mensaje tiene una gramática de segmentos definida que especifica qué segmentos son obligatorios, cuáles son opcionales y en qué orden aparecen. La pestaña Tipos de Mensaje de este navegador muestra estas gramáticas para los 10 tipos de mensaje más comunes.
Casos de Uso Prácticos para Analistas de Integración
Los analistas de interfaces y los ingenieros de integración utilizan este navegador de segmentos en varios escenarios cotidianos. Al redactar especificaciones de interfaces, el navegador proporciona posiciones de campo y tipos de datos precisos para documentar la lógica de mapeo entre sistemas origen y destino. Cuando un sistema receptor informa de un valor faltante o incorrecto, consultar el segmento permite verificar la posición de campo esperada y el tipo de dato correspondiente. Al incorporar un nuevo analista al equipo, la combinación de definiciones de segmentos y esquemas de mensaje ofrece una introducción completa y práctica al estándar HL7 v2.x sin necesidad de descargar la especificación oficial.
Tres Flujos de Trabajo de Referencia
Un analista que mapea un nuevo feed de laboratorio se encuentra con un valor poco familiar como "CE" en OBX-2 de un mensaje de muestra y lo busca aquí en lugar de adivinar — confirmando que significa Elemento Codificado antes de escribir una regla de mapeo que asuma la forma incorrecta para OBX-5.
Un nuevo miembro del equipo que se incorpora a una interfaz ADT abre la pestaña Tipos de Mensaje, hace clic en ADT^A08 y ve de un vistazo la secuencia completa de segmentos obligatorios frente a opcionales — convirtiendo lo que de otro modo sería una lectura lenta de la especificación de interfaz de un proveedor en una orientación de cinco minutos.
Un ingeniero de integración que investiga una anotación inesperada en el Visor HL7 viene aquí para consultar la definición de campo exacta que usó el visor — como ambas herramientas comparten las mismas definiciones de segmentos subyacentes, confirmar la definición aquí confirma exactamente qué está haciendo el visor con un mensaje real, sin conjeturas.
Cuándo No Usar Esta Herramienta
Esto es una referencia estándar pura — no analiza, valida ni procesa ningún mensaje HL7 que puedas tener, y no hay ninguna subida de archivos. Para inspeccionar un mensaje real, usa en su lugar el Visor HL7. También cubre 21 segmentos comunes en los 10 tipos de mensaje más frecuentes, no los cientos de tipos de segmento que define la especificación completa de HL7 v2.x, y no incluye Z-segments específicos de proveedor, que son extensiones propietarias definidas por organizaciones individuales y quedan fuera de cualquier estándar público. Si tu interfaz usa un segmento o tipo de mensaje fuera de este conjunto, la especificación de interfaz propia del proveedor sigue siendo la fuente autorizada.
Dos Esquemas de Tipo de Mensaje Comparados
Ver dos esquemas uno junto al otro muestra cómo varía la composición de segmentos según el propósito del mensaje — un evento de ingreso necesita segmentos distintos a un resultado de laboratorio:
| Tipo de mensaje | Segmentos obligatorios (en orden) | Segmentos opcionales comunes |
|---|
| ADT^A01 (Ingreso) | MSH, EVN, PID, PV1 | NK1, AL1, DG1 |
| ORU^R01 (Resultado) | MSH, PID, OBR, OBX | NTE, ORC |
La gramática completa de los 10 tipos de mensaje cubiertos, con el orden exacto y las reglas de repetición, está en la pestaña Tipos de Mensaje.
Trabajar Junto a Otras Herramientas HL7
Este navegador es la capa de referencia bajo otras dos herramientas de este sitio: el Visor HL7, que anota un mensaje real pegado usando estas mismas definiciones de segmentos, y HL7 a JSON, cuyo modo estilo HAPI nombra los componentes según estos mismos tipos de datos. Consultar aquí un campo poco familiar antes de analizar o convertir un mensaje real significa que ya sabes qué esperar de la salida de las otras herramientas.
