introduction - osehra web viewand in my ideal world, ... provides reusable services that can be...

Working Draft; Not for wide distribution

Fdi dom

Document Title: EHR SOA Platform (ESP) Software Development Kit (SDK) Implementation Guide (IG)

Last Updated: 11 Oct 11, Draft B

Requested Action: Please send suggestions for improvement to [email protected] document editor

Prepared for:Department of Defense, Military Health SystemDepartment Of Veterans Affairs andOpen Source EHR Custodial Agent

Submitted By:Steve Hufnagel PhD, chair, OSEHRA Architecture WG andMs. Nancy Orvis, MHA, CPHMSPaul Tibbits, M.D.Co-Chairs, Health Architecture Interagency Group

1

1

2

3

4

5

6

7

89

1011

12

1314151617181920212223242526272829303132

mailto:[email protected]

Preface

In March 2011, VA Secretary Eric Shinseki and DOD Secretary Robert Gates agreed on a common EHR technical architecture, data and services and exchange standards for the joint EHR system (aka iEHR), where the joint EHR will include both proprietary and open source software. The secretaries of the Veterans Affairs and Defense Departments met on May 2 and June 30, 2011 to determine their next steps toward developing a single electronic health record, for the two agencies.

“VA is developing an open source track to modernize VistA and will incorporate the approach in the joint EHR", Shinseki said. “One of my objectives is to have minimal disruption in the hospitals as we evolve from VistA to the joint EHR system What I think you will see us do is replace modules, do incremental upgrades.” … “In five or 10 years, there may not be one line of code left from VistA. And in my ideal world, the users will have no idea that I have made any changes,” VA Secretary Eric Shinseki said.

“Our goals are to bring in as many private sector modules as possible and selecting the same thing to run between VA and DOD so that we end up with a single, common electronic health record system,” Roger Baker, VA CIO said. OSEHRA sees private modules including both open-source and commercial; OSEHRA intends to foster innovation at the module level and encourages Darwinian selection among competing modules based on cost, performance and support preferences.

"We planned, as part of this EHR framework, to release all the documents, architecture, all these things. It will no longer be, 'you figure it out, you tell us a solution,'" said Col. Hon Pak, the Army medical department's chief information officer. "The open-source custodial agent, largely a VA-led effort but we also participate, really gives you an opportunity in ways that we've never had before." … "Having that venue now equalizes the playing ground so that small, innovative organizations can come and help us figure things out." said Pak. Opening the door to nimble, innovative technologies is a core focus for Pak, who said “DoD is looking for more modular capabilities.” All the services "have pretty much bet the farm" that patient-centered medical home will change healthcare, but he said they need the right tools to get there. "This idea around [health information exchange], telehealth, mobile health, patient-centered medical home are really going to be the necessary ingredients that have to be formulated to drive some of the transformation," Col. Pak said.

“Prompted by President Obama’s push for medical facilities to adopt electronic records, hospitals may pay companies to modify the open-source code likely to power the government-developed system, rather than buying commercial systems”, said Ed Meagher, former Veterans Affairs deputy chief information officer.

Distributed development without an architectural vision is virtually impossible.

Health Architecture Interagency GroupDocument Title: interoperable HER (iEHR) Implementation Guide (IG) Page ii

33343536373839404142434445464748495051525354555657585960616263646566676869707172737475

Working Draft; not for wide distribution

iEHR SDKTable of Contents

1 INTRODUCTION........................................................................................................................... 1

2 SDK FOR THE FUTURE-STATE IEHR ARCHITECTURE..............................................1

2.1 EHRS-iEHR Solution.................................................................................................................................... 42.1.1 EHR Viewer.............................................................................................................................................92.1.2 Point of Service Application................................................................................................................11

2.1.2.1 Lab Information System (LIS).........................................................................................................132.1.2.2 Public Health Services....................................................................................................................13

2.1.3 EHRI-EHR Infrastructure.....................................................................................................................152.1.3.1 Ancillary Data and Services............................................................................................................162.1.3.2 EHR Data and Services...................................................................................................................172.1.3.3 Shared Health Record....................................................................................................................182.1.3.4 Diagnostic Imaging.........................................................................................................................222.1.3.5 EHR Service....................................................................................................................................242.1.3.6 Drug Information...........................................................................................................................252.1.3.7 Laboratory.....................................................................................................................................262.1.3.8 ESB-Engineering Service Bus..........................................................................................................282.1.3.9 Common Services..........................................................................................................................292.1.3.10 Messaging......................................................................................................................................312.1.3.11 En/Coding Services........................................................................................................................312.1.3.12 Encrypt/Decrypt Services...............................................................................................................312.1.3.13 Parser Services...............................................................................................................................322.1.3.14 Routing Service..............................................................................................................................322.1.3.15 Serialization Services.....................................................................................................................322.1.3.16 Transformation Services................................................................................................................332.1.3.17 Protocol Service Components........................................................................................................332.1.3.18 App Protocol Services....................................................................................................................342.1.3.19 Network Protocol Services.............................................................................................................342.1.3.20 Communication Bus/Services........................................................................................................342.1.3.21 HIAL – Health Information Access Layer........................................................................................352.1.3.22 Health Information Data Warehouse.............................................................................................362.1.3.23 Longitudinal Record Services.........................................................................................................372.1.3.24 Business Rules...............................................................................................................................392.1.3.25 EHR Index......................................................................................................................................392.1.3.26 Message Structures.......................................................................................................................402.1.3.27 Normalization Rules.......................................................................................................................402.1.3.28 Registries, Data and Services.........................................................................................................41

2.2 Interoperability Specifications (IS)............................................................................................................ 432.2.1 Service Aware Interoperability Framework (SAIF)...........................................................................43

2.2.1.1 SAIF Concept Map..........................................................................................................................442.2.1.2 SAIF Behavioral Framework (BF)....................................................................................................452.2.1.3 SAIF Information Framework (IF)...................................................................................................46

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page iii

76

7778

79

80

81828384858687888990919293949596979899

100101102103104105106107108109110111112113114

115116117118119


2.2.1.4 SAIF Governance Framework (GF).................................................................................................472.2.1.5 Enterprise Compliance and Conformance Framework (ECCF).......................................................48

2.2.2 Information Model Within iEHR..........................................................................................................492.2.2.1 iEHR Information Meta-Model......................................................................................................492.2.2.2 Information Meta-Model...............................................................................................................502.2.2.3 Terminology Meta-Model..............................................................................................................512.2.2.4 Data Meta-Model..........................................................................................................................52

1 IntroductionThis document is intended as a implementation guide for interoperable EHR (iEHR) stakeholders. It defines an n-tiered standards-based component-service reference architecture, Application Program Interfaces (APIs) and interoperability specifications. The n-tiered component-service architecture is based on the eight years of experience of Canada Health Infoway and the interoperability specifications are based on the HL7 Service Aware Interoperability Framework (SAIF). This is a living document, which will be flushed out, adapted to DoD-VA iEHR requirements and constraints and updated as we go forward on the iEHR initiative. Currently, this document is a shell, which needs refinement.

An interoperable iEHR Blueprint is useful to information technology professionals, in government, purchased care organizations, health regions and hospitals planning to implement electronic health record solutions. It is also valuable to technology vendors who want to align their products and services with the National vision for the interoperable electronic health record (iEHR). The iEHR SDK will be tailored to DoD-VA requirements and constraints.

