Standards & Interoperability Kickoff

1. Standards & InteroperabilityKickoff Office of Standards and Interoperability

2. Agenda and Goals for Today Opening Remarks and Introduction Background on ONC Overview of the S&I Framework Break Brief presentations from each of the S&I Teams Q&A Session Break Administrative Session – This will be a closed section (limited to only S&I Team members and contractors)

3. ONC Organizational Chart

4. Standards and Interoperability Organizational Structure Standards and Interoperability Standards National Health Information Network Certification and Testing FHA Standards Teams NHIN Teams Certification Team FHA Teams Architecture Use Cases (Accenture) CONNECT (TBD) Certification (Stanley/Deloitte) Reference Implementations (Lockheed Martin) Standards Development (TBD) Test Infrastructure (Stanley/Deloitte) Emergent Pilots (Lockheed Martin) Harmonization (Deloitte) Tools (Stanley) Spec Factory (Deloitte) Operations (Stanley)

5. S&I Mission Promote a sustainable ecosystem that drives increasing interoperability and standards adoption Create a collaborative, coordinated, incremental standards process that is led by the industry in solving real world problems Leverage “government as a platform” – provide tools, coordination, and harmonization that will support interested parties as they develop solutions to interoperability and standards adoption.

6. An Introduction to S&I Framework and NIEM THE ONC STANDARDS AND INTEROPERABILITY FRAMEWORK

7. Outline • The ONC S&I Framework (what is it, why is it, how does it work) • Activities and Processes • National Information Exchange Model • Information Exchange Package Documentation • Model-Centric Specifications For Healthcare Data Exchange • The Approach – Model Centric Specification • Next Steps (discussion)

8. ONC Standards and Interoperability Framework Pilot Demonstration Projects (Lockheed Martin) Standards Development (TBD) Reference Implementation (Lockheed Martin) Harmonization ofCore Concepts (Deloitte) Implementation Specifications (Deloitte) Certificationand Testing (Stanley/Deloitte) Use Case Developmentand Functional Requirements (Accenture) Tools and Services(Use Case Development, Harmonization Tools, Vocabulary Browser, Value Set Repository, Testing Scripts, etc) (Stanley) 8

9. Why do we need an interoperability framework? “Whitepapers are not Specifications” David Linthicum ,OMG SOA Healthcare Conference 2010

10. Why do we need an interoperability framework? • Move toward more “computational” implementation specifications (IS) • Scalable processes • Ability to develop tools to increase the efficiency of IS development and maintenance • The importance of developing IS that are explicit and subject to less interpretation • Link use cases and standards from inception to certification • Keep the certification processes tightly linked to the standards and IS processes • Support tool development for certification testing • Develop the testing for compliance at the same time as developing the standards • Integrate multiple SDOs with different expertise across the process • Transport packages • Vocabulary • Value sets • Security • Provide repeatable mechanisms for harmonization and integration of existing standards across SDOs 10/24/2014

11. S&I Organizing Principles • Not a “waterfall” Process: Developing and harmonizing standards and service specifications across diverse communities necessitates concurrent, agile activities • Need for Structured Coordination: To manage coordination of the concurrent activities within the framework , we need well defined: • Artifacts: We need to ensure the content and structure of the artifacts within the process are well defined and provide continuity within the activities and the tools. • Roles: Clear “ownership” of significant artifacts and activities must be assigned to ensure coordination, to reduce duplication and to maintain continuity throughout the process. An example of this is the Use Case Stewart, but there are additional roles throughout the process. • Control Points: Need prioritization, validation or approval of artifacts to ensure quality and alignment with goals

12. S&I Activities Use Cases and Harmonization Harmonization ofCore Concepts Use Case Developmentand Functional Requirements 12 • Engages a wide community in defining use cases to be driven through the process • Focus on solving a real problem • Determines scope • Able to “test” if the use case solves the problem • Prevents “analysis paralysis” • Does not model in the abstract • Open, transparent process • Output Business Scenarios should describe • Services • Standards • Business rules, trust, policies • Output can be captured as • Use Cases and Activity Diagrams • Collaborations • BPMN • Etc… • Use-case driven (bottom up) with top down coordination • Multiple use cases might have overlapping standards, services or policies • E-prescribing and adverse event reporting • Clinical care summary and quality reporting • Laboratory data exchange and clinical decision support • Need to have a strong harmonization framework that spans different standards organizations

