Iehr ciif sdk-slides-draft-h

iEHR-CIIFWORKING DRAFT: not for wide distribution or official use. 1

Open Source EHR Custodial Agent (OSEHRA) Architecture CommitteeStephen Hufnagel PhD, Chair

&Health Architecture Interagency Group (HAIG)

Nancy Orvis, MHA, CPHMS and Paul Tibbits, M.D., DoD and VA Co-Chairs

Current version is always available at: http://www.osehra.org/node/47/content/documents

October 9, 2011 DRAFT-H

Software Development Kit (SDK) for Interoperable EHR (iEHR)

Common Information Interoperability Framework (CIIF)

CALL FOR PARTICIPATION

Please send updates and suggestions for improvement to

[email protected]

http://www.osehra.org/node/47/content/documents


ACKNOWLEDGEMENT

This iEHR-CIIF SDK started with the most excellent Canada Health Infoway “Electronic Health Record Blueprint” as a foundation; the SDK is being adapted to meet the US OSEHR, DoD and VA interoperable EHR situation and needs.

https://www.infoway-inforoute.ca/working-with-ehr/knowledgeway/knowledge-center/657

A five color star “branding” indicates that a slide was adapted from Canada Health Infoway’s EHR Blueprint

https://www.infoway-inforoute.ca/working-with-ehr/knowledgeway/knowledge-center/657

iEHR-CIIFWORKING DRAFT: not for wide distribution or official use.

PrefaceIn 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 or 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.

This iEHR-CIIF SDK is a part of the journey to implement the vision expressed above.

33


PurposeiEHR is a part of a joint DoD-VA Open Source EHR (OSEHR) Initiative

• The interoperable EHR Common Information Integration Framework (iEHR-CIIF) Software Development Kit (SDK) presents the vision (slide deck) and specifies the means (technical document) for Open Source and COTS applications to plug-and-play with DoD-VA’s future-state open-source interoperable-EHR kernel-operating-system and data-store (s); the kernel is an n-tiered set of “information” services for best-of-class 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 iEHR Implementation Guide (IG) for vender and open-source developers.

YOUR HELP IS REQUESTED IN VERIFYING, VALIDATING AND INCREASING THE

USABILITY OF THE iEHR-CIIF SDK

44


Benefits

D R A F T Talking Points

The SDK ensures consistency across

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

– Interoperable Virtual Database (DB) APIs scalable from• Legacy MUMPS-globals acting as a DB to CDR/HDR to HAIMES II to• Massively-parallel high-performance grids running on commodity-hardware-blade-platforms (i.e.,

amazon.com & google.com models).

– Interoperable Trading Partners

– Acquisitions (SDK as GFI for RFIs and RFPs)

– VA, DoD and IHS offices, staff and contractors

– Open Source Community

5


Transition Strategy

6

1. The iEHR-CIIF set-of kernel-and-data services MUST be set-up at one-or-more data-centers. 2. For pre-certification self-testing and attestation, venders and developers MUST be provided: i) SDK, ii)

an open-source test virtual-machine (VM) with the iEHR’s set-of kernel-and-data services, iii) clinically-meaningful test-database, test-scripts, OSEHRA certification-criteria.

A. OSEHRA certified applications, their test and certification test-VM, test scripts and test-results MUST be made available to anyone who wishes to verify test results attestations.

B. Agile SDK, kernel and application development and certification processes require certification up-to-date VMs and ongoing OSEHRA recertification to maintain “VA’s class 1 software” status.

3. One-or-more user-configurable iEHR viewers MUST be made freely available. 4. Legacy systems MUST be updated to “journal” their clinically-relevant data-store transactions with the

iEHR data-store and to query the iEHR, analogous to legacy DoD-VA sharing; legacy-CIIF terminology harmonization MUST be a part of a transition.

5. To be repurposed to iEHR capability, legacy applications MUST meet the SDK’s iEHR kernel-services interoperability specifications and OSEHRA certification criteria.

6. Once appropriate iEHR viewer(s) and iEHR certified applications are available to clinical users, they can transition to iEHR-CIIF based systems, while others might continue on legacy systems.

7. Clinically-meaningful legacy-data MUST be extracted to iEHR before legacy systems are shut down.

6

Outline

7

Understanding iEHR-CIIF

iEHR-CIIF SDK Scope

Business Context

Clinical/Work Process Architecture

System Architecture

Information Architecture

Integration & Deployment Options

Potential Applications

Summary & Conclusion

iEHR-CIIFWORKING DRAFT: not for wide distribution or official use


Understanding the Interoperable EHR (iEHR) Common Information Infrastructure Framework (CIIF)

• The iEHR-CIIF is a business-driven agile enterprise-information-management methodology and set of software-service technologies, which enable semantic interoperability of clinical data.

• The iEHR-CIIF Team specifies, implements, or imposes a standards-based set of iEHR foundational services that enables any authorized iEHR enpowered provider to care for any beneficiary regardless of location, organization or device.

88See notes page


iEHR-CIIF Benefits

• Increases availability & accessibility of information patient safety & quality of care

• Eliminates/reduces costly data mapping • Clarifies & communicates improved requirements (for vendors)• Provides common reproducible software development processes

(interoperability design patterns)• Encourages faster-and-lower-cost changes• Supports efficient legacy transition to modernized systems• Assures consistent information context and meaning

99


iEHR-CIIF SDK Scope

WORK PROCESS INFORMATION SYSTEM TECHNOLOGY

framework V1framework V2

iEHR-CIIF CONCEPTUAL LAYER ADDRESSES BUSINESS CONTEXT(Mission, objectives, stakeholders, benefits)

iEHR-CIIF Implementations

framework V2framework V1framework V2

Conceptual

framework V2 framework V2 framework V2Logical

Physical

YES YES YES

YES YESYES

11

Architecture Perspectives

CONTEXT

BusinessArchitecture

ClinicalWork ProcessArchitecture

PotentialApplications

Integration &Deployment

Models

SystemArchitecture

InformationArchitecture


12


CONTEXT





Models

SystemArchitecture



13

Business Context


Healthcare Industry

14

Provides $

Patient

Planning &Resources

VHA, MHS, IHS, SSA, State Agencies, etc.

Clients/PatientsProviders

Tax $$$

Planning &Resources

Pharmacy

Laboratory

Diagnostic

Hospital Emergency

Specialist Clinic

Homecare

Community Care Center

Elected Federal

Government

Federal Agencies and States

Emergency Services



International Industry: IT Spending Comparisons

IT spending as a % of total expenditures

1.2

1.4

1.6

1.7

1.9

2.2

2.7

3.3

4.2

5.5

5.7

12.1

Food & Bev

Canadian Healthcare

Pulp & Paper

Petroleum

Manufacturing

Textiles

Utilities

Transportation

Worldwide Health Providers

Telcos

Government

Financial Services

SOURCE: Gartner Group – as reported in the Health Services Restructuring Commission’s (www.hsrc.gov.on.ca) report: Ontario Health Information Management Action Plan, June 1999

This slide needs to be updated or

removed

This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs.

Please send suggested updates to [email protected]

mailto:[email protected]


SOURCE: 2003 Report on I.T. in Canadian Hospitals: Top issues, applications and vendors. Canadian Healthcare Technology, 2003. CIHI NHex 2002 (Hospital Expenditures)

IT budgets as a % of total hospital budget

10

12

27

27

25

0 5 10 15 20 25 30

2.5% or more

2-2.4%

1.5-1.9%

1-1.4%

less than 1%

Mean Hospital: IT spending in Canada <2%


removed




Why an iEHR? The World of Healthcare is Changing…

The Old WorldProvider-focused

Illness centric

Site-of-care centric

Episode Management

Supply Management

Solitary decision making

Inefficiency

De-centralized, generalized care

The New WorldPatient & family-focused

Medical home and wellness care

Continuum of care & case management

Disease and demand management

Collaborative, evidence-based decisions

Meaningful-Use objectives, metrics & criteria

Patient safety, quality and effectiveness

Centralized, specialized care

17iEHR-CIIFWORKING DRAFT: not for wide distribution or official use See notes page

Why an iEHR-CIIF? The World of Healthcare is Changing…

The changes in healthcare require significant capability from the health infostructure; this capability does not fully exist today

18iEHR-CIIFWORKING DRAFT: not for wide distribution or official use


• Political will

• Funding is now available

• mandated to pursue investments

CONVERGENCE

The Timing Has Never Been Better!

WILL

• Public wants more accessibility

• Health Authorities recognize benefits

• Increased financial pressures

• Healthcare professionals embracing technology

• Willingness to collaborate

CAPACITY

• Better infrastructure

• More mature application technologies

CAPABILITY

iEHR-CIIFThis Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs.



20

iEHR-CIIF: Key Concepts


EHR

An Electronic Health Record (EHR) provides each individual with a secure and private lifetime record of their key health history and care within the health system. The record is available electronically to authorized health providers and the individual anywhere, anytime in support of high quality care.

This record is designed to facilitate the sharing of data – across the continuum of care, across healthcare delivery organizations and across geographies.


Interoperable EHR Solution

22

The Interoperable EHR Solution is a combination of people, organizational entities, business processes, systems, technology and standards that interact and exchange clinical data to provide high quality and effective healthcare.

iEHR-CIIFWORKING DRAFT: not for wide distribution or official use See notes page

EHR Information Infrostructure (EHRI)

23

The EHR Infostructure is a collection of common and reusable component-services in support of a diverse set of health information management applications. It consists of interoperable software-solutions for the EHR, semantically-interoperable data and terminology for the EHR and secure information-exchange standards for the EHR.

iEHR-CIIFWORKING DRAFT: not for wide distribution or official use See notes page


Providers• Relevant data, granular,

computable if needed

• Real time

• Rapid access from multiple locations, anywhere, anytime

• Decision support• Clinical reference data• Guidelines & protocols• Common terms & codes

• Case management & workflow

• Safety

• Improved quality of care

• Regulation & accountability

Authoritative,reliable, secure,

private

Patient/Public/Clients• Convenient, relevant access to

accredited health information

• Access to relevant personal health information

• Safety

• Improved quality of care

Public Sector Health Managers• Registry solutions & initiatives

• Objective analysis of results & benefits

• Management reports

• Funding & resource allocation

• Policy

Payer/Payee• Relevant data to adjudicate claim

• Workflow management

Researchers & Health Surveillance Professionals

• Computable data

• Appropriately summarized data

• Anonymized in framework

• Designed for analysis:• Statistical sampling• Trends• Outbreak detection• Outcome analysis

• Regional

• National

iEHR-CIIF Outcomes

iEHR-CIIF This Canada Health Infoway based slide needs to be verified and validated for the US OSEHR, IHS, DoD & VA situation and needs.




Key iEHR-CIIF Architecture Concepts

Interoperable EHR SOLUTION (iEHR-CIIF)

EHR INFOSTRUCTURE (EHRi)

EHR ViewerPoint of Service

ApplicationPoint of Service

Application

iEHR-CIIFLocator

Longitudinal Record Services (LRS)

Common Information Interopérability Framework (CIIF)

Population HealthData &

Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services


Please send suggested updates to [email protected] See notes page



iEHRiEHR iEHRiEHR iEHR iEHRiEHR

iEHR-CIIF Framework Recommended Approach: A DoD. VA & Purchased Care EHR Service

Interoperable EHR SOLUTION (iEHR)



Application

Point of Service

Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services






Application

Point of Service

Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services



26





iEHR-CIIF Infostructure: Conceptual ArchitectureORGANISATIONAL INFOSTRUCTURE

Population Health Data& Services

Registries Data& Services

EHR Data& Services

DataWarehouse

OutbreakManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

POINT OF SERVICE

Hospital, LTC,CCC, EPR

PhysicianOffice EMR

EHR Viewer

Physician/Provider

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtData

Privacy Data Configuration

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist

Public HealthServices

