HL 7 EHR SD RM Project EHR System

HL 7 “EHR SD RM” Project “EHR System Design Reference Model” Constructing a Future State EHR Reference Architecture • EHR Way Ahead Business Architecture • Healthcare SOA Reference Architecture • Enterprise Information Model From HL 7 and HITSP Artifacts For presentation at HL 7 Phoenix Workgroup Meeting, January 2010 Nancy. Orvis@tma. osd. mil, Chief of Integration & Interoperability Details available at Stephen. Hufnagel. ctr@tma. osd. mil, Architect & System Engineer www. hssp. wikisoaces. com/Reference+Architecture Alean Kirnak, President, Software Partners EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 0

Federal Enterprise Architecture (FEA) www. whitehouse. gov/omb/egov q Performance Reference Model - The FEA PRM is a framework to measure the performance of major IT initiatives and their contribution to program performance. The PRM leverages performance measurement best practices from the public and private sectors, including the Balanced Scorecard, Baldrige Criteria, Value Measurement Methodology, program logic models, the value chain, and theory of constraints. There is an increased emphasis placed on linkage of investment to agency program performance and the PRM will help agencies produce enhanced performance information. Furthermore, the PRM will assist in: improving the alignment of program goals and objectives with Mission Area goals and objectives; improving communication of program contributions such as technology (input) to outputs and outcomes; and in identifying improvement opportunities that span traditional organizational boundaries. q Business Reference Model - The Business Reference Model (BRM) is a functional-driven framework for describing and organizing the day-to-day business operations of the Federal Government into Lines of Business (LOBs), independent of the agencies that perform the business operation. The BRM is the first layer of the Federal Enterprise Architecture and it is the organizing construct for the analysis of the other four reference models: performance, service components, data, and technology. q Service Component Reference Model - The Service Component Reference Model (SRM) is a functional framework to evaluate to identify government-wide opportunities to leverage IT investments and assets from a service perspective. This model helps understand the services delivered by the government and assess if there is an opportunity to group like services and create leverage opportunities, such as reuse or shared services. q Data Reference Model - The Data Reference Model (DRM) describes at an aggregate level, the data and information required to support the Lines of Business (LOBs). The three elements of data exchange that have been standardized include data description, data context, and data sharing. Establishing a common data model streamlines the information exchange process within and across the Federal Government and facilitates the ability to identify duplicative data resources. q Technical Reference Model - The Technical Reference Model (TRM) establishes a common technical framework for categorizing standards, specifications, and technologies that support and enable the delivery of services. This framework can be leveraged to support the development, delivery, and exchange of business and application components (Service Components) that may be leveraged in a Component-based or Service Oriented Architecture (SOA). Furthermore, it also EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 1 serves as the foundation to advance the re-use of technology and best practices from each of the Service Components on

EHR-SD RM Project Description and Plan PROJECT DESCRIPTION: HL 7 EHR System Design Reference Model (EHR SD RM) This project will mature the April 2008 Healthcare Services Oriented Reference Architecture (H-SOA-RA) version 1. 0 into H-SOA-RA Version 2. 0, for HL 7 Architecture Review Board (Ar. B) consideration, and then integrate it into an EHR System Design Reference Model (EHRSD RM), using the HL 7 SOA-Aware Enterprise Architecture Framework (SAEAF), HITSP Multi-Enterprise Architecture of Networked Services Standards (MEANS), EHR System Functional Model (EHR-S FM). Emphasis will be placed on maintaining AHIC, HITSP, NHIN and CCHIT conformance by maintaining Information Exchange Requirements (IERs) and Data Requirements (DRs) traceability. Mapping and analysis of the HL 7 product portfolio against the EHR-S FM will be used to integrate the reference architecture with HL 7 product lines and initially mature the resulting model as a technical white papers, then an informative reference model and finally a standard reference model. An HSSP based prototype case study architectural specification will be built to validate the effort. NEXT STEPS: For Project Information, see http: //hssp. wikispaces. com/Reference+Architecture 1. EHR SD RM Framework – Populate the framework with HL 7 EHR-S Functional Model content, candidate healthcare Information Exchanges, HITSP capabilities/ services and data architecture 2. Information Model – Loosely-coupled top-down Framework – Rigorously specified bottom up structure/ content based on HITSP Data Architecture Socialize EHR SD RM (HL 7 Meeting, Jan 2010) Collaborate with others within HL 7 (ongoing) Publish HL 7 HSSP Practical Guide for SOA in Healthcare Part 2: Case Study (May 2010) Solicit public comment; collaborate with IHE; HL 7/OMG SOA Conference (May to Sept) HL 7 Informative ballot (Oct 2010) HL 7 Normative ballot (Oct 2011) 3. 4. 5. 6. 7. 8. EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 2

