HIT Standards CommitteeHIT Standards CommitteeTechnical Review of The Direct Technical Review of The Direct ProjectProject

Dixie Baker

December 17, 2010

Review Team

• Dixie Baker (Team Lead)

• Carol Diamond

• David McCallie

• John Moehrke

• Cris Ross

• Walter Suarez

Review Objective

• To assess the extent to which the NHIN Direct Project’s* body of existing documentation meets the ONC's goal of defining a "set of policies, standards and services that enable simple, direct, scalable transport over the Internet to be used for secure and meaningful exchange between known participants in support of meaningful use" – Simple means responsive to the Implementation WG's guidelines driven

by ease of implementation, concern for the "little guy," and recognition of the fact that the development community is broad and "unspecialized"

– Direct means transport of content from a sender to a receiver, with no content-aware intermediary services

– Scalable means ability to support increasing workload and to adapt to new exchange models

– Secure means minimizing confidentiality, integrity, and availability risk to the content being transported

*Note that the “NHIN Direct Project” has been renamed “The Direct Project.” However, for consistency with the language used in the artifacts examined, we will use the term “NHIN Direct” in this presentation.

Approach

1. Reviewed key documents to assess degree to which they described a transport that was simple, direct, secure, and scalable– Design Principles– Consensus Proposal

• Outlines transport specifications for SMTP-based exchange and for using XDR for exchanges with NHIN Exchange participants

– Core Specification– Specification for using XDR and XDM for direct messaging– Security and Trust Consensus Proposal

2. Overall assessment

3. Reached consensus

Simplicity (1 of 2)

• Is it simple? Yes No Undetermined– Core specification document is “messy” – would be difficult to

develop against– Too much optionality– “Suggests” use of Domain Name Service (DNS) to discover and

distribute digital certificates -- which has never been used for this purpose, and may duplicate capabilities available from other services (e.g., GSA USAccess for federal agencies)

– Requires the sender to know the technical capabilities of the receiver (e.g., Transport Layer Security is optional; allows destination to reject content object, without constraining criteria for rejection)

Simplicity (2 of 2)

• Recommendation: Make it simple – SMTP transport of S/MIME-secured content objects between entities– Clean up the core specification– Remove optionality – Remove necessity of sender to know the capabilities of the

receiver – Remove TLS and S/MIME wrapping from the core specification

as options for protecting against information leakage (see Security recommendations)

– Don’t require DNS as the only mechanism for certificate discovery and distribution; recommend a standard for certificate discovery and distribution

Direct Exchange

• Is it direct? Yes No Undetermined– Allows receiver to reject content that does not meet expectations

– without constraining the reasons for rejection

• Recommendation: Make it direct– Keep the NHIN Direct scope as intended – secure exchange of

content objects from organization A to organization B– Keep content-agnostic

• Sender should be able to send, and receiver should be able to accept, a variety of unstructured, semi-structured, and structured content

– Content standards are generally controlled by national requirements such as HIPAA, Meaningful Use, and others

• Default is human-readable content package

Scalability

• Is it scalable? Yes No Undetermined– Scalable for the purposes for which it was designed

• Recommendation: Clarify intended purpose and usage– Not well suited for workflows involving high-transactional-

volume, point-to-point exchanges that require mechanisms to deal with complex discovery, addressing, and routing issues

• We consider these workflow issues outside the control of basic NHIN Direct technology

– Local policy may limit bandwidth requirements of attachments (e.g., large images) – again, outside the control of basic NHIN Direct technology

Security (1 of 2)

• Is it secure? Yes No Undetermined– By default, NHIN Direct uses S/MIME and X.509 digital

certificates to secure content end-to-end• S/MIME verifies the identity of sender and receiver, and encrypts

and integrity-protects message content

• Some risk of data leakage through header fields (to/from, subject) – manageable through policy and guidance

– Core specification contains ambiguous requirements regarding the use of TLS and full message wrapping to protect against data-leakage, creating confusion and complexity

• “SHOULD” provide capability to use mutually authenticated Transport Layer Security (TLS) for all communications

• Full message wrapping is “RECOMMENDED” and “OPTIONAL” – but warns that some receivers “may present such messages in ways that are confusing to end users“

Security (2 of 2)

• Recommendation: Specify S/MIME as standard for securing NHIN Direct content end-to-end– Remove TLS and message wrapping as security options in core

specification – consider as potential security enhancements to be addressed in future implementation specifications

– Address residual risk through policy direction regarding suitable content for subject fields

Observed Discontinuity (1 of 2)

• Team noted a discontinuity between NHIN Direct’s intended scope and the exchange model presented in the XDR/XDM specification

• Team recognizes that a need exists for an on/off-ramp capability to facilitate exchanges between small providers and NHIN Exchange participants – How end-points are implemented to address this need is a

deployment issue and is inappropriate to include in the core NHIN Direct specification

– Appropriate to include in implementation specification to increase efficiency of content processing for exchanges with organizations who have implemented IHE profiles

Observed Discontinuity (2 of 2)

• Including XDR/XDM as part of the NHIN Direct Project core specification creates concerns with respect to 3 of our 4 criteria– Increases complexity – No longer “direct” exchange– Security is undeterminable

• Although preliminary work to separate routing and content metadata has been done, not yet accepted by IHE – and is likely to remain an “option” and not part of the core XDR specification

• Security considerations have not been addressed pending completion of the risk assessment (which is pending completion of the metadata work)

• Recommend removing XDR/XDM from the NHIN Direct core specification

Overarching Recommendation

• Support Postel’s Law: “Be conservative in what you send; be liberal in what you receive” (a.k.a. Robustness Principle)– Enable senders to send the minimum information necessary,

with high confidence of the identity of the receiver and with end-to-end security protection

– Enable receivers to receive a content object without constraints on the format or coding of the information contained therein, other than assurance of its provinence and safety

– Optionality among Standards should be limited, but services should have maximum flexibility (Fridsma’s corollary)

• Recommend that the HITSC adopt both Postel’s Law and Fridsma’s corollary as principles in the development of standards moving forward