From HL7 and HITSP Artifacts HL7 “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 HL7 and HITSP Artifacts For presentation at HL7 Phoenix Workgroup Meeting, January 2010 Details available at www.HSSP.wikispaces.com/Reference+Architecture Nancy.Orvis@tma.osd.mil, Chief of Integration & Interoperability Stephen.Hufnagel.ctr@tma.osd.mil, Architect & System Engineer Alean Kirnak, President, Software Partners

Federal Enterprise Architecture (FEA) www.whitehouse.gov/omb/egov 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 the 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. 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. 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. 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. 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 serves as the foundation to advance the re-use of technology and best practices from each of the Service Components on a government-wide basis.

EHR-SD RM Project Description and Plan PROJECT DESCRIPTION: HL7 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 HL7 Architecture Review Board (ArB) consideration, and then integrate it into an EHR System Design Reference Model (EHR-SD RM), using the HL7 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 HL7 product portfolio against the EHR-S FM will be used to integrate the reference architecture with HL7 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 EHR SD RM Framework Populate the framework with HL7 EHR-S Functional Model content, candidate healthcare Information Exchanges, HITSP capabilities/ services and data architecture Information Model Loosely-coupled top-down Framework Rigorously specified bottom up structure/ content based on HITSP Data Architecture Socialize EHR SD RM (HL7 Meeting, Jan 2010) Collaborate with others within HL7 (ongoing) Publish HL7 HSSP Practical Guide for SOA in Healthcare Part 2: Case Study (May 2010) Solicit public comment; collaborate with IHE; HL7/OMG SOA Conference (May to Sept) HL7 Informative ballot (Oct 2010) HL7 Normative ballot (Oct 2011) 1 - Populate a framework of candidate healthcare services, with IERs, based on SAEAF service categories Define priority Information Exchange Requirements (IERs) Define priority Data Requirements (DRs) along with IERs Map IERs and DRs to the framework of candidate healthcare services Build Catalog of candidate Services from 2008 H-SOA-RA work Show AHIC-HITSP traceability (e.g., AHIC IERs to HITSP ISs to standards) Show NHIN traceability (align with NHIN services) Show CCHIT traceability (align with CCHIT test criteria) Compare and contrast framework of candidate healthcare services with Canada Infoway’s SOA and/or other SOA 2 - Define EHR-SD RM Map Priority IERs and DRs to EHR-S FM Map candidate services to EHR-S FM Define EHR-SD RM based Business Transformation Architecture methodology for Identify gaps and overlaps in HL7’s portfolio Identify artifacts that do not now exist but are indicated in the EHR-S FM Identify the extent of duplication that may exist across HL7 artifacts 3 - Create prototype EHR-SD RM validation case study prototype, using AHIC-HITSP Public Health and Emergency Response use cases and Interoperability Specifications Services Aware Enterprise Architecture Framework (SAEAF) HITSP Multi-Enterprise Architecture of Networked Services Standards (MEANS) and HL7 HSSP Practical Guide for SOA in Healthcare “sample health” example specifications Include mapping to MHS and DOD specific IERs and DRs Publish HL7 HSSP Practical Guide for SOA in Healthcare Part 2: Case Study To show HITSP, NHIN and CCHIT conformance criteria, use OMG Object Constraint Language and/or OWL Semantic Ontology specification language

Linking Business and Technical Architectures

Contents Constructing a Future State EHR Reference Architecture HL7 EHR System Functional Model (EHR-S FM) Healthcare SOA Reference Framework HL7 RIM (Reference Information Model) HITSP Harmonization Framework HITSP Constructs HITSP Data Architecture HITSP Clinical Document Components HITSP/C83 Data Module Categories EHR Way Forward Business Architecture Specification Framework Future State EHR Reference Architecture Adding ARRA and FHIM Basic UML Legend Abbreviations PART II: HL7 SAEAF, Requirements Management Process and Governance PROTOTYPE: Immunization and Adverse Event Reporting

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, HL7’s System Functional Model (EHR-S FM) and HL7’s Reference Information Model (RIM). A Health IT EHR BA can be modeled as clinical stakeholder requirements and their workflow-orchestration of HL7 RIM compliant HITSP data modules manipulated by HL7 EHR-S FM functions. 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 HL7 RIM Entity, Role and Action foundation classes. These concepts are the topic of this presentation

HL7 EHR System Functional Model (EHR-S) > 160 System Functions in 4 level categorization (separate spreadsheet available for full enumeration) 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). System Functions Other O-1 Electronic Resource Planning (ERP) O-2 Finances O-3 Other 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. 6

