practical guide to soa in healthcare volume ii - hssp -...

The Practical Guide for SOA in Health CareVolume II: Immunization Management

Case StudyAn 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 2010Latest version is available at:

http://hssp.wikispaces.com/PracticalGuide

Please send Suggestions for Improvement to

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

1

12345

2


Working Draft; NOT for Public Distribution

Executive Summary

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

interoperability specifications and conformance statements. The SAIF-ECCF is an “Exchange Architecture;” which can be used as an

Architectural Executive Summary to present the IMC interoperability specifications and conformance statements.

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

Two use cases from the Health and Human Services (HHS) American Health Information Community (AHIC) were used. The Immunization and Response Management (IRM) use case and its Vaccine and Drug Administration and Reporting scenario and the Public Health Case Reporting (PHCR) use case were used to develop the business architecture, Information Exchange Requirements (IERs), data requirements, interoperability specifications and conformance statements for the IMC’s Services.

Effective SOA programs involve cooperation and coordination among a wide variety of business, technical and functional participants from across an organization, including senior management sponsorship, business community ownership, program management, governance, architecture, project level

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

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 168

34

6

789

10111213141516171819202122232425262728293031323334353637383940

56789

101112



execution, test and certification and sustainment teams. The HL7 EHR-SD-RM helps bring these communities together throughout a Business Capability Lifecycle. It maps capabilities and their business Information Exchange Requirements (IERs) to the

HL7 EHR System Functional Model (EHR-S FM), to Healthcare Information Technology Standards Panel (HITSP)

o Data Architecture, o Security and Privacy Architecture, o Harmonization Framework,o Interoperability Specifications, Constructs and their referenced

standards; Integrating the Healthcare Enterprise (IHE) profiles; and 2009 Health Information Technology for Economic and Clinical Health

(HITECH) Act selected standards for interoperability and meaningful use objectives and criteria.

The projects listed above are all evolving and maturing as is the EHR-SD RM. Generally, no one person can keep track of this diverse set of information; the EHR-SD-RM lets individual analysts use appropriate, meaningful and consistent viewpoints as a project team works through a business capability’s lifecycle.

Change History (remove from the final document) Version A, dated 26 Mar 2010 Table of Contents Version B, dated 02 Apr 2010 Background Section (1st Draft) Version C, dated 09 Apr 2010 Executive Summary, TOGAF ADM and SAIF

Sections (1st Draft) Version D, dated 16 Apr 2010, Executive Summary and TOGAF ADM (2nd

Draft) Version E, dated 30 Apr 2010. SAIF-ECCF Appendix (2nd Draft) Version F, dated 30 Apr 2010. IHE, TOGAF ADM and SAIF Sections (3th

Draft) Version G, dated 07 May 2010, Full document edit, cleanup, review and

gap identification Version H, dated 14 May 2010, Document & Slides for HL7 WG meeting in

Rio de Janeiro. Version I, dated 21 May 2010, Move ECCF to body and Background &

TOGAF to appendix Version J, dated 04 Jun 2010, Updated IHE example in Section 2.1.1. TODO …


reserved.5/16/2010 Page ii of 168

1314

4142434445464748495051525354555657585960616263646566676869707172737475767778

151617181920


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

Version ?, dated summer 2010, Add FHIM to IMC specification Version ?, dated summer 2010, Add NIEM IEPDs to IMC specification Version ?, dated summer 2010, Add CCHIT certification criteria to IMC Version ?, dated summer 2010, Integrate NHIN Connect & Direct Services

into ECCF PIM Version ?, dated summer 2010, Add UITS IMC Platform Specific

specifications Version ?, dated summer 2010, Enhance the TOGAF & ECCF discussions

linking views together Version ?, dated summer 2010, Refine ECCF Conformance Statements Version 1.0, dated 01-Oct-2010, for HL7 24th Annual Plenary & Working

Group Meeting

HELP NEEDED: (remove from the final document)1) Editorial review: Is the document clear, complete, concise, correct,

consistent and easy to use?2) Update references, abbreviations, glossary, Index the document and add

an index at the end.3) NHIN, NHIN Connect and NHIN Direct services Subject Matter Expert

a. WSDL Subject Matter Expert for specifications4) NIEM IEPD Subject Matter Expert5) CCHIT Subject Matter Expert6) XML XSD schema development for EHR-S FM and EHR-SD RM

representation.a. Good xml reference guideb. Editor or other tool to easily develop XSD schemasc. Tool to convert XML + XSD to Access, SQL, Excel or Word formats

and vice-versa.7) Review of Practical Guide to SOA in Healthcare Subject Matter Expert

review from:a. Immunization Management and Public Health Reporting views.b. Service Oriented Architectural review … what is missing?c. SAIF view - have we presented a clear, complete, concise, correct

and consistent ECCF?

HOW TO PARTICIPATE:


reserved.5/16/2010 Page iii of 168

2122

798081828384858687888990919293949596979899

100101102103104105106107108109110111112113114115116117232425262728


Coordinate with [email protected] , 703-681-3929 or 703-575-7912-cell.

We have a weekly telecom each Friday 1230-1330 EasternPHONE: +1 770-657-9270, CODE: 071582#WEB LINK: http://my.dimdim.com/hsspPROJECT WIKI:

http://hssp.wikispaces.com/Reference+Architecture PRACTICAL GUIDE: http://hssp.wikispaces.com/PracticalGuide


reserved.5/16/2010 Page iv of 168

2930

118119120121122123124125126

313233343536


http://hssp.wikispaces.com/Reference+Architecture

http://my.dimdim.com/hssp

http://my.dimdim.com/hssp

mailto:[email protected]


Table of Contents1 Introduction......................................................................................................91.1 Acknowledgement.......................................................................................91.2 Document Objectives and Scope...............................................................101.3 Document “Tour” and Structure...............................................................101.4 Document Use...........................................................................................112 SAIF-ECCF SS for Immunization Management Capability............................122.1 Preamble - Architecture Vision from an IHE Perspective.........................12

2.1.1 Top Down Immunization Management Functional Analysis...............132.1.1 Bottom Up Immunization Management Technical Analysis...............14

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

2.1.2 Benefits................................................................................................262.1.3 Discussion............................................................................................26

2.2 ECCF Introduction....................................................................................272.2.1 ECCF Artifacts.....................................................................................302.2.2 ECCF Working Interoperability...........................................................312.2.3 ECCF Traceability...............................................................................312.2.4 ECCF Glossary and Traceability Meta-Model.....................................322.2.5 ECCF Implementation Guide...............................................................34

2.3 Conceptual Enterprise-Business-Viewpoint..............................................372.3.1 Policy and Regulation..........................................................................38

2.3.1. Privacy & Security Requirements....................................................392.3.1. HITECH Meaningful Use Objectives and Criteria............................43

2.3.2 Business Objectives.............................................................................442.3.3 Project Scope and Vision Statement...................................................442.3.4 Non-Functional Requirements............................................................462.3.5 Use Case Inventory.............................................................................492.3.6 Conformance Criteria..........................................................................502.3.7 Discussion............................................................................................50

2.4 Conceptual Information-Viewpoint...........................................................502.4.1 Domain Information Model.................................................................522.4.2 Conformance Statements....................................................................532.4.3 Discussion............................................................................................53

2.5 Conceptual Computation-Viewpoint..........................................................532.5.1 Service Inventory................................................................................542.5.1 Functional Requirements....................................................................562.5.2 Conceptual Functional Service Specification (CFSS).........................572.5.3 Service Roles and Relationships.........................................................572.5.4 Conformance Statements....................................................................572.5.5 Discussion............................................................................................57

2.6 Conceptual Engineering-View...................................................................58


reserved.5/16/2010 Page v of 168

3738

127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170

394041424344


2.6.1 Inventory of Software Platforms and Their Capabilities.....................582.6.2 Conformance Statements....................................................................592.6.3 Discussion............................................................................................59

2.7 Platform-Independent Enterprise-Business-Viewpoint.............................592.7.1 NHIN Standards..................................................................................592.7.2 Business Governance..........................................................................602.7.3 Conformance Statements....................................................................602.7.4 Discussion............................................................................................61

2.8 Platform-Independent Information-Viewpoint..........................................612.8.1 Project Information Model..................................................................62

2.8.1. Data Requirements (DRs).................................................................622.8.1. Standards Gaps................................................................................702.8.1. Standard Overlaps............................................................................73

2.8.2 Conformance Statements....................................................................752.8.3 Discussion............................................................................................75

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

2.9.1. Map of Business Functions...............................................................762.9.2 Use Cases and Business Level Interaction Diagrams.........................78

2.9.2. Information Exchanges.....................................................................792.9.2. Information Exchange Requirements (IERs)....................................802.9.2. Business Level Behavioral Specifications........................................81

2.9.3 Service Interaction Types and Collaboration Participations...............852.9.3. System-Level Exchange Architecture...............................................852.9.3. System Data Exchange Behavioral Specifications...........................88

2.9.4 Service Collaboration Types................................................................942.9.5 Service Contracts Parts.......................................................................992.9.6 Conformance Statements..................................................................1012.9.7 Discussion..........................................................................................101

2.10 Platform-Independent Engineering-Viewpoint........................................1012.10.1 Existing Platforms.............................................................................1012.10.2 Conformance Statements..................................................................1022.10.3 Discussion..........................................................................................102

2.11 Platform-Specific Enterprise-Business-Viewpoint...................................1022.11.1 Rules, Procedures and Industry Standards.......................................1032.11.2 Conformance Statements..................................................................1032.11.3 Discussion..........................................................................................103

2.12 Platform-Specific Information-Viewpoint................................................1032.12.1 Schemas and Transformations..........................................................1042.12.2 Conformance Statements..................................................................1042.12.3 Discussion..........................................................................................104

2.13 Platform-Specific Computation-Viewpoint..............................................1042.13.1 Collaboration Scripts, Orchestration, Realized Interfaces...............1042.13.2 Conformance Statements..................................................................104


reserved.5/16/2010 Page vi of 168

4546

171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214

474849505152


2.13.3 Discussion..........................................................................................1042.14 Platform-Specific Engineering-Viewpoint...............................................104

2.14.1 Execution Context, Platform Bindings and Deployment...................1052.14.1. Systems........................................................................................105

2.14.2 Conformance Statements..................................................................1062.14.3 Discussion..........................................................................................106

3 Conclusions and Lessons-Learned...............................................................1063.1 Immunization Management Lessons Learned........................................1073.2 ECCF Lessons Learned...........................................................................1073.3 SOA Lessons Learner..............................................................................1093.4 TOGAF ADM Lessons Learned................................................................1094 Acronym List................................................................................................1095 Glossary........................................................................................................1106 References....................................................................................................1107 Appendix.......................................................................................................1107.1 Background.............................................................................................111

7.1.1 Service Oriented Architecture (SOA)................................................1117.1.2 EHR System Functional Model (EHR-S FM).....................................1137.1.3 Healthcare SOA Reference Architecture (H-SOA-RA)......................1167.1.4 Reference Information Model (RIM).................................................1177.1.5 Federal Health Information Model (FHIM).......................................1187.1.6 Healthcare Service Specification Project (HSSP).............................1207.1.7 Service Aware Interoperability Framework (SAIF)..........................1217.1.8 Integrating the Healthcare Enterprise (IHE)....................................1227.1.9 EHR System Design Reference Model (EHR-SD RM).......................123

7.1.9. EHR-SD RM within the Requirements Management and Architecture Cycle.....................................................................................124

7.1.10 Health Information Technology Standards Panel (HITSP)...............1257.1.11 Certification Commission for Health Information Technology (CCHIT)

1277.1.12 National Information Exchange Model (NIEM)................................1287.1.13 Nationwide Health Information Network (NHIN).............................129

7.1.13. NHIN CONNECT.........................................................................1297.1.13. NHIN Direct................................................................................130

7.1.14 Universal Immunization Tracking System (UITS).............................1307.2 TOGAF Architecture Development Method (ADM).................................131

7.2.1 Preliminary........................................................................................1327.2.2 A – Architecture Vision......................................................................1337.2.3 B – Business Architecture.................................................................1347.2.4 C – Information Systems Architecture..............................................1347.2.5 D – Technology Architecture.............................................................1357.2.6 E – Opportunities and Solutions........................................................1367.2.7 F – Migration Planning......................................................................1367.2.8 G – Implementation Governance.......................................................137


reserved.5/16/2010 Page vii of 168

5354

215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258

555657585960


7.2.9 H – Architecture Change Management.............................................138

List of TablesTable 1 Capabilities Mapped to Existing IHE Profiles and Transactions.............20Table 2: Introduction of Mediating Services........................................................22Table 3 Standards Overlaps for Services.............................................................23Table 4 Taxonomy of Immunization Services Based on Standards......................24Table 5 Notional Set of Architectural Artifacts within the HL7 SAIF ECCF SS. .29Table 6 Guidance Standards.................................................................................43Table 7 Data Element and Information Requirements (DR).................................63Table 8 Use Case Requirements and Associated Standards Gaps.......................71Table 9 Use Case Requirements and Associated Standard Overlaps..................74Table 10 As-Is SampleHealth Business Function Map.........................................77Table 11 To-Be SampleHealth Business Function Map........................................77Table 12 Design Principles vs. Strategic Goals and Benefits.............................112Table 13 HL7 SAIF Enterprise Conformance and Compliance Framework (ECCF)............................................................................................................................122

List of Figures Figure 1 Meet in the Middle Approach................................................................13Figure 2 US Recommended Child Immunization Schedule..................................14Figure 3 Request Immunization History Using PIX.............................................17Figure 4 Request Immunization History using PDQ............................................18Figure 5 Public Health Immunization Deployment Example...............................24Figure 6 Rows in the ECCF Stack........................................................................27Figure 7 Reference Standards and Models within the HL7 SAIF (ECCF)...........30Figure 8 Conceptual Map of ECCF Working Interoperability..............................31Figure 9 IS10 IRM HITSP Constructs Mapped to Standards...............................32Figure 10 ECCF SS Traceability Meta Model......................................................34Figure 11 EHR-S FM Direct Care 1.8.2 Manage Immunization Administration Dependencies........................................................................................................46Figure 12 Conceptual Health Data Model............................................................51Figure 13 NHIN Standards Framework...............................................................60Figure 14 Immunization and Response Management Information Exchanges....79Figure 15 Immunizations and Response Management (IRM) Business Sequence – Part 1 – Clinician Perspective: Immunizations and Response Management Scenario 2: Vaccine and Drug Administration and Reporting.............................82Figure 16 Immunizations and Response Management (IRM) Business Sequence – Part 2 – Registries Perspective: Immunizations and response management Scenario 2: Vaccine and Drug Administration and Reporting.............................83Figure 17 Immunizations and Response Management (IRM) Business Sequence – Part 3– Consumer Perspective: Immunizations and response management Scenario 2: Vaccine and Drug Administration and Reporting.............................84


reserved.5/16/2010 Page viii of 168

6162

259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301

636465666768


Figure 18 Immunizations and Response Management (IRM) Business Sequence – Part 4....................................................................................................................85Figure 19 As-Is SampleHealth Information System High Level Architecture......86Figure 20 To-Be SampleHealth Information System High Level Architecture....87Figure 21 Mapping of Requirements to HITSP Constructs..................................88Figure 22 Communicate Vaccinations..................................................................90Figure 23 Immunization Query and Response.....................................................92Figure 24 Vaccine and Drug Inventory Reporting...............................................93Figure 25 Immunization Management Entities, Actions and Roles.....................94Figure 26 Capability System Roles.......................................................................94Figure 27 Information Exchanges Mapped to External Interfaces......................95Figure 28 Supported Information Exchanges......................................................96Figure 29 Information Exchanges Mapped to Constructs...................................97Figure 30 Immunization Information Sender System Role Mapped to HITSP Construct Interfaces.............................................................................................98Figure 31 Implementation Conditions..................................................................98Figure 32 HL7 EHR System Functional Model (EHR-S FM)..............................114Figure 33 Healthcare SOA Reference Architecture (H-SOA-RA).......................117Figure 34 HL7 Reference Information Model (RIM)..........................................118Figure 35 FHIM relationship to NIEM...............................................................120Figure 37 EHR-SD RM Leveraging Standards Related Organizations..............123Figure 38 Conceptual View of the HL7 EHR System Design Reference Model.124Figure 39 EHR-SD RM Supporting Requirements and Architecture Processes 125Figure 40 HITSP Harmonization Process...........................................................126Figure 41 HITSP Document Architecture..........................................................126Figure 42 Fundamental Interoperability Relationships.....................................127Figure 43 ONC Standards and Interoperability Framework Process................129Figure 44 TOGAF ADM Supported by EHR-SD RM...........................................132


reserved.5/16/2010 Page ix of 168

6970

302303304305306307308309310311312313314315316317318319320321322323324325326327328329330

717273747576


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

1.1 AcknowledgementThis document reflects the collective input from across the HSSP, HITSP, HL7, OMG and IHE communities, and was developed in collaboration during a series of workgroup meetings, teleconference calls and offline work from a host of contributors. Special thanks to all who contributed to the authoring and review of this document; in particular, the following individuals and organizations made significant contributions to this work:

Nancy Orvis (Government Projects Co-Chair), Military Health System Stephen Hufnagel (EHR-SD RM project facilitator), Military Health System

contractor Alean Kirnak (PHER WG co-chair, HSSP-IHE coordinator), Software

Partners LLC Anna Orlova, (IHE contributor) Public Health Data Standards Consortium Joshua Painter, (IHE contributor), Intel Corporation Ken Rubin (HSSP co-chair, HL7-OMG coordinator), EDS a Hewlett Packard

company Pat Van Dyke (EHR WG co-chair), Delta Dental Plans Association John Ritter (EHR WG co-chair), College of American Pathologists Gary Dickinson (EHR WG co-chair), CentriHealth Don Mon, (EHR WG co-chair), AHIMA

The EHR System Design Reference Model (EHR-SD RM) is built from and links standards related organizations (e.g., HL7, OASIS, ANSI, HITSP, OMG, IHE) 2 HSSP is the HL7 Healthcare Service Specification Project3 HITSP is the American National Standards Institute (ANSI) Healthcare Information Technology Standards Panel4 IHE is the Integrating the Healthcare Enterprise organization


reserved.5/16/2010 Page 10 of 168

7778

331332333334335336337338339340341342

343344345346347348349350351352353354355356357358359360361362363364365

7980818283848586


artifacts. The EHR-SD RM assimilates these artifacts into a requirements analysis, system engineering, enterprise architectural and test set of products to increase the productivity of business, functional, information, systems and test analysts in producing a set of standards-based healthcare information technology architectural interoperability specifications and conformance criteria. The EHR-SD RM and this case study use the work products and stand on the shoulders of the participants of the standards related organizations; special thank to all those standards related organizations volunteers.

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

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

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

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

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

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



8788

366367368369370371372373374375376377378379

380381382383384385386387388389390391392393394395396397398399400401402

89909192


1.3 Document “Tour” and StructureVolume I of this document addresses principles, systems and architectural structures from a “static” and topological view, focusing on how the pieces fit together. In Volume II’s Immunization Management case study we present an Immunization Management Capability (IMC). We use the HL7 Service Aware Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF) to organize the IMC’s Interoperability-Specification into twelve architectural viewpoints which specify an exchange architecture of interoperability specifications and conformance statements, which are suitable for acquisition, development, test or certification. Then we go over our conclusions and lessons-learned, abbreviations and glossary. The appendix presents a background overview of the EHR-SD RM’s standards related artifacts. The appendix also presents a walk through the OMG TOGAF Architecture Development Method (ADM) which was used to harvest immunization management architectural artifacts, using the EHR-SD RM. To avoid duplication, the TOGAF ADM section 7.2 references architectural artifacts or diagrams, which are presented in the SAIF-ECCF Section 2.

Although a linear read of the document is possible, some readers may wish to jump to Section 2.1 Preamble - Architecture Vision from an IHE Perspective for an approximately 12 page high level presentation. Persons not familiar with healthcare standards organization may wish to read the background section in the appendix first. Similarly, persons not familiar with architecture development methodologies, may wish to read the TOGAF overview in the appendix. The full SAIF ECCF presentation starts in Section 2.2 and it presents the twelve ECCF architectural viewpoints.

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

Finally, the document is structured around a set of core underlying principles, which are explained in Volume I, followed by the Volume II Case Study where those principles have been applied to an Immunization Management Capability example to make the abstract concepts tangible. Volume I of this



9394

403404405406407408409410411412413414415416417418419420421422423424425426427428

429430431432433434435436437438439440441

95969798


document addresses system and architectural structure from a “static” and topological view, focusing on how the pieces fit together. Volume II adds dynamic business, user and system behaviors and interactions; it focuses on how the pieces work together … working interoperability.

This guide may be used: To provide an example of a standards-based Interoperability Specifications

and conformance statements in a health context using industry standard services within a SOA

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

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

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

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

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

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

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

2 SAIF-ECCF SS for Immunization Management Capability

This Practical Guide for SOA in Healthcare Volume II Case Study presents an Immunization Management Capability (IMC) addition to Volume I’s SampleHealth’s Service Oriented Architecture (SOA)5 using the HL7 Service Aware Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF) Specification Stack (SS). We use the ECCF as an architectural “Executive Summary,” to present the IMC exchange architecture, interoperability specifications and conformance statements. The ECCF demonstrates the HL7 EHR 5 See the HSSP Practical Guide to SOA in Healthcare Volume 1 for the development of the SampleHealth SOA.



99100

442443444445446447

448449450451452453454455456457458459460461462463464465466467468469

470

471

472473474475476477478

101102103104105106


System Design Reference Model (EHR-SD RM) linked artifacts (e.g., EHR System Functional Model, FHIM, HITSP, HITEC, HSSP, IHE, NIEM, etc) as an initial architectural baseline suitable for an EHR related SOA acquisition, development or certification project.

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

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

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

service definition The platform-independent layer broadly maps to Volume I of the IHE Technical

Framework and The platform-specific layer broadly maps to Volume II of the IHE Technical

Framework.

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



107108

479480481482483484485486487488489490491492493494495496497

498499500501502503504505506507508509510511512513514515516109110111112113114115116

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_A-Service-Oriented-Architecture_SOA_2009-09-28.pdf

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_A-Service-Oriented-Architecture_SOA_2009-09-28.pdf


Carrying this a step further, the IHE SOA White Paper discusses a quick-and-simple “meet-in-the-middle” approach to SOA, whereby a taxonomy of services may be used to tie existing standards and legacy software together with a top-down analysis beginning with business processes. The meet-in-the-middle approach is illustrated in Figure 1.

Figure 1 Meet in the Middle Approach

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

2.1.1 Top Down Immunization Management Functional AnalysisWe will discuss immunization information delivery, in particular, as it pertains to the interaction between healthcare providers and public health immunization information systems, or IISs. IISs are public health registries whose goal is the control of vaccine-preventable diseases through improve vaccine coverage rates within populations.

Meet in the MiddleWe now begin top-down design. Our stakeholders are:



117118

517518519520521

522523524525526527528

529530531532533534535536

119120121122


The patient The regional IIS Hospitals Ambulatory clinics Public health clinics Providers School nurses and other public health staff

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

Register a patient in the eMPI8 (make the patient known) Find a patient in the eMPI by identifier or by demographics

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.



123124

537538539540541542543

544545546547548549550551

125126127128129130131132133134135136


Submit a patient’s immunization information9 to one-or-more public health or shared registries.

Locate a patient’s federated immunization information Retrieve a patient’s immunization information Recommend next immunizations Share a patient’s immunization information with providers Share a patient’s information with the patient himself Submit a patient’s immunization information to other IIS

2.1.1 Bottom Up Immunization Management Technical Analysis

There are different required fields (segments, vocabulary, etc.) lists depending upon the use case:

If the IIS does not participate in an MPI:- An EHR system reporting immunization data to the IIS for the first time must

supply demographics or a local ID as well as immunization data- If EHR system updates immunization data for a previously reported patient, it may

supply the local ID and the immunization data (but not necessarily the demographics)

If the IIS participates in an MPI used by the EHR system:- An EHR system registering a patient in the MPI for the first time must supply

demographics and a local ID- An EHR system reporting immunization data to the participating IIS that has

already registered the patient reports the retrieved IIS ID and the immunization data (but not necessarily the demographics)

- An EHR system reporting immunization data to the participating IIS that has not already registered the patient must report something else to identify the patient – possibly the MPI ID and optionally demographics? – and the immunization data

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

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

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

Utility services such as auditing (ATNA)