Linking Business and Technical Architectur es EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 3

CONTENTS 2. Constructing a Future State EHR Reference Architecture 3. HL 7 EHR System Functional Model (EHR-S FM) 4. Healthcare SOA Reference Framework 5. HL 7 RIM (Reference Information Model) 6. HITSP Harmonization Framework 7. HITSP Constructs 8. HITSP Data Architecture 9. HITSP Clinical Document Components 10. HITSP/C 83 Data Module Categories 11. EHR Way Forward Business Architecture Specification Framework 12. Future State EHR Reference Architecture Adding ARRA and FHIM 13. Basic UML Legend 14. Abbreviations 15. PART II: HL 7 SAEAF, Requirements Management Process and Governance 16. PROTOTYPE: Immunization and Adverse Event Reporting EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 4

Constructing a Future State EHR Reference Architecture OBJECTIVE: A system agnostic Future State EHR Business Architecture (BA) specified with a lexicon, based upon HITSP’s data architecture, HL 7’s System Functional Model (EHR-S FM) and HL 7’s Reference Information Model (RIM). v A Health IT EHR BA can be modeled as clinical stakeholder requirements and their workflow-orchestration of v HL 7 RIM compliant HITSP data modules manipulated by v HL 7 EHR-S FM functions. v An EHR Information Model, for a project or enterprise, can be constructed from the HITSP data models managed by the EHR Functions used within the EHR BA, categorized using the HL 7 RIM Entity, Role and Action foundation classes. EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 5

HL 7 EHR System Functional Model (EHR-S) > 160 System Functions in 4 level categorization (separate spreadsheet available for full enumeration) 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). O-1 Electronic Resource Planning (ERP) O-2 Finances O-3 Other EHR SD RM - EHR Way Forward … Future State Reference Architecture 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. Slide 6

Healthcare SOA Framework Based on HL 7 EHR System Functional Model & Thomas Erl’s SOA Layers HL 7 System Functions Direct Care Supportive Information 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 Entity Services Information Management Information Reporting and Management 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…) Agnostic Services Application Services Ambulatory Care Systems, In Patient Care Systems Logistics Systems Financial Systems Decision Support Systems Data Marts Repositories Business Objects Integrated Healthcare Analysis Profiles Communications Implementation Profiles Enterprise (IHE) Profiles/Stacks Profiles EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 7 7 Implementation Profiles

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

HITSP Constructs q A HITSP Interoperability Specification (IS) defines a business context, supports a business workflow, constrains and orchestrates underlying constructs. q A HITSP capability (CAP) is a specification that assembles HITSP constructs to fulfill a business need for information exchanges. To use a Capability, an Interoperability Specification or an implementation conformance statement must assign Systems to one or more Capability System Roles and identify how the Capability Options are to be addressed. The use of a Capability shall: – for each assigned Capability System Role, the responsibilities of the assigned System Role must be supported, including all interfaces specified by the underlying HITSP constructs according to the conditions specified for the assigned System Role. – If a Capability option is selected, the implementation must conform to the Capability’s specifications for that option. q A HITSP Service Collaboration (SC) binds communications infrastructure, security and privacy constructs together. q HITSP Transaction Packages/ Transactions/ Components (TP/T/Cs) are where standards-based Interface Design Specifications are specified are given and conformance requirements are defined. EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 9

HITSP Harmonization Framework IS = Interoperability Specification Addressing Business Needs Defining Information Content IS Capability Available for Independent Implementation Service Collaboration Transaction, Transaction Package Providing Infrastructure, Security, Privacy Components Data Architecture EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 10

HITSP Data Architecture within HITSP Harmonization Framework HITSP Documents are available at www. hitsp. org Detailed HITSP Data Architecture is available online at www. ushik. org GREEN indicates reusable elements EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 11

HITSP Clinical Document Components HITSP Reuse Paradigm: With HITSP/Capability 119 - Communication of Structured Documents, a HL 7 Clinical Data Architecture (CDA) document can be composed, from any group of C 83 data modules, and then it can be communicated. EHR SD RM - EHR Way Forward … Future State Reference Architecture Benefit: agile system Slide 12 interoperability.

