ESP SDK WORKING DRAFT RFI: not for official use. 1 Open Source EHR Custodial Agent (OSEHRA)...

ESP SDK WORKING DRAFT RFI: not for official use. 1

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

In collaboration withHealth Architecture Interagency Group (HAIG)

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

Current 180+ slide set Conceptual Architecture SDK and companion Implementation Guide (IG) is available at: http://www.osehra.org/node/47/content/documents

October 18, 2011 DRAFT-N

EHR Modernization - Conceptual ArchitectureEHR Services Platform (ESP) - Software Development Kit (SDK)

CALL FOR PARTICIPATION Please post your discussion comments at http://www.osehra.org/group/architecture

This DRAFT document is a Request for Information (RFI)

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

http://www.osehra.org/group/architecture

ESP SDK WORKING DRAFT RFI: not for official use.

PrefaceIn March 2011, VA Secretary Eric Shinseki and DOD Secretary Robert Gates agreed on a common Electronic Health Record (EHR) technical architecture, data and services and exchange standards for the joint integrated EHR system, 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 common EHR..

“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 Software Development Kit (SDK) specifies the EHR Services Platform (ESP) to implement the vision expressed above .

22

Executive Summary

3

EHR Services Platform

SDK Scope

Business Context

Clinical/Work Process Architecture

System Architecture

Information Architecture

Integration & Deployment Options

Potential Applications

Summary & Conclusion

WORKING DRAFT RFI: not for official use

SAIF (Service Aware Interoperability Framework)

Conceptual Perspective

Also See CompanionSAIF Logical Perspective

Implementation Guide (IG)

ESP SDK


TALKING POINTS: SDK PurposeESP enabled systems are a part of a joint DoD-VA Open Source EHR (OSEHR) Initiative

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

plug-&-play application-integration.

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

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

YOUR HELP IS REQUESTED IN VERIFYING, VALIDATING AND INCREASING THE

USABILITY OF THE ESP SDK

44


ACKNOWLEDGEMENT

This ESP SDK started with the Canada Health Infoway “Electronic Health Record Blueprint” as a foundation; the SDK is being adapted to meet the Open

Source EHR modernization 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



DISCLAIMER

THIS DRAFT SDK IS NOT LEGALLY BINDING

AND DOES NOT REPRESENT OFFICIAL DOD OR VA POSITION.

• The DoD and VA wish to openly-and-transparently collaborate with the Open-Source EHR-Community; this is a new “agile acquisition” approach for the government and MUST evolve with lessons learned.

• This SDK, its companion Implementation Guide (IG) and related artifacts are DRAFT Working Documents, being coordinated by the Open Source EHR Custodial Agent (OSEHRA) Architecture Committee with the guidance of the DoD-VA Health Architecture Interagency Group (HAIG). The purpose is to seek EHR-modernization architectural-input from DoD & VA staff, contractors, partners, stakeholders, venders and open-source-community in an open-and-transparent collaborative-forum;

• The DRAFT Software Development Kit (SDK), its IG and any related documents MUST be considered a government Request for Information (RFI); without obligation to the government as we go through this new open-and-transparent agile-development-process;

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

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

6


Technical Vision: EHR Service Platform (ESP)

INTEGRATED EHR SOLUTION

EHR SERVICES PLATFORM (ESP)

EHR ViewersPoint of Service

ApplicationsPersonal Health Record Systems

EHR ISLocator

Information Access & Longitudinal Record Services (LRS)

EHR Information Services (EHR IS)

EHRData &

Services

RegistriesData &

Services

Population HealthData &

Services


Services

See notes page


TALKING POINTS: Technical Vision is to modernize and transition legacy to an EHR Services Platform (ESP) for Application Integration

• An EHR Services Platform (ESP) facilitates application innovation; it is composed of separated operation, business-rule and information services to integrate plug-&-play applications; the ESP services MUST be used by ALL applications and ALL applications MUST be service-based.

