¿Qué es HL7 v2.x?
Health Level Seven versión 2 (HL7 v2.x) es el estándar de mensajería sanitaria más desplegado en el mundo. Define un formato de texto delimitado por pipes para el intercambio de datos clínicos, administrativos y financieros entre sistemas hospitalarios. A pesar de estándares más recientes como FHIR, HL7 v2.x sigue siendo la columna vertebral de las interfaces en tiempo real, gestionando notificaciones ADT, resultados de laboratorio, órdenes y programación.
Anatomía de un Mensaje HL7
Un mensaje HL7 v2.x está compuesto por segmentos, cada uno en su propia línea e identificado por un código de tres caracteres:
- MSH (Cabecera del Mensaje): Contiene los caracteres de codificación, aplicaciones emisora y receptora, tipo de mensaje e ID de control. Siempre es el primer segmento.
- PID (Identificación del Paciente): Transporta la demografía del paciente — nombre, fecha de nacimiento, número de historia clínica y datos de contacto.
- PV1 (Visita del Paciente): Describe el contexto del encuentro: clase del paciente, médico responsable y ubicación asignada.
- OBR (Solicitud de Observación): Representa una orden o procedimiento con el identificador de servicio y estado del resultado.
- OBX (Observación/Resultado): Transporta valores de resultado individuales — analitos de laboratorio, signos vitales o texto de informes.
Estructura de Campos y Codificación
Dentro de cada segmento, los campos se separan con el carácter pipe (|). Los campos pueden contener componentes separados por el circunflejo (^) y subcomponentes separados por el ampersand (&). Los campos repetitivos usan la tilde (~). Estos delimitadores se declaran en MSH-1 y MSH-2. Cada campo tiene un tipo de dato definido — por ejemplo, XPN para nombre de persona, CWE para codificado con excepciones o TS para marca temporal.
Escenarios Comunes de Pruebas de Integración
- Validación de Flujos ADT: Verificar que los mensajes de ingreso, alta y traslado contengan los identificadores de paciente y códigos de ubicación correctos.
- Mapeo de Resultados de Laboratorio: Los mensajes ORU entrantes deben mapear los identificadores de observación (OBX-3) a códigos locales. Un visor que decodifica campos facilita confirmar los mapeos.
- Resolución de Problemas de Órdenes: Comparar el mensaje ORM saliente con el formato esperado para revelar campos faltantes o problemas de codificación.
- Comparación de Mensajes: Durante migraciones de motores de integración, comparar mensajes antes y después para confirmar que las transformaciones son correctas.
Mensajes de Confirmación (ACK) y Gestión de Errores
HL7 v2.x utiliza mensajes ACK (confirmación) para verificar la recepción y el procesamiento de mensajes entrantes. Un ACK contiene un segmento MSA con un código de confirmación — AA (Aceptación de Aplicación), AE (Error de Aplicación) o AR (Rechazo de Aplicación) — junto con el ID de control del mensaje original para su correlación. Cuando las interfaces fallan silenciosamente, inspeccionar la respuesta ACK suele ser el primer paso de depuración. El visor analiza los mensajes ACK como cualquier otro tipo de mensaje, permitiéndote examinar los campos MSA y los segmentos ERR que describen la condición de error específica. Comprender los patrones ACK es esencial para diagnosticar mensajes perdidos, procesamiento duplicado y problemas de timeout en interfaces HL7 en producción.
HL7 v2.x vs. FHIR: Cuándo Aplica Cada Estándar
Aunque FHIR (Fast Healthcare Interoperability Resources) ha ganado adopción significativa para APIs RESTful y casos de interoperabilidad modernos, HL7 v2.x sigue siendo dominante para interfaces punto a punto en tiempo real dentro de los hospitales. La mayoría de los sistemas HCE — incluyendo Epic, Cerner (Oracle Health) y MEDITECH — continúan generando mensajes HL7 v2.x para flujos ADT, resultados de laboratorio y comunicación de órdenes. FHIR destaca en aplicaciones orientadas al paciente, consultas de salud poblacional e intercambio de datos entre organizaciones. En la práctica, muchas organizaciones sanitarias operan ambos estándares simultáneamente, usando v2.x para interfaces internas y FHIR para interoperabilidad externa.
Consideraciones de Privacidad para Mensajes HL7
Los mensajes HL7 contienen PHI altamente sensible: nombres de pacientes, diagnósticos, resultados de laboratorio y datos de seguros. Pegar estos mensajes en herramientas en la nube puede violar la HIPAA. Nuestra herramienta elimina este riesgo al realizar todo el análisis localmente. Ningún contenido se envía a un servidor ni se registra.
Para interfaces de radiología y laboratorio, el visor resulta especialmente útil cuando los analistas necesitan rastrear cómo se propagó un evento clínico por varios sistemas. Una actualización ADT puede explicar por qué un resultado ORU no se adjuntó al encounter correcto; una orden ORM puede explicar por qué una entrada de worklist de modalidad llega incompleta; un ACK puede revelar si el sistema receptor rechazó el mensaje de inmediato o lo aceptó con errores de negocio posteriores. Ver esas estructuras ya decodificadas en un único lugar acorta el tiempo entre la alerta y la causa raíz.
Otro beneficio práctico es mantener una separación limpia entre inspección del mensaje y transformación del mensaje. Antes de que un equipo escriba o ajuste mappings en un motor de interfaces, necesita confirmar qué envió realmente el sistema de origen: repeticiones, pipes finales ausentes, caracteres de codificación inesperados, segmentos Z locales y uso de campos específico de la versión. Un visor que expone la estructura original sin modificarla ofrece una línea base fiable antes de pasar al scripting, la transformación o la escalada con el proveedor.