13. S&I ActivitiesStandards Development andImplementation Specs Standards Development Implementation Specifications 13 • As part of the use case development and harmonization process gaps in standards may arise • Gaps may exist in • Data package • Value Sets • Services • Work with SDOs (NLM, HL7, IHE etc) to fill in gaps • Allows the standards work to proceed in parallel with development of the implementation specifications • Using a model-centric approach to provide sufficient details to support implementation • Implementation Specification is an explicit description of the • Standards • Services • Policies • Specifications are packaged together to support use cases and business scenarios • Create guidelines for development of reference implementation

14. S&I ActivitiesReference Implementation and Pilots Pilot Demonstration Projects Reference Implementation 14 Executable implementations of specifications Can be used by others to help guide their own implementation or find problems with specifications Encourages feedback to ONC Reference implementations in use by stakeholders Confirms use case is being supported ONC helps provide coordination of pilot demonstrations

15. S&I ActivitiesCertification and Testing and Tools and Services Tools and Services(Use Case Development, Harmonization Tools, Vocabulary Browser, Value Set Repository, Testing Scripts, etc) Certificationand Testing 15 Provides mechanisms and infrastructure for testing specification implementations Includes conformance testing for individual specifications as well as interoperability testing for business scenarios Tools and Tests can be used as part of ONC Certification • Tools and Repositories used to support the other S&I activities • Example • IEPD and model repositories • Vocabulary sets • Modeling tools and guidelines • Collaboration tools • Will leverage existing tools and repositories whenever possible • Many of the repositories and collaboration tools to be publically available

16. S&I Coordination (Artifacts, Roles and Controls) Core artifacts are versioned and controlled Artifacts are “packaged” and released Each artifacts has a responsible role Artifacts and releases have prioritization and approval points, or “controls” 10/24/2014

17. What is an IEPD? • An Information Exchange Package Documentation (IEPD) is a collection of artifacts that describe the construction and content of an information exchange • Developed to provide the business, functional, and technical details of the information exchange through predefined artifacts • Created with a core set of artifacts in a prescribed format and organizational structure to allow for consistency • Designed to be shared and reused in the development of new information exchanges through publication in IEPD repositories • IEPDs contain design specifications for an information exchange but may not include supplementary information such as implementation decisions. 10/24/2014

18. NIEM Process From NIEM website http://www.niem.gov/index.php IEPD: Information Exchange Package Documentation

19. The IEPD Artifacts IEPDs contain both required and recommended artifacts Required : Bold Recommended : Italic Note: Best practices for most organizations include many of the optional artifacts listed here Scenario Planning • Business Process • Use Cases • Sequence Diagrams Analyze Requirements • Business Rules • Business Requirements Map & Model • Exchange Content Model • Mapping Document Build & Validate • Subset Schema • Exchange Schema • XML Wantlist • Constraint Schema • Extension Schema • Main Document • IEPD Catalog • IEPD Metadata • Sample XML Instances • XML Stylesheets Assemble & Document No required artifacts. Publish the IEPD to a repository and implement the exchange Publish & Implement

20. S&I NIEM Harmonization Strategy Human Services Health and Human Services 20 ONC’s Office of Interoperability and Standards is building a Health Information Exchange Model (NIEM Health) that is harmonized with NIEM Health and Human Services petal to serve as bridge between NIEM and NIEM Health

21. S&I NIEM Process Harmonized S&I Development Phases Participants Release & Publication Capability Formulation Capability Elaboration Construction Assemble & Document Map & Model Pub. & Impl. Scenario Planning Analyze Requirements Build & Validate NIEM Lifecycle Use Case Development Harmonization Spec Development Reference Impl Cert &Testing Health Community S&I Governance

