DRAFT Final Proposal

ACTUAL FINAL PROPOSAL AT Consensus Proposal

Introduction

The following consensus proposal is an outline for a set of transport specifications intended to enable support for the NHIN Direct User Stories, meet the goals of universal health addressing, and fulfill the Design Principles. These transport specifications will have two parts:

1. A set of specifications based on SMTP providing a common denominator solution encompassing all providers, and intended as a stepping stone to NHIN Exchange
2. A set of specifications based on XDR allowing participants in NHIN Exchange to fulfill the user stories

Endorsement of this document is endorsement of the common consensus principles; detailed specification documents will be produced in parallel with reference implementation development and will have a separate endorsement and consensus round.

Use of the term "NHIN Exchange" in this document means the exchange described as such on the ONC web site.

Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."

Assumptions

This consensus proposal and the resulting specifications to be developed rest on the following assumptions:

1. The sender has fulfilled all legal, regulatory and policy requirements such as consent, authorization, accounting of disclosure, privacy notices, data use restrictions incumbent on the receiver, and the like, prior to initiating transport.
2. The sender and receiver have ensured that agents of the sender and receiver (for example, HIO, HISP, intermediary) are authorized to act as such and are authorized to handle PHI according to law and policy.
3. Sender intends to send to the receiver and has verified and confirmed the accuracy of receiver's address prior to initiating transport.

In addition, the consensus proposal is intended to adhere to the NHIN Direct Project Design Principles.

Security

The consensus proposal will adhere to the Security and Trust Consensus Proposal. Key details are presented in the individual protocol details and in the Security appendix to this document.

As the details are further developed, security layers will be applied using a Risk Assessment methodology in the context of the assumptions and intended use. The goal is to provide a specification that assures interoperability and assures end-to-end protection of the PHI against realistic security threats including unnecessary or unauthorized access. The use of standards-based mechanisms such as X.509, TLS, S/MIME, AES, SHA, XML-Digital-Signatures, and other security standards will be considered to protect against the threats identified in the Risk Assessment.

An initial Threat Model - SMTP with Full Service HISPs is under development and will be completed prior to specification finalization.

Common End-to-End Protocol

HISP-HISP

HISPs MUST support SMTP, as configured and described in this section, as a common transport protocol.

The owner of the Health Internet Domain MUST maintain DNS Mail Exchange (MX) and Certificate (CERT) Resource Records (RRs) for the Health Interent Domain and Health Internet Addresses. Support for DNS maintenance MAY be delegated to the HISP.

Source HISPs MUST be capable of accepting incoming messages with unencrypted payloads from Sources, and securing and transmitting them using the Security Agent model documented in the appendix below, in accordance with the Security and Trust Consensus Proposal. Source HISPs MUST be capable of receiving Source encrypted transactions and delivering them without further transformation (assuming the Source manages content packaging, keys, signing and encryption).

Destination HISPs MUST reject attempted delivery of content that is not packaged in accordance with the security and trust model.

Destination HISPs MUST either verify provenance and trust of the transaction using the Security Agent model, and reject all transactions that fail to verify or deliver to a Destination that has taken responsibility for verification of provenance (e.g., the Destination manages keys and decryption and verification).

Destination HISPs MUST ensure that Message Disposition Notification is sent as appropriate to inform the Source of transaction receipt or error. Destinations MAY send additional MDN (e.g., read receipts sent by ordinary e-mail clients).

Source and Destination Connectivity

Systems MAY combine HISP and Source/Destination capability.

HISPs MAY support end-to-end connectivity based on the e-mail connectivity model.

E-mail connectivity MUST support SMTP client connectivity over a TLS-encrypted channel. E-mail connectivity MUST authenticate client connections and MUST reject unencrypted and/or unauthenticated connections.

E-mail connectivity MUST support POP3 or IMAP4 client connectivity over a TLS-encrypted channel. E-mail connectivity MUST authenticate client connections and MUST reject unencrypted and/or unauthenticated connections.

Destinations MAY reject content that does not meet Destination expectations. For instance, some Destinations MAY require receipt of structured data, MAY support only particular content types, and MAY require receipt of XDM structured attachments.

Content Packaging