• As the ESP is fully-specified in the SDK Implementation Guide (IG), as standardized and reference implementations become available; then, general-purpose and domain-specific “best-of-class” certified applications can be user-selectable and evolve on a Darwinian basis. This is analogous to a Smart-Phone Application-Markets

• Anyone can build and submit ESP services and/or applications for certification• The Open Source EHR Custodial Agent (OSEHRA) will IV&V and CM certified ESP

application services and reference-implementations (e.g., gold builds).• DoD, VA, IHS and others may pick-&-choose, which certified applications they use.• Legacy-systems and ESP enabled systems can co-exist during long legacy transition

periods across large enterprises. This is analogous to the PC and telecommunications evolution-revolution from the 1980s to now.

88


Key Concepts: Federated EHR Services Architecture



EHR ViewersPoint of Service

ApplicationsPersonal Health Record Systems

EHR ISLocator



EHRData &

Services

RegistriesData &

Services

EHR IS

EHR IS Enabled Legacy System

ESP Based SystemPopulation

HealthData &

Services

EHR IS Enabled PHR System

See notes page

Tier 1Plug-&-PlayApplications

Tier 2EHR

Information Services

Tier 3Plug-&-PlayData Stores

ApplicationServices Layer

Data AccessServices Layer

EHR IP

EAI IP

EHR IPEHR IP

IP is SOA Interoperability Profile aka Service Interface

EAI is Enterprise Application Integration


Services


TALKING POINTS: Benefits

D R A F T Talking Points

The ESP can become the National and possible International EHR standard for “best-of-breed” Darwinian innovation, evolution or

revolution where anyone can participate.

The SDK’s Standards-Based Best-Practices ensure consistency across:

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

– Interoperable Virtual Database (DB) APIs scalable from• Legacy MUMPS-globals acting as a DB to MS Access, Open or MS SQL, Oracle to• Massively-parallel high-performance grids running on commodity-hardware-blade-platforms

(i.e., amazon.com & google.com models).

– ESP enabled Trading Partners

– Acquisitions (ESP SDK-IG as GFI for RFIs and RFPs)

– VA, DoD and IHS offices, staff and contractors

– Open Source and vender community

10


Legacy Transition Strategy

LEGACY EHR SYSTEM

EHR-IS ENABLED LEGACY INFRASTRUCTURE

LegacyPoint of Service

Application



EHR ViewerPoint of Service

Application

Personal Health Record

Systems


Services

DataWarehouse

Data & Services

EHRData &

Services

RegistriesData &

Services



DataWarehouse

Data & Services




System

EHRData &

Services

11

EAI IP


IP is SOA Interoperability Profile aka Service InterfaceEHR-IS enabled legacy systems allow users to transition at a convenient time and then legacy

systems can be gracefully shut down.

EHR IP

EAI IP

EHR IPEHR IP

Legacy

EHR-ISEHR-IS

Bi-Directional Information Exchange

EAI IP


TALKING POINTS: Transition Strategy based on ESP enabled systems

12

1. ESP kernel-services and data stores CAN be set-up at one-or-more data-centers (any cloud topology). 2. For pre-certification self-testing and attestation, venders and developers MUST be provided: i) SDK-IG,

ii) an open-source test virtual-machine (VM) with the ESP set-of operating-and-data services, iii) clinically-meaningful test-database, test-scripts, certification-criteria.

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

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

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

ESP data-store and to query via the ESP, analogous to legacy “BHIE” DoD-VA sharing; 5. Terminology mapping SHOULD be a part of legacy-data transition.6. To be repurposed to ESP capability, legacy-applications MUST conform to ESP SDK-IG and associated

certification criteria. 7. Once certified ESP enabled viewer(s) and ESP enabled applications are available to clinical users, they

CAN transition to modernized ESP based systems, while others might continue on legacy systems. 8. Clinically-meaningful legacy-data MUST be extracted to ESP before legacy systems are shut down.

