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!
John, I couldn't be more with you on the optionality trap; it always seems like a good idea when trying to reach consensus, and always comes back to get us.
ReplyDeleteNote that at least specifically in the Direct case, there was no interop requirement around XDR/SOAP --- the ONLY wire protocol in the applicability statement is SMTP. We did consider and write documentation describing how an XDR endpoint could translate to/from SMTP, but that was as a convenience for implementers that already had XDR behind the firewall (the same as has been done for RESTful messaging endpoints) --- not as a peer wire protocol.
I know that doesn't help with some of the stage 2 requirements that do elevate XDR to first-class "optionality" ... but at least the original intent was there....
---S