1.1 DisclaimerDRAFT WORKING DOCUMENTS ARE NOT LEGALLY BINDINGAND DO NOT REPRESENT OFFICIAL DOD OR VA POSITION.

The DoD and VA wish to openly-and-transparently collaborate with the Open-Source EHR-Community; this is a new “agile acquisition” approach for the government and MUST evolve with lessons learned. This SDK, its companion Implementation Guide (IG) and related artifacts are DRAFT Working Documents, being coordinated by the Open Source EHR Custodial Agent (OSEHRA) Architecture Committee with the guidance of the DoD-VA Health Architecture Interagency Group (HAIG). The purpose is to seek EHR-modernization architectural-input from DoD & VA staff, contractors, partners, stakeholders, venders and open-source-community in an open-and-transparent collaborative-forum; The DRAFT Software Development Kit (SDK), its IG and any related documents MUST be considered a government Request for Information (RFI); without obligation to the government as we go through this new open-and-transparent agile-development-process; Once feedback has been received, OSEHRA Architecture Committee’s Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page iv

120121122123124125126127128

129130131132133134135136137138139140141142143144145146

147148149150151152153154155156157158159160


updates have been made and the SDK has been reviewed and approved by appropriate government leadership, DRAFT can be removed from the SDK and its IG and they will be versioned, time-stamped and an official government letter of endorsement MUST be attached.

Only an official government-endorsed-and-versioned SDK, its IG and related artifactscan be used in any government contract or acquisition process.

1.2 Technical VisionThe Technical Vision is to modernize and transition legacy EHR systems to an EHR Services Platform (ESP) for Application Integration. An ESP facilitates application innovation; it is composed of separated operation, business-rule and information services to integrate plug-&-play applications; the ESP services MUST be used by ALL applications and ALL applications MUST be service-based.

As the ESP is fully-specified in the SDK Implementation Guide (IG), as standardized and reference implementations become available; then, general-purpose and domain-specific “best-of-class” certified applications can be user-selectable and evolve on a Darwinian basis. This is analogous to a Smart-Phone Application-Markets. Anyone can build and submit ESP services and/or applications for certification. The Open Source EHR Custodial Agent (OSEHRA) will IV&V and CM certified ESP application services and reference-implementations (e.g., gold builds). DoD, VA, IHS and others may pick-&-choose, which certified applications they use. Legacy-systems and ESP enabled systems can co-exist during long legacy transition periods across large enterprises. This is analogous to the PC and telecommunications evolution-revolution from the 1980s to now.

1.3 Problem Solution Approach2 Problem: Innovation to revitalize legacy systems Solution Approach: Services within a standards-based component-architecture

encourage lower-cost component innovation without requiring enterprise-wide expertise and extensive testing. SDK empowers individuals and avoids stovepipes.

3 Problem: Interoperability among partners. Solution Approach: EHR IS canonical information and terminology models can

be used to map among heterogeneous system information exchanges. By adopting common EHR IS data, terminology, and communications standards; multiple organizations can share and ultimately harmonize Electronic Medical Records.

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page v

161162163164165166167168

169170171172173174

175176177178179180181182183184185186

187188189190191192193194195196197198


4 Problem: Transition from legacy systems and data to an integrated EHR architecture.

Solution Approach: Virtualization-Layers of Federated Standards-Based Services allow new and legacy COTS, GOTS and open-source applications, scalable databases and infrastructure to coexist.

5 Problem: Agility to respond to rapid healthcare changes and related legislation.

Solution Approach: Services within a standards-based component-architecture encourage faster and lower-cost changes to be made and tested within components without requiring enterprise-wide expertise and testing.

6 Problem: High Costs of change and sustainment. Solution Approach: Virtualization-Layers of Federated Standards-Based

Services make plug-and-play applications, databases and infrastructure possible, which can be treated as commodities and can be tested efficiently. Interchangeable-components can compete based, on functionality, quality, performance vs. cost, usability and supportability. Built In Test Environment (BITE) identifies faults early, improving robustness and reducing test costs. .

7 Problem: Patient Safety issues resulting from software changes. Solution Approach: Component architecture localizes faults. BITE identifies

faults early, improving system robustness, patient safety.8 Open Source Community Enablement Solution Approach: Virtualization-Layers of Federated Standards-Based

Services support alternate configurations of applications, databases and infrastructure, which may be combinations of MUMPS, COTS, GOTS and open source code to meet the specific-needs of various stakeholder-and-user communities.

8.1 Legacy Transition Strategy

1. ESP kernel-services and data stores CAN be set-up at one-or-more data-centers (any cloud topology).

2. For pre-certification self-testing and attestation, venders and developers MUST be provided: i) SDK-IG, ii) an open-source test virtual-machine (VM) with the ESP set-of operating-and-data services, iii) clinically-meaningful test-database, test-scripts, certification-criteria.

A. Agile SDK, ESP and application development and certification processes MUST have up-to-date VMs and ongoing regression testing to obtain/maintain “certified” status.

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page vi

199200201202203204205206207208209210211212213214215216217218219220221222223224225

226227228229230231232233234235236


B. Certified applications, test and certification VMs, test fixtures/scripts, test-results MUST be made available to anyone (e.g., open source community) to verify and validate test results & attestations.

3. One-or-more user-configurable ESP enabled viewers SHOULD be made freely available.

4. Legacy systems MUST be updated i) to “journal” their clinically-relevant data-store transactions with the ESP data-store and to query via the ESP, analogous to legacy DoD-VA sharing;

5. Terminology mapping SHOULD be a part of legacy-data transition.6. To be repurposed to ESP capability, legacy-applications MUST conform to ESP

SDK-IG and associated certification criteria. 7. Once certified ESP enabled viewer(s) and ESP enabled applications are

available to clinical users, they CAN transition to modernized ESP based systems, while others might continue on legacy systems.

8. Clinically-meaningful legacy-data MUST be extracted to ESP before legacy systems are shut down.

8.2 SDK-IG Purpose

• The ESP Software Development Kit (SDK) presents the vision (see the companion slide deck) and specifies the means (companion ESP Implementation Guide (IG)) for Open Source and vender applications to plug-&-play within future-state ESP enabled operating and data-access platforms; ESP enabled systems are composed of “information” services supporting efficient plug-&-play application-integration.

• The SDK development, following agile processes, is intended to become a clear, complete, concise, correct and consistent HL7 SAIF (Service Aware Interoperability Framework) conformant standards-based ESP enabled system SDK IG for vender and open-source developers.

• This comprehensive set of slides may be freely used or repurposed with appropriate attribution

YOUR HELP IS REQUESTED IN VERIFYING, VALIDATING AND INCREASING THE USABILITY OF THE ESP SDK

8.3 Benefits

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page vii

237238239240241242243244245246247248249250251252253

254255256257258259260261262263264265266267268269270271

272273


The ESP can become the National and possible International EHR standard for “best-of-breed” Darwinian innovation, evolution or revolution where anyone can participate. The SDK’s Standards-Based Best-Practices ensure consistency across:

– Interoperable Application Service APIs– Common/ Engineering Service Bus (C/ESB)– Interoperable Plug-and-Play Applications