Public Health Provider


CIIFSecure Communications Bus

Common Services

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry





Guiding Principles for iEHR-CIIF

• Patient-centric

• Easially customized views of all clinical data

• Value add for the provider

• Timely, accurate information

• Enable sharing at local, regional, cross-organizational

• Interoperable, integrated applications

• Standards based

• Computable where required

• Replicable solution – patterns, components

• Leverage legacy systems & solutions• VA VistA

• MHS AHLTA

• Open Source Applications

• Design for phased rollout with near term results

• Scalable• Individual provider’s Point-of-Service (POS)

• Specialty, Ancillary, Public Health POSs

• Interoperating with large -o-massive Enterprise

• Extensible to support future growth

• Pragmatic and Cost-effective

• Secure & private

• Allow for innovation & competition• Open Source commodity applications

• Best –of-class COTS applications

• Comprehensive





Generations of EHR Capabilities

Full

Functionality

Minimal

Gen 4The Colleague

Gen 2The Documentor

Gen 3The Helper

Gen 5The Mentor

Availability of Products

1993 1998 2005 2010 2015+

Gen 1The Collector

Source: Gartner (December 2005)

End of 2009

This slide needs to be updated

See notes page


A Few Misconceptions About Interoperable EHR Solutions

Misconception• A person’s health data is in only one

physical EHR

• All data for a person must be in the EHR to have value and generate adoption

• An Organization is a provider practice

• The EHR is a data warehouse to support research and surveillance

Reality• EHR: an integrated service covering

all available Interoperable EHR Solutions; a client’s record is seen as coming from a single integrated EHR

• Quality, safety & effectiveness enhanced with only subsets of clinically relevant data available for sharing

• An organization is any geo-political entity mandated or chartered to govern the operation of an Interoperable EHR Solution

• The iEHR-CIIF: an information support service available to caregivers in the daily context of care provision work activities





Great Impact on links between components (e.g., interoperability)

Little Impact on links between components(e.g., Interoperability)

Little impact on components

Great impact on components

Architectural

Innovation

Radical Innovation

Incremental

Innovation

Modular Plug-&-

Play Innovation

End

Archite

ctural

Visio

n for

Seman

tic Int

erope

rability

Start

Future-State-Architecture GOAL

OBJECTIVEA change-immune domain-specific component-

architecture emphasizing interoperable standards-based services, resulting-in simpler, loosely-coupled, and less-

costly module-level innovation.

PROBLEMLittle innovation, long lead times and

high costs resulting from complex highly-coupled components

31


March 2011 Version

Common Interface Standards

Presentation(Common GUI)

Common Data Centers

Common Services Broker(includes Enterprise Service Bus (ESB) and Infrastructure Services)

PresentationLayer Team

SystemsCapabilitiesTeam

EnterpriseArchitectureTeam

Data Inter-operabilityTeam

MissionRequirements& Performance Outcomes Team

BusinessProcessTeam

Common Information Interoperability Framework (CIIF)Common Information Model, Common Terminology Model,Information Exchange Specifications, Translation Service

Common Data Standards: SNOMED CT and Extensions, LOINC and RxNorm

DoD Only VA Only Joint DoD/VA

Pharmacy

DisabilityEvaluation

Dental Care

PersonalHealth Record

InpatientOrders Mgmt

Consult &Referral Mgmt

Immunization

Laboratory

EmergencyDept Care

Nursing Home

RehabilitativeCare

Long Term Care

TransientOutreach

DoD Unique (16) VA Unique (6)Common (Joint) Applications & Services (30)Battlefield

CarePediatrics

MilitaryReadiness

Obstetrics

Enroute Care

VeterinaryOperating

Room Mgmt

Blood Mgmt

DocumentMgmt

Applications and Services

Common DoD-VA Requirements: HL7 EHR-S Functional Model with DoD and VA vetted Extensions (SV-4)Common DoD-VA Integrated Health Business Reference Model (OV-5)

Common DoD-VA “To Be” Process Flow Model (OV-6C)

Common DoD-VA Measures of Effectiveness, Measures of Performance and key Performance Parameters

OccupationalHealth (VA)

PharmacyMail Order

Common Interface Standards

iEHR ‘Cherry’ Architecture

04/12/2332

See notes page


Coordination Across the Enterprise

CommonServices

Bus (CSB)

CIIF

Infrastructure

Rules EngineTechnical Services

ServicesCommunications

Translation ServiceMDR

Terminology ModelServices Model

Information ModelRule Set

Mapping to LegacyData Standardization

Physical Data Model

CachingDatabase

TopologiesLatency

Outside• Clinical Measures• Capabilities• Applications• Adapters

33See notes page


The CIIF drives the iEHR run-time environment

04/12/2334


Rules EngineMediation ServicesTranslation Services

Common Information Interoperability Framework (CIIF)Common Information Model, Common Terminology Model, Information Exchange Specifications,

Translation Service Common Data Standards:

Pharmacy Delivery Use Case – The CIIF Leads the Way

35See notes page

36

Business/Clinical Scope



iEHR-CIIF Serving Healthcare Service DeliveryInteroperable EHR SOLUTION (iEHR)



ApplicationPoin of Service

Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services







Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services


Diagnostic

Hospital Emergency

Specialist Clinic

Homecare

Clients/Patients


Emergency Services

Pharmacy

Laboratory

Diagnostic

Hospital Emergency

Specialist Clinic

Homecare

Clients/Patients


Emergency Services

Pharmacy

Laboratory






Population/Public Health Business Requirements

• Focuses on managing health status of populations

• Managed and executed through complex network of public/private organizations acting at different levels of the health system (Federal, State, Regional, Local, Individual)

• Involves:• Research & analysis to identify/define population health programs

• Surveillance activities to detect and pro-actively react to potential population health problems

• Application of health programs to prevent the appearance and/or dissemination of preventable diseases

• Active management of communicable disease outbreaks

• Active management of the delivery of health services to individuals in the context public health related programs

• Current focus limited to:• Surveillance and detection (focused on human health-related diseases)

• Outbreak Management

• Public Health Alert Management

• Disease Information Dissemination

• Immunization Management

• Communicable Disease Case Management





Integrating Population/Public Health in the Architecture

Candidate services required to support:• Surveillance & Detection: There is a business need for a Health information data warehouse

• Outbreak Management: requires the addition of a new category of service called Population Health Services where a specific service is introduced to address outbreak management; analogous services will evolve.

• Common Information Integration Framework (CIIF): addresses the need for a formal terminology registry system that maintains information and terminology models for clinical domains and other key terminologies required for many services of the iEHR

• Public Health Alert Management• Public health disease alert reporting requires use of specific applications also positioned as Population Health services

• Public health alerts dissemination relies on terminology registry and CIIF Alerts and Notification services

• Immunization Management• Immunization programs and their management requires a specific application that would live under the Population Health

services category

• Delivery of immunisation would be tracked by the drug information domain as part of the EHR

• Communicable Disease Case Management• Delivery of health services in relation with the treatment of a CD case would be tracked by the shared health record and other

domains as part of the EHR

• Management of a CD case from the perspective of the public health specialists involved in detection and tracking would require a specific application that would live under the Population Health services category





Integrating Public Health in the Architecture

Some Public Health business requirements can be sustained by theexisting services of the EHR Infostructure• Public Health Alert Management: CIIF and LRS to provide for mechanism to help with

detection & reporting on communicable diseases

• Immunization Management: Drug Information Domain is the home of immunization information as part of the core clinical data in client’s health records. CIIF and LRS to provide mechanisms to communicate the data and coordinate its location and access within the EHRi

• Communicable Disease Case Management: CD Cases, from the perspective of the EHR are treated like any other health delivery encounter





POINT OF SERVICE

ORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse

OutbreakManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtData




Common Services

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

Hospital,Community,etc… EPR

PhysicianOffice EMR

EHR Viewer

Physician/Provider

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist

Other PHSystem(s)

Public Health Providers

Public Health Surveillance Portal

PHS Systems

Operational data

CM OM AM IM*PHS

A

iEHR-CIIF Serving Public Health Service DeliveryImmunization

“Registry“

ReferenceManagement

PHS DataWarehouse

Services

CaseManagement

Alert NotificationServices

MessagingContent &

KnowledgeManagement

Security &Privacy Services





Telehealth Business Requirements

• Telehealth: the use of information & communication technologies to deliver health services in contexts where the providers and clients are in separate locations

• Telecommunication infrastructure is a pre-requisite

• Telehealth solutions enable health service delivery channels:

Tele-consultations Tele-education Tele-homecare Tele-triage

• Scheduling solutions – a key enabler required for the effective use of telehealth service delivery

• EHR Infostructures support telehealth applications as per any other Point-of-Service Application

Videoconferencing stations, communication enabled medical devices

Videoconferencing stations used for training/education

Active or passive monitoring of remote patients for pre-/post-op procedures, chronic diseases management, etc

Centralized call centers to offer first line delivery of service to clients as part of primary care and emergency response








EHR Data& Services

DataWarehouse

OutbreakManagement

PHSReporting

HealthInformation

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtData




Common Services

iEHR-CIIF Serving Telehealth Scheduling

POINT OF SERVICE

Referring Physician

Site

Attending Physician

Site

Physician/Provider

Physician/Provider

TSADatabase

PatientInfo

End-userInfo

EventHistory

ClinicalProfile

SchedulingVideo

Session

Telehealth Scheduling Application (TSA)

SharedHealth Record

DrugInformation

DiagnosticImaging

Laboratory

ProviderRegistry

LocationRegistry

TerminologyRegistry

ClientRegistry




iEHR-CIIF Framework: Tele-Consultation

44



Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services


Common Interoperable Information Infrastructure (CIIF)



Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services



Local ElectronicMedical Record

Live Video-ConferencingSession

Tele-Consultation Devices Data

TelehealthApplication

TelehealthApplication

Local ElectronicPatient Record







Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services





Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services



iEHR-CIIF Framework: Tele-Homecare

45

Local ElectronicMedical Record

Tele-Homecare Data Feed

Tele-Consultation Devices

HomecareApplication Server

HomecareClient Application







Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services





Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services



iEHR-CIIF Framework: Tele-Triage

46

Tele-TriageApplication

Patient Info End-user Info

EventHistory

ClinicalProfile

Scheduling Video Session

Personal Health Record

Application

EHR Viewer





47

Clinical, Business & Socio-economic Drivers for Interoperable EHR SOLUTIONs



Why is Value Created by an Interoperable EHR SOLUTION?

• Healthcare professionals make clinical decisions based on knowledge• Encounter and Case Management,

• Care Plan,

• Health Concern Tracking

• Analytics

• Better knowledge translates to better care

• Knowledge starts with accurate, relevant clinical information

• The EHR creates the capability to share relevant clinical information

• The 5 Rs of the EHR:• The right information

• About the right client

• Available to the right person

• In the right place

• At the right time





# of Data Domains Included

(Encounter Summaries, Lab, DI, Drugs, etc.)

Extent of the Care Continuum Involved

(PCP office, Hospital, Long Term Care Homecare, etc.)

Local C

are Area

Natural R

eferral A

rea

Point ofgreatest value

The value of the iEHR for clients, families and their providers increases with the completeness of the information contained as well as the level of standardization of the data

How Is Value Delivered By An iEHR?





Pharmacy

Laboratory

DiagnosticHospital Emergency

Homecare


Clinic Emergency Services

Specialist Clinic

Why Pursue The iEHR-CIIF: Circle of Care

See notes page


QUALITY SAFETY

ACCESSIBILITY

Pharmacy

Laboratory


Homecare



Specialist Clinic

Why Pursue The EHR: BenefitsDoD priorities:1.Experience of care2.Readiness3.PopHealth4.Per capita costs




The iEHR-CIIF is a Key to a Renewed Health System!

Interoperable EHR Solutions provide an opportunity to