HITSP/C 83 Data Module Categories Module Category Description Personal Information The personal information includes name, address, contact information, personal identification information, ethnic and racial affiliation and marital status of a person Support includes the patient's sources of support, such as immediate family, relatives and/or guardians. This includes next of kin, caregivers, support organizations, and key contacts relative to healthcare decisions. Support providers may include providers of healthcare related services, such as a personally controlled health record, or registry of emergency contacts Healthcare Providers This includes a list of the healthcare providers and organizations that provide or have provided care to the patient Insurance Providers and Insurance providers include data about the organizations or individuals who may pay for a patient's healthcare, and the relationships, demographics and identifiers of those individuals with respect to the payer. Such organizations or individuals may be health insurance plans, Payers other payers, guarantors, parties with financial responsibility, some combination of payers or the patient directly Allergies and Drug Sensitivities This includes the allergy or intolerance conditions, severity and associated adverse reactions suffered by the patient Conditions This includes relevant clinical problems and conditions for which the patient is receiving care, including information about onset, severity, and providers treating the condition. Conditions are broader than, but include diagnoses Medications This includes the patient's prescription or non-prescription medications and medication history, and may include prescriptions, fulfillments and medication administration activities Immunizations This includes data describing the patient's immunization history Vital Signs This includes data about the patient’s vital signs Test Results This includes data about current and historical test results from laboratory or other diagnostic testing performed on the patient Encounter This includes data describing the interactions between the patient and clinicians. Interaction includes both in-person and non-in-person encounters such as telephone and email Procedures This includes data describing procedures performed on a patient Family History Data defining the patient’s genetic relatives in terms of possible or relevant health risk factors that have a potential impact on the patient’s health Social History Data defining the patient’s occupational, personal (e. g. lifestyle), social, and environmental history that have a potential impact on the patient’s health Medical Equipment includes implanted and external medical devices and equipment that a patient’s health status depends on, as well as any pertinent equipment or device history Functional Status Data defining the patient’s functional status with respect to, ambulatory ability, mental status or competency, activities of daily living, including bathing, dressing, feeding, grooming, home/living situation having an effect on the health status of the patient, and ability to care for self EHR SD RM - EHR Way Forward … Future State Reference Architecture Plan of Care Slide 13 The plan of care contains data defining prospective or intended orders, interventions, encounters, services, and procedures for the patient

Functional Analysis Object Analysis Requirements Analysis EHR Future State Reference Architecture … EHR Way Forward Business Architecture Specification Framework Service Interface Analysis Design EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 14

Architecture Adding ARRA and FHIMS For Project Information, see http: //hssp. wikispaces. com/Reference+Archit ecture EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 15

Value Proposition of Standards Based Approach q Analysis Pre-Done: Analysts from throughout industry have vetted and contributed to the development of thorough specifications q Less Customization: COTS vendors are already building applications to meet these specifications. q Comprehensive View: Standards provide a way to ensure that requirements and design address all of the necessary issues q Lack of unexpected dependencies late in project: All functions and specifications have been pre-analyzed and defined q Better Interoperability: Standards based approaches will ensure development between all stakeholders are able to communicate at the project and technical level EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 16

PART II: HL 7 SAEAF, Requirements Management and Governance • The HL 7 Services-Aware Enterprise Architecture Framework (SAEAF) • HL 7 SAEAF ECCF Specification Stack • HITSP Within HL 7 SAEAF ECCF Specification Stack • HL 7, HITSP, FHIMS and NHIN Within HL 7 SAEAF ECCF Specification Stack • Business Capability Lifecycle (BCL) • Develop/ Update Reference Architecture • Requirements Management Process • BACKUP SLIDES: Example (Immunization and Adverse Event Reporting) EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 17

The HL 7 Services-Aware Enterprise Architecture Framework (SAEAF) SAEAF Contains: q Enterprise Conformance and Compliance Framework (ECCF) is based on RM-ODP q Behavioral Framework (BF) – Interoperability Scenarios supporting the RM-ODP Computational Viewpoint q Governance Framework (GF) – Governance is the overarching policy structure and set of related processes by which a group exercises its authority and demonstrates accountability for accepted responsibilities within a particular jurisdiction. SAEAF Principles: q Applicable within each of HL 7’s three Interoperability Paradigms (IPs), – (i. e. , messages, documents, and services). q Provide support for measurable conformance and compliance. q Define appropriate governance structures and processes. q Provide support for directly implementable solutions. q Address the growing disparity between the various solution sets emerging from HL 7. EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 18

