A Secure Transport Strawman

Over the past few years, I've posted many blogs about the importance of transport standards.   Once a transport standard is widely adopted, content will seamlessly flow per Metcalfe's law.   We already have good content standards from X12, HL7, ASTM, and NCPDP.  We already have good vocabulary standards from NLM, Regenstrief, IHTSDO and others.   We have the beginnings of transport standards from CAQH, IHE, and W3C.   We have the work of the NHIN Direct Project (now called the Direct Project).

After working with Dixie Baker/the HIT Standards Committee's Privacy and Security Workgroup on the Direct evaluation and after many email conversations with Arien Malec, I can now offer a strawman plan for transport standards.

Based on the implementation guides currently available, the HIT Standards Committee evaluation found the SMTP/SMIME exchange defined by the Direct Project sufficiently simple, direct, scalable, and secure, but stressed the need to develop implementation guidance that is clear and unambiguous.   I've received many emails and blog comments about SMTP/SMIME verses other approaches.  I believe I can harmonize everything I've heard into a single path forward.

As with all HIE efforts, policy has to constrain technology. The policy guidance that the Direct Project was given was as follows:

A "little guy" such as a 2 doctor practice in rural America wants to send content to another 2 doctor practice across town.   These small practices should not have to operate servers or have to pay for a complex health information exchange infrastructure.   Healthcare Information Services Providers (HISPs) should provide them the means to exchange data as easily as Google provides Gmail or Verizon FIOS provides ISP service.   All HISP to HISP communications should be encrypted such that the sending practice and receiving practice can exchange data without any HISP in the middle being able to view the contents of the data exchanged.

In my opinion, for this type of exchange

Small Practice 1 ---> HISP 1 ----> HISP 2 ----> Small Practice 2

SMTP/SMIME at an organizational level is the right transport solution.   By organizational level, I mean that one certificate is used for the sending organization and one for the receiving organization.   There is no need to issue certificates to individual people involved in the exchange.

SMTP/SMIME at an organizational level encrypts, integrity protects, and digitally signs the payload at the point where the message is created.  The payload can be sent through multiple intermediaries to the receiver with assurance that the message will be readable only by the intended receiver.

Given the policy guidance to support the little guy, any practice in the country that wants to send any content securely to any other practice without risk of viewing by any intermediary, SMTP/SMIME is sufficient and appropriate.

For other types of exchanges with different policy constraints, TLS is more flexible and functional.   In Massachusetts, NEHEN is a federated HIE, enabled by placing open source software within the networks of each participating institution.    Server to Server communication is a SOAP exchange over TLS.   In this case, the HISP resides within the firewall of each participating payer or provider organization.   TLS enables simple, secure transmission from one organization to another.   TLS does not require a certificate store.  TLS enables REST, SOAP, or SMTP transactions to flow securely because the connection between organizations is encrypted.

Where TLS falls down is in the Direct use case with its policy requirements that no intermediaries between the sender and receiver may have access to unencrypted data.  This excludes the case in which the sender uses a HISP as a business associate to package the data as an SMIME message.  A sender has no way of knowing what intermediaries the information may flow through, so implementing secured message flows from any sender to any receiver using TLS is untenable.

Thus, our path forward is clear.  If we impose a policy constraint that small organizations which use external HISPs should be able to send data securely to other small organizations which use external HISPs such that the HISPs cannot view the data, then SMTP/SMIME with some mechanism to discover the certificates of each organization is the right answer at this time.

If the use case is simpler - secure exchange between HISPs such that the HISPs reside within the trading partner organizations or a relaxation of the policy constraint that HISPs cannot view data, then TLS is the right answer at this time.

The next steps are also clear.   Establish SMTP/SMIME as a standard, and secure email using SMTP/SMIME as a certification criteria for EHR technology.  Establish standards for X.509 certificates for organization-to-organization exchanges, as suggested by the Privacy and Security Tiger Team.

There you have it - the solution to the transport standards issue for the country - SMTP/SMIME for little guys using external HISPs and TLS for other use cases.

Done! Now it's time to implement and foster adoption.