HIT Standards Committee NwHIN Power Team Preliminary Results

1. HIT Standards CommitteeNwHIN Power TeamPreliminary Results Dixie Baker, Chair August 17, 2011 1

2. 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

3. 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

4. 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

5. Evaluate existing Exchange and Direct specs with respect to the functions provided, and eliminate those that provide functions with a “Low” Need 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

6. Selection Process 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

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

8. 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 Subjectively assess whether any gaps remain for which we should recommend that specifications be developed Selection Process (cont.) 8

9. Preliminary Results – Secure Transport Specs 9

10. Preliminary Results – Discovery Specs 10

11. 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

12. 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

13. 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

14. Specification Grid: Spec Maturity x Technology Life-Cycle Maturity • Messaging Platform • Direct Secure Transport (SMTP, S/MIME) • Patient Discovery • Query • Retrieve • XDR and XDM for Direct Messaging High • Authorization Framework • Document Submission • Administrative Distribution Spec Maturity Mod • Web Service Registry (consider alternatives) Low Emerging Maturing Mature Declining Technology Maturity 14

15. 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

16. Specification Grid: Deployment/Operational Complexity x Industry Adoption • Administrative Distribution (recommend as building blocks) Low • Document Submission • Messaging Platform • XDR and XDM for Direct • Patient Discovery • Query • Retrieve Mod Deployment/Operational Complexity • Direct Secure Transport (SMTP, S/MIME) (consider alternatives) • Authorization Framework High • esMD (unknown deployment/operational complexity) (individually assess) Low Mod High Industry Adoption 16

17. 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

18. 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

19. 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

20. 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

21. Glossary - Attachment Glossary Attachment 21

22. 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

23. 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

24. 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

25. 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

26. 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