12


EHR Information Services (EHR IS) within EHR Services Platform (ESP)


Population Health Data& Services

Registries Data& Services

EHR Data& Services

Data Warehouse

& Services

OutbreakManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

POINT OF SERVICE APPLICATIONS

Hospital, LTC,CCC, EPR

PhysicianOffice EMR

EHR Viewer

Physician/Provider

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtRules/Data

Privacy Mgmt Rules/Data

Configuration Rules/Data

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist

Public HealthServices

Public Health Provider


EHR ISSecure Communications Bus

Common Information Integration Framework (CIIF) and Common Services

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

ORGANISATIONAL INFOSTRUCTURE

See notes page

EHR IPEHR IPEHR IPEHR IPEHR IP EHR IP EHR IP

EAI IPEAI IP

IP is SOA Interoperability Profile aka Service Interface



TALKING POINTS: Common Information Integration Framework (CIIF)

• The Common Information Integration Framework (CIIF) is a business-driven agile enterprise-information-management methodology and set of software-service technologies, which enable semantic interoperability of clinical data.

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

1414See notes page


ERH Services Platform (ESP) enabled system (conceptual view)

1515

See notes page


1. Innovation to revitalize legacy systems• 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 partners.

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

3. Transition from legacy systems and data to an integrated 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.

TALKING POINTS: EHR Services Platform (ESP)Addressing Legacy Problems

D R A F T Talking Points1616


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

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

Vision, Scope

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

Vision, Scope

Enterprise Dimension“Why” - Policy

Enterprise Dimension“Why” - Policy

Business Policies Governance Implementation Guides Design Constraints Organization Contracts

Business Policies Governance Implementation Guides Design Constraints Organization Contracts

Business NodesBusiness RulesBusiness ProceduresBusiness WorkflowsTechnology Specific

Standards

Business NodesBusiness RulesBusiness ProceduresBusiness WorkflowsTechnology Specific

Standards

Inventory of• Domain Entities • Activities• Associations• Information

Requirements• Information Modelso Conceptualo Domain

Inventory of• Domain Entities • Activities• Associations• Information

Requirements• Information Modelso Conceptualo Domain

Information Dimension

“What” - Content

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

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

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

Requirements, Profiles, Behaviors, Interactions

• Interfaces, Contracts

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

Requirements, Profiles, Behaviors, Interactions

• Interfaces, Contracts

Computational Dimension

“How” - Behavior

Computational Dimension

“How” - Behavior

Specifications• Use Cases, Interactions• Components, Interfaces

Collaboration Participations

Collaboration Types & Roles

Function Types Interface Types Service Contracts

Specifications• Use Cases, Interactions• Components, Interfaces

Collaboration Participations

Collaboration Types & Roles

Function Types Interface Types Service Contracts

Automation UnitsTechnical InterfacesTechnical OperationsOrchestration Scripts

Automation UnitsTechnical InterfacesTechnical OperationsOrchestration Scripts

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

Requirements• Enterprise Service Bus Key Performance

Parameters

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

Requirements• Enterprise Service Bus Key Performance

Parameters

Engineering Dimension

“Where” - Implementation

Engineering Dimension

“Where” - Implementation

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

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

SW Specifications for• Applications• GUIs• Components

SW Deployment Topologies

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

Devices Technical

Requirements

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

Devices Technical

Requirements

Technical Dimension

“Where” - Deployments

Technical Dimension

“Where” - Deployments

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

Devices

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

Devices

HW Deployment Specifications

HW Execution ContextHW Application BindingsHW Deployment TopologyHW Platform Bindings

HW Deployment Specifications

HW Execution ContextHW Application BindingsHW Deployment TopologyHW Platform Bindings

Conceptual PerspectiveConceptual Perspective

ECCFECCF

Logical Perspective

Logical Perspective

