HISP to HISP communications

As Massachusetts works through the details of building a trust fabric for health information exchange, we have been working through another set of challenges in HISP to HISP communication.

Meaningful use Stage 2 requires EHRs to support the Direct Project implementation guide, which uses SMTP/SMIME as a transport protocol.   Optionally, Stage 2 also supports XDR/SOAP.

In the world of standards, "OR" always means  "AND" for implementers.   Massachusetts needs to support HISPs that allow XDR as well as those which only allow with SMTP/SMIME.   This gets confusing when there is a mismatch between the sender's protocol and the receiver's protocol, requiring a HISP to convert XDR to SMTP/SMIME or SMTP/SMIME to XDR.

There are 4 basic scenarios to think through
1. An SMTP/SMIME sender to an SMTP/SMIME receiver
2. An SMTP/SMIME sender to an XDR receiver
3. An XDR sender to an SMTP/SMIME receiver
4. An XDR sender to an XDR receiver

Scenarios 1 and 4 could be done without a HISP at all if the EHR fully implements the Direct Standard including certificate discovery.

Cases 2 and 3 require thoughtful security planning to support end to end encryption between two HISPs.

These slides provide the detail of what must be done for Cases 2 and 3.  

The challenge of supporting XDR is that the HISP must act as the agent of senders and receivers, holding their private key for use in the conversion from/to SMTP/SMIME.

As Massachusetts continues to enhance its state HIE capabilities and connect many other HISPs (eClinicalWorks, Cerner, Surescripts, AthenaHealth etc) to state government users and those using the Massachusetts HISP as part of their EHR (Partners, BIDMC, Atrius, Tufts Medical Center, Meditech users, NextGen users etc.) we now know what must be done to provide end to end encryption among different HISPs and users connected via 2 protocol choices.

We're learning once again that optionality in standards seems like a good idea, but ultimately adds expense and complexity.
.
Everyone on the HIT Standards Committee knows my bias - offer no optionality and replace the existing SMTP/SMIME and XDR approaches with RESTful APIs such as the Mitre hdata initiative.

Maybe for Stage 3!