We also need certain capabilities not covered by existing IHE profiles:9 Immunization Information might include current IZ, IZ history, IZ schedule, IZ adverse events, allergies, etc.



137138

552553554555556557558559

560561

562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593

139140141142143144145


HL7 Version 2 immunization messaging for data exchange with existing IISs HL7 Version 3 messaging for immunization (POIZ Immunization messaging) data

exchange with V3-based systems such as Canadian Health Infoway or British National Health systems

Immunization decision support (trial use) services to recommend next vaccines10

ISSUE: Using a Two-step process to request an immunization historyThe IHE profile defines two queries for obtaining an ID of interest. One query requests an ID based on the demographic information included in the query (PDQ, using the Pediatric Demographic profile). When a match is found, it returns the relevant ID and demographic information. The other query seeks an ID for a person from one registered provider based on the ID from another registered provider (PIX).

The use of the IHE Patient Identification Cross-Referencing (PIX) and Patient Demographic Query (PDQ) transactions is an alternative approach which separates retrieval/update of a patient identifier and retrieval/update of immunization data into two messaging transactions.

A Patient Demographic Supplier may be a Master Person Index or other source of patient demographic and identification information. While we will focus on an MPI below, any Patient Demographic Supplier may be substituted.

A Master Person Index is a database that contains demographic and locating information of registered persons and associates each person with the identifiers for the person from each of the participating systems. This allows one system to request the identifier for a person that was assigned by another system. This ID may be used to request data from that second system and assures a positive match.

Systems that participate in an MPI should register each person they are interested in with the MPI. An excellent profile for maintaining and interacting with an MPI has been published by the group, Integrating the Healthcare Enterprise (IHE). That profile will not be replicated here. However, the process for requesting personal identifier outlined below is based on that profile.

Adding a patient record to an MPI is done by a PIX transaction using an ADT message. This method may be used by an EHR system or by an IIS, or both, to add a patient identifier to an MPI. The PIX profile, described in the IHE Technical Framework Volume I, includes specific transactions that describe the segments and fields to be used. These ADT-based transactions are described in the IHE

10 IHE profiles to support immunization decision support services are available for trial use in the IHE Patient Care Coordination (PCC) domain.



146147

594595596597598

599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633

148149150151152153154155


Technical Framework Volume II. The standard transaction used by PIX is ITI-8, which uses an HL7 V2.3.1 ADT.

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

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

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

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

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

Figure 3 Request Immunization History Using PIXNote that this interaction is simplified. The initiating system sends a request for a patient identifier. The request includes one identifier in a PID-3. The identity



156157

634635636

637638639640641

642643644645646

647648649650651

652653654655656657

658659660661

662663664665

158159160161


supplier looks for a matching identifier of interest and returns it along with the patient name (PID-5). This information is included in the request immunization history query (QBP^Q11). Assuming that the identifier used is the one in the immunization history supplier, there should be a one to one match.

If the EHR system wishes to retrieve the IIS ID without previously registering the patient with the MPI, or if it wishes to query the MPI by demographics for some other reason, it may use a Patient Demographics Query to do so.

Figure 4 illustrates the use of PDQ to obtain an ID and how this would be used to request an immunization record. The record seeker uses a Patient Demographic Query (PDQ) to a Master Person Index (MPI), requesting the identifiers for the person of interest. The MPI finds the person of interest and returns the demographic information and identifiers. The record seeker system uses this information to create a request for immunization history, which it sends to the record source. The record source uses this information to find the immunization history for the person of interest.

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

Figure 4 Request Immunization History using PDQ



162163

666667668669670671672673674675676677678679680681682683684

685686687688689690691

692693

164165166167


Note that this interaction is simplified. The client of interest would be selected and that client’s information would populate the query requesting an immunization history. To be assured of success, the record source system would need to have registered the person in the MPI. In that way the person ID in the record source would be available in the MPI.

Figure 3 and Figure 4 illustrate that the PIX Query and Patient Demographics Query (PDQ) approaches share similar flow to the original VXQ message. PIX Query followed by a RIH using the retrieved identifier is similar to a VXQ/VXR. PDQ followed by an RIH replicates a VXQ/XXX and VXQ/VXR (when multiple candidates are initially returned), or just a VXQ/VXR (if a single high-confidence candidate) 11

The following illustrates one of the above-described messages, the Patient Demographics Query. For examples of other messages, IHE documentation12 should be consulted.

MSH|^~\&| MYIIS|MyStateIIS|SOME_SYSTEM|A_Clinic |20091105||QBP^Q22^ ||P|2.5.1||||||||| <CR>

QPD|^IHE PDQ Query^ |37374859|@PID.3.1^[email protected]^[email protected]^[email protected]^[email protected]^[email protected]^Q [email protected]^[email protected]^Suzy [email protected]^[email protected]^[email protected]^10 East Main St^[email protected]^[email protected]^GA <CR>

RCP|I|5^RD^HL70126|R^real-time^HL70394<CR>

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

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



168169

694695696697698699700701702703704705706707708709710711

712713714715716717718719720

721722723724725726

170171172173

174175176177178179180181182183184185186187188189190

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_Pediatric-Demographics_TI_2009-08-10.pdf

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_Pediatric-Demographics_TI_2009-08-10.pdf

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_6-0_Vol2b_FT_2009-08-10.pdf

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_6-0_Vol2a_FT_2009-08-10-2.pdf

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_6-0_Vol1_FT_2009-08-10-2.pdf


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

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

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

Potential use of DSC segment to support return of batches of records

The following example shows a return similar to the response message returned by the request for immunization history query (above). Note that in both cases, the response message returns all information that it knows about each client in the segments required for each response.

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

Using PIX/PDQ in preparation for reporting an Immunization Record to an IIS

In the case where an IIS participates in an MPI, the EHR may use a PIX Query to retrieve the IIS identifier from the MPI prior to sending an immunization record to the IIS. In the case where the IIS identifier is returned by the MPI, the VXU message sent to the IIS may contain the IIS ID.

Using the IIS Identifier to Retrieve an Immunization History from the IISRequest Immunization History (not profiled by IHE) - method of retrieving immunization history by IIS ID:MSH|^~\&|||||||QBP^Q11^QBP_Q11|793543|P|2.5.1|||||||||Z34^CDCPHINVS <CR> QPD|Z34^Request Immunization History^HL70471|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main St^^Myfaircity^GA^^^L<CR> RCP|I|5^RD^HL70126|R^real-time^HL70394<CR> Request Immunization History response (not profiled by IHE but uses IIS ID retrieved either by PDQ or by PIX Query):MSH||MYIIS|MyStateIIS||MYEHR|20091130||RSP^K11^RSP_K11|7731029|P|2.5.1|||||||||Z32^CDCPHINVS<CR>MSA|AA|793543<CR>QAK|37374859|OK|Z343^request Immunization history^HL70471<CR>QPD|Z34^Request Immunization History^HL70471|37374859|123456^^^MYEHR^MR|Child^Bobbie^Q^^^^L|Que^Suzy^^^^^M|20050512|M|10 East Main St^^Myfaircity^GA^^^L<CRPID|1||123456^^^MYEHR^MR||Child^Robert^Quenton^^^^L|Que^Suzy^^^^^M|||||10 East Main St^^Myfaircity^GA<CR> PD1||||||||||||N|20091130<CR>NK1|1|Child^Suzy^^^^^L|MTH^Mother^HL70063<CR>



191192

727728729730731732733734735736737738739740741742

743744745746747748749750751752

753754755756757758759760761762

763764765766

767768769

770771772773774775776777778

193194195196


PV1||R||||||||||||||||||V03^20091130<CR> ORC|RE||142324567^YOUR_EHR|||||||^Shotgiver^Fred||Ôrderwriter^Sally^^^^^^^^^^^^^^^^^^MD<CR>RXA|0|1|20050725||03^MMR^HL70292|0.5|ML^ÎSO+||^New Immunization Record^NIP001<CR>RXR|SC^^HL70162<CR>

VXU supplying retrieved IIS ID (not profiled by IHE but uses IIS ID retrieved either by PDQ or by PIX Query):MSH|^~\&|MYIIS|MyStateIIS|SOME_SYSTEM|A_Clinic|20091105||VXU^V04|206935|P|2.3.1|<CR>PID|1||123456^^^MYEHR^MR||<CR>RXA|0|1|20050512|20050512|08^HEPB-PEDIATRIC/ADOLESCENT^CVX|.5|ML^ÎSO+||||||||MRK12345||MSD^MERCK^MVX|<CR>

VXU supplying demographics (not profiled by IHE):MSH|^~\&|MYIIS|MyStateIIS|SOME_SYSTEM|A_Clinic|20091105||VXU^V04|206935|P|2.3.1|<CR>PID|1||123456^^^MYEHR^MR||Child^Bobbie^Q^^^^L|Que^Suzy|20050512|M|||10 East Main St^^Myfaircity^GA^^^H|||||U|<CR>RXA|0|1|20050512|20050512|08^HEPB-PEDIATRIC/ADOLESCENT^CVX|.5|ML^ÎSO+||||||||MRK12345||MSD^MERCK^MVX|<CR>

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

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

Table 1 Capabilities Mapped to Existing IHE Profiles and TransactionsUse Case

Description #

Capability(EHR-S FM)

IHE Profile (TF Vol I)

IHE Transaction or Content Profiles (TF Vol

II)

Manage a patient's immunizations from birth through age 18

1 Consistent time

CT-ITI-1 2 Auditing ATNA-ITI-203 Register a patient in the eMPI

Patient Identifier Cross-Referencing (PIX)

ITI-8, ITI-10, ITI-30

4Find a patient's cross-referenced identifiers ITI-9

5Find a patient by identifier or by demographics

Patient Demographics Query (PDQ)

ITI-21

6Register a patient's IZ info in document form

Cross-Enterprise Document Sharing (XDS.b)

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

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



197198

779780781782783

784785786

787788789790791

792793794795796797798

799800801802803804

199200201202203204


Use Case Descriptio

n #

Capability(EHR-S FM)


IHE Transaction or Content Profiles (TF Vol

II)

13 Recommend next immunizationsPCC "Request for Clinical Guidance" [RCG]

Immunization Content

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



205206

805806807808809810811812

207208209210


Table 2: Introduction of Mediating Services

Use Case

#

Capability IHE Mediating Service


IHE Transaction or Content

Profile (TF Vol II)

Man

age

a pa

tient

's im

mun

izatio

ns fr

om b

irth

thro

ugh

age

18

1 Consistent timeUtility Services applied to all IHE Existing services

CT-ITI-1 2 Auditing ATNA-ITI-20

3Register a patient in the eMPI

Identification Service

Patient Identifier Cross-Referencing (PIX)

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

4Find a patient's cross-referenced identifiers ITI-9, ITI-45

5Find a patient by identifier or by demographics

Patient Demographics Query (PDQ)

ITI-21, ITI-47

6Register a patient's IZ info in document form

Retrieve, Locate, and Update Service

Cross-Enterprise Document Sharing (XDS.b)


7Submit a patient's IZ info in document form


8Locate a patient's IZ info in document form

ITI-18

9Retrieve a patient's IZ info in document form


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

None ( HL7 V2 IZ message) None (VXU)

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

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

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

None (HL7 V2 IZ message) None (VXQ)

13Recommend next immunizations

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

Request for Clinical Guidance

This solution does provide the needed communication between stakeholders speaking HL7 Version 2 and stakeholders using an XDS repository and registry for information sharing because we have created a Submit, Locate and Retrieve service which provides the needed translation. We have also created an Immunization Decision Support Service to provide immunization-specific decision support. We have created an Identification service for communication between stakeholders and the eMPI.

Note also that Table 1 and Table 1 above resemble Figure 1 but rotated left 90 degrees. So far our model is entirely based upon IHE profiles. We now map it to the full landscape of currently available standards, expanding the sections on standards not (yet) profiled by IHE. So now we flip the table back upright to follow Table 3. We delete the Use Case and Capabilities columns to focus on services and standards.

In Table 3, the services are mapped again to their IHE profiles and transactions, but also to profiles or implementation guides created by other profiling organizations, and to their “base” HL7 standards. Profiles and implementation guides are classified as the “interoperability layer” because they define as tightly as possible the exact sequence of



211212

813

814815816817818819820821822823824825826827828829830831

213214215216


bits that is required to conform to the standard. When successful, such profiles and implementation guides facilitate interoperability by creating an environment in which one vendor system connects “out-of-the-box” with another vendor system. As we will see, such “plug-and-play” interfaces are a powerful contributor to healthcare interoperability cost reduction, especially in an environment such as public health where the number of systems that need to communicate is large. (An aspect of plug-and-play interfaces not elaborated here is the requirement to test conformance to standards in an environment such as the IHE Connectathon.)

Table 3 Standards Overlaps for Services#Service Identification Retrieve, Locate and Update Decision Support1 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) messagingVersion 3 Care Record CDA

Version 3 Care Record CDA

Version 3 Care Record messaging

Now, we reduce Table 3 further to remove overlapping standards choices. Competing standards co-exist; a good solution must recognize and accommodate them since it is almost never practical to eliminate all their implementations. However, to create an elegant architecture which we can analyze, we choose the best of breed here 14 . The best of breed may be thought of as priority #1 choices, with additional choices added in as needed.

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.



217218

832833834835836837838839840841

842843844845846847848849

219220221222223224225226227228229230


In addition to removing overlap and choosing the best of breed, we remove the detail of the standards and profiling organizations that developed them, and also the detail of their base standards. Finally, we add a “task layer” service called GetPatientIZStatus. GetPatientIZStatus is a composed service which may be used to hide the details of identification, data retrieval and decision support when all the user wants is the end result of all three of these services.



231232

850851852853854855

233234235236


Table 4 Taxonomy of Immunization Services Based on Standards

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

In Table 4, we now have a specific example of the abstracted taxonomy shown in Figure 1Meet in the Middle Approach. Our taxonomy of services provides the bridge from business processes to on-the-wire, standards-based plug and play interfaces. It spans different technology platforms, including messages, services, HL7 V2, HL7 V3, which allows us to accommodate the variety of systems in the field, whether they are legacy or new systems, systems from different geographic and political areas, and other variations.

A deployment example of our solution is given in Figure 5 Public Health Immunization Deployment Example. Our patients, regional IIS and hospital, ambulatory, public health and safety net healthcare providers leverage commonly accessible regional Health Information Exchange (HIE) infrastructure. The HIE provides enterprise Master Person Index (eMPI) to facilitate patient identification, and a document registry and repository. The HIE provides common services to the patient’s Personal Health Record (PHR), the providers’ Electronic Health Record systems (EHRs), and public health’s Immunization Information System (IIS).

15 HL7 Version 2.3 messaging is commonly used today.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 28 of 168

237238

856

857858859860861862863864865866867868869870871872

239240241242243


Figure 5 Public Health Immunization Deployment Example

Health Information Exchange

Immunization Information System (IIS)

Imm

uniz

atio

n Se

rvic

es

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)

Public Health Immunization ScenariosWe now walk through our scenario and indicate which services are used to accomplish the steps of Figure 5 Public Health Immunization Deployment Example above.

PHR Perspective Step #1: Parent uses Personal Health Record (PHR) to prepare for well-child visitOur PHR makes a GetPatientIZStatus request. GetPatientIZStatus in turn implements a composition of:

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

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

3. Decision Support Service16: A Request for Clinical Guidance HL7 CDA V3 message containing the retrieved clinical information is passed and the immunization recommendation returned. CDA wrappers are stripped and a small amount of mapping is done to convert Immunization Content CDA format into the

16 Protocols for Decision Support Systems are immature; we present a hypothetical protocol here.The Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 29 of 168

244245

873

874875876877878879880881882883884885886887888889890891892893894

246247248249250


required Care Record message. The result is converted back to CDA before it is returned.

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

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

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

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

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

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

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

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

1. This step is just like Step #2.

Public Health Perspective Step #5: Schools and Public Health interact1. This step represents traditional, logged-in use of an IIS. The school nurse is

authorized to log directly into the IIS application software. All the child’s immunization activities have been submitted to the IIS, so his record is up to date.

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

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

2.1.2 BenefitsOur Public Health Immunization example offers these possibilities:

Single entry point for all EHR systems for submission of data to immunization registries. The HIE infrastructure hides much of the complexity of immunization information access. The details of extending access beyond the domain boundaries – for instance to another county or state – is implemented under the layers of Identification and Document services and so is hidden from both the private



251252

895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930

931932933934935936937

253254255256


providers and public health agencies. Service consumers only have to worry about a one-hop access to the infrastructure.

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

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

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

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



257258

938939940941942943944945946947948949950951952953954955956957958959960961962963964965

966967968969970971972

259260261262


2.2 ECCF Introduction

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

Figure 6 Rows in the ECCF StackFigure 6 Rows in the ECCF Stack describes the layers in the ECCF stack.

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

The RMODP viewpoints18 are: The Enterprise Viewpoint, which is concerned with the purpose and

behaviors of the system as it relates to the business objective and the business processes of the organization.

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.



263264

973

974975976977

978979980981982983984985986987988989990991992

265266267268269270271

272273274275

http://www.mel.nist.gov/msidlibrary/doc/AMIS-Concepts.pdf

http://www.rm-odp.net/


The Information Viewpoint, which is concerned with the nature of the information handled by the system and constraints on the use and interpretation of that information.

The Computational Viewpoint, which is concerned with the functional decomposition of the system into a set of components that exhibit specific behaviors and interact at interfaces.

The Engineering Viewpoint, which is concerned with the mechanisms and functions required to support the interactions of the computational components.

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

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

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.



276277

993994995996997998999

100010011002100310041005100610071008100910101011101210131014101510161017

278279280281282283284285286287288289290291292293294295296

297298299300


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

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.



301302

1018101910201021102210231024102510261027102810291030

303304305306307308

309310311312


SubjectSpecification

EnterpriseViewpoint

“Why”Policy

InformationViewpoint

“What”Content

ComputationalViewpoint

“How”Behavior

EngineeringViewpoint

“Where”Implementation

CIM(Conceptual)

Inventory ofo Use Caseso Stakeholderso Capabilities-Services o Requirementso Contracts

Business Scope Business Vision Business Objectives Policy & Regulations

Inventory of o Domain Entitieso Roles, o Activities, o Associations.

Information Modelso Conceptualo Domain

Inventories ofo Capabilities-Components,o Functions-Services.

Requirementso Accountability, Roleso Behaviors, Interactionso 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 ando Associations

Information Modelso Localizedo Constrainedo Project

Message Content Specifications

Use Case SpecsComponent. 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 Transformati

on Schemas (e.g., XSD)

Automation UnitTechnical InterfacesTechnical OperationsOrchestration Scripts

Application Specs. GUI Specifications Component Designs Deployment Topology Platform Bindings

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

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

2.2.1 ECCF Artifacts



313314

1031

103210331034103510361037103810391040104110421043

10441045

315316317318


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

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

23 From an ECCF perspective, a given reference artifact can be used, applied, referenced, transformed, or otherwise leveraged by any cell of the specification stack (within the same viewpoint). However, referenced specifications need not reside in a particular layer of the specification stack. Rather, they are most often viewed as surrounding or providing input to instances of the SS at any level of abstraction (row) or column. Note that externally referenced specifications may or may not have preexisting technology bindings.



319320

10461047104810491050

10511052

321322323324325326327

328329330331


2.2.2 ECCF Working Interoperability

Figure 8 Conceptual Map of ECCF Working Interoperability SS is specification Stack Subject or Specification stack subject refers to a particular SS instance and

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

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

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

2.2.3 ECCF TraceabilityAdding WI fidelity, traceability among architectural artifacts should be addressed within or referenced by an ECCF SS. The relevancy of the Platform Specific Model (PSM) level statements substantially increases when the conformance statements are traceable derivatives from conformance statements at the Platform-Independent Model (PIM) and Computationally Independent Model (CIM) levels of the Specification Stack (SS) instance. The more mature24 the SS instance, the greater the conformance value. Figure 9 is an

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



332333

1053

1054105510561057105810591060106110621063106410651066

1067106810691070107110721073

334335336

337338339340


abstract view of traceability, which we will make more specific within our IMC ECCF SS presented below. As a project advances, detailed requirements, architecture, design, deployment, test and certification traceability should be audited at Software Development Lifecycle (SDLC) configuration baselines, which are typically established at a System Requirements Review (SRR), Preliminary Design Review (PDR), Critical Design Review (CDR), and Test Readiness Review (TRR). At each of these reviews, a successful baseline should be established and the traceable configuration audit should be one of a review’s exit criterion.

Figure 9 IS10 IRM HITSP Constructs Mapped to Standards

2.2.4 ECCF Glossary and Traceability Meta-Model This section presents a notional set of architectural artifacts. Some subset or variations of these should populate any ECCF SS. The following list provides definitions for the notional value set of architectural artifacts shown in Table 5.

Accountability defines “Who does what to whom.” [SAIF BF]Automation Unit describes the implementation of a single service, several services, or an application. It is itself a specialized form of versioned-specification. It consists of a collection of deployable artifacts, which can be decomposed into distributed Automation Units.Base Standard: is a standard capable of fulfilling a discrete function within a single category produced and maintained by a single standards organization. Examples include HL7 v2.x, SNOMED-CT. [HITSP TN904]Behavior is sets of actions and constraints on when the actions can occur. [SAIF BF]

across the cells of the SS. This is represented by the collection of SS cells that are populated with the appropriate artifacts.



341342

10741075107610771078107910801081

10821083

1084108510861087

10881089109010911092109310941095

343344

345346347348


Capability (CAP): is an implementable business service that addresses a focused business need by supporting stakeholder requirements and business processes. A CAP Specifies required optional and required secure, interoperable Information Exchanges between System Roles using HITSP constructs. A CAP identifies how to claim conformance, when options are resolved by an IS or implementation. [HITSP TN904]Component: is a construct that defines the set of data elements, structures, relationships, constraints and terminology needed to support specific reusable information content. A Component may also express constraints on base or composite standards, examples include the Lab Result Message and Lab Result Document. [HITSP TN904]Construct: is a specification based on harmonized interoperability standards. HITSP defines Transaction, Transaction Package, Service Collaboration and Component constructs. [HITSP TN904]Contract is an agreement covering part of the collective behavior of any number of role instances. [SAIF BF]Conceptual Functional Service Specification (CFSS) is the formal specification of a Conceptual Functional Model [NIH] (e.g., EHR System Design Functional Model).Collaboration Participation model specifies the system roles and their information exchanges for a system capability (e.g., document management), which may support one-or-more system functions (e.g., patient identification, registry query, repository request). [SAIF BF]Collaboration or Orchestration scripts define threads-of-execution, which achieve meaningful system or business functions.Collaboration types might be some combination of Distributed, Client-Server, Federated, Synchronous or Asynchronous etc. [SAIF BF]Composite Standard: is a grouping of coordinated base standards, often from multiple standards organizations, maintained by a single organization. Examples include IHE Information Technology Infrastructure XDS Integration Profile. [HITSP TN904]Conceptual data model is developed based on the data requirements for the application that is being developed, perhaps in the context of an activity model. The data model will normally consist of entity types, attributes, relationships, integrity rules, and the definitions of those objects.Data are facts, observations, measures or conclusions recorded about a subject of interest (often termed a unit of observation), at a particular place through a particular process for a particular purpose. Each fact can be termed a data element and is meaningless unless the context in which it was recorded is known. A Data Model is a means of categorizing and grouping data items (persons, places, objects, processes) of interest. However, in a data model, a single piece of data should be identified only once and be associated with the specific subject it describes. This level of discipline is required to appropriately specify requirements for information systems. Information systems have a structure just as buildings and bridges do. Therefore, they must be constructed with the same attention to design to achieve the same high degree of quality and reliability that is expected of physical structures. [Conceptual Health Data Model v2.3, Canadian Institute for Health Information]Data Requirement (DR): defines requirements for all or part of the IER exchange content as a set of data elements with specific semantic details. [HITSP TN904]Deployment Topology is the allocation of Platforms and Capabilities and capability System Roles to Systems. Harmonization Framework: defines the terms, concepts and their relationships within a HITSP Interoperability Specification (IS), Capability (CAP), Component (C), Transaction (T), Transaction Package (TP) and Service Collaboration (SC). Information is a set of data that has been collated, interpreted and presented to be meaningful to a particular audience for a particular purpose. Information for one purpose can be recorded and/or transformed to become data used as input into a new process to create information for a different purpose. Transformation processes may be automated or be the result of human judgment. An Information Model then, is a means of classifying information topics of interest. A Data Model defines the specific subjects and the facts about them. The same data can be used to produce many different pieces of information. A Data Model does not identify or define any topics that are essentially derived by any transformation process. [Conceptual Health Data Model v2.3, Canadian Institute for Health Information]Information Exchange Requirement (IER): is a business requirement described in terms of Exchange Content, Exchange Action, and Systems involved in the exchange and Exchange Attributes. [HITSP TN904]

