organizing ihe integration profiles related to the electronic health record input to the ihe iti...

Organizing IHE Integration Profilesrelated to the Electronic Health Record

Input to the IHE ITI Tech CommitteeNovember 2002

Charles Parisot, GE Medical Systems-ITKarima Bourquard, GMSIH

WardsAnesthesia

Pneumology

Order and others inputs

RegistriesKnowledge

Result andOthers outputs

(event)Process

EHR

Control (Rules, procedures,reporting)

Resources


DirectoriesKnowledge


(event)Process

EHR


Resources

General Practionner

Accute Care (Inpatient)

GPs and Clinics (Outpatient)

Nursing Homes

Other Specialized Careor Diagnostics Services

A large Number of Care Settings with many different care delivery processes

Each Care Setting (incl. Diagnostics Services) will require specific IHE Integration Profiles

WardsAnesthesia

Pneumology


RegistriesKnowledge


(event)Process

EHR


Resources




(event)Process

EHR


Resources

General Practionner

Acute Care (Inpatient)


Nursing Homes


Continuity of Care: Patient Longitudinal Record Across Encounters

A typical patient goes through a sequence of encounters in different Care Setting (incl. Diagnostics Services).

WardsAnesthesia

Pneumology


RegistriesKnowledge


(event)Process

EHR


Resources




(event)Process

EHR


Resources

General Practionner

Acute Care (Inpatient)


Nursing Homes


EHR-S ≈ Entire SystemEHR-LR= The Longitudinal Record of a person’s health

Integration : Feeding & Accessing the Longitudinal Health Record Information

Care Delivery Process

Act lifecycle

ServicesOrders Results

Act lifecycle

Selection of informations

Decide toAssess demand For care

Actions to order

Define an action plan

Identification End ofEncounter

Define healthcareObjective

EHR-CREHR-CR : EHR information supporting immediate care deliveryEHR-LREHR-LR : EHR information supporting long term care delivery

Two types of Integration : Health Record as used during care delivery Health Record as used across-encounters

C,U

EHR-CR

C,U

EHR-CR

C=createU=update

EHR-CR

C,U

EHR-CR

R = read

KnowledgeDirectoriesEHR-LR

EHR-CR

EHR-LR

C,U

KnowledgeDirectoriesEHR-LR

R

EHR-LR

C,U

RadiologyCardiology

Ward




(event)Process

EHR-LR or EHR-CR


Resources

Inside hospital…



Result andOthers outputs(event)

Process

EHR-LR or CR


ResourcesGP

Outsidethe hospital…

Care Delivery Integration Profiles : Process and workflow focus within a specific care delivery setting

Each should includetransactions with itsEHR-CR

Process1

Process 3

Process 2EHR: one or several DB + applications

r,c,u

rr,c,u

r,c,u

r r

t

t

t

tr :readc,u : create, updatet : transfer

Patient

EHR-CR

EHR-CREHR-CR

Longitudinal EHR Integration Profiles :Integration of EHR-LR (longitudinal) with the EHR-CR (care delivery)

Within Healthcare Enterprisesand Across Enterprises

EHR-LR

Proposed IHE Principles for EHR Integration:

1. EHR Care Delivery Integration Integration Profiles manage integration withinan enterprise where patients have encounters or episodes of care:• They are specific to the type of care (cardiology, surgery, etc.)

or service (laboratory, radiology, etc.) provided.

• The source of information is close to the point of care delivery

