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. The real advantage of the IHE implementation, and perhaps the one least classifiable by this side-by-side comparison, is that it provides a set of guidelines that promote an effective exchange of clinical information in a healthcare setting. The IHE specifications are developed through a formal and open standards process, with formal testing, many demonstrations, and real world deployment experience. If SOAP can be considered to define the grammar of a foreign language, then IHE provides the etiquette for its use. That's a support structure that isn't present in the other implementations in this table, and it's not only vitally important, it's something that any chosen implementation will eventually create for itself naturally. The IHE implementation has already completed that work, and when we look at the maturity of any implementation, we cannot limit ourselves to an examination of its proven use in a vacuum devoid of context. In that sense, only the IHE implementation can claim that is has truly been tested, since it tests not only the protocol for exchange but also the responsibilities of each endpoint to initiate, complete, and audit the exchange.	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." As an example, the REST implementation approach uses S/MIME to accommodate for end-to-end encryption of the payload. The same can be accomplished using SOAP-based web services with WS-Security. The difference in implementation, however, can be significant. The REST implementation must create this functionality from scratch, combining libraries that are not usually designed to work together (HTTP combined with Internet message format, MIME, S/MIME). An IHE implementation can start with an existing XDR code base, and, for most existing SOAP-based web services platforms, the addition of WS-Security functionality is a little more than configuration change. Furthermore, adding new requirements to existing implementations, e.g. encrypting parts of the payload, are possible with WS-Security, while an S/MIME-based solution may encounter problems accommodating such a requirement (possible for future use in public health reporting, for example). Like many aspects of the NHIN Direct project, concepts are only simple until you get to the details, and it's the last 20 percent that devours 80 percent of the implementation's time. Complications abound in complicated scenarios, and despite our initial impressions, secure transport of clinical data is complicated.	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.