Slide 0 EHR SD RM - EHR Way Forward … Future State Reference Architecture Please Send Suggestions for Improvement to GovProjects; EHR, SOA, ArB EHR SD RM SAIF Alpha Project “EHR System-Design Reference-Model” Constructing a Future State EHR Reference Architecture EHR Way Ahead Business Architecture From HL7, HITSP and ARRA Artifacts For presentation at HL7 Sydney Workgroup Meeting, 11 Jan 2011 Practical Guide: EHR SD RM info:

Slide 1 EHR SD RM - EHR Way Forward … Future State Reference Architecture Objective of this Presentation is to Discuss the Following Next Step Questions …  How should the EHR-SD RM be represented? – Hypothesis : XML DB, DITTA documentation  Use cases for EHR-SD RM use? –Ad Hoc Reporting needs –Web based tools needs –Profile needs (e.g., domain adaption vs. local use adaption)  How to ballot the EHR-SD RM? – Part of EHR-S FM R2.1 –Independent of EHR-S FM  Who will Participate? –Information Model sub-project –XML/XSL Technical expert –Subject Matter Experts (e.g., diabetes, Immunization, etc.)

Slide 2 EHR SD RM - EHR Way Forward … Future State Reference Architecture EHR SD RM Milestones Healthcare SOA Reference Architecture (H-SOA-RA) EHR SD RM Immunization & Response Management (IRM) Prototype May HSSP Practical Guide for SOA in Healthcare Volume II: Immunization Case Study DSTU is Draft Standard for Trial Use (ANSI standards development) EHR-S CI-IM is EHR System Computationally Independent Information Model HF&EA is Harmonization Framework and Exchange Architecture 2011 May EHR-S FM R2.0 With EHR SD RM Informative Reference Sep EHR SD RM Integrated into EHR-S FM R2.1

Slide 3 EHR SD RM - EHR Way Forward … Future State Reference Architecture 2008 Healthcare SOA Framework Based on HL7 EHR System Functional Model & Thomas Erl’s SOA Layers HL7 System Functions  Direct CareSupportiveInformation Infrastructure Other Business Process Value Chains Composite Services Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas Core Business Services Functional Areas + Focal Classes Functional Areas + Focal Classes Functional Areas + Focal Classes Functional Areas + Focal Classes Entity Services Information Management Information Management Information Management Information Reporting and Management Agnostic Services C r o s s T e c h n I c a l “Common S e r v I c e s” (e.g., Security, Privacy, Auditing, Logging…) Application Services Ambulatory Care Systems, In Patient Care Systems Logistics Systems Financial Systems Decision Support Systems Data Marts Repositories Business Objects Implementation Profiles Integrated Healthcare Enterprise (IHE) Profiles Analysis ProfilesCommunications Profiles/Stacks Implementation Profiles 3

Slide 4 EHR SD RM - EHR Way Forward … Future State Reference Architecture HL7 EHR System Functional Model (EHR-S) > 160 System Functions in 4 level categorization (separate spreadsheet available for full enumeration) NOTE : “Other” Category - The EHR-S model does NOT include Electronic Resource Planning (ERP) / Logistics and Financial components, which are needed for completeness of a Health IT Enterprise. Other O-1 Electronic Resource Planning (ERP) O-2 Finances O-3 Other System Functions EHR-S FM functions can be grouped into Service Components … aka Capabilities (e.g., Lab Order Capability, which does eligibility and authorization function as well as lab order function).

Slide 5 EHR SD RM - EHR Way Forward … Future State Reference Architecture SUPPLY CHAIN (ORDER/CHARGE) ANATOMY OF AN ANCILLARY SYSTEM AUTHORIZATION DOCUMENT RECORDS MANAGEMENT DECISION SUPPORT PERFORMANCE DATA MANAGEMENT SCHEDULING IDENTITY TERMINOLOGY LABORATORYRADIOLOGYPHARMACYCARDIOLOGYOT/PT/SPEECH s CORE BUSINESS SERVICES 5 Capabilities, which orchestrate Core Business Services