• Improve the quality, safety, accessibility and timeliness of care

• Support more informed healthcare decision making, research and management

• Improve the efficiency of the healthcare system and reduce costly duplication

• Maximize return on IT investments

• Achieve standards based solution allowing interoperability

52iEHR-CIIF

WORKING DRAFT: not for wide distribution or official use


iEHR-CIIF Key Clinical & Business Requirements

• Life-long longitudinal record of clinical data

• Allowing private and secured access to data made available in EHR

• Focused on clinically relevant data shared beyond organizational boundaries

• Support for accurate, complete, timely delivery of information

• Shared across multiple organizations, Organizations

• Adaptive to the future of healthcare delivery in the 21st Century

• Requiring ongoing governance and operations management with 24/7 high availability service

• Affordable in relation to complexity and size of integration challenges (connecting large numbers health points of service)

• Scalable to allow continuous, extensive growth of clinical and financial ROI• More POS applications sourcing data to EHR

• More users accessing and using data from EHR

• Allowing natural growth of capabilities towards Generation 3 and beyond




54

Different Approaches To Achieving iEHR-CIIF



Clients/Patients

iEHR-CIIF: How Do We Do This?Sharing Information From Multiple Systems

Pharmacy

Laboratory


Homecare



Specialist Clinic

INTEGRATED VIEW


Methods of Sharing EHR Information

The “Big Databasein the Sky”

• All Point-of-Service (POS) systems share same data store

Broadcast to all or a logical subset ofSystems (caching)

• Replication of data from one system to all other relevant/participating POS systems

• Every POS system holds same information

The “Big Index inthe Sky”

• EHR Index or locator service that holds links to all POS systems where information resides

• Each POS system interfaces to other systems

Use of a shared reference

information source

• POS systems populate it

• POS systems or viewers reference it

• External to the “operational” store





Key Factors Affecting How to Share

• Sharing creates some very profound issues & requirements• Unique identification of clients, providers, service delivery locations, etc.

• Protecting privacy and confidentiality of patients and providers while simultaneously not limiting the ability to deliver appropriate services

• Ensuring information is stored, shared securely

• Ensuring compatibility of how data is interpreted/understood --- CIIF

• Issues the same no matter which model is chosen to share patient identified information

• Governance model for healthcare means these issues are organizational responsibilities – requirements vary

• People increasingly mobile, especially when considering long periods of time

• Provider’s confidence in the mechanisms to enable sharing is crucial

DEERS EDIPN Service is the DoD-VA solution




58

The Integration Challenge of Interoperable EHR Solutions



Clients/Patients

Integrating Heterogeneous Systems

Pharmacy

Laboratory


Homecare



Specialist Clinic


Clients/Patients

Integrating Heterogeneous Systems: Hospital

Pharmacy

Laboratory

Diagnostic

Homecare



Specialist Clinic

Hospital Emergency

ADTOrder/Results

ElectronicPatientRecord

SpecializedCare

Pharmacy

Scheduling LaboratoryClinical Data Repository

Radiology PACS

EmergencyHuman

Resources

Hospital Emergency

Finance, inventory,

payroll


Clients/Patients

Integrating Heterogeneous Systems: Hospital

Pharmacy

Laboratory

Diagnostic

Homecare


Emergency Services

Specialist Clinic

Hospital Emergency

Clinic Clinic

SchedulingAccountiing/

Billing

ElectronicMedical Record


Clients/Patients

Locations of Electronic Clinical Data Today: Number of Systems to Integrate

Pharmacy

Laboratory


Homecare



Specialist Clinic





Integrating Health Information Systems: Key Challenges

• Protecting Privacy• Governance, accountability & data custodianship• Controlling access• Managing & applying consent directives• Controlling feeds and queries to the data• Trust relationships & contracts

• Existence & availability of data thru CIIF• Discovery capability• Availability in electronic format• Timeliness

• Harmonization through CIIF• Data structures (format)• Vocabularies (encoding, normalization)• Semantics

• Heterogeneous technology environments

• Number of organizations, connection points & systems

• Costs inherent to integration



64

Recommended Approach: The Cost of Integration As A Key Driver



SYSTEMS TO CONNECT

SYSTEMS TO CONNECT

SYSTEMS TO CONNECT

Integrating Health Information Systems:Point-to-Point Connectivity

Costs basis

• Cost of one integration• Simple = $32K; Medium = $95K;

Complex = $190K

Futile approach

• 38,783 systems in Canada

• Simple = 4,527; Medium = 20,081; Complex = 14,175

• 1.5 B integration points

• 183.928 B $CDN

Contracts

2

App 1Appl 1 App 1Appl 2

App 1 App 1

App 1App 1Appl 1 App 1Appl 2

6App 1App 1Appl 3

Interfaces = N (N-1)

12

App 1 App 1App 1Appl 1 App 1App 1Appl 2

App 1 App 1App 1Appl 3 App 1App 1Appl 4We need a different approach


removed




Integrating Health Information Systems:Hospital Networks Approach

Costs basis

• Cost of one integration• Simple = $32K; Medium = $95K;

Complex = $190K

Hypothesis

• 1,126 Hospital networks, each includes 71 systems to integrate and group (EAI) in 44 points of integration

• 1,892 (44 x 43) integrations per network totalling 2.1 M (1,126 x 1,892) integrations in Canada

• Assuming existence of standardized protocol for interfaces

• 68.172 M $CDN (if Simple – 32K)

• 202.316 M $CDN (if Medium – 95K)

We need a different approach

SYSTEMS TO CONNECT

SYSTEMS TO CONNECT

SYSTEMS TO CONNECT

Contracts

2

App 1Appl 1 App 1Appl 2

App 1 App 1

App 1App 1Appl 1 App 1Appl 2

6App 1App 1Appl 3

Interfaces = N (N-1)

12




removed




Rational for Recommended Approach

• Only cost effective scenario to handle degree of application integration required

• Maximized ability to deliver proper response time and consistent access to data across thousands of source systems

• Maximized ability to apply privacy and security policies in a harmonized and consistent fashion

• Enables evolutionary path to semantic harmonization of health information across service delivery points

• Enables high degree of scalability from local health services integration, to regional, state and cross-organizational

• Enables high degree of flexibility in reconfiguration of health services delivery networks



68


CONTEXT





Models

SystemArchitecture




iEHR-CIIF Work Process Architecture

• The EHR Clinical Reference Framework: Life of the Lamberts

• Depiction of the use of an Interoperable EHR Solution in different contexts of health service delivery

• 14 different storyboards created

• Extensible by adding new use cases

• System or security administration use cases not represented

• Life of the Lamberts• Patient centric framework

• Focused on different members of a family and their health status evolution

• Focused on health related events

• Represented with UML use case notation

• Published as artefacts under the Artefact Repository• Available in HTML and PDF format

• Available in Magic Draw format and XMI for upload to other case tools



iEHR-CIIF Reference Architecture

iEHR-CIIF Reference

Architecture 70

EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IPHospital, LTC,

CCC, EPRPhysician

Office EMR EHR Viewer

Physician/Provider

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist


Public Health ProviderPOINT OF SERVICE

POS APPLICATION

SIGNIFICANT REUSEHERE

Life OfThe Lamberts

CIIFComm Step Put New Patient

EHR IPAdd New Patient

EHR IP

EHR IP

EHR IP

Clinical Events

Clinical Events

Clinical Events

NewFamily Physician

Activity

Clinical Activity

Clinical Activity

Clinic VisitAdmission

NewFamily Physician

Activity

Encounter

EncounterCOPDStoryboard

Storyboard

Storyboard





Documenting EHRi Services Requirements

iEHR-CIIF Reference

Architecture

POINT OF SERVICE

PhysicianOffice EMR

EHR Viewer EHR Viewer

Physician/Provider

Physician/Provider

Physician/Provider

PhysicianOffice EMR

Lab Clinician


Radiologist

EHR IPData

EHR IPData

EHR IPData

EHR IPData

EHR IPData




EHR Data& Services

DataWarehouse

OutbreakManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtData




Common Services

EHR IPEHR IPEHR IPEHR IPEHR IP

IP “Put” IP “List” IP “Get” IP “List” IP “Get”

EAI IP

EAI IP

CIIF

EAI IP EAI IP EAI IP EAI IP EAI IP EAI IPProviderRegistry

LocationRegistry

TerminologyRegistry

ClientRegistry E

AI

IPE

AI

IPE

AI

IPE

AI

IP







EHR Data& Services

DataWarehouse

POINT OF SERVICE

People Use Cases: Caregiver Perspective

Security MgmtData



Common Services


PhysicianOffice EMR

EHR Viewer

Physician/Provider

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist



EHR INTERFACE REQUIREMENTS DOCUMENTATION

Stakeholder EntitiesStoryboards,Use Cases

Events, Encounters, Episodes of Care

Clinical Activities,Information Exchanges

• First class of SDK informative deliverables are contextual & informational

• They describe the end-user functional requirements and assumptions for use of an Interoperable EHR Solution (DoDAF OV-3: Operational Resource Flow Matrix)

• Establish when POS applications expected to interact with an EHRi in the context of daily work activities for caregivers (DODAF OV-6c: Event-Trace Description aka BPMN use case diagrams)

• iEHR-CIIF SDK is only documenting Interoperability Specifications (ISs); not internal EHR features.

• Scope is broad enough to cover large spectrum of healthcare and public health service delivery to achieve representative set




EHR Interoperability Profile (EHR IP)ORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse

POINT OF SERVICE


PhysicianOffice EMR

EHR Viewer

Physician/Provider

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist



CIIF

EHR Interoperability Profile (IP)

Information Exchange Content Standards

Information ExchangeTransport Standards

• Second class of SDK normative deliverables; specify the interfaces between POS applications and iEHR (DODAF SV-6: Systems Resource Flow Matrix & SvcV-6: Services Resource Flow Matrix)

• Establishes a language to describe types of service requests made to an EHRi (DODAF SV-1: Systems Interface Description & SvcV-1: Services Context Description)

• Positions which data to be exchanged by referring to data views of the data model (DODAF DIV-1: Conceptual Data Model & DIV-2: Logical Data Model)

• Assumes SOAP-based web services calls where XML encoded HL7 V3 message requests … V3? and responses are carried between POS applications and the EHRi







EHR Data& Services

DataWarehouse

OutbreakManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

BusinessRules

EHRIndex

MessageStructures

NormalizationRules


ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

POINT OF SERVICE

EHR Infostructure IP (EHR I-IP)

Security MgmtData



Common Services

• Third class of SDK normative deliverables; specify inner workings within iEHR Infostructure to orchestrate and process transactions (DODAF SV-10c: Systems Event-Trace Description & SvcV-10c: Services Event-Trace Description)

• Express sequencing of activities to process transactions (DODAF SV-5a: Operational Activity to Systems Function Traceability Matrix & SvcV-5: Operational Activity to Services Traceability Matrix)

• Express expected capabilities of services within an EHRi to process transactions (DODAF CV-3: Capability Phasing)

INFOSTRUCTURE INTEROPERABILITY PROFILE

InfostructureIP

InfostructureServices Catalogue

Generic InterfaceSpecification







EHR Data& Services

DataWarehouse

OutbreakManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

BusinessRules

EHRIndex

MessageStructures

NormalizationRules


ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

POINT OF SERVICE

Enterprise Application Integration (EAI IP)

Security MgmtData



Common Services

• Fourth class of SDK normative deliverables; specify inner workings within iEHR Applications to orchestrate and process transactions (DODAF SV-10c: Systems Event-Trace Description & SvcV-10c: Services Event-Trace Description)

• Express sequencing of activities to process transactions (DODAF SV-5a: Operational Activity to Systems Function Traceability Matrix & SvcV-5: Operational Activity to Services Traceability Matrix)

• Express expected capabilities of services within an EHRi to process transactions (DODAF CV-3: Capability Phasing)

