practical guide for soa in healthcare volume ii ...hssp.wikispaces.com/file/view/practical guide for...

1 2 3 4

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:

http://hssp.wikispaces.com/PracticalGuide

Please send Suggestions for Improvement to [email protected], editor

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.

HSSP

Working Draft; NOT for Public Distribution

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

©2010, Healthcare Services Specification Project, Health Level Seven, IHE, Object Management Group. All rights reserved. 5/16/2010 Page i of 139

Executive Summary 5

The Practical Guide for SOA in Healthcare1 Volume II presents a case study, which adds an Immunization 6 Management Capability (IMC) to Volume I’s SampleHealth’s Service Oriented Architecture (SOA). We 7 used the TOGAF Architecture Development Method (ADM) and HL7 Service Aware Interoperability 8 Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF). Volume II 9 demonstrates the use of HL7’s EHR System Design Reference Model (EHR-SD RM) linked architectural 10 artifacts (e.g., EHR System Functional Model, IHE, HSSP, HITSP, HITEC, FHIM, NIEM, etc) to 11 provide an initial architectural baseline suitable for an EHR related SOA acquisition, development or 12 certification project. We conclude with lessons learned, such as: 13

The TOGAF ADM is an effective process, which led us to produce a set of interoperability 14 specifications and conformance statements. 15

The SAIF-ECCF is an “Exchange Architecture;” which can be used as an Architectural Executive Summary 16 to present the IMC interoperability specifications and conformance statements. 17

Other architecture development methods or other architectural frameworks, such as the Rational 18 Unified Process, the Zachman or the DOD Architectural Framework can complement and benefit-19 from HL7’s EHR-SD-RM and SAIF-ECCF to build and present an exchange architecture, 20 interoperability specifications and conformance statements. 21

22 Two use cases from the Health and Human Services (HHS) American Health Information Community 23 (AHIC) were used. The Immunization and Response Management (IRM) use case and its Vaccine and 24 Drug Administration and Reporting scenario and the Public Health Case Reporting (PHCR) use case 25 were used to develop the business architecture, Information Exchange Requirements (IERs), data 26 requirements, interoperability specifications and conformance statements for the IMC’s Services. 27 28 Effective SOA programs involve cooperation and coordination among a wide variety of business, 29 technical and functional participants from across an organization, including senior management 30 sponsorship, business community ownership, program management, governance, architecture, project 31 level execution, test and certification and sustainment teams. The HL7 EHR-SD-RM helps bring these 32 communities together throughout a Business Capability Lifecycle. It maps capabilities and their business 33 Information Exchange Requirements (IERs) to the 34 HL7 EHR System Functional Model (EHR-S FM), to 35 Healthcare Information Technology Standards Panel (HITSP) 36

o Data Architecture, 37 o Security and Privacy Architecture, 38 o Harmonization Framework, 39 o Interoperability Specifications, Constructs and their referenced standards; 40

1 Current versions of both The Practical Guide to SOA in Healthcare Volume 1 and Volume II are available at http://hssp.wikispaces.com/PracticalGuide



©2010, Healthcare Services Specification Project, Health Level Seven, IHE, Object Management Group. All rights reserved. 5/16/2010 Page ii of 139

Integrating the Healthcare Enterprise (IHE) profiles; and 41 2009 Health Information Technology for Economic and Clinical Health (HITECH) Act selected 42

standards for interoperability and meaningful use objectives and criteria. 43 The projects listed above are all evolving and maturing as is the EHR-SD RM. Generally, no one person 44 can keep track of this diverse set of information; the EHR-SD-RM lets individual analysts use appropriate, 45 meaningful and consistent viewpoints as a project team works through a business capability’s lifecycle. 46 47 Change History (remove from the final document) 48 Version A, dated 26 Mar 2010 Table of Contents 49 Version B, dated 02 Apr 2010 Background Section (1st Draft) 50 Version C, dated 09 Apr 2010 Executive Summary, TOGAF ADM and SAIF Sections (1st Draft) 51 Version D, dated 16 Apr 2010, Executive Summary and TOGAF ADM (2nd Draft) 52 Version E, dated 30 Apr 2010. SAIF-ECCF Appendix (2nd Draft) 53 Version F, dated 30 Apr 2010. IHE, TOGAF ADM and SAIF Sections (3th Draft) 54 Version G, dated 07 May 2010, Full document edit, cleanup, review and gap identification 55 Version H, dated 14 May 2010, Document & Slides for HL7 WG meeting in Rio de Janeiro. 56 Version I, dated 21 May 2010, Move ECCF to body and Background & TOGAF to appendix 57 Version J, dated 04 Jun 2010, Updated IHE example in Section 2.1.1. 58

TODO … 59

Version ?, dated summer 2010, summer 2010, ECCF architectural artifact ontology & glossary 60

Version ?, dated summer 2010, Add FHIM to IMC specification 61

Version ?, dated summer 2010, Add NIEM IEPDs to IMC specification 62

Version ?, dated summer 2010, Add CCHIT certification criteria to IMC 63

Version ?, dated summer 2010, Integrate NHIN Connect & Direct Services into ECCF PIM 64

Version ?, dated summer 2010, Add UITS IMC Platform Specific specifications 65

Version ?, dated summer 2010, Enhance the TOGAF & ECCF discussions linking views together 66

Version ?, dated summer 2010, Refine ECCF Conformance Statements 67

Version 1.0, dated 01-Oct-2010, for HL7 24th Annual Plenary & Working Group Meeting 68 69 70 HELP NEEDED: (remove from the final document) 71

1) Editorial review: Is the document clear, complete, concise, correct, consistent and easy to use? 72 2) Update references, abbreviations, glossary, Index the document and add an index at the end. 73 3) NHIN, NHIN Connect and NHIN Direct services Subject Matter Expert 74

a. WSDL Subject Matter Expert for specifications 75 4) NIEM IEPD Subject Matter Expert 76 5) CCHIT Subject Matter Expert 77 6) XML XSD schema development for EHR-S FM and EHR-SD RM representation. 78

a. Good xml reference guide 79



©2010, Healthcare Services Specification Project, Health Level Seven, IHE, Object Management Group. All rights reserved. 5/16/2010 Page iii of 139

b. Editor or other tool to easily develop XSD schemas 80 c. Tool to convert XML + XSD to Access, SQL, Excel or Word formats and vice-versa. 81

7) Review of Practical Guide to SOA in Healthcare Subject Matter Expert review from: 82 a. Immunization Management and Public Health Reporting views. 83 b. Service Oriented Architectural review … what is missing? 84 c. SAIF view - have we presented a clear, complete, concise, correct and consistent ECCF? 85

86 HOW TO PARTICIPATE: 87 Coordinate with [email protected] , 703-681-3929 or 703-575-7912-cell. 88 89 We have a weekly telecom each Friday 1230-1330 Eastern 90

PHONE: +1 770-657-9270, CODE: 071582# 91 WEB LINK: http://my.dimdim.com/hssp 92 PROJECT WIKI: http://hssp.wikispaces.com/Reference+Architecture 93 PRACTICAL GUIDE: http://hssp.wikispaces.com/PracticalGuide 94



©2010, Healthcare Services Specification Project, Health Level Seven, IHE, Object Management Group. All rights reserved. 5/16/2010 Page iv of 139

Table of Contents 95 1 Introduction ......................................................................................................................................................... 9 96 1.1 Acknowledgement ..........................................................................................................................................9 97 1.2 Document Objectives and Scope...............................................................................................................10 98 1.3 Document “Tour” and Structure ...............................................................................................................10 99 1.4 Document Use ..............................................................................................................................................11 100 2 SAIF-ECCF SS for Immunization Management Capability....................................................................... 12 101 2.1 Preamble - Architecture Vision from an IHE Perspective.....................................................................12 102

2.1.1 Top Down Immunization Management Functional Analysis .................................................... 13 103 2.1.1 Bottom Up Immunization Management Technical Analysis...................................................... 14 104

2.1.1. ISSUE: Using a Two-step process to request an immunization history ............................... 15 105 2.1.1. APPROACH: Returning a list of candidate clients in response to PDQ query .................. 19 106

2.1.2 Benefits ............................................................................................................................................... 26 107 2.1.3 Discussion .......................................................................................................................................... 26 108

2.2 ECCF Introduction ......................................................................................................................................27 109 2.2.1 ECCF Artifacts .................................................................................................................................. 30 110 2.2.2 ECCF Working Interoperability...................................................................................................... 31 111 2.2.3 ECCF Traceability............................................................................................................................. 31 112 2.2.4 ECCF Glossary and Traceability Meta-Model .............................................................................. 32 113 2.2.5 ECCF Implementation Guide......................................................................................................... 34 114

2.3 Conceptual Enterprise-Business-Viewpoint .............................................................................................37 115 2.3.1 Policy and Regulation ....................................................................................................................... 38 116

2.3.1. Privacy & Security Requirements................................................................................................39 117 2.3.1. HITECH Meaningful Use Objectives and Criteria.................................................................. 43 118

2.3.2 Business Objectives........................................................................................................................... 44 119 2.3.3 Project Scope and Vision Statement .............................................................................................. 44 120 2.3.4 Non-Functional Requirements........................................................................................................ 46 121 2.3.5 Use Case Inventory ........................................................................................................................... 49 122 2.3.6 Conformance Criteria ....................................................................................................................... 50 123 2.3.7 Discussion .......................................................................................................................................... 50 124

2.4 Conceptual Information-Viewpoint ..........................................................................................................50 125 2.4.1 Domain Information Model ............................................................................................................ 52 126 2.4.2 Conformance Statements ................................................................................................................. 53 127 2.4.3 Discussion .......................................................................................................................................... 53 128

2.5 Conceptual Computation-Viewpoint.........................................................................................................53 129 2.5.1 Service Inventory............................................................................................................................... 54 130 2.5.1 Functional Requirements ................................................................................................................. 56 131 2.5.2 Conceptual Functional Service Specification (CFSS)................................................................... 57 132 2.5.3 Service Roles and Relationships...................................................................................................... 57 133 2.5.4 Conformance Statements ................................................................................................................. 57 134 2.5.5 Discussion .......................................................................................................................................... 57 135

2.6 Conceptual Engineering-View....................................................................................................................58 136 2.6.1 Inventory of Software Platforms and Their Capabilities............................................................. 58 137 2.6.2 Conformance Statements ................................................................................................................. 59 138 2.6.3 Discussion .......................................................................................................................................... 59 139

2.7 Platform-Independent Enterprise-Business-Viewpoint..........................................................................59 140 2.7.1 NHIN Standards ............................................................................................................................... 59 141



©2010, Healthcare Services Specification Project, Health Level Seven, IHE, Object Management Group. All rights reserved. 5/16/2010 Page v of 139

2.7.2 Business Governance........................................................................................................................ 60 142 2.7.3 Conformance Statements ................................................................................................................. 60 143 2.7.4 Discussion .......................................................................................................................................... 61 144

2.8 Platform-Independent Information-Viewpoint .......................................................................................61 145 2.8.1 Project Information Model .............................................................................................................. 62 146

2.8.1. Data Requirements (DRs)............................................................................................................ 62 147 2.8.1. Standards Gaps.............................................................................................................................. 70 148 2.8.1. Standard Overlaps......................................................................................................................... 73 149

2.8.2 Conformance Statements ................................................................................................................. 75 150 2.8.3 Discussion .......................................................................................................................................... 75 151

2.9 Platform-Independent Computation-Viewpoint .....................................................................................76 152 2.9.1 Service Interface Specification Types and Functional Group Types,........................................ 76 153

2.9.1. Map of Business Functions ......................................................................................................... 76 154 2.9.2 Use Cases and Business Level Interaction Diagrams................................................................... 78 155

2.9.2. Information Exchanges................................................................................................................ 79 156 2.9.2. Information Exchange Requirements (IERs) ........................................................................... 80 157 2.9.2. Business Level Behavioral Specifications .................................................................................. 81 158

2.9.3 Service Interaction Types and Collaboration Participations....................................................... 85 159 2.9.3. System-Level Exchange Architecture......................................................................................... 85 160 2.9.3. System Data Exchange Behavioral Specifications.................................................................... 88 161

2.9.4 Service Collaboration Types ............................................................................................................ 94 162 2.9.5 Service Contracts Parts ..................................................................................................................... 99 163 2.9.6 Conformance Statements ...............................................................................................................101 164 2.9.7 Discussion ........................................................................................................................................101 165

2.10 Platform-Independent Engineering-Viewpoint .....................................................................................101 166 2.10.1 Existing Platforms...........................................................................................................................101 167 2.10.2 Conformance Statements ...............................................................................................................102 168 2.10.3 Discussion ........................................................................................................................................102 169

2.11 Platform-Specific Enterprise-Business-Viewpoint ................................................................................102 170 2.11.1 Rules, Procedures and Industry Standards ..................................................................................103 171 2.11.2 Conformance Statements ...............................................................................................................103 172 2.11.3 Discussion ........................................................................................................................................103 173

2.12 Platform-Specific Information-Viewpoint..............................................................................................103 174 2.12.1 Schemas and Transformations ......................................................................................................104 175 2.12.2 Conformance Statements ...............................................................................................................104 176 2.12.3 Discussion ........................................................................................................................................104 177

2.13 Platform-Specific Computation-Viewpoint ............................................................................................104 178 2.13.1 Collaboration Scripts, Orchestration, Realized Interfaces ........................................................104 179 2.13.2 Conformance Statements ...............................................................................................................104 180 2.13.3 Discussion ........................................................................................................................................104 181

2.14 Platform-Specific Engineering-Viewpoint ..............................................................................................104 182 2.14.1 Execution Context, Platform Bindings and Deployment .........................................................105 183

2.14.1. Systems .....................................................................................................................................105 184 2.14.2 Conformance Statements ...............................................................................................................106 185 2.14.3 Discussion ........................................................................................................................................106 186

3 Conclusions and Lessons-Learned ...............................................................................................................106 187 3.1 Immunization Management Lessons Learned .......................................................................................107 188



©2010, Healthcare Services Specification Project, Health Level Seven, IHE, Object Management Group. All rights reserved. 5/16/2010 Page vi of 139

3.2 ECCF Lessons Learned .............................................................................................................................107 189 3.3 SOA Lessons Learner ................................................................................................................................109 190 3.4 TOGAF ADM Lessons Learned .............................................................................................................109 191 4 Acronym List ...................................................................................................................................................109 192 5 Glossary ............................................................................................................................................................110 193 6 References ........................................................................................................................................................110 194 7 Appendix ..........................................................................................................................................................110 195 7.1 Background..................................................................................................................................................111 196

7.1.1 Service Oriented Architecture (SOA)...........................................................................................111 197 7.1.2 EHR System Functional Model (EHR-S FM) ............................................................................113 198 7.1.3 Healthcare SOA Reference Architecture (H-SOA-RA) ............................................................116 199 7.1.4 Reference Information Model (RIM)...........................................................................................117 200 7.1.5 Federal Health Information Model (FHIM) ...............................................................................118 201 7.1.6 Healthcare Service Specification Project (HSSP) .......................................................................120 202 7.1.7 Service Aware Interoperability Framework (SAIF)....................................................................121 203 7.1.8 Integrating the Healthcare Enterprise (IHE) ..............................................................................122 204 7.1.9 EHR System Design Reference Model (EHR-SD RM) ............................................................123 205

7.1.9. EHR-SD RM within the Requirements Management and Architecture Cycle..................124 206 7.1.10 Health Information Technology Standards Panel (HITSP)......................................................125 207 7.1.11 Certification Commission for Health Information Technology (CCHIT).............................127 208 7.1.12 National Information Exchange Model (NIEM) .......................................................................128 209 7.1.13 Nationwide Health Information Network (NHIN)...................................................................129 210

7.1.13. NHIN CONNECT................................................................................................................129 211 7.1.13. NHIN Direct ...........................................................................................................................130 212

7.1.14 Universal Immunization Tracking System (UITS) .....................................................................130 213 7.2 TOGAF Architecture Development Method (ADM)..........................................................................131 214

7.2.1 Preliminary........................................................................................................................................132 215 7.2.2 A – Architecture Vision..................................................................................................................133 216 7.2.3 B – Business Architecture ..............................................................................................................134 217 7.2.4 C – Information Systems Architecture ........................................................................................134 218 7.2.5 D – Technology Architecture........................................................................................................135 219 7.2.6 E – Opportunities and Solutions ..................................................................................................136 220 7.2.7 F – Migration Planning...................................................................................................................136 221 7.2.8 G – Implementation Governance.................................................................................................137 222 7.2.9 H – Architecture Change Management .......................................................................................138 223

224 List of Tables 225 Table 1 Capabilities Mapped to Existing IHE Profiles and Transactions ......................................................... 20 226 Table 2: Introduction of Mediating Services .......................................................................................................... 22 227 Table 3 Standards Overlaps for Services ................................................................................................................ 23 228 Table 4 Taxonomy of Immunization Services Based on Standards ................................................................... 24 229 Table 5 Notional Set of Architectural Artifacts within the HL7 SAIF ECCF SS ............................................ 29 230 Table 6 Guidance Standards ..................................................................................................................................... 43 231 Table 7 Data Element and Information Requirements (DR).............................................................................. 63 232 Table 8 Use Case Requirements and Associated Standards Gaps ...................................................................... 71 233 Table 9 Use Case Requirements and Associated Standard Overlaps ................................................................. 74 234 Table 10 As-Is SampleHealth Business Function Map ........................................................................................ 77 235



©2010, Healthcare Services Specification Project, Health Level Seven, IHE, Object Management Group. All rights reserved. 5/16/2010 Page vii of 139

Table 11 To-Be SampleHealth Business Function Map....................................................................................... 77 236 Table 12 Design Principles vs. Strategic Goals and Benefits.............................................................................112 237 Table 13 HL7 SAIF Enterprise Conformance and Compliance Framework (ECCF) ..................................122 238 239 List of Figures 240 Figure 1 Meet in the Middle Approach................................................................................................................... 13 241 Figure 2 US Recommended Child Immunization Schedule ................................................................................ 14 242 Figure 3 Request Immunization History Using PIX............................................................................................. 17 243 Figure 4 Request Immunization History using PDQ ........................................................................................... 18 244 Figure 5 Public Health Immunization Deployment Example............................................................................. 24 245 Figure 6 Rows in the ECCF Stack ........................................................................................................................... 27 246 Figure 7 Reference Standards and Models within the HL7 SAIF (ECCF) ....................................................... 30 247 Figure 8 Conceptual Map of ECCF Working Interoperability............................................................................ 31 248 Figure 9 IS10 IRM HITSP Constructs Mapped to Standards............................................................................. 32 249 Figure 10 ECCF SS Traceability Meta Model ........................................................................................................ 34 250 Figure 11 EHR-S FM Direct Care 1.8.2 Manage Immunization Administration Dependencies................... 46 251 Figure 12 Conceptual Health Data Model.............................................................................................................. 51 252 Figure 13 NHIN Standards Framework ................................................................................................................. 60 253 Figure 14 Immunization and Response Management Information Exchanges ............................................... 79 254 Figure 15 Immunizations and Response Management (IRM) Business Sequence – Part 1 – Clinician 255 Perspective: Immunizations and Response Management Scenario 2: Vaccine and Drug Administration and 256 Reporting ..................................................................................................................................................................... 82 257 Figure 16 Immunizations and Response Management (IRM) Business Sequence – Part 2 – Registries 258 Perspective: Immunizations and response management Scenario 2: Vaccine and Drug Administration and 259 Reporting ..................................................................................................................................................................... 83 260 Figure 17 Immunizations and Response Management (IRM) Business Sequence – Part 3– Consumer 261 Perspective: Immunizations and response management Scenario 2: Vaccine and Drug Administration and 262 Reporting ..................................................................................................................................................................... 84 263 Figure 18 Immunizations and Response Management (IRM) Business Sequence – Part 4............................ 85 264 Figure 19 As-Is SampleHealth Information System High Level Architecture.................................................. 86 265 Figure 20 To-Be SampleHealth Information System High Level Architecture................................................ 87 266 Figure 21 Mapping of Requirements to HITSP Constructs ................................................................................ 88 267 Figure 22 Communicate Vaccinations .................................................................................................................... 90 268 Figure 23 Immunization Query and Response ...................................................................................................... 92 269 Figure 24 Vaccine and Drug Inventory Reporting................................................................................................ 93 270 Figure 25 Immunization Management Entities, Actions and Roles ................................................................... 94 271 Figure 26 Capability System Roles........................................................................................................................... 94 272 Figure 27 Information Exchanges Mapped to External Interfaces .................................................................... 95 273 Figure 28 Supported Information Exchanges........................................................................................................ 96 274 Figure 29 Information Exchanges Mapped to Constructs................................................................................... 97 275 Figure 30 Immunization Information Sender System Role Mapped to HITSP Construct Interfaces.......... 98 276 Figure 31 Implementation Conditions .................................................................................................................... 98 277 Figure 32 HL7 EHR System Functional Model (EHR-S FM) ..........................................................................114 278 Figure 33 Healthcare SOA Reference Architecture (H-SOA-RA) ...................................................................117 279 Figure 34 HL7 Reference Information Model (RIM).........................................................................................118 280 Figure 35 FHIM relationship to NIEM................................................................................................................120 281 Figure 37 EHR-SD RM Leveraging Standards Related Organizations............................................................123 282



©2010, Healthcare Services Specification Project, Health Level Seven, IHE, Object Management Group. All rights reserved. 5/16/2010 Page viii of 139

Figure 38 Conceptual View of the HL7 EHR System Design Reference Model ...........................................124 283 Figure 39 EHR-SD RM Supporting Requirements and Architecture Processes............................................125 284 Figure 40 HITSP Harmonization Process............................................................................................................126 285 Figure 41 HITSP Document Architecture ...........................................................................................................126 286 Figure 42 Fundamental Interoperability Relationships.......................................................................................127 287 Figure 43 ONC Standards and Interoperability Framework Process...............................................................129 288 Figure 44 TOGAF ADM Supported by EHR-SD RM......................................................................................132 289 290


The Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study ©2010, Healthcare Services Specification Project, Health Level Seven, IHE, Object Management Group. All rights reserved.

5/16/2010 Page 9 of 139

1 Introduction 291

This document builds upon the “The Practical Guide for SOA in Health Care” Volume I. Volume II elaborates 292 an Immunization and Response Management (IRM) use case illustrating how services can be coordinated in 293 support of workflow [choreography, service orchestration] documented within the HL7 Services Aware 294 Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF). 295 Specifically, volume II illustrates how the set of IRM use case behavioral specifications (e.g., dynamic 296 business and system architectural views) can be linked through the EHR System Design Reference Model 297 (EHR-SD RM) to satisfy the set of IRM Information Exchange Requirements (IERs) with HSSP2, HITSP3 298 and IHE4 conformant standards-based (e. g., HL7, ANSI, ISO, OASIS etc.) services. 299

1.1 Acknowledgement 300 This document reflects the collective input from across the HSSP, HITSP, HL7, OMG and IHE 301 communities, and was developed in collaboration during a series of workgroup meetings, teleconference 302 calls and offline work from a host of contributors. Special thanks to all who contributed to the authoring 303 and review of this document; in particular, the following individuals and organizations made significant 304 contributions to this work: 305 Nancy Orvis (Government Projects Co-Chair), Military Health System 306 Stephen Hufnagel (EHR-SD RM project facilitator), Military Health System contractor 307 Alean Kirnak (PHER WG co-chair, HSSP-IHE coordinator), Software Partners LLC 308 Anna Orlova, (IHE contributor) Public Health Data Standards Consortium 309 Joshua Painter, (IHE contributor), Intel Corporation 310 Ken Rubin (HSSP co-chair, HL7-OMG coordinator), EDS a Hewlett Packard company 311 Pat Van Dyke (EHR WG co-chair), Delta Dental Plans Association 312 John Ritter (EHR WG co-chair), College of American Pathologists 313 Gary Dickinson (EHR WG co-chair), CentriHealth 314 Don Mon, (EHR WG co-chair), AHIMA 315

316 The EHR System Design Reference Model (EHR-SD RM) is built from and links standards related 317 organizations (e.g., HL7, OASIS, ANSI, HITSP, OMG, IHE) artifacts. The EHR-SD RM assimilates these 318 artifacts into a requirements analysis, system engineering, enterprise architectural and test set of products to 319 increase the productivity of business, functional, information, systems and test analysts in producing a set of 320 standards-based healthcare information technology architectural interoperability specifications and 321 conformance criteria. The EHR-SD RM and this case study use the work products and stand on the 322 shoulders of the participants of the standards related organizations; special thank to all those standards 323 related organizations volunteers. 324 325

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 10 of 139

The EHR-SD RM was co-sponsored and developed by the HL7 Government Projects, Healthcare Services 326 Specification Project (HSSP), Electronic Health Record (EHR) and Public Health and Emergency Response 327 (PHER) work groups. Members of those groups and IHE also contributed to the Practical Guide for SOA 328 in Healthcare Volume II: Immunization Management Case Study. 329

1.2 Document Objectives and Scope 330 The objectives of this document are: 331

1. It is a SOA implementation guide, which shows by example what it means to do a “standards-332 based” SOA development of a capability. 333

2. It is an HL7 SAIF Alpha Project, which demonstrates the SAIF ECCF used to document the IMC 334 exchange architecture, Interoperability Specifications and Conformance Criteria. 335

3. It is an Immunization Management Capability prototype demonstrating how the EHR-SD RM can 336 be used to build a baseline architectural specification for an acquisition, development or certification 337 program. 338

339 The scope of this document is to present a standards-based Case Study applying the principles and lessons 340 discussed in The HSSP Practical Guide to SOA in Healthcare Volume 1 and the IHE SOA Whitepaper applied 341 to develop architectural interoperability specification and conformance statements for an Immunization 342 Management Capability (IMC) added to the SampleHealth Service Oriented Architecture (SOA), given in 343 Volume I. To the extent that we use HITSP artifacts, this case study applies to the US Realm; although the 344 general approach is applicable anywhere. Note that the SAIF-ECCF used here is a skeleton for a 345 comprehensive enterprise architecture, such as OMG’s TOGAF, the Zachman Framework or the DOD 346 Architectural Framework (DODAF); the IMC ECCF presents an exchange architecture, it’s interoperability 347 specifications and conformance statements. 348

1.3 Document “Tour” and Structure 349

Volume I of this document addresses principles, systems and architectural structures from a “static” and 350 topological view, focusing on how the pieces fit together. In Volume II’s Immunization Management case 351 study we present an Immunization Management Capability (IMC). We use the HL7 Service Aware 352 Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF) to 353 organize the IMC’s Interoperability-Specification into twelve architectural viewpoints which specify an 354 exchange architecture of interoperability specifications and conformance statements, which are suitable for 355 acquisition, development, test or certification. Then we go over our conclusions and lessons-learned, 356 abbreviations and glossary. The appendix presents a background overview of the EHR-SD RM’s standards 357 related artifacts. The appendix also presents a walk through the OMG TOGAF Architecture Development 358 Method (ADM) which was used to harvest immunization management architectural artifacts, using the 359 EHR-SD RM. To avoid duplication, the TOGAF ADM section 7.2 references architectural artifacts or 360 diagrams, which are presented in the SAIF-ECCF Section 2. 361 362 Although a linear read of the document is possible, some readers may wish to jump to Section 2.1 Preamble - 363 Architecture Vision from an IHE Perspective for an approximately 12 page high level presentation. Persons not 364 familiar with healthcare standards organization may wish to read the background section in the appendix 365



5/16/2010 Page 11 of 139

first. Similarly, persons not familiar with architecture development methodologies, may wish to read the 366 TOGAF overview in the appendix. The full SAIF ECCF presentation starts in Section 2.2 and it presents 367 the twelve ECCF architectural viewpoints. 368

1.4 Document Use 369

Recognize that this is a ‘practical guide’ and informative reference. The challenge we faced as authors was to 370 consider the tradeoff between keeping things simple and useful versus the extensive depth that would be 371 needed to address all concerns. As in Volume I, we opted for simple and useful. As a result, we believe that 372 many of the challenges that you are likely to face are addressed in these pages, but some of your situational-373 specific needs might not be. We encourage you to extend the Practical Guide for SOA in Healthcare to make it 374 your own; we only ask for attribution. 375

Finally, the document is structured around a set of core underlying principles, which are explained in 376 Volume I, followed by the Volume II Case Study where those principles have been applied to an 377 Immunization Management Capability example to make the abstract concepts tangible. Volume I of this 378 document addresses system and architectural structure from a “static” and topological view, focusing on 379 how the pieces fit together. Volume II adds dynamic business, user and system behaviors and interactions; it 380 focuses on how the pieces work together … working interoperability. 381 382 This guide may be used: 383

To provide an example of a standards-based Interoperability Specifications and conformance 384 statements in a health context using industry standard services within a SOA 385

To identify representative conformance views and touch-points with existing standards and 386 technologies (e.g., platforms) within a SOA 387

To demonstrate a possible “minimum essential set” of layers and services needed to successfully 388 specify a SOA 389

To provide a helpful example to assist in localizing / customizing standard services to meet (your) 390 needs 391

To provide a framework setting the context in which (your) future service planning (e.g., Roadmap) 392 can occur. 393

To demonstrate the use of: 394 o HL7 EHR System Functional Model (EHR-S FM) 395 o HL7 EHR System Design Reference Model (EHR-SD RM) 396 o TOGAF Architecture Development Method (ADM) 397 o HL7 Service Aware Interoperability Framework (SAIF) 398

Enterprise Conformance and Compliance Framework (ECCF) 399 o HITSP Interoperability Specifications (ISs) and constructs 400

Capabilities and Service Collaborations 401 Components (e.g., data) 402 Transactions and Transaction Packages 403

404



5/16/2010 Page 12 of 139

2 SAIF-ECCF SS for Immunization Management Capability 405

This Practical Guide for SOA in Healthcare Volume II Case Study presents an Immunization Management Capability 406 (IMC) addition to Volume I’s SampleHealth’s Service Oriented Architecture (SOA)5 using the HL7 Service Aware 407 Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF) Specification 408 Stack (SS). We use the ECCF as an architectural “Executive Summary,” to present the IMC exchange 409 architecture, interoperability specifications and conformance statements. The ECCF demonstrates the HL7 410 EHR System Design Reference Model (EHR-SD RM) linked artifacts (e.g., EHR System Functional Model, FHIM, 411 HITSP, HITEC, HSSP, IHE, NIEM, etc) as an initial architectural baseline suitable for an EHR related SOA 412 acquisition, development or certification project. 413 414

This ECCF section is self contained and can be independently read from the body of the document. The ECCF 415 presents an Exchange Architecture containing twelve ECCF architectural viewpoints, which individually may appear 416 disjoint; taken as a whole, the twelve viewpoints present a comprehensive set of IMC interoperability specifications and 417 conformance statements. A particular user may only be interested in a subset of the twelve viewpoints. 418

419 The challenge we faced was to consider the tradeoff between keeping things simple and useful versus comprehensive; we 420 opted for simple and useful, if additional details are desired, readers can go to the source documents. Additionally, we 421 reduced font sizes for long detailed information blocks and tables to help keep the overall document size down. The MS 422 Word version of this document is available, if readers prefer larger fonts. 423

2.1 Preamble - Architecture Vision from an IHE Perspective 424 This section gives a high level approach to the Immunization Management Capability, prior to presenting 425 the full up SAIF ECCF framework. This architecture vision was done prior to the IMC project and is 426 presented here to set the context for the IMC SAIF ECCF. In 2009, IHE published an IHE IT 427 Infrastructure SOA White Paper6, which describes basic SOA concepts and used an immunization 428 management scenario to illustrate how to map between the IHE Technical Framework and SOA 429 approaches. The paper provides a tutorial that grounds SOA concepts in familiar messaging and structured 430 document standards7. It includes tables of definitions that cross-reference SOA and IHE terms and helps tie 431 together some of the frameworks we are using. For example, in the SAIF ECCF: 432

The platform-independent layer corresponds to the SOA whitepaper’s abstract service definition 433

The platform-independent layer broadly maps to Volume I of the IHE Technical Framework and 434

The platform-specific layer broadly maps to Volume II of the IHE Technical Framework. 435 436 Carrying this a step further, the IHE SOA White Paper discusses a quick-and-simple “meet-in-the-middle” 437 approach to SOA, whereby a taxonomy of services may be used to tie existing standards and legacy software 438 together with a top-down analysis beginning with business processes. The meet-in-the-middle approach is 439

illustrated in Figure 1. 440

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, 2009 7 http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_A-Service-Oriented-Architecture_SOA_2009-

09-28.pdf



5/16/2010 Page 13 of 139

441 Figure 1 Meet in the Middle Approach 442

443 The following sub-section applies this meet-in-the-middle approach to our Immunization Management 444 capability to yield an immunization reference-architecture based upon existing standards. Finally, we 445 illustrate the SOA Business Case cost savings and time-to-market benefits. 446

2.1.1 Top Down Immunization Management Functional Analysis 447 We will discuss immunization information delivery, in particular, as it pertains to the interaction between healthcare 448 providers and public health immunization information systems, or IISs. IISs are public health registries whose goal is 449 the control of vaccine-preventable diseases through improve vaccine coverage rates within populations. 450 451 Meet in the Middle 452 We now begin top-down design. Our stakeholders are: 453

The patient 454 The regional IIS 455 Hospitals 456 Ambulatory clinics 457 Public health clinics 458 Providers 459 School nurses and other public health staff 460



5/16/2010 Page 14 of 139

461 Figure 2 US Recommended Child Immunization Schedule 462

Figure 2 shows the recommended immunization schedule for infants and young children. At a regional, state and 463 national level this is a huge amount of information, which must be shared among stakeholders. To effectively share 464 immunization information, the stakeholders Immunization Information System (IIS) SHALL: 465

Register a patient in the eMPI8 (make the patient known) 466 Find a patient in the eMPI by identifier or by demographics 467 Submit a patient’s immunization information9 to one-or-more public health or shared registries. 468 Locate a patient’s federated immunization information 469 Retrieve a patient’s immunization information 470 Recommend next immunizations 471 Share a patient’s immunization information with providers 472 Share a patient’s information with the patient himself 473 Submit a patient’s immunization information to other IIS 474

2.1.1 Bottom Up Immunization Management Technical Analysis 475 476 There are different required fields (segments, vocabulary, etc.) lists depending upon the use case: 477

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 15 of 139

478 If the IIS does not participate in an MPI: 479

‐ An EHR system reporting immunization data to the IIS for the first time must supply demographics or a 480 local ID as well as immunization data 481

‐ If EHR system updates immunization data for a previously reported patient, it may supply the local ID and 482 the immunization data (but not necessarily the demographics) 483

484 If the IIS participates in an MPI used by the EHR system: 485

‐ An EHR system registering a patient in the MPI for the first time must supply demographics and a local ID 486 ‐ An EHR system reporting immunization data to the participating IIS that has already registered the patient 487

reports the retrieved IIS ID and the immunization data (but not necessarily the demographics) 488 ‐ An EHR system reporting immunization data to the participating IIS that has not already registered the 489

patient must report something else to identify the patient – possibly the MPI ID and optionally 490 demographics? – and the immunization data 491

492 The stakeholders use a mix of HL7 Version 2 and HL7 Version 3 (document and messaging) for data exchange. We 493 now proceed in bottom-up fashion to leverage existing IHE profiles. We identify profiles that implement the required 494 capabilities: 495

Patient Identifier Cross-Referencing (PIX) and Patient Demographics Query (PDQ) with Pediatric 496 Demographics Option – implements an eMPI 497

Cross-Enterprise Document Sharing (XDS.b) with Immunization Content Profile – implements a document 498 registry and repository that can manage immunization documents 499

Utility services such as auditing (ATNA) 500 501

We also need certain capabilities not covered by existing IHE profiles: 502 HL7 Version 2 immunization messaging for data exchange with existing IISs 503 HL7 Version 3 messaging for immunization (POIZ Immunization messaging) data exchange with V3-based 504

systems such as Canadian Health Infoway or British National Health systems 505 Immunization decision support (trial use) services to recommend next vaccines10 506

2.1.1. ISSUE: Using a Two-step process to request an immunization history 507 The IHE profile defines two queries for obtaining an ID of interest. One query requests an ID based on 508 the demographic information included in the query (PDQ, using the Pediatric Demographic profile). When 509 a match is found, it returns the relevant ID and demographic information. The other query seeks an ID for 510 a person from one registered provider based on the ID from another registered provider (PIX). 511 512 The use of the IHE Patient Identification Cross-Referencing (PIX) and Patient Demographic Query (PDQ) 513 transactions is an alternative approach which separates retrieval/update of a patient identifier and 514 retrieval/update of immunization data into two messaging transactions. 515 516

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 16 of 139

