1. Overview
The CORE HL7 Listener supports secure HL7 Version 2.x message delivery using Minimal Lower Layer Protocol (MLLP) over TLS encrypted TCP/IP connections. The listener accepts inbound HL7 messages from approved HL7 Senders and optionally supports mutual TLS (client certificate authentication). The "HL7 Standard" for TCP/IP communications does not include any encryption standards. This is by design. This means that while our implementation of the secure TCP/IP connection is not "HL7 Standard" it certainly adheres to the TCP/IP Standard for establishing a TCP/IP Listener (just like MS SQL Server, or IIS). See What Is A Listener for more information.
IMPORTANT: Any CORE HL7 Listener Profile which has been configured as a SSL/TLS enabled listener CANNOT receive HL7 messages from a pure "HL7 Standard" HL7 TCP/IP Sender. Any HL7 Sender must follow the proper connection and validation procedures required for connecting and sending data to a SSL/TLS enabled TCP/IP Listener.
Supported use cases include:
•Hospital information systems
•Laboratory systems
•EMR/EHR integrations
•Interface engines
•Medical device integrations
2. Supported Protocols
Features Supported
•HL7 Version 2.x: Yes
•MLLP Framing: Yes
•TLS 1.2: Yes
•TLS 1.3: Yes
•SSL 2.0: No
•SSL 3.0: No
•TLS 1.0: No
•TLS 1.1: No
3. Network Requirements
Settings Example:
Hostname: hl7.company.com
Port: 2575
IP Address: 1.1.1.1 <IP of Listener>
Protocol: TCP/IP
Direction: Outbound from Sender
Firewall rules must allow outbound TCP connections from the sender to the configured listener port.
4. TLS Encryption Requirements
The HL7 Listener requires encrypted TLS communication.
The sender must support: TLS 1.2 or TLS 1.3
The listener presents an X.509 server certificate during the TLS handshake.
The sender should:
•trust the certificate authority (CA)
•or trust the provided self-signed certificate
•validate certificate expiration
•validate the server Thumbprint, hostname or SAN entry
5. Mutual TLS (Optional)
If enabled by the listener, the HL7 Sender must present a valid, approved client X.509 certificate during the TLS handshake.
The listener validates the client certificate against:
•approved certificate thumbprints
•certificate expiration
•certificate validity
Connections from unapproved client certificates will be rejected.
NOTE: If mutual TLS is NOT enabled by the listener then any client certificate presented by the HL7 Sender will be ignored.
6. MLLP Framing Requirements
All HL7 messages should use standard MLLP framing unless custom MLLP framing has been mutually agreed to.
BOM Start Message: (Hex) 0x0B
EOM End Message: (Hex) 0x1C 0x0D
Example: <VT>HL7 MESSAGE<FS><CR>
Custom BOM and EOM MLLP Framing can be negotiated.
7. Character Encoding
Supported message encodings include:
•UTF-8
•Windows-1252 (ANSI)
UTF-8 is recommended.
8. Connection Behavior
The listener supports:
•Persistent TCP connections
•Multiple HL7 messages per connection
•Automatic reconnect handling
The sender may either keep the connection open or reconnect for each message.
NOTE: The CORE HL7 Listener will typically implement a IDLE TIMEOUT behavior wherein IF no HL7 traffic is received for a configured period of time (range: 10 minutes to 2 hours) it will reset itself. This will result in any persistent idle sender connections being disconnected.
9. HL7 Acknowledgements
Acknowledgements are enabled by default and returned based on the value in the MSH segment of each message.
The listener will return the HL7 ACK message after successful message receipt and processing.
The sender should implement:
•ACK timeout handling
•retry logic
•disconnect recovery
NOTE: Different ACK behavior, like ALWAYS send ACK or NEVER send ACK can be mutually negotiated.
10. Error Conditions
Connections may be rejected for:
•Invalid TLS protocol
•Invalid or missing client certificate thumbprints (Mutual TLS)
•Expired certificates
•Invalid MLLP framing
•Network interruption
11. Recommended Security Practices
For best security:
•Use TLS 1.2 or TLS 1.3 only (REQUIRED)
•Use certificates from trusted certificate authorities when possible
•Use mutual TLS for sender authentication
•Use VPN connectivity when transmitting HL7 traffic across public networks
•Restrict firewall access to approved IP addresses
12. Example Connection Flow
•Sender opens TCP connection
•TLS handshake begins
•Listener presents server certificate
•Sender validates certificate
•Optional client certificate authentication occurs
•Secure TLS session established
•Sender transmits MLLP framed HL7 message
•Listener processes message
•Listener returns HL7 ACK
•Connection can then remain open or closed
13. Support
Vendor: TransWorld Scribes Ltd
Contact: support@transworldscribe.com
Web: https://www.transworldscribe.com
