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.
Because SMTP store and forward infrastructure can only do the push transaction, it is a limited platform standard and a technical dead-end in trying to address other transaction needs. The functions it can support fall short of where many people, including the President’s Council of Advisors on Science and Technology (PCAST), believe health information exchange transactions need to go. The meaningful use of EHRs, Accountable Care Organizations, medical homes and a true U.S. health system all seem to need more. Their functional needs do not stop with the data that one provider anticipates another provider will need. Nor do they stop with the assumption that providers will reliably initiate a store and forward SMTP transaction to move the right data to all that need them.
The many transactions in exchange
HIE functions include unanticipated needs, unanticipated providers, reliable data access from unreliable senders, accumulation of data into longitudinal and population records, accessing registries and data for decision support, accumulating quality reporting data, querying to get more data when needed, a raft of directory services, and with team care, the shared management of care plans, problem lists and other data. SMTP infrastructure does not now support these needs and does not provide a path going forward to do so.
The Web services-based NwHIN Exchange specifications demonstrate how a broader platform standard than SMTP can implement a variety of data transactions like push, pull and publish-subscribe. Exchange also includes transactions that look-up someone in a provider directory, determine what services that provider can support, find a patient's data and retrieve those data when an appropriate authorization is in place. Either Web services or REST could also support other transactions such as those needed to manage team data across the component organizations of an ACO. SMTP infrastructure really cannot.
One argument for SMTP has been that it is more accessible to small providers. In practice, implementations to date have involved more complexity than predicted and point to a frequent, if not omnipresent, reliance on an outside organization – a Health Information Service Provider (HISP) to carry the technical load. If a HISP is necessary, a more robust platform standard like Web services or REST would seem to be just as achievable as SMTP.
Some have suggested that SMTP can be a stepping stone on the way to a fuller transaction suite and that the other transactions can be implemented later on other standards. But with the specific implications of SMTP for associated infrastructure like EHRs, certificate providers, and ancillary systems, resistance to other standards will increase with time and investment in the SMTP approach.
Moving forward in Stage 2
Transactions are very important to EHR outcomes. And ONC has a very tough job ahead to really get HIE and supporting transactions moving forward in a way that fulfills the many needs. In this context, it is hard to recommend negative comments - even about SMTP and store-and-forward messaging.
Most constructively, however, Stage 2 commenters may want to identify the need to do more than SMTP can accomplish. They may also want to suggest an accelerated, more public effort to describe a path to a broader transaction standard that can be a true platform building block.