Presenters: Co-Chairs of the EHR-Centric IS Tiger Team Michael Nusbaum, BASc, MHSA, FHIMSS

1. EHR Centric Interoperability Specification Webinar #9 October 8, 2009 | 2:00 – 3:30 pm (Eastern) Presenters: Co-Chairs of the EHR-Centric IS Tiger Team Michael Nusbaum, BASc, MHSA, FHIMSS Manick Rajendran, BS, MBA Corey Spears

2. Overview Re-organization and re-purposing of all of HITSP’s 13 original Interoperability Specifications (IS) into an EHR-centric view Aligned with the Health Information Technology (HIT) provisions of the American Recovery and Reinvestment Act of 2009 (ARRA). Simplified framework for HITSP’s ongoing activities, making future work products easier to understand and simpler to implement.

3. Learning Objectives During this 90-minute webinar, participants will: Learn why this IS is important to EHR vendors and organizations Understand how the HITSP EHR-Centric IS can support ARRA requirements Learn how the EHR-Centric IS utilized the concepts of “capabilities” and “service collaborations” to simplify the specifications and facilitate ease of implementation Discover how HITSP efforts going forward will further leverage Capabilities and Service Collaborations as re-usable components Learn how to find and navigate the IS107 EHR Centric document

4. Agenda What is HITSP? What HITSP produces What is ARRA? What was the EHR-Centric IS Tiger Team asked to produce? Introduction of new “building blocks” Capabilities Service Collaborations A new HITSP approach Navigating the IS107 Document Conclusion Questions and Answers

5. To serve as a cooperative partnership between the public and private sectors for the purpose of achieving a widely accepted and useful set of standards specifically to enable and support widespread interoperability among healthcare software applications, as they will interact in a local, regional, and national health information network for the United States. Mission

6. Overview HITSP is a volunteer-driven, consensus-based organization that is funded through a contract from the Department of Health and Human Services Created in 2005 HITSP develops Interoperability Specifications (IS) – documents that harmonize and recommend the technical standards that are necessary to assure the interoperability of electronic health records Production to date: 14 IS and 60 related constructs

7. Patients Consumers Employers General Practitioners HITSP Stakeholders • Standards Developers • Specialists • Payers • Suppliers • Review Boards • Practice Guidelines • Residential Care Providers • Outpatient Providers • Government Agencies • Hospitals Current Participation in HITSP: 800+ organizations 1,000+ individuals Over 25,000 volunteer hours

8. HIT Standardization HITSP members agreed that a standard is a well-defined approach that supports a business process and . . . • has been agreed upon by a group of experts • has been publicly vetted • provides rules, guidelines, or characteristics • helps to ensure that materials, products, processes and services are fit for their intended purpose • is available in an accessible format • is subject to an ongoing review and revision process Standards Harmonization is required when a proliferation of standards prevents progress rather than enabling it.

9. What is ARRA? Also known as the “economic stimulus package” Signed into law by President Obama on February 17, 2009 What is HITECH? A portion of ARRA referred to as the Health Information Technology for Economic and Clinical Health (HITECH) Act TITLE XIII—Health Information Technology TITLE IV—Medicare and Medicaid Health Information Technology Contains numerous provisions related to Health Information Technology (HIT) and privacy with aggressive timelines for completion

10. To Address ARRA Requirements, Tiger Teams Were Created with Specific Focus Areas • A new EHR Centric Interoperability Specification to meet ARRA requirements • Security, Privacy & Infrastructure • Quality Measures • Data Architecture (Element, Template, and Value Set) • Exchange Architecture and Harmonization Framework • Clinical Research Tiger Team membership 232 technical experts

11. Status: Interoperability Specifications Recognized Released Accepted Secretary of HHS has recognized the IS for immediate implementation Secretary of HHS has accepted for a period of testing Panel approved for submission to HHS Federal projects must use HITSP recognized standards Per Executive Order13410