– Interoperable Virtual Database (DB) APIs scalable from– Legacy MUMPS-globals acting as a DB to MS Access, Open or MS SQL,

Oracle to– Massively-parallel high-performance grids running on commodity-

hardware-blade-platforms (i.e., amazon.com & google.com models). – ESP enabled Trading Partners – Acquisitions (ESP SDK-IG as GFI for RFIs and RFPs) – VA, DoD and IHS offices, staff and contractors – Open Source and vender community

8.4 HL7 SAIF

HL7 Service Aware Interoperability Framework (SAIF) Conformant ESP Implementation Guide (IG)• To be OSEHRA software-quality certified, ESP enabled applications MUST be

conformant to the companion ESP SDK Implementation Guide (IG) which follows HL7 SAIF guidance.

• The SDK slide set is the SAIF Conceptual Perspective• The SDK Implementation Guide is the SAIF Logical Perspective• Developers & Venders MUST deliver the SAIF Physical Perspective

• SAIF provides guidance; but, OSEHRA, DoD, VA, IHS and stakeholders MUST establish a consensus ESP IG, defining required architectural views (e.g., subset of DoDAF views) and appropriate specification language (e.g., BPMN, UML).

• The ESP companion SDK IG is HL7 SAIF conformant and defines software-engineering best-practices for interoperability Standards and Conventions (iSAC).

• Agile processes are being followed to define the SDK slides and IG; that is, there will be many incremental refinements.

8.5 Abbreviations

AKA Also Known AsBITE Built in Test Environment

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page viii

274275276277278279280281282283284285286287288289

290291292293294295296297298299300301302303304305306307

308309310311


CM Configuration ManagementDI Diagnostic ImagingDoD Department of DefenseEAI Enterprise Application IntegrationEHR IS EHR Information ServicesESP HER Services PlatformESB Engineering Service BusHAIMS Health Artifact and Image Management SolutionICIB Interagency Clinical Informatics BoardIG Implementation GuideIHS Indian Health ServicesIP Interoperability Profile / SpecificationIV&V Independent Verification and ValidationLIS Laboratory Information SystemsLRS Longitudinal Record ServiceOSEHR Open Source EHROSEHRA OSEHT Custodial AgentRFI Request for InformationRIS Radiology Information SystemSAIF HL7’s Service Aware Interoperability FrameworkSDK Software Development KitSDO Standards Development OrganizationSOA Service Oriented ArchitectureTSA Telehealth Scheduling ApplicationVA Veterans AdministrationVHA Veterans Health AdministrationVM Virtual Machine

8.6 References See https://www.infoway-inforoute.ca/lang-en/ for Canada Health Infoway interoperable

EHR Blueprint

9 SDK for the Future-State iEHR Architecture

Software may have attached licenses that make them unsuitable for building software intended to be developed under an incompatible license. For example, proprietary software applications may be incompatible with free software development, while a

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page ix

312313314315316317318319320321322323324325326327328329330331332333334335336337338339340

341342343

344

345347348349350

https://www.infoway-inforoute.ca/lang-en/


GPL-licensed applications could be incompatible with proprietary software development. To solve license incompatibilities, it may take something as simple as an application programming interface (API) in the form of some files to interface to a particular programming language or include sophisticated hardware to communicate with a certain embedded system.

Common tools include debugging aids and other utilities often presented in an integrated development environment (IDE). SDKs also frequently include sample code and supporting technical notes or other supporting documentation to help clarify points from the primary reference material.

A contractor, internal developer or open source software engineer typically uses the SDK. This SDK can be downloaded directly via the Internet. This SDKs is provided for free to encourage developers to use the same architecture, component-services and standards.

The Software Development Kit (SDK) describes a framework for the future state of the iEHR system components within the context of a Service Oriented Architecture (SOA). It is a given that intermediate solutions that meet these requirements can and will be deployed. The importance of this system architecture is that it establishes a strategic direction towards which all partial implementations will aim while still delivering specific short-term results.

The iEHR infrastructure includes a broad set of electronic information sources that capture and hold data related to the provision of health services to individuals. This definition encompasses every care setting and health discipline that is oriented towards health promotion, the diagnosis and treatment of illness, or the management of care processes that directly affect individuals and the public at large. While this definition incorporates a significant number of source systems, the data they hold cannot be considered a coherent Electronic Health Record unless that data can be assembled consistently, reliably, when and where it is required, regardless of when or where it was captured. This presents a daunting challenge both technically and systemically for the health system. This iEHR SDK suggests a response to address those challenges.

The iEHR SDK includes an Enterprise Architecture blueprint that defines “the Enterprise” as the entire health care delivery system. It addresses the problem of consolidating disparate and dispersed data into a coherent whole by providing a common set of standards-based interfaces for placing and retrieving information in a set of shared data repositories held within each instance of an iEHR infostructure. Rather Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page x

351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389


than reaching into the (legacy) operational systems that capture and hold the data at the Point of Service, the EHR infostructure (EHRi) provides a mechanism for those PoS applications to push appropriate subsets of data to these shared data repositories in near real-time. As more source systems are modified to participate in the EHRi, the amount and variety of clinically-relevant data increases significantly. Because each instance of an EHR infostructure exists as a peer to the other infostructures, implemented within the same organization or in other organizations across the country, the EHRi also permits the retrieving of all information related to a person, regardless of where they received their health services.

The EHR infostructure organizes EHR data into data stores (e.g. repositories) that have clinically-relevant person-specific data supporting use by health service providers, as well as specialized information supporting:• Public Health service delivery and surveillance• Lab services• Diagnostic Imaging• Drug utilization and e-prescribing.

In order to provide their domain specific value and features to care providers, these domain-specific repositories are more closely integrated with the systems that provide and require this data. For example, the consolidation of lab orders and results in a repository shared at the organization level will result in reduced duplication of test orders, more efficient handling of results, and more timely assessment of results for improved health care. The amount of data and the number of specialized repositories may change over time, and the Longitudinal Record Services would be reconfigured to accommodate such changes.

In order to correctly organize the information in these repositories, a series of identifier registries are used to uniquely identify and manage the identifying characteristics of:• clients of the health system• providers of health services• the locations where services are provided

In the EHRS SDK Blueprint vision for the EHRi, the identifying and demographic information held in the registries are consolidated for an entire organization (e.g., Both DoD and VA use DEERS - Defense Eligibility Enrollment Reporting System - DMDC ), and are used by all Point of Service applications in that organization. The EHR infostructure incorporates these registries, enabling them as services within the architecture and

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xi

390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427

http://www.dmdc.osd.mil/deers/


using them to link the persistent internal EHR identifiers to the external identifiers known to the clients and service providers.

class SDK for Future-State-Architecture

SDK for Future-State-Architecture

+ EHRS-EHR Solution+ Interoperability Specifications

EHRS-EHR Solution

+ EHRS Conceptual View+ EHRS-EHR Solution

+ EHR Viewer+ Point of Service Application

+ EHRI-EHR Infrastructure

EHR Viewer

+ EHR Viewer

Point of Serv ice Application

+ Hospital Systems+ Pharmacy System

+ Physician Office EMR+ Point of Service Application

+ Radiology Center PACS/RIS+ Lab Information System (LIS)

+ Public Health Services

EHRI-EHR Infrastructure

+ EHRI-EHR Infrastructure+ Ancillary Data and Services