Implementable Perspective

Implementable Perspective

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

17


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

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

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

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

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

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

1818

ESP SDK Conceptual View

19

EHR Services Platform concepts

SDK Scope

Business Context


System Architecture






Generally, only the preceding Executive Summary is distributed via e-mail

The most-current 180+ slide ESP SDK Conceptual Architecture and The most-current evolving ESP SDK Implementation Guide (IG)

can be downloaded at: http://www.osehra.org/node/47/content/documents

CALL FOR PARTICIPATION Please post your discussion comments at http://www.osehra.org/group/architecture

Next: ESP SDK Future-StateSAIF Conceptual Perspective

ESP SDK

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


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

Abbreviations

20


Suggested Plan of Actions and Milestones (POA&M) toRefactor & Certify Legacy MUMPS within ESP Enabled System1. CY2011: Verified System Architecture, Product Baseline and Roadmap

2. CY2012: Prepare

• Complete ESP SDK through Open-Source-Community & DoD, VA, IHS collaboration • Specify future-state ESP Key Performance Parameters (KPPs) and implementation constraints• Get ESP SDK officially endorsed by DoD and VA leadership; work ESP SDK through HL7, OASIS & OMG SDOs• Specify OSEHR automated ESP enabled system certification-test-scripts & Built-in-Test-Environment (BITE)• Proof-of-concept refactoring-prototype (e.g., scheduling, clinical & nursing notes modules) • ESP enabled system & test environment prototype in a Virtual Machine (VM)

3. CY2013: Build Critical Components

• Construct automated-certification test-scripts for ESP & key applications• Construct ESP Built-in-Test-Environment (BITE)• Construct ESP reference-implementation in a VM test environment• Refactor & certify VistA Kernel & FileMan into as ESP enabled system

4. CY2014: Build Necessary Components

• Refactor & certify strategically important applications to be ESP conformant.• Refactor & certify other modules/routines in MUMPS to use ESP SDK specified services

5. CY2015: Integrate and Make Everything Work to Users Satisfaction

• ESP Integrate & certify other-available critical-components ESP (e.g., VLER, pharmacy, lab, imaging) • Performance optimize ESP & integrated applications to meet KPPs

21


Suggested OSEHRA Role in MUMPS Code Refactoring

1. Thought Leadership

2. OSEHR System Architecture, Product Definition and Roadmap

3. Technical, Operational and Functional Certification

4. Open Source Tools, Test & Collaboration Environment Management

5. Configuration Management of:

1. OSEHR Services Platform (ESP) Software Development Kit (SDK)

2. Codebase

3. Certification test artifacts (fixtures, results, attestations)

6. Technical/ Standards Mentoring, Verification and Validation of:

1. Refactoring

2. ESP system enablement (Refactored VistA Kernel & Fileman Modules)

3. Automated Certification test scripts, fixtures & Built-in-Test-Environment (BITE)

4. Operational/technical/functional testing and certification

7. Open Source Community Engagement and Professional Organizations Evangelism

22

Outline

23

EHR Services Platform Concepts

ESP SDK Scope

Business Context


System Architecture






ESP SDK Future-StateSAIF Conceptual Architecture

CALL FOR PARTICIPATION Please post comments at


ESP SDK


EHR IS 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

2424


ESP SDK Scope

WORK PROCESS INFORMATION SYSTEM TECHNOLOGY

framework V1framework V2

EHR IS CONCEPTUAL LAYER ADDRESSES BUSINESS CONTEXT(Mission, objectives, stakeholders, benefits)

EHR IS Implementations

framework V2framework V1framework V2

Conceptual

framework V2 framework V2 framework V2Logical

Physical

YES YES YES

YES YESYES

26

Architecture Perspectives

CONTEXT

BusinessArchitecture

ClinicalWork ProcessArchitecture

PotentialApplications

Integration &Deployment

Models

SystemArchitecture