A Patient Demographic Supplier may be a Master Person Index or other source of patient demographic and 517 identification information. While we will focus on an MPI below, any Patient Demographic Supplier may 518 be substituted. 519 520 A Master Person Index is a database that contains demographic and locating information of registered 521 persons and associates each person with the identifiers for the person from each of the participating 522 systems. This allows one system to request the identifier for a person that was assigned by another system. 523 This ID may be used to request data from that second system and assures a positive match. 524 525 Systems that participate in an MPI should register each person they are interested in with the MPI. An 526 excellent profile for maintaining and interacting with an MPI has been published by the group, Integrating 527 the Healthcare Enterprise (IHE). That profile will not be replicated here. However, the process for 528 requesting personal identifier outlined below is based on that profile. 529 530 Adding a patient record to an MPI is done by a PIX transaction using an ADT message. This method may 531 be used by an EHR system or by an IIS, or both, to add a patient identifier to an MPI. The PIX profile, 532 described in the IHE Technical Framework Volume I, includes specific transactions that describe the 533 segments and fields to be used. These ADT-based transactions are described in the IHE Technical 534 Framework Volume II. The standard transaction used by PIX is ITI-8, which uses an HL7 V2.3.1 ADT. 535

Patient Identity Feed ITI-8 - method of inserting patient into MPI: 536 MSH|^~\&|MYIIS|MyStateIIS|SOME_SYSTEM|A_Clinic|20091105||ADTÂ01|206935|P|2.3.1|<CR> 537 EVN|A01|20091105|<CR> 538 PID|1||123456^^^MYEHR^MR||Child^Bobbie^Q^^^^L|Que^Suzy|20050512|M|||10 East Main St^^Myfaircity^GA^^^H|||||U|<CR> 539

PV1||I<CR> 540 The Pediatric Demographics Option, described at this writing in a supplement to PIX and PDQ, is 541 preferred for interactions with MPIs managing IIS data. The use of the Pediatric Demographics Option 542 adds ITI-30, which uses an HL7 V2.5 ADT. 543

Patient Identity Management ITI-30 - alternate method of inserting patient into MPI using HL7 544 V2.5 and Pediatric Demographics Option: 545 MSH|^~\&|MYIIS|MyStateIIS|SOME_SYSTEM|A_Clinic|20091105||ADTÂ28ÂDT_A05|206935|P|2.5|<CR> 546 EVN||20091105|<CR> 547 PID|1||123456^^^MYEHR^MR||Child^Bobbie^Q^^^^L|Que^Suzy|20050512|M|||10 East Main St^^Myfaircity^GA^^^H|||||U|<CR> 548 PV1||O|<CR> 549

Once a person has been registered with the MPI, a PIX Query may be used to retrieve the cross-referenced 550 IIS identifier (if any). Figure 3 illustrates the use of the PIX query to get a pre-registered patient identifier. 551 This requires that the cross-referenced identifiers are registered using the ADT message. 552

PIX Query ITI-9 - method of retrieving IIS ID from MPI, supplying local ID as search parameter: 553 MSH|^~\&|MYIIS|MyStateIIS|SOME_SYSTEM|A_Clinic|20091105||QBP^Q23^QBP_Q21|206935|P|2.5|<CR> 554 QPD|IHE PIX Query|37374859|123456^^^MYEHR^MR|^^^MyStateIISAssigningAuthority|<CR> 555 RCP|I<CR> 556

557



5/16/2010 Page 17 of 139

558 Figure 3 Request Immunization History Using PIX 559

Note that this interaction is simplified. The initiating system sends a request for a patient identifier. The 560 request includes one identifier in a PID-3. The identity supplier looks for a matching identifier of interest 561 and returns it along with the patient name (PID-5). This information is included in the request 562 immunization history query (QBP^Q11). Assuming that the identifier used is the one in the immunization 563 history supplier, there should be a one to one match. 564 565 If the EHR system wishes to retrieve the IIS ID without previously registering the patient with the MPI, or 566 if it wishes to query the MPI by demographics for some other reason, it may use a Patient Demographics 567 Query to do so. 568 569 Figure 4 illustrates the use of PDQ to obtain an ID and how this would be used to request an immunization 570 record. The record seeker uses a Patient Demographic Query (PDQ) to a Master Person Index (MPI), 571 requesting the identifiers for the person of interest. The MPI finds the person of interest and returns the 572 demographic information and identifiers. The record seeker system uses this information to create a request 573 for immunization history, which it sends to the record source. The record source uses this information to 574 find the immunization history for the person of interest. 575

Patient Demographic Query ITI-21 - method of retrieving IIS ID from MPI for previously 576 unknown patient: 577 MSH|^~\&|MYIIS|MyStateIIS|SOME_SYSTEM|A_Clinic|20091105||QBP^Q22^|1357908642|P|2.5.1|<CR> 578 QPD|^IHE PDQ Query^ |37374859|@PID.5.1.1^[email protected]^[email protected]^[email protected]^[email protected]^Suzy 579 [email protected]^[email protected]^[email protected]^10 East Main St^[email protected]^[email protected]^GA<CR> 580 RCP|I|5^RD^HL70126|R^real-time^HL70394<CR> 581

582



5/16/2010 Page 18 of 139

583 Figure 4 Request Immunization History using PDQ 584

Note that this interaction is simplified. The client of interest would be selected and that client’s information 585 would populate the query requesting an immunization history. To be assured of success, the record source 586 system would need to have registered the person in the MPI. In that way the person ID in the record 587 source would be available in the MPI. 588 589 Figure 3 and Figure 4 illustrate that the PIX Query and Patient Demographics Query (PDQ) approaches 590 share similar flow to the original VXQ message. PIX Query followed by a RIH using the retrieved identifier 591 is similar to a VXQ/VXR. PDQ followed by an RIH replicates a VXQ/XXX and VXQ/VXR (when 592 multiple candidates are initially returned), or just a VXQ/VXR (if a single high-confidence candidate) 11 593 594 The following illustrates one of the above-described messages, the Patient Demographics Query. For 595 examples of other messages, IHE documentation12 should be consulted. 596 597 598 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): http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_6-0_Vol1_FT_2009-08-10-2.pdf - Patient Identifier

Cross Referencing (PIX) and Patient Demographics Query (PDQ) Integration Profiles http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_6-0_Vol2a_FT_2009-08-10-2.pdf - Transactions ITI-I

through ITI-28. Includes Patient Identity Feed (ITI-8), PIX Query (ITI-9) and Patient Demographics Query (ITI-21) http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_6-0_Vol2b_FT_2009-08-10.pdf - Transactions (cont'd)

ITI-29 through ITI-50. Includes Patient Identity Management (ITI-30) which is used by Pediatric Demographics Option. http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_Pediatric-Demographics_TI_2009-08-

10.pdf - Pediatric Demographics Option



5/16/2010 Page 19 of 139

MSH|^~\&| MYIIS|MyStateIIS|SOME_SYSTEM|A_Clinic |20091105||QBP^Q22^ ||P|2.5.1||||||||| <CR> 599 600 QPD|^IHE PDQ Query^ 601 |37374859|@PID.3.1^[email protected]^[email protected]^[email protected]^[email protected]^[email protected]^Q 602 [email protected]^[email protected]^Suzy [email protected]^[email protected]^[email protected]^10 East Main St^[email protected]^[email protected]^GA 603 <CR> 604 605 RCP|I|5^RD^HL70126|R^real-time^HL70394<CR> 606

607 Note that the intent of the Quantity Limited Request differs from its use in the Request Immunization 608 History query. Here it means send me batches of 5 records until you have sent them all. In the Request 609 Immunization History query it means return a list of up to five clients, but if you find more, then send me 610 an error indicating too many records found. 611 612

2.1.1. APPROACH: Returning a list of candidate clients in response to PDQ query 613 The response to a PDQ query is very similar to that of a Request for Immunization History query which 614 finds lower confidence matches. The most significant differences include: 615

No NK1 is returned. MPIs implementing the Pediatric Demographics Option use Mother's Maiden 616 name in the PID segment to provide equivalent value in patient record matching. 617

If more than the maximum records are found they are returned in batches of up to the maximum 618 records specified in the query 619

Potential use of DSC segment to support return of batches of records 620 621 The following example shows a return similar to the response message returned by the request for 622 immunization history query (above). Note that in both cases, the response message returns all information 623 that it knows about each client in the segments required for each response. 624

ITI-21 Patient Demographic Query response: 625 MSH|^~\&|SOME_SYSTEM|A_Clinic|MYIIS|MyStateIIS|20091105||RSP^K22^ |37374859|P|2.5.1||||||||| <CR> 626 MSA|AA|793543<CR> 627 QAK|37374859|AA<CR> 628 QPD|^IHE PDQ Query^|37374859|@PID.5.1.1^[email protected]^[email protected]^[email protected]^[email protected]^Suzy 629 [email protected]^[email protected]^[email protected]^10 East Main St^[email protected]^[email protected]^GA <CR> 630 PID|1||99445566^^^MYStateIIS^SR||Child^Robert^^^^^L||20050512|M<CR> 631 PID|2||123456^^^MYStateIIS^SR||Child^Robert^^^^^L||20050512|M<CR> 632

633

2.1.1.. Using PIX/PDQ in preparation for reporting an Immunization Record to an IIS 634 In the case where an IIS participates in an MPI, the EHR may use a PIX Query to retrieve the IIS identifier 635 from the MPI prior to sending an immunization record to the IIS. In the case where the IIS identifier is 636 returned by the MPI, the VXU message sent to the IIS may contain the IIS ID. 637

Using the IIS Identifier to Retrieve an Immunization History from the IIS 638 Request Immunization History (not profiled by IHE) - method of retrieving immunization history 639 by IIS ID: 640 MSH|^~\&|||||||QBP^Q11^QBP_Q11|793543|P|2.5.1|||||||||Z34^CDCPHINVS <CR> 641 QPD|Z34^Request Immunization 642 History^HL70471|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main 643 St^^Myfaircity^GA^^^L<CR> 644 RCP|I|5^RD^HL70126|R^real-time^HL70394<CR> 645 646 Request Immunization History response (not profiled by IHE but uses IIS ID retrieved either by 647 PDQ or by PIX Query): 648 MSH||MYIIS|MyStateIIS||MYEHR|20091130||RSP^K11^RSP_K11|7731029|P|2.5.1|||||||||Z32^CDCPHINVS<CR> 649 MSA|AA|793543<CR> 650



5/16/2010 Page 20 of 139

QAK|37374859|OK|Z343^request Immunization history^HL70471<CR> 651 QPD|Z34^Request Immunization 652 History^HL70471|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main 653 St^^Myfaircity^GA^^^L<CR 654 PID|1||123456^^^MYEHR^MR||Child^Robert^Quenton^^^^L|Que^Suzy^^^^^M|||||10 East Main St^^Myfaircity^GA<CR> 655 PD1||||||||||||N|20091130<CR> 656 NK1|1|Child^Suzy^^^^^L|MTH^Mother^HL70063<CR> 657 PV1||R||||||||||||||||||V03^20091130<CR> 658 ORC|RE||142324567^YOUR_EHR|||||||^Shotgiver^Fred||Ôrderwriter^Sally^^^^^^^^^^^^^^^^^^MD<CR> 659 RXA|0|1|20050725||03^MMR^HL70292|0.5|ML^ÎSO+||^New Immunization Record^NIP001<CR> 660 RXR|SC^^HL70162<CR> 661 662 VXU supplying retrieved IIS ID (not profiled by IHE but uses IIS ID retrieved either by PDQ or 663 by PIX Query): 664 MSH|^~\&|MYIIS|MyStateIIS|SOME_SYSTEM|A_Clinic|20091105||VXU^V04|206935|P|2.3.1|<CR> 665 PID|1||123456^^^MYEHR^MR||<CR> 666 RXA|0|1|20050512|20050512|08^HEPB-667 PEDIATRIC/ADOLESCENT^CVX|.5|ML^ÎSO+||||||||MRK12345||MSD^MERCK^MVX|<CR> 668 669 VXU supplying demographics (not profiled by IHE): 670 MSH|^~\&|MYIIS|MyStateIIS|SOME_SYSTEM|A_Clinic|20091105||VXU^V04|206935|P|2.3.1|<CR> 671 PID|1||123456^^^MYEHR^MR||Child^Bobbie^Q^^^^L|Que^Suzy|20050512|M|||10 East Main St^^Myfaircity^GA^^^H|||||U|<CR> 672 RXA|0|1|20050512|20050512|08^HEPB-673 PEDIATRIC/ADOLESCENT^CVX|.5|ML^ÎSO+||||||||MRK12345||MSD^MERCK^MVX|<CR> 674

675 *caveat – the preceding message examples are for illustration purposes, they have been only cursorily tested 676

677 We then map capabilities to existing IHE profiles, as depicted in Table 1. 678 679

Table 1 Capabilities Mapped to Existing IHE Profiles and Transactions 680 Use Case

Description # Capability

(EHR-S FM) IHE Profile (TF Vol I)

IHE Transaction or Content Profiles (TF Vol II)

1 Consistent time CT-ITI-1

2 Auditing ATNA-ITI-20

3 Register a patient in the eMPI ITI-8, ITI-10, ITI-30

4 Find a patient's cross-referenced identifiers

Patient Identifier Cross-Referencing (PIX) ITI-9

5 Find a patient by identifier or by demographics

Patient Demographics Query (PDQ)

ITI-21

6 Register a patient's IZ info in document form ITI-42, Immunization Content

7 Submit a patient's IZ info in document form ITI-41, Immunization Content

8 Locate a patient's IZ info in document form ITI-18

9 Retrieve a patient's IZ info in document form

Cross-Enterprise Document Sharing (XDS.b)

ITI-43, Immunization Content

10 Update a patient's IZ info in HL7 V2 form

None. Update a source via HL7 V2 IZ message

None (VXU, not profiled)

11 Locate a patient's IZ info in HL7 V2 form

None. Locate HL7 V2 IZ source None (use ITI-9 to retrieve sources from eMPI)

Manage a patient's immunizations from birth through age 18

12 Retrieve a patient's IZ info in HL7 V2 form

None. Retrieve HL7 V2 IZ message

None (VXQ or RIH13, not profiled)

13 Request Immunization History, from draft 2.5 implementation guide for immunization messaging



5/16/2010 Page 21 of 139

Use Case Description #

Capability (EHR-S FM)

IHE Profile (TF Vol I) IHE Transaction or Content

Profiles (TF Vol II)

13 Recommend next immunizations PCC "Request for Clinical Guidance" [RCG]

Immunization Content

681 Our first pass at a solution provides a good start, but fails to provide the interoperability required by the public health 682 immunization use case. One challenge is that stakeholders making use of an XDS document registry and repository 683 for sharing of immunization information cannot communicate with stakeholders using HL7 Version 2 for the same 684 purpose. A solution is provided by applying the SOA design of, which introduces mediation services. 685 686



5/16/2010 Page 22 of 139

Table 2: Introduction of Mediating Services 687

Use Case #

Capability IHE Mediating

Service IHE Profile (TF Vol I)

IHE Transaction or Content Profile (TF

Vol II) 1 Consistent time CT-ITI-1

2 Auditing Utility Services applied to all IHE Existing services

ATNA-ITI-20

3 Register a patient in the eMPI

ITI-8, ITI-10, ITI-30, ITI-44

4 Find a patient's cross-referenced identifiers

Patient Identifier Cross-Referencing (PIX)

ITI-9, ITI-45

5 Find a patient by identifier or by demographics

Identification Service

Patient Demographics Query (PDQ)

ITI-21, ITI-47

6 Register a patient's IZ info in document form


7 Submit a patient's IZ info in document form


8 Locate a patient's IZ info in document form

ITI-18

9 Retrieve a patient's IZ info in document form

Cross-Enterprise Document Sharing (XDS.b)


10 Submit a patient's IZ info in HL7 V2 form

None ( HL7 V2 IZ message) None (VXU)

11 Locate a patient's IZ info in HL7 V2 form

None (HL7 V2 IZ message) None (use ITI-9 to retrieve sources from eMPI)

12 Retrieve a patient's IZ info in HL7 V2 form

Retrieve, Locate, and Update Service

None (HL7 V2 IZ message) None (VXQ)

Man

age

a pa

tient

's im

mun

izat

ions

from

birt

h th

roug

h ag

e 18

13 Recommend next immunizations

Decision Support Service PCC "Retrieve Clinical Guidance" [RCG] (2009-2010)

Request for Clinical Guidance

688 This solution does provide the needed communication between stakeholders speaking HL7 Version 2 and 689 stakeholders using an XDS repository and registry for information sharing because we have created a Submit, Locate 690 and Retrieve service which provides the needed translation. We have also created an Immunization Decision Support 691 Service to provide immunization-specific decision support. We have created an Identification service for 692 communication between stakeholders and the eMPI. 693 694 Note also that Table 1 and Table 1 above resemble Figure 1 but rotated left 90 degrees. So far our model is entirely 695 based upon IHE profiles. We now map it to the full landscape of currently available standards, expanding the sections 696 on standards not (yet) profiled by IHE. So now we flip the table back upright to follow Table 3. We delete the Use 697 Case and Capabilities columns to focus on services and standards. 698 699 In Table 3, the services are mapped again to their IHE profiles and transactions, but also to profiles or 700 implementation guides created by other profiling organizations, and to their “base” HL7 standards. Profiles and 701 implementation guides are classified as the “interoperability layer” because they define as tightly as possible the exact 702 sequence of bits that is required to conform to the standard. When successful, such profiles and implementation 703 guides facilitate interoperability by creating an environment in which one vendor system connects “out-of-the-box” 704 with another vendor system. As we will see, such “plug-and-play” interfaces are a powerful contributor to healthcare 705



5/16/2010 Page 23 of 139

interoperability cost reduction, especially in an environment such as public health where the number of systems that 706 need to communicate is large. (An aspect of plug-and-play interfaces not elaborated here is the requirement to test 707 conformance to standards in an environment such as the IHE Connectathon.) 708 709

Table 3 Standards Overlaps for Services 710 # 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 Immunization Content (IC)

Immunization Content

Request for Clinical

Guidance

7 Profile Org AIRA/CDC

8 Interoperability Layer

Draft: 2.5 Implemen-

tation Guide

Draft: 2.5 Implemen-

tation Guide

9 Interoperability Layer

2.3.1 Implemen-

tation Guide

2.3.1 Implemen-

tation Guide

10 Standards Org HL7

11 Base Standard Version 2

Version 3 Patient Admin

messaging Version 2

Version 3 Immunization

(POIZ) messaging Version 3 Care Record CDA

Version 3 Care Record CDA

Version 3 Care Record messaging

711 Now, we reduce Table 3 further to remove overlapping standards choices. Competing standards co-exist; a good 712 solution must recognize and accommodate them since it is almost never practical to eliminate all their 713 implementations. However, to create an elegant architecture which we can analyze, we choose the best of breed here14. The 714 best of breed may be thought of as priority #1 choices, with additional choices added in as needed. 715 716 In addition to removing overlap and choosing the best of breed, we remove the detail of the standards and profiling 717 organizations that developed them, and also the detail of their base standards. Finally, we add a “task layer” service 718 called GetPatientIZStatus. GetPatientIZStatus is a composed service which may be used to hide the details of 719 identification, data retrieval and decision support when all the user wants is the end result of all three of these services. 720

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, HL7 2.3.1 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 2.3.1 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 24 of 139

Table 4 Taxonomy of Immunization Services Based on Standards 721

Task Service GetPatientIZStatus

Mediating Service Identification Retrieve, Locate, Update Decision Support

Utility Service PIX/PDQ transactions

HL7 Version 2.515 Imple-mentation

Guide VXU, RIH

Version 3 Immuni- zation (POIZ)

messaging

XDS.b, Immuni- zation

Content (IC)

Request for Clinical

Guidance, Immuni- zation

Content 722 In Table 4, we now have a specific example of the abstracted taxonomy shown in Figure 1 Meet in the Middle 723 Approach. Our taxonomy of services provides the bridge from business processes to on-the-wire, standards-based 724 plug and play interfaces. It spans different technology platforms, including messages, services, HL7 V2, HL7 V3, 725 which allows us to accommodate the variety of systems in the field, whether they are legacy or new systems, systems 726 from different geographic and political areas, and other variations. 727 728 A deployment example of our solution is given in Figure 5 Public Health Immunization Deployment Example. Our 729 patients, regional IIS and hospital, ambulatory, public health and safety net healthcare providers leverage commonly 730 accessible regional Health Information Exchange (HIE) infrastructure. The HIE provides enterprise Master Person 731 Index (eMPI) to facilitate patient identification, and a document registry and repository. The HIE provides common 732 services to the patient’s Personal Health Record (PHR), the providers’ Electronic Health Record systems (EHRs), and 733 public health’s Immunization Information System (IIS). 734

Figure 5 Public Health Immunization Deployment Example 735

Health Information Exchange

Immunization Information System (IIS)

Imm

un

iza

tio

n S

erv

ice

s

3. Patient Empowerment

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.

5. Schools and Public Health

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.

1. PHR

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

Immunization Decision

Support Service

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).

2. Primary Care Provider

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.

4. Primary Care Provider

Personal Health Record (PHR)

736 737

15 HL7 Version 2.3 messaging is commonly used today.



5/16/2010 Page 25 of 139

Public Health Immunization Scenarios 738 We now walk through our scenario and indicate which services are used to accomplish the steps of Figure 5 Public 739 Health Immunization Deployment Example above. 740 741 PHR Perspective Step #1: Parent uses Personal Health Record (PHR) to prepare for well-child visit 742 Our PHR makes a GetPatientIZStatus request. GetPatientIZStatus in turn implements a composition of: 743

1. Identification Service: to authenticate the patient and obtain identifiers necessary for retrieving the data. For 744 this, in our example it uses a PIX transaction passing a HL7 V2 message to an MPI at the regional HIE. 745

2. Retrieve, Locate and Update Service: using the retrieved identifiers and domains, the location of the 746 patient’s data is determined. The data is retrieved in HL7 Structured Document format using XDS.b and the 747 Immunization Content profile. 748

3. Decision Support Service16: A Request for Clinical Guidance HL7 CDA V3 message containing the 749 retrieved clinical information is passed and the immunization recommendation returned. CDA wrappers are 750 stripped and a small amount of mapping is done to convert Immunization Content CDA format into the 751 required Care Record message. The result is converted back to CDA before it is returned. 752

4. The results are presented to the user by PHR software. Since the data is in Structured Document format, it 753 may be displayed without parsing to the user. 754

755 Primary Care Provider Perspective Step #2: Parent and patient visit the primary care provider 756

1. GetPatientIZStatus is again used as in Step #1 to retrieve the child’s immunization information. The EHR 757 system may parse the information and store it or just display it to the user in document format. 758

2. When the provider enters the new vaccines, an Immunization Content document is created. It may or may 759 not include the vaccines just retrieved from the HIE. 760

3. The document is passed to Retrieve, Locate and Update service. The service parses it and “tees” it, sending it 761 in Immunization Content form to the HIE and in HL7 V2 form to the IIS. 762

763 Patient Perspective Step #3: The parent again uses his up-to-date PHR to determine if any shots are due. 764

1. Assuming he has kept his PHR up to date, all he has to do is call Decision Support Service, passing the PHR 765 data, to see if any shots are due now. 766

767 Primary Care Provider Perspective Step #4: Parent and patient visit the primary care provider 768

1. This step is just like Step #2. 769 770 Public Health Perspective Step #5: Schools and Public Health interact 771

1. This step represents traditional, logged-in use of an IIS. The school nurse is authorized to log directly into the 772 IIS application software. All the child’s immunization activities have been submitted to the IIS, so his record 773 is up to date. 774

2. Decision support, whether invoked locally or remotely through a call to Decision Support Service, is run to 775 assist the nurse in determining the patient’s immunization status. 776

3. To update the HIE; only Retrieve, Locate and Update need be used. If the patient were new, Identification 777 Service would also need to be used to register the patient with the HIE MPI. The HL7 V2 form of RLUS 778 may be used in keeping with IIS standards. 779

16 Protocols for Decision Support Systems are immature; we present a hypothetical protocol here.



5/16/2010 Page 26 of 139

2.1.2 Benefits 780 Our Public Health Immunization example offers these possibilities: 781

Single entry point for all EHR systems for submission of data to immunization registries. The HIE 782 infrastructure hides much of the complexity of immunization information access. The details of extending 783 access beyond the domain boundaries – for instance to another county or state – is implemented under the 784 layers of Identification and Document services and so is hidden from both the private providers and public 785 health agencies. Service consumers only have to worry about a one-hop access to the infrastructure. 786

Availability of information to the patient. In our model, with proper authentication, a patient may use the 787 same HIE services to view his own information. In the absence of reusable infrastructure, such 788 interoperability would be unaffordable for individual patients. 789

Federated Knowledge Resources. Ability to share public health and medical professional organization 790 knowledge resources. In fact, Immunization Decision Support is currently implemented within the many IIS 791 existing systems and also within many provider EHR systems. All of these systems have to interpret and 792 codify clinical rules individually and keep them up to date. Decision support rules are complex and frequently 793 updated; updating them within implementations in the field is costly and time-consuming. Common 794 implementations are possible with our model. 795

Cost Savings. Potential for powerful cost savings, as a move is made from exponential to linear cost functions 796 relative to the number of participating systems. Our reference architecture suggests a bus model in which cost 797 of complete interoperability among many participating systems is a function of the number of participating 798 systems times the number of services. Bus model alone is not sufficient to achieve such savings; in addition, 799 certain other conditions such as adherence to service definitions, common information model, and plug-and-800 play interfaces are required. It is worth noting that many of the topics discussed here lay the groundwork for 801 achieving dramatic efficiencies. For example, by contrast, a set of N cooperating systems with point-to-point 802 HL7 V2 connections can require, in the worst case, up to N * (N + 1) / 2 connections for full data exchange 803 capabilities. Although in practice, optimizations such as reuse of some connection implementations and use 804 of hub models reduce this number somewhat, for purposes of calculating complexity, the current cost model 805 is still exponential. 806

2.1.3 Discussion 807 This section shows the type of early analysis that might be done as a part of strategic-planning, a feasibility-808 study or a business-case budget-analysis. TOGAF ADM step “A-Architecture Vision”, presented in this 809 section, does not specifically fit into the HL7 SAIF ECCF. This Architecture Vision was developed in 2008-810 2009, within IHE, prior to this Immunization Management Capability (IMC) project and is shown as a 811 preamble to the SAIF ECCF to set the context of the IMC project. 812



5/16/2010 Page 27 of 139

2.2 ECCF Introduction 813

In this section, we show how to construct an HL7 SAIF ECCF Specification Stack (SS) instance from 814 traditional architectural artifacts. The ECCF goal is to ensure Working Interoperability (WI) among various 815 healthcare organizations; WI is also known as compatibility among healthcare systems. 816

817 Figure 6 Rows in the ECCF Stack 818

Figure 6 Rows in the ECCF Stack describes the layers in the ECCF stack. Thicker arrows indicate that 819 a trading partner has more specific specifications allowing trading partners to better achieve Working 820 Interoperability (WI), based on a more comprehensive Specification Stack (SS). Note that Reference Models 821 generally reside above the CIM and Implementations reside below the PSM. The columns in the ECCF stack are based 822 on the International Organization for Standardization (ISO) Reference Model for Open Distributed 823 Processing (RM-ODP17) set of viewpoints for partitioning the design of a distributed software/hardware 824 system. 825

The RMODP viewpoints18 are: 826 The Enterprise Viewpoint, which is concerned with the purpose and behaviors of the system as it 827

relates to the business objective and the business processes of the organization. 828 The Information Viewpoint, which is concerned with the nature of the information handled by the 829

system and constraints on the use and interpretation of that information. 830 The Computational Viewpoint, which is concerned with the functional decomposition of the 831

system into a set of components that exhibit specific behaviors and interact at interfaces. 832 The Engineering Viewpoint, which is concerned with the mechanisms and functions required to 833

support the interactions of the computational components. 834 17 ISO/IEC 10746-1:1998 Information technology – Open Distributed Processing: Reference Model – Part 1:

Overview, International Organization for Standardization, Geneva, Switzerland, 1998. http://www.rm-odp.net/ 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 2003.



5/16/2010 Page 28 of 139

The Technology Viewpoint, which is concerned with the explicit choice of technologies for the 835 implementation of the system, and particularly for the communications among the components. 836

The ECCF collapses the RM-ODP engineering and technology viewpoints together. The ECCF is not a 837 comprehensive enterprise-architecture; rather, we use it to specify information exchange interoperability and 838 conformance statements for documents, messages and services. The ECCF specification stack is an exchange 839 architecture; it contains three abstract layers of ECCF interoperability viewpoints. Architectural artifacts are 840 distributed across the various ECCF viewpoints (columns) and through the ECCF levels of abstraction 841 (rows). The architectural artifacts are categorized into business rules, information, behavioral and structural 842 specifications and engineering/technical platforms. In a mature19 SS, all ECCF cells are filled and artifacts across 843 rows or layers of the ECCF are consistent20 and artifacts down columns or viewpoints of the ECCF are traceable21. 844

845 Table 5 Notional Set of Architectural Artifacts within the HL7 SAIF ECCF SS is a template, which 846

shows how we might organize a typical set of architectural artifacts into an ECCF specification stack (SS). 847 Within each cell 1) we place and discuss architectural artifacts/ specifications, 2) we define conformance 848 statements, which are testable representations of assumptions that the specifications make and 3) we discuss 849 traceability within columns and consistency across layers or lack thereof. An implementation of the 850 specification asserts, as True or False, that one-or-more conformance assertions are met. SS maturity implies 851 that the SS instance is clear, complete, concise, correct, consistent and traceable within and across the SS. 852 Examining the relevant SS instances provides a traceable, consistent, scalable approach to assessing the 853 degree of difficulty and specific amount of effort required to enable trading partners to attain Working 854 Interoperability among their compatible22 systems. 855

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 29 of 139

856

Subject

Specification

Enterprise Viewpoint

“Why” Policy

Information Viewpoint

“What” Content

Computational Viewpoint

“How” Behavior

Engineering Viewpoint

“Where” Implementation

CIM (Conceptual)

Inventory of o Use Cases o Stakeholders o Capabilities-Services o Requirements o Contracts Business Scope Business Vision Business Objectives Policy & Regulations

Inventory of o Domain Entities o Roles, o Activities, o Associations. Information Models

o Conceptual o Domain

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)

Inventor of Platforms/ Environments.

PIM (Logical)

Applicable Rules Use Case Specs Governance. Technology Neutral

Standards Wireframes

of

o architectural layers o Components and o Associations

Information Models o Localized o Constrained o Project Message Content

Specifications

Use Case Specs Component. specs Interface Specs Interaction Specs Collaboration Participations Collaboration Types Function Types Interface Types Collaboration Scripts Service Contracts

Existing Platform models, Capabilities, Libraries and Versions.

PSM (Implementable)

Business Nodes Business Rules Business Procedures Business Workflow Technology Specific

Standards

Database Schemas Message Schemas Transformation

Schemas (e.g., XSD)

Automation Unit Technical Interfaces Technical Operations Orchestration Scripts

Application Specs. GUI Specifications Component Designs Deployment Topology Platform Bindings

Table 5 Notional Set of Architectural Artifacts within the HL7 SAIF ECCF SS 857 858

DISCUSSION: In Table 5 ECCF SS template, a notional set of architectural artifacts are distributed across 859 the ECCF viewpoints (columns) and through the ECCF levels of abstraction (rows). Artifacts are placed in 860 the most intuitively obvious SS cell and then are organized to facilitate traceability. Some subset or variations 861 of these architectural artifacts should populate any ECCF SS. Note that the difference between a function and a 862 service is that a service is public, reusable and has an associated Service Agreement also known as a 863 Distributed User Resource Sharing Agreement (DURSA). Technically, a well specified function and a well 864 specified service can be identical to each other. 865 866



5/16/2010 Page 30 of 139

2.2.1 ECCF Artifacts 867

868 Figure 7 identifies the referenced standards-based artifacts23, which the EHR-SD RM used to produce the IMC ECCF 869 Conceptual and Platform Independent viewpoints. By starting with the EHR-SD RM’s reusable models and 870 architectural artifacts, we were able to quickly lay out the IMC ECCF, tailored to SampleHealth’s requirements and 871 then do the platform specific viewpoints. 872

873 Figure 7 Reference Standards and Models within the HL7 SAIF (ECCF) 874

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 31 of 139

2.2.2 ECCF Working Interoperability 875

876 Figure 8 Conceptual Map of ECCF Working Interoperability 877

SS is specification Stack 878 Subject or Specification stack subject refers to a particular SS instance and defines the instance’s scope or topic. 879

We use the term “subject” to avoid the already overloaded terms “scope” and “topic.” The subject of a 880 specification varies, depending on the granularity, intent, and/or context of the specification. 881

MDA is Model Driven Architecture 882 CIM is Computationally Independent Model (Conceptual) 883 PIM is Platform-Independent Model (Logical) 884 PSM is Platform-Specific Model (Implementable) 885

Figure 8 shows the relationship between the RM-ODP viewpoints and Working Interoperability. 886

2.2.3 ECCF Traceability 887 Adding WI fidelity, traceability among architectural artifacts should be addressed within or referenced by an ECCF SS. 888 The relevancy of the Platform Specific Model (PSM) level statements substantially increases when the conformance 889 statements are traceable derivatives from conformance statements at the Platform-Independent Model (PIM) and 890 Computationally Independent Model (CIM) levels of the Specification Stack (SS) instance. The more mature24 the SS 891 instance, the greater the conformance value. Figure 9 is an abstract view of traceability, which we will make more 892 specific within our IMC ECCF SS presented below. As a project advances, detailed requirements, architecture, design, 893 deployment, test and certification traceability should be audited at Software Development Lifecycle (SDLC) 894 configuration baselines, which are typically established at a System Requirements Review (SRR), Preliminary Design 895 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 32 of 139

Review (PDR), Critical Design Review (CDR), and Test Readiness Review (TRR). At each of these reviews, a 896 successful baseline should be established and the traceable configuration audit should be one of a review’s exit 897 criterion. 898

899 Figure 9 IS10 IRM HITSP Constructs Mapped to Standards 900

2.2.4 ECCF Glossary and Traceability Meta-Model 901 This section presents a notional set of architectural artifacts. Some subset or variations of these should populate any 902 ECCF SS. The following list provides definitions for the notional value set of architectural artifacts shown in Table 5. 903 - Accountability defines “Who does what to whom.” [SAIF BF] 904 - Automation Unit describes the implementation of a single service, several services, or an application. It is itself a specialized form of 905

versioned-specification. It consists of a collection of deployable artifacts, which can be decomposed into distributed Automation Units. 906 - Base Standard: is a standard capable of fulfilling a discrete function within a single category produced and maintained by a single 907

standards organization. Examples include HL7 v2.x, SNOMED-CT. [HITSP TN904] 908 - Behavior is sets of actions and constraints on when the actions can occur. [SAIF BF] 909 - Capability (CAP): is an implementable business service that addresses a focused business need by supporting stakeholder requirements 910

and business processes. A CAP Specifies required optional and required secure, interoperable Information Exchanges between System 911 Roles using HITSP constructs. A CAP identifies how to claim conformance, when options are resolved by an IS or implementation. 912 [HITSP TN904] 913

- Component: is a construct that defines the set of data elements, structures, relationships, constraints and terminology needed to support 914 specific reusable information content. A Component may also express constraints on base or composite standards, examples include the 915 Lab Result Message and Lab Result Document. [HITSP TN904] 916

- Construct: is a specification based on harmonized interoperability standards. HITSP defines Transaction, Transaction Package, Service 917 Collaboration and Component constructs. [HITSP TN904] 918

- Contract is an agreement covering part of the collective behavior of any number of role instances. [SAIF BF] 919 - Conceptual Functional Service Specification (CFSS) is the formal specification of a Conceptual Functional Model [NIH] (e.g., EHR 920

System Design Functional Model). 921 - Collaboration Participation model specifies the system roles and their information exchanges for a system capability (e.g., document 922

management), which may support one-or-more system functions (e.g., patient identification, registry query, repository request). [SAIF BF] 923 - Collaboration or Orchestration scripts define threads-of-execution, which achieve meaningful system or business functions. 924



