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.

[See also: VA, DoD to make imminent 3M Health Data Dictionary part of iEHR.]

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.

[See also: Comments for the meaningful use stage 2 NPRM commenters: Specificty matters.]

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.