NwHIN Power Team Recommendations

HIT Standards CommitteeHIT Standards CommitteeNwHIN Power TeamNwHIN Power TeamFinal RecommendationsFinal Recommendations

September 28, 2011September 28, 2011

Dixie Baker, Chair

• Dixie Baker (SAIC)

• Tim Cromwell (VA)• John Feikema (Ability)• Ollie Gray (DOD)• Kevin Hutchinson (Prematics)• David McCallie (Cerner)• Nancy Orvis (DOD)• Wes Rishel (Gartner)• Cris Ross (SureScripts)• Ken Tarkoff (Relay Health)

Supported by Avinash Shanbhag (ONC)

NwHIN Power Team

• The ONC has defined the Nationwide Health Information Network (NwHIN) as “the set of standards, services and policies that enable secure health information exchange over the Internet”

• The NwHIN Power Team was tasked to assist the ONC in defining this set of standards, services, and policies by:1. Evaluating the specifications developed for the Exchange and Direct

pilots with respect to their usability and scalability to support nationwide health information exchange

2. Recommending those specifications that could be integrated and deployed to support the secure transport and exchange of electronic health information at a national scale, and identifying where further work may be needed

• Outputs from this work are intended to help inform ONC decisions regarding future investments in additional NwHIN pilots and specification development

NwHIN Power Team Context and Tasking

• The focus of this work is at the national level – we did not address the use of these specifications within enterprises or among partners within a regional health information exchange, or for community use

• The Power Team evaluated each Exchange and Direct specification independently against a number of defined criteria

• No “comparison” or “selection” between the specification sets for Exchange and Direct is implied – we recognize that each of these specification sets was designed for a different use case and to fulfill different needs

NwHIN Power Team Scope

• Exchange Specifications (available from http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__nhin_inventory/1486)

– NHIN Messaging Platform Specification

– NHIN Web Services Registry Specification

– NHIN Authorization Framework Specification

– NHIN Patient Discovery Specification

– NHIN Query for Documents Specification

– NHIN Retrieve Documents Specification

– NHIN Access Consent Policies Specification

– NHIN Health Information Event Messaging (HIEM) Specification

– NHIN Document Submission Specification

– NHIN Administrative Distribution Specification