Enterprise Application Integration Interoperability Profile / Specification

ApplicationIP

ApplicationServices Catalogue

Generic InterfaceSpecification



76


CONTEXT





Models

SystemArchitecture




EHR Infostructure: Services Drill-DownORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse

OutbreakManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

POINT OF SERVICE


PhysicianOffice EMR

EHR Viewer

Physician/Provider

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtData


Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist





Common Services

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry





EHR Infostructure: Standards Based Connectivity

POINT OF SERVICE


PhysicianOffice EMR

EHR Viewer

Physician/Provider

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist



EHR IPEHR IPEHR IPEHR IPEHR IPEHR IPEHR IP


EHR IP Standards EHR IP Standards EHR IP Standards EHR IP Standards EHR IP Standards EHR IP Standards EHR IP Standards

EHR SCP Standards



EHR Data& Services

DataWarehouse

OutbreakManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

BusinessRules

EHRIndex

MessageStructures

NormalizationRules


EAI IP

EAI IP EAI IP EAI IP EAI IP EAI IP EAI IPProviderRegistry

LocationRegistry

TerminologyRegistry

ClientRegistry E

AI

IPE

AI

IPE

AI

IPE

AI

IP

Security MgmtData

Privacy Data ConfigurationEAI IPEAI IP


Common Services







EHR Data& Services

DataWarehouse

POINT OF SERVICE


EHR Infostructure: Secure Communications Bus

Secure Communications Bus

MESSAGING

TransformationServices

RoutingServices

Encrypt/Decrypt

Services

En/Decoding

Services

ParserServices

SerializationServices

PROTOCOL

App ProtocolServices

Network ProtocolServices




EHR Infostructure: Common ServicesORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse

POINT OF SERVICE

CIIF

Security MgmtData


Common Services

COMMON SERVICES

INTEROP

InteroperabilityServices

Search/ResolutionServices

INTEGRATION

Service CatalogueServices

Broker Services

Mapping Services

Queuing Services

CONTEXT

Session MgmtServices

Caching Services

Identity ProtectionServices

Identity MgmtServices

AnonymizationServices

User AuthenticationServices

Consent DirectivesMgmt Services

EncryptionServices

Access ControlServices

Secure AuditingServices

Digital SignatureServices

General SecurityServices

SUBSCRIPTION

Alert/NotificationServices

Pub/SubServices

MANAGEMENT

ManagementServices

ConfigurationServices

GENERAL

AuditingServices

Log MgmtServices

Policy MgmtServices

Exception/ErrorHandling Services

PRIVACY & SECURITY




EHR Infostructure: Longitudinal Record Services (LRS)ORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse

POINT OF SERVICE

CIIF

BusinessRules

EHRIndex

MessageStructures

NormalizationRules



DATA

Key MgmtServices

ETLServices

BUSINESS

Data QualityServices

Domain Business Components(Registries, EHR, Domains, User, Context)

EHR IndexServices

OrchestrationServices

NormalizationServices

Business RulesServices

AssemblyServices

DataServices

ReplicationServices




EHR Infostructure: Longitudinal Record Services (LRS)ORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse

POINT OF SERVICE

CIIF

BusinessRules

EHRIndex

MessageStructures

NormalizationRules


The EHR Index maintains a sequential list of all events that affect the clinical picture of a client. It also provides the location where the data relevant to each event 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.

EHR INDEXEvent ID (Instance ID of an event)

Parent Folder ID

Focal Class Type

Focal Act Subject (Client ECID)

Focal Act Author (Provider)

Focal Act Service Delivery Location

Focal Act Timestamp

Focal Act Status

Focal Act Language

Focal Act Type: • Act Mood (e.g. Order Request)• Act Class Code (type of class, e.g. Lab order)• Act Code (Class value, e.g. CBC)

Focal Act Source ID (ID provided by POS)

Focal Act Template ID

Focal Act Data Location ID (URI)


DATA

Key MgmtServices

ETLServices

BUSINESS

Data QualityServices


EHR IndexServices




AssemblyServices

DataServices

ReplicationServices




CROSS-ORGANIZATIONAL INFOSTRUCTURE

EHR Infostructure: iEHR-CIIF Locator Data

• EHRi Client ID (resolved ECID)• CR instance ID (OID root)• EHRi instance ID (which instance of an EHRi)• EHRi URI (the URI to access the CIIF)• Optimized for performance

• Information type (drug, lab, DI) (derived from HL7 act classes)• First created date• Last updated date




Application

Point of Service

Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services






Application

Point of Service

Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services




POINT OF SERVICE

iEHRLocator






POINT OF SERVICE

Organization

AOrganization

BOrganization

C

Centralized Service Approach

iEHR-CIIFLocator





Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services







Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services






Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services


Common Interoperable Information Infrastructure (CIIF) Common Interoperable Information Infrastructure (CIIF)






POINT OF SERVICE

Distributed Service Approach

iEHR-CIIF Locator Synchronization

iEHR-CIIFLocator

iEHR-CIIFLocator

Organization

AOrganization

BOrganization

C





Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services







Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services






Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services






POINT OF SERVICE

iEHR-CIIF Locator: LRS Integrated ApproachCROSS-ORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse


BusinessRules

EHRIndex

MessageStructures

NormalizationRules


ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

CIIF

iEHR-CIIFLocator




LRS Integrated Services ApproachCROSS-ORGANIZATIONAL INFOSTRUCTURE


POINT OF SERVICE

Client Registry Synchronization

Organization

AOrganization

BOrganization

C





Application


Services

HealthInformation

DataWarehouse

EHRData &

Services







Application


Services

HealthInformation

DataWarehouse

EHRData &

Services






Application


Services

HealthInformation

DataWarehouse

EHRData &

Services



RegistriesData &

Services

RegistriesData &

Services

RegistriesData &

Services




EHR Infostructure: EHR Data Domain ServicesORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse

POINT OF SERVICE

CIIF

SharedHealth Record

DrugInformation

DiagnosticImaging

Laboratory

SHARED HEALTH RECORD

DATA

Key MgmtServices

BUSINESS



EHRi InteroperabilityServices


AssemblyServices

DataServices




EHR Infostructure: EHR ViewerORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse

POINT OF SERVICE

CIIF

EHR Viewer

Physician/Provider

EHR VIEWER

EHRi InteroperabilityServices

EHR ViewerBusiness Objects Components


End-userNavigation Services


End-userDisplay Services

DataServices




EHR Infostructure: Client RegistryORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse

POINT OF SERVICE

CIIF

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry




EHR Infostructure: Why A Client Registry?ORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse

POINT OF SERVICE

CIIF

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

EHR Viewer

Physician/Provider

Has Mr. Lambert had any ER visits since I’ve last seen him

one year ago?

PatientInfo

End-userInfo

VisitHistory

DrugProfile

LaboratoryDiagnostic

Imaging

EHR VIEWER




Pharmacy

ALab

B???

C

EHRi Client Registry: The Challenge

1: A 123 Robert Lambert 1 Main St

1: B 456 Bob Lambert 1 Main St

1: C 789 Robert Lambert 1 Main St

1: C 987 Robert Lambert 1 Main St

2: B 444 Robert Lambert 2 Elm St

123 Robert Lambert 1 Main St 456 Bob Lambert 1 Main St444 Robert Lambert 2 Elm St

789 Robert Lambert 1 Main St987 Robert Lambert 1 Main St

EMPI




MDR IDLab ID

NameBirthdateGender

SINULIECID

AddressPhone

Eligibility statusCoverage details

Static, natural person identity information

Dynamic, natural person identity information

Static, artificial person-identifying information

Dynamic, artificial person-identifying information

Core system data about the person

EHRi Client Registry: What Data?

The generation (or sourcing) of the EHRI Client Identifier (ECID) is a service offered by the Client Registry.

The ECID is the foundation for interoperability both locally and across EHR Infostructures.



DEERS EDIPN Service is the DoD-VA solution


ORGANIZATIONAL

EHRi Client Registry: Interoperability Pattern

Applications

ClientRegistry

J1

ClientRegistry

J1.1

ClientRegistry

J1/2

ClientRegistry

J2

ECID: J1 Root ID. Client ID ECID: J2 Root ID. Client ID

Active synchronizationof travelling clients only

Applications




EHR Infostructure: Provider RegistryORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse

POINT OF SERVICE

CIIF

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry







EHR Data& Services

DataWarehouse

POINT OF SERVICE

CIIF

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

EHR Infostructure: Why A Provider Registry?

Have any new test results been published for me?

PatientInfo

End-userInfo

VisitHistory

DrugProfile


Imaging

EHR VIEWER

EHR Viewer

Physician/Provider




Provider Registry: Data SourcesORGANIZATIONAL

REGIONAL

Provider Registry

Applications Applications Applications

Doctors DentistsUnlicensed Providers

EHR SCP StandardsProvider Registry

EHR SCP StandardsProvider Registry



98

Standards-based Solutions: What Does It Mean?

iEHR CIIFWORKING DRAFT: not for wide distribution or official use

Interoperable EHR Solutions: Key Architectural Requirements

Standards-based

Solutions

StandardizedArchitecture

StandardizedInterfaces

StandardizedData Structures

StandardizedData Vocabularies(encoding rules)

StandardizedFunctional Behaviour

99iEHR-CIIF



iEHR’s program role is to encourage standards and requirements for robust, interoperable products and outcomes

Standards-based Solutions

Why Standards?• They facilitate information exchange; are a critical foundation

for EHR

• They create opportunity for future cost reduction as vendors and systems converge on national and international standards

• They ease effort required for replication

Mandatory Investment Eligibility Requirements• Compliance to standards (infostructure, architecture)

• Initiatives must comply with existing guidelines or standards adopted by US Health and Human Services (HHS)

• Where standards or guidelines do not exist, projects must support longer-term interoperability and congruence of solutions




Principles for Establishing iEHR Standards

• The DoD-VA have created Principles for Establishing iEHRs

• Standards to provide guidance in the adoption of standards-based solutions

• As the iEHR SDK evolves, there are many assumptions made that, once implemented in the architecture, can no longer be considered assumptions anymore: they are now principles about the function of iEHR-CIIF Infostructures and iEHR-CIIF Solutions that need to guide detailed design and development of solutions.Business-driven Adoption of existing standards where ever possible




Principles for Establishing iEHR-CIIF Standards

• Standards initiatives to be driven by the business of healthcare with a clearly defined business need

• Existing standards work must be leveraged wherever possible and practical with an approach that includes adoption, or adaptation of existing standards, before development

• Health Level 7 V3 messaging standard required for all new message development related to EHR

• Investments predicated on a commitment to implement national iEHR standards

• Standards to be established, tested, refined and evaluated within the context of early adopter implementations

• DoD and VA will support early adopter investment projects that have the establishment of National standards as their goal

NOT DoD-VA Principles




Principles for Establishing iEHR-CIIF Standards

• Establishing standards is an evolutionary process and will not be perfect the first time; implementation of standards that are not fully balloted may be needed

• iEHR program is committed to supporting influencing EHR national and international standards

• iEHR program and its stakeholders will work with other organizations undertaking similar EHR initiatives to leverage their work and bring synergies to the projects as they move toward balloted standards

• iEHR program and its stakeholders will partner with HL7, IHE, OASIS, IHTSDO and other standards organizations in the establishment of iEHR-CIIF standards

• Establishment of EHR standards is coordinated via an open, transparent and inclusive Stakeholder Collaboration Process

NOT DoD-VA Principles




GOVERNANCE

REGIONAL DEVELOPMENT

Interoperable EHR

ST

RA

TE

GIC

CO

LLAB

OR

AT

ION

/CO

OR

DIN

AT

ION

Standards Collaboration Process (SCP)

• An integral element of and key requirement for the establishment of an interoperable Electronic Health Record (EHR)

