Organizing IHE Integration Profiles related to the Electronic Health Record

1. Organizing IHE Integration Profiles related to the Electronic Health Record Input to the IHE ITI Tech Committee November 2002 Charles Parisot, GE Medical Systems-IT Karima Bourquard, GMSIH

2. Control (Rules, procedures, reporting) Control (Rules, procedures, reporting) Registries Knowledge Directories Knowledge Order and others inputs Result and Others outputs Order and others inputs Result and Others outputs Process Process (event) (event) Resources Resources EHR EHR Wards Anesthesia Pneumology General Practionner A large Number of Care Settings with many different care delivery processes Accute Care (Inpatient) Nursing Homes Other Specialized Careor Diagnostics Services Each Care Setting (incl. Diagnostics Services) will require specific IHE Integration Profiles GPs and Clinics (Outpatient)

3. Control (Rules, procedures, reporting) Control (Rules, procedures, reporting) Registries Knowledge Directories Knowledge Order and others inputs Result and Others outputs Order and others inputs Result and Others outputs Process Process (event) (event) Resources Resources EHR EHR Wards Anesthesia Pneumology General Practionner Continuity of Care: Patient Longitudinal Record Across Encounters Acute Care (Inpatient) Nursing Homes Other Specialized Careor Diagnostics Services A typical patient goes through a sequence of encounters in different Care Setting (incl. Diagnostics Services). GPs and Clinics (Outpatient)

4. Control (Rules, procedures, reporting) Control (Rules, procedures, reporting) Registries Knowledge Directories Knowledge Order and others inputs Result and Others outputs Order and others inputs Result and Others outputs Process Process (event) (event) Resources Resources EHR EHR Wards Anesthesia Pneumology General Practionner Integration : Feeding & Accessing the Longitudinal Health Record Information Acute Care (Inpatient) Nursing Homes Other Specialized Careor Diagnostics Services EHR-S ≈ Entire System EHR-LR= The Longitudinal Record of a person’s health GPs and Clinics (Outpatient)

5. Services Act lifecycle Act lifecycle Results Orders Identification Decide to Assess demand For care End ofEncounter Define an action plan Selection of informations Actions to order C=create U=update C,U R = read C,U C,U R C,U C,U EHR-CR EHR-CR EHR-CR EHR-CR EHR-CR Knowledge Directories EHR-LR Knowledge Directories EHR-LR EHR-LR EHR-LR Define healthcare Objective Two types of Integration : Health Record as used during care delivery Health Record as used across-encounters Care Delivery Process EHR-CR : EHR information supporting immediate care delivery EHR-LR : EHR information supporting long term care delivery

6. Control (Rules, procedures, reporting) Directories Knowledge Order and others inputs Result and Others outputs Process (event) Resources EHR-LR or EHR-CR Ward Care Delivery Integration Profiles :Process and workflow focus within a specific care delivery setting Inside hospital… Radiology Cardiology Outside the hospital… Control (Rules, procedures, reporting) Directories Knowledge Order and others inputs Each should includetransactions with its EHR-CR Result and Others outputs Process (event) Resources GP EHR-LR or CR

7. Longitudinal EHR Integration Profiles :Integration of EHR-LR (longitudinal) with the EHR-CR (care delivery) EHR-CR EHR-LR t t EHR-CR t t r :read c,u : create, update t : transfer EHR-CR r,c,u r r r,c,u Process 3 r Patient r,c,u EHR: one or several DB + applications Process 2 Process1 Within Healthcare Enterprises and Across Enterprises

8. Proposed IHE Principles for EHR Integration: • 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. • 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 performedwithin 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 ….

9. A simplistic model for organizing the EHR-LR Patient 1 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.). n Encounter 1 n Information

10. EHR-LR Integration: Directory Concept, 6 Core Actors EHR-LR Patient Level Directory For each patient it references the EHR-LR instances where this patient has had one or more encounters. • Patient A has encounters known on: • P/E Directory = 1 • P/E Directory = 78 1-n n-m 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. • Patient A has encounters: • Encounter E4 on E/D = 34 • Encounter E8 on E/D = 67 • Encounter E56 on E/D = 641 EHR-LR Document Consumer 1-n n-m 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. • 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 EHR-LR Document Feeder n-m EHR-LR Documents Repository It is the custodian for an unspecified time of Documents recorded as a result of encounters made by patients.

11. Example : Country-Wide (e.g. NHII) One such P Directory by region. All shadows copies. EHR-LR Patient Level Directory One such P/E Directory by region. Holds a reference to all encountersmade in the region. EHR-LR Patient/Encounter Level Directory One such P/E Directory by EncounterCustodian used by the health delivery entity where the encounter happen EHR-LR Encounter/Documents Level Directory One or more document repositoryby document custodians used by the health delivery entity where theencounter happen. EHR-LR Documents Repository

12. 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. EHR-LR Patient Level Directory EHR-LR Patient/Encounter Level Directory 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. EHR-LR Encounter/Documents Level Directory EHR-LR Documents Repository A number of independent documentrepositories are also used in the hospitalfor certain types of documents (e.g. images, waveforms, etc.). EHR-LR Documents Repository

13. 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 EHR-LR Patient Level Directory EHR-LR Patient/Encounter Level Directory 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 Encounter/Documents Level Directory EHR-LR Documents Repository

14. EHR-LR : A persistent document management system • 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.) • 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. • 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-LRIntegration Profile. They will be addressed by other integration profiles.

15. Open Issues: • This approach relies on two key concepts: Patient and Encounter • The EHR-LR is organized as a document repository where documents are assignedto 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 ? • 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 ?