v5 organizing ihe integration profiles related to the electronic health record initial thoughts ihe...

V5

Organizing IHE Integration Profilesrelated to the Electronic Health Record

Initial Thoughts

IHE ITI Tech Committee - November 2002

V5

IHE Integration Profiles Focused on the EHRIHE Integration Profiles Focused on the EHR

• An IHE Integration Profile organizes a set of coordinated, standards-based transactions between a subset of the functional components of healthcare enterprises in order to address a specific clinical or infrastructure need.

• IHE develops such solutions for IT systems integration in a stepwise and pragmatic manner, focusing on the most common integration challenges.

• IHE has developed close to 20 Integration Profiles focuses on Radiology, Laboratory, IT Infrastructure (MPI, Security, etc.) and is now expanding to Cardiology. This is an intra-enterprise, bottom-up approach.

• In this proposal, IHE explains how it intends to approach the longitudinal dimension of the EHR with a distributed, cross-enterprise, document centric, top-down point of view.

• The strategy is to progressively bridge the two approaches as new integration profiles are developed.

Feedback on this approach and expanding collaborations are sought.

V5

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

Acute Care (Inpatient)

GPs and Clinics (Outpatient)

Nursing Homes

Other Specialized Careor Diagnostics Services

Continuity of Care: Patient Longitudinal Record Across Encounters

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

V5




(event)Process

EHR


Resources

General Practionner




(event)

Process

EHR


Resources

General Practionner

WardsAnesthesia

Pneumology


RegistriesKnowledge


(event)Process

EHR


Resources



Nursing Homes


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

Integration : Feeding & Accessing the Longitudinal Health Record Information

V5

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

EHR-CRR = read

KnowledgeDirectoriesEHR-LR

KnowledgeDirectoriesEHR-LR

R=Read

EHR-LR

CreateUpdate

V5




(event)Process

EHR


Resources

General Practionner

WardsAnesthesia

Pneumology


RegistriesKnowledge


(event)Process

EHR


Resources




(event)

Process

EHR


Resources

General Practionner



Nursing Homes


EHR-S ≈ Entire SystemEHR-LR= The Longitudinal Record of a person’s healthEHR-CR= Care-delivery Record

Integration : Feeding & Accessing the Longitudinal Health Record Information

EHR-LR

EHR-CR

EHR-CREHR-CR

EHR-CR

V5

EHR-LR Documents Repository

Custodian for an unspecified time of Documents recorded from patient encounters.

EHR-LR Directory

EHR-LR Directory

EHR-LR Documents Virtual Repository

Custodian for an unspecified time of Documents recorded from local patient encounters.

EHR-LR Encounter/Documents Directory

EHR-LR Use Cases: Directory Concept, Core Actors D

ocu

men

t C

reat

or

Do

cum

ent

Cre

ato

r Do

cum

ent

Co

ns

um

er

Do

cum

ent

Co

ns

um

er

EHR-LR Directory

EHR-LR DirectoryEHR-LR Directory

EHR-LR Encounter/Documents Directory


Custodian for an unspecified time of Documents recorded from patient encounters.

Registerand Provide Doc

Register Doc

RetrieveDoc

QueryDoc List

EHR-CR

EH

R-

CR

Not all transactions necessary to ensure management of a distributed and dynamic EHR-LR are depicted in this illustration.

EHR-LR

V5

Key Statements : IHE Focuses on the EHR-LRIHE Focuses on the EHR-LR

1. The EHR-LR (Longitudinal Record) federates patient encounter information managed by “EHRs within an enterprise” (EHR-CRs). EHR CRs (Care-delivery Record) may range from a large EHR of an IDN enterprise all the way down to a single practice management system.

2. EHR-LR includes repositories of encounter data that contribute to the patient’s longitudinal healthcare record. EHR-LR data will be stored in multiple repositories (depts., sites, domains).

3. Encounter data includes some information/state/workflow info that may not end up in the EHR-LR.

V5

Key Statements: What is in the EHR-LR ? What is in the EHR-LR ? 1. The EHR-LR data is made of discrete, persistent, logical

documents (structured or not) which may be accessed by a unique identifier.

2. Relevant clinical domain standards would be used to format EHR-LR data. This body of clinical domain standards and the domain clinical practice will dictate evolution.

3. EHR-LR will likely be initially focused on certain specialties (cardiology, oncology, etc) or a key information for continuity of care (CCR summaries only) and expand progressively.

4. Conversion between EHR-CR data “formats” and EHR-LR document “formats” is the responsibility of the EHR-CR.

5. At the end of an encounter, new document(s) are added to the EHR-LR. These new EHR-LR docs could be stored (in any form) in the EHR-CR where they are created or pushed to a separate EHR-LR repository (in a standard format).

V5

Key Statements : IHE ConstraintsIHE Constraints

1. The domains of EHR content are primarily clinical. Other information and services are needed to provide an operational EHR-LR environment (e.g. demographics, security, consents – IHE has already addressed some).