5/16/2010 Page 33 of 139

- Collaboration types might be some combination of Distributed, Client-Server, Federated, Synchronous or Asynchronous etc. [SAIF BF] 925 - Composite Standard: is a grouping of coordinated base standards, often from multiple standards organizations, maintained by a single 926

organization. Examples include IHE Information Technology Infrastructure XDS Integration Profile. [HITSP TN904] 927 - Conceptual data model is developed based on the data requirements for the application that is being developed, perhaps in the context of 928

an activity model. The data model will normally consist of entity types, attributes, relationships, integrity rules, and the definitions of those 929 objects. 930

- Data are facts, observations, measures or conclusions recorded about a subject of interest (often termed a unit of observation), at a 931 particular place through a particular process for a particular purpose. Each fact can be termed a data element and is meaningless unless the 932 context in which it was recorded is known. A Data Model is a means of categorizing and grouping data items (persons, places, objects, 933 processes) of interest. However, in a data model, a single piece of data should be identified only once and be associated with the specific 934 subject it describes. This level of discipline is required to appropriately specify requirements for information systems. Information systems 935 have a structure just as buildings and bridges do. Therefore, they must be constructed with the same attention to design to achieve the 936 same high degree of quality and reliability that is expected of physical structures. [Conceptual Health Data Model v2.3, Canadian Institute 937 for Health Information] 938

- Data Requirement (DR): defines requirements for all or part of the IER exchange content as a set of data elements with specific 939 semantic details. [HITSP TN904] 940

- Deployment Topology is the allocation of Platforms and Capabilities and capability System Roles to Systems. 941 - Harmonization Framework: defines the terms, concepts and their relationships within a HITSP Interoperability Specification (IS), 942

Capability (CAP), Component (C), Transaction (T), Transaction Package (TP) and Service Collaboration (SC). 943 - Information is a set of data that has been collated, interpreted and presented to be meaningful to a particular audience for a particular 944

purpose. Information for one purpose can be recorded and/or transformed to become data used as input into a new process to create 945 information for a different purpose. Transformation processes may be automated or be the result of human judgment. An Information 946 Model then, is a means of classifying information topics of interest. A Data Model defines the specific subjects and the facts about them. 947 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 948 essentially derived by any transformation process. [Conceptual Health Data Model v2.3, Canadian Institute for Health Information] 949

- Information Exchange Requirement (IER): is a business requirement described in terms of Exchange Content, Exchange Action, and 950 Systems involved in the exchange and Exchange Attributes. [HITSP TN904] 951

Exchange Content: describes the information to be communicated in business terms 952 Exchange Action: describes the interaction that communicates the Exchange Content between the Systems 953 Exchange Attributes: are parameters about an Information Exchange. Examples are constraints, conditions 954 and triggers 955 IER Identifier: is an optional IER name and number, which is local to an IS and valid within the scope of an 956 IS 957

- Exchange Architecture: defines the fundamental topologies that can be used in implementing the HITSP Interoperability Specifications 958 in systems (e.g., EHR systems directly connected or connected to Health Information Exchanges (HIEs) and HIEs connected to other 959 HIEs. [HITSP TN904] 960

- Functional Profile is a collection of Proposed Operations that align with some intended usage patterns. Often, these are characterized by 961 quality considerations, such as security or performance, though they may not be so. 962

- Function Types are Direct Care, Supportive Care, Infrastructure, etc. and their sub-types. See EHR System Functional Model. 963 - Harmonization Request: defines business or functional needs, within a workflow, and sets context and conditions for the 964

Interoperability Specification. Behavioral specifications of functional needs or capabilities may be structured as Use Cases, Scenarios, 965 Business Process Models or other forms. [HITSP TN904] 966

- Implementation Specifications bind environment and platforms (e.g., J2EE, .NET, etc) to Platform Independent specifications. [SAIF 967 BF] 968

- Interaction is something that happens between a role’s interfaces and other roles in its environment. [SAIF BF] 969 - 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 970

constraints that define when the identified interactions can occur. [SAIF BF] 971 - Interface: is the set of features and obligations that support Information Exchanges for a HITSP system. Interfaces and Information 972

Exchanges between interfaces are specified by HITSP Constructs, including Service Collaborations for example, Content Creator, 973 Document Consumer, Eligibility Information Receiver and Audit Record Repository. [HITSP TN904] 974

- Interface Design Specifications includes the content, transport, privacy and security standards and protocols for system data exchanges. 975 Software engineering best-practices recommend an “Information Hiding” approach with a separate external specification for use and 976 internal information and behavior specification for implementation. 977

- Interaction Specifications define information exchange Transport, Content, Constraints, Systems or System Roles. [SAIF BF] 978 - Interface Types are Message, Document or Service. [SAIF ECCF] 979 - Interoperability Specification (IS): is organized by scenarios, Capabilities and integrates and constrains Constructs to specify the 980

interoperability needs of one or more business processes. [HITSP TN904] 981 - Role is a cohesive set of capabilities, capacities, or competencies abstracted as behaviors, which can be invoked at run-time. 982 - Service definition contains the terms for information exchange, providing the service’s technical constraints and requirements as well as 983

any semantic information needed to consume the service. It is comprised of two parts: (1) an abstract portion; and (2) a concrete portion. 984 The abstract portion describes the functionality of the service. It includes a series of technology-independent elements: the interface, 985



5/16/2010 Page 34 of 139

operations, operation semantics, and data structure definitions. The concrete portion describes how to access the service. It effectively 986 designates how the abstract interface connects to technology that implements the service. Note that there can be more than one concrete 987 portion corresponding to a single abstract portion. This ensures that the means used to access the service – such as web services, messaging 988 or direct invocation – can be independent of the abstract service definition. The Service Implementation is the core logic in support of the 989 service definition. It is essentially the code behind the service, often written in an application language like Java, .Net or C++. [IHE SOA 990 Whitepaper] 991

- Service Collaboration (SC): is the composition of Transaction, Transaction Package, or Component constructs into a reusable workflow, 992 primarily at the infrastructure level, for example HITSP/SC115 HL7 Messaging Service Collaboration. [HITSP TN904] 993

- Service contracts might include Information model extracts for semantic interoperability, role-based security, costs, etc. In NHIN this is 994 known as a Distributed User Resource Sharing Agreement (DURSA). 995

- Stakeholder: is defined as a person or organization that uses or benefits from systems that interoperate. [HITSP TN904] 996 - System: is an IT software application that plays an initiating or responding role in one or more Information Exchanges addressed by a 997

Interoperability Specification or Capability. [HITSP TN904] 998 - System Role: is a set of closely related capability behaviors, which satisfy a business need. A Capability has two or more System Roles, 999

such as Order Placer; Order Filler; Specimen Analyzer. Behaviors are the set of prescribed and optional Information Exchanges among 1000 systems roles. In an IS or implementation, a system supports one or more capability system roles from each capability it supports. [HITSP 1001 TN904] 1002

- Transaction (T): is a logical grouping of data exchanges and transport methods that must all succeed or fail as a group. Examples are the 1003 Query Lab Result or Send Lab Result. [HITSP TN904] 1004

- Transaction Package (TP): is a logical grouping of two or more Transactions, Transaction Packages, and/or composite standards used 1005 to fulfill Information Exchange Requirements (IERs). A Transaction Package is not required to succeed or fail as a whole. Examples 1006 include the Record Locator Service and Entity Identification Service. [HITSP TN904] 1007

- Technical Interface is a technology specific interface provided by an Automation Unit. . 1008 - Technical Operation is a specific function provided by a particular Technical Interface, which is technology specific. 1009 - Use Cases can be specified textually as a sequence of Scenarios, Events and Actions. They can also be specified as Business Process 1010

Models. 1011 - Wireframe is a basic visual guide used in interface design to suggest the structure of a website and relationships between its pages. A 1012

system component wireframe is a similar illustration of the layout of fundamental elements in the component or system and their 1013 interfaces. [adapted from Wikipedia] 1014

1015 Figure 10 ECCF SS Traceability Meta Model shows the associations among the set of notional architectural 1016 artifacts shown in Table 5 Notional Set of Architectural Artifacts within the HL7 SAIF ECCF SS. This can 1017 be a many-to-one mapping because the granularity of a particular architectural artifact may not match the 1018 ECCF SS granularity. This is a typical set of architectural products. Obviously, variations among and within 1019 architectural artifacts may replace the ones listed in the notional set used in this section. 1020 1021

TBD 1022 Figure 10 ECCF SS Traceability Meta Model 1023

1024

2.2.5 ECCF Implementation Guide 1025 A mature ECCF SS shall contain a clear, complete, concise, correct, consistent and traceable set of architectural 1026 artifacts, organized as follows: 1027 1. The ECCF Conceptual Enterprise-Business-Viewpoint defines the business and reference context. The Enterprise-1028

Business-Viewpoint is concerned with the purpose and behaviors of the system as it relates to the business objective, 1029 environment and the business processes of the organization. This Viewpoint answers the question “why” and 1030 refers to policy. This Viewpoint is primarily useful to project sponsors, project managers, program directors, IT 1031 directors and requirements analysts. This Viewpoint might typically contains some combination of: 1032

Inventory of 1033 Use Cases 1034 Stakeholders 1035 Capabilities-Services 1036 Requirements\Contracts 1037

Business Scope 1038



5/16/2010 Page 35 of 139

Business Vision 1039 Business Objectives 1040 Policy & Regulations 1041

2. The ECCF Conceptual Information-Viewpoint is defined by the domain analysis information model. The Information-1042 Viewpoint is concerned with the nature of the information handled by the system and constraints on the use and 1043 interpretation of that information. This Viewpoint answers the question “what” and refers to information 1044 content. This Viewpoint is primarily useful to clinicians and clinical analysts. This Viewpoint might typically 1045 contains some combination of: 1046

Inventory of 1047 Domain Entities, 1048 Roles, 1049 Activities and 1050 Associations. 1051

Information Model 1052 Conceptual 1053 Domain 1054

3. The ECCF Conceptual Computational Viewpoint is defined by collaboration analysis (e.g., BPM and UML sequence or 1055 activity diagrams), functional profiles, service roles and relationships. The computational viewpoint is concerned 1056 with the functional decomposition of the system into a set of components that exhibit specific behaviors and 1057 interact at interfaces. This Viewpoint answers the question “how” and references behavioral specifications. This 1058 Viewpoint is primarily useful to business analysts and functional analysts. This Viewpoint might typically contains 1059 some combination of: 1060

Inventories of 1061 Capabilities-Components, 1062 Functions-Services 1063

Requirements 1064 Accountability 1065 Roles 1066 Behaviors 1067 Functional Profiles 1068 Interactions 1069 Interfaces 1070 Contracts 1071

Conceptual Functional Service Specifications (CFSS) 1072 4. The ECCF Conceptual Engineering-Viewpoint is defined by existing platform capabilities. The Engineering-Viewpoint 1073

is concerned with the mechanisms and functions required to support the interactions of the computational 1074 components. This ECCF Viewpoint may overlap with the RM-ODP technology viewpoint, which is concerned 1075 with the explicit choice of technologies for the implementation of the system, and particularly for the 1076 communications among the components. This Viewpoint is primarily useful to enterprise architects. This 1077 Viewpoint answers the question “where” and refers to implementation environments. This Viewpoint might 1078 typically contains some combination of: 1079

Inventory of Software Platforms/ Environments. 1080 5. The ECCF Platform-Independent Enterprise-Business-Viewpoint defines the business and reference context. The 1081

Enterprise-Business-Viewpoint is concerned with the business governance of the system as it relates to the 1082



5/16/2010 Page 36 of 139

business objectives and the business processes of the organization. This Viewpoint answers the question “why” 1083 and refers to policy. This Viewpoint is primarily useful to project managers and business process experts. This 1084 Viewpoint might typically contains some combination of: 1085

Applicable Rules 1086 Use Case Specs 1087 Governance. 1088 Technology Neutral Standards 1089 Wireframes of 1090

architectural layers 1091 components and 1092 Associations 1093

6. The ECCF Platform-Independent Information-Viewpoint is defined by the project information model. The Information-1094 Viewpoint is concerned with the nature of the information handled by the system and constraints on the use and 1095 interpretation of that information. This view answers the question “what” and refers to information content. This 1096 Viewpoint is primarily useful to clinical informaticists. This Viewpoint answers the question “where” and refers to 1097 implementation environments. This Viewpoint might typically contains some combination of: 1098

Information Model 1099 Localized Information Model 1100 Constrained Information Model 1101 Project Information Model 1102

Message Content Specifications 1103 7. The ECCF Platform-Independent Computational-Viewpoint is defined by collaboration analysis (e.g., UML sequence 1104

diagrams), functional profiles, service roles and relationships. The Platform-Independent Computational-1105 Viewpoint is concerned with the functional decomposition of the system into a set of components that exhibit 1106 specific behaviors and interact at interfaces. This Viewpoint answers the question “how” and references 1107 behavioral specifications. This viewpoint is primarily useful to System Engineers and Business Process Modelers. 1108 This Viewpoint might typically contains some combination of: 1109

Use Case Specs 1110 Component specs 1111 Interface Specs 1112 Interaction Specs 1113 Collaboration Participations 1114 Collaboration Types 1115 Function Types 1116 Interface Types 1117 Collaboration Scripts 1118 Service Contracts 1119

8. The ECCF Platform-Independent Engineering-Viewpoint is defined by existing platform capabilities. The Engineering-1120 Viewpoint is concerned with the mechanisms and functions required to support the interactions of the 1121 computational components. This ECCF viewpoint may overlap with the RM-ODP technology viewpoint, which 1122 is concerned with the explicit choice of technologies for the implementation of the system, and particularly for 1123 the communications among the components. This viewpoint answers the question “where” and refers to 1124 implementation environments. This viewpoint is of primary interest to Application Architects. This Viewpoint 1125 might typically contains some combination of: 1126



5/16/2010 Page 37 of 139

Existing Platform models, Capabilities, Libraries and Versions. 1127 9. The ECCF Platform-Specific Enterprise-Business-Viewpoint defines the business and reference context. The Enterprise-1128

Business-Viewpoint is concerned with the business or reference context, purpose and behaviors of the system as 1129 it relates to the business objective and the business processes of the organization. This viewpoint answers the 1130 question “why” and refers to policy. This viewpoint is primarily useful to managers, compliance staff and 1131 auditors. This Viewpoint might typically contains some combination of: 1132

Business Nodes 1133 Business Rules 1134 Business Procedures 1135 Business Workflow 1136 Technology Specific Standards 1137

10. The ECCF Platform-Specific Information-Viewpoint is defined by localized information models. The Information-1138 Viewpoint is concerned with the nature of the information handled by the system and constraints on the use and 1139 interpretation of that information. This viewpoint answers the question “what” and refers to information content. 1140 This viewpoint is primarily useful to information modelers. This viewpoint is primarily useful to managers, 1141 compliance staff and auditors. This Viewpoint might typically contains some combination of: 1142

Database Schemas 1143 Message Schemas 1144 Transformation Schemas (e.g., XSD) 1145

11. The ECCF Platform-Specific Computational Viewpoint is defined by collaboration analysis (e.g., UML sequence 1146 diagrams), functional profiles, service roles and relationships. The computational viewpoint is concerned with the 1147 functional decomposition of the system into a set of components that exhibit specific behaviors and interact at 1148 interfaces. This viewpoint answers the question “how” and references behavioral specifications. This viewpoint is 1149 primarily useful to system integrators and solution and solution architects. This Viewpoint might typically 1150 contains some combination of: 1151

Automation Unit 1152 Technical Interfaces 1153 Technical Operations 1154 Orchestration Scripts 1155

12. The ECCF Platform-Specific Engineering-Viewpoint is defined by existing platform capabilities. The Engineering-1156 Viewpoint is concerned with the mechanisms and functions required to support the interactions of the 1157 computational components. This ECCF viewpoint may overlap with the RM-ODP technology viewpoint, which is 1158 concerned with the explicit choice of technologies for the implementation of the system, and particularly for the 1159 communications among the components. This viewpoint answers the question “where” and refers to 1160 implementation environments. This viewpoint is primarily useful to application developers. This Viewpoint might 1161 typically contains some combination of: 1162

Application Specifications 1163 GUI specifications 1164 Deployment Topology or Execution Context 1165 Platform Bindings 1166

2.3 Conceptual Enterprise-Business-Viewpoint 1167



5/16/2010 Page 38 of 139

The ECCF Conceptual Enterprise-Business-Viewpoint defines the business and reference context. The Enterprise-Business-1168 Viewpoint is concerned with the purpose and behaviors of the system as it relates to the business objective, 1169 environment and the business processes of the organization. This Viewpoint answers the question “why” and refers 1170 to policy. This Viewpoint is primarily useful to project sponsors, project managers, program directors, IT directors 1171 and requirements analysts. The ECCF Conceptual Enterprise-Business-Viewpoint typically contains: 1172

Inventory of 1173 Use Cases 1174 Stakeholders 1175 Capabilities-Services 1176 Requirements\Contracts 1177

Business Scope 1178 Business Vision 1179 Business Objectives 1180 Policy & Regulations 1181

2.3.1 Policy and Regulation 1182

The following have impact on this project: 1183 The Federal Health IT Policy Committee, which makes recommendations to the National Coordinator for 1184

Health Information Technology (HIT) on a policy framework for the development and adoption of a 1185 nationwide health information infrastructure, including standards for the exchange of patient medical 1186 information. The American Recovery and Reinvestment Act of 2009 (ARRA) provides that the HIT Policy 1187 Committee shall at least make recommendations on standards, implementation specifications, and 1188 certifications criteria in eight specific areas: 1189

o Technologies that protect the privacy of health information 1190 o A nationwide health information technology infrastructure 1191 o The utilization of a certified electronic record for each person in the US by 2014 1192 o Technologies that support accounting of disclosures made by a covered entity 1193 o The use of electronic records to improve quality 1194 o Technologies that enable identifiable health information to be rendered unusable/unreadable 1195 o Demographic data collection including race, ethnicity, primary language, and gender 1196 o Technologies that address the needs of children and other vulnerable populations 1197

The Federal Health IT Standards Committee, which makes recommendations to the National Coordinator 1198 for Health Information Technology (HIT) on standards, implementation specifications, and certification 1199 criteria for the electronic exchange and use of health information. Initially, the HIT Standards Committee 1200 focused on the policies developed by the Health IT Policy Committee’s initial eight areas. Within 90 days of 1201 the signing of ARRA, the HIT Standards Committee developed a schedule for the assessment of policy 1202 recommendations developed by the HIT Policy Committee, to be updated annually. In developing, 1203 harmonizing, or recognizing standards and implementation specifications, the HIT Standards Committee 1204 also provided for the testing of same by the National Institute for Standards and Technology (NIST). 1205

HIPAA25 - The Health Insurance Portability and Accountability Act of 1996 (HIPAA) required the 1206 Secretary of the U.S. Department of Health and Human Services (HHS) to develop regulations 1207 protecting the privacy and security of certain health information.1 To fulfill this requirement, HHS 1208

25 For additional information, see http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/index.html



5/16/2010 Page 39 of 139

published what are commonly known as the HIPAA Privacy Rule and the HIPAA Security Rule. 1209 The Privacy Rule, or Standards for Privacy of Individually Identifiable Health Information, establishes 1210 national standards for the protection of certain health information. The Security Standards for the 1211 Protection of Electronic Protected Health Information (the Security Rule) establish a national set of security 1212 standards for protecting certain health information that is held or transferred in electronic 1213 form. The Security Rule operationalizes the protections contained in the Privacy Rule by addressing 1214 the technical and non-technical safeguards that organizations called “covered entities” must put in 1215 place to secure individuals’ “electronic protected health information” (e-PHI). The HIPAA/EDI 1216 provision took effect on October 16, 2003. On January 1, 2012 the newest version 5010 becomes 1217 effective, replacing the version 4010. This allows for the larger field size of ICD-10-CM as well as 1218 other improvements. 1219

The HITECH Act, part of the 2009 economic stimulus package (ARRA) passed by the US 1220 Congress, aims at inducing more physicians to adopt EHR. Title IV of the act promises incentive 1221 payments to those who adopt and use "certified EHRs" and, eventually, reducing Medicare 1222 payments to those who do not use an EHR. Funding for EHR incentives is also added to the 1223 Medicaid system. In order to receive the EHR stimulus money, the HITECH act (ARRA) requires 1224 doctors to also show "meaningful use" of an EHR system. 1225

HITECH Standards & Certification Criteria Interim Final Rule (IFR) on an initial set of 1226 standards, implementation specifications, and certification criteria for adoption by the HHS 1227 Secretary was issued on December 30, 2009, with a request for comments. This Interim Final Rule 1228 represents the first step in an incremental approach to adopting standards, implementation 1229 specifications, and certification criteria to enhance the interoperability, functionality, utility, and 1230 security of health IT and to support its meaningful use. The certification criteria adopted in this 1231 initial set establish the required capabilities and related standards that certified electronic health 1232 record (EHR) technology will need to include in order to, at a minimum, support the achievement 1233 of the proposed meaningful use Stage 1 (beginning in 2011) by eligible professionals and eligible 1234 hospitals under the Medicare and Medicaid EHR incentive programs. 1235

HITSP/ TN 900 - Securities and Privacy Technical Note provides the context for use of the HITSP 1236 Security and Privacy constructs, based on the American Health Information Community (AHIC) 1237 Use Cases. It includes a design map of existing standards and specifications that will be used to 1238 meet the stated requirements of the Use Cases. It references the Requirements, Design and 1239 Standards Selection document which describes the process by which the Use Cases were analyzed, 1240 candidate standards were identified and the design developed. 1241

2.3.1. Privacy & Security Requirements 1242 HITSP TN900 specifies the constructs to support a wide variety of security and privacy policies and technical 1243 frameworks. Consistent with the HITSP Technical Committee Terms of Reference, HITSP has not attempted to 1244 resolve privacy or security policy issues, risk management, healthcare application functionality, operating systems 1245 functionality, physical control specifications, or other low-level specifications. This approach is crucial because of the 1246 variety of requirements that the HITSP Security and Privacy constructs will be called on to address. 1247 The United States has an extensive body of federal and state laws and regulations that define the security and privacy 1248 requirements for collecting, creating, maintaining, using, disclosing and disposing individually identifiable health 1249 information. Among them, at the federal level are: 1250



5/16/2010 Page 40 of 139

American Recovery and Reinvestment Act (ARRA) of 2009, including Health Information Technology for 1251 Economic and Clinical Health (HITECH) 1252 HIPAA Privacy Regulations (45 CFR § 160 and 164 Part E) 1253 HIPAA Security Regulations (45 CFR § 160 and 164 Part C) 1254 Confidentiality of Alcohol and Drug Abuse Patient Records (42 CFR Part 2) 1255 Family Education Rights and Privacy Act (FERPA) 1256 Privacy Act of 1974 1257 Right to Financial Privacy Act (1978) 1258 Privacy Protection Act of 1980 1259 Electronic Communications Privacy Act (1986) 1260 Communications Assistance for Law Enforcement Act of 1994 1261 Telecommunications Act of 1996 1262 Financial Modernization Act (Gramm-Leach-Bliley Act) (2000) 1263 Emergency Supplemental Appropriations Act for Defense, the Global War on Terror and Tsunami Relief 1264 (Real ID Act) (2005) 1265

At the state level, numerous state health information laws and regulations exist with different degrees of detail and 1266 granularity, some more stringent (thus, not preempted) by the overarching HIPAA Security and Privacy regulations. 1267 These laws and regulations generally apply to the: 1268

Holder of the data 1269 User (requester) of the data 1270 Data itself 1271 Purpose of the use or disclosure of the data 1272 Timing of the use and disclosure of the data 1273 Methods and mechanisms used to collect, maintain, use and disclose data 1274

Several of them also define and assign specific rights to consumers with respect to controls consumers can exercise 1275 over the collection, access, use and disclosure of their health information. 1276 1277 In developing the HITSP Security and Privacy constructs, HITSP considered a set of overarching principles and 1278 concepts, derived from an analysis of major federal and common state laws and regulations. They included: 1279 1280 Privacy Principles 1281

Consumer consent requirements (including the concepts of consent and authorization, whether they are 1282 considered one and the same in some regulations, or treated differently in others) 1283 Consumer’s ability to provide directives on: 1284 The collection, access, use and disclosure of his/her health information 1285 What information is collected, accessed, used, disclosed 1286 By whom 1287 To whom 1288 For what purpose(s) 1289 When 1290 For how long 1291 Consumer’s ability to modify or revoke directives 1292 Patient privacy rights, such as those identified in the HIPAA Privacy regulations, including the right to: 1293 Receive a Notice of Privacy Practices 1294 Access individually identifiable health information for review and/or copy 1295



5/16/2010 Page 41 of 139

Request amendments to health information 1296 Request privacy protections to health information including the right to request restrictions on the use and 1297 disclosure of health information and the right to request confidential communications from a covered entity 1298 Request an accounting of certain disclosures that a covered entity has made of their protected health 1299 information (within the context of HIPAA) 1300 File a complaint about privacy issues 1301

1302 Privacy requirements: 1303

Various degrees of sensitive health information 1304 Minimum necessary 1305 Accounting of disclosure 1306 Procedures for ensuring confidential communications are being done (i.e., sending an electronic message with 1307 results to the patient at an alternative location) 1308 Deidentification (anonymization) of information, when necessary 1309 Verification requirements of the identity and authority of individual requesting health information prior to 1310 disclosure (if not known by the entity disclosing the information), including documentation of such identify 1311 and authority 1312 Mitigation of harm, in the event of a use or disclosure done in violation of privacy requirements or 1313 organization’s own policies and procedures 1314

1315 Security Principles 1316

Availability of health information – information is available when and where needed 1317 Confidentiality – information is not accessed, used, disclosed by non-authorized individuals or entities 1318 Integrity - Information content not alterable except under authorized circumstances 1319 Accountability – ensuring that those collecting, accessing, using or disclosing health information are 1320 accountable for their roles and responsibilities 1321 Identification – of users and subjects of health information, as appropriate and applicable 1322 Authentication – of users and subjects of health information, as appropriate and applicable 1323 Authorization – of those identified and authenticated, to allow them to perform the functions they are 1324 specifically authorized to perform with the health information they are collecting, accessing, using or 1325 disclosing 1326 Access Control - only authorized persons can access health information for authorized purposes 1327 Attribution/nonrepudiation - actions taken are reliably traceable 1328 Auditability – controls to identify, record and report and monitor health information events 1329 Secure communication – between entities exchanging health information 1330 Time recording – methods to control time of events in a consistent manner 1331

Through an iterative process, these overarching concepts where identified and further refined in conjunction with the 1332 review of the first set of AHIC Use Cases. Further refinement of the existing constructs will continue, and new 1333 potential constructs will be identified and defined in the future, as new Use Cases are presented to HITSP. 1334

Consistent with the HITSP Technical Committee Terms of Reference, the work of the Committee does not 1335 define or attempt to resolve security and privacy policy issues, risk management, healthcare application functionality, 1336 operating systems functionality, physical control specifications, or other low-level specifications. The HITSP Security 1337 and Privacy constructs were designed to support a wide range of federal, state, local, and institutional policies. 1338 Work is being done elsewhere, and through other national and regional efforts to identify, define and address security 1339 and privacy related policy issues. 1340



5/16/2010 Page 42 of 139

These efforts include: 1341 The Health Information Technology Policy Committee 1342

http://healthit.hhs.gov/portal/server.pt?open=512&objID=1269&parentname=CommunityPage&parentid=2&mode=2&in_hi_userid=10741&cache1343 d=true 1344

Health Information Technology Standards Committee 1345 http://healthit.hhs.gov/portal/server.pt?open=512&objID=1271&parentname=CommunityPage&parentid=3&mode=2&in_hi_userid=10741&cache1346 d=true 1347

National eHealth Collaborative 1348 http://www.nationalehealth.org/ 1349

The American Health Information Community’s Confidentiality (AHIC), Security and privacy Workgroup 1350 http://www.hhs.gov/healthit/community/background/ 1351

The Health Information Security and Privacy Collaborative (HISPC) 1352 http://healthit.ahrq.gov/portal/server.pt?open=514&objID=5562&mode=2&holderDisplayURL=http://prodportallb.ahrq.gov:7087/publishedconten1353 t/publish/communities/a_e/ahrq_funded_projects/rti_public_page/main.html 1354 http://www.rti.org/page.cfm?objectid=09E8D494-C491-42FC-BA13EAD1217245C0 1355

Certification Commission for Healthcare Information Technology (CCHIT), utilizing security and privacy 1356 standards in developing certification criteria 1357

http://www.cchit.org 1358 Office for Civil Rights (OCR), HIPAA Privacy 1359

http://www.hhs.gov/ocr/hipaa/ 1360 Agency for Healthcare Research and Quality (AHRQ), Health Information Technology Program 1361

http://healthit.ahrq.gov/ 1362 Centers for Disease Control and Prevention (CDC), Public Health Information Network (PHIN) 1363

http://www.cdc.gov/phin/ 1364 Centers for Disease Control and Prevention (CDC), BioSense 1365

http://www.cdc.gov/biosense/ 1366 Health Resources and Services Administration (HRSA) 1367

http://www.hrsa.gov/healthit/ 1368 Substance Abuse and Mental Health Services Administration (SAMHSA) 1369

http://www.samhsa.gov 1370 Indian Health Services (IHS) 1371

http://www.ihs.gov/CIO/EHR/ 1372 U.S. Department of Defense (DoD) 1373

http://www.defenselink.mil 1374 U.S. Department of Veterans Affairs (VA) 1375

http://www.va.gov 1376 NCVHS – National Committee on Vital and Health Statistics (NCVHS) 1377

http://www.ncvhs.hhs.gov 1378 National Governors Association’s State Alliance for e-Health (NGA) 1379

http://www.nga.org/portal/site/nga/menuitem.1f41d49be2d3d33eacdcbeeb501010a0/?vgnextoid=5066b5bd2b991110VgnVCM1000001a01010aRC1380 RD 1381 The variability in health information security and privacy federal and state laws and regulations, and business policies 1382 and practices across the country, poses significant challenges to the development of a common set of security and 1383 privacy constructs. With this in mind, HITSP used an approach based on the identification of a core set of 1384 overarching policy concepts, and the establishment of a minimum common base set of requirements that could be 1385 applied to different health information exchange scenarios. 1386 In looking at the various candidate standards for Security and Privacy Constructs, HITSP identified a group of 1387 standards that may be used in guiding the implementation of the constructs. These are listed in Table 6 Guidance 1388 Standards below: 1389



5/16/2010 Page 43 of 139

1390 Table 6 Guidance Standards 1391

Standard Reference

ISO 27799:Health informatics: Security management in health using ISO 17799 www.iso.org

ASTM E1869: Standard Guide for Confidentiality, Privacy, Access, and Data Security Principles for Health Information Including Electronic Health Records

www.astm.org

ASTM E1986: Standard Guide for Information Access Privileges to Health Information

www.astm.org

ASTM E2086: Standard Guide for Internet and Intranet Healthcare Security www.astm.org

ASTM E2085: Standard Guide on Security Framework for Healthcare Information www.astm.org

WS-I: Security Challenges, Threats and Countermeasures Version 1.0 www.wsi.org

ISO 15408: Common Criteria Toolkit www.commoncriteriaportal.org

ASTM E2595 PMI: Privilege Management Infrastructure www.astm.org

ASTM E1985: Standard Guide for User Authentication and Authorization www.astm.org

ASTM E1987: Standard Guide for Individual Rights Regarding Health Information www.astm.org

NIST Special Publications (800 Series) csrc.nist.gov

NIST Federal Information Processing Standards (FIPS) Publications http://csrc.nist.gov/publications/PubsFIPS.html

2.3.1. HITECH Meaningful Use Objectives and Criteria 1392 There are 25 specific HITECH Meaningful Use (MU) objectives and criteria for the 2011 MU Stage I: 1393

1. Objective: Use CPOE (Computerized Physician Order Entry) 1394 Measure: CPOE is used for at least 80 percent of all orders 1395

2. Objective: Implement drug-drug, drug-allergy, drug- formulary checks 1396 Measure: The EP (Eligible Provider) has enabled this functionality 1397

3. Objective: Maintain an up-to-date problem list of current and active diagnoses based on ICD-9-CM or SNOMED CT® 1398 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 1399 structured data. 1400

4. Objective: Generate and transmit permissible prescriptions electronically (eRx). 1401 Measure: At least 75 percent of all permissible prescriptions written by the EP are transmitted electronically using certified EHR 1402 technology. 1403

5. Objective: Maintain active medication list. 1404 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 1405 not currently prescribed any medication) recorded as structured data. 1406

6. Objective: Maintain active medication allergy list. 1407 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 1408 has no medication allergies) recorded as structured data. 1409

7. Objective: Record demographics. 1410 Measure: At least 80 percent of all unique patients seen by the EP or admitted to the eligible hospital have demographics recorded as 1411 structured data 1412

8. Objective: Record and chart changes in vital signs. 1413 Measure: For at least 80 percent of all unique patients age 2 and over seen by the EP, record blood pressure and BMI; additionally, 1414 plot growth chart for children age 2 to 20. 1415

9. Objective: Record smoking status for patients 13 years old or older 1416 Measure: At least 80 percent of all unique patients 13 years old or older seen by the EP “smoking status” recorded 1417

10. Objective: Incorporate clinical lab-test results into EHR as structured data. 1418 Measure: At least 50 percent of all clinical lab tests results ordered by the EP or by an authorized provider of the eligible hospital 1419 during the EHR reporting period whose results are in either in a positive/negative or numerical format are incorporated in certified 1420 EHR technology as structured data. 1421

11. Objective: Generate lists of patients by specific conditions to use for quality improvement, reduction of disparities, research, and 1422 outreach. 1423 Measure: Generate at least one report listing patients of the EP with a specific condition. 1424

12. Objective: Report ambulatory quality measures to CMS or the States. 1425 Measure: For 2011, an EP would provide the aggregate numerator and denominator through attestation as discussed in section 1426 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 1427 proposed rule. 1428



5/16/2010 Page 44 of 139

13. Objective: Send reminders to patients per patient preference for preventive/ follow-up care 1429 Measure: Reminder sent to at least 50 percent of all unique patients seen by the EP that are 50 and over 1430

14. Objective: Implement five clinical decision support rules relevant to specialty or high clinical priority, including for diagnostic test 1431 ordering, along with the ability to track compliance with those rules 1432 Measure: Implement five clinical decision support rules relevant to the clinical quality metrics the EP is responsible for as described 1433 further in section II.A.3. 1434

15. Objective: Check insurance eligibility electronically from public and private payers 1435 Measure: Insurance eligibility checked electronically for at least 80 percent of all unique patients seen by the EP 1436

16. Objective: Submit claims electronically to public and private payers. 1437 Measure: At least 80 percent of all claims filed electronically by the EP. 1438

17. Objective: Provide patients with an electronic copy of their health information (including diagnostic test results, problem list, 1439 medication lists, and allergies) upon request 1440 Measure: At least 80 percent of all patients who request an electronic copy of their health information are provided it within 48 1441 hours. 1442

18. Objective: Provide patients with timely electronic access to their health information (including lab results, problem list, medication 1443 lists, allergies) 1444 Measure: At least 10 percent of all unique patients seen by the EP are provided timely electronic access to their health information 1445

19. Objective: Provide clinical summaries to patients for each office visit. 1446 Measure: Clinical summaries provided to patients for at least 80 percent of all office visits. 1447

20. Objective: Capability to exchange key clinical information (for example, problem list, medication list, allergies, and diagnostic test 1448 results), among providers of care and patient authorized entities electronically. 1449 Measure: Performed at least one test of certified EHR technology’s capacity to electronically exchange key clinical information. 1450

21. Objective: Perform medication reconciliation at relevant encounters and each transition of care. 1451 Measure: Perform medication reconciliation for at least 80 percent of relevant encounters and transitions of care. 1452

22. Objective: Provide summary care record for each transition of care and referral. 1453 Measure: Provide summary of care record for at least 80 percent of transitions of care and referrals. 1454

23. Objective: Capability to submit electronic data to immunization registries and actual submission where required and accepted. 1455 Measure: Performed at least one test of certified EHR technology’s capacity to submit electronic data to immunization registries. 1456

