Why Stage 2 MU transactions need more than SMTP
Health IT is at a critical juncture with the technical NPRM for Stage 2 of Meaningful Use (MU). There have always been questions about whether enough standards, implementation guidance, and policies would be expressed ahead of the huge HITECH EHR investment in order to leverage an interoperable health IT infrastructure for health reform needs. But now, in addition to the tiered schedule for meeting MU requirements, the deadlines for Stages 2 and 3 have been further extended. As a result, Stage 2 standards and certification requirements will be the only technical requirements some EHRs are held to as late as 2019.
Numerous CMS programs will tweak the related quality measures in an ongoing fashion, but MU is the only place with any focus on the technical tools to actually help manage the quality of care. And while many Stage 2 commenters will focus on those voluminous quality measures, threshold changes, and MU timing complexities, there are core technical building blocks that may be more important for the success of health IT than any of the measure specifics.
More than Transport
One very critical building block is sometimes described as "transport". It really is much more than just data transport alone. The issue is about the transaction technology that will be used to connect the now loosely associated providers, hospitals, health departments, ancillary health services, and other involved organizations into an electronic "health system" – or not.
[Commentary: Inside the MU Stage 2 NPRM: 'A difficult balance'.]
Data and messaging standards are also very important building blocks for specific health functions, but transaction technology is necessary as a platform to undergird them all.
SMTP, the standard of the “store and forward” email infrastructure, is suggested in the Stage 2 NPRM as the transaction technology to connect all EHRs for the purpose of health information exchange and interoperability. Web services are also listed as an "option," but only SMTP is required. By most accounts, politics backed ONC into the SMTP decision. Reportedly, on the committee that was working the issue, many wanted Web services and many wanted RESTful services. These camps helped cancel each other out and a small but powerful contingent that wanted SMTP won the day.
More than SMTP
In SMTP “store and forward” a message is initiated, sent, queued, and eventually received by (hopefully) those to whom it was addressed. One concern is that the store part of this SMTP exchange pattern introduces new security concerns even with encrypted data. But an even more challenging aspect of SMTP infrastructure is that push – data exchange initiated by the party with whom those data already reside – is the only transaction it can support.
To be clear, ONC has prioritized push, or directed health information exchange, from one provider to another, as their initial focus. But even prioritizing push does not necessitate SMTP. The push that is ONC’s Direct protocol can also be implemented on REST or on Web services, as is the push in the NwHIN Exchange specifications. Unfortunately, SMTP is where the committee ended up and the comments on Stage 2 look like one of the first and last opportunities to address this SMTP conclusion.