Healthcare SOA Framework Based on HL7 EHR System Functional Model & Thomas Erl’s SOA Layers HL7 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 Functional Areas + Focal Classes Entity Information Management 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 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 Profiles Communications Profiles/Stacks Implementation Profiles Re: Focal Classes:  The issue is less the idea of a focal class than a business focal class. The difference is that when you model the service, you are generally modeling a service that will express the state changes of a business. For example, via analysis, you would find the states of a business focal class (canceled, new, active, signed, finalized in lab orders for example) and the trigger events that would correspond to state changes ("a lab is ordered", "a lab is canceled", "a lab specimen is corrupted", and so on).  You could say that a "patient" is a focal class, but a patient ID service generally doesn't express operations to modify the state of that "object". Rather, a patientID service would generally encompass operations that would express information about the class (reconcileID or lookUpID, eg) rather than tying the service functional components to changes in the state of that class.  It is not a subtle distinction - most clinical domains are focused on a focal class (an order, an encounter, an appointment, a schedule, a lab). A business service is focused with exposing that class to the enterprise.  Infrastructure services (or the subset information services) are generally function calls or based on exposing sets of information. The functional profiles of the service are generally not focused on the state of the underlying information or in the trigger events that modify the state of that information. They tend to be focused along different lines - typically along the lines of an information profile (a RIM-based patient class, eg, or a CDA-based CCD).   The focal class is explicit in a business service, generally implicit in other services. 7 7

HL7 RIM (Reference Information Model) Six Core Classes Defining a Semantic Framework which Maintains Clinical Data Context ENTITY ROLE ACT (aka ACTION) Participation Role link Act relationship 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. 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. Language / communication The HL7 RIM supports EHR interoperability; an EHR may needs additional foundation classes (e.g., Responsibility)

HITSP Constructs A HITSP Interoperability Specification (IS) defines a business context, supports a business workflow, constrains and orchestrates underlying constructs. 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. A HITSP Service Collaboration (SC) binds communications infrastructure, security and privacy constructs together. HITSP Transaction Packages/ Transactions/ Components (TP/T/Cs) are where standards-based Interface Design Specifications are specified are given and conformance requirements are defined.

HITSP Harmonization Framework IS = Interoperability Specification IS Capability Service Collaboration Transaction, Transaction Package Components Addressing Business Needs Available for Independent Implementation Providing Infrastructure, Security, Privacy Defining Information Content Data Architecture

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

HITSP Clinical Document Components HITSP Reuse Paradigm: With HITSP/Capability 119 - Communication of Structured Documents, a HL7 Clinical Data Architecture (CDA) document can be composed, from any group of C83 data modules, and then it can be communicated. Benefit: agile system interoperability.

HITSP/C83 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 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 Payers 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, 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 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 Plan of Care The plan of care contains data defining prospective or intended orders, interventions, encounters, services, and procedures for the patient

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

EHR Future State Reference Architecture Adding ARRA and FHIMS For Project Information, see http://hssp.wikispaces.com/Reference+Architecture Slide 15

Value Proposition of Standards Based Approach Analysis Pre-Done: Analysts from throughout industry have vetted and contributed to the development of thorough specifications Less Customization: COTS vendors are already building applications to meet these specifications. Comprehensive View: Standards provide a way to ensure that requirements and design address all of the necessary issues Lack of unexpected dependencies late in project: All functions and specifications have been pre-analyzed and defined Better Interoperability: Standards based approaches will ensure development between all stakeholders are able to communicate at the project and technical level Across Project Visibility: Normalized requirements and design would allow for “apples to apples” comparison across the portfolio

PART II: HL7 SAEAF, Requirements Management and Governance The HL7 Services-Aware Enterprise Architecture Framework (SAEAF) HL7 SAEAF ECCF Specification Stack HITSP Within HL7 SAEAF ECCF Specification Stack HL7, HITSP, FHIMS and NHIN Within HL7 SAEAF ECCF Specification Stack Business Capability Lifecycle (BCL) Develop/ Update Reference Architecture Requirements Management Process BACKUP SLIDES: Example (Immunization and Adverse Event Reporting)