• The EHR Standards Collaboration Process includes those Organizations, standards-related organizations, healthcare professionals and vendors that will build, operate and use an interoperable EHR-CIIF

• The EHR Standards Collaboration Process will establish standards for investments through collaboration and consensus

Telehealth

Lab

Diagnostic Imaging

Drugs

Registries

Infostructure

Infostructure/EH

R

E

xpert Working G

roupsEHR Standards Steering Committee

National EHR Standards Advisory Committee

National Standards working groups

NOT DoD-VA Process




iEHR-CIIF Standards: Status

Needed Standards Groups• Drugs• Client Registry• Provider Registry• DI/Tele-radiology• Laboratory• Clinical Terminology• iEHR Technical Standards

(coming soon)• iEHR Clinical Standards

(coming soon)• Public Health (coming soon)

Suggested Projects

• iEHR-CIIF SDK • EHR Data Definition & Standards• Standards Collaboration Process• Standards Tactical Plan• Artefacts Repository• Telehealth ISO Interoperability• Telehealth CCHSA Accreditation• Client Registry• Provider Registry• Laboratory Nomenclature & Messaging• NeCST: electronic claims messaging• EHR Clinical Terminology Integration• EHR Profiles for Interoperability

between DI, Registries & Consumers• EHR-CIIF Evolution Project• Privacy & Security Architecture Project

Health Surveillance

Telehealth

Lab

Diagnostic Imaging

Drugs

Registries

Interoperable EHR

NOT DoD-VA Status




iEHR-CIIF Infostructure: Standards-based Connectivity


POINT OF SERVICE


EHR Data& Services

DataWarehouse


Physician/Provider

Physician/Provider

Physician/Provider

Lab ClinicianRadiologistPharmacistPublic Health Provider



EHR IP Standards EHR IP Standards EHR IP Standards EHR IP Standards EHR IP Standards EHR IP Standards EHR IP Standards

EHR SCP Standards

EAI IP

EA

I IP

EA

I IP

EA

I IP

EA

I IP

EAI IPEAI IP

CIIF

EAI IP EAI IP EAI IP EAI IP EAI IP EAI IP

Architecture Standards

• iEHR Blueprint

• EHR Use Cases

• FHIM/EHR Data Model

• iEHR-CIIF Services Model

• EHR Interoperability Profiles

• Terminology Standards

• Terminology implemented in data messaging standards

Data Messaging Standards

• Client Registry

• HL7 Provider Registry

• HL7 Pharmacy

• Laboratory

• Public Health Services Standards

• Public Health Surveillance Standards

• Diagnostic Imaging/Teleradiology (in planning)

• iEHR Clinical Messaging (in planning)

• iEHR Technical Standards (DODAF StdV-1: Standards Profile aka DoD-VA shared Standards Profile)



107

Service-oriented Architecture (SOA): What Does It Mean?



1

Level of Encapsulation Can Vary:Five Normal Forms of Encapsulated Software

2 3 4 5External access

Other data

Own data

Encapsulated software

Programmatic interface

Overloaded, incomplete; any data

One complete function; any data

Own data only Exclusive data Opaque data

Source: Gartner

See Notes Page




SOA as an Enabler

Applications of SOA in EHRi Solutions

• Repurposed legacy applications to offer services as part of SOA-based EHR Infostructure

• New breed of services to enable coordinated transactions in an EHR Infostructure (e.g. Longitudinal Record Services (LRS))

• Use of commercially available solutions to enable components of EHR Infostructure

Two Degrees of Separation

• Services exposed outside of an EHRi in the form of supported EHR Interoperability Profiles for an entire Infostructure perceived as a single system with transactional services

• Services within an EHR Infostructure to optimize scalability, maintainability and functional flexibility




First Degree: The EHR ServiceORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse

OutbreakManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

POINT OF SERVICE


PhysicianOffice EMR

EHR Viewer

Physician/Provider

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtData


Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist





Common Services

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

EHR SERVICE

Get Client IDResolution

List Laboratory Orders Get Laboratory Result

List LaboratoryResults

Get Prescription

List Medications

Stream DI Image

List DI Results Get DI ReportGet OutbreakCase Data

List CD ReportEvents

Get ProviderInformation

List ServiceDelivery

Locations

List EncounterEvents

Get EncounterSummary

Get ClinicalDashboard

Get ClientDemographic







EHR Data& Services

DataWarehouse

OutbreakManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

POINT OF SERVICE

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtData




Common Services

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

Second Degree: Inside The EHR Infostructure

EHRi SERVICES

CRServices

PRServices

LRServices

TerminologyServices

Detection& Reporting

Services

Shared HealthRecord Services

DrugServices

DIServices

LabServices


AssemblyServices

A & AServices

BrokeringServices

ConsentServices

SessionServices

LoggingServices

OutbreakServices

RulesServices


EHR IndexServices

Any Point-of-Service

Application

EHR IP

See Notes Page



112

Functioning Principles



Functioning Principles/Rules

• Home/no-home EHR

• EHRi Identifier Management

• EHR Index

• iEHR Locator

• POS to EHRi interface

• Level of transparency of EHR to POS applications

• Transaction scope

• Trust Models valid for an EHRi

• CIIF normalization of information/terminology

• Auditing, logging, use of logs

• HL7 V3 (Messaging and templates)

• Level of parameterization

• Primary Purpose for EHRi repositories

• Other uses of the CIIF (POS to POS)

• Multilingual capabilities

• Runtime environment

• Performance principles – targets

• POS Integration environment

• Error Handling

• Consent

• Authentication & Authorization

• OIDS as a principle

• Prospective Events



114


CONTEXT





Models

SystemArchitecture




EHRi Conceptual Data Model

• High-level model representing generalized concepts

• Encounter Management,

• Care Plan Service,

• Health Concern Tracking

• Analytics

• Event driven model to represent instances of clinical service impacting a patient record

• Broad range of event typing – governance, people playing roles, delivery, environment, resource

• Derived from the Federal Health Information Model (FHIM)

• Detailed Clinical Models (DCLs)

• Aligned and mapped to HL7 V3 RIM

• Mapped against several local and international EHR data models

• More detailed views available – transactional views, domain views

Governance

Event Linkage

Event

Role

People

Resource Environment

Place

Capability




Components of Computable Data

TerminologyModel

InformationModel

Repository

Used By

Used By

Concepts Concept relationships Concept definitions Terms Hierarchies Clinical propositions Standard terminologies Mappings Not patient specific

Structural layout Clinical definition Hierarchical in nature Contains fields for discrete values Fields tied to dictionary Defines “valid data” Not patient specific

Instances of data using model and dictionary

Event based Constrained by model Patient specific

•An Terminology is a formal representation of healthcare knowledge as a set of concepts , called terms, and the relationships between those terms.

•An information model is a representation of concepts, relationships, constraints, rules, and operations to specify data semantics for healthcare.

116See notes page


Key Terms and Concepts … Terminology

117

The approach to common terminology is for both agencies to use SNOMED + Extensions = Lingua Franca for DoD-VA Terminology. The EHRWF will

incorporate the CIIF Information and terminology models as the logical data models for our shared (virtual) repositories; thereby, improving semantic

interoperability and performance. 117

See notes page


Use Case Example: Patient is Admitted with “Cold” Symptoms As-Is = Different Points of Entry Can Have Different Interpretations of “Cold”

Cold =Patient is diagnosed with the Common Cold

cold =Patient is diagnosed as psychologically unfeeling and distant

C.O.L.D. = Patient is diagnosed with Chronic Obstructive Lung Disease

MHS VAPrivate Health Sector

& Other

The CIIF reduces redundancies, leverages agency resources, provides contextual information, and ensures data integrity across DoD and VA applications, directly improving continuity of care

As-Is… To Be…

The right diagnosis based on the right data applied in the right context

118


HDD and SNOMED-CT mapping work - Mapping Example (not actual codes)

HDD NCID

SNOMED-CT RxNORM

MEDCIN CPT CHCS 1 VistA 1

443

<Substance> <acetylsalicylic acid (ASA) ID:

123455>

<Orderable drug Brand Name ID> <Aspirin: 82464>

2214 N/A ASP A112

812<Condition:

diagnosis><Cold>N/A 9923 123 Cld CD8

123

<Procedure Test Result Name:>< Red Blood

Count>

N/A 1324 98231 RBC RBC

923DoD specific

termVA term

119See notes page


CIIF ServicesServices Provided by CIIF

•Translation – syntactic and semantic data harmonization using standard information models and SNOMED CT and extensions as the CIIF conical terminology and iEHR data stores’ native terminology.

• Syntactic field mapping and conformance • Semantic terminology mediation and value normalization

•Mediation - a mediation service can handle the transformation from one information-exchange payload-format and transport to another.

•Built-In-Test-Environment (BITE) - for run-time information-exchange integrity-checking.

•Common Terminology Services 2 (CTS2) - CTS 2 terminology services

•Metadata Service – provides information schemas and terminology bindings

Services Used by CIIF

•Identification – Who are you looking for?

•Authentication – Who are you?

•Authorization –What are you allowed to know or do?

•Secure Data Transport - Standards-based information exchanges.

•RLUS - Retrieve, Locate, Update Service•Rules Engine – – A business rule service enables policies and other operational decisions to be defined, tested, executed and maintained separately from application code.

120120


“As Is” System Data Interoperability

Schematic

EHRWF/CIIF System Data Interoperability

Schematic

System Data Interoperability

See notes page for explanation of slide121

See notes page

122


CONTEXT





Models

SystemArchitecture



123

CIIF Integration Layer: Evolutionary Path

iEHR=CIIFWORKING DRAFT: not for wide distribution or official use


Interim State: No EHR Services (Undesirable)ORGANIZATIONAL INFOSTRUCTURE

POINT OF SERVICE


EHR Data& Services

ClientRegistry

DrugInformation

SystemRepository

EHR Viewer

Physician

PharmacySystem

Pharmacist

Each Organization Infostructure level system uses patient and other required strong identifiers (e.g. provider, encounter) based on point-of-service generated IDs (e.g. MRNs). The CR-EMPI source systems make the CR-EMPI aware of client identifiers. The Point-of-Service applications and Infostructure systems query the CR EMPI for these identifiers in order to access data within any Infostructure System. The level of queries and maintenance of MRNs in the EMPI is not scalable to hundreds or thousands of Point-of-Service systems. There are performance issues accessing CR/EMPI for every Drug system interaction.

CR

AP

I

CR API

Client Registration1) Search client2) Create new client3) Update existing client

HL7 (CR)

Pharmacy Profile4) Request drug profile5) Request DUR6) Enter new prescription

HL7 (CR)

Sea

rch/

Res

olve

PATIENT ENCOUNTERClient Registration1) Search client2) Create new client3) Update existing client


HL7 v3 (Rx)

HL7 v3 (Rx)

DR API

CR API DR APICR API

DR API




Interim State: CIIF Without LRSORGANIZATIONAL INFOSTRUCTURE

POINT OF SERVICE

EHR Data& Services

DrugInformation

SystemRepository




HL7 (CR)

HL7 v3 (Rx)

Pharmacy Profile4) Request drug profile5) Request DUR6) Enter new Prescription

Search/Resolve

Get EHR ID

EA

I IP

Security MgmtData



Common Services

EHR Viewer

Physician

PharmacySystem

Pharmacist

HL7HL7

EH

R IP

EH

R IP


ClientRegistry E

AI

IP

DetermineEHR Client ID E

AI

IP

The Client Registry system “determines” a global unique ID (EHR ID) for patients. The Drug Informaton System (DIS) will use the EHR patient ID to store prescribing and dispensing data. Point-of-Service applications query the Client Registry and obtain the EHR patient ID and will use this ID as a token throughout the entire business transaction. This model eliminates the need for communication between the DIS and CR and reduces the transactions to the CR to one per business transaction.




