Security and Trust Consensus Proposal
0. Intent
NHIN Direct implementations will, when deployed in conjunction with externally-defined policies, enable the secure exchange of PHI-containing messages between authorized participants.
In the same way that clinicians currently do not assume that it is safe to fax PHI to anyone with a fax number, or mail PHI to anyone with a post office address, NHIN Direct users will not assume that it is safe to send messages to any NHIN Direct address. NHIN Direct users will need to establish real-world trust relationships with other NHIN Direct users on their own terms, but once they have established this real-world trust, they can be sure that an NHIN Direct network will securely deliver NHIN Direct messages to the trusted NHIN Direct user.
Any NHIN Direct user will need to establish policies and standards for deciding which other NHIN Direct addresses to trust, in much the same way that clinicians currently decide which numbers or addresses they are willing to fax or mail PHI to. As much as possible, the design of the NHIN Direct secure network will not force NHIN Direct users to adopt trust policies they might otherwise have rejected, or reject trust policies they might otherwise have adopted. However, in order to build a secure network for the transmission of PHI, NHIN Direct must select which protocols and technologies that NHIN Direct Implementers will use to build a secure network for NHIN Direct users. In some cases, those protocols and technologies will come with specific configuration options that will have policy implications. These security protocol and technology configuration options will present constraints that NHIN Direct will force on the trust policies of its users.
These security protocols and technologies will determine what "language" that given policies must speak. Most notably the decision to use the IETF X.509 standards for a PKI-based infrastructure will force NHIN Direct users to create trust policies that speak in terms of certificates, public key infrastructure and certificate authorities. Other protocol and technology decisions will have similar policy language implications.
All of this is to enable the NHIN Direct implementations to provide a simple security feature:
if two NHIN Direct users trust each other in the real world, and can mutually agree on standards and policies for handling PHI, they will be able to configure an NHIN Direct implementation to securely send messages containing PHI between them.
1. Purpose
1.1. "Message handling policy" can be thought of similarly to the policies of a delivery agent like Federal Express that assures its employees won’t open and read your packages, they will not leave them at the bus station, and they will take care that they are delivered to the person on the address label.
1.2. This workgroup is defining the functional requirements of an NHIN Direct protocol that will support the message handling policy recommendations of the HIT Policy Committee and regulatory mandates of ONC. Because these policies have not been finalized at this time, and because they are certain to evolve in the future, the workgroup is attempting to define those protocol requirements in a way that provides appropriate flexibility and “future-proofing,” balanced against the requirement of simplicity critical to ensure real-world adoption.
1.3. We also foresee that the HIT Policy Committee and ONC will not be in a position to define a single message handling policy acceptable to every constituent expected to participate in NHIN Direct messaging networks. For example, state law may already add additional requirements for providers in their jurisdiction, or some individual providers may have their own legitimate preferences. Therefore our requirements will include the ability for participants to configure the system to define their exchange partners, at varying levels of granularity as described later.
1.4. It is important to review these requirements in the context of the specific goals of NHIN Direct, which include an important policy simplification: the sender of a message is responsible for ensuring that any disclosure is appropriate and complies with all regulatory and PHI policy obligations before sending the message. Our recommendations exist solely to enable a technical environment in which participants can make these disclosures in a way that satisfies their message handling obligations. That is to simply say, messages go where they are meant to, are not altered during transmission, and are not seen by those they are not intended for.
2. Protocol Requirements
2.1 Use of x.509 Certificates. The NHIN Direct protocol relies on agreement that possession of the private key of an x.509 certificate with a particular subject assures compliance of the bearer with a set of arbitrary policies as defined by the issuing authority of the certificate. For example, Verisign assures that bearers of their "extended validation" certificates have been validated according to their official "Certification Practice Statement." Certificates can be used in many ways, but NHIN Direct relies on the embedded subject and issuing chain as indicated in the following points. Specific implementations may choose to go beyond these basic requirements.
2.2 Certificate Anchor Configuration. Implementations must allow configuration of one or more public certificates representing "anchors" that implement agreed-to message handing policies. Implementations should allow anchors for sending messages to be distinct from those for receiving messages.
2.3 Certificate Granularity. Implementations should allow these configurations to be unique per-address in addition to per-health-domain. This will ease integration for participants with an existing PKI infrastructure, and provides a path to more fine-grained assurance for future use cases. Implementations must be able to accept messages identified per-address or per-health-domain per 2.5.
2.4 Revocation. When possible, implementations must frequently check the validity of configured or cached certificates through standard means. The definition of "frequently" should be defined by external policy.
2.5 Sender identification. NHIN Direct messages must be reliably linked to the public certificates possessed by the sender, through standard digital signatures or other means that match the certificate subject to the sender's address or health domain. Implementations must reject messages that are not linked to valid, non-expired, non-revoked public certificates inheriting up to a configured Anchor certificate per 2.2.
2.6 Encryption. NHIN Direct messages sent over unsecured channels must be protected by standard encryption techniques using key material from the recipient's valid, non-expired, non-revoked public certificate inheriting up to a configured Anchor certificate per 2.2. Normally this will mean symmetric encryption with key exchange encrypted with PKI. Implementations must also be able to ensure that source and destination endpoint addresses used for routing purposes are not disclosed in transit.
2.7 Ease of use. Implementations should attempt to ease the complexity of certificate management for end users and organizations. While this is not a hard protocol requirement, it is important to be aware that many systems leveraging certificate technology have failed to achieve adoption due to complexity of PKI management, so efforts here will be a key driver of success or failure for NHIN Direct. If possible implementations should enable NHIN Direct users to think in terms of "who do I trust" rather than "what certificates to I import". Implementations should also ensure that users can leverage existing credential management programs; for example, ICAM in the federal space (see related links).
2.8 Integrity. NHIN Direct messages must be protected using standard hashing techniques acceptable in current regulation.
3. Implications for Policymakers
3.1. The workgroup has attempted to, as much as possible, decouple specific policies from technology. It is our hope that the NHIN Direct protocols can be used in many policy environments in addition to that defined by the HIT Policy Committee and ONC. For example, a foreign government might choose to deploy NHIN Direct implementations, but require participants to adhere to their own unique policies.
3.2. This goal is facilitated by using possession of x.509 certificate artifacts to "proxy" for policy adherence. In this model, a policy-enforcing body is responsible for issuing certificates only to those they have confirmed can and will adhere to their requirements. These requirements may be virtually anything. A few examples: undergo an annual HIPAA compliance audit, use biometric authentication for system login, have a valid license to practice medicine in one of the 50 states, and so on.
3.3. We have also tried to ensure that a particular NHIN Direct participant can use a single NHIN Direct implementation to exchange messages with distinct policy-defined groups. For example, a provider in the Northwest may want to use their NHIN Direct "address" to communicate both with US and Canadian colleagues, even though the US and Canadian authorities have different policy requirements. If that provider satisfies both sets of requirements, and if it is legal for them to do so, they should be able to exchange messages with providers in both countries. They would represent this in NHIN Direct by possessing two certificates --- one issued by the US policy-enforcing body, and one issued by the Canadians.
3.4. All this notwithstanding, we expect the HIT Policy Committee and ONC to issue guidance for a base level of policy that will enable participating trust anchors to include the broadest-possible set of US-based providers and patients. The more inclusive the anchors, the more likely it is for any two participants to have the ability to exchange messages. This is critical work.
3.5. Of particular interest for policy committees will be what level of "identity assurance" is required for authentication of participants logging into NHIN Direct messaging systems. It is important to note that this decision is external to the NHIN Direct protocols described here, but extensive work has been done in the Federal ICAM trust framework and the private-sector Kantara Initiative; these are important initiatives for the committee to understand.
3.6. We do not presume to say what policies are the right ones to achieve the right tradeoff between policy protection and breadth of participation. Private organizations are currently making local policy decisions in accordance with existing law, and at a national level that is for ONC to specify with the advice of the HIT Policy Committee in the spirit of the initial NHIN Workgroup recommendations. Rather, our intent is to ensure that whatever those outcomes may be, they can be instantiated easily and quickly using NHIN Direct protocols.
Related Links
- NHIN Direct
- HIT Policy Committee
- Kantara Initiative
- ICAM Trust Framework
- Verisign Extended Validation Certification Practice Statement
- IETF Public-Key Infrastructure Working Group (PKIX)
- IHE-ITI Technical Framework
- NEMA White Paper on Management of Machine Authentication Certificates
Version 3.4 Workgroup Call for Consensus:
Here's hoping this is our last vote on this!
Please do not vote NO without specifying in the "Notes" column what would be required for you to move to YES. If you have been participating in workgroup discussions and do not see your organization listed, please feel free to add it.
| Organization |
Agree |
Notes |
| Allscripts |
||
| Axolotl |
||
| CareSpark/Anakam (HIE Tech) |
||
| Cautious Patient |
Yes |
|
| Cerner |
||
| Clinical Groupware Collaborative |
YES |
|
| CSC |
||
| Epic |
||
| GE |
YES |
This is good enough to move to the next phase. In the next phase many little details will need to be cleaned up . |
| Healthcare Information Xchange of NY |
YES |
|
| HLN Consulting |
||
| MedAllies |
||
| Medicity |
YES |
|
| Microsoft |
YES |
|
| Mirth Corporation |
YES |
|
| Misys Open Source Solutions |
YES |
|
| Oracle Health Sciences Global Strategies |
||
| RelayHealth |
YES |
|
| Siemens |
YES |
|
| Social Security Administration |
||
| SureScripts |
||
| VA |
YES |
|
| VisionShare |
YES |
Version 3.2 Workgroup Call for Consensus:
This vote is now closed
| Organization |
Agree |
Notes |
| Allscripts |
||
| Axolotl |
yes |
|
| CareSpark/Anakam (HIE Tech) |
YES |
(per email) |
| Cautious Patient |
||
| Cerner |
YES |
|
| Clinical Groupware Collaborative |
||
| CSC |
YES |
(per email) |
| Epic |
||
| GE |
YES |
|
| Healthcare Information Xchange of NY |
||
| HLN Consulting |
||
| MedAllies |
||
| Medicity |
||
| Microsoft |
YES |
|
| Mirth Corporation |
||
| Misys Open Source Solutions |
YES |
|
| Oracle Health Sciences Global Strategies |
YES |
|
| RelayHealth |
YES |
|
| Siemens |
||
| Social Security Administration |
||
| SureScripts |
||
| VA |
YES |
|
| VisionShare |
YES |
Version 3.1 Workgroup Call for Consensus:
This vote is now closed
| Organization |
Agree |
Notes |
| Allscripts |
||
| Axolotl |
yes |
|
| CareSpark/Anakam (HIE Tech) |
||
| Cautious Patient |
Yes ;) |
|
| Cerner |
YES |
|
| Clinical Groupware Collaborative |
||
| CSC |
||
| Epic |
||
| GE |
||
| Healthcare Information Xchange of NY |
||
| HLN Consulting |
||
| MedAllies |
||
| Medicity |
||
| Microsoft |
YES |
|
| Mirth Corporation |
||
| Misys Open Source Solutions |
||
| Oracle Health Sciences Global Strategies |
YES |
|
| RelayHealth |
NO |
Section 2.3 indicates that implementors MUST accept self signed certificates. In order to change this to a YES vote, that wording should be changed from MUST to MAY/SHOULD accept. (note from Fred... please read this and reply there what exactly is needed to change your vote) |
| Siemens |
||
| Social Security Administration |
||
| SureScripts |
||
| VA |
NO |
Provide clarification of 2.3. Change “must allow” to “may allow” . Nothing in these requirements should require NHIN participants to implement mechanisms or accept credentials in violation of their own or jurisdictional policy. |
| VisionShare |
YES |