ONC’s Direct Project: In Defense of Simplicity

Over the past year or so, I’ve been deeply involved in various Federal gov’t health IT initiatives, including the Direct Project and Query Health. This is first time, I believe, that the public (private sector “outsiders”) has had access to the inner-workings of the Office of the National Coordinator for Health Information Technology (ONC). While I’ve been delighted with this new level of transparency, I’ve been dismayed by the way the process tends to transform simple ideas and sensible goals—aimed at improving care quality and efficiency—into overwhelmingly complex, convoluted and costly technical specifications and requirements!

One of the reasons for situation is that people often “come to the table” with preconceived notions of what is possible and how do it. These narrow/closed mindsets are either unaware or prone to reject  technologies that provide simple inexpensive solutions through the “novel combinations of existing off-the-shelf components, applied cleverly to a small, fledgling value network”) in favor of conventional technologies (commodities) that lack those positive qualities. Following is just one example.

A few months ago, Dr. John Loonsk (CMO of CGI Federal) wrote a widely cited article at this link in which he criticizes the Direct Project’s reliance on SMTP (Simple Mail Transfer Protocol)—the simple method for transporting e-mail messages that’s been widely used since the early 1980s. His criticism is based on the fact that SMTP uses a “store and forward” process in which messages are stored locally (in the user's computer) and then sent to the recipient. He claims that SMTP is insufficient and thus should be augmented by types of Web Services, such as SOAP or RESTful methods, which tend to be considerably more complex than SMTP.

In his critique, Dr. Loonsk takes a “closed inside-the-box” view of SMTP-based e-mail. Following are my responses to his key issues. In contrast to his narrow conventional point of view, my replies take an “open outside-the-box” perspective of SMTP’s capabilities that incorporates a novel publish/subscribe (pub/sub) node-to-node desktop architecture (see this link for technical details).

Issue 1: Dr. Loonsk wrote that “the store part of SMTP…introduces new security concerns even with encrypted data.”

My reply: Since when is the encryption of stored files not enough? These days, it is free and easy to encrypt not only individual files, but even entire hard drives (or partitions) can be protected with bit-locker encryption. With this kind encryption of stored files, along with encryption of e-mail in transit (e.g., using PKI), Protected Health Information (PHI) is protected end-to-end (in transit and at rest), which is about as secure as you can get!

In contrast, the Web Services approach can leave PHI exposed at the web server, e.g., when Web Services provide the in-transit encryption and when they transform the PHI format as it passes between disparate EHRs. With the SMTP pub/sub node-to-node architecture, on the other hand, all encryption and PHI transformations are done by the sender prior to transporting the e-mail.

One more thing about XML security: Encryption vulnerabilities. According to an interesting (and technical) blog post by a cryptographic engineer, encrypting XML securely requires extra steps to prevent a "ciphertext" attack that exposes the encrypted XML content. The author concludes: "If your system is online and doesn't have a solid, well-analyzed protection against them, don't pretend that you're doing anything at all to secure your data. I wish I had a funny, pithy way to sum this all up. But honestly, I'm just a little depressed."

Issue 2: Dr. Loonsk wrote that “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…a true U.S. health system all seem to need more [which does] not stop with the data that one provider anticipates another provider will need…[nor] with the assumption that providers will reliably initiate a store and forward SMTP transaction to move the right data to all that need them.”

My reply: The SMTP pub/sub node-to-node architecture actually enables both “pull” transactions whereby the request for the transmission of information is initiated by the receiver, as well as “push” whereby the request for a given transaction is initiated by the sender. To perform a pull transaction, the party who wants to receive the PHI (1^st party) e-mails a request for it to the party with whom the PHI resides (2^nd party). Upon receipt of the request, the 2^nd party responds by sending the requested PHI to the 1^st party. Either or both parties can do his manually or have it done programmatically (automatically) by the software. This simple solution resolves the SMTP push-pull issue. Nevertheless, as reported by ONC in 2009, push messaging is crucial because it is "...less complex and will be far more readily available to a broader range of providers than so-called 'pull' technologies.

Issue 3: Dr. Loonsk wrote that, unlike Web Services and REST, the SMTP infrastructure does not support HIE functions such as “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.”

My reply: The SMTP pub/sub node-to-node architecture actually does support these functions and we’ve demonstrated such capabilities with our software tools using SMTP.

Issue 4: Dr. Loonsk wrote that “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…[rely] 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.”

My reply: Unlike Web services or REST, the SMTP pub/sub node-to-node architecture I’ve been describing does NOT rely on a HISP since the desktop e-mail client (MS Outlook in our case) carries the technical load, not the HISP. To comply with the Direct Project requirements, however, we use a HISP for PKI certificate management and provider registries, but the actual e-mails pass right through the HISP from senders (publisher) to their recipients (subscribers).

In conclusion, the view of Dr. Loonsk and many others fail to realize how breakthrough innovations, like our novel SMTP architecture and apps, can accomplish what seems impossible to folks focused conventional technology. Though no doubt well-intentioned arguments by intelligent people, their criticisms do not provide good reason for denigrating the simple, sensible, survivable solution SMTP provides.