2. The EHR-LR and EHR-CR repositories may be using different Patient Ids.

3. The care-delivery view and form of current encounter data (EHR-CR) is out of scope of EHR-LR IHE Integration Profiles.

V5

Key Statements : Accessing EHR-LRAccessing EHR-LR1. EHR-LR shall provide a list of available documents for a

patient. Logical directories are necessary to provide such document lists.

2. The full burden of locating and filtering documents should not be placed on the EHR-LR consumer applications. The EHR-LR needs to have some meta-information about the documents it tracks.

3. There is a need for the EHR-LR to provide a means to retrieve the clinical documents that have been registered with full content fidelity.

4. There is a also a need for the EHR-LR to provide clinical data to consumer applications based on processing, extracting, or combining the content of multiple existing documents.

5. Documents may reference other documents including images, waveforms, etc.

V5


EHR-LR= The Longitudinal Record of a person’s healthEHR-CR= Care-delivery Record

Integration Profiles : Current Profiles vs “EHR-LR Profiles

EHR-LR

EHR-CR

EHR-CR

EHR-CR

EHR-CR

Nursing Homes


IHEIntegration Profile

(e.g. IT Infrastructure


(e.g. Lab, Cardio, etc)














Patient Access IHEIntegration Profile

Domain SpecificDoc Content






(e.g. Cross-enterprise Security, LR Management, etc.

IHEIntegration ProfileX-Enterprise Security, MPI

LR Register, Retrieve.

V5

EHR-LR Integration Profiles : Infrastructure(s) + Content(s)

EHR-LR Security, MPILR Register, Retrieve. Integration Profile(s)

ZZZ Content Integration

Profile

YYY Content Integration

Profile

XXX Content Integration

Profile

In PatientIn PatientOutpatientOutpatientLinkLink

CardiologyCardiologySpecialist toSpecialist toAcuteAcute

OncologyOncologySpecialist toSpecialist toAcuteAcute

Etc….Etc….

. . . .

. . . .

EHR-LR Security, MPILR Register, Retrieve. Integration Profile(s)

EHR-LR Security, PIXLR Register, Retrieve. Integration Profile(s)

V5

Some examples applying this EHR ConceptSome examples applying this EHR Concept

• Following are three examples where the same “EHR-LR integration concept would be applicable:

• GP Office in multiple IDNs with an EHR-LR ASP: GP linkage to acute care

• Cardiologist Practices and Inpatient: a domain specific longitudinal record

• Region or Country-Wide: a broad cross-domain longitudinal record

• These examples largely rely on the same set of core-EHR-LR IHE Integration Profiles, but used with different configurations and policies. The EHR-LR documents content would greatly vary.

• These examples are not intended to be exhaustive, but attempt to demonstrate the balance that IHE is looking for a reasonably broad set of use cases that would share the same infrastructure (i.e. set of actors and transactions).

V5

EHR-LR Patient/Encounter Level Directory

EHR-LR Encounter/Documents Level Directory

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

One Directory by IDN.Holds a reference to all encountersknown by the IDN, including thosefrom the GP

This Encounter Directory manages allencounters form the GP. It is an EHR-LRASP. This ASP system is also theprimary EHR-CR or all documentscreated by the GP’s encounters.EHR-LR Documents Repository


GP Practice Clinical Record Entry Document Creator and Consumer

V5


Example : Cardiologist Practices and Inpatient

IDN and associated Cardiologists establisha Central Directory.Holds a reference to all encountersknown by the IDN and Cardiologist

This Encounter Directory manages allencounters form the Cardiologists.It is an EHR-LR with all documentscreated by Cardiology encounters.


Cardiologist Practice Clinical Record Document Creator and Consumer


CardiologyInpatient Clinical Record Document Creator and Consumer

CardiologyInpatient Clinical Record Document Creator and Consumer



V5

EHR-LR Patient Level Directory



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

One such Patient Directory by region.Shadows copies. Knows all lower leveldirectories where encounters are identified.

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

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

One or more document repository by document custodians used by the health delivery entity where the encounter happen or external.EHR-LR Documents Repository






V5

IHE Integration Profiles Focused on the EHRIHE Integration Profiles Focused on the EHR • In this proposal, IHE has proposed an approach the longitudinal

dimension of the EHR, with a distributed, cross-enterprise, document centric, top-down point of view.

• The strategy is to progressively bridge the gap from these EHR-LR Integration Profiles with the current care-settings centric approach as new integration profiles are developed.

Feedback on this approach and expanding collaborations are sought.

Is this a useful “brick” ?

• The proposed strategy is a scoping exercise to address one of the many integration problems in the realization of the EHR vision. IHE does not claim to master and address the definition and all aspects of a complete and interoperable EHR System.

• In collaboration with well established standards bodies and other EHR related initiatives world-wide (EHRCOM, CCR, HL7, etc.), IHE expects to contribute at a more cost-effective and rapid deployment.

V5

Draft IHE IT Infrastructure RoadmapDraft IHE IT Infrastructure Roadmap

In support of the IHE Integration ProfilesIn support of the IHE Integration Profilesfocused on the EHRfocused on the EHR

Draft for Comments – 11/03To be finalized January 2004.

V5

IHE IT Infrastructure Roadmap – HIMSS 2004 (1)IHE IT Infrastructure Roadmap – HIMSS 2004 (1)

EHR Security Common Data

Profiles RID PIX PSA

Profiles EUA CT

No content

Standards & Prerequisites CCOW v1.4 Patient Context HL7 v2.3.1 HL7 v2.4 HTTP WSDL 1.1 XHTML 1.0 XML 1.0

Standards & Prerequisites CCOW v 1.4 User Context Kerberos NTP SNTP

V5

IHE IT Infrastructure Roadmap - Next Stage (2)IHE IT Infrastructure Roadmap - Next Stage (2) EHR Security Common Data

Profiles EHR-LR- Provide Document- Register Document- Query Document(s)- Retrieve Document Patient Demographics Query - enterprise

Profiles Take-on Basic Security- Common Audit schema - Node authentication PKI User demographics directory- Healthcare staff- Patients?

Profiles LDAP base- Federated- Multiple information bases: equipment, organizations, users Reference code sets- Distribution- Update SNMP MIBS?- Event reports- Equipment calibration changes- Equipment and software change management & tracking- Event trending

Standards & Prerequisites Stage 0 IHE ITI profiles- PIX-enabled EMPI service CDA level 1- ASTM E31.28 CCR encoding

Standards & Prerequisites IHE Radiology Basic Security Stage 0 IHE ITI security profiles RFC 2798 ITU X.509(95) Stable Common Audit Message RFC

Standards & Prerequisites LDAP SNMP- MIB standards / registry Mature/stable standards for selected code sets

V5

IHE IT Infrastructure Roadmap – Stage 3 IHE IT Infrastructure Roadmap – Stage 3 EHR Security Common Data

Profiles EHR-LR- Solidify step 1- Add 2 composite information sets (candidates: allergies, discharge summaries, medication lists; consult with IHE clinicians on choices)- RAD plug-in Patient Demographics Query - multi-enterprise

Profiles Incorporate Kerberized standards into EUA- DICOM- HL7 v2 (v3?)- HL7 CCOW User PKI- Enterprise- Patients- Multi-enterprise?- Key distribution

Profiles Masterfile Maintenance Additional LDAP information sources RID configurability directory #1

Standards & Prerequisites Stage 1 IHE ITI profiles Additional CDA templates PKI for user identify management

Standards & Prerequisites Stage 1 IHE ITI security profiles Stable Kerberos support in:- HL7 v2.6- CCOW- DICOM PKCS#10 ISO/TS 17090

Standards & Prerequisites Stage 1 IHE ITI common data profiles HL7 v2 Masterfile maintenance Mature/stable standards for selected information sources Suitable LDAP schema definitions

V5

IHE IT Infrastructure Roadmap – Stage 4IHE IT Infrastructure Roadmap – Stage 4


Profiles EHR - Lab trending - Consents- Medication list

Profiles Add attribute certificates to PKI to support:- Basic RBAC- Consents? Multi-entity EUA Digital signatures

Profiles Additional LDAP information sources RID configurability directory #2 Workflow management preferences?

Standards & Prerequisites Stage 2 IHE ITI profiles IHE Lab profiles Basic RBAC

Standards & Prerequisites Stage 2 IHE ITI security profiles Mature attribute certificate distribution specification/standard ISO/TC 215 Privilege Management Infrastructure specification

Standards & Prerequisites Stage 2 IHE ITI common data profiles Mature/stable standards for selected information sources Suitable LDAP schema definitions

V5

IHE IT Infrastructure Roadmap – Stage 5IHE IT Infrastructure Roadmap – Stage 5


Profiles EHR-LR- More document types (general document templates)- More clinical domains (cardiology, nuclear medicine, pharmacy, ...)- Composite documents from multiple clinical domains.

Profiles Remote service access Anonymization Wide-area patient access Mobile applications- Wireless- Patient active homecare- Mobile providers Location-sensitive behaviors Patient identification standards

Profiles RID configurability directory #3- "Hanging protocols"

Standards & Prerequisites Stage 3 IHE ITI profiles IHE clinical domain uptake

Standards & Prerequisites Stage 3 IHE ITI security profiles Stable standards for mobile access security Stable standards for patient identification

Standards & Prerequisites Stage 3 IHE ITI common data profiles Suitable LDAP schema definitions

v5 organizing ihe integration profiles related to the electronic health record initial thoughts ihe...

Documents

ehr information

v5 order

encounters ehrcr r

specialized care

resources order

care delivery health

v5 ihe integration profiles

care actions