Content packaging for SMTP transport MUST support the Content Container Specification. Use of XDM zipped files by Source and Destination is RECOMMENDED.

Add-on Connectivity

Additional specifications will be added to the minimal end-to-end connectivity model. HISPs MUST support the minimal end-to-end model and are encouraged to move towards support of the NHIN Exchange model.

HISP-HISP

HISPs MAY support additional protocols for HISP-HISP transport, but Source HISPs SHALL BE responsible for discovering through mechanisms not defined in this proposal which Destination HISPs mutually support the chosen backbone protocol.

As a bridge to the full NHIN Exchange model, reference implementations intend to support complete end-to-end transactions outside of NHIN Exchange using XDR, including service discovery.

XDR connectivity as part of NHIN Exchange is a special case described below.

The XDR specification will be amended by the NHIN Direct Project to address the lessons learned in Concrete Implementation and the HITSC review findings, in particular to separate addressing metadata from content metadata.

Source and Destination Connectivity

HISPs MAY support additional protocols for Source and Destination connectivity. Reference implementations intended to support REST and SOAP edge connectivity.

NHIN Exchange Connectivity

NOTE: The terms "RECOMMENDED" and "SHOULD" are used in this section because the NHIN Direct Project has no authority to change or mandate use by NHIN Exchange participants.

NHIN Exchange participants sending to other NHIN Exchange participants are RECOMMENDED to use the native Document Submission (IHE XDR SOAP) specification for connectivity and the native UDDI service for service discovery.

NHIN Exchange to Minimal End-to-End Connectivity

NHIN Exchange participants sending to non-NHIN Exchange SHOULD send XDM zipped attachments via the SMTP HISP-HISP protocol and receive messages from non-NHIN Exchange participants via the SMTP HISP-HISP protocol

As with any Destination, NHIN Exchange partipants MAY reject content that does not meet participant expectations.

Source	Destination	Action
NHIN Exchange Participant	NHIN Exchange Participant	XDR end-to-end
NHIN Exchange Participant	Non-NHIN Exchange Participant	SMTP send with XDM zip attachment
Non-NHIN Exchange Participant	NHIN Exchange Participant	SMTP receive, error if content not supported

Appendix

MDN

The Status MDN SHALL be an RFC 3798 Message Disposition Formatted Internet Message Format document.

The following clarifications and changes are applied in the use of RFC 3798 by this document:

disposition-type = "displayed"
                 / "processed"

Note that the production grammar for RFC 3798 removes the processed value from the disposition-type definition, but refers to them in the RFC text.

The disposition-type of processed SHALL be interpreted to mean that the message has been accepted by the Destination HISP but has not been delivered to the Destination.

The disposition-type of displayed SHALL be interpreted to mean that the message has been delivered successfully to the Destination.

The disposition-type of deleted, defined in RFC 3798, is not defined in this specification.

When the disposition-modifier is error, the error-field MUST be provided, and SHOULD provide error text that is formatted according to the error handling rules for the content that was transmitted (for example, HL7 V2 error reporting for HL7 V2 messages).

Security

HISPs MUST only send and receive TLS-encrypted SMTP traffic. TLS encrypted channels MUST support at least server certificates issued by a well-known and accepted Internet Certificate Authority.

HISPs MUST TLS-encrypt Source and Destination connections, and MUST appropriately authenticate such connections. The minimal mechanisms to be supported are defined in the Edge section.

Organizations that perform signing, encryption, decryption and verification activities MUST maintain a list of accepted certificate anchors, and MUST verify inclusion in accepted certificate anchors of senders and receivers. Such lists MUST be capable of being Health Internet Domain specific.

HISP, Source and Destination MUST audit message exchange. The information audited MUST include sufficient detail to satisfy security policy and regulatory obligations, such as message ID, source and destination address, and authentication information, including attempts at unauthenticated or unauthorized transmission. Opaque patient identifiers SHOULD be audited if allowed by policy. Specific recommendations for audit points will be supplied in the final specification.

Security Agent

