HL7 Transport Methods

HL7 messages are sent via a variety of TCP/IP transports, some of which include: 

      • Lower Layer Protocol (LLP)
      • File Transfer Protocol (FTP)
      • Simple Object Access Protocol (SOAP)
      • Simple Mail Transfer Protocol (SMTP)

Although HL7 can be transmitted using a variety of transport protocols, the most common transport method for real time point-to-point interfaces is LLP. For systems which require batch HL7 processing, FTP is typically utilized.


The basics: TCP/IP based communication

Before looking at the common HL7 transport methods, it’s important to understand the basics of TCP/IP based communication, the roles of the client and server when implementing an HL7 interface, as well as the limits of TCP/IP. Securing HL7 transport. 

When implementing an HL7 interface, your interface will either be acting as a Client or a Server.

TCP/IP Server

A TCP/IP server is a program that listens on a TCP/IP port number receiving connections from clients. For instance, a web server is a special type of TCP/IP server that listens on port number 80. A TCP/IP server can have many different TCP/IP clients connected to it.

A typical example of where you might want to implement an HL7 server is when you want to receive an ADT (Admit/Discharge/Transfer) feed to extract, for instance, patient demographics. Typically, you would write your interface as a TCP/IP server. You would then listen on a port number that you could negotiate with your counterparty, and the device sending you the ADT messages will connect to your server. This means you need to give the host and port number that you are listening on to the administrator of the ADT feed so they know how to connect to you.

TCP/IP Client

A TCP/IP client is a program that connects to a TCP/IP server. For instance, Netscape and Internet Explorer are TCP/IP client programs that connect to web servers. A TCP/IP client must specify both the host address or IP address, as well as the port number that it wants to connect to.

A typical example of where you might want to implement an HL7 client is when you want to send lab results to a HIS (Health Information System). The administrator of the HIS system would need to give you the host or IP address of their HL7 server and the port number that it is listening on.

ACKnowledgment Messages

One final point that confuses many people is how HL7 ACKnowledgment messages should be sent. It is important to understand that when a TCP/IP connection is established, it is a two-way channel of communication. When a client establishes a connection to a server there is one channel on which the client can send data to the server, and another on which the server can send data back to the client. This latter channel should be used to send ACK messages.

Sometimes it is necessary to implement both a client and a server component for your product’s HL7 interface. Avoid the temptation to follow some creative members of the computer community who use the client component to send back all the ACK messages. Your creativity will be someone else’s problem. This certainly happens in the real world, but if you have the choice, make use of the fact that you can use the second channel of communication to send back ACK messages, as this is a much cleaner design.




LLP - Lower Layer Protocol

The Lower Layer Protocol (LLP), sometimes referred to as the Minimal Lower Layer Protocol (MLLP), is the absolute standard for transmitting HL7 messages via TCP/IP. Since TCP/IP is a continuous stream of bytes, a wrapping protocol is required for communications code to be able to recognize the start and the end of each message. The Lower Layer Protocol is the most common HL7 transport mechanism for sending unencrypted HL7 via TCP/IP over a local area network, such as those found in a hospital.

When using LLP, an HL7 message must be wrapped using a header and trailer (also called a footer) to signify the beginning and end of a message. These headers and footers are usually non-printable characters that would not be shown in the actual content of an HL7 message.

The typical structure of an HL7 message being sent via LLP is described in the table below. It contains four parts:

Header HL7 Message Trailer Carriage Return
Vertical tab character (0x0B)

The HL7 message is wrapped using a header and trailer (immediately followed by a carriage return):

Field separator character (0x1C) Carriage return (0x0D)


Moreover, you must also ensure that each segment is terminated by an 0x0D (carriage return) character. This is mandated by the standard, but often HL7 log data can be received via FTP or email where the segment separators have been transformed into 0x0A characters.

There are various methods to secure data traffic via LLP:

      • VPN Tunnel: A Virtual Private Network (VPN) is a private network that uses the Internet to link remote sites together while using secure cryptography to ensure that it cannot be read by unauthorized users. This is a very popular way to solve the HL7 encryption problem, especially in today’s climate as many common cloud platforms provide VPN connections as part of their platform offering. 
      • SSH Tunnelling: This is a similar concept to using a VPN connection wherein an SSH server is used to securely tunnel the LLP traffic between systems. Every Linux distribution has a built-in SSH server and there are also options for Windows such as VShell.
      • TLS/SSL: HL7 messages can also be transported over the Transport Layer Security (TLS) or Secure Socket Layer (SSL) cryptographic protocol to ensure authentication and encryption of messages. 

HLLP - Hybrid Lower Layer Protocol

The Hybrid Lower Layer Protocol (HLLP) is a variation of the more widely used Lower Layer Protocol. Like LLP, HLLP uses TCP/IP as its transport but incorporates error detection and verification via the use of checksums at the end of messages. The checksums are used to verify that no data was corrupted. Checksums are typically computed for each block of data that is sent for the sending application and then verified for accuracy at the receiving application.