Exchange Content: describes the information to be communicated in business termsExchange Action: describes the interaction that communicates the Exchange



349350

109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152

115311541155

351352353354


Content between the SystemsExchange Attributes: are parameters about an Information Exchange. Examples are constraints, conditions and triggersIER Identifier: is an optional IER name and number, which is local to an IS and valid within the scope of an IS

Exchange Architecture: defines the fundamental topologies that can be used in implementing the HITSP Interoperability Specifications in systems (e.g., EHR systems directly connected or connected to Health Information Exchanges (HIEs) and HIEs connected to other HIEs. [HITSP TN904]Functional Profile is a collection of Proposed Operations that align with some intended usage patterns. Often, these are characterized by quality considerations, such as security or performance, though they may not be so.Function Types are Direct Care, Supportive Care, Infrastructure, etc. and their sub-types. See EHR System Functional Model.Harmonization Request: defines business or functional needs, within a workflow, and sets context and conditions for the Interoperability Specification. Behavioral specifications of functional needs or capabilities may be structured as Use Cases, Scenarios, Business Process Models or other forms. [HITSP TN904]Implementation Specifications bind environment and platforms (e.g., J2EE, .NET, etc) to Platform Independent specifications. [SAIF BF]Interaction is something that happens between a role’s interfaces and other roles in its environment. [SAIF BF]Interface is an abstraction of the behavior of an object that consists of a subset of the interactions of that object together with a set of constraints that define when the identified interactions can occur. [SAIF BF]Interface: is the set of features and obligations that support Information Exchanges for a HITSP system. Interfaces and Information Exchanges between interfaces are specified by HITSP Constructs, including Service Collaborations for example, Content Creator, Document Consumer, Eligibility Information Receiver and Audit Record Repository. [HITSP TN904]Interface Design Specifications includes the content, transport, privacy and security standards and protocols for system data exchanges. Software engineering best-practices recommend an “Information Hiding” approach with a separate external specification for use and internal information and behavior specification for implementation. Interaction Specifications define information exchange Transport, Content, Constraints, Systems or System Roles. [SAIF BF]Interface Types are Message, Document or Service. [SAIF ECCF]Interoperability Specification (IS): is organized by scenarios, Capabilities and integrates and constrains Constructs to specify the interoperability needs of one or more business processes. [HITSP TN904]Role is a cohesive set of capabilities, capacities, or competencies abstracted as behaviors, which can be invoked at run-time.Service definition contains the terms for information exchange, providing the service’s technical constraints and requirements as well as any semantic information needed to consume the service. It is comprised of two parts: (1) an abstract portion; and (2) a concrete portion. The abstract portion describes the functionality of the service. It includes a series of technology-independent elements: the interface, operations, operation semantics, and data structure definitions. The concrete portion describes how to access the service. It effectively designates how the abstract interface connects to technology that implements the service. Note that there can be more than one concrete portion corresponding to a single abstract portion. This ensures that the means used to access the service – such as web services, messaging or direct invocation – can be independent of the abstract service definition. The Service Implementation is the core logic in support of the service definition. It is essentially the code behind the service, often written in an application language like Java, .Net or C++. [IHE SOA Whitepaper]Service Collaboration (SC): is the composition of Transaction, Transaction Package, or Component constructs into a reusable workflow, primarily at the infrastructure level, for example HITSP/SC115 HL7 Messaging Service Collaboration. [HITSP TN904]Service contracts might include Information model extracts for semantic interoperability, role-based security, costs, etc. In NHIN this is known as a Distributed User Resource Sharing Agreement (DURSA). Stakeholder: is defined as a person or organization that uses or benefits from systems that interoperate. [HITSP TN904]



355356

11561157115811591160

11611162116311641165116611671168116911701171117211731174117511761177117811791180118111821183118411851186118711881189119011911192119311941195119611971198119912001201120212031204120512061207120812091210121112121213

357358359360


System: is an IT software application that plays an initiating or responding role in one or more Information Exchanges addressed by a Interoperability Specification or Capability. [HITSP TN904]System Role: is a set of closely related capability behaviors, which satisfy a business need. A Capability has two or more System Roles, such as Order Placer; Order Filler; Specimen Analyzer. Behaviors are the set of prescribed and optional Information Exchanges among systems roles. In an IS or implementation, a system supports one or more capability system roles from each capability it supports. [HITSP TN904]Transaction (T): is a logical grouping of data exchanges and transport methods that must all succeed or fail as a group. Examples are the Query Lab Result or Send Lab Result. [HITSP TN904]Transaction Package (TP): is a logical grouping of two or more Transactions, Transaction Packages, and/or composite standards used to fulfill Information Exchange Requirements (IERs). A Transaction Package is not required to succeed or fail as a whole. Examples include the Record Locator Service and Entity Identification Service. [HITSP TN904]Technical Interface is a technology specific interface provided by an Automation Unit. .Technical Operation is a specific function provided by a particular Technical Interface, which is technology specific.Use Cases can be specified textually as a sequence of Scenarios, Events and Actions. They can also be specified as Business Process Models.Wireframe is a basic visual guide used in interface design to suggest the structure of a website and relationships between its pages. A system component wireframe is a similar illustration of the layout of fundamental elements in the component or system and their interfaces. [adapted from Wikipedia]

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

TBDFigure 10 ECCF SS Traceability Meta Model

2.2.5 ECCF Implementation GuideA mature ECCF SS shall contain a clear, complete, concise, correct, consistent and traceable set of architectural artifacts, organized as follows: 1. The ECCF Conceptual Enterprise-Business-Viewpoint defines the business and

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

Inventory of Use Cases Stakeholders Capabilities-Services Requirements\Contracts

Business Scope Business Vision Business Objectives



361362

121412151216121712181219122012211222122312241225122612271228122912301231123212331234

12351236123712381239124012411242124312441245

124612471248124912501251125212531254125512561257125812591260126112621263

363364365366


Policy & Regulations 2. The ECCF Conceptual Information-Viewpoint is defined by the domain analysis

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

Inventory of Domain Entities, Roles, Activities and Associations.

Information Model Conceptual Domain

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

Inventories of Capabilities-Components, Functions-Services

Requirements Accountability Roles Behaviors Functional Profiles Interactions Interfaces Contracts

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

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

Inventory of Software Platforms/ Environments.The Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 42 of 168

367368

12641265126612671268126912701271127212731274127512761277127812791280128112821283128412851286128712881289129012911292129312941295129612971298129913001301130213031304130513061307

369370371372


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

Applicable Rules Use Case Specs Governance. Technology Neutral Standards Wireframes of

architectural layers components and Associations

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

Information Model Localized Information Model Constrained Information Model Project Information Model

Message Content Specifications 7. The ECCF Platform-Independent Computational-Viewpoint is defined by collaboration

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

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



373374

13081309131013111312131313141315131613171318131913201321132213231324132513261327132813291330133113321333133413351336133713381339134013411342134313441345134613471348134913501351

375376377378


Service Contracts8. The ECCF Platform-Independent Engineering-Viewpoint is defined by existing

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

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

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

Business Nodes Business Rules Business Procedures Business Workflow Technology Specific Standards

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

Database Schemas Message Schemas Transformation Schemas (e.g., XSD)

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

Automation Unit Technical Interfaces Technical Operations



379380

13521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386138713881389139013911392139313941395

381382383384


Orchestration Scripts12.The ECCF Platform-Specific Engineering-Viewpoint is defined by existing platform

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

Application Specifications GUI specifications Deployment Topology or Execution Context

Platform Bindings2.3 Conceptual Enterprise-Business-Viewpoint

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

Inventory of Use Cases Stakeholders Capabilities-Services Requirements\Contracts

Business Scope Business Vision Business Objectives Policy & Regulations

2.3.1 Policy and Regulation

The following have impact on this project: The Federal Health IT Policy Committee, which makes recommendations to the

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



385386

13961397139813991400140114021403140414051406140714081409

1410

14111412141314141415141614171418141914201421142214231424142514261427

142814291430143114321433143414351436

387388389390

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


o Technologies that protect the privacy of health informationo A nationwide health information technology infrastructureo The utilization of a certified electronic record for each person in the US by

2014o Technologies that support accounting of disclosures made by a covered

entityo The use of electronic records to improve qualityo Technologies that enable identifiable health information to be rendered

unusable/unreadableo Demographic data collection including race, ethnicity, primary language,

and gendero Technologies that address the needs of children and other vulnerable

populations The Federal Health IT Standards Committee, which makes recommendations to

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

HIPAA25 - The Health Insurance Portability and Accountability Act of 1996 (HIPAA) required the Secretary of the U.S. Department of Health and Human Services (HHS) to develop regulations protecting the privacy and security of certain health information.1 To fulfill this requirement, HHS published what are commonly known as the HIPAA Privacy Rule and the HIPAA Security Rule. The Privacy Rule, or Standards for Privacy of Individually Identifiable Health Information, establishes national standards for the protection of certain health information. The Security Standards for the Protection of Electronic Protected Health Information (the Security Rule) establish a national set of security standards for protecting certain health information that is held or transferred in electronic form. The Security Rule operationalizes the protections contained in the Privacy Rule by addressing the technical and non-technical safeguards that organizations called “covered entities” must put in place to secure individuals’ “electronic protected health information” (e-PHI). The HIPAA/EDI provision took effect on October 16, 2003. On January 1, 2012

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



391392

1437143814391440144114421443144414451446144714481449145014511452145314541455145614571458145914601461146214631464146514661467146814691470147114721473147414751476

393394395396397398

http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/index.html

http://www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule/index.html

http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/index.html



the newest version 5010 becomes effective, replacing the version 4010. This allows for the larger field size of ICD-10-CM as well as other improvements.

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

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

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

Privacy & Security RequirementsHITSP TN900 specifies the constructs to support a wide variety of security and privacy policies and technical frameworks. Consistent with the HITSP Technical Committee Terms of Reference, HITSP has not attempted to resolve privacy or security policy issues, risk management, healthcare application functionality, operating systems functionality, physical control specifications, or other low-level specifications. This approach is crucial because of the variety of requirements that the HITSP Security and Privacy constructs will be called on to address.The United States has an extensive body of federal and state laws and regulations that define the security and privacy requirements for collecting, creating, maintaining, using,



399400

14771478147914801481148214831484148514861487

1488148914901491149214931494149514961497149814991500

15011502150315041505150615071508

1509151015111512151315141515151615171518

401402403404

http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=5&PrefixNumeric=900


disclosing and disposing individually identifiable health information. Among them, at the federal level are:

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

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

Holder of the dataUser (requester) of the dataData itselfPurpose of the use or disclosure of the dataTiming of the use and disclosure of the dataMethods and mechanisms used to collect, maintain, use and disclose data

Several of them also define and assign specific rights to consumers with respect to controls consumers can exercise over the collection, access, use and disclosure of their health information.

In developing the HITSP Security and Privacy constructs, HITSP considered a set of overarching principles and concepts, derived from an analysis of major federal and common state laws and regulations. They included:

Privacy PrinciplesConsumer consent requirements (including the concepts of consent and authorization, whether they are considered one and the same in some regulations, or treated differently in others)Consumer’s ability to provide directives on:The collection, access, use and disclosure of his/her health informationWhat information is collected, accessed, used, disclosedBy whomTo whom



405406

15191520152115221523152415251526152715281529153015311532153315341535153615371538153915401541154215431544154515461547154815491550155115521553155415551556155715581559156015611562

407408409410

http://www.consumerprivacyguide.org/law/glb.shtml

http://www.consumerprivacyguide.org/law/ta.shtml

http://www.consumerprivacyguide.org/law/calea.shtml

http://www.consumerprivacyguide.org/law/ecpa.shtml

http://www.consumerprivacyguide.org/law/ppa.shtml

http://www.consumerprivacyguide.org/law/rfpa.shtml


For what purpose(s)WhenFor how longConsumer’s ability to modify or revoke directivesPatient privacy rights, such as those identified in the HIPAA Privacy regulations, including the right to:Receive a Notice of Privacy PracticesAccess individually identifiable health information for review and/or copyRequest amendments to health informationRequest privacy protections to health information including the right to request restrictions on the use and disclosure of health information and the right to request confidential communications from a covered entityRequest an accounting of certain disclosures that a covered entity has made of their protected health information (within the context of HIPAA) File a complaint about privacy issues

Privacy requirements:Various degrees of sensitive health informationMinimum necessaryAccounting of disclosureProcedures for ensuring confidential communications are being done (i.e., sending an electronic message with results to the patient at an alternative location)Deidentification (anonymization) of information, when necessaryVerification requirements of the identity and authority of individual requesting health information prior to disclosure (if not known by the entity disclosing the information), including documentation of such identify and authorityMitigation of harm, in the event of a use or disclosure done in violation of privacy requirements or organization’s own policies and procedures

Security PrinciplesAvailability of health information – information is available when and where neededConfidentiality – information is not accessed, used, disclosed by non-authorized individuals or entitiesIntegrity - Information content not alterable except under authorized circumstancesAccountability – ensuring that those collecting, accessing, using or disclosing health information are accountable for their roles and responsibilitiesIdentification – of users and subjects of health information, as appropriate and applicableAuthentication – of users and subjects of health information, as appropriate and applicableAuthorization – of those identified and authenticated, to allow them to perform the functions they are specifically authorized to perform with the health information



411412

15631564156515661567156815691570157115721573157415751576157715781579158015811582158315841585158615871588158915901591159215931594159515961597159815991600160116021603160416051606

413414415416


they are collecting, accessing, using or disclosingAccess Control - only authorized persons can access health information for authorized purposesAttribution/nonrepudiation - actions taken are reliably traceableAuditability – controls to identify, record and report and monitor health information eventsSecure communication – between entities exchanging health informationTime recording – methods to control time of events in a consistent manner

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

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

The Health Information Technology Policy Committeehttp://healthit.hhs.gov/portal/server.pt?open=512&objID=1269&parentname=CommunityPage&parentid=2&mode=2&in_hi_userid=10741&cached=true

Health Information Technology Standards Committeehttp://healthit.hhs.gov/portal/server.pt?open=512&objID=1271&parentname=CommunityPage&parentid=3&mode=2&in_hi_userid=10741&cached=true

National eHealth Collaborativehttp://www.nationalehealth.org/

The American Health Information Community’s Confidentiality (AHIC), Security and privacy Workgroup

http://www.hhs.gov/healthit/community/background/ The Health Information Security and Privacy Collaborative (HISPC)

http://healthit.ahrq.gov/portal/server.pt?open=514&objID=5562&mode=2&holderDisplayURL=http://prodportallb.ahrq.gov:7087/publishedcontent/publish/communities/a_e/ahrq_funded_projects/rti_public_page/main.html http://www.rti.org/page.cfm?objectid=09E8D494-C491-42FC-BA13EAD1217245C0

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

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

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

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



417418

1607160816091610161116121613161416151616161716181619162016211622162316241625162616271628

16291630

163116321633

16341635

16361637

1638

16391640

16411642

16431644

1645

16461647

16481649

1650

16511652

419420421422

http://healthit.ahrq.gov/

http://www.hhs.gov/ocr/hipaa/

http://www.cchit.org/

http://www.rti.org/page.cfm?objectid=09E8D494-C491-42FC-BA13EAD1217245C0

http://healthit.ahrq.gov/portal/server.pt?open=514&objID=5562&mode=2&holderDisplayURL=http://prodportallb.ahrq.gov:7087/publishedcontent/publish/communities/a_e/ahrq_funded_projects/rti_public_page/main.html

http://healthit.ahrq.gov/portal/server.pt?open=514&objID=5562&mode=2&holderDisplayURL=http://prodportallb.ahrq.gov:7087/publishedcontent/publish/communities/a_e/ahrq_funded_projects/rti_public_page/main.html

http://www.hhs.gov/healthit/community/background/

http://www.nationalehealth.org/






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

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

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

http://www.samhsa.govIndian Health Services (IHS)

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

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

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

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

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



423424

1653

16541655

16561657

16581659

16601661

16621663

16641665

16661667

16681669

16701671167216731674167516761677167816791680

425426427428

http://www.nga.org/portal/site/nga/menuitem.1f41d49be2d3d33eacdcbeeb501010a0/?vgnextoid=5066b5bd2b991110VgnVCM1000001a01010aRCRD

http://www.nga.org/portal/site/nga/menuitem.1f41d49be2d3d33eacdcbeeb501010a0/?vgnextoid=5066b5bd2b991110VgnVCM1000001a01010aRCRD

http://www.ncvhs.hhs.gov/

http://www.va.gov/

http://www.defenselink.mil/

http://www.ihs.gov/CIO/EHR/

http://www.samhsa.gov/

http://www.hrsa.gov/healthit/

http://www.cdc.gov/biosense/

http://www.cdc.gov/phin/


Table 6 Guidance StandardsStandard 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.orgASTM E2595 PMI: Privilege Management Infrastructure www.astm.orgASTM 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.govNIST Federal Information Processing Standards (FIPS) Publications

http://csrc.nist.gov/publications/PubsFIPS.html

HITECH Meaningful Use Objectives and CriteriaThere are 25 specific HITECH Meaningful Use (MU) objectives and criteria for the 2011 MU Stage I:

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

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

3. Objective: Maintain an up-to-date problem list of current and active diagnoses based on ICD-9-CM or SNOMED CT®Measure: At least 80 percent of all unique patients seen by the EP have at least one entry or an indication of none recorded as structured data.

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

5. Objective: Maintain active medication list.Measure: At least 80 percent of all unique patients seen by the EP have at least one entry (or an indication of “none” if the patient is not currently prescribed any medication) recorded as structured data.

6. Objective: Maintain active medication allergy list.Measure: At least 80 percent of all unique patients seen by the EP have at least one entry (or an indication of “none” if the patient has no medication allergies) recorded as structured data.

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

8. Objective: Record and chart changes in vital signs.Measure: For at least 80 percent of all unique patients age 2 and over seen by the EP, record blood pressure and BMI; additionally, plot growth chart for children age 2 to 20.The Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 52 of 168

429430

1681

168216831684

168516861687168816891690169116921693169416951696169716981699170017011702170317041705170617071708

431432433434



http://csrc.nist.gov/publications/PubsSPs.html

http://www.astm.org/



http://www.commoncriteriaportal.org/

http://www.wsi.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf





http://www.iso.org/


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

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

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

12. Objective: Report ambulatory quality measures to CMS or the States.Measure: For 2011, an EP would provide the aggregate numerator and denominator through attestation as discussed in section II.A.3 of this proposed rule. For 2012, an EP would electronically submit the measures are discussed in section II.A.3. of this proposed rule.

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

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

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

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

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

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

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

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

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

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

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

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

25. Objective: Protect electronic health information maintained using certified EHR technology through the implementation of appropriate technical capabilities.



435436

170917101711171217131714171517161717171817191720172117221723172417251726172717281729173017311732173317341735173617371738173917401741174217431744174517461747174817491750175117521753175417551756175717581759176017611762176317641765176617671768

437438439440


Measure: Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308 (a)(1) and implement security updates as necessary.

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

2.3.2 Business Objectives

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

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

2.3.3 Project Scope and Vision Statement

The Immunization Management Capability (IMC) project is intended to optimally accomplish immunization documentation and tracking, and support immunizations readiness reporting. The IMC initiative supports three broad goals:

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

medically protect individuals with the maximal ability to safely pursue their education and careers.

b. Improved medical readiness through documenting, monitoring and reporting immunization status.

2. Population Health perspective: a. Preventing and controlling diseases reduces adverse incidence requiring

medical treatment. b. Compliant with current national standards and regulations to include patient

safety and data quality. 3. Medical Care perspective:

a. Patient safety. b. Provider has immunization history. c. Medical conditions require supplemental immunization. d. Contraindications to immunizations.



441442

17691770177117721773

1774

1775177617771778177917801781178217831784

17851786178717881789179017911792179317941795179617971798179918001801180218031804

443444445446


2.3.4 Non-Functional Requirements

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

Figure 11 EHR-S FM Direct Care 1.8.2 Manage Immunization Administration Dependencies

The EHR-SD RM provides Figure 11 EHR-S FM Direct Care 1.8.2 Manage Immunization Administration Dependencies, which shows how Immunization Management depends on the EHR System Non-functional requirements (e.g., IN.1.6, IN.1.7, IN.2.4, IN.2.5.1, IN.2.5.2, IN.3.1, IN.3.2, IN.4.1, IN.4.2, IN.4.3, IN.5.1, IN.5.2, IN.6) and results in the following overall conformance criteria:DC 1.8.2 Manage Immunization Administration depends on IN 1.6 Secure Data

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


5/16/2010 Page 55 of 168

447448

1805

18061807180818091810181118121813181418151816

449450451452


1. The system SHALL secure all modes of EHR data exchange. 2. The system SHOULD conform to function IN.1.7 (Secure Data Routing). 3. The system MAY provide the ability to obfuscate data. 4. The system SHALL encrypt and decrypt EHR data that is exchanged over a non-

secure link. 5. The system SHALL support standards-based encryption mechanisms when encryption is used for

secure data exchange. DC 1.8.2 Manage Immunization Administration depends on IN 1.7 Secure Data Routing

1. The system SHALL automatically route electronically exchanged EHR data only from and to known sources and destinations and only over secure networks.

2. The system SHOULD route electronically exchanged EHR data only to and from authenticated sources and destinations (conform to function IN.1.1 (Entity Authentication)).

3. The system SHOULD conform to function IN.2.2 (Auditable Records) to provide audit information about additions and changes to the status of destinations and sources.

DC 1.8.2 depends on IN 2.4 Extraction of Health Record Information 1. The system SHALL provide the ability to extract health record information. 2. The system SHOULD conform to function IN.1.6 (Secure Data Exchange) to provide secure data

exchange capabilities. 3. The system SHOULD provide the ability to de-identify extracted information. 4. The system SHOULD conform to function IN.5.1 (Interchange Standards) to enable data extraction in

standard-based formats. 5. The system SHOULD provide the ability to perform extraction operations across the complete data set

that constitutes the health record of an individual within the system. 6. The system MAY provide the ability to perform extraction operations whose output fully chronicles the

healthcare process. 7. The system SHOULD provide the ability to extract data for administrative purposes. 8. The system SHOULD provide the ability to extract data for financial purposes. 9. The system SHOULD provide the ability to extract data for research purposes. 10. The system SHOULD provide the ability to extract data for quality analysis purposes. 11. The system SHOULD provide the ability to extract data for public health purposes.

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

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

the original unstructured health record information. A specific type of implementation is not implied.

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

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

DC 1.8.2 depends on IN 2.5.2 Manage Structured Health Record Information 1. The system SHALL capture structured health record information as part of the patient EHR. 2. The system SHALL retrieve structured health record information as part of the patient EHR. 3. The system SHALL provide the ability to update structured health record information. 4. The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction) to

provide the ability to inactivate, obsolete, or destroy structured health record information. The Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 56 of 168

453454

1817181818191820182118221823

18241825

18261827

18281829

1830183118321833

183418351836

18371838

18391840

18411842184318441845184618471848184918501851

1852185318541855

18561857

18581859

186018611862

18631864186518661867

1868455456457458


5. The system SHOULD provide the ability to report structured health record information. 6. The system MAY track structured health record information over time. 7. The system SHOULD provide the ability to retrieve each item of structured health record information

discretely within patient context. 8. The system SHALL provide the ability to append corrected structured health record information to the

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

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

the original structured health record information. A specific type of implementation is not implied.

DC 1.8.2 depends on IN 3. Registry and Directory Services 1. The system SHALL provide the ability to use registry services and directories. 2. The system SHOULD provide the ability to securely use registry services and directories. 3. The system SHALL conform to function IN.5.1 (Interchange Standards) to provide standard data

interchange capabilities for using registry services and directories. 4. The system SHOULD communicate with local registry services through standardized interfaces. 5. The system SHOULD communicate with non-local registry services (that is, to registry services that

are external to an EHR-S) through standardized interfaces. 6. The system SHOULD provide the ability to use registries or directories to uniquely identify patients

for the provision of care. 7. The system SHOULD provide the ability to use registries or directories to uniquely identify providers

