This post is hopefully going to sum up a good deal of what is taken for granted within the Direct Project implementation group membership, but causes confusion outside.
It touches a bit on John Halamka's latest post and on the feedback from the HITSC Privacy and Security Workgroup on XDR.
I started the work on the Direct Project with my neighborhood in mind. In the SF Bay Area, there are a large set of HIOs that share information within clinical networks, but there are also large numbers of real-world clinical transactions that cross clinical networks on an hourly basis. The combination of Universal Addressing and Universal Transport was a powerful idea that could help coordinate transitions of care across organizational boundaries.
Each of those clinical networks, however, use proprietary mechanisms for information sharing within the network. Is it the goal of the Direct Project to replace those networks?
The definition of "Direct Project Compliant" that we have been using (at least informally) in the project is pretty simple: a participant can send and receive from any other participant with a Direct Address, given a common trust fabric. That does not mean that the "last mile" connection necessarily needs to be SMTP + S/MIME. It may mean that there is an XDS or XDR or a proprietary connection to an HIO, and the HIO has a Direct gateway that allows for sending and receiving from other Direct Project Compliant users. It may also mean that two HIOs mutually agree to use XDR or REST or another protocol to bridge between them. The semantics of the directed message, however, need to be preserved (this is what the sometimes misunderstood specification on using XDR and XDM for Direct messaging is all about: specifying a well-defined mechanism to bridge between SMTP + S/MIME and XDR while preserving directed messaging semantics).
For a provider or hospital that already has the capability and the trust fabric to share laboratory, discharge, referral, and consult information robustly across organizational boundaries, and is creating the capability to improve quality and health outcomes in both a patient-centered and population-centered way, and does so with SOAP or REST transport (such as the example John Halamka provided of NEHEN), there is no interest in the Direct Project to replace those mechanisms of transport with S/MIME and SMPT.
That being said, there will, over time, be a benefit for using Direct Project specifications for the last mile. It will often be easier to connect EHRs that have built-in support for Direct Project specifications, and have built-in workflow for receiving structured data over that transport, particularly if, as John Halamka notes, the HITSC recommends that support for Direct Project specifications and common X.509 certificates become a certification criterion.
If this seems familiar, it parallels the evolution of the common e-mail network. In the beginning, e-mail was fragmented into proprietary networks (e.g., AOL, Compuserve). Over time, those proprietary networks added SMTP gateways so their members could send and receive from other e-mail users. Those gateways did not replace the existing transports for sending and receiving from other Compuserve or AOL members, and even now Blackberry users receive encrypted content over HTTP connections and a GMail user sending to a GMail user will use a different transport mechanism from a GMail user sending to a Hotmail user. However, the SMTP standard allows any device to plug into any standard network, and any e-mail user can send and receive from any other e-mail user. Seems like a good pattern for health information exchange.