Interim State: CIIF Without LRSORGANIZATIONAL INFOSTRUCTURE

POINT OF SERVICE


ClientRegistry E

AI

IP

DetermineEHR Client ID

EHR Data & Services

DrugInformation

SystemRepository




HL7 (CR)

HL7 v3 (Rx)

Pharmacy Profile4) Request drug profile5) Request DUR6) Enter new Prescription

Search/ResolveGet EHR ID

EA

I IP

Security MgmtData



Common Services

EHR Viewer

Physician

PharmacySystem

Pharmacist

HL7HL7

EH

R IP

EH

R IP


Business Components

Dat

a A

cces

s

EHRIndexCR API DR API

The Client Registry determines a global unique ID (EHR ID) for patients. The DIS will use the EHR patient ID to store prescribing and dispensing data. EHR services will use the CR to map any local MRN found within transactions to the corresponding EHR client ID. The POS applications do not necessarily have to be aware of the EHR client ID or they can continue to provide this ID themselves after querying the CR (compatible with prior model).







EHR Data& Services

DataWarehouse

OutbreakManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

POINT OF SERVICE


PhysicianOffice EMR

EHR Viewer

Physician/Provider

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtData


Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist





Common Services

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

Target State: Full Featured iEHR-CIIF InfostructureThe client, provider, location registries and EHR Services determine (respond with) global unique ids for patient, providers, encounters and other required strong identifiers. All Infostructure systems use these unique IDs to store clinical data about a person. The EHR Services will map any local ID to the corresponding EHR ID. The Domain services (DIS, DI, Lab) systems rely on the EHR Services to ensure that the necessary EHR IDs are provided with every transaction.



128

iEHR Infostructure: Deployment Models



RE

GIO

NA

L/

OR

GA

NIZ

AT

ION

AL

Large & Medium Deployment Models

Medium size Organizations

• Organizational or regional Client and Provider and Location Registries

• Organizational or regional Lab, Drug, Diagnostic Imaging (DI), Shared Health Record, LRS, CIIF and EHR Viewer

• iEHR Locator across Organizational or regional

• Local EMR, CIS and other applications

Larger size Organizations

• Organizational or regional Client and Provider and Location Registries

• Organizational or regional Lab, Drug Repositories and CIIF

• Supra-regional LRS, Shared Health Record and DI Repositories and EHR Viewer

• iEHR Locator across organizations or regions

• Local EMR, CIS and other applications

REGION 1


ClientRegistry

ProviderRegistry

LaboratoryRepository

DrugRepository

DIRepository

REGION 2


Common Services

CISEHR

ViewerEMR


CIS EMREHRViewerL

OC

AL

/RE

GIO

NA

L

RE

GIO

NA

L/

OR

GA

NIZ

AT

ION

AL


SharedHealth Record

DIRepository

CISEHR

ViewerEMR

LO

CA

L


Common Services

SharedHealth Record

DIRepository

SharedHealth Record

ClientRegistry

ProviderRegistry

LaboratoryRepository

DrugRepository




REGIONAL

LOCAL

ClientRegistry

ProviderRegistry

CIS

Diagnostic Imaging (DI)Repository

SharedHealth Record

Drug/Lab

EHR Viewer EMR

Small Organizations

• Regional Client, Provider & Location Registry

• integrated hospital CIS solution fulfilling the roles of the Regional EHR Services, Laboratory and Drug services

• Regional Diagnostic Imaging (DI) Service

• Regional CIIF & EHR Viewer

• Local physician office systems & other CIS connect as POS Systems



Common Services




REGIONAL

POINT OF SERVICE

Model 1: Single EHR Infostructure

Registry & Data Services EHR Data & Services

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Clientregistry

ProviderRegistry

Locationregistry

TerminologyRegistry

Drug Information

EHR Data & Services

DiagnosticImaging (DI)

SharedHealth Record

Laboratory


Security MgmtData



Common Services


PhysicianOffice EMR

EHR Viewer

Physician/Provider

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist






REGIONAL

POINT OF SERVICE


PhysicianOffice EMR

EHR Viewer

Physician/Provider

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist



Model 2: Shared EHR Infostructure

REGIONAL


Clientregistry

ProviderRegistry

Locationregistry

TerminologyRegistry

Drug Information

REGION 1 REGION 2 …

DiagnosticImaging (DI)

SharedHealth Record


Imaging (DI)Shared

Health RecordLaboratory

SharedHealth Record

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtData



Common Services

Longitudinal Record Services (LRS) Longitudinal Record Services (LRS)




REGIONALRegistry & Data Services EHR Data & Services

Clientregistry

ProviderRegistry

Locationregistry

TerminologyRegistry

Drug Information

Model 3: Distributed EHR Infostructures

Region 1 Region 2 Region X

Reuse drives down cost, accelerates timelines, reduces risk and enables interoperability Reuse drives down cost, accelerates timelines, reduces risk and enables interoperability

Nosolution

Nosolution

Differentspecification

Differentspecification

DifferentstandardsDifferent

standardsSpecification& standards

Specification& standards

DatamodelData

modelBusinessprocess

Businessprocess

Businessrules

Businessrules

UserInterface

UserInterface

SamesolutionSame

solutionUse shared

serviceUse shared

service

Least leverageLeast leverage Most leverageMost leverage

POINT OF SERVICE

EHR Data & ServicesREGIONAL

POINT OF SERVICE


POINT OF SERVICE





Regional/Organizational Deployment DecisionsREGIONAL

POINT OF SERVICE


BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Clientregistry

ProviderRegistry

Locationregistry

TerminologyRegistry

Drug Information

EHR Data & Services

DiagnosticImaging

SharedHealth Record

Laboratory


Security MgmtData



Common Services


PhysicianOffice EMR

EHR Viewer

Physician/Provider

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist



Business choices?• Who, where, when, what

• Clinical value

• Adoption

Solution development choices?• Services/functions

• Data persistence

• Communication standards

• Data standards

• Integration tooling

Evolution plan?• What functionality when

• EHR Service evolution path

Deployment configuration choices?• State vs regional

• Single Solution/many deployments

• Multiple solutions



135


CONTEXT





Models

SystemArchitecture




EHR Infostructure Deployment

• Strategic planning

• Change management

• System development/integration

• EHR SCP message development

• Testing (compliance)

• System implementation

• Education & training

• Operation & maintenance




EHR Data& Services

DataWarehouse

OutbreakManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtData




Common Services

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry




iEHR Data: Value Enabler For Existing Applications

EHR Infostructure (EHRi)

Enhancedpresentation

EHR SCPStandards

• Client data

• Provider data

• Location data

• Privacy data

• Security data

• Encounter data

• Blood/allergy/immunization data

• Encounter summaries

• Clinical notes

• Observations/problems/conditions

• Orders/Results data

• Referrals data

• Lab data

• Pharmacy data

• Diagnostic Imaging data

Initial data load/data feeds/integration

of systems

Data loadingData feeds

EHR SCPStandards

Hospitals/private clinics/emergency/homecare/specialty

centers/LT care

Laboratories/pharmacy / diagnostics

ADT CDR PMS

Self-care Research/surveillance

Enhancedpresentation

EHR SCPStandards

Rx Lab DI

Chronic Disease Health EducationHealth Prevention

EHR SCPStandards

Custom projectsData Mining

EHR SCPStandards



CIIF


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services

See notes page



POINT OF SERVICE


EHR Data& Services

End-User Perspective: EHR Viewer


DataWarehouse

OutbreakManagement

PHSReporting

HealthInformation

EHR Viewer

Physician/Provider

BusinessRules

EHRIndex

MessageStructures

NormalizationRules



Security MgmtData


ProviderRegistry

LocationRegistry

TerminologyRegistry

Common Services

PatientInfo

End-userInfo

VisitHistory

DrugProfile


Imaging

EHR VIEWER

ClientRegistry Shared

Health RecordDrug

InformationDiagnostic

ImagingLaboratory




End-User Perspective: EMR ApplicationORGANIZATIONAL INFOSTRUCTURE

POINT OF SERVICE


EHR Data& Services


DataWarehouse

OutbreakManagement

PHSReporting

HealthInformation

Physician Office EMR

Physician/Provider

BusinessRules

EHRIndex

MessageStructures

NormalizationRules



Security MgmtData


ProviderRegistry

LocationRegistry

TerminologyRegistry

Common Services

PatientInfo

End-userInfo

PatientHistory

DrugProfile


Imaging

EMR APPLICATION

EMRDatabase

ClientRegistry Shared

Health RecordDrug

InformationDiagnostic

ImagingLaboratory




iEHR Data: Enables New Classes of Applications

Decision supportThe HelperThe Mentor

EHR SCPStandards

? ? ?

Patients

Automated workflowDrug interactionsAbnormal results

EHR SCPStandards

? ? ?

New applicationsPatient monitoring

EHR SCPStandards

Custom projectsData mining

EHR SCPStandards

? ? ?

EHR Infostructure (EHRi)

• Client data

• Provider data

• Location data

• Privacy data

• Security data

• Encounter data

• Blood/allergy/immunization data

• Encounter summaries

• Clinical notes

• Observations/problems/conditions

• Orders/Results data

• Referrals data

• Lab data

• Pharmacy data

• Diagnostic Imaging data





Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services

141

Deployment Configurations: Hybrid Open Source and COTS-based Solutions




POINT OF SERVICE

COTS: CIS with Integrated Viewer

EHR Data& Services



OutbreakServices

PHSReportingServices

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

EAI IP EAI IP

Drug Information

System

DiagnosticImaging

EAI

Interoperability General

Integration Subscription

Context Management


CLINICAL INFORMATION SYSTEM

SharedHealth Record

Laboratory

Laboratory Shared Health Record

Longitudinal Record Services (LTS)

EHR Viewer Server

Consent Management

Authentication/Acess Control

Auditing/Logging

EA

I IP

EA

I IP

EA

I IP

EA

I IP

EHR IP Transactions: Get, Put, List; National and International EHR Standards


PhysicianOffice EMR

EHR ViewerClient

Lab System(LIS)

RadiologyCenter

PACS/RIS

PharmacySystem







POINT OF SERVICE

COTS: CIS with External Viewer

EHR Data& Services



OutbreakServices


ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

EAI IP EAI IP

Drug Information

System

DiagnosticImaging

EAI



Context Management


CLINICAL INFORMATION SYSTEM

SharedHealth Record

Laboratory

Laboratory Shared Health Record

Longitudinal Record Services (LTS)

Consent Management


Auditing/Logging

EA

I IP

EA

I IP

EA

I IP

EA

I IP


PhysicianOffice EMR

EHR ViewerClient

Lab System(LIS)

RadiologyCenter

PACS/RIS

PharmacySystem








POINT OF SERVICE

COTS Based: EAI Centric

EHR Data& Services



OutbreakServices


ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

EAI IP EAI IP

Drug Information

System

DiagnosticImaging

EAI



Context Management


Consent Management


Auditing/Logging

EA

I IP

EA

I IP

EA

I IP

EA

I IP


PhysicianOffice EMR

EHR ViewerClient

Lab System(LIS)

RadiologyCenter

PACS/RIS

PharmacySystem



EAI IP

CIS:Shared Health

Record & Laboratory



Please send suggested updates to [email protected] 144144

Enterprise Application Integration (EAI) is the unrestricted sharing of data and

business processes throughout the networked applications or data sources

in an organization.

145

iEHR-CIIF SDK: In Summary


iEHR-CIIF As Design Pattern & Standard

Provides specifications for providerorganizations & the vendor community to design and develop:• EHR infostructure

• Interfaces to allow existing systems to interoperate using EHR infostructure

• New applications that take advantage of the EHR infostructure to provide added value to service providers, patients; to promote wellness

• Provides design pattern & set ofstandardized specifications that: • Provide flexibility to meet the variety found in

