NHIN Direct Convergence Proposal
Jump to navigation
Jump to search
This post is from Rich Elmore (Allscripts) and David McCallie (Cerner), with thanks and gratitude to many contributors and reviewers. A special thanks to the Concrete Implementation teams and the HIT Standards Committee review team that paved the way for this proposal.
Following the Direct Project Implementation Group June face-to-face meetings, the following proposal emerged as having a reasonable potential for consensus. The core of the idea is to take the best aspects of each proposal and blend them together to create something that doesn’t have to compromise on any dimension.
The proposed approach is designed to address the following CTQ’s:
- The backbone shall be:
- A pervasive widely-available, universally-addressable, secure and reliable network
- Already proven and in widespread use for this specific purpose (1a)
- “Instantly on” – meaning that the global network can be built out in months, without central planning, using proven infrastructure and deep existing knowledge for this specific application (1a). Wes Rishel has described this as a “socially scalable” deployment architecture.
- The edge protocols shall support:
- Instantly-on integration with EHR’s using the existing IHE XDR standard
- Immediately available infrastructure ready for system-to-system innovations using a RESTful reference implementation
- Bootstrapping for non-EMR users by providing basic access using standard email clients (POP/IMAP)
- A payload neutral content model shall meet entry-level providers where they are, but can scale up to the levels of metadata that are currently required by integrated health care settings and will be required by all providers to drive efficient and high quality workflows.
In more detail, we are proposing that:
- The backbone protocol for the Direct Project would be SMTP carrying S/MIME signed and encrypted messages. This approach will allow us to leverage existing software, infrastructure and business models to ensure that the Direct Project is immediately available to both large and small providers regardless of practice size and IT budget.
- In order to minimize the need to have end-users managing PKI certificates, we have designed and coded a transparent way for an organization and/or its users to delegate certificate management to a trusted HISP. The HISP will then transparently use DNS to locate and apply the user’s certificate (or the organization’s certificate) to convert the unencrypted message into a standard S/MIME message and verify an S/MIME signature. If an organization prefers not to sign a BAA with their HISP and prefers to manage certificates themselves, security can be performed within the organization. If the sender is unwilling to outsource encryption to the HISP, then the sender will have to perform any necessary XDM packaging (and encryption) before uploading the message to the HISP. Direct Project-supplied libraries could be invoked locally to perform the XDM wrapping.
- The use of organization or user level certificates also allows our approach to manage “multiple circles of trust,” as required by the Privacy & Security principles because each organization may independently chose which certificate authorities to accept, and which to reject.
- HISP-HISP conversations will be additionally encrypted using standard TLS using server certificates only (no client certificates) issued by an accepted Internet CA. This will guarantee a secure channel to protect the routing metadata while messages are being sent between trusted entities.
- Error and status messages will be returned as messages using the MDN content type.
- An integrated XDR interface/gateway will be developed that can translate messages to and from XDR for out-of-the-box integration with existing XDR implementations. The system will adopt XDM as the recognized mechanism to encode content metadata for transmission across the backbone (as an attachment with the application/xdm+zip content type) and will use XDR as the protocol to interface with existing XD* applications. See the figure below for a schematic. (Note: we use the term “metadata” here to refer to content-associated metadata, not the routing information used to send the message.)
- We recommend that clients create metadata attachments whenever possible. As a general rule of thumb, the sender is recommended to create as “rich” a metadata package as possible. The receiver should use as much received metadata as possible, and will be expected to send a “bounce” message back to the sender if the message cannot be processed, or the metadata does not meet the receiver’s standards.
- A key goal here is to provide a “bootstrapping” pathway that lets clients move from “no metadata” to full metadata without having to change messaging platforms. A provider should be able to start out with a simple an email client, and then move to an EHR module, and then to a full EHR without changing HISP or secure Direct Project addresses.
- Our approach follows the same content standards as are used by XDR with the design criteria to avoid changes to the EHRs. It would also follow and leverage the “step up” and “step down” gateway code created by the SOAP team. It would follow any new profiling standards from IHE that would guide the proper use of “minimal” content metadata for those clients who cannot generate full metadata.
- The REST reference implementation will be specifically tuned to ease creation of the metadata package transparently.
- A reference implementation of a simple REST interface will be exposed to the edge to support a more familiar integration approach for developers comfortable in that environment. This interface will also enable rapid innovation through the addition of new methods as needed.
- The REST interface can readily be used to integrate the HISP with existing EHR software (where there is an already-established workflow engine and/or “inbox”)
- The REST interface can be used to create novel integration points, such as web-based portals, for secure message-handling. We propose to create a reference implementation of a simple web-based portal, as part of the pilot deliverables.
- A basic client interface will be provided by exposure of standard POP/IMAP email services.
- To ensure edge on-the-wire privacy, all clients will be required to use TLS with a server certificate only to connect to the HISP. Authentication could be username/password and/or client certificates.
- To minimize the risk of mistaking a non-secure e-mail account with the secure e-mail account, we recommend (but don't require) that clients use a separate e-mail instance to connect to their HISP, where this is technically supported by the client, rather than managing two accounts from one e-mail client. This would be similar to using one client for personal email and a different client for corporate email.
- Our reference implementation will include instructions to pre-configure e-mail clients to ensure secure communication with a HISP.
Together, a reference implementation built to support this proposal is able to expose all three of XDR, REST and SMTP/POP3/IMAP as peer interfaces to edge clients. It will provide immediate utility for providers with limited IT capability, maximize the acquisition and exchange of content metadata, and provide a surface for rapid innovation.
Appendix - Sending / Receiving