• Direct Specifications (available from http://wiki.directproject.org/Documentation+Library)

– Applicability Statement for Secure Health Transport – XDR and XDM for Direct Messaging

Specifications Included in This Analysis

http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__nhin_inventory/1486

http://wiki.directproject.org/Documentation+Library

1. Evaluate specifications generated by Exchange and Direct pilots on the following factors (defined in the Glossary at the end of this presentation):

– Need for specified capability– Maturity of the specification– Maturity of the underlying technology used in the specification– Deployment and Operational Complexity– Industry adoption– Availability of alternatives

Scores recommended by the ONC, with inputs from the NwHIN Exchange Coordinating Committee and the National Institute of Standards and Technology (NIST), with review inputs from the NwHIN Power Team

2. Identify specifications that provide capabilities for which the business need is “Low”

3. Identify specifications that are in early or moderate stages of development, and that use technologies in the declining phase of their life-cycle

Methodology (1 of 2)

4. Identify specifications that introduce significant deployment, operational, and administrative complexity, and that have low industry adoption

5. Consider availability of alternatives – Sources used

• NwHIN Power Team identification of standards and solutions that have been broadly adopted by healthcare, other than the Exchange and Direct specifications

• Other industry standards

– In considering suitability of alternatives, use the same criteria as those used for Exchange and Direct specifications

6. Subjectively assess whether any gaps remain that may be addressed with new specifications

7. Formulate recommendations for consideration by the HIT Standards Committee

Methodology (2 of 2)

Scores – Exchange Specifications (1 of 2)

Specification Need Maturity of Spec

Maturity of Underlying Technology

Deployment, Operational, and Administrative

Complexity

Industry Adoption

Alternatives

NHIN Messaging Platform Specification

High High Mature Moderate (Mature tools available to deploy and manage the services)

Low REST style; Direct Secure Transport

NHIN Web Services Registry Specification

Moderate/ High

Moderate Declining High Low LDAP Provider Directories; DNS look-up for certificates (Direct)

NHIN Authorization Framework Specification

High Moderate/High Mature High (Complexity is primarily a reflection of ensuring security)

Low OAuth 2.0 OpenID for SOAP Authentication Framework; TLS over REST

NHIN Patient Discovery Specification

High (high need, spec has problems)

High Mature High Low PCAST model

NHIN Query for Documents Specification

Moderate High Mature Moderate/High Low REST style

Scores – Exchange Specifications (2 of 2)




Complexity

Industry Adoption

Alternatives

NHIN Retrieve Documents Specification

Moderate High Mature Moderate Low REST style

NHIN Access Consent Policies Specification

Low Low Emerging High Low Metadata Power Team recommendation (HL7 CDA R2 with HL7, LOINC, and new vocab)

NHIN Health Information Event Management (HIEM) Specification

Low Moderate Mature Not enough knowledge

Low

NHIN Document Submission Specification

Moderate High Maturing Low Low REST style

NHIN Administrative Distribution Specification

Moderate Moderate Maturing Low Low REST style or other push solution

Scores – Direct Specifications




Complexity

Industry Adoption

Alternatives

Applicability Statement for Secure Health Transport

High High Mature Moderate/High (mainly due to encryption, certificate mgmt)

Low SOAP Transport, REST style

XDR & XDM for Direct Messaging

High High Mature Moderate Low Direct to email inbox

• NeedSubjective judgment (low, moderate, high) from ONC, focused on whether the specification is needed for meaningful-use, federal agencies, or to meet other national needs, plus review inputs from Power Team. Factors considered include:

– Lacks specific, compelling needs (low)– Needed for meaningful use (moderate-high, considering other 3 factors)– Federal agency need – Other National HIT needs, etc.

Evaluation Criterion: Need

• NHIN Access Consent Policies Specification• NHIN Health Information Event Management (HIEM)

Specification

Specifications for Which Business Need is “Low”

• Maturity of SpecificationSubjective assessment (low, moderate, high) from survey conducted by NwHIN Exchange Coordinating Committee, plus ONC and NIST inputs, plus review inputs from Power Team. Factors considered include:

– Specification still in development (low)– Clear and unambiguous (moderate) – Testable (moderate-high)– Maintainable (moderate-high)– Fully tested and piloted (high)

• Maturity of Underlying TechnologySubjective assessment (emerging, maturing, mature, declining) of the maturity of the technologies used in the specification, with respect to the complete technology life-cycle; plus review inputs from Power Team. Factors considered include:

– New unproven standard, building industry support (emerging)– Gaining market adoption, but less than 30% industry adoption (maturing)– Mainstream adoption (mature)– Declining support (declining)

Evaluation Criteria: Maturity of Specification x Maturity of Underlying Technology

Maturity of Specification x Maturity of Underlying Technology

Technology Maturity

Emerging Maturing Declining

Low

Mod

High

Mature

• NHIN Messaging Platform Specification• NHIN Patient Discovery Specification• NHIN Query for Documents Specification• NHIN Retrieve Documents Specification• Applicability Statement for Secure Health Transport• XDR & XDM for Direct Messaging

• NHIN Web Services Registry Specification

• NHIN Authorization Framework Specification

• NHIN Administrative Distribution Specification

• NHIN Document Submission Specification

• Deployment, Operational, and Administrative ComplexitySubjective assessment (low, moderate, high) that considers ease of implementation, maintenance throughout on-going operations, and administrative complexity across organizations.

– Can be handled with ease by IT support (Low)– Need a modest administrative support for deployment and maintenance over time

(Moderate)– Need a substantial on-going IT investment to support the service (High) – Introduces administrative complexity that spans organizations; requires high degree of

federation; project complexity (High)

• Industry AdoptionAssessed (low, moderate, high) relative to the market segment for which the specification was developed. Initial scores were derived from responses to objective questions on Exchange usage. Scores were reviewed by the Power Team, who concluded that since neither the Exchange specifications nor the Direct specifications had been broadly deployed beyond the ONC pilots, all should be judged “low.” Factors considered include:

– Currently deployed as production offering by “x” number / percentage of vendors – Significant volume potential (e.g. within 12 months; full deployment, etc.)

Evaluation Criteria: Deployment, Operational, and Administrative Complexity x Industry Adoption

Deployment, Operational, and Administrative Complexity x Industry Adoption

Industry Adoption

Low Mod High

High

Mod

Low

• NHIN Messaging Platform Specification• NHIN Retrieve Documents Specification• Applicability Statement for Secure Health Transport• XDR & XDM for Direct Messaging

• NHIN Authorization Framework Specification• NHIN Patient Discovery Specification• NHIN Web Services Registry Specification

• NHIN Administrative Distribution Specification• NHIN Document Submission Specification

• NHIN Query for Documents Specification

Conclusions and Recommendations

1. Architecture is important. The set of standards, services, and policies that comprise the Nationwide Health Information Network (NwHIN) must be deployable within an architectural framework capable of supporting the secure exchange of health information at a national scale.

– Standards, services, and policies need to address transport, security, and clinical content, including standards for clinical documents and controlled vocabulary. Structured clinical documents and controlled vocabulary should be equally valuable regardless of the NwHIN secure transport used; and any NwHIN secure transport should support the full range of health information exchange, from unstructured (and perhaps incomplete) data to structured, coded data.


2. Neither the Exchange specifications nor the Direct specifications have been proven at large scale, in production environments, across a broad range of healthcare organizations. The scalability of the underlying architectures, and inherent impacts on workflow, need to be better understood. Once these specifications have been deployed at much larger scale, across a broader spectrum of healthcare users, they should be re-assessed against the criteria used in this exercise to determine suitability as a nationwide standard.


3. The Exchange specifications are highly complex, and designed to support a complex architecture that may not be appropriate for all healthcare organizations, and that may not scale to nationwide deployment

– “Too many layers ... debugging is very hard due to the complexity of the layered approach ... all layered protocols have this problem, but this is the most complex we have encountered” (implementer testimony)

– Version skew among “layered protocols” (externally specified) makes it hard to manage widespread deployments

– NHIN Query for Documents Specification poses operational challenges • No agreed-upon way to query for specific item, such as “most recent ECG,” which

forces download of large chunks of the patient's record from multiple sites• Does not handle images well (largely due to under-constrained specifications on how

to handle extremely large files)• HITSP C32 (Continuity of Care Document) definitions are not precise enough to allow