The checksums used in HLLP are non-standard, meaning they may vary from implementation to implementation.

A common type of checksum used in HLLP is called BCC (Block Character Check), which is the sum of all characters in a block. The BCC checksum is considered a weak checksum since it may be easy to find different blocks that generate the same block checksum. Although the BCC checksum is relatively easy to implement, it may not meet the communication standards of most companies.

In practice, most vendors choose to use TCP/IP over LLP, rather than HLLP. LLP is a very simple protocol to incorporate and can be used instead of HLLP since the TCP/IP channel provides all of the services necessary for the error-free delivery of HL7 messages. This includes:

1. Connection Handshaking

The process by which two systems initiate communication. Start and end control characters are used to start/stop the transmission of data.

2. Full Duplex Data Transfer

The process by which a system transmits and bi-directionally receives data simultaneously.

3. Error Detection and Retransmission

The process by which the transport layer detects segments that fail transmission and retransmits them, if necessary.

4. Flow Control

The process by which the flow of messages between systems is managed by TCP through the use of ACKs and NACKs. Through the use of ACKs/NACKs and other built-in mechanisms in an HL7 application, you can manage the flow of data to ensure that messages are transferred efficiently and reliably.

5. Connection Termination

The process by which a connection is ended independently by each system via a handshake.

In most cases, HLLP is an unnecessary requirement as long as the two communicating health systems are using a reliable Open Systems Interconnection (OSI) transport layer since the transmission of messages, as well as the integrity of messages, is already verified by the underlying OSI protocols.

Hybrid LLP is only used for unreliable transports (e.g. transporting messages via a serial cable) and is considered unnecessary by most vendors.

With TCP/IP, checksums over data and headers are already inherent to the protocol. This means that the protocol will detect checksum errors and request the retransmission of data, if necessary. What this means is that a secondary checksum associated with HLLP will not further guarantee data delivery but just adds to transport overheads.



FTP - File Transfer Protocol

The File Transfer Protocol (FTP) is an application layer TCP/IP protocol which moves files between local and remote file systems or vice versa. FTP initiates two TCP connections in parallel to transfer a file; a control connection, to send commands for interacting with the server (for example, authenticating) and initiating file actions (for example, download or rename a file); and a data connection, to send out the file. 

When sending HL7 messages that contain electronic Protected Health Information (ePHI), it is pertinent that files are sent using a secure protocol. There are two ways to provide secure transport of HL7 messages using FTP: 

  • SFTP (SSH File Transfer Protocol) is an extension of the SSH protocol, and provides secure file transfer, access and management capabilities for any data stream. 
  • FTPS (FTP Secure) provides support for the TLS (Transport Layer Security) and SSL (Secure Socket Layer) protocols. 

SFTP and FTPS are often thought of as secure “extensions” of FTP, but this is not quite the case and the two protocols are actually incompatible. Either SFTP or FTPS works well, even for some real-time feeds, if your counterparty is able to support it.

HL7 batch processing involves sending files via the FTP protocol or as email attachments. According to the HL7 Standard, any HL7 message must start with an MSH segment, however when sending a batch of HL7 messages, the rules change. A batch contains several single HL7 messages (each marked by their starting MSH segments) however, the batch itself is enclosed in a batch header. This is identified with batch headers, FSH and BSH, and batch trailers, FTS and BTS, as seen in the sample HL7 batch file below.

PID|||583020^^^ADT1||WHITE^CHARLES||19980704|M||AI|7616 STANFORD AVE^^ST. LOUIS^MO^63130|||||||20-98-1701||||||||||||
PID|||583020^^^ADT1||WHITE^CHARLES||19980704|M||AI|7616 STANFORD AVE^^ST. LOUIS^MO^63130|||||||20-98-1701||||||||||||
OBR|1|A101Z^MESA_ORDPLC||P1^Procedure 1^ERL_MESA|||||||||xxx||Radiology^^^^R|7101^ESTRADA^JAIME^P^^DR|||||||||||1^once^^^^S|||WALK|Project Manager||||||||||A||
PID|||583020^^^ADT1||WHITE^CHARLES||19980704|M||AI|7616 STANFORD AVE^^ST. LOUIS^MO^63130|||||||20-98-1701||||||||||||
BTS|3|Batch Message Count
FTS|1|Have a Nice Day




Looking for professional advice? 

Iguana is the leading HL7 integration engine on the market, trusted globally for 20+ years. To learn more about HL7 data exchange, contact one of our integration engine experts today.

Additional Resources:

Debunking the Myths of HL7 Integration

There are many myths about what the HL7 standard can do and the implications for healthcare organizations. In this guide, we set the record straight on common HL7 claims.

At iNTERFACEWARE we specialize in connecting everything, and our Iguana integration solution can connect with and leverage the HL7 standard, contact us today

Hear from our HL7 Integration Specialists

At iNTERFACEWARE we specialize in connecting everything. Our solution, Iguana can connect anything HL7 related.