The HL7 Services-Aware Enterprise Architecture Framework (SAEAF) SAEAF Contains: Enterprise Conformance and Compliance Framework (ECCF) is based on RM-ODP Behavioral Framework (BF) Interoperability Scenarios supporting the RM-ODP Computational Viewpoint 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: Applicable within each of HL7’s three Interoperability Paradigms (IPs), (i.e., messages, documents, and services). Provide support for measurable conformance and compliance. Define appropriate governance structures and processes. Provide support for directly implementable solutions. Address the growing disparity between the various solution sets emerging from HL7. Utilize existing V3/RIM artifacts and expertise to the maximum degree possible.

HL7 SAEAF Conformance and Compliance Framework (ECCF) Specification Stack Views Policy Content Behavior Implementation Traceable Consistency

HITSP Within HL7 SAEAF ECCF Specification Stack Topic Specification Enterprise / Business View “WHY” Information View “WHAT” Computational “HOW” Engineering “WHERE” Conceptual Business Context, Reference Context Domain Analysis (Information) Model Collaboration Analysis, Functional Profile(s), Service Roles and Relationships Existing Platform capabilities Platform- Independent Business Governance 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. Specific Rules, Procedures Localized Information Model, Transforms, Schema Collaboration scripts, Orchestrations, Realized Interfaces Execution Context, Platform Bindings, Deployment Model Policy Content Behavior Implementation HITSP IS HITSP DA HITSP CAP Harmonization Requests/ Use Case HITSP CAP HITSP Harmonization Framework HITSP C HITSP T, TP and SCs Traceable 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 20

HL7, HITSP, FHIMS and NHIN Within HL7 SAEAF ECCF Specification Stack Topic Specification Enterprise / Business View “WHY” Information View “WHAT” Computational View “HOW” Engineering “WHERE” Conceptual Business Context, Reference Context Domain Analysis (Information) Model Collaboration Analysis, Functional Profile(s), Service Roles and Relationships Existing Platform capabilities Platform- Independent Business Governance 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. Specific Rules, Procedures Localized Information Model, Transforms, Schema Collaboration scripts, Orchestrations, Realized Interfaces Execution Context, Platform Bindings, Deployment Model Policy Content Behavior Implementation HL7 EHR-S FM HITSP IS HL7 RIM FHA FHIMS HITSP DA HITSP CAP Harmonization Requests/ Use Case HITSP CAP Tomcat, JBoss, J2SE, Eclipse, GlassFish ESB, OpenSSO HL7 EHR SD RM HITSP Harmonization Framework HITSP C HITSP T, TP and SCs NHIN Connect Services Traceable 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 21

HITSP and Immunization Use Case # Capability Patient Identification Data Retrieval and Update Decision Support 1 Standards Org HL7 2 Service Specification Identification Service Functional Model Retrieve, Locate, Update SFM Decision Support SFM 3 OMG 4 Identification Service Specification Retrieve, Locate, Update Spec Decision Support Service Spec 5 Profile Org IHE 6 SOA Profile SOA White Paper 7 8 Immunization Profile PIX/PDQ SC110   Query for Existing Data (QED) CAP123 SC113 Immunization Content (IC) CAP119 CAP133 SC112 Request for Clinical Guidance CAP133 (IC payload) 9 American Immunization Registry Association/CDC 10 Draft: 2.5 Impl Guide 11 2.3.1 Impl Guide CAP131 CAP132 SC115 2.3.1 Impl Guide CAP131 CAP132 SCII5 12 13 Original Standard V2 V3 Patient Admin messaging V3 Care Record messaging V3 (POIZ) Immunization messaging V3 Care Record CDA V3 POIZ messaging

Immunization Use Case - Simplified # Capability Patient Identification Data Retrieval and Update Decision Support 1 Standards Org HL7 2 Service Specification Identification Service Functional Model Retrieve, Locate, Update SFM Decision Support SFM 3 OMG 4 Identification Service Specification Retrieve, Locate, Update Spec Decision Support Service Spec 5 Profile Org IHE 6 SOA Profile SOA White Paper 7 IHE/American Immunization Registry Association/CDC 8 Immunization Profile PIX/PDQ SC110 Future Draft: 2.5 Impl Guide Query for Existing Data (QED) CAP123 SC113 Immunization Content (IC) CAP119 CAP133 SC112 Request for Clinical Guidance CAP133 (IC payload) 12 13 Original Standard V2 V3 Patient Admin messaging V3 Care Record messaging V3 Care Record CDA