for seamless importing of external data elements– NHIN Retrieve Documents Specification’s method of accumulating query results

may cause long delays, huge messages, and frequent time-outs– NHIN Patient Discovery Specification is at risk of being a “show stopper” for

nationwide health information exchange – due to serious policy issues that drive an architecture that performs poorly, disrupts provider workflow, and poses a “serious challenge to scalability beyond a limited pilot”


4. The results from this study present opportunities for simplification– Two specifications address needs judged “low” in our analysis

• NHIN Access Consent Policies Specification

• NHIN Health Information Event Management (HIEM) Specification

– NHIN Web Services Registry Specification – a moderately mature specification that uses technology in its declining phase of the life-cycle [Note: The Standards and Interoperability Framework team is already considering alternatives to this specification]

– NHIN Authorization Framework Specification – highly complex, and alternatives exist (e.g., OAuth)

– NHIN Patient Discovery Specification (highly complex, highly needed) and NHIN Query for Documents Specification (operational and workflow challenges)

• Need more scalable architecture to support patient discovery

• Because the Query for Documents, Patient Discovery, and Retrieve Documents specifications are usually implemented together, any alternatives should be considered within this context


5. Although the Direct specifications have been in pilot usage for only a short time (starting January this year) and have not been widely deployed beyond the pilot, the underlying transport standard (SMTP) is well-understood, widely deployed, and proven highly scalable, and the security standard (S/MIME) fulfills the EHR certification requirement for an “encrypted and integrity protected link” (45 CFR 170.210(a)(2)). The Direct specifications do introduce some new approaches that have yet to be fully developed and proven beyond the Direct Project itself, particularly around the validation and use of organization-level digital certificates and the use of DNS for certificate discovery. Given current ONC initiatives to address these risks, and recognizing the potential benefit of having a simple, easily implemented solution for exchanging EHR data within the framework of existing standards and certification criteria, we would support and encourage broader deployment and use of the Direct specifications.


