Qué significan los caracteres de codificación del segmento MSH en HL7
Todo mensaje HL7 v2.x comienza con un segmento de cabecera del mensaje (MSH), y lo primero que hace ese segmento es declarar la puntuación que usará el resto del mensaje. Si alguna vez has mirado una línea que empieza por MSH|^~\& y te has preguntado por qué un estándar sanitario comienza con lo que parece un gato caminando sobre el teclado, esta guía es para ti. Esos cinco caracteres no son adorno — son el contrato de análisis sintáctico de todo el mensaje, y equivocarse con ellos es una de las causas más frecuentes de fallos silenciosos de interfaz en producción.
La respuesta corta a la pregunta que muchos ingenieros buscan — qué significan los caracteres de codificación del segmento MSH en HL7 — es esta: la barra vertical es el separador de campos, el circunflejo separa componentes, la tilde separa repeticiones, la barra invertida es el carácter de escape y el ampersand separa subcomponentes. El resto de este artículo explica con exactitud cómo se declara cada uno, por qué el segmento MSH se analiza de forma distinta a los demás y cómo manejar los casos límite que rompen los analizadores ingenuos. Puedes seguir el ejemplo pegando cualquier mensaje en nuestro Visor HL7 gratuito, que muestra la jerarquía de delimitadores de forma visual.
MSH-1 y MSH-2 — los dos campos especiales
Los caracteres de codificación residen en los dos primeros campos del segmento MSH, y estos dos campos son únicos en todo el estándar HL7 v2.x porque se definen por posición y no por contenido. La especificación HL7 v2.5.1, Capítulo 2 (Control), Sección 2.5.3, describe el segmento MSH como el único segmento donde el separador de campos es a la vez un valor de campo.
MSH-1 — el separador de campos
MSH-1 es el separador de campos. Es el carácter que sigue inmediatamente al identificador literal del segmento MSH. En la cabecera canónica del mensaje MSH|^~\&, el cuarto carácter — la barra vertical (|) — es MSH-1. Esto resulta genuinamente extraño la primera vez que lo encuentras, porque en cualquier otro segmento un separador de campos delimita campos en lugar de ser uno. El estándar lo resuelve declarando que cualquiera que sea el carácter que aparece en el cuarto byte del segmento es, por definición, el separador de campos de todo el mensaje.
La consecuencia práctica es que un analizador debe leer MSH-1 antes de poder tokenizar cualquier otra cosa. No puedes dividir el segmento MSH por la barra y luego buscar el campo 1 — el campo 1 es el carácter de división. Los analizadores correctos tratan MSH como caso especial: toman el byte 4 como separador de campos, toman la siguiente secuencia de caracteres hasta la próxima aparición de ese separador como caracteres de codificación, y solo entonces comienzan la tokenización ordinaria campo a campo.
MSH-2 — los caracteres de codificación
MSH-2 contiene los cuatro delimitadores restantes empaquetados en un solo campo. En la cabecera por defecto MSH|^~\&, MSH-2 es la cadena ^~\&. Los caracteres son posicionales y el orden lo fija el estándar:
- Posición 1 (
^): el separador de componentes - Posición 2 (
~): el separador de repetición - Posición 3 (
\): el carácter de escape - Posición 4 (
&): el separador de subcomponentes
Un sistema receptor lee MSH-2 literalmente — no asume los valores por defecto. Un emisor conforme puede elegir caracteres diferentes, y un receptor conforme debe respetar lo que declare MSH-2. En la práctica casi todo el mundo usa los valores por defecto recomendados, pero el estándar permite explícitamente la sustitución, por lo que un analizador nunca debería codificar de forma fija ^~\&.
La jerarquía de delimitadores — barra, circunflejo, tilde, ampersand
HL7 v2.x codifica un árbol de valores dentro de una sola línea de texto, y los cuatro delimitadores de datos expresan los niveles de ese árbol. Comprender la jerarquía es la diferencia entre navegar un mensaje con confianza y adivinar.
La barra vertical — separador de campos
La barra vertical separa campos dentro de un segmento. En un segmento PID como PID|1||MRN12345^^^HOSP^MR||DOE^JANE||19850312|F, cada barra avanza a la siguiente posición de campo: PID-1 es el identificador de conjunto, PID-3 es la lista de identificadores del paciente, PID-5 es el nombre del paciente, y así sucesivamente. Dos barras seguidas (||) significan un campo vacío, lo cual es semánticamente distinto de un campo presente pero en blanco.
El circunflejo — separador de componentes
El circunflejo divide un solo campo en sus componentes. Muchos campos HL7 no son valores escalares sino datos estructurados. El campo del nombre del paciente PID-5 usa el tipo de dato XPN (Extended Person Name), de modo que DOE^JANE^Q^JR se descompone en apellido (DOE), nombre (JANE), segundo nombre (Q) y sufijo (JR). El circunflejo es lo que permite que un único campo transporte un registro estructurado completo.
La tilde — separador de repetición
La tilde separa repeticiones de un campo al que se le permite aparecer más de una vez. Un paciente puede tener varios identificadores — un número de historia clínica y un identificador nacional, por ejemplo — de modo que PID-3 podría leerse MRN12345^^^HOSP^MR~987654321^^^GOV^NI. Cada fragmento delimitado por tilde es una repetición completa y estructurada de forma independiente. La repetición es un concepto a nivel de campo: no todos los campos son repetibles, y las definiciones de segmento del estándar especifican cuáles lo son.
El ampersand — separador de subcomponentes
El ampersand es el nivel más profundo: divide un componente en subcomponentes. Aparece con más frecuencia dentro de campos codificados y direcciones. Por ejemplo, un elemento codificado que use el tipo de dato CWE podría llevar una traducción, y una dirección extendida (XAD) podría usar subcomponentes para cualificar una línea de calle. Como el ampersand se sitúa en la parte inferior de la jerarquía, es el delimitador que los ingenieros encuentran con menos frecuencia y, por tanto, el que más probablemente se maneja mal.
La barra invertida — por qué el carácter de escape es diferente
La barra invertida declarada en la posición 3 de MSH-2 no es en absoluto un delimitador estructural — es el carácter de escape, y resuelve un problema que crean los demás delimitadores. Si un carácter delimitador debe aparecer dentro de los datos reales, no puedes escribirlo literalmente, porque el analizador lo trataría como estructura. Imagina una observación de texto libre que contiene genuinamente un ampersand, como el nombre de un departamento del tipo Cardiología & Vascular. Tal cual, el ampersand se interpretaría erróneamente como una división de subcomponente.
HL7 lo resuelve con secuencias de escape delimitadas por la barra invertida. La especificación HL7 v2.5.1, Capítulo 2, Sección 2.7 (uso de secuencias de escape en campos de texto), define un conjunto de códigos de escape de dos letras envueltos en barras invertidas:
\F\— un separador de campos literal (barra vertical)\S\— un separador de componentes literal (circunflejo)\T\— un separador de subcomponentes literal (ampersand)\R\— un separador de repetición literal (tilde)\E\— un carácter de escape literal (la propia barra invertida)
Así, la codificación segura del nombre del departamento anterior es Cardiología \T\ Vascular. Un receptor debe revertir estos escapes cuando extrae el valor legible. Un analizador que ignore las secuencias de escape corromperá los datos o dividirá un campo en el límite equivocado — un error sutil que a menudo pasa las pruebas con mensajes de muestra limpios y solo se manifiesta cuando llegan datos reales con puntuación.
Errores frecuentes de codificación en MSH
La mayoría de los defectos relacionados con delimitadores caen en un puñado de patrones recurrentes. Reconocerlos acorta notablemente la depuración.
Dividir el segmento MSH por la barra
El error más frecuente es tratar MSH como cualquier otro segmento y dividirlo por el separador de campos. Como MSH-1 es el propio separador, una división ingenua descuadra la numeración de campos de todo el segmento MSH, de modo que la aplicación emisora que debería ser MSH-3 acaba en la posición equivocada. Trata siempre el análisis de MSH como caso especial.
Codificar de forma fija los delimitadores por defecto
Un analizador que asume ^~\& sin leer MSH-2 analizará mal de forma silenciosa cualquier mensaje que use caracteres de codificación alternativos. El código conforme lee los delimitadores reales de la cabecera y los usa en todo el mensaje.
Ignorar las secuencias de escape
Tratar \T\ como caracteres literales en lugar de un ampersand escapado corrompe los campos de texto libre. Esto es especialmente peligroso en notas clínicas, donde la puntuación abunda.
Confundir vacío, nulo y ausente
Un campo vacío (||) no es lo mismo que el nulo explícito de HL7, la secuencia de dos caracteres "", que indica al receptor que elimine un valor existente. El estándar, Capítulo 2 Sección 2.6, traza esta distinción con cuidado, y confundir ambos puede borrar datos en un HCE en los mensajes de actualización.
Puedes detectar la mayoría de estos problemas antes del despliegue ejecutando los mensajes en nuestro Validador HL7 basado en navegador, y puedes explorar la estructura de campos y componentes de cada segmento estándar con el Navegador de Segmentos HL7.
Uniendo las piezas
Los caracteres de codificación del segmento MSH son la piedra Rosetta de un mensaje HL7 v2.x. MSH-1 declara el separador de campos, MSH-2 declara los caracteres de componente, repetición, escape y subcomponente en ese orden fijo, y el resto del mensaje es un árbol de valores expresado mediante esos delimitadores. El mecanismo de escape con barra invertida permite que los datos reales contengan caracteres delimitadores sin romper la estructura, y la regla de análisis por posición del segmento MSH es la única excepción que todo analizador robusto debe implementar.
Una vez que estos cinco caracteres encajan en su sitio, el resto de HL7 v2.x se vuelve mucho más legible. Para un recorrido más profundo por la anatomía del mensaje y los errores de validación que provocan los problemas de delimitadores, lee nuestras guías complementarias sobre validación de mensajes HL7 y mensajes de confirmación ACK de HL7. Juntas cubren el ciclo de vida desde un mensaje correctamente delimitado hasta el ACK que confirma que un receptor lo entendió.