Implementation FAQ:Encryption and Security

The use of encryption and security is discussed in the security committee, and email questions sent to that list get good answers. This page has been created to capture some of those answers to make them more accessible

Encryption

In the Security TC we have assumed that encryption happens below the application layer, e.g., via IPSec or TLS, not within HL7 messages.

Any encryption to be done on only part of a message hauls along considerable technical baggage. That includes whole new classes of administrative & infrastructure messages to establish and maintain organizational trust, communicate shared secrets (keys), user/entity authentication, etc. It would require considerable net-new volunteerism to accomplish this work along with other things already on our agendas.

As a practical matter, we also should assume that people want to access healthcare data in a way that resembles the regime used for e-commerce or VPNs. When healthcare consumers access their healthcare information it's proper to assume that they'd use normal browser-based access, which limits the technical choices anyhow.

The Security TC does support the HL7 application-layer necessities, of course, such as the recently-balloted RBAC role vocabulary and the exchange of privacy-consent data.

(email from Glen Marshall 31/8/07)

note as well that the Abstract Transport Specification (ATS) has clearly stated that encryption "belongs" to the Messaging Infrastructure. I'd say that the answer to best practices or how to solve encryption problems shouldn't reside on HL7 normative pack. (from Miroslav Koncar)

When you ask about "requirements" for encryption, you could be talking about policies, or technology. I'll assume the latter, since the former is something that is unlikely to be specified within HL7 due to many variations in policy needs. With regard to encryption technology, the mechanisms to enable it is a function of the underlying messaging infrastructure. The HL7 specifications for sending HL7 messages over Web Services and ebXML for example, should specify how to secure a communications channel. (from Keith Boone)

IHE view

MLLP, which really doesn't provide any support for encryption, since this very light "application layer" doesn't provide access to lower layers. However, the sockets can be encrypted using TLS, as is described in the IHE ATNA profile (see http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_4.0_Vol2_FT_2007-08-22.pdf). (from Keith Boone)

also

The IHE profiles effectively do require encryption for all the 2.X HL7 transport with a escape clause for the local implementation by requiring TLS unless the local administration determines that their physical network provides equivalent protection. This was originally put in so that the heavy network traffic for radiology images had the alternative of TLS or VLAN. There are many implementations of local VLANs that have an encryption and authentication protection that is equivalent to TLS, and many radiology suites were using VLANs rather than host-based encryption like TLS. This means that IHE has made the policy decision that the traffic needs TLS equivalent protection, giving the local policy makers the final decision on host-based or network implementation. (Robert Horn)

This seems to be the most common regulatory attitude worldwide.

Signing

See the separate page:

• Digital Signatures