• They leverage a Care Delivery EHR (EHR-CR) that is often specific in contentand functions (acts lifecycles, workflows, display layout, to the type of care delivery.

• This EHR-CR is generally hosted in a small number of systems, often a single one.

2. EHR Longitudinal Record Management Integration Profiles focus on integrationof multiple care delivery processes related to past encounters or episodes of care:• EHR-LR Information may be consumed by care delivery processes performed

within the same enterprise or across different enterprises.

• An EHR-LR is almost always hosted on several systems. A distributed approach to information access (directories) and feeding is required.

Lets now focus on the EHR-LR or the integration for the longitudinal record ….

Patient

A simplistic model for organizing the EHR-LR

Encounter

Information

11

n

n

1

A starting point ?

A sufficient baseline ?

Lets assume that “information”in an encounter is made of a variety of documents(prescriptions, clinical notes, discharge summaries,radiology and lab reports, etc.).

EHR-LR Patient Level Directory

For each patient it references the EHR-LR instances where this patient has had one or more encounters.

EHR-LR Patient/Encounter Level Directory

For each patient it references a number of encounters instances and the EHR-LR instances where each encounter is managed.

EHR-LR Documents Repository

It is the custodian for an unspecified time of Documents recorded as a result of encounters made by patients.

EHR-LR Encounter/Documents Level Directory

For each encounter of a patient it references the Documents recorded as a result of this encounter and their repositories.

EHR-LR Integration: Directory Concept, 6 Core Actors

Patient A has encounters known on:•P/E Directory = 1•P/E Directory = 78

Patient A has encounters:• Encounter E4 on E/D = 34• Encounter E8 on E/D = 67• Encounter E56 on E/D = 641

Encounter E4 has documents;:• Document D9 on D/R = 87• Document D38 on D/R 12• Document D76 on D/R = 87• Document D92 on D/R = 87• Document D56 on D/R = 87

EH

R-L

R D

ocu

men

t F

eed

erE

HR

-LR

Do

cum

ent

Fee

der

EH

R-L

R D

ocu

men

t C

on

sum

erE

HR

-LR

Do

cum

ent

Co

nsu

mer

n-m

n-m

n-m

1-n

1-n





Example : Country-Wide (e.g. NHII)

One such P Directory by region.All shadows copies.

One such P/E Directory by region.Holds a reference to all encountersmade in the region.

One such P/E Directory by EncounterCustodian used by the health deliveryentity where the encounter happen

One or more document repositoryby document custodians used by thehealth delivery entity where theencounter happen.





Example : IDN (e.g. Group of Hospitals)

One such combined P Directory and P/EDirectory by hospital. All shadows copiesHolds a reference to all encountersmade across the entire IDN.

One such P/E Directory by Hospital where the encounter happen/ Thissystem is also the primary EHR-CR for the hospital. It also acts as theDocument repository for a number ofdocuments.

A number of independent documentrepositories are also used in the hospitalfor certain types of documents (e.g. images, waveforms, etc.).





Example : GP Office in multiple IDNswith an EHR-LR ASP

One such combined P Directory and P/EDirectory by IDN.Holds a reference to all encountersmade by the GP

One such P/E Directory by the GP’s selected EHR-LR ASP. This ASPsystem is also the primary EHR-CRfor all documents created by the GP’sencounters.


EHR-LR : A persistent document management system

1. Does the longitudinal record (EHR-LR) receives clinical data inputother than from Documents ?• By Documents, one uses the HL7-CDA definition: Persistence, Stewardship,

Potential for Authentication, Context, Wholeness, Human Readability.

• There are numerous need for accessing and viewing information that will not besupported by a CDA, but no use cases has been identified for input into an EHR-LRother than through persistent documents. This is especially important for attestability.

• A CDA Based clinical information input for EHR-LR includes much more than theHL7-CDA standard. It should also include the document management transactions(store, update, commit, delete, retrieve, query, etc.)

2. What about other EHR functions that require integration such as workflow and security ?• The above statement does not mean that an operational EHR-LR does not need other

transactions such as workflow management functions (reminders, requests, questions, etc.) and infrastructure integration functions (security, consent mgt,patient identifier cross-referencing, etc.). In the context of IHE these functions arehandled by specific integration profiles and actors.

3. What about other documents than directly patient related in the EHR-LR ? • Such documents may exist but are considered out of scope of the EHR-LR

Integration Profile. They will be addressed by other integration profiles.

Open Issues:

1. This approach relies on two key concepts: Patient and Encounter• The EHR-LR is organized as a document repository where documents are assigned

to a patient. All patients are known by one or more Patient Identifiers is patient iddomains. Each one of the EHR-LR Actor resides within predefined domainscross-referenced by the PIX Integration Profile.

• The EHR-LR is organized as a document repository where documents are assignedto an encounter. In addition, all documents from an encounter can be registered with asingle Encounter/document Directory. The concept of Encounter shall be clearlydefined (suggest using HL7 V3 Patient Admin concept). HL7V3 allows Encounter to bea recursive concept. Should this be supported, or should one limit the EHR-R to thetop-level encounter ?

2. Need to ensure that a simple query will allow to identify documents of interest inan encounter without accessing the document itself.• One should ensure that at the level of encounter and document a small number of

meta attributes are defined to allow for easy human and computer selection ofappropriate documents. The CDA header offers a solid set of such meta attributes.Is this sufficient ?