organizing ihe integration profiles related to the electronic
TRANSCRIPT
V6
Organizing IHE Integration Profilesrelated to the Electronic Health Record
Initial Thoughts
IHE ITI Tech Committee - December 2003
V6
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.
V6
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).
V6
Acute Care (Inpatient)
GPs and Clinics (Outpatient)
Nursing Homes
Other Specialized Careor Diagnostics Services
Integration : Feeding & Accessing the Longitudinal Health Record Information
EHR-LR
The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems
V6
Care Delivery Process
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-CR
Read
EHR-LR EHR-LR
Read
EHR-LR
CreateUpdate
V6
EHR-LR Documents Repository
Custodian for an unspecified time of Documents recorded from patient encounters.
EHR-LR Virtual Documents Repository
Custodian for an unspecified time of Documents recorded from local patient encounters.
EHR-LR Directory
EHR-LR Actors: Directory & Repository Actors
EHR-LR Documents Repository
Custodian for an unspecified time of Documents recorded from patient encounters.EH
R-C
R
EH
R-C
R
V6
Key Statements : EHR-LR FundamentalsEHR-LR Fundamentals • The EHR-LR (Longitudinal Record) brings together patient
encounter information managed by multiple care delivery systems, ranging from EHR-CR (Care-delivery Record) in a large hospital network all the way down to a single practice management system.
• EHR-LR will be cross-enterprise and may include one or more clinical domain and will be typically collected over a large period of time.
• 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).
• Encounter data includes some information/state/workflow info that may not end up in the EHR-LR.
V6
Key Statements: What is in the EHR-LR ? What is in the EHR-LR ? • The EHR-LR data is made of discrete, persistent, clinical
documents accessed by a unique identifier. It may also contain other dynamic objects (e.g. prescription status, allergy lists, etc.) which are not addressed at this time.
• EHR-LR data will follow relevant clinical domain standards defined by field experts. Their content and codification will evolve according to the clinical needs.
• At the end of an encounter, new document(s) are published to the EHR-LR. These new EHR-LR documents will either be kept in the EHR-CR where they are created or pushed to a separate EHR-LR repository.
• Conversion between EHR-CR internal data formats and the standard EHR-LR document is the responsibility of the EHR-CR.
V6
Key Statements : IHE ConstraintsIHE Constraints
• The domains of EHR-LR are primarily clinical. Other information and services are needed to provide a complete view of the patient longitudinal record (e.g. demographics, security, consents – IHE has already addressed some).
• The EHR-LR and EHR-CR repositories may be using different Patient Ids. The longitudinal view is provided by cross-patient identification services.
• The way data is stored and managed by the EHR-CR is out of scope of the EHR-LR IHE Integration Profiles.
V6
Key Statements : Accessing EHR-LRAccessing EHR-LR• EHR-LR shall provide a list of available documents for a
patient. Logical directories will be used to provide such lists.
• The location and filtering of documents is the responsibility of the EHR-LR and not of the consumer applications. The EHR-LR will use meta-information about the documents it tracks to provide this service.
• The EHR-LR must provide with full content fidelity all clinical documents that have been registered.
• Documents may include references to other documents such as images, waveforms, etc.
• In addition, the EHR-LR may optionally provide clinical data to consumer applications based on processing, extracting, or combining the content of multiple existing documents.
V6
Key Statements : Deploying IHE EHR-LR ProfilesDeploying IHE EHR-LR Profiles• EHR-LR will likely be initially focused on certain specialties
(cardiology, oncology, etc), disease, or on key information for continuity of care (CCR summaries only) and expand progressively.
Now includes disease.
V6
Acute Care (Inpatient)
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
Other Specialized Careor Diagnostics Services
IHEIntegration Profile
(e.g. IT Infrastructure
IHEIntegration Profile
(e.g. Lab, Cardio, etc)
IHEIntegration Profile
(e.g. Lab, Cardio, etc)
IHEIntegration Profile
(e.g. Lab, Cardio, etc)
IHEIntegration Profile
(e.g. Lab, Cardio, etc)
IHEIntegration Profile
(e.g. IT Infrastructure
IHEIntegration Profile
(e.g. IT Infrastructure
IHEIntegration Profile
(e.g. Lab, Cardio, etc)
GPs and Clinics (Outpatient)
Patient Access
IHEIntegration Profile
Domain SpecificDoc Content
IHEIntegration Profile
Domain SpecificDoc Content
IHEIntegration Profile
Domain SpecificDoc Content
IHEIntegration ProfileX-Enterprise Security, MPI
LR Register, Retrieve.
V6
EHR-LR Integration Profiles : Infrastructure(s) + Content(s)
EHR-LR Security, MPILR Register, Retrieve. Integration Profile(s)
Cath Report Integration
Profile
Tumor Report Integration
Profile
Radiology Report 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)
V6
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).
V6
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
EHR-LR Patient/Encounter Level Directory
GP Practice Clinical Record Entry Document Creator and Consumer
V6
EHR-LR Encounter/Documents Level Directory
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.
EHR-LR Documents Repository
Cardiologist Practice Clinical Record Document Creator and Consumer
EHR-LR Patient/Encounter Level Directory
CardiologyInpatient Clinical Record Document Creator and Consumer
CardiologyInpatient Clinical Record Document Creator and Consumer
Cardiologist Practice Clinical Record Document Creator and Consumer
Cardiologist Practice Clinical Record Document Creator and Consumer
V6
EHR-LR Patient Level Directory
EHR-LR Documents Repository
EHR-LR Encounter/Documents 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
EHR-LR Documents Repository
EHR-LR Encounter/Documents Level Directory
EHR-LR Encounter/Documents Level Directory
EHR-LR Patient/Encounter Level Directory
EHR-LR Patient/Encounter Level Directory
V6
EHR-LR Documents Repository
Custodian for an unspecified time of Documents recorded from patient encounters.
EHR-LR Patient Directory
EHR-LR Patient Directory
EHR-LR Documents Virtual Repository
Custodian for an unspecified time of Documents recorded from local patient encounters.
EHR-LR Encounter Directory
EHR-LR Use Cases: Actors & Transactions Concepts D
ocu
men
t C
reat
or
Do
cum
ent
Cre
ato
r Do
cu
me
nt
Co
nsu
mer
Do
cu
me
nt
Co
nsu
mer
EHR-LR Patient Directory
EHR-LR Patient Directory
EHR-LR Encounter Directory
EHR-LR Documents Repository
Custodian for an unspecified time of Documents recorded from patient encounters.
Registerand Provide Doc
Register Doc
RetrieveDoc
QueryDoc List
EHR-CR
EH
R-C
R
Not all transactions necessary to ensure management of a distributed and dynamic EHR-LR are depicted in this illustration.
EHR-LR
V6
IHE Integration Profiles Focused on the EHRIHE Integration Profiles Focused on the EHR • IHE proposes an approach to obtaining a longitudinal view of the EHR,
with a distributed, cross-enterprise, document centric solution.
• The strategy is to progressively bridge the gap between the EHR-LR Integration Profiles and the domain integration profiles 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.
V6
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.
V6
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
V6
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
V6
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
V6
IHE IT Infrastructure Roadmap – Stage 4IHE IT Infrastructure Roadmap – Stage 4
EHR Security Common Data
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
V6
IHE IT Infrastructure Roadmap – Stage 5IHE IT Infrastructure Roadmap – Stage 5
EHR Security Common Data
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