for the provision of care. 8. The system MAY provide the ability to use registries or directories to retrieve links to relevant

healthcare information regarding a patient. 9. The system MAY provide the ability to use registries to supply links to relevant healthcare information

regarding a patient. 10. The system MAY provide the ability to use registries or directories to identify payers, health plans,

and sponsors for administrative and financial purposes. 11. The system MAY provide the ability to use registries or directories to identify employers for

administrative and financial purposes. 12. The system MAY provide the ability to use registries or directories to identify public health agencies

for healthcare purposes. 13. The system MAY provide the ability to use registries or directories to identify healthcare resources

and devices for resource management purposes. DC 1.8.2 depends on IN 4.1 Standard Terminologies and Terminology Models

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

2. The system SHALL provide the ability to validate that clinical terms and coded clinical data exists in a current standard terminology.

3. The system SHOULD provide the ability to exchange healthcare data using formal standard information models and standard terminologies.

4. The system SHOULD provide the ability to use a formal standard terminology model. 5. The system SHOULD provide the ability to use hierarchical inference searches e.g., subsumption

across coded terminology concepts that were expressed using standard terminology models. 6. The system SHOULD provide the ability to manage terminology assets and supporting tools (internal

or external to the EHR-S). 7. IF there is no standard terminology model available, THEN the system MAY provide a formal explicit

terminology model. DC 1.8.2 depends on IN 4.2 Maintenance and Versioning of Standard Terminologies

1. The system SHALL provide the ability to use different versions of terminology standards. 2. The system SHALL provide the ability to update terminology standards.



459460

186918701871

18721873

18741875

18761877

18781879

1880188118821883

188418851886

18871888

18891890

18911892

18931894

18951896

18971898

18991900

19011902

190319041905

19061907

19081909

191019111912

19131914

19151916

1917191819191920

461462463464


3. The system MAY relate modified concepts in the different versions of a terminology standard to allow preservation of interpretations over time.

4. The system SHOULD provide the ability to interoperate with systems that use known different versions of a terminology standard.

5. The system SHOULD provide the ability to deprecate terminologies. 6. The system MAY provide the ability to deprecate individual codes within a terminology. 7. The system SHALL provide the ability to cascade terminology changes where coded terminology

content is embedded in clinical models (for example, templates and custom formularies) when the cascaded terminology changes can be accomplished unambiguously.

8. Changes in terminology SHALL be applied to all new clinical content (via templates, custom formularies, etc.).

DC 1.8.2 depends on IN 4.3 Terminology Mapping1. The system SHALL provide the ability to use a terminology map. 2. The system SHOULD provide the ability to use standard terminology services for the purposes of

mapping terminologies. 3. The system MAY provide the ability for a user to validate a mapping. 4. The system MAY provide the ability to create a terminology map.

DC 1.8.2 depends on IN 5.1 Interchange Standards 1. The system SHALL provide the ability to use interchange standards as required by realm specific

and/or local profiles. 2. The system SHALL provide the ability to seamlessly perform interchange operations with other

systems that adhere to recognized interchange standards. 3. The system SHALL conform to functions under header IN.4 (Standard Terminologies and Terminology

Services) to support terminology standards in accordance with a users' scope of practice, organizational policy, or jurisdictional law.

4. IF there is no standard information model available, THEN the system MAY provide a formal explicit information model in order to support the ability to operate seamlessly with other systems.

5. The system SHOULD provide the ability to exchange data using an explicit and formal information model and standard, coded terminology.

DC 1.8.2 depends on IN 5.2 Interchange Standards Versioning and Maintenance 1. The system SHALL provide the ability to use different versions of interchange standards. 2. The system SHALL provide the ability to change (reconfigure) the way that data is transmitted as an

interchange standard evolves over time and in accordance with business needs. 3. The system SHOULD provide the ability to deprecate an interchange standard. 4. The system SHOULD provide the ability to interoperate with other systems that use known earlier

versions of an interoperability standard. DC 1.8.2 depends on IN 6 Business Rules Management

1. The system SHALL provide the ability to manage business rules. 2. The system SHOULD provide the ability to create, import, or access decision support rules to guide

system behavior. 3. The system SHOULD provide the ability to update decision support rules. 4. The system SHOULD provide the ability to customize decision support rules and their components. 5. The system SHOULD provide the ability to inactivate, obsolete, or destroy decision support rules. 6. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to decision

support rules. 7. The system SHOULD provide the ability to create diagnostic support rules to guide system behavior. 8. The system SHOULD provide the ability to update diagnostic support rules. 9. The system MAY provide the ability to customize diagnostic support rules and their components. 10. The system SHOULD provide the ability to inactivate, obsolete, or destroy diagnostic support rules. 11. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to

diagnostic support rules. 12. The system SHOULD provide the ability to create workflow control rules to guide system behavior. 13. The system SHOULD provide the ability to update workflow control rules.



465466

19211922

19231924

192519261927

19281929

19301931

193219331934

19351936193719381939

19401941

19421943

19441945

19461947

19481949

195019511952

195319541955

1956195719581959

19601961196219631964

196519661967196819691970

197119721973

467468469470


14. The system MAY provide the ability to customize workflow control rules and their components. 15. The system SHOULD provide the ability to inactivate, obsolete, or destroy workflow control rules. 16. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to workflow

control rules. 17. The system MAY provide the ability to create access privilege rules to guide system behavior. 18. The system MAY provide the ability to update access privilege rules. 19. The system MAY provide the ability to customize access privilege rules and their components. 20. The system MAY provide the ability to inactivate, obsolete, or destroy access privilege rules. 21. The system MAY conform to function IN.2.2 (Auditable Records) to audit all changes to access

privilege rules. 22. The system SHOULD conform to function IN.2.2 (Auditable Records) to audit all changes to other

business rules. 23. The system SHOULD support the ability to selectively export business rules.

2.3.5 Use Case Inventory

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

o Consumer Preferences 2009 Use Case and Extensions/Gaps

o Common Data Transport o General Laboratory Orders o Order Sets o Medication Gaps o Clinical Note Details o Common Device Connectivity o Newborn Screening

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

2008 Use Caseso Remote Monitoring o Patient - Provider Secure Messaging o Personalized Healthcare o Consultations and Transfers of Care o Public Health Case Reporting o Immunizations & Response Management

2007 Use Caseso Emergency Responder — Electronic Health Record (PDF) o Consumer Empowerment: Consumer Access to Clinical Information o Medication Management o Quality

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



471472

197419751976

197719781979198019811982

19831984

19851986

1987

1988198919901991199219931994199519961997199819992000200120022003200420052006200720082009201020112012201320142015201620172018201920202021

2022473474475476

http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848101_0_0_18/BiosurveillanceUtilizationUseCase.pdf

http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848103_0_0_18/EHRLabUseCase.pdf

http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848102_0_0_18/ConsumerEmpowerment.pdf

http://healthit.hhs.gov/portal/server.pt?open=512&objID=1202&&PageID=15677&mode=2&in_hi_userid=10732&cached=true



http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848104_0_0_18/EmergencyRespEHRUseCase.pdf














http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10779_868916_0_0_18/2009.05.13%20NBS%20Use%20Case%20Companion%20042409.pdf






http://healthit.hhs.gov/portal/server.pt?open=512&objID=1202&&PageID=15720&mode=2


http://healthit.hhs.gov/portal/server.pt?open=512&objID=1202&PageID=16769&mode=2


2.3.6 Conformance Criteria1. IMC satisfies all applicable national regulations and policies.2. IMC satisfies the requirements of the EHR-S FM Direct Care 1.8.2 function and its

dependencies.3. IMC satisfies the requirements of the HHS AHIC Immunization & Response

Management (IRM) use Case.4. IMC satisfies the requirements of the HHS AHIC Public Health Case Reporting

(PHCR) Use Case.2.3.7 Discussion

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

2.4 Conceptual Information-Viewpoint

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

Inventory of Domain Entities, Roles, Activities and Associations.

Information Model Conceptual Domain

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



477478

202320242025202620272028202920302031

203220332034203520362037

2038

2039204020412042204320442045204620472048204920502051205220532054

479480481482


Figure 12 Conceptual Health Data Model

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

26 Conceptual Health Data Model v2.3, Canadian Institute for Health InformationThe Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 61 of 168

483484

2055

205620572058

20592060206120622063206420652066206720682069207020712072207320742075

485486487488489




490491

2076

492493494495


2.4.1 Domain Information Model

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

Payers Section Allergies and Other Adverse

Reactions Section Problem List Section History of Past Illness Section Chief Complaint Section Reason for Referral Section History of Present Illness Section List of Surgeries Section Functional Status Section Hospital Admission Diagnosis Section Discharge Diagnosis Section Medications Section Admission Medications History

Section Hospital Discharge Medications

Section Medications Administered Section Advance Directives Section Immunizations Section Physical Examination Section Vital Signs Section Review of Systems Section Hospital Course Section Diagnostic Results Section Assessment and Plan Section Plan of Care Section

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 allergy29 CDA Data dictionary is defined in the HITSP/C154 Data Dictionary Component.

Family History Section Social History Section Encounters Section Medical Equipment Section Preoperative Diagnosis Section Postoperative Diagnosis Section Surgery Description Section Surgical Operation Note Findings

Section Anesthesia Section Estimated Blood Loss Section Specimens Removed Complications Section Planned Procedure Section Indications Section Disposition Section Operative Note Fluids Section Operative Note Surgical Procedure

Section Surgical Drains Section Implants Section Assessments Section Procedures and Interventions Section Provider Orders Section Questionnaire Assessment Section

The following Entry Content Modules are used:

Personal Information Language Spoken Support Healthcare Provider Insurance Provider Allergy/Drug Sensitivity Condition Medication Pregnancy Information Source Comment Advance Directive Immunization Vital Sign Result Encounter Procedure Family History Social History Medical Equipment Functional Status Plan Of Care

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



496497

2077

2078207920802081208220832084208520862087208820892090209120922093209420952096209720982099210021012102210321042105210621072108210921102111211221132114

498499500501502503

504505506507508509

510

2115211621172118211921202121212221232124212521262127212821292130213121322133213421352136213721382139214021412142214321442145214621472148214921502151215221532154215521562157215821592160216121622163216421652166216721682169

511512513514

http://www.hitsp.org/


2.4.2 Conformance Statements1. The IMC is CDA compliant as specified by HITSP C80, C83 and C154.2. IMC messaging is compliant with HITSP C72 (Immunization Message).

2.4.3 Discussion

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

2.5 Conceptual Computation-Viewpoint

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

Inventories of Capabilities-Components, Functions-Services

Requirements Accountability Roles Behaviors Functional Profiles Interactions Interfaces Contracts

Conceptual Functional Service Specifications (CFSS)



515516

2170217121722173

21742175217621772178217921802181218221832184218521862187

2188

21892190219121922193219421952196219721982199220022012202220322042205220622072208

517518519520


The Conceptual Computation-Viewpoint is defined by the functional requirements defined in the HL7 EHR System Functional Model, AHIC Use Case Harmonization Request and by HITSP capabilities. The SampleHealth ECCF Conceptual Computation-Viewpoint contains:

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

2.5.1 Service Inventory

HSSP provides the following services: CTS2 (Common Terminology Services 2) - CTS 2 is a standard for terminology services that

enhances the capabilities of the initial CTS specification for sub-setting and mapping, and extends the specification into domains such as terminology distribution, versioning, and classification.

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

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

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

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

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

NHIN Connect version 2.4 provides the following services: Access Consent - This specification provides a standard language for expressing restrictions on access

to health information. These restrictions are also known as Access Consent Policies. Access Consent Policies may be “off-the-shelf” policies that are adopted by or apply to a consumer, or they may be policies that are customized by a consumer to grant or deny access to specific types of information by specific types of users. Access Consent policies may also be created by users other than consumers; for example, physicians may create policies that restrict access to health information they create.

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

Enterprise Service Component - Policy Engine - The Policy Engine Enterprise Service Component comprises both open-source components and interactions implemented within CONNECT. This section describes the overall architecture of the Policy Engine, identifying those components that are open-source. The Policy Engine takes responsibility of determining whether a message should be processed by CONNECT, regardless of the direction the message is being moved - whether it is inbound from the NHIN or outbound to the NHIN - and thereby enables an organization to apply policies to all messages.



521522

22092210221122122213221422152216

22172218

22192220

2221222222232224

222522262227

22282229

223022312232

22332234

2235

22362237

22382239224022412242

2243224422452246224722482249225022512252

225322542255225622572258

523524525526

http://developer.connectopensource.org/display/NHINR24/Referenced+Materials#ReferencedMaterials-ONC20096

http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848156_0_0_18/NHIN%20Trial%20Implementations%20Audit%20Log%20Query%20Service%20Interface%20Specification%20v%201.3.1.pdf

http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848156_0_0_18/NHIN%20Trial%20Implementations%20Audit%20Log%20Query%20Service%20Interface%20Specification%20v%201.3.1.pdf