InformationArchitecture

WORKING DRAFT RFI: not for official useESP SDK

27


CONTEXT





Models

SystemArchitecture



28

Business Context


Healthcare Industry

29

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

HELP NEEDEDThis slide should

be updated to current US

figures

HELP NEEDED validating that this Canada Health Infoway based-slide applies to the US ESP/EHR IS situation & needs. Please send your feedback 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%



be updated to current US

figures


Why an ESP? 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

32WORKING DRAFT RFI: not for official use See notes pageESP SDK

Why an EHR IS? The World of Healthcare is Changing…

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

33WORKING DRAFT RFI: not for official useESP SDK


• 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



35

EHR IS: 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

37

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.

WORKING DRAFT RFI: not for official use See notes pageESP SDK


38

The EHR Information Services are 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.

WORKING DRAFT RFI: not for official use See notes pageESP SDK


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

EHR IS Outcomes




Key EHR IS Architecture Concepts


EHR Services Platform (ESP)


ApplicationPoint of Service

Application

EHR ISLocator




Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services

See notes page


ESPESP ESPESP ESP ESPESP

EHR Services Platform (ESP) Recommended Approach for Partner Collaboration

EHR IS ENABLED SYSTEM SOLUTION

EHR INFOSTRUCTURE (EHRi)


Application

Point of Service

Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services






Application

Point of Service

Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services



41

HELP NEEDED validating that this Canada Health Infoway based-slide applies to the US ESP/EHR IS situation & needs. Please send your feedback to [email protected] See notes page



EHR IS Infostructure: Conceptual ArchitectureORGANISATIONAL 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

Privacy Data Configuration

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist





Information and Common Services

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry




Guiding Principles for EHR Services Platform (ESP)

• 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


be updated

See notes page


A Few Misconceptions About integrated 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 integrated 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 integrated EHR Solution

• The EHR IS: 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: To Support Modular Plug-&-Play Innovation

OBJECTIVEA change-immune domain-specific component-

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

costly agile module-level innovation.

PROBLEMLittle innovation, long lead times and

high costs resulting from complex highly-coupled components

46


Coordination Across the Enterprise

CommonServices

Bus (CSB)

EHR IS

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

47See notes page


The EHR IS drives the ESP enabled run-time environment

48

EHR IS


Rules EngineMediation ServicesTranslation Services

Common Information Interoperability Framework (EHR IS)Common Information Model, Common Terminology Model, Information Exchange Specifications,

Translation Service Common Data Standards:

Pharmacy Delivery Use Case – The EHR IS Leads the Way

49See notes page

50

Business/Clinical Scope



EHR IS Serving Healthcare Service DeliveryEHR IS ENABLED SYSTEM SOLUTION



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 (EHR IS): 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 ESP

• 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 EHR IS 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: EHR IS 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. EHR IS 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

Data Warehouse

& Services

OutbreakManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtData





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

EHR IS 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


Privacy Rules/Data





EHR IS 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



EHR IS Framework: Tele-Consultation

58



Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services





Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services



Local ElectronicMedical Record

Live Video-ConferencingSession

Tele-Consultation Devices Data

TelehealthApplication

TelehealthApplication

Local ElectronicPatient Record


HELP NEEDED validating that this Canada Health Infoway based-slide applies to the US ESP/EHR IS situation & needs. Please send your feedback to [email protected] ESP SDK




Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services





Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services



EHR IS Framework: Tele-Homecare

59

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



EHR IS Framework: Tele-Triage

60

Tele-TriageApplication

Patient Info End-user Info

EventHistory

ClinicalProfile

Scheduling Video Session


Application

EHR Viewer




61

Clinical, Business & Socio-economic Drivers for integrated EHR solutions



Why is Value Created by an integrated 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 ESP Enabled System 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 ESP Enabled System?




Pharmacy

Laboratory

DiagnosticHospital Emergency

Homecare


Clinic Emergency Services