existing service delivery settings while providing an ability for Organizations to evolve their solution set, leveraging their current investments in systems

• Allowing the managed addition of contributors to and users of Electronic Health Records

146iEHR-CIIF



From Concept to Implementation

interoperable iEHR-CIIF SDK provides the Blueprint for

transition to working interoperability through:

• partnering with Organizations ready to build interoperability between existing systems

• Organizations ready to incorporate their registries and domain repositories

The second vehicle fortesting and refining the

Blueprint specifications isadoption by the vendor

community and acquisitionsof “interoperable ready”

applications• Major vendors have

incorporated the iEHR-CIIF architectural approach into their product strategies

• The iEHR-CIIF can provide the framework for Organizations to evaluate vendor provided solutions and ensure they will work with their evolving iEHR-CIIF infostructures

This process will be the test-bed for the iEHR-CIIF

specifications• Elements of the iEHR-CIIF Blueprint

specifications will be updated by these project teams as the concepts are tested and refined

• Implementation guidelines will be produced to assist others in implementing these capabilities

CONCEPT IMPLEMENTATION



Maintaining the iEHR-CIIF as a National / International Standard

• It is critically important to have a stable, managed specification for interoperability

• Organizations and provider organizations need to be confident that their commitment to implementing EHR infostructure is based on a sound specification that will be maintained and managed

• Implementations of the infostructure will reveal where the specification needs to be adjusted to optimize performance and ensure reliability

• For this reason, the iEHR-CIIF specifications will be subject to the Standards Collaboration Process

• Ensuring broad participation in requirements definition

• Providing foreknowledge of the financial and change management requirements to all affected groups and organizations

• Providing a scope and change-management model for the iEHR-CIIF specifications themselves





The iEHR-CIIF Architecture In Summary: EHR Repository

Concepts• Patient’s data is stored and accessed

from one logical EHR

• Patient’s longitudinal clinically relevant information, authoritative & reliable

• iEHR-CIIF co-exists with legacy domain repositories

• iEHR-CIIF may be implemented at any organizational level

• iEHR-CIIF has a common definition

Benefits• Interoperability, performance, scalability

• Provider adoption, supports use cases across continuum of care, timely and accurate for provider

• Preserves investments, does not unnecessarily duplicate data

• Flexibility, configurable to local & regional needs

• Cost effective, standards-based, Interoperability




The Architecture In Summary: CIIF

Concepts• CIIF (Common Interoperable

Information Infrastructure (CIIF) ) provides common way to interoperate with EHRs, registries, domain repositories

• Provider applications interoperate through CIIF to access HER, providing semantic interoperability

• CIIF provides peer-to-peer trusted communication and value-added common services to enable interoperability across the continuum of care and across Organizations

Benefits• Common and standards based is most cost

effective, secure & private; applications focus on clinical logic vs. integration logic

• Cost effective environment for broad set of provider applications, standards based integration

• Secure & private, efficient, scalable, cost effective and standard runtime environment, responsive




The Architecture In Summary: iEHR

Concepts• Common standards will enable integration

& interoperability

• Standard message data protocol for external communications is HL7 V3

• Registries have common definition nationally and internationally

Benefits• Reduces design, development, test &

operational costs

• True interoperability, international standard will incent vendors

• Interoperability, cost, security & privacy




The Architecture In Summary: Applications

Concepts• Messages initiated by point-of-care

applications populate EHR with clinical data

• Provider applications read data out of the EHR via the CIIF in addition to their operational data stores

• Use cases, business rules and visualization of data is a function of the point-of-care application

Benefits• Low cost and common model of integration,

secure and private, scalable, extensible, preserves current investments

• Mass customized views of data tailored to provider needs, secure and private, scalable, authoritative, reliable, responsive

• Vendors compete and innovate, extensible, value added services for providers




Thank you!

CALL FOR PARTICIPATIONFor technical details, see companion iEHR-CIIF SDK.doc, which is also under development. Your help is solicited.

You may get the most current version of this document and submit suggestions for improvement at: http://www.osehra.org/node/47/content/documents

CALL FOR PARTICIPATION

Please send updates and suggestions for improvement to

[email protected]


Open Questions / Issues

154

1. Branding is important … should this brief be titled iEHR Kernel SDK , iEHR Infostructure SDK or iEHR SDK rather than iEHR-CIIF SDK?

2. Do the clinical, functional and technical principles, assertions, use cases and status accurately reflect those of the Services, DoD, VA and the Open Source Community best practices?

3. Help needed verifying, validating and specifying clinical services4. What is the concept for migration of data and documents from legacy systems? 5. How is metadata managed in CIIF?6. Have Data Quality metrics been established?7. How does CIIF handle data integration? Or is it ESB?8. Does CIIF facilitate federated queries?9. How does CIIF promote data virtualization?10.When will CIIF terminology models be developed?11.Will the DoD/VA VLER be interoperable with the civilian networks used by

TRICARE and the VA? 12.What System Engineering standard will be used to develop the Interface

Requirements Specification (IRS) as well as the Interface Design Document (ICD) for the CIIF?

154