HL7 EHR_S-Based Functional Architecture/Services Analysis Security Unique ID, Registry, and Director Terminology Information and Records Management Interoperability ETC Support Knowledge Access Support Clinical Communication Clinical Workflow Tasking Clinical Decision Support Record Patient Specific Instructions Documentation of Care, Measurement, and Results Orders and Referral Management Care Plans, Treatment Plans, Guidelines, and Protocols Management of Assessment Summary Lists Preferences, Directives, Consents, and Authorizations Manage Patient History Record Management Manage Business Rules ETC Primary Care Critical/Emergency Care Dental Non-Surgical Specialty Care Laboratory Nursing Pharmacy Population Health Behavioral Health ETC. Cross-Cutting Direct Care/ Support Functions Infrastructure Functions Lines of Business Infrastructure Services Security Policy Records Management Audit Terminology Registry Workflow Business Rules etc Core Clinical Services Entity Identification Resource Location and Updating Services Decision Support Orders Management Scheduling Image Management Etc. 6

EHR System Design Reference Model (EHR SD RM) Supporting Requirements/ Architecture Development Cycle EHR System Design Reference Model EHR System Design Reference Model Requirements Analysis Requirements Analysis Stakeholder Requirements Definition Stakeholder Requirements Definition Requirements Loop Verification & Validation Loop Specifications Loop PROCESS INPUTS -Required Capabilities -Environments -Constraints PROCESS OUTPUTS -System Architecture, -Test Specifications -Configuration Management Baselines Capabilities, Functions, Information and Information Exchanges Conformance Criteria Interface Specifications Test Loop Functions – Dependencies Test Specifications Test Specifications Conformance is a recognition of formal testing, that prove that a system provides 100% support for a given standard. Architectural Specifications Architectural Specifications 7

EHR SD RM Supporting Requirements/ Architecture Development Cycle Stakeholder Requirements – What is the system supposed to do? Under what conditions will the products be used? – Where will the products of the system be used? – How often? How long? – Who will use the products of the system? Requirements Analysis (“HOW?” using “Action Verbs”) –Analyze functions and Services Decompose higher level functions to lower level functions Allocate performance requirements to the functions Architecture Design ( Which hardware/ software elements) –Define the physical architecture Each part must perform at least one function Some parts may perform more than one function Test Specifications – How Requirements-Specifications are validated Requirements Loop  Ensure all requirements are covered by at least one function  Ensure all functions are justified by a valid requirement (no unnecessary duplication) Design Loop  Ensure all functions are covered by at least one hardware or software element  Ensure all elements of physical architecture are justified by a valid functional requirement (no unnecessary duplication) Verification & Validation (V&V) Loop  Each requirement must be verifiable that the solution meets requirements and validated that it meets the user’s needs and expectations.  V&V can be accomplished by: Inspection, Analysis, Demonstration, Test Test Loop  Ensure all information is covered by test specifications  Ensure all interfaces are covered by test specifications 8

Slide 9 EHR SD RM - EHR Way Forward … Future State Reference Architecture 2010 SAIF Alpha Project The Practical Guide For SOA in Healthcare Volume II Immunization Management Case Study The Practical Guide for SOA in Healthcare Volume II presents a case study, which adds an Immunization Management Capability (IMC) to Volume I’s SampleHealth’s Service Oriented Architecture (SOA). We used the TOGAF Architecture Development Method (ADM) and HL7 Service Aware Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF). Volume II demonstrates the use of HL7’s EHR System Design Reference Model (EHR-SD RM) linked artifacts (e.g., EHR System Functional Model, FHIM, HITSP, HITEC, HSSP, IHE, NIEM, etc) to provide an initial architectural baseline suitable for an EHR related SOA acquisition, development or certification project. We conclude with lessons learned. Healthcare Services Specification Project ( HSSP ) Practical Guide: 

10 SAIF ECCF examples

Slide 11 EHR-S FM Behavioral Viewpoints Conceptual Independent Model Platform Independent Model Platform Specific Model Information Viewpoints Conceptual Independent Model Platform Independent Model Platform Specific Model Engineering/Technical Viewpoints Conceptual Independent Model Platform Independent Model Platform Specific Model Example of SAIF Traceability Using HL7 EHR-S FM FMIDs Business Viewpoints Conceptual Independent Model Platform Independent Model Platform Specific Model Key to Traceability Traceability is achieved by using Functional Model Identifiers ( FMIDs ) as attributes to all SAIF artifacts. This is analogous to a library system, which uses Dewey decimal numbers as book identifiers. Investment Portfolio Line Items Planning budget for new, improved or sunset capabilities FMIDs Product Line Inventory Inventory of systems and their capabilities and Functions