HL 7 SAEAF Conformance and Compliance Framework (ECCF) Specification Stack Views Policy Content Behavior Implementation Traceable Consistency EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 19

HITSP Within HL 7 SAEAF ECCF Specification Stack Specification Enterprise / Business View “WHY” Information View “WHAT” Business Context, Reference Context Topic Domain Analysis (Information) Model HITSP IS HITSP DA HITSP CAP Policy Conceptual Platform. Independent HITSP Harmonizatio n Framework Rules, Procedures Platform. Specific Behavior Harmonization Collaboration Analysis, Functional Profile(s), Service Roles and Requests/ Use Relationships Case Engineering View “WHERE” Implementation Existing Platform capabilities HITSP CAP Project-oriented Domain Information Model, Constrained Information Model, Localized Information Model, Hierarchical Message Definition Collaboration Types, Interface Specification and Functional Groups, Interaction Types and Collaboration Participations, Contracts Parts Existing Platform models, libraries, etc. Localized Information Model, Transforms, Schema Collaboration scripts, Orchestrations, Realized Interfaces Execution Context, Platform Bindings, Deployment Model HITSP C HITSP T, TP and SCs EHR-S FM is EHR System Functional Model EHR SD RM is EHR System Design Reference Model RIM is Reference Information Model FHIMS is Federal Health Information Model & Standards DA is Data Architecture Consistency EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 20 20 Traceable Business Governance Content Computational View “HOW”

HL 7, HITSP, FHIMS and NHIN Within HL 7 SAEAF ECCF Specification Stack Topic Specification Conceptual Enterprise / Business View “WHY” Policy Business Context, Reference HL 7 EHR-S Context FM Information View “WHAT” Content Domain Analysis (Information) Model Independent Platform. Specific Project-oriented Domain Information Model, Constrained Information Model, Localized Information Model, Hierarchical Message Definition Rules, Procedures Platform- Business Governance HL 7 EHRIS HITSP SD RM HITSP Harmonizatio n Framework Localized Information Model, Transforms, Schema HITSP C Engineering View “WHERE” Specification and Functional Groups, Interaction Types and Collaboration Participations, Contracts Parts libraries, etc. Behavior Implementation Tomcat, Harmonization Collaboration Analysis, Functional Existing Platform capabilities Profile(s), Service Roles and JBoss, J 2 SE, Requests/ Use Relationships Eclipse, Case Glass. Fish ESB, Open. SSO HITSP CAP Collaboration Types, Interface Existing Platform models, HITSP T, TP and SCs Collaboration scripts, Orchestrations, Realized Interfaces NHIN Connect Services Execution Context, Platform Bindings, Deployment Model EHR-S FM is EHR System Functional Model EHR SD RM is EHR System Design Reference Model RIM is Reference Information Model FHIMS is Federal Health Information Model & Standards DA is Data Architecture Consistency EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 21 21 Traceable HL 7 RIM FHA FHIMS HITSP DA HITSP CAP Computational View “HOW”

HITSP and Immunization Use Case # Capability 1 Standards Org 2 Service Specification 3 Standards Org 4 5 6 7 Service Specification Profile Org SOA Profile Org Patient Identification Data Retrieval and Update HL 7 Retrieve, Locate, Update SFM OMG Identification Service Specification Decision Support SFM Retrieve, Locate, Update Spec IHE SOA White Paper IHE Identification Service Functional Model Decision Support Service Spec Immunization Content (IC) Query for Existing Data (QED) PIX/PDQ 8 Immunization Profile 9 Profile Org 10 Immunization Profile 11 Immunization Profile 12 Standards Org 13 Original Standard SC 110 CAP 123 SC 113 PIX/PDQ SC 110 Draft: 2. 5 Impl Guide 2. 3. 1 Impl Guide CAP 131 CAP 132 SC 115 CAP 119 CAP 133 SC 112 Request for Clinical Guidance CAP 133 (IC payload) American Immunization Registry Association/CDC Draft: 2. 5 Impl Guide 2. 3. 1 Impl Guide CAP 131 CAP 132 SCII 5 V 3 Care Record messaging V 3 POIZ messaging HL 7 V 2 V 3 Patient Admin messaging V 2 V 3 Care V 3 (POIZ) Record Immunization V 3 Care messaging Record CDA EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 22

