The Practical Guide for SOA in Health Care Volume II: Immunization Management Case Study

Transcription

1 The Practical Guide for SOA in Health Care Volume II: Immunization Management Case Study An informative reference guide produced for Health IT Practitioners. Produced by the Healthcare Services Specification Project (HSSP) as a collaborative effort among Health Level Seven (HL7), the Object Management Group and IHE. 4-Jun-10 Peer Review Draft Version J, last updated 1-Jun-2010 Version 1.0 planned for October 2010 Latest version is available at: Please send Suggestions for Improvement to Stephen.Hufnagel.ctr@tma.osd.mil, editor HSSP This document is an informative reference and it is not, nor is it intended to be, an industry standard. Free distribution and replication of this document is permitted, as is the reuse of content when appropriately attributed. The content of this document was collected during standards working meeting and is copyright to the Healthcare Services Specification Project, Health Level Seven, IHE and the Object Management Group. All Rights Reserved.

2 Executive Summary The Practical Guide for SOA in Healthcare 1 Volume II presents a case study, which adds an Immunization Management Capability (IMC) to Volume I s SampleHealth s Service Oriented Architecture (SOA). We used the TOGAF Architecture Development Method (ADM) and HL7 Service Aware Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF). Volume II demonstrates the use of HL7 s EHR System Design Reference Model (EHR-SD RM) linked architectural artifacts (e.g., EHR System Functional Model, IHE, HSSP, HITSP, HITEC, FHIM, NIEM, etc) to provide an initial architectural baseline suitable for an EHR related SOA acquisition, development or certification project. We conclude with lessons learned, such as: The TOGAF ADM is an effective process, which led us to produce a set of interoperability specifications and conformance statements. The SAIF-ECCF is an Exchange Architecture; which can be used as an Architectural Executive Summary to present the IMC interoperability specifications and conformance statements. Other architecture development methods or other architectural frameworks, such as the Rational Unified Process, the Zachman or the DOD Architectural Framework can complement and benefitfrom HL7 s EHR-SD-RM and SAIF-ECCF to build and present an exchange architecture, interoperability specifications and conformance statements. Two use cases from the Health and Human Services (HHS) American Health Information Community (AHIC) were used. The Immunization and Response Management (IRM) use case and its Vaccine and Drug Administration and Reporting scenario and the Public Health Case Reporting (PHCR) use case were used to develop the business architecture, Information Exchange Requirements (IERs), data requirements, interoperability specifications and conformance statements for the IMC s Services. Effective SOA programs involve cooperation and coordination among a wide variety of business, technical and functional participants from across an organization, including senior management sponsorship, business community ownership, program management, governance, architecture, project level execution, test and certification and sustainment teams. The HL7 EHR-SD-RM helps bring these communities together throughout a Business Capability Lifecycle. It maps capabilities and their business Information Exchange Requirements (IERs) to the HL7 EHR System Functional Model (EHR-S FM), to Healthcare Information Technology Standards Panel (HITSP) o Data Architecture, o Security and Privacy Architecture, o Harmonization Framework, o Interoperability Specifications, Constructs and their referenced standards; 1 Current versions of both The Practical Guide to SOA in Healthcare Volume 1 and Volume II are available at 5/16/2010 Page i of 139

3 Integrating the Healthcare Enterprise (IHE) profiles; and 2009 Health Information Technology for Economic and Clinical Health (HITECH) Act selected standards for interoperability and meaningful use objectives and criteria. The projects listed above are all evolving and maturing as is the EHR-SD RM. Generally, no one person can keep track of this diverse set of information; the EHR-SD-RM lets individual analysts use appropriate, meaningful and consistent viewpoints as a project team works through a business capability s lifecycle. Change History (remove from the final document) Version A, dated 26 Mar 2010 Table of Contents Version B, dated 02 Apr 2010 Background Section (1 st Draft) Version C, dated 09 Apr 2010 Executive Summary, TOGAF ADM and SAIF Sections (1 st Draft) Version D, dated 16 Apr 2010, Executive Summary and TOGAF ADM (2 nd Draft) Version E, dated 30 Apr SAIF-ECCF Appendix (2 nd Draft) Version F, dated 30 Apr IHE, TOGAF ADM and SAIF Sections (3 th Draft) Version G, dated 07 May 2010, Full document edit, cleanup, review and gap identification Version H, dated 14 May 2010, Document & Slides for HL7 WG meeting in Rio de Janeiro. Version I, dated 21 May 2010, Move ECCF to body and Background & TOGAF to appendix Version J, dated 04 Jun 2010, Updated IHE example in Section TODO Version?, dated summer 2010, summer 2010, ECCF architectural artifact ontology & glossary Version?, dated summer 2010, Add FHIM to IMC specification Version?, dated summer 2010, Add NIEM IEPDs to IMC specification Version?, dated summer 2010, Add CCHIT certification criteria to IMC Version?, dated summer 2010, Integrate NHIN Connect & Direct Services into ECCF PIM Version?, dated summer 2010, Add UITS IMC Platform Specific specifications Version?, dated summer 2010, Enhance the TOGAF & ECCF discussions linking views together Version?, dated summer 2010, Refine ECCF Conformance Statements Version 1.0, dated 01-Oct-2010, for HL7 24 th Annual Plenary & Working Group Meeting HELP NEEDED: (remove from the final document) 1) Editorial review: Is the document clear, complete, concise, correct, consistent and easy to use? 2) Update references, abbreviations, glossary, Index the document and add an index at the end. 3) NHIN, NHIN Connect and NHIN Direct services Subject Matter Expert a. WSDL Subject Matter Expert for specifications 4) NIEM IEPD Subject Matter Expert 5) CCHIT Subject Matter Expert 6) XML XSD schema development for EHR-S FM and EHR-SD RM representation. a. Good xml reference guide 5/16/2010 Page ii of 139

4 b. Editor or other tool to easily develop XSD schemas c. Tool to convert XML + XSD to Access, SQL, Excel or Word formats and vice-versa. 7) Review of Practical Guide to SOA in Healthcare Subject Matter Expert review from: a. Immunization Management and Public Health Reporting views. b. Service Oriented Architectural review what is missing? c. SAIF view - have we presented a clear, complete, concise, correct and consistent ECCF? HOW TO PARTICIPATE: Coordinate with Stephen.Hufnagel.ctr@tma.osd.mil, or cell. We have a weekly telecom each Friday Eastern PHONE: , CODE: # WEB LINK: PROJECT WIKI: PRACTICAL GUIDE: 5/16/2010 Page iii of 139

5 Table of Contents 1 Introduction Acknowledgement Document Objectives and Scope Document Tour and Structure Document Use SAIF-ECCF SS for Immunization Management Capability Preamble - Architecture Vision from an IHE Perspective Top Down Immunization Management Functional Analysis Bottom Up Immunization Management Technical Analysis ISSUE: Using a Two-step process to request an immunization history APPROACH: Returning a list of candidate clients in response to PDQ query Benefits Discussion ECCF Introduction ECCF Artifacts ECCF Working Interoperability ECCF Traceability ECCF Glossary and Traceability Meta-Model ECCF Implementation Guide Conceptual Enterprise-Business-Viewpoint Policy and Regulation Privacy & Security Requirements HITECH Meaningful Use Objectives and Criteria Business Objectives Project Scope and Vision Statement Non-Functional Requirements Use Case Inventory Conformance Criteria Discussion Conceptual Information-Viewpoint Domain Information Model Conformance Statements Discussion Conceptual Computation-Viewpoint Service Inventory Functional Requirements Conceptual Functional Service Specification (CFSS) Service Roles and Relationships Conformance Statements Discussion Conceptual Engineering-View Inventory of Software Platforms and Their Capabilities Conformance Statements Discussion Platform-Independent Enterprise-Business-Viewpoint NHIN Standards /16/2010 Page iv of 139

6 Business Governance Conformance Statements Discussion Platform-Independent Information-Viewpoint Project Information Model Data Requirements (DRs) Standards Gaps Standard Overlaps Conformance Statements Discussion Platform-Independent Computation-Viewpoint Service Interface Specification Types and Functional Group Types, Map of Business Functions Use Cases and Business Level Interaction Diagrams Information Exchanges Information Exchange Requirements (IERs) Business Level Behavioral Specifications Service Interaction Types and Collaboration Participations System-Level Exchange Architecture System Data Exchange Behavioral Specifications Service Collaboration Types Service Contracts Parts Conformance Statements Discussion Platform-Independent Engineering-Viewpoint Existing Platforms Conformance Statements Discussion Platform-Specific Enterprise-Business-Viewpoint Rules, Procedures and Industry Standards Conformance Statements Discussion Platform-Specific Information-Viewpoint Schemas and Transformations Conformance Statements Discussion Platform-Specific Computation-Viewpoint Collaboration Scripts, Orchestration, Realized Interfaces Conformance Statements Discussion Platform-Specific Engineering-Viewpoint Execution Context, Platform Bindings and Deployment Systems Conformance Statements Discussion Conclusions and Lessons-Learned Immunization Management Lessons Learned /16/2010 Page v of 139

7 ECCF Lessons Learned SOA Lessons Learner TOGAF ADM Lessons Learned Acronym List Glossary References Appendix Background Service Oriented Architecture (SOA) EHR System Functional Model (EHR-S FM) Healthcare SOA Reference Architecture (H-SOA-RA) Reference Information Model (RIM) Federal Health Information Model (FHIM) Healthcare Service Specification Project (HSSP) Service Aware Interoperability Framework (SAIF) Integrating the Healthcare Enterprise (IHE) EHR System Design Reference Model (EHR-SD RM) EHR-SD RM within the Requirements Management and Architecture Cycle Health Information Technology Standards Panel (HITSP) Certification Commission for Health Information Technology (CCHIT) National Information Exchange Model (NIEM) Nationwide Health Information Network (NHIN) NHIN CONNECT NHIN Direct Universal Immunization Tracking System (UITS) TOGAF Architecture Development Method (ADM) Preliminary A Architecture Vision B Business Architecture C Information Systems Architecture D Technology Architecture E Opportunities and Solutions F Migration Planning G Implementation Governance H Architecture Change Management List of Tables Table 1 Capabilities Mapped to Existing IHE Profiles and Transactions...20 Table 2: Introduction of Mediating Services...22 Table 3 Standards Overlaps for Services...23 Table 4 Taxonomy of Immunization Services Based on Standards...24 Table 5 Notional Set of Architectural Artifacts within the HL7 SAIF ECCF SS...29 Table 6 Guidance Standards...43 Table 7 Data Element and Information Requirements (DR)...63 Table 8 Use Case Requirements and Associated Standards Gaps...71 Table 9 Use Case Requirements and Associated Standard Overlaps...74 Table 10 As-Is SampleHealth Business Function Map /16/2010 Page vi of 139

8 Table 11 To-Be SampleHealth Business Function Map...77 Table 12 Design Principles vs. Strategic Goals and Benefits Table 13 HL7 SAIF Enterprise Conformance and Compliance Framework (ECCF) List of Figures Figure 1 Meet in the Middle Approach...13 Figure 2 US Recommended Child Immunization Schedule...14 Figure 3 Request Immunization History Using PIX...17 Figure 4 Request Immunization History using PDQ...18 Figure 5 Public Health Immunization Deployment Example...24 Figure 6 Rows in the ECCF Stack...27 Figure 7 Reference Standards and Models within the HL7 SAIF (ECCF)...30 Figure 8 Conceptual Map of ECCF Working Interoperability...31 Figure 9 IS10 IRM HITSP Constructs Mapped to Standards...32 Figure 10 ECCF SS Traceability Meta Model...34 Figure 11 EHR-S FM Direct Care Manage Immunization Administration Dependencies...46 Figure 12 Conceptual Health Data Model...51 Figure 13 NHIN Standards Framework...60 Figure 14 Immunization and Response Management Information Exchanges...79 Figure 15 Immunizations and Response Management (IRM) Business Sequence Part 1 Clinician Perspective: Immunizations and Response Management Scenario 2: Vaccine and Drug Administration and Reporting...82 Figure 16 Immunizations and Response Management (IRM) Business Sequence Part 2 Registries Perspective: Immunizations and response management Scenario 2: Vaccine and Drug Administration and Reporting...83 Figure 17 Immunizations and Response Management (IRM) Business Sequence Part 3 Consumer Perspective: Immunizations and response management Scenario 2: Vaccine and Drug Administration and Reporting...84 Figure 18 Immunizations and Response Management (IRM) Business Sequence Part Figure 19 As-Is SampleHealth Information System High Level Architecture...86 Figure 20 To-Be SampleHealth Information System High Level Architecture...87 Figure 21 Mapping of Requirements to HITSP Constructs...88 Figure 22 Communicate Vaccinations...90 Figure 23 Immunization Query and Response...92 Figure 24 Vaccine and Drug Inventory Reporting...93 Figure 25 Immunization Management Entities, Actions and Roles...94 Figure 26 Capability System Roles...94 Figure 27 Information Exchanges Mapped to External Interfaces...95 Figure 28 Supported Information Exchanges...96 Figure 29 Information Exchanges Mapped to Constructs...97 Figure 30 Immunization Information Sender System Role Mapped to HITSP Construct Interfaces...98 Figure 31 Implementation Conditions...98 Figure 32 HL7 EHR System Functional Model (EHR-S FM) Figure 33 Healthcare SOA Reference Architecture (H-SOA-RA) Figure 34 HL7 Reference Information Model (RIM) Figure 35 FHIM relationship to NIEM Figure 37 EHR-SD RM Leveraging Standards Related Organizations /16/2010 Page vii of 139

9 Figure 38 Conceptual View of the HL7 EHR System Design Reference Model Figure 39 EHR-SD RM Supporting Requirements and Architecture Processes Figure 40 HITSP Harmonization Process Figure 41 HITSP Document Architecture Figure 42 Fundamental Interoperability Relationships Figure 43 ONC Standards and Interoperability Framework Process Figure 44 TOGAF ADM Supported by EHR-SD RM /16/2010 Page viii of 139

10 Introduction This document builds upon the The Practical Guide for SOA in Health Care Volume I. Volume II elaborates an Immunization and Response Management (IRM) use case illustrating how services can be coordinated in support of workflow [choreography, service orchestration] documented within the HL7 Services Aware Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF). Specifically, volume II illustrates how the set of IRM use case behavioral specifications (e.g., dynamic business and system architectural views) can be linked through the EHR System Design Reference Model (EHR-SD RM) to satisfy the set of IRM Information Exchange Requirements (IERs) with HSSP 2, HITSP 3 and IHE 4 conformant standards-based (e. g., HL7, ANSI, ISO, OASIS etc.) services. 1.1 Acknowledgement This document reflects the collective input from across the HSSP, HITSP, HL7, OMG and IHE communities, and was developed in collaboration during a series of workgroup meetings, teleconference calls and offline work from a host of contributors. Special thanks to all who contributed to the authoring and review of this document; in particular, the following individuals and organizations made significant contributions to this work: Nancy Orvis (Government Projects Co-Chair), Military Health System Stephen Hufnagel (EHR-SD RM project facilitator), Military Health System contractor Alean Kirnak (PHER WG co-chair, HSSP-IHE coordinator), Software Partners LLC Anna Orlova, (IHE contributor) Public Health Data Standards Consortium Joshua Painter, (IHE contributor), Intel Corporation Ken Rubin (HSSP co-chair, HL7-OMG coordinator), EDS a Hewlett Packard company Pat Van Dyke (EHR WG co-chair), Delta Dental Plans Association John Ritter (EHR WG co-chair), College of American Pathologists Gary Dickinson (EHR WG co-chair), CentriHealth Don Mon, (EHR WG co-chair), AHIMA The EHR System Design Reference Model (EHR-SD RM) is built from and links standards related organizations (e.g., HL7, OASIS, ANSI, HITSP, OMG, IHE) artifacts. The EHR-SD RM assimilates these artifacts into a requirements analysis, system engineering, enterprise architectural and test set of products to increase the productivity of business, functional, information, systems and test analysts in producing a set of standards-based healthcare information technology architectural interoperability specifications and conformance criteria. The EHR-SD RM and this case study use the work products and stand on the shoulders of the participants of the standards related organizations; special thank to all those standards related organizations volunteers. 2 HSSP is the HL7 Healthcare Service Specification Project 3 HITSP is the American National Standards Institute (ANSI) Healthcare Information Technology Standards Panel 4 IHE is the Integrating the Healthcare Enterprise organization 5/16/2010 Page 9 of 139

11 The EHR-SD RM was co-sponsored and developed by the HL7 Government Projects, Healthcare Services Specification Project (HSSP), Electronic Health Record (EHR) and Public Health and Emergency Response (PHER) work groups. Members of those groups and IHE also contributed to the Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study. 1.2 Document Objectives and Scope The objectives of this document are: 1. It is a SOA implementation guide, which shows by example what it means to do a standardsbased SOA development of a capability. 2. It is an HL7 SAIF Alpha Project, which demonstrates the SAIF ECCF used to document the IMC exchange architecture, Interoperability Specifications and Conformance Criteria. 3. It is an Immunization Management Capability prototype demonstrating how the EHR-SD RM can be used to build a baseline architectural specification for an acquisition, development or certification program. The scope of this document is to present a standards-based Case Study applying the principles and lessons discussed in The HSSP Practical Guide to SOA in Healthcare Volume 1 and the IHE SOA Whitepaper applied to develop architectural interoperability specification and conformance statements for an Immunization Management Capability (IMC) added to the SampleHealth Service Oriented Architecture (SOA), given in Volume I. To the extent that we use HITSP artifacts, this case study applies to the US Realm; although the general approach is applicable anywhere. Note that the SAIF-ECCF used here is a skeleton for a comprehensive enterprise architecture, such as OMG s TOGAF, the Zachman Framework or the DOD Architectural Framework (DODAF); the IMC ECCF presents an exchange architecture, it s interoperability specifications and conformance statements. 1.3 Document Tour and Structure Volume I of this document addresses principles, systems and architectural structures from a static and topological view, focusing on how the pieces fit together. In Volume II s Immunization Management case study we present an Immunization Management Capability (IMC). We use the HL7 Service Aware Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF) to organize the IMC s Interoperability-Specification into twelve architectural viewpoints which specify an exchange architecture of interoperability specifications and conformance statements, which are suitable for acquisition, development, test or certification. Then we go over our conclusions and lessons-learned, abbreviations and glossary. The appendix presents a background overview of the EHR-SD RM s standards related artifacts. The appendix also presents a walk through the OMG TOGAF Architecture Development Method (ADM) which was used to harvest immunization management architectural artifacts, using the EHR-SD RM. To avoid duplication, the TOGAF ADM section 7.2 references architectural artifacts or diagrams, which are presented in the SAIF-ECCF Section 2. Although a linear read of the document is possible, some readers may wish to jump to Section 2.1 Preamble - Architecture Vision from an IHE Perspective for an approximately 12 page high level presentation. Persons not familiar with healthcare standards organization may wish to read the background section in the appendix 5/16/2010 Page 10 of 139

12 first. Similarly, persons not familiar with architecture development methodologies, may wish to read the TOGAF overview in the appendix. The full SAIF ECCF presentation starts in Section 2.2 and it presents the twelve ECCF architectural viewpoints. 1.4 Document Use Recognize that this is a practical guide and informative reference. The challenge we faced as authors was to consider the tradeoff between keeping things simple and useful versus the extensive depth that would be needed to address all concerns. As in Volume I, we opted for simple and useful. As a result, we believe that many of the challenges that you are likely to face are addressed in these pages, but some of your situationalspecific needs might not be. We encourage you to extend the Practical Guide for SOA in Healthcare to make it your own; we only ask for attribution. Finally, the document is structured around a set of core underlying principles, which are explained in Volume I, followed by the Volume II Case Study where those principles have been applied to an Immunization Management Capability example to make the abstract concepts tangible. Volume I of this document addresses system and architectural structure from a static and topological view, focusing on how the pieces fit together. Volume II adds dynamic business, user and system behaviors and interactions; it focuses on how the pieces work together working interoperability. This guide may be used: To provide an example of a standards-based Interoperability Specifications and conformance statements in a health context using industry standard services within a SOA To identify representative conformance views and touch-points with existing standards and technologies (e.g., platforms) within a SOA To demonstrate a possible minimum essential set of layers and services needed to successfully specify a SOA To provide a helpful example to assist in localizing / customizing standard services to meet (your) needs To provide a framework setting the context in which (your) future service planning (e.g., Roadmap) can occur. To demonstrate the use of: o HL7 EHR System Functional Model (EHR-S FM) o HL7 EHR System Design Reference Model (EHR-SD RM) o TOGAF Architecture Development Method (ADM) o HL7 Service Aware Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF) o HITSP Interoperability Specifications (ISs) and constructs Capabilities and Service Collaborations Components (e.g., data) Transactions and Transaction Packages 5/16/2010 Page 11 of 139

13 SAIF-ECCF SS for Immunization Management Capability This Practical Guide for SOA in Healthcare Volume II Case Study presents an Immunization Management Capability (IMC) addition to Volume I s SampleHealth s Service Oriented Architecture (SOA) 5 using the HL7 Service Aware Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF) Specification Stack (SS). We use the ECCF as an architectural Executive Summary, to present the IMC exchange architecture, interoperability specifications and conformance statements. The ECCF demonstrates the HL7 EHR System Design Reference Model (EHR-SD RM) linked artifacts (e.g., EHR System Functional Model, FHIM, HITSP, HITEC, HSSP, IHE, NIEM, etc) as an initial architectural baseline suitable for an EHR related SOA acquisition, development or certification project. This ECCF section is self contained and can be independently read from the body of the document. The ECCF presents an Exchange Architecture containing twelve ECCF architectural viewpoints, which individually may appear disjoint; taken as a whole, the twelve viewpoints present a comprehensive set of IMC interoperability specifications and conformance statements. A particular user may only be interested in a subset of the twelve viewpoints. The challenge we faced was to consider the tradeoff between keeping things simple and useful versus comprehensive; we opted for simple and useful, if additional details are desired, readers can go to the source documents. Additionally, we reduced font sizes for long detailed information blocks and tables to help keep the overall document size down. The MS Word version of this document is available, if readers prefer larger fonts. 2.1 Preamble - Architecture Vision from an IHE Perspective This section gives a high level approach to the Immunization Management Capability, prior to presenting the full up SAIF ECCF framework. This architecture vision was done prior to the IMC project and is presented here to set the context for the IMC SAIF ECCF. In 2009, IHE published an IHE IT Infrastructure SOA White Paper 6, which describes basic SOA concepts and used an immunization management scenario to illustrate how to map between the IHE Technical Framework and SOA approaches. The paper provides a tutorial that grounds SOA concepts in familiar messaging and structured document standards 7. It includes tables of definitions that cross-reference SOA and IHE terms and helps tie together some of the frameworks we are using. For example, in the SAIF ECCF: The platform-independent layer corresponds to the SOA whitepaper s abstract service definition The platform-independent layer broadly maps to Volume I of the IHE Technical Framework and The platform-specific layer broadly maps to Volume II of the IHE Technical Framework. Carrying this a step further, the IHE SOA White Paper discusses a quick-and-simple meet-in-the-middle approach to SOA, whereby a taxonomy of services may be used to tie existing standards and legacy software together with a top-down analysis beginning with business processes. The meet-in-the-middle approach is illustrated in Figure 1. 5 See the HSSP Practical Guide to SOA in Healthcare Volume 1 for the development of the SampleHealth SOA. 6 A Service-Oriented Architecture (SOA) View of IHE Profiles by Joshua Painter (Intel Corporation), Alean Kirnak (Software Partners LLC), John Moehrke (GE Healthcare), September 28, /16/2010 Page 12 of 139

14 Figure 1 Meet in the Middle Approach The following sub-section applies this meet-in-the-middle approach to our Immunization Management capability to yield an immunization reference-architecture based upon existing standards. Finally, we illustrate the SOA Business Case cost savings and time-to-market benefits Top Down Immunization Management Functional Analysis We will discuss immunization information delivery, in particular, as it pertains to the interaction between healthcare providers and public health immunization information systems, or IISs. IISs are public health registries whose goal is the control of vaccine-preventable diseases through improve vaccine coverage rates within populations. Meet in the Middle We now begin top-down design. Our stakeholders are: The patient The regional IIS Hospitals Ambulatory clinics Public health clinics Providers School nurses and other public health staff 5/16/2010 Page 13 of 139

15 Figure 2 US Recommended Child Immunization Schedule Figure 2 shows the recommended immunization schedule for infants and young children. At a regional, state and national level this is a huge amount of information, which must be shared among stakeholders. To effectively share immunization information, the stakeholders Immunization Information System (IIS) SHALL: Register a patient in the empi 8 (make the patient known) Find a patient in the empi by identifier or by demographics Submit a patient s immunization information 9 to one-or-more public health or shared registries. Locate a patient s federated immunization information Retrieve a patient s immunization information Recommend next immunizations Share a patient s immunization information with providers Share a patient s information with the patient himself Submit a patient s immunization information to other IIS Bottom Up Immunization Management Technical Analysis There are different required fields (segments, vocabulary, etc.) lists depending upon the use case: 8 An Enterprise Master Patient Index (empi) is a directory of identifiers pertaining to individuals that have been assigned by one or more organizations in the health sector. An empi ensures that personal health information for an individual, in the custody and control of organizations in the health sector, may be consistently linked to the correct individual. It is expected that an empi, as a centralized identity management service for an enterprise, Health Information Network (HIN), region, state etc. will eventually support broader system-to-system interoperability for national e-health initiatives in the future. Most importantly, federated empis will provide the cornerstone for electronic records of personal health information in the NHIN. 9 Immunization Information might include current IZ, IZ history, IZ schedule, IZ adverse events, allergies, etc. 5/16/2010 Page 14 of 139

16 If the IIS does not participate in an MPI: An EHR system reporting immunization data to the IIS for the first time must supply demographics or a local ID as well as immunization data If EHR system updates immunization data for a previously reported patient, it may supply the local ID and the immunization data (but not necessarily the demographics) If the IIS participates in an MPI used by the EHR system: An EHR system registering a patient in the MPI for the first time must supply demographics and a local ID An EHR system reporting immunization data to the participating IIS that has already registered the patient reports the retrieved IIS ID and the immunization data (but not necessarily the demographics) An EHR system reporting immunization data to the participating IIS that has not already registered the patient must report something else to identify the patient possibly the MPI ID and optionally demographics? and the immunization data The stakeholders use a mix of HL7 Version 2 and HL7 Version 3 (document and messaging) for data exchange. We now proceed in bottom-up fashion to leverage existing IHE profiles. We identify profiles that implement the required capabilities: Patient Identifier Cross-Referencing (PIX) and Patient Demographics Query (PDQ) with Pediatric Demographics Option implements an empi Cross-Enterprise Document Sharing (XDS.b) with Immunization Content Profile implements a document registry and repository that can manage immunization documents Utility services such as auditing (ATNA) We also need certain capabilities not covered by existing IHE profiles: HL7 Version 2 immunization messaging for data exchange with existing IISs HL7 Version 3 messaging for immunization (POIZ Immunization messaging) data exchange with V3-based systems such as Canadian Health Infoway or British National Health systems Immunization decision support (trial use) services to recommend next vaccines ISSUE: Using a Two-step process to request an immunization history The IHE profile defines two queries for obtaining an ID of interest. One query requests an ID based on the demographic information included in the query (PDQ, using the Pediatric Demographic profile). When a match is found, it returns the relevant ID and demographic information. The other query seeks an ID for a person from one registered provider based on the ID from another registered provider (PIX). The use of the IHE Patient Identification Cross-Referencing (PIX) and Patient Demographic Query (PDQ) transactions is an alternative approach which separates retrieval/update of a patient identifier and retrieval/update of immunization data into two messaging transactions. 10 IHE profiles to support immunization decision support services are available for trial use in the IHE Patient Care Coordination (PCC) domain. 5/16/2010 Page 15 of 139

17 A Patient Demographic Supplier may be a Master Person Index or other source of patient demographic and identification information. While we will focus on an MPI below, any Patient Demographic Supplier may be substituted. A Master Person Index is a database that contains demographic and locating information of registered persons and associates each person with the identifiers for the person from each of the participating systems. This allows one system to request the identifier for a person that was assigned by another system. This ID may be used to request data from that second system and assures a positive match. Systems that participate in an MPI should register each person they are interested in with the MPI. An excellent profile for maintaining and interacting with an MPI has been published by the group, Integrating the Healthcare Enterprise (IHE). That profile will not be replicated here. However, the process for requesting personal identifier outlined below is based on that profile. Adding a patient record to an MPI is done by a PIX transaction using an ADT message. This method may be used by an EHR system or by an IIS, or both, to add a patient identifier to an MPI. The PIX profile, described in the IHE Technical Framework Volume I, includes specific transactions that describe the segments and fields to be used. These ADT-based transactions are described in the IHE Technical Framework Volume II. The standard transaction used by PIX is ITI-8, which uses an HL7 V2.3.1 ADT. Patient Identity Feed ITI-8 - method of inserting patient into MPI: MSH ^~\& MYIIS MyStateIIS SOME_SYSTEM A_Clinic ADT^A P <CR> EVN A <CR> PID ^^^MYEHR^MR Child^Bobbie^Q^^^^L Que^Suzy M 10 East Main St^^Myfaircity^GA^^^H U <CR> PV1 I<CR> The Pediatric Demographics Option, described at this writing in a supplement to PIX and PDQ, is preferred for interactions with MPIs managing IIS data. The use of the Pediatric Demographics Option adds ITI-30, which uses an HL7 V2.5 ADT. Patient Identity Management ITI-30 - alternate method of inserting patient into MPI using HL7 V2.5 and Pediatric Demographics Option: MSH ^~\& MYIIS MyStateIIS SOME_SYSTEM A_Clinic ADT^A28^ADT_A P 2.5 <CR> EVN <CR> PID ^^^MYEHR^MR Child^Bobbie^Q^^^^L Que^Suzy M 10 East Main St^^Myfaircity^GA^^^H U <CR> PV1 O <CR> Once a person has been registered with the MPI, a PIX Query may be used to retrieve the cross-referenced IIS identifier (if any). Figure 3 illustrates the use of the PIX query to get a pre-registered patient identifier. This requires that the cross-referenced identifiers are registered using the ADT message. PIX Query ITI-9 - method of retrieving IIS ID from MPI, supplying local ID as search parameter: MSH ^~\& MYIIS MyStateIIS SOME_SYSTEM A_Clinic QBP^Q23^QBP_Q P 2.5 <CR> QPD IHE PIX Query ^^^MYEHR^MR ^^^MyStateIISAssigningAuthority <CR> RCP I<CR> 5/16/2010 Page 16 of 139

18 Figure 3 Request Immunization History Using PIX Note that this interaction is simplified. The initiating system sends a request for a patient identifier. The request includes one identifier in a PID-3. The identity supplier looks for a matching identifier of interest and returns it along with the patient name (PID-5). This information is included in the request immunization history query (QBP^Q11). Assuming that the identifier used is the one in the immunization history supplier, there should be a one to one match. If the EHR system wishes to retrieve the IIS ID without previously registering the patient with the MPI, or if it wishes to query the MPI by demographics for some other reason, it may use a Patient Demographics Query to do so. Figure 4 illustrates the use of PDQ to obtain an ID and how this would be used to request an immunization record. The record seeker uses a Patient Demographic Query (PDQ) to a Master Person Index (MPI), requesting the identifiers for the person of interest. The MPI finds the person of interest and returns the demographic information and identifiers. The record seeker system uses this information to create a request for immunization history, which it sends to the record source. The record source uses this information to find the immunization history for the person of interest. Patient Demographic Query ITI-21 - method of retrieving IIS ID from MPI for previously unknown patient: MSH ^~\& MYIIS MyStateIIS SOME_SYSTEM A_Clinic QBP^Q22^ P <CR> QPD ^IHE PDQ Query^ ~@PID.7.1^ ~@PID.8.1^M~@PID ^10 East Main St^~@PID.11.3^Myfaircity~@PID.11.4^GA<CR> RCP I 5^RD^HL70126 R^real-time^HL70394<CR> 5/16/2010 Page 17 of 139

19 Figure 4 Request Immunization History using PDQ Note that this interaction is simplified. The client of interest would be selected and that client s information would populate the query requesting an immunization history. To be assured of success, the record source system would need to have registered the person in the MPI. In that way the person ID in the record source would be available in the MPI. Figure 3 and Figure 4 illustrate that the PIX Query and Patient Demographics Query (PDQ) approaches share similar flow to the original VXQ message. PIX Query followed by a RIH using the retrieved identifier is similar to a VXQ/VXR. PDQ followed by an RIH replicates a VXQ/XXX and VXQ/VXR (when multiple candidates are initially returned), or just a VXQ/VXR (if a single high-confidence candidate) 11 The following illustrates one of the above-described messages, the Patient Demographics Query. For examples of other messages, IHE documentation 12 should be consulted. 11 It is possible that even with the two-step process, an exact match may not be found for the record of interest. This is especially true if the source of identity resolution is not exactly in synch with the source of the immunization history. Local rules should dictate the response to this situation. 12 IHE references (document versions from which these examples are taken): - Patient Identifier Cross Referencing (PIX) and Patient Demographics Query (PDQ) Integration Profiles - Transactions ITI-I through ITI-28. Includes Patient Identity Feed (ITI-8), PIX Query (ITI-9) and Patient Demographics Query (ITI-21) - Transactions (cont'd) ITI-29 through ITI-50. Includes Patient Identity Management (ITI-30) which is used by Pediatric Demographics Option pdf - Pediatric Demographics Option 5/16/2010 Page 18 of 139

20 MSH ^~\& MYIIS MyStateIIS SOME_SYSTEM A_Clinic QBP^Q22^ P <CR> QPD ^IHE PDQ Query^ ~@PID.6.1.1^Que~@PID.6.2^Suzy ~@PID.7^ ~@PID.8^M~@PID ^10 East Main St^~@PID.11.3^Myfaircity~@PID.11.4^GA <CR> RCP I 5^RD^HL70126 R^real-time^HL70394<CR> Note that the intent of the Quantity Limited Request differs from its use in the Request Immunization History query. Here it means send me batches of 5 records until you have sent them all. In the Request Immunization History query it means return a list of up to five clients, but if you find more, then send me an error indicating too many records found APPROACH: Returning a list of candidate clients in response to PDQ query The response to a PDQ query is very similar to that of a Request for Immunization History query which finds lower confidence matches. The most significant differences include: No NK1 is returned. MPIs implementing the Pediatric Demographics Option use Mother's Maiden name in the PID segment to provide equivalent value in patient record matching. If more than the maximum records are found they are returned in batches of up to the maximum records specified in the query Potential use of DSC segment to support return of batches of records The following example shows a return similar to the response message returned by the request for immunization history query (above). Note that in both cases, the response message returns all information that it knows about each client in the segments required for each response. ITI-21 Patient Demographic Query response: MSH ^~\& SOME_SYSTEM A_Clinic MYIIS MyStateIIS RSP^K22^ P <CR> MSA AA <CR> QAK AA<CR> QPD ^IHE PDQ Query^ ~@PID.7.1^ ~@PID.8.1^M~@PID ^10 East Main St^~@PID.11.3^Myfaircity~@PID.11.4^GA <CR> PID ^^^MYStateIIS^SR Child^Robert^^^^^L M<CR> PID ^^^MYStateIIS^SR Child^Robert^^^^^L M<CR> Using PIX/PDQ in preparation for reporting an Immunization Record to an IIS In the case where an IIS participates in an MPI, the EHR may use a PIX Query to retrieve the IIS identifier from the MPI prior to sending an immunization record to the IIS. In the case where the IIS identifier is returned by the MPI, the VXU message sent to the IIS may contain the IIS ID. Using the IIS Identifier to Retrieve an Immunization History from the IIS Request Immunization History (not profiled by IHE) - method of retrieving immunization history by IIS ID: MSH ^~\& QBP^Q11^QBP_Q P Z34^CDCPHINVS <CR> QPD Z34^Request Immunization History^HL ^^^MYEHR^MR Child^Bobbie^Q^^^^L Que^Suzy^^^^^M M 10 East Main St^^Myfaircity^GA^^^L<CR> RCP I 5^RD^HL70126 R^real-time^HL70394<CR> Request Immunization History response (not profiled by IHE but uses IIS ID retrieved either by PDQ or by PIX Query): MSH MYIIS MyStateIIS MYEHR RSP^K11^RSP_K P Z32^CDCPHINVS<CR> MSA AA <CR> 5/16/2010 Page 19 of 139

21 QAK OK Z343^request Immunization history^hl70471<cr> QPD Z34^Request Immunization History^HL ^^^MYEHR^MR Child^Bobbie^Q^^^^L Que^Suzy^^^^^M M 10 East Main St^^Myfaircity^GA^^^L<CR PID ^^^MYEHR^MR Child^Robert^Quenton^^^^L Que^Suzy^^^^^M 10 East Main St^^Myfaircity^GA<CR> PD1 N <CR> NK1 1 Child^Suzy^^^^^L MTH^Mother^HL70063<CR> PV1 R V03^ <CR> ORC RE ^YOUR_EHR ^Shotgiver^Fred ^Orderwriter^Sally^^^^^^^^^^^^^^^^^^MD<CR> RXA ^MMR^HL ML^^ISO+ ^New Immunization Record^NIP001<CR> RXR SC^^HL70162<CR> VXU supplying retrieved IIS ID (not profiled by IHE but uses IIS ID retrieved either by PDQ or by PIX Query): VXU supplying demographics (not profiled by IHE): MSH ^~\& MYIIS MyStateIIS SOME_SYSTEM A_Clinic VXU^V P <CR> PID ^^^MYEHR^MR <CR> RXA ^HEPB- PEDIATRIC/ADOLESCENT^CVX.5 ML^^ISO+ MRK12345 MSD^MERCK^MVX <CR> MSH ^~\& MYIIS MyStateIIS SOME_SYSTEM A_Clinic VXU^V P <CR> PID ^^^MYEHR^MR Child^Bobbie^Q^^^^L Que^Suzy M 10 East Main St^^Myfaircity^GA^^^H U <CR> RXA ^HEPB- PEDIATRIC/ADOLESCENT^CVX.5 ML^^ISO+ MRK12345 MSD^MERCK^MVX <CR> *caveat the preceding message examples are for illustration purposes, they have been only cursorily tested We then map capabilities to existing IHE profiles, as depicted in Table 1. Table 1 Capabilities Mapped to Existing IHE Profiles and Transactions Use Case Capability IHE Transaction or Content IHE Profile (TF Vol I) Description # (EHR-S FM) Profiles (TF Vol II) Manage a patient's 1 Consistent time CT-ITI-1 immunizations from 2 Auditing ATNA-ITI-20 birth through age 3 Register a patient in the empi ITI-8, ITI-10, ITI Patient Identifier Cross- Find a patient's cross-referenced 4 Referencing (PIX) ITI-9 identifiers Find a patient by identifier or by demographics Register a patient's IZ info in document form Submit a patient's IZ info in document form Locate a patient's IZ info in document form Retrieve a patient's IZ info in document form Update a patient's IZ info in HL7 V2 form Locate a patient's IZ info in HL7 V2 form Retrieve a patient's IZ info in HL7 V2 form Patient Demographics Query (PDQ) Cross-Enterprise Document Sharing (XDS.b) None. Update a source via HL7 V2 IZ message None. Locate HL7 V2 IZ source None. Retrieve HL7 V2 IZ message ITI-21 ITI-42, Immunization Content ITI-41, Immunization Content ITI-18 ITI-43, Immunization Content None (VXU, not profiled) None (use ITI-9 to retrieve sources from empi) None (VXQ or RIH 13, not profiled) 13 Request Immunization History, from draft 2.5 implementation guide for immunization messaging 5/16/2010 Page 20 of 139