Un mensaje HL7 en formato ER7 se representa como una secuencia de caracteres en Ascii con unos caracteres de «control» para la interpretación de la estructura propia del mensaje. Por ejemplo para la separación de segmentos, campos, subcampos, etc.
A menudo ocurre que alguno de los valores que se están enviando, principalmente cuando se está enviando algún campo con texto libre en la fuente, puede contener alguno de esos caracteres de control. En esos casos es necesario realizar un escape de caracteres especiales en HL7 para que no afecten al mensaje enviado.
Para poner base a los caracteres de control, y aunque HL7 permite definir los los mismos en su segmento MSH, lo más frecuente, es usar los clásicos:
| Carácter | Descripción |
| CHR(13) | Como separador de segmento (en HEX 0x0D) |
| | | Como separador de campo en un segmento |
| ^ | Como separador de componentes en un campo |
| & | Como separador de subcomponentes en un componente |
| ~ | Como separador de repeticiones |
Veamos un ejemplo de lo que ocurre si no se sustituyen estos caracteres de control. Si por ejemplo quisiéramos transmitir un texto libre con el siguiente contenido en un campo de tipo TX:
Resultó en Test de O’Sullivan un valor de Glucosa 141 mg/dL | >140.
Valorar una curva larga de glucemia.
La interpretación del mensaje sin utilizar secuencias de escapado cuando los caracteres de control son los clásicos descritos arriba sería incorrecta. El destinatario, al encontrar el pipe“|” lo interpretaría como final de campo, y el contenido a continuación “>140…” lo incluiría en el siguiente campo, provocando un error de interpretación, y posiblemente de tipo de dato.
Por otro lado el resultado, sería un mensaje incorrecto, ya que el salto de línea sería interpretado por el destinatario del mensaje como un final de segmento. Cuando intentara interpretar el siguiente, el identificador de segmento que encontraría sería «Valorar » que no es un segmento existente.
Secuencias de escape de caracteres especiales en HL7
Para ello el estándar define secuencias de escape de caracteres especiales en HL7, que se sustituyen por aquellos que pueden colisionar con los de control.
| Secuencia | Descripción | Conversión |
| \E\ | Secuencia de escapado para escapar el carácter de escape (suena divertido) | \ |
| \F\ | Secuencia de escape para el separador de campo | | |
| \R\ | Secuencia de escape para el carácter separador de repeticiones | ~ |
| \S\ | Secuencia de escape para el carácter separador de componente | ^ |
| \T\ | Secuencia de escape para el carácter de separador de subcomponente | & |
| \Xdd..\ | Secuencia de escape para cualquier carácter. Se indica el carácter por su número ascii en hexadecimal. | 0xdd |
| \Zdd..\ | Cualquier otra secuencia no estándar que se quiera definir, incluyendo por ejemplo, plantilla de texto, pactada entre ambas partes. |
Para enviar un texto formateado, en el que queremos conservar el formato, también disponemos de algunas secuencias, como por ejemplo:
| Secuencia | Descripción |
| \H\ | Para indicar el inicio de texto en negrita. Equivalente a < strong > en HMTL. |
| \N\ | Para indicar el final de texto en negrita o principio de texto normal. Equivalente a < / strong > en HMTL |
El problema con el salto de línea en un texto, carácter ascii 13 o en hexadecimal 0x0D, es que HL7 no define ninguna secuencia de escape para este carácter, que a menudo en la codificación del mensaje se utiliza como separador de segmento.
El motivo por el que HL7 no define una secuencia de escape para el ascii 13 es que se asume que los saltos de línea no son parte del un valor de un campo, y el único caso en el que se asume que pueden contenerse saltos de línea será un campo de tipo texto, representado por los tipos de datos TX y FT.
Personalmente me resulta contradictorio que existan secuencias para el resaltado y no para el salto de línea, pero veamos qué ocurre para estos dos tipos de datos.
Campos TX (Texto sin formato)
En general los campos de tipo TX admiten repeticiones, por tanto, se asume que un salto de línea debería ser sustituido por un carácter separador de repetición “~” que enlace las distintas líneas (ver Documentación 2.A.78 o v2.6 capítulo 2).
Pero cuando un campo TX no admite repetición, entonces sí es necesario escapar el salto del línea con alguna secuencia. Aquí entra en juego la genérica \Xdd\ que permite especificar un byte en hexadecimal. Sin embargo, aquí la especificación HL7 vuelve a ser restrictiva y detalla que el escapado \Xdd\ para bytes y no caracteres por su código hexadecimal en ASCII. Sin embargo, permite flexibilidad en el acuerdo de contrato entre ambas partes para “interpretar” lo que se estime oportuno.
En mi experiencia profesional, si el contenido no se ve afectado por los saltos de línea por no ser relevante el formato, en campos TX no debería serlo, omito los saltos del línea. Si son relevantes, pactar un \X0D\ entre ambas partes para interpretar el salto de línea es lo mas adecuado.
Campos FT (Texto formateado)
En estos campos de texto enriquecido permiten otras secuencias propias del formato, por ejemplo del RTF o HTML.
Por lo general, un campo de tipo FT permite incluir secuencias del formateo del texto, como sangría, identación, etc.
Las secuencias mas frecuentes para el formato de texto son las siguientes:
| Secuencia | Descripción |
| \.br\ | Salto de línea. |
| \.sp-n\ | Fin de línea y saltar n de líneas verticales. |
| \.fi\ | Comenzar modo de ajuste. Por defecto. |
| \.nf\ | Fin del modo de ajuste. |
| \.in-n\ | Sangría de n espacios, donde n es un entero positivo o negativo. |
| \.ti-n\ | Sangría temporal de n espacios, donde n es un entero positivo o negativo. |
| \.sk-n\ | Saltar espacios a la derecha. |
| \.ce\ | Finaliza la línea de salida actual y centra la siguiente línea. |
