Concrete Model Commentary Page
Fred Trotter
IHE |
SMTP |
REST |
XMPP | |
Fred's very subjective opinions from a protocol perspective. Feel free to correct me, you can wiki-edit me or just send me an email. |
The use of IHE protocols at a national infrastructure level is not mature. In fact one could argue that the whole point of the NHIN Direct project is to avoid the complexity of implementing a massively complex health exchange standard, even as that standard if being stabalized. IHE is a protocol "designed for" the transfer of healthcare information, but it is extremely complex and relatively untested in comparison to any of the other three protocol stacks.On the other hand, it handily solves the problem of "how to interoperate with NHIN Exchange. This is the heavy weight contender here. It could bring lots of potentially benificial healthcare-focused functionality, but at the expense of relatively high levels of development complexity. The only FOSS implementations of this type of technology that I know of are the NHIN CONNECT project, some MOSS+Health Tools projects, and some of the Mirth code. All relatively young and untested on a national scale. I am unaware of the maturity of existing proprietary implementations. |
This protocol provides the least deviation from the "similar to email" expectation for the NHIN Direct project since it -is- email. One could argue that since this is the "protocol to imitate" that it is also the "protocol to beat". If there was such a thing as a known-good technology this would be it. Given the tremendous complexity of creating a decentralized trust fabric (which I nickname the "healthquilt"), there is alot to be said for choosing the technology stack that has already come closest to meeting the requirements for NHIN Direct in the real world. In my mind we should be evaluating the other protocols with the question "How is this protocol stack so much better than SMTP+SMIME that it is worth the headaches involved?" Note that some problems, like spam, suffered by SMTP generally will not be as much of a problem on a secure SMTP network. Lots of very solid Open Source and proprietary implementations of this protocol could potentially be made compliant with mere configuration. SMTP software is some of the most mature on the Internet. |
REST is not even a formal protocol. It is a philosophy of development that focuses on using HTTP to streamline data exchange. If we go with REST we are really building NHIN Direct as a new protocol on top of a really good data exchange philosophy. If we were going to build something from scratch REST is the way to go. It dramatically streamlines lots of hairy software design issues. Which leaves us with the question "Should we be developing a new protocol at all?" I think there might be a good case here, but everyone should feel comfortable knowing that this would probably be the most "from scratch" implementation strategy. Lots of good REST server and client implementations in both open source and proprietary worlds. Nothing stable on the actual protocol level, but lots of reliable tools. |
Some consider XMPP to be the "sucessor to the thrown" of SMTP. The reasons that I can glean are that XMPP has superior spam handling (built in white listing and such) and strongly supports a model compatible with real-time messaging and potentially even mobile phone text messaging. However, most of those benifits are in comparision to the wide-open spam-fest that is SMTP. With SMTP+SMIME following anything like what the Security and Trust group is recommending, our "secure email network" will be relatively resistant to spam. Does the additional functionality added by XMPP have substantive advantages against the more-familiar secure SMTP architecture? While not as mature as SMTP software, there are multiple solid Open Source and proprietary implementations of XMPP that could potentially be made compliant with mere configuration. |
Janet Campbell
IHE |
SMTP |
REST |
XMPP | |
Janet's very subjective opinions from an implementation perspective Feel free to correct me: You can wiki-edit me or just send me an e-mail |
Unlike the other implementations listed in this table, IHE is not a protocol. Instead, it's both a profile built on existing protocols and an implementation guide. The set of protocols that underlie the IHE profiles are SOAP-based web services (commonly known as WS-*), which are widely supported in all major development platforms. That's mature support for both client and server implementations, in both open source and proprietary worlds. The specific IHE transaction we propose - the "ITI-41: Provide and Register Document Set b" has open source implementations, as mentioned, in NHIN CONNECT, Open Health Tools, and as a Microsoft Connected Health Platform Solution Accelerator, as well as many commercial implementations. |
It's true that the SMTP implementation is closest to the "make it like e-mail" motivation that has captivated NHIN Direct. It would be interesting to explore, then, the extent to which providers e-mail each other today. Do providers commonly use e-mail to communicate in the use cases we've identified? If not, is it because of security concerns? Alternatively, if so, should NHIN Direct spend its time defining e-mail ... to replace e-mail? The SMTP implementation brings attention to a dissonance that has been common to many of our discussions around the possible outcomes for NHIN Direct. On one hand, we constantly call for a communication protocol that supports the simplest users without an EHR, yet our use cases are based on Meaningful Use Requirements for 2011 (which, at their base, include meaningful use of an EHR or EHR modules). These requirements define decidedly non-simple cases such as patient referrals and discharge notification and management. This dissonance leads us to scenarios where we are attempting to accommodate complex workflows assuming a technological floor that won't support the requisite factors necessary for such scenarios. As a result, we artificially limit ourselves. And finally, I've heard a few claims as to the ease of integrating SMTP into existing EHR implementations. My personal experience is that this is not a particularly trivial task, and I suspect that the continued support of the Electronic Health Record Association for the XDR profile backs me up. That's because a technical implementation isn't difficult. A usable integration is difficult, and the usability of that integration (and the design, testing, and discovery of the myriad cases where things don't work) is what takes the majority of an implementation's time from code to production. If our use cases presuppose the use of an EHR, then it's the EHRs that are ultimately responsible for the implementation's speed of adoption and eventual success. |
A REST implementation is simple, simpler to implement than SMTP because it does not require the integration of additional server infrastructure, simpler than SOAP-based web services conceptually. But this simplicity might be deceiving. While the SOAP-based web services are designed from the outset to work together in a consistent manner using a layered approach and allowing for gradual introduction of features without disrupting implemented ones, there is no such set of standards for REST implementations. To quote a whitepaper prepared on behalf of the Department of Homeland Security, "REST-style web services leverage the existing Web infrastructure, that is, plain XML (i.e., without SOAP) over HTTP. Due to the security limitations of basic XML over HTTP, the WS-* framework associated with SOAP Web Services provides security services to fill the gap. REST [Fielding 2000] is more of a grassroots movement, but does not provide security standards, so programmers must design security mechanisms and achieve interoperability without standards support. This ad hoc approach makes it much more of a challenge to 'build security in' from the outset." |
Besides the shortcomings listed here for other protocols, XMPP has another notable drawback - the inefficiency of in-band binary data transfer. While XMPP has addressed this through extensions, most notably the Jingle extension, SOAP-based MTOM is more mature. |