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. Wards Anesthesia Pneumology Order and others inputs Registries Knowledge Result and Others outputs (event) Process EHR Control (Rules, procedures, reporting) Resources Order and others inputs Directories Knowledge Result and Others outputs (event) Process EHR Control (Rules, procedures, reporting) Resources General Practionner Accute Care (Inpatient) GPs and Clinics (Outpatient) Nursing Homes Other Specialized Care or 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

3. Wards Anesthesia Pneumology Order and others inputs Registries Knowledge Result and Others outputs (event) Process EHR Control (Rules, procedures, reporting) Resources Order and others inputs Directories Knowledge Result and Others outputs (event) Process EHR Control (Rules, procedures, reporting) Resources General Practionner Acute Care (Inpatient) GPs and Clinics (Outpatient) Nursing Homes Other Specialized Care or 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).

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

5. Care Delivery Process Act lifecycle Services Orders Results Act lifecycle Selection of informations Decide to Assess demand For care Actions to order Define an action plan Identification End of Encounter Define healthcare Objective EHR-CR EHR-CR : EHR information supporting immediate care delivery EHR-LR EHR-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=create U=update EHR-CR C,U EHR-CR R = read Knowledge Directories EHR-LR EHR-CR EHR-LR C,U Knowledge Directories EHR-LR R C,U

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

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

8. Proposed IHE Principles for EHR Integration: 1.EHR Care Delivery Integration Integration Profiles manage integration within an 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 content and 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 integration of 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 ….

9. 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.).

10. 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 EHR-LR Document Feeder EHR-LR Document Consumer n-m 1-n

11. EHR-LR Patient Level Directory EHR-LR Patient/Encounter Level Directory EHR-LR Documents Repository EHR-LR Encounter/Documents Level Directory 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 encounters made in the region. One such P/E Directory by Encounter Custodian used by the health delivery entity where the encounter happen One or more document repository by document custodians used by the health delivery entity where the encounter happen.

12. EHR-LR Patient Level Directory EHR-LR Patient/Encounter Level Directory EHR-LR Documents Repository EHR-LR Encounter/Documents Level Directory Example : IDN (e.g. Group of Hospitals) One such combined P Directory and P/E Directory by hospital. All shadows copies Holds a reference to all encounters made across the entire IDN. One such P/E Directory by Hospital where the encounter happen/ This system is also the primary EHR-CR for the hospital. It also acts as the Document repository for a number of documents. A number of independent document repositories are also used in the hospital for certain types of documents (e.g. images, waveforms, etc.). EHR-LR Documents Repository

13. EHR-LR Patient Level Directory EHR-LR Patient/Encounter Level Directory EHR-LR Encounter/Documents Level Directory Example : GP Office in multiple IDNs with an EHR-LR ASP One such combined P Directory and P/E Directory by IDN. Holds a reference to all encounters made by the GP One such P/E Directory by the GP’s selected EHR-LR ASP. This ASP system is also the primary EHR-CR for all documents created by the GP’s encounters. EHR-LR Documents Repository

14. EHR-LR : A persistent document management system 1.Does the longitudinal record (EHR-LR) receives clinical data input other 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 be supported by a CDA, but no use cases has been identified for input into an EHR-LR other than through persistent documents. This is especially important for attestability. A CDA Based clinical information input for EHR-LR includes much more than the HL7-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 are handled 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.

15. 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 id domains. Each one of the EHR-LR Actor resides within predefined domains cross-referenced by the PIX Integration Profile. The EHR-LR is organized as a document repository where documents are assigned to an encounter. In addition, all documents from an encounter can be registered with a single Encounter/document Directory. The concept of Encounter shall be clearly defined (suggest using HL7 V3 Patient Admin concept). HL7V3 allows Encounter to be a recursive concept. Should this be supported, or should one limit the EHR-R to the top-level encounter ? 2.Need to ensure that a simple query will allow to identify documents of interest in an 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 of appropriate documents. The CDA header offers a solid set of such meta attributes. Is this sufficient ?