+ EHR Data and Services+ ESB-Engineering Service Bus/Services

+ Health Information Data Warehouse+ HIAL – Health Information Access Layer

+ Longitudinal Record Services+ Registries, Data and Services

Figure 2-1

9.1 EHRS-iEHR Solution The information stored in the EHR Data and Services Repositories is patient/client-

centric and longitudinal. Logically it forms a “womb–to-tomb” health history for the patient/client. Together the PoS applications participating in an EHRi and their associated databases form the complete electronic health record of a patient/client;

Across a network of EHR Solutions a patient/client is perceived by the PoS applications and their end-users (caregivers) as existing logically in one single EHR.

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xii

428429

430431

432434435436437438439


Given the way healthcare is delivered it is important that there be flexibility in the solution architecture with respect to where a patient/client’s physical EHR data is located. By way of example, the EHR data about a client will typically stay physically in the province/territory where they received care. Over time, this may mean that a client’s EHR data is distributed across several EHR infostructures. However, each time that a caregiver is accessing this client’s EHR, the EHR infostructure handling this request will compile all the data relevant across any number of EHR infostructures where relevant data is kept. From the system’s perspective, and more importantly the users of those systems, the person’s data is perceived as being in one EHR;

The EHR is an authoritative and reliable source of the clinical information. It is meant to be used as a valid source of information in support of health services providers assessing and making clinical decisions for clients on a continual basis;

Conceptually, an EHR is a structured set of clinical information for a patient/client. Information for the patient/client may be organized into “multi-dimensional” categories such as time, clinical data type (e.g. encounter events, lab order or result, drugs prescription or dispense, clinical notes), practice area, disease classes and others;

The EHR holds a history of health service delivery events for each patient/client. Events can be flexibly associated with, or organized as, an Encounter, or as part of a larger Episode of Care. This allows the organizing of a patient/client’s health history in a way that is meaningful to providers of services;

All clinically relevant data required to share the clinical picture of a patient/client across the continuum of care is kept in the EHR;

An EHRi is NOT an on-line transaction processing (OLTP) store for any clinical system used in a point of service;

An EHRi is enabled by registries, a LRS, EHR Data domain repositories, ancillary services, a health information data warehouse and a HIAL;

The PoS applications are key elements of the solution. PoS applications are used by authorized caregivers to view and navigate the EHR of a patient/client. These include applications at the point of care that a provider is interacting with. This may be a piece of medical equipment that is generating or reading clinical data for a patient/client or an intelligent agent (i.e. without a human-computer interface) implementing some specific business rules;

Data produced in PoS settings is pushed or published into the EHRi from PoS applications;

PoS applications store encounter related data in their local data store and are also publishing or replicating the parts of this data that is declared as clinically relevant for sharing, in near real-time into the EHR via the EHRi.

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xiii

440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478


The same set of PoS applications read and use data out of the EHRi. Thus, the EHRi is used for clinical purposes by these applications. EHRi data is viewed from PoS applications that caregivers or providers use in their daily activities. For example, a primary care doctor using an electronic medical record (EMR) application may be viewing four sets of data on their system. One set of data coming from the patient’s EHR; another from the EMR application order entry module (i.e. for a new prescription or lab test); another from the EMR’s local database regarding the patient’s latest visit; and a fourth set for an input screen for the doctor’s clinical notes pertaining to the visit.

The interface between PoS applications and EHRi must comply with EHR standards. Several modes of communication have to be supported in order to cover the different types of interactions that are needed. Most of the communications rely on a service oriented messaging framework for the purposes of reading and writing clinical information in and out of the EHRi. Some communications rely on streaming protocols (e.g. diagnostic imaging). EHRi communication standards are based on industry standards such as HL7, DICOM, EBXML, SOAP, SHTTP and TCP/IP.

The EHRi is composed of multiple classes of service that need to participate and interact with one another in a coordinated fashion, namely:• The Longitudinal Record Services (LRS) which represent a grouping of capabilities that acts as the kernel of the EHR Infostructure. It is namely responsible for the orchestration of services in order to realize transactions. It is also in charge of providing a coordinated and centralized view of what data is in the EHR for any single patient/client. In other words, it is the engine that coordinates and executes any transaction that needs to have a longitudinal perspective of the clinical data of a patient/client.• The Shared Health Record repository maintaining encounter history data as well as clinical data not otherwise maintained in specific domain repositories; examples of classes of data could include encounter or visit summary documents, referral orders and notes, diagnosis data, observations, care protocols, care plans;• Registry systems providing data and resolution services for persons or entities needing to be identified uniquely in the context of a transaction to an EHRi. Examples include: Patients/clients, Providers, Service Delivery Locations, Organizations and potentially others relating to the application of security frameworks such as user, PoS applications, Provider Role, End User Role;• Domain repositories that store, maintain and provide subsets of clinical information that pertain to the clinical picture of a patient/client such as drugs or medication profiles, laboratory orders and tests results, shared diagnostic imaging orders and results including image repositories (a.k.a. PACS – Picture Archiving Communication System);Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xiv

479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517


• A HIAL made up of common services and communication bus to enable a high level of abstraction and independence between PoS applications and an EHR Infostructure. It provides reusable services that can be shared by any component of the EHRi. It also acts as a centralized entry point or connection point for any PoS application to interact with an EHR Infostructure or for multiple EHR Infostructures to connect to each other.• Point of Service applications represent all the systems used by healthcare organizations or caregivers that store, manage and or provide access to clinical data for patients/clients. PoS applications interact with one EHRi in a given organization. This interaction is accomplished by way of messages being exchanged between the applications and the HIAL.

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xv

518519520521522523524525526527


class EHRS-EHR Solution (Conceptual View)

EHRS-EHR Solution

EHR Viewer


Ancillary Data and Serv ices

Health Information Data Warehouse


HIAL – Health Information Access Layer

Registries, Data and Serv ices

Longitudinal Record Serv ice

(LRS)

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xvi

528


Figure: 2

EHRS-EHR Solution (Federated View)

class EHRS-EHR Solution (Federated View)

Figure: 3

9.1.1 EHR Viewer

Note that the EHR Viewer is included as just one of the many “Point of Service” applications, but it is distinguished by the fact that it does not rely on a local data store (i.e. the blue cylinder shown with the other PoS systems), but must obtain all its information from the EHRi The EHR Viewer deals with the presentation of EHR data to end-users using software solutions that have been in existence and in use in hospitals and other facilities for years. Since there is a mature market for these solutions and since the EHR brings a whole new perspective on their potential use, it is expected that there will be different technical approaches considered for the EHR Viewer.

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xvii

529530531533

534535536537539540541542543544545546547


class EHR Viewer

EHR Viewer

Figure: 49.1.2 Point of Service Application

POS application requirements: To support a set of local business or clinical requirements to manage information

and/or automate workflows in a specific domain of health services delivery (e.g. drug, diagnostic imaging, laboratory, ADT, etc...)

To support the business or clinical requirements associated with the sharing of local

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xviii

548549550552553554555556557


clinical data through the EHRi. Support of the PoS application communication requirements needed to interact with

the EHRi system. The integration and presentation of EHR data in the PoS application processing flow

and end-user interface via: o An integrated view of local application data and EHR data o An EHR Viewer

class Point of Serv ice Application