Specialist Clinic

Why Pursue The EHR IS: 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 EHR IS is a Key to a Renewed Health System!

integrated 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



EHR IS 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

HELP NEEDED validating that this Canada Health Infoway based-slide applies to the US ESP/EHR IS situation & needs.

Please send your feedback to [email protected] See notes page

68

Different Approaches To Achieving EHR IS



Clients/Patients

EHR IS: 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


Please send your feedback to [email protected]


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 --- EHR IS

• 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 unique person

identification solution



The DoD & VA use the Electronic Data Interchange Personal Number, or EDIPN, is a unique number assigned to a record in the United States Department of Defense's Defense Enrollment and Eligibility Reporting System (DEERS) database. A record in the DEERS database is a person plus personnel category (e.g.

contractor, reservist, civilian, active duty, etc.).

72

The Integration Challenge of integrated 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 EHR IS• Discovery capability• Availability in electronic format• Timeliness

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

• Heterogeneous technology environments

• Number of organizations, connection points & systems

• Costs inherent to integration



78

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 (Canadian example)

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

• 1.5 B integration points

• $183.928 B

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




We need a different approach


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) (Canadian example)

• Assuming existence of standardized protocol for interfaces

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

• $202.316 M (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






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



82


CONTEXT





Models

SystemArchitecture




EHR IS Work Process Architecture

• The EHR Clinical Reference Framework: Life of the Lamberts

• Depiction of the use of an integrated 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



Functional/Clinical Help needed downloading, verifying, validating the 14 storyboards and integrating them into the SDK


EHR IS Reference Architecture

EHR IS Reference

Architecture 84

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

EHR ISComm 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



Please send your feedback to [email protected] ESP SDK


Documenting EHRi Services Requirements

EHR IS 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


Privacy Rules/Data





EHR IPEHR IPEHR IPEHR IPEHR IP

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

EAI IP

EAI IP

EHR IS

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

LocationRegistry

TerminologyRegistry

ClientRegistry E

AI

IPE

AI

IPE

AI

IPE

AI

IP



IP is Interoperability ProfileEAI is Enterprise Application Integration





EHR Data& Services

DataWarehouse

POINT OF SERVICE

People Use Cases: Caregiver Perspective


Privacy Rules/Data





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

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



EHR IS

EHR Interoperability Profile (IP)

Information Exchange Content Standards

Information ExchangeTransport Standards

• Second class of SDK normative deliverables; specify the interfaces between POS applications and ESP Enabled System (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)


Privacy Rules/Data




• Third class of SDK normative deliverables; specify inner workings within ESP Enabled System 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)


Privacy Rules/Data




• Fourth class of SDK normative deliverables; specify inner workings within ESP Enabled System 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



90


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


Privacy Rules/Data


Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist






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


Privacy Rules/Data

Configuration Rules/DataEAI IPEAI IP










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

EHR IS


Privacy Rules/Data



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

EHR IS

BusinessRules

EHRIndex

MessageStructures

NormalizationRules


Longitudinal Record Services (LRS)

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

EHR IS

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)

Longitudinal Record Services (LRS)

DATA

Key MgmtServices

ETLServices

BUSINESS

Data QualityServices


EHR IndexServices




AssemblyServices

DataServices

ReplicationServices




CROSS-ORGANIZATIONAL INFOSTRUCTURE

EHR Infostructure: EHR IS 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 EHR IS)• 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

EHR ISLocator






POINT OF SERVICE

Organization

AOrganization

BOrganization

C

Centralized Service Approach

EHR ISLocator





Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services







Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services






Application


Services

HealthInformation

DataWarehouse

EHRData &

Services

RegistriesData &

Services


EHR Information Services (EHR IS) EHR Information Services (EHR IS)






POINT OF SERVICE

Distributed Service Approach

EHR IS Locator Synchronization

EHR ISLocator

EHR ISLocator

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