12. HITSP Interoperability Specifications (IS) Recognized Accepted

13. Accepted Released / Panel Approved HITSP Interoperability Specifications (IS)

14. EHR-Centric Tiger Team Produced the EHR-Centric Interoperability Specification (IS) Utilizing the 13 recognized/accepted (as of 13Feb09) HITSP Interoperability Specifications . . . . . . in the context of the ARRA to produce an EHR-Centric IS . . . • that is: • simplified • easily understood • applicable beyond limitations of initiating use cases • implementable • leverages existing work

15. EHR-Centric IS Addresses ARRA / HITECH Priority Areas * Individually Identifiable Health Information (IIHI) Unusable

16. EHR-Centric IS Facilitates Achievement ofARRA / HITECH Meaningful Use

17. New Harmonized Construction Rules Were Needed Something every organization can use for its EHR Takes advantage of opportunities to work smarter Re-use and re-purpose

18. Putting the Pieces Together HITSP created IS’s to harmonize standards and make them implementable • Before HITSP, there was a “custom puzzle” to build for every organization to talk to another organization • HITSP used existing Interoperability Specification (IS) constructs to create reusable Capabilities and Service Collaborations

19. Meeting Business Needs Capabilities and Collaborations could be used to build any new Interoperability Specification to meet a particular business need

20. HITSP Capabilities Enable systems to address a business need for interoperable information exchange Bridge between business, policy and implementation views: Define a set of information exchanges at a level relevant to policy and business decisions Support stakeholder requirements and business processes Define information content and secure infrastructure Specify use of HITSP constructs sufficiently for implementation Include constraints and identify specific network topologies Created To Simplify Design and Use of HITSP Specifications for ARRA Efforts and Beyond

21. Overview: HITSP Interoperability Specifications AHIC Use Case Constructsavailable for reuse or repurposing • Interoperability Specification (IS) • Identifies the framework that is a solution for business need (use case) • Defines requirements including transactions and terminology • Addresses multi-year roadmap as needed Technical Notes Transaction Package Transaction Component

22. HITSP Glossary • Capability (CAP) – Specifies a business service that an EHR system addresses and specifies the contents and secure infrastructure needed for that business service • Service Collaboration (SC) – Defines a standards-based secure infrastructure needed for interoperable information exchanges and includes a secure transport mechanism with topology and other options regardless of content • Interoperability Specifications (IS) – Integration of all constructs used to meet business needs or the business needs specified in a Use Case • Components (C) – Logical grouping of base standards that work together, such as messaging and terminology • Transactions (T) – Logical grouping of actions that use components and/or composite standards to realize the actions • Transaction Packages (TP) – Logical grouping of transactions

23. Standards “Real World” examples of Base and Composite Standards • XML (base) • IHE-XDS (composite) • HL7-CCD (base) • DICOM (base) • LOINC (base) • SNOMED-CT (base) • NCPDP-Script (composite) • etc. Base Standard • capable of fulfilling a discrete function Composite Standards • groupings of coordinated base standards Examples • Basic Specifications • Implementation Guides • Code Sets and Terminologies

24. What Is an Example of a Capability? Requirement: Hospital wants to exchange a discharge prescription with an patient’s physician’s office. This diagram shows how Capability (CAP) 117 was assembled to support this requirement using Transaction, Transaction Package and Service Collaboration T40 T42 TP43 TP46 SC114 • System Roles • Medication Order Prescriber • Medication Order Filler • Health Plan • Health Information Exchange Exchange a prescription with an Ambulatory or Long-Term Care Organization CAP117 – Communicate Ambulatory and Long Term Care Prescription

25. Details of Capability 117 • Requirement: Hospital wants to exchange a discharge prescription with an patient’s physician’s office. SC114– Administrative Transport to Health Plan P H A R M A C Y TP46– Medication Formulary and Benefits Information TP43– Medication Orders T42– Medication Dispensing Status T40– Patient Health Plan Eligibility Verification CAP117 – Communicate Ambulatory and Long Term Care Prescription

