The question is how SMTP as the preferred transport mechanism reconciles with the EHR certification criterion (in the IFR) that requires certified EHRs to use either SOAP or REST for HIE (i.e., §170.202 Transport standards for exchanging electronic health information).
Just sign me “Puzzled in Peoria”
Dear P in P,
First, let’s be clear. I speak for no-one. What I am saying hear does not cite an official position of the ONC, it is not a consensus position of the NHINDirect org, and so on. I speak as an individual who is a self-avowed cheerleader for NHIN Direct.
The certification requirements do not limit healthcare organizations to using the standards on which software is certified. They really only say that if a healthcare delivery org buys or builds software and wants to get incentive money for meaningful use the software has to be capable of using the standard (i.e., pass certification tests).
For example, MU requires a provider to get 50% of the lab results in structured form. An HDO could meet the requirement by sending CDs by courier and still qualify for the MU incentive money, as long as they uses software that could have accepted data according to the certification requirements were it asked. Certainly all the people that currently receive data through sources that do customized links to their EHRs are not going to have to re-implement their interfaces in order to get MU incentive money.
Part of the positioning of NHIN Direct is that it is metaphorically a “try before you buy” opportunity. ONC is facilitating activities that produce specifications they might choose later. The “buy” would happen, for example, if a stage 2 certification rule were to incorporate the actual specs developed by NHIN Direct. The “try” is what happens when NHINDirect participants put the interfaces in place and actually begin to use it. If the “try” shows rapid uptake, the “buy” is more likely to happen.
It is also important to keep in mind that NHIN Direct is not directly comparable to existing standards that are certified. It is designed to encompass cases of “clinician to clinician” (rather than “clinician’s EHR to clinician’s EHR” over email and “physician to patient” (via PHR). It is also designed to require less elaborate governance and less complex technology because it sidesteps many of the consent issues that encumber HIEs.
(signed) Abigail van Bureaucrat
The convergence proposal accepts SOAP and REST at the edge as inputs from the EHR, so the convergence proposal is completely consistent with the IFR as written.
(signed) Halamka from the Hub
Dear H from H,
OMG! How cool. Wish I’d thought of that.
BFF Ab van B’rat
Revised 26 June 2010
Read Complimentary Relevant Research
Predicts 2017: Artificial Intelligence
Artificial intelligence is changing the way in which organizations innovate and communicate their processes, products and services. Practical...
View Relevant Webinars
The IoT In Manufacturing Operations: Where Are We Now?
The Internet of Things (IoT) is a paradigm shift for manufacturing operations. Its fanfare creates uncertainty in state-of-the-art technology...
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.