EHR IS Locator: LRS Integrated ApproachCROSS-ORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse


BusinessRules

EHRIndex

MessageStructures

NormalizationRules


ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

EHR IS

EHR ISLocator




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

EHR IS

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

EHR IS

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

EHR IS

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry




EHR Infostructure: Why A Client Registry?ORGANIZATIONAL INFOSTRUCTURE



EHR Data& Services

DataWarehouse

POINT OF SERVICE

EHR IS

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

SSNULIECID

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.



The DoD & VA ULI is called Electronic Data Interchange Personal Number, or EDIPN, is a unique number assigned to a record in the United States Department of Defense's Defense Enrollment and Eligibility Reporting System (DEERS) database. A record in the DEERS database is a person plus personnel category

(e.g. contractor, reservist, civilian, active duty, etc.).

MDR – Medical Device RegulationsSSN – Social Security NumberULI – Unique Lifetime Identifier


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

EHR IS

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry







EHR Data& Services

DataWarehouse

POINT OF SERVICE

EHR IS

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



112

Standards-based Solutions: What Does It Mean?


integrated EHR Solutions: Key Architectural Requirements

Standards-based

Solutions

StandardizedArchitecture

StandardizedInterfaces

StandardizedData Structures

StandardizedData Vocabularies(encoding rules)

StandardizedFunctional Behaviour



An OSEHRA role is to encourage standards and requirements for robust, interoperable

EHR products for improved clinical

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 ESP Enabled System Standards

• The HL7 has created Principles for Establishing EHR interoperability

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

• As the ESP 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 EHR IS Infostructures and EHR IS Solutions that need to guide detailed design and development of solutions and Business-driven Adoption of existing standards where ever possible




Principles for Establishing EHR IS 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 EHR Services standards

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

• We should support early adopter investment projects that have the establishment of National standards as their goal

HELP NEEDED to confirm Official DoD-VA Principles




Principles for Establishing EHR IS 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

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

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

• OSEHRA program and its stakeholders will partner with HL7, IHE, OASIS, IHTSDO and other standards organizations in the establishment of EHR IS standards

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



HELP NEEDED to confirm Appropriate 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 integrated EHR Services Platform (ESP)

• 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




EHR IS Standards: Status

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

(coming soon)• EHR Clinical Standards

(coming soon)• Public Health (coming soon)

Suggested Projects

• ESP 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-EHR IS Evolution Project• Privacy & Security Architecture Project

Health Surveillance

Telehealth

Lab

Diagnostic Imaging

Drugs

Registries

integrated EHR



HELP NEEDED to confirm Current Status


EHR IS 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

EHR IS

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

Architecture Standards

• ESP Blueprint

• EHR Use Cases

• FHIM/EHR Data Model

• EHR IS 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)

• Clinical Messaging (in planning)

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



121

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




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. Information Access & 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 Privacy Data Configuration

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist






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





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



126

Functioning Principles



Functioning Principles/Rules

• Home/no-home EHR

• EHRi Identifier Management

• EHR Index

• ESP Locator

• POS to EHRi interface

• Level of transparency of EHR to POS applications

• Transaction scope

• Trust Models valid for an EHRi

• EHR IS 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 EHR IS (POS to POS)

• Multilingual capabilities

• Runtime environment

• Performance principles – targets

• POS Integration environment

• Error Handling

• Consent

• Authentication & Authorization

• OIDS as a principle

• Prospective Events



128


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.

130See notes page


Key Terms and Concepts … Terminology

131

The approach to common terminology is for both agencies to use SNOMED + Extensions = Lingua Franca for semantically interoperable Terminology. The

EHR Services Platform will incorporate the EHR IS Information and terminology models as the logical data models for our shared (virtual)

repositories; thereby, improving semantic interoperability and performance.

131See 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 EHR IS 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

132


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

133See notes page


EHR IS ServicesServices Provided by EHR IS

