MLLP: Minimum Lower Layer Protocol for HL7
HL7 MLLP (Minimum Lower Layer Protocol) is the standard TCP transport wrapper for HL7 v2 messages. It defines the framing characters that delimit where one HL7 message ends and the next begins on a persistent TCP connection. Nearly every HL7 v2 interface in production uses MLLP — it is the default transport for integration engines like Mirth Connect, Rhapsody, and Cloverleaf.
MLLP Frame Structure
Section titled “MLLP Frame Structure”Each HL7 message is wrapped in three framing characters:
<SB> [HL7 Message Data] <EB><CR>| Character | Hex | Name | Purpose |
|---|---|---|---|
| SB | 0x0B | Start Block (Vertical Tab) | Marks the beginning of an HL7 message |
| EB | 0x1C | End Block (File Separator) | Marks the end of the HL7 message |
| CR | 0x0D | Carriage Return | Immediately follows EB to signal frame complete |
Wire Format Example
Section titled “Wire Format Example”A complete MLLP frame on the wire (hex representation):
0B ← Start Block4D 53 48 7C 5E 7E 5C 26... ← MSH|^~\&|... (HL7 message bytes)0D ← Segment delimiter (CR between segments)50 49 44 7C 31 7C... ← PID|1|... (next segment)0D ← Segment delimiter... ← Additional segments1C ← End Block0D ← Carriage Return (frame complete)Within the message, segments are separated by 0x0D (carriage return). The outer framing (0x0B … 0x1C 0x0D) wraps the entire message including its internal segment delimiters.
Connection Patterns
Section titled “Connection Patterns”Persistent TCP Connection (Most Common)
Section titled “Persistent TCP Connection (Most Common)”The standard MLLP pattern maintains a long-lived TCP connection. Connection pooling and keepalive timers maintain the connection during idle periods.
Connection-Per-Message
Section titled “Connection-Per-Message”Some implementations open a new TCP connection for each message. Less efficient but simpler to implement and more resilient to network interruptions. Some firewalls and load balancers prefer this pattern.
Listener vs Sender Roles
Section titled “Listener vs Sender Roles”| Role | Description | Typical System |
|---|---|---|
| Listener (Server) | Binds to a port and waits for connections | Integration engine receiving messages |
| Sender (Client) | Initiates TCP connection to a listener | EHR or ancillary system sending messages |
Most integration engines can operate in both roles simultaneously — listening for inbound messages on some channels while sending outbound messages on others.
Port Configuration
Section titled “Port Configuration”MLLP has no officially assigned port number. Common conventions:
| Port Range | Usage |
|---|---|
| 2575 | HL7 registered port (IANA), rarely used in practice |
| 5000-5999 | Common range for custom MLLP listeners |
| 6000-6999 | Alternate range, often used in multi-channel setups |
| 8000-8999 | Sometimes used alongside HTTP interfaces |
In multi-interface environments, each channel typically gets its own port (e.g., ADT on 5001, ORU on 5002, ORM on 5003).
MLLP over TLS
Section titled “MLLP over TLS”Securing HL7 transport with TLS (formerly SSL) encrypts the MLLP connection:
Configuration Requirements
Section titled “Configuration Requirements”| Setting | Recommendation |
|---|---|
| TLS Version | TLS 1.2 minimum; TLS 1.3 preferred |
| Certificate | X.509 certificate from trusted CA or internal PKI |
| Mutual TLS | Recommended — both client and server present certificates |
| Cipher Suites | Disable weak ciphers (RC4, DES, 3DES) |
TLS Handshake Flow
Section titled “TLS Handshake Flow”The MLLP framing is identical inside the TLS tunnel — the encryption is transparent to the HL7 message layer.
HIPAA Compliance
Section titled “HIPAA Compliance”HIPAA requires encryption of PHI in transit. MLLP over TLS satisfies this requirement for HL7 v2 interfaces. Without TLS, HL7 messages containing patient data travel in cleartext — a HIPAA violation if the network is not otherwise secured (e.g., dedicated VLAN with network-level encryption).
Integration Engine Configuration
Section titled “Integration Engine Configuration”Mirth Connect
Section titled “Mirth Connect”Mirth Connect is the most widely used open-source integration engine for MLLP:
Inbound (Listener):
- Source connector type: TCP Listener
- Transmission mode: MLLP
- Local port: (assigned port number)
- Response: Auto-generate ACK or custom response
Outbound (Sender):
- Destination connector type: TCP Sender
- Transmission mode: MLLP
- Remote host/port: (destination address)
- Queue on failure: Enabled (prevents message loss)
Key Configuration Parameters
Section titled “Key Configuration Parameters”| Parameter | Recommended Value | Purpose |
|---|---|---|
| Receive timeout | 30-120 seconds | How long to wait for a complete message |
| Response timeout | 30-120 seconds | How long to wait for an ACK |
| Reconnect interval | 10-30 seconds | Delay between reconnection attempts |
| Max retry count | 3-5 | Maximum retransmission attempts |
| Keep connection open | Yes | Persistent connection (default) |
| Queue buffer size | Based on volume | Messages queued during outages |
Key Implementation Considerations
Section titled “Key Implementation Considerations”Character Encoding
Section titled “Character Encoding”| Encoding | Usage |
|---|---|
| ASCII | Default for most HL7 v2 interfaces |
| UTF-8 | Required for international character sets (accented names, CJK characters) |
| ISO 8859-1 | Latin-1, sometimes used in European implementations |
The encoding must match between sender and receiver. MSH-18 declares the character set, but many interfaces assume ASCII and don’t check MSH-18.
Message Size Limits
Section titled “Message Size Limits”MLLP itself has no message size limit, but practical limits exist:
- Large ORU messages: Pathology reports with embedded PDFs can exceed 1MB
- Large MDM documents: Full clinical documents may be several MB
- Buffer allocation: Receiving systems must allocate sufficient buffer to hold the entire message before processing
Integration engines typically have configurable maximum message size settings (default often 10-50MB).
Network Reliability
Section titled “Network Reliability”Production MLLP connections must handle network interruptions:
- TCP keepalive: Enable OS-level keepalive to detect dead connections (typical interval: 60-120 seconds)
- Reconnection logic: Automatic reconnection with exponential backoff
- Queue persistence: Messages queued during outages must survive engine restarts (disk-backed queues)
- Monitoring: Alert on connection drops, ACK timeouts, and queue depth exceeding thresholds
Firewall and NAT Considerations
Section titled “Firewall and NAT Considerations”Healthcare networks often have strict firewall rules:
- Static ports: MLLP uses fixed port numbers — request firewall rules for each interface
- Bidirectional: If both systems send and receive, open ports in both directions
- NAT traversal: Persistent MLLP connections may be dropped by stateful firewalls with idle timeouts — use TCP keepalive to prevent this
- VPN tunnels: Cross-organization interfaces often require site-to-site VPN before MLLP traffic flows