Visor HL7 Online

¿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.

Tres Flujos de Trabajo de Analista

El caso clásico es rastrear un ID de paciente perdido en una actualización sintética ADT^A08. Un HCE informa que una actualización demográfica no se aplicó; pegar el mensaje en bruto aquí decodifica PID-3 campo a campo, mostrando de inmediato si el identificador estaba vacío, mal formado o presente en una repetición que el sistema receptor no esperaba — convirtiendo un ticket vago de "la actualización no se aplicó" en un campo y un valor concretos.

Un segundo flujo habitual es confirmar un mapeo de resultado ORU antes de que llegue a un LIS o HCE. Pegar un mensaje sintético ORU^R01 y leer OBX-3 (el identificador de observación) junto a OBX-5 (el valor) y OBX-6 (las unidades) confirma exactamente qué envió un laboratorio de referencia, la forma más rápida de resolver una disputa entre "el laboratorio envió datos incorrectos" y "nuestro sistema los mapeó mal".

Un tercero es comparar una orden ORM antes y después de una transformación del motor de interfaces, usando la vista en paralelo. Pegar el mensaje saliente sintético en un lado y lo que el sistema receptor realmente registró en el otro resalta exactamente qué campo alteró la regla de mapeo del motor — una repetición colapsada, un componente reordenado o un carácter de codificación sustituido — antes de escalar al proveedor del motor.

Cuándo No Usar Esta Herramienta

Este visor decodifica únicamente mensajes HL7 v2.x delimitados por pipes; no analiza recursos FHIR en JSON/XML — usa una herramienta FHIR dedicada para eso. Su diccionario de segmentos y campos se basa en las definiciones de HL7 v2.5 y v2.7, así que los mensajes de esas versiones obtienen los nombres de campo y tipos de datos más completos; otras versiones v2.x igualmente se analizan estructuralmente (el análisis basado en delimitadores es en sí mismo agnóstico a la versión), pero un campo poco común o específico de versión puede mostrar solo una etiqueta genérica en lugar de un nombre completo. También se centra en decodificación y comparación, no en validación de esquema — no comprueba si los segmentos o campos obligatorios están presentes según el esquema de un tipo de mensaje. Para esa capa de comprobación, combínalo con el Validador HL7 dedicado.

Códigos de Confirmación ACK de un Vistazo

Cuando una interfaz se queda en silencio, el ACK que devolvió el sistema receptor suele ser el lugar más rápido donde mirar. El primer campo del segmento MSA lleva uno de un conjunto reducido de códigos:

Código	Significado	Qué comprobar después
AA	Aceptación de Aplicación — mensaje recibido y procesado	Confirma que los sistemas downstream reflejan la actualización
AE	Error de Aplicación — ocurrió un error de procesamiento	Busca un segmento ERR que describa el fallo concreto
AR	Rechazo de Aplicación — el mensaje fue rechazado por completo	Revisa la estructura del mensaje y el ID de control frente a lo esperado

El visor analiza los mensajes ACK de la misma forma que cualquier otro tipo de mensaje, así que el MSA y cualquier segmento ERR que lo acompañe se decodifican con campos nombrados en lugar de pipes en bruto.

Trabajar Junto a Otras Herramientas HL7

Visualizar suele ser el primer paso de una cadena de tres herramientas. Una vez que la estructura de un mensaje está clara aquí, pásalo por el Validador HL7 para comprobarlo contra el esquema de un tipo de mensaje en busca de campos obligatorios ausentes, y luego conviértelo con HL7 a JSON si los datos necesitan alimentar un script, un banco de pruebas o un sistema no HL7. Inspeccionar, validar, convertir — el mismo mensaje pasa por las tres sin salir nunca del navegador.