24. Objective: Capability to provide electronic syndromic surveillance data to public health agencies and actual transmission according to 1457 applicable law and practice. 1458 Measure: Performed at least one test of certified EHR technology’s capacity to provide electronic syndromic surveillance data to 1459 public health agencies (unless none of the public health agencies to which an EP or eligible hospital submits such information have 1460 the capacity to receive the information electronically). 1461

25. Objective: Protect electronic health information maintained using certified EHR technology through the implementation of 1462 appropriate technical capabilities. 1463 Measure: Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308 (a)(1) and 1464 implement security updates as necessary. 1465

1466 MU Objective 23 directly addresses Immunization Management. MU Objectives 7, 17, 18, 19, 22 and 25 impact immunization management. 1467

2.3.2 Business Objectives 1468

SampleHealth’s business objectives are: 1469 Patient safety and quality of care, 1470 Patient and clinician satisfaction, 1471 Meet government regulations, 1472 Minimize costs 1473

o Fast and efficient patient care, 1474 o Maximum utilization of clinician’s time. 1475 o Qualify for maximum government reimbursements 1476 o Minimize medical-legal liability. 1477

2.3.3 Project Scope and Vision Statement 1478

The Immunization Management Capability (IMC) project is intended to optimally accomplish immunization 1479 documentation and tracking, and support immunizations readiness reporting. 1480

The IMC initiative supports three broad goals: 1481



5/16/2010 Page 45 of 139

1. Public Health Protection and Readiness perspective: 1482 a. Ensure a healthy and fit population that is fully medically ready and medically protect individuals 1483

with the maximal ability to safely pursue their education and careers. 1484 b. Improved medical readiness through documenting, monitoring and reporting immunization status. 1485

2. Population Health perspective: 1486 a. Preventing and controlling diseases reduces adverse incidence requiring medical treatment. 1487 b. Compliant with current national standards and regulations to include patient safety and data quality. 1488

3. Medical Care perspective: 1489 a. Patient safety. 1490 b. Provider has immunization history. 1491 c. Medical conditions require supplemental immunization. 1492 d. Contraindications to immunizations. 1493



5/16/2010 Page 46 of 139

2.3.4 Non-Functional Requirements 1494

class DC.1.8.2 (Manage Immunization Administration)

DC.1.8.2 (Manage Immunization Administration)

SEE ALSO: DC.1.3.2DC.1.4.4S.1.1S.2.2.2S.3.7.1IN.1.6IN.1.7IN.2.4IN.2.5.1IN.2.5.2IN.3.1IN.3.2IN.4.1IN.4.2IN.4.3IN.5.1IN.5.2IN.6IN.3.1 and IN.3.2 do not exist! Substituted IN.3.

DC.1.3.2 (Manage Patient Advance Directives)

DC.1.4.4 (Manage Immunization List)

S.1.1 (Registry Notification)

S.2.2.2 (Standard Report Generation)

S.3.7.1 (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.2.5.1 (Manage Unstructured Health Record Information)

IN.2.5.2 (Manage Structured Health Record Information)

IN.4.1 (Standard Terminologies and Terminology Models)

IN.3 Registry and Directory Services

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

DC.1.8 Documentation of Care, Measurements and Results

DC.1 Care Management

EHR-S FM

+ Direct Care+ Supportive Care+ Information Infrastructure

1495

Figure 11 EHR-S FM Direct Care 1.8.2 Manage Immunization Administration Dependencies 1496 1497 The EHR-SD RM provides Figure 11 EHR-S FM Direct Care 1.8.2 Manage Immunization Administration 1498 Dependencies, which shows how Immunization Management depends on the EHR System Non-functional 1499 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, 1500 IN.6) and results in the following overall conformance criteria: 1501 DC 1.8.2 Manage Immunization Administration depends on IN 1.6 Secure Data Exchange 1502

1. The system SHALL secure all modes of EHR data exchange. 1503 2. The system SHOULD conform to function IN.1.7 (Secure Data Routing). 1504 3. The system MAY provide the ability to obfuscate data. 1505



5/16/2010 Page 47 of 139

4. The system SHALL encrypt and decrypt EHR data that is exchanged over a non-secure link. 1506 5. The system SHALL support standards-based encryption mechanisms when encryption is used for secure data exchange. 1507

DC 1.8.2 Manage Immunization Administration depends on IN 1.7 Secure Data Routing 1508 1. The system SHALL automatically route electronically exchanged EHR data only from and to known sources and destinations and only 1509

over secure networks. 1510 2. The system SHOULD route electronically exchanged EHR data only to and from authenticated sources and destinations (conform to 1511

function IN.1.1 (Entity Authentication)). 1512 3. The system SHOULD conform to function IN.2.2 (Auditable Records) to provide audit information about additions and changes to 1513

the status of destinations and sources. 1514 DC 1.8.2 depends on IN 2.4 Extraction of Health Record Information 1515

1. The system SHALL provide the ability to extract health record information. 1516 2. The system SHOULD conform to function IN.1.6 (Secure Data Exchange) to provide secure data exchange capabilities. 1517 3. The system SHOULD provide the ability to de-identify extracted information. 1518 4. The system SHOULD conform to function IN.5.1 (Interchange Standards) to enable data extraction in standard-based formats. 1519 5. The system SHOULD provide the ability to perform extraction operations across the complete data set that constitutes the health 1520

record of an individual within the system. 1521 6. The system MAY provide the ability to perform extraction operations whose output fully chronicles the healthcare process. 1522 7. The system SHOULD provide the ability to extract data for administrative purposes. 1523 8. The system SHOULD provide the ability to extract data for financial purposes. 1524 9. The system SHOULD provide the ability to extract data for research purposes. 1525 10. The system SHOULD provide the ability to extract data for quality analysis purposes. 1526 11. The system SHOULD provide the ability to extract data for public health purposes. 1527

DC 1.8.2 depends on IN 2.5.1 Manage Unstructured Health Record Information 1528 1. The system SHALL capture unstructured health record information as part of the patient EHR. 1529 2. The system SHALL retrieve unstructured health record information as part of the patient EHR. 1530 3. The system SHALL provide the ability to update unstructured health record information. 1531 4. The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction) to provide the ability to inactivate, 1532

obsolete, or destroy unstructured health record information. 1533 5. The system SHOULD provide the ability to report unstructured health record information. 1534 6. The system MAY track unstructured health record information over time. 1535 7. The system SHALL provide the ability to append corrected unstructured health record information to the original unstructured health 1536

record information. A specific type of implementation is not implied. 1537 8. The system SHALL provide the ability to append unstructured health record information to the original unstructured health record 1538

information. A specific type of implementation is not implied. 1539 9. The system SHALL provide the ability to append augmented unstructured health record information to the original unstructured health 1540

record information. A specific type of implementation is not implied. 1541 DC 1.8.2 depends on IN 2.5.2 Manage Structured Health Record Information 1542

1. The system SHALL capture structured health record information as part of the patient EHR. 1543 2. The system SHALL retrieve structured health record information as part of the patient EHR. 1544 3. The system SHALL provide the ability to update structured health record information. 1545 4. The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction) to provide the ability to inactivate, 1546

obsolete, or destroy structured health record information. 1547 5. The system SHOULD provide the ability to report structured health record information. 1548 6. The system MAY track structured health record information over time. 1549 7. The system SHOULD provide the ability to retrieve each item of structured health record information discretely within patient context. 1550 8. The system SHALL provide the ability to append corrected structured health record information to the original structured health record 1551

information. A specific type of implementation is not implied. 1552 9. The system SHALL provide the ability to append structured health record information to the original structured health record 1553

information. A specific type of implementation is not implied. 1554 10. The system SHALL provide the ability to append augmented structured health record information to the original structured health 1555

record information. A specific type of implementation is not implied. 1556 DC 1.8.2 depends on IN 3. Registry and Directory Services 1557

1. The system SHALL provide the ability to use registry services and directories. 1558 2. The system SHOULD provide the ability to securely use registry services and directories. 1559



5/16/2010 Page 48 of 139

3. The system SHALL conform to function IN.5.1 (Interchange Standards) to provide standard data interchange capabilities for using 1560 registry services and directories. 1561

4. The system SHOULD communicate with local registry services through standardized interfaces. 1562 5. The system SHOULD communicate with non-local registry services (that is, to registry services that are external to an EHR-S) through 1563

standardized interfaces. 1564 6. The system SHOULD provide the ability to use registries or directories to uniquely identify patients for the provision of care. 1565 7. The system SHOULD provide the ability to use registries or directories to uniquely identify providers for the provision of care. 1566 8. The system MAY provide the ability to use registries or directories to retrieve links to relevant healthcare information regarding a 1567

patient. 1568 9. The system MAY provide the ability to use registries to supply links to relevant healthcare information regarding a patient. 1569 10. The system MAY provide the ability to use registries or directories to identify payers, health plans, and sponsors for administrative and 1570

financial purposes. 1571 11. The system MAY provide the ability to use registries or directories to identify employers for administrative and financial purposes. 1572 12. The system MAY provide the ability to use registries or directories to identify public health agencies for healthcare purposes. 1573 13. The system MAY provide the ability to use registries or directories to identify healthcare resources and devices for resource 1574

management purposes. 1575 DC 1.8.2 depends on IN 4.1 Standard Terminologies and Terminology Models 1576

1. The system SHALL provide the ability to use standard terminologies to communicate with other systems (internal or external to the 1577 EHR-S). 1578

2. The system SHALL provide the ability to validate that clinical terms and coded clinical data exists in a current standard terminology. 1579 3. The system SHOULD provide the ability to exchange healthcare data using formal standard information models and standard 1580

terminologies. 1581 4. The system SHOULD provide the ability to use a formal standard terminology model. 1582 5. The system SHOULD provide the ability to use hierarchical inference searches e.g., subsumption across coded terminology concepts 1583

that were expressed using standard terminology models. 1584 6. The system SHOULD provide the ability to manage terminology assets and supporting tools (internal or external to the EHR-S). 1585 7. IF there is no standard terminology model available, THEN the system MAY provide a formal explicit terminology model. 1586

DC 1.8.2 depends on IN 4.2 Maintenance and Versioning of Standard Terminologies 1587 1. The system SHALL provide the ability to use different versions of terminology standards. 1588 2. The system SHALL provide the ability to update terminology standards. 1589 3. The system MAY relate modified concepts in the different versions of a terminology standard to allow preservation of interpretations 1590

over time. 1591 4. The system SHOULD provide the ability to interoperate with systems that use known different versions of a terminology standard. 1592 5. The system SHOULD provide the ability to deprecate terminologies. 1593 6. The system MAY provide the ability to deprecate individual codes within a terminology. 1594 7. The system SHALL provide the ability to cascade terminology changes where coded terminology content is embedded in clinical 1595

models (for example, templates and custom formularies) when the cascaded terminology changes can be accomplished 1596 unambiguously. 1597

8. Changes in terminology SHALL be applied to all new clinical content (via templates, custom formularies, etc.). 1598 DC 1.8.2 depends on IN 4.3 Terminology Mapping 1599

1. The system SHALL provide the ability to use a terminology map. 1600 2. The system SHOULD provide the ability to use standard terminology services for the purposes of mapping terminologies. 1601 3. The system MAY provide the ability for a user to validate a mapping. 1602 4. The system MAY provide the ability to create a terminology map. 1603

DC 1.8.2 depends on IN 5.1 Interchange Standards 1604 1. The system SHALL provide the ability to use interchange standards as required by realm specific and/or local profiles. 1605 2. The system SHALL provide the ability to seamlessly perform interchange operations with other systems that adhere to recognized 1606

interchange standards. 1607 3. The system SHALL conform to functions under header IN.4 (Standard Terminologies and Terminology Services) to support 1608

terminology standards in accordance with a users' scope of practice, organizational policy, or jurisdictional law. 1609 4. IF there is no standard information model available, THEN the system MAY provide a formal explicit information model in order to 1610

support the ability to operate seamlessly with other systems. 1611 5. The system SHOULD provide the ability to exchange data using an explicit and formal information model and standard, coded 1612

terminology. 1613 DC 1.8.2 depends on IN 5.2 Interchange Standards Versioning and Maintenance 1614



5/16/2010 Page 49 of 139

1. The system SHALL provide the ability to use different versions of interchange standards. 1615 2. The system SHALL provide the ability to change (reconfigure) the way that data is transmitted as an interchange standard evolves over 1616

time and in accordance with business needs. 1617 3. The system SHOULD provide the ability to deprecate an interchange standard. 1618 4. The system SHOULD provide the ability to interoperate with other systems that use known earlier versions of an interoperability 1619

standard. 1620 DC 1.8.2 depends on IN 6 Business Rules Management 1621

1. The system SHALL provide the ability to manage business rules. 1622 2. The system SHOULD provide the ability to create, import, or access decision support rules to guide system behavior. 1623 3. The system SHOULD provide the ability to update decision support rules. 1624 4. The system SHOULD provide the ability to customize decision support rules and their components. 1625 5. The system SHOULD provide the ability to inactivate, obsolete, or destroy decision support rules. 1626 6. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to decision support rules. 1627 7. The system SHOULD provide the ability to create diagnostic support rules to guide system behavior. 1628 8. The system SHOULD provide the ability to update diagnostic support rules. 1629 9. The system MAY provide the ability to customize diagnostic support rules and their components. 1630 10. The system SHOULD provide the ability to inactivate, obsolete, or destroy diagnostic support rules. 1631 11. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to diagnostic support rules. 1632 12. The system SHOULD provide the ability to create workflow control rules to guide system behavior. 1633 13. The system SHOULD provide the ability to update workflow control rules. 1634 14. The system MAY provide the ability to customize workflow control rules and their components. 1635 15. The system SHOULD provide the ability to inactivate, obsolete, or destroy workflow control rules. 1636 16. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to workflow control rules. 1637 17. The system MAY provide the ability to create access privilege rules to guide system behavior. 1638 18. The system MAY provide the ability to update access privilege rules. 1639 19. The system MAY provide the ability to customize access privilege rules and their components. 1640 20. The system MAY provide the ability to inactivate, obsolete, or destroy access privilege rules. 1641 21. The system MAY conform to function IN.2.2 (Auditable Records) to audit all changes to access privilege rules. 1642 22. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to other business rules. 1643 23. The system SHOULD support the ability to selectively export business rules. 1644

2.3.5 Use Case Inventory 1645

Following is the HHS AHIC Use Case inventory: 1646 2009 Requirements Documents 1647

o Consumer Preferences 1648 2009 Use Case and Extensions/Gaps 1649

o Common Data Transport 1650 o General Laboratory Orders 1651 o Order Sets 1652 o Medication Gaps 1653 o Clinical Note Details 1654 o Common Device Connectivity 1655 o Newborn Screening 1656

Newborn Screening Companion Document 1657 o Medical Home: Problem Lists & Practice-Based Registries 1658 o Maternal and Child Health 1659 o Long Term Care - Assessments 1660 o Consumer Adverse Event Reporting 1661 o Scheduling 1662 o Prior-Authorization in Support of Treatment, Payment, & Operations 1663 o Preliminary Consumer Preferences Extension/Gap 1664

2008 Use Cases 1665 o Remote Monitoring 1666



5/16/2010 Page 50 of 139

o Patient - Provider Secure Messaging 1667 o Personalized Healthcare 1668 o Consultations and Transfers of Care 1669 o Public Health Case Reporting 1670 o Immunizations & Response Management 1671

2007 Use Cases 1672 o Emergency Responder — Electronic Health Record (PDF) 1673 o Consumer Empowerment: Consumer Access to Clinical Information 1674 o Medication Management 1675 o Quality 1676

2006 Use Cases 1677 o Harmonized Consumer Empowerment (Registration & Medication History) Use Case (PDF) 1678 o Harmonized Electronic Health Record (Laboratory Result Reporting) Use Case (PDF) 1679 o Harmonized Biosurveillance (Visit, Utilization, and Lab Result Data) Use Case (PDF) 1680

2.3.6 Conformance Criteria 1681

1. IMC satisfies all applicable national regulations and policies. 1682 2. IMC satisfies the requirements of the EHR-S FM Direct Care 1.8.2 function and its dependencies. 1683 3. IMC satisfies the requirements of the HHS AHIC Immunization & Response Management (IRM) use Case. 1684 4. IMC satisfies the requirements of the HHS AHIC Public Health Case Reporting (PHCR) Use Case. 1685

2.3.7 Discussion 1686

SampleHealth is focused on meeting the National Objectives and policies. The EHR-S FM did not map 1687 one-to-one to SAIF-ECCF viewpoints. EHR-S FM Infrastructure non-functional requirements were mapped to 1688 the Conceptual Enterprise-Viewpoint given here; while, EHR-S FM Direct Care and Supportive Care functional 1689 requirements were mapped to the SAIF-ECCF Conceptual Computation-Viewpoint given below. 1690

2.4 Conceptual Information-Viewpoint 1691

The ECCF Conceptual Information-Viewpoint is defined by the domain analysis information model. The 1692 Information-Viewpoint is concerned with the nature of the information handled by the system and 1693 constraints on the use and interpretation of that information. This Viewpoint answers the question “what” 1694 and refers to information content. This Viewpoint is primarily useful to clinicians and clinical analysts. This 1695 Viewpoint might typically contains some combination of: 1696

Inventory of 1697 Domain Entities, 1698 Roles, 1699 Activities and 1700 Associations. 1701

Information Model 1702 Conceptual 1703 Domain 1704

1705 The HITSP/TN903 Data Architecture is our domain analysis model. 1706



5/16/2010 Page 51 of 139

1707 1708

1709 Figure 12 Conceptual Health Data Model 1710

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

26 Conceptual Health Data Model v2.3, Canadian Institute for Health Information



5/16/2010 Page 52 of 139

2.4.1 Domain Information Model 1724

For SampleHealth the Conceptual Business-Viewpoint is 1725 defined by the HL7 RIM based HITSP Data Architecture 1726 (e.g., HITSP/ TN903 Data Architecture, C80 1727 Terminology, C83 Data Modules, C154 Data Dictionary), 1728 which are organized by the CDA Document Sections27 and 1729 Entry Content Modules28 and Data Elements29. 1730 A CDA document may contain the following Sections: 1731

Payers Section 1732 Allergies and Other Adverse Reactions Section 1733 Problem List Section 1734 History of Past Illness Section 1735 Chief Complaint Section 1736 Reason for Referral Section 1737 History of Present Illness Section 1738 List of Surgeries Section 1739 Functional Status Section 1740 Hospital Admission Diagnosis Section 1741 Discharge Diagnosis Section 1742 Medications Section 1743 Admission Medications History Section 1744 Hospital Discharge Medications Section 1745 Medications Administered Section 1746 Advance Directives Section 1747 Immunizations Section 1748 Physical Examination Section 1749 Vital Signs Section 1750 Review of Systems Section 1751 Hospital Course Section 1752 Diagnostic Results Section 1753 Assessment and Plan Section 1754 Plan of Care Section 1755 Family History Section 1756 Social History Section 1757 Encounters Section 1758 Medical Equipment Section 1759 Preoperative Diagnosis Section 1760

27 CDA Sections are collection of Entries pertaining to a single specified concept. For example, the Allergies and Other Adverse Reactions Section can contain a list of allergies (multiple Entry Content Modules)

28 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 1761 Surgery Description Section 1762 Surgical Operation Note Findings Section 1763 Anesthesia Section 1764 Estimated Blood Loss Section 1765 Specimens Removed 1766 Complications Section 1767 Planned Procedure Section 1768 Indications Section 1769 Disposition Section 1770 Operative Note Fluids Section 1771 Operative Note Surgical Procedure Section 1772 Surgical Drains Section 1773 Implants Section 1774 Assessments Section 1775 Procedures and Interventions Section 1776 Provider Orders Section 1777 Questionnaire Assessment Section 1778

The following Entry Content Modules are used: 1779 Personal Information 1780 Language Spoken 1781 Support 1782 Healthcare Provider 1783 Insurance Provider 1784 Allergy/Drug Sensitivity 1785 Condition 1786 Medication 1787 Pregnancy 1788 Information Source 1789 Comment 1790 Advance Directive 1791 Immunization 1792 Vital Sign 1793 Result 1794 Encounter 1795 Procedure 1796 Family History 1797 Social History 1798 Medical Equipment 1799 Functional Status 1800 Plan Of Care 1801

1802 HITSP C83 identifies data elements per content module and 1803 HITSP C154 defines the data elements. 1804 HITSP documents are available at www.HITSP.org 1805



5/16/2010 Page 53 of 139

2.4.2 Conformance Statements 1806

1. The IMC is CDA compliant as specified by HITSP C80, C83 and C154. 1807 2. IMC messaging is compliant with HITSP C72 (Immunization Message). 1808


An Information Model is a means of classifying information topics of interest (e.g., clinical summary, encounter 1810 note, transfer of care summary, etc.). Information is a set of data that has been collated, interpreted and presented 1811 to be meaningful to a particular audience for a particular purpose. A Data Model defines the specific subjects and 1812 the facts about them (e.g., HITSP TN903). The same data can be used to produce many different pieces of 1813 information. A Data Model does not identify or define any topics that are essentially derived by any transformation 1814 process. The HITSP standards-based domain information model is essential to semantic interoperability and is 1815 specified in SampleHealth’s Data Use and Reciprocal Support Agreement (DURSA). Currently, the HITSP 1816 selected standards are mandated for Federal Agencies and for HITECH meaningful use incentives to physicians 1817 and healthcare organizations in the HITECH Standards & Certification Criteria Interim Final Rule (IFR). 1818 Ultimately, the emerging Federal Health Information Model (FHIM) will apply to this viewpoint. 1819

2.5 Conceptual Computation-Viewpoint 1820

The ECCF Conceptual Computation-Viewpoint is defined by collaboration analysis (e.g., BPM and UML sequence or 1821 activity diagrams), functional profiles, service roles and relationships. The Computation-Viewpoint is concerned 1822 with the functional decomposition of the system into a set of components that exhibit specific behaviors and 1823 interact at interfaces. This Viewpoint answers the question “how” and references behavioral specifications. This 1824 Viewpoint is primarily useful to business analysts and functional analysts. This Viewpoint might typically contains 1825 some combination of: 1826

Inventories of 1827 Capabilities-Components, 1828 Functions-Services 1829

Requirements 1830 Accountability 1831 Roles 1832 Behaviors 1833 Functional Profiles 1834 Interactions 1835 Interfaces 1836 Contracts 1837

Conceptual Functional Service Specifications (CFSS) 1838 1839 The Conceptual Computation-Viewpoint is defined by the functional requirements defined in the HL7 EHR System 1840 Functional Model, AHIC Use Case Harmonization Request and by HITSP capabilities. The SampleHealth ECCF 1841 Conceptual Computation-Viewpoint contains: 1842

HSSP & NHIN Services 1843 HSSP & NHIN Service Interfaces 1844



5/16/2010 Page 54 of 139

HSSP & NHIN Service Roles and Relationships (e.g., Responsibilities) 1845

2.5.1 Service Inventory 1846

HSSP provides the following services: 1847 CTS2 (Common Terminology Services 2) - CTS 2 is a standard for terminology services that enhances the capabilities of the initial 1848

CTS specification for sub-setting and mapping, and extends the specification into domains such as terminology distribution, versioning, 1849 and classification. 1850

DSS (Decision Support Service) - A commonly accepted standard for the DSS would make it more attractive for service consumers to 1851 invest in the infrastructure required for using the DSS to meet its patient evaluation needs, as they would be able to use the same 1852 interface to interact with multiple service vendors. 1853

HCPDS (Healthcare Provider and Services Directory Service) - HCPDS is required to provide an online facility that will enable 1854 Practitioners, via a set of parameters, to locate other practitioners, to assist in the continuum of care. 1855

IXS (Identity Cross-Reference Service, formerly known as Entity Identification Service) Normative - In balloting to become a full 1856 HL7 standard. 1857

PASS (Privacy, Access and Security Services) - The goal of PASS is to define a suite of services that will provide a simple interface 1858 for all privacy, access control, consent, identity management and other security services that are needed in a service-oriented health 1859 information architecture. 1860

RLUS (Retrieve, Locate and Update Service) and EIS (Entity Identification Service) - The HL7 SFM has been approved by the 1861 HL7 Board as an official DSTU. 1862

1863 NHIN Connect version 2.4 provides the following services: 1864 Access Consent - This specification provides a standard language for expressing restrictions on access to health information. These 1865

restrictions are also known as Access Consent Policies. Access Consent Policies may be “off-the-shelf” policies that are adopted by or 1866 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 1867 by specific types of users. Access Consent policies may also be created by users other than consumers; for example, physicians may 1868 create policies that restrict access to health information they create. 1869

Audit Log Query - The Query Audit Log service provides the mechanism by which audit data associated with accessing health 1870 information on the NHIN is exchanged so that consumers and privacy or security officers can account for who has had access to what 1871 information for what purpose. The service allows one NHIE to request an audit log, meeting certain search criteria, from another NHIE. 1872 The service can be viewed as receiving query requests from the NHIN to which it must respond, and sending queries to NHIEs on the 1873 NHIN in order to receive and potentially view audit log entries. Sequence diagrams are included for messages in each direction. The 1874 transactions implemented by the Query Audit Log service are described in the NHIN Trial Implementations Service Interface 1875 Specifications - Audit Log Query v1.3.1 [ONC 2009-6]. See that document for more information on the standards and specifications 1876 that describe this service. 1877