Messages sent over the SMTP backbone must be encrypted and signed on send, and decrypted and verified on receive, by an implementation of the NHIN Direct Security Agent. Messages sent between HISPs must be signed and encrypted to the S/MIME specification and have the content type application/pkcs7-mime. The clear text source message within this secure envelope may have any content type permitted by the Content Container Specification.
  The security agent ensures that the sending and receiving parties have each been configured to enable exchange between them, and that each end of the exchange can be confident that their messages will travel intact and undisclosed.
  The agent relies on DNS CERT records to distribute public keys. It is the responsibility of the HISP supporting an endpoint to ensure that its corresponding CERT records are publicly available when requested using the name formed by taken the endpoint address and replacing the “@” character with a “.” character.
  The actions taken to package and unpackage a message are described below; some simplifications have been made for clarity in this context. Detailed documentation and reference code can be found in the Google Code projects nhin-d-agent and nhin-d-jagent (these locations may change as the project moves forward; the most current documentation will always be available at the NHIN Direct wiki).
  When we talk about “configured anchors” here, we mean a set of public certificates that have been configured as “trusted” by the endpoint in question. More detail on this concept is found in the Security and Trust Consensus Proposal document on the wiki.
 
 

• Sending A Message
  1. Fetch configured private keys for the endpoint and sign the original message with each.
  2. For each recipient of the message
     1. Fetch the recipients public certificates with DNS
     2. Find the first valid certificate that chains up to a configured anchor. Valid here means standard checks on expiration, etc., and also that the certificate subject matches either the full endpoint address or the domain name part of the address. If no match is found, the message will not be sent to this recipient.
     3. Encrypt the message using the matched public certificate. Note that in order to support multiple recipients, the message is actually encrypted once with a random symmetric key, and then the key is encrypted for each recipient using their public key.
• Receiving A Message
  1. Decrypt the message using a configured private key. If not matching key is found or the message does not decrypt, reject it.
  2. For each valid signature found on the message, determine if the certificate used to sign chains up to a configured anchor. If no matching signature is found, the message will be rejected.

---

OLDER CONTENT FOR REFERENCE

Overview

The NHIN Direct consensus proposal combines key positive aspects of the proposals of all the Implementation Group participants.

HISP-HISP: The proposal requires SMTP as the lowest-common-denominator backbone, while preserving the NHIN Exchange Document Submission backbone for current and future participants in the NHIN Exchange. It also recognizes the value of HISPs mutually agreeing on SOAP, REST, or other backbones, as long as they can fulfill the common functional requirements for the Source and Destination.

Content Packaging: The proposal requires MIME as the lowest-common-denominator content package and recommends the use of full content metadata using the IHE XDM content package. This allows providers with basic technology to participate in information exchange and communicate at transitions in care, while preserving the ability for users of more advanced systems to automate workflow with rich metadata

Source/Destination-HISP Connectivity The proposal allows for variability at the edge to preserve innovation and meet providers both where they are, and where they are going. It allows for:

• Combined Source/Destination and HISP: Supports providers with enterprise EHRs, Software as a Service EHRs, or other systems that combine EHR and directed exchange capabilities.
• SOAP/XDR: Supports providers who use full-featured EHRs or EHR Modules to use the IHE-profiled SOAP web service support built into some EHR systems.
• REST: Supports providers with EHRs or EHR modules that have not implemented a SOAP stack, who wish to take advantage of direct messaging with attachments. 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
• E-mail: Supports providers without EHRs or EHR modules who still wish to participate in information exchange.

Security: The proposal requires the use of S/MIME-encrypted and signed content packages to preserve PHI confidentiality and security, to allow message senders to ensure that only authorized recipients can view the PHI, and to allow message receivers to verify that only authorized senders sent the message. Combined with S/MIME-encrypted and signed Message Disposition Notification, the proposal allows for end-to-end verification of message delivery and receipt. The proposal requires TLS encrypted channels and authentication of all edge systems.

In more detail, we are proposing that:

