MLLP Minimum Lower Layer Protocol

Los estándares de interoperabilidad en sanidad de la organización Health Level Seven definen protocolos en la capa de aplicación (nivel 7) de la pila OSI. Sin embargo, enmarcado en lo que la organización denomina Protocolos Fundamentales, encontramos MLLP, un protocolo para la capa de sesión (nivel 5).

El hecho de que HL7 sea un protocolo de nivel de aplicación hace que sea posible implementarlo sobre cualquier otro protocolo de nivel inferior en la pila OSI. En el caso de la versión 2, por ejemplo, en sus primeras versiones el formato mas utilizado de mensaje fue ER7 que, básicamente, era un conjunto de segmentos y campos en formato ASCII.

A nivel de infraestructura y en la capa de transporte, la implementación mas frecuente de HL7 v2 en ER7 ha sido sobre TCP. Para aportar seguridad en las comunicaciones de este formato en un entorno de red, sobre TCP, HL7 definió el protocolo mínimo de capa de sesión. De ahí su nombre MLLP, del inglés Minimum Lower Layer Protocol.

El objeto de MLLP, como protocolo de nivel inferior, es proporcionar una interfaz entre HL7 y la red, añadiendo una sobrecarga mínima a las comunicaciones. Esto lo consigue encapsulando los datos del nivel 7 (mensajes HL7 v2 principalmente) entre secuencias de inicio de mensaje y final de mensaje.

Hay que decir que MLLP está pensado para funcionar sobre entorno de red, principalmente bajo TCP. Pierde el sentido en otro tipo de entornos de comunicaciones. La detección y corrección de errores se manejarán en los niveles inferiores de cualquier protocolo de red, como TCP / IP, SNA, etc.

Estructura de la trama MLLP

La trama de MLLP se construye como bloques, compuestos por el contenido en HL7, encapsulado por caracteres especiales.

En concreto, el formato de bloque MLLP sería así:

<SB> dddd <EB><CR>

Donde tenemos los siguientes elementos:

Elemento	Descripción
<SB>	Carácter de Inicio de Bloque (1 byte) ASCII <VT> en hexadecimal 0x0B, y no debería colisionar con los carácteres ASCII SOH o STX
dddd	Datos a transmitir con el contenido HL7 del bloque, que pueden incluir caraceres ASCII como el <CR> retorno de carro, hexadecimal 0x0D. En el formato ER7 se define <CR> como final de segmento HL7.
<EB>	Carácter de Final de Bloque (1 byte). ASCII <FS> o en hexadecimal 0x1C. No deben colisionar con los caracteres ASCII ETX o EOT.
<CR>	Retorno de carro (1 byte) ASCII <CR> en Hexadecimal 0x0D.

En general, la estructura de una trama o bloque MLLP será:

Limitaciones

Hay que decir que, aunque MLLP se utiliza mas frecuentemente con la versión 2 de HL7 y en formato ER7, también puede utilizarse tanto con las versiones XML, así como en HL7 v3 y HL7 CDA.

Hay que asumir una limitación de MLLP en relación a que los caracteres especiales de inicio y fin de bloque son de un solo byte. Por tanto hay que tener esto en cuenta para que no colisionen con los datos transmitidos en el bloque HL7. En algunas codificaciones de caracteres multi-byte pueden resultar valores de byte que colisionen con los caracteres especiales de la trama MLLP. Por ejemplo en UTF-16 o UTF-32. Estas codificaciones no son compatibles con MLLP, pero sí serán compatibles cualquier codificación de un byte, como UTF8, iso-8859-x, cp1252, etc. En España el mas utilizado es el ISO 8859-1.

Ejemplo de mensaje HL7 v.2.3 donde las etiquetas <SB> representa el caracter no imprimible 0x0B hex, la etiqueta <EB> representa el caracter no imprimible 0x1C, y la etiqueta <CR> representa el retorno de carro o caracer 0x0D.

<SB>
MSH|^~\&|HIS||LAB||20190321090859||ADT^A01|1234569|P|2.3||||AL<CR>
EVN|A01|20190321090859<CR>
PID|1||282828^^^^HI|123456^^^^DNI|APE1^NOM|APE2|19770112000000|F|||DIR3331^^SEVILLA^^2910<CR>
PV1|1|I|301^301B|R|||976543^AP1M^APE2M^NOMM|987654^AP21^NOM2||CAR|||A|4|A1|N||OB||||||||||||||||||CAR||||||||20190321080859|20190321080859<CR><EB><CR>