Policies may be patient-specific (e.g., based on the patient's consent for a specific information exchange) or organization specific (e.g., based on hours of operation, user role, etc.).

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

Authorized Case Follow-Up - Pseudonymization is the process of removing the association between a data set (e.g., protected health information or PHI) and the subject of that data (e.g., a patient) by removing identifying information, and adding an association between the data set and one or more alternative identifiers, or pseudonyms. Reidentification is the process of obtaining the association between a pseudonym and the original subject of that data set (e.g., re-associating PHI with the patient). Pseudonymization may be required for a number of reasons. For example, there may be a need to report health information to a public health agency for surveillance purposes in which case the identity of the individual is not needed. Likewise, reidentification may be required if an authorized individual, such as a public health official, must investigate a potential public health issue with proper legal authorization by gaining more information from the longitudinal health record of the individual known only by their pseudonym. Authorized Case Follow-up represents the services for reidentification. It does not include the services, algorithms, or specifications for pseudonymization. The transaction used by the service interface is the HL7 v3 Patient Registry Get Identifiers Query, as profiled by the IHE Patient Identifier Cross-Reference HL7 v3 (PIX v3) Supplement Draft for Trial Implementations dated 15 August 2007 and Patient Demographic Query HL7 v3 (PDQ v3) Supplement Draft for Trial Implementations dated 15 August 2007 [IHE PIX and IHE PDQ]. See the NHIN Trial Implementations Service Interface Specifications - Authorized Case Follow Up v1.0 for more information on the standards and specifications that describe this service [ONC 2009-7].

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

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

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

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



527528

22592260

226122622263226422652266

2267226822692270227122722273227422752276227722782279228022812282228322842285

22862287228822892290

229122922293229422952296

22972298229923002301230223032304230523062307

2308230923102311

529530531532



http://developer.connectopensource.org/display/NHINR24/Referenced+Materials#ReferencedMaterials-IHEXCA

http://developer.connectopensource.org/display/NHINR24/Service+View+-+Query+for+Documents



http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848251_0_0_18/NHIN_Trial_Implementations_Authorized_Case_Service_Interface_SpecificationV1.0.pdf

http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848251_0_0_18/NHIN_Trial_Implementations_Authorized_Case_Service_Interface_SpecificationV1.0.pdf

http://developer.connectopensource.org/display/NHINR24/Referenced+Materials#ReferencedMaterials-IHEPDQ

http://developer.connectopensource.org/display/NHINR24/Referenced+Materials#ReferencedMaterials-IHEPIX


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

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

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

Query for Documents - The Query for Documents service provides the mechanism by which one NHIE locates electronic health information on the NHIN associated with a specific patient. The service allows one NHIE to acquire a list of documents for a given patient that may exist at another NHIE, based on a set of search criteria. The service can be viewed as receiving query requests from the NHIN to which it must respond, and sending queries to NHIEs on the NHIN in order to locate a patient's health information. Sequence diagrams are included for messages in each direction. The transactions implemented by the Query for Documents service are described in the IHE IT Infrastructure Technical Framework - Cross Gateway Query (XCA) Supplement Draft for Trial Implementations dated 15 August 2007 [IHE XCA]. The use of this profile is included in HITSP TP13 Manage Sharing of Documents Transaction Package [HITSP TP13]. See the NHIN Query for Documents Web Service Interface Specification v2.0 dated 29 January 2010 for more information on the standards and specifications that describe this service [ONC 2010-2]. The XCA specification has been relaxed within the NHIN to support the query for, and retrieval of, dynamically generated document content.

Retrieve Documents - The Retrieve Documents service provides a mechanism to retrieve the electronic health information on the NHIN. It is used in conjunction with the Query for Documents service, which returns a list of document references that Retrieve Documents uses to retrieve patient records. The service can be viewed as receiving document requests from the NHIN to which it must respond, and sending requests to NHIEs on the NHIN in order to retrieve patient health information. Sequence diagrams are included for messages in each direction. The transactions implemented by the Retrieve Documents service are described in the IHE IT Infrastructure Technical Framework - Cross Community Access (XCA) Supplement Draft for Trial Implementations dated 15 August 2007 [IHE XCA]. The use of this profile is included in HITSP TP13 Manage Sharing of Documents Transaction Package [HITSP TP13]. See the NHIN Retrieve Documents Web Service Interface Specification v2.0 dated 29 January 2010 for more information on the standards and specifications that describe this service [ONC 2010-3].

Service Registry - The NHIN Services Registry allows NHIN member organizations to locate and utilize the appropriate services offered by other members in a controlled, secure manner. The registry enables privacy and trust by only allowing vetted participant organizations into the registry. The



533534

23122313231423152316231723182319

2320232123222323

232423252326232723282329233023312332233323342335

23362337233823392340234123422343234423452346234723482349

235023512352235323542355235623572358235923602361

236223632364

535536537538


http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_910547_0_0_18/NHIN_RetrieveDocumentsProductionSpecification_v2.0.pdf

http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_910547_0_0_18/NHIN_RetrieveDocumentsProductionSpecification_v2.0.pdf

http://developer.connectopensource.org/display/NHINR24/Referenced+Materials#ReferencedMaterials-HITSPTP13


http://developer.connectopensource.org/display/NHINR24/Service+View+-+Query+for+Documents


http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_910546_0_0_18/NHIN_QueryforDocumentsProductionSpecification_v2.0.pdf

http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_910546_0_0_18/NHIN_QueryforDocumentsProductionSpecification_v2.0.pdf

http://developer.connectopensource.org/display/NHINR24/Referenced+Materials#ReferencedMaterials-HITSPTP13




http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_910524_0_0_18/NHIN_PatientDiscoveryProductionSpecification_v1.0.pdf

http://developer.connectopensource.org/display/NHINR24/Referenced+Materials#ReferencedMaterials-IHEXCPD

http://developer.connectopensource.org/display/NHINR24/Referenced+Materials#ReferencedMaterials-IHEXCPD


http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_910522_0_0_18/NHIN_HealthInformationEventMessagingProductionSpecification_v2.0.pdf

http://developer.connectopensource.org/display/NHINR24/Referenced+Materials#ReferencedMaterials-OASIS20062

http://developer.connectopensource.org/display/NHINR24/Referenced+Materials#ReferencedMaterials-OASIS20061


registry facilitates interoperability, by cataloging and advertising in real-time which services are supported by each organization.

Subject Discovery - The Subject Discovery service interface is used between NHIEs for the purpose of querying for a subject, and upon a positive match returns a unique identifier that may be used to query for records on that subject. The subject referred to in this specification is a healthcare consumer, patient or may be a provider. Subject as used in this specification does not include system user.

2.5.1 Functional Requirements

The EHR-SD RM provides Figure 11 EHR-S FM Direct Care 1.8.2 Manage ImmunizationAdministration Dependencies, which shows how Immunization Management depends on other EHR System functional requirements (e.g., DC.1.3.2, DC.1.4.4, S.1.1, S.2.2.2, S.3.7.1) and results in the following functional conformance criteria:DC 1.8.2 Manage Immunization Administration

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

2. The system SHOULD provide the ability to recommend required immunizations based on patient risk factors.

3. The system SHALL perform checking for potential adverse or allergic reactions for all immunizations when they are about to be given.

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

5. The system SHOULD provide the ability to capture other clinical data pertinent to the immunization administration (e.g. vital signs).

6. The system SHALL record as discrete data elements data associated with any immunization. 7. The system SHOULD provide the ability to associate standard codes with discrete data elements

associated with an immunization. 8. The system SHALL provide the ability to update the immunization schedule. 9. The system SHOULD provide the ability to prepare a report of a patient's immunization history upon

request for appropriate authorities such as schools or day-care centers. 10. The system SHALL conform to function DC.1.4.1 (Manage Allergy, Intolerance and Adverse

Reaction Lists). 11. The system SHOULD transmit required immunization information to a public health immunization

registry. 12. The system SHOULD receive immunization histories from a public health immunization registry.

DC 1.8.2 depends on DC 1.3.2 Manage Patient Advance Directives 1. The system SHALL provide the ability to indicate that advance directives exist for the patient. 2. The system SHALL provide the ability to indicate the type of advance directives completed for the

patient such as living will, durable power of attorney, preferred interventions for known conditions, or the existence of a "Do Not Resuscitate order”.

3. The system SHOULD provide the ability to capture, present, maintain and make available for clinical decisions patient advance directives documents and “Do Not Resuscitate” orders.

4. The system SHOULD conform to function DC.1.1.3.1 (Capture Data and Documentation from External Clinical Sources) and capture scanned patient advance directive documents and “Do Not Resuscitate” orders.

5. The system SHOULD provide the ability to indicate when advanced directives were last reviewed. 6. The system SHOULD provide the ability to indicate the name and relationship of the party

completing the advance directive for the patient. 7. The system SHALL time and date stamp advance directives. 8. The system SHOULD provide the ability to document the location and or source of any legal

documentation regarding advance directives. 9. The system SHOULD conform to function DC.2.1.4 (Support for Patient and Family Preferences).

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



539540

23652366

23672368236923702371

2372237323742375

23762377

23782379

23802381

23822383

23842385

238623872388

238923902391

23922393

23942395

23962397239823992400

24012402

24032404

240524062407

24082409

241024112412

2413241424152416

541542543544


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

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

DC 1.8.2 depends on S 1.1 Registry Notification 1. The system SHOULD automatically transfer formatted demographic and clinical information to local

disease specific registries (and other notifiable registries). 2. The system MAY provide the ability to automate the retrieval of formatted demographic and clinical

information from local disease specific registries (and other notifiable registries). 3. The system SHOULD provide the ability to add, change, or remove access to registries.

DC 1.8.2 depends on S 2.2.2 Standard Report Generation 1. The system SHOULD provide the ability to generate reports of structured clinical and

administrative data using either internal or external reporting tools. 2. The system MAY provide the ability to include information extracted from unstructured clinical and

administrative data in the report generation process, using internal or external tools. 3. The system SHOULD provide the ability to export reports generated. 4. The system SHOULD provide the ability to specify report parameters, based on patient demographic

and/or clinical data, which would allow sorting and/or filtering of the data. 5. The system (or an external application, using data from the system) MAY provide the ability to save

report parameters for generating subsequent reports. 6. The system (or an external application, using data from the system) MAY provide the ability to

modify one or more parameters of a saved report specification when generating a report using that specification.

DC 1.8.2 depends on S 3.7.1 Clinical Decision Support System Guidelines Updates 1. The system SHALL provide the ability to update the clinical content or rules utilized to generate

clinical decision support reminders and alerts. 2. The system SHOULD validate that the most applicable version is utilized for the update, and capture

the date of update. 3. The system MAY track and retain the version used when guidelines are provided in a patient

encounter.

2.5.2 Conceptual Functional Service Specification (CFSS)

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

TBD

2.5.3 Service Roles and Relationships

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

TBD2.5.4 Conformance Statements

1. IMC meets the EHR-S FM Direct Care 1.8.2 Immunization Management and derived requirements.

2. IMC makes appropriate use of HSSP and NHIN services.



545546

24172418

24192420

24212422

24232424

2425242624272428

24292430

243124322433

24342435

24362437

24382439

24402441

24422443

24442445

244624472448

2449

245024512452

2453

2454245524562457245824592460

547548549550


2.5.5 Discussion

The SampleHealth IMC project Conceptual Computation-Viewpoint is defined by the functional requirements and Information Exchange Requirements (IERs) defined in the HL7 EHR System Functional Model, AHIC Use Case Harmonization Request and by HITSP capabilities. ISSUE: In the ECCF, it is not intuitively obvious where Use cases, Information Exchange Requirements (IERs), Business Process Models and System Data Exchanges models (i.e., sequence diagrams of transactions implementing an IHE profile) respectively belong.

2.6 Conceptual Engineering-View

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

Inventory of Software Platforms/ Environments and their Capabilities.

2.6.1 Inventory of Software Platforms and Their Capabilities

For SampleHealth the Conceptual Engineering-Viewpoint is defined by NHIN Connect to be:

Apache Tomcat (or Jakarta Tomcat or simply Tomcat) is an open source servlet container developed by the Apache Software Foundation (ASF). Tomcat implements the Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems, and provides a "pure Java" HTTP web server environment for Java code to run.

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

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



551552

2461

24622463246424652466246724682469

2470

247124722473247424752476247724782479248024812482248324842485248624872488248924902491249224932494249524962497249824992500

553554555556


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

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

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

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

2.6.2 Conformance Statements1. IMC uses the appropriate NHIN CONNECT version 2.4 platforms.

2.6.3 Discussion

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

2.7 Platform-Independent Enterprise-Business-Viewpoint

The ECCF Platform-Independent Enterprise-Business-Viewpoint defines the business and reference context. The Enterprise-Business-Viewpoint is concerned with the business governance of the system as it relates to the business objectives and the business processes of the organization. This Viewpoint answers the question “why” and refers to policy. This Viewpoint is primarily



557558

2501250225032504250525062507250825092510251125122513251425152516251725182519252025212522252325242525252625272528

25292530253125322533

2534

2535

25362537253825392540

559560561562

http://en.wikipedia.org/wiki/OpenAM

http://en.wikipedia.org/wiki/Federated_identity

http://en.wikipedia.org/wiki/New_I/O

http://en.wikipedia.org/w/index.php?title=Grizzly_(software)&action=edit&redlink=1

https://open-esb.dev.java.net/


useful to project managers and business process experts. This Viewpoint might typically contains some combination of:

Applicable Rules Use Case Specs Governance. Technology Neutral Standards Wireframes of

architectural layers components and Associations

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

Figure 13 NHIN Standards Framework

2.7.2 Business Governance

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

Change Control Board (CCB) manages Enterprise Requirements and Investment Portfolio.

Architecture Review Board (ARB) manages architecture, reusable components and services.

30 Based on DOD Instruction (DODI) 5000.2The Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 72 of 168

563564

2541254225432544254525462547254825492550255125522553255425552556

25572558

25592560256125622563256425652566256725682569

565566567568569


Configuration Management Board (CMB) manages the following baselines. o System Requirements Review (SRR)o Preliminary Design Review (PDR)o Critical Design Review (CDR)o Test Readiness Review (TRR)o System Integration Test (SIT)o System Qualification Test (SQT)o Operational Test and Evaluation (OT&E)

2.7.3 Conformance Statements1. IMC requirements were approved by the CCB. 2. IMC architectural views were approved by the ARB.3. IMC SRR baseline was approved by the CMB. 4. IMC PDR baseline was approved by the CMB. 5. IMC CDR baseline was approved by the CMB. 6. IMC TRR baseline was approved by the CMB. 7. IMC SIT baseline was approved by the CMB. 8. IMC SQT baseline was approved by the CMB. 9. IMC OT&E baseline was approved by the CMB.

2.7.4 Discussion

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

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

31 Available at http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf The Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 73 of 168

570571

2570257125722573257425752576257725782579258025812582258325842585258625872588

258925902591259225932594259525962597259825992600260126022603

2604260526062607260826092610

572573574575576

http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf


2.8Platform-Independent Information-Viewpoint

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

Information Models Localized Information Model Constrained Information Model Project Information Model

Message Content Specifications

A Logical Level Data Model32 is the most detailed level. The full complexity of data entities and all their relationships are expressed. It is this level of detail that is necessary to specify information systems. All entities should be fully described with all their characteristics. The permissible values of all attributes (characteristics) should also be defined and all relationships expressed.

The SampleHealth Project Information Model for the Platform-Independent Information-Viewpoint is defined by the HITSP Components33.

HITSP/C72 Immunization Message, HITSP/C83 CDA Content Modules HITSP/C80 Terminology HITSP/C154 Data Dictionary

2.8.1 Project Information Model

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

Data Requirements (DRs)IRM Data Requirements (DRs):

DR08 Unstructured Data DR11 Immunization response data DR12 Adverse Event Report DR13 Drug/Vaccine Inventory Data DR14 Drug/Vaccine Inventory Usage Data DR15 Drug/Vaccine Inventory Availability Data

32 Conceptual Health Data Model v2.3, Canadian Institute for Health Information33 Available from www.HITSP.org



577578

2611

26122613261426152616261726182619262026212622262326242625262626272628262926302631263226332634263526362637

26382639264026412642

26432644264526462647264826492650

579580581582583584


DR16 Supply Chain Management Vaccine Recall DR17 Decision Support Data DR18 Vaccination Data DR19 Medication Administration data DR20 Aggregate Inventory of Available Vaccine DR21 Terminology Data DR22 Generic Alert Data DR23 Consumer Vaccination View

PHCR Data Requirements (DRs): DR08 Unstructured Data DR17 Decision Support Data DR21 Terminology Data DR24 Case Report Pre-populate Data DR22 Generic Alert Data DR23 Consumer Vaccination View DR24 Case Report Pre-populate Data DR25 Case Report Content DR26 Reporting Criteria Content DR59 Generic Alert Data

Table 7 Data Element and Information Requirements (DR)Data

Requirement Number

(DR) DescriptionDR8 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:TitleClinic IDDate

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 AddressPatient Phone NumberPatient IdentifierPatient Birth Date Patient Sex Patient Race Patient EthnicityPatient Primary Language



585586

26512652265326542655265626572658265926602661266226632664266526662667266826692670267126722673

587588589590


Data Requirement

Number (DR) Description

Patient Multiple Birth IndicatorPatient Multiple Birth OrderPatient 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 SSNInsurance 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/DateLast Update Facility Immunization Event IdentifierVaccine Expiration Date Vaccine Injection Site Vaccination Date Vaccine Lot Number Vaccine Administration Provider Vaccine Administration FacilityVaccine Type Vaccine Manufacturer Vaccine Dose Number Reason for Non-Vaccination Patient Status in the Immunization Home Transaction Information Source Immunisation Information SourceAmount Administered (dosage amount): Smallpox Take Response ObservationRead Date for Take Response Treatment Route Refusal Reason Action Code Vaccine Dose Valid FlagImmunization Recommendations Vaccine Information Sheet (VIS) date Vaccine Information Sheet (VIS) version Vaccine Recall Effective DateVaccine 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 The Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 76 of 168

591592

593594595596


Data Requirement


management functions of vaccine supply. NOTE: Scenario 2 deferred. Data requirements include (but are not limited to):quantity of vaccine locationcliniciangeographic identifiersnon-geographic identifiersmanufacturerlot numberexpiration 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 locationcliniciangeographic identifiersnon-geographic identifiersmanufacturerlot numberexpiration 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 locationcliniciangeographic identifiersnon-geographic identifiersmanufacturerlot numberexpiration date

DR16 Supply Chain Management Vaccine Recall: Content that supports the vaccine recall functions of the vaccine supply chain.NOTE: Scenario 2 deferred.Data requirements include (but are not limited to):Title (what is being recalled)Date of recallLot # Expiration dateManufacturersReason- textAction – 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’



597598

599600601602


Data Requirement


function) or a Clinical Decision Support actor such as SurveillanceDR17 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 reconciliationClinical protocolsAdministrative protocols (e.g: Insurance) Diagnosis Laboratory resultsFor this Interoperability Specification, data may also include, but is not limited to:Decision support data input Age rangeSexRace RiskLocation of the exposureDate/time of exposureType of exposureOccupation (e.g., first responders)Clinical historyPatient Birth DateDecision support feedback (pending further analysisLogicContraindicationsPolicyTrigger CriteriaOther 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 AddressPatient Phone NumberPatient IdentifierPatient Birth Date Patient Sex Patient Race Patient EthnicityPatient Primary Language Patient Multiple Birth IndicatorPatient Multiple Birth OrderPatient Birth Registration Number Patient Birth State/Country



603604

605606607608


Data Requirement


Patient Birthing Facility Mother’s Name: First, Middle, Last Mother’s Maiden Name Mother’s SSN Father’s Name: First, Middle, Last Father’s SSNInsurance 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/DateLast Update Facility Immunization Event IdentifierVaccine Expiration Date Vaccine Injection Site Vaccination Date Vaccine Lot Number Vaccine Administration Provider Vaccine Administration FacilityVaccine Type Vaccine Manufacturer Vaccine Dose Number Reason for Non-Vaccination Patient Status in the Immunization Home Transaction Information Source Immunisation Information SourceAmount Administered (dosage amount)Smallpox Take Response ObservationRead 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 individualdates administeredadministering clinician



609610

611612613614


Data Requirement


manufacturer and lot numbersource of this information (clinically verifiable source, self-reported by a consumer, or provided from another non-clinically verifiable source) reason for drug administration- information does not go to registry unless given for prophylactic reasoncampaign for prophylactic drug use/contextpopulation that the campaign is directed towardcampaign IDcampaign namecampaign start/end datecampaign potential counter-measuresSee 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 committeddoses remaininglocationcliniciangeographic identifiers non-geographic identifiersmanufacturerlot numberexpiration 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 criteriaData requirements include (but are not limited to):Target populationAlert delivery timeframeA descriptive directiveAlert title/subject Date/time of alert Alert typeSeveritySource/AuthorAlert identifier Alert statusAcknowledge requirements

DR23 Consumer Vaccination View: This is a consumer friendly view of a person’s



615616

617618619620


Data Requirement


immunization history/record.Patient Name: First, Middle, Last Patient Alias Name: First, Middle, Last Patient AddressPatient Phone NumberPatient IdentifierPatient Birth Date Patient Sex Patient Race Patient EthnicityPatient Primary Language Patient Multiple Birth IndicatorPatient Multiple Birth OrderPatient 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 SSNInsurance 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/DateLast Update Facility Immunization Event IdentifierVaccine Expiration Date Vaccine Injection Site Vaccination Date Vaccine Lot Number Vaccine Administration Provider Vaccine Administration FacilityVaccine Type Vaccine Manufacturer Vaccine Dose Number Reason for Non-Vaccination Patient Status in the Immunization Home Transaction Information Source Immunisation Information SourceAmount Administered (dosage amount): Smallpox Take Response ObservationRead Date for Take Response Treatment Route Refusal Reason



621622

623624625626


Data Requirement


Action Code Vaccine Dose Valid FlagImmunization 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 AddressPatient Phone NumberPatient IdentifierPatient Birth Date Patient Sex Patient Race Patient EthnicityPatient Primary Language Patient Multiple Birth IndicatorPatient Multiple Birth OrderPatient Birth Registration Number Patient Birth State/Country Patient Birthing FacilityMother’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/DateLast 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 AddressPatient Phone NumberPatient IdentifierPatient Birth Date Patient Sex



627628

629630631632


Data Requirement


Patient Race Patient EthnicityPatient Primary Language Patient Multiple Birth IndicatorPatient Multiple Birth OrderPatient Birth Registration Number Patient Birth State/Country Patient Birthing FacilityMother’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/DateLast 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 namelocationcliniciangeographic identifiersnon-geographic identifiersmanufacturerlot numberexpiration 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 locationcliniciangeographic identifiersnon-geographic identifiersmanufacturerlot numberexpiration 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



633634

635636637638


Data Requirement


Shipping/handling information data requirementsTemperature Storage conditionsBreakageHumidityAir qualitySee Countermeasure and Response Administration Campaign for additional detail

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

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

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

Table 8 Use Case Requirements and Associated Standards GapsRequire

ment Number

Summary Description Identified Gaps Recommended Resolution

DR17 Decision Support Data (immunization schedule)

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 schedulesThe 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



639640

267426752676

2677267826792680268126822683268426852686

26872688

2689

641642643644


Requirement

NumberSummary

Description Identified Gaps Recommended Resolution7.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 interimLook at what is in the text versions to identify the data element requirements

DR17 Decision Support Data (Immunization reminders)

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

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



645646

647648649650651652

http://www.OMG.org/


Requirement

NumberSummary

Description Identified Gaps Recommended Resolution7.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 interventionAction: 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 outThe 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 appropriateRefer 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 decisionsRefer 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

DR18DR19

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



653654

655656657658


Requirement

NumberSummary

Description Identified Gaps Recommended ResolutionDR23 Consumer

Vaccination View

Policy gap in standard requirements for consumer-facing communications of immunization data

DR18DR19


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

DR11DR76

Immunization response dataImmunization query data

7.1.2.1a Action: Identify individuals needing immunization or drug7.1.2.1b Alternative Action: Receive information about individuals needing prioritized intervention7.4.2.1 Action: Provide vaccine or drug administration information. 7.4.3.1 Action: Retrieve vaccine or drug administration information from external sources7.4.4.1 Action: Receive information describing the administration of a vaccine or drug7.3.2.1 Action: Request available immunization information7.2.1.1 Action: Conduct analysis to determine intervention priorities7.2.1.2 Action: Notify clinicians of individuals or population characteristics needing prioritized intervention8.2.2.1 Action: Receive and monitor inventory status information8.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 ISAlign 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

DR18DR19


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



659660

661662663664


Requirement

NumberSummary

Description Identified Gaps Recommended ResolutionDR16 Supply Chain

Management Vaccine RecallVaccine Recall (including consumer directed message)

7.1.6.1 Action: Receive vaccine recall information from registries7.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

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

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



665666

26902691269226932694269526962697

26982699

667668669670


Table 9 Use Case Requirements and Associated Standard OverlapsRequirement Number

Summary Description Standard Overlap

Recommended Resolution

DR11 Immunization response dataDR76 Immunization query data

Immunization Query and Response

7.1.2.1a Action: Identify individuals needing immunization or drug7.1.2.1b Alternative Action: Receive information about individuals needing prioritized intervention7.4.2.1 Action: Provide vaccine or drug administration information 7.4.3.1 Action: Retrieve vaccine or drug administration information from external sources7.4.4.1 Action: Receive information describing the administration of a vaccine or drug7.3.2.1 Action: Request available immunization information7.2.1.1 Action: Conduct analysis to determine intervention priorities7.2.1.2 Action: Notify clinicians of individuals or population characteristics needing prioritized intervention8.2.2.1 Action: Receive and monitor inventory status information8.3.1.1 Action: Monitor inventory usageHITSP/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 earlierVXQ/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 selectionWork 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



671672

2700

673674675676


Requirement Number

Summary Description Standard Overlap

Recommended Resolution

DR17 Decision Support Data

7.1.1.1 Action: Receive immunization schedules7.1.1.2 Action: Incorporate immunization schedules into the clinician’s EHR7.1.2.1a Action: Identify individuals needing immunization or drug7.1.2.1b Alternative Action: Receive information about individuals needing prioritized intervention7.1.3.2 Action: Record vaccine or drug administration information7.1.5.1 Action: Receive immunization schedules7.4.1.1 Action: Incorporate immunization schedules into the registry7.4.1.2 Action: Conduct analysis to determine intervention priorities7.2.1.1 Action: Identify individuals needing prioritized intervention9.4 Data provisioning – including support for secondary uses; data provisioning and distribution of data transmission parametersThere 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

IER54 Query/response for clinical message dataDR18

Immunization Query and ResponseVaccination Data

7.1.3.2 Action: Record vaccine or drug administration information7.1.4.1 Action: Report administration information to registries7.4.1.1 Action: Report administration information to registries7.4.2.1 Action: Provide vaccine or drug administration information7.4.4.1 Action: Receive information describing the administration of a vaccine or drug7.3.1.1 Action: Provide available immunization information via a personally controlled health recordVaccinationV2 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

2.8.2 Conformance Statements1. IMC messages are conformant with HITSP/C72 Immunization Message

specification2. IMC documents and services are compliant with:

o HITSP/C83 CDA Content Moduleso HITSP/ C80 Terminologyo HITSP/ C154 Data Dictionary.



677678

2701

2702270327042705270627072708

679680681682


o Manufactured vaccines are identified by either a Global Trade Identification Number (GTIN) or Drug Identification Number (DIN).

The CDC codes for immunizations and manufacturers http://www.cdc.gov/vaccines/programs/iis/stds/cvx.htm http://www.cdc.gov/vaccines/programs/iis/stds/mvx.htm

o The American Immunization Registry Association (AIRA) Immunization Information Systems Codebook: Guide to Code Sets and Data Definitions for Registry Data Sharing Using HL7 dated 06/03/2009, available at

http://www.immregistries.org/pubs/index.phtml o SNOMED-CT is used to represent "genericized" immunizing agents (e.g.

"MMR" vs. a GTIN for a specific manufacturer's MMR product 3. Standards gaps and overlaps are identified.

2.8.3 Discussion

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

2.9Platform-Independent Computation-Viewpoint

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

Use Case Specs Component specs Interface Specs Interaction Specs Collaboration Participations



683684

2709271027112712271327142715271627172718271927202721

272227232724272527262727272827292730273127322733273427352736

2737

2738273927402741274227432744274527462747274827492750

685686687688

http://www.immregistries.org/pubs/index.phtml

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

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


Collaboration Types Function Types Interface Types Collaboration Scripts Service Contracts

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

2.9.1 Service Interface Specification Types and Functional Group Types,

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



689690

2751275227532754275527562757275827592760

2761

2762276327642765276627672768

691692693694


Healthcare Unique Services

Business Services SOA Infrastructure Services

Business Line

Orde

r Ent

ry

Orde

r Ful

fillm

ent

Patie

nt

Eval

uatio

n (D

SS)

Labo

rato

ry D

ata

Retri

eval

Phar

mac

y Da

ta

Retri

eval

EHR

Aler

t/Eve

nt M

gmt

Mas

ter P

erso

n In

dex

Term

inol

ogy

Serv

ice

Dem

ogra

phic

s

Billi

ng

Sche

dulin

g

Audi

ting

Serv

ice

Exce

ptio

n M

gmt

Busi

ness

Pr

oces

s M

gmt

Auth

entic

atio

n

Serv

ices

Di

rect

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 XOrder Entry/Mgmt X X X X X X X X X X X X X XScheduling X X X X X X X X XRegistration 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 XReferrals/Referral Mgmt X X X X X X X X X X X X X X X X XNursing X X X X X X X X X X X X X X X X XEmergency Department X X X X X X X X X X X X X X X XPatient 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 XClinical Decision Support X X X X X X X X X X Facilities Management X X X X X XNutrition 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

Healthcare Unique Services

Business Services SOA Infrastructure Services

Business Line

Orde

r Ent

ry

Orde

r Ful

fillm

ent

Patie

nt

Eval

uatio

n (D

SS)

Labo

rato

ry D

ata

Retri

eval

Phar

mac

y Da

ta

Retri

eval

Imm

uniza

tion

Man

agem

ent

EHR

Aler

t/Eve

nt M

gmt

Mas

ter P

erso

n In

dex

Term

inol

ogy

Serv

ice

Dem

ogra

phic

s

Billi

ng

Sche

dulin

g

Audi

ting

Serv

ice

Exce

ptio

n M

gmt

Busi

ness

Pr

oces

s M

gmt

Auth

entic

atio

n

Serv

ices

Di

rect

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 XOrder Entry/Mgmt X X X X X X X X X X X X X X XScheduling X X X X X X X X XRegistration 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 XReferrals/Referral Mgmt X X X X X X X X X X X X X X X X X XNursing X X X X X X X X X X X X X X X X X XEmergency Department X X X X X X X X X X X X X X X X XPatient 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 XClinical Decision Support X X X X X X X X X X X Facilities Management X X X X X XNutrition Mgmt (Dietetics) X X X X X X X X X X X X X X X XImmunization 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



695696

2769

27702771

277227732774

697698699700


2.9.2 Use Cases and Business Level Interaction Diagrams

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

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

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

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

35 Immunization and Response Management (IRM), Detailed Use Case, U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, March 21, 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.



701702

2775

277627772778277927802781278227832784

27852786278727882789279027912792

2793279427952796279727982799280028012802

2803280428052806

703704705

706707708709710711


Information Exchanges

Figure 14 Immunization and Response Management Information ExchangesThe following information exchanges are key to the IRM use case, Vaccine and Drug Administration and Reporting Scenario:

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

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

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

4. Consumers provide available immunization information to clinicians5. Following administration of (or inability to administer) a vaccine or drug the

clinician provides appropriate clinical documentation to registries, consumers and others

6. Public health gathers information to identify individuals needing prioritized intervention

7. Public Health provides information to clinicians about populations or individuals having special needs for immunization or other intervention The Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 95 of 168

712713

2807

2808280928102811281228132814281528162817281828192820282128222823282428252826

714715716717


8. Registries provide information about vaccine recalls to clinicians and affected consumers

Information Exchange Requirements (IERs)IRM Information Exchange Requirements (IERs)37:

IER10 Identify patient IER13 Send/receive notification of document availability IER18 Send/receive clinical document IER26 Identify communication recipients IER27 Send non-patient notification message or alert IER40 Query for existing data IER42 Request/receive medical concept knowledge IER54 Query/response for clinical message data IER67 Send/receive clinical message IER78 Send/receive Vaccine Inventory Requirements IER79 Query/response for inventory usage data IER80 Send/receive Vaccine Inventory Data

NOTE: Blue Italics indicates IERs, which are common to 1-IRM and 2-PHCR

PHCR Information Exchange Requirements (IERs)38

IER10 Identify patient IER13 Send/receive notification of document availability IER18 Send/receive clinical document IER26 Identify communication recipients IER27 Send non-patient notification message or alert IER29 Send/receive electronic form for data capture IER40 Query for existing data IER42 Request/receive medical concept knowledge IER49 Report confirmation

HITSP Security and Privacy Information Exchange Requirements (IERs): IER01 Provide authorization and consent IER02 Send data over secured communication channel IER03 Create audit log entry IER04 Synchronize system time IER05 Verify entity identity IER06 Provide proof of document integrity and origin IER55 Anonymize patient identifiable data

37 See HITSP Interoperability Specification (IS) 10 Immunization and Response Management for details. It is available at www.HITSP.org3838 See HITSP Interoperability Specification (IS) 11 Public Health Case Reporting InteroperabilitySee HITSP Interoperability Specification (IS) 11 Public Health Case Reporting Interoperability Specification Immunization for details. It is available at www.HITSP.orgSpecification Immunization for details. It is available at www.HITSP.org



718719

282728282829

283028312832283328342835283628372838283928402841284228432844284528462847284828492850285128522853285428552856285728582859286028612862286328642865

720721

722723724725


IER56 Pseudonymize patient identifying information

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

Public Health Information System, EHR System, which contains the Immunization Information System (IIS)

component, PHR System, HIE System which provides Infrastructure Services (e.g., ESB).

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

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

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



726727

28662867

2868286928702871287228732874287528762877

2878287928802881

288228832884288528862887

28882889289028912892289328942895289628972898

728729730731


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

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



732733

289929002901

2902290329042905290629072908290929102911

734735736737


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

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



738739

291229132914

2915

29162917291829192920292129222923

740741742743


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


reserved.5/16/2010 Page 100 of

168

744745

292429252926

2927

746747748749750


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

2.9.3 Service Interaction Types and Collaboration Participations

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



168

751752

29282929

2930

2931

2932293329342935

753754755756757


Figure 19 As-Is SampleHealth Information System High Level Architecture

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 102 of 168

758759

2936

29372938

760761762


Figure 20 To-Be SampleHealth Information System High Level Architecture

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 103 of 168

763764

29392940

765766767


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

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

Figure 21 Mapping of Requirements to HITSP Constructs

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 dataDR76 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 dataDR76 Immunization query dataDR18 Vaccination data DR58 Demographic data – vaccinationDR23 Consumer vaccination view

HITSP/C83 – CDA Content Modules

DR18 Vaccination data DR58 Demographic data – vaccinationDR23 Consumer vaccination view



168

768769

2941

2942294329442945294629472948

294929502951

2952

770771772773774

775


Construct Name



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



168

776777

778779780781782

783


Construct Name



Number (DR#)HITSP/TP30 - Manage Consent Directives

IER1 Provide authorization and consent

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

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

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

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

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

Option 4 –The HITSP/C78 document can be communicated as a shared document to a document repository (HITSP/TP13) or sent to another provider o using document reliable interchange (HITSP/T31) or via media/email (HITSP/T33)

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

Option 6 – An Immunization Information System may optionally send an unsolicited notification using HITSP/C72 to a clinical information system to indicate that one of



168

784785

2953

295429552956295729582959

296029612962296329642965

296629672968296929702971297229732974297529762977297829792980298129822983298429852986298729882989

786787788789790

791


their patients has received an immunization from another clinician (e.g., Airport, school, another clinician)

Figure 22 Communicate Vaccinations

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

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

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



168

792793

29902991

2992

2993

2994299529962997

299829993000

3001300230033004

794795796797798

799


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

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

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



168

800801

3005300630073008300930103011301230133014301530163017

802803804805806

807


Figure 23 Immunization Query and Response

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

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



168

808809

3018

3019302030213022

30233024302530263027302830293030

810811812813814

815


FAX as specified by the implementation. Communication recipients may be identified using the Identify Communication Recipients (HITSP/T64) construct

Option 2 – Where the alert is generic and not specific to a particular patient (e.g., immunizations required for a particular population such as those over the age of 65) and the communication is text-based, the communication recipients are identified using the Identify Communication Recipients (HITSP/T64) construct, and the generic alert is sent to those providers using the Emergency Message Distribution Element (HITSP/T63) with the Emergency Common Alerting Protocol (HITSP/C82).

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

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



168

816817

3031303230333034303530363037303830393040304130423043304430453046304730483049

818819820821822

823


Figure 24 Vaccine and Drug Inventory Reporting

2.9.4 Service Collaboration Types

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



168

824825

3050

30513052

3053

30543055305630573058305930603061

826827828829830

831


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

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

Immunization SchedulesImmunization RemindersImmunization PrioritizationsContraindication AlertsActive/Passive Surveillance for Adverse eventsAll specification for Scenario 2 (Vaccine and Drug Inventory Reporting).

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

TBDFigure 25 Immunization Management Entities, Actions and Roles

Figure 26 Capability System RolesSystem 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,



168

832833

3062306330643065306630673068306930703071307230733074307530763077

3078

3079308030813082308330843085

3086308730883089309030913092

834835836837838

839


consumers, other registries and other 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.

Figure 27 defines each of the Information Exchanges supported by the proposed Immunization Management Capability in terms of the Exchange Action (EA) or Exchange Content (EC) used.



168

840841

30933094309530963097

842843844845846

847


Figure 27 Information Exchanges Mapped to External InterfacesInformation Exchange Identifier

Exchange Action Exchange Content

A** Send Immunization Schedules B Send Immunization InformationC Send Vaccine or Drug Administration InformationD Send Immunization InformationE Send Clinical Documentation

F** Send Public Health InformationG** Send Public Health Alert information H** Send Vaccine Recalls Information

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

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



168

848849

3098

309931003101

310231033104310531063107

850851852853854

855


Figure 28 Supported Information Exchanges 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

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



168

856857

3108

3109

311031113112311331143115311631173118

858859860861862

863


Figure 29 Information Exchanges Mapped to ConstructsInformation Exchange

Identifier Exchange Type Construct Identifier DescriptionA - 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 DocumentsHITSP/C78 - Immunization DocumentHITSP/C80 – Document and Message TerminologyHITSP/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 ResponseHITSP/TP13 - Manage Sharing of DocumentsHITSP/C78 - Immunization DocumentHITSP/C80 – Document and Message TerminologyHITSP/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 DocumentsHITSP/C78 - Immunization DocumentHITSP/C80 – Document and Message TerminologyHITSP/C83 – CDA Content Modules

Consumers provide available immunization information to clinicians



168

864865

3119

866867868869870

871


Information Exchange Identifier Exchange Type Construct Identifier Description

E - Send Clinical Documentation

Send HITSP/C72 - Immunization Message,HITSP/TP13 - Manage Sharing of Documents, HITSP/C78 - Immunization DocumentHITSP/C80 – Document and Message TerminologyHITSP/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

F - Send Public Health Information

Send HITSP/TP13 - Manage Sharing of Documents,HITSP/C78 - Immunization DocumentHITSP/C80 – Document and Message TerminologyHITSP/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 ProtocolHITSP/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 RecipientsHITSP/C62 - Unstructured Document

Registries provide information about vaccine recalls to clinicians and affected consumers

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

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

Construct Interface

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

OptionalityTBDTBDTBDTBD

Optionality Legend: “R” for Required, “O” for Optional, or “C” for ConditionalThe Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 117 of 168

872873

3120312131223123

31243125

3126874875876877878

879


Figure 31 Implementation ConditionsCondition

IDCondition Description

TBD

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

2.9.5 Service Contracts Parts

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

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

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

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

Participant operates and any applicable Federal law. For Federal Participants, this means applicable Federal law.

39 For more information see www.hhs.gov/healthit and search “DURSA”.The Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 118 of 168

880881

31273128

3129313031313132

3133

3134313531363137313831393140314131423143

3144314531463147314831493150

31513152315331543155

315631573158315931603161

882883884885886887

888

http://www.hhs.gov/healthit


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

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

Duty to Respond: Participants that allow their respective end users to seek data for treatment

purposes have a duty to respond to requests for data for treatment purposes. This duty to respond means that if actual data is not sent in response, the Participant

will at a minimum send a standardized response to the requesting Participant. Participants are permitted, but not required, to respond to all other (non-treatment)

requests. The DURSA does not require a Participant to disclose data when such a disclosure

would conflict with Applicable Law.

Future Use of Data Received Through the NHIN: Once the Participant or Participant’s end user receives data from a responding Participant (i.e. a copy of the responding Participant’s records), the recipient may incorporate that data into its records and retain that information in accordance with the recipient’s record retention policies and procedures. The recipient can re-use and re-disclose that data in accordance with all applicable law and the agreements between a Participant and its end users.

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

Duties of Requesting and Responding Participants: To effectively enable the exchange of health information in a manner that protects the privacy, confidentiality and security of the data, the DURSA adopts the HIPAA Privacy and Security Rules as minimum requirements. When a request is based on a purpose for which authorization is required under HIPAA (e.g. for SSA benefits determination), the requesting Participant must send a copy of the authorization with the request for data. Requesting



168

889890

3162316331643165316631673168

31693170317131723173

317431753176317731783179318031813182

3183318431853186318731883189

319031913192319331943195319631973198

319932003201320232033204

891892893894895

896


Participants are not obligated to send a copy of an authorization or consent when requesting data for treatment purposes.

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

specifications have a material impact on Participants.

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

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

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

Subcommittee hears the dispute and is encouraged to develop an appropriate and equitable resolution

NHIN Coordinating Committee can review the Subcommittee’s recommendation, if requested by any Participant involved in the dispute, and issue its own resolution

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



168

897898

32053206

3207320832093210321132123213321432153216

32173218321932203221

32223223322432253226322732283229

32303231323232333234323532363237323832393240

3241324232433244324532463247

899900901902903

904


Applicable Law. This section is not intended as a hold harmless or indemnification provision.

2.9.6 Conformance Statements The IMC specified information exchange requirements and their associated data

requirements are satisfied or gaps are identified and a transition plan is specified..

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

2.10 Platform-Independent Engineering-Viewpoint

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

Existing Platform models, Capabilities, Libraries and Versions.

2.10.1 Existing Platforms For SampleHealth the Platform-Independent Engineering-Viewpoint is defined by HSSP and NHIN Services to be:This viewpoint is primarily useful to enterprise architects. For SampleHealth the Conceptual Engineering-Viewpoint is defined by NHIN Connect to be:

Apache Tomcat (or Jakarta Tomcat or simply Tomcat) is an open source servlet container developed by the Apache Software Foundation (ASF). Tomcat implements the Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems, and provides a "pure Java" HTTP web server environment for Java code to run.

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



168

905906

32483249

3250325132523253

32543255325632573258

3259

32603261326232633264326532663267326832693270

32713272327332743275327632773278327932803281328232833284

907908909910911

912


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

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

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

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

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

.

2.10.2 Conformance Statements1. The NHIN CONNENT version 2.4 requirement for Apache Tomcat is met.2. The NHIN CONNENT version 2.4 requirement for JBoss Application Server is

met.3. The NHIN CONNENT version 2.4 requirement for J2SE, Java Platform,

Standard Edition is met.4. The NHIN CONNENT version 2.4 requirement for Eclipse Open Healthcare

Framework (OHF) is met.5. The NHIN CONNENT version 2.4 requirement for GlassFish ESB v2 is met. 6. The NHIN CONNENT version 2.4 requirement for GlassFish is met.



168

913914

32853286328732883289329032913292329332943295329632973298329933003301330233033304330533063307330833093310331133123313331433153316

3317331833193320332133223323332433253326

915916917918919

920

http://en.wikipedia.org/wiki/OpenAM

http://en.wikipedia.org/wiki/Federated_identity

http://en.wikipedia.org/wiki/New_I/O

http://en.wikipedia.org/w/index.php?title=Grizzly_(software)&action=edit&redlink=1

https://open-esb.dev.java.net/


7. The NHIN CONNENT version 2.4 requirement for OpenSSO is met. 2.10.3 Discussion

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

2.11 Platform-Specific Enterprise-Business-Viewpoint

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

Business Nodes Business Rules Business Procedures Business Workflow

2.11.1 Rules, Procedures and Industry Standards

SampleHealth’s Platform-Specific Views includes the following:Rules – SampleHealth IMC must meet the appropriate HITEC ARRA Meaningful Use Objectives and Criteria and must use NHIN CONNECT version 2.4 services.Procedures – SampleHealth IMC must present its exchange architecture interoperability specifications using the HL7 SAIF-ECCF.Industry Technology-Specific Standards – SampleHealth must use the appropriate HSSP services.

2.11.2 Conformance Statements1. Appropriate IMC HITEC meaningful use objectives and criteria are identified and

satisfied.2. The IMC exchange architecture interoperability specifications are

presented, using the HL7 SAIF-ECCF.3. IMC identifies and uses appropriate HSSP services.



168

921922

33273328

332933303331

3332

3333

3334333533363337333833393340334133423343334433453346334733483349335033513352335333543355

335633573358335933603361

923924925926927

928


2.11.3 Discussion

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

2.12 Platform-Specific Information-Viewpoint

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

Database Schemas Message Schemas Transformation Schemas

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

2.12.1 Schemas and Transformations

TBD

2.12.2 Conformance Statements TBD after architectural artifacts are completed and are sorted into the correct

ECCF categories.

2.12.3 DiscussionSampleHealth’s Platform-Specific Viewpoint s will be added between May and

September 2010,as the IMC prototype is being developed.

40 Conceptual Health Data Model v2.3, Canadian Institute for Health InformationThe Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 124 of 168

929930

3362

336333643365

3366

3367336833693370337133723373337433753376337733783379338033813382338333843385338633873388338933903391

33923393339433953396

931932933934935936

937


2.13 Platform-Specific Computation-Viewpoint 13. The ECCF Conceptual Computation-Viewpoint is defined by collaboration

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

Automation Unit Technical Interfaces Technical Operations Orchestration Scripts

2.13.1 Collaboration Scripts, Orchestration, Realized InterfacesTBD


ECCF categories. 2.13.3 Discussion

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

as the IMC prototype is being developed.

2.14 Platform-Specific Engineering-Viewpoint

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

Application Specifications GUI specifications Deployment Topology or Execution Context



168

938939

3397339833993400340134023403340434053406340734083409341034113412

3413341434153416

341734183419

3420

3421342234233424342534263427342834293430343134323433

940941942943944

945


Platform Bindings

2.14.1 Execution Context, Platform Bindings and Deployment



SystemsImmunization Management deals with the following systems:

Electronic Health Record (EHR) System: The Electronic Health Record (EHR) System is a secure, real-time, point-of-care, patient-centric information resource for clinicians

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

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

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

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

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

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

o Supported stakeholders are: Government Agencies, Healthcare Payors, Knowledge Providers, Public and Private Immunology, Vaccine Response,



168

946947

34343435343634373438343934403441

3442344334443445344634473448344934503451345234533454345534563457345834593460346134623463346434653466346734683469347034713472347334743475

948949950951952

953


and Adverse Event Experts, Registries, Public Health Agencies/ Organizations (federal/state/local/territorial/tribal)

Public Health Information System: An automated and integrated system used to document and address information of interest to public health. Local, state, and federal government organizations and personnel use these systems to help protect and improve the health of their respective constituents. A critical effort under this charge is collecting health information to monitor for the existence of emerging health threats appearing in the population and manage these threats once manifested. Staff of these agencies interacts with the public health information system to verify and validate system indications of public health threats, and to assert acknowledgements that may be required by system processes

o Supported stakeholders are: Consumers, Patients, Personal Health Record (PHR) System Suppliers

Supply Chain Management System: A system used by organizations managing the distribution of supplies and the oversight of materials, information, and finances as they move in a process from supplier to manufacturer to wholesaler to retailer to consumer. For example, used to track vaccines and associated supplies

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

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


ECCF categories. 2.14.3 Discussion



3 Conclusions and Lessons-LearnedWe believe that the resultant IMC ECCF presented above is a clear, complete, concise, correct, consistent and traceable exchange-architecture, Interoperability Specifications and Conformance Statements. The TOGAF ADM process and SAIF-ECCF structure were efficient for a distributed team to



168

954955

347634773478347934803481348234833484348534863487348834893490349134923493349434953496349734983499350035013502

3503350435053506

3507350835093510

35113512351335143515

956957958959960

961


develop interoperability specifications for the IMC exchange architecture, using the EHR-SD RM. The HL7 SAIF-ECCF might be considered the skeleton of an enterprise-architecture; ECCF was demonstrated to be an effective enterprise-architecture “Executive Summary”. The SD RM and its artifacts are evolving with the healthcare IT domain. Using the HL7 EHR-S FM, HITSP constructs and NHIN services as a reuse starting point was key to quickly filling out the IMC ECCF. The EHR SD RM facilitated the rapid identification of reusable architectural artifacts for the baseline IMC ECCF exchange architecture. Lessons learned from this case study are applicable to other processes (e.g., Rational Unified Process) and other frameworks (e.g., Zachman, DODAF).

A compelling story for the return-on-investment of SOA reuse can be told comparing:

Table 10 As-Is SampleHealth Business Function Map versus Table 11 To-Be SampleHealth Business Function Map

And then comparing: Figure 19 As-Is SampleHealth Information System High Level Architecture

versus Figure 20 To-Be SampleHealth Information System High Level

ArchitectureBoth of these pairs of as-is and to-be figures show the massive SOA reuse the IMC project benefited from; making the IMC project relatively simple compared to starting from scratch.

One of the most difficult challenges facing healthcare organizations making IT investments today comes from deciding whether to go all-in with a particular vendor, or whether to self-integrate components from multiple vendors. The appeal of the single-vendor solution is strong – no finger-pointing, out-of-the-box integration, [US-based] EHR certification via the Certification Commission for Healthcare IT (CCHIT), and so on. This is contrasted with seemingly increased risk and work involved in a multi-vendor solution involving integration. A multi-vendor SOA solution can offer compelling best-of-breed options; where, a SOA promotes an easier integration and alignment across suppliers into a cohesive, testable and certifiable architecture. We demonstrated an approach that can build and present consistent Interoperability Specifications (IS) and conformance criteria for both best-of-suite and best-of-breed components and their exchange architecture. Having these ISs, exchange architectures, certification criteria and associated business



168

962963

351635173518351935203521352235233524352535263527352835293530353135323533353435353536353735383539354035413542354335443545354635473548354935503551355235533554

964965966967968

969


cases is the appropriate due diligence needed to help justify a best-of-suite vs. best-of-breed decision.

The following lessons learned subsections are a living part of the document; they will periodically be reviewed and updated until the projects completion in October 2010.

3.1 Immunization Management Lessons Learned1. Updating Legacy System Standards - The HITSP selected Immunization

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

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

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

4. SOA and Cost - SOA changes the cost equation from N squared to a linear cost per interface

5. Reuse has been shown to increase quality and reduce cost.

3.2 ECCF Lessons Learned1. An ECCF SS can be presented as an “Architectural Executive Summary” or

“Information Exchange Architecture” to add value to a project. 2. A mature ECCF SS must be clear, complete, concise, correct, consistent and

traceable, as a whole. ECCF documentation is misleading by saying that viewpoints must be horizontally consistent and vertically traceable.

3. ECCF Viewpoint Conformance Statements – The ECCF would benefit by following the example of the EHR System Functional Model; statements, descriptions, “depends on” links and conformance statements for each viewpoint that is needed. Particular domains should have profiles, which subset the conformance statements to be suitable for the sub domains. Similarly, the governance framework, Information Framework would also benefit from this approach.

4. The ECCF placement of architectural artifacts is not always intuitively obvious (e.g., structural specifications of modules and their information). Arguable, many of the Table 5 artifacts might be in both the Enterprise and Computational Viewpoints, such as: Functional and non-functional Requirements



168

970971

355535563557355835593560

3561356235633564356535663567356835693570357135723573357435753576

35773578357935803581358235833584358535863587358835893590359135923593

972973974975976

977


Stakeholders and their roles and capabilities Use Case inventory and Use Case Specifications Capabilities and their Services Component inventory Function-Service inventory Contracts and business rulesStrict viewpoint traceability would require all of the above artifacts being in the Computational Viewpoint.

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

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

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

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

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

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

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



168

978979

35943595359635973598359936003601360236033604360536063607360836093610361136123613361436153616361736183619362036213622362336243625362636273628362936303631363236333634

980981982983984

985


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

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

The Enterprise Business Viewpoint was intuitive to fill out. The Information Viewpoint was intuitive to fill out. The Computation-Viewpoint was difficult to determine where structural

specifications, which show the encapsulation of information with functions to define components and capabilities.

The Engineering Viewpoint was intuitive to fill out; but, it was not obvious the distinction between the conceptual and platform-independent layers because we do not have a reference architecture for the engineering view.

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

3.3 SOA Lessons Learner1. Reuse of legacy services can make a project significantly faster, better and

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

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

3.4 TOGAF ADM Lessons Learned

1. As the TOGAF ADM implies, requirements, conformance statements, test specifications and risks should be managed/ governed throughout the Business Capability, Architecture and Software Development Lifecycles, as they evolve.

2. Methodologies must be adaptable to suite the needs of projects. In our case, we augmented HL7 SAIF with TOGAF ADM, DOD Instruction 5000.2



168

986987

363536363637363836393640364136423643364436453646364736483649365036513652365336543655

3656

365736583659366036613662366336643665

36663667366836693670367136723673

988989990991992

993


acquisition processes (e.g., governance) and HITSP’s TN903 Data Architecture (e.g., Clinical Information Model).

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

4 Acronym ListB2B: Business-to-BusinessBPMN: Business Process Management NotationBPEL: Business Process Execution LanguageCCD: Continuity of Care DocumentCDA: Clinical Document Architecture.CCR: Continuity of Care RecordCM: Configuration ManagementCRFQ: Clinical Research Filtered QueryCTS/CTS2: Common Terminology ServiceDSS: Decision Support ServiceEA: Enterprise ArchitectureED: Emergency DepartmentEHR: Electronic Health RecordEIS: Entity Identification ServiceESB: Enterprise Service BusHL7: Health Level SevenHSD: Human Services DirectoryHSSP: Healthcare Services Specification ProjectOMG: Object Management GroupPASS: Privacy, Access, Security Services RLUS: Retrieve, Locate, Update ServiceSOA: Service-oriented Architecture

5 GlossaryA glossary of architectural terms is provided in Section 2.2.4. Following is the glossary for the main body of the document.

TBD



168

994995

36743675367636773678367936803681

36823683368436853686368736883689369036913692369336943695369636973698369937003701370237033704

370537063707370837093710

996997998999

1000

1001


6 ReferencesTBD

7 Appendix7.1 Background..................................................................................................111

7.1.1 Service Oriented Architecture (SOA)................................................1117.1.2 EHR System Functional Model (EHR-S FM).....................................1137.1.3 Healthcare SOA Reference Architecture (H-SOA-RA)......................1167.1.4 Reference Information Model (RIM).................................................1177.1.5 Federal Health Information Model (FHIM).......................................1187.1.6 Healthcare Service Specification Project (HSSP).............................1207.1.7 Service Aware Interoperability Framework (SAIF)..........................1217.1.8 Integrating the Healthcare Enterprise (IHE)....................................1227.1.9 EHR System Design Reference Model (EHR-SD RM).......................1237.1.10 Health Information Technology Standards Panel (HITSP)...............1257.1.11 Certification Commission for Health Information Technology (CCHIT)

1277.1.12 National Information Exchange Model (NIEM)................................1287.1.13 Nationwide Health Information Network (NHIN).............................1297.1.14 Universal Immunization Tracking System (UITS).............................130

7.2 TOGAF Architecture Development Method (ADM).................................1317.2.1 Preliminary........................................................................................1327.2.2 A – Architecture Vision......................................................................1337.2.3 B – Business Architecture.................................................................1347.2.4 C – Information Systems Architecture..............................................1347.2.5 D – Technology Architecture.............................................................1357.2.6 E – Opportunities and Solutions........................................................1367.2.7 F – Migration Planning......................................................................1367.2.8 G – Implementation Governance.......................................................1377.2.9 H – Architecture Change Management.............................................138

7.1 BackgroundThe EHR-SD RM prototype example is based on HL7-OMG HSSP, HL7 EHR-S FM, HL7 RIM, HL7 SAIF, HITSP and IHE artifacts.

7.1.1 Service Oriented Architecture (SOA)This section is based on Thomas Erl’s “SOA Principles of Service Design” July 28, 2007, Prentice Hall. SOA is “A technology architecture Design Paradigm which can be applied in the context of Distributed Computing which collectively expresses a set of core Design Principles which collectively realize a set of Design Characteristics?” -- [Thomas Erl, “SOA Principles of Service Design.”] Semantics are critical to interoperability in the domain of healthcare, which often requires computable semantic interoperability.



168

10021003

37113712

3713

371437153716371737183719372037213722372337243725372637273728372937303731373237333734373537363737373837393740

3741374237433744

3745374637473748374937503751

10041005100610071008

1009


SOA Strategic Goals [Thomas Erl] are: Intrinsic Interoperability

– Interoperability vs. Integration Increased Federation

– Common endpoint and local governance Increased business/technology alignment

– Linear “degree of difficulty” for change Increased vendor neutrality options

– Specifications at a logical level (ECCF PIM)

SOA Strategic Benefits are: Increased ROI

– Reuse vs inconsistent Redundancy– Applications as “compositional aggregations”

Increased Organizational Agility– Business evolution aligned with technology flexibility

Reduced IT footprint– Elimination of redundancy and inconsistency– Elimination of one-off integration activities– Decreased governance burden

SOA Design Principles are: Standardized Service Contracts Service Loose Coupling Service Abstraction Service Reusability Service Autonomy Service Statelessness Service Discoverability Service Composability

Intrinsic Inter-

operability

IncreasedFederation

IncreasedBusiness/Technology

Alignment

IncreasedVendor

Diversification Options

IncreasedROI

IncreasedOrganiza-

tional Agility

DecreasedIT 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

ServiceReusability

X X X X X

Service X X X X X X



168

10101011

37523753375437553756375737583759376037613762376337643765376637673768376937703771377237733774377537763777377837793780378137823783

10121013101410151016

1017


AutonomyService

StatelessnessX 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

SOA Challenges are: increased design complexity need for Design Standards (informational, behavioral) top-down delivery requirements “counter-agile” (contract-first) design/delivery governance requirements

SOA Benefits are: Advantages gained from SOA: users will realize benefits from the solution to

each aspect of the Problem Statement:…– focus on business capabilities à increased agility– fine-grained certification à increased predictability and reliability– automated certification à increased responsiveness to change and

evolution of software components– technology-independent specifications à increased vendor participation

and cross-vendor interoperability

Road Map to sSOA via SAIF/ECCF: Some things will evolve:

– Static data, metadata, terminology representations, and tooling– Application development from monolithic to service composition– Increased emphasis on enterprise architecture– Increased emphasis on Continuous Integration

Some things will be new:– Behavioral metadata that is defined and captured– Artifacts that define ECCF Specification Stack instances– Increased emphasis on automated testing/certification– Tooling to support new data/metadata and processes– Focus on software contracts as basis for Computable Semantic

Interoperability (CSI)– Formal requirements traceability– Formal project and architecture governance– Some aspects of software engineering process– Some aspects of contracts for development organizations



168

10181019

378437853786378737883789379037913792379337943795379637973798379938003801380238033804380538063807380838093810381138123813381438153816381738183819

10201021102210231024

1025


7.1.2 EHR System Functional Model (EHR-S FM)

HL7 traditionally develops standards around messaging and interoperability. However, in July 2003 it collaborated with public and private healthcare leaders to develop the EHR functional standard. In May 2004 Health Level Seven (HL7), an ANSI-accredited designated standards organization, announced passage of the electronic health record system (EHR-S) draft standard for trial use (DSTU). In 2007 Electronic Health Record System Functional Model became a Normative Standard (ANSI-approved). This draft standard summarizes the functions that may be present in an EHR system and provides a common language for communicating its behaviors and capabilities. The EHR-S FM’s scope is limited to functionality and does not address data content for the EHR or endorse the use of specific technology. An EHR-S could be one system with applicable functionality in the EHR-S FM standard, or it could be a variety of interoperable systems that combine to meet the functionality of the EHR-S FM. An EHR is the data content contained within the EHR system.

Figure 32 HL7 EHR System Functional Model (EHR-S FM)



168

10261027

3820

3821382238233824382538263827382838293830383138323833

38343835

10281029103010311032

1033


Figure 32 HL7 EHR System Functional Model (EHR-S FM) shows the EHR-S FM structure, which contains more than 160 hierarchically categorized functions. They are broken into three main sections:

Direct care Supportive Information infrastructure

Each function is assigned an ID and includes a title, a short statement, and a longer narrative describing the functionality. The example below illustrates the format of the EHR-S functional model.

EDITORS NOTE: use DC1.8.2 Immunization Management example here, rather than DC1.1.4.

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.1IN.1.9IN.2.4IN.2.5.1IN.2.5.2

Each system function may also indicate dependencies on other functions (“see also”) and conformance criteria, such as:

DC.1.1.4 Conformance Criteria:1. The system SHALL present summarized views and reports of the patient’s comprehensive EHR. 2. The system SHOULD include at least the following in the summary: problem list, medication list, allergy and adverse reaction list. 3. The system SHOULD conform to function S.3.3.6 (Health Service Reports at the Conclusion of an Episode of Care). 4. The system SHOULD conform to function IN.1.4 (Patient Access Management).



168

10341035

383638373838

383938403841

384238433844

3845

3846

3847

3848

38493850

3851

3852385338543855385638573858

10361037103810391040

1041


5. The system SHALL conform to function IN.2.2 (Auditable Records).

For a particular function, the conformance criteria should be collected across all of its dependencies, resulting in a comprehensive set of functional requirements and test specifications.

Functions are outlined in a hierarchical manner; for example:

DC.1.2—Care plans, guidelines, and protocols (This is the “parent” function. Additional related functions are listed below as “children.”)

DC.1.2.1—Present care plans, guidelines, and protocols (child function) DC.1.2.2—Manage guidelines, protocols, and patient-specific care plans (child

function) DC.1.2.3—Generate and record patient-specific instructions (child function)

The direct care section of the functional model addresses functionality related to the care delivery process under three main headings:

DC.1 Care Management DC.2 Clinical Decision Support DC.3 Operations Management and Communication

The direct care section is comprised of parent functions, with children functions that provide more detail and granularity. The table identifies the main functions and then summarizes the functionality within the section.

The supportive section of the EHR-S FM addresses functionality related to administrative and financial requirements associated with care delivery. It includes support for medical research, public health, and quality improvement. There are three main sections:

S.1 Clinical Support S.2 Measurement, Analysis, Research, Reporting S.3 Administrative and Financial

Most, but not all, of the functions in the supportive section have both parent and child sub-functions.

The information infrastructure section of the EHR-S FM addresses functionality related to technical capabilities that are essential to support operations and the direct care functions. There are seven main sections:

I.1 EHR Security I.2 EHR Information and Records Management I.3 Unique Identity, Registry, and Directory Services



168

10421043

38593860386138623863

3864

3865386638673868386938703871

38723873

387438753876

387738783879

3882388338843885

388638873888

38893890

389138923893

389438953896

10441045104610471048

1049


I.4 Support for Health Informatics and Terminology Standards I.5 Interoperability I.6 Manage Business Rules I.7 Workflow

Most of the functions in the seven sections include both parent and child functions.

7.1.3 Healthcare SOA Reference Architecture (H-SOA-RA)In 2008, the Figure 33 Healthcare SOA Reference Architecture (H-SOA-RA) based on the Figure 32 HL7 EHR System Functional Model (EHR-S FM) and the ISO 7498-1 layers [ISO/IEC 7498-1 Information technology – Open Systems Interconnection – Basic Reference Model: The Basic Model]. The H-SOA-RA supports a structured reuse-based approach to architectural specifications within the healthcare domain and across domains, which intersect the healthcare domain (e.g., emergency responder). It also provides a common vocabulary, to discuss requirements traceability to design specifications, to implementations, to deployments, to tests and to certifications; with the aim to encourage lexical and semantic consistency throughout the Business Capability Lifecycle (BCL).

The Healthcare SOA Reference Architecture (H-SOA-RA), was built on commercial healthcare models (e.g., HL7 EHR System Functional Model (EHR-S)) and ISO based SOA layers [SOA Principles of Service Design by Thomas Erl 2007]. The objective of the H-SOA-RA is to assure semantic interoperability at the Service Level and consistency within and among systems’ architectural interoperability specifications, resulting in aligned, interoperable and agile enterprise architectures and their system components. The H-SOA-RA allows logical specifications of business transformation architectures and their associated investment portfolios; it allows system component flexibility/options in the ultimate physical “best-of-breed component” implementations.



168

10501051

3897389838993900

3901

39023903390439053906390739083909391039113912

391339143915391639173918391939203921

10521053105410551056

1057


Figure 33 Healthcare SOA Reference Architecture (H-SOA-RA)The H-SOA-RA is intended to support the transformation of a behavior model’s systems and their capabilities (e.g., business process model or use case) into system structural models of components and their interfaces (e.g., system functions and services). In particular the H-SOA-RA focuses on constructing system components from candidate reusable services (e.g., composite services, entity services, application services, agnostic or common services.). Healthcare Information Technology Standards Panel (HITSP) constructs (e.g., data components, transaction packages, transactions and their associated standards specifications) provide architectural constraints, which are intended to assure Electronic Healthcare Record (EHR) interoperability.

7.1.4 Reference Information Model (RIM)The purpose of a Reference Information Model is to share consistent meaning beyond a local context. In general, the broader the scope of interest, the more important it is to make all assumptions about a topic of interest explicit. The HL7 Version 3 Reference Information Model (RIM) is a comprehensive source of all information subjects used in any HL7 specification.



168

10581059

39223923

392439253926392739283929393039313932

393339343935393639373938

10601061106210631064

1065


Since HL7 specifications permit loosely coupled information systems to interoperate, the scope of the HL7 RIM is the information required to be understood between information systems, but not necessarily all information recorded within any particular system. As HL7 specifications are used to connect information systems operated in different circumstances, across many types of healthcare delivery organizations and potentially across political jurisdictions, the HL7 RIM needs to be flexible enough to express a diverse range of information content while maintaining a unified framework.The Version 3 RIM articulates explicit definitions of the things of interest referenced in HL7 messages, structured documents or any future HL7 "information packages" specification. The RIM also contains definitions of the characteristics of these things of interest and the relationships among them.

Figure 34 HL7 Reference Information Model (RIM)The Reference Information Model is expressed using a modified object notation similar to that used in UML. The RIM is graphically presented as a network of classes containing their attributes and connected by their associations. Behind the graph are the details of all the definitions, connections and constraints. All information about the RIM is held in a repository that contains the details, the connections among the details and the changes over time.



168

10661067

39393940394139423943394439453946394739483949

39503951395239533954395539563957

10681069107010711072

1073


The HL7 RIM is not a model of a database, or any particular vendor's information system, or any particular healthcare organization enterprise, or even any particular set of messages. Any of these specific contexts may have an information model of their own and can use a similar form of notation.

7.1.5 Federal Health Information Model (FHIM)The Federal Health Architecture (FHA) sponsored Federal Health Information Model (FHIM) work group directs and coordinates federal engagement in health IT SDOs and other IT standards related organizations. The goal of the work group is to enable health information interoperability by participating in the development and implementation of a comprehensive, integrated health information model and set of standards that support the semantic interoperability requirements of ARRA.

• The HL7 Reference Information Model (RIM) is leveraged as a reference model for the FHIM

• The FHIM is a comprehensive, integrated, logical, health information model and associated terminology models.

• The FHIM includes the HITSP/ TN903 Data Architecture• To support the exchange of health information between Federal

partners• To standardize the exchange of health information between Federal

partners and their commercial partners as NIEM IEPDs.• Supports the consolidation of information exchange formats from the

existing (and expanding) 8-9 to 3 or possibly even 1 in the long-term• Enables implementation of Service Oriented Architectures by Federal

partners• Reduces the amount of mapping between different information concepts,

information attributes and terminologies/code sets that Federal partners must currently support

• Identifies terminology and code set requirements that have not yet been addressed

• Improves harmonization of information concepts and attributes across standards development organizations

• The FHIM supports health interoperability, especially semantic interoperability• As the basis for work between Federal partners and standards related

organizations to enhance existing or develop new standards• As the basis for defining information requirements for inclusion in vendor

contracts• As the basis for defining information requirements for in-house developed

applications and databases, especially in organizations implementing model-driven architectures

• As a component of the Data Use and Reciprocal Support Agreement (DURSA) among trading partners and their service contracts



168

10741075

3958395939603961

3962396339643965396639673968396939703971397239733974397539763977397839793980398139823983398439853986398739883989399039913992399339943995399639973998

10761077107810791080

1081


• The FHIM is built by harmonizing information from the individual Federal partners and from standards organizations.

• The FHIM has the potential to become the Federal Health Architecture information model for NIEM and NHIN.

Figure 35 FHIM relationship to NIEM

7.1.6 Healthcare Service Specification Project (HSSP)The Healthcare Services Specification Project (HSSP) project is a collaborative effort between Health Level Seven [http://www.hl7.org] and the Object Management Group [http://www.omg.org] to address interoperability challenges within the healthcare sector and to identify and document service specifications, functionality, and conformance resulting in real-world implementations.

The following Candidate HSSP Services will be considered within this interoperability specification:



168

10821083

3999400040014002400340044005400640074008

400940104011

401240134014401540164017401840194020

10841085108610871088

1089

http://www.omg.org/

http://www.hl7.org/


CTS2 (Common Terminology Services 2) CTS 2 is a standard for terminology services that enhances the capabilities of the initial CTS specification for sub-setting and mapping, and extends the specification into domains such as terminology distribution, versioning, and classification.

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

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

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

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

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

7.1.7 Service Aware Interoperability Framework (SAIF)The collective work of the HL7 Architecture Board (ArB) is called the HL7 Services-Aware Interoperability Framework (HL7 SAIF41). We note that SAIF is NOT an enterprise architectural framework; but rather, SAIF is an interoperability framework. The goal of SAIF is to ensure interoperability among various healthcare organizations. Medical and healthcare organizations using different technologies, software, and business structures need a common framework for sharing documents, messages, and services with other organizations. An example of a document might be an invoice or a doctor's report. An example of a service might be a request for a lab order or a patient's longitudinal health record. Often these organizations are unable to share the information because the different systems do not interoperate with each other, which may likely increase delays and expenses. For a long time, HL7 has been developing specifications, methodologies, and extensible standards for making healthcare systems interoperable. HL7 collaborates with healthcare information users and other Standards Development Organizations, and enables domain experts from the healthcare industry to develop healthcare information standards in their areas of expertise.41 http://www.hl7.org/permalink/?SAIF



168

10901091

4021402240234024402540264027402840294030403140324033403440354036403740384039404040414042404340444045

4046404740484049405040514052405340544055405640574058405940604061

109210931094109510961097

1098

http://www.hl7.org/permalink/?SAIF

http://hssp-rlus-rfpsubmission.wikispaces.com/

http://hssp-rlus-rfpsubmission.wikispaces.com/

http://hssp-security.wikispaces.com/

http://hssp.wikispaces.com/EIS+Normative+Ballot

http://hssp.wikispaces.com/EIS+Normative+Ballot

http://hssp-provider-services-directory.wikispaces.com/

http://hssp-dss.wikispaces.com/

http://hssp.wikispaces.com/cts2


SAIF seeks to meet this need by providing a framework for ensuring interoperability for documents, messages, and services between organizations. SAIF is designed not only to craft software components -- messages, computable documents, services, and applications -- that are usable in the healthcare, life sciences, and clinical research domains, but also to facilitate and enable efficient lines of communications between the various cross-functional teams.

The SAIF satisfies the following principles/ criteria: Applies to each of HL7's three interoperability paradigms (IPs): messages,

documents, and services. Provides support for measurable conformance and compliance. Defines appropriate governance structures and processes. Provides support for directly implementable solutions. Addresses the growing disparity between the various solution sets emerging from

HL7 Uses existing HL7 V3 and Reference Information Model (RIM) artifacts and expertise

to the maximum degree possible.

SAIF consists of four core components: Enterprise Conformance and Compliance Framework (ECCF) Governance Framework (GF) Behavioral Framework (BF) Information Framework (IF)

Together, these sub-frameworks provide an overarching framework for specifying (and governing the specification of) the set of artifacts that enables HL7 to develop specifications which support Working Interoperability (WI) among parties using HL7 specifications, either alone, or with other specifications that other organizations have developed. The ECCF, shown in Table 13 below, shows a prototypic ECCF specification stack (SS) template with example artifacts in each cell. It is based on the ISO Reference Model of the Open Distributed Processing (RMODP) and extends the historical work within HL7 on conformance. The BF formalizes and extends the constructs of the HL7 Dynamic module to include explicit semantics around contracts and integration. The IF is an extension of the HL7 Reference Information Model (RIM), shown in Figure 34 above.



168

10991100

4062406340644065406640674068406940704071407240734074407540764077407840794080408140824083408440854086408740884089409040914092409340944095409640974098

11011102110311041105

1106


Table 13 HL7 SAIF Enterprise Conformance and Compliance Framework (ECCF)

7.1.8 Integrating the Healthcare Enterprise (IHE)Integrating the Healthcare Enterprise (IHE) is an initiative by healthcare professionals and industry to improve the way computer systems in healthcare share information. IHE promotes the coordinated use of established standards such as DICOM and HL7 to address specific clinical needs in support of optimal patient care. Systems developed in accordance with IHE communicate with one another better, are easier to implement, and enable care providers to use information more effectively.

IHE brings together users and developers of healthcare information technology (HIT) in an annually recurring four-step process:

1. Clinical and technical experts define critical use cases for information sharing.2. Technical experts create detailed specifications for communication among

systems to address these use cases, selecting and optimizing established standards.

3. Industry implements these specifications called IHE Profiles in HIT systems.



168

11071108

40994100

410141024103410441054106410741084109411041114112411341144115

11091110111111121113

1114


4. IHE tests vendors’ systems at carefully planned and supervised events called Connectathons.

7.1.9 EHR System Design Reference Model (EHR-SD RM)HL7 EHR System Design Reference Model (EHR-SD RM)42 project expands the H-SOA RA; but still starts with the EHR System Functional Model (EHR-S FM). Emphasis is placed on mapping to ARRA HITECH standards and meaningful use measures, HITSP ISs, NIEM IEPDs, and CCHIT conformance criteria.

Figure 36 EHR-SD RM Leveraging Standards Related Organizations To Get the Right Information to the Right Analyst at the Right Time

Reference architectures generally have lists of: 1) System Functions or Services (aka, methods),2) Reusable components composed of one or more encapsulated objects and3) Policies, standards and constraints.