• The backbone protocol for NHIN Direct 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 NHIN Direct service is immediately available to both large and small providers regardless of practice size and IT budget.
  • In order to minimize the need for 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 convert the unencrypted message into a standard S/MIME message and verify an S/MIME signature as described in the "Security Agent" appendix to this document. If an organization prefers not to sign a Business Associate Agreement (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. NHIN Direct 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 choose which issuing 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 Message Disposition Notification (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 on the decrypted message with the application content type and a well-known attachment name) 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 an MDN error 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 e-mail client, and then move to an EHR module, and then to a full EHR without changing HISP or secure NHIN-Direct 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. Theh goal of this interface is to enable rapid innovation through the addition of new methods as needed.
  • The REST interface may be used to integrate the HISP with existing EHR software (where there is an already-established workflow engine and/or “inbox”)
  • The REST interface may 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 e-mail services.
  • To ensure edge on-the-wire privacy, all clients will be required to use TLS with at least a server certificate to connect to the HISP. Authentication could be username/password and/or client certificates.
  • To minimize the risk of mistaking an existing non-secure e-mail account with the secure NHIN Direct 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 e-mail and a different client for corporate e-mail.
  • Our reference implementation will include instructions to pre-configure e-mail clients to ensure secure communication with a HISP.

The following diagram provides a comprehensive overview of the SMTP and SOAP-based client interfaces and HISP interactions. The REST-based interface would work similarly to the SMTP-based interfaces:



In a pure NHIN Exchange case, the flow shall be XDR end-to-end.

HISP-HISP

HISPs MUST support SMTP as a common protocol.

HISPs MAY support additional protocols for HISP-HISP transport, but Source HISPs SHALL BE responsible for discovering through mechanisms not defined in this proposal which Destination HISPs mutually support the chosen backbone protocol. As a special case of this support, NHIN Exchange participants are RECOMMENDED to use the NHIN Exchange native Document Submission (XDR) and UDDI discovery methods.

The owner of the Health Internet Domain MUST maintain DNS Mail Exchange (MX) Resource Records (RRs) for that address. Support for DNS maintenance MAY be delegated to the HISP.

Source HISPs MUST be capable of receiving incoming unencrypted messages and processing them according to the specifications of the NHIN Direct Security Agent as described in the appendix below. Source HISPs MUST and MUST be capable of receiving already S/MIME-signed and encrypted transactions and delivering them without further transformation (assuming the Source manages content packaging, keys, signing and encryption).

Destination HISPs MUST reject attempted delivery of content that is not signed and encrypted. Destination HISPs MUST reject attempted delivery of messages that are not accepted by the NHIN Direct Security Agent as described in the appendix below. Destination HISPs MAY support delivery of signed and encrypted content to the Destination without further processing (assuming the Destination manages keys and decryption and verification).

Destination HISPs MUST ensure that Message Disposition Notification is sent as appropriate to inform the Source of transaction receipt or error. Destinations MAY send additional MDN (e.g., read receipts sent by ordinary e-mail clients).

Source and Destination Connectivity

Systems MAY combine HISP and Source/Destination capability.

Source HISPs MAY support e-mail, XDR, or REST connectivity.

E-mail connectivity MUST support SMTP client connectivity over a TLS-encrypted channel. E-mail connectivity MUST support authentication using username/password or client certificates. On receipt, the Source HISP SHALL extract content headers and the subject header (if supplied) and apply S/MIME signing and encryption (unless the package is already signed and encrypted). Source HISPs SHALL reject connections on unencrypted channels and unauthenticated transactions.

XDR connectivity MUST support the XDR specification (as modified by this project to place routing information in the header). The Source HISP MUST enforce a TLS- encrypted channel and MUST enforce XUA or client certificates. On receipt, the Source HISP MUST extract the content payload (the MTOM-encoded XDS content package), transform the package to an XDM-zipped file, sign and encrypt, then construct the message/RFC 822 document for delivery to the Destination HISP.

REST connectivity MUST follows the applicable portions of REST Specification. That specification will be modified to provide a standard REST specification to programmatically create documents and metadata to construct a rich content package for delivery.

When packaging small flat sets of documents in a message/RFC 822 document it is RECOMMENDED to use redundant attachments, including the same attachment both as a separate message body part and as a component of the XDM zip file. This allows e-mail receivers to easily access the attachments.

Destination HISPs MAY support e-mail, XDR or REST connectivity.

E-mail connectivity MUST support IMAP4 client connectivity over a TLS-encrypted channel with a username/password or a client certificate (Destination HISPs need not support both as clients and libraries generally support either model equally well).

XDR connectivity MUST support the XDR specification (as modified by this project to place routing information in the header). The Destination MUST enforce a TLS-encrypted channel and MUST enforce client certificates. The Destination MUST transform the content payload to an XDR message. If the content payload is an XDM attachment, the Destination MUST extract the metadata and content parts and create the appropriate XDR message.

REST connectivity MUST follow the applicable portions of REST Specification. That specification will be modified to provide a standard REST specification to provide programmatic access to content and metadata in an XDM content container.

Content

The content container follows the Content Container Specification and RECOMMENDS the use by edge systems of rich metadata (either in the form of an XDR edge connection or the use of XDM zipped files).

The Status MDN SHALL be an RFC 3798 Message Disposition Formatted Internet Message Format document.

The following clarifications and changes are applied in the use of RFC 3798 by this document:

disposition-type = "displayed"
                 / "processed"

Note that the production grammar for RFC 3798 removes the processed value from the disposition-type definition, but refers to them in the RFC text.

The disposition-type of processed SHALL be interpreted to mean that the message has been accepted by the Destination HISP but has not been delivered to the Destination.

The disposition-type of displayed SHALL be interpreted to mean that the message has been delivered successfully to the Destination.

The disposition-type of deleted, defined in RFC 3798, is not defined in this specification.

When the disposition-modifier is error, the error-field MUST be provided, and SHOULD provide error text that is formatted according to the error handling rules for the content that was transmitted (for example, HL7 V2 error reporting for HL7 V2 messages).

Security

HISPs MUST only send and receive TLS-encrypted SMTP traffic. TLS encrypted channels MUST support at least server certificates issued by a well-known and accepted Internet Certificate Authority.

HISPs MUST TLS-encrypt Source and Destination connections, and MUST appropriately authenticate such connections. The minimal mechanisms to be supported are defined in the Edge section.

Organizations that perform signing, encryption, decryption and verification activities MUST maintain a list of accepted certificate anchors, and MUST verify inclusion in accepted certificate anchors of senders and receivers. Such lists MUST be capable of being Health Internet Domain specific.

HISP, Source and Destination MUST audit to allow end-to-end traceability of message exchange. The information audited MUST include message ID, source and destination address, and authentication information. Opaque patient identifiers SHOULD be audited if allowed by policy.

Security Agent

Messages sent over the SMTP backbone must be encrypted and signed on send, and decrypted and verified on receive, by an implementation of the NHIN Direct Security Agent. Messages sent between HISPs must be signed and encrypted to the S/MIME specification and have the content type application/pkcs7-mime. The clear text source message within this secure envelope may have any content type permitted by the Content Container Specification.
  The security agent ensures that the sending and receiving parties have each been configured to enable exchange between them, and that each end of the exchange can be confident that their messages will travel intact and undisclosed.
  The agent relies on DNS CERT records to distribute public keys. It is the responsibility of the HISP supporting an endpoint to ensure that its corresponding CERT records are publicly available when requested using the name formed by taken the endpoint address and replacing the “@” character with a “.” character.
  The actions taken to package and unpackage a message are described below; some simplifications have been made for clarity in this context. Detailed documentation and reference code can be found in the Google Code projects nhin-d-agent and nhin-d-jagent (these locations may change as the project moves forward; the most current documentation will always be available at the NHIN Direct wiki).
  When we talk about “configured anchors” here, we mean a set of public certificates that have been configured as “trusted” by the endpoint in question. More detail on this concept is found in the Security & Trust Consensus Requirements document on the wiki.
 
 

• Sending A Message
  1. Fetch configured private keys for the endpoint and sign the original message with each.
  2. For each recipient of the message
     1. Fetch the recipients public certificates with DNS
     2. Find the first valid certificate that chains up to a configured anchor. Valid here means standard checks on expiration, etc., and also that the certificate subject matches either the full endpoint address or the domain name part of the address. If no match is found, the message will not be sent to this recipient.
     3. Encrypt the message using the matched public certificate. Note that in order to support multiple recipients, the message is actually encrypted once with a random symmetric key, and then the key is encrypted for each recipient using their public key.
• Receiving A Message
  1. Decrypt the message using a configured private key. If not matching key is found or the message does not decrypt, reject it.
  2. For each valid signature found on the message, determine if the certificate used to sign chains up to a configured anchor. If no matching signature is found, the message will be rejected.