Immunization Use Case - Simplified # Capability Patient Identification Data Retrieval and Update 1 Standards Org 2 Service Specification HL 7 Identification Service Functional Model Retrieve, Locate, Update SFM 3 Standards Org 4 5 6 7 Service Specification Profile Org SOA Profile Org 13 Original Standard Decision Support SFM OMG Identification Service Specification PIX/PDQ 8 Immunization Profile 12 Standards Org Decision Support SC 110 V 2 Decision Support Service Spec Retrieve, Locate, Update Spec IHE SOA White Paper IHE/American Immunization Registry Association/CDC Query for Immunization Existing Content (IC) Request for Clinical Data (QED) CAP 119 Guidance Future PIX/PDQ Draft: 2. 5 CAP 123 CAP 133 SC 112 SC 110 Impl Guide SC 113 (IC payload) HL 7 V 3 Patient Admin messaging V 2 V 3 Care Record V 3 Care messaging Record CDA EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 23 V 3 Care Record messaging

Immunization Use Case Within HL 7 SAEAF ECCF Specification Stack # Patient Identification Service Functional Model Identification Service Specification PIX/PDQ SC 110 Retrieve, Locate, Update Spec Decision Support Service Spec Query for Immunization Content (IC) Existing Data (QED) CAP 119 Future Draft: CAP 133 PIX/PDQ 2. 5 Impl CAP 123 SC 110 SC 113 SC 112 Guide Request for Clinical Guidance CAP 133 (IC payload) Implementation View (Vendor Implementations) 7 8 9 Decision Support SFM Information View (Payloads) 5 6 Retrieve, Locate, Update SFM Computational View (Service Definitions) 3 4 Decision Support Enterprise View (Service Functional Models) 1 2 Data Retrieval and Update V 2 V 3 Patient Admin msg V 2 Base Standard V 3 Care Record msg Record CDA EHR SD RM - EHR Way Forward … Future State Reference Architecture V 3 Care Record mesg Slide 24

Service Definition Ref: A Service-Oriented Architecture (SOA) View of IHE Profiles IHE 2009 EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 25

Meet in the Middle* *Anna Orlova, Josh Painter, Alean Kirnak, “A SOA View of IHE Profiles” working drafts Copyright 2009 EHR SD RM - EHR Way Forward … Future State Reference Architecture Software Partners LLC Slide 26 26

Cost Effectiveness Proposition q Target cost function of healthcare IT connectivity # of service consumers * # of services EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 27

Cost Effectiveness Proposition q Target cost function of healthcare IT connectivity # of service consumers * # of services EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 28

Point to Point Messaging Economics q Approximately 75 U. S. Immunization Information Systems (IISs) q Completely connected point-to-point IIS network: 74 * 75 / 2 = 2775 connections q Assume 200 regional provider EHRs per IIS: 200 * 75 = 15, 000 connections q Each connection costs $10 K-$30 K per side q $40 K each * 17, 775 =$711, 000 Copyright 2009 EHR SD RM - EHR Way Forward … Future State Reference Architecture Software Partners Slide 29 29

Expand to Multiple Domains q q q Labs Meds Allergies Cancer Registries Joint Replacement Registries Chronic Disease Registries Adverse Event Reporting …etc. Intra-enterprise communication Provider-to-Provider communication. . . 100 domains increases cost to $71, 100, 000 Copyright 2009 EHR SD RM - EHR Way Forward … Future State Reference Architecture Software Partners Slide 30 30

Growth of Points of Care q q Schools Drug stores Airports … Copyright 2009 EHR SD RM - EHR Way Forward … Future State Reference Architecture Software Partners Slide 31 31

Growth of Personal Health Records q q Tethered Untethered Wireless devices … Copyright 2009 EHR SD RM - EHR Way Forward … Future State Reference Architecture Software Partners Slide 32 32

How to Solve? q Bus architecture q Plug-and-play connections q Common information model Copyright 2009 EHR SD RM - EHR Way Forward … Future State Reference Architecture Software Partners Slide 33 33

Cost Reduction Opportunities q Bus architecture – Build common carrier once – hide routing, translation q Plug and play connections – Eliminates cost on one side of each connection q Common information model – Allows multiple platform-specific models for a single platform-independent model Copyright 2009 EHR SD RM - EHR Way Forward … Future State Reference Architecture Software Partners Slide 34 34