Enterprise Service Component - Policy Engine - The Policy Engine Enterprise Service Component comprises both open-source 1878 components and interactions implemented within CONNECT. This section describes the overall architecture of the Policy Engine, 1879 identifying those components that are open-source. The Policy Engine takes responsibility of determining whether a message should be 1880 processed by CONNECT, regardless of the direction the message is being moved - whether it is inbound from the NHIN or outbound 1881 to the NHIN - and thereby enables an organization to apply policies to all messages. Policies may be patient-specific (e.g., based on the 1882 patient's consent for a specific information exchange) or organization specific (e.g., based on hours of operation, user role, etc.). 1883

Authorization Framework - Authorization Framework defines the exchange of metadata used to characterize each NHIN request. The 1884 purpose of that exchange is to provide the responder with the information needed to make an authorization decision for the requested 1885 function. Each initiating message must convey information regarding end user attributes and authentication using SAML 2.0 assertions. 1886 The NHIN Authorization Framework specification defines a SAML assertion that can indicate a Policy ID that one NHIO may wish to 1887 retrieve from another NHIO. 1888

Authorized Case Follow-Up - Pseudonymization is the process of removing the association between a data set (e.g., protected health 1889 information or PHI) and the subject of that data (e.g., a patient) by removing identifying information, and adding an association between 1890 the data set and one or more alternative identifiers, or pseudonyms. Reidentification is the process of obtaining the association between a 1891 pseudonym and the original subject of that data set (e.g., re-associating PHI with the patient). Pseudonymization may be required for a 1892 number of reasons. For example, there may be a need to report health information to a public health agency for surveillance purposes in 1893 which case the identity of the individual is not needed. Likewise, reidentification may be required if an authorized individual, such as a 1894 public health official, must investigate a potential public health issue with proper legal authorization by gaining more information from 1895 the longitudinal health record of the individual known only by their pseudonym. Authorized Case Follow-up represents the services for 1896



5/16/2010 Page 55 of 139

reidentification. It does not include the services, algorithms, or specifications for pseudonymization. The transaction used by the service 1897 interface is the HL7 v3 Patient Registry Get Identifiers Query, as profiled by the IHE Patient Identifier Cross-Reference HL7 v3 1898 (PIX v3) Supplement Draft for Trial Implementations dated 15 August 2007 and Patient Demographic Query HL7 v3 (PDQ v3) 1899 Supplement Draft for Trial Implementations dated 15 August 2007 [IHE PIX and IHE PDQ]. See the NHIN Trial 1900 Implementations Service Interface Specifications - Authorized Case Follow Up v1.0 for more information on the standards and 1901 specifications that describe this service [ONC 2009-7]. 1902

CARE Profile - CMS has established the CARE data set to promote standards-based exchange of CARE data with the ultimate goal of 1903 improving the quality of care experienced by patients as they transition among providers. CMS has initiated a proof-of-concept project 1904 referred to as the CARE Health Information Exchange Project (C-HIEP) to explore the use of the CARE data and its exchange of over 1905 the NHIN. 1906

Consumer Preferences - The consumer preferences profile allows consumers to express their preferences for whether or not to share 1907 their information on the NHIN and for more granular control over access to their private information. The CONNECT policy engine 1908 enforces those preferences in the runtime environment to insure that the access policies of the organization and the preferences of the 1909 consumer are honored in the decision to release health information in response to a request from the NHIN. 1910

Document Submission - The Document Submission service provides a mechanism to send documents to another organization, 1911 unsolicited by a call to the Query for Documents service or other mechanism, and therefore implementing a "push" exchange pattern. 1912 The service can be viewed as submitting document(s) from the NHIN that must be processed or stored by the receiving system, and 1913 sending document(s) including health information to NHIEs on the NHIN. Sequence diagrams are included for messages in each 1914 direction. The transactions implemented by the Document Submission service are described in the IHE IT Infrastructure Technical 1915 Framework Supplement 2009-2010 - Cross-Enterprise Document Reliable Interchange (XDR) dated 10 August 2009 [IHE 1916 XDR]. See the NHIN Document Submission Web Services Interface Specification draft, not yet released at the time of this 1917 writing, for more information on the standards and specifications that describe this service [ONC 2010-5]. 1918

GIPSE Profile - GIPSE stands for Geocoded Interoperable Population Summary Exchange. It was created by the CDC to allow the 1919 electronic exchange of health condition summary data. GIPSE data will be used by public health agencies for early event detection and 1920 monitoring for potential public health events. 1921

Health Info. Event Messaging - The Health Information Event Messaging, or HIEM, refers to the NHIN specification for NHIN-1922 enabled systems to initiate subscriptions for information with other NHIN participants, and subsequently to deliver notifications of 1923 when data matching subscription criteria is available. HIEM is an extension to the OASIS Web Services Base Notification 1.3 (WS-1924 BaseNotification) [OASIS 2006-1] utilizing Web Services Topics 1.3 (WS-Topics) [OASIS 2006-2]. See NHIN Health Information 1925 Event Messaging Web Service Interface Specification v2.0 dated 29 January 2010 for more information on the standards and 1926 specifications that describe this service [ONC 2010-4]. 1927

Messaging Platform - Messaging Platform specifies a base set of messaging standards and web service protocols which must be 1928 implemented by each NHIN node and applies to all transactions. All NHIN inter-nodal messages are SOAP messages over HTTP using 1929 web services, must be encrypted and digitally signed. 1930

Patient Discovery - In order to share patient data within and among NHIEs, and at times between NHIEs and other connected 1931 organizations, it is necessary to have mechanisms to match patient identities in the absence of a single national identifier. The Patient 1932 Discovery service meets this need by providing the mechanism for locating patients at other NHIN-enabled organizations based on 1933 demographic information. The service provides the ability for one NHIE to determine whether other NHIEs have records for a given 1934 patient by submitting a set of demographic identifiers that NHIEs can use to match against their own master patient indices. The 1935 transactions implemented by the Patient Discovery service is described in the IHE IT Infrastructure Technical Framework - Cross-1936 Community Patient Discovery (XCPD) Supplemental Draft for Trial Implementations dated 10 August 2010 [IHE XCPD]. See the 1937 NHIN Patient Discovery Web Service Interface Specification v1.0 dated 29 January 2010 for more information on the standards and 1938 specifications that describe this service [ONC 2010-1]. 1939

Query for Documents - The Query for Documents service provides the mechanism by which one NHIE locates electronic health 1940 information on the NHIN associated with a specific patient. The service allows one NHIE to acquire a list of documents for a given 1941 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 1942 NHIN to which it must respond, and sending queries to NHIEs on the NHIN in order to locate a patient's health information. Sequence 1943 diagrams are included for messages in each direction. The transactions implemented by the Query for Documents service are described 1944 in the IHE IT Infrastructure Technical Framework - Cross Gateway Query (XCA) Supplement Draft for Trial 1945 Implementations dated 15 August 2007 [IHE XCA]. The use of this profile is included in HITSP TP13 Manage Sharing of 1946 Documents Transaction Package [HITSP TP13]. See the NHIN Query for Documents Web Service Interface Specification v2.0 1947 dated 29 January 2010 for more information on the standards and specifications that describe this service [ONC 2010-2]. The XCA 1948 specification has been relaxed within the NHIN to support the query for, and retrieval of, dynamically generated document content. 1949

Retrieve Documents - The Retrieve Documents service provides a mechanism to retrieve the electronic health information on the 1950 NHIN. It is used in conjunction with the Query for Documents service, which returns a list of document references that Retrieve 1951 Documents uses to retrieve patient records. The service can be viewed as receiving document requests from the NHIN to which it must 1952



5/16/2010 Page 56 of 139

respond, and sending requests to NHIEs on the NHIN in order to retrieve patient health information. Sequence diagrams are included 1953 for messages in each direction. The transactions implemented by the Retrieve Documents service are described in the IHE IT 1954 Infrastructure Technical Framework - Cross Community Access (XCA) Supplement Draft for Trial Implementations dated 15 1955 August 2007 [IHE XCA]. The use of this profile is included in HITSP TP13 Manage Sharing of Documents Transaction Package 1956 [HITSP TP13]. See the NHIN Retrieve Documents Web Service Interface Specification v2.0 dated 29 January 2010 for more 1957 information on the standards and specifications that describe this service [ONC 2010-3]. 1958

Service Registry - The NHIN Services Registry allows NHIN member organizations to locate and utilize the appropriate services 1959 offered by other members in a controlled, secure manner. The registry enables privacy and trust by only allowing vetted participant 1960 organizations into the registry. The registry facilitates interoperability, by cataloging and advertising in real-time which services are 1961 supported by each organization. 1962

Subject Discovery - The Subject Discovery service interface is used between NHIEs for the purpose of querying for a subject, and 1963 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 1964 specification is a healthcare consumer, patient or may be a provider. Subject as used in this specification does not include system user. 1965

2.5.1 Functional Requirements 1966

The EHR-SD RM provides Figure 11 EHR-S FM Direct Care 1.8.2 Manage Immunization Administration 1967 Dependencies, which shows how Immunization Management depends on other EHR System functional 1968 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 1969 criteria: 1970 DC 1.8.2 Manage Immunization Administration 1971

1. The system SHALL provide the ability to recommend required immunizations, and when they are due, during an encounter based on 1972 widely accepted immunization schedules. 1973

2. The system SHOULD provide the ability to recommend required immunizations based on patient risk factors. 1974 3. The system SHALL perform checking for potential adverse or allergic reactions for all immunizations when they are about to be 1975

given. 1976 4. The system SHALL provide the ability to capture immunization administration details, including date, type, lot number and 1977

manufacturer. 1978 5. The system SHOULD provide the ability to capture other clinical data pertinent to the immunization administration (e.g. vital signs). 1979 6. The system SHALL record as discrete data elements data associated with any immunization. 1980 7. The system SHOULD provide the ability to associate standard codes with discrete data elements associated with an immunization. 1981 8. The system SHALL provide the ability to update the immunization schedule. 1982 9. The system SHOULD provide the ability to prepare a report of a patient's immunization history upon request for appropriate 1983

authorities such as schools or day-care centers. 1984 10. The system SHALL conform to function DC.1.4.1 (Manage Allergy, Intolerance and Adverse Reaction Lists). 1985 11. The system SHOULD transmit required immunization information to a public health immunization registry. 1986 12. The system SHOULD receive immunization histories from a public health immunization registry. 1987

DC 1.8.2 depends on DC 1.3.2 Manage Patient Advance Directives 1988 1. The system SHALL provide the ability to indicate that advance directives exist for the patient. 1989 2. The system SHALL provide the ability to indicate the type of advance directives completed for the patient such as living will, durable 1990

power of attorney, preferred interventions for known conditions, or the existence of a "Do Not Resuscitate order”. 1991 3. The system SHOULD provide the ability to capture, present, maintain and make available for clinical decisions patient advance 1992

directives documents and “Do Not Resuscitate” orders. 1993 4. The system SHOULD conform to function DC.1.1.3.1 (Capture Data and Documentation from External Clinical Sources) and 1994

capture scanned patient advance directive documents and “Do Not Resuscitate” orders. 1995 5. The system SHOULD provide the ability to indicate when advanced directives were last reviewed. 1996 6. The system SHOULD provide the ability to indicate the name and relationship of the party completing the advance directive for the 1997

patient. 1998 7. The system SHALL time and date stamp advance directives. 1999 8. The system SHOULD provide the ability to document the location and or source of any legal documentation regarding advance 2000

directives. 2001 9. The system SHOULD conform to function DC.2.1.4 (Support for Patient and Family Preferences). 2002

DC 1.8.2 depends on DC 1.4.1 Manage Immunization List 2003 1. The system SHALL capture, display and report all immunizations associated with a patient 2004



5/16/2010 Page 57 of 139

2. The system SHALL record as discrete data elements data associated with any immunization given including date, type, lot number 2005 and manufacturer 2006

3. The system SHOULD prepare a report of a patient‘s immunization history upon request for appropriate authorities such as schools 2007 or day-care centers 2008

DC 1.8.2 depends on S 1.1 Registry Notification 2009 1. The system SHOULD automatically transfer formatted demographic and clinical information to local disease specific registries (and 2010

other notifiable registries). 2011 2. The system MAY provide the ability to automate the retrieval of formatted demographic and clinical information from local disease 2012

specific registries (and other notifiable registries). 2013 3. The system SHOULD provide the ability to add, change, or remove access to registries. 2014

DC 1.8.2 depends on S 2.2.2 Standard Report Generation 2015 1. The system SHOULD provide the ability to generate reports of structured clinical and administrative data using either internal or 2016

external reporting tools. 2017 2. The system MAY provide the ability to include information extracted from unstructured clinical and administrative data in the report 2018

generation process, using internal or external tools. 2019 3. The system SHOULD provide the ability to export reports generated. 2020 4. The system SHOULD provide the ability to specify report parameters, based on patient demographic and/or clinical data, which 2021

would allow sorting and/or filtering of the data. 2022 5. The system (or an external application, using data from the system) MAY provide the ability to save report parameters for generating 2023

subsequent reports. 2024 6. The system (or an external application, using data from the system) MAY provide the ability to modify one or more parameters of a 2025

saved report specification when generating a report using that specification. 2026 DC 1.8.2 depends on S 3.7.1 Clinical Decision Support System Guidelines Updates 2027

1. The system SHALL provide the ability to update the clinical content or rules utilized to generate clinical decision support reminders 2028 and alerts. 2029

2. The system SHOULD validate that the most applicable version is utilized for the update, and capture the date of update. 2030 3. The system MAY track and retain the version used when guidelines are provided in a patient encounter. 2031 2032 2033

2.5.2 Conceptual Functional Service Specification (CFSS) 2034

This information is available at the HSSP and NHIN CONNECT websites. The IMC capability CFSS will be 2035 described here. 2036

TBD 2037

2.5.3 Service Roles and Relationships 2038

This information is available at the HSSP and NHIN CONNECT websites. The IMC capability CFSS will be 2039 described here. 2040

TBD 2041 2.5.4 Conformance Statements 2042

1. IMC meets the EHR-S FM Direct Care 1.8.2 Immunization Management and derived requirements. 2043 2. IMC makes appropriate use of HSSP and NHIN services. 2044


The SampleHealth IMC project Conceptual Computation-Viewpoint is defined by the functional requirements and 2046 Information Exchange Requirements (IERs) defined in the HL7 EHR System Functional Model, AHIC Use Case 2047 Harmonization Request and by HITSP capabilities. 2048



5/16/2010 Page 58 of 139

ISSUE: In the ECCF, it is not intuitively obvious where Use cases, Information Exchange Requirements (IERs), 2049 Business Process Models and System Data Exchanges models (i.e., sequence diagrams of transactions implementing 2050 an IHE profile) respectively belong. 2051

2.6 Conceptual Engineering-View 2052

The ECCF Conceptual Engineering-Viewpoint is defined by existing platform capabilities. The Engineering-2053 Viewpoint is concerned with the mechanisms and functions required to support the interactions of the 2054 computational components. This ECCF Viewpoint may overlap with the RM-ODP technology viewpoint, 2055 which is concerned with the explicit choice of technologies for the implementation of the system, and 2056 particularly for the communications among the components. This Viewpoint is primarily useful to enterprise 2057 architects. This Viewpoint answers the question “where” and refers to implementation environments. This 2058 Viewpoint might typically contains some combination of: 2059

Inventory of Software Platforms/ Environments and their Capabilities. 2060 2061

2.6.1 Inventory of Software Platforms and Their Capabilities 2062 2063 For SampleHealth the Conceptual Engineering-Viewpoint is defined by NHIN Connect to be: 2064 Apache Tomcat (or Jakarta Tomcat or simply Tomcat) is an open source servlet container developed by the 2065

Apache Software Foundation (ASF). Tomcat implements the Java Servlet and the JavaServer Pages (JSP) 2066 specifications from Sun Microsystems, and provides a "pure Java" HTTP web server environment for Java code 2067 to run. 2068

JBoss Application Server (or JBoss AS) is a free software/open-source Java EE-based application server. 2069 Because it is Java-based, the JBoss application server operates cross-platform: usable on any operating system 2070 that supports Java. JBoss AS was developed by Jboss, now a division of Red Hat. 2071

J2SE, Java Platform, Standard Edition or Java SE is a widely used platform for programming in the Java 2072 language. It is the Java Platform used to deploy portable applications for general use. In practical terms, Java SE 2073 consists of a virtual machine, which must be used to run Java programs, together with a set of libraries (or 2074 "packages") needed to allow the use of file systems, networks, graphical interfaces, and so on, from within those 2075 programs. 2076

Eclipse Open Healthcare Framework (OHF) is a project within Eclipse formed for the purpose of expediting 2077 healthcare informatics technology. The project is composed of extensible frameworks and tools which 2078 emphasize the use of existing and emerging standards in order to encourage interoperable open source 2079 infrastructure, thereby lowering integration barriers. 2080

GlassFish ESB v2 integrates the OpenESB project into the GlassFish Java 5 EE Application Server, where 2081 "Project OpenESB implements an Enterprise Service Bus (ESB) runtime using Java Business Integration (JBI) 2082 as the foundation, enabling the easy integration of web services to create loosely coupled, enterprise-class 2083 composite applications." 2084

GlassFish is an open source application server project led by Sun Microsystems for the Java EE platform. 2085 GlassFish is free software, dual-licensed under two free software licenses: the Common Development and 2086 Distribution License (CDDL) and the GNU General Public License (GPL) with the classpath exception. 2087 GlassFish is based on source code released by Sun and Oracle Corporation's TopLink persistence system. It 2088 uses a derivative of Apache Tomcat as the servlet container for serving Web content, with an added component 2089 called Grizzly which uses Java NIO for scalability and speed. 2090



5/16/2010 Page 59 of 139

OpenSSO is an open source access management and federation server platform. OpenSSO is based on Sun 2091 Java System Access Manager, and is the core of Sun's commercial access management and federation product, 2092 OpenSSO Enterprise (formerly Sun Access Manager and Sun Federation Manager). Oracle completed their 2093 acquisition of Sun Microsystems in February 2010 and announced that OpenSSO would no longer be their 2094 strategic product. OpenSSO will continue to be developed and supported by ForgeRock under the name of 2095 *OpenAM. 2096


1. IMC uses the appropriate NHIN CONNECT version 2.4 platforms. 2098


Because the EHR-SD RM is sponsored by the HL7 Government Projects workgroup and the Universal 2100 Immunization Tracking System (UITS) prototype is funded by the Military Health System, the SampleHealth ECCF 2101 Conceptual Engineering-Viewpoint identifies the Federal Health Architecture’s Federal Partners’ sponsored NHIN 2102 Connect suite of environments (e.g., platforms). 2103

2.7 Platform-Independent Enterprise-Business-Viewpoint 2104

The ECCF Platform-Independent Enterprise-Business-Viewpoint defines the business and reference context. The 2105 Enterprise-Business-Viewpoint is concerned with the business governance of the system as it relates to the 2106 business objectives and the business processes of the organization. This Viewpoint answers the question 2107 “why” and refers to policy. This Viewpoint is primarily useful to project managers and business process 2108 experts. This Viewpoint might typically contains some combination of: 2109

Applicable Rules 2110 Use Case Specs 2111 Governance. 2112 Technology Neutral Standards 2113 Wireframes of 2114

architectural layers 2115 components and 2116 Associations 2117

2118 2.7.1 NHIN Standards 2119

Figure 13 illustrates the categories of standards, which apply to EHR interoperability, compliant with the 2120 Meaningful Use Stage 1 certification criteria in the Interim Final Rule (IFR) issued by the Office of the 2121 National Coordinator (ONC), US Department of Health and Human Services (HHS) in January 2010. 2122



5/16/2010 Page 60 of 139

2123 Figure 13 NHIN Standards Framework 2124

2125 2126

2.7.2 Business Governance 2127 2128 The Platform-Independent Enterprise-Business-Viewpoint is defined by the governance enforced throughout the 2129 Architecture Development Method (ADM). The governance30 includes the following: 2130

Change Control Board (CCB) manages Enterprise Requirements and Investment Portfolio. 2131 Architecture Review Board (ARB) manages architecture, reusable components and services. 2132 Configuration Management Board (CMB) manages the following baselines. 2133

o System Requirements Review (SRR) 2134 o Preliminary Design Review (PDR) 2135 o Critical Design Review (CDR) 2136 o Test Readiness Review (TRR) 2137 o System Integration Test (SIT) 2138 o System Qualification Test (SQT) 2139 o Operational Test and Evaluation (OT&E) 2140


1. IMC requirements were approved by the CCB. 2142 2. IMC architectural views were approved by the ARB. 2143 3. IMC SRR baseline was approved by the CMB. 2144 4. IMC PDR baseline was approved by the CMB. 2145 5. IMC CDR baseline was approved by the CMB. 2146 6. IMC TRR baseline was approved by the CMB. 2147 7. IMC SIT baseline was approved by the CMB. 2148 8. IMC SQT baseline was approved by the CMB. 2149 9. IMC OT&E baseline was approved by the CMB. 2150

30 Based on DOD Instruction (DODI) 5000.2



5/16/2010 Page 61 of 139


The "Requirements Management and Governance" circle at the center of the Figure 43 ADM graphic indicates that 2152 Requirements Management and Governance should be a part of every stage of a project. It is important to note that 2153 the Requirements Management and Governance circle denotes, not a static set of requirements, but a dynamic 2154 process whereby requirements for enterprise architecture and subsequent changes to those requirements are 2155 identified, validated, stored, and fed into and out of the relevant ADM phases but, the requirements management 2156 process must also dispose of, address, validate or prioritize evolving and refined requirements during the relevant 2157 phases of the ADM. The ability to govern changes in requirements is crucial. Architecture is an activity that by its 2158 very nature deals with uncertainty and change - the "grey area" between what stakeholders aspire-to and what can be 2159 specified and engineered as a pragmatic solution. Moreover, architecture often deals with drivers and constraints, 2160 which can produce changes in requirements in an unforeseen manner. Many of the factors influencing architecture 2161 by their very nature are beyond the control of the enterprise (changing market conditions, new legislation, etc.). 2162

Governance is critical to a project’s success. SOA governance includes the management of the reusable 2163 library of component, their service specifications and service contracts (DURSAs). Because the EHR-SD 2164 RM is sponsored by the HL7 Government Projects workgroup and the Universal Immunization Tracking System 2165 (UITS) prototype is funded by the Military Health System, the SampleHealth is following the governance described 2166 in DOD Instruction 5000.231 Operation of the Defense Acquisition System. 2167

2.8 Platform-Independent Information-Viewpoint 2168

The ECCF Platform-Independent Information-Viewpoint is defined by the project information model. The Information-2169 Viewpoint is concerned with the nature of the information handled by the system and constraints on the use and 2170 interpretation of that information. This view answers the question “what” and refers to information content. This 2171 Viewpoint is primarily useful to clinical informaticists. This Viewpoint answers the question “where” and refers to 2172 implementation environments. This Viewpoint might typically contains some combination of: 2173

Information Models 2174 Localized Information Model 2175 Constrained Information Model 2176 Project Information Model 2177

Message Content Specifications 2178 2179 A Logical Level Data Model32 is the most detailed level. The full complexity of data entities and all their 2180 relationships are expressed. It is this level of detail that is necessary to specify information systems. All entities 2181 should be fully described with all their characteristics. The permissible values of all attributes (characteristics) should 2182 also be defined and all relationships expressed. 2183 2184 The SampleHealth Project Information Model for the Platform-Independent Information-Viewpoint is defined by 2185 the HITSP Components33. 2186

HITSP/C72 Immunization Message, 2187 HITSP/C83 CDA Content Modules 2188 HITSP/C80 Terminology 2189

31 Available at http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf 32 Conceptual Health Data Model v2.3, Canadian Institute for Health Information 33 Available from www.HITSP.org



5/16/2010 Page 62 of 139

HITSP/C154 Data Dictionary 2190

2.8.1 Project Information Model 2191

IMC Data Requirements and Data Elements are based on the HL7 Reference Information Model we generate 2192 Figure 25 Immunization Management Entities, Actions and Roles. HITSP IS 010, which contains Table 7 Data 2193 Element and Information Requirements (DR) 2194 2195

2.8.1. Data Requirements (DRs) 2196 IRM Data Requirements (DRs): 2197 DR08 Unstructured Data 2198 DR11 Immunization response data 2199 DR12 Adverse Event Report 2200 DR13 Drug/Vaccine Inventory Data 2201 DR14 Drug/Vaccine Inventory Usage Data 2202 DR15 Drug/Vaccine Inventory Availability Data 2203 DR16 Supply Chain Management Vaccine Recall 2204 DR17 Decision Support Data 2205 DR18 Vaccination Data 2206 DR19 Medication Administration data 2207 DR20 Aggregate Inventory of Available Vaccine 2208 DR21 Terminology Data 2209 DR22 Generic Alert Data 2210 DR23 Consumer Vaccination View 2211

2212 PHCR Data Requirements (DRs): 2213 DR08 Unstructured Data 2214 DR17 Decision Support Data 2215 DR21 Terminology Data 2216 DR24 Case Report Pre-populate Data 2217 DR22 Generic Alert Data 2218 DR23 Consumer Vaccination View 2219 DR24 Case Report Pre-populate Data 2220 DR25 Case Report Content 2221 DR26 Reporting Criteria Content 2222 DR59 Generic Alert Data 2223

2224 2225



5/16/2010 Page 63 of 139

Table 7 Data Element and Information Requirements (DR) 2226 Data

Requirement Number (DR) Description

DR8 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

DR11 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 64 of 139

Data Requirement

Number (DR) 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

DR12 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))

DR13 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

DR14 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

DR15 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

DR16 Supply Chain Management Vaccine Recall: Content that supports the vaccine recall functions of the vaccine supply chain.



5/16/2010 Page 65 of 139

Data Requirement


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

DR17 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

DR18 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 66 of 139

Data Requirement


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

DR19 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 67 of 139

Data Requirement


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

DR20 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

DR21 Terminology Data: Used to transform human or computer vocabularies. Data attributes may be specified based upon implementation

DR22 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

DR23 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 68 of 139

Data Requirement


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

DR58 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 69 of 139

Data Requirement


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

DR76 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 70 of 139

Data Requirement


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

2.8.1. Standards Gaps 2227 This section describes gaps in standards. Gaps occur in the following two cases, where HITSP has: 2228

Identified requirements derived from the context that have no standards that meet all tiers of HITSP 2229 criteria to merit selection for that context 2230 Identified a single standard that encompasses and singly fulfills a set of tightly-coupled standards from the 2231 given context, yet is lacking in fulfilling one or more of the tightly-coupled requirements 2232 The gap is only relative to the specific Use Case requirement. Recommended resolutions were developed 2233 through a series of steps including the HITSP Technical Committee’s initial recommendations, cross 2234 Technical Committee validation of the gap, provisional recommendations and peer review by the Technical 2235 Committee. 2236

The table below identifies the Use Case requirements and known associated gaps, along with the 2237 recommended resolutions. 2238



5/16/2010 Page 71 of 139

Table 8 Use Case Requirements and Associated Standards Gaps 2239 Requirement

Number Summary

Description Identified Gaps Recommended Resolution

7.1.1.2 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

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

DR17 Decision Support Data (immunization schedule)

7.1.1.1 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

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 specifications34. Proprietary solutions may be leveraged in the interim Look at what is in the text versions to identify the data element requirements

7.1.2.1a : Action: Identify individuals needing immunization or drug: - No approved standard for identifying individuals needing immunization or drug

Monitor and contribute to HL7 Clinical Decision Support work on standardized service/algorithm

DR17 Decision Support Data (Immunization reminders)

Web Services approach for Entity identification services

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

DR17 Decision Support Data (Prioritization)

7.1.2.1b 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

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 www.OMG.org



5/16/2010 Page 72 of 139

Requirement Number

Summary Description Identified Gaps Recommended Resolution

7.1.2.1b, Alternative Action: Receive information about individuals needing prioritized intervention, 7.2.1.1 Action: Conduct analysis to determine intervention priorities, 7.2.1.2 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

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

DR19 Medication Administration data

7.1.3.2 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

Refer to the appropriate SDO to define standards. Monitor and contribute to effort

DR17 Decision Support Data (Alert - Recall)

7.1.6.1 Action: Receive vaccine recall information from registries : Standards gap – today this is done by human communications

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

DR17 Decision Support Data (Prioritization)

7.2.1.1 Action: Identify individuals needing prioritized intervention : no standard for the consumer-friendly decision

May be influenced by policy decisions Refer to and appropriate SDO to define standards. Monitor and contribute to effort

DR19 Medication Administration data

7.4.1.1Action: 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

7.4.2.1 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


7.4.2.1: 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 73 of 139

Requirement Number

Summary Description Identified Gaps Recommended Resolution

DR11 DR76

Immunization response data Immunization query data

7.1.2.1a Action: Identify individuals needing immunization or drug 7.1.2.1b Alternative Action: Receive information about individuals needing prioritized intervention 7.4.2.1 Action: Provide vaccine or drug administration information. 7.4.3.1 Action: Retrieve vaccine or drug administration information from external sources 7.4.4.1 Action: Receive information describing the administration of a vaccine or drug 7.3.2.1 Action: Request available immunization information 7.2.1.1 Action: Conduct analysis to determine intervention priorities 7.2.1.2 Action: Notify clinicians of individuals or population characteristics needing prioritized intervention 8.2.2.1 Action: Receive and monitor inventory status information 8.3.1.1 Action: Monitor inventory usageVXQ/VXR – There is a deprecation of these and an update in progress from CDC to the implementation guide

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

DR18 DR19


7.4.3.1 Action: Retrieve vaccine or drug administration information from external sources NCPDP – does not conform to the Vaccination data details

Either pharmacies conform to HL7 standard or update NCPDP standard to conform to immunization data requirements

DR16 Supply Chain Management Vaccine RecallVaccine Recall (including consumer directed message)

7.1.6.1 Action: Receive vaccine recall information from registries 7.3.3.1 Action: Receive vaccine recall information from registries GAP: Possible if the vaccine recall information does not contain enough info to update the supply chain

Work with SDOs to update the standards to conform to the data requirements

2.8.1. Standard Overlaps 2240 This section describes the instances where there are overlaps among standards for the Use Case 2241 requirements. The overlap is only relative to the specific Use Case requirement. Overlaps refer to instances 2242 wherein some of the requirements are met by multiple standards. Recommended resolutions were 2243 developed through a series of steps including the Technical Committee’s initial recommendations, cross 2244 Technical Committee validation of the overlap, provisional recommendations and peer review by the 2245 Technical Committees. 2246

The table below presents the identified overlaps and the respective resolution plans. 2247



5/16/2010 Page 74 of 139

Table 9 Use Case Requirements and Associated Standard Overlaps 2248 Requirement

Number Summary

Description Standard Overlap Recommended Resolution

DR11 Immunization response data DR76 Immunization query data

Immunization Query and Response

7.1.2.1a Action: Identify individuals needing immunization or drug 7.1.2.1b Alternative Action: Receive information about individuals needing prioritized intervention 7.4.2.1 Action: Provide vaccine or drug administration information 7.4.3.1 Action: Retrieve vaccine or drug administration information from external sources 7.4.4.1 Action: Receive information describing the administration of a vaccine or drug 7.3.2.1 Action: Request available immunization information 7.2.1.1 Action: Conduct analysis to determine intervention priorities 7.2.1.2 Action: Notify clinicians of individuals or population characteristics needing prioritized intervention 8.2.2.1 Action: Receive and monitor inventory status information 8.3.1.1 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

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

DR18 Vaccination Data 7.4.4.1 Action: Receive information describing the administration of a vaccine or drug We will continue to support 2.3.1 messages with optionality to include PIX/PDQ where supported.

We want something that allows for this in one step

DR17 Decision Support Data

7.1.1.1 Action: Receive immunization schedules 7.1.1.2 Action: Incorporate immunization schedules into the clinician’s EHR 7.1.2.1a Action: Identify individuals needing immunization or drug 7.1.2.1b Alternative Action: Receive information about individuals needing prioritized intervention 7.1.3.2 Action: Record vaccine or drug administration information 7.1.5.1 Action: Receive immunization schedules 7.4.1.1 Action: Incorporate immunization schedules into the registry 7.4.1.2 Action: Conduct analysis to determine intervention priorities 7.2.1.1 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

Tier-2 Selection process; Work with SDOs to align and harmonize the standardization efforts in this area



5/16/2010 Page 75 of 139

Requirement Number

Summary Description Standard Overlap Recommended Resolution

IER54 Query/response for clinical message data DR18

Immunization Query and Response Vaccination Data

7.1.3.2 Action: Record vaccine or drug administration information 7.1.4.1 Action: Report administration information to registries 7.4.1.1 Action: Report administration information to registries 7.4.2.1 Action: Provide vaccine or drug administration information 7.4.4.1 Action: Receive information describing the administration of a vaccine or drug 7.3.1.1 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

2249


1. IMC messages are conformant with HITSP/C72 Immunization Message specification 2251 2. IMC documents and services are compliant with: 2252

o HITSP/C83 CDA Content Modules 2253 o HITSP/ C80 Terminology 2254 o HITSP/ C154 Data Dictionary. 2255 o Manufactured vaccines are identified by either a Global Trade Identification Number (GTIN) or 2256

Drug Identification Number (DIN). 2257 The CDC codes for immunizations and manufacturers 2258

http://www.cdc.gov/vaccines/programs/iis/stds/cvx.htm 2259 http://www.cdc.gov/vaccines/programs/iis/stds/mvx.htm 2260

o The American Immunization Registry Association (AIRA) Immunization Information Systems 2261 Codebook: Guide to Code Sets and Data Definitions for Registry Data Sharing Using HL7 dated 2262 06/03/2009, available at 2263 http://www.immregistries.org/pubs/index.phtml 2264

o SNOMED-CT is used to represent "genericized" immunizing agents (e.g. "MMR" vs. a GTIN for a 2265 specific manufacturer's MMR product 2266

3. Standards gaps and overlaps are identified. 2267


This section included the data requirements, which were derived from the analysis of the IMR use case. The ultimate 2269 standards solution must fit within the HITSP/ TN903 Data Architecture. Information intended for one purpose can 2270 be repurposed or transformed to become data used as input into a new process to create information for a different 2271 purpose. Transformation processes may be automated or be the result of human judgment. An Information Model 2272 then, is a means of classifying information topics of interest (e.g., clinical summary, encounter note, transfer of care 2273 summary, etc.). Information is a set of data that has been collated, interpreted and presented to be meaningful to a 2274 particular audience for a particular purpose. A Data Model defines the specific subjects and the facts about them 2275 (e.g., HITSP TN903). The same data can be used to produce many different pieces of information. A Data Model 2276 does not identify or define any topics that are essentially derived by any transformation process. Notice that there 2277 are standards gaps and overlaps, which may need to be harmonized within the standards Development 2278 Organizations (SDOs). These gaps and overlaps represent risks to the IMC project. 2279



5/16/2010 Page 76 of 139

2.9 Platform-Independent Computation-Viewpoint 2280

The ECCF Platform-Independent Computation-Viewpoint is defined by collaboration analysis (e.g., UML 2281 sequence diagrams), functional profiles, service roles and relationships. The Platform-Independent 2282 Computation-Viewpoint is concerned with the functional decomposition of the system into a set of 2283 components that exhibit specific behaviors and interact at interfaces. This Viewpoint answers the question 2284 “how” and references behavioral specifications. This viewpoint is primarily useful to System Engineers 2285 and Business Process Modelers. This Viewpoint might typically contains some combination of: 2286

Use Case Specs 2287 Component specs 2288 Interface Specs 2289 Interaction Specs 2290 Collaboration Participations 2291 Collaboration Types 2292 Function Types 2293 Interface Types 2294 Collaboration Scripts 2295 Service Contracts 2296

2297 For SampleHealth the Platform-Independent Computation-Viewpoint is defined by Capabilities composed of 2298 HITSP Transactions, Transaction Packages, Service Collaborations. 2299 2300

2.9.1 Service Interface Specification Types and Functional Group Types, 2301

2.9.1. Map of Business Functions 2302 The SampleHealth Business Functions Map identifies the business functions performed by SampleHealth in Volume I. 2303 These high-level business lines are likely consistent with many mid-sized healthcare provider organizations. This 2304 collection of information is the baseline against which gap analyses can be performed and the candidate list of “to-2305 be” services identified. Comparing Table 10 to Table 11 we see the tremendous reuse gained by a SOA. 2306



5/16/2010 Page 77 of 139

2307 Healthcare

Unique Services Business Services SOA Infrastructure Services

Business Line

Ord

er E

ntry

Ord

er F

ulfil

lmen

t

Patie

nt

Eval

uatio

n (D

SS)

Labo

rato

ry D

ata

Ret

rieva

l

Phar

mac

y D

ata

Ret

rieva

l

EHR

Ale

rt/E

vent

Mgm

t

Mas

ter P

erso

n In

dex

Term

inol

ogy

Serv

ice

Dem

ogra

phic

s

Bill

ing

Sche

dulin

g

Aud

iting

Ser

vice

Exce

ptio

n M

gmt

Bus

ines

s Pr

oces

s M

gmt (

BPM

)

Aut

hent

icat

ion

Serv

ices

D

irect

ory

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 2308 2309

Healthcare Unique Services

Business Services SOA Infrastructure Services

Business Line

Ord

er E

ntry

Ord

er F

ulfil

lmen

t

Patie

nt

Eval

uatio

n (D

SS)

Labo

rato

ry D

ata

Ret

rieva

l

Phar

mac

y D

ata

Ret

rieva

l

Imm

uniz

atio

n M

anag

emen

t

EHR

Ale

rt/E

vent

Mgm

t

Mas

ter P

erso

n In

dex

Term

inol

ogy

Serv

ice

D

emog

raph

ics

Bill

ing

Sche

dulin

g

Aud

iting

Ser

vice

Exce

ptio

n M

gmt

Bus

ines

s Pr

oces

s M

gmt (

BPM

)

Aut

hent

icat

ion

Serv

ices

D

irect

ory

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 2310 2311 2312



5/16/2010 Page 78 of 139

2.9.2 Use Cases and Business Level Interaction Diagrams 2313

This section describes the Immunizations and Response Management (IRM)35 Use Case requirements and 2314 outlines the given IRM scenarios at a high level. The IRM Use Case focuses on: 1) access to information about 2315 individuals who need to receive specific vaccines, drugs, or other interventions; 2) the ability to report, track, 2316 and manage administration of vaccines, drugs, isolation, and quarantine; 3) the ability to identify and 2317 electronically exchange information describing the treatment or prophylaxis status of populations; 4) the ability 2318 to exchange specific resource and supply chain data from public and private sectors. The Use Case describes 2319 these activities within the context of two scenarios: 2320

1. Vaccine and Drug Administration and Reporting: This scenario describes the process of identifying 2321 individuals and populations requiring and the administration of vaccines or drugs based on routine 2322 schedules, or as dictated by emergency response priorities. Additionally, this scenario describes the exchange 2323 of data necessary to support countermeasure and response administration of prophylaxis and treatment 2324 modalities, and the supply of data between appropriate registries and other sources of data to support 2325 clinical care and public health follow-up activities. 2326

2. Vaccine and Drug Inventory Reporting: This scenario describes how information regarding the need for, 2327 and availability of, vaccines and/or drugs is collected and exchanged to support coordinated delivery of 2328 care. SampleHealth has chosen to defer Scenario 2: Vaccine and Drug Inventory Reporting; but, include the 2329 associations and commonalities between the scenarios in the IRM Use Case and the AHIC Public Health 2330 Case Reporting (PHCR)36 Use Case. Additionally, the IRM Use Case does not specifically cite processing a 2331 query and response solely for the sake of getting the data without the goal of identifying whether or not a 2332 vaccination is needed (e.g., for school registration), this functionality is required by SampleHealth. 2333

The IRM Use Case assumes the developing presence of electronic systems such as Electronic Health Records 2334 (EHRs), Personal Health Records (PHRs), and other local or Web-based solutions supporting consumers and 2335 clinicians, while recognizing the issues and obstacles associated with these assumptions. 2336

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, 2008. 36 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, 2008.



5/16/2010 Page 79 of 139

2.9.2. Information Exchanges 2337

2338 Figure 14 Immunization and Response Management Information Exchanges 2339

The following information exchanges are key to the IRM use case, Vaccine and Drug Administration and Reporting 2340 Scenario: 2341

1. Immunization knowledge providers distribute immunization schedules for incorporation into Immunization 2342 Information Systems (IIS), other registries, EHR systems and possibly health information exchange. 2343

2. Registries, including IISs, provide immunization information to clinicians, consumers, other registries and 2344 other organizations 2345

3. Registries, including IISs, gather vaccine or drug administration information from clinicians, consumers, 2346 other registries and other organizations 2347

4. Consumers provide available immunization information to clinicians 2348 5. Following administration of (or inability to administer) a vaccine or drug the clinician provides appropriate 2349

clinical documentation to registries, consumers and others 2350 6. Public health gathers information to identify individuals needing prioritized intervention 2351 7. Public Health provides information to clinicians about populations or individuals having special needs for 2352

immunization or other intervention 2353 8. Registries provide information about vaccine recalls to clinicians and affected consumers 2354

2355



5/16/2010 Page 80 of 139

2.9.2. Information Exchange Requirements (IERs) 2356 IRM Information Exchange Requirements (IERs)37: 2357 IER10 Identify patient 2358 IER13 Send/receive notification of document availability 2359 IER18 Send/receive clinical document 2360 IER26 Identify communication recipients 2361 IER27 Send non-patient notification message or alert 2362 IER40 Query for existing data 2363 IER42 Request/receive medical concept knowledge 2364 IER54 Query/response for clinical message data 2365 IER67 Send/receive clinical message 2366 IER78 Send/receive Vaccine Inventory Requirements 2367 IER79 Query/response for inventory usage data 2368 IER80 Send/receive Vaccine Inventory Data 2369

2370 NOTE: Blue Italics indicates IERs, which are common to 1-IRM and 2-PHCR 2371 2372 PHCR Information Exchange Requirements (IERs)38 2373 IER10 Identify patient 2374 IER13 Send/receive notification of document availability 2375 IER18 Send/receive clinical document 2376 IER26 Identify communication recipients 2377 IER27 Send non-patient notification message or alert 2378 IER29 Send/receive electronic form for data capture 2379 IER40 Query for existing data 2380 IER42 Request/receive medical concept knowledge 2381 IER49 Report confirmation 2382

2383 HITSP Security and Privacy Information Exchange Requirements (IERs): 2384 IER01 Provide authorization and consent 2385 IER02 Send data over secured communication channel 2386 IER03 Create audit log entry 2387 IER04 Synchronize system time 2388 IER05 Verify entity identity 2389 IER06 Provide proof of document integrity and origin 2390 IER55 Anonymize patient identifiable data 2391 IER56 Pseudonymize patient identifying information 2392

2393

37 See HITSP Interoperability Specification (IS) 10 Immunization and Response Management for details. It is available at www.HITSP.org 3388 SSeeee HHIITTSSPP IInntteerrooppeerraabbiilliittyy SSppeecciiffiiccaattiioonn ((IISS)) 1111 PPuubblliicc HHeeaalltthh CCaassee RReeppoorrttiinngg IInntteerrooppeerraabbiilliittyy SSppeecciiffiiccaattiioonn IImmmmuunniizzaattiioonn ffoorr ddeettaaiillss.. IItt iiss aavvaaiillaabbllee aatt wwwwww..HHIITTSSPP..oorrgg



5/16/2010 Page 81 of 139

2.9.2. Business Level Behavioral Specifications 2394 The SampleHealth IMC project focused on adding an immunization registry to its existing enterprise. The ECCF 2395 Conceptual Computation-Viewpoint presented the behavioral specifications for the following system components: 2396

Public Health Information System, 2397 EHR System, which contains the Immunization Information System (IIS) component, 2398 PHR System, 2399 HIE System which provides Infrastructure Services (e.g., ESB). 2400

2401

Business Process Models are currently popular for Business level behavioral specifications; but, UML sequence 2402 diagrams were used in HITSP IS10 because they are more concise and more closely correspond to the AHIC IRM 2403 use case, which were modeled. 2404

Behavioral Specifications in the form of Use Case dynamic views (e.g., in our case, sequence diagrams) illustrate each 2405 Use Case scenario with a representation of a normal sequence of exchanges among the primary actors. The event 2406 codes from the Use Case are annotated on the diagrams to show how the interactions relate to the Use Case. The 2407 interactions are supported by the various constructs which are introduced in the Figure 21 Mapping of 2408 Requirements to HITSP Constructs. 2409

Figure 15 Immunizations and Response Management (IRM) Business Sequence – Part 1 – Clinician Perspective: 2410 Immunizations and Response Management Scenario 2: Vaccine and Drug Administration and Reporting depicts the 2411 events and actions associated with the clinician perspective from the Immunizations and Response Management 2412 (IRM) Scenario 2: Vaccine and Drug Administration and Reporting. The clinician in this exchange may represent 2413 clinicians performing administration and treatment in routine care settings and non-routine settings including, but 2414 not limited to physician offices, hospitals, clinics, field medical stations, pharmacies, incident locations. It is assumed 2415 in this diagram that the clinician is supported in the interactions with registries and other business actors through the 2416 EHR. 2417 2418



5/16/2010 Page 82 of 139

Figure 15 Immunizations and Response Management (IRM) Business Sequence – Part 1 – Clinician 2419 Perspective: Immunizations and Response Management Scenario 2: Vaccine and Drug Administration 2420 and Reporting 2421

2422 2423 Figure 16 Immunizations and Response Management (IRM) Business Sequence – Part 2 – Registries Perspective: 2424 Immunizations and response management Scenario 2: Vaccine and Drug Administration and Reporting depicts the 2425 events and actions associated with the registries perspective from the Immunizations and Response Management 2426 Scenario 2: Vaccine and Drug Administration and Reporting. It is assumed in this diagram that the public health and 2427 registry personnel are supported in the interactions with other business actors through the registries. 2428 2429



5/16/2010 Page 83 of 139

Figure 16 Immunizations and Response Management (IRM) Business Sequence – Part 2 – Registries 2430 Perspective: Immunizations and response management Scenario 2: Vaccine and Drug Administration and 2431 Reporting 2432

2433

Figure 17 Immunizations and Response Management (IRM) Business Sequence – Part 3– Consumer Perspective: 2434 Immunizations and response management Scenario 2: Vaccine and Drug Administration and Reporting depicts the 2435 events and actions associated with the consumer perspective from the Immunizations and Response Management 2436 Scenario 2: Vaccine and Drug Administration and Reporting. It is assumed in this diagram that the consumer is 2437 supported in the interactions with other business actors either through the PHR or through interactions with their 2438 clinicians, who are supported through the EHR. 2439



5/16/2010 Page 84 of 139

Figure 17 Immunizations and Response Management (IRM) Business Sequence – Part 3– Consumer 2440 Perspective: Immunizations and response management Scenario 2: Vaccine and Drug Administration and 2441 Reporting 2442

2443



5/16/2010 Page 85 of 139

Figure 18 Immunizations and Response Management (IRM) Business Sequence – Part 4 2444

2445

2.9.3 Service Interaction Types and Collaboration Participations 2446