Radiology Center PACS/RIS

Public Health Serv ices

Physician Office EMR

Pharmacy SystemLab Information

System (LIS)

Hospital Systems

Figure: 5

9.1.2.1 Lab Information System (LIS)

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xix

558559560561562563564

565566567568569570


class Lab Information Syste...

Lab Information System (LIS)

Figure: 6

9.1.2.2 Public Health Services

Key information types to be shared in the EHRi Public Health Domain are text-based Reportable Diseases and Immunizations. These are communicated between PHS PoS applications and organizational Immunization systems via structured HL7 messages from Public Health labs and Immunization Management systems.

PHS Immunization Management (IM) has three parts:1. IM Health Surveillance user function;2. IM “supply chain” (serum and antiviral sources, inventory, distribution);3. IM “clinical” (where immunization service events are recorded)

IM Clinical events can occur in multiple settings, performed by different providers (PH Nurse, Physician or Nurse in a primary care or hospital setting, etc.), using different systems: i.e., PHS IM System, Physician Office EMR system, Acute Care (Hospital) system; IM Clinical events is therefore a combination of IM “reporting” from PoS applications (directly or via EHR & domain repositories) and an IM-specific PoS application.

It is expected that these types of functions will be available in commercial PHS software applications and can be accessed using generic Portal technologies rather than separate interfaces.

If a separate PHS domain repository does not exist, the EHR Shared Health Record Repository must, at minimum, provide the ability to record patient Immunizations using standard HL7 messages. In this scenario, the EHR Index must also be updated to describe the type, location and access method of the data. Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xx

572573574575576577578580581582583584585586587588589590591592593594595596597598599600601602603604605


Public Health Systems will also share or reuse components/services described in the EHRi such as: The Common Services and Communication Bus (Health Information Access Layer –

HIAL) will service the entire architecture Inter-organization communication or messaging for PHS purposes uses the same

HIAL to HIAL mechanisms as inter-organizational EHR messaging A PHS Portal could share the same technology platform as an EHR Viewer The “Immunization Repository Services” (aka “Immunization Registry”) should be

shared for PHS and EHR purposes; there is a need for Immunization Services to be implemented with both purposes in mind; this will mean using EHR messaging standards

Organization Data Warehouse services (where they already exist) should provide services to PHS along with other business requirements; if these services and solutions are not in place, they need to be implemented with other possible Data Warehouse business function in mind

EHR and Domain Repositories are potential sources of inputs to PHS, especially Laboratory results, and potentially other clinical information

The Organization Registry Services should be used directly by PHS applications and services, either in transactional mode (for developed components), or as integrated source and consumer systems (for purchased components).

“Reference Management” and “Content & Knowledge Management” may be sharable resources (with EHR), or implied or contained within each PHS application or services

“Reporting” of clinical events (e.g., reportable Lab results, reportable PoS events) should evolve to become messages from EHR and Domain repositories, via EHR services, to PHS functions, instead of separate messages from PoS systems to PHS services.

class Public Health Serv ices

Public Health Serv ices

Figure: 7

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxi

606607608609610611612613614615616617618619620621622623624625626627628629630631632633634

635636637638


9.1.3 EHRI-EHR Infrastructure The EHR infrastructure includes a broad set of electronic information sources that capture andhold data related to the provision of health services to individuals. This definition encompassesevery care setting and health discipline that is oriented towards health promotion, the diagnosisand treatment of illness, or the management of care processes that directly affect individuals andthe public at large.

class EHRI-EHR Infrastructure


Health Information Data Warehouse HIAL – Health

Information Access Layer

EHRS Locator

ESB-Engineering Serv ice

Bus/Serv ices

Longitudinal Record Serv ice

(LRS)

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxii

639640641642643644645

646


Figure: 8

9.1.3.1 Ancillary Data and Services class Ancillary Data and Serv ices

Ancillary Data and Serv ices

Figure: 9

9.1.3.2 EHR Data and Services

The extent of the clinical information sustained by an EHR Infostructure may vary based primarily on the presence or absence of EHR Domain Repositories. The key data domains recognized as part of an EHR are the shared health record, drugs, laboratory and diagnostic imaging. Some of these data domains may already be the subject of deployed organizational level systems. In order to provide the complete clinical picture of a patient/client, the EHR infostructure must be able to assemble information transparently from these EHR Domain Repositories.

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxiii

647648649

651652653654655656658659660661662663664665


class EHR Data and Serv ices

EHR Data and Serv ices (Domain Repository)

EHR Serv iceLongitudinal Record Serv ice

(LRS)

Figure: 10

9.1.3.3 Shared Health Record

The data maintained in the SHR can grow to be very wide ranging both in terms of scope and volume. In early generations of EHR Infostructure solutions however we expect the scope of this data to be fairly limited and constrained. These limitations are largely due to the need to focus on only clinically relevant data appropriate for sharing, and on the fact that current systems are not engineered to take advantage of more advanced EHR infostructures capabilities. The early definition of this scope includes the following facets of information:

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxiv

666667668669671672673674675676677678


Encounter Basic Information Referral Orders and Referral Notes Encounter Summaries Clinical Observations primarily focused on critical observations that impact the

health status of an individual. Problems/Conditions/Diagnosis As PoS applications become more EHRi-enabled, additional facets of information

could include: Care Plans Care Protocols Client Health Status indicators including level of comfort, likelihood to die, function

and severity And others

In this context, the following services allow EHR users / PoS applications to record, list and retrieve Shared Health Record repository information. Put Encounter - Records a new encounter in the SHR with the base information

that describes it including start date, planned end date, end date, state, reason for admission/visit.

Put Referral Records a new referral in the SHR with its supporting information including a type of referral, the date of the referral, referral target service, referral state.

Put Encounter Summary - Records a new encounter summary with all of its supporting information. Both coded and noncoded entries are incorporated. An encounter summary should always be associated to at least one Encounter record maintained in the EHR Index.

Put Clinical Observation - Records a new observation in the SHR. Both coded and non-coded entries are accepted. Put Problem / Condition / Diagnosis Records a problem, condition or diagnosis in the SHR. Both coded and non-coded entries are accepted.

List Encounters - Searches for a range of encounter records based on a set of research criteria including client id, provider id, location id, date range, reason for admission/visit, status.

List Referrals - Searches for a range of referral events in the SHR based a set of research criteria including client id, provider id, location id, date range, status.

List Observations - Searches for a range of observation records in the SHR based on a set of research criteria including client id, provider id, location id, observation type, date range, status. Review Basic Patient Observations from clinical Rx

List Problems / Conditions / Diagnosis - Searches for a range of problems, Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxv

679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717


conditions or diagnosis records in the SHR based on a set of research criteria including client id, provider id, location id, problem type, condition type, diagnosis type, date range, status.

Get Encounter - Retrieves a specific encounter record with all of its supporting information

Get Referral - Retrieves a specific referral event and all of its supporting information Get Encounter Summary - Retrieves a specific encounter summary entry and all of

its supporting information Get Observation - Retrieves a specific observation and all of its supporting

information Get Problem / Condition / Diagnosis - Retrieves a specific problem, condition or

diagnosis record with all of its supporting information Get SHR Complete Record - An extended feature allowing the retrieval of the entire