Cost Reduction Opportunities q 75 IISs each accessing one service q 15, 000 EHRs, 500 products @ 30 installations ea = 500 connections q Cost @$20 K is per service consumer only $20 K * (500 + 75) =$11, 500, 000 + cost of carrier q Drive down the $20 K Copyright 2009 EHR SD RM - EHR Way Forward … Future State Reference Architecture Software Partners Slide 35 35

Meaningful Use Rules and Regs # Capability 1 Standards Org 2 3 4 5 6 7 Patient Identification Data Retrieval and Update HL 7 Retrieve, Locate, Update SFM OMG Identification Service Specification Functional Model Standards Org Identification Service Specification Profile Org SOA Profile Org Decision Support SFM Decision Support Service Spec Retrieve, Locate, Update Spec IHE SOA White Paper IHE Query for Immunization Existing Content (IC) Request for Data Clinical CAP 119 (QED) Guidance CAP 123 CAP 133 (IC PIX/PDQ SC 113 SC 112 8 Immunization Profile SC 110 payload) 9 Profile Org American Immunization Registry Association/CDC Draft: 2. 5 10 Immunization Profile Impl Guide 2. 3. 1 Impl Guide 11 Immunization Profile 12 Standards Org 13 Original Standard CAP 131 CAP 132 SC 115 V 2 V 3 Patient Admin msg CAP 131 CAP 132 SCII 5 V 2 HL 7 V 3 (POIZ) V 3 Care Immunization V 3 Care Record msg Record CDA EHR SD RM - EHR Way Forward … Future State Reference Architecture V 3 Care Record messaging V 3 POIZ messaging Slide 36

Proposed Meaningful Use Comments q Propose use of service interfaces to satisfy need for transport layer standards for immunizations q Fill gaps in immunization standards – Include immunizations in medical summary – Use CAP 133 Immunization Content in Table 2 A – Include immunizations in decision support clauses q Note the immunization use case includes patient identification EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 37

Proposed 2. 5. 1 Immunization Guide Changes q Clarify use of HITSP and IHE constructs q Consider a service definition that combines PIX/PDQ and IZ data retrieval and update into a composed service EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 38

Topics for Discussion EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 39

Business Capability Lifecycle (BCL) KEY PROCESS RED indicates where HL 7 and HITSP artifacts can be used EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 40

BCL Develop/ Update Reference Architecture RED indicates where HL 7 and HITSP artifacts can be used EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 41

Requirements Management Process EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 42

Prototype q Vaccination and Adverse Event Reporting Prototype – AHIC Use Cases – EHR-S FM – HITSP Capabilities – Information Model EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 43

EHR-SD RM Prototype Requirements from 2008 AHIC Use Cases q Use Case 1: Immunization and Response Management (IRM) and q Use Case 2: Public Health Case Reporting (PHCR) – The IRM AHIC Use Case and HITSP Interoperability Specification are intended to support current interoperability approaches between EHRs and Immunization Information Systems while allowing for a migration toward emerging interoperability implementations and document sharing environments where PHRs are able to be included in the information flow – The Interoperability Specification also allows for basic electronic information exchanges to enable requirement communications and alerting mechanisms and to lay the foundation for future clinical support capabilities – The Public Health Case Reporting AHIC Use Case and HITSP Interoperability Specification supports the bi-directional information exchanges of the Public Health Case Reporting process – The Public Health Case Reporting Use Case addresses numerous domains which have similar content and processes at a high level, but which also are dissimilar in report content details and case management processes when EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 44

EXAMPLE ARTIFACT: Vaccine and Drug Administration and Reporting Information Exchanges EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 45 45

EXAMPLE ARTIFACT Vaccine and Drug Administration and Reporting Use Case Full use case available at: http: //healthit. hhs. gov/portal/server. pt? open=512&obj. ID=1255&parentname=Community. Page&parentid=1&mode=2&in_hi_userid=10 741&cached=true EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 46

EHR-SD RM Prototype Information Exchange Requirements (IERs) Use Case 1: Immunization and Response Management (IRM) q q q IER 10 Identify patient IER 13 Send/receive notification of document availability IER 18 Send/receive clinical document IER 26 Identify communication recipients IER 27 Send non-patient notification message or alert Blue Italics indicates IERs, which are common to 1 IRM and 2 -PHCR IER 40 Query for existing data IER 42 Request/receive medical concept knowledge IER 54 Query/response for clinical message data IER 67 Send/receive clinical message IER 78 Send/receive Vaccine Inventory Requirements IER 79 Query/response for inventory usage data For details, see HITSP IS 10 Immunization and Response Management, available at www. HITSP. org IER 80 Send/receive Vaccine Inventory Data EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 47