In a constrained system design (e.g., net-centric43 Service Oriented Architecture (SOA)), reference architectures can be used to allocate capabilities and their system functions to system components, while maintaining architectural constraints, resulting in a design baseline.

Reference architectures can be defined at different levels of abstraction: - A deployment reference-architecture might show different pieces of equipment on a

communications network, each component providing gross functionality (e.g., Application Server, Database Server, Master Patient Index, etc.).

- A business reference-architecture decomposes business-process views, which show persons, organizations and systems; it includes the information exchanges within and among business processes. Our approach is to have the H-SOA-RA constrain the functions, which are allocated to systems.

- An inheritance reference-architecture might include functions, which can be constructed into system components.

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.



168

11151116

411641174118

41194120412141224123

412441254126

4127412841294130

4131413241334134

41354136413741384139414041414142414341444145

1117111811191120112111221123112411251126

1127

http://hssp.wikispaces.com/Reference+Architecture


Federal Agencies are mandated to have Healthcare Information Technology Standards Panel (HITSP) conformant interoperable Electronic Healthcare Records (EHR) and systems. Our strategy is to focus on HITSP conformant interoperability at the service level.

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

requirementsdesign

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

Figure 37 Conceptual View of the HL7 EHR System Design Reference Model

Figure 37 Conceptual View of the HL7 EHR System Design Reference Model shows how a user can start with functions (EHR-S FM) or data (e.g., RIM), requirements and behavioral specifications (e.g., use cases) to define capabilities and information exchanges, which can be allocated to systems and their standards-based interfaces,; the interoperable interfaces can be implemented as services.

