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