q q q q EHR-SD RM Prototype Data Requirements (DRs) Use Case 1: Immunization and Response Management (IRM) DR 08 Unstructured Data DR 11 Immunization response data DR 12 Adverse Event Report DR 13 Drug/Vaccine Inventory Data DR 14 Drug/Vaccine Inventory Usage Data DR 15 Drug/Vaccine Inventory Availability Data DR 16 Supply Chain Management Vaccine Recall DR 17 Decision Support Data DR 18 Vaccination Data DR 19 Medication Administration data DR 20 Aggregate Inventory of Available Vaccine Blue Italics indicates common across IRM and PHCR DR 21 Terminology Data For details, see HITSP IS 10 Immunization and Response Management, available at www. HITSP. org DR 22 Generic Alert Data DR 23 Consumer Vaccination View EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 48

EHR-SD RM Prototype IRM Information Exchange Requirements (IERs) Use Case 2: Public Health Case Reporting (PHCR) q IER 10 Identify patient q IER 13 Send/receive notification of document availability q IER 18 Send/receive clinical document q IER 26 Identify communication recipients q IER 27 Send non-patient notification message or alert q IER 29 Send/receive electronic form for data capture q IER 40 Query for existing data q IER 42 Request/receive medical concept knowledge q Blue Italics indicates common across 1 -IRM and 2 -PHCR For details, see HITSP IS 10 Immunization and Response Management, available at www. HITSP. org IER 49 Report confirmation EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 49

EHR-SD RM Prototype Data Requirements (DRs) Use Case 2: Public Health Case Reporting (PHCR) q DR 08 Unstructured Data q DR 17 Decision Support Data q DR 21 Terminology Data q DR 24 Case Report Pre-populate Data q DR 22 Generic Alert Data q DR 23 Consumer Vaccination View q DR 24 Case Report Pre-populate Data q DR 25 Case Report Content q DR 26 Reporting Criteria Content q DR 59 Generic Alert Data EHR SD RM - EHR Way Forward … Future State Reference Architecture Blue Italics indicates common across IRM and PHCR For details, see HITSP IS 10 Immunization and Response Management, available at www. HITSP. org Slide 50

EHR-SD RM Prototype Information Exchange Requirements (IERs) HITSP Security and Privacy q IER 01 Provide authorization and consent q IER 02 Send data over secured communication channel q IER 03 Create audit log entry q IER 04 Synchronize system time q IER 05 Verify entity identity q IER 06 Provide proof of document integrity and origin q IER 55 Anonymize patient identifiable data q IER 56 Pseudonymize patient identifying information EHR SD RM - EHR Way Forward … Future State Reference Architecture Blue Italics indicates common across IRM and PHCR For details, see HITSP IS 10 Immunization and Response Management, available at www. HITSP. org Slide 51

EXAMPLE ARTIFACT HL 7 Requirements and Certification Criteria and HITSP Design HL 7 EHR System Functional Model HITSP Interoperability Specifications EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 52

EXAMPLE ARTIFACT EHR-S Requirements EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 53

EXAMPLE ARTIFACT EHR-S FM Dependencies EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 54

EXAMPLE ARTIFACT HITSP Interoperability Design Specifications EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 55

Sample HITSP C 83 Data Modules Immunizations Data Mapping Table – Requirements CDA Data Location cda: substance. Administration[cda: template. Id/@root = '2. 16. 840. 1. 113883. 10. 20. 1. 24'] HITSP Data Element Identifier and Name O/R[1] Additional Specificatio n Immunization Event Entry See Below[2] @negation. Ind 13. 01 - Refusal R/N cda: effective. Time 13. 02 - Administered Date O/N cda: entry. Relationship [@type. Code='SUBJ']/ cda: observation/cda: value 13. 03 - Medication Series Number cda: entry. Relationship[@type. Code='CAUS']/ 13. 04 - Reaction O/N O/Y cda: observation[cda: template. Id/@root= ’ 2. 16. 840. 1. 113883. 10. 20. 1. 54’] cda: performer/cda: assigned. Entity 13. 05 - Performer O/N cda: consumable/cda: manufactured. Product Medication Information R/Y 13. 06 - Coded Product cda: manufactured. Material/cda: code/@code Name R 2/Y cda: original. Text cda: manufacturer. Organization 13. 07 - Free Text Product Name R/N 13. 08 - Drug Manufacturer O/N cda: manufactured. Material/ 13. 09 - Lot Number EHR SD RM - EHR Way Forward … Future State Reference Architecture R 2/N Slide 56 2. 2. 2. 13. 1

