HIT Standards Committee NwHIN Power Team Preliminary Results Dixie Baker, Chair August 17, 2011 1.

HIT Standards CommitteeHIT Standards CommitteeNwHIN Power TeamNwHIN Power TeamPreliminary ResultsPreliminary Results

Dixie Baker, Chair

August 17, 2011

1

• 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 ONC Standards and Interoperability Framework team (Avinash Shanbhag)

NwHIN Power Team

2

• Using the NwHIN Exchange and Direct Project specifications as primary inputs, recommend a modular set of transport, security, and content components (“building blocks”) that can be selectively combined and integrated to enable the trusted exchange of content in support of the meaningful use of electronic health record (EHR) technology

• Present recommendations to HITSC:– Preliminary recommendations at August 2011 meeting

– Final recommendations at September 2011 meeting

Reminder of NwHIN Power Team Charge

3

• NwHIN 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 Project Specifications (available from http://wiki.directproject.org/Documentation+Library)

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

Specifications Included

4

1. Evaluate existing Exchange and Direct specs with respect to the functions provided, and eliminate those that provide functions with a “Low” Need

2. Identify those specifications that are in early or moderate stages of development, and the technologies used are in a declining phase of their life-cycle – Since the “Need” still exists, consider alternatives for these specifications

Selection Process

5

Selection Process

3. Evaluate the remaining specs on Deployment/Operational Complexity and Industry Adoption

– Recommend as “building blocks” those specifications that have moderate-low complexity and moderate-high industry adoption (judged against the industry segment for which the specification was designed)

– Recommend alternatives for those specifications that are judged highly complex to deploy and operate, and whose industry-adoption is low

– Consider remaining specs within context of need and architectural compatibility with other building blocks, and decide on case-by-case basis whether to recommend as building block or to recommend alternative

6

• Deployment/Operational Complexity (low, moderate, high) considers both ease of implementation and maintenance throughout on-going operations – 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)

• Industry Adoption (low, moderate, high) is assessed relative to the market segment for which the specification was developed

(A Word About These Two Criteria)

7

4. Consider alternatives – Sources

• NwHIN Power Team identification of non-NwHIN/Direct specifications that have been broadly adopted by healthcare

• Other industry standards

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

5. Subjectively assess whether any gaps remain for which we should recommend that specifications be developed

Selection Process (cont.)

8

Preliminary Results – Secure Transport Specs

Spec Need Spec Maturity

Technology Maturity

Deployment/ Operational Complexity

Industry Adoption

Alternatives

Exchange Messaging Platform (SOAP)

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

Moderate/High

Yes; REST pattern; Direct Secure Transport

Exchange Authorization Framework

High Moderate/ High

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

Moderate/High

Direct secure transport (SMTP, S/MIME)

High High Mature Moderate/High (Mainly due to encryption, certificate mgt)

Moderate/High

XDR and XDM for Direct Messaging

High High Maturing Moderate Moderate

9

Preliminary Results – Discovery Specs

Spec Need Spec Maturity

Technology Maturity

Deployment/ Operational Complexity

Industry Adoption

Alternatives

Web Service Registry

Moderate/High

Moderate Declining Moderate Low Provider Directories; DNS Look-up for certificates (Direct)

Exchange Patient discovery

Moderate High Mature Moderate Moderate No

Exchange Query

Moderate High Mature Moderate Moderate Yes; REST pattern

10

Preliminary Results – Content Exchange Specs

* This specification describes the content and format of access consent policies associated with content exchanged between entities using Exchange Query and Retrieve.

11

1. Eliminate from further consideration those specifications for which the need is “Low”– Exchange Access Consent Policies– Health Information Event Management (HIEM)

1. Disqualify Low-Need Specs

12

2. Identify those specifications that are in early or moderate stages of development, and the technologies used are in a declining phase of their life-cycle – Since the “Need” still exists, consider alternatives for these specifications

2. Immature Specs x Technology Life-Cycle

