What is MLLP and why does it matter for HL7 interfaces?
HL7 v2 defines the message format but not, historically, how to move it across a network. That job falls to MLLP — the Minimal Lower Layer Protocol — a deliberately tiny framing protocol that wraps HL7 messages so they can be sent over TCP. It's simple enough to describe in a paragraph, yet MLLP framing bugs are behind a surprising share of 'the interface is stuck' incidents. This guide explains how MLLP frames a message, why the framing bytes matter, and how to secure what is by default a plaintext protocol.
What MLLP does
TCP is a stream of bytes with no inherent notion of where one message ends and the next begins. MLLP solves exactly that one problem: it wraps each HL7 message in a start block and an end block so the receiver can tell messages apart on the stream. That's essentially all MLLP is — a framing convention. It does not add reliability, ordering, or security beyond what TCP provides; it just delimits messages.
The framing bytes
- A start-of-block character (0x0B, vertical tab) marks the beginning of a message.
- The HL7 message payload follows.
- An end-of-block sequence (0x1C followed by 0x0D, carriage return) marks the end.
- The receiver reads from start block to end block, strips the framing, and hands the payload to the parser.
Why framing bugs cause stuck interfaces
Because MLLP delimits messages purely by these bytes, getting the framing wrong is catastrophic in a quiet way. If a sender omits the end block, the receiver waits forever for a message that never 'ends' — the interface hangs. If a receiver doesn't buffer correctly across TCP packet boundaries (a single message can span multiple packets, and a single packet can contain multiple messages), it mis-frames and either splits or merges messages. Many 'the feed stopped' incidents are really MLLP framing or buffering bugs, not HL7 content problems.
One connection, many messages
MLLP interfaces typically hold a persistent TCP connection and send many messages over it, each individually framed and each individually acknowledged. That means your implementation must handle the full-duplex reality: send a framed message, read a framed ACK, correlate them, and keep the connection healthy. Connection management — detecting a dropped socket, reconnecting, and not losing in-flight messages — is as important as the framing itself.
MLLP is plaintext by default
Classic MLLP sends HL7 — full of PHI — as clear text over TCP. On a flat hospital network that was historically 'acceptable'; today it is a liability. There are two common ways to secure it: run MLLP over TLS (sometimes called Secure MLLP), so the transport is encrypted and optionally mutually authenticated, or tunnel it through a VPN/private link between endpoints. For anything crossing a network boundary, unencrypted MLLP should be considered unacceptable.
Securing MLLP properly
- Prefer MLLP over TLS with certificate validation; use mutual TLS where both ends can present certificates.
- If TLS isn't available on a legacy endpoint, tunnel the connection over a VPN or private network link rather than sending plaintext across untrusted networks.
- Restrict which hosts can connect (IP allow-listing/firewalling) since MLLP itself has no authentication.
- Monitor the connection and alert on drops — a silently dead MLLP link means messages are queuing or lost.
Getting MLLP right
MLLP is small, but 'small' isn't 'trivial': robust interfaces frame messages correctly, buffer properly across packet boundaries, manage the persistent connection with reconnection and in-flight safety, and encrypt the transport. Use a proven MLLP implementation rather than hand-rolling the byte handling, secure it with TLS, and monitor the link. Do that and MLLP becomes the boring, reliable pipe it's supposed to be.