6. Some areas are underspecified in the current specification set– Exchange or remote viewing of large images– Discovery and retrieval of data elements (e.g., lab results) outside a “document”

context– More granular query capability for patient records (e.g., “most recent ECG”)


Addressing these needs may present opportunities to consider the PCAST model for data discovery using indexed metadata, combined with retrieval of the desired data element or object (e.g., image) – a model that may be more scalable for patient-discovery as well.

7. Industry is trending toward widespread use of the REST architectural style in designing networked systems – this presents an opportunity to develop new specification for RESTful exchange of healthcare information

– REST is not a “standard,” but a “style” that uses the HTTP standard communication protocol to provide a simpler alternative to SOAP for accessing web services – not all “RESTful” implementations are implemented in the same way

– REST is not inherently secure, but can be secured using standards such as Transport Layer Security (TLS) and Open Authorization (OAuth)

– Developing specification(s) for “secure RESTful transport for healthcare exchange” would provide healthcare organizations assurance that RESTful implementations built in accordance with the specification(s) would be predictable and secured


Glossary

Term Definition

Direct Specifications Two (2) specification documents developed and implemented by participants in the Direct pilot; available from http://wiki.directproject.org/Documentation+Library

Applicability Statement for Secure Health Transport

Describes how to use SMTP, S/MIME and X.509 certificates to securely transport health information over the internet. Standards used include (but not limited to): SMTP, MIME, S/MIME, X.509.

XDR and XDM for Direct Messaging

Describes the use of XDR and XDM zipped packages in email in the context of directed messaging for Direct Project•XDR supports a direct push model from sender to receiver using Web Services transport•XDM supports a direct push model of a package of content where one of several optional transports is via SMTP

Evaluation Criteria Criteria that the NwHIN Power Team and its ONC support used to evaluate the Exchange and Direct specifications.

Deployment, Operational, and Administrative Complexity

Subjective assessment (low, moderate, high) that considers ease of implementation, maintenance throughout on-going operations, and administrative complexity across organizations. •Can be handled with ease by IT support (Low)•Need a modest administrative support for deployment and maintenance over time (Moderate)•Need a substantial on-going IT investment to support the service (High) •Introduces administrative complexity that spans organizations; requires high degree of federation; project complexity (High)

Glossary

Term Definition

Evaluation Criteria (cont.)

Industry Adoption Assessed (low, moderate, high) relative to the market segment for which the specification was developed. Initial scores were derived from responses to objective questions on Exchange usage. Scores were reviewed by the Power Team, who concluded that since neither the Exchange specifications nor the Direct specifications had been broadly deployed beyond the ONC pilots, all should be judged “low.” Factors considered include:•Currently deployed as production offering by “x” number / percentage of vendors •Significant volume potential (e.g. within 12 months; full deployment, etc.)

Maturity of Specification

Subjective assessment (low, moderate, high) from survey conducted by NwHIN Exchange Coordinating Committee, plus ONC and NIST inputs, plus review inputs from Power Team. Factors considered include:•Specification still in development (low)•Clear and unambiguous (moderate) •Testable (moderate-high)•Maintainable (moderate-high)•Fully tested and piloted (high)


Subjective assessment (emerging, maturing, mature, declining) of the maturity of the technologies used in the specification, with respect to the complete technology life-cycle; plus review inputs from Power Team. Factors considered include:•New unproven standard, building industry support (emerging)•Gaining market adoption, but less than 30% industry adoption (maturing)•Mainstream adoption (mature)•Declining support (declining)

Glossary

Term Definition

Evaluation Criteria (cont.)

Need Subjective judgment (low, moderate, high) from ONC, focused on whether the specification is needed for meaningful-use, federal agencies, or to meet other national needs, plus review inputs from Power Team. Factors considered include:•Lacks specific, compelling needs (low)•Needed for meaningful use (moderate-high, considering other 3 factors) •Federal agency need •Other National HIT needs, etc.

Exchange Specifications Ten (10) specification documents implemented by participants in the Exchange pilot; available from http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__nhin_inventory/1486