Immunization Use Case Within HL7 SAEAF ECCF Specification Stack # Patient Identification Data Retrieval and Update Decision Support 1 Enterprise View (Service Functional Models) 2 Identification Service Functional Model Retrieve, Locate, Update SFM Decision Support SFM 3 Computational View (Service Definitions) 4 Identification Service Specification Retrieve, Locate, Update Spec Decision Support Service Spec 5 Information View (Payloads) 6 PIX/PDQ SC110 Future Draft: 2.5 Impl Guide Query for Existing Data (QED) CAP123 SC113 Immunization Content (IC) CAP119 CAP133 SC112 Request for Clinical Guidance CAP133 (IC payload) 7 Implementation View (Vendor Implementations) 8 Base Standard 9 V2 V3 Patient Admin msg V3 Care Record msg V3 Care Record CDA V3 Care Record mesg

Service Definition Ref: A Service-Oriented Architecture (SOA) View of IHE Profiles IHE 2009

Meet in the Middle* *Anna Orlova, Josh Painter, Alean Kirnak, “A SOA View of IHE Profiles” working drafts Copyright 2009 Software Partners LLC

Cost Effectiveness Proposition Target cost function of healthcare IT connectivity # of service consumers * # of services

Cost Effectiveness Proposition Target cost function of healthcare IT connectivity # of service consumers * # of services

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

Expand to Multiple Domains 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,000 Copyright 2009 Software Partners

Growth of Points of Care Schools Drug stores Airports … Copyright 2009 Software Partners

Growth of Personal Health Records Tethered Untethered Wireless devices … Copyright 2009 Software Partners

How to Solve? Bus architecture Plug-and-play connections Common information model Copyright 2009 Software Partners

Cost Reduction Opportunities Bus architecture Build common carrier once hide routing, translation Plug and play connections Eliminates cost on one side of each connection Common information model Allows multiple platform-specific models for a single platform-independent model Copyright 2009 Software Partners

Cost Reduction Opportunities 75 IISs each accessing one service 15,000 EHRs, 500 products @ 30 installations ea = 500 connections Cost @$20K is per service consumer only $20K * (500 + 75) =$11,500,000 + cost of carrier Drive down the $20K Copyright 2009 Software Partners

Meaningful Use Rules and Regs # Capability Patient Identification Data Retrieval and Update Decision Support 1 Standards Org HL7 2 Service Specification Identification Service Functional Model Retrieve, Locate, Update SFM Decision Support SFM 3 OMG 4 Identification Service Specification Retrieve, Locate, Update Spec Decision Support Service Spec 5 Profile Org IHE 6 SOA Profile SOA White Paper 7 8 Immunization Profile PIX/PDQ SC110   Query for Existing Data (QED) CAP123 SC113 Immunization Content (IC) CAP119 CAP133 SC112 Request for Clinical Guidance CAP133 (IC payload) 9 American Immunization Registry Association/CDC 10 Draft: 2.5 Impl Guide 11 2.3.1 Impl Guide CAP131 CAP132 SC115 2.3.1 Impl Guide CAP131 CAP132 SCII5 12 13 Original Standard V2 V3 Patient Admin msg V3 Care Record msg V3 (POIZ) Immunization msg V3 Care Record CDA V3 Care Record messaging V3 POIZ messaging

Proposed Meaningful Use Comments Propose use of service interfaces to satisfy need for transport layer standards for immunizations Fill gaps in immunization standards Include immunizations in medical summary Use CAP133 Immunization Content in Table 2A Include immunizations in decision support clauses Note the immunization use case includes patient identification

Proposed 2.5.1 Immunization Guide Changes Clarify use of HITSP and IHE constructs Consider a service definition that combines PIX/PDQ and IZ data retrieval and update into a composed service

Topics for Discussion

RED indicates where HL7 and HITSP artifacts can be used Business Capability Lifecycle (BCL) KEY PROCESS RED indicates where HL7 and HITSP artifacts can be used

RED indicates where HL7 and HITSP artifacts can be used BCL Develop/ Update Reference Architecture RED indicates where HL7 and HITSP artifacts can be used

Requirements Management Process Slide 42

Prototype Vaccination and Adverse Event Reporting Prototype AHIC Use Cases EHR-S FM HITSP Capabilities Information Model

EHR-SD RM Prototype Requirements from 2008 AHIC Use Cases Use Case 1: Immunization and Response Management (IRM) and 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 considering any specific report

EXAMPLE ARTIFACT: Vaccine and Drug Administration and Reporting Information Exchanges

EXAMPLE ARTIFACT Vaccine and Drug Administration and Reporting Use Case Full use case available at: http://healthit.hhs.gov/portal/server.pt?open=512&objID=1255&parentname=CommunityPage&parentid=1&mode=2&in_hi_userid=10741&cached=true

