Slide 0 EHR SD RM - EHR Way Forward … Future State Reference Architecture 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 Rio Workgroup Meeting, 18 May 2010 Details available at Dir Health Stds Participation Architect & System Engineer Last Updated 26 March 2010

Slide 1 EHR SD RM - EHR Way Forward … Future State Reference Architecture Federal Enterprise Architecture (FEA)  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. Performance Reference Model  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. Business Reference Model  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. Service Component Reference Model  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. Data Reference Model  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. Technical Reference ModelService Oriented Architecture

Slide 2 EHR SD RM - EHR Way Forward … Future State Reference Architecture 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 (SAIF), 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. Phases: For Project Information, see 1.EHR SD RM Framework –Populate the framework with HL7 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 3.Socialize EHR SD RM (HL7 Meeting, Jan 2010) 4.Collaborate with others within HL7 (ongoing) 5.Publish HL7 HSSP Practical Guide for SOA in Healthcare Part 2: Case Study (May 2010) 6.Solicit public comment; collaborate with IHE; HL7/OMG SOA Conference (May to Sept) 7.HL7 Informative ballot (Oct 2010) 8.HL7 Normative ballot (Oct 2011)

Slide 3 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 HSSP Practical Guide for SOA in Healthcare Volume II: IRM Case Study __________ EHR SD RM Informative DSTU DSTU is Draft Standard for Trial Use (ANSI standards development) 2011 EHR SD RM Normative Standard

Slide 4 EHR SD RM - EHR Way Forward … Future State Reference Architecture Linking Business and Technical Architectures

Slide 5 EHR SD RM - EHR Way Forward … Future State Reference Architecture CONTENTS 2.Constructing a Future State EHR Reference Architecture 3.HL7 EHR System Functional Model (EHR-S FM) 4.Healthcare SOA Reference Framework 5.HL7 RIM (Reference Information Model) 6.HITSP Harmonization Framework 7.HITSP Constructs 8.HITSP Data Architecture 9.HITSP Clinical Document Components 10.HITSP/C83 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: HL7 SAIF, Requirements Management, Architecture and Governance Processes 16.PART III : Prototype (Immunization and Adverse Event Reporting)

Slide 6 EHR SD RM - EHR Way Forward … Future State Reference Architecture 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

Slide 7 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 8 EHR SD RM - EHR Way Forward … Future State Reference Architecture 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 8

Slide 9 EHR SD RM - EHR Way Forward … Future State Reference Architecture 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.

Slide 10 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 10

Slide 11 EHR SD RM - EHR Way Forward … Future State Reference Architecture IT PLATFORM SUPPORT ANALYTIC DATA MANAGEMENT PERFORMANCE DECISION SUPPORT RECORDS MANAGEMENT DOCUMENT SUPPLY CHAIN: (ORDERS/CHARGES) SCHEDULING AUTHORIZATION TERMINOLOGY IDENTITY RADIOLOGY LABORATORY PHARMACY CLINIC ASU TEST ONLY OUTPATIENT OTHER INPATIENT ER CARDIOLOGY PT/OT/SPEECH DIETARY SPECIALTY CARE Ancillary Systems Core Business Services INTEGRATED REQUIREMENTS DESIGNS: Putting the H-SOA-RA Pieces Together RESPIRATORY Federated Business Services Agnostic Services Federated Services, may be categorized by: -- Encounter Types -- CMS billing category -- Record type -- Care setting type -- etc. Data sets are defined for each system functional- capability-service module 11 Inter-Agency Inter-Service Across Providers

Slide 12 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 13 EHR SD RM - EHR Way Forward … Future State Reference Architecture 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.  A HITSP Transaction Package (TP), Transaction (T), Component (C) is where standards-based Interface Design Specifications are specified and conformance requirements are defined.

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

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

Slide 16 EHR SD RM - EHR Way Forward … Future State Reference Architecture HITSP Clinical Document Components HITSP Reuse Paradigm: With HITSP/Capability 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.

Slide 17 EHR SD RM - EHR Way Forward … Future State Reference Architecture HITSP/C83 Data Module Categories Module CategoryDescription 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 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

Slide 18 EHR SD RM - EHR Way Forward … Future State Reference Architecture Functional Analysis Object Analysis Requirements Analysis Interface Design Analysis Service Analysis EHR System Design Reference Model (EHR SD RM) Constructing a Future State EHR Reference Architecture

Slide 19 EHR SD RM - EHR Way Forward … Future State Reference Architecture 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

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

Slide 21 EHR SD RM - EHR Way Forward … Future State Reference Architecture 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

Slide 22 EHR SD RM - EHR Way Forward … Future State Reference Architecture PART II: HL7 SAIF, Requirements Management and Architectural Processes EHR SD RM within the Requirements and Architecture Development Cycle The HL7 Services-Aware Interoperability Framework (SAIF) HL7 SAIF ECCF Specification Stack HITSP Within HL7 SAIF ECCF Specification Stack HL7, HITSP, FHIMS and NHIN Within HL7 SAIF ECCF Specification Stack

Slide 23 EHR SD RM - EHR Way Forward … Future State Reference Architecture 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 Architecture Design Architecture Design Stakeholder Requirements Definition Stakeholder Requirements Definition Requirements Loop Verification & Validation Loop Design Loop PROCESS INPUTS -Required Capabilities -Environments -Constraints PROCESS OUTPUTS -System Architecture, -System & Test Specifications -Configuration Management Baselines Test Specifications Test Specifications Capabilities - Functions, Information Model Information Exchanges Functions – Dependencies Function or Service Interface Design Specifications Compliance means a system provides support for a given standard. Conformance is a recognition of formal testing, that prove that a system provides 100% support for a given standard. Conformance Criteria

Slide 24 EHR SD RM - EHR Way Forward … Future State Reference Architecture EHR SD RM Supporting Requirements/ Architecture Development Cycle Stakeholder Requirements – What is the system supposed to do? – Where will the products of the system be used? –Under what conditions will the products 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 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

Slide 25 EHR SD RM - EHR Way Forward … Future State Reference Architecture EHR SD RM Supporting Requirements & Architectural Processes 2010 slide

Slide 26 EHR SD RM - EHR Way Forward … Future State Reference Architecture The HL7 Services-Aware Interoperability Framework (SAIF) SAIF 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. SAIF 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.

Slide 27 EHR SD RM - EHR Way Forward … Future State Reference Architecture HL7 SAIF Responsibilities Conformance and Compliance Framework (ECCF) Consistency Traceable Implementation “ Where ” Behavior “ How ” Content “ What ” Policy “ Why ”

Slide 28 EHR SD RM - EHR Way Forward … Future State Reference Architecture HL7 SAIF Specification Stack Views Conformance and Compliance Framework (ECCF) Consistency Traceable ImplementationBehaviorContentPolicy Topic Specification Enterprise / Business View “WHY” Information View “WHAT” Computational View “HOW” Engineering View “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 GovernanceProject-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. Platform- Specific Rules, ProceduresLocalized Information Model, Transforms, Schema Collaboration scripts, Orchestrations, Realized Interfaces Execution Context, Platform Bindings, Deployment Model

Slide 29 EHR SD RM - EHR Way Forward … Future State Reference Architecture HITSP Within HL7 SAIF ECCF Specification Stack Topic Specification Enterprise / Business View “WHY” Information View “WHAT” Computational View “HOW” Engineering View “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 GovernanceProject-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. Platform- Specific Rules, ProceduresLocalized Information Model, Transforms, Schema Collaboration scripts, Orchestrations, Realized Interfaces Execution Context, Platform Bindings, Deployment Model Consistency Traceable HITSP DA HITSP CAP Harmonization Requests/ Use Case HITSP CAP HITSP Transaction, Transaction Package and Service Collaboration HITSP Component HITSP IS ImplementationBehavior HITSP Harmonization Framework 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 ContentPolicy

Slide 30 EHR SD RM - EHR Way Forward … Future State Reference Architecture HL7, HITSP, FHIMS, NIEM and NHIN Within HL7 SAIF ECCF Specification Stack Topic Specification Enterprise / Business View “WHY” Information View “WHAT” Computational View “HOW” Engineering View “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 GovernanceProject-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. Platform- Specific Rules, ProceduresLocalized Information Model, Transforms, Schema Collaboration scripts, Orchestrations, Realized Interfaces Execution Context, Platform Bindings, Deployment Model Consistency Traceable HL7 RIM FHA FHIMS HITSP DA HITSP CAP Harmonization Requests/ Use Case HITSP Capability NIEM, HITSP Transaction, Transaction Package and Service Collaboration HITSP Component NIEM Information Exchange Package HL7 EHR-S FM HITSP Harmonization Framework HL7 EHR SD RM HITSP IS EHR-S FM is EHR System Functional Model EHR SD RM is EHR System Design Reference Model NIEM is National Information Exchange Model RIM is Reference Information Model FHIMS is Federal Health Information Model & Standards DA is Data Architecture NHIN Connect Services Tomcat, JBoss, J2SE, Eclipse, GlassFish ESB, OpenSSO 30 ImplementationBehaviorContentPolicy

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

Slide 32 EHR SD RM - EHR Way Forward … Future State Reference Architecture  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 –Scenario 1: Vaccine and Drug Administration and Reporting and –Scenario 2: Vaccine and Drug Inventory Reporting EHR-SD RM Prototype [2008 AHIC Use Cases] Immunization and Response Management (IRM)

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

Slide 34 EHR SD RM - EHR Way Forward … Future State Reference Architecture EXAMPLE ARTIFACT Vaccine and Drug Administration and Reporting Use Case Full use case available at:

Slide 35 EHR SD RM - EHR Way Forward … Future State Reference Architecture EHR-SD RM Prototype Information Exchange Requirements (IERs) Vaccine and Drug Administration and Reporting Use Case  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 For details, see HITSP IS 10 Immunization and Response Management, available at

Slide 36 EHR SD RM - EHR Way Forward … Future State Reference Architecture  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 EHR-SD RM Prototype Data Requirements (DRs) Vaccine and Drug Administration and Reporting Use Case For details, see HITSP IS 10 Immunization and Response Management, available at

Slide 37 EHR SD RM - EHR Way Forward … Future State Reference Architecture EHR-SD RM Prototype HITSP Security and Privacy Vaccine and Drug Administration and Reporting Use Case  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 For details, see HITSP IS 10 Immunization and Response Management, available at

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

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

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

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

Slide 42 EHR SD RM - EHR Way Forward … Future State Reference Architecture IS10 IRM HITSP Constructs Mapped to Standards

Slide 43 EHR SD RM - EHR Way Forward … Future State Reference Architecture Contact Information Nancy Orvis Chief Integration Architect Office of the Chief Information Officer DoD Military Health System Steve Hufnagel Enterprise Architect, TIAG contract support Office of the Chief Information Officer DoD Military Health System