This document is currently up for Implementation Group Consensus.

Overview


This document is intended for organizations and individuals wishing to participate in directed exchange using Direct Project specifications. Such organizations often ask if the solution (Electronic Health Record system, Health Information Exchange technology, personally controlled health record, etc.) they are using or considering is "Direct Project compliant."

At the most definitional level, Direct Project compliance is defined by the Applicability Statement for Secure Health Transport, which defines a core set of requirements for using SMTP, S/MIME and X.509 certificates in an interoperable way.

Much enabling technology will, however, use other standards (such as Integrating the Heathcare Enterprise's Cross-Enterprise Document Reliable Interchange standard) or proprietary mechanisms within a local community. Is such technology "Direct Project compliant?" The situation is very similar to other network technologies. For instance, in telephony, a local network may use cellular technologies, IP telephony (VOIP), Skype, or "traditional" landline service. A caller knows, however, that regardless of the underlying technology used, he is using telephony if he can dial anumber and reach the intended party, and he can be reached in the same manner.

Similarly, when evaluating enabling technology, the simplest test to demonstrate Direct Project compliance is that the technology enables, for the users or other endpoints served by the technology, Direct Project-compliant transmission to and from other Direct Project-compliant addresses.

Technology Details


Enabling Technology


Local networks will generally have a Direct Project-compliant enabling technology that implements the Applicability Statement for Secure Health Transport specification. That gateway will serve to harmonize local means of addressing, packaging and transport with the Direct Project-compliant equivalents.

An example of a well-defined enabling technology specification is the XDR and XDM for Direct Messaging specification, which defines a solution for implementations using IHE XDR for local transport.

When evaluating enabling technology, it is important to look both at technical conformance to the Applicability Statement for Secure Health Transport and at the level of integration and workflow provided by the enabling technology.

Examples


The following are non-normative examples of technology that enables Direct Project specification-based information exchange:

  • An e-mail client that supports SMTP and S/MIME natively in ways that conform to the Applicability Statement for Secure Health Transport
  • An EHR client that supports compliant SMTP and S/MIME for inbound and outbound transport
  • A personally controlled health record (PCHR/PHR) with a web-based messaging function that allows records to be associated with a Direct Address and that has a compliant gateway allowing the messaging function to send and receive via Direct Project-compliant means
  • An EHR that supports XDR and has a gateway that supports the XDR and XDM for Direct Messaging specification
  • An Immunization Information System supporting PHIN-MS that has a gateway mapping PHIN-MS to Direct Project-compliant means
  • An HIE platform that supports a custom addressing and transport mechanism to EHRs and has a Direct Project-compliant gateway mapping the custom addressing and transport mechanism to Direct Project-compliant equivalents.