2.9.3. System-Level Exchange Architecture 2447 Figure 19 As-Is SampleHealth Information System High Level Architecture and Figure 20 To-Be SampleHealth 2448 Information System High Level Architecture show the addition of the IMC information exchanges to the as-is 2449 SamplaHealth architecture. 2450



5/16/2010 Page 86 of 139

2451

2452 Figure 19 As-Is SampleHealth Information System High Level Architecture 2453



5/16/2010 Page 87 of 139

2454 Figure 20 To-Be SampleHealth Information System High Level Architecture 2455



5/16/2010 Page 88 of 139

2456

2.9.3. System Data Exchange Behavioral Specifications 2457 The Dynamic View (e.g., UML sequence diagrams) used in this section incorporate the detailed data requirements 2458 for the selected standards, with the interfaces and their specific and detailed Transactions and content encapsulated 2459 in the HITSP constructs. The detailed interface Transactions described in these diagrams show all common or 2460 independent interfaces, data, and the specific transactions from the HITSP constructs that are used for the IRM 2461 Capability. 2462

Figure 21 below provides a mapping of the HITSP constructs that will be used in the design of the IRM capability 2463 and the data and information exchange requirements that are being satisfied by the construct. 2464

Figure 21 Mapping of Requirements to HITSP Constructs 2465

Construct Name Information Exchange