HL7 EHR System Functional Model (EHR-S)(> 230 System Functions in 4 level categorization, (see attached spreadsheet for full enumeration)

NOTE: “Other” Category - The EHR-S model does NOT include Electronic Resource Planning (ERP) / Logistics and Financial components, which are needed for completeness of a military EHR.

Other O-1 Electronic Resource Planning (ERP)

O-2 Finances

O-3 Other

Business

Entity(Information)

Choreography

Infrastructure

Choreography

Business

Business

Infrastructure

Infrastructure

Infrastructure

Entity(Information)

Ser

vice

Typ

es

Sys

tem

Fun

ctio

ns

Choreography

Business

155


SystemArchitecture

ArchitecturalBehavioralViewpoints

Conceptual Independent ModelPlatform Independent Model

Platform Specific Model

ArchitecturalInformation Viewpoints

Conceptual Independent ModelPlatform Independent Model

Platform Specific Model

ArchitecturalEngineering/

TechnicalViewpointsConceptual Independent Model

Platform Independent ModelPlatform Specific Model

CUIs

CUIsCUIs

CUIs

ArchitecturalBusiness

ViewpointsConceptual Independent Model


Key to Traceability Traceability is achieved by using Concept Unique (numeric) Identifiers (CUIs) from the HL7 EHR System Functional Model (EHR-S FM)

as attributes to all artifacts. This is analogous to a library system, which uses Dewey decimal numbers as book identifiers.

Core ProjectsPlan for New, Improved, Sustained or Sunset

Capabilities

Product Line Inventory

Inventory of Systems and their Capabilities and Functions

CUIsCUIs

Approach to Architectural Traceability

Innovation/ Prototype ProjectsConceptual Independent Model


CUIs

Interoperability ProjectsConceptual Independent Model


CUIs

156


157

Healthcare SOA FrameworkBased on HL7 EHR System Functional Model & Thomas Erl’s SOA Layers

HL7 System Functions

Direct Care Supportive Information Infrastructure

Other

Business Process

Value Chains

CompositeServices Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas

Core BusinessServices

Functional Areas + Focal Classes




EntityServices

Information Management



Information Reporting and Management

Agnostic Services

C r o s s T e c h n I c a l “Common S e r v I c e s”(e.g., Security, Privacy, Auditing, Logging…)

ApplicationServices

Ambulatory Care Systems,

In Patient Care Systems

Logistics SystemsFinancial Systems

Decision Support Systems

Data MartsRepositories

Business Objects

ImplementationProfiles

Integrated Healthcare Enterprise (IHE) Profiles

Analysis Profiles Communications Profiles/Stacks

Implementation Profiles

15704/12/23


EHR DATA REUSE THROUGH H-SOA-RAACROSS EPISODES OF CARE

• Patient Demographics• Provider Demographics• Insurer Demographic

IDENTITY

Terminology

Document

• Chronic Diagnoses• Procedure History

• Patient History• Summary Lists - Medication List - Allergy/Adverse Reaction List - Immunization

Current EpisodeOf Care EHR

Previous EpisodeOf Care EHR

Reu

sabl

e S

ervi

ces

Data Must Be Verified And Updated

15804/12/23


SUPPLY CHAIN (ORDER/CHARGE)

ANATOMY OF AN ANCILLARY SYSTEM

AUTHORIZATION

DOCUMENT

RECORDS MANAGEMENT

DECISION SUPPORT

PERFORMANCE

DATA MANAGEMENT

SCHEDULING

IDENTITY

TERMINOLOGY

LABORATORY RADIOLOGY PHARMACY CARDIOLOGY OT/PT/SPEECH

s

CO

RE

B

US

INE

SS

S

ER

VIC

ES

15904/12/23

iEHR-CIIFWORKING DRAFT: not for wide distribution or official use.IT PLATFORM

SUPPORT

ANALYTIC

DATA MANAGEMENT

PERFORMANCE

DECISION SUPPORT

RECORDS MANAGEMENT

DOCUMENT

SUPPLY CHAIN: (ORDERS/CHARGES)

SCHEDULING

AUTHORIZATION

TERMINOLOGY

IDENTITY

RADIOLO

GY

LABORATORY

PHARMACY

CLI

NIC

AS

U

T

ES

T O

NLY

O

UT

PA

TIE

NT

OT

HE

R

INP

AT

IEN

T E

R

CARDIOLO

GY

PT/O

T/SPEECH

DIETARY

SPECIALTY CARE

Ancillary Systems

Co

re B

usi

nes

s S

ervi

ces

INTEGRATEDREQUIREMENTS

DESIGNS: Putting the H-SOA-RA

Pieces Together

RESPIRATORY

Fed

erat

ed B

usi

nes

sS

ervi

ces

Ag

no

stic

S

ervi

ces

Federated Services, may be categorized by: -- Encounter Types -- CMS billing category -- Record type -- Care setting type -- etc.

Data sets are defined for each system functional-

capability-service module 160In

ter-

Age

ncy

Inte

r-S

ervi

ceA

cros

sP

rovi

ders


Case Management Coordination Across SOAs and the Continuum

ASSESSMENTCARE

PLANNING

ORDERS &

SCHEDULING

BENEFITMANAGEMENT

AUTHORIZATION &

UTILIZATION MGT.

COMMUNICATION(FACILITATION

ADVOCACY)

DISCHARGE/TRANSFERPLANNING

REFERRAL RECORD TRANSPORT

ROLE OF CASE MANAGER

AcuteInpatient

ChronicRehab.

OutpatientWartimeTheater

ER AcuteRehab.

SkilledLongTerm Care

CustodialLongTermCare

HomeHealth

Prevention/Wellness

Care Continuum

Coordination ACROSS SOAS

cCOORDINATION ` ACROSS LEVELS OF CARE, PROVIDERS and LOCATIONS

EDUCATION.

16104/12/23161


ADDRESSING REAL BUSINESS ISSUES THROUGH H-SOA-RA

• Incomplete/Inaccurate Demographic Data (Identity Service)• Incomplete/Inaccurate Insurance Information (Authorization Service)• Unauthorized Service (Authorization Service)• Diagnosis/Procedure Coding Errors (Terminology Service)• Service Delays (Scheduling Service)• Incomplete and Inefficient Charge Capture (Supply Chain Service)• Non-indicated or Contra-indicated Services (Decision Support/

Authorization Services)

• Delays in EHR Document Production and Provision (Document Service)• Billing Delays and Errors (Supply Chain/ Billing/ Collection Services)• Not fully coordinated Scheduling (Scheduling Service) • Lack of fully integrated Patient Assessment and Treatment Plan (Document Service/ Decision Support Service)• Delayed or Lack of Medical Record Access (Record Service)

16216204/12/23

162


HL7 Service Aware Interoperability Framework (SAIF)Enterprise Compliance and Conformance Framework (ECCF)

Inventory of• User Cases, Contracts• Capabilities Business Mission,

Vision, Scope


Vision, Scope

Enterprise Dimension“Why” - Policy


Business Policies Governance Implementation Guides Design Constraints Organization Contracts


Business NodesBusiness RulesBusiness ProceduresBusiness WorkflowsTechnology Specific

Standards


Standards

Inventory of• Domain Entities • Activities• Associations• Information

Requirements• Information Modelso Conceptualo Domain



Information Dimension

“What” - Content



Information Models Terminologies Value Sets Content Specifications

Information Models Terminologies Value Sets Content Specifications

Schemas for• Databases• Messages• Documents• Services• Transformations


Inventory of• Functions-services Requirements• Accountability, Roles• Functional

Requirements, Profiles, Behaviors, Interactions

• Interfaces, Contracts




Computational Dimension

“How” - Behavior



Specifications• Use Cases, Interactions• Components, Interfaces

Collaboration Participations

Collaboration Types & Roles

Function Types Interface Types Service Contracts





Automation UnitsTechnical InterfacesTechnical OperationsOrchestration Scripts


Inventory of• SW Platforms, Layers• SW Environments• SW Components• SW Services• Technical

Requirements• Enterprise Service Bus Key Performance

Parameters



Parameters

Engineering Dimension

“Where” - Implementation



Models, Capabilities, Features and Versions for• SW Environments• SW Capabilities• SW Libraries• SW Services• SW Transports


SW Specifications for• Applications• GUIs• Components

SW Deployment Topologies



Inventory of• HW Platforms• HW Environments• Network Devices• Communication

Devices Technical

Requirements


Devices Technical

Requirements

Technical Dimension

“Where” - Deployments

Technical Dimension


Models, Capabilities, Features and Versions for• HW Platforms• HW Environments• Network Devices• Communication

Devices


Devices

HW Deployment Specifications

HW Execution ContextHW Application BindingsHW Deployment TopologyHW Platform Bindings



Conceptual PerspectiveConceptual Perspective

ECCFECCF

Logical Perspective

Logical Perspective

Implementable Perspective


Five (5) Categories: Capability | Mission | Business Process | Infrastructure/Enterprise Architecture | Interoperability

163



Vision, Scope


Vision, Scope






Standards


Standards









Information Models Vocabularies Value Sets Content Specifications

Information Models Vocabularies Value Sets Content Specifications

























Parameters



Parameters












Devices Technical

Requirements


Devices Technical

Requirements

Technical Dimension


Technical Dimension



Devices


Devices





Conceptual PerspectiveConceptual Perspective

ECCFECCF

Logical Perspective

Logical Perspective



Common InformationInteroperability Framework

(CIIF)

Common Service Broker (CSB) and System Analysis

Common Data Centers and

Infrastructure

System Analysis

How the iEHR Architecture Components Align to SAIF


AV-1: Overview and Summary Information.AV-2: Integrated Dictionary

CV-1: Vision CV-2: Capability Taxonomy CV-3: Capability Phasing CV-4: Capability DependenciesCV-5: Capability to Organizational Development MappingCV-6: Capability to Operational Activities MappingCV-7: Capability to Services Mapping

DIV-1: Conceptual Data ModelDIV-2: Logical Data ModelDIV-3: Physical Data Model

OV-1: High-Level Operational Concept GraphicOV-2: Operational Resource Flow DescriptionOV-3: Operational Resource Flow MatrixOV-4: Organizational Relationships ChartOV-5a: Operational Activity Decomposition TreeOV-5b: Operational Activity ModelOV-6a: Operational Rules ModelOV-6b: State Transition DescriptionOV-6c: Event-Trace Description

PV-1: Project Portfolio RelationshipsPV-2: Project TimelinesPV-3: Project to Capability Mapping

StdV-1: Standards ProfileStdV-2: Standards Forecast

SV-1: Systems Interface Description

SV-2: Systems Resource Flow Description

SV-3: Systems-Systems Matrix

SV-4: Systems Functionality Description

SV-5a: Operational Activity to Systems Function Traceability Matrix

SV-5b: Operational Activity to Systems Traceability Matrix

SV-6: Systems Resource Flow Matrix

SV-7: Systems Measures Matrix

SV-8: Systems Evolution Description

SV-9: Systems Technology & Skills Forecast

SV-10a: Systems Rules Model

SV-10b: Systems State Transition Description

SV-10c: Systems Event-Trace Description

SvcV-1: Services Context Description

SvcV-2: Services Resource Flow Description

SvcV-3a: Systems-Services Matrix

SvcV-3b: Services-Services Matrix

SvcV-4: Services Functionality Description

SvcV-5: Operational Activity to Services Traceability Matrix

SvcV-6: Services Resource Flow Matrix

SvcV-7: Services Measures Matrix

SvcV-8: Services Evolution Description

SvcV-9: Services Technology & Skills Forecast

SvcV-10a: Services Rules Model

SvcV-10b: Services State Transition Description

SvcV-10c: Services Event-Trace Description

DoDAF 2.x Views


Future-State Architecture Software Development Kit (SDK)Draft Specifications needed by Fall 2011 *

1. Built-In-Test-Environment (BITE) Service Specification to support automated fault-detection resulting from distributed ad-hoc partners & plug-and-play applications. • Model-Driven Health-Tool defines run-time schematron test fixtures.• Performance-Monitoring-Component Service-Specification to trace run-time execution

pathways and measure latency to support, system tuning, automated testing and certification.

• Code-Coverage Regression-Test and Stress-Test Tool-Specification, to support automated testing and certification of “happy path” and fault recovery pathways.

• Cross-Reference Tool-Specification to automatically map module-module and module-data dependencies and certify no unexpected changes.

• Pretty-Printer Tool-Specification to certify software-module Standards and Conventions (SAC) & to do syntax verification and readability reformatting.

* Must be done in collaboration with DoD-VA joint iEHR initiative and open source community.

166


Future-State Architecture Software Development Kit (SDK)Draft Specifications needed by Fall 2011 *

2. SAIF ECCF Implementation Guide (IG) for documenting component Interoperability Specifications, which will support new development, repurposing, reimplementation, automated testing and certification.

3. SAIF ECCF Tool Specification to manage module Interoperability Specifications, which will support new development, repurposing, reimplementation, automated testing and certification.

4. ESB Services Specification of iEHR Tier 1-2 Application Virtualization-Layer of federated standards-based services.

5. Database Services Specification of iEHR Tier 2-3 Database Virtualization-Layer of federated standards-based services.

6. Standards and Conventions (SAC), updated to modern SOA software engineering practices, as defined by Thomas Erl.

* Must be done in collaboration with DoD-VA joint iEHR initiative and open source community.

167


NIST 7497 Security Architecture * Design Principles

1. Perform Information Assurance Risk assessments of shared information;

2. Create “master” trust agreements describing requirements for a trust domain;

3. Separate authentication/credential management and authorization/privilege management;

4. Develop data protection capabilities as plug-and-play services;

5. Maintain a standards-based, technology-neutral, and vendor-neutral architecture.

* NIST IR 7497, Security Architecture Design Process for Health Information Exchanges (HIEs) , Sept. 2010, available at http://csrc.nist.gov/publications/PubsNISTIRs.html

168


NIST 7497 Security ArchitectureEnabling Services

1. Risk Assessment is a Security and Privacy Principles, which means to identify security and privacy risks to HIE operations based on threats, assets, vulnerabilities, and likelihood of threat success.

2. Entity Identity Assertion (Authentication) is HITSP Construct * SC110 & C19, which ensures that an entity is the person or application that claims the identity provided.

3. Credential Management is a Security Principles, which means to manage the life cycle of entity credentials used for authentication and authorization.

4. Access Control (Authorization) is HITSP Construct * SC108 & TP20, which ensures that an entity can access protected resources if they are permitted to do so.

5. Privilege Management is a Security Principles, which means to manage the life cycle of an entity’s authorization attributes (e.g., roles, permissions, rules) for making access control decisions.

6. Collect and Communicate Audit Trail is HITSP Construct * SC109 & T15, which defines and identifies security-relevant events and the data to be collected and communicated as determined by policy, regulation, or risk analysis.

* HITSP constructs are available at www.HITSP.org169


NIST 7497 Security ArchitectureEnabling Services

7. Document Integrity is HITSP Construct * T31, which validates that the contents of a document have not been changed in an unauthorized or inappropriate manner.

8. Secured Communication Channel is HITSP Construct * SC109 & SC112, which ensures that the mechanism through which information is shared or transmitted appropriately protects the authenticity, integrity, and confidentiality of transactions to preserve mutual trust between communicating parties.

9. Document Confidentiality is a Security Principles, which means to prevent the unauthorized disclosure of a document that is exchanged or shared.

10. De-identification is a Privacy Principles, which means to remove individual identifiers from a health record, or replace them with other information such as pseudonyms, so that it cannot be used to identify an individual.

11. Non-Repudiation of Origin is HITSP Construct * C26, which provides the proof of the integrity and origin of data in an unforgettable relationship which can be verified by any party.

12. Manage Consent Directives is HITSP Construct * TP30, which ensures that individually identifiable health information is accessed only with an individual’s consent.

D R A F T Talking Points* HITSP constructs are available at www.HITSP.org170


171

NIST 7407 Security Architecture

Web-Service Security-Standards


NIST 7497 Security ArchitectureNotional Development Process

172


Common Information Interoperability Framework (CIIF) Design-Time Environments

173


Common Information Interoperability Framework (CIIF) Run-Time Environments

174See notes page


iEHR-CIIF (Conceptual View)

175175

See notes page


1. Innovation to revitalize VistA and AHLTA • 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. 2. Interoperability among DoD, VA, IHS and purchased care partners.

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

3. Transition from legacy systems and data to an interoperable EHR architecture.• Virtualization-Layers of Federated Standards-Based Services allow new and legacy COTS, GOTS and open-

source applications, scalable databases and infrastructure to coexist. 4. Agility to respond to rapid healthcare changes and related legislation.

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

5. High Costs of change and sustainment. • 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. .

6. Patient Safety issues resulting from software changes.• Component architecture localizes faults. BITE identifies faults early, improving system robustness, patient safety.

7. Open Source Community Enablement• 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.

Future State Architecture Addressing Legacy Problems

D R A F T Talking Points176176


Information Model within iEHRBased on HL7 Service Aware Interoperability Framework (SAIF) Information Framework (IF)

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

has-anhas-an

has-a has-ahas-a

is-an

has-an

defines

has-a

is-a is-a is-a

has-an

has-a has-ahas-a

supports

177See notes page


Information Model within HL7 Service Aware Interoperability Framework (SAIF) Information Framework (IF)

178

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

has-a has-a

has-a

1..*

has-a

has-a

1..*

has-a

has-a

has-a

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

1..*

has-a

See notes page


Information Meta-Model and GlossaryBased on HL7 Service Aware Interoperability Framework (SAIF) Information Framework (IF)

179See notes page

class Information Meta-Model

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

is-modelled as-a

*has-a

is-a

is-a

is-a

has one-or-more

has-a

has

0..*

*has-a

*

has-a

binds-to one-or-more

has-a

has-a

has-a

has one-or-more


BITE Built in Test EnvironmentCIIF Common Information Interoperability FrameworkDI Diagnostic ImagingDoD Department of DefenseEAI Enterprise Application IntegrationEHRI EHR Information InfrostructureiEHR Interoperable Electronic Health RecordESB Engineering Service BusHAIMS Health Artifact and Image Management SolutionIG Implementation GuideIHS Indian Health ServicesIP Interoperability Profile / SpecificationLIS Laboratory Information SystemsLRS Longitudinal Record ServiceOSEHR Open Source EHROSEHRA OSEHT Custodial AgentRIS Radiology Information SystemSDK Software Development KitSOA Service Oriented ArchitectureTSA Telehealth Scheduling ApplicationVA Veterans AdministrationVHA Veterans Health Administration

Abbreviations

180