Today Anand Shroff replied to my prior post with some very provoking questions. I have added emphasis in quoting his reply.
Wes – are you detecting a split between EMR vendors and HIE vendors? From where I sit, the HIE vendors should be fairly neutral about what gets picked, as long as there is a single standard and not multiple \standards\. It is fairly easy for HIE vendors to implement IHE/SOAP (most of us have done that already) and SMTP/REST.
I suspect that the real pushback might be coming from the EMR vendors, who have recently started adopting IHE based integration and from what I have seen, they are beginning to see incremental results from substantial efforts. Their fear may be that a change in fundamental standards (from SOAP to REST) may obviate their current investment and will instead require them to refocus on building to new specs. Their core competency is clinical EMR development, not interoperability and therefore this is an acquired taste at best.
Secondly, there is a concern in some corners that NHIN Direct sets too low a bar and as a result undermines the Meaningful Use effort and the REC funds that are supposed to foster broader and more meaningful EMR adoption. A \mailbox\ type solution that is built using NHIN Direct principles and without a roadmap to getting to the level 1 Meaningful Use criteria can dilute those efforts.
We are not certain about how to address that concern. I know that this issue came up at the Seattle face-to-face meeting, but didn’t seem to have been resolved to a level that can be messaged to the community as a whole.
My observation is the opposite of the split you described. The participants that seem to derive a substantial portion of their revenue stream directly or indirectly from the state grants favor an approach that is as close as possible to protocols in NHIN Exchange. Two very big EHR vendors put their support squarely behind the simpler approach and two others, while hesitating to add to the polarization in the room, have worked actively behind the scenes to shape the simpler approach to be more palatable to a broader group.
Bar Too Low
It is inaccurate to describe the simpler approach as “mailbox only.” It would be better to describe the approach as “mailbox inclusive” and recognize that the advocates of the simpler approach argue for permitting structured data, passing NHIN Exchange metadata through NHIN Direct without requiring that every participant handle unencrypted personal health information, and includes an approach to dealing across participants that are at different levels in terms of their ability to deal with structured data.
My own recommendation in Simple Interop: The Payload has been to include both human readable and structured data to give receiving systems the most options. This table provides one summary of the alternatives. “Best possible” means that the receiving system uses whatever capabilities it has to interpret the document. “Full XDR” means payloads fully compliant with all relevant NHIN Exchange standards as to metadata and payload. “Not Full XDR” allows for a wider variety of payloads and, perhaps, not the metadata that is required in NHIN Exchange.
I suspect that there is no way to reconcile the two camps on the “Bar Too Low” issue. One side believes that the only thing that prevents chaos is a highly controlled approaches limited to participants who have implemented very specific protocols and operate according to a predetermined model of what health information interchange is. The other side believes that if you create a little bit of enablement that can be rolled out widely the market without the delays inherent in HIE governance will move towards immediate realization of real business value and discovery of easy incremental steps that will constitute disruptive innovation in the best sense of the phrase.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.