22. Addressing Challenges for the Health Information Exchange Model

23. Model Centric Specification Development • The S&I Framework uses models to capture the information required to specify exchanges between parties on the NHIN. This supports the 2 primary goals of the S&I Framework • To aid in the creation of specifications that are less ambiguous than specs traditionally done using word processing tools. • To support the creation of specifications by other groups • Models refers largely to the visual representation of exchange syntax, semantics, dependencies and rules. • By using models the S&I Framework intends to: • Establish a repeatable pattern for evolution and traceability from requirements to implementation of specifications • Provides for the implementation of specifications using multiple possible technologies • Support the composability and reuse among specifications • Support the creation of specifications by groups outside ONC by providing guidelines, patterns, repositories and tools

24. Requirements for a Model Centric Approach • The modeling approach used by the S&I Framework must • Provide traceability from Use Case and Requirements through to one or more implementations • Provide semantic and syntactic modeling constructs to support defining the information and behavior that are part of exchanges • Support the need to harmonize with existing standards defined at different levels of abstraction • Be adoptable by different organizations • Be able to integrate into NIEM process

25. Model-Centric Solution - MDA • Base S&I Framework modeling on the 3 OMG/MDA model abstractions. • Computational Independent Model (CIM) • Platform Independent Model (PIM) • Platform Specific Model (PSM) • Define a mechanism to show traceability from Use Cases and Functional Requirements through to technical bindings defined in a PSM. • Define a flexible modeling foundation by which different types of specifications can be defined. • Provides ability for multiple technology bindings for the same set of logical specifications (multiple PSMs)

26. Behavior Model Domain Model Web Services Schema and WSDL Use Case Model, Interaction Model, Domain Model Vision Document, Process Model Main Document, IEPD Catalog, IEPD Metadata, Sample XML Exchange Schema, Subset/Constraint Schema, Business Processes, Use Cases Business Rules, Business Requirements Exchange Content Model, Mapping Document Model Centric Solution - NIEM S&I Activities NIEM Processes and Artifacts Specification Models Scenario Planning Use Case Developmentand Functional Requirements CIM Harmonization ofCore Concepts Analyze Requirements Map and Model Implementation Specifications PIM Build and Validate Reference Implementation and Pilots PSM Assemble and Document Certification and Testing Publish and Implement

27. Prioritization and Backlog Lists Strategic Priorities Operational Priorities “Day to Day” Priorities within each functional team 10/24/2014

28. Examples of stakeholder coordination HITPC HIT SC VLER VLER NHIN CC NHIN TC FHA FHA • Other important stakeholders: • SDOs • Providers • Venders • Consumers • States • HIEs 10/24/2014

29. What’s Next Pilot Demonstration Projects Standards Development Reference Implementation Harmonization ofCore Concepts (NIEM framework) Implementation Specifications Certificationand Testing Use Case Developmentand Functional Requirements Scenario Planning Map & Model Analyze Requirements Build & Validate Assemble & Document Publish & Implement NIEM IEPD Lifecycle Create a NIEM Health standards harmonization process and governance framework Establish roadmap for existing NHIN standards, MU harmonization, and non-MU health information exchange specifications Establishes a repeatable, iterative process for developing widely reusable, computable implementation specifications Establishing the tooling and repositories needed Establishing the practices and guidelines for modeling Enables semantic traceability so that useable code can be traced back to original requirements and definitions Promotes transparency and collaboration from broad range of health stakeholders

30. Bottom up use case development within a top-down coordination framework CORE PRINCIPLES Prioritization Transparency Engagement Rapid Results Focused Collaboration Commandand Control Focus Classic Trade-Off Low High A Thousand Flowers Bloom Low High Participation NHIN Direct + Interoperability Framework =Focused Collaboration

31. Final Thoughts Don’t let perfect be the enemy of the good Incremental, iterative, and value-focused Don’t forget the little guy

32. QUESTIONS?