EHR-SD RM within the Requirements Management and Architecture CycleThe EHR-SD RM supports the requirements, specifications, design and test processes as is shown in Figure 38

Stakeholder Requirements answer the questions WHAT is the system supposed to do? WHERE will the products of the system be used? Under what conditions are



168

11281129

41464147414841494150

41514152415341544155415641574158

41594160416141624163

11301131113211331134

1135


the products used? How often does the system produce its products? How long does it take to produce the products? Who will use the products of the system?

Requirements Analysis answers the questions HOW, using “Action Verbs”. In this step we analyze functions and Services by decomposing higher level functions to lower level functions and Allocating performance requirements to the functions.

Architecture Design answers the questions of WHICH hardware and software elements define the physical architecture, WHERE each part must perform at least one function and some parts may perform more than one function.

Test Specifications answer the question of HOW Requirements-Specifications are validated.

The Requirements Loop ensures that all requirements are covered by at least one function and it ensures that all functions are justified by a valid requirement (no unnecessary duplication).

The Design Loop ensures that all functions are covered by at least one hardware or software element and it also ensures that all elements of the physical architecture are justified by a valid functional requirement (no unnecessary duplication).

The Verification & Validation (V&V) Loop verifies that that the solution meets the requirements and validates that the solution meets the user’s needs and expectations. Note that V&V can be accomplished by: Inspection, Analysis, Demonstration or Test.

The Test Loop ensures that all information is covered by test specifications and it also ensures that all interfaces are covered by test specifications.



168

11361137

416441654166416741684169417041714172417341744175417641774178417941804181418241834184418541864187

11381139114011411142

1143


Figure 38 EHR-SD RM Supporting Requirements and Architecture Processes

7.1.10 Health Information Technology Standards Panel (HITSP)The Healthcare Information Technology Standards Panel (HITSP) was a cooperative partnership between the public and private sectors from December 2005 through 30 April 2010. The Panel was formed for the purpose of harmonizing and integrating standards that will meet clinical and business needs for sharing information among organizations and systems.

The Figure 39 HITSP Harmonization Process was defined to transform interoperability requirements into an Interoperability Specification (IS) and related artifacts (called constructs) that were collectively called an IS Package as shown in Figure 40. In HITSP, an IS assembles constructs to define the secure message, document and service infrastructure (transport together with secure and private transport mechanisms), information content, vocabulary, and constraints for each Information Exchange (IE) needed to address an interoperable business need and use case that articulated the requirements to reorganize its specifications to more clearly portray how they addressed HITECH requirements. The HITSP Data Architecture, Service Collaborations, and Capabilities were established as part of the effort to match HITSP results to HITECH, simplify reuse, and more rigorously separate transport and content. The Data Architecture organizes the data dictionary, vocabulary, and constraints (value sets and



168

11441145

41884189

4190419141924193419441954196419741984199420042014202420342044205420642074208

11461147114811491150

1151


templates). Service Collaborations assembled HITSP constructs into secure infrastructure definitions. Capabilities addressed reusable business process chunks (such as patient registration), using Service Collaborations to specify the secure infrastructure and components to specify the information content. Figure 41 Fundamental Interoperability Relationships depicts the interrelationships of the requirements and design sections of the IS. Stakeholders’ Information Exchange Requirements (IERs) are met with System software Capabilities (CAP), which group the IERs into System Roles and their standards-based interface design specifications.

Figure 39 HITSP Harmonization Process

Figure 40 HITSP Document Architecture

Figure 40 HITSP Document Architecture portrays the HITSP constructs that were used to address a use case. Built on base (e.g. HL7, SNOMED-CT) and composite standards (e.g. IHE Integration Profiles), HITSP components defined the information content, while transactions and transaction packages defined the transport as well as security and privacy mechanisms. In response to HITECH, ONC asked HITSP to reorganize its specifications to more clearly portray how they addressed HITECH requirements. The HITSP Data Architecture, Service Collaborations, and Capabilities were established as part of the effort to match HITSP results to HITECH, simplify reuse, and more rigorously separate transport and content. The Data Architecture organized the data dictionary, vocabulary, and constraints (value sets and templates). Service Collaborations assembled HITSP constructs into secure infrastructure definitions. Capabilities addressed reusable business process chunks (such as patient registration),



168

11521153

420942104211421242134214421542164217

421842194220

422142224223422442254226422742284229423042314232423342344235

11541155115611571158

1159


using Service Collaborations to specify the secure infrastructure and components to specify the information content. Figure 41 Fundamental Interoperability Relationships depicts the interrelationships of the requirements and design sections of the IS. Stakeholders’ Information Exchange Requirements (IERs) are met with System software Capabilities (CAP), which group the IERs into System Roles and their standards-based interface design specifications.

Figure 41 Fundamental Interoperability Relationships

7.1.11 Certification Commission for Health Information Technology (CCHIT)

Improvements in quality, safety, efficiency and access, which are key goals in today’s national dialog on health reform, are also the goals which drive the Certification Commission for Health Information Technology (CCHIT®), a nonprofit, 501(c)3 organization with the public mission of accelerating the adoption of health IT.

Founded in 2004, and certifying electronic health records (EHRs) since 2006, the Commission established the first comprehensive, practical definition of what capabilities were needed in these systems. The certification criteria were developed through a voluntary, consensus-based process engaging diverse stakeholders, and the Certification Commission was officially recognized by the federal government as a certifying body.

Uptake by the health IT industry was rapid, with more than 200 EHR products certified by mid-2009, representing over 75% of the marketplace. Provider organizations endorsed the work as well. Based on this broad acceptance, healthcare payers and purchasers in the government and private sectors began offering incentives to providers for adopting certified EHR technology. In February 2009, Congress acknowledged the value of certification in the language of the American Recovery and Reinvestment Act (ARRA) aimed at stimulating the nation’s



168

11601161

423642374238423942404241

4242

4243

424442454246424742484249425042514252425342544255425642574258425942604261426242634264

11621163116411651166

1167


economy. The law offers a multi-year series of incentive payments to providers and hospitals for the meaningful use of certified EHR technology. The total amount of payments has been projected by the Congressional Budget Office at $34 billion. Anticipating a massive response to the new incentives, CCHIT has broadened access to certification, offering three paths to certification instead of just one. The new paths are intended to bring wider availability of EHR technologies, stimulate innovation, and address the needs of providers and hospitals at varying stages of technology adoption readiness. They are:

CCHIT Certified®, an independently developed certification that includes a rigorous inspection of an EHR’s integrated functionality, interoperability and security. Products that are CCHIT Certified® are tested against criteria developed by the Commission’s broadly representative, expert work groups. This program is intended to serve health care providers looking for maximal assurance that a product will meet their complex needs. As part of this independent evaluation, successful use is verified at live sites and product usability is rated.

Preliminary ARRA, a certification program that tests Complete EHRs or EHR Modules against the Meaningful Use Stage 1 certification criteria in the Interim Final Rule (IFR) issued by the Office of the National Coordinator (ONC), US Department of Health and Human Services (HHS) in January 2010. The Preliminary ARRA program is designed to demonstrate that a vendor’s product is extremely well prepared to be certified once ONC-accredited testing and certification becomes available, but the final criteria and test procedures are not yet available, nor has CCHIT been accredited yet by ONC. When those events occur, CCHIT will replace the Preliminary ARRA program with a final, ONC-accredited ARRA certification program.

In addition to these product certifications, later this year, CCHIT has plans to offer a Site certification - a simplified, low cost certification for sites or organizations. Technology must meet minimum federal standards requirements once they are finalized. This program allows providers and hospitals who develop or assemble EHR technologies themselves to qualify for ARRA incentives, offering an open door to encourage continued innovation.