NHIN Access Consent Policies Specification

Describes the content and format of access content policies covering the electronic exchange of health information between nodes and also describes how access consent policies may be exchanged among nodes. Standards used include (but not limited to): HITSP TP-20, HITSP TP-30, HITSP C80, XACML, XSPA Profile of XACML.

NHIN Administrative Distribution Specification

Describes specification to provide the ability to submit non-patient specific data including document based reports or discrete data from one node to another node using a “Push” mechanism. Standards used include (but not limited to): HITSP T63, OASIS EDXL.

NHIN Authorization Framework Specification

Describes the security and privacy foundations for every SOAP message in Exchange. It defines the exchange of metadata used to characterize the initiator of an Nationwide Health Information Network request so that it may be evaluated by responding node in local authorization decisions. Standards used include (but not limited to): XSPA Profile of SAML 2.0, WS-Security, X.509, TLS.

Glossary

Term Definition

Exchange Specifications (cont.)

NHIN Document Submission Specification

Defines specification that allows an initiating Exchange node to send one or more documents for a given patient to a receiving node. Unlike Query/Retrieve and Pub/Sub, this specification does not require a prior request to retrieve a document or to subscribe to content and is categorized as a “push” transaction. Standards used include (but not limited to): IHE XDR TI, HITSP C80, MTOM SOAP Message Transmission Optimization Mechanism.

NHIN Health Information Event Messaging (HIEM) Specification

Describes specification which allows a node to request to subscribe or unsubscribe to various classes of content and events, and to notify node when content or events matching a subscription have been created or modified. Standards used include (but not limited to): OASIS WS-BaseNotification, WS-Topics.

NHIN Messaging Platform Specification

Describes the common web service protocols that must underlie every message transmitted via SOAP protocol. They represent common transport layer for all messages in Exchange. Standards used include (but not limited to): WS-I Basic Profile 2.0, SOAP 1.2, WS-*, XML Schema.

NHIN Patient Discovery Specification

Defines the specification by which one Nationwide Health Information Network Node can query another to determine if it is a source of information for a specific patient. Standards used include (but not limited to): IHE XCPD.

NHIN Query for Documents Specification

Defines a query from one Exchange node to another, requesting a list of available patient specific documents meeting query parameters for later retrieval. Standards used include (but not limited to): IHE XCA TI, HITSP TP13, HITSP C80.

Glossary

Term Definition

Exchange Specifications (cont.)

NHIN Retrieve Documents Specification

Defines specification which allows an initiating Exchange node to retrieve one or more documents for a specific patient from a responding node. The document Ids are typically (by not necessarily) obtained using Query specification. Standards used include (but not limited to): IHE XCA TI, HITSP TP13, HITSP C80.

NHIN Web Services Registry Specification

Describes the specification that allows nodes on the Nationwide Health Information Network to locate and utilize the appropriate services offered by other nodes in a controlled, secure manner. Standards used include (but not limited to): OASIS UDDI.

IHE Integrating the Healthcare Enterprise, an initiative by healthcare professionals and industry to improve the way computer systems in healthcare share information

Nationwide Health Information Network (NwHIN)

The set of standards, services and policies that enable secure health information exchange over the Internet (ONC definition); for purposes of this evaluation, “NwHIN” refers to a collective set of specifications including NHIN Exchange, Direct, and other specifications to be defined in the future, including RESTful approaches

PCAST President’s Council of Advisors on Science and Technology (PCAST) report to the President, “Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward,” published December 2010

REST REpresentational State Transfer – a style of system design that uses the Hypertext Transfer Protocol (HTTP) standard for communication, providing a simpler alternative to SOAP for accessing web services

Glossary

Term Definition

SMTP Simple Mail Transfer Protocol, the widely adopted Internet standard protocol for sending email messages between servers

S/MIME Secure/Multipurpose Internet Mail Extensions, an Internet standard for securing email messages

SMTP Simple Mail Transfer Protocol, the widely adopted Internet standard protocol for sending email messages between servers

SOAP Simple Object Access Protocol – an XML-based protocol for exchanging information in a decentralized, distributed environment

Health & Medicine

NwHIN Power Team Recommendations