26. Details of Service Collaboration 114 SC109 - Security Audit Collaboration T15 - Collect and Communicate Security Audit Trail T16 - Consistent Time SC108 - Access Control Service Collaboration C19 - Entity Identity Assertion (Optional) H E A L T H PLAN T17 - Secured Communication Channel TP20 - Access Control TP30 - Manage Consent Directives T85 - Administrative Transport to Health Plan T17 - Secured Communication Channel Provider SC114 – Administrative Transport to Health Plan

27. HITSP Capabilities

28. More HITSP Capabilities

29. And Yes . . . there are more HITSP Capabilities

30. Service Collaborations (SC) Defines a standards-based secure infrastructure needed for interoperable information exchanges. Includes a secure transport mechanism with topology and other options. Uses HITSP Constructs to specify the secure infrastructure. Does not specify the content of the information exchange but may include information to support the exchange (e.g., authorization information) Additional Keys to Simpler Definition and Implementation of HITSP Specifications

31. Service Collaboration – An Essential Component

32. HITSP Service Collaborations (SC) SC108 – Access Control SC109 – Security Audit SC110 – Patient Identification Management SC111 – Knowledge and Vocabulary SC112 – Healthcare Document Management SC113 – Query for Existing Data SC114 – Administrative Transport to Health Plan SC115 – HL7 Messaging SC116 – Emergency Message Distribution Element

33. How It All Fits Binds content definition with secure infrastructure for a set of interoperable information exchanges

34. Initial HITSP Approach – Use Cases

35. Capabilities Changed the Level at which We Work

36. Capabilities Allow Us to Develop New Technical Constructs As Needed

37. The Refined HITSP Framework HITSP Capabilities Service Collaborations Transaction Constructs Service Collaboration Transaction Package Transaction Component SDOs = Standards Development Organizations

38. “Meaningful Use” From existing Interoperability Specifications, determine subset required for “meaningful use” as called for in the American Recovery and Reinvestment Act (ARRA). Effort began on April 7, 2009.

39. HITSP Capabilities Were Created from Previous Work Full copy of this file posted with the Webinar Slides @ www.hitsp.org/webinars

40. The Capabilities Map to ARRA Requirements Example

41. Requirements Supports New HITSP Interoperability Specifications EHR-Centric IS Organized by End Result: The EHR-Centric IS was built using these Capabilities. AnyIS can be assembled using Capabilities. Capability Capability Capability Service Collaborations Based on Existing HITSP Constructs

42. Document Overview and Navigation Tips EHR Centric Interoperability Specification

43. You Can Find IS107 on www. hitsp.org

44. Scroll to the bottom to find IS107

45. IS107 EHR CentricInteroperability Specification

46. In the EHR-Centric IS, Each Capability Is Described by: Detailed description Design specification Interacting Systems Constraints & Assumptions List of constructs (including Service Collaborations) Specified Interfaces (mapped to construct/content) Interface Conditions & content optionality Uniform Modeling Language (UML) diagram Capability options (content subsets and transport options)

47. Each Capability is written in this format • Communicate Ambulatory and Long Term Care Prescription Specification • 3.2.1 Overview • 3.2.2 Design Specification • 3.2.2.1 Interacting Systems • 3.2.2.2 Constraints and Assumptions • 3.2.2.3 List of Constructs • 3.2.2.4 Specified Interfaces • 3.2.2.5 Capability Options

48. Two Key Websites to Bookmark • www.hitsp.org • http://wiki.hitsp.org/docs

49. NEW HITSP Team Members ALWAYS welcome!www.HITSP.org • All you need is passion to get the job done • Motivation to make a difference • Drive to push the nation forward • Volunteers ARE the life blood of HITSP to get the job done • If you knew enough to attend this webinar, you know enough to jump on in!

50. The 2009 Webinar Series www.HITSP.org/webinars         