Slide 12 EHR SD RM - EHR Way Forward … Future State Reference Architecture Immunization Management ECCF Specification Stack Subject Specification Enterprise Viewpoint “Why” Policy Information Viewpoint “What” Content Computational Viewpoint “How” Behavior Engineering Viewpoint “Where” Implementation CIM (Conceptual) Inventory of o Use Cases o Capabilities-Services o Requirements o Contracts o Stakeholders Business Scope Business Vision Business Objectives Policy & Regulations Inventory of o Domain Entities o Roles, o Activities, o Associations. Information Models o Conceptual o Domain Inventories of o Capabilities-Components, o Functions-Services. Requirements o Accountability, Roles o Behaviors, Interactions o Functional Profiles, o Interfaces, Contracts Conceptual Functional Service Specifications Inventory of Platforms/ Environments. PIM (Logical) Applicable Rules Use Case Specs Governance. Technology Neutral Standards Wireframes of o architectural layers o Components and o Associations Information Models o Localized o Constrained o Project Message Content Specifications Use Case Specs Component. specs Interface Specs Interaction Specs Collaboration Participations Collaboration Types Function Types Interface Types Collaboration Scripts Service Contracts Existing Platform models, Capabilities, Libraries and Versions. PSM (Implementable) Business Nodes Business Rules Business Procedures Business Workflow Technology Specific Standards Database Schemas Message Schemas Transformation Schemas (e.g., XSD) Automation Unit Technical Interfaces Technical Operations Orchestration Scripts Application Specs. GUI Specifications Component Designs Deployment Topology Platform Bindings 12

Slide 13 EHR SD RM - EHR Way Forward … Future State Reference Architecture

Initiation Analysis Peer Review “Ballot” Design EHR-S FM & EHR-S CI-IM EHR System Function Model & EHR System Computationally- Independent Information- Model DAM Domain Analysis Models CDA Clinical Document Architecture CMET Common Model Element Types D-MIM Domain Message Information Model Interoperability Specifications for Messages and/or Documents and/or Services HL7 Development Framework (HDF) Implement & Test Specifications for Business Objects Components Capabilities Applications Systems V&V Checkpoin t V&V Checkpoint V&V Checkpoint V&V is Verification and Validation SAIF ECCF - Services Aware Interoperability Architecture - Enterprise Compliance and Conformance Framework V&V Checkpoint DSTU - Draft Standard for Trial Use “Prototype” Draft Working Document; Not for Public Distribution 14

Slide 15 EHR SD RM - EHR Way Forward … Future State Reference Architecture SAIF ECCF Viewpoints CIM PSM PIM ECCF CIM is Computationally Independent Model PIM is Platform Independent Model PSM is Platform Specific Model Draft Working Document; Not for Public Distribution 15 Interoperability Specification

Slide 16 EHR SD RM - EHR Way Forward … Future State Reference Architecture EHR-S CI-IM (Started Jun 2010) EHR System Computationally-Independent Information-ModelEHR System Computationally-Independent Information-Model This project will produce a set of Constrained Information Models called EHR-S “data profiles”. Each EHR-S data profile corresponds directly with an EHR-S function profile and each EHR-S data profile will include one-or-more Reference Information Model classes. Pairs of EHR-S function profiles and data profiles can be used to define business objects, which can be composed into software components, capabilities, applications, systems and their message exchanges and/or document exchanges and/or services. The superset of EHR-S data profiles is called the EHR-S Computationally-Independent Information-Model, which supports the HL7 Development Process and Service Aware Interoperability Framework. The project will include the development and execution of a communication strategy to ensure that all affected stakeholders are engaged.

Slide 17 EHR SD RM - EHR Way Forward … Future State Reference Architecture HL7 RIM (Reference Information Model) Six Core Classes Defining a Semantic Framework which Maintains Clinical Data Context The HL7 RIM expresses the data content needed in a specific clinical or administrative context and provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages. Role link Act relationship Participation The HL7 RIM supports EHR interoperability; an EHR may needs additional foundation classes (e.g., Responsibility) Language / communication ACT (aka ACTION) ROLEENTITY ACT – something that has happened or may happen Entity – a person, animal, organization, or thing Role – a responsibility of, or part played by, an Entity Participation – the involvement of a Role in an Act Act Relationship – a relationship between two Acts Role Link – a relationship between two Roles.

Slide 18 EHR SD RM - EHR Way Forward … Future State Reference Architecture Federal Health Information Model (FHIM) Person Model (Harmonized with RIM, HIPAA & HITSP)

Slide 19 EHR-S FM DC x.y.z EHR-S Function Profile … SC x.y.z EHR-S Function Profile … IN x.y.z EHR-S Function Profile … Entity a.b.c EHR-S Data Modules … 1:1 Relationshi p between Function Profiles and Data Profiles For each EHR-S Function, its Data Profile = Set of RIM Classes and their EHR-S Data Modules EHR-S CI-IM Role a.b.c EHR-S Data Modules … Act a.b.c EHR-S Data Modules … Act Relationship a.b.c EHR-S Data Modules … Role Link a.b.c EHR-S Data Modules … Participation a.b.c EHR-S Data Modules … Entity d.e.f … RIM Classes Role d.e.f … Act d.e.f … Act Relationship d.e.f … Role Link d.e.f … Participation d.e.f … 1:N Relationship among Data Profiles and RIM Classes DC is Direct Care SC is Supportive Care IN is Infrastructure HL7 EHR System Computationally-Independent Information-Model (EHR-S CI-IM) Project Draft Working Document; Not for Public Distribution

Slide 20 EHR SD RM - EHR Way Forward … Future State Reference Architecture EHR SD RM Status (Oct 2010)  Supporting EHR System Functional Model R2 –EHR SD RM foundation (linked XML version) Spring 2011 ballot –HITSP (2010 completion) –ARRA Meaningful Use Objectives/ Criteria (Jun 2010 Final Rule)  Sub Projects –EHR Computationally Independent Information Model –Harmonization Framework and Exchange Architecture SAIF Executive Summary and Implementation Guide

Slide 21 EHR SD RM - EHR Way Forward … Future State Reference Architecture Prototype Demonstration of Browser-Version XML with XSL & XSLT  HTML Style Sheet  EHR-S FM R1.1 linked to –US Meaningful Use Objectives and Criteria –US Mandated Standards –Information Model (TBD)

Slide 22 EHR SD RM - EHR Way Forward … Future State Reference Architecture EHR SD RM Issue/Questions  2011 Planned Representation (Better Options?) –Linked XML (most flexible for documentation, current preference) – EHR–S FM (R2) and it’s profiles (2011) ISSUE: Managing Profiles ISSUE: Tracking Changes / Comments ISSUE : Managing HL7 Domain Analysis Models ( DAMS )? and ISSUE : Managing Detailed Clinical Models ( DCMs )? ISSUE : DITTA Publishing? (Resources needed) ISSUE : Data Base / Web version? (Resources Needed) – EHR CI-IM - Computationally Independent Information Model ISSUE: RIM/RIMBA expertise needed – US HITSP (2010)  Health & Human Services Selected Standards – US ARRA MU Meaningful Use Objectives & Criteria (2010)

Slide 23 EHR SD RM - EHR Way Forward … Future State Reference Architecture Call for Participation  XSL style sheet expert for –EHR-S FM R2 –EHR-S FM R2 with EHR SD RM additions –Profiles –Comment/Change tracking  EHR Computationally Independent Information Model –Decomposed by EHR-S FM –Traceable to RIM

Contact Information Nancy Orvis Chief Integration Architect Information Management DoD Military Health System HOW TO PARTICIPATE: Coordinate with We have a weekly telecom each Friday Eastern PHONE: , CODE: # WEB LINK: PROJECT WIKI: Steve Hufnagel Enterprise Architect, TIAG contract support Information Management DoD Military Health System 24 Backup Slides Available at Web Site

Slide 25 EHR SD RM - EHR Way Forward … Future State Reference Architecture Immunization Management Case Study Questions? HOW TO PARTICIPATE: Coordinate with or We have a weekly telecom each Friday Eastern PHONE: , CODE: # WEB LINK: PROJECT WIKI: