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 [email protected], 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 [email protected], 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^ [email protected]^ [email protected]^M~@PID ^10 East Main St^[email protected]^[email protected]^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^ [email protected]^[email protected]^Suzy [email protected]^ [email protected]^M~@PID ^10 East Main St^[email protected]^[email protected]^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^ [email protected]^ [email protected]^M~@PID ^10 East Main St^[email protected]^[email protected]^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

22 Use Case Description # Capability (EHR-S FM) IHE Profile (TF Vol I) IHE Transaction or Content Profiles (TF Vol II) Recommend next immunizations PCC "Request for Clinical Guidance" [RCG] Immunization Content Our first pass at a solution provides a good start, but fails to provide the interoperability required by the public health immunization use case. One challenge is that stakeholders making use of an XDS document registry and repository for sharing of immunization information cannot communicate with stakeholders using HL7 Version 2 for the same purpose. A solution is provided by applying the SOA design of, which introduces mediation services. 5/16/2010 Page 21 of 139

23 Use Case Manage a patient's immunizations from birth through age 18 Table 2: Introduction of Mediating Services IHE Transaction or IHE Mediating Capability IHE Profile (TF Vol I) Content Profile (TF Service # Vol II) 1 Consistent time CT-ITI-1 Utility Services applied to all IHE Existing services 2 Auditing ATNA-ITI Register a patient in the empi Find a patient's crossreferenced 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 Submit 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 Recommend next immunizations Identification Service Retrieve, Locate, and Update Service Decision Support Service Patient Identifier Cross- Referencing (PIX) Patient Demographics Query (PDQ) Cross-Enterprise Document Sharing (XDS.b) None ( HL7 V2 IZ message) None (HL7 V2 IZ message) None (HL7 V2 IZ message) PCC "Retrieve Clinical Guidance" [RCG] ( ) ITI-8, ITI-10, ITI-30, ITI-44 ITI-9, ITI-45 ITI-21, ITI-47 ITI-42, Immunization Content ITI-41, Immunization Content ITI-18 ITI-43, Immunization Content None (VXU) None (use ITI-9 to retrieve sources from empi) None (VXQ) Request for Clinical Guidance This solution does provide the needed communication between stakeholders speaking HL7 Version 2 and stakeholders using an XDS repository and registry for information sharing because we have created a Submit, Locate and Retrieve service which provides the needed translation. We have also created an Immunization Decision Support Service to provide immunization-specific decision support. We have created an Identification service for communication between stakeholders and the empi. Note also that Table 1 and Table 1 above resemble Figure 1 but rotated left 90 degrees. So far our model is entirely based upon IHE profiles. We now map it to the full landscape of currently available standards, expanding the sections on standards not (yet) profiled by IHE. So now we flip the table back upright to follow Table 3. We delete the Use Case and Capabilities columns to focus on services and standards. In Table 3, the services are mapped again to their IHE profiles and transactions, but also to profiles or implementation guides created by other profiling organizations, and to their base HL7 standards. Profiles and implementation guides are classified as the interoperability layer because they define as tightly as possible the exact sequence of bits that is required to conform to the standard. When successful, such profiles and implementation guides facilitate interoperability by creating an environment in which one vendor system connects out-of-the-box with another vendor system. As we will see, such plug-and-play interfaces are a powerful contributor to healthcare 5/16/2010 Page 22 of 139

24 interoperability cost reduction, especially in an environment such as public health where the number of systems that need to communicate is large. (An aspect of plug-and-play interfaces not elaborated here is the requirement to test conformance to standards in an environment such as the IHE Connectathon.) Table 3 Standards Overlaps for Services # Service Identification Retrieve, Locate and Update Decision Support 1 Standards Org HL7 2 Capability Identification Service Functional Mode Retrieve, Locate, Update SFM Decision Support SFM 3 Standards Org OMG 4 Service Definition Identification Service Specification Retrieve, Locate, Update Spec Decision Support Service Spec 5 Profile Org IHE 6 Interoperability Layer PIX/PDQ 7 Profile Org AIRA/CDC 8 Interoperability Layer 9 Interoperability Layer Draft: 2.5 Implementation Guide Implementation Guide Draft: 2.5 Implementation Guide Implementation Guide 10 Standards Org HL7 11 Base Standard Version 2 Version 3 Patient Admin messaging Version 2 Version 3 Immunization (POIZ) messaging Immunization Content (IC) Version 3 Care Record CDA Immunization Content Version 3 Care Record CDA Request for Clinical Guidance Version 3 Care Record messaging Now, we reduce Table 3 further to remove overlapping standards choices. Competing standards co-exist; a good solution must recognize and accommodate them since it is almost never practical to eliminate all their implementations. However, to create an elegant architecture which we can analyze, we choose the best of breed here 14. The best of breed may be thought of as priority #1 choices, with additional choices added in as needed. In addition to removing overlap and choosing the best of breed, we remove the detail of the standards and profiling organizations that developed them, and also the detail of their base standards. Finally, we add a task layer service called GetPatientIZStatus. GetPatientIZStatus is a composed service which may be used to hide the details of identification, data retrieval and decision support when all the user wants is the end result of all three of these services. 14 We chose to use HL7 v2.5 immunization messaging; specifically, we focus on the option within the new HL7 v2.5 immunization messaging implementation guide that supports separate identification query and immunization information query. Traditionally, HL immunization messaging has been used; which combines the query for patient identification and for immunization information into a single query. The choice was made in the interest of harmonization and simplification of our model. Nothing in our model prevents the use of instead of 2.5. A combined ( one step ) query could also be implemented as a composition of the HSSP Identification and RLUS services. 5/16/2010 Page 23 of 139

25 Table 4 Taxonomy of Immunization Services Based on Standards Task Service GetPatientIZStatus Mediating Service Identification Retrieve, Locate, Update HL7 Version Version 3 XDS.b, Implementation Immuni- Immuni- zation zation Guide VXU, (POIZ) Content Utility Service PIX/PDQ transactions RIH messaging (IC) Decision Support Request for Clinical Guidance, Immuni- zation Content In Table 4, we now have a specific example of the abstracted taxonomy shown in Figure 1 Meet in the Middle Approach. Our taxonomy of services provides the bridge from business processes to on-the-wire, standards-based plug and play interfaces. It spans different technology platforms, including messages, services, HL7 V2, HL7 V3, which allows us to accommodate the variety of systems in the field, whether they are legacy or new systems, systems from different geographic and political areas, and other variations. A deployment example of our solution is given in Figure 5 Public Health Immunization Deployment Example. Our patients, regional IIS and hospital, ambulatory, public health and safety net healthcare providers leverage commonly accessible regional Health Information Exchange (HIE) infrastructure. The HIE provides enterprise Master Person Index (empi) to facilitate patient identification, and a document registry and repository. The HIE provides common services to the patient s Personal Health Record (PHR), the providers Electronic Health Record systems (EHRs), and public health s Immunization Information System (IIS). Figure 5 Public Health Immunization Deployment Example 1. PHR 2. Primary Care Provider A parent is preparing to go to a Primary Care Provider for a well-child visit. The parent views the child s current immunizations using a Personal Health Record The 5-year-old child and the parent visit the provider, who uses an EHR system that retrieves the child s immunizations and recommendations from the HIE. The provider sees the same immunization data the parent saw via the PHR. He administers vaccines, and enters them into his EHR. The EHR updates the HIE and simultaneously, the Immunization Information System (IIS). Personal Health Record (PHR) Health Information Exchange Patient Empowerment 4. Primary Care Provider 5. Schools and Public Health The child is now getting ready to enter school. The parent double checks the immunization record to make sure the child is up-to-date on all of the immunizations required for school entry. He sees that one shot is missing. In a rush, the parent makes an appointment for the child at a different clinic. The provider s EHR retrieves the child s immunization data from the HIE. He administers the missing vaccine, and enters it into his EHR. The EHR updates the HIE and simultaneously, the IIS. Predictions of an especially severe flu season cause the child s school to implement a school-located vaccination program. The school nurse logs on to IIS and accesses the child s record and recommendations, which have been kept current with other sources. School nurse administers H1N1 vaccine and updates the IIS, which forwards the new record to the HIE using immunization services. Epidemiologist views individual or population-level immunization data. Immunization Services Immunization Information System (IIS) Immunization Decision Support Service 15 HL7 Version 2.3 messaging is commonly used today. 5/16/2010 Page 24 of 139

26 Public Health Immunization Scenarios We now walk through our scenario and indicate which services are used to accomplish the steps of Figure 5 Public Health Immunization Deployment Example above. PHR Perspective Step #1: Parent uses Personal Health Record (PHR) to prepare for well-child visit Our PHR makes a GetPatientIZStatus request. GetPatientIZStatus in turn implements a composition of: 1. Identification Service: to authenticate the patient and obtain identifiers necessary for retrieving the data. For this, in our example it uses a PIX transaction passing a HL7 V2 message to an MPI at the regional HIE. 2. Retrieve, Locate and Update Service: using the retrieved identifiers and domains, the location of the patient s data is determined. The data is retrieved in HL7 Structured Document format using XDS.b and the Immunization Content profile. 3. Decision Support Service 16 : A Request for Clinical Guidance HL7 CDA V3 message containing the retrieved clinical information is passed and the immunization recommendation returned. CDA wrappers are stripped and a small amount of mapping is done to convert Immunization Content CDA format into the required Care Record message. The result is converted back to CDA before it is returned. 4. The results are presented to the user by PHR software. Since the data is in Structured Document format, it may be displayed without parsing to the user. Primary Care Provider Perspective Step #2: Parent and patient visit the primary care provider 1. GetPatientIZStatus is again used as in Step #1 to retrieve the child s immunization information. The EHR system may parse the information and store it or just display it to the user in document format. 2. When the provider enters the new vaccines, an Immunization Content document is created. It may or may not include the vaccines just retrieved from the HIE. 3. The document is passed to Retrieve, Locate and Update service. The service parses it and tees it, sending it in Immunization Content form to the HIE and in HL7 V2 form to the IIS. Patient Perspective Step #3: The parent again uses his up-to-date PHR to determine if any shots are due. 1. Assuming he has kept his PHR up to date, all he has to do is call Decision Support Service, passing the PHR data, to see if any shots are due now. Primary Care Provider Perspective Step #4: Parent and patient visit the primary care provider 1. This step is just like Step #2. Public Health Perspective Step #5: Schools and Public Health interact 1. This step represents traditional, logged-in use of an IIS. The school nurse is authorized to log directly into the IIS application software. All the child s immunization activities have been submitted to the IIS, so his record is up to date. 2. Decision support, whether invoked locally or remotely through a call to Decision Support Service, is run to assist the nurse in determining the patient s immunization status. 3. To update the HIE; only Retrieve, Locate and Update need be used. If the patient were new, Identification Service would also need to be used to register the patient with the HIE MPI. The HL7 V2 form of RLUS may be used in keeping with IIS standards. 16 Protocols for Decision Support Systems are immature; we present a hypothetical protocol here. 5/16/2010 Page 25 of 139

27 Benefits Our Public Health Immunization example offers these possibilities: Single entry point for all EHR systems for submission of data to immunization registries. The HIE infrastructure hides much of the complexity of immunization information access. The details of extending access beyond the domain boundaries for instance to another county or state is implemented under the layers of Identification and Document services and so is hidden from both the private providers and public health agencies. Service consumers only have to worry about a one-hop access to the infrastructure. Availability of information to the patient. In our model, with proper authentication, a patient may use the same HIE services to view his own information. In the absence of reusable infrastructure, such interoperability would be unaffordable for individual patients. Federated Knowledge Resources. Ability to share public health and medical professional organization knowledge resources. In fact, Immunization Decision Support is currently implemented within the many IIS existing systems and also within many provider EHR systems. All of these systems have to interpret and codify clinical rules individually and keep them up to date. Decision support rules are complex and frequently updated; updating them within implementations in the field is costly and time-consuming. Common implementations are possible with our model. Cost Savings. Potential for powerful cost savings, as a move is made from exponential to linear cost functions relative to the number of participating systems. Our reference architecture suggests a bus model in which cost of complete interoperability among many participating systems is a function of the number of participating systems times the number of services. Bus model alone is not sufficient to achieve such savings; in addition, certain other conditions such as adherence to service definitions, common information model, and plug-andplay interfaces are required. It is worth noting that many of the topics discussed here lay the groundwork for achieving dramatic efficiencies. For example, by contrast, a set of N cooperating systems with point-to-point HL7 V2 connections can require, in the worst case, up to N * (N + 1) / 2 connections for full data exchange capabilities. Although in practice, optimizations such as reuse of some connection implementations and use of hub models reduce this number somewhat, for purposes of calculating complexity, the current cost model is still exponential Discussion This section shows the type of early analysis that might be done as a part of strategic-planning, a feasibilitystudy or a business-case budget-analysis. TOGAF ADM step A-Architecture Vision, presented in this section, does not specifically fit into the HL7 SAIF ECCF. This Architecture Vision was developed in , within IHE, prior to this Immunization Management Capability (IMC) project and is shown as a preamble to the SAIF ECCF to set the context of the IMC project. 5/16/2010 Page 26 of 139

28 ECCF Introduction In this section, we show how to construct an HL7 SAIF ECCF Specification Stack (SS) instance from traditional architectural artifacts. The ECCF goal is to ensure Working Interoperability (WI) among various healthcare organizations; WI is also known as compatibility among healthcare systems Figure 6 Rows in the ECCF Stack Figure 6 Rows in the ECCF Stack describes the layers in the ECCF stack. Thicker arrows indicate that a trading partner has more specific specifications allowing trading partners to better achieve Working Interoperability (WI), based on a more comprehensive Specification Stack (SS). Note that Reference Models generally reside above the CIM and Implementations reside below the PSM. The columns in the ECCF stack are based on the International Organization for Standardization (ISO) Reference Model for Open Distributed Processing (RM-ODP 17 ) set of viewpoints for partitioning the design of a distributed software/hardware system. The RMODP viewpoints 18 are: The Enterprise Viewpoint, which is concerned with the purpose and behaviors of the system as it relates to the business objective and the business processes of the organization. The Information Viewpoint, which is concerned with the nature of the information handled by the system and constraints on the use and interpretation of that information. The Computational Viewpoint, which is concerned with the functional decomposition of the system into a set of components that exhibit specific behaviors and interact at interfaces. The Engineering Viewpoint, which is concerned with the mechanisms and functions required to support the interactions of the computational components. 17 ISO/IEC :1998 Information technology Open Distributed Processing: Reference Model Part 1: Overview, International Organization for Standardization, Geneva, Switzerland, links to a variety of RM-ODP information sources as well as providing references to the proposed enhancements incorporating concepts such as services, components, relations, patterns, etc. 18 Edward J. Barkmeyer ea (2003). Concepts for Automating Systems Integration NIST /16/2010 Page 27 of 139

29 The Technology Viewpoint, which is concerned with the explicit choice of technologies for the implementation of the system, and particularly for the communications among the components. The ECCF collapses the RM-ODP engineering and technology viewpoints together. The ECCF is not a comprehensive enterprise-architecture; rather, we use it to specify information exchange interoperability and conformance statements for documents, messages and services. The ECCF specification stack is an exchange architecture; it contains three abstract layers of ECCF interoperability viewpoints. Architectural artifacts are distributed across the various ECCF viewpoints (columns) and through the ECCF levels of abstraction (rows). The architectural artifacts are categorized into business rules, information, behavioral and structural specifications and engineering/technical platforms. In a mature 19 SS, all ECCF cells are filled and artifacts across rows or layers of the ECCF are consistent 20 and artifacts down columns or viewpoints of the ECCF are traceable 21. Table 5 Notional Set of Architectural Artifacts within the HL7 SAIF ECCF SS is a template, which shows how we might organize a typical set of architectural artifacts into an ECCF specification stack (SS). Within each cell 1) we place and discuss architectural artifacts/ specifications, 2) we define conformance statements, which are testable representations of assumptions that the specifications make and 3) we discuss traceability within columns and consistency across layers or lack thereof. An implementation of the specification asserts, as True or False, that one-or-more conformance assertions are met. SS maturity implies that the SS instance is clear, complete, concise, correct, consistent and traceable within and across the SS. Examining the relevant SS instances provides a traceable, consistent, scalable approach to assessing the degree of difficulty and specific amount of effort required to enable trading partners to attain Working Interoperability among their compatible 22 systems. 19 The term mature refers to the completeness of a given SS instance; the extent to which the SS subject cells are fully populated i.e., the degree to which the maximum number of possible explicit assumptions and conformance statements have been made across the cells of the SS. This is represented by the collection of SS cells that are populated with the appropriate artifacts. 20 Consistency is a characterization of the logical coherence of the artifacts that are collected in a 540 particular instance of a specification stack. Consistency is normally assessed on a row-by-row basis. 21 Traceability refers to system capabilities explicit in a software component that can be traced down from a CIM-level statement to the PIM-level, followed by a trace to the PSM-level, followed by a trace to an implementation-specific capability. Traceability may apply to capabilities stated as conformance statements. Provenance can be viewed as another face of traceability in the sense that traceability is an instance-level construct, whereas provenance is a collection-level construct for an entire specification. Provenance is formally defined as documentation that identifies the traceability of the history of a given artifact within a given specification, from its origination (for example, as a requirement) through its implementation. In other words, provenance is the documentation of the source of all constraint statements in the specification. 22 Compatibility is a relationship between two or more conformance statements involving two or more specification stack instances. The relationship identifies whether two or more implementations certified to be conformant to the specification stack instances can achieve WI without further transformations. If so, the two SS instances and associated implementations are called compatible. 5/16/2010 Page 28 of 139

30 Subject Specification CIM (Conceptual) PIM (Logical) PSM (Implementable) Enterprise Viewpoint Why Policy Inventory of o Use Cases o Stakeholders o Capabilities-Services o Requirements o Contracts Business Scope Business Vision Business Objectives Policy & Regulations Applicable Rules Use Case Specs Governance. Technology Neutral Standards Wireframes of o architectural layers o Components and o Associations Business Nodes Business Rules Business Procedures Business Workflow Technology Specific Standards Information Viewpoint What Content Inventory of o Domain Entities o Roles, o Activities, o Associations. Information Models o Conceptual o Domain Information Models o Localized o Constrained o Project Message Content Specifications Database Schemas Message Schemas Transformation Schemas (e.g., XSD) Computational Viewpoint How Behavior Inventories of o Capabilities-Components, o Functions-Services. Requirements o Accountability, Roles o Behaviors, Interactions o Functional Profiles, o Interfaces, Contracts Conceptual Functional Service Specifications (CFSS) Use Case Specs Component. specs Interface Specs Interaction Specs Collaboration Participations Collaboration Types Function Types Interface Types Collaboration Scripts Service Contracts Automation Unit Technical Interfaces Technical Operations Orchestration Scripts Table 5 Notional Set of Architectural Artifacts within the HL7 SAIF ECCF SS Engineering Viewpoint Where Implementation Inventor of Platforms/ Environments. Existing Platform models, Capabilities, Libraries and Versions. Application Specs. GUI Specifications Component Designs Deployment Topology Platform Bindings DISCUSSION: In Table 5 ECCF SS template, a notional set of architectural artifacts are distributed across the ECCF viewpoints (columns) and through the ECCF levels of abstraction (rows). Artifacts are placed in the most intuitively obvious SS cell and then are organized to facilitate traceability. Some subset or variations of these architectural artifacts should populate any ECCF SS. Note that the difference between a function and a service is that a service is public, reusable and has an associated Service Agreement also known as a Distributed User Resource Sharing Agreement (DURSA). Technically, a well specified function and a well specified service can be identical to each other. 5/16/2010 Page 29 of 139

31 ECCF Artifacts Figure 7 identifies the referenced standards-based artifacts 23, which the EHR-SD RM used to produce the IMC ECCF Conceptual and Platform Independent viewpoints. By starting with the EHR-SD RM s reusable models and architectural artifacts, we were able to quickly lay out the IMC ECCF, tailored to SampleHealth s requirements and then do the platform specific viewpoints Figure 7 Reference Standards and Models within the HL7 SAIF (ECCF) 23 From an ECCF perspective, a given reference artifact can be used, applied, referenced, transformed, or otherwise leveraged by any cell of the specification stack (within the same viewpoint). However, referenced specifications need not reside in a particular layer of the specification stack. Rather, they are most often viewed as surrounding or providing input to instances of the SS at any level of abstraction (row) or column. Note that externally referenced specifications may or may not have preexisting technology bindings. 5/16/2010 Page 30 of 139

32 ECCF Working Interoperability Figure 8 Conceptual Map of ECCF Working Interoperability SS is specification Stack Subject or Specification stack subject refers to a particular SS instance and defines the instance s scope or topic. We use the term subject to avoid the already overloaded terms scope and topic. The subject of a specification varies, depending on the granularity, intent, and/or context of the specification. MDA is Model Driven Architecture CIM is Computationally Independent Model (Conceptual) PIM is Platform-Independent Model (Logical) PSM is Platform-Specific Model (Implementable) Figure 8 shows the relationship between the RM-ODP viewpoints and Working Interoperability ECCF Traceability Adding WI fidelity, traceability among architectural artifacts should be addressed within or referenced by an ECCF SS. The relevancy of the Platform Specific Model (PSM) level statements substantially increases when the conformance statements are traceable derivatives from conformance statements at the Platform-Independent Model (PIM) and Computationally Independent Model (CIM) levels of the Specification Stack (SS) instance. The more mature 24 the SS instance, the greater the conformance value. Figure 9 is an abstract view of traceability, which we will make more specific within our IMC ECCF SS presented below. As a project advances, detailed requirements, architecture, design, deployment, test and certification traceability should be audited at Software Development Lifecycle (SDLC) configuration baselines, which are typically established at a System Requirements Review (SRR), Preliminary Design 24 The term mature refers to the completeness of a given SS instance; the extent to which the SS subject cells are fully populated i.e., the degree to which the maximum number of possible explicit assumptions and conformance statements have been made across the cells of the SS. This is represented by the collection of SS cells that are populated with the appropriate artifacts. 5/16/2010 Page 31 of 139

33 Review (PDR), Critical Design Review (CDR), and Test Readiness Review (TRR). At each of these reviews, a successful baseline should be established and the traceable configuration audit should be one of a review s exit criterion Figure 9 IS10 IRM HITSP Constructs Mapped to Standards ECCF Glossary and Traceability Meta-Model This section presents a notional set of architectural artifacts. Some subset or variations of these should populate any ECCF SS. The following list provides definitions for the notional value set of architectural artifacts shown in Table 5. - Accountability defines Who does what to whom. [SAIF BF] - Automation Unit describes the implementation of a single service, several services, or an application. It is itself a specialized form of versioned-specification. It consists of a collection of deployable artifacts, which can be decomposed into distributed Automation Units. - Base Standard: is a standard capable of fulfilling a discrete function within a single category produced and maintained by a single standards organization. Examples include HL7 v2.x, SNOMED-CT. [HITSP TN904] - Behavior is sets of actions and constraints on when the actions can occur. [SAIF BF] - Capability (CAP): is an implementable business service that addresses a focused business need by supporting stakeholder requirements and business processes. A CAP Specifies required optional and required secure, interoperable Information Exchanges between System Roles using HITSP constructs. A CAP identifies how to claim conformance, when options are resolved by an IS or implementation. [HITSP TN904] - Component: is a construct that defines the set of data elements, structures, relationships, constraints and terminology needed to support specific reusable information content. A Component may also express constraints on base or composite standards, examples include the Lab Result Message and Lab Result Document. [HITSP TN904] - Construct: is a specification based on harmonized interoperability standards. HITSP defines Transaction, Transaction Package, Service Collaboration and Component constructs. [HITSP TN904] - Contract is an agreement covering part of the collective behavior of any number of role instances. [SAIF BF] - Conceptual Functional Service Specification (CFSS) is the formal specification of a Conceptual Functional Model [NIH] (e.g., EHR System Design Functional Model). - Collaboration Participation model specifies the system roles and their information exchanges for a system capability (e.g., document management), which may support one-or-more system functions (e.g., patient identification, registry query, repository request). [SAIF BF] - Collaboration or Orchestration scripts define threads-of-execution, which achieve meaningful system or business functions. 5/16/2010 Page 32 of 139

34 Collaboration types might be some combination of Distributed, Client-Server, Federated, Synchronous or Asynchronous etc. [SAIF BF] - Composite Standard: is a grouping of coordinated base standards, often from multiple standards organizations, maintained by a single organization. Examples include IHE Information Technology Infrastructure XDS Integration Profile. [HITSP TN904] - Conceptual data model is developed based on the data requirements for the application that is being developed, perhaps in the context of an activity model. The data model will normally consist of entity types, attributes, relationships, integrity rules, and the definitions of those objects. - Data are facts, observations, measures or conclusions recorded about a subject of interest (often termed a unit of observation), at a particular place through a particular process for a particular purpose. Each fact can be termed a data element and is meaningless unless the context in which it was recorded is known. A Data Model is a means of categorizing and grouping data items (persons, places, objects, processes) of interest. However, in a data model, a single piece of data should be identified only once and be associated with the specific subject it describes. This level of discipline is required to appropriately specify requirements for information systems. Information systems have a structure just as buildings and bridges do. Therefore, they must be constructed with the same attention to design to achieve the same high degree of quality and reliability that is expected of physical structures. [Conceptual Health Data Model v2.3, Canadian Institute for Health Information] - Data Requirement (DR): defines requirements for all or part of the IER exchange content as a set of data elements with specific semantic details. [HITSP TN904] - Deployment Topology is the allocation of Platforms and Capabilities and capability System Roles to Systems. - Harmonization Framework: defines the terms, concepts and their relationships within a HITSP Interoperability Specification (IS), Capability (CAP), Component (C), Transaction (T), Transaction Package (TP) and Service Collaboration (SC). - Information is a set of data that has been collated, interpreted and presented to be meaningful to a particular audience for a particular purpose. Information for one purpose can be recorded and/or transformed to become data used as input into a new process to create information for a different purpose. Transformation processes may be automated or be the result of human judgment. An Information Model then, is a means of classifying information topics of interest. A Data Model defines the specific subjects and the facts about them. The same data can be used to produce many different pieces of information. A Data Model does not identify or define any topics that are essentially derived by any transformation process. [Conceptual Health Data Model v2.3, Canadian Institute for Health Information] - Information Exchange Requirement (IER): is a business requirement described in terms of Exchange Content, Exchange Action, and Systems involved in the exchange and Exchange Attributes. [HITSP TN904] Exchange Content: describes the information to be communicated in business terms Exchange Action: describes the interaction that communicates the Exchange Content between the Systems Exchange Attributes: are parameters about an Information Exchange. Examples are constraints, conditions and triggers IER Identifier: is an optional IER name and number, which is local to an IS and valid within the scope of an IS - Exchange Architecture: defines the fundamental topologies that can be used in implementing the HITSP Interoperability Specifications in systems (e.g., EHR systems directly connected or connected to Health Information Exchanges (HIEs) and HIEs connected to other HIEs. [HITSP TN904] - Functional Profile is a collection of Proposed Operations that align with some intended usage patterns. Often, these are characterized by quality considerations, such as security or performance, though they may not be so. - Function Types are Direct Care, Supportive Care, Infrastructure, etc. and their sub-types. See EHR System Functional Model. - Harmonization Request: defines business or functional needs, within a workflow, and sets context and conditions for the Interoperability Specification. Behavioral specifications of functional needs or capabilities may be structured as Use Cases, Scenarios, Business Process Models or other forms. [HITSP TN904] - Implementation Specifications bind environment and platforms (e.g., J2EE,.NET, etc) to Platform Independent specifications. [SAIF BF] - Interaction is something that happens between a role s interfaces and other roles in its environment. [SAIF BF] - Interface is an abstraction of the behavior of an object that consists of a subset of the interactions of that object together with a set of constraints that define when the identified interactions can occur. [SAIF BF] - Interface: is the set of features and obligations that support Information Exchanges for a HITSP system. Interfaces and Information Exchanges between interfaces are specified by HITSP Constructs, including Service Collaborations for example, Content Creator, Document Consumer, Eligibility Information Receiver and Audit Record Repository. [HITSP TN904] - Interface Design Specifications includes the content, transport, privacy and security standards and protocols for system data exchanges. Software engineering best-practices recommend an Information Hiding approach with a separate external specification for use and internal information and behavior specification for implementation. - Interaction Specifications define information exchange Transport, Content, Constraints, Systems or System Roles. [SAIF BF] - Interface Types are Message, Document or Service. [SAIF ECCF] - Interoperability Specification (IS): is organized by scenarios, Capabilities and integrates and constrains Constructs to specify the interoperability needs of one or more business processes. [HITSP TN904] - Role is a cohesive set of capabilities, capacities, or competencies abstracted as behaviors, which can be invoked at run-time. - Service definition contains the terms for information exchange, providing the service s technical constraints and requirements as well as any semantic information needed to consume the service. It is comprised of two parts: (1) an abstract portion; and (2) a concrete portion. The abstract portion describes the functionality of the service. It includes a series of technology-independent elements: the interface, 5/16/2010 Page 33 of 139

35 operations, operation semantics, and data structure definitions. The concrete portion describes how to access the service. It effectively designates how the abstract interface connects to technology that implements the service. Note that there can be more than one concrete portion corresponding to a single abstract portion. This ensures that the means used to access the service such as web services, messaging or direct invocation can be independent of the abstract service definition. The Service Implementation is the core logic in support of the service definition. It is essentially the code behind the service, often written in an application language like Java,.Net or C++. [IHE SOA Whitepaper] - Service Collaboration (SC): is the composition of Transaction, Transaction Package, or Component constructs into a reusable workflow, primarily at the infrastructure level, for example HITSP/SC115 HL7 Messaging Service Collaboration. [HITSP TN904] - Service contracts might include Information model extracts for semantic interoperability, role-based security, costs, etc. In NHIN this is known as a Distributed User Resource Sharing Agreement (DURSA). - Stakeholder: is defined as a person or organization that uses or benefits from systems that interoperate. [HITSP TN904] - System: is an IT software application that plays an initiating or responding role in one or more Information Exchanges addressed by a Interoperability Specification or Capability. [HITSP TN904] - System Role: is a set of closely related capability behaviors, which satisfy a business need. A Capability has two or more System Roles, such as Order Placer; Order Filler; Specimen Analyzer. Behaviors are the set of prescribed and optional Information Exchanges among systems roles. In an IS or implementation, a system supports one or more capability system roles from each capability it supports. [HITSP TN904] - Transaction (T): is a logical grouping of data exchanges and transport methods that must all succeed or fail as a group. Examples are the Query Lab Result or Send Lab Result. [HITSP TN904] - Transaction Package (TP): is a logical grouping of two or more Transactions, Transaction Packages, and/or composite standards used to fulfill Information Exchange Requirements (IERs). A Transaction Package is not required to succeed or fail as a whole. Examples include the Record Locator Service and Entity Identification Service. [HITSP TN904] - Technical Interface is a technology specific interface provided by an Automation Unit.. - Technical Operation is a specific function provided by a particular Technical Interface, which is technology specific. - Use Cases can be specified textually as a sequence of Scenarios, Events and Actions. They can also be specified as Business Process Models. - Wireframe is a basic visual guide used in interface design to suggest the structure of a website and relationships between its pages. A system component wireframe is a similar illustration of the layout of fundamental elements in the component or system and their interfaces. [adapted from Wikipedia] Figure 10 ECCF SS Traceability Meta Model shows the associations among the set of notional architectural artifacts shown in Table 5 Notional Set of Architectural Artifacts within the HL7 SAIF ECCF SS. This can be a many-to-one mapping because the granularity of a particular architectural artifact may not match the ECCF SS granularity. This is a typical set of architectural products. Obviously, variations among and within architectural artifacts may replace the ones listed in the notional set used in this section. TBD Figure 10 ECCF SS Traceability Meta Model ECCF Implementation Guide A mature ECCF SS shall contain a clear, complete, concise, correct, consistent and traceable set of architectural artifacts, organized as follows: 1. The ECCF Conceptual Enterprise-Business-Viewpoint defines the business and reference context. The Enterprise- Business-Viewpoint is concerned with the purpose and behaviors of the system as it relates to the business objective, environment and the business processes of the organization. This Viewpoint answers the question why and refers to policy. This Viewpoint is primarily useful to project sponsors, project managers, program directors, IT directors and requirements analysts. This Viewpoint might typically contains some combination of: Inventory of Use Cases Stakeholders Capabilities-Services Requirements\Contracts Business Scope 5/16/2010 Page 34 of 139

36 Business Vision Business Objectives Policy & Regulations 2. The ECCF Conceptual Information-Viewpoint is defined by the domain analysis information model. The Information- Viewpoint is concerned with the nature of the information handled by the system and constraints on the use and interpretation of that information. This Viewpoint answers the question what and refers to information content. This Viewpoint is primarily useful to clinicians and clinical analysts. This Viewpoint might typically contains some combination of: Inventory of Domain Entities, Roles, Activities and Associations. Information Model Conceptual Domain 3. The ECCF Conceptual Computational Viewpoint is defined by collaboration analysis (e.g., BPM and UML sequence or activity diagrams), functional profiles, service roles and relationships. The computational viewpoint is concerned with the functional decomposition of the system into a set of components that exhibit specific behaviors and interact at interfaces. This Viewpoint answers the question how and references behavioral specifications. This Viewpoint is primarily useful to business analysts and functional analysts. This Viewpoint might typically contains some combination of: Inventories of Capabilities-Components, Functions-Services Requirements Accountability Roles Behaviors Functional Profiles Interactions Interfaces Contracts Conceptual Functional Service Specifications (CFSS) 4. The ECCF Conceptual Engineering-Viewpoint is defined by existing platform capabilities. The Engineering-Viewpoint is concerned with the mechanisms and functions required to support the interactions of the computational components. This ECCF Viewpoint may overlap with the RM-ODP technology viewpoint, which is concerned with the explicit choice of technologies for the implementation of the system, and particularly for the communications among the components. This Viewpoint is primarily useful to enterprise architects. This Viewpoint answers the question where and refers to implementation environments. This Viewpoint might typically contains some combination of: Inventory of Software Platforms/ Environments. 5. The ECCF Platform-Independent Enterprise-Business-Viewpoint defines the business and reference context. The Enterprise-Business-Viewpoint is concerned with the business governance of the system as it relates to the 5/16/2010 Page 35 of 139

37 business objectives and the business processes of the organization. This Viewpoint answers the question why and refers to policy. This Viewpoint is primarily useful to project managers and business process experts. This Viewpoint might typically contains some combination of: Applicable Rules Use Case Specs Governance. Technology Neutral Standards Wireframes of architectural layers components and Associations 6. The ECCF Platform-Independent Information-Viewpoint is defined by the project information model. The Information- Viewpoint is concerned with the nature of the information handled by the system and constraints on the use and interpretation of that information. This view answers the question what and refers to information content. This Viewpoint is primarily useful to clinical informaticists. This Viewpoint answers the question where and refers to implementation environments. This Viewpoint might typically contains some combination of: Information Model Localized Information Model Constrained Information Model Project Information Model Message Content Specifications 7. The ECCF Platform-Independent Computational-Viewpoint is defined by collaboration analysis (e.g., UML sequence diagrams), functional profiles, service roles and relationships. The Platform-Independent Computational- Viewpoint is concerned with the functional decomposition of the system into a set of components that exhibit specific behaviors and interact at interfaces. This Viewpoint answers the question how and references behavioral specifications. This viewpoint is primarily useful to System Engineers and Business Process Modelers. This Viewpoint might typically contains some combination of: Use Case Specs Component specs Interface Specs Interaction Specs Collaboration Participations Collaboration Types Function Types Interface Types Collaboration Scripts Service Contracts 8. The ECCF Platform-Independent Engineering-Viewpoint is defined by existing platform capabilities. The Engineering- Viewpoint is concerned with the mechanisms and functions required to support the interactions of the computational components. This ECCF viewpoint may overlap with the RM-ODP technology viewpoint, which is concerned with the explicit choice of technologies for the implementation of the system, and particularly for the communications among the components. This viewpoint answers the question where and refers to implementation environments. This viewpoint is of primary interest to Application Architects. This Viewpoint might typically contains some combination of: 5/16/2010 Page 36 of 139

38 Existing Platform models, Capabilities, Libraries and Versions. 9. The ECCF Platform-Specific Enterprise-Business-Viewpoint defines the business and reference context. The Enterprise- Business-Viewpoint is concerned with the business or reference context, purpose and behaviors of the system as it relates to the business objective and the business processes of the organization. This viewpoint answers the question why and refers to policy. This viewpoint is primarily useful to managers, compliance staff and auditors. This Viewpoint might typically contains some combination of: Business Nodes Business Rules Business Procedures Business Workflow Technology Specific Standards 10. The ECCF Platform-Specific Information-Viewpoint is defined by localized information models. The Information- Viewpoint is concerned with the nature of the information handled by the system and constraints on the use and interpretation of that information. This viewpoint answers the question what and refers to information content. This viewpoint is primarily useful to information modelers. This viewpoint is primarily useful to managers, compliance staff and auditors. This Viewpoint might typically contains some combination of: Database Schemas Message Schemas Transformation Schemas (e.g., XSD) 11. The ECCF Platform-Specific Computational Viewpoint is defined by collaboration analysis (e.g., UML sequence diagrams), functional profiles, service roles and relationships. The computational viewpoint is concerned with the functional decomposition of the system into a set of components that exhibit specific behaviors and interact at interfaces. This viewpoint answers the question how and references behavioral specifications. This viewpoint is primarily useful to system integrators and solution and solution architects. This Viewpoint might typically contains some combination of: Automation Unit Technical Interfaces Technical Operations Orchestration Scripts 12. The ECCF Platform-Specific Engineering-Viewpoint is defined by existing platform capabilities. The Engineering- Viewpoint is concerned with the mechanisms and functions required to support the interactions of the computational components. This ECCF viewpoint may overlap with the RM-ODP technology viewpoint, which is concerned with the explicit choice of technologies for the implementation of the system, and particularly for the communications among the components. This viewpoint answers the question where and refers to implementation environments. This viewpoint is primarily useful to application developers. This Viewpoint might typically contains some combination of: Application Specifications GUI specifications Deployment Topology or Execution Context Platform Bindings 2.3 Conceptual Enterprise-Business-Viewpoint 5/16/2010 Page 37 of 139

39 The ECCF Conceptual Enterprise-Business-Viewpoint defines the business and reference context. The Enterprise-Business- Viewpoint is concerned with the purpose and behaviors of the system as it relates to the business objective, environment and the business processes of the organization. This Viewpoint answers the question why and refers to policy. This Viewpoint is primarily useful to project sponsors, project managers, program directors, IT directors and requirements analysts. The ECCF Conceptual Enterprise-Business-Viewpoint typically contains: Inventory of Use Cases Stakeholders Capabilities-Services Requirements\Contracts Business Scope Business Vision Business Objectives Policy & Regulations Policy and Regulation The following have impact on this project: The Federal Health IT Policy Committee, which makes recommendations to the National Coordinator for Health Information Technology (HIT) on a policy framework for the development and adoption of a nationwide health information infrastructure, including standards for the exchange of patient medical information. The American Recovery and Reinvestment Act of 2009 (ARRA) provides that the HIT Policy Committee shall at least make recommendations on standards, implementation specifications, and certifications criteria in eight specific areas: o Technologies that protect the privacy of health information o A nationwide health information technology infrastructure o The utilization of a certified electronic record for each person in the US by 2014 o Technologies that support accounting of disclosures made by a covered entity o The use of electronic records to improve quality o Technologies that enable identifiable health information to be rendered unusable/unreadable o Demographic data collection including race, ethnicity, primary language, and gender o Technologies that address the needs of children and other vulnerable populations The Federal Health IT Standards Committee, which makes recommendations to the National Coordinator for Health Information Technology (HIT) on standards, implementation specifications, and certification criteria for the electronic exchange and use of health information. Initially, the HIT Standards Committee focused on the policies developed by the Health IT Policy Committee s initial eight areas. Within 90 days of the signing of ARRA, the HIT Standards Committee developed a schedule for the assessment of policy recommendations developed by the HIT Policy Committee, to be updated annually. In developing, harmonizing, or recognizing standards and implementation specifications, the HIT Standards Committee also provided for the testing of same by the National Institute for Standards and Technology (NIST). HIPAA 25 - The Health Insurance Portability and Accountability Act of 1996 (HIPAA) required the Secretary of the U.S. Department of Health and Human Services (HHS) to develop regulations protecting the privacy and security of certain health information. 1 To fulfill this requirement, HHS 25 For additional information, see 5/16/2010 Page 38 of 139

40 published what are commonly known as the HIPAA Privacy Rule and the HIPAA Security Rule. The Privacy Rule, or Standards for Privacy of Individually Identifiable Health Information, establishes national standards for the protection of certain health information. The Security Standards for the Protection of Electronic Protected Health Information (the Security Rule) establish a national set of security standards for protecting certain health information that is held or transferred in electronic form. The Security Rule operationalizes the protections contained in the Privacy Rule by addressing the technical and non-technical safeguards that organizations called covered entities must put in place to secure individuals electronic protected health information (e-phi). The HIPAA/EDI provision took effect on October 16, On January 1, 2012 the newest version 5010 becomes effective, replacing the version This allows for the larger field size of ICD-10-CM as well as other improvements. The HITECH Act, part of the 2009 economic stimulus package (ARRA) passed by the US Congress, aims at inducing more physicians to adopt EHR. Title IV of the act promises incentive payments to those who adopt and use "certified EHRs" and, eventually, reducing Medicare payments to those who do not use an EHR. Funding for EHR incentives is also added to the Medicaid system. In order to receive the EHR stimulus money, the HITECH act (ARRA) requires doctors to also show "meaningful use" of an EHR system. HITECH Standards & Certification Criteria Interim Final Rule (IFR) on an initial set of standards, implementation specifications, and certification criteria for adoption by the HHS Secretary was issued on December 30, 2009, with a request for comments. This Interim Final Rule represents the first step in an incremental approach to adopting standards, implementation specifications, and certification criteria to enhance the interoperability, functionality, utility, and security of health IT and to support its meaningful use. The certification criteria adopted in this initial set establish the required capabilities and related standards that certified electronic health record (EHR) technology will need to include in order to, at a minimum, support the achievement of the proposed meaningful use Stage 1 (beginning in 2011) by eligible professionals and eligible hospitals under the Medicare and Medicaid EHR incentive programs. HITSP/ TN Securities and Privacy Technical Note provides the context for use of the HITSP Security and Privacy constructs, based on the American Health Information Community (AHIC) Use Cases. It includes a design map of existing standards and specifications that will be used to meet the stated requirements of the Use Cases. It references the Requirements, Design and Standards Selection document which describes the process by which the Use Cases were analyzed, candidate standards were identified and the design developed Privacy & Security Requirements HITSP TN900 specifies the constructs to support a wide variety of security and privacy policies and technical frameworks. Consistent with the HITSP Technical Committee Terms of Reference, HITSP has not attempted to resolve privacy or security policy issues, risk management, healthcare application functionality, operating systems functionality, physical control specifications, or other low-level specifications. This approach is crucial because of the variety of requirements that the HITSP Security and Privacy constructs will be called on to address. The United States has an extensive body of federal and state laws and regulations that define the security and privacy requirements for collecting, creating, maintaining, using, disclosing and disposing individually identifiable health information. Among them, at the federal level are: 5/16/2010 Page 39 of 139

41 American Recovery and Reinvestment Act (ARRA) of 2009, including Health Information Technology for Economic and Clinical Health (HITECH) HIPAA Privacy Regulations (45 CFR 160 and 164 Part E) HIPAA Security Regulations (45 CFR 160 and 164 Part C) Confidentiality of Alcohol and Drug Abuse Patient Records (42 CFR Part 2) Family Education Rights and Privacy Act (FERPA) Privacy Act of 1974 Right to Financial Privacy Act (1978) Privacy Protection Act of 1980 Electronic Communications Privacy Act (1986) Communications Assistance for Law Enforcement Act of 1994 Telecommunications Act of 1996 Financial Modernization Act (Gramm-Leach-Bliley Act) (2000) Emergency Supplemental Appropriations Act for Defense, the Global War on Terror and Tsunami Relief (Real ID Act) (2005) At the state level, numerous state health information laws and regulations exist with different degrees of detail and granularity, some more stringent (thus, not preempted) by the overarching HIPAA Security and Privacy regulations. These laws and regulations generally apply to the: Holder of the data User (requester) of the data Data itself Purpose of the use or disclosure of the data Timing of the use and disclosure of the data Methods and mechanisms used to collect, maintain, use and disclose data Several of them also define and assign specific rights to consumers with respect to controls consumers can exercise over the collection, access, use and disclosure of their health information. In developing the HITSP Security and Privacy constructs, HITSP considered a set of overarching principles and concepts, derived from an analysis of major federal and common state laws and regulations. They included: Privacy Principles Consumer consent requirements (including the concepts of consent and authorization, whether they are considered one and the same in some regulations, or treated differently in others) Consumer s ability to provide directives on: The collection, access, use and disclosure of his/her health information What information is collected, accessed, used, disclosed By whom To whom For what purpose(s) When For how long Consumer s ability to modify or revoke directives Patient privacy rights, such as those identified in the HIPAA Privacy regulations, including the right to: Receive a Notice of Privacy Practices Access individually identifiable health information for review and/or copy 5/16/2010 Page 40 of 139

42 Request amendments to health information Request privacy protections to health information including the right to request restrictions on the use and disclosure of health information and the right to request confidential communications from a covered entity Request an accounting of certain disclosures that a covered entity has made of their protected health information (within the context of HIPAA) File a complaint about privacy issues Privacy requirements: Various degrees of sensitive health information Minimum necessary Accounting of disclosure Procedures for ensuring confidential communications are being done (i.e., sending an electronic message with results to the patient at an alternative location) Deidentification (anonymization) of information, when necessary Verification requirements of the identity and authority of individual requesting health information prior to disclosure (if not known by the entity disclosing the information), including documentation of such identify and authority Mitigation of harm, in the event of a use or disclosure done in violation of privacy requirements or organization s own policies and procedures Security Principles Availability of health information information is available when and where needed Confidentiality information is not accessed, used, disclosed by non-authorized individuals or entities Integrity - Information content not alterable except under authorized circumstances Accountability ensuring that those collecting, accessing, using or disclosing health information are accountable for their roles and responsibilities Identification of users and subjects of health information, as appropriate and applicable Authentication of users and subjects of health information, as appropriate and applicable Authorization of those identified and authenticated, to allow them to perform the functions they are specifically authorized to perform with the health information they are collecting, accessing, using or disclosing Access Control - only authorized persons can access health information for authorized purposes Attribution/nonrepudiation - actions taken are reliably traceable Auditability controls to identify, record and report and monitor health information events Secure communication between entities exchanging health information Time recording methods to control time of events in a consistent manner Through an iterative process, these overarching concepts where identified and further refined in conjunction with the review of the first set of AHIC Use Cases. Further refinement of the existing constructs will continue, and new potential constructs will be identified and defined in the future, as new Use Cases are presented to HITSP. Consistent with the HITSP Technical Committee Terms of Reference, the work of the Committee does not define or attempt to resolve security and privacy policy issues, risk management, healthcare application functionality, operating systems functionality, physical control specifications, or other low-level specifications. The HITSP Security and Privacy constructs were designed to support a wide range of federal, state, local, and institutional policies. Work is being done elsewhere, and through other national and regional efforts to identify, define and address security and privacy related policy issues. 5/16/2010 Page 41 of 139

43 These efforts include: The Health Information Technology Policy Committee d=true Health Information Technology Standards Committee d=true National ehealth Collaborative The American Health Information Community s Confidentiality (AHIC), Security and privacy Workgroup The Health Information Security and Privacy Collaborative (HISPC) t/publish/communities/a_e/ahrq_funded_projects/rti_public_page/main.html Certification Commission for Healthcare Information Technology (CCHIT), utilizing security and privacy standards in developing certification criteria Office for Civil Rights (OCR), HIPAA Privacy Agency for Healthcare Research and Quality (AHRQ), Health Information Technology Program Centers for Disease Control and Prevention (CDC), Public Health Information Network (PHIN) Centers for Disease Control and Prevention (CDC), BioSense Health Resources and Services Administration (HRSA) Substance Abuse and Mental Health Services Administration (SAMHSA) Indian Health Services (IHS) U.S. Department of Defense (DoD) U.S. Department of Veterans Affairs (VA) NCVHS National Committee on Vital and Health Statistics (NCVHS) National Governors Association s State Alliance for e-health (NGA) RD The variability in health information security and privacy federal and state laws and regulations, and business policies and practices across the country, poses significant challenges to the development of a common set of security and privacy constructs. With this in mind, HITSP used an approach based on the identification of a core set of overarching policy concepts, and the establishment of a minimum common base set of requirements that could be applied to different health information exchange scenarios. In looking at the various candidate standards for Security and Privacy Constructs, HITSP identified a group of standards that may be used in guiding the implementation of the constructs. These are listed in Table 6 Guidance Standards below: 5/16/2010 Page 42 of 139

44 Table 6 Guidance Standards Standard ISO 27799:Health informatics: Security management in health using ISO ASTM E1869: Standard Guide for Confidentiality, Privacy, Access, and Data Security Principles for Health Information Including Electronic Health Records ASTM E1986: Standard Guide for Information Access Privileges to Health Information ASTM E2086: Standard Guide for Internet and Intranet Healthcare Security ASTM E2085: Standard Guide on Security Framework for Healthcare Information WS-I: Security Challenges, Threats and Countermeasures Version 1.0 ISO 15408: Common Criteria Toolkit ASTM E2595 PMI: Privilege Management Infrastructure ASTM E1985: Standard Guide for User Authentication and Authorization ASTM E1987: Standard Guide for Individual Rights Regarding Health Information NIST Special Publications (800 Series) NIST Federal Information Processing Standards (FIPS) Publications Reference csrc.nist.gov HITECH Meaningful Use Objectives and Criteria There are 25 specific HITECH Meaningful Use (MU) objectives and criteria for the 2011 MU Stage I: 1. Objective: Use CPOE (Computerized Physician Order Entry) Measure: CPOE is used for at least 80 percent of all orders 2. Objective: Implement drug-drug, drug-allergy, drug- formulary checks Measure: The EP (Eligible Provider) has enabled this functionality 3. Objective: Maintain an up-to-date problem list of current and active diagnoses based on ICD-9-CM or SNOMED CT Measure: At least 80 percent of all unique patients seen by the EP have at least one entry or an indication of none recorded as structured data. 4. Objective: Generate and transmit permissible prescriptions electronically (erx). Measure: At least 75 percent of all permissible prescriptions written by the EP are transmitted electronically using certified EHR technology. 5. Objective: Maintain active medication list. Measure: At least 80 percent of all unique patients seen by the EP have at least one entry (or an indication of none if the patient is not currently prescribed any medication) recorded as structured data. 6. Objective: Maintain active medication allergy list. Measure: At least 80 percent of all unique patients seen by the EP have at least one entry (or an indication of none if the patient has no medication allergies) recorded as structured data. 7. Objective: Record demographics. Measure: At least 80 percent of all unique patients seen by the EP or admitted to the eligible hospital have demographics recorded as structured data 8. Objective: Record and chart changes in vital signs. Measure: For at least 80 percent of all unique patients age 2 and over seen by the EP, record blood pressure and BMI; additionally, plot growth chart for children age 2 to Objective: Record smoking status for patients 13 years old or older Measure: At least 80 percent of all unique patients 13 years old or older seen by the EP smoking status recorded 10. Objective: Incorporate clinical lab-test results into EHR as structured data. Measure: At least 50 percent of all clinical lab tests results ordered by the EP or by an authorized provider of the eligible hospital during the EHR reporting period whose results are in either in a positive/negative or numerical format are incorporated in certified EHR technology as structured data. 11. Objective: Generate lists of patients by specific conditions to use for quality improvement, reduction of disparities, research, and outreach. Measure: Generate at least one report listing patients of the EP with a specific condition. 12. Objective: Report ambulatory quality measures to CMS or the States. Measure: For 2011, an EP would provide the aggregate numerator and denominator through attestation as discussed in section II.A.3 of this proposed rule. For 2012, an EP would electronically submit the measures are discussed in section II.A.3. of this proposed rule. 5/16/2010 Page 43 of 139

45 Objective: Send reminders to patients per patient preference for preventive/ follow-up care Measure: Reminder sent to at least 50 percent of all unique patients seen by the EP that are 50 and over 14. Objective: Implement five clinical decision support rules relevant to specialty or high clinical priority, including for diagnostic test ordering, along with the ability to track compliance with those rules Measure: Implement five clinical decision support rules relevant to the clinical quality metrics the EP is responsible for as described further in section II.A Objective: Check insurance eligibility electronically from public and private payers Measure: Insurance eligibility checked electronically for at least 80 percent of all unique patients seen by the EP 16. Objective: Submit claims electronically to public and private payers. Measure: At least 80 percent of all claims filed electronically by the EP. 17. Objective: Provide patients with an electronic copy of their health information (including diagnostic test results, problem list, medication lists, and allergies) upon request Measure: At least 80 percent of all patients who request an electronic copy of their health information are provided it within 48 hours. 18. Objective: Provide patients with timely electronic access to their health information (including lab results, problem list, medication lists, allergies) Measure: At least 10 percent of all unique patients seen by the EP are provided timely electronic access to their health information 19. Objective: Provide clinical summaries to patients for each office visit. Measure: Clinical summaries provided to patients for at least 80 percent of all office visits. 20. Objective: Capability to exchange key clinical information (for example, problem list, medication list, allergies, and diagnostic test results), among providers of care and patient authorized entities electronically. Measure: Performed at least one test of certified EHR technology s capacity to electronically exchange key clinical information. 21. Objective: Perform medication reconciliation at relevant encounters and each transition of care. Measure: Perform medication reconciliation for at least 80 percent of relevant encounters and transitions of care. 22. Objective: Provide summary care record for each transition of care and referral. Measure: Provide summary of care record for at least 80 percent of transitions of care and referrals. 23. Objective: Capability to submit electronic data to immunization registries and actual submission where required and accepted. Measure: Performed at least one test of certified EHR technology s capacity to submit electronic data to immunization registries. 24. Objective: Capability to provide electronic syndromic surveillance data to public health agencies and actual transmission according to applicable law and practice. Measure: Performed at least one test of certified EHR technology s capacity to provide electronic syndromic surveillance data to public health agencies (unless none of the public health agencies to which an EP or eligible hospital submits such information have the capacity to receive the information electronically). 25. Objective: Protect electronic health information maintained using certified EHR technology through the implementation of appropriate technical capabilities. Measure: Conduct or review a security risk analysis in accordance with the requirements under 45 CFR (a)(1) and implement security updates as necessary. MU Objective 23 directly addresses Immunization Management. MU Objectives 7, 17, 18, 19, 22 and 25 impact immunization management Business Objectives SampleHealth s business objectives are: Patient safety and quality of care, Patient and clinician satisfaction, Meet government regulations, Minimize costs o Fast and efficient patient care, o Maximum utilization of clinician s time. o Qualify for maximum government reimbursements o Minimize medical-legal liability Project Scope and Vision Statement The Immunization Management Capability (IMC) project is intended to optimally accomplish immunization documentation and tracking, and support immunizations readiness reporting. The IMC initiative supports three broad goals: 5/16/2010 Page 44 of 139

46 Public Health Protection and Readiness perspective: a. Ensure a healthy and fit population that is fully medically ready and medically protect individuals with the maximal ability to safely pursue their education and careers. b. Improved medical readiness through documenting, monitoring and reporting immunization status. 2. Population Health perspective: a. Preventing and controlling diseases reduces adverse incidence requiring medical treatment. b. Compliant with current national standards and regulations to include patient safety and data quality. 3. Medical Care perspective: a. Patient safety. b. Provider has immunization history. c. Medical conditions require supplemental immunization. d. Contraindications to immunizations. 5/16/2010 Page 45 of 139

47 Non-Functional Requirements class DC (Manage Immunization Administration) EHR-S FM + Direct Care + Supportive Care + Information Infrastructure DC.1 Care Management DC.1.8 Documentation of Care, Measurements and Results DC (Manage Immunization Administration) DC (Manage Patient Advance Directives) DC (Manage Immunization List) S.1.1 (Registry Notification) SEE ALSO: DC DC S.1.1 S S IN.1.6 IN.1.7 IN.2.4 IN IN IN.3.1 IN.3.2 IN.4.1 IN.4.2 IN.4.3 IN.5.1 IN.5.2 IN.6 IN.3.1 and IN.3.2 do not exist! Substituted IN.3. S (Standard Report Generation) S (Clinical Decision Support System Guidelines Updates) IN.1.6 (Secure Data Exchange) IN.1.7 (Secure Data Routing) IN.2.4 (Extraction of Health Record Information) IN (Manage Unstructured Health Record Information) IN (Manage Structured Health Record Information) IN.3 Registry and Directory Services IN.4.1 (Standard Terminologies and Terminology Models) IN.4.2 (Maintenance and Versioning of Standard Terminologies) IN.4.3 (Terminology Mapping) IN.5.1 (Interchange Standards) IN.5.2 (Interchange Standards Versioning and Maintenance ) IN.6 Business Rules Management Figure 11 EHR-S FM Direct Care Manage Immunization Administration Dependencies The EHR-SD RM provides Figure 11 EHR-S FM Direct Care Manage Immunization Administration Dependencies, which shows how Immunization Management depends on the EHR System Non-functional requirements (e.g., IN.1.6, IN.1.7, IN.2.4, IN.2.5.1, IN.2.5.2, IN.3.1, IN.3.2, IN.4.1, IN.4.2, IN.4.3, IN.5.1, IN.5.2, IN.6) and results in the following overall conformance criteria: DC Manage Immunization Administration depends on IN 1.6 Secure Data Exchange 1. The system SHALL secure all modes of EHR data exchange. 2. The system SHOULD conform to function IN.1.7 (Secure Data Routing). 3. The system MAY provide the ability to obfuscate data. 5/16/2010 Page 46 of 139

48 The system SHALL encrypt and decrypt EHR data that is exchanged over a non-secure link. 5. The system SHALL support standards-based encryption mechanisms when encryption is used for secure data exchange. DC Manage Immunization Administration depends on IN 1.7 Secure Data Routing 1. The system SHALL automatically route electronically exchanged EHR data only from and to known sources and destinations and only over secure networks. 2. The system SHOULD route electronically exchanged EHR data only to and from authenticated sources and destinations (conform to function IN.1.1 (Entity Authentication)). 3. The system SHOULD conform to function IN.2.2 (Auditable Records) to provide audit information about additions and changes to the status of destinations and sources. DC depends on IN 2.4 Extraction of Health Record Information 1. The system SHALL provide the ability to extract health record information. 2. The system SHOULD conform to function IN.1.6 (Secure Data Exchange) to provide secure data exchange capabilities. 3. The system SHOULD provide the ability to de-identify extracted information. 4. The system SHOULD conform to function IN.5.1 (Interchange Standards) to enable data extraction in standard-based formats. 5. The system SHOULD provide the ability to perform extraction operations across the complete data set that constitutes the health record of an individual within the system. 6. The system MAY provide the ability to perform extraction operations whose output fully chronicles the healthcare process. 7. The system SHOULD provide the ability to extract data for administrative purposes. 8. The system SHOULD provide the ability to extract data for financial purposes. 9. The system SHOULD provide the ability to extract data for research purposes. 10. The system SHOULD provide the ability to extract data for quality analysis purposes. 11. The system SHOULD provide the ability to extract data for public health purposes. DC depends on IN Manage Unstructured Health Record Information 1. The system SHALL capture unstructured health record information as part of the patient EHR. 2. The system SHALL retrieve unstructured health record information as part of the patient EHR. 3. The system SHALL provide the ability to update unstructured health record information. 4. The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction) to provide the ability to inactivate, obsolete, or destroy unstructured health record information. 5. The system SHOULD provide the ability to report unstructured health record information. 6. The system MAY track unstructured health record information over time. 7. The system SHALL provide the ability to append corrected unstructured health record information to the original unstructured health record information. A specific type of implementation is not implied. 8. The system SHALL provide the ability to append unstructured health record information to the original unstructured health record information. A specific type of implementation is not implied. 9. The system SHALL provide the ability to append augmented unstructured health record information to the original unstructured health record information. A specific type of implementation is not implied. DC depends on IN Manage Structured Health Record Information 1. The system SHALL capture structured health record information as part of the patient EHR. 2. The system SHALL retrieve structured health record information as part of the patient EHR. 3. The system SHALL provide the ability to update structured health record information. 4. The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction) to provide the ability to inactivate, obsolete, or destroy structured health record information. 5. The system SHOULD provide the ability to report structured health record information. 6. The system MAY track structured health record information over time. 7. The system SHOULD provide the ability to retrieve each item of structured health record information discretely within patient context. 8. The system SHALL provide the ability to append corrected structured health record information to the original structured health record information. A specific type of implementation is not implied. 9. The system SHALL provide the ability to append structured health record information to the original structured health record information. A specific type of implementation is not implied. 10. The system SHALL provide the ability to append augmented structured health record information to the original structured health record information. A specific type of implementation is not implied. DC depends on IN 3. Registry and Directory Services 1. The system SHALL provide the ability to use registry services and directories. 2. The system SHOULD provide the ability to securely use registry services and directories. 5/16/2010 Page 47 of 139

49 The system SHALL conform to function IN.5.1 (Interchange Standards) to provide standard data interchange capabilities for using registry services and directories. 4. The system SHOULD communicate with local registry services through standardized interfaces. 5. The system SHOULD communicate with non-local registry services (that is, to registry services that are external to an EHR-S) through standardized interfaces. 6. The system SHOULD provide the ability to use registries or directories to uniquely identify patients for the provision of care. 7. The system SHOULD provide the ability to use registries or directories to uniquely identify providers for the provision of care. 8. The system MAY provide the ability to use registries or directories to retrieve links to relevant healthcare information regarding a patient. 9. The system MAY provide the ability to use registries to supply links to relevant healthcare information regarding a patient. 10. The system MAY provide the ability to use registries or directories to identify payers, health plans, and sponsors for administrative and financial purposes. 11. The system MAY provide the ability to use registries or directories to identify employers for administrative and financial purposes. 12. The system MAY provide the ability to use registries or directories to identify public health agencies for healthcare purposes. 13. The system MAY provide the ability to use registries or directories to identify healthcare resources and devices for resource management purposes. DC depends on IN 4.1 Standard Terminologies and Terminology Models 1. The system SHALL provide the ability to use standard terminologies to communicate with other systems (internal or external to the EHR-S). 2. The system SHALL provide the ability to validate that clinical terms and coded clinical data exists in a current standard terminology. 3. The system SHOULD provide the ability to exchange healthcare data using formal standard information models and standard terminologies. 4. The system SHOULD provide the ability to use a formal standard terminology model. 5. The system SHOULD provide the ability to use hierarchical inference searches e.g., subsumption across coded terminology concepts that were expressed using standard terminology models. 6. The system SHOULD provide the ability to manage terminology assets and supporting tools (internal or external to the EHR-S). 7. IF there is no standard terminology model available, THEN the system MAY provide a formal explicit terminology model. DC depends on IN 4.2 Maintenance and Versioning of Standard Terminologies 1. The system SHALL provide the ability to use different versions of terminology standards. 2. The system SHALL provide the ability to update terminology standards. 3. The system MAY relate modified concepts in the different versions of a terminology standard to allow preservation of interpretations over time. 4. The system SHOULD provide the ability to interoperate with systems that use known different versions of a terminology standard. 5. The system SHOULD provide the ability to deprecate terminologies. 6. The system MAY provide the ability to deprecate individual codes within a terminology. 7. The system SHALL provide the ability to cascade terminology changes where coded terminology content is embedded in clinical models (for example, templates and custom formularies) when the cascaded terminology changes can be accomplished unambiguously. 8. Changes in terminology SHALL be applied to all new clinical content (via templates, custom formularies, etc.). DC depends on IN 4.3 Terminology Mapping 1. The system SHALL provide the ability to use a terminology map. 2. The system SHOULD provide the ability to use standard terminology services for the purposes of mapping terminologies. 3. The system MAY provide the ability for a user to validate a mapping. 4. The system MAY provide the ability to create a terminology map. DC depends on IN 5.1 Interchange Standards 1. The system SHALL provide the ability to use interchange standards as required by realm specific and/or local profiles. 2. The system SHALL provide the ability to seamlessly perform interchange operations with other systems that adhere to recognized interchange standards. 3. The system SHALL conform to functions under header IN.4 (Standard Terminologies and Terminology Services) to support terminology standards in accordance with a users' scope of practice, organizational policy, or jurisdictional law. 4. IF there is no standard information model available, THEN the system MAY provide a formal explicit information model in order to support the ability to operate seamlessly with other systems. 5. The system SHOULD provide the ability to exchange data using an explicit and formal information model and standard, coded terminology. DC depends on IN 5.2 Interchange Standards Versioning and Maintenance 5/16/2010 Page 48 of 139

50 The system SHALL provide the ability to use different versions of interchange standards. 2. The system SHALL provide the ability to change (reconfigure) the way that data is transmitted as an interchange standard evolves over time and in accordance with business needs. 3. The system SHOULD provide the ability to deprecate an interchange standard. 4. The system SHOULD provide the ability to interoperate with other systems that use known earlier versions of an interoperability standard. DC depends on IN 6 Business Rules Management 1. The system SHALL provide the ability to manage business rules. 2. The system SHOULD provide the ability to create, import, or access decision support rules to guide system behavior. 3. The system SHOULD provide the ability to update decision support rules. 4. The system SHOULD provide the ability to customize decision support rules and their components. 5. The system SHOULD provide the ability to inactivate, obsolete, or destroy decision support rules. 6. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to decision support rules. 7. The system SHOULD provide the ability to create diagnostic support rules to guide system behavior. 8. The system SHOULD provide the ability to update diagnostic support rules. 9. The system MAY provide the ability to customize diagnostic support rules and their components. 10. The system SHOULD provide the ability to inactivate, obsolete, or destroy diagnostic support rules. 11. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to diagnostic support rules. 12. The system SHOULD provide the ability to create workflow control rules to guide system behavior. 13. The system SHOULD provide the ability to update workflow control rules. 14. The system MAY provide the ability to customize workflow control rules and their components. 15. The system SHOULD provide the ability to inactivate, obsolete, or destroy workflow control rules. 16. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to workflow control rules. 17. The system MAY provide the ability to create access privilege rules to guide system behavior. 18. The system MAY provide the ability to update access privilege rules. 19. The system MAY provide the ability to customize access privilege rules and their components. 20. The system MAY provide the ability to inactivate, obsolete, or destroy access privilege rules. 21. The system MAY conform to function IN.2.2 (Auditable Records) to audit all changes to access privilege rules. 22. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to other business rules. 23. The system SHOULD support the ability to selectively export business rules Use Case Inventory Following is the HHS AHIC Use Case inventory: 2009 Requirements Documents o Consumer Preferences 2009 Use Case and Extensions/Gaps o Common Data Transport o General Laboratory Orders o Order Sets o Medication Gaps o Clinical Note Details o Common Device Connectivity o Newborn Screening Newborn Screening Companion Document o Medical Home: Problem Lists & Practice-Based Registries o Maternal and Child Health o Long Term Care - Assessments o Consumer Adverse Event Reporting o Scheduling o Prior-Authorization in Support of Treatment, Payment, & Operations o Preliminary Consumer Preferences Extension/Gap 2008 Use Cases o Remote Monitoring 5/16/2010 Page 49 of 139

51 o Patient - Provider Secure Messaging o Personalized Healthcare o Consultations and Transfers of Care o Public Health Case Reporting o Immunizations & Response Management 2007 Use Cases o Emergency Responder Electronic Health Record (PDF) o Consumer Empowerment: Consumer Access to Clinical Information o Medication Management o Quality 2006 Use Cases o Harmonized Consumer Empowerment (Registration & Medication History) Use Case (PDF) o Harmonized Electronic Health Record (Laboratory Result Reporting) Use Case (PDF) o Harmonized Biosurveillance (Visit, Utilization, and Lab Result Data) Use Case (PDF) Conformance Criteria 1. IMC satisfies all applicable national regulations and policies. 2. IMC satisfies the requirements of the EHR-S FM Direct Care function and its dependencies. 3. IMC satisfies the requirements of the HHS AHIC Immunization & Response Management (IRM) use Case. 4. IMC satisfies the requirements of the HHS AHIC Public Health Case Reporting (PHCR) Use Case Discussion SampleHealth is focused on meeting the National Objectives and policies. The EHR-S FM did not map one-to-one to SAIF-ECCF viewpoints. EHR-S FM Infrastructure non-functional requirements were mapped to the Conceptual Enterprise-Viewpoint given here; while, EHR-S FM Direct Care and Supportive Care functional requirements were mapped to the SAIF-ECCF Conceptual Computation-Viewpoint given below. 2.4 Conceptual Information-Viewpoint The ECCF Conceptual Information-Viewpoint is defined by the domain analysis information model. The Information-Viewpoint is concerned with the nature of the information handled by the system and constraints on the use and interpretation of that information. This Viewpoint answers the question what and refers to information content. This Viewpoint is primarily useful to clinicians and clinical analysts. This Viewpoint might typically contains some combination of: Inventory of Domain Entities, Roles, Activities and Associations. Information Model Conceptual Domain The HITSP/TN903 Data Architecture is our domain analysis model. 5/16/2010 Page 50 of 139

52 Figure 12 Conceptual Health Data Model A Conceptual Level Data Model 26 refines the subjects in the contextual data model, adding relationships to other entities that are required to fully understand each subject. The purpose of this level is to clarify the relationships among the major entities and to add enough qualifying detail to be able to distinguish each entity from all others. The data models of most organizations start at this level since the context of the organization is assumed. Figure 12 Conceptual Health Data Model provides a framework for the Information viewpoint, which we instantiate into an information model with the HITSP TN903/ Data Architecture. The Conceptual Health Data Model provides an overview of the essential foundations of data to be captured that can then be transformed into meaningful information to support the many different uses across the health system. Consistent data capture and systematic information transformation processes can result in more effective evidence being available to support health system management purposes. More importantly, value-added information can be supplied back to the clinician at the point of care, not only improving the clinician s ability to deliver quality health care but also providing an incentive to the clinician to capture the highest quality data as a by-product of providing first quality care. 26 Conceptual Health Data Model v2.3, Canadian Institute for Health Information 5/16/2010 Page 51 of 139

53 Domain Information Model For SampleHealth the Conceptual Business-Viewpoint is 1764 defined by the HL7 RIM based HITSP Data Architecture 1765 (e.g., HITSP/ TN903 Data Architecture, C Terminology, C83 Data Modules, C154 Data Dictionary), 1767 which are organized by the CDA Document Sections 27 and 1768 Entry Content Modules 28 and Data Elements A CDA document may contain the following Sections: 1770 Payers Section 1771 Allergies and Other Adverse Reactions Section 1772 Problem List Section 1773 History of Past Illness Section 1774 Chief Complaint Section 1775 Reason for Referral Section 1776 History of Present Illness Section 1777 List of Surgeries Section 1778 Functional Status Section 1779 Hospital Admission Diagnosis Section 1780 Discharge Diagnosis Section 1781 Medications Section 1782 Admission Medications History Section 1783 Hospital Discharge Medications Section 1784 Medications Administered Section 1785 Advance Directives Section 1786 Immunizations Section 1787 Physical Examination Section 1788 Vital Signs Section 1789 Review of Systems Section 1790 Hospital Course Section 1791 Diagnostic Results Section 1792 Assessment and Plan Section 1793 Plan of Care Section 1794 Family History Section 1795 Social History Section 1796 Encounters Section 1797 Medical Equipment Section 1798 Preoperative Diagnosis Section CDA Sections are collection of Entries pertaining to a single 1801 specified concept. For example, the Allergies and Other Adverse Reactions Section can contain a list of allergies (multiple Entry 1804 Content Modules) CDA Entry Content Modules are collections of Data Elements; each module pertaining to a single instance of the specified concept. For example, the Allergy/Drug Sensitivity Entry Module describes all the Data Elements for one allergy 29 CDA Data dictionary is defined in the HITSP/C154 Data Dictionary Component. Postoperative Diagnosis Section Surgery Description Section Surgical Operation Note Findings Section Anesthesia Section Estimated Blood Loss Section Specimens Removed Complications Section Planned Procedure Section Indications Section Disposition Section Operative Note Fluids Section Operative Note Surgical Procedure Section Surgical Drains Section Implants Section Assessments Section Procedures and Interventions Section Provider Orders Section Questionnaire Assessment Section The following Entry Content Modules are used: Personal Information Language Spoken Support Healthcare Provider Insurance Provider Allergy/Drug Sensitivity Condition Medication Pregnancy Information Source Comment Advance Directive Immunization Vital Sign Result Encounter Procedure Family History Social History Medical Equipment Functional Status Plan Of Care HITSP C83 identifies data elements per content module and HITSP C154 defines the data elements. HITSP documents are available at 5/16/2010 Page 52 of 139

54 Conformance Statements 1. The IMC is CDA compliant as specified by HITSP C80, C83 and C IMC messaging is compliant with HITSP C72 (Immunization Message) Discussion An Information Model is a means of classifying information topics of interest (e.g., clinical summary, encounter note, transfer of care summary, etc.). Information is a set of data that has been collated, interpreted and presented to be meaningful to a particular audience for a particular purpose. A Data Model defines the specific subjects and the facts about them (e.g., HITSP TN903). The same data can be used to produce many different pieces of information. A Data Model does not identify or define any topics that are essentially derived by any transformation process. The HITSP standards-based domain information model is essential to semantic interoperability and is specified in SampleHealth s Data Use and Reciprocal Support Agreement (DURSA). Currently, the HITSP selected standards are mandated for Federal Agencies and for HITECH meaningful use incentives to physicians and healthcare organizations in the HITECH Standards & Certification Criteria Interim Final Rule (IFR). Ultimately, the emerging Federal Health Information Model (FHIM) will apply to this viewpoint. 2.5 Conceptual Computation-Viewpoint The ECCF Conceptual Computation-Viewpoint is defined by collaboration analysis (e.g., BPM and UML sequence or activity diagrams), functional profiles, service roles and relationships. The Computation-Viewpoint is concerned with the functional decomposition of the system into a set of components that exhibit specific behaviors and interact at interfaces. This Viewpoint answers the question how and references behavioral specifications. This Viewpoint is primarily useful to business analysts and functional analysts. This Viewpoint might typically contains some combination of: Inventories of Capabilities-Components, Functions-Services Requirements Accountability Roles Behaviors Functional Profiles Interactions Interfaces Contracts Conceptual Functional Service Specifications (CFSS) The Conceptual Computation-Viewpoint is defined by the functional requirements defined in the HL7 EHR System Functional Model, AHIC Use Case Harmonization Request and by HITSP capabilities. The SampleHealth ECCF Conceptual Computation-Viewpoint contains: HSSP & NHIN Services HSSP & NHIN Service Interfaces 5/16/2010 Page 53 of 139

55 Working Draft; NOT for Public Distribution HSSP & NHIN Service Roles and Relationships (e.g., Responsibilities) Service Inventory HSSP provides the following services: CTS2 (Common Terminology Services 2) - CTS 2 is a standard for terminology services that enhances the capabilities of the initial CTS specification for sub-setting and mapping, and extends the specification into domains such as terminology distribution, versioning, and classification. DSS (Decision Support Service) - A commonly accepted standard for the DSS would make it more attractive for service consumers to invest in the infrastructure required for using the DSS to meet its patient evaluation needs, as they would be able to use the same interface to interact with multiple service vendors. HCPDS (Healthcare Provider and Services Directory Service) - HCPDS is required to provide an online facility that will enable Practitioners, via a set of parameters, to locate other practitioners, to assist in the continuum of care. IXS (Identity Cross-Reference Service, formerly known as Entity Identification Service) Normative - In balloting to become a full HL7 standard. PASS (Privacy, Access and Security Services) - The goal of PASS is to define a suite of services that will provide a simple interface for all privacy, access control, consent, identity management and other security services that are needed in a service-oriented health information architecture. RLUS (Retrieve, Locate and Update Service) and EIS (Entity Identification Service) - The HL7 SFM has been approved by the HL7 Board as an official DSTU. NHIN Connect version 2.4 provides the following services: Access Consent - This specification provides a standard language for expressing restrictions on access to health information. These restrictions are also known as Access Consent Policies. Access Consent Policies may be off-the-shelf policies that are adopted by or apply to a consumer, or they may be policies that are customized by a consumer to grant or deny access to specific types of information by specific types of users. Access Consent policies may also be created by users other than consumers; for example, physicians may create policies that restrict access to health information they create. Audit Log Query - The Query Audit Log service provides the mechanism by which audit data associated with accessing health information on the NHIN is exchanged so that consumers and privacy or security officers can account for who has had access to what information for what purpose. The service allows one NHIE to request an audit log, meeting certain search criteria, from another NHIE. The service can be viewed as receiving query requests from the NHIN to which it must respond, and sending queries to NHIEs on the NHIN in order to receive and potentially view audit log entries. Sequence diagrams are included for messages in each direction. The transactions implemented by the Query Audit Log service are described in the NHIN Trial Implementations Service Interface Specifications - Audit Log Query v1.3.1 [ONC ]. See that document for more information on the standards and specifications that describe this service. Enterprise Service Component - Policy Engine - The Policy Engine Enterprise Service Component comprises both open-source components and interactions implemented within CONNECT. This section describes the overall architecture of the Policy Engine, identifying those components that are open-source. The Policy Engine takes responsibility of determining whether a message should be processed by CONNECT, regardless of the direction the message is being moved - whether it is inbound from the NHIN or outbound to the NHIN - and thereby enables an organization to apply policies to all messages. Policies may be patient-specific (e.g., based on the patient's consent for a specific information exchange) or organization specific (e.g., based on hours of operation, user role, etc.). Authorization Framework - Authorization Framework defines the exchange of metadata used to characterize each NHIN request. The purpose of that exchange is to provide the responder with the information needed to make an authorization decision for the requested function. Each initiating message must convey information regarding end user attributes and authentication using SAML 2.0 assertions. The NHIN Authorization Framework specification defines a SAML assertion that can indicate a Policy ID that one NHIO may wish to retrieve from another NHIO. Authorized Case Follow-Up - Pseudonymization is the process of removing the association between a data set (e.g., protected health information or PHI) and the subject of that data (e.g., a patient) by removing identifying information, and adding an association between the data set and one or more alternative identifiers, or pseudonyms. Reidentification is the process of obtaining the association between a pseudonym and the original subject of that data set (e.g., re-associating PHI with the patient). Pseudonymization may be required for a number of reasons. For example, there may be a need to report health information to a public health agency for surveillance purposes in which case the identity of the individual is not needed. Likewise, reidentification may be required if an authorized individual, such as a public health official, must investigate a potential public health issue with proper legal authorization by gaining more information from the longitudinal health record of the individual known only by their pseudonym. Authorized Case Follow-up represents the services for 5/16/2010 Page 54 of 139

56 reidentification. It does not include the services, algorithms, or specifications for pseudonymization. The transaction used by the service interface is the HL7 v3 Patient Registry Get Identifiers Query, as profiled by the IHE Patient Identifier Cross-Reference HL7 v3 (PIX v3) Supplement Draft for Trial Implementations dated 15 August 2007 and Patient Demographic Query HL7 v3 (PDQ v3) Supplement Draft for Trial Implementations dated 15 August 2007 [IHE PIX and IHE PDQ]. See the NHIN Trial Implementations Service Interface Specifications - Authorized Case Follow Up v1.0 for more information on the standards and specifications that describe this service [ONC ]. CARE Profile - CMS has established the CARE data set to promote standards-based exchange of CARE data with the ultimate goal of improving the quality of care experienced by patients as they transition among providers. CMS has initiated a proof-of-concept project referred to as the CARE Health Information Exchange Project (C-HIEP) to explore the use of the CARE data and its exchange of over the NHIN. Consumer Preferences - The consumer preferences profile allows consumers to express their preferences for whether or not to share their information on the NHIN and for more granular control over access to their private information. The CONNECT policy engine enforces those preferences in the runtime environment to insure that the access policies of the organization and the preferences of the consumer are honored in the decision to release health information in response to a request from the NHIN. Document Submission - The Document Submission service provides a mechanism to send documents to another organization, unsolicited by a call to the Query for Documents service or other mechanism, and therefore implementing a "push" exchange pattern. The service can be viewed as submitting document(s) from the NHIN that must be processed or stored by the receiving system, and sending document(s) including health information to NHIEs on the NHIN. Sequence diagrams are included for messages in each direction. The transactions implemented by the Document Submission service are described in the IHE IT Infrastructure Technical Framework Supplement Cross-Enterprise Document Reliable Interchange (XDR) dated 10 August 2009 [IHE XDR]. See the NHIN Document Submission Web Services Interface Specification draft, not yet released at the time of this writing, for more information on the standards and specifications that describe this service [ONC ]. GIPSE Profile - GIPSE stands for Geocoded Interoperable Population Summary Exchange. It was created by the CDC to allow the electronic exchange of health condition summary data. GIPSE data will be used by public health agencies for early event detection and monitoring for potential public health events. Health Info. Event Messaging - The Health Information Event Messaging, or HIEM, refers to the NHIN specification for NHINenabled systems to initiate subscriptions for information with other NHIN participants, and subsequently to deliver notifications of when data matching subscription criteria is available. HIEM is an extension to the OASIS Web Services Base Notification 1.3 (WS- BaseNotification) [OASIS ] utilizing Web Services Topics 1.3 (WS-Topics) [OASIS ]. See NHIN Health Information Event Messaging Web Service Interface Specification v2.0 dated 29 January 2010 for more information on the standards and specifications that describe this service [ONC ]. Messaging Platform - Messaging Platform specifies a base set of messaging standards and web service protocols which must be implemented by each NHIN node and applies to all transactions. All NHIN inter-nodal messages are SOAP messages over HTTP using web services, must be encrypted and digitally signed. Patient Discovery - In order to share patient data within and among NHIEs, and at times between NHIEs and other connected organizations, it is necessary to have mechanisms to match patient identities in the absence of a single national identifier. The Patient Discovery service meets this need by providing the mechanism for locating patients at other NHIN-enabled organizations based on demographic information. The service provides the ability for one NHIE to determine whether other NHIEs have records for a given patient by submitting a set of demographic identifiers that NHIEs can use to match against their own master patient indices. The transactions implemented by the Patient Discovery service is described in the IHE IT Infrastructure Technical Framework - Cross- Community Patient Discovery (XCPD) Supplemental Draft for Trial Implementations dated 10 August 2010 [IHE XCPD]. See the NHIN Patient Discovery Web Service Interface Specification v1.0 dated 29 January 2010 for more information on the standards and specifications that describe this service [ONC ]. Query for Documents - The Query for Documents service provides the mechanism by which one NHIE locates electronic health information on the NHIN associated with a specific patient. The service allows one NHIE to acquire a list of documents for a given patient that may exist at another NHIE, based on a set of search criteria. The service can be viewed as receiving query requests from the NHIN to which it must respond, and sending queries to NHIEs on the NHIN in order to locate a patient's health information. Sequence diagrams are included for messages in each direction. The transactions implemented by the Query for Documents service are described in the IHE IT Infrastructure Technical Framework - Cross Gateway Query (XCA) Supplement Draft for Trial Implementations dated 15 August 2007 [IHE XCA]. The use of this profile is included in HITSP TP13 Manage Sharing of Documents Transaction Package [HITSP TP13]. See the NHIN Query for Documents Web Service Interface Specification v2.0 dated 29 January 2010 for more information on the standards and specifications that describe this service [ONC ]. The XCA specification has been relaxed within the NHIN to support the query for, and retrieval of, dynamically generated document content. Retrieve Documents - The Retrieve Documents service provides a mechanism to retrieve the electronic health information on the NHIN. It is used in conjunction with the Query for Documents service, which returns a list of document references that Retrieve Documents uses to retrieve patient records. The service can be viewed as receiving document requests from the NHIN to which it must 5/16/2010 Page 55 of 139

57 Working Draft; NOT for Public Distribution respond, and sending requests to NHIEs on the NHIN in order to retrieve patient health information. Sequence diagrams are included for messages in each direction. The transactions implemented by the Retrieve Documents service are described in the IHE IT Infrastructure Technical Framework - Cross Community Access (XCA) Supplement Draft for Trial Implementations dated 15 August 2007 [IHE XCA]. The use of this profile is included in HITSP TP13 Manage Sharing of Documents Transaction Package [HITSP TP13]. See the NHIN Retrieve Documents Web Service Interface Specification v2.0 dated 29 January 2010 for more information on the standards and specifications that describe this service [ONC ]. Service Registry - The NHIN Services Registry allows NHIN member organizations to locate and utilize the appropriate services offered by other members in a controlled, secure manner. The registry enables privacy and trust by only allowing vetted participant organizations into the registry. The registry facilitates interoperability, by cataloging and advertising in real-time which services are supported by each organization. Subject Discovery - The Subject Discovery service interface is used between NHIEs for the purpose of querying for a subject, and upon a positive match returns a unique identifier that may be used to query for records on that subject. The subject referred to in this specification is a healthcare consumer, patient or may be a provider. Subject as used in this specification does not include system user Functional Requirements The EHR-SD RM provides Figure 11 EHR-S FM Direct Care Manage Immunization Administration Dependencies, which shows how Immunization Management depends on other EHR System functional requirements (e.g., DC.1.3.2, DC.1.4.4, S.1.1, S.2.2.2, S.3.7.1) and results in the following functional conformance criteria: DC Manage Immunization Administration 1. The system SHALL provide the ability to recommend required immunizations, and when they are due, during an encounter based on widely accepted immunization schedules. 2. The system SHOULD provide the ability to recommend required immunizations based on patient risk factors. 3. The system SHALL perform checking for potential adverse or allergic reactions for all immunizations when they are about to be given. 4. The system SHALL provide the ability to capture immunization administration details, including date, type, lot number and manufacturer. 5. The system SHOULD provide the ability to capture other clinical data pertinent to the immunization administration (e.g. vital signs). 6. The system SHALL record as discrete data elements data associated with any immunization. 7. The system SHOULD provide the ability to associate standard codes with discrete data elements associated with an immunization. 8. The system SHALL provide the ability to update the immunization schedule. 9. The system SHOULD provide the ability to prepare a report of a patient's immunization history upon request for appropriate authorities such as schools or day-care centers. 10. The system SHALL conform to function DC (Manage Allergy, Intolerance and Adverse Reaction Lists). 11. The system SHOULD transmit required immunization information to a public health immunization registry. 12. The system SHOULD receive immunization histories from a public health immunization registry. DC depends on DC Manage Patient Advance Directives 1. The system SHALL provide the ability to indicate that advance directives exist for the patient. 2. The system SHALL provide the ability to indicate the type of advance directives completed for the patient such as living will, durable power of attorney, preferred interventions for known conditions, or the existence of a "Do Not Resuscitate order. 3. The system SHOULD provide the ability to capture, present, maintain and make available for clinical decisions patient advance directives documents and Do Not Resuscitate orders. 4. The system SHOULD conform to function DC (Capture Data and Documentation from External Clinical Sources) and capture scanned patient advance directive documents and Do Not Resuscitate orders. 5. The system SHOULD provide the ability to indicate when advanced directives were last reviewed. 6. The system SHOULD provide the ability to indicate the name and relationship of the party completing the advance directive for the patient. 7. The system SHALL time and date stamp advance directives. 8. The system SHOULD provide the ability to document the location and or source of any legal documentation regarding advance directives. 9. The system SHOULD conform to function DC (Support for Patient and Family Preferences). DC depends on DC Manage Immunization List 1. The system SHALL capture, display and report all immunizations associated with a patient 5/16/2010 Page 56 of 139

58 The system SHALL record as discrete data elements data associated with any immunization given including date, type, lot number and manufacturer 3. The system SHOULD prepare a report of a patient s immunization history upon request for appropriate authorities such as schools or day-care centers DC depends on S 1.1 Registry Notification 1. The system SHOULD automatically transfer formatted demographic and clinical information to local disease specific registries (and other notifiable registries). 2. The system MAY provide the ability to automate the retrieval of formatted demographic and clinical information from local disease specific registries (and other notifiable registries). 3. The system SHOULD provide the ability to add, change, or remove access to registries. DC depends on S Standard Report Generation 1. The system SHOULD provide the ability to generate reports of structured clinical and administrative data using either internal or external reporting tools. 2. The system MAY provide the ability to include information extracted from unstructured clinical and administrative data in the report generation process, using internal or external tools. 3. The system SHOULD provide the ability to export reports generated. 4. The system SHOULD provide the ability to specify report parameters, based on patient demographic and/or clinical data, which would allow sorting and/or filtering of the data. 5. The system (or an external application, using data from the system) MAY provide the ability to save report parameters for generating subsequent reports. 6. The system (or an external application, using data from the system) MAY provide the ability to modify one or more parameters of a saved report specification when generating a report using that specification. DC depends on S Clinical Decision Support System Guidelines Updates 1. The system SHALL provide the ability to update the clinical content or rules utilized to generate clinical decision support reminders and alerts. 2. The system SHOULD validate that the most applicable version is utilized for the update, and capture the date of update. 3. The system MAY track and retain the version used when guidelines are provided in a patient encounter Conceptual Functional Service Specification (CFSS) This information is available at the HSSP and NHIN CONNECT websites. The IMC capability CFSS will be described here. TBD Service Roles and Relationships This information is available at the HSSP and NHIN CONNECT websites. The IMC capability CFSS will be described here. TBD Conformance Statements 1. IMC meets the EHR-S FM Direct Care Immunization Management and derived requirements. 2. IMC makes appropriate use of HSSP and NHIN services Discussion The SampleHealth IMC project Conceptual Computation-Viewpoint is defined by the functional requirements and Information Exchange Requirements (IERs) defined in the HL7 EHR System Functional Model, AHIC Use Case Harmonization Request and by HITSP capabilities. 5/16/2010 Page 57 of 139

59 ISSUE: In the ECCF, it is not intuitively obvious where Use cases, Information Exchange Requirements (IERs), Business Process Models and System Data Exchanges models (i.e., sequence diagrams of transactions implementing an IHE profile) respectively belong. 2.6 Conceptual Engineering-View The ECCF Conceptual Engineering-Viewpoint is defined by existing platform capabilities. The Engineering- Viewpoint is concerned with the mechanisms and functions required to support the interactions of the computational components. This ECCF Viewpoint may overlap with the RM-ODP technology viewpoint, which is concerned with the explicit choice of technologies for the implementation of the system, and particularly for the communications among the components. This Viewpoint is primarily useful to enterprise architects. This Viewpoint answers the question where and refers to implementation environments. This Viewpoint might typically contains some combination of: Inventory of Software Platforms/ Environments and their Capabilities Inventory of Software Platforms and Their Capabilities For SampleHealth the Conceptual Engineering-Viewpoint is defined by NHIN Connect to be: Apache Tomcat (or Jakarta Tomcat or simply Tomcat) is an open source servlet container developed by the Apache Software Foundation (ASF). Tomcat implements the Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems, and provides a "pure Java" HTTP web server environment for Java code to run. JBoss Application Server (or JBoss AS) is a free software/open-source Java EE-based application server. Because it is Java-based, the JBoss application server operates cross-platform: usable on any operating system that supports Java. JBoss AS was developed by Jboss, now a division of Red Hat. J2SE, Java Platform, Standard Edition or Java SE is a widely used platform for programming in the Java language. It is the Java Platform used to deploy portable applications for general use. In practical terms, Java SE consists of a virtual machine, which must be used to run Java programs, together with a set of libraries (or "packages") needed to allow the use of file systems, networks, graphical interfaces, and so on, from within those programs. Eclipse Open Healthcare Framework (OHF) is a project within Eclipse formed for the purpose of expediting healthcare informatics technology. The project is composed of extensible frameworks and tools which emphasize the use of existing and emerging standards in order to encourage interoperable open source infrastructure, thereby lowering integration barriers. GlassFish ESB v2 integrates the OpenESB project into the GlassFish Java 5 EE Application Server, where "Project OpenESB implements an Enterprise Service Bus (ESB) runtime using Java Business Integration (JBI) as the foundation, enabling the easy integration of web services to create loosely coupled, enterprise-class composite applications." GlassFish is an open source application server project led by Sun Microsystems for the Java EE platform. GlassFish is free software, dual-licensed under two free software licenses: the Common Development and Distribution License (CDDL) and the GNU General Public License (GPL) with the classpath exception. GlassFish is based on source code released by Sun and Oracle Corporation's TopLink persistence system. It uses a derivative of Apache Tomcat as the servlet container for serving Web content, with an added component called Grizzly which uses Java NIO for scalability and speed. 5/16/2010 Page 58 of 139

60 OpenSSO is an open source access management and federation server platform. OpenSSO is based on Sun Java System Access Manager, and is the core of Sun's commercial access management and federation product, OpenSSO Enterprise (formerly Sun Access Manager and Sun Federation Manager). Oracle completed their acquisition of Sun Microsystems in February 2010 and announced that OpenSSO would no longer be their strategic product. OpenSSO will continue to be developed and supported by ForgeRock under the name of *OpenAM Conformance Statements 1. IMC uses the appropriate NHIN CONNECT version 2.4 platforms Discussion Because the EHR-SD RM is sponsored by the HL7 Government Projects workgroup and the Universal Immunization Tracking System (UITS) prototype is funded by the Military Health System, the SampleHealth ECCF Conceptual Engineering-Viewpoint identifies the Federal Health Architecture s Federal Partners sponsored NHIN Connect suite of environments (e.g., platforms). 2.7 Platform-Independent Enterprise-Business-Viewpoint The ECCF Platform-Independent Enterprise-Business-Viewpoint defines the business and reference context. The Enterprise-Business-Viewpoint is concerned with the business governance of the system as it relates to the business objectives and the business processes of the organization. This Viewpoint answers the question why and refers to policy. This Viewpoint is primarily useful to project managers and business process experts. This Viewpoint might typically contains some combination of: Applicable Rules Use Case Specs Governance. Technology Neutral Standards Wireframes of architectural layers components and Associations NHIN Standards Figure 13 illustrates the categories of standards, which apply to EHR interoperability, compliant with the Meaningful Use Stage 1 certification criteria in the Interim Final Rule (IFR) issued by the Office of the National Coordinator (ONC), US Department of Health and Human Services (HHS) in January /16/2010 Page 59 of 139

61 Figure 13 NHIN Standards Framework Business Governance The Platform-Independent Enterprise-Business-Viewpoint is defined by the governance enforced throughout the Architecture Development Method (ADM). The governance 30 includes the following: Change Control Board (CCB) manages Enterprise Requirements and Investment Portfolio. Architecture Review Board (ARB) manages architecture, reusable components and services. Configuration Management Board (CMB) manages the following baselines. o System Requirements Review (SRR) o Preliminary Design Review (PDR) o Critical Design Review (CDR) o Test Readiness Review (TRR) o System Integration Test (SIT) o System Qualification Test (SQT) o Operational Test and Evaluation (OT&E) Conformance Statements 1. IMC requirements were approved by the CCB. 2. IMC architectural views were approved by the ARB. 3. IMC SRR baseline was approved by the CMB. 4. IMC PDR baseline was approved by the CMB. 5. IMC CDR baseline was approved by the CMB. 6. IMC TRR baseline was approved by the CMB. 7. IMC SIT baseline was approved by the CMB. 8. IMC SQT baseline was approved by the CMB. 9. IMC OT&E baseline was approved by the CMB. 30 Based on DOD Instruction (DODI) /16/2010 Page 60 of 139

62 Discussion The "Requirements Management and Governance" circle at the center of the Figure 43 ADM graphic indicates that Requirements Management and Governance should be a part of every stage of a project. It is important to note that the Requirements Management and Governance circle denotes, not a static set of requirements, but a dynamic process whereby requirements for enterprise architecture and subsequent changes to those requirements are identified, validated, stored, and fed into and out of the relevant ADM phases but, the requirements management process must also dispose of, address, validate or prioritize evolving and refined requirements during the relevant phases of the ADM. The ability to govern changes in requirements is crucial. Architecture is an activity that by its very nature deals with uncertainty and change - the "grey area" between what stakeholders aspire-to and what can be specified and engineered as a pragmatic solution. Moreover, architecture often deals with drivers and constraints, which can produce changes in requirements in an unforeseen manner. Many of the factors influencing architecture by their very nature are beyond the control of the enterprise (changing market conditions, new legislation, etc.). Governance is critical to a project s success. SOA governance includes the management of the reusable library of component, their service specifications and service contracts (DURSAs). Because the EHR-SD RM is sponsored by the HL7 Government Projects workgroup and the Universal Immunization Tracking System (UITS) prototype is funded by the Military Health System, the SampleHealth is following the governance described in DOD Instruction Operation of the Defense Acquisition System. 2.8 Platform-Independent Information-Viewpoint The ECCF Platform-Independent Information-Viewpoint is defined by the project information model. The Information- Viewpoint is concerned with the nature of the information handled by the system and constraints on the use and interpretation of that information. This view answers the question what and refers to information content. This Viewpoint is primarily useful to clinical informaticists. This Viewpoint answers the question where and refers to implementation environments. This Viewpoint might typically contains some combination of: Information Models Localized Information Model Constrained Information Model Project Information Model Message Content Specifications A Logical Level Data Model 32 is the most detailed level. The full complexity of data entities and all their relationships are expressed. It is this level of detail that is necessary to specify information systems. All entities should be fully described with all their characteristics. The permissible values of all attributes (characteristics) should also be defined and all relationships expressed. The SampleHealth Project Information Model for the Platform-Independent Information-Viewpoint is defined by the HITSP Components 33. HITSP/C72 Immunization Message, HITSP/C83 CDA Content Modules HITSP/C80 Terminology 31 Available at 32 Conceptual Health Data Model v2.3, Canadian Institute for Health Information 33 Available from 5/16/2010 Page 61 of 139

63 2190 HITSP/C154 Data Dictionary Working Draft; NOT for Public Distribution Project Information Model IMC Data Requirements and Data Elements are based on the HL7 Reference Information Model we generate Figure 25 Immunization Management Entities, Actions and Roles. HITSP IS 010, which contains Table 7 Data Element and Information Requirements (DR) Data Requirements (DRs) IRM Data Requirements (DRs): 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 PHCR Data Requirements (DRs): DR08 Unstructured Data DR17 Decision Support Data DR21 Terminology Data DR24 Case Report Pre-populate Data DR22 Generic Alert Data DR23 Consumer Vaccination View DR24 Case Report Pre-populate Data DR25 Case Report Content DR26 Reporting Criteria Content DR59 Generic Alert Data 5/16/2010 Page 62 of 139

64 2226 Data Requirement Number (DR) DR8 DR11 Table 7 Data Element and Information Requirements (DR) Description Unstructured Data: Document that contains simple text such as a note to the patient, about a patient, or a note from the patient (e.g., camp form immunization summary, patient-specific immunization alert, patient listing alert to providers of patients needing vaccination). This document could include an unstructured, presentation preserved format, such as PDF. Metadata may include but is not limited to: Title Clinic ID Date Immunization response data: Immunization details returned in response to immunization inquiry including (but not limited to): Patient Name: First, Middle, Last Patient Alias Name: First, Middle, Last Patient Address Patient Phone Number Patient Identifier Patient Birth Date Patient Sex Patient Race Patient Ethnicity Patient Primary Language Patient Multiple Birth Indicator Patient Multiple Birth Order Patient Birth Registration Number Patient Birth State/Country Patient Birthing Facility Mother s Name: First, Middle, Last Mother s Maiden Name Mother s SSN Father s Name: First, Middle, Last Father s SSN Insurance Plan Insurance Company Immunization Services Funding Eligibility Next of Kin Relationship Next of Kin Address Next of Kin Telephone Next of Kin DOB Last Update Time/Date Last Update Facility Immunization Event Identifier Vaccine Expiration Date Vaccine Injection Site Vaccination Date Vaccine Lot Number Vaccine Administration Provider Vaccine Administration Facility Vaccine Type Vaccine Manufacturer Vaccine Dose Number Reason for Non-Vaccination Patient Status in the Immunization Home Transaction Information Source Immunisation Information Source 5/16/2010 Page 63 of 139

65 Data Requirement Number (DR) DR12 DR13 DR14 DR15 DR16 Description Amount Administered (dosage amount): Smallpox Take Response Observation Read Date for Take Response Treatment Route Refusal Reason Action Code Vaccine Dose Valid Flag Immunization Recommendations Vaccine Information Sheet (VIS) date Vaccine Information Sheet (VIS) version Vaccine Recall Effective Date Vaccine Lot # Recall Code Adverse Event Report: A report of a Vaccine Adverse Event. See requirements for HITSP/IS11 - Public Health Case Reporting for Adverse Event Report (FDA MedWatch, Vaccine Adverse Events Reporting System (VAERS)) Drug/Vaccine Inventory Data: detail-level content supporting the inventory management functions of vaccine supply. NOTE: Scenario 2 deferred. Data requirements include (but are not limited to): quantity of vaccine location clinician geographic identifiers non-geographic identifiers manufacturer lot number expiration date Drug/Vaccine Inventory Usage Data: Aggregate content supporting the inventory usage functions of vaccine supply. NOTE: Scenario 2 deferred. Data requirements include (but are not limited to): quantity of vaccine utilized in a specific period of time location clinician geographic identifiers non-geographic identifiers manufacturer lot number expiration date Drug/Vaccine Inventory Availability Data: Aggregated content supporting the inventory availability functions of vaccine supply. NOTE: Scenario 2 deferred. Data requirements include (but are not limited to): quantity of vaccine available in a specific period of time location clinician geographic identifiers non-geographic identifiers manufacturer lot number expiration date Supply Chain Management Vaccine Recall: Content that supports the vaccine recall functions of the vaccine supply chain. 5/16/2010 Page 64 of 139

66 Data Requirement Number (DR) DR17 DR18 Description NOTE: Scenario 2 deferred. Data requirements include (but are not limited to): Title (what is being recalled) Date of recall Lot # Expiration date Manufacturers Reason- text Action text (interventions required for the recall) NOTE: Deferred to be further specified as part of Supply Chain Management in Scenario 2. NOTE: This information could come from adverse event monitoring (a research function) or a Clinical Decision Support actor such as Surveillance Decision Support Data: Employed to evaluate a given clinical situation to suggest a course of action, or to set up criteria to trigger one or more actions when a clinical event meets those criteria. NOTE: Component Specification deferred due to standards gaps (see scope and gaps) Data requirements include (but are not limited to): In general, the data may include, but is not limited to: Medication reconciliation Clinical protocols Administrative protocols (e.g: Insurance) Diagnosis Laboratory results For this Interoperability Specification, data may also include, but is not limited to: Decision support data input Age range Sex Race Risk Location of the exposure Date/time of exposure Type of exposure Occupation (e.g., first responders) Clinical history Patient Birth Date Decision support feedback (pending further analysis Logic Contraindications Policy Trigger Criteria Other pending further analysis Vaccination Data: The immunization data content to be exchanged between healthcare entities such as immunization information systems; electronic medical records systems, personal healthcare record systems and other stakeholders. Data requirements include (but are not limited to): Patient Name: First, Middle, Last Patient Alias Name: First, Middle, Last Patient Address Patient Phone Number Patient Identifier Patient Birth Date Patient Sex Patient Race Patient Ethnicity Patient Primary Language 5/16/2010 Page 65 of 139

67 Data Requirement Number (DR) DR19 Description Patient Multiple Birth Indicator Patient Multiple Birth Order Patient Birth Registration Number Patient Birth State/Country Patient Birthing Facility Mother s Name: First, Middle, Last Mother s Maiden Name Mother s SSN Father s Name: First, Middle, Last Father s SSN Insurance Plan Insurance Company Immunization Services Funding Eligibility Next of Kin Relationship Next of Kin Address Next of Kin Telephone Next of Kin DOB Last Update Time/Date Last Update Facility Immunization Event Identifier Vaccine Expiration Date Vaccine Injection Site Vaccination Date Vaccine Lot Number Vaccine Administration Provider Vaccine Administration Facility Vaccine Type Vaccine Manufacturer Vaccine Dose Number Reason for Non-Vaccination Patient Status in the Immunization Home Transaction Information Source Immunisation Information Source Amount Administered (dosage amount) Smallpox Take Response Observation Read Date for Take Response Treatment Route Refusal Reason Action Code Vaccine Dose Valid Flag Immunization Recommendations Vaccine Information Sheet (VIS) date Vaccine Information Sheet (VIS) version Vaccine Recall Effective Date Vaccine Lot # Recall Code Medication Administration data: The Medication Administration data content to be exchanged between healthcare entities such as immunization information systems and electronic medical records systems, in support of Countermeasure and Response Administration. NOTE: Imposing a data requirement on immunization registries that they do not have at this time is deferred. vaccinations received by an individual dates administered administering clinician manufacturer and lot number source of this information (clinically verifiable source, self-reported by a consumer, or provided from another 5/16/2010 Page 66 of 139

68 Data Requirement Number (DR) DR20 DR21 DR22 DR23 Description non-clinically verifiable source) reason for drug administration- information does not go to registry unless given for prophylactic reason campaign for prophylactic drug use/context population that the campaign is directed toward campaign ID campaign name campaign start/end date campaign potential counter-measures See content for CDC file format for submitting data into CDC summary level/aggregate data format (XML) NOTE: not at administration level Aggregate Inventory of Available Vaccine: The Aggregate Inventory of Available Vaccine data content to be exchanged between healthcare entities inventory systems such as Immunization Information Systems and Electronic Medical Records Systems, in support of Vaccine Supply monitoring and management. NOTE: Scenario 2 deferred pending further analysis on Scenario 2 for supply chain include but are not limited to: quantity of vaccine available doses committed doses remaining location clinician geographic identifiers non-geographic identifiers manufacturer lot number expiration date Terminology Data: Used to transform human or computer vocabularies. Data attributes may be specified based upon implementation Generic Alert Data Immunizations: A non-patient identifiable alert (message or presentation preserving document) sent to an identified set of recipients. This may be used to communicate immunization schedules, prioritization notices, and alerts. NOTE: See Clinical Decision Support Prioritization for trigger criteria Data requirements include (but are not limited to): Target population Alert delivery timeframe A descriptive directive Alert title/subject Date/time of alert Alert type Severity Source/Author Alert identifier Alert status Acknowledge requirements Consumer Vaccination View: This is a consumer friendly view of a person s immunization history/record. Patient Name: First, Middle, Last Patient Alias Name: First, Middle, Last Patient Address Patient Phone Number Patient Identifier Patient Birth Date Patient Sex Patient Race 5/16/2010 Page 67 of 139

69 Data Requirement Number (DR) DR58 Description Patient Ethnicity Patient Primary Language Patient Multiple Birth Indicator Patient Multiple Birth Order Patient Birth Registration Number Patient Birth State/Country Patient Birthing Facility Mother s Name: First, Middle, Last Mother s Maiden Name Mother s SSN Father s Name: First, Middle, Last Father s SSN Insurance Plan Insurance Company Immunization Services Funding Eligibility Next of Kin Relationship Next of Kin Address Next of Kin Telephone Next of Kin DOB Last Update Time/Date Last Update Facility Immunization Event Identifier Vaccine Expiration Date Vaccine Injection Site Vaccination Date Vaccine Lot Number Vaccine Administration Provider Vaccine Administration Facility Vaccine Type Vaccine Manufacturer Vaccine Dose Number Reason for Non-Vaccination Patient Status in the Immunization Home Transaction Information Source Immunisation Information Source Amount Administered (dosage amount): Smallpox Take Response Observation Read Date for Take Response Treatment Route Refusal Reason Action Code Vaccine Dose Valid Flag Immunization Recommendations Vaccine Information Sheet (VIS) date Vaccine Information Sheet (VIS) version Vaccine Recall Effective Date Vaccine Lot # Recall Code Demographic Data Vaccination: The demographic data content to be exchanged to appropriately associate the patient vaccination or vaccination inquiry data with vaccination data maintained in another system. Data requirements include (but are not limited to): Patient Name: First, Middle, Last Patient Alias Name: First, Middle, Last Patient Address 5/16/2010 Page 68 of 139

70 Data Requirement Number (DR) DR76 Description Patient Phone Number Patient Identifier Patient Birth Date Patient Sex Patient Race Patient Ethnicity Patient Primary Language Patient Multiple Birth Indicator Patient Multiple Birth Order Patient Birth Registration Number Patient Birth State/Country Patient Birthing Facility Mother s Name: First, Middle, Last Mother s Maiden Name Mother s SSN Father s Name: First, Middle, Last Father s SSN Insurance Plan Insurance Company Immunization Services Funding Eligibility Next of Kin Relationship Next of Kin Address Next of Kin Telephone Next of Kin DOB Last Update Time/Date Last Update Facility Immunization query data: data attributes sent for request of immunization data including (but not limited to): Patient Name: First, Middle, Last Patient Alias Name: First, Middle, Last Patient Address Patient Phone Number Patient Identifier Patient Birth Date Patient Sex Patient Race Patient Ethnicity Patient Primary Language Patient Multiple Birth Indicator Patient Multiple Birth Order Patient Birth Registration Number Patient Birth State/Country Patient Birthing Facility Mother s Name: First, Middle, Last Mother s Maiden Name Mother s SSN Father s Name: First, Middle, Last Father s SSN Insurance Plan Insurance Company Immunization Services Funding Eligibility Next of Kin Relationship Next of Kin Address Next of Kin Telephone 5/16/2010 Page 69 of 139

71 Data Requirement Number (DR) Description Next of Kin DOB Last Update Time/Date Last Update Facility DR77 Drug/Vaccine query data: Content for an inquiry of available vaccine (subject to further analysis of scenario 2). Data requirements include (but are not limited to): vaccine name location clinician geographic identifiers non-geographic identifiers manufacturer lot number expiration date DR78 Drug/vaccine response data: Content for an inquiry response for available vaccine (subject to further analysis of scenario 2). Data requirements include (but are not limited to): quantity of vaccine location clinician geographic identifiers non-geographic identifiers manufacturer lot number expiration date DR79 Drug/Vaccine Inventory Requirements: Content for communication of inventory needs/requirements. NOTE: Scenario 2 deferred. Data requirements include (but are not limited to): Vaccine requirement/delivery instructions Shipping/handling information data requirements Temperature Storage conditions Breakage Humidity Air quality See Countermeasure and Response Administration Campaign for additional detail Standards Gaps This section describes gaps in standards. Gaps occur in the following two cases, where HITSP has: Identified requirements derived from the context that have no standards that meet all tiers of HITSP criteria to merit selection for that context Identified a single standard that encompasses and singly fulfills a set of tightly-coupled standards from the given context, yet is lacking in fulfilling one or more of the tightly-coupled requirements The gap is only relative to the specific Use Case requirement. Recommended resolutions were developed through a series of steps including the HITSP Technical Committee s initial recommendations, cross Technical Committee validation of the gap, provisional recommendations and peer review by the Technical Committee. The table below identifies the Use Case requirements and known associated gaps, along with the recommended resolutions. 5/16/2010 Page 70 of 139

72 2239 Requirement Number DR17 DR17 DR17 Working Draft; NOT for Public Distribution Table 8 Use Case Requirements and Associated Standards Gaps Summary Description Identified Gaps Recommended Resolution Decision Support Data (immunization schedule) Decision Support Data (Immunization reminders) Decision Support Data (Prioritization) Action: Incorporate immunization schedules into the clinician s EHR: for incorporation in a computable fashion gap for content this is an active issue around the country Action: Receive immunization schedules : - Currently no standards for automated updates gap - No content standards other than paper formats in use - Most EHR systems today do not have a thorough immunization schedule a : Action: Identify individuals needing immunization or drug: - No approved standard for identifying individuals needing immunization or drug Web Services approach for Entity identification services b Alternative Action: Receive information about individuals needing prioritized intervention: Typically adults that may not be in immunization registries they may be in an emergency preparedness registry, chronic disease registry, or from the EHR There is HL7 Clinical Decision Support work in this area for immunization schedules The Advisory Committee on Immunization Practice (ACIP) is providing the content in a standard as a standard table distributed in a text format every year based upon CDC recommendations. As currently done, proprietary implementations of these specifications may be leveraged for system automation. Once the Clinical Decision Support specifications are defined, specify a method to express the schedules In progress through HL7 SOA, HSSP and Clinical Decision Support "; this is not the PH this is not the PH emergency response effort this is the SOA; dependent upon the gap resolution above for immunization schedules; NOTE: Further details are pending HITSP Clinical Decision Support specifications 34. Proprietary solutions may be leveraged in the interim Look at what is in the text versions to identify the data element requirements Monitor and contribute to HL7 Clinical Decision Support work on standardized service/algorithm Monitor and contribute to work under way with ISO TS21091, which is adding SOA in collaboration with HSSP work in updating the TS to IS Monitor and contribute to HL7 Clinical Decision Support work on standardized service/algorithm 34 The HSSP Decision Support Service (DSS) was ratified in December 2009 and is available at 5/16/2010 Page 71 of 139

73 Requirement Number DR19 DR17 DR17 Summary Description Identified Gaps Recommended Resolution Medication Administration data Decision Support Data (Alert - Recall) Decision Support Data (Prioritization) b, Alternative Action: Receive information about individuals needing prioritized intervention, Action: Conduct analysis to determine intervention priorities, Action: Notify clinicians of individuals or population characteristics needing prioritized intervention Action: Identify individuals needing prioritized intervention: There are no standards for prioritization Gap/policy element Action: Record vaccine or drug administration information: Gap in standards to fulfill Counter-measure Response Administration (CRA) requirements implied by the Use Case which may be population based Action: Receive vaccine recall information from registries : Standards gap today this is done by human communications Action: Identify individuals needing prioritized intervention : no standard for the consumer-friendly decision This is a Clinical Decision Support effort we may approach this in deferred HITSP Clinical Decision Support effort scoped to demographics for initial deliverable; This may be expanded once requirements are fleshed out The requirements beyond demographics need to be defined to fit within HITSP Clinical Decision Support Refer to the appropriate SDO to define standards. Monitor and contribute to effort Continue human communication until an appropriate message can be developed Leverage Unstructured Document Component approach defined by HITSP construct where appropriate Refer to and appropriate SDO to define standards. Monitor and contribute to effort May be influenced by policy decisions Refer to and appropriate SDO to define standards. Monitor and contribute to effort DR19 Medication Administration data Action: Report administration information to registries Standards gap to transmit in a computable way Standards gap Refer to and appropriate SDO to define standards. Monitor and contribute to effort DR18 DR19 Vaccination Data Medication Administration Action: Provide vaccine or drug administration information Policy Gap: School health records may not be able to be made available to registry Refer to appropriate policy group; Implications with various federal law; HISPC referral DR23 Consumer Vaccination View Policy gap in standard requirements for consumer-facing communications of immunization data DR18 DR19 Vaccination Data Medication Administration : Action: Provide vaccine or drug administration information. 9.4: Data provisioning including support for secondary uses; data provisioning and distribution of data transmission parameters Gap in Data Quality routine checking/automation Gap is in Clinical Decision Support transmission of rules for record checking Need standards for the transmission of the immunization rules the data quality rules. Refer to SDOs for consideration as to whether this can be combined as a common standard 5/16/2010 Page 72 of 139

74 Requirement Number DR11 DR76 DR18 DR19 DR16 Summary Description Identified Gaps Recommended Resolution Immunization response data Immunization query data Vaccination Data Medication Administration Supply Chain Management Vaccine RecallVaccine Recall (including consumer directed message) a Action: Identify individuals needing immunization or drug b Alternative Action: Receive information about individuals needing prioritized intervention Action: Provide vaccine or drug administration information Action: Retrieve vaccine or drug administration information from external sources Action: Receive information describing the administration of a vaccine or drug Action: Request available immunization information Action: Conduct analysis to determine intervention priorities Action: Notify clinicians of individuals or population characteristics needing prioritized intervention Action: Receive and monitor inventory status information Action: Monitor inventory usagevxq/vxr There is a deprecation of these and an update in progress from CDC to the implementation guide Action: Retrieve vaccine or drug administration information from external sources NCPDP does not conform to the Vaccination data details Action: Receive vaccine recall information from registries Action: Receive vaccine recall information from registries GAP: Possible if the vaccine recall information does not contain enough info to update the supply chain We intend to leverage this new work and will provisionally select these updated approaches in the HITSP IRM IS Align Query/Response construct with the emerging implementation guide and updated HL7 messages and provisionally select these newer standards. It is possible that the IS will be published prior to the completion of the underlying update in which case we will generate an update once the work is complete and updated in the associated HITSP constructs Either pharmacies conform to HL7 standard or update NCPDP standard to conform to immunization data requirements Work with SDOs to update the standards to conform to the data requirements Standard Overlaps This section describes the instances where there are overlaps among standards for the Use Case requirements. The overlap is only relative to the specific Use Case requirement. Overlaps refer to instances wherein some of the requirements are met by multiple standards. Recommended resolutions were developed through a series of steps including the Technical Committee s initial recommendations, cross Technical Committee validation of the overlap, provisional recommendations and peer review by the Technical Committees. The table below presents the identified overlaps and the respective resolution plans. 5/16/2010 Page 73 of 139

75 2248 Requirement Number DR11 Immunization response data DR76 Immunization query data Table 9 Use Case Requirements and Associated Standard Overlaps Summary Description Standard Overlap Recommended Resolution Immunization Query and Response a Action: Identify individuals needing immunization or drug b Alternative Action: Receive information about individuals needing prioritized intervention Action: Provide vaccine or drug administration information Action: Retrieve vaccine or drug administration information from external sources Action: Receive information describing the administration of a vaccine or drug Action: Request available immunization information Action: Conduct analysis to determine intervention priorities Action: Notify clinicians of individuals or population characteristics needing prioritized intervention Action: Receive and monitor inventory status information Action: Monitor inventory usage HITSP/TP21 (this leverages Care Record and Care Record Query DSTU's, from the HL7 Care Provision Domain) HL7 V2.4+ overlaps VXQ/VXR V2.3 and earlier VXQ/VXR is Deprecated 2.4 or 2.5 and replaced QRD/QRF structure. This also overlaps V3 which exists as a DSTU DR18 Vaccination Data Action: Receive information describing the administration of a vaccine or drug We will continue to support messages with optionality to include PIX/PDQ where supported. DR17 Decision Support Data Action: Receive immunization schedules Action: Incorporate immunization schedules into the clinician s EHR a Action: Identify individuals needing immunization or drug b Alternative Action: Receive information about individuals needing prioritized intervention Action: Record vaccine or drug administration information Action: Receive immunization schedules Action: Incorporate immunization schedules into the registry Action: Conduct analysis to determine intervention priorities Action: Identify individuals needing prioritized intervention 9.4 Data provisioning including support for secondary uses; data provisioning and distribution of data transmission parameters There are multiple standards for expression of clinical knowledge: Arden, GELLO, OWL, Common Logic, HL7 SOA SIG, W3C Web Services Support what exists today (VXQ/VXR) and allow for the new pilot testing to migrate toward Support for V3 and IHE components, including XDS, that might be used in lieu of VXQ and VXR and possibly web services through provisional standards selection Work with HL7 to resolve concerns that deprecation of VXQ/VXR may impact functionality requirements for immunization registries We want something that allows for this in one step Tier-2 Selection process; Work with SDOs to align and harmonize the standardization efforts in this area 5/16/2010 Page 74 of 139

76 2249 Requirement Number IER54 Query/response for clinical message data DR18 Summary Description Standard Overlap Recommended Resolution Immunization Query and Response Vaccination Data Action: Record vaccine or drug administration information Action: Report administration information to registries Action: Report administration information to registries Action: Provide vaccine or drug administration information Action: Receive information describing the administration of a vaccine or drug Action: Provide available immunization information via a personally controlled health record Vaccination V2 messages from today, V3 which exists as a DSTU Specify optionality to allow for a dual approach of V2.3.1 and TP21 capabilities with TP22 (PIX) and TP23 (PDQ) specified as optional for Immunization Information Systems, but required where available for EHR systems Conformance Statements 1. IMC messages are conformant with HITSP/C72 Immunization Message specification 2. IMC documents and services are compliant with: o HITSP/C83 CDA Content Modules o HITSP/ C80 Terminology o HITSP/ C154 Data Dictionary. o Manufactured vaccines are identified by either a Global Trade Identification Number (GTIN) or Drug Identification Number (DIN). The CDC codes for immunizations and manufacturers o The American Immunization Registry Association (AIRA) Immunization Information Systems Codebook: Guide to Code Sets and Data Definitions for Registry Data Sharing Using HL7 dated 06/03/2009, available at o SNOMED-CT is used to represent "genericized" immunizing agents (e.g. "MMR" vs. a GTIN for a specific manufacturer's MMR product 3. Standards gaps and overlaps are identified Discussion This section included the data requirements, which were derived from the analysis of the IMR use case. The ultimate standards solution must fit within the HITSP/ TN903 Data Architecture. Information intended for one purpose can be repurposed or transformed to become data used as input into a new process to create information for a different purpose. Transformation processes may be automated or be the result of human judgment. An Information Model then, is a means of classifying information topics of interest (e.g., clinical summary, encounter note, transfer of care summary, etc.). Information is a set of data that has been collated, interpreted and presented to be meaningful to a particular audience for a particular purpose. A Data Model defines the specific subjects and the facts about them (e.g., HITSP TN903). The same data can be used to produce many different pieces of information. A Data Model does not identify or define any topics that are essentially derived by any transformation process. Notice that there are standards gaps and overlaps, which may need to be harmonized within the standards Development Organizations (SDOs). These gaps and overlaps represent risks to the IMC project. 5/16/2010 Page 75 of 139

77 Platform-Independent Computation-Viewpoint The ECCF Platform-Independent Computation-Viewpoint is defined by collaboration analysis (e.g., UML sequence diagrams), functional profiles, service roles and relationships. The Platform-Independent Computation-Viewpoint is concerned with the functional decomposition of the system into a set of components that exhibit specific behaviors and interact at interfaces. This Viewpoint answers the question how and references behavioral specifications. This viewpoint is primarily useful to System Engineers and Business Process Modelers. This Viewpoint might typically contains some combination of: Use Case Specs Component specs Interface Specs Interaction Specs Collaboration Participations Collaboration Types Function Types Interface Types Collaboration Scripts Service Contracts For SampleHealth the Platform-Independent Computation-Viewpoint is defined by Capabilities composed of HITSP Transactions, Transaction Packages, Service Collaborations Service Interface Specification Types and Functional Group Types, Map of Business Functions The SampleHealth Business Functions Map identifies the business functions performed by SampleHealth in Volume I. These high-level business lines are likely consistent with many mid-sized healthcare provider organizations. This collection of information is the baseline against which gap analyses can be performed and the candidate list of tobe services identified. Comparing Table 10 to Table 11 we see the tremendous reuse gained by a SOA. 5/16/2010 Page 76 of 139

78 2307 Healthcare Unique Services Business Services SOA Infrastructure Services Order Entry Order Fulfillment Patient Evaluation (DSS) Laboratory Data Retrieval Pharmacy Data Retrieval EHR Alert/Event Mgmt Master Person Index Terminology Service Demographics Billing Scheduling Auditing Service Exception Mgmt Business Process Mgmt (BPM) Business Line Pharmacy X X X X X X X X X X X X X X Laboratory X X X X X X X X X X X X X X X Patient Administration X X X X X X X X Order Entry/Mgmt X X X X X X X X X X X X X X Scheduling X X X X X X X X X Registration X X X X X X X X X Care Management X X X X X X X X X X X X X X X X X Referrals/Referral Mgmt X X X X X X X X X X X X X X X X X Nursing X X X X X X X X X X X X X X X X X Emergency Department X X X X X X X X X X X X X X X X Patient Billing X X X X X X X X X X X X Imaging/Radiology X X X X X X X X X X X X X Clinical Decision Support X X X X X X X X X X Facilities Management X X X X X X Nutrition Mgmt (Dietetics) X X X X X X X X X X X X X X X X Table 10 As-Is SampleHealth Business Function Map Order Entry Order Fulfillment Patient Evaluation (DSS) Healthcare Unique Services Laboratory Data Retrieval Pharmacy Data Retrieval Immunization Management EHR Alert/Event Mgmt Business Services Master Person Index Terminology Service Demographics Billing Scheduling Authentication Services Directory SOA Infrastructure Services Business Line Pharmacy X X X X X X X X X X X X X X Laboratory X X X X X X X X X X X X X X X Patient Administration X X X X X X X X Order Entry/Mgmt X X X X X X X X X X X X X X X Scheduling X X X X X X X X X Registration X X X X X X X X X Care Management X X X X X X X X X X X X X X X X X X Referrals/Referral Mgmt X X X X X X X X X X X X X X X X X X Nursing X X X X X X X X X X X X X X X X X X Emergency Department X X X X X X X X X X X X X X X X X Patient Billing X X X X X X X X X X X X X Imaging/Radiology X X X X X X X X X X X X X Clinical Decision Support X X X X X X X X X X X Facilities Management X X X X X X Nutrition Mgmt (Dietetics) X X X X X X X X X X X X X X X X Immunization Registry X X X X X X X X X X X X X X X X Table 11 To-Be SampleHealth Business Function Map Auditing Service Exception Mgmt Business Process Mgmt (BPM) Authentication Services Directory 5/16/2010 Page 77 of 139

79 Use Cases and Business Level Interaction Diagrams This section describes the Immunizations and Response Management (IRM) 35 Use Case requirements and outlines the given IRM scenarios at a high level. The IRM Use Case focuses on: 1) access to information about individuals who need to receive specific vaccines, drugs, or other interventions; 2) the ability to report, track, and manage administration of vaccines, drugs, isolation, and quarantine; 3) the ability to identify and electronically exchange information describing the treatment or prophylaxis status of populations; 4) the ability to exchange specific resource and supply chain data from public and private sectors. The Use Case describes these activities within the context of two scenarios: 1. Vaccine and Drug Administration and Reporting: This scenario describes the process of identifying individuals and populations requiring and the administration of vaccines or drugs based on routine schedules, or as dictated by emergency response priorities. Additionally, this scenario describes the exchange of data necessary to support countermeasure and response administration of prophylaxis and treatment modalities, and the supply of data between appropriate registries and other sources of data to support clinical care and public health follow-up activities. 2. Vaccine and Drug Inventory Reporting: This scenario describes how information regarding the need for, and availability of, vaccines and/or drugs is collected and exchanged to support coordinated delivery of care. SampleHealth has chosen to defer Scenario 2: Vaccine and Drug Inventory Reporting; but, include the associations and commonalities between the scenarios in the IRM Use Case and the AHIC Public Health Case Reporting (PHCR) 36 Use Case. Additionally, the IRM Use Case does not specifically cite processing a query and response solely for the sake of getting the data without the goal of identifying whether or not a vaccination is needed (e.g., for school registration), this functionality is required by SampleHealth. The IRM Use Case assumes the developing presence of electronic systems such as Electronic Health Records (EHRs), Personal Health Records (PHRs), and other local or Web-based solutions supporting consumers and clinicians, while recognizing the issues and obstacles associated with these assumptions. 35 Immunization and Response Management (IRM), Detailed Use Case, U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, March 21, Public Health Case Reporting, Detailed Use Case, U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, March 21, /16/2010 Page 78 of 139

80 Information Exchanges Figure 14 Immunization and Response Management Information Exchanges The following information exchanges are key to the IRM use case, Vaccine and Drug Administration and Reporting Scenario: 1. Immunization knowledge providers distribute immunization schedules for incorporation into Immunization Information Systems (IIS), other registries, EHR systems and possibly health information exchange. 2. Registries, including IISs, provide immunization information to clinicians, consumers, other registries and other organizations 3. Registries, including IISs, gather vaccine or drug administration information from clinicians, consumers, other registries and other organizations 4. Consumers provide available immunization information to clinicians 5. Following administration of (or inability to administer) a vaccine or drug the clinician provides appropriate clinical documentation to registries, consumers and others 6. Public health gathers information to identify individuals needing prioritized intervention 7. Public Health provides information to clinicians about populations or individuals having special needs for immunization or other intervention 8. Registries provide information about vaccine recalls to clinicians and affected consumers 5/16/2010 Page 79 of 139

81 Information Exchange Requirements (IERs) IRM Information Exchange Requirements (IERs) 37 : 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 NOTE: Blue Italics indicates IERs, which are common to 1-IRM and 2-PHCR PHCR Information Exchange Requirements (IERs) 38 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 HITSP Security and Privacy Information Exchange Requirements (IERs): 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 37 See HITSP Interoperability Specification (IS) 10 Immunization and Response Management for details. It is available at 38 See HITSP Interoperability Specification (IS) 11 Public Health Case Reporting Interoperability Specification Immunization for details. It is available at 5/16/2010 Page 80 of 139

82 Business Level Behavioral Specifications The SampleHealth IMC project focused on adding an immunization registry to its existing enterprise. The ECCF Conceptual Computation-Viewpoint presented the behavioral specifications for the following system components: Public Health Information System, EHR System, which contains the Immunization Information System (IIS) component, PHR System, HIE System which provides Infrastructure Services (e.g., ESB). Business Process Models are currently popular for Business level behavioral specifications; but, UML sequence diagrams were used in HITSP IS10 because they are more concise and more closely correspond to the AHIC IRM use case, which were modeled. Behavioral Specifications in the form of Use Case dynamic views (e.g., in our case, sequence diagrams) illustrate each Use Case scenario with a representation of a normal sequence of exchanges among the primary actors. The event codes from the Use Case are annotated on the diagrams to show how the interactions relate to the Use Case. The interactions are supported by the various constructs which are introduced in the Figure 21 Mapping of Requirements to HITSP Constructs. 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 depicts the events and actions associated with the clinician perspective from the Immunizations and Response Management (IRM) Scenario 2: Vaccine and Drug Administration and Reporting. The clinician in this exchange may represent clinicians performing administration and treatment in routine care settings and non-routine settings including, but not limited to physician offices, hospitals, clinics, field medical stations, pharmacies, incident locations. It is assumed in this diagram that the clinician is supported in the interactions with registries and other business actors through the EHR. 5/16/2010 Page 81 of 139

83 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 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 depicts the events and actions associated with the registries perspective from the Immunizations and Response Management Scenario 2: Vaccine and Drug Administration and Reporting. It is assumed in this diagram that the public health and registry personnel are supported in the interactions with other business actors through the registries. 5/16/2010 Page 82 of 139

84 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 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 depicts the events and actions associated with the consumer perspective from the Immunizations and Response Management Scenario 2: Vaccine and Drug Administration and Reporting. It is assumed in this diagram that the consumer is supported in the interactions with other business actors either through the PHR or through interactions with their clinicians, who are supported through the EHR. 5/16/2010 Page 83 of 139

85 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 /16/2010 Page 84 of 139

86 2444 Figure 18 Immunizations and Response Management (IRM) Business Sequence Part Service Interaction Types and Collaboration Participations System-Level Exchange Architecture Figure 19 As-Is SampleHealth Information System High Level Architecture and Figure 20 To-Be SampleHealth Information System High Level Architecture show the addition of the IMC information exchanges to the as-is SamplaHealth architecture. 5/16/2010 Page 85 of 139

87 Figure 19 As-Is SampleHealth Information System High Level Architecture 5/16/2010 Page 86 of 139

88 Figure 20 To-Be SampleHealth Information System High Level Architecture 5/16/2010 Page 87 of 139

89 System Data Exchange Behavioral Specifications The Dynamic View (e.g., UML sequence diagrams) used in this section incorporate the detailed data requirements for the selected standards, with the interfaces and their specific and detailed Transactions and content encapsulated in the HITSP constructs. The detailed interface Transactions described in these diagrams show all common or independent interfaces, data, and the specific transactions from the HITSP constructs that are used for the IRM Capability. Figure 21 below provides a mapping of the HITSP constructs that will be used in the design of the IRM capability and the data and information exchange requirements that are being satisfied by the construct. Construct Name HITSP/C19 - Entity Identity Assertion HITSP/C26 - Nonrepudiation of Origin HITSP/C62 - Unstructured Document Figure 21 Mapping of Requirements to HITSP Constructs Information Exchange Requirement Number (IER#) IER5 Verify entity identity IER6 Provide proof of document integrity and origin Data Requirement Number (DR#) DR8 Unstructured data HITSP/C70 - Immunization Query and Response IER54 Query/response for clinical message data DR11 Immunization response data DR76 Immunization query data HITSP/C72 - Immunization Message IER67 Send/receive clinical message DR18 Vaccination data HITSP/C78 - Immunization Document HITSP/C80 Document and Message Terminology HITSP/C83 CDA Content Modules HITSP/C88 - Anonymize Immunizations and Response Management Data HITSP/T63 - Emergency Message Distribution Element HITSP/64 - Identify Communication Recipients HITSP/C82 - Emergency Common Alerting Protocol HITSP/T15 - Collect and Communicate Security Audit Trail HITSP/T16 - Consistent Time IER55 Anonymize patient identifiable data IER27 Send non-patient notification message or alert IER26 Identify communication recipients IER27 Send non-patient notification message or alert IER3 Create audit log entry IER4 Synchronize system time DR18 Vaccination data DR23 Consumer vaccination view DR11 Immunization response data DR76 Immunization query data DR18 Vaccination data DR58 Demographic data vaccination DR23 Consumer vaccination view DR18 Vaccination data DR58 Demographic data vaccination DR23 Consumer vaccination view DR22 Generic alert data - Immunizations DR22 Generic alert data - Immunizations DR8 Unstructured datadr8 Unstructured data (Alerts) DR18 Vaccination data DR16 Supply chain management vaccine recall (deferred) DR22 Generic alert data Immunizations 5/16/2010 Page 88 of 139

90 Construct Name HITSP/T17 - Secured Communication Channel HITSP/T23 - Patient Demographics Query HITSP/T24 - Pseudonymize HITSP/T29 - Notification of Document Availability HITSP/T31 - Document Reliable Interchange HITSP/T33 - Transfer of Documents on Media HITSP/T66 - Retrieve Value Set Terminology Service HITSP/T81 - Retrieval of Medical Knowledge HITSP/TP13 - Manage Sharing of Documents HITSP/TP20 - Access Control HITSP/TP21 - Query for Existing Data HITSP/TP22 - Patient ID Cross- Referencing HITSP/TP30 - Manage Consent Directives Information Exchange Requirement Number (IER#) IER2 Send data over secured communication channel IER10 Identify patient IER56 Pseudonymize patient identifying information IER13 Send/receive notification of document availability IER18 Send/receive clinical document IER18 Send/receive clinical document IER42 Request/receive medical concept knowledge IER18 Send/receive clinical document IER1 Provide authorization and consent IER40 Query for existing data IER10 Identify patient IER1 Provide authorization and consent Data Requirement Number (DR#) DR58 Demographic data - vaccination DR8 Unstructured data DR21 Terminology data DR58 Demographic data vaccination The UML sequence diagrams used in this section incorporate the detailed data requirements for the selected standards and their specific and detailed Transactions and content (encapsulated in the HITSP constructs listed above). The detailed actor Transactions described in these diagrams show all common or independent technical actors, data, and the specific transactions from the HITSP constructs that are used for the IRM Capability. Figure 22 below depicts the options supported to communicate vaccinations. Multiple options are specified for communication of immunization information in order to enable current operational systems migration toward shared patient identification services as defined by HITSP/TP22 and HITSP/T23. A CDA vaccination (HITSP/C78) is also specified to support PHR interoperability and as an option for providers and Immunization Information System to engage in document sharing of immunizations. Option 1 - Use just HL7 VXU (HITSP/C72) from the message sender (clinician system or Immunization Information System) to the message receiver (Immunization Information System) Option 2 - If the HIE offers a HITSP/TP22 PIX manager, the clinician system shall first query the PIX manager using a PIX (HITSP/TP22) or PDQ (HITSP/T23) query transaction and populate the patient identifier in the HL7 VXU (HITSP/C72) message with the HIE domain identifier Option 3 From the PHR, a HITSP/C78 Immunization Document can be communicated as a shared document to a document repository or sent to the Immunization Information System using document reliable interchange (HITSP/T31) or via media/ (HITSP/T33). Option 4 The HITSP/C78 document can be communicated as a shared document to a document repository 5/16/2010 Page 89 of 139

91 Working Draft; NOT for Public Distribution (HITSP/TP13) or sent to another provider o using document reliable interchange (HITSP/T31) or via media/ (HITSP/T33) Option 5 An Immunization Information System may optionally support a document repository and receive vaccination data using document reliable interchange (HITSP/T31) or via media/ (HITSP/T33). The Immunization Information System may retrieve an Immunization document (HITSP/C78) from the document repository or from another jurisdiction document repository for cross-jurisdiction information sharing leveraging query and retrieve transactions and the Cross Community Access option in HITSP/TP13. As current immunization registries are not configured with these capabilities, this is a forward looking option Option 6 An Immunization Information System may optionally send an unsolicited notification using HITSP/C72 to a clinical information system to indicate that one of their patients has received an immunization from another clinician (e.g., Airport, school, another clinician) Figure 22 Communicate Vaccinations Figure 23 below depicts the options supported to communicate Immunization Query and Response. 5/16/2010 Page 90 of 139

92 Multiple options are specified for Immunization Query and Response in order to enable current operational systems migration toward shared patient identification services as defined by HITSP/TP22 and HITSP/T23 and to enable migration toward HITSP/TP21: Option 1 Use the traditional HL7 VXQ to send a query from the message sender (clinician system) to the message receiver (Immunization Information System) and the HL7 VXR to send the result of the query from the message sender (Immunization Information System) to the message receiver (clinician system) (HITSP/C70) Option 2 If the HIE offers a PIX manager (HITSP/TP22), the clinician system shall first query the PIX manager (using HITSP/TP22 or HITSP T23) and populate the patient identifier in the HL7 VXQ message with the HIE domain identifier and in the resulting VXR message (HITSP/C70). NOTE: policy would need to assert query result policies in PDQ as currently specified for VXR Option 3 - Use HITSP/TP21 Query for Existing Data to request and receive immunization data; If the HIE offers a PIX manager, the clinician system shall first query the PIX manager and populate the patient identifier in the HITSP/TP21 query Option 4 Where there are immunization documents available in the HIE Document repository, use HITSP/TP13 Manage Sharing of Documents query/retrieve to gather the most up-to-date immunization data available. which may be published as HITSP/C62 Unstructured Document Component containing summary or patient-specific immunization alert, HITSP/C78 Immunization Document) 5/16/2010 Page 91 of 139

93 2519 Figure 23 Immunization Query and Response Figure 24 below depicts the options supported to communicate notification of immunization related alerts: Option 1 Non-patient specific push Where the alert is generic and not specific to a particular patient (e.g., immunizations required for a particular population such as those over the age of 65) and the communication requires presentation preserving properties, the communication recipients are identified using the Identify Communication Recipients (HITSP/T64) construct, and the generic alert is sent to those providers leveraging the Emergency Message Distribution Element (HITSP/T63) with the Emergency Common Alerting Protocol (HITSP/C82). The communication itself may be conducted using , Health Alert Network (HAN), or FAX as specified by the implementation. Communication recipients may be identified using the Identify Communication Recipients (HITSP/T64) construct Option 2 Where the alert is generic and not specific to a particular patient (e.g., immunizations required for a particular population such as those over the age of 65) and the communication is text-based, the communication recipients are identified using the Identify Communication Recipients (HITSP/T64) construct, and the generic 5/16/2010 Page 92 of 139

94 Working Draft; NOT for Public Distribution alert is sent to those providers using the Emergency Message Distribution Element (HITSP/T63) with the Emergency Common Alerting Protocol (HITSP/C82). Option 3 Where the alert is patient-specific in nature, the notification of document availability (HITSP/T29) is sent to the alert recipient (may be patient or provider). The person receiving the alert may then retrieve the patient-specific alert as an Unstructured Document (HITSP/C62) which will contain the immunization notification alert and instructions for the clinician or patient. Option 4 Context specific information may be requested by the EHR or PHR using Retrieval of Medical Knowledge (HITSP/T81) as part of the user interface or pre-fetching options. This approach may be used to address the request of immunization data for assessment if a vaccine is needed. This option leverages a retrieval model and can not be leveraged for a distribution only approach. Figure 24 Vaccine and Drug Inventory Reporting /16/2010 Page 93 of 139

95 Service Collaboration Types The scope of the SampleHealth Immunization Management capability design as it relates to the Information Exchange and Data Requirements for the IRM Use Case is to enable electronic communication of immunization data among clinicians, with patients, and with other immunization registries as identified in Scenario 1 (Vaccine and Drug Administration and Reporting). All specification for Scenario 2 (Vaccine and Drug Inventory Reporting) has been deferred pending further analysis of the workflow, business actor responsibilities, and available standards suitable to fulfill the needs identified through this effort. We will include: Establish Transaction Packages, Transactions, and Components to complete the Use Case requirements related to the communication of vaccination information between patients, providers, and immunization registries, including registry-to-registry communications Enable optionality of architectures supporting traditional legacy message-based communications, addition of support for patient identification services (HITSP/TP22 Patient ID Cross-Referencing, HITSP/T23 Patient Demographics Query) and the addition of support for document-centric sharing and point-to-point communications. This optionality will allow existing systems a migration path to adopt patient identity services and document sharing approaches without disrupting operational environments Adoption of HL7 V2.3.1 messaging with the expectation that this will be updated in accordance with future HL7 implementation guides Include Security and Privacy constraints for implementation of the Immunizations and Response Management Interoperability Specifications We will NOT include Use Case actions requiring clinical decision support capabilities: Immunization Schedules Immunization Reminders Immunization Prioritizations Contraindication Alerts Active/Passive Surveillance for Adverse events All specification for Scenario 2 (Vaccine and Drug Inventory Reporting). Figure 26 summarizes the system roles of the proposed Immunization Management Capability. TBD Figure 25 Immunization Management Entities, Actions and Roles System Role Immunization Schedule Sender* Immunization Schedule Receiver* Immunization Information Sender Figure 26 Capability System Roles System Role Definition Immunization knowledge providers distribute immunization schedules for incorporation into Immunization Information Systems (IIS), other registries, EHR systems and possibly health information exchange. The system which receives the immunization schedule Registries, including IISs, provide immunization information to clinicians, consumers, other registries and other 5/16/2010 Page 94 of 139

96 Immunization Information Receiver (clinician system) Vaccine or Drug Administration Information Sender Vaccine or Drug Administration Information Receiver Immunization Information Sender (consumer PHR) Immunization Information Receiver (clinician system) Clinical Documentation Sender (clinician system) Clinical Documentation Receiver Public Health Information Sender* organizations. The system which receives the immunization information The system which sends the vaccine or drug administration information Registries, including IISs, gather vaccine or drug administration information from clinicians, consumers, other registries and other organizations Consumers provide available immunization information to clinicians The system which receives the immunization information Following administration of (or inability to administer) a vaccine or drug the clinician provides appropriate clinical documentation to registries, consumers and others The system which receives the clinical documentation The system which sends the public health information Public Health Information Receiver* Public health gathers information to identify individuals needing prioritized intervention Public Health Alert Sender* Public Health provides information to clinicians about populations or individuals having special needs for immunization or other intervention Public Health Alert Receiver* The system which receives the Public Health Alerts Vaccine Recalls Information Sender* Registries provide information about vaccine recalls to clinicians and affected consumers Vaccine Recalls Information* The system which receives information about vaccine recalls NOTE: * indicates this system role is out-of-scope to keep this case study short. Figure 27 defines each of the Information Exchanges supported by the proposed Immunization Management Capability in terms of the Exchange Action (EA) or Exchange Content (EC) used. Information Exchange Identifier Figure 27 Information Exchanges Mapped to External Interfaces Exchange Action A** Send Immunization Schedules B Send Immunization Information Exchange Content C Send Vaccine or Drug Administration Information D Send Immunization Information E Send Clinical Documentation F** Send Public Health Information G** Send Public Health Alert information 5/16/2010 Page 95 of 139

97 Information Exchange Exchange Action Exchange Content Identifier H** Send Vaccine Recalls Information NOTE: ** indicates this information exchange is out-of-scope to keep this case study short. Figure 28 identifies how this Capability supports various system roles within multiple system architectures. For example, either an Electronic Health Record (EHR) system or a Health Information Exchange (HIE) might fill a registry system role in an information exchange). In an implementation architecture, system roles may be combined locally (e.g., Hospital EHR System) and in others, the system roles may be provided by multiple-distributed trusted third parties (e.g., registries within an HIE). cmp SampleHealth Immunization Management Capability Figure 28 Supported Information Exchanges Consumer System (e.g., PHR) Clinician System (e.g., EHR) C, D B, E, H C, E, F, G, H A, B, D Immunization Information Systems (IIS) B, C, F A, B, C Other Organizations C B, E A Immunization Information Provider B, C, F, H A, B, C, E Registry System (e.g., HIE) G Public Health Systems F A - Immunization Schedules B - Immunization Information C - Vaccine or Drug Administration Information D - Immunization Information E - Clinical Documentation F - Public Health Information G - Public Health Alert information H - Vaccine Recalls Information Immunization knowledge providers distribute immunization schedules for incorporation into Immunization Information Systems (IIS), other registries, EHR systems and possibly health information exchange. 2. Registries, including IISs, provide immunization information to clinicians, consumers, other registries and other organizations 3. Registries, including IISs, gather vaccine or drug administration information from clinicians, consumers, other registries and other organizations 4. Consumers provide available immunization information to clinicians 5. Following administration of (or inability to administer) a vaccine or drug the clinician provides appropriate clinical documentation to registries, consumers and others 6. Public health gathers information to identify individuals needing prioritized intervention 7. Public Health provides information to clinicians about populations or individuals having special needs for immunization or other intervention 8. Registries provide information about vaccine recalls to clinicians and affected consumers Figure 29 defines the mapping of the Information Exchanges supported by this Capability in terms of the Exchange Action (EA), Exchange Content (EC) and any Constraints applied to the Information Exchange with specific initiating and/or responding system interfaces. This provides the traceability of constructs to the information exchanges identified above. Content modules and terminology Components are not listed here because they are referenced by other constructs, but do not provide an interface. HITSP/TN903 discusses how content modules and terminology Components are referenced by other constructs. 5/16/2010 Page 96 of 139

98 2603 Information Exchange Identifier A - Send Immunization Schedules B - Send Immunization Information C - Send Vaccine or Drug Administration Information D - Send Immunization Information E - Send Clinical Documentation Working Draft; NOT for Public Distribution Figure 29 Information Exchanges Mapped to Constructs Exchange Type Construct Identifier Description Send HITSP/64 - Identify Communication Recipients, HITSP/T81 - Retrieval of Medical Knowledge, HITSP/TP13 - Manage Sharing of Documents Query/ Response HITSP/C70 - Immunization Query and Response, HITSP/TP13 - Manage Sharing of Documents HITSP/C78 - Immunization Document HITSP/C80 Document and Message Terminology HITSP/C83 CDA Content Modules Query/ Response HITSP/C70 - Immunization Query and Response HITSP/TP13 - Manage Sharing of Documents HITSP/C78 - Immunization Document HITSP/C80 Document and Message Terminology HITSP/C83 CDA Content Modules Send HITSP/T33 - Transfer of Documents on Media, HITSP/TP13 - Manage Sharing of Documents HITSP/C78 - Immunization Document HITSP/C80 Document and Message Terminology HITSP/C83 CDA Content Modules Send HITSP/C72 - Immunization Message, HITSP/TP13 - Manage Sharing of Documents, HITSP/C78 - Immunization Document HITSP/C80 Document and Message Terminology HITSP/C83 CDA Content Modules Immunization knowledge providers distribute immunization schedules for incorporation into Immunization Information Systems (IIS), other registries, EHR systems and possibly health information exchange. Registries, including IISs, provide immunization information to clinicians, consumers, other registries and other organizations Registries, including IISs, gather vaccine or drug administration information from clinicians, consumers, other registries and other organizations Consumers provide available immunization information to clinicians Following administration of (or inability to administer) a vaccine or drug the clinician provides appropriate clinical documentation to registries, consumers and others 5/16/2010 Page 97 of 139

99 Information Exchange Identifier F - Send Public Health Information G - Send Public Health Alert information H - Send Vaccine Recalls Information Exchange Type Construct Identifier Description Send Send Send HITSP/TP13 - Manage Sharing of Documents, HITSP/C78 - Immunization Document HITSP/C80 Document and Message Terminology HITSP/C83 CDA Content Modules HITSP/64 - Identify Communication Recipients, HITSP/C82 - Emergency Common Alerting Protocol HITSP/T63 - Emergency Message Distribution Element HITSP/64 - Identify Communication Recipients HITSP/C62 - Unstructured Document Public health gathers information to identify individuals needing prioritized intervention Public Health provides information to clinicians about populations or individuals having special needs for immunization or other intervention Registries provide information about vaccine recalls to clinicians and affected consumers Next we will specify the HITSP Capability interfaces in terms of the Capability s System Roles. Figure 30 Immunization Information Sender System Role Mapped to HITSP Construct Interfaces Construct Interface Optionality Legend: R for Required, O for Optional, or C for Conditional Figure 31 Implementation Conditions Condition ID Interface Type TBD TBD TBD TBD TBD T/TP/SC or Content Condition Description TBD the set of system roles mapped to HITSP construct interfaces needs to be completed T/SC/Content Optionality 5/16/2010 Page 98 of 139

100 Service Contracts Parts SampleHealth is a signature in the NHIN Data Use and Reciprocal Support Agreement (DURSA 39 ), which is a comprehensive, multi-party trust agreement that is signed by all eligible entities who wish to exchange data among its participant organizations. The DURSA requires signatories to abide by common set of terms and conditions that establish Participants obligations and the trust fabric to support the privacy, confidentiality and security of health data that is exchanged The DURSA assumes that each participant has trust relationships in place with its agents, employees and data connections (end users, systems, data suppliers, networks, etc.). The DURSA is a living document, the agreement is be modified over time. The following are the key provisions of the DURSA: Multi-Party Agreement: The DURSA accommodates and accounts for a variety of Participants so that it can successfully serve as a multi-party agreement among all Participants. This multi-party agreement is critical to avoid the need for each Participant to enter into point-to-point agreements with each other Participant, which becomes exceedingly difficult, costly and inefficient as the number of Participants increases. Federal participants have asserted that supporting point-to-point agreements is not sustainable for information exchange. Participants in Production: The DURSA expressly assumes that each Participant is in production and, as a result, already has in place trust agreements with or written policies applicable to its agents, employees and data connections (end users, data suppliers, systems, and networks, etc.). These trust agreements and policies must include terms necessary to support the trust framework memorialized in the DURSA. Applicable Law: The DURSA reaffirms each Participant s obligation to comply with Applicable Law. As defined in the DURSA, Applicable Law is the law of the jurisdiction in which the Participant operates. For non-federal Participants, this means the law in the state(s) in which the Participant operates and any applicable Federal law. For Federal Participants, this means applicable Federal law. Privacy and Security Obligations: To the extent that each Participant has existing privacy and security obligations under applicable law (e.g. HIPAA or other state or federal privacy and security statutes and regulations), the Participant is required to continue complying with these obligations. Participants, which are neither HIPAA covered entities, HIPAA business associates nor governmental agencies, are obligated to comply with specified HIPAA Privacy and Security provisions as a contractual standard of performance. Requests for Data Based on Permitted Purposes: Participant s end users may only request data through the NHIN for Permitted Purposes, which include treatment, payment, limited health care operations with respect to the patient that is the subject of the data request, specific public health activities, quality reporting for meaningful use and disclosures based on an authorization from the individual. Duty to Respond: Participants that allow their respective end users to seek data for treatment purposes have a duty to respond to requests for data for treatment purposes. This duty to respond means that if actual data is not sent in response, the Participant will at a minimum send a standardized response to the requesting Participant. Participants are permitted, but not required, to respond to all other (non-treatment) requests. The DURSA does not require a Participant to disclose data when such a disclosure would conflict with Applicable Law. Future Use of Data Received Through the NHIN: Once the Participant or Participant s end user receives data from a responding Participant (i.e. a copy of the responding Participant s records), the recipient may incorporate 39 For more information see and search DURSA. 5/16/2010 Page 99 of 139

101 that data into its records and retain that information in accordance with the recipient s record retention policies and procedures. The recipient can re-use and re-disclose that data in accordance with all applicable law and the agreements between a Participant and its end users. Duties of Requesting and Responding Participants: When responding to a request for data, Participants will apply their local policies to determine whether and how to respond to the request. This concept is called the autonomy principle because each Participant can apply its own local access policies before requesting data from other Participants or releasing data to other Participants. It is the responsibility of the responding Participant the one disclosing the data to make sure that it has met all legal requirements before disclosing the data, including, but not limited to, obtaining any consent or authorization that is required by law applicable to the responding Participant. Duties of Requesting and Responding Participants: To effectively enable the exchange of health information in a manner that protects the privacy, confidentiality and security of the data, the DURSA adopts the HIPAA Privacy and Security Rules as minimum requirements. When a request is based on a purpose for which authorization is required under HIPAA (e.g. for SSA benefits determination), the requesting Participant must send a copy of the authorization with the request for data. Requesting Participants are not obligated to send a copy of an authorization or consent when requesting data for treatment purposes. NHIN Coordinating Committee: The NHIN Coordinating Committee is responsible for accomplishing the necessary planning, consensus building, and consistent approaches to developing, implementing and operating the NHIN, including playing a key role in the following: NHIN breach notification Dispute resolution Participant membership, suspension and termination; NHIN operating policies and procedures; and, Informing the NHIN Technical Board when proposed changes for interface specifications have a material impact on Participants. NHIN Technical Committee: The NHIN Technical Committee will be responsible for determining priorities for the NHIN and creating and adopting specifications and test approaches. The NHIN Technical Committee will work closely with the NHIN Coordinating Committee to assess the impact that changes to the specifications and test approaches may have on Participants. Breach Notification: Participants are required to promptly notify the NHIN Coordinating Committee and other impacted Participants of suspected breaches (within 1 hour) or confirmed breaches (within 24 hours) which involve the unauthorized disclosure of data through the NHIN, take steps to mitigate the breach and implement corrective action plans to prevent such breaches from occurring in the future. This process is not intended to address any obligations for notifying consumers of breaches, but simply establishes an obligation for Participants to notify each other and the Coordinating Committee when breaches occur to facilitate an appropriate response. Mandatory Non-Binding Dispute Resolution: Because the disputes that may arise between Participants will be relatively complex and unique, the Participants are required to participate in the dispute resolution process but are still free to pursue legal remedies if they are not satisfied with the outcome of the dispute resolution process. Following is the Multi-step process: Informal Conference between the Participants involved in the dispute If not resolved through the Informal Conference, the Dispute Resolution Subcommittee hears the dispute and is encouraged to develop an appropriate and equitable resolution NHIN Coordinating Committee can review the Subcommittee s recommendation, if requested by any Participant involved in the dispute, and issue its own resolution 5/16/2010 Page 100 of 139

102 Allocation of Liability Risk: With respect to liability, the DURSA articulates the Participants understanding that each Participant is responsible for its own acts or omissions and not for the acts or omissions of any other Participant. If a Participant allows a User to improperly access Message Content through the NHIN and another Participant is harmed as a result then the Participant who allows that access may be liable. However, the DURSA explicitly recognizes that a Participant cannot bring a cause of action against another Participant where the cause of action is prohibited by Applicable Law. This section is not intended as a hold harmless or indemnification provision Conformance Statements The IMC specified information exchange requirements and their associated data requirements are satisfied or gaps are identified and a transition plan is specified Discussion The ECCF Platform-Independent Computation-Viewpoint presents SampleHealth s exchange architecture, system functions and interface design specifications, which are specified by HITSP Capability, Service Collaboration, Transaction, transaction Package and Component constructs Platform-Independent Engineering-Viewpoint The ECCF Platform-Independent Engineering-Viewpoint is defined by existing platform capabilities. The Engineering-Viewpoint is concerned with the mechanisms and functions required to support the interactions of the computational components. This ECCF viewpoint may overlap with the RM-ODP technology viewpoint, which is concerned with the explicit choice of technologies for the implementation of the system, and particularly for the communications among the components. This viewpoint answers the question where and refers to implementation environments. This viewpoint is of primary interest to Application Architects. This Viewpoint might typically contains some combination of: Existing Platform models, Capabilities, Libraries and Versions Existing Platforms For SampleHealth the Platform-Independent Engineering-Viewpoint is defined by HSSP and NHIN Services to be: This viewpoint is primarily useful to enterprise architects. For SampleHealth the Conceptual Engineering-Viewpoint is defined by NHIN Connect to be: Apache Tomcat (or Jakarta Tomcat or simply Tomcat) is an open source servlet container developed by the Apache Software Foundation (ASF). Tomcat implements the Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems, and provides a "pure Java" HTTP web server environment for Java code to run. JBoss Application Server (or JBoss AS) is a free software/open-source Java EE-based application server. Because it is Java-based, the JBoss application server operates cross-platform: usable on any operating system that supports Java. JBoss AS was developed by Jboss, now a division of Red Hat. J2SE, Java Platform, Standard Edition or Java SE is a widely used platform for programming in the Java language. It is the Java Platform used to deploy portable applications for general use. In practical terms, Java SE consists of a virtual machine, which must be used to run Java programs, together with a set of libraries (or "packages") needed to allow the use of file systems, networks, graphical interfaces, and so on, from within those programs. Eclipse Open Healthcare Framework (OHF) is a project within Eclipse formed for the purpose of expediting healthcare informatics technology. The project is composed of extensible frameworks and tools which 5/16/2010 Page 101 of 139

103 Working Draft; NOT for Public Distribution emphasize the use of existing and emerging standards in order to encourage interoperable open source infrastructure, thereby lowering integration barriers. GlassFish ESB v2 integrates the OpenESB project into the GlassFish Java 5 EE Application Server, where "Project OpenESB implements an Enterprise Service Bus (ESB) runtime using Java Business Integration (JBI) as the foundation, enabling the easy integration of web services to create loosely coupled, enterprise-class composite applications." GlassFish is an open source application server project led by Sun Microsystems for the Java EE platform. GlassFish is free software, dual-licensed under two free software licenses: the Common Development and Distribution License (CDDL) and the GNU General Public License (GPL) with the classpath exception. GlassFish is based on source code released by Sun and Oracle Corporation's TopLink persistence system. It uses a derivative of Apache Tomcat as the servlet container for serving Web content, with an added component called Grizzly which uses Java NIO for scalability and speed. OpenSSO is an open source access management and federation server platform. OpenSSO is based on Sun Java System Access Manager, and is the core of Sun's commercial access management and federation product, OpenSSO Enterprise (formerly Sun Access Manager and Sun Federation Manager). Oracle completed their acquisition of Sun Microsystems in February 2010 and announced that OpenSSO would no longer be their strategic product. OpenSSO will continue to be developed and supported by ForgeRock under the name of *OpenAM Conformance Statements 1. The NHIN CONNENT version 2.4 requirement for Apache Tomcat is met. 2. The NHIN CONNENT version 2.4 requirement for JBoss Application Server is met. 3. The NHIN CONNENT version 2.4 requirement for J2SE, Java Platform, Standard Edition is met. 4. The NHIN CONNENT version 2.4 requirement for Eclipse Open Healthcare Framework (OHF) is met. 5. The NHIN CONNENT version 2.4 requirement for GlassFish ESB v2 is met. 6. The NHIN CONNENT version 2.4 requirement for GlassFish is met. 7. The NHIN CONNENT version 2.4 requirement for OpenSSO is met Discussion The IMC is built on SampleHealth existing environment, which is specified as part of the NHIN CONNECT version 2.4; as such, this section was done in a cursory fashion as an example Platform-Specific Enterprise-Business-Viewpoint The ECCF Platform-Specific Enterprise-Business-Viewpoint defines the business and reference context. The Enterprise-Business-Viewpoint is concerned with the business or reference context, purpose and behaviors of the system as it relates to the business objective and the business processes of the organization. This viewpoint answers the question why and refers to policy. This viewpoint is primarily useful to managers, compliance staff and auditors. This Viewpoint might typically contains some combination of: Business Nodes 5/16/2010 Page 102 of 139

104 Business Rules Business Procedures Business Workflow Rules, Procedures and Industry Standards SampleHealth s Platform-Specific Views includes the following: Rules SampleHealth IMC must meet the appropriate HITEC ARRA Meaningful Use Objectives and Criteria and must use NHIN CONNECT version 2.4 services. Procedures SampleHealth IMC must present its exchange architecture interoperability specifications using the HL7 SAIF-ECCF. Industry Technology-Specific Standards SampleHealth must use the appropriate HSSP services Conformance Statements 1. Appropriate IMC HITEC meaningful use objectives and criteria are identified and satisfied. 2. The IMC exchange architecture interoperability specifications are presented, using the HL7 SAIF- ECCF. 3. IMC identifies and uses appropriate HSSP services Discussion Details will be added between May and September 2010 as the physical IMC prototype is being developed Platform-Specific Information-Viewpoint The ECCF Platform-Specific Information-Viewpoint is defined by localized information models. The Information- Viewpoint is concerned with the nature of the information handled by the system and constraints on the use and interpretation of that information. This viewpoint answers the question what and refers to information content. This viewpoint is primarily useful to information modelers. This viewpoint is primarily useful to managers, compliance staff and auditors. This Viewpoint might typically contains some combination of: Database Schemas Message Schemas Transformation Schemas See the glossary for definitions of data vs. information and data models vs. information models. A Physical Level Data Model 40 contains the same level of detail as the logical level, but has been transformed to show how the data would be stored within an information system. Information exchange structures and formats (messages) are also defined at the physical level. 40 Conceptual Health Data Model v2.3, Canadian Institute for Health Information 5/16/2010 Page 103 of 139

105 Working Draft; NOT for Public Distribution Schemas and Transformations TBD Conformance Statements TBD after architectural artifacts are completed and are sorted into the correct ECCF categories Discussion SampleHealth s Platform-Specific Viewpoint s will be added between May and September 2010, as the IMC prototype is being developed Platform-Specific Computation-Viewpoint 13. The ECCF Conceptual Computation-Viewpoint is defined by collaboration analysis (e.g., UML sequence diagrams), functional profiles, service roles and relationships. The computational viewpoint is concerned with the functional decomposition of the system into a set of components that exhibit specific behaviors and interact at interfaces. This viewpoint answers the question how and references behavioral specifications. This viewpoint is primarily useful to system integrators and solution and solution architects. This Viewpoint might typically contains some combination of: Automation Unit Technical Interfaces Technical Operations Orchestration Scripts Collaboration Scripts, Orchestration, Realized Interfaces TBD Conformance Statements 2839 TBD after architectural artifacts are completed and are sorted into the correct ECCF categories Discussion SampleHealth s Platform-Specific Viewpoints will be added between May and September 2010 as the IMC prototype is being developed Platform-Specific Engineering-Viewpoint The ECCF Platform-Specific Engineering-Viewpoint is defined by existing platform capabilities. The Engineering- Viewpoint is concerned with the mechanisms and functions required to support the interactions of the computational components. This ECCF viewpoint may overlap with the RM-ODP technology viewpoint, which is concerned with the explicit choice of technologies for the implementation of the system, and particularly for the communications among the components. This viewpoint answers the question where 5/16/2010 Page 104 of 139

106 and refers to implementation environments. This viewpoint is primarily useful to application developers. This Viewpoint might typically contains some combination of: Application Specifications GUI specifications Deployment Topology or Execution Context Platform Bindings Execution Context, Platform Bindings and Deployment SampleHealth s Platform-Specific Viewpoints will be added between May and September 2010 as the IMC prototype is being developed Systems Immunization Management deals with the following systems: Electronic Health Record (EHR) System: The Electronic Health Record (EHR) System is a secure, realtime, point-of-care, patient-centric information resource for clinicians o Supported stakeholders are: EHR System Suppliers, Healthcare Entities, Providers, (including healthcare delivery organizations, ancillary entities, clinicians pharmacy-based care delivery and immunization clinics), On-site care providers, and Schools Health Information Exchange (HIE): A Health Information Exchange (HIE) is a multi-stakeholder system that enables the exchange and use of health information, in a secure manner, for the purpose of promoting the improvement of health quality, safety and efficiency o Supported stakeholders are: EHR System Suppliers, Healthcare Entities, Providers, (including healthcare delivery organizations, ancillary entities, clinicians pharmacy-based care delivery and immunization clinics), On-site care providers, and Schools. Immunization Information System (IIS): IIS is used by local, state, and federal government organizations to identify populations at high risk for vaccine-preventable diseases and to target interventions and resources efficiently. Staff of stakeholder agencies interact with the IIS to verify and validate system indications of public health threats, and to assert acknowledgements that may be required by system processes. This includes, for instance, emergency preparedness registry, chronic disease registry o Supported stakeholders are: Geographic Health Information Exchange/Regional Health Information Organization, Point-to-Point Exchanges Personal Health Record (PHR) Systems: A healthcare record system used to create, review, annotate and maintain records by the patient or the caregiver for a patient. The PHR may include any aspect(s) of the health condition, medications, medical problems, allergies, vaccination history, visit history or communications with healthcare providers o Supported stakeholders are: Government Agencies, Healthcare Payors, Knowledge Providers, Public and Private Immunology, Vaccine Response, and Adverse Event Experts, Registries, Public Health Agencies/ Organizations (federal/state/local/territorial/tribal) Public Health Information System: An automated and integrated system used to document and address information of interest to public health. Local, state, and federal government organizations and personnel use these systems to help protect and improve the health of their respective constituents. A critical effort under this charge is collecting health information to monitor for the existence of emerging health threats appearing in the population and manage these threats once manifested. Staff of these agencies interacts with 5/16/2010 Page 105 of 139

107 the public health information system to verify and validate system indications of public health threats, and to assert acknowledgements that may be required by system processes o Supported stakeholders are: Consumers, Patients, Personal Health Record (PHR) System Suppliers Supply Chain Management System: A system used by organizations managing the distribution of supplies and the oversight of materials, information, and finances as they move in a process from supplier to manufacturer to wholesaler to retailer to consumer. For example, used to track vaccines and associated supplies o Supported stakeholders are: Government Agencies, Knowledge Providers, Public and Private Immunology, Vaccine Response, and Adverse Event Experts, Registries, Response Management Organizations, Public Health Agencies/Organizations (federal/state/local/territorial/tribal) o Public and Private Sector Supply Chain, Inventory Managers. NOTE: Varying and changing business models impact the stakeholder that serves as this business actor in any given implementation (e.g., contracted distributor, manufacturer, public health authority, Registry etc) Conformance Statements TBD after architectural artifacts are completed and are sorted into the correct ECCF categories Discussion SampleHealth s Platform-Specific Viewpoints will be added between May and September 2010 as the IMC prototype is being developed Conclusions and Lessons-Learned We believe that the resultant IMC ECCF presented above is a clear, complete, concise, correct, consistent and traceable exchange-architecture, Interoperability Specifications and Conformance Statements. The TOGAF ADM process and SAIF-ECCF structure were efficient for a distributed team to develop interoperability specifications for the IMC exchange architecture, using the EHR-SD RM. The HL7 SAIF- ECCF might be considered the skeleton of an enterprise-architecture; ECCF was demonstrated to be an effective enterprise-architecture Executive Summary. The SD RM and its artifacts are evolving with the healthcare IT domain. Using the HL7 EHR-S FM, HITSP constructs and NHIN services as a reuse starting point was key to quickly filling out the IMC ECCF. The EHR SD RM facilitated the rapid identification of reusable architectural artifacts for the baseline IMC ECCF exchange architecture. Lessons learned from this case study are applicable to other processes (e.g., Rational Unified Process) and other frameworks (e.g., Zachman, DODAF). A compelling story for the return-on-investment of SOA reuse can be told comparing: Table 10 As-Is SampleHealth Business Function Map versus Table 11 To-Be SampleHealth Business Function Map And then comparing: Figure 19 As-Is SampleHealth Information System High Level Architecture versus 5/16/2010 Page 106 of 139

108 Figure 20 To-Be SampleHealth Information System High Level Architecture Both of these pairs of as-is and to-be figures show the massive SOA reuse the IMC project benefited from; making the IMC project relatively simple compared to starting from scratch. One of the most difficult challenges facing healthcare organizations making IT investments today comes from deciding whether to go all-in with a particular vendor, or whether to self-integrate components from multiple vendors. The appeal of the single-vendor solution is strong no finger-pointing, out-of-the-box integration, [US-based] EHR certification via the Certification Commission for Healthcare IT (CCHIT), and so on. This is contrasted with seemingly increased risk and work involved in a multi-vendor solution involving integration. A multi-vendor SOA solution can offer compelling best-of-breed options; where, a SOA promotes an easier integration and alignment across suppliers into a cohesive, testable and certifiable architecture. We demonstrated an approach that can build and present consistent Interoperability Specifications (IS) and conformance criteria for both best-of-suite and best-of-breed components and their exchange architecture. Having these ISs, exchange architectures, certification criteria and associated business cases is the appropriate due diligence needed to help justify a best-of-suite vs. best-of-breed decision. The following lessons learned subsections are a living part of the document; they will periodically be reviewed and updated until the projects completion in October Immunization Management Lessons Learned 1. Updating Legacy System Standards - The HITSP selected Immunization message is HL7 v2.5. Most existing immunization repositories are using HL7 v2.31. Not only are the repositories effected; additionally, feeder and user systems are affected. In some cases, it can be difficult to justify the expense to bring legacy system to current standards. 2. Social Issues Trump Technical Issues - The Case Study shows an Immunization Management Capability technical solution; it does not address the more socially challenging Service Contract needed among stakeholders (e.g., agencies, states, hospitals). 3. Information Model - There is an implicit common information model across immunization standards, which require an explicit common information model.. 4. SOA and Cost - SOA changes the cost equation from N squared to a linear cost per interface 5. Reuse has been shown to increase quality and reduce cost. 3.2 ECCF Lessons Learned 1. An ECCF SS can be presented as an Architectural Executive Summary or Information Exchange Architecture to add value to a project. 2. A mature ECCF SS must be clear, complete, concise, correct, consistent and traceable, as a whole. ECCF documentation is misleading by saying that viewpoints must be horizontally consistent and vertically traceable. 3. ECCF Viewpoint Conformance Statements The ECCF would benefit by following the example of the EHR System Functional Model; statements, descriptions, depends on links and conformance statements for each viewpoint that is needed. Particular domains should have profiles, which subset the conformance statements to 5/16/2010 Page 107 of 139

109 be suitable for the sub domains. Similarly, the governance framework, Information Framework would also benefit from this approach. 4. The ECCF placement of architectural artifacts is not always intuitively obvious (e.g., structural specifications of modules and their information). Arguable, many of the Table 5 artifacts might be in both the Enterprise and Computational Viewpoints, such as: Functional and non-functional Requirements Stakeholders and their roles and capabilities Use Case inventory and Use Case Specifications Capabilities and their Services Component inventory Function-Service inventory Contracts and business rules Strict viewpoint traceability would require all of the above artifacts being in the Computational Viewpoint. 5. The placement of traditional architectural artifacts (e.g., Text, Figures, Tables, BPMN and UML diagrams) into a particular ECCF viewpoint and layer is NOT prescribed by SAIF; placement is not always obvious (e.g., where do Use Case derived Information Exchange Requirements (IERs) go?). The general placement criteria used was first, the artifact intuitively fits best into a particular ECCF viewpoint-layer and second, presenting the architecture breadth-first, from beginning to end, flows and makes sense to an educated but uninformed audience. 6. Architectural artifact granularity may not match ECCF categories (e, g,. component data and functions) 7. A value set of architectural artifacts, clear definitions and model is needed. Because of ambiguity, some architectural artifacts are listed in multiple cells having different purpose and contents in the respective cells (e.g., business vs. requirements level and design level capability and contracts). 8. Within the ECCF, Function and Service mean the same thing, considering that the difference between a well specified function and a service is that a service is public, reusable and has an associated Service Agreement or contract also known as a Distributed User Resource Sharing Agreement (DURSA). 9. SAIF-ECCF conformance statements can be at a high abstract level; but, this adds the responsibility that the conformance tester is provided a detailed traceability matrix, detailed test specifications/ procedures to insure that all the appropriate architectural specifications are verifiable and certification results can be audited. 10. This document shows an Immunization Management Capability technical solution; it does not address the challenge of the stakeholder Service Contract (e.g., among agencies, states, hospitals). 11. Normally, architectures are presented as a set of documents, where a reader selects one-or-more viewpoint documents that are of interest. Presenting an single ECCF architectural executive summary document proved to be intimidating to some readers, who are not used to looking at an architecture as a whole. Readers, who didn t know where to start needed a verbal architectural walk-through before they felt comfortable working on their own. 12. Inventory of Architectural Artifacts - Table 13 HL7 SAIF Enterprise Conformance and Compliance Framework (ECCF) shows the sparsely populated set of architectural artifacts given in the ECCF documentation; it should be compared to the resultant densely populated Table 5 Notional Set of Architectural Artifacts within the HL7 SAIF ECCF SS. 5/16/2010 Page 108 of 139

110 Filling out the conceptual and platform-independent layers of the ECCF, was relatively quick, thanks to the reuse of the artifacts identified by the EHR SD RM. Our IMC ECCF was easy to fill out, except for the Computation-Viewpoint. The Enterprise Business Viewpoint was intuitive to fill out. The Information Viewpoint was intuitive to fill out. The Computation-Viewpoint was difficult to determine where structural specifications, which show the encapsulation of information with functions to define components and capabilities. The Engineering Viewpoint was intuitive to fill out; but, it was not obvious the distinction between the conceptual and platform-independent layers because we do not have a reference architecture for the engineering view. Using the ECCF to present an exchange architecture and its conformance statements as an enterprise architecture Executive Summary proved to be effective; we presented the ECCF breadth-first across the viewpoints of each layer; we first presented the conceptual, then platform-independent and finally platform-dependent layers and their respective viewpoints. 3.3 SOA Lessons Learner 1. Reuse of legacy services can make a project significantly faster, better and cheaper; but, managing the reuse library of candidate services and their specifications can be challenging. Specifically, funding and policies must be provided to manage, publish and mandate the use of the Reusable Components and Services. It is easy for each project to create stovepipe services without harmonizing and reusing services across an enterprise. 2. Functions and Services differ by a Service Level Agreement and the documented specificity of a service interoperability specification. 3.4 TOGAF ADM Lessons Learned 1. As the TOGAF ADM implies, requirements, conformance statements, test specifications and risks should be managed/ governed throughout the Business Capability, Architecture and Software Development Lifecycles, as they evolve. 2. Methodologies must be adaptable to suite the needs of projects. In our case, we augmented HL7 SAIF with TOGAF ADM, DOD Instruction acquisition processes (e.g., governance) and HITSP s TN903 Data Architecture (e.g., Clinical Information Model). 3. TOGAF ADM initially led the project team to organize the architectural artifacts chronologically, in the order they were developed; not SAIF-ECCF organized, as they are needed for architectural reviews and analysis. We reorganized the artifacts for ECCF presentation and we moved the TOGAF overview to the appendix. This resulted in some rework; but, this pitfall is easily avoidable in the future. 4 Acronym List B2B: Business-to-Business BPMN: Business Process Management Notation BPEL: Business Process Execution Language 5/16/2010 Page 109 of 139

111 CCD: Continuity of Care Document CDA: Clinical Document Architecture. CCR: Continuity of Care Record CM: Configuration Management CRFQ: Clinical Research Filtered Query CTS/CTS2: Common Terminology Service DSS: Decision Support Service EA: Enterprise Architecture ED: Emergency Department EHR: Electronic Health Record EIS: Entity Identification Service ESB: Enterprise Service Bus HL7: Health Level Seven HSD: Human Services Directory HSSP: Healthcare Services Specification Project OMG: Object Management Group PASS: Privacy, Access, Security Services RLUS: Retrieve, Locate, Update Service SOA: Service-oriented Architecture 5 Glossary A glossary of architectural terms is provided in Section Following is the glossary for the main body of the document. TBD 6 References 7 Appendix TBD 7.1 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) Health Information Technology Standards Panel (HITSP) Certification Commission for Health Information Technology (CCHIT) National Information Exchange Model (NIEM) Nationwide Health Information Network (NHIN) /16/2010 Page 110 of 139

112 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 Background The EHR-SD RM prototype example is based on HL7-OMG HSSP, HL7 EHR-S FM, HL7 RIM, HL7 SAIF, HITSP and IHE artifacts Service Oriented Architecture (SOA) This section is based on Thomas Erl s SOA Principles of Service Design July 28, 2007, Prentice Hall. SOA is A technology architecture Design Paradigm which can be applied in the context of Distributed Computing which collectively expresses a set of core Design Principles which collectively realize a set of Design Characteristics? -- [Thomas Erl, SOA Principles of Service Design. ] Semantics are critical to interoperability in the domain of healthcare, which often requires computable semantic interoperability. SOA Strategic Goals [Thomas Erl] are: Intrinsic Interoperability Interoperability vs. Integration Increased Federation Common endpoint and local governance Increased business/technology alignment Linear degree of difficulty for change Increased vendor neutrality options Specifications at a logical level (ECCF PIM) SOA Strategic Benefits are: Increased ROI Reuse vs inconsistent Redundancy Applications as compositional aggregations Increased Organizational Agility Business evolution aligned with technology flexibility Reduced IT footprint Elimination of redundancy and inconsistency Elimination of one-off integration activities Decreased governance burden 5/16/2010 Page 111 of 139

113 SOA Design Principles are: Standardized Service Contracts Service Loose Coupling Service Abstraction Service Reusability Service Autonomy Service Statelessness Service Discoverability Service Composability Standard Service Contracts Service Loose Coupling Service Abstraction Service Reusability Service Autonomy Service Statelessness Service Discoverability Service Composability Intrinsic Interoperability Increased Federation Increased Business/Technology Alignment Increased Vendor Diversification Options Increased ROI Increased Organizational Agility Decreased IT Burden X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X Table 12 Design Principles vs. Strategic Goals and Benefits SOA Challenges are: increased design complexity need for Design Standards (informational, behavioral) top-down delivery requirements counter-agile (contract-first) design/delivery governance requirements SOA Benefits are: Advantages gained from SOA: users will realize benefits from the solution to each aspect of the Problem Statement: focus on business capabilities increased agility fine-grained certification increased predictability and reliability automated certification increased responsiveness to change and evolution of software components technology-independent specifications increased vendor participation and cross-vendor interoperability Road Map to ssoa via SAIF/ECCF: 5/16/2010 Page 112 of 139

114 Some things will evolve: Static data, metadata, terminology representations, and tooling Application development from monolithic to service composition Increased emphasis on enterprise architecture Increased emphasis on Continuous Integration Some things will be new: Behavioral metadata that is defined and captured Artifacts that define ECCF Specification Stack instances Increased emphasis on automated testing/certification Tooling to support new data/metadata and processes Focus on software contracts as basis for Computable Semantic Interoperability (CSI) Formal requirements traceability Formal project and architecture governance Some aspects of software engineering process Some aspects of contracts for development organizations EHR System Functional Model (EHR-S FM) HL7 traditionally develops standards around messaging and interoperability. However, in July 2003 it collaborated with public and private healthcare leaders to develop the EHR functional standard. In May 2004 Health Level Seven (HL7), an ANSI-accredited designated standards organization, announced passage of the electronic health record system (EHR-S) draft standard for trial use (DSTU). In 2007 Electronic Health Record System Functional Model became a Normative Standard (ANSI-approved). This draft standard summarizes the functions that may be present in an EHR system and provides a common language for communicating its behaviors and capabilities. The EHR-S FM s scope is limited to functionality and does not address data content for the EHR or endorse the use of specific technology. An EHR-S could be one system with applicable functionality in the EHR-S FM standard, or it could be a variety of interoperable systems that combine to meet the functionality of the EHR-S FM. An EHR is the data content contained within the EHR system. 5/16/2010 Page 113 of 139

115 Figure 32 HL7 EHR System Functional Model (EHR-S FM) Figure 32 HL7 EHR System Functional Model (EHR-S FM) shows the EHR-S FM structure, which contains more than 160 hierarchically categorized functions. They are broken into three main sections: Direct care Supportive Information infrastructure Each function is assigned an ID and includes a title, a short statement, and a longer narrative describing the functionality. The example below illustrates the format of the EHR-S functional model EDITORS NOTE: use DC1.8.2 Immunization Management example here, rather than DC /16/2010 Page 114 of 139

116 ID Title Statement Description See Also DC Produce a Summary Record of Care Present a summarized review of a patient's comprehensive EHR, subject to jurisdictional laws and organizational policies related to privacy and confidentiality. Create summary views and reports at the conclusion of an episode of care. Create service reports at the completion of an episode of care such as, but not limited to, discharge summaries and public health reports, without additional input from clinicians. S IN.1.9 IN.2.4 IN IN Each system function may also indicate dependencies on other functions ( see also ) and conformance criteria, such as: DC Conformance Criteria: 1. The system SHALL present summarized views and reports of the patient s comprehensive EHR. 2. The system SHOULD include at least the following in the summary: problem list, medication list, allergy and adverse reaction list. 3. The system SHOULD conform to function S (Health Service Reports at the Conclusion of an Episode of Care). 4. The system SHOULD conform to function IN.1.4 (Patient Access Management). 5. The system SHALL conform to function IN.2.2 (Auditable Records). For a particular function, the conformance criteria should be collected across all of its dependencies, resulting in a comprehensive set of functional requirements and test specifications. Functions are outlined in a hierarchical manner; for example: DC.1.2 Care plans, guidelines, and protocols (This is the parent function. Additional related functions are listed below as children. ) DC Present care plans, guidelines, and protocols (child function) DC Manage guidelines, protocols, and patient-specific care plans (child function) DC Generate and record patient-specific instructions (child function) The direct care section of the functional model addresses functionality related to the care delivery process under three main headings: DC.1 Care Management DC.2 Clinical Decision Support DC.3 Operations Management and Communication The direct care section is comprised of parent functions, with children functions that provide more detail and granularity. The table identifies the main functions and then summarizes the functionality within the section. 5/16/2010 Page 115 of 139

117 The supportive section of the EHR-S FM addresses functionality related to administrative and financial requirements associated with care delivery. It includes support for medical research, public health, and quality improvement. There are three main sections: S.1 Clinical Support S.2 Measurement, Analysis, Research, Reporting S.3 Administrative and Financial Most, but not all, of the functions in the supportive section have both parent and child sub-functions. The information infrastructure section of the EHR-S FM addresses functionality related to technical capabilities that are essential to support operations and the direct care functions. There are seven main sections: I.1 EHR Security I.2 EHR Information and Records Management I.3 Unique Identity, Registry, and Directory Services I.4 Support for Health Informatics and Terminology Standards I.5 Interoperability I.6 Manage Business Rules I.7 Workflow Most of the functions in the seven sections include both parent and child functions Healthcare SOA Reference Architecture (H-SOA-RA) In 2008, the Figure 33 Healthcare SOA Reference Architecture (H-SOA-RA) based on the Figure 32 HL7 EHR System Functional Model (EHR-S FM) and the ISO layers [ISO/IEC Information technology Open Systems Interconnection Basic Reference Model: The Basic Model]. The H-SOA-RA supports a structured reuse-based approach to architectural specifications within the healthcare domain and across domains, which intersect the healthcare domain (e.g., emergency responder). It also provides a common vocabulary, to discuss requirements traceability to design specifications, to implementations, to deployments, to tests and to certifications; with the aim to encourage lexical and semantic consistency throughout the Business Capability Lifecycle (BCL). The Healthcare SOA Reference Architecture (H-SOA-RA), was built on commercial healthcare models (e.g., HL7 EHR System Functional Model (EHR-S)) and ISO based SOA layers [SOA Principles of Service Design by Thomas Erl 2007]. The objective of the H-SOA-RA is to assure semantic interoperability at the Service Level and consistency within and among systems architectural interoperability specifications, resulting in aligned, interoperable and agile enterprise architectures and their system components. The H-SOA-RA allows logical specifications of business transformation architectures and their associated investment portfolios; it allows system component flexibility/options in the ultimate physical best-of-breed component implementations. 5/16/2010 Page 116 of 139

118 Figure 33 Healthcare SOA Reference Architecture (H-SOA-RA) The H-SOA-RA is intended to support the transformation of a behavior model s systems and their capabilities (e.g., business process model or use case) into system structural models of components and their interfaces (e.g., system functions and services). In particular the H-SOA-RA focuses on constructing system components from candidate reusable services (e.g., composite services, entity services, application services, agnostic or common services.). Healthcare Information Technology Standards Panel (HITSP) constructs (e.g., data components, transaction packages, transactions and their associated standards specifications) provide architectural constraints, which are intended to assure Electronic Healthcare Record (EHR) interoperability Reference Information Model (RIM) The purpose of a Reference Information Model is to share consistent meaning beyond a local context. In general, the broader the scope of interest, the more important it is to make all assumptions about a topic of interest explicit. The HL7 Version 3 Reference Information Model (RIM) is a comprehensive source of all information subjects used in any HL7 specification. Since HL7 specifications permit loosely coupled information systems to interoperate, the scope of the HL7 RIM is the information required to be understood between information systems, but not necessarily all information recorded within any particular system. As HL7 specifications are used to connect information systems operated in different circumstances, across many types of healthcare delivery organizations and potentially across political 5/16/2010 Page 117 of 139

119 jurisdictions, the HL7 RIM needs to be flexible enough to express a diverse range of information content while maintaining a unified framework. The Version 3 RIM articulates explicit definitions of the things of interest referenced in HL7 messages, structured documents or any future HL7 "information packages" specification. The RIM also contains definitions of the characteristics of these things of interest and the relationships among them Figure 34 HL7 Reference Information Model (RIM) The Reference Information Model is expressed using a modified object notation similar to that used in UML. The RIM is graphically presented as a network of classes containing their attributes and connected by their associations. Behind the graph are the details of all the definitions, connections and constraints. All information about the RIM is held in a repository that contains the details, the connections among the details and the changes over time. The HL7 RIM is not a model of a database, or any particular vendor's information system, or any particular healthcare organization enterprise, or even any particular set of messages. Any of these specific contexts may have an information model of their own and can use a similar form of notation Federal Health Information Model (FHIM) The Federal Health Architecture (FHA) sponsored Federal Health Information Model (FHIM) work group directs and coordinates federal engagement in health IT SDOs and other IT standards related organizations. The goal of the work group is to enable health information interoperability by participating in the development and implementation of a comprehensive, integrated health information model and set of standards that support the semantic interoperability requirements of ARRA. 5/16/2010 Page 118 of 139

120 The HL7 Reference Information Model (RIM) is leveraged as a reference model for the FHIM The FHIM is a comprehensive, integrated, logical, health information model and associated terminology models. The FHIM includes the HITSP/ TN903 Data Architecture To support the exchange of health information between Federal partners To standardize the exchange of health information between Federal partners and their commercial partners as NIEM IEPDs. Supports the consolidation of information exchange formats from the existing (and expanding) 8-9 to 3 or possibly even 1 in the long-term Enables implementation of Service Oriented Architectures by Federal partners Reduces the amount of mapping between different information concepts, information attributes and terminologies/code sets that Federal partners must currently support Identifies terminology and code set requirements that have not yet been addressed Improves harmonization of information concepts and attributes across standards development organizations The FHIM supports health interoperability, especially semantic interoperability As the basis for work between Federal partners and standards related organizations to enhance existing or develop new standards As the basis for defining information requirements for inclusion in vendor contracts As the basis for defining information requirements for in-house developed applications and databases, especially in organizations implementing model-driven architectures As a component of the Data Use and Reciprocal Support Agreement (DURSA) among trading partners and their service contracts The FHIM is built by harmonizing information from the individual Federal partners and from standards organizations. The FHIM has the potential to become the Federal Health Architecture information model for NIEM and NHIN. 5/16/2010 Page 119 of 139

121 Figure 35 FHIM relationship to NIEM Healthcare Service Specification Project (HSSP) The Healthcare Services Specification Project (HSSP) project is a collaborative effort between Health Level Seven [ and the Object Management Group [ to address interoperability challenges within the healthcare sector and to identify and document service specifications, functionality, and conformance resulting in real-world implementations. The following Candidate HSSP Services will be considered within this interoperability specification: CTS2 (Common Terminology Services 2) CTS 2 is a standard for terminology services that enhances the capabilities of the initial CTS specification for sub-setting and mapping, and extends the specification into domains such as terminology distribution, versioning, and classification. DSS (Decision Support Service) A commonly accepted standard for the DSS would make it more attractive for service consumers to invest in the infrastructure required for using the DSS to meet its patient evaluation needs, as they would be able to use the same interface to interact with multiple service vendors. HCPDS (Healthcare Provider and Services Directory Service) HCPDS is required to provide an online facility that will enable Practitioners, via a set of parameters, to locate other practitioners, to assist in the continuum of care. IXS (Identity Cross-Reference Service, formerly known as Entity Identification Service) Normative In balloting to become a full HL7 standard. 5/16/2010 Page 120 of 139

122 PASS (Privacy, Access and Security Services) The goal of PASS is to define a suite of services that will provide a simple interface for all privacy, access control, consent, identity management and other security services that are needed in a service-oriented health information architecture. RLUS (Retrieve, Locate and Update Service) and EIS (Entity Identification Service) The HL7 SFM has been approved by the HL7 Board as an official DSTU Service Aware Interoperability Framework (SAIF) The collective work of the HL7 Architecture Board (ArB) is called the HL7 Services-Aware Interoperability Framework (HL7 SAIF 41 ). We note that SAIF is NOT an enterprise architectural framework; but rather, SAIF is an interoperability framework. The goal of SAIF is to ensure interoperability among various healthcare organizations. Medical and healthcare organizations using different technologies, software, and business structures need a common framework for sharing documents, messages, and services with other organizations. An example of a document might be an invoice or a doctor's report. An example of a service might be a request for a lab order or a patient's longitudinal health record. Often these organizations are unable to share the information because the different systems do not interoperate with each other, which may likely increase delays and expenses. For a long time, HL7 has been developing specifications, methodologies, and extensible standards for making healthcare systems interoperable. HL7 collaborates with healthcare information users and other Standards Development Organizations, and enables domain experts from the healthcare industry to develop healthcare information standards in their areas of expertise. SAIF seeks to meet this need by providing a framework for ensuring interoperability for documents, messages, and services between organizations. SAIF is designed not only to craft software components -- messages, computable documents, services, and applications -- that are usable in the healthcare, life sciences, and clinical research domains, but also to facilitate and enable efficient lines of communications between the various cross-functional teams. The SAIF satisfies the following principles/ criteria: Applies to each of HL7's three interoperability paradigms (IPs): messages, documents, and services. Provides support for measurable conformance and compliance. Defines appropriate governance structures and processes. Provides support for directly implementable solutions. Addresses the growing disparity between the various solution sets emerging from HL7 Uses existing HL7 V3 and Reference Information Model (RIM) artifacts and expertise to the maximum degree possible. SAIF consists of four core components: Enterprise Conformance and Compliance Framework (ECCF) Governance Framework (GF) Behavioral Framework (BF) Information Framework (IF) Together, these sub-frameworks provide an overarching framework for specifying (and governing the specification of) the set of artifacts that enables HL7 to develop specifications which support Working Interoperability (WI) /16/2010 Page 121 of 139

123 among parties using HL7 specifications, either alone, or with other specifications that other organizations have developed. The ECCF, shown in Table 13 below, shows a prototypic ECCF specification stack (SS) template with example artifacts in each cell. It is based on the ISO Reference Model of the Open Distributed Processing (RMODP) and extends the historical work within HL7 on conformance. The BF formalizes and extends the constructs of the HL7 Dynamic module to include explicit semantics around contracts and integration. The IF is an extension of the HL7 Reference Information Model (RIM), shown in Figure 34 above Table 13 HL7 SAIF Enterprise Conformance and Compliance Framework (ECCF) Integrating the Healthcare Enterprise (IHE) Integrating the Healthcare Enterprise (IHE) is an initiative by healthcare professionals and industry to improve the way computer systems in healthcare share information. IHE promotes the coordinated use of established standards such as DICOM and HL7 to address specific clinical needs in support of optimal patient care. Systems developed in accordance with IHE communicate with one another better, are easier to implement, and enable care providers to use information more effectively. IHE brings together users and developers of healthcare information technology (HIT) in an annually recurring fourstep process: 1. Clinical and technical experts define critical use cases for information sharing. 5/16/2010 Page 122 of 139

124 Technical experts create detailed specifications for communication among systems to address these use cases, selecting and optimizing established standards. 3. Industry implements these specifications called IHE Profiles in HIT systems. 4. IHE tests vendors systems at carefully planned and supervised events called Connectathons EHR System Design Reference Model (EHR-SD RM) HL7 EHR System Design Reference Model (EHR-SD RM) 42 project expands the H-SOA RA; but still starts with the EHR System Functional Model (EHR-S FM). Emphasis is placed on mapping to ARRA HITECH standards and meaningful use measures, HITSP ISs, NIEM IEPDs, and CCHIT conformance criteria Figure 36 EHR-SD RM Leveraging Standards Related Organizations To Get the Right Information to the Right Analyst at the Right Time Reference architectures generally have lists of: 1) System Functions or Services (aka, methods), 2) Reusable components composed of one or more encapsulated objects and 3) Policies, standards and constraints. In a constrained system design (e.g., net-centric 43 Service Oriented Architecture (SOA)), reference architectures can be used to allocate capabilities and their system functions to system components, while maintaining architectural constraints, resulting in a design baseline. Reference architectures can be defined at different levels of abstraction: A deployment reference-architecture might show different pieces of equipment on a communications network, each component providing gross functionality (e.g., Application Server, Database Server, Master Patient Index, etc.). A business reference-architecture decomposes business-process views, which show persons, organizations and systems; it includes the information exchanges within and among business processes. Our approach is to have the H-SOA-RA constrain the functions, which are allocated to systems. An inheritance reference-architecture might include functions, which can be constructed into system components. Federal Agencies are mandated to have Healthcare Information Technology Standards Panel (HITSP) conformant interoperable Electronic Healthcare Records (EHR) and systems. Our strategy is to focus on HITSP conformant interoperability at the service level. 42 Additional information is available at 43 Netcentric, or "network-centric", refers to participating as a part of a continuously-evolving, complex community of people, devices, information and services interconnected by a communications network to optimize resource management and provide superior information on events and conditions needed to empower decision makers. 5/16/2010 Page 123 of 139

125 class EHR SD RM EHR Business Architecture Functional Analysis Object Analysis EHR-S FM + Direct Care + Supportive Care + Information Infrastructure Functional Requirements Use Case Behavioral Model + scenario Reference Information Model (RIM) + Entity + Role + Act + Participation + Act relationship + Role relationship Information Exchange Requirement (IER) + Systems + Exchange Content + Exchange Action + Exchange Attribute ARRA Meaningful Use Measure + Stakeholder Clinical Document Architecture (CDA) Federal Health Information Model (FHIM) Agency Information Model Legend requirements design ARRA is American Recovery and Reinvestment Act of 2009 FHIM is Federal Health Information Model EHR-S FM is EHR System Functional-Model EHR SD RM is EHR System Design Reference-Model NIEM IEPD is National Information Exchange Model (NIEM) Information Exchange Package Documentation (IEPD) An EHR Business Architecture (BA) can be modeled as a Functional Model, which is a set of direct care, supportive care and information infrastructure system functions defined by the HL7 EHR System Functional Model (EHR-S FM) and Information Model, which is a set of entities, roles and role relationships participating in actions and action relationships. Set of Information Exchanges, which define the associations between the Information and Functional Models Certification Criteria + Capability ARRA Selected Standard Constructs + Component (C) + Transaction (T) + Transaction Package (TP) + Service Collaboration (SC) Capability Requirements + Information Exchange + option + Scenario + system role + conditions + optionality + system role Capability Design Interface Service realize is-a NIEM IEPD Service Taxonomy SOA Layers SOA Analysis + Business Processes + Composite Services + Core Business Services + Component Services + Operational Services + Implementation Profiles NHIN Connect Service A HITSP Capability (CAP) specifies interfaces for a set of information exchanges, grouped by system role (e.g., Lab Order Prescriber, Lab Order Filler, Specimen Collector). A HITSP Conformant System implements the system role interfaces for the Information Exchange Requirements supported by the capability. Realize relationship: a source object implements or Realizes its destination object. Realize connectors are used to express traceability and completeness in the model. Functions vs. Services differ in that a services enforces encapsulation (e.g., information hiding), have associated governance and Distributed User Resource Sharing Agreements (DURSAs), which define the business rules for a services' information exchanges. Figure 37 Conceptual View of the HL7 EHR System Design Reference Model Figure 37 Conceptual View of the HL7 EHR System Design Reference Model shows how a user can start with functions (EHR-S FM) or data (e.g., RIM), requirements and behavioral specifications (e.g., use cases) to define capabilities and information exchanges, which can be allocated to systems and their standards-based interfaces,; the interoperable interfaces can be implemented as services EHR-SD RM within the Requirements Management and Architecture Cycle The EHR-SD RM supports the requirements, specifications, design and test processes as is shown in Figure 38 Stakeholder Requirements answer the questions WHAT is the system supposed to do? WHERE will the products of the system be used? Under what conditions are the products used? How often does the system produce its products? How long does it take to produce the products? Who will use the products of the system? Requirements Analysis answers the questions HOW, using Action Verbs. In this step we analyze functions and Services by decomposing higher level functions to lower level functions and Allocating performance requirements to the functions. Architecture Design answers the questions of WHICH hardware and software elements define the physical architecture, WHERE each part must perform at least one function and some parts may perform more than one function. Test Specifications answer the question of HOW Requirements-Specifications are validated. 5/16/2010 Page 124 of 139

126 The Requirements Loop ensures that all requirements are covered by at least one function and it ensures that all functions are justified by a valid requirement (no unnecessary duplication). The Design Loop ensures that all functions are covered by at least one hardware or software element and it also ensures that all elements of the physical architecture are justified by a valid functional requirement (no unnecessary duplication). The Verification & Validation (V&V) Loop verifies that that the solution meets the requirements and validates that the solution meets the user s needs and expectations. Note that V&V can be accomplished by: Inspection, Analysis, Demonstration or Test. The Test Loop ensures that all information is covered by test specifications and it also ensures that all interfaces are covered by test specifications Figure 38 EHR-SD RM Supporting Requirements and Architecture Processes Health Information Technology Standards Panel (HITSP) The Healthcare Information Technology Standards Panel (HITSP) was a cooperative partnership between the public and private sectors from December 2005 through 30 April The Panel was formed for the purpose of harmonizing and integrating standards that will meet clinical and business needs for sharing information among organizations and systems. The Figure 39 HITSP Harmonization Process was defined to transform interoperability requirements into an Interoperability Specification (IS) and related artifacts (called constructs) that were collectively called an IS Package as shown in Figure 40. In HITSP, an IS assembles constructs to define the secure message, document and service infrastructure (transport together with secure and private transport mechanisms), information content, vocabulary, 5/16/2010 Page 125 of 139

127 and constraints for each Information Exchange (IE) needed to address an interoperable business need and use case that articulated the requirements to reorganize its specifications to more clearly portray how they addressed HITECH requirements. The HITSP Data Architecture, Service Collaborations, and Capabilities were established as part of the effort to match HITSP results to HITECH, simplify reuse, and more rigorously separate transport and content. The Data Architecture organizes the data dictionary, vocabulary, and constraints (value sets and templates). Service Collaborations assembled HITSP constructs into secure infrastructure definitions. Capabilities addressed reusable business process chunks (such as patient registration), using Service Collaborations to specify the secure infrastructure and components to specify the information content. Figure 41 Fundamental Interoperability Relationships depicts the interrelationships of the requirements and design sections of the IS. Stakeholders Information Exchange Requirements (IERs) are met with System software Capabilities (CAP), which group the IERs into System Roles and their standards-based interface design specifications Figure 39 HITSP Harmonization Process Figure 40 HITSP Document Architecture Figure 40 HITSP Document Architecture portrays the HITSP constructs that were used to address a use case. Built on base (e.g. HL7, SNOMED-CT) and composite standards (e.g. IHE Integration Profiles), HITSP components defined the information content, while transactions and transaction packages defined the transport as well as security and privacy mechanisms. In response to HITECH, ONC asked HITSP to reorganize its specifications to more clearly portray how they addressed HITECH requirements. The HITSP Data Architecture, Service Collaborations, and Capabilities were established as part of the effort to match HITSP results to HITECH, simplify reuse, and more rigorously separate transport and content. The Data Architecture organized the data dictionary, vocabulary, and constraints (value sets and templates). Service Collaborations assembled HITSP constructs into secure infrastructure definitions. Capabilities addressed reusable business process chunks (such as patient registration), using Service Collaborations to specify the secure infrastructure and components to specify the information content. Figure 41 Fundamental Interoperability Relationships depicts the interrelationships of the 5/16/2010 Page 126 of 139

128 requirements and design sections of the IS. Stakeholders Information Exchange Requirements (IERs) are met with System software Capabilities (CAP), which group the IERs into System Roles and their standards-based interface design specifications Figure 41 Fundamental Interoperability Relationships Certification Commission for Health Information Technology (CCHIT) Improvements in quality, safety, efficiency and access, which are key goals in today s national dialog on health reform, are also the goals which drive the Certification Commission for Health Information Technology (CCHIT ), a nonprofit, 501(c)3 organization with the public mission of accelerating the adoption of health IT. Founded in 2004, and certifying electronic health records (EHRs) since 2006, the Commission established the first comprehensive, practical definition of what capabilities were needed in these systems. The certification criteria were developed through a voluntary, consensus-based process engaging diverse stakeholders, and the Certification Commission was officially recognized by the federal government as a certifying body. Uptake by the health IT industry was rapid, with more than 200 EHR products certified by mid-2009, representing over 75% of the marketplace. Provider organizations endorsed the work as well. Based on this broad acceptance, healthcare payers and purchasers in the government and private sectors began offering incentives to providers for adopting certified EHR technology. In February 2009, Congress acknowledged the value of certification in the language of the American Recovery and Reinvestment Act (ARRA) aimed at stimulating the nation s economy. The law offers a multi-year series of incentive payments to providers and hospitals for the meaningful use of certified EHR technology. The total amount of payments has been projected by the Congressional Budget Office at $34 billion. Anticipating a massive response to the new incentives, CCHIT has broadened access to certification, offering three paths to certification instead of just one. The new paths are intended to bring wider availability of EHR technologies, stimulate innovation, and address the needs of providers and hospitals at varying stages of technology adoption readiness. They are: CCHIT Certified, an independently developed certification that includes a rigorous inspection of an EHR s integrated functionality, interoperability and security. Products that are CCHIT Certified are tested against criteria developed by the Commission s broadly representative, expert work groups. This program is 5/16/2010 Page 127 of 139

129 intended to serve health care providers looking for maximal assurance that a product will meet their complex needs. As part of this independent evaluation, successful use is verified at live sites and product usability is rated. Preliminary ARRA, a certification program that tests Complete EHRs or EHR Modules against the Meaningful Use Stage 1 certification criteria in the Interim Final Rule (IFR) issued by the Office of the National Coordinator (ONC), US Department of Health and Human Services (HHS) in January The Preliminary ARRA program is designed to demonstrate that a vendor s product is extremely well prepared to be certified once ONC-accredited testing and certification becomes available, but the final criteria and test procedures are not yet available, nor has CCHIT been accredited yet by ONC. When those events occur, CCHIT will replace the Preliminary ARRA program with a final, ONC-accredited ARRA certification program. In addition to these product certifications, later this year, CCHIT has plans to offer a Site certification - a simplified, low cost certification for sites or organizations. Technology must meet minimum federal standards requirements once they are finalized. This program allows providers and hospitals who develop or assemble EHR technologies themselves to qualify for ARRA incentives, offering an open door to encourage continued innovation National Information Exchange Model (NIEM) NIEM, the National Information Exchange Model, is a partnership of the U.S. Department of Justice and the Department of Homeland Security. It is designed to develop, disseminate and support enterprise-wide information exchange standards and processes that can enable jurisdictions to effectively share critical information in emergency situations, as well as support the day-to-day operations of agencies throughout the nation. NIEM enables information sharing, focusing on information exchanged among organizations as part of their current or intended business practices. The NIEM exchange development methodology results in a common semantic understanding among participating organizations and data formatted in a semantically consistent manner. NIEM will standardize content (actual data exchange standards), provide tools, and managed processes. NIEM builds on the demonstrated success of the Global Justice XML Data Model. Stakeholders from relevant communities work together to define critical exchanges, leveraging the successful work of the Global Justice XML Data Model (GJXDM) Today, the NIEM domain does not include healthcare; but, the HHS Office of the National Coordinator (ONC) plans to leverage many of the existing tools and resources from the National Information Exchange Model (NIEM) and develop a NIEM-like process for the health care domain. Leveraging the tools and resources available in the NIEM process will help each new use case to build on previous use cases and relevant standards as well as help build the repository for all stakeholders. 5/16/2010 Page 128 of 139

130 Figure 42 ONC Standards and Interoperability Framework Process Figure 42 shows the proposed HHS process to develop NIEM compliant Information Exchange Package documents. Through this process ONC would like to develop not only data interchange specifications, but also continue to develop HITSP like software specifications to support the exchange of data within NHIN. The software functionality does not currently exist in the NIEM toolset, and therefore, it will be necessary to extend NIEM tools to include needed resources. Investments in developing the tools to support this process will help streamline the standards development processes, and aid in the maintenance and use of the data and application standards developed in these activities Nationwide Health Information Network (NHIN) The Nationwide Health Information Network is a set of standards, services and policies that enable secure health information exchange over the Internet. Several Federal agencies and healthcare organizations are already using NHIN technology to exchange information amongst themselves and their partners. The NHIN will provide a foundation for the exchange of health IT across diverse entities, within communities and across the country, helping to achieve the goals of the HITECH Act. This critical part of the national health IT agenda will enable health information to follow the consumer, be available for clinical decision making, and support appropriate use of healthcare information beyond direct patient care so as to improve population health. The NHIN Work Group, part of the Health IT Policy Committee, is currently developing recommendations for extending the secure exchange of health information using NHIN standards, services and policies to the broadest audience possible. Activities of the NHIN Work Group and Health IT Policy Committee can be found at NHIN CONNECT CONNECT is an open source software solution that supports health information exchange both locally and at the national level. CONNECT uses Nationwide Health Information Network (NHIN) standards and governance to make sure that health information exchanges are compatible with other exchanges being set up throughout the country. This software solution was initially developed by federal agencies to support their health-related missions, but it is now available to all organizations and can be used to help set up health information exchanges and share data using nationally-recognized interoperability standards. CONNECT can be used to: 5/16/2010 Page 129 of 139

131 Set up a health information exchange within an organization Tie a health information exchange into a regional network of health information exchanges Tie a health information exchange into the NHIN By advancing the adoption of interoperable health IT systems and health information exchanges, the country will better be able to achieve the goal of making sure all citizens have electronic health records by Health data will be able to follow a patient across the street or across the country. Three primary elements make up the CONNECT solution: The Core Services Gateway provides the ability to locate patients at other organizations, request and receive documents associated with the patient, and record these transactions for subsequent auditing by patients and others. Other features include mechanisms for authenticating network participants, formulating and evaluating authorizations for the release of medical information, and honoring consumer preferences for sharing their information. The NHIN Interface specifications are implemented within this component. The Enterprise Service Components provide default implementations of many critical enterprise components required to support electronic health information exchange, including a Master Patient Index (MPI), XDS.b Document Registry and Repository, Authorization Policy Engine, Consumer Preferences Manager, HIPAA-compliant Audit Log and others. Implementers of CONNECT are free to adopt the components or use their own existing software for these purposes. The Universal Client Framework contains a set of applications that can be adapted to quickly create an edge system, and be used as a reference system, and/or can be used as a test and demonstration system for the gateway solution. This makes it possible to innovate on top of the existing CONNECT platform NHIN Direct Based on initial recommendations from the NHIN Work Group, a new initiative, the NHIN Direct Project, was launched to explore the NHIN standards and services required to enable secure health information exchange at a more local and less complex level, such as a primary care provider sending a referral or care summary to a local specialist electronically. NHIN Direct is a project to expand the standards and service definitions that, with a policy framework, constitute the NHIN. Those standards and services will allow organizations to deliver simple, direct, secure and scalable transport of health information over the Internet between known participants in support of Stage 1 meaningful use. The key deliverables of the project will be standards and service definitions, implementation guides, reference implementations, and associated testing frameworks. The project will not run health information exchange services. This project will expand the standards and service descriptions available to the NHIN to address the key Stage 1 requirements for meaningful use, and provide an easy "on-ramp" for a wide set of providers and organizations looking to adopt. At the conclusion of this project, there will be one nationwide exchange, consisting of the organizations that have come together in a common policy framework to implement the standards and services Universal Immunization Tracking System (UITS) The UITS Prototype Project is a Military Health System (MHS) prototype is intended to optimally accomplish immunization documentation and tracking, and support immunizations readiness reporting. The ECCF Physical Implementation Model (PIM) layer are based on the UITS project prototype, which is scheduled for its first go-live demonstration in September /16/2010 Page 130 of 139

132 This initiative supports three broad goals: 1. Force Health Protection and Readiness perspective: a. Ensure a healthy and fit fighting force that is fully medically ready to deploy and provide the Department of Defense (DoD) maximal ability to perform its mission. b. Improved medical readiness through documenting, monitoring and reporting immunization status. 2. Population Health perspective: a. Preventing and controlling diseases reduces adverse incidence requiring medical treatment. b. Compliant with current national standards and regulations to include patient safety and data quality. 3. Medical Care perspective: a. Patient safety. b. Provider has immunization history. c. Medical conditions require supplemental immunization. d. Contraindications to immunizations. 7.2 TOGAF Architecture Development Method (ADM) We followed The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM 44 ), shown in Figure 43 (below) to populate the SAIF Enterprise Conformance and Compliance Framework (ECCF 45 ) shown in Table 13 (above). The ECCF views are analogous to TOGAF s business, data, application, and technology views. In order to minimize duplication, this section references figures and tables in the SAIF-ECCF appendix, rather than duplicate them here. The TOGAF ADM, shown in Figure 43, recommends a sequence for phases and steps involved in developing architectures; it is an iterative process which supports agile refinement processes and incremental delivery over the whole requirements-specifications lifecycle from simple requirements statements to implemented, tested, certified and deployed systems. Capabilities can be developed concurrently; but, for each capability and iteration, it is important to reconsider scope, detail, schedules, costs and milestones with an eye for optimization in TOGAF ADM s Phase E described below. TOGAF ADM is usable with deliverables of other frameworks such as Zachman 46, DODAF 47. It is usual to modify or extend the ADM to suit specific enterprise or project needs, as we have adapted it to populate the HL7 SAIF-ECCF See for details. 45 See for details. 46 The Zachman Framework provides a formal and highly structured way of defining an enterprise. It is based on a two-dimensional classification model, displayed as a matrix, which utilizes six basic communication interrogatives (What, How, Where, Who, When, and Why) and intersecting six distinct model types which relate to stakeholder groups (Strategists, Executive Leaders, Architects, Engineers, Technicians, and Workers) to give a holistic view of the enterprise. Decomposition of the matrix allows for several diagrams of the same data sets to be developed for the same architecture, where each diagram shows an increasing level of detail. See for details. 47 DoDAF focuses on architectural "data", rather than on developing individual "products". The DoDAF enables architectural content that is "Fit-for- Purpose" user-defined views using subsets of architectural data as architectural descriptions consistent with specific project or mission objectives. Visualizing architectural data is accomplished through models (e.g., the products). When data is collected and presented as a "filled-in" model, the result is called a view. Organized collections of views (often representing processes, systems, services, standards, etc.) are referred to as viewpoints, and with appropriate definitions are collectively called the Architectural Description. See for details. 48 The SAIF-ECCF is based on the ISO Reference Model of the Open Distributed Processing (RM-ODP, ITU-T Rec. X.901-X.904 ISO/IEC 10746) which is a joint effort by ISO/IEC and ITU-T, 5/16/2010 Page 131 of 139

133 Figure 43 TOGAF ADM Supported by EHR-SD RM The "Requirements Management and Governance" circle at the center of the ADM graphic indicates that Requirements Management and Governance should be a part of every stage of a project. It is important to note that the Requirements Management and Governance circle denotes, not a static set of requirements, but a dynamic process whereby requirements for enterprise architecture and subsequent changes to those requirements are identified, validated, stored, and fed into and out of the relevant ADM phases but, the requirements management process must also dispose of, address, validate or prioritize evolving and refined requirements during the relevant phases of the ADM. The ability to govern changes in requirements is crucial. Architecture is an activity that by its very nature deals with uncertainty and change - the "grey area" between what stakeholders aspire to and what can be specified and engineered as a pragmatic solution. Moreover, architecture often deals with drivers and constraints, which can produce changes in requirements in an unforeseen manner. Many of the factors influencing architecture by their very nature are beyond the control of the enterprise (changing market conditions, new legislation, etc.) Preliminary The TOGAF ADM Preliminary Phase prepares the organization for a successful architecture project; it defines "how we do architecture." Its objectives are [TOGAF ADM 2006]: 5/16/2010 Page 132 of 139

134 Working Draft; NOT for Public Distribution To ensure that everyone who will be involved in, or benefit from, this approach is committed to the success of the architectural process To define the architecture principles that will inform the constraints on any architecture work To define the "architecture footprint" for the organization - the people responsible for performing architecture work, where they are located, and their responsibilities To define the scope and assumptions (particularly in a federated architecture environment) To define the framework and detailed methodologies that are going to be used to develop enterprise architectures in the organization concerned (typically, an adaptation of the generic ADM) To set up and monitor a process (normally including a pilot project) to confirm the fitness-for-purpose of the defined framework If necessary, to define a set of criteria for evaluating architecture tools, repositories, and repository management processes to be used to capture, publish, and maintain architecture artifacts DISCUSSION: In adding an Immunization Management Capability (IMC) to SampleHealth s SOA, we followed the TOGAF ADM and present the Interoperability Specifications using the HL7 SAIF Enterprise Conformance and Compliance Framework (ECCF). Since this was a prototype project, we followed a consensus governance (e.g., decision processes and management) based on peer review of architectural products. Additionally, we maintained a configuration management discipline, which mandates that each artifact be dated and have a version number. SAIF-ECCF MAPPING: TOGAF ADM Preliminary Phase products are not shown in the Section 2 SAIF-ECCF for Immunization Management A Architecture Vision TOGAF ADM Phase A sets the scope, constraints and expectations for the project. Validate the business context and create the Statement of Architecture Work. Architectural activity can be scoped or limited in the following four ways [TOGAF ADM 2006]: 1. Enterprise scope or focus. 2. Architecture Domains. 3. Level of details (vertical scope). 4. Project Schedules (time horizons). DISCUSSION: 1. Enterprise scope or focus: Our scope is to prototype an Immunization Management capability, which is added to SampleHealth s SOA. Our use cases are defined in the Health and Human Services (HHS) American Health Information Community (AHIC) developed Immunization Response Management (IRM) use case and its Vaccine and Drug Administration and Reporting scenario plus overlaps with AHIC s Public Health Case Reporting (PHCR). Our secondary scope, as an HL7 SAIF alpha-project, is to demonstrate the use of the SAIF ECCF. 2. Architecture Domains: We are working in the healthcare EHR and public health domains 3. Level of details (vertical scope): We will reuse and reference details provided by Standards Development Organizations (e.g., HL7, OASIS, ANSI) and Standards Related Organizations (e.g., IHE, HITSP) artifacts and guidelines. 4. Project Schedules (time horizons): We assume an agile development and deployment lifecycle requiring all prototype work to be done from 24-March-2010 to 20-September Incremental documentation 5/16/2010 Page 133 of 139

135 deliveries are planned for the HL7 May 2010 Working Group meeting and final delivery at the 24 th HL7 Annual Plenary and Working Group Meeting in October SAIF-ECCF MAPPING: TOGAF ADM Architecture Vision Phase A products are shown in the Appendix Section 2.1 Preamble - Architecture Vision. Although this is not a formal part of the SAIF ECCF, decisions made during this phase impacted the resultant Section 2 architecture B Business Architecture TOGAF ADM Business Architecture Phase B Develops the Business Architecture as-is and target tobe baselines and analyzes the gaps. In practical terms, the Business Architecture is also often necessary as a means of demonstrating the business value of subsequent architecture work to key stakeholders, and the return on investment to those stakeholders from supporting and participating in the subsequent work. The objectives of Phase B are [TOGAF ADM 2006]: To describe the Baseline Business Architecture To develop a Target Business Architecture, describing the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment, based on the business principles, business goals, and strategic drivers To analyze the gaps between the Baseline and Target Business Architectures To select and develop the relevant architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are addressed in the Business Architecture To select the relevant tools and techniques to be used in association with the selected viewpoints DISCUSSION: SampleHealth s as-is architectural baseline was given in The Practical Guide for SOA in Healthcare Volume I. The to-be target architecture adds an Immunization Management Capability (IRC). The EHR-SD RM was used to identify the reusable EHR-S FM and HITSP to-be artifacts. IRC Business Architecture behavioral specifications are given as Use Cases and Scenarios, Business Process Models and Sequence Diagrams in the Section 2 SAIF-ECCF for Immunization Management. SAIF-ECCF MAPPING: The architectural artifacts identified during the TOGAF ADM Business Architecture Phase B were placed within the four SAIF-ECCF Conceptual Viewpoints of 1) Enterprise-Business (e.g., Why), 2) Information (e.g., What), 3) Computational (e.g., How) and 4) Engineering (e.g., Where) C Information Systems Architecture TOGAF ADM Information Systems Architecture Phase C develops a baseline as-is and target to-be and analyzes the gaps. The objective of Phase C is to develop Target Architectures covering either or both (depending on project scope) of the data and application systems domains. Information Systems Architecture focuses on identifying and defining the applications and data considerations that support an enterprise's Business Architecture; for example, by defining views that relate to information, knowledge, application services, etc. The objective of the data architecture is that it defines the major types and sources of data necessary to support the business, in a way that is understandable by stakeholders, complete and 5/16/2010 Page 134 of 139

136 consistent and stable. It is important to note that this effort is not concerned with database design. The goal is to define the data entities relevant to the enterprise, not to design logical or physical storage systems. (However, linkages to existing files and databases may be developed, and may demonstrate significant areas for improvement.) The objective of the application architecture is to define the major kinds of application system necessary to process the data and support the business. It is important to note that this effort is not concerned with applications systems design. The goal is to define what kinds of application systems are relevant to the enterprise, and what those applications need to do in order to manage data and to present information to the human and computer actors in the enterprise. The applications are not described as computer systems, but as logical groups of capabilities that manage the data objects in the Data Architecture and support the business functions in the Business Architecture. The applications and their capabilities are defined without reference to particular technologies. The applications are stable and relatively unchanging over time, whereas the technology used to implement them will change over time, based on the technologies currently available and changing business needs. [TOGAF ADM 2006] DISCUSSION: SampleHealth s as-is architectural baseline was given in The Practical Guide for SOA in Healthcare Volume I. The to-be target architecture adds an Immunization Management Capability (IRC). The IRC Business Architecture behavioral specifications are given as Use Cases and Scenarios, Business Process Models and Sequence Diagrams in the Section 2 SAIF-ECCF for Immunization Management. SAIF-ECCF MAPPING: The architectural artifacts identified during the TOGAF ADM Business Information Systems Architecture Phase C were placed within the four SAIF-ECCF Conceptual Views of 1) Enterprise-Business (e.g., Why), 2) Information (e.g., What), 3) Computational (e.g., How) and 4) Engineering (e.g., Where) D Technology Architecture TOGAF ADM Technology Architecture Phase D develops the baseline as-is and target to-be technology architecture and analyzes the gaps. The Technology Architecture phase seeks to map application components defined in the Application Architecture phase into a set of technology components, which represent software and hardware components, available from the market or configured within the organization into technology platforms. As Technology Architecture defines the physical realization of an architectural solution, it has strong links to implementation and migration planning. Technology Architecture will define baseline (i.e., current) and target views of the technology portfolio, detailing the roadmap towards the Target Architecture, and to identify key work packages in the roadmap. Technology Architecture completes the set of architectural information and therefore supports cost assessment for particular migration scenarios. [TOGAF ADM 2006] DISCUSSION: SampleHealth s as-is architectural baseline was given in The Practical Guide for SOA in Healthcare Volume I. The to-be target architecture adds an Immunization Management Capability (IRC). The IRC Business Architecture behavioral specifications are given as Use Cases and Scenarios, Business Process Models and Sequence Diagrams in the Section 2. 5/16/2010 Page 135 of 139

137 SAIF-ECCF MAPPING: TOGAF ADM Technology Architecture Phase D architectural artifacts were placed within the four SAIF-ECCF System Independent Viewpoints of 1) Enterprise-Business (e.g., Why), 2) Information (e.g., What), 3) Computational (e.g., How) and 4) Engineering (e.g., Where) E Opportunities and Solutions TOGAF ADM Opportunities and Solutions Phase E Identifies Major Implementation delivery vehicles (projects, programs, or portfolios) that effectively deliver the Target Architecture identified in previous phases. The objectives of Phase E are [TOGAF ADM 2006]: To review the target business objectives and capabilities, consolidate the gaps from Phases B to D, and then organize groups of building blocks to address these capabilities. To review and confirm the enterprise's current parameters for and ability to absorb change. To derive a series of Transition Architectures that deliver continuous business value (e.g., capability increments) through the exploitation of opportunities to realize the building blocks To generate and gain consensus on an outline Implementation and Migration Strategy DISCUSSION: For SampleHealth s IMC, the opportunities and Solutions which we take advantage of is the reuse of the As-Is SampleHealth Services, described in Volume I. The TOGAF ADM phases B-to-D gaps are filled by the new Immunization Management Capability. For the May 2010 draft version of this document, a series of transition architectures or Implementation and Migration Strategy were not done; they are planned to be done for the Oct 2010 version 1.0 of this document. SAIF-ECCF MAPPING: TOGAF ADM Opportunities and Solutions Phase E products are not explicitly shown in the Section 2; but, the decisions made during this phase are reflected in the resultant Section 2 architecture F Migration Planning TOGAF ADM Migration Planning Phase F Analyzes the costs, benefits and risks and produce an implementation roadmap. The main focus of Phase F is the creation of a viable Implementation and Migration Plan in co-operation with the portfolio and project managers. Phase F activities include assessing the dependencies, costs, and benefits of the various migration projects. The prioritized list of projects will form the basis of the detailed Implementation and Migration Plan that will supplement the architectures with investment portfolio and project-level detail assigning tasks to specific resources. The Implementation and Migration Plan is part of a family of plans issued by enterprise management frameworks that have to be closely coordinated to ensure that business value is delivered and that the resources are made available to complete the necessary work. This phase ensures that all concerned agencies outside of the enterprise architecture world are aware of the scope and import of the Implementation and Migration Plan and its implications with respect to their activities. Finally, the architecture evolution cycle should be established to ensure that the architecture stays relevant, and lessons learned should be documented to enable continuous process improvement. The objectives of Phase F are to finalize a detailed Implementation and Migration Plan; specifically [TOGAF ADM 2006]: To ensure that the Implementation and Migration Plan is coordinated with the various management frameworks in use within the enterprise 5/16/2010 Page 136 of 139

138 To prioritize all work packages, projects, and building blocks by assigning business value to each and conducting a cost/business analysis To finalize the Architecture Vision and Architecture Definition Documents, in line with the agreed implementation approach To confirm the Transition Architectures defined in Phase E with relevant stakeholders To create, evolve, and monitor the detailed Implementation and Migration Plan providing necessary resources to enable the realization of the Transition Architectures, as defined in Phase E DISCUSSION: For SampleHealth s IMC, we need an Implementation and Migration Plan for the to-be architectures. For the May 2010 draft version of this document, the Implementation and Migration Plan is not done; it is planned for the Oct 2010 version 1.0 of this document. SAIF-ECCF MAPPING: TOGAF ADM Migration Planning Phase F products are not explicitly shown in the Section 2; but, the decisions made during this phase are shown by the resultant Section 2 architecture G Implementation Governance TOGAF ADM Implementation Governance Phase G ensures that the implementation projects conform to the architecture. The objectives of Phase G are [TOGAF ADM 2006]: To formulate recommendations for each implementation project To govern and manage an Architecture Contract covering the overall implementation and deployment process To perform appropriate governance functions while the solution is being implemented and deployed To ensure conformance with the defined architecture by implementation projects and other projects To ensure that the program of solutions is deployed successfully, as a planned program of work To ensure conformance of the deployed solution with the Target Architecture To mobilize supporting operations that will underpin the future working lifetime of the deployed solution The overall approach in Phase G is to: Establish an implementation program that will enable the delivery of the Transition Architectures agreed for implementation during the Migration Planning phase Adopt a phased deployment schedule that reflects the business priorities embodied in the Architecture Roadmap Follow the organization's standard for corporate, IT, and architecture governance Use the organization's established portfolio/program management approach, where this exists Define an operations framework to ensure the effective long life of the deployed solution DISCUSSION: For SampleHealth s IMC, we need an Implementation and Migration Plan for the to-be architectures. For the May 2010 draft version of this document, the Implementation and Migration Plan is not done; it is planned for the Oct 2010 version 1.0 of this document. 5/16/2010 Page 137 of 139

139 SAIF-ECCF MAPPING: TOGAF ADM Migration Planning Phase F products are not shown in the Section 2 SAIF-ECCF for Immunization Management; but, the decisions made during this phase are shown by the resultant Section 2 architecture H Architecture Change Management TOGAF ADM Architecture Change Management Phase H ensures that the architecture responds to the needs of the enterprise as changes arise. The goal of an architecture change management process is to ensure that the architecture achieves its original target business value. This includes managing changes to the architecture in a cohesive and architected way. This process will typically provide for the continual monitoring of such things as governance requests, new developments in technology, and changes in the business environment. When changes are identified, change management will determine whether to formally initiate a new architecture evolution cycle. Additionally, the architecture change management process aims to establish and support the implemented enterprise architecture as a dynamic architecture; that is, one having the flexibility to evolve rapidly in response to changes in the technology and business environment. The objectives of Phase H are [TOGAF ADM 2006]: To ensure that baseline architectures continue to be fit-for-purpose To assess the performance of the architecture and make recommendations for change To assess changes to the framework and principles set up in previous phases To establish an architecture change management process for the new enterprise architecture baseline that is achieved with completion of Phase G To maximize the business value from the architecture and ongoing operations To operate the Governance Framework DISCUSSION: For SampleHealth s IMC, we need change management for iterations from the as-is baseline configuration to the final to-be future state configuration. Changes to documents and diagrams must be version controlled. SAIF-ECCF MAPPING: TOGAF ADM Architecture Change Management Phase H products are not shown in the Section 2 SAIF-ECCF for Immunization Management; but, the decisions made during this phase are shown by the resultant Section 2 architecture. 5/16/2010 Page 138 of 139