Tuesday, December 28, 2010

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.

11 comments:

David said...

John,
Your position is understandable and clearly stated. What isn't explicit is your recommendation for the "crossover" scenarios where the "little guy" and the "big guy" need to exchange info. Since we don't want Balkanization where only little-little or big-big exchanges occur, the Direct Project spent lots of time on the SMTP/SOAP conversion scenarios which are addressed in the "XDR and XDM for Direct Messaging" specification" rather than in the "core" Direct specification. What's your strawman's position on how to handle transport in that scenario?
Thanks,
David

glenmarshall said...

The technology path is fairly quick to a SMTP/SMIME solution. SMTP and SMIME are already standards. The ISO 17090 standard is already available for health care X.509 certificates and, as a bonus, it enables data providers to assert professional credentials in a standard (X.509-2000) way.

The biggest problem is major IT vendors lack of ease-of-use for SMTP/SMIME, and lack of X.509-2000 implementations. To kick-start the vendors may require government incentives, carrot and/or stick.

Andrew said...

I think the proposed approach is solid. It makes good sense. However I am curious to understand your thoughts on how the HISP would be funded.

John Halamka said...

I'll write a post next week about HISP funding. In brief, State HIEs should offer conformance testing services for HISPs, paying vendors an incentive to conform with State HIE requirements. Additionally, State HIEs could pay a connectivity incentive for each clinician successfully transmitting data to the HIE, analogous to the Regional Extension Center program that is being used to incentivize EHR implementation. Ongoing fees to support the HISP will be provided by HISP customers.

John Halamka said...

David - The big guys need to be able to send and receive from anyone else using at least the common SMTP/SMIME transport. How they handle local transport between big guys or internally is up to them, with TLS being a logical choice. However, these alternative transport methods should not be part of the Direct Core specification. Additional implementation guides such as SMTP/SOAP conversion will be helpful.

ftrotter said...

I always advocated for SMTP over TLS but gave up after getting shot down several times on the issue.

The problem is the lack of support for using multiple certificates on server and client libraries. Making it difficult to establish circles of trust automatically in the TLS connection. Hard limit on the technology unfortunately, everyone wanted to do both TLS and S/MIME.

-FT

Arien Malec said...

I just posted on this topic on the Direct Project blog:

http://blog.directproject.org/2010/12/what-does-it-mean-to-be-direct-project-compliant.html

Corey Spears said...

John - I think clear implementation guidance (including use case applicability) is definitely needed in regards to this transport technology. Can you comment of the suitability of SMTP for communication that requires more real-time and synchronous behavior than simply sending content from sender to receiver (e.g. activities involving decision support, query of a registry like an immunization registry (which is an area that sorely needs transport specification harmonization), etc.)?
Thanks,
Corey

Hank said...

Does your transport suggestion preclude, support, or serve as a transition to the tagged-data proposal of PCAST?

Prasad Mokkapati said...

Rather than bringing in yet more entites - HISP ... into the mix as well as complexities of managing security, protocols, connectivity from Email to EHR systems.. Would'nt it be better to transfer information from physician to Patient (portal) and the appropriate information then transferred from Patient portal to the other doc ?

Ultimately, a Patient needs/owns all the medical history and would be the best one to manage the security of their records. Additionally, it would be easier for all EHR vendors to connect to a Patient portal.

Brian Mahoney said...

I think the only solution for most doctors and other healthcare providers is free Direct email web-portals similar to the Microsoft HealthVault “Message Center” App.

Given FAX is still the dominant solution with most healthcare providers, even this is a technological leap.

My business specialty is large technology mashups for general users with a lot of emphasis on hand holding and cajoling. I have never worked in core healthcare (lots of 501(c) though).

Recently I had an ER event that devolved into multiple surgeons and other physicians. Communications was chaotic, and the majority of the healthcare providers mandated only FAX or hand delivery/pickup of documents (e.g. Hoag Hospital).

Based on a web search, I did all the following with free tools:

1. Opened a Microsoft HealthVault and enabled their Direct email “Message Center” App.
2. Enabled other HealthVault Apps for labs, pharmacy etc.
3. Uploaded Blue Button health history files from the VA and CMS.
4. Uploaded imaging results from CD’s I obtained from hospitals etc.
5. Acquired health histories in digital and paper formats from MD’s and hospitals.
6. Used the Mayo Clinic Health Manager and other App’s to enter and upload health histories, doctors, contacts etc.
7. Printed and captured HealthVault reports in PDF.
8. Received all the provider-questionnaire Fax’s with a computer and used PDF-XChange Viewer to OCR and typewrite the results on to them. In every case, the providers would only accept them by return Fax.
9. Deliver everything else (labs, histories, contacts, Advance Health Care Directive etc.) to the involved parties according to their transmission rules.

The greatest failure of my solution was that none of the player’s could/would receive or send Direct email.
Ironically, if there were free Web-HISP portals like the HealthVault Direct email “Message Center” for healthcare providers, most of the doctors were ready to try encrypted email.

I had to deliver the new labs, radiology reports and images to all the doctors by email or FAX as all of them claimed they never received anything. I waited until three days after receiving them all myself.

The real world, the virtual world and healthcare bedlam… In 50-years of technology (I started on GE computers in Europe) I thought I’d seen it all.

...Brian