health record maintained in the SHR for a single client. This will return several types of data structures packaged into a single message. The criteria includes client id, date range, last record fetched bookmark and paging size value. See Note 2

List Relevant SHR records - An extended feature allowing for a free text search to be launched in the SHR and retrieve any record that match the criteria for a given client, provider or location. Search criteria includes client id, provider id or location id as well as last record fetched bookmark and a paging size value. See Note 2.

Note 1: This table does not include the “List Encounter Summaries” transaction profile. This is not a mistake, encounter summaries are expected to be accessed from the basic encounter records to which they are associated. The SHR is not expected to support a search and find capability on encounter summary records per say. Users would first list encounter records with their basic information and then access more details which may include the encounter summary.

Note 2: This kind of transaction will require the SHR to maintain a paging ability as part of its search algorithm. This way the system always limits the extraction of record to a limited set. Over time multiple queries may come back towards the SHR to further retrieve valid responses.

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxvi

718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749


class Shared Health Record

Shared Health Record (SHR)

Diagnostic Imaging

Drug Information Laboratory

Figure: 11

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxvii

750751752


9.1.3.4 Diagnostic Imaging

This service allows for the centralized capture and sharing of DICOM compatible objects across a large distributed network. These networks include Picture Archiving and Communication Systems (PACS) implemented in hospitals or diagnostic centers as well as diagnostic modalities used to produce such pictures. Typically, there are two key pieces of data associated with a diagnostic imaging test, a writtenreport outlining the conclusions of a study and the imaging artifacts which may take different forms such as video or sound but most often will take the form of one or more pictures. Both the written reports as well as the key picture(s) used to reach the conclusions expressed in such report are expected to be available from the DI service.

The diagnostic images discussed herein are typically the end result of a business process that starts with an order created by a clinician for a certain type of test. The order itself is expected to be represented within the DI domain service as a set of data in support of a given diagnostic image result and therefore is expected to be available as part of the electronic health record of clients.

Other types of large binary objects could also be handled by the DI domain capabilities, examples of those include clips of video streams coming from a telehealth session seen as clinically-relevant for a person’s health record, or eventually any digital stream coming from different modalities (ECG, Respiratory Monitors, etc…).

Providing fast, easy and responsive access to large picture or other types of streaming objects presents a challenge. The EHRi DI Domain services support EHR user requests to retrieve patient clinical data from the DI domain repository system for display. The centralized organizational EHR Index service, provided as part of the Longitudinal Record Services, performs a vital role in recording the location and types of DI information a patient has received. This indexing mechanism is core to the operation of the DI domain service whenever an end-user is trying to access an image (or any object) for viewing.

The following EHRi DI Domain service operations represent the patient centric queries initiated by an EHR user in the context of an EHRi system.

Get DI Order - Allows to view a DI order already placed in a DI domain system.

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxviii

753754755757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792


Get DI Report - Allows to view a DI report (final, addendum, first impression) either in plain text or PDF format.

Get DICOM Object - Allows to view DI images or evidence documents. This service will allow the retrieval of the following types of DI documents:• Full set of images (Exam)• Set of pertinent images (Key Images)• Evidence documents (requisition, technologist impressions, screening forms, etc.)

List DI Orders - Allows to query and retrieve a list of a patient’s DI orders using search criteria such as:• Client ID (ECID)• Type of DI Orders• Modality• Date Range• Service Location• Ordering Physician

List DI Exams - Allows to query and retrieve a list of a patient’s DI Exams using search criteria such as:• Client ID (ECID)• Document type – images, diagnosis, progress• DI Domain Service• Operation• Description SCP EHR• Standard• report, preliminary report, etc.• Date Range• Service Location• Ordering PhysicianRelevant metadata for this query includes:• Exam date• Modality• Body part/anatomical region• Procedure code

Get DI Complete Record - An extended feature allowing to retrieve the entire record maintained in the DI domain service for a single client. This will return several types of

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxix

793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830


data structures packaged into a single message. The criteria includes client id, date range, last record fetched bookmark and paging size value.• DI Domain Service• Operation• Description SCP EHR• Standard• report, preliminary report, etc.• Date Range• Service Location• Ordering Physician• Relevant metadata for this query includes:• Exam date• Modality• Body part/anatomical region• Procedure code

Get DI Complete Record - An extended feature allowing to retrieve the entire record maintained in the DI domain service for a single client. This will return several types of data structures packaged into a single message. The criteria includes client id, date range, last record fetched bookmark and paging size value.

class Diagnostic...

Diagnostic Imaging

Figure: 12

9.1.3.5 EHR Service

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxx

831832833834835836837838839840841842843844845846847848849850

851852853854855856857


class EHR Serv ice

EHR Serv ice

Figure: 13

9.1.3.6 Drug Information

The EHRi Drug Domain services support EHR user requests to retrieve patient clinical data from the Drug domain repository system interface for display.

The following EHRi Drug Domain service operations represent the subset of patient centric queries that would be consumed by an EHR user in the context of an EHRi system. These services are supported by the Clinical Drug (Rx) Messaging standard.

List Prescription Dispenses - Find all dispenses for a specific prescription (for a patient).

List Dispense History - Find what drugs have been dispensed / filled for a specific patient over a specified time period. a.k.a. Patient Dispensed Drugs Query.

Get Dispense Details - Dispense details for a specific drug dispense, including notes.

List Unfilled Prescriptions - Find all prescriptions, for a specific patient that has never been filled.

List Outstanding Prescriptions - Find all prescriptions for a specific patient that are either [1] never filled or [2] have outstanding refills or [3] both [1] & [2], by prescriber

Get Prescription Order Summary - Provide a list of prescriptions that have been prescribed for a specific patient

Get Prescription Order - Used to get all the details about a specific prescription searching by prescription number. Dispenses are not included in the response.

Get Medication Details - For a specific patient, list all prescriptions ordered but not filled + ordered and partially or completely filled + other active medications + filled with no order. Focus is on complete details for included prescriptions.

Get Drug Profile - For a specific patient, list all prescriptions ordered but not filled + ordered and partially or completely filled + other active medications + filled with no

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxxi

859860861862863864866867868869870871872873874875876877878879880881882883884885886887888889890891892


order. Focus is on summary information for included prescriptions. Get Other Medication Details - Used to get all the details for one specific other active

medication for a patient. Get Drug Complete Record - An extended feature allowing to retrieve the entire

record maintained in the drug domain service for a single client. This will return several types of data structures packaged into a single message. The criteria includes client id, date range, last record fetched bookmark and paging size value.

class Drug Infor...

Drug Information

Figure: 149.1.3.7 Laboratory

A key distinction needs to be made between solutions focused on enabling a view into laboratory results and order information as a supporting set of data for results. This is in contrast with more elaborate organizational laboratory information system solutions designed to enable the management, and potentially the automation of, the workflows associated with the process of laboratory based testing.

Early generation solutions are expected, at a minimum, to be able to compile laboratory results as well as the accompanying data (such as the preceding orders) so that a view of this consolidated information can be provided to caregivers. In its simplest state, the Laboratory domain system will compile laboratory testing related events from source systems such as an order, a sample, and a result and allow for access to this data on the basis of standards-based message queries to retrieve any of this information. More advanced solutions will provide that basic capability and will also support workflow automation and business logic to manage the status of orders and result generation and will also interact with source systems in a much more proactive fashion to generate alerts and notifications or to expedite processing.