Requirement Number (IER#) Data Requirement Number

(DR#)

HITSP/C19 - Entity Identity Assertion IER5 Verify entity identity

HITSP/C26 - Nonrepudiation of Origin IER6 Provide proof of document integrity and origin

HITSP/C62 - Unstructured Document 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 DR18 Vaccination data DR23 Consumer vaccination view

HITSP/C80 – Document and Message Terminology

DR11 Immunization response data DR76 Immunization query data DR18 Vaccination data DR58 Demographic data – vaccination DR23 Consumer vaccination view

HITSP/C83 – CDA Content Modules DR18 Vaccination data DR58 Demographic data – vaccination DR23 Consumer vaccination view

HITSP/C88 - Anonymize Immunizations and Response Management Data

IER55 Anonymize patient identifiable data

HITSP/T63 - Emergency Message Distribution Element

IER27 Send non-patient notification message or alert

DR22 Generic alert data - Immunizations

HITSP/64 - Identify Communication Recipients

IER26 Identify communication recipients DR22 Generic alert data - Immunizations DR8 Unstructured dataDR8 Unstructured data (Alerts) DR18 Vaccination data DR16 Supply chain management vaccine recall (deferred)

HITSP/C82 - Emergency Common Alerting Protocol

IER27 Send non-patient notification message or alert

DR22 Generic alert data – Immunizations

HITSP/T15 - Collect and Communicate Security Audit Trail

IER3 Create audit log entry

HITSP/T16 - Consistent Time IER4 Synchronize system time



5/16/2010 Page 89 of 139

Construct Name Information Exchange

Requirement Number (IER#) Data Requirement Number

(DR#)

HITSP/T17 - Secured Communication Channel

IER2 Send data over secured communication channel

HITSP/T23 - Patient Demographics Query

IER10 Identify patient DR58 Demographic data - vaccination

HITSP/T24 - Pseudonymize IER56 Pseudonymize patient identifying information

HITSP/T29 - Notification of Document Availability

IER13 Send/receive notification of document availability

DR8 Unstructured data

HITSP/T31 - Document Reliable Interchange

IER18 Send/receive clinical document

HITSP/T33 - Transfer of Documents on Media


HITSP/T66 - Retrieve Value Set Terminology Service

DR21 Terminology data

HITSP/T81 - Retrieval of Medical Knowledge

IER42 Request/receive medical concept knowledge

HITSP/TP13 - Manage Sharing of Documents


HITSP/TP20 - Access Control IER1 Provide authorization and consent

HITSP/TP21 - Query for Existing Data IER40 Query for existing data

HITSP/TP22 - Patient ID Cross-Referencing

IER10 Identify patient DR58 Demographic data – vaccination

HITSP/TP30 - Manage Consent Directives

IER1 Provide authorization and consent

2466

The UML sequence diagrams used in this section incorporate the detailed data requirements for the selected 2467 standards and their specific and detailed Transactions and content (encapsulated in the HITSP constructs listed 2468 above). The detailed actor Transactions described in these diagrams show all common or independent technical 2469 actors, data, and the specific transactions from the HITSP constructs that are used for the IRM Capability. 2470

Figure 22 below depicts the options supported to communicate vaccinations. Multiple options are specified for 2471 communication of immunization information in order to enable current operational systems migration toward 2472 shared patient identification services as defined by HITSP/TP22 and HITSP/T23. A CDA vaccination 2473 (HITSP/C78) is also specified to support PHR interoperability and as an option for providers and Immunization 2474 Information System to engage in document sharing of immunizations. 2475

Option 1 - Use just HL7 VXU (HITSP/C72) from the message sender (clinician system or Immunization 2476 Information System) to the message receiver (Immunization Information System) 2477

Option 2 - If the HIE offers a HITSP/TP22 PIX manager, the clinician system shall first query the PIX 2478 manager using a PIX (HITSP/TP22) or PDQ (HITSP/T23) query transaction and populate the patient 2479 identifier in the HL7 VXU (HITSP/C72) message with the HIE domain identifier 2480

Option 3 – From the PHR, a HITSP/C78 Immunization Document can be communicated as a shared 2481 document to a document repository or sent to the Immunization Information System using document reliable 2482 interchange (HITSP/T31) or via media/email (HITSP/T33). 2483

Option 4 –The HITSP/C78 document can be communicated as a shared document to a document repository 2484



5/16/2010 Page 90 of 139

(HITSP/TP13) or sent to another provider o using document reliable interchange (HITSP/T31) or via 2485 media/email (HITSP/T33) 2486

Option 5 – An Immunization Information System may optionally support a document repository and receive 2487 vaccination data using document reliable interchange (HITSP/T31) or via media/email (HITSP/T33). The 2488 Immunization Information System may retrieve an Immunization document (HITSP/C78) from the document 2489 repository or from another jurisdiction document repository for cross-jurisdiction information sharing 2490 leveraging query and retrieve transactions and the Cross Community Access option in HITSP/TP13. As current 2491 immunization registries are not configured with these capabilities, this is a forward looking option 2492

Option 6 – An Immunization Information System may optionally send an unsolicited notification using 2493 HITSP/C72 to a clinical information system to indicate that one of their patients has received an immunization 2494 from another clinician (e.g., Airport, school, another clinician) 2495

2496

Figure 22 Communicate Vaccinations 2497

2498 2499 Figure 23 below depicts the options supported to communicate Immunization Query and Response. 2500



5/16/2010 Page 91 of 139

Multiple options are specified for Immunization Query and Response in order to enable current operational systems 2501 migration toward shared patient identification services as defined by HITSP/TP22 and HITSP/T23 and to enable 2502 migration toward HITSP/TP21: 2503

Option 1 – Use the traditional HL7 VXQ to send a query from the message sender (clinician system) to the 2504 message receiver (Immunization Information System) and the HL7 VXR to send the result of the query from 2505 the message sender (Immunization Information System) to the message receiver (clinician system) 2506 (HITSP/C70) 2507

Option 2 – If the HIE offers a PIX manager (HITSP/TP22), the clinician system shall first query the PIX 2508 manager (using HITSP/TP22 or HITSP T23) and populate the patient identifier in the HL7 VXQ message with 2509 the HIE domain identifier and in the resulting VXR message (HITSP/C70). NOTE: policy would need to assert 2510 query result policies in PDQ as currently specified for VXR 2511

Option 3 - Use HITSP/TP21 Query for Existing Data to request and receive immunization data; If the HIE 2512 offers a PIX manager, the clinician system shall first query the PIX manager and populate the patient identifier 2513 in the HITSP/TP21 query 2514

Option 4 – Where there are immunization documents available in the HIE Document repository, use 2515 HITSP/TP13 Manage Sharing of Documents query/retrieve to gather the most up-to-date immunization data 2516 available. which may be published as HITSP/C62 Unstructured Document Component containing summary or 2517 patient-specific immunization alert, HITSP/C78 Immunization Document) 2518



5/16/2010 Page 92 of 139

Figure 23 Immunization Query and Response 2519

2520 2521 Figure 24 below depicts the options supported to communicate notification of immunization related alerts: 2522

Option 1 – Non-patient specific push – Where the alert is generic and not specific to a particular patient (e.g., 2523 immunizations required for a particular population such as those over the age of 65) and the communication 2524 requires presentation preserving properties, the communication recipients are identified using the Identify 2525 Communication Recipients (HITSP/T64) construct, and the generic alert is sent to those providers leveraging 2526 the Emergency Message Distribution Element (HITSP/T63) with the Emergency Common Alerting Protocol 2527 (HITSP/C82). The communication itself may be conducted using email, Health Alert Network (HAN), or FAX 2528 as specified by the implementation. Communication recipients may be identified using the Identify 2529 Communication Recipients (HITSP/T64) construct 2530

Option 2 – Where the alert is generic and not specific to a particular patient (e.g., immunizations required for a 2531 particular population such as those over the age of 65) and the communication is text-based, the communication 2532 recipients are identified using the Identify Communication Recipients (HITSP/T64) construct, and the generic 2533



5/16/2010 Page 93 of 139

alert is sent to those providers using the Emergency Message Distribution Element (HITSP/T63) with the 2534 Emergency Common Alerting Protocol (HITSP/C82). 2535

Option 3 – Where the alert is patient-specific in nature, the notification of document availability (HITSP/T29) 2536 is sent to the alert recipient (may be patient or provider). The person receiving the alert may then retrieve the 2537 patient-specific alert as an Unstructured Document (HITSP/C62) which will contain the immunization 2538 notification alert and instructions for the clinician or patient. 2539

Option 4 – Context specific information may be requested by the EHR or PHR using Retrieval of Medical 2540 Knowledge (HITSP/T81) as part of the user interface or pre-fetching options. This approach may be used to 2541 address the request of immunization data for assessment if a vaccine is needed. This option leverages a retrieval 2542 model and can not be leveraged for a distribution only approach. 2543

2544

Figure 24 Vaccine and Drug Inventory Reporting 2545

2546 2547



5/16/2010 Page 94 of 139

2.9.4 Service Collaboration Types 2548

The scope of the SampleHealth Immunization Management capability design as it relates to the Information Exchange 2549 and Data Requirements for the IRM Use Case is to enable electronic communication of immunization data among 2550 clinicians, with patients, and with other immunization registries as identified in Scenario 1 (Vaccine and Drug 2551 Administration and Reporting). All specification for Scenario 2 (Vaccine and Drug Inventory Reporting) has been 2552 deferred pending further analysis of the workflow, business actor responsibilities, and available standards suitable to 2553 fulfill the needs identified through this effort. We will include: 2554

Establish Transaction Packages, Transactions, and Components to complete the Use Case requirements 2555 related to the communication of vaccination information between patients, providers, and immunization 2556 registries, including registry-to-registry communications 2557 Enable optionality of architectures supporting traditional legacy message-based communications, addition 2558 of support for patient identification services (HITSP/TP22 Patient ID Cross-Referencing, HITSP/T23 2559 Patient Demographics Query) and the addition of support for document-centric sharing and point-to-point 2560 communications. This optionality will allow existing systems a migration path to adopt patient identity 2561 services and document sharing approaches without disrupting operational environments 2562 Adoption of HL7 V2.3.1 messaging with the expectation that this will be updated in accordance with future 2563 HL7 implementation guides 2564 Include Security and Privacy constraints for implementation of the Immunizations and Response 2565 Management Interoperability Specifications 2566

2567

We will NOT include Use Case actions requiring clinical decision support capabilities: 2568

Immunization Schedules 2569 Immunization Reminders 2570 Immunization Prioritizations 2571 Contraindication Alerts 2572 Active/Passive Surveillance for Adverse events 2573 All specification for Scenario 2 (Vaccine and Drug Inventory Reporting). 2574

2575

Figure 26 summarizes the system roles of the proposed Immunization Management Capability. 2576 2577

TBD 2578 Figure 25 Immunization Management Entities, Actions and Roles 2579

2580 Figure 26 Capability System Roles 2581

System Role System Role Definition

Immunization Schedule Sender* Immunization knowledge providers distribute immunization schedules for incorporation into Immunization Information Systems (IIS), other registries, EHR systems and possibly health information exchange.

Immunization Schedule Receiver* The system which receives the immunization schedule

Immunization Information Sender Registries, including IISs, provide immunization information to clinicians, consumers, other registries and other



5/16/2010 Page 95 of 139

organizations.

Immunization Information Receiver (clinician system)

The system which receives the immunization information

Vaccine or Drug Administration Information Sender

The system which sends the vaccine or drug administration information

Vaccine or Drug Administration Information Receiver

Registries, including IISs, gather vaccine or drug administration information from clinicians, consumers, other registries and other organizations

Immunization Information Sender (consumer PHR)

Consumers provide available immunization information to clinicians

Immunization Information Receiver (clinician system)

The system which receives the immunization information

Clinical Documentation Sender (clinician system) Following administration of (or inability to administer) a vaccine or drug the clinician provides appropriate clinical documentation to registries, consumers and others

Clinical Documentation Receiver The system which receives the clinical documentation

Public Health Information Sender* 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. 2582 2583 Figure 27 defines each of the Information Exchanges supported by the proposed Immunization Management 2584 Capability in terms of the Exchange Action (EA) or Exchange Content (EC) used. 2585

Figure 27 Information Exchanges Mapped to External Interfaces 2586 Information Exchange Identifier

Exchange Action Exchange Content

A** Send Immunization Schedules

B Send Immunization Information

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 96 of 139

Information Exchange Identifier

Exchange Action Exchange Content

H** Send Vaccine Recalls Information

NOTE: ** indicates this information exchange is out-of-scope to keep this case study short. 2587 2588

Figure 28 identifies how this Capability supports various system roles within multiple system architectures. For 2589 example, either an Electronic Health Record (EHR) system or a Health Information Exchange (HIE) might fill a 2590 registry system role in an information exchange). In an implementation architecture, system roles may be combined 2591 locally (e.g., Hospital EHR System) and in others, the system roles may be provided by multiple-distributed trusted 2592 third parties (e.g., registries within an HIE). 2593

Figure 28 Supported Information Exchanges 2594 cmp SampleHealth Immunization Management Capability

B, E, H

Consumer System (e.g., PHR)

C, D B, E, H A, B, D

Clinician System (e.g., EHR)

C, E, F, G, H A, B, D

A, B, C, E

Registry System (e.g., HIE)

B, C, F, H A, B, C, E

Immunization Information Provider

A

A - Immunization Schedules B - Immunization InformationC - Vaccine or Drug Administration InformationD - Immunization InformationE - Clinical DocumentationF - Public Health InformationG - Public Health Alert information H - Vaccine Recalls Information

A, B, C

Immunization Information

Systems (I IS)

B, C, F A, B, C

F

Public Health Systems

G F

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 organizations3. Registries, including IISs, gather vaccine or drug administration information from clinicians, consumers, other registries and other organizations4. Consumers provide available immunization information to clinicians5. Following administration of (or inability to administer) a vaccine or drug the clinician provides appropriate clinical documentation to registries, consumers and others6. 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

B, E

Other Organizations

C B, E

2595

2596 Figure 29 defines the mapping of the Information Exchanges supported by this Capability in terms of the Exchange 2597 Action (EA), Exchange Content (EC) and any Constraints applied to the Information Exchange with specific 2598 initiating and/or responding system interfaces. This provides the traceability of constructs to the information 2599 exchanges identified above. Content modules and terminology Components are not listed here because they are 2600 referenced by other constructs, but do not provide an interface. HITSP/TN903 discusses how content modules and 2601 terminology Components are referenced by other constructs. 2602



5/16/2010 Page 97 of 139

Figure 29 Information Exchanges Mapped to Constructs 2603 Information Exchange

Identifier Exchange Type Construct Identifier Description

A - Send Immunization Schedules

Send HITSP/64 - Identify Communication Recipients, HITSP/T81 - Retrieval of Medical Knowledge, HITSP/TP13 - Manage Sharing of Documents

Immunization knowledge providers distribute immunization schedules for incorporation into Immunization Information Systems (IIS), other registries, EHR systems and possibly health information exchange.

B - Send Immunization Information

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

Registries, including IISs, provide immunization information to clinicians, consumers, other registries and other organizations

C - Send Vaccine or Drug Administration Information

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

Registries, including IISs, gather vaccine or drug administration information from clinicians, consumers, other registries and other organizations

D - Send Immunization Information

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

Consumers provide available immunization information to clinicians

E - Send Clinical Documentation

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

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 98 of 139

Information Exchange Identifier

Exchange Type Construct Identifier Description

F - Send Public Health Information

Send HITSP/TP13 - Manage Sharing of Documents, HITSP/C78 - Immunization Document HITSP/C80 – Document and Message Terminology HITSP/C83 – CDA Content Modules

Public health gathers information to identify individuals needing prioritized intervention

G - Send Public Health Alert information

Send HITSP/64 - Identify Communication Recipients, HITSP/C82 - Emergency Common Alerting Protocol HITSP/T63 - Emergency Message Distribution Element

Public Health provides information to clinicians about populations or individuals having special needs for immunization or other intervention

H - Send Vaccine Recalls Information

Send HITSP/64 - Identify Communication Recipients HITSP/C62 - Unstructured Document

Registries provide information about vaccine recalls to clinicians and affected consumers

2604 2605 Next we will specify the HITSP Capability interfaces in terms of the Capability’s System Roles. 2606

Figure 30 Immunization Information Sender System Role Mapped to HITSP Construct Interfaces 2607

Optionality Legend: “R” for Required, “O” for Optional, or “C” for Conditional 2608

2609

Figure 31 Implementation Conditions 2610 Condition ID Condition Description

TBD

2611 TBD the set of system roles mapped to HITSP construct interfaces needs to be completed 2612 2613

Construct Interface

Interface Type T/TP/SC or Content T/SC/Content

Optionality

TBD

TBD

TBD

TBD



5/16/2010 Page 99 of 139

2.9.5 Service Contracts Parts 2614

SampleHealth is a signature in the NHIN Data Use and Reciprocal Support Agreement (DURSA39), which is a 2615 comprehensive, multi-party trust agreement that is signed by all eligible entities who wish to exchange data among 2616 its participant organizations. The DURSA requires signatories to abide by common set of terms and conditions that 2617 establish Participants’ obligations and the trust fabric to support the privacy, confidentiality and security of health 2618 data that is exchanged The DURSA assumes that each participant has trust relationships in place with its agents, 2619 employees and data connections (end users, systems, data suppliers, networks, etc.). The DURSA is a living 2620 document, the agreement is be modified over time. The following are the key provisions of the DURSA: 2621

Multi-Party Agreement: The DURSA accommodates and accounts for a variety of Participants so that it can 2622 successfully serve as a multi-party agreement among all Participants. This multi-party agreement is critical to avoid 2623 the need for each Participant to enter into “point-to-point” agreements with each other Participant, which becomes 2624 exceedingly difficult, costly and inefficient as the number of Participants increases. Federal participants have asserted 2625 that supporting point-to-point agreements is not sustainable for information exchange. 2626

Participants in Production: The DURSA expressly assumes that each Participant is in “production” and, as a 2627 result, already has in place trust agreements with or written policies applicable to its agents, employees and data 2628 connections (end users, data suppliers, systems, and networks, etc.). These trust agreements and policies must 2629 include terms necessary to support the trust framework memorialized in the DURSA. 2630

Applicable Law: The DURSA reaffirms each Participant’s obligation to comply with “Applicable Law.” As defined 2631 in the DURSA, “Applicable Law” is the law of the jurisdiction in which the Participant operates. 2632 For non-Federal Participants, this means the law in the state(s) in which the Participant operates and any 2633

applicable Federal law. 2634 For Federal Participants, this means applicable Federal law. 2635

Privacy and Security Obligations: To the extent that each Participant has existing privacy and security obligations 2636 under applicable law (e.g. HIPAA or other state or federal privacy and security statutes and regulations), the 2637 Participant is required to continue complying with these obligations. Participants, which are neither HIPAA covered 2638 entities, HIPAA business associates nor governmental agencies, are obligated to comply with specified HIPAA 2639 Privacy and Security provisions as a contractual standard of performance. 2640

Requests for Data Based on Permitted Purposes: Participant’s end users may only request data through the 2641 NHIN for “Permitted Purposes,” which include treatment, payment, limited health care operations with respect to 2642 the patient that is the subject of the data request, specific public health activities, quality reporting for “meaningful 2643 use” and disclosures based on an authorization from the individual. 2644

Duty to Respond: 2645 Participants that allow their respective end users to seek data for treatment purposes have a duty to respond to 2646

requests for data for treatment purposes. 2647 This duty to respond means that if actual data is not sent in response, the Participant will at a minimum send a 2648

standardized response to the requesting Participant. 2649 Participants are permitted, but not required, to respond to all other (non-treatment) requests. 2650 The DURSA does not require a Participant to disclose data when such a disclosure would conflict with 2651

Applicable Law. 2652

Future Use of Data Received Through the NHIN: Once the Participant or Participant’s end user receives data 2653 from a responding Participant (i.e. a copy of the responding Participant’s records), the recipient may incorporate 2654

39 For more information see www.hhs.gov/healthit and search “DURSA”.



5/16/2010 Page 100 of 139

that data into its records and retain that information in accordance with the recipient’s record retention policies and 2655 procedures. The recipient can re-use and re-disclose that data in accordance with all applicable law and the 2656 agreements between a Participant and its end users. 2657

Duties of Requesting and Responding Participants: When responding to a request for data, Participants will 2658 apply their local policies to determine whether and how to respond to the request. This concept is called the 2659 “autonomy principle” because each Participant can apply its own local access policies before requesting data from 2660 other Participants or releasing data to other Participants. It is the responsibility of the responding Participant – the 2661 one disclosing the data – to make sure that it has met all legal requirements before disclosing the data, including, but 2662 not limited to, obtaining any consent or authorization that is required by law applicable to the responding 2663 Participant. 2664

Duties of Requesting and Responding Participants: To effectively enable the exchange of health information in 2665 a manner that protects the privacy, confidentiality and security of the data, the DURSA adopts the HIPAA Privacy 2666 and Security Rules as minimum requirements. When a request is based on a purpose for which authorization is 2667 required under HIPAA (e.g. for SSA benefits determination), the requesting Participant must send a copy of the 2668 authorization with the request for data. Requesting Participants are not obligated to send a copy of an authorization 2669 or consent when requesting data for treatment purposes. 2670

NHIN Coordinating Committee: The NHIN Coordinating Committee is responsible for accomplishing the 2671 necessary planning, consensus building, and consistent approaches to developing, implementing and operating the 2672 NHIN, including playing a key role in the following: 2673 NHIN breach notification 2674 Dispute resolution 2675 Participant membership, suspension and termination; 2676 NHIN operating policies and procedures; and, 2677 Informing the NHIN Technical Board when proposed changes for interface specifications have a material 2678

impact on Participants. 2679

NHIN Technical Committee: The NHIN Technical Committee will be responsible for determining priorities for 2680 the NHIN and creating and adopting specifications and test approaches. The NHIN Technical Committee will work 2681 closely with the NHIN Coordinating Committee to assess the impact that changes to the specifications and test 2682 approaches may have on Participants. 2683

Breach Notification: Participants are required to promptly notify the NHIN Coordinating Committee and other 2684 impacted Participants of suspected breaches (within 1 hour) or confirmed breaches (within 24 hours) which involve 2685 the unauthorized disclosure of data through the NHIN, take steps to mitigate the breach and implement corrective 2686 action plans to prevent such breaches from occurring in the future. This process is not intended to address any 2687 obligations for notifying consumers of breaches, but simply establishes an obligation for Participants to notify each 2688 other and the Coordinating Committee when breaches occur to facilitate an appropriate response. 2689

Mandatory Non-Binding Dispute Resolution: Because the disputes that may arise between Participants will be 2690 relatively complex and unique, the Participants are required to participate in the dispute resolution process but are 2691 still free to pursue legal remedies if they are not satisfied with the outcome of the dispute resolution 2692 process. Following is the Multi-step process: 2693 Informal Conference between the Participants involved in the dispute 2694 If not resolved through the Informal Conference, the Dispute Resolution Subcommittee hears the dispute and 2695

is encouraged to develop an appropriate and equitable resolution 2696 NHIN Coordinating Committee can review the Subcommittee’s recommendation, if requested by any 2697

Participant involved in the dispute, and issue its own resolution 2698



5/16/2010 Page 101 of 139

Allocation of Liability Risk: With respect to liability, the DURSA articulates the Participants’ understanding that 2699 each Participant is responsible for its own acts or omissions and not for the acts or omissions of any other 2700 Participant. If a Participant allows a User to improperly access Message Content through the NHIN and another 2701 Participant is harmed as a result then the Participant who allows that access may be liable. However, the DURSA 2702 explicitly recognizes that a Participant cannot bring a cause of action against another Participant where the cause of 2703 action is prohibited by Applicable Law. This section is not intended as a hold harmless or indemnification provision. 2704

2.9.6 Conformance Statements 2705 The IMC specified information exchange requirements and their associated data requirements are satisfied 2706

or gaps are identified and a transition plan is specified.. 2707


The ECCF Platform-Independent Computation-Viewpoint presents SampleHealth’s exchange architecture, system 2709 functions and interface design specifications, which are specified by HITSP Capability, Service Collaboration, 2710 Transaction, transaction Package and Component constructs. 2711

2.10 Platform-Independent Engineering-Viewpoint 2712

The ECCF Platform-Independent Engineering-Viewpoint is defined by existing platform capabilities. The 2713 Engineering-Viewpoint is concerned with the mechanisms and functions required to support the 2714 interactions of the computational components. This ECCF viewpoint may overlap with the RM-ODP 2715 technology viewpoint, which is concerned with the explicit choice of technologies for the implementation 2716 of the system, and particularly for the communications among the components. This viewpoint answers 2717 the question “where” and refers to implementation environments. This viewpoint is of primary interest to 2718 Application Architects. This Viewpoint might typically contains some combination of: 2719

Existing Platform models, Capabilities, Libraries and Versions. 2720

2.10.1 Existing Platforms 2721 For SampleHealth the Platform-Independent Engineering-Viewpoint is defined by HSSP and NHIN Services to be: 2722 This viewpoint is primarily useful to enterprise architects. For SampleHealth the Conceptual Engineering-Viewpoint 2723 is defined by NHIN Connect to be: 2724 Apache Tomcat (or Jakarta Tomcat or simply Tomcat) is an open source servlet container developed by the 2725

Apache Software Foundation (ASF). Tomcat implements the Java Servlet and the JavaServer Pages (JSP) 2726 specifications from Sun Microsystems, and provides a "pure Java" HTTP web server environment for Java code 2727 to run. 2728

JBoss Application Server (or JBoss AS) is a free software/open-source Java EE-based application server. 2729 Because it is Java-based, the JBoss application server operates cross-platform: usable on any operating system 2730 that supports Java. JBoss AS was developed by Jboss, now a division of Red Hat. 2731

J2SE, Java Platform, Standard Edition or Java SE is a widely used platform for programming in the Java 2732 language. It is the Java Platform used to deploy portable applications for general use. In practical terms, Java SE 2733 consists of a virtual machine, which must be used to run Java programs, together with a set of libraries (or 2734 "packages") needed to allow the use of file systems, networks, graphical interfaces, and so on, from within those 2735 programs. 2736

Eclipse Open Healthcare Framework (OHF) is a project within Eclipse formed for the purpose of expediting 2737 healthcare informatics technology. The project is composed of extensible frameworks and tools which 2738



5/16/2010 Page 102 of 139

emphasize the use of existing and emerging standards in order to encourage interoperable open source 2739 infrastructure, thereby lowering integration barriers. 2740

GlassFish ESB v2 integrates the OpenESB project into the GlassFish Java 5 EE Application Server, where 2741 "Project OpenESB implements an Enterprise Service Bus (ESB) runtime using Java Business Integration (JBI) 2742 as the foundation, enabling the easy integration of web services to create loosely coupled, enterprise-class 2743 composite applications." 2744

GlassFish is an open source application server project led by Sun Microsystems for the Java EE platform. 2745 GlassFish is free software, dual-licensed under two free software licenses: the Common Development and 2746 Distribution License (CDDL) and the GNU General Public License (GPL) with the classpath exception. 2747 GlassFish is based on source code released by Sun and Oracle Corporation's TopLink persistence system. It 2748 uses a derivative of Apache Tomcat as the servlet container for serving Web content, with an added component 2749 called Grizzly which uses Java NIO for scalability and speed. 2750

OpenSSO is an open source access management and federation server platform. OpenSSO is based on Sun 2751 Java System Access Manager, and is the core of Sun's commercial access management and federation product, 2752 OpenSSO Enterprise (formerly Sun Access Manager and Sun Federation Manager). Oracle completed their 2753 acquisition of Sun Microsystems in February 2010 and announced that OpenSSO would no longer be their 2754 strategic product. OpenSSO will continue to be developed and supported by ForgeRock under the name of 2755 *OpenAM. 2756

. 2757


1. The NHIN CONNENT version 2.4 requirement for Apache Tomcat is met. 2759 2. The NHIN CONNENT version 2.4 requirement for JBoss Application Server is met. 2760 3. The NHIN CONNENT version 2.4 requirement for J2SE, Java Platform, Standard Edition is met. 2761 4. The NHIN CONNENT version 2.4 requirement for Eclipse Open Healthcare Framework (OHF) is met. 2762 5. The NHIN CONNENT version 2.4 requirement for GlassFish ESB v2 is met. 2763 6. The NHIN CONNENT version 2.4 requirement for GlassFish is met. 2764 7. The NHIN CONNENT version 2.4 requirement for OpenSSO is met. 2765


The IMC is built on SampleHealth existing environment, which is specified as part of the NHIN 2767 CONNECT version 2.4; as such, this section was done in a cursory fashion as an example. 2768

2.11 Platform-Specific Enterprise-Business-Viewpoint 2769

The ECCF Platform-Specific Enterprise-Business-Viewpoint defines the business and reference context. The 2770 Enterprise-Business-Viewpoint is concerned with the business or reference context, purpose and 2771 behaviors of the system as it relates to the business objective and the business processes of the 2772 organization. This viewpoint answers the question “why” and refers to policy. This viewpoint is primarily 2773 useful to managers, compliance staff and auditors. This Viewpoint might typically contains some 2774 combination of: 2775

Business Nodes 2776



5/16/2010 Page 103 of 139

Business Rules 2777 Business Procedures 2778 Business Workflow 2779

2780 2.11.1 Rules, Procedures and Industry Standards 2781

2782 2783 SampleHealth’s Platform-Specific Views includes the following: 2784

Rules – SampleHealth IMC must meet the appropriate HITEC ARRA Meaningful Use Objectives and 2785 Criteria and must use NHIN CONNECT version 2.4 services. 2786 Procedures – SampleHealth IMC must present its exchange architecture interoperability specifications using 2787 the HL7 SAIF-ECCF. 2788 Industry Technology-Specific Standards – SampleHealth must use the appropriate HSSP services. 2789


1. Appropriate IMC HITEC meaningful use objectives and criteria are identified and satisfied. 2791 2. The IMC exchange architecture interoperability specifications are presented, using the HL7 SAIF-2792

ECCF. 2793 3. IMC identifies and uses appropriate HSSP services. 2794


Details will be added between May and September 2010 as the physical IMC prototype is being developed. 2796 2797

2.12 Platform-Specific Information-Viewpoint 2798

The ECCF Platform-Specific Information-Viewpoint is defined by localized information models. The Information-2799 Viewpoint is concerned with the nature of the information handled by the system and constraints on the 2800 use and interpretation of that information. This viewpoint answers the question “what” and refers to 2801 information content. This viewpoint is primarily useful to information modelers. This viewpoint is 2802 primarily useful to managers, compliance staff and auditors. This Viewpoint might typically contains some 2803 combination of: 2804

Database Schemas 2805 Message Schemas 2806 Transformation Schemas 2807

2808 See the glossary for definitions of data vs. information and data models vs. information models. A Physical 2809 Level Data Model40 contains the same level of detail as the logical level, but has been transformed to show how the 2810 data would be stored within an information system. Information exchange structures and formats (messages) are 2811 also defined at the physical level. 2812 2813

40 Conceptual Health Data Model v2.3, Canadian Institute for Health Information



5/16/2010 Page 104 of 139

2.12.1 Schemas and Transformations 2814 2815

TBD 2816 2817

2.12.2 Conformance Statements 2818 TBD after architectural artifacts are completed and are sorted into the correct ECCF categories. 2819


SampleHealth’s Platform-Specific Viewpoint s will be added between May and September 2010, 2821 as the IMC prototype is being developed. 2822

2823

2.13 Platform-Specific Computation-Viewpoint 2824

13. The ECCF Conceptual Computation-Viewpoint is defined by collaboration analysis (e.g., UML sequence 2825 diagrams), functional profiles, service roles and relationships. The computational viewpoint is concerned 2826 with the functional decomposition of the system into a set of components that exhibit specific 2827 behaviors and interact at interfaces. This viewpoint answers the question “how” and references 2828 behavioral specifications. This viewpoint is primarily useful to system integrators and solution and 2829 solution architects. This Viewpoint might typically contains some combination of: 2830

Automation Unit 2831 Technical Interfaces 2832 Technical Operations 2833 Orchestration Scripts 2834

2835 2.13.1 Collaboration Scripts, Orchestration, Realized Interfaces 2836

TBD 2837


TBD after architectural artifacts are completed and are sorted into the correct ECCF categories. 2839


SampleHealth’s Platform-Specific Viewpoints will be added between May and September 2010 2841 as the IMC prototype is being developed. 2842

2.14 Platform-Specific Engineering-Viewpoint 2843

The ECCF Platform-Specific Engineering-Viewpoint is defined by existing platform capabilities. The Engineering-2844 Viewpoint is concerned with the mechanisms and functions required to support the interactions of the 2845 computational components. This ECCF viewpoint may overlap with the RM-ODP technology viewpoint, 2846 which is concerned with the explicit choice of technologies for the implementation of the system, and 2847 particularly for the communications among the components. This viewpoint answers the question “where” 2848



5/16/2010 Page 105 of 139

and refers to implementation environments. This viewpoint is primarily useful to application developers. 2849 This Viewpoint might typically contains some combination of: 2850

Application Specifications 2851 GUI specifications 2852 Deployment Topology or Execution Context 2853 Platform Bindings 2854

2855 2.14.1 Execution Context, Platform Bindings and Deployment 2856

2857 SampleHealth’s Platform-Specific Viewpoints will be added between May and September 2010 2858

as the IMC prototype is being developed. 2859 2860

2.14.1. Systems 2861 Immunization Management deals with the following systems: 2862 Electronic Health Record (EHR) System: The Electronic Health Record (EHR) System is a secure, real-2863

time, point-of-care, patient-centric information resource for clinicians 2864 o Supported stakeholders are: EHR System Suppliers, Healthcare Entities, Providers, (including 2865

healthcare delivery organizations, ancillary entities, clinicians pharmacy-based care delivery and 2866 immunization clinics), On-site care providers, and Schools 2867

Health Information Exchange (HIE): A Health Information Exchange (HIE) is a multi-stakeholder 2868 system that enables the exchange and use of health information, in a secure manner, for the purpose of 2869 promoting the improvement of health quality, safety and efficiency 2870

o Supported stakeholders are: EHR System Suppliers, Healthcare Entities, Providers, (including 2871 healthcare delivery organizations, ancillary entities, clinicians pharmacy-based care delivery and 2872 immunization clinics), On-site care providers, and Schools. 2873

Immunization Information System (IIS): IIS is used by local, state, and federal government 2874 organizations to identify populations at high risk for vaccine-preventable diseases and to target 2875 interventions and resources efficiently. Staff of stakeholder agencies interact with the IIS to verify and 2876 validate system indications of public health threats, and to assert acknowledgements that may be required by 2877 system processes. This includes, for instance, emergency preparedness registry, chronic disease registry 2878

o Supported stakeholders are: Geographic Health Information Exchange/Regional Health 2879 Information Organization, Point-to-Point Exchanges 2880

Personal Health Record (PHR) Systems: A healthcare record system used to create, review, annotate 2881 and maintain records by the patient or the caregiver for a patient. The PHR may include any aspect(s) of the 2882 health condition, medications, medical problems, allergies, vaccination history, visit history or 2883 communications with healthcare providers 2884

o Supported stakeholders are: Government Agencies, Healthcare Payors, Knowledge Providers, 2885 Public and Private Immunology, Vaccine Response, and Adverse Event Experts, Registries, Public 2886 Health Agencies/ Organizations (federal/state/local/territorial/tribal) 2887

Public Health Information System: An automated and integrated system used to document and address 2888 information of interest to public health. Local, state, and federal government organizations and personnel 2889 use these systems to help protect and improve the health of their respective constituents. A critical effort 2890 under this charge is collecting health information to monitor for the existence of emerging health threats 2891 appearing in the population and manage these threats once manifested. Staff of these agencies interacts with 2892



5/16/2010 Page 106 of 139

the public health information system to verify and validate system indications of public health threats, and 2893 to assert acknowledgements that may be required by system processes 2894

o Supported stakeholders are: Consumers, Patients, Personal Health Record (PHR) System Suppliers 2895 Supply Chain Management System: A system used by organizations managing the distribution of 2896

supplies and the oversight of materials, information, and finances as they move in a process from supplier 2897 to manufacturer to wholesaler to retailer to consumer. For example, used to track vaccines and associated 2898 supplies 2899

o Supported stakeholders are: Government Agencies, Knowledge Providers, Public and Private 2900 Immunology, Vaccine Response, and Adverse Event Experts, Registries, Response Management 2901 Organizations, Public Health Agencies/Organizations (federal/state/local/territorial/tribal) 2902

o Public and Private Sector Supply Chain, Inventory Managers. NOTE: Varying and changing 2903 business models impact the stakeholder that serves as this business actor in any given 2904 implementation (e.g., contracted distributor, manufacturer, public health authority, Registry etc) 2905

2906


TBD after architectural artifacts are completed and are sorted into the correct ECCF categories. 2908


SampleHealth’s Platform-Specific Viewpoints will be added between May and September 2010 2910 as the IMC prototype is being developed. 2911

2912

3 Conclusions and Lessons-Learned 2913

We believe that the resultant IMC ECCF presented above is a clear, complete, concise, correct, consistent 2914 and traceable exchange-architecture, Interoperability Specifications and Conformance Statements. The 2915 TOGAF ADM process and SAIF-ECCF structure were efficient for a distributed team to develop 2916 interoperability specifications for the IMC exchange architecture, using the EHR-SD RM. The HL7 SAIF-2917 ECCF might be considered the skeleton of an enterprise-architecture; ECCF was demonstrated to be an 2918 effective enterprise-architecture “Executive Summary”. The SD RM and its artifacts are evolving with the 2919 healthcare IT domain. Using the HL7 EHR-S FM, HITSP constructs and NHIN services as a reuse 2920 starting point was key to quickly filling out the IMC ECCF. The EHR SD RM facilitated the rapid 2921 identification of reusable architectural artifacts for the baseline IMC ECCF exchange architecture. Lessons 2922 learned from this case study are applicable to other processes (e.g., Rational Unified Process) and other 2923 frameworks (e.g., Zachman, DODAF). 2924 2925 A compelling story for the return-on-investment of SOA reuse can be told comparing: 2926

Table 10 As-Is SampleHealth Business Function Map versus 2927

Table 11 To-Be SampleHealth Business Function Map 2928 And then comparing: 2929

Figure 19 As-Is SampleHealth Information System High Level Architecture versus 2930



5/16/2010 Page 107 of 139

Figure 20 To-Be SampleHealth Information System High Level Architecture 2931 Both of these pairs of as-is and to-be figures show the massive SOA reuse the IMC project benefited 2932 from; making the IMC project relatively simple compared to starting from scratch. 2933 2934 One of the most difficult challenges facing healthcare organizations making IT investments today comes 2935 from deciding whether to go all-in with a particular vendor, or whether to self-integrate components from 2936 multiple vendors. The appeal of the single-vendor solution is strong – no finger-pointing, out-of-the-box 2937 integration, [US-based] EHR certification via the Certification Commission for Healthcare IT (CCHIT), 2938 and so on. 2939 This is contrasted with seemingly increased risk and work involved in a multi-vendor solution involving 2940 integration. A multi-vendor SOA solution can offer compelling best-of-breed options; where, a SOA 2941 promotes an easier integration and alignment across suppliers into a cohesive, testable and certifiable 2942 architecture. 2943 We demonstrated an approach that can build and present consistent Interoperability Specifications (IS) 2944 and conformance criteria for both best-of-suite and best-of-breed components and their exchange 2945 architecture. Having these ISs, exchange architectures, certification criteria and associated business cases is 2946 the appropriate due diligence needed to help justify a best-of-suite vs. best-of-breed decision. 2947 2948 The following lessons learned subsections are a living part of the document; they will periodically be 2949 reviewed and updated until the projects completion in October 2010. 2950

3.1 Immunization Management Lessons Learned 2951 1. Updating Legacy System Standards - The HITSP selected Immunization message is HL7 v2.5. 2952

Most existing immunization repositories are using HL7 v2.31. Not only are the repositories 2953 effected; additionally, feeder and user systems are affected. In some cases, it can be difficult to 2954 justify the expense to bring legacy system to current standards. 2955

2. Social Issues Trump Technical Issues - The Case Study shows an Immunization Management 2956 Capability technical solution; it does not address the more socially challenging Service Contract 2957 needed among stakeholders (e.g., agencies, states, hospitals). 2958

3. Information Model - There is an implicit common information model across immunization 2959 standards, which require an explicit common information model. . 2960

4. SOA and Cost - SOA changes the cost equation from N squared to a linear cost per interface 2961 5. Reuse has been shown to increase quality and reduce cost. 2962

3.2 ECCF Lessons Learned 2963 1. An ECCF SS can be presented as an “Architectural Executive Summary” or “Information Exchange 2964

Architecture” to add value to a project. 2965

2. A mature ECCF SS must be clear, complete, concise, correct, consistent and traceable, as a whole. ECCF 2966 documentation is misleading by saying that viewpoints must be horizontally consistent and vertically traceable. 2967

3. ECCF Viewpoint Conformance Statements – The ECCF would benefit by following the example of the EHR 2968 System Functional Model; statements, descriptions, “depends on” links and conformance statements for each 2969 viewpoint that is needed. Particular domains should have profiles, which subset the conformance statements to 2970



5/16/2010 Page 108 of 139

be suitable for the sub domains. Similarly, the governance framework, Information Framework would also 2971 benefit from this approach. 2972

4. The ECCF placement of architectural artifacts is not always intuitively obvious (e.g., structural specifications of 2973 modules and their information). Arguable, many of the Table 5 artifacts might be in both the Enterprise and 2974 Computational Viewpoints, such as: 2975 Functional and non-functional Requirements 2976 Stakeholders and their roles and capabilities 2977 Use Case inventory and Use Case Specifications 2978 Capabilities and their Services 2979 Component inventory 2980 Function-Service inventory 2981 Contracts and business rules 2982 Strict viewpoint traceability would require all of the above artifacts being in the Computational Viewpoint. 2983

5. The placement of traditional architectural artifacts (e.g., Text, Figures, Tables, BPMN and UML 2984 diagrams) into a particular ECCF viewpoint and layer is NOT prescribed by SAIF; placement is not 2985 always obvious (e.g., where do Use Case derived Information Exchange Requirements (IERs) go?). 2986 The general placement criteria used was first, the artifact intuitively fits best into a particular ECCF 2987 viewpoint-layer and second, presenting the architecture breadth-first, from beginning to end, flows and 2988 makes sense to an educated but uninformed audience. 2989

6. Architectural artifact granularity may not match ECCF categories (e, g,. component data and functions) 2990

7. A value set of architectural artifacts, clear definitions and model is needed. Because of ambiguity, some 2991 architectural artifacts are listed in multiple cells having different purpose and contents in the respective cells 2992 (e.g., business vs. requirements level and design level capability and contracts). 2993

8. Within the ECCF, “Function” and “Service” mean the same thing, considering that the difference between a 2994 well specified function and a service is that a service is public, reusable and has an associated Service Agreement 2995 or contract also known as a Distributed User Resource Sharing Agreement (DURSA). 2996

9. SAIF-ECCF conformance statements can be at a high abstract level; but, this adds the responsibility 2997 that the conformance tester is provided a detailed traceability matrix, detailed test specifications/ 2998 procedures to insure that all the appropriate architectural specifications are verifiable and certification 2999 results can be audited. 3000

10. This document shows an Immunization Management Capability technical solution; it does not address 3001 the challenge of the stakeholder Service Contract (e.g., among agencies, states, hospitals). 3002

11. Normally, architectures are presented as a set of documents, where a reader selects one-or-more 3003 viewpoint documents that are of interest. Presenting an single ECCF architectural executive summary 3004 document proved to be intimidating to some readers, who are not used to looking at an architecture as 3005 a whole. Readers, who “didn’t know where to start” needed a verbal architectural walk-through before 3006 they felt comfortable working on their own. 3007

12. Inventory of Architectural Artifacts - Table 13 HL7 SAIF Enterprise Conformance and Compliance 3008 Framework (ECCF) shows the sparsely populated set of architectural artifacts given in the ECCF 3009 documentation; it should be compared to the resultant densely populated Table 5 Notional Set of 3010 Architectural Artifacts within the HL7 SAIF ECCF SS. 3011



5/16/2010 Page 109 of 139

Filling out the conceptual and platform-independent layers of the ECCF, was relatively quick, thanks to 3012 the reuse of the artifacts identified by the EHR SD RM. Our IMC ECCF was easy to fill out, except for 3013 the Computation-Viewpoint. 3014

The Enterprise Business Viewpoint was intuitive to fill out. 3015 The Information Viewpoint was intuitive to fill out. 3016 The Computation-Viewpoint was difficult to determine where structural specifications, which show the 3017

encapsulation of information with functions to define components and capabilities. 3018 The Engineering Viewpoint was intuitive to fill out; but, it was not obvious the distinction between the 3019

conceptual and platform-independent layers because we do not have a reference architecture for the 3020 engineering view. 3021

Using the ECCF to present an exchange architecture and its conformance statements as an enterprise 3022 architecture “Executive Summary” proved to be effective; we presented the ECCF breadth-first across the 3023 viewpoints of each layer; we first presented the conceptual, then platform-independent and finally 3024 platform-dependent layers and their respective viewpoints. 3025 3026

3.3 SOA Lessons Learner 3027 1. Reuse of legacy services can make a project significantly faster, better and cheaper; but, managing the 3028

reuse library of candidate services and their specifications can be challenging. Specifically, funding and 3029 policies must be provided to manage, publish and mandate the use of the Reusable Components and 3030 Services. It is easy for each project to create stovepipe services without harmonizing and reusing 3031 services across an enterprise. 3032

2. Functions and Services differ by a Service Level Agreement and the documented specificity of a 3033 service interoperability specification. 3034

3.4 TOGAF ADM Lessons Learned 3035 3036 1. As the TOGAF ADM implies, requirements, conformance statements, test specifications and risks 3037

should be managed/ governed throughout the Business Capability, Architecture and Software 3038 Development Lifecycles, as they evolve. 3039

2. Methodologies must be adaptable to suite the needs of projects. In our case, we augmented HL7 SAIF 3040 with TOGAF ADM, DOD Instruction 5000.2 acquisition processes (e.g., governance) and HITSP’s 3041 TN903 Data Architecture (e.g., Clinical Information Model). 3042

3. TOGAF ADM initially led the project team to organize the architectural artifacts chronologically, in 3043 the order they were developed; not SAIF-ECCF organized, as they are needed for architectural reviews 3044 and analysis. We reorganized the artifacts for ECCF presentation and we moved the TOGAF 3045 overview to the appendix. This resulted in some rework; but, this pitfall is easily avoidable in the 3046 future. 3047

4 Acronym List 3048

B2B: Business-to-Business 3049 BPMN: Business Process Management Notation 3050 BPEL: Business Process Execution Language 3051



5/16/2010 Page 110 of 139

CCD: Continuity of Care Document 3052 CDA: Clinical Document Architecture. 3053 CCR: Continuity of Care Record 3054 CM: Configuration Management 3055 CRFQ: Clinical Research Filtered Query 3056 CTS/CTS2: Common Terminology Service 3057 DSS: Decision Support Service 3058 EA: Enterprise Architecture 3059 ED: Emergency Department 3060 EHR: Electronic Health Record 3061 EIS: Entity Identification Service 3062 ESB: Enterprise Service Bus 3063 HL7: Health Level Seven 3064 HSD: Human Services Directory 3065 HSSP: Healthcare Services Specification Project 3066 OMG: Object Management Group 3067 PASS: Privacy, Access, Security Services 3068 RLUS: Retrieve, Locate, Update Service 3069 SOA: Service-oriented Architecture 3070

5 Glossary 3071

A glossary of architectural terms is provided in Section 2.2.4. Following is the glossary for the main body of 3072 the document. 3073 3074 TBD 3075

3076 6 References 3077

TBD 3078

7 Appendix 3079

7.1 Background ......................................................................................................................................................111 3080 7.1.1 Service Oriented Architecture (SOA)...........................................................................................111 3081 7.1.2 EHR System Functional Model (EHR-S FM) ............................................................................113 3082 7.1.3 Healthcare SOA Reference Architecture (H-SOA-RA) ............................................................116 3083 7.1.4 Reference Information Model (RIM)...........................................................................................117 3084 7.1.5 Federal Health Information Model (FHIM) ...............................................................................118 3085 7.1.6 Healthcare Service Specification Project (HSSP) .......................................................................120 3086 7.1.7 Service Aware Interoperability Framework (SAIF)....................................................................121 3087 7.1.8 Integrating the Healthcare Enterprise (IHE) ..............................................................................122 3088 7.1.9 EHR System Design Reference Model (EHR-SD RM) ............................................................123 3089 7.1.10 Health Information Technology Standards Panel (HITSP)......................................................125 3090 7.1.11 Certification Commission for Health Information Technology (CCHIT).............................127 3091 7.1.12 National Information Exchange Model (NIEM) .......................................................................128 3092 7.1.13 Nationwide Health Information Network (NHIN)...................................................................129 3093



5/16/2010 Page 111 of 139

7.1.14 Universal Immunization Tracking System (UITS) .....................................................................130 3094 7.2 TOGAF Architecture Development Method (ADM)..........................................................................131 3095

7.2.1 Preliminary........................................................................................................................................132 3096 7.2.2 A – Architecture Vision..................................................................................................................133 3097 7.2.3 B – Business Architecture ..............................................................................................................134 3098 7.2.4 C – Information Systems Architecture ........................................................................................134 3099 7.2.5 D – Technology Architecture........................................................................................................135 3100 7.2.6 E – Opportunities and Solutions ..................................................................................................136 3101 7.2.7 F – Migration Planning...................................................................................................................136 3102 7.2.8 G – Implementation Governance.................................................................................................137 3103 7.2.9 H – Architecture Change Management .......................................................................................138 3104

3105

7.1 Background 3106 The EHR-SD RM prototype example is based on HL7-OMG HSSP, HL7 EHR-S FM, HL7 RIM, HL7 SAIF, 3107 HITSP and IHE artifacts. 3108 3109

7.1.1 Service Oriented Architecture (SOA) 3110 This section is based on Thomas Erl’s “SOA Principles of Service Design” July 28, 2007, Prentice Hall. SOA is “A 3111 technology architecture Design Paradigm which can be applied in the context of Distributed Computing which 3112 collectively expresses a set of core Design Principles which collectively realize a set of Design Characteristics?” -- 3113 [Thomas Erl, “SOA Principles of Service Design.”] Semantics are critical to interoperability in the domain of healthcare, 3114 which often requires computable semantic interoperability. 3115 3116 SOA Strategic Goals [Thomas Erl] are: 3117 Intrinsic Interoperability 3118

– Interoperability vs. Integration 3119 Increased Federation 3120

– Common endpoint and local governance 3121 Increased business/technology alignment 3122

– Linear “degree of difficulty” for change 3123 Increased vendor neutrality options 3124

– Specifications at a logical level (ECCF PIM) 3125 3126 SOA Strategic Benefits are: 3127 Increased ROI 3128

– Reuse vs inconsistent Redundancy 3129 – Applications as “compositional aggregations” 3130

Increased Organizational Agility 3131 – Business evolution aligned with technology flexibility 3132

Reduced IT footprint 3133 – Elimination of redundancy and inconsistency 3134 – Elimination of one-off integration activities 3135 – Decreased governance burden 3136

3137



5/16/2010 Page 112 of 139

SOA Design Principles are: 3138 Standardized Service Contracts 3139 Service Loose Coupling 3140 Service Abstraction 3141 Service Reusability 3142 Service Autonomy 3143 Service Statelessness 3144 Service Discoverability 3145 Service Composability 3146

3147 Intrinsic

Inter- operability

Increased Federation

Increased Business/Technology

Alignment

Increased Vendor

Diversification Options

Increased ROI

Increased Organiza-

tional Agility

Decreased IT Burden

Standard Service

Contracts

X X X X X X X

Service Loose Coupling

X X X X X X

Service Abstraction

X X X X X X

Service Reusability

X X X X X

Service Autonomy

X X X X X X

Service Statelessness

X X X X

Service Discoverability

X X X X X

Service Composability

X X X X X

Table 12 Design Principles vs. Strategic Goals and Benefits 3148 3149 SOA Challenges are: 3150 increased design complexity 3151 need for Design Standards (informational, behavioral) 3152 top-down delivery requirements 3153 “counter-agile” (contract-first) design/delivery 3154 governance requirements 3155

3156 SOA Benefits are: 3157 Advantages gained from SOA: users will realize benefits from the solution to each aspect of the Problem 3158

Statement:… 3159 – focus on business capabilities increased agility 3160 – fine-grained certification increased predictability and reliability 3161 – automated certification increased responsiveness to change and evolution of software components 3162 – technology-independent specifications increased vendor participation and cross-vendor interoperability 3163

3164 Road Map to sSOA via SAIF/ECCF: 3165



5/16/2010 Page 113 of 139

Some things will evolve: 3166 – Static data, metadata, terminology representations, and tooling 3167 – Application development from monolithic to service composition 3168 – Increased emphasis on enterprise architecture 3169 – Increased emphasis on Continuous Integration 3170

Some things will be new: 3171 – Behavioral metadata that is defined and captured 3172 – Artifacts that define ECCF Specification Stack instances 3173 – Increased emphasis on automated testing/certification 3174 – Tooling to support new data/metadata and processes 3175 – Focus on software contracts as basis for Computable Semantic Interoperability (CSI) 3176 – Formal requirements traceability 3177 – Formal project and architecture governance 3178 – Some aspects of software engineering process 3179 – Some aspects of contracts for development organizations 3180

7.1.2 EHR System Functional Model (EHR-S FM) 3181

HL7 traditionally develops standards around messaging and interoperability. However, in July 2003 it collaborated 3182 with public and private healthcare leaders to develop the EHR functional standard. In May 2004 Health Level Seven 3183 (HL7), an ANSI-accredited designated standards organization, announced passage of the electronic health record 3184 system (EHR-S) draft standard for trial use (DSTU). In 2007 Electronic Health Record System Functional Model 3185 became a Normative Standard (ANSI-approved). This draft standard summarizes the functions that may be present 3186 in an EHR system and provides a common language for communicating its behaviors and capabilities. The EHR-S 3187 FM’s scope is limited to functionality and does not address data content for the EHR or endorse the use of specific 3188 technology. An EHR-S could be one system with applicable functionality in the EHR-S FM standard, or it could be 3189 a variety of interoperable systems that combine to meet the functionality of the EHR-S FM. An EHR is the data 3190 content contained within the EHR system. 3191



5/16/2010 Page 114 of 139

3192

Figure 32 HL7 EHR System Functional Model (EHR-S FM) 3193

Figure 32 HL7 EHR System Functional Model (EHR-S FM) shows the EHR-S FM structure, which contains more 3194 than 160 hierarchically categorized functions. They are broken into three main sections: 3195

Direct care 3196 Supportive 3197 Information infrastructure 3198

Each function is assigned an ID and includes a title, a short statement, and a longer narrative describing the 3199 functionality. The example below illustrates the format of the EHR-S functional model. 3200

3201

3202

3203

EDITORS NOTE: use DC1.8.2 Immunization Management example here, rather than DC1.1.4. 3204



5/16/2010 Page 115 of 139

ID Title Statement Description See Also

DC.1.1.4 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.2.2.1 IN.1.9 IN.2.4 IN.2.5.1IN.2.5.2

Each system function may also indicate dependencies on other functions (“see also”) and conformance criteria, such 3205 as: 3206

DC.1.1.4 Conformance Criteria: 3207

1. The system SHALL present summarized views and reports of the patient’s comprehensive EHR. 3208 2. The system SHOULD include at least the following in the summary: problem list, medication list, allergy and 3209 adverse reaction list. 3210 3. The system SHOULD conform to function S.3.3.6 (Health Service Reports at the Conclusion of an Episode of 3211 Care). 3212 4. The system SHOULD conform to function IN.1.4 (Patient Access Management). 3213 5. The system SHALL conform to function IN.2.2 (Auditable Records). 3214 3215 For a particular function, the conformance criteria should be collected across all of its dependencies, resulting in a 3216 comprehensive set of functional requirements and test specifications. 3217

Functions are outlined in a hierarchical manner; for example: 3218

DC.1.2—Care plans, guidelines, and protocols 3219 (This is the “parent” function. Additional related functions are listed below as “children.”) 3220

DC.1.2.1—Present care plans, guidelines, and protocols (child function) 3221 DC.1.2.2—Manage guidelines, protocols, and patient-specific care plans (child function) 3222 DC.1.2.3—Generate and record patient-specific instructions (child function) 3223

The direct care section of the functional model addresses functionality related to the care delivery process under three 3224 main headings: 3225

DC.1 Care Management 3226 DC.2 Clinical Decision Support 3227 DC.3 Operations Management and Communication 3228

The direct care section is comprised of parent functions, with children functions that provide more detail and 3229 granularity. The table identifies the main functions and then summarizes the functionality within the section. 3230



5/16/2010 Page 116 of 139

The supportive section of the EHR-S FM addresses functionality related to administrative and financial requirements 3231 associated with care delivery. It includes support for medical research, public health, and quality improvement. 3232 There are three main sections: 3233

S.1 Clinical Support 3234 S.2 Measurement, Analysis, Research, Reporting 3235 S.3 Administrative and Financial 3236

Most, but not all, of the functions in the supportive section have both parent and child sub-functions. 3237

The information infrastructure section of the EHR-S FM addresses functionality related to technical capabilities that are 3238 essential to support operations and the direct care functions. There are seven main sections: 3239

I.1 EHR Security 3240 I.2 EHR Information and Records Management 3241 I.3 Unique Identity, Registry, and Directory Services 3242 I.4 Support for Health Informatics and Terminology Standards 3243 I.5 Interoperability 3244 I.6 Manage Business Rules 3245 I.7 Workflow 3246

Most of the functions in the seven sections include both parent and child functions. 3247

7.1.3 Healthcare SOA Reference Architecture (H-SOA-RA) 3248 In 2008, the Figure 33 Healthcare SOA Reference Architecture (H-SOA-RA) based on the Figure 32 HL7 EHR 3249 System Functional Model (EHR-S FM) and the ISO 7498-1 layers [ISO/IEC 7498-1 Information technology – 3250 Open Systems Interconnection – Basic Reference Model: The Basic Model]. The H-SOA-RA supports a structured 3251 reuse-based approach to architectural specifications within the healthcare domain and across domains, which 3252 intersect the healthcare domain (e.g., emergency responder). It also provides a common vocabulary, to discuss 3253 requirements traceability to design specifications, to implementations, to deployments, to tests and to certifications; 3254 with the aim to encourage lexical and semantic consistency throughout the Business Capability Lifecycle (BCL). 3255

The Healthcare SOA Reference Architecture (H-SOA-RA), was built on commercial healthcare models (e.g., HL7 3256 EHR System Functional Model (EHR-S)) and ISO based SOA layers [SOA Principles of Service Design by Thomas 3257 Erl 2007]. The objective of the H-SOA-RA is to assure semantic interoperability at the Service Level and 3258 consistency within and among systems’ architectural interoperability specifications, resulting in aligned, interoperable 3259 and agile enterprise architectures and their system components. The H-SOA-RA allows logical specifications of 3260 business transformation architectures and their associated investment portfolios; it allows system component 3261 flexibility/options in the ultimate physical “best-of-breed component” implementations. 3262



5/16/2010 Page 117 of 139

3263 Figure 33 Healthcare SOA Reference Architecture (H-SOA-RA) 3264

The H-SOA-RA is intended to support the transformation of a behavior model’s systems and their capabilities (e.g., 3265 business process model or use case) into system structural models of components and their interfaces (e.g., system 3266 functions and services). In particular the H-SOA-RA focuses on constructing system components from candidate 3267 reusable services (e.g., composite services, entity services, application services, agnostic or common services.). 3268 Healthcare Information Technology Standards Panel (HITSP) constructs (e.g., data components, transaction 3269 packages, transactions and their associated standards specifications) provide architectural constraints, which are 3270 intended to assure Electronic Healthcare Record (EHR) interoperability. 3271

7.1.4 Reference Information Model (RIM) 3272 The purpose of a Reference Information Model is to share consistent meaning beyond a local context. In general, 3273 the broader the scope of interest, the more important it is to make all assumptions about a topic of interest explicit. 3274 The HL7 Version 3 Reference Information Model (RIM) is a comprehensive source of all information subjects used 3275 in any HL7 specification. 3276 Since HL7 specifications permit loosely coupled information systems to interoperate, the scope of the HL7 RIM is 3277 the information required to be understood between information systems, but not necessarily all information 3278 recorded within any particular system. As HL7 specifications are used to connect information systems operated in 3279 different circumstances, across many types of healthcare delivery organizations and potentially across political 3280



5/16/2010 Page 118 of 139

jurisdictions, the HL7 RIM needs to be flexible enough to express a diverse range of information content while 3281 maintaining a unified framework. 3282 The Version 3 RIM articulates explicit definitions of the things of interest referenced in HL7 messages, structured 3283 documents or any future HL7 "information packages" specification. The RIM also contains definitions of the 3284 characteristics of these things of interest and the relationships among them. 3285

3286 Figure 34 HL7 Reference Information Model (RIM) 3287

The Reference Information Model is expressed using a modified object notation similar to that used in UML. The 3288 RIM is graphically presented as a network of classes containing their attributes and connected by their associations. 3289 Behind the graph are the details of all the definitions, connections and constraints. All information about the RIM is 3290 held in a repository that contains the details, the connections among the details and the changes over time. 3291 The HL7 RIM is not a model of a database, or any particular vendor's information system, or any particular 3292 healthcare organization enterprise, or even any particular set of messages. Any of these specific contexts may have 3293 an information model of their own and can use a similar form of notation. 3294

7.1.5 Federal Health Information Model (FHIM) 3295 The Federal Health Architecture (FHA) sponsored Federal Health Information Model (FHIM) work group directs 3296 and coordinates federal engagement in health IT SDOs and other IT standards related organizations. The goal of 3297 the work group is to enable health information interoperability by participating in the development and 3298 implementation of a comprehensive, integrated health information model and set of standards that support the 3299 semantic interoperability requirements of ARRA. 3300



5/16/2010 Page 119 of 139

• The HL7 Reference Information Model (RIM) is leveraged as a reference model for the FHIM 3301 • The FHIM is a comprehensive, integrated, logical, health information model and associated terminology 3302

models. 3303 • The FHIM includes the HITSP/ TN903 Data Architecture 3304

• To support the exchange of health information between Federal partners 3305 • To standardize the exchange of health information between Federal partners and their 3306

commercial partners as NIEM IEPDs. 3307 • Supports the consolidation of information exchange formats from the existing (and expanding) 8-9 3308

to 3 or possibly even 1 in the long-term 3309 • Enables implementation of Service Oriented Architectures by Federal partners 3310 • Reduces the amount of mapping between different information concepts, information attributes 3311

and terminologies/code sets that Federal partners must currently support 3312 • Identifies terminology and code set requirements that have not yet been addressed 3313 • Improves harmonization of information concepts and attributes across standards development 3314

organizations 3315 • The FHIM supports health interoperability, especially semantic interoperability 3316

• As the basis for work between Federal partners and standards related organizations to enhance 3317 existing or develop new standards 3318

• As the basis for defining information requirements for inclusion in vendor contracts 3319 • As the basis for defining information requirements for in-house developed applications and 3320

databases, especially in organizations implementing model-driven architectures 3321 • As a component of the Data Use and Reciprocal Support Agreement (DURSA) among trading 3322

partners and their service contracts 3323 • The FHIM is built by harmonizing information from the individual Federal partners and from standards 3324

organizations. 3325 • The FHIM has the potential to become the Federal Health Architecture information model for NIEM and 3326

NHIN. 3327 3328 3329 3330 3331 3332



5/16/2010 Page 120 of 139

3333 3334

3335

Figure 35 FHIM relationship to NIEM 3336

7.1.6 Healthcare Service Specification Project (HSSP) 3337 The Healthcare Services Specification Project (HSSP) project is a collaborative effort between Health Level Seven 3338 [http://www.hl7.org] and the Object Management Group [http://www.omg.org] to address interoperability 3339 challenges within the healthcare sector and to identify and document service specifications, functionality, and 3340 conformance resulting in real-world implementations. 3341 3342 The following Candidate HSSP Services will be considered within this interoperability specification: 3343 CTS2 (Common Terminology Services 2) 3344

CTS 2 is a standard for terminology services that enhances the capabilities of the initial CTS specification 3345 for sub-setting and mapping, and extends the specification into domains such as terminology distribution, 3346 versioning, and classification. 3347

DSS (Decision Support Service) 3348 A commonly accepted standard for the DSS would make it more attractive for service consumers to invest 3349 in the infrastructure required for using the DSS to meet its patient evaluation needs, as they would be able 3350 to use the same interface to interact with multiple service vendors. 3351

HCPDS (Healthcare Provider and Services Directory Service) 3352 HCPDS is required to provide an online facility that will enable Practitioners, via a set of parameters, to 3353 locate other practitioners, to assist in the continuum of care. 3354

IXS (Identity Cross-Reference Service, formerly known as Entity Identification Service) Normative 3355 In balloting to become a full HL7 standard. 3356



5/16/2010 Page 121 of 139

PASS (Privacy, Access and Security Services) 3357 The goal of PASS is to define a suite of services that will provide a simple interface for all privacy, access 3358 control, consent, identity management and other security services that are needed in a service-oriented 3359 health information architecture. 3360

RLUS (Retrieve, Locate and Update Service) and EIS (Entity Identification Service) 3361 The HL7 SFM has been approved by the HL7 Board as an official DSTU. 3362

7.1.7 Service Aware Interoperability Framework (SAIF) 3363 The collective work of the HL7 Architecture Board (ArB) is called the HL7 Services-Aware Interoperability 3364 Framework (HL7 SAIF41). We note that SAIF is NOT an enterprise architectural framework; but rather, SAIF is an 3365 interoperability framework. The goal of SAIF is to ensure interoperability among various healthcare organizations. 3366 Medical and healthcare organizations using different technologies, software, and business structures need a common 3367 framework for sharing documents, messages, and services with other organizations. An example of a document 3368 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 3369 longitudinal health record. Often these organizations are unable to share the information because the different 3370 systems do not interoperate with each other, which may likely increase delays and expenses. For a long time, HL7 3371 has been developing specifications, methodologies, and extensible standards for making healthcare systems 3372 interoperable. HL7 collaborates with healthcare information users and other Standards Development Organizations, 3373 and enables domain experts from the healthcare industry to develop healthcare information standards in their areas 3374 of expertise. 3375 3376 SAIF seeks to meet this need by providing a framework for ensuring interoperability for documents, messages, and 3377 services between organizations. SAIF is designed not only to craft software components -- messages, computable 3378 documents, services, and applications -- that are usable in the healthcare, life sciences, and clinical research domains, 3379 but also to facilitate and enable efficient lines of communications between the various cross-functional teams. 3380 3381 The SAIF satisfies the following principles/ criteria: 3382 Applies to each of HL7's three interoperability paradigms (IPs): messages, documents, and services. 3383 Provides support for measurable conformance and compliance. 3384 Defines appropriate governance structures and processes. 3385 Provides support for directly implementable solutions. 3386 Addresses the growing disparity between the various solution sets emerging from HL7 3387 Uses existing HL7 V3 and Reference Information Model (RIM) artifacts and expertise to the maximum degree 3388

possible. 3389 3390 SAIF consists of four core components: 3391 Enterprise Conformance and Compliance Framework (ECCF) 3392 Governance Framework (GF) 3393 Behavioral Framework (BF) 3394 Information Framework (IF) 3395 3396 Together, these sub-frameworks provide an overarching framework for specifying (and governing the specification 3397 of) the set of artifacts that enables HL7 to develop specifications which support Working Interoperability (WI) 3398 41 http://www.hl7.org/permalink/?SAIF



5/16/2010 Page 122 of 139

among parties using HL7 specifications, either alone, or with other specifications that other organizations have 3399 developed. The ECCF, shown in Table 13 below, shows a prototypic ECCF specification stack (SS) template with 3400 example artifacts in each cell. It is based on the ISO Reference Model of the Open Distributed Processing 3401 (RMODP) and extends the historical work within HL7 on conformance. The BF formalizes and extends the 3402 constructs of the HL7 Dynamic module to include explicit semantics around contracts and integration. The IF is an 3403 extension of the HL7 Reference Information Model (RIM), shown in Figure 34 above. 3404 3405

3406 Table 13 HL7 SAIF Enterprise Conformance and Compliance Framework (ECCF) 3407

7.1.8 Integrating the Healthcare Enterprise (IHE) 3408 Integrating the Healthcare Enterprise (IHE) is an initiative by healthcare professionals and industry to improve the 3409 way computer systems in healthcare share information. IHE promotes the coordinated use of established standards 3410 such as DICOM and HL7 to address specific clinical needs in support of optimal patient care. Systems developed in 3411 accordance with IHE communicate with one another better, are easier to implement, and enable care providers to 3412 use information more effectively. 3413 3414 IHE brings together users and developers of healthcare information technology (HIT) in an annually recurring four-3415 step process: 3416

1. Clinical and technical experts define critical use cases for information sharing. 3417



5/16/2010 Page 123 of 139

2. Technical experts create detailed specifications for communication among systems to address these use 3418 cases, selecting and optimizing established standards. 3419

3. Industry implements these specifications called IHE Profiles in HIT systems. 3420 4. IHE tests vendors’ systems at carefully planned and supervised events called Connectathons. 3421

3422

7.1.9 EHR System Design Reference Model (EHR-SD RM) 3423 HL7 EHR System Design Reference Model (EHR-SD RM)42 project expands the H-SOA RA; but still starts with 3424 the EHR System Functional Model (EHR-S FM). Emphasis is placed on mapping to ARRA HITECH standards 3425 and meaningful use measures, HITSP ISs, NIEM IEPDs, and CCHIT conformance criteria. 3426

3427 Figure 36 EHR-SD RM Leveraging Standards Related Organizations 3428 To Get the Right Information to the Right Analyst at the Right Time 3429

Reference architectures generally have lists of: 3430 1) System Functions or Services (aka, methods), 3431 2) Reusable components composed of one or more encapsulated objects and 3432 3) Policies, standards and constraints. 3433

In a constrained system design (e.g., net-centric43 Service Oriented Architecture (SOA)), reference architectures can 3434 be used to allocate capabilities and their system functions to system components, while maintaining architectural 3435 constraints, resulting in a design baseline. 3436

Reference architectures can be defined at different levels of abstraction: 3437 ‐ A deployment reference-architecture might show different pieces of equipment on a communications network, 3438

each component providing gross functionality (e.g., Application Server, Database Server, Master Patient Index, 3439 etc.). 3440

‐ A business reference-architecture decomposes business-process views, which show persons, organizations and 3441 systems; it includes the information exchanges within and among business processes. Our approach is to have 3442 the H-SOA-RA constrain the functions, which are allocated to systems. 3443

‐ An inheritance reference-architecture might include functions, which can be constructed into system 3444 components. 3445

3446 Federal Agencies are mandated to have Healthcare Information Technology Standards Panel (HITSP) conformant 3447 interoperable Electronic Healthcare Records (EHR) and systems. Our strategy is to focus on HITSP conformant 3448 interoperability at the service level. 3449 3450

42 Additional information is available at http://hssp.wikispaces.com/Reference+Architecture 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 124 of 139

class EHR SD RM

Functional Analysis Object Analysis

Constructs

+ Component (C)+ Transaction (T)+ Transaction Package (TP)+ Service Collaboration (SC)

Capability Requirements

+ Information Exchange+ option+ Scenario+ system role

Information Exchange Requirement (IER)

+ Systems+ Exchange Content+ Exchange Action+ Exchange Attribute

Service

Capability Design

+ conditions+ optionality+ system role

Interface

SOA Layers

+ Business Processes+ Composite Services+ Core Business Services+ Component Services+ Operational Services+ Implementation Profiles

requirements

design

Legend

EHR Business Architecture

ARRA Selected Standard

Certification Criteria

+ Capability

Federal Health Information Model (FHIM)

Reference Information Model (RIM)

+ Entity+ Role+ Act+ Participation+ Act relationship+ Role relationship

Clinical Document Architecture (CDA)

ARRA Meaningful Use Measure

+ Stakeholder

Agency Information Model

NHIN Connect Service

Realize relationship: a source object implements or Realizes its destination object. Realize connectors are used to express traceability and completeness in the model.

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 forthe Information Exchange Requirements supported by the capability.

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.

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.

EHR-S FM

+ Direct Care+ Supportive Care+ Information Infrastructure

Behavioral Model

Functional Requirements

Use Case

+ scenario

Service Taxonomy

ARRA is American Recovery and Reinvestment Act of 2009FHIM is Federal Health Information ModelEHR-S FM is EHR System Functional-ModelEHR SD RM is EHR System Design Reference-ModelNIEM IEPD is National Information Exchange Model (NIEM) Information Exchange Package Documentation (IEPD)

NIEM IEPD

SOA Analysis

realize

is-a

3451 Figure 37 Conceptual View of the HL7 EHR System Design Reference Model 3452

3453 Figure 37 Conceptual View of the HL7 EHR System Design Reference Model shows how a user can start with 3454 functions (EHR-S FM) or data (e.g., RIM), requirements and behavioral specifications (e.g., use cases) to define 3455 capabilities and information exchanges, which can be allocated to systems and their standards-based interfaces,; the 3456 interoperable interfaces can be implemented as services. 3457

7.1.9. EHR-SD RM within the Requirements Management and Architecture Cycle 3458 The EHR-SD RM supports the requirements, specifications, design and test processes as is shown in Figure 38 3459 Stakeholder Requirements answer the questions WHAT is the system supposed to do? WHERE will the 3460

products of the system be used? Under what conditions are the products used? How often does the system 3461 produce its products? How long does it take to produce the products? Who will use the products of the 3462 system? 3463

Requirements Analysis answers the questions HOW, using “Action Verbs”. In this step we analyze functions 3464 and Services by decomposing higher level functions to lower level functions and Allocating performance 3465 requirements to the functions. 3466

Architecture Design answers the questions of WHICH hardware and software elements define the physical 3467 architecture, WHERE each part must perform at least one function and some parts may perform more than 3468 one function. 3469

Test Specifications answer the question of HOW Requirements-Specifications are validated. 3470



5/16/2010 Page 125 of 139

The Requirements Loop ensures that all requirements are covered by at least one function and it ensures that 3471 all functions are justified by a valid requirement (no unnecessary duplication). 3472

The Design Loop ensures that all functions are covered by at least one hardware or software element and it 3473 also ensures that all elements of the physical architecture are justified by a valid functional requirement (no 3474 unnecessary duplication). 3475

The Verification & Validation (V&V) Loop verifies that that the solution meets the requirements and 3476 validates that the solution meets the user’s needs and expectations. Note that V&V can be accomplished by: 3477 Inspection, Analysis, Demonstration or Test. 3478

The Test Loop ensures that all information is covered by test specifications and it also ensures that all 3479 interfaces are covered by test specifications. 3480

3481

3482 Figure 38 EHR-SD RM Supporting Requirements and Architecture Processes 3483

7.1.10 Health Information Technology Standards Panel (HITSP) 3484 The Healthcare Information Technology Standards Panel (HITSP) was a cooperative partnership between the 3485 public and private sectors from December 2005 through 30 April 2010. The Panel was formed for the purpose of 3486 harmonizing and integrating standards that will meet clinical and business needs for sharing information among 3487 organizations and systems. 3488 3489 The Figure 39 HITSP Harmonization Process was defined to transform interoperability requirements into an 3490 Interoperability Specification (IS) and related artifacts (called constructs) that were collectively called an IS Package 3491 as shown in Figure 40. In HITSP, an IS assembles constructs to define the secure message, document and service 3492 infrastructure (transport together with secure and private transport mechanisms), information content, vocabulary, 3493



5/16/2010 Page 126 of 139

and constraints for each Information Exchange (IE) needed to address an interoperable business need and use case 3494 that articulated the requirements to reorganize its specifications to more clearly portray how they addressed 3495 HITECH requirements. The HITSP Data Architecture, Service Collaborations, and Capabilities were established as 3496 part of the effort to match HITSP results to HITECH, simplify reuse, and more rigorously separate transport and 3497 content. The Data Architecture organizes the data dictionary, vocabulary, and constraints (value sets and templates). 3498 Service Collaborations assembled HITSP constructs into secure infrastructure definitions. Capabilities addressed 3499 reusable business process chunks (such as patient registration), using Service Collaborations to specify the secure 3500 infrastructure and components to specify the information content. Figure 41 Fundamental Interoperability 3501 Relationships depicts the interrelationships of the requirements and design sections of the IS. Stakeholders’ 3502 Information Exchange Requirements (IERs) are met with System software Capabilities (CAP), which group the 3503 IERs into System Roles and their standards-based interface design specifications. 3504 3505

3506 Figure 39 HITSP Harmonization Process 3507

3508

3509 Figure 40 HITSP Document Architecture 3510

3511 Figure 40 HITSP Document Architecture portrays the HITSP constructs that were used to address a use case. Built 3512 on base (e.g. HL7, SNOMED-CT) and composite standards (e.g. IHE Integration Profiles), HITSP components 3513 defined the information content, while transactions and transaction packages defined the transport as well as 3514 security and privacy mechanisms. In response to HITECH, ONC asked HITSP to reorganize its specifications to 3515 more clearly portray how they addressed HITECH requirements. The HITSP Data Architecture, Service 3516 Collaborations, and Capabilities were established as part of the effort to match HITSP results to HITECH, simplify 3517 reuse, and more rigorously separate transport and content. The Data Architecture organized the data dictionary, 3518 vocabulary, and constraints (value sets and templates). Service Collaborations assembled HITSP constructs into 3519 secure infrastructure definitions. Capabilities addressed reusable business process chunks (such as patient 3520 registration), using Service Collaborations to specify the secure infrastructure and components to specify the 3521 information content. Figure 41 Fundamental Interoperability Relationships depicts the interrelationships of the 3522



5/16/2010 Page 127 of 139

requirements and design sections of the IS. Stakeholders’ Information Exchange Requirements (IERs) are met with 3523 System software Capabilities (CAP), which group the IERs into System Roles and their standards-based interface 3524 design specifications. 3525

3526

Figure 41 Fundamental Interoperability Relationships 3527

7.1.11 Certification Commission for Health Information Technology (CCHIT) 3528 Improvements in quality, safety, efficiency and access, which are key goals in today’s national dialog on health 3529 reform, are also the goals which drive the Certification Commission for Health Information Technology (CCHIT®), 3530 a nonprofit, 501(c)3 organization with the public mission of accelerating the adoption of health IT. 3531 3532 Founded in 2004, and certifying electronic health records (EHRs) since 2006, the Commission established the first 3533 comprehensive, practical definition of what capabilities were needed in these systems. The certification criteria were 3534 developed through a voluntary, consensus-based process engaging diverse stakeholders, and the Certification 3535 Commission was officially recognized by the federal government as a certifying body. 3536 3537 Uptake by the health IT industry was rapid, with more than 200 EHR products certified by mid-2009, representing 3538 over 75% of the marketplace. Provider organizations endorsed the work as well. Based on this broad acceptance, 3539 healthcare payers and purchasers in the government and private sectors began offering incentives to providers for 3540 adopting certified EHR technology. 3541 In February 2009, Congress acknowledged the value of certification in the language of the American Recovery and 3542 Reinvestment Act (ARRA) aimed at stimulating the nation’s economy. The law offers a multi-year series of incentive 3543 payments to providers and hospitals for the meaningful use of certified EHR technology. The total amount of 3544 payments has been projected by the Congressional Budget Office at $34 billion. 3545 3546 Anticipating a massive response to the new incentives, CCHIT has broadened access to certification, offering three 3547 paths to certification instead of just one. The new paths are intended to bring wider availability of EHR 3548 technologies, stimulate innovation, and address the needs of providers and hospitals at varying stages of technology 3549 adoption readiness. They are: 3550

CCHIT Certified®, an independently developed certification that includes a rigorous inspection of an 3551 EHR’s integrated functionality, interoperability and security. Products that are CCHIT Certified® are tested 3552 against criteria developed by the Commission’s broadly representative, expert work groups. This program is 3553



5/16/2010 Page 128 of 139

intended to serve health care providers looking for maximal assurance that a product will meet their 3554 complex needs. As part of this independent evaluation, successful use is verified at live sites and product 3555 usability is rated. 3556

Preliminary ARRA, a certification program that tests Complete EHRs or EHR Modules against the 3557 Meaningful Use Stage 1 certification criteria in the Interim Final Rule (IFR) issued by the Office of the 3558 National Coordinator (ONC), US Department of Health and Human Services (HHS) in January 2010. The 3559 Preliminary ARRA program is designed to demonstrate that a vendor’s product is extremely well prepared 3560 to be certified once ONC-accredited testing and certification becomes available, but the final criteria and 3561 test procedures are not yet available, nor has CCHIT been accredited yet by ONC. When those events 3562 occur, CCHIT will replace the Preliminary ARRA program with a final, ONC-accredited ARRA 3563 certification program. 3564

In addition to these product certifications, later this year, CCHIT has plans to offer a Site certification - 3565 a simplified, low cost certification for sites or organizations. Technology must meet minimum federal 3566 standards requirements once they are finalized. This program allows providers and hospitals who develop 3567 or assemble EHR technologies themselves to qualify for ARRA incentives, offering an open door to 3568 encourage continued innovation. 3569

7.1.12 National Information Exchange Model (NIEM) 3570

NIEM, the National Information Exchange Model, is a partnership of the U.S. Department of Justice and the 3571 Department of Homeland Security. It is designed to develop, disseminate and support enterprise-wide information 3572 exchange standards and processes that can enable jurisdictions to effectively share critical information in emergency 3573 situations, as well as support the day-to-day operations of agencies throughout the nation. 3574

NIEM enables information sharing, focusing on information exchanged among organizations as part of their 3575 current or intended business practices. The NIEM exchange development methodology results in a common 3576 semantic understanding among participating organizations and data formatted in a semantically consistent manner. 3577 NIEM will standardize content (actual data exchange standards), provide tools, and managed processes. NIEM 3578 builds on the demonstrated success of the Global Justice XML Data Model. Stakeholders from relevant 3579 communities work together to define critical exchanges, leveraging the successful work of the Global Justice XML 3580 Data Model (GJXDM) 3581

Today, the NIEM domain does not include healthcare; but, the HHS Office of the National Coordinator (ONC) 3582 plans to leverage many of the existing tools and resources from the National Information Exchange Model (NIEM) 3583 and develop a NIEM-like process for the health care domain. Leveraging the tools and resources available in the 3584 NIEM process will help each new use case to build on previous use cases and relevant standards as well as help 3585 build the repository for all stakeholders. 3586 3587



5/16/2010 Page 129 of 139

3588 Figure 42 ONC Standards and Interoperability Framework Process 3589

Figure 42 shows the proposed HHS process to develop NIEM compliant Information Exchange Package 3590 documents. Through this process ONC would like to develop not only data interchange specifications, but also 3591 continue to develop HITSP like software specifications to support the exchange of data within NHIN. The software 3592 functionality does not currently exist in the NIEM toolset, and therefore, it will be necessary to extend NIEM tools 3593 to include needed resources. Investments in developing the tools to support this process will help streamline the 3594 standards development processes, and aid in the maintenance and use of the data and application standards 3595 developed in these activities. 3596

7.1.13 Nationwide Health Information Network (NHIN) 3597 The Nationwide Health Information Network is a set of standards, services and policies that enable secure health 3598 information exchange over the Internet. Several Federal agencies and healthcare organizations are already using 3599 NHIN technology to exchange information amongst themselves and their partners. The NHIN will provide a 3600 foundation for the exchange of health IT across diverse entities, within communities and across the country, helping 3601 to achieve the goals of the HITECH Act. This critical part of the national health IT agenda will enable health 3602 information to follow the consumer, be available for clinical decision making, and support appropriate use of 3603 healthcare information beyond direct patient care so as to improve population health. 3604 3605 The NHIN Work Group, part of the Health IT Policy Committee, is currently developing recommendations for 3606 extending the secure exchange of health information using NHIN standards, services and policies to the broadest 3607 audience possible. Activities of the NHIN Work Group and Health IT Policy Committee can be found at 3608 http://healthit.hhs.gov/policycommittee. 3609

7.1.13. NHIN CONNECT 3610 CONNECT is an open source software solution that supports health information exchange – both locally and at the 3611 national level. CONNECT uses Nationwide Health Information Network (NHIN) standards and governance to 3612 make sure that health information exchanges are compatible with other exchanges being set up throughout the 3613 country. 3614 This software solution was initially developed by federal agencies to support their health-related missions, but it is 3615 now available to all organizations and can be used to help set up health information exchanges and share data using 3616 nationally-recognized interoperability standards. 3617 3618 CONNECT can be used to: 3619



5/16/2010 Page 130 of 139

Set up a health information exchange within an organization 3620 Tie a health information exchange into a regional network of health information exchanges 3621 Tie a health information exchange into the NHIN 3622

By advancing the adoption of interoperable health IT systems and health information exchanges, the country will 3623 better be able to achieve the goal of making sure all citizens have electronic health records by 2014. Health data will 3624 be able to follow a patient across the street or across the country. 3625 3626 Three primary elements make up the CONNECT solution: 3627

The Core Services Gateway provides the ability to locate patients at other organizations, request and 3628 receive documents associated with the patient, and record these transactions for subsequent auditing by 3629 patients and others. Other features include mechanisms for authenticating network participants, formulating 3630 and evaluating authorizations for the release of medical information, and honoring consumer preferences 3631 for sharing their information. The NHIN Interface specifications are implemented within this component. 3632

The Enterprise Service Components provide default implementations of many critical enterprise 3633 components required to support electronic health information exchange, including a Master Patient Index 3634 (MPI), XDS.b Document Registry and Repository, Authorization Policy Engine, Consumer Preferences 3635 Manager, HIPAA-compliant Audit Log and others. Implementers of CONNECT are free to adopt the 3636 components or use their own existing software for these purposes. 3637

The Universal Client Framework contains a set of applications that can be adapted to quickly create an 3638 edge system, and be used as a reference system, and/or can be used as a test and demonstration system for 3639 the gateway solution. This makes it possible to innovate on top of the existing CONNECT platform. 3640

7.1.13. NHIN Direct 3641

Based on initial recommendations from the NHIN Work Group, a new initiative, the NHIN Direct Project, was 3642 launched to explore the NHIN standards and services required to enable secure health information exchange at a 3643 more local and less complex level, such as a primary care provider sending a referral or care summary to a local 3644 specialist electronically. 3645

NHIN Direct is a project to expand the standards and service definitions that, with a policy framework, constitute 3646 the NHIN. Those standards and services will allow organizations to deliver simple, direct, secure and scalable 3647 transport of health information over the Internet between known participants in support of Stage 1 meaningful use. 3648 3649 The key deliverables of the project will be standards and service definitions, implementation guides, reference 3650 implementations, and associated testing frameworks. The project will not run health information exchange services. 3651 3652 This project will expand the standards and service descriptions available to the NHIN to address the key Stage 1 3653 requirements for meaningful use, and provide an easy "on-ramp" for a wide set of providers and organizations 3654 looking to adopt. At the conclusion of this project, there will be one nationwide exchange, consisting of the 3655 organizations that have come together in a common policy framework to implement the standards and services. 3656 . 3657

7.1.14 Universal Immunization Tracking System (UITS) 3658 The UITS Prototype Project is a Military Health System (MHS) prototype is intended to optimally accomplish 3659 immunization documentation and tracking, and support immunizations readiness reporting. The ECCF Physical 3660 Implementation Model (PIM) layer are based on the UITS project prototype, which is scheduled for its first go-live 3661 demonstration in September 2010. 3662



5/16/2010 Page 131 of 139

3663

This initiative supports three broad goals: 3664 1. Force Health Protection and Readiness perspective: 3665

a. Ensure a healthy and fit fighting force that is fully medically ready to deploy and provide the 3666 Department of Defense (DoD) maximal ability to perform its mission. 3667

b. Improved medical readiness through documenting, monitoring and reporting immunization status. 3668 2. Population Health perspective: 3669

a. Preventing and controlling diseases reduces adverse incidence requiring medical treatment. 3670 b. Compliant with current national standards and regulations to include patient safety and data quality. 3671

3. Medical Care perspective: 3672 a. Patient safety. 3673 b. Provider has immunization history. 3674 c. Medical conditions require supplemental immunization. 3675 d. Contraindications to immunizations. 3676

7.2 TOGAF Architecture Development Method (ADM) 3677 We followed The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM44), 3678 shown in Figure 43 (below) to populate the SAIF Enterprise Conformance and Compliance Framework (ECCF45) 3679 shown in Table 13 (above). The ECCF views are analogous to TOGAF’s business, data, application, and 3680 technology views. In order to minimize duplication, this section references figures and tables in the SAIF-ECCF 3681 appendix, rather than duplicate them here. The TOGAF ADM, shown in Figure 43, recommends a sequence for 3682 phases and steps involved in developing architectures; it is an iterative process which supports agile refinement 3683 processes and incremental delivery over the whole requirements-specifications lifecycle from simple requirements 3684 statements to implemented, tested, certified and deployed systems. Capabilities can be developed concurrently; but, 3685 for each capability and iteration, it is important to reconsider scope, detail, schedules, costs and milestones with an 3686 eye for optimization in TOGAF ADM’s Phase E described below. TOGAF ADM is usable with deliverables of 3687 other frameworks such as Zachman46, DODAF47. It is usual to modify or extend the ADM to suit specific 3688 enterprise or project needs, as we have adapted it to populate the HL7 SAIF-ECCF48. 3689

44 See http://www.opengroup.org/togaf/ for details. 45 See http://wiki.hl7.org/index.php?title=SAIF_main_page 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 http://zachmaninternational.com/index.php/the-zachman-framework 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 http://cio-nii.defense.gov/sites/dodaf20/index.html 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 132 of 139

3690 Figure 43 TOGAF ADM Supported by EHR-SD RM 3691

The "Requirements Management and Governance" circle at the center of the ADM graphic indicates that Requirements 3692 Management and Governance should be a part of every stage of a project. It is important to note that the 3693 Requirements Management and Governance circle denotes, not a static set of requirements, but a dynamic process 3694 whereby requirements for enterprise architecture and subsequent changes to those requirements are identified, 3695 validated, stored, and fed into and out of the relevant ADM phases but, the requirements management process must 3696 also dispose of, address, validate or prioritize evolving and refined requirements during the relevant phases of the 3697 ADM. The ability to govern changes in requirements is crucial. Architecture is an activity that by its very nature 3698 deals with uncertainty and change - the "grey area" between what stakeholders aspire to and what can be specified 3699 and engineered as a pragmatic solution. Moreover, architecture often deals with drivers and constraints, which can 3700 produce changes in requirements in an unforeseen manner. Many of the factors influencing architecture by their 3701 very nature are beyond the control of the enterprise (changing market conditions, new legislation, etc.). 3702

7.2.1 Preliminary 3703 The TOGAF ADM Preliminary Phase prepares the organization for a successful architecture project; it defines 3704 "how we do architecture." Its objectives are [TOGAF ADM 2006]: 3705



5/16/2010 Page 133 of 139

To ensure that everyone who will be involved in, or benefit from, this approach is committed to the 3706 success of the architectural process 3707

To define the architecture principles that will inform the constraints on any architecture work 3708 To define the "architecture footprint" for the organization - the people responsible for performing 3709

architecture work, where they are located, and their responsibilities 3710 To define the scope and assumptions (particularly in a federated architecture environment) 3711 To define the framework and detailed methodologies that are going to be used to develop enterprise 3712

architectures in the organization concerned (typically, an adaptation of the generic ADM) 3713 To set up and monitor a process (normally including a pilot project) to confirm the fitness-for-purpose 3714

of the defined framework 3715 If necessary, to define a set of criteria for evaluating architecture tools, repositories, and repository 3716

management processes to be used to capture, publish, and maintain architecture artifacts 3717

DISCUSSION: In adding an Immunization Management Capability (IMC) to SampleHealth’s SOA, we followed 3718 the TOGAF ADM and present the Interoperability Specifications using the HL7 SAIF Enterprise Conformance and 3719 Compliance Framework (ECCF). Since this was a prototype project, we followed a consensus governance (e.g., 3720 decision processes and management) based on peer review of architectural products. Additionally, we maintained a 3721 configuration management discipline, which mandates that each artifact be dated and have a version number. 3722

SAIF-ECCF MAPPING: TOGAF ADM Preliminary Phase products are not shown in the Section 2 SAIF-ECCF 3723 for Immunization Management. 3724

7.2.2 A – Architecture Vision 3725

TOGAF ADM Phase A sets the scope, constraints and expectations for the project. Validate the business context 3726 and create the Statement of Architecture Work. Architectural activity can be scoped or limited in the following four 3727 ways [TOGAF ADM 2006]: 3728

1. Enterprise scope or focus. 3729 2. Architecture Domains. 3730 3. Level of details (vertical scope). 3731 4. Project Schedules (time horizons). 3732

3733 DISCUSSION: 3734

1. Enterprise scope or focus: Our scope is to prototype an Immunization Management capability, which is 3735 added to SampleHealth’s SOA. Our use cases are defined in the Health and Human Services (HHS) 3736 American Health Information Community (AHIC) developed Immunization Response Management 3737 (IRM) use case and its Vaccine and Drug Administration and Reporting scenario plus overlaps with 3738 AHIC’s Public Health Case Reporting (PHCR). Our secondary scope, as an HL7 SAIF alpha-project, is to 3739 demonstrate the use of the SAIF ECCF. 3740

2. Architecture Domains: We are working in the healthcare EHR and public health domains 3741 3. Level of details (vertical scope): We will reuse and reference details provided by Standards Development 3742

Organizations (e.g., HL7, OASIS, ANSI) and Standards Related Organizations (e.g., IHE, HITSP) artifacts 3743 and guidelines. 3744

4. Project Schedules (time horizons): We assume an agile development and deployment lifecycle requiring all 3745 prototype work to be done from 24-March-2010 to 20-September-2010. Incremental documentation 3746



5/16/2010 Page 134 of 139

deliveries are planned for the HL7 May 2010 Working Group meeting and final delivery at the 24th HL7 3747 Annual Plenary and Working Group Meeting in October 2010. 3748

3749 SAIF-ECCF MAPPING: TOGAF ADM Architecture Vision Phase “A” products are shown in the Appendix 3750 Section 2.1 Preamble - Architecture Vision. Although this is not a formal part of the SAIF ECCF, decisions made 3751 during this phase impacted the resultant Section 2 architecture. 3752

7.2.3 B – Business Architecture 3753

TOGAF ADM Business Architecture Phase B Develops the Business Architecture as-is and target to-3754 be baselines and analyzes the gaps. In practical terms, the Business Architecture is also often 3755 necessary as a means of demonstrating the business value of subsequent architecture work to key 3756 stakeholders, and the return on investment to those stakeholders from supporting and participating 3757 in the subsequent work. The objectives of Phase B are [TOGAF ADM 2006]: 3758 To describe the Baseline Business Architecture 3759 To develop a Target Business Architecture, describing the product and/or service strategy, and 3760

the organizational, functional, process, information, and geographic aspects of the business 3761 environment, based on the business principles, business goals, and strategic drivers 3762

To analyze the gaps between the Baseline and Target Business Architectures 3763 To select and develop the relevant architecture viewpoints that will enable the architect to 3764

demonstrate how the stakeholder concerns are addressed in the Business Architecture 3765 To select the relevant tools and techniques to be used in association with the selected 3766

viewpoints 3767

DISCUSSION: SampleHealth’s as-is architectural baseline was given in The Practical Guide for SOA in Healthcare 3768 Volume I. The to-be target architecture adds an Immunization Management Capability (IRC). The EHR-SD RM was 3769 used to identify the reusable EHR-S FM and HITSP “to-be” artifacts. IRC Business Architecture behavioral 3770 specifications are given as Use Cases and Scenarios, Business Process Models and Sequence Diagrams in the Section 3771 2 SAIF-ECCF for Immunization Management. 3772 3773 SAIF-ECCF MAPPING: The architectural artifacts identified during the TOGAF ADM Business Architecture Phase 3774 B were placed within the four SAIF-ECCF Conceptual Viewpoints of 1) Enterprise-Business (e.g., Why), 2) 3775 Information (e.g., What), 3) Computational (e.g., How) and 4) Engineering (e.g., Where). 3776 3777

7.2.4 C – Information Systems Architecture 3778

TOGAF ADM Information Systems Architecture Phase C develops a baseline as-is and target to-be and 3779 analyzes the gaps. The objective of Phase C is to develop Target Architectures covering either or 3780 both (depending on project scope) of the data and application systems domains. Information 3781 Systems Architecture focuses on identifying and defining the applications and data considerations 3782 that support an enterprise's Business Architecture; for example, by defining views that relate to 3783 information, knowledge, application services, etc. 3784

The objective of the data architecture is that it defines the major types and sources of data 3785 necessary to support the business, in a way that is understandable by stakeholders, complete and 3786



5/16/2010 Page 135 of 139

consistent and stable. It is important to note that this effort is not concerned with database design. 3787 The goal is to define the data entities relevant to the enterprise, not to design logical or physical 3788 storage systems. (However, linkages to existing files and databases may be developed, and may 3789 demonstrate significant areas for improvement.) 3790

The objective of the application architecture is to define the major kinds of application system 3791 necessary to process the data and support the business. It is important to note that this effort is not 3792 concerned with applications systems design. The goal is to define what kinds of application systems 3793 are relevant to the enterprise, and what those applications need to do in order to manage data and 3794 to present information to the human and computer actors in the enterprise. The applications are 3795 not described as computer systems, but as logical groups of capabilities that manage the data 3796 objects in the Data Architecture and support the business functions in the Business Architecture. 3797 The applications and their capabilities are defined without reference to particular technologies. The 3798 applications are stable and relatively unchanging over time, whereas the technology used to 3799 implement them will change over time, based on the technologies currently available and changing 3800 business needs. [TOGAF ADM 2006] 3801

DISCUSSION: SampleHealth’s as-is architectural baseline was given in The Practical Guide for SOA in Healthcare 3802 Volume I. The to-be target architecture adds an Immunization Management Capability (IRC). The IRC Business 3803 Architecture behavioral specifications are given as Use Cases and Scenarios, Business Process Models and Sequence 3804 Diagrams in the Section 2 SAIF-ECCF for Immunization Management. 3805 3806 SAIF-ECCF MAPPING: The architectural artifacts identified during the TOGAF ADM Business Information Systems 3807 Architecture Phase C were placed within the four SAIF-ECCF Conceptual Views of 1) Enterprise-Business (e.g., 3808 Why), 2) Information (e.g., What), 3) Computational (e.g., How) and 4) Engineering (e.g., Where). 3809

7.2.5 D – Technology Architecture 3810

TOGAF ADM Technology Architecture Phase D develops the baseline as-is and target to-be 3811 technology architecture and analyzes the gaps. The Technology Architecture phase seeks to map 3812 application components defined in the Application Architecture phase into a set of technology 3813 components, which represent software and hardware components, available from the market or 3814 configured within the organization into technology platforms. As Technology Architecture defines 3815 the physical realization of an architectural solution, it has strong links to implementation and 3816 migration planning. Technology Architecture will define baseline (i.e., current) and target views of 3817 the technology portfolio, detailing the roadmap towards the Target Architecture, and to identify key 3818 work packages in the roadmap. Technology Architecture completes the set of architectural 3819 information and therefore supports cost assessment for particular migration scenarios. [TOGAF 3820 ADM 2006] 3821

DISCUSSION: SampleHealth’s as-is architectural baseline was given in The Practical Guide for SOA in Healthcare 3822 Volume I. The to-be target architecture adds an Immunization Management Capability (IRC). The IRC Business 3823 Architecture behavioral specifications are given as Use Cases and Scenarios, Business Process Models and Sequence 3824 Diagrams in the Section 2. 3825 3826



5/16/2010 Page 136 of 139

SAIF-ECCF MAPPING: TOGAF ADM Technology Architecture Phase D architectural artifacts were placed within 3827 the four SAIF-ECCF System Independent Viewpoints of 1) Enterprise-Business (e.g., Why), 2) Information (e.g., 3828 What), 3) Computational (e.g., How) and 4) Engineering (e.g., Where). 3829 3830

7.2.6 E – Opportunities and Solutions 3831 TOGAF ADM Opportunities and Solutions Phase E Identifies Major Implementation delivery vehicles 3832 (projects, programs, or portfolios) that effectively deliver the Target Architecture identified in 3833 previous phases. The objectives of Phase E are [TOGAF ADM 2006]: 3834

To review the target business objectives and capabilities, consolidate the gaps from Phases B to D, 3835 and then organize groups of building blocks to address these capabilities. 3836

To review and confirm the enterprise's current parameters for and ability to absorb change. 3837 To derive a series of Transition Architectures that deliver continuous business value (e.g., capability 3838

increments) through the exploitation of opportunities to realize the building blocks 3839 To generate and gain consensus on an outline Implementation and Migration Strategy 3840

3841 DISCUSSION: For SampleHealth’s IMC, the opportunities and Solutions which we take advantage of is the reuse 3842 of the As-Is SampleHealth Services, described in Volume I. The TOGAF ADM phases B-to-D gaps are filled by the 3843 new Immunization Management Capability. For the May 2010 draft version of this document, a series of transition 3844 architectures or Implementation and Migration Strategy were not done; they are planned to be done for the Oct 3845 2010 version 1.0 of this document. 3846 3847 SAIF-ECCF MAPPING: TOGAF ADM Opportunities and Solutions Phase E products are not explicitly shown in 3848 the Section 2; but, the decisions made during this phase are reflected in the resultant Section 2 architecture. 3849

7.2.7 F – Migration Planning 3850 TOGAF ADM Migration Planning Phase F Analyzes the costs, benefits and risks and produce an 3851 implementation roadmap. The main focus of Phase F is the creation of a viable Implementation 3852 and Migration Plan in co-operation with the portfolio and project managers. Phase F activities 3853 include assessing the dependencies, costs, and benefits of the various migration projects. The 3854 prioritized list of projects will form the basis of the detailed Implementation and Migration Plan 3855 that will supplement the architectures with investment portfolio and project-level detail assigning 3856 tasks to specific resources. The Implementation and Migration Plan is part of a family of plans 3857 issued by enterprise management frameworks that have to be closely coordinated to ensure that 3858 business value is delivered and that the resources are made available to complete the necessary 3859 work. This phase ensures that all concerned agencies outside of the enterprise architecture world 3860 are aware of the scope and import of the Implementation and Migration Plan and its implications 3861 with respect to their activities. Finally, the architecture evolution cycle should be established to 3862 ensure that the architecture stays relevant, and lessons learned should be documented to enable 3863 continuous process improvement. 3864 3865 The objectives of Phase F are to finalize a detailed Implementation and Migration Plan; specifically 3866 [TOGAF ADM 2006]: 3867 To ensure that the Implementation and Migration Plan is coordinated with the various 3868

management frameworks in use within the enterprise 3869



5/16/2010 Page 137 of 139

To prioritize all work packages, projects, and building blocks by assigning business value to 3870 each and conducting a cost/business analysis 3871

To finalize the Architecture Vision and Architecture Definition Documents, in line with the 3872 agreed implementation approach 3873

To confirm the Transition Architectures defined in Phase E with relevant stakeholders 3874 To create, evolve, and monitor the detailed Implementation and Migration Plan providing 3875

necessary resources to enable the realization of the Transition Architectures, as defined in 3876 Phase E 3877

3878 DISCUSSION: For SampleHealth’s IMC, we need an Implementation and Migration Plan for the to-be architectures. 3879 For the May 2010 draft version of this document, the Implementation and Migration Plan is not done; it is planned for the 3880 Oct 2010 version 1.0 of this document. 3881

SAIF-ECCF MAPPING: TOGAF ADM Migration Planning Phase F products are not explicitly shown in the 3882 Section 2; but, the decisions made during this phase are shown by the resultant Section 2 architecture. 3883

7.2.8 G – Implementation Governance 3884 TOGAF ADM Implementation Governance Phase G ensures that the implementation projects conform 3885 to the architecture. The objectives of Phase G are [TOGAF ADM 2006]: 3886 To formulate recommendations for each implementation project 3887 To govern and manage an Architecture Contract covering the overall implementation and 3888

deployment process 3889 To perform appropriate governance functions while the solution is being implemented and 3890

deployed 3891 To ensure conformance with the defined architecture by implementation projects and other 3892

projects 3893 To ensure that the program of solutions is deployed successfully, as a planned program of 3894

work 3895 To ensure conformance of the deployed solution with the Target Architecture 3896 To mobilize supporting operations that will underpin the future working lifetime of the 3897

deployed solution 3898 3899 The overall approach in Phase G is to: 3900 Establish an implementation program that will enable the delivery of the Transition 3901

Architectures agreed for implementation during the Migration Planning phase 3902 Adopt a phased deployment schedule that reflects the business priorities embodied in the 3903

Architecture Roadmap 3904 Follow the organization's standard for corporate, IT, and architecture governance 3905 Use the organization's established portfolio/program management approach, where this exists 3906 Define an operations framework to ensure the effective long life of the deployed solution 3907

3908 DISCUSSION: For SampleHealth’s IMC, we need an Implementation and Migration Plan for the to-be architectures. 3909 For the May 2010 draft version of this document, the Implementation and Migration Plan is not done; it is planned for the 3910 Oct 2010 version 1.0 of this document. 3911



5/16/2010 Page 138 of 139

3912 SAIF-ECCF MAPPING: TOGAF ADM Migration Planning Phase F products are not shown in the Section 2 3913 SAIF-ECCF for Immunization Management; but, the decisions made during this phase are shown by the resultant 3914 Section 2 architecture. 3915

7.2.9 H – Architecture Change Management 3916 TOGAF ADM Architecture Change Management Phase H ensures that the architecture responds to the 3917 needs of the enterprise as changes arise. The goal of an architecture change management process is 3918 to ensure that the architecture achieves its original target business value. This includes managing 3919 changes to the architecture in a cohesive and architected way. This process will typically provide for 3920 the continual monitoring of such things as governance requests, new developments in technology, 3921 and changes in the business environment. When changes are identified, change management will 3922 determine whether to formally initiate a new architecture evolution cycle. Additionally, the 3923 architecture change management process aims to establish and support the implemented enterprise 3924 architecture as a dynamic architecture; that is, one having the flexibility to evolve rapidly in 3925 response to changes in the technology and business environment. 3926 3927 The objectives of Phase H are [TOGAF ADM 2006]: 3928 To ensure that baseline architectures continue to be fit-for-purpose 3929 To assess the performance of the architecture and make recommendations for change 3930 To assess changes to the framework and principles set up in previous phases 3931 To establish an architecture change management process for the new enterprise architecture 3932

baseline that is achieved with completion of Phase G 3933 To maximize the business value from the architecture and ongoing operations 3934 To operate the Governance Framework 3935

3936 DISCUSSION: For SampleHealth’s IMC, we need change management for iterations from the as-is baseline 3937 configuration to the final to-be future state configuration. Changes to documents and diagrams must be version 3938 controlled. 3939 3940 SAIF-ECCF MAPPING: TOGAF ADM Architecture Change Management Phase H products are not shown in the 3941 Section 2 SAIF-ECCF for Immunization Management; but, the decisions made during this phase are shown by the 3942 resultant Section 2 architecture. 3943