Understanding HL7 transports – MLLP

Systems exchanges HL7 messages using a variety of TCP/IP transports including MLLP, HLLP, SOAP, SMTP, FTP and even HTTP. The most common type of transport used is MLLP ( Minimum Lower Layer protocol )  which sometimes referred as LLP without ‘M’ or simply MLP.

The MLLP protocol is a minimalistic OSI-session layer framing protocol which is extensively used for the transport of HL7 version 2 and 3 messages. This protocol doesn’t require any supplementation for error detection and correction which are handled by underlying TCP/IP protocol.

This protocol uses special block markers at the start and the end of every HL7 message exchanged. The sender prepares HL7 content with start block marker <SB> and end block marker <EB> followed by a carriage return <CR>. The receiver decodes <HL7 message> by stripping these markers. This one is normal behaviour for exchanging HL7 version 2 messages. However, HL7 version 3 messages requires an acknowledgement or negative acknowledgement of 4 bytes from the receiver to sender with a ACK value in the case of success where as a NAK value in the case of failure. Both ACK and NAK enclosed by the special block markers <SB> and <EB> followed by a carriage return <CR>. This ensures a guaranteed exchange.

The MLLP transport protocol uses the following formats for exchanging HL7 version 2 and version 3 messages.

Version 2

<SB> <HL7 message> <EB><CR>

Version 3 requires additional response from the receiver in the following format.

<SB> <ACK | NAK> <EB> <CR>

The receiver always sends a response to the sender which sometimes referred as commit acknowledgement to guarantee In order delivery and At Least Once delivery of HL7 content.


Element Description
<SB> Start Block character of length 1 ASCII byte 0x0B
<HL7 message> The actual HL7 message to be exchanged in bytes. Each message contains variable number of bytes
with values greater than 0x1F followed by ASCII carriage return <CR>. Version 2 uses HL7 message in segments fashion whereas Version 3 always use in xml form.
<EB> End block character of length 1 ASCII byte 0x1C
<CR> A carriage return of length 1 ASCII byte 0x0D
<ACK> Acknowledgement of length 1 ASCII byte 0x06
<NAK> Acknowledgement of length 1 ASCII byte 0x15

Both sender and receiver are implemented with validation checks to ensure messages are exchanged in agreeable format such as Block markers, encodings, timeouts etc. Additional processing is done by the sender depending upon the type of acknowledgement.



Version 2

^^P||""|""||""|||||||""|""<CR>PV1||I|3w^301^""^01|S|||100^van den Berg^^A.S.

Version 3

<?xml version="1.0" encoding="ISO-8859-15"?>
	<MFMT_IN10001NL xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" 
	<id extension="10213" root="2.16.840.1.113883."/>
	<creationTime value="20050216140000"/>
	<interactionId extension="MFMT_IN100010NL" root="2.16.840.1.113883"/>
	<processingCode code="P"/>
	. . .
	. . .



Negative Acknowledgement


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.