The Laboratory Domain service is expected to interact, through standards-based messaging, with laboratory systems used for generating and managing orders in facilities as well as with systems used in sampling and testing facilities to produce results. In other words users acting as clinicians and lab technicians in laboratory Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxxii

893894895896897898899900

901902903905906907908909910911912913914915916917918919920921922923924925926


facilities are expected to use their local information system solutions to conduct their work. These applications, by way of being connected to an EHRi will be able to publish or promote key relevant results data to the Electronic Health Record of patients. Similarly, CPOE applications used by caregivers in hospitals, clinics will be able to promote order information to patient health records through the same type of connectivity with the EHRi.

Get Lab Orders - Allows to retrieve a specific lab order for a patient.

Get Lab Results - Allows to retrieve a specific lab result for a patient.

List Lab Orders - Allows to query a list of a patient’s lab order with criteria such as:• Type of Lab Orders• Date Range• Service Location• Ordering Physician

List Lab Results - Allows to query a list of a patient’s lab results with criteria such as:• Type of Lab Results• Date Range• Service Location• Ordering Physician

Get Lab Complete Record - An extended feature allowing to retrieve the entire record maintained in the Lab domain service for a single client. This will return several types of data structures packaged into a single message. The criteria includes client id, date range.

class Laboratory

Laboratory

Figure: 15

9.1.3.8 ESB-Engineering Service Bus

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxxiii

927928929930931932933934935936937938939940941942943944945946947948949950951952953

954955956957


class ESB-Engineering Serv ice Bus

ESB-Engineering Serv ice

Bus/Serv ices

Common Serv ices Communication Bus/Serv ices

Figure: 169.1.3.9 Common Services

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxxiv

959960961


class Common Serv ices

Common Serv ices

Figure: 17

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxxv

963964965


9.1.3.10 Messaging class Messaging

Messaging

En/Coding Serv ices

Parser Serv ices Routing Serv ice Serialization Serv ices

Transformation Serv ices

Encrypt/Decrypt Serv ices

Figure: 18

9.1.3.11 En/Coding Services coding formats such as Unicode, UTF-8, and Base64 etc.

class En/Coding...

En/Coding Serv ices

Figure: 19

9.1.3.12 Encrypt/Decrypt Services

class Encrypt/D...

Encrypt/Decrypt Serv ices

Figure: 20

9.1.3.13 Parser Services

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxxvi

966

967968969970972

973974975976977978979

981982983984


class Parser Se...

Parser Serv ices

Figure: 21

9.1.3.14 Routing Service class Routing S...

Routing Serv ice

Figure: 22

9.1.3.15 Serialization Services class Serializati...

Serialization Serv ices

Figure: 23

9.1.3.16 Transformation Services class Transform...

Transformation Serv ices

Figure: 24

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG)

Page xxxvii

986987988989

991992993994

996997998999

100110021003


9.1.3.17 Protocol Service Components class Protocol Serv ice Components

Protocol Serv ice Components

Application Protocol Serv ices Network Protocol

Serv ices

Figure: 25

9.1.3.18 App Protocol Services class App Protocol Serv ices

Application Protocol Serv ices

Figure: 26

9.1.3.19 Network Protocol Services class Network P...

Network Protocol Serv ices

Figure: 27

9.1.3.20 Communication Bus/Services

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG)

Page xxxviii

1004

1006100710081009

1011101210131014

1016101710181019


class Communication Bus/Serv ices

Communication Bus/Serv ices

Figure: 28

9.1.3.21 HIAL – Health Information Access Layer The Health Information Access Layer (HIAL) is a gateway that acts as an abstraction layer to separate PoS applications from the EHR Infostructure. It is made up of service components, service roles, information models and messaging standards required for the exchange of EHR Data and the execution of interoperability profiles between EHR Services. The HIAL is broken down into two layers of services: the common services and the communication bus services.Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xxxix

1021102210231024102510261027102810291030


class HIAL – Health Information Access Layer

HIAL – Health Information

Access Layer

EHRS Locator

Figure: 29

9.1.3.22 Health Information Data Warehouse

While this is the primary goal of the EHR Infostructure, a lot can be said for the healthcare value derived from being able to use this information for research, analysis and health prevention initiatives. Key examples of such uses include public health surveillance, public health reporting and tracking of key health indicators, health research analysis, cancer care research, etc…

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xl

1031

10321033103410351037103810391040104110421043


To support these types of uses, a separate data analysis environment is required and online transactional data needs to be moved to a data warehouse environment where data can easily be manipulated and transformed to meet such analysis requirements.

class Health Information Data Warehouse

Health Information Data Warehouse

Figure: 30

9.1.3.23 Longitudinal Record Services

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xli

104410451046

10471048104910501051


class Longitudinal Record Serv ices

Business Rules

EHR Index Message Structures

Normalization Rules

Longitudinal Record Serv ice (LRS)

Figure: 31

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xlii

10531054


9.1.3.24 Business Rules validation and logical process rules objects that are assembled at run time to execute the business logic applicable to a given type of I-IP transaction being processed. The business rules can be hard coded into Domain Business Components or can be applied dynamically through the Business Rules Services.

class Business ...

Business Rules

Figure: 329.1.3.25 EHR Index

The responsibility of the EHR Index within the framework of an interoperable EHR is to offer an efficient discovery mechanism within the EHR infostructure (EHRi) that provides EHR consumer applications a normalized, patient-specific and aggregated list of EHR data components that fit a given search criteria.

The EHR Index holds metadata about each person’s records. As information about a patient is published to any of the EHRi data repositories, the repository sends selected attributes to the EHR Index which will allow faster and easier selection of that EHR data in subsequent queries. All queries for longitudinal view will be applied against the EHR index allowing for very fast discovery of which EHR data fits the given selection criteria. If the EHR consumer desires more complete and detailed information about the particular EHR data entry, then a specific transaction will be sent directly (via the EHRi) to the repository where that particular EHR data is stored. This retrieval system interaction will use the specific set of messages that are applicable to the class of EHR data being retrieved by the EHR consumer.

There are, however, two basic assumptions for the approach to work most effectively:1. the metadata on stored events is sufficient to address the EHR Index queries2. the metadata is normalized at the time the EHR index is updated by the repositories.

The result of the above strategy is that for each EHRi instance, an EHR Index will maintain a sequential list of all events, documents and other EHR data that create the clinical picture of a client. It also provides the location where the detailed data relevant Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xliii

105510561058105910601061

106210631064106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089


to each entry is kept in the EHRi. It can be used to retrieve the history of events for a client or to trace the information about a specific event. As one of the components of the Longitudinal Record Services (LRS) in each organizational EHRi, the EHR Index must support a wide range of queries of different types of EHR data and provide consistent responses to the EHR consumers. The figure below shows the various components that make up the LRS, including the EHR Index Services (aka EHR Index).

class EHR Index

EHR Index

Figure: 33

9.1.3.26 Message Structures class Message ...

Message Structures

Figure: 34

9.1.3.27 Normalization Rules class Normalizat...

Normalization Rules

Figure: 35

9.1.3.28 Registries, Data and Services

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xliv

109010911092109310941095

1096109710981099

1101110211031104

1106110711081109


class Registries, Data and Serv ices