Blue Italics indicates IERs, which are common to 1-IRM and 2-PHCR EHR-SD RM Prototype Information Exchange Requirements (IERs) Use Case 1: Immunization and Response Management (IRM) IER10 Identify patient IER13 Send/receive notification of document availability IER18 Send/receive clinical document IER26 Identify communication recipients IER27 Send non-patient notification message or alert IER40 Query for existing data IER42 Request/receive medical concept knowledge IER54 Query/response for clinical message data IER67 Send/receive clinical message IER78 Send/receive Vaccine Inventory Requirements IER79 Query/response for inventory usage data IER80 Send/receive Vaccine Inventory Data Blue Italics indicates IERs, which are common to 1-IRM and 2-PHCR For details, see HITSP IS 10 Immunization and Response Management, available at www.HITSP.org

Blue Italics indicates common across IRM and PHCR EHR-SD RM Prototype Data Requirements (DRs) Use Case 1: Immunization and Response Management (IRM) DR08 Unstructured Data DR11 Immunization response data DR12 Adverse Event Report DR13 Drug/Vaccine Inventory Data DR14 Drug/Vaccine Inventory Usage Data DR15 Drug/Vaccine Inventory Availability Data DR16 Supply Chain Management Vaccine Recall DR17 Decision Support Data DR18 Vaccination Data DR19 Medication Administration data DR20 Aggregate Inventory of Available Vaccine DR21 Terminology Data DR22 Generic Alert Data DR23 Consumer Vaccination View Blue Italics indicates common across IRM and PHCR For details, see HITSP IS 10 Immunization and Response Management, available at www.HITSP.org

Blue Italics indicates common across 1-IRM and 2-PHCR EHR-SD RM Prototype IRM Information Exchange Requirements (IERs) Use Case 2: Public Health Case Reporting (PHCR) IER10 Identify patient IER13 Send/receive notification of document availability IER18 Send/receive clinical document IER26 Identify communication recipients IER27 Send non-patient notification message or alert IER29 Send/receive electronic form for data capture IER40 Query for existing data IER42 Request/receive medical concept knowledge IER49 Report confirmation 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

Blue Italics indicates common across IRM and PHCR EHR-SD RM Prototype Data Requirements (DRs) Use Case 2: Public Health Case Reporting (PHCR) DR08 Unstructured Data DR17 Decision Support Data DR21 Terminology Data DR24 Case Report Pre-populate Data DR22 Generic Alert Data DR23 Consumer Vaccination View DR25 Case Report Content DR26 Reporting Criteria Content DR59 Generic Alert Data Blue Italics indicates common across IRM and PHCR For details, see HITSP IS 10 Immunization and Response Management, available at www.HITSP.org

Blue Italics indicates common across IRM and PHCR EHR-SD RM Prototype Information Exchange Requirements (IERs) HITSP Security and Privacy IER01 Provide authorization and consent IER02 Send data over secured communication channel IER03 Create audit log entry IER04 Synchronize system time IER05 Verify entity identity IER06 Provide proof of document integrity and origin IER55 Anonymize patient identifiable data IER56 Pseudonymize patient identifying information Blue Italics indicates common across IRM and PHCR For details, see HITSP IS 10 Immunization and Response Management, available at www.HITSP.org

EHR System Functional Model Interoperability Specifications EXAMPLE ARTIFACT HL7 Requirements and Certification Criteria and HITSP Design HL7 EHR System Functional Model HITSP Interoperability Specifications

EXAMPLE ARTIFACT EHR-S Requirements

EXAMPLE ARTIFACT EHR-S FM Dependencies

EXAMPLE ARTIFACT HITSP Interoperability Design Specifications

HITSP Data Element Identifier and Name Additional Specification Sample HITSP C83 Data Modules Immunizations Data Mapping Table – Requirements CDA Data Location HITSP Data Element Identifier and Name O/R[1] Additional Specification cda:substanceAdministration[cda:templateId/@root = '2.16.840.1.113883.10.20.1.24'] Immunization Event Entry See Below[2] @negationInd 13.01 - Refusal R/N cda:effectiveTime 13.02 - Administered Date O/N cda:entryRelationship [@typeCode='SUBJ']/ cda:observation/cda:value 13.03 - Medication Series Number cda:entryRelationship[@typeCode='CAUS']/ cda:observation[cda:templateId/@root= ’2.16.840.1.113883.10.20.1.54’] 13.04 - Reaction O/Y cda:performer/cda:assignedEntity 13.05 - Performer cda:consumable/cda:manufacturedProduct Medication Information R/Y cda:manufacturedMaterial/cda:code/@code 13.06 - Coded Product Name R2/Y 2.2.2.13.1 cda:originalText 13.07 - Free Text Product Name cda:manufacturerOrganization 13.08 - Drug Manufacturer cda:manufacturedMaterial/ cda:lotNumberText 13.09 - Lot Number R2/N cda:entryRelationship[@typeCode=’RSON’]/ cda:act[cda:templateId/@root= ’2.16.840.1.113883.10.20.1.27’] 13.10 - Refusal Reason 2.2.2.13.2

