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:
- A set of specifications based on SMTP providing a common denominator solution encompassing all providers, and intended as a stepping stone to NHIN Exchange
- A set of specifications based on XDR allowing participants in NHIN Exchange to fulfill the user stories
In addition, we expect early implementations to provide combination SMTP and modified-XDR HISPs with service discovery to enable native XDR end-to-end transport. To meet policy requirements, XDR will need to be modified to separate address metadata from content metadata.
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:
- 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
- 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.
- Sender intends to send to the receiver and has verified and confirmed the accuracy of receiver's address prior to initiating transport
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 risk assessment threat model 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 Internet Domain and Health Internet Addresses. Support for DNS maintenance MAY be delegated to the HISP.
Source HISPs MAY be capable of accepting (over TLS encrypted channels) incoming messages with unencrypted payloads from Sources, and securing and transmitting them using the Security Agent algorithm documented in the appendix below, in accordance with the Security and Trust Consensus Proposal. Source HISPs which are not capable of performing content payload signing and encrypting MUST reject unencrypted payloads. 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 algorithm, 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 (MDN) 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 for Source to Source-HISP 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 for Destination to Destination-HISP 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 (or Source+Source HISP combinations) 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 and bridging from email packaging to XDR packaging. Such bridging will support EHRs that connect to the HISP via XDR and exchange transactions with partners who send and receive via SMTP.
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 intend to support REST and XDR (with step up and step down capabilities) 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 have the capability to send XDM zipped attachments via the SMTP HISP-HISP protocol and receive messages from non-NHIN Exchange participants via the SMTP HISP-HISP protocol and SHOULD send/receive via the best known backbone (e.g., XDR), defaulting to SMTP if no other supported backbone is known.
As with any Destination, NHIN Exchange partipants MAY reject content that does not meet participant expectations.
| Source |
Destination |
Action |
| NHIN Exchange Partipant |
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 Algorithm
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 algorithm. 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 algorithm 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 algorithm 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 taking 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 implementing the algorithm 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
- Fetch configured private keys for the endpoint and sign the original message with each.
- For each recipient of the message
- Fetch the recipients public certificates with DNS
- 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.
- 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
- Decrypt the message using a configured private key. If no matching key is found or the message does not decrypt, reject it.
- 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.
Call for Consensus for Consensus Proposal