Important things to know about HL7 Encryption, HL7, and the regulatory environment related to this.

Point #1. HL7 as a world-wide standard does not support encryption of any kind. This is not an oversight, it is by design. This does NOT mean that security (and thus encryption or restricted access) for HL7 data is not required, on the contrary it is absolutely required. It is just NOT part of the HL7 standard.

Point #2. Many people confuse ENCRYPTION with SECURITY. They are not the same thing! SECURITY is an enormous topic with many, many facets of which ENCRYPTION is just one small part. If your situation requires TLS Encryption of HL7 data (which it might not) you should carefully examine why this type of solution is correct for you. In our opinion the vastly superior solution is to use a VPN (Virtual Private Network) typically hosted by the machine running the HL7 Listener or by the larger organization. This allows the VPN software to handle the end-to-end encryption. VPN software comes in all shapes and sizes and all are much more in tune with how to handle the SECURITY of Network communications.

SSL / TLS HL7 Only

Consider the image above. Using SSL/TLS alone encrypts the HL7 traffic between the sender and receiver, which protects the message contents from being easily intercepted. However, exposing HL7 Listener ports directly over the public internet or a wide-area network (WAN) still increases security risk because the system itself becomes visible and reachable by outside networks. Attackers can continuously probe open ports, attempt denial-of-service attacks, exploit operating system vulnerabilities, or try to abuse weak certificate or authentication configurations. TLS protects the data in transit, but it does not hide or isolate the service itself. So whether this is safe or not depends on the network SECURITY. What type of network is being traversed between Site-A and Site-B? If it is the internet, this is NOT SAFE. If it is your LAN (local area network), this is probably safe. If it is a large WAN (wide area network) or intranet, this might be safe but be cautious.

Secure VPN

If you are using a secure VPN as shown above there is no legal or regulatory requirement anywhere in the world that says you need anything more as far as the end-to-end encryption of HL7 messages is concerned because a properly configured VPN adds another security layer by creating a private encrypted network tunnel between trusted sites. This reduces exposure because the HL7 Listener is no longer openly accessible from the internet. In practice, many healthcare organizations prefer VPNs because they provide network isolation, access control, and easier firewall management in addition to TLS encryption.

Secure VPN AND HL7 SSL/TLS

The most secure approach is often to use both together: VPN for private network connectivity and general encryption, and TLS for end-to-end message encryption and authentication. IF you opt to implement this there is a caveat, all HL7 data WILL be encrypted/decrypted at least TWICE and there is a performance consideration. As in the image above, the VPN secures and encrypts data between and .

The HL7 TLS Sender and Listener encrypts HL7 data all the way from to .

Point #3. There are unscrupulous software vendors and salespeople out there who use the confusion of decision makers about the technical differences between SECURITY and ENCRYPTION to "up-sell" their clients to something that they may not need. We have seen clients who implement a VPN AND point-to-point encryption like this just because the vendor selling the HL7 SSL system told them that they "must have this to be secure". In one instance a client was encrypting and decrypting the HL7 data SEVEN (7) times between the Sender and the final recipient. That is overkill. Consider this test: Is the Vendor who is telling you that you must have this feature charging you extra for it? We do not!

Some things to know about how this will work:

•You can use a TLS certificate you can purchase through a 3rd party globally trusted CA (Certificate Authority) see 3rd Party SSL Vendors, you can use your own Self-Signed TLS certificate see Creating Your Own Certificate, or you can use a Self-Signed TLS certificate that the CORE Listener creates for you (see below).

•You can also require 2 way TLS, meaning that you can also require that any HL7 Sender also have their own SSL/TLS certificate in order to send HL7 messages to your SSL Enabled CORE Listener.

In this dropdown you have 3 choices:

•TLS 1.2 and TLS 1.3

•TLS 1.2 Only

•TLS 1.3 Only
 

TLS stands for Transport Layer Security.

In simple terms, it’s the technology that encrypts data sent over a network, so information (like HL7 messages) can’t be read or tampered with while it’s in transit between systems.

These options control which versions of the security protocol (TLS) your system is allowed to use when connecting. Think of TLS like a secure language both systems must speak to encrypt data. If you choose “TLS 1.2 and 1.3”, your system will try the newest version (1.3) first and fall back to 1.2 if needed—this is the most flexible and usually the best choice. Selecting “TLS 1.2 only” or “TLS 1.3 only” means you are restricting communication to just that version, which can improve compatibility (for older systems) or security (for newer ones), but may prevent connections if the other side doesn’t support that version.

In summary: both sides must support at least one matching version or the connection will fail. TLS 1.3 is newer, faster, and more secure, while TLS 1.2 is older but still widely used and supported. If you’re unsure, choose both TLS 1.2 and TLS 1.3 to maximize compatibility, and only lock it down to a single version if you’ve been told to do so by the system you’re connecting to or management within your own enterprise. If you choose both TLS 1.2 and TLS 1.3, when the secure connection is established between the HL7 Sender and the HL7 Listener they will "agree" in the TLS Handshake to use the highest version supported by both sides.