•Translation – syntactic and semantic data harmonization using standard information models and SNOMED CT and extensions as the EHR IS conical terminology and ESP 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 EHR IS

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

134134

135


CONTEXT





Models

SystemArchitecture



136

EHR IS Integration Layer: Evolutionary Path



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: EHR IS 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


Privacy Rules/Data




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: EHR IS 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


Privacy Rules/Data

Configuration\ Rules/Data



EHR Viewer

Physician

PharmacySystem

Pharmacist

HL7HL7

EH

R IP

EH

R IP

Information Access & LRS

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


Privacy Rules/Data

Configuration

Rules/Data

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist






ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

Target State: Full Featured EHR IS 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.



141

ESP 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, EHR IS and EHR Viewer

• ESP 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 EHR IS

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

• ESP Locator across organizations or regions

• Local EMR, CIS and other applications

REGION 1


ClientRegistry

ProviderRegistry

LaboratoryRepository

DrugRepository

DIRepository

REGION 2



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



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 EHR IS & EHR Viewer

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







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



Privacy Rules/Data

Configuration

Rules/Data




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


Privacy Rules/Data

Configuration

Rules/Data



Information Access & Longitudinal Record Services (LRS) Information Access & 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/Data

Clientregistry

ProviderRegistry

Locationregistry

TerminologyRegistry

Drug Information

EHR Data & Services

DiagnosticImaging

SharedHealth Record

Laboratory


Security MgmtData

Privacy Rules/Data





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



148


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





ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry




ESP 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



EHR IS


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


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


PatientInfo

End-userInfo

PatientHistory

DrugProfile


Imaging

EMR APPLICATION

EMRDatabase

ClientRegistry Shared

Health RecordDrug

InformationDiagnostic

ImagingLaboratory




ESP 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

154

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: Clinical Information System (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: Enterprise Application Centric (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 your feedback to [email protected] 157157

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

business processes throughout the networked applications or data sources

in an organization.


158

ESP SDK: In Summary


EHR IS 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



From Concept to Implementation

interoperable ESP 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 EHR IS architectural approach into their product strategies

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

This process will be the test-bed for the EHR IS

specifications• Elements of the EHR IS 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 EHR IS 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 EHR IS 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 EHR IS specifications themselves

161WORKING DRAFT RFI: not for official use


Please send your feedback to [email protected] ESP SDK


The EHR IS 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

• EHR IS co-exists with legacy domain repositories

• EHR IS may be implemented at any organizational level

• EHR IS 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: EHR IS

Concepts• EHR IS (EHR Information Services (EHR

IS)) provides common way to interoperate with EHRs, registries, domain repositories

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

• EHR IS provides peer-to-peer trusted communication and value-added Information and 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: ESP

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 EHR IS 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 PARTICIPATIONSee companion ESP SDK Implementation Guide (IG),

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 post your comments at



Backup

The following slides are more technical in nature and will be discussed in the EHR Services Platform SDK Implementation Guide


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

168


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

169

ESP SDK WORKING DRAFT RFI: not for official use.170

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

170


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

17104/19/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

17204/19/23

ESP SDK WORKING DRAFT RFI: not for 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 173In

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.

174

174


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)

175175

175


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 ESP initiative and open source community.

177


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 ESP Tier 1-2 Application Virtualization-Layer of federated standards-based services.

5. Database Services Specification of ESP 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 ESP initiative and open source community.

178


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

179


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


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

ESP SDK WORKING DRAFT RFI: not for official use.182

NIST 7407 Security Architecture

Web-Service Security-Standards


NIST 7497 Security ArchitectureNotional Development Process

183

ESP SDK WORKING DRAFT RFI: not for official use. 1 Open Source EHR Custodial Agent (OSEHRA)...

Documents

Transcript of ESP SDK WORKING DRAFT RFI: not for official use. 1 Open Source EHR Custodial Agent (OSEHRA)...