13

Specification Grid: Spec Maturity x Technology Life-Cycle Maturity

• Document Submission•Administrative Distribution

Technology Maturity

Emerging Maturing Declining

Low

Mod

High

Mature

• XDR and XDM for Direct Messaging

• Messaging Platform• Direct Secure Transport (SMTP,

S/MIME)• Patient Discovery• Query• Retrieve

• Web Service Registry

• Authorization Framework

(consider alternatives)

14

3. Evaluate the remaining specs on Deployment/Operational Complexity and Industry Adoption

– Recommend as “building blocks” those specifications that have moderate-low complexity and moderate-high industry adoption (judged against the industry segment for which the specification was designed)

– Recommend alternatives for those specifications that are judged highly complex to deploy and operate, and whose industry-adoption is low

– Consider remaining specs within context of need and architectural compatibility with other building blocks, and decide on case-by-case basis whether to recommend as building block or to recommend alternative

3. Deployment/Operational Complexity x Industry Adoption

15

Specification Grid: Deployment/Operational Complexity x Industry Adoption

Industry Adoption

Low Mod High

High

Mod

Low

• XDR and XDM for Direct• Patient Discovery• Query• Retrieve

• Authorization Framework

• Administrative Distribution

• Direct Secure Transport (SMTP, S/MIME)

• Messaging Platform

• Document Submission

• esMD (unknown deployment/operational complexity)

(consider alternatives)

(recommend as building

blocks)

(individually assess)

16

• Recommend as building blocks– Exchange-Based Architecture

• Exchange Messaging Platform

• Exchange Patient Discovery

• Exchange Query

• Exchange Retrieve

– Direct-Based Architecture• Direct Secure Transport (SMTP, S/MIME)

– Building Block for bridging from Direct-based architecture to Exchange-based architecture

• Direct XDR/XDM

• Consider alternatives for– Web Service Registry (S&I Framework already considering

alternatives to this specification)

Preliminary Results (1 of 2)

standardly implemented and used together

17

• Consider remaining specs within context of need and architectural compatibility with other building blocks, and decide on case-by-case basis whether to recommend as building block or to recommend alternative– Authorization Framework (high need, Exchange architecture)– Administrative Distribution (moderate need, Exchange

architecture)– Document Submission (moderate need, Exchange architecture)

Preliminary Results (2 of 2)

18

• Exchange Query, Discovery, and Retrieve specs are standardly implemented and used as a package – should the three be combined into a single building block?

• Initially considered recently published CMS esMD specification – but concluded that it was an application of the Exchange specifications and not a core Exchange specification– Team recommends consideration of additional transport building blocks

in this specification  

Notes

19

• Decide whether to recommend as building blocks or suggest alternatives for:– Authorization Framework– Administrative Distribution– Document Submission

• Recommend alternatives for Web Services Registry and any of the above, as applicable

• Subjectively assess gaps• Present final recommendations at September HITSC

meeting

Next Steps

20

Glossary Attachment

Glossary - Attachment

21

• Exchange Messaging Platform: – 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.

• Exchange Authorization Framework:– 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.

• Web Services Registry:– 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.

Glossary

22

• Exchange Patient Discovery: – 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.

• Exchange Query:– 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.

• Exchange Retrieve:– 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.

Glossary Cont.

23

• Exchange Document Submission: – 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.

• Exchange Administrative Distribution:– 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.

Glossary Cont.

24

• Exchange Access Consent Policies: – 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.

• Health Information Event Management:– 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.

Glossary Cont.

25

• esMD: – Describes specification on how to format medical documentation payloads for submission to

CMS gateway. Standards used include (but not limited to): HITSP C62 CDA, NHIN Exchange Document Submission .

• Direct Secure 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:– Describes the use of XDR and XDM zipped packages in email in the context of directed

messaging for Direct Project. Standards used include (but not limited to): IHE XDR, IHE XDM, XDS Metadata Model.

Glossary Cont.

26