Clinical Registry Location Registry Prov ider Registry Terminology Registry

Registries, Data and Serv ices

Figure: 36

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xlv

1111111211131114


9.2 Interoperability Specifications (IS)9.2.1 Service Aware Interoperability Framework (SAIF)

class Serv ice Aware Interoperability Framework (SAIF)

Information Model

Behav ioral Framework (BF)

Gov ernance Framework (GF)

Enterprise Compliance and Conformance Framework (ECCF)

Information Framework (IF)

Serv ice Aware Interoperability Framework (SAIF)

Behav ioral Model Business Model

Canonical Definition

Implementation Guide

Dynamic Specification

Static Specification

Business Rules

Implementation Specification Template (IST)

Interoperability Specification Instance (ISI)

Implementable Instance

has-a

has-a

1..*1..* 1..*

has-a

1..*has-a

1..*

has-ahas-a

has-a has-ahas-a

1..*

has-a

1..*

has-a

Figure: 37

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xlvi

111511161117

11191120112111221123


9.2.1.1 SAIF Concept Map mmd SAIF Concept Map

SAIF

InformationFramework (IF)

GovernanceFramework (GF)

EnterpriseArchitecture

BehavioralFramework (BF)

Enterprise Compliance andConformance Framework (ECCF)

EnterpriseStructure

FoundationalPrinciples

BusinessArchitecture

SystemArchitecture

TechnicalArchitecture

InteroperabilitySpecification

InteroperabilitySpecification Stack

(Profi le)


(Implementation Instance)

populates

populates

manages

supports

defines concepts and structuring rules

maintains

goal

apply to


(Subject/Type)

SAIFConanicalReference

SAIFImplementation

Guide

SAIFImplementation

Instance

Figure: 42

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xlvii

1124

11251126112711281129


9.2.1.2 SAIF Behavioral Framework (BF) class SAIF Behav ioral Framework (BF)

Functional Profile

Serv ice Interface

Serv ice

Operation

Precondition

Postcondition Exception Condition

Signature Exchange

Term of Art

Operation Semantics

Contract Semantics

SAIF CD

GF

ECCF

BF

BF Language

Process Semantics

Role

Operation

Responsible Agent

Comissioning Agent

Object

Contract

Party

CommunityComponent

PolicyPermission

Prohabition

Obligation

has-a

has-a

has

correspond to

has-a

Figure: 38

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xlviii

1130

11311132113311341135


9.2.1.3 SAIF Information Framework (IF) class SAIF Information Framework (IF)

Data

Concept

Metadata Binding

Information

Terminology

Conceptual Information Model

Logical Information Model

Implementable Information Model

Information Model

Archetype / DCM Filler

Value Set

Class

Terminology Binding

FHIM

VHIM

Term

Reference Information Model

Schema

Serv ice Aware Interoperability Framework (SAIF) Information Framework (IF)

Enterprise Compliance and Conformance Framework (ECCF)

0..*

has-a

defineslanguage

is-a

scopes

*has-a

has-a

has-a

has one-or-more

binds-to one-or-more

has one-or-more

has-a

has-ahas-a

is-a

has-a

is-a

is-a

*

has-a

has

has-a

*has-a

is-modelled as-a0..*

Figure: 39

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page xlix

1136

11371138113911401141


9.2.1.4 SAIF Governance Framework (GF) class SAIF Governance Framework (GF)

SAIF CD

GF

ECCF

GF Language

GF Terms of Art

Interoperability

Provence

Accountability Responsibility Community Role

Authority

Community Contract

Jurisdiction

PartyCommunity

metricsBusiness Processes People (Roles)Precepts

Objectives

Standards Policies

Guidelines

Process Definition

Communication Process

Appeal Process

Rev italization Process

Gov ernance

Shared PurposeManagement Methodology

define a general framework as

BF

influences influences

has-a

is specified by

has-a

has-a

maintained via

uses

Figure: 40

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page l

1142

11431144114511461147


9.2.1.5 Enterprise Compliance and Conformance Framework (ECCF) class Enterprise Compliance and Conformance Framework (ECCF)

ECCF Terms of Reference

Prov enance

Traceability

Localization

Compatibility

Correspondence/ Consistency

Compliance

Conformance

ECCF Language

SAIF Implementation

Guide (IG)

Implementation Specification Matrix (ISM)

Implementation Specification Template (IST)

Interoperability Specification Instance (ISI)

Subject

Artifacts

Component

Conformance Statement (Boolean)

Implementation Instance

Conformance Assertion (Boolean)

Shared Purpose Conformance Testing

Conformance Certification

1..*

Figure: 41

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page li

1148

11491150115111521153


9.2.2 Information Model Within iEHR class Information Model Within iEHR

Interoperable EHR (iEHR)

Information ExchangeData Store

Information Model

Message DocumentServ ice

InterfaceCommon Information Interoperability Framework (CIIF)

Interoperability Specification (IS)

Behav ioral ModelBusiness Model

has-ahas-a

has-an has-anhas-an

is-a is-ais-a

is-an

has-andefines supports

has-a

has-a

has-an

Figure: 43

9.2.2.1 iEHR Information Meta-Model class iEHR Information Meta-Model

Data

Concept

Metadata Binding

Information

Terminology




Information Model


Value Set

Class

Terminology Binding

Term

is-modelled as-a

*has-a

has-a

hasis-a

is-a

is-a

0..*has one-or-more


has one-or-more

has-a*

has-a

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page lii

1154

1155115611571158

1160


Figure: 44

9.2.2.2 Information Meta-Model class Information Meta-Model

Data

Concept

Metadata Binding

Information

Terminology




Information Model


Value Set

Class

Terminology Binding

FHIM

VHIM

Term

is-a

has-a

has-a

has one-or-more


has one-or-more0..*

*has-a

has-a

is-a

*

has-a

has

has-a

*has-a

is-modelled as-a

is-a

Figure: 45

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page liii

116111621163

116411651166


9.2.2.3 Terminology Meta-Model class Terminology Meta-Model

Terminology

Code System

Semantic Type Code System Taxonomy (e.g., SNOMED CT, LOINC)

Controlled Terminology

Descriptiv e Logic (DL) Based Referenc-Terminology

Ontology

Vocabulary

Strong TaxonomyWeak Taxonomy

Subsumption Hierarchy

Parent

Child

Classification (e.g., ICD-9/10)

0..* has-a

has-a

has-a

is-a

0..*

has-a

is-a is-a

is-a

0..* has-a

is-a

0..* has-a

is-a

is-a

is-ais-a

0..* has-a

is-a

Figure: 46

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page liv

1167

116811691170


9.2.2.4 Data Meta-Model class Data Meta-Model

Data

Data Type (DT)Simple DT

Complex DT

DT Flav or

Canonical DT

Nominal DT

Ordinal DT

Quantitativ e DT

Narrativ e Text DT

Binary DT

is-a templateis-a

is-a

is-a

is-a

is-a is-a

is-a

is-a

is-a

Figure: 47

IndexHIAL, iii, 5, 6, 7, 9, 14, 35Longitudinal Record Services, iii, 3, 6,

22, 37, 40

LRS, 6

Health Architecture Interagency Group (HAIG)Document Title: interoperable EHR (iEHR) Implementation Guide (IG) Page lv

1171

1172117311741175117611771178

1179

1180