7.1.12 National Information Exchange Model (NIEM)

NIEM, the National Information Exchange Model, is a partnership of the U.S. Department of Justice and the Department of Homeland Security. It is designed to develop, disseminate and support enterprise-wide information exchange standards and processes that can enable jurisdictions to effectively share critical information in emergency situations, as well as support the day-to-day operations of agencies throughout the nation.



168

11681169

42654266426742684269427042714272427342744275427642774278427942804281428242834284428542864287428842894290429142924293429442954296

4297

429842994300430143024303

11701171117211731174

1175


NIEM enables information sharing, focusing on information exchanged among organizations as part of their current or intended business practices. The NIEM exchange development methodology results in a common semantic understanding among participating organizations and data formatted in a semantically consistent manner. NIEM will standardize content (actual data exchange standards), provide tools, and managed processes. NIEM builds on the demonstrated success of the Global Justice XML Data Model. Stakeholders from relevant communities work together to define critical exchanges, leveraging the successful work of the Global Justice XML Data Model (GJXDM)

Today, the NIEM domain does not include healthcare; but, the HHS Office of the National Coordinator (ONC) plans to leverage many of the existing tools and resources from the National Information Exchange Model (NIEM) and develop a NIEM-like process for the health care domain. Leveraging the tools and resources available in the NIEM process will help each new use case to build on previous use cases and relevant standards as well as help build the repository for all stakeholders.

Figure 42 ONC Standards and Interoperability Framework ProcessFigure 42 shows the proposed HHS process to develop NIEM compliant Information Exchange Package documents. Through this process ONC would like to develop not only data interchange specifications, but also continue to develop HITSP like software specifications to support the exchange of data within NHIN. The software functionality does not currently exist in the NIEM toolset, and therefore, it will be necessary to extend NIEM tools to include needed resources. Investments in developing the tools to support this process will help streamline the standards development processes, and aid in the maintenance and use of the data and application standards developed in these activities.

7.1.13 Nationwide Health Information Network (NHIN)The Nationwide Health Information Network is a set of standards, services and policies that enable secure health information exchange over the Internet. Several Federal



168

11761177

430443054306430743084309431043114312

4313431443154316431743184319

43204321

432243234324432543264327432843294330

433143324333

11781179118011811182

1183


agencies and healthcare organizations are already using NHIN technology to exchange information amongst themselves and their partners. The NHIN will provide a foundation for the exchange of health IT across diverse entities, within communities and across the country, helping to achieve the goals of the HITECH Act. This critical part of the national health IT agenda will enable health information to follow the consumer, be available for clinical decision making, and support appropriate use of healthcare information beyond direct patient care so as to improve population health.

The NHIN Work Group, part of the Health IT Policy Committee, is currently developing recommendations for extending the secure exchange of health information using NHIN standards, services and policies to the broadest audience possible. Activities of the NHIN Work Group and Health IT Policy Committee can be found at http://healthit.hhs.gov/policycommittee.

NHIN CONNECTCONNECT is an open source software solution that supports health information exchange – both locally and at the national level. CONNECT uses Nationwide Health Information Network (NHIN) standards and governance to make sure that health information exchanges are compatible with other exchanges being set up throughout the country.This software solution was initially developed by federal agencies to support their health-related missions, but it is now available to all organizations and can be used to help set up health information exchanges and share data using nationally-recognized interoperability standards.

CONNECT can be used to: Set up a health information exchange within an organization Tie a health information exchange into a regional network of health information

exchanges Tie a health information exchange into the NHIN

By advancing the adoption of interoperable health IT systems and health information exchanges, the country will better be able to achieve the goal of making sure all citizens have electronic health records by 2014. Health data will be able to follow a patient across the street or across the country. Three primary elements make up the CONNECT solution:

The Core Services Gateway provides the ability to locate patients at other organizations, request and receive documents associated with the patient, and record these transactions for subsequent auditing by patients and others. Other features include mechanisms for authenticating network participants, formulating and evaluating authorizations for the release of medical information, and honoring consumer preferences for sharing their information. The NHIN Interface specifications are implemented within this component.The Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 155 of 168

11841185

4334433543364337433843394340434143424343434443454346

43474348434943504351435243534354435543564357435843594360436143624363436443654366436743684369437043714372437343744375

11861187118811891190

1191

http://healthit.hhs.gov/policycommittee


The Enterprise Service Components provide default implementations of many critical enterprise components required to support electronic health information exchange, including a Master Patient Index (MPI), XDS.b Document Registry and Repository, Authorization Policy Engine, Consumer Preferences Manager, HIPAA-compliant Audit Log and others. Implementers of CONNECT are free to adopt the components or use their own existing software for these purposes.

The Universal Client Framework contains a set of applications that can be adapted to quickly create an edge system, and be used as a reference system, and/or can be used as a test and demonstration system for the gateway solution. This makes it possible to innovate on top of the existing CONNECT platform.

NHIN DirectBased on initial recommendations from the NHIN Work Group, a new initiative, the NHIN Direct Project, was launched to explore the NHIN standards and services required to enable secure health information exchange at a more local and less complex level, such as a primary care provider sending a referral or care summary to a local specialist electronically.

NHIN Direct is a project to expand the standards and service definitions that, with a policy framework, constitute the NHIN. Those standards and services will allow organizations to deliver simple, direct, secure and scalable transport of health information over the Internet between known participants in support of Stage 1 meaningful use.

The key deliverables of the project will be standards and service definitions, implementation guides, reference implementations, and associated testing frameworks. The project will not run health information exchange services.

This project will expand the standards and service descriptions available to the NHIN to address the key Stage 1 requirements for meaningful use, and provide an easy "on-ramp" for a wide set of providers and organizations looking to adopt. At the conclusion of this project, there will be one nationwide exchange, consisting of the organizations that have come together in a common policy framework to implement the standards and services..

7.1.14 Universal Immunization Tracking System (UITS)The UITS Prototype Project is a Military Health System (MHS) prototype is intended to optimally accomplish immunization documentation and tracking, and support immunizations readiness reporting. The ECCF Physical Implementation Model (PIM) layer are based on the UITS project prototype, which is scheduled for its first go-live demonstration in September 2010.



168

11921193

4376437743784379438043814382438343844385

438643874388438943904391

43924393439443954396439743984399440044014402440344044405440644074408

4409441044114412441344144415

11941195119611971198

1199


This initiative supports three broad goals: 1. Force Health Protection and Readiness perspective:

a. Ensure a healthy and fit fighting force that is fully medically ready to deploy and provide the Department of Defense (DoD) maximal ability to perform its mission.

b. Improved medical readiness through documenting, monitoring and reporting immunization status.

2. Population Health perspective: a. Preventing and controlling diseases reduces adverse incidence requiring

medical treatment. b. Compliant with current national standards and regulations to include

patient safety and data quality. 3. Medical Care perspective:

a. Patient safety. b. Provider has immunization history. c. Medical conditions require supplemental immunization. d. Contraindications to immunizations.

7.2 TOGAF Architecture Development Method (ADM) We followed The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM44), shown in Figure 43 (below) to populate the SAIF Enterprise Conformance and Compliance Framework (ECCF45) shown in Table 13 (above). The ECCF views are analogous to TOGAF’s business, data, application, and technology views. In order to minimize duplication, this section references figures and tables in the SAIF-ECCF appendix, rather than duplicate them here. The TOGAF ADM, shown in Figure 43, recommends a sequence for phases and steps involved in developing architectures; it is an iterative process which supports agile refinement processes and incremental delivery over the whole requirements-specifications lifecycle from simple requirements statements to implemented, tested, certified and deployed systems. Capabilities can be developed concurrently; but, for each capability and iteration, it is important to reconsider scope, detail, schedules, costs and milestones with an eye for optimization in TOGAF ADM’s Phase E described below. TOGAF ADM is usable with deliverables of other frameworks such as Zachman46, DODAF47. It is usual to modify or extend the ADM to suit specific enterprise or project needs, as we have adapted it to populate the HL7 SAIF-ECCF48. 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,



168

12001201

44164417441844194420442144224423442444254426442744284429443044314432

44334434443544364437443844394440444144424443444444454446444744484449

1202120312041205120612071208

12091210121112121213

1214121512161217121812191220

1221

http://en.wikipedia.org/wiki/International_Telecommunication_Union

http://en.wikipedia.org/wiki/International_Electrotechnical_Commission

http://en.wikipedia.org/wiki/International_Organization_for_Standardization

http://cio-nii.defense.gov/sites/dodaf20/index.html

http://zachmaninternational.com/index.php/the-zachman-framework

http://zachmaninternational.com/index.php/the-zachman-framework

http://wiki.hl7.org/index.php?title=SAIF_main_page

http://www.opengroup.org/togaf/


Figure 43 TOGAF ADM Supported by EHR-SD RM

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



168

12221223

44504451

445244534454445544564457445844594460446144624463446444654466

12241225122612271228

1229


7.2.1 PreliminaryThe TOGAF ADM Preliminary Phase prepares the organization for a successful architecture project; it defines "how we do architecture." Its objectives are [TOGAF ADM 2006]:

To ensure that everyone who will be involved in, or benefit from, this approach is committed to the success of the architectural process

To define the architecture principles that will inform the constraints on any architecture work

To define the "architecture footprint" for the organization - the people responsible for performing architecture work, where they are located, and their responsibilities

To define the scope and assumptions (particularly in a federated architecture environment)

To define the framework and detailed methodologies that are going to be used to develop enterprise architectures in the organization concerned (typically, an adaptation of the generic ADM)

To set up and monitor a process (normally including a pilot project) to confirm the fitness-for-purpose of the defined framework

If necessary, to define a set of criteria for evaluating architecture tools, repositories, and repository management processes to be used to capture, publish, and maintain architecture artifacts

DISCUSSION: In adding an Immunization Management Capability (IMC) to SampleHealth’s SOA, we followed the TOGAF ADM and present the Interoperability Specifications using the HL7 SAIF Enterprise Conformance and Compliance Framework (ECCF). Since this was a prototype project, we followed a consensus governance (e.g., decision processes and management) based on peer review of architectural products. Additionally, we maintained a configuration management discipline, which mandates that each artifact be dated and have a version number.

SAIF-ECCF MAPPING: TOGAF ADM Preliminary Phase products are not shown in the Section 2 SAIF-ECCF for Immunization Management.

7.2.2 A – Architecture Vision

TOGAF ADM Phase A sets the scope, constraints and expectations for the project. Validate the business context and create the Statement of Architecture Work. Architectural activity can be scoped or limited in the following four ways [TOGAF ADM 2006]:

1. Enterprise scope or focus.2. Architecture Domains.3. Level of details (vertical scope).



168

12301231

4467446844694470

44714472447344744475447644774478447944804481448244834484448544864487

4488448944904491449244934494

44954496

4497

4498449945004501

450245034504

12321233123412351236

1237


4. Project Schedules (time horizons).

DISCUSSION: 1. Enterprise scope or focus: Our scope is to prototype an Immunization

Management capability, which is added to SampleHealth’s SOA. Our use cases are defined in the Health and Human Services (HHS) American Health Information Community (AHIC) developed Immunization Response Management (IRM) use case and its Vaccine and Drug Administration and Reporting scenario plus overlaps with AHIC’s Public Health Case Reporting (PHCR). Our secondary scope, as an HL7 SAIF alpha-project, is to demonstrate the use of the SAIF ECCF.

2. Architecture Domains: We are working in the healthcare EHR and public health domains

3. Level of details (vertical scope): We will reuse and reference details provided by Standards Development Organizations (e.g., HL7, OASIS, ANSI) and Standards Related Organizations (e.g., IHE, HITSP) artifacts and guidelines.

4. Project Schedules (time horizons): We assume an agile development and deployment lifecycle requiring all prototype work to be done from 24-March-2010 to 20-September-2010. Incremental documentation deliveries are planned for the HL7 May 2010 Working Group meeting and final delivery at the 24 th HL7 Annual Plenary and Working Group Meeting in October 2010.

SAIF-ECCF MAPPING: TOGAF ADM Architecture Vision Phase “A” products are shown in the Appendix Section 2.1 Preamble - Architecture Vision. Although this is not a formal part of the SAIF ECCF, decisions made during this phase impacted the resultant Section 2 architecture.

7.2.3 B – Business Architecture

TOGAF ADM Business Architecture Phase B Develops the Business Architecture as-is and target to-be baselines and analyzes the gaps. In practical terms, the Business Architecture is also often necessary as a means of demonstrating the business value of subsequent architecture work to key stakeholders, and the return on investment to those stakeholders from supporting and participating in the subsequent work. The objectives of Phase B are [TOGAF ADM 2006]: To describe the Baseline Business Architecture To develop a Target Business Architecture, describing the product

and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment, based on the business principles, business goals, and strategic drivers

To analyze the gaps between the Baseline and Target Business Architectures



168

12381239

4505450645074508450945104511451245134514451545164517451845194520452145224523452445254526452745284529

4530

45314532453345344535453645374538453945404541454245434544

12401241124212431244

1245


To select and develop the relevant architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are addressed in the Business Architecture

To select the relevant tools and techniques to be used in association with the selected viewpoints

DISCUSSION: SampleHealth’s as-is architectural baseline was given in The Practical Guide for SOA in Healthcare Volume I. The to-be target architecture adds an Immunization Management Capability (IRC). The EHR-SD RM was used to identify the reusable EHR-S FM and HITSP “to-be” artifacts. IRC Business Architecture behavioral specifications are given as Use Cases and Scenarios, Business Process Models and Sequence Diagrams in the Section 2 SAIF-ECCF for Immunization Management.

SAIF-ECCF MAPPING: The architectural artifacts identified during the TOGAF ADM Business Architecture Phase B were placed within the four SAIF-ECCF Conceptual Viewpoints of 1) Enterprise-Business (e.g., Why), 2) Information (e.g., What), 3) Computational (e.g., How) and 4) Engineering (e.g., Where).

7.2.4 C – Information Systems Architecture

TOGAF ADM Information Systems Architecture Phase C develops a baseline as-is and target to-be and analyzes the gaps. The objective of Phase C is to develop Target Architectures covering either or both (depending on project scope) of the data and application systems domains. Information Systems Architecture focuses on identifying and defining the applications and data considerations that support an enterprise's Business Architecture; for example, by defining views that relate to information, knowledge, application services, etc.

The objective of the data architecture is that it defines the major types and sources of data necessary to support the business, in a way that is understandable by stakeholders, complete and consistent and stable. It is important to note that this effort is not concerned with database design. The goal is to define the data entities relevant to the enterprise, not to design logical or physical storage systems. (However, linkages to existing files and databases may be developed, and may demonstrate significant areas for improvement.)

The objective of the application architecture is to define the major kinds of application system necessary to process the data and support the business. It is important to note that this effort is not concerned with applications systems design. The goal is to define what kinds of application systems are



168

12461247

45454546454745484549

455045514552455345544555455645574558455945604561

4562

45634564456545664567456845694570

45714572457345744575457645774578

4579458045814582

12481249125012511252

1253


relevant to the enterprise, and what those applications need to do in order to manage data and to present information to the human and computer actors in the enterprise. The applications are not described as computer systems, but as logical groups of capabilities that manage the data objects in the Data Architecture and support the business functions in the Business Architecture. The applications and their capabilities are defined without reference to particular technologies. The applications are stable and relatively unchanging over time, whereas the technology used to implement them will change over time, based on the technologies currently available and changing business needs. [TOGAF ADM 2006]

DISCUSSION: SampleHealth’s as-is architectural baseline was given in The Practical Guide for SOA in Healthcare Volume I. The to-be target architecture adds an Immunization Management Capability (IRC). The IRC Business Architecture behavioral specifications are given as Use Cases and Scenarios, Business Process Models and Sequence Diagrams in the Section 2 SAIF-ECCF for Immunization Management.

SAIF-ECCF MAPPING: The architectural artifacts identified during the TOGAF ADM Business Information Systems Architecture Phase C were placed within the four SAIF-ECCF Conceptual Views of 1) Enterprise-Business (e.g., Why), 2) Information (e.g., What), 3) Computational (e.g., How) and 4) Engineering (e.g., Where).

7.2.5 D – Technology Architecture

TOGAF ADM Technology Architecture Phase D develops the baseline as-is and target to-be technology architecture and analyzes the gaps. The Technology Architecture phase seeks to map application components defined in the Application Architecture phase into a set of technology components, which represent software and hardware components, available from the market or configured within the organization into technology platforms. As Technology Architecture defines the physical realization of an architectural solution, it has strong links to implementation and migration planning. Technology Architecture will define baseline (i.e., current) and target views of the technology portfolio, detailing the roadmap towards the Target Architecture, and to identify key work packages in the roadmap. Technology Architecture completes the set of architectural information and therefore supports cost assessment for particular migration scenarios. [TOGAF ADM 2006]

DISCUSSION: SampleHealth’s as-is architectural baseline was given in The Practical Guide for SOA in Healthcare Volume I. The to-be target architecture adds an Immunization Management Capability (IRC). The IRC Business Architecture behavioral specifications are given as Use Cases and Scenarios, Business Process Models and Sequence Diagrams in the Section 2.



168

12541255

4583458445854586458745884589459045914592

4593459445954596459745984599460046014602

4603

46044605460646074608460946104611461246134614461546164617

46184619462046214622

12561257125812591260

1261


SAIF-ECCF MAPPING: TOGAF ADM Technology Architecture Phase D architectural artifacts were placed within the four SAIF-ECCF System Independent Viewpoints of 1) Enterprise-Business (e.g., Why), 2) Information (e.g., What), 3) Computational (e.g., How) and 4) Engineering (e.g., Where).

7.2.6 E – Opportunities and SolutionsTOGAF ADM Opportunities and Solutions Phase E Identifies Major Implementation delivery vehicles (projects, programs, or portfolios) that effectively deliver the Target Architecture identified in previous phases. The objectives of Phase E are [TOGAF ADM 2006]:

To review the target business objectives and capabilities, consolidate the gaps from Phases B to D, and then organize groups of building blocks to address these capabilities.

To review and confirm the enterprise's current parameters for and ability to absorb change.

To derive a series of Transition Architectures that deliver continuous business value (e.g., capability increments) through the exploitation of opportunities to realize the building blocks

To generate and gain consensus on an outline Implementation and Migration Strategy

DISCUSSION: For SampleHealth’s IMC, the opportunities and Solutions which we take advantage of is the reuse of the As-Is SampleHealth Services, described in Volume I. The TOGAF ADM phases B-to-D gaps are filled by the new Immunization Management Capability. For the May 2010 draft version of this document, a series of transition architectures or Implementation and Migration Strategy were not done; they are planned to be done for the Oct 2010 version 1.0 of this document.

SAIF-ECCF MAPPING: TOGAF ADM Opportunities and Solutions Phase E products are not explicitly shown in the Section 2; but, the decisions made during this phase are reflected in the resultant Section 2 architecture.

7.2.7 F – Migration PlanningTOGAF ADM Migration Planning Phase F Analyzes the costs, benefits and risks and produce an implementation roadmap. The main focus of Phase F is the creation of a viable Implementation and Migration Plan in co-operation with the portfolio and project managers. Phase F activities include assessing the dependencies, costs, and benefits of the various migration projects. The prioritized list of projects will form the basis of the detailed Implementation and Migration Plan that will supplement the architectures with investment portfolio and project-level detail assigning The Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 163 of 168

12621263

462346244625462646274628

46294630463146324633463446354636463746384639464046414642464346444645464646474648464946504651465246534654

465546564657465846594660466146624663

12641265126612671268

1269


tasks to specific resources. The Implementation and Migration Plan is part of a family of plans issued by enterprise management frameworks that have to be closely coordinated to ensure that business value is delivered and that the resources are made available to complete the necessary work. This phase ensures that all concerned agencies outside of the enterprise architecture world are aware of the scope and import of the Implementation and Migration Plan and its implications with respect to their activities. Finally, the architecture evolution cycle should be established to ensure that the architecture stays relevant, and lessons learned should be documented to enable continuous process improvement.

The objectives of Phase F are to finalize a detailed Implementation and Migration Plan; specifically [TOGAF ADM 2006]: To ensure that the Implementation and Migration Plan is coordinated

with the various management frameworks in use within the enterprise To prioritize all work packages, projects, and building blocks by

assigning business value to each and conducting a cost/business analysis

To finalize the Architecture Vision and Architecture Definition Documents, in line with the agreed implementation approach

To confirm the Transition Architectures defined in Phase E with relevant stakeholders

To create, evolve, and monitor the detailed Implementation and Migration Plan providing necessary resources to enable the realization of the Transition Architectures, as defined in Phase E

DISCUSSION: For SampleHealth’s IMC, we need an Implementation and Migration Plan for the to-be architectures. For the May 2010 draft version of this document, the Implementation and Migration Plan is not done; it is planned for the Oct 2010 version 1.0 of this document.

SAIF-ECCF MAPPING: TOGAF ADM Migration Planning Phase F products are not explicitly shown in the Section 2; but, the decisions made during this phase are shown by the resultant Section 2 architecture.

7.2.8 G – Implementation GovernanceTOGAF ADM Implementation Governance Phase G ensures that the implementation projects conform to the architecture. The objectives of Phase G are [TOGAF ADM 2006]: To formulate recommendations for each implementation project To govern and manage an Architecture Contract covering the overall

implementation and deployment process



168

12701271

466446654666466746684669467046714672467346744675467646774678467946804681468246834684468546864687468846894690469146924693

469446954696

4697469846994700470147024703

12721273127412751276

1277


To perform appropriate governance functions while the solution is being implemented and deployed

To ensure conformance with the defined architecture by implementation projects and other projects

To ensure that the program of solutions is deployed successfully, as a planned program of work

To ensure conformance of the deployed solution with the Target Architecture

To mobilize supporting operations that will underpin the future working lifetime of the deployed solution

The overall approach in Phase G is to: Establish an implementation program that will enable the delivery of

the Transition Architectures agreed for implementation during the Migration Planning phase

Adopt a phased deployment schedule that reflects the business priorities embodied in the Architecture Roadmap

Follow the organization's standard for corporate, IT, and architecture governance

Use the organization's established portfolio/program management approach, where this exists

Define an operations framework to ensure the effective long life of the deployed solution

DISCUSSION: For SampleHealth’s IMC, we need an Implementation and Migration Plan for the to-be architectures. For the May 2010 draft version of this document, the Implementation and Migration Plan is not done; it is planned for the Oct 2010 version 1.0 of this document.

SAIF-ECCF MAPPING: TOGAF ADM Migration Planning Phase F products are not shown in the Section 2 SAIF-ECCF for Immunization Management; but, the decisions made during this phase are shown by the resultant Section 2 architecture.

7.2.9 H – Architecture Change ManagementTOGAF ADM Architecture Change Management Phase H ensures that the architecture responds to the needs of the enterprise as changes arise. The goal of an architecture change management process is to ensure that the architecture achieves its original target business value. This includes managing changes to the architecture in a cohesive and architected way. This process will typically provide for the continual monitoring of such things as governance requests, new developments in technology, and changes in the business environment. When changes are identified, change management will determine whether to formally initiate a new architecture The Practical Guide for SOA in Healthcare Volume II: Immunization Management Case Study


5/16/2010 Page 165 of 168

12781279

47044705470647074708470947104711471247134714471547164717471847194720472147224723472447254726472747284729473047314732473347344735

4736473747384739474047414742474347444745

12801281128212831284

1285


evolution cycle. Additionally, the architecture change management process aims to establish and support the implemented enterprise architecture as a dynamic architecture; that is, one having the flexibility to evolve rapidly in response to changes in the technology and business environment.

The objectives of Phase H are [TOGAF ADM 2006]: To ensure that baseline architectures continue to be fit-for-purpose To assess the performance of the architecture and make

recommendations for change To assess changes to the framework and principles set up in previous

phases To establish an architecture change management process for the new

enterprise architecture baseline that is achieved with completion of Phase G

To maximize the business value from the architecture and ongoing operations

To operate the Governance Framework

DISCUSSION: For SampleHealth’s IMC, we need change management for iterations from the as-is baseline configuration to the final to-be future state configuration. Changes to documents and diagrams must be version controlled.

SAIF-ECCF MAPPING: TOGAF ADM Architecture Change Management Phase H products are not shown in the Section 2 SAIF-ECCF for Immunization Management; but, the decisions made during this phase are shown by the resultant Section 2 architecture.



168

12861287

4746474747484749475047514752475347544755475647574758475947604761476247634764476547664767476847694770

12881289129012911292

1293