Sample of Standards used within HITSP Components within IS10 Standard: HITSP Construct Accredited Standards Committee (ASC) X12 Standards Release 004010 HITSP/C80 - Clinical Document and Message Terminology American Medical Association (AMA) Current Procedural Terminology (CPT®) Fourth Edition (CPT-4); CPT Evaluation and Management Codes HITSP/C80 - Clinical Document and Message Terminology ASTM International Standard Guide for Electronic Authentication of Health Care Information: # E1762-95 (2003) HITSP/C26 - Nonrepudiation of Origin CDC Race and Ethnicity Code Sets HITSP/C80 - 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 (HL7) Standard Protocol. Implementation Guide Version 2.2 June 2006 HITSP/C70 - Immunization Query and Response, HITSP/C72 - Immunization Message, HITSP/C80 - Clinical Document and Message Terminology Digital Imaging and Communications in Medicine (DICOM) Part 3.12: Media Formats and Physical Media for Media Interchange HITSP/T33 - Transfer of Documents on Media European Telecommunications Standards Institute (ETSI) Technical Specification TS 101 903: XML Advanced Electronic Signatures (XadES) HITSP/C26 - 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/C80 - Clinical Document and Message Terminology Food and Drug Administration (FDA) - Unique Ingredient Identifier (UNII) HITSP/C80 - Clinical Document and Message Terminology Food and Drug Administration (FDA) - National Drug Code (NDC) HITSP/C80 - Clinical Document and Message Terminology Health Care Provider Taxonomy HITSP/C80 - Clinical Document and Message Terminology Health Level Seven (HL7) Clinical Document Architecture (CDA) Release 2.0 HITSP/C78 - Immunization Document, HITSPC83 - CDA Content Modules Health Level Seven (HL7) Common Terminology Services (CTS) Release 1 HITSP/T66 - Retrieve Value Set Health Level Seven (HL7) Implementation Guide for CDA Release 2: History and Physical (H&P) Notes HITSP/C83 - CDA Content Modules Health Level Seven (HL7) Implementation Guide for CDA Release 2: Consultation Note HITSP/C83 - CDA Content Modules Health Level Seven (HL7) Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD), April 01, 2007 HITSP/C83 - CDA Content Modules Health Level Seven (HL7) Standard Code Set CVX - Vaccines Administered HITSP/C80 - Clinical Document and Message Terminology Health Level Seven (HL7) Standard Code Set MVX - Manufacturers of Vaccines HITSP/C80 - Clinical Document and Message Terminology Health Level Seven (HL7) V3 RBAC, R1-2008, HL7 Version 3 Standard: Role Based Access Control (RBAC) Healthcare Permissions Catalog, Release 1, February 2008, HITSP/TP20 - Access Control Health Level Seven (HL7) Version 2.3.1 HITSP/C70 - Immunization Query and Response Health Level Seven (HL7) Version 2.3.1 Chapter 2 – Control, Chapter 3 – Patient Administration HITSP/TP22 - Patient ID Cross-Referencing Health Level Seven (HL7) Version 2.5, Chapter 2 – Control, Chapter 3 – Patient Administration, Chapter 5 – Query HITSP/TP22 - Patient ID Cross-Referencing Health Level Seven (HL7) Version 2.5, Chapter 2 – Control, Chapter 3 – Patient Administration, Chapter 5 - Query HITSP/T23 - Patient Demographics Query Health Level Seven (HL7) Version 2.5.1 HITSP/C80 - Clinical Document and Message Terminology Health Level Seven (HL7) Version 3.0 - Vocabularies and Value Sets HITSP/C80 - Clinical Document and Message Terminology Health Level Seven (HL7) Version 3.0 Context-Aware Information Retrieval Specification: URL Implementation Guide HITSP/T81 - Retrieval of Medical Knowledge

Basic UML Legend

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