Sample of Standards used within HITSP Components within IS 10 1. Standard: 2. Accredited Standards Committee (ASC) X 12 Standards Release 004010 HITSP/C 80 - Clinical Document and Message Terminology American Medical Association (AMA) Current Procedural Terminology (CPT®) Fourth Edition (CPT-4); CPT Evaluation and Management Codes HITSP/C 80 - Clinical Document and Message Terminology ASTM International Standard Guide for Electronic Authentication of Health Care Information: # E 1762 -95 (2003) HITSP/C 26 - Nonrepudiation of Origin CDC Race and Ethnicity Code Sets HITSP/C 80 - Clinical Document and Message Terminology Center for Disease Control and Prevention Implementation Guide for Immunizations Data Transaction using Version 2. 3. 1 of the Health Level Seven (HL 7) Standard Protocol. Implementation Guide Version 2. 2 June 2006 HITSP/C 70 - Immunization Query and Response, HITSP/C 72 - Immunization Message, HITSP/C 80 - Clinical Document and Message Terminology Digital Imaging and Communications in Medicine (DICOM) Part 3. 12: Media Formats and Physical Media for Media Interchange HITSP/T 33 - Transfer of Documents on Media European Telecommunications Standards Institute (ETSI) Technical Specification TS 101 903: XML Advanced Electronic Signatures (Xad. ES) HITSP/C 26 - Nonrepudiation of Origin Federal Information Processing Standards (FIPS) Codes for the Identification of the States, the District of Columbia and the Outlying Areas of the United States, and Associated Areas Publication # 5 -2, May, 1987 HITSP/C 80 - Clinical Document and Message Terminology Food and Drug Administration (FDA) - Unique Ingredient Identifier (UNII) HITSP/C 80 - Clinical Document and Message Terminology Food and Drug Administration (FDA) - National Drug Code (NDC) HITSP/C 80 - Clinical Document and Message Terminology Health Care Provider Taxonomy HITSP/C 80 - Clinical Document and Message Terminology Health Level Seven (HL 7) Clinical Document Architecture (CDA) Release 2. 0 HITSP/C 78 - Immunization Document, HITSPC 83 - CDA Content Modules Health Level Seven (HL 7) Common Terminology Services (CTS) Release 1 HITSP/T 66 - Retrieve Value Set Health Level Seven (HL 7) Implementation Guide for CDA Release 2: History and Physical (H&P) Notes HITSP/C 83 - CDA Content Modules Health Level Seven (HL 7) Implementation Guide for CDA Release 2: Consultation Note HITSP/C 83 - CDA Content Modules Health Level Seven (HL 7) Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD), April 01, 2007 HITSP/C 83 - CDA Content Modules Health Level Seven (HL 7) Standard Code Set CVX - Vaccines Administered HITSP/C 80 - Clinical Document and Message Terminology Health Level Seven (HL 7) Standard Code Set MVX - Manufacturers of Vaccines HITSP/C 80 - Clinical Document and Message Terminology Health Level Seven (HL 7) V 3 RBAC, R 1 -2008, HL 7 Version 3 Standard: Role Based Access Control (RBAC) Healthcare Permissions Catalog, Release 1, February 2008, HITSP/TP 20 - Access Control EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 57 Health Level Seven (HL 7) Version 2. 3. 1 HITSP/C 70 - Immunization Query and Response 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. HITSP Construct

Basic UML Legend EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 58

Abbreviations q B-Case is Business Case q BPM is Business Process Model q CCD is Continuity of Care Document q CCHIT is Certification Commission for Health Information Technology q CDRL is Contract Deliverable q DBT is Defense Business Transformation q IHE is Integrating the Healthcare Enterprise q NHIN is National Health Information Exchange q PCC is Patient Care Coordination q RM-ODP is Reference Model of Open Distributed Processing q SOA is Service Oriented Architecture EHR SD RM - EHR Way Forward … Future State Reference Architecture Slide 59