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

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 –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 –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

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 SpecNeedSpec Maturity Technology Maturity Deployment/ Operational Complexity Industry Adoption Alternatives Exchange Messaging Platform (SOAP) High MatureModerate (Mature Tools available to deploy and manage the services) Moderate/ High Yes; REST pattern; Direct Secure Transport Exchange Authorization Framework HighModerate/ High MatureHigh (Complexity is primarily a reflection of ensuring security) Moderate/ High Direct secure transport (SMTP, S/MIME) High MatureModerate/High (Mainly due to encryption, certificate mgt) Moderate/ High XDR and XDM for Direct Messaging High MaturingModerate 9

Preliminary Results – Discovery Specs SpecNeedSpec Maturity Technology Maturity Deployment/ Operational Complexity Industry Adoption Alternatives Web Service Registry Moderate/ High ModerateDecliningModerateLowProvider Directories; DNS Look-up for certificates (Direct) Exchange Patient discovery ModerateHighMatureModerate No Exchange Query ModerateHighMatureModerate Yes; REST pattern 10

Preliminary Results – Content Exchange Specs SpecNeedSpec Maturity Technology Maturity Deployment/ Operational Complexity Industry Adoption Alternatives Exchange Document Submission Moderate MaturingLow to ModerateLowYes; REST pattern Exchange Administrative Distribution Moderate Maturing Low Yes; REST pattern or other push solution Exchange Retrieve ModerateHighMatureModerate Yes; REST pattern Exchange Access Consent Policies* Low MaturingModerateLow Health Information Event Management (HIEM) LowModerateDecliningNot enough knowledge LowNo * 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 Document Submission Administrative Distribution Spec Maturity 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 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 Deployment/Operational Complexity Industry Adoption LowModHigh Mod Low XDR and XDM for Direct Patient Discovery Query Retrieve 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 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