1. V5 Organizing IHE Integration Profiles related to the Electronic Health Record Initial Thoughts IHE ITI Tech Committee - November 2002

2. V5 IHE 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.

3. V5 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. V5 Order and others inputs Directories Knowledge Result and Others outputs (event) Process EHR Control (Rules, procedures, reporting) Resources General Practionner Order and others inputs Directories Knowledge Result and Others outputs (event) Process EHR Control (Rules, procedures, reporting) Resources General Practionner Wards Anesthesia Pneumology Order and others inputs Registries Knowledge Result and Others outputs (event) Process EHR Control (Rules, procedures, reporting) Resources 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. V5 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 EHR-CR R = read Knowledge Directories EHR-LR Knowledge Directories EHR-LR R=Read EHR-LR Create Update

6. V5 Order and others inputs Directories Knowledge Result and Others outputs (event) Process EHR Control (Rules, procedures, reporting) Resources General Practionner 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 EHR-CR= Care-delivery Record Integration : Feeding & Accessing the Longitudinal Health Record Information EHR-LR EHR-CR

7. V5 EHR-LR Documents Repository Custodian for an unspecified time of Documents recorded from patient encounters. 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 Document Creator Document Consumer EHR-LR Directory EHR-LR Encounter/Documents Directory EHR-LR Documents Repository Custodian for an unspecified time of Documents recorded from patient encounters. Register and Provide Doc Register Doc Retrieve Doc Query Doc List EHR-CR Not all transactions necessary to ensure management of a distributed and dynamic EHR-LR are depicted in this illustration. EHR-LR

8. V5 IHE Focuses on the EHR-LR Key Statements : IHE 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.

9. V5 What is in the EHR-LR ? Key Statements: 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).

10. V5 IHE Constraints Key Statements : IHE 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.

11. V5 Accessing EHR-LR Key Statements : Accessing EHR-LR 1.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.

12. V5 Acute Care (Inpatient) EHR-LR= The Longitudinal Record of a person’s health EHR-CR= Care-delivery Record Integration Profiles : Current Profiles vs “EHR-LR Profiles EHR-LR EHR-CR Nursing Homes Other Specialized Care or Diagnostics Services IHE Integration Profile (e.g. IT Infrastructure IHE Integration Profile (e.g. Lab, Cardio, etc) IHE Integration Profile (e.g. Lab, Cardio, etc) IHE Integration Profile (e.g. Lab, Cardio, etc) IHE Integration Profile (e.g. Lab, Cardio, etc) IHE Integration Profile (e.g. IT Infrastructure IHE Integration Profile (e.g. IT Infrastructure IHE Integration Profile (e.g. Lab, Cardio, etc) GPs and Clinics (Outpatient) Patient Access IHE Integration Profile Domain Specific Doc Content IHE Integration Profile Domain Specific Doc Content IHE Integration Profile Domain Specific Doc Content IHE Integration Profile (e.g. Cross-enterprise Security, LR Management, etc. IHE Integration Profile X-Enterprise Security, MPI LR Register, Retrieve.

13. V5 EHR-LR Integration Profiles : Infrastructure(s) + Content(s) EHR-LR Security, MPI LR Register, Retrieve. Integration Profile(s) ZZZ Content Integration Profile YYY Content Integration Profile XXX Content Integration Profile In Patient Outpatient Link Cardiology Specialist to Acute Oncology Specialist to Acute Etc…... EHR-LR Security, MPI LR Register, Retrieve. Integration Profile(s) EHR-LR Security, PIX LR Register, Retrieve. Integration Profile(s)

14. V5 Some 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).

15. V5 EHR-LR Patient/Encounter Level Directory EHR-LR Encounter/Documents Level Directory Example : GP Office in multiple IDNs with an EHR-LR ASP One Directory by IDN. Holds a reference to all encounters known by the IDN, including those from the GP This Encounter Directory manages all encounters form the GP. It is an EHR-LR ASP. This ASP system is also the primary EHR-CR or all documents created by the GP’s encounters. EHR-LR Documents Repository EHR-LR Patient/Encounter Level Directory GP Practice Clinical Record Entry Document Creator and Consumer

16. V5 EHR-LR Encounter/Documents Level Directory Example : Cardiologist Practices and Inpatient IDN and associated Cardiologists establish a Central Directory. Holds a reference to all encounters known by the IDN and Cardiologist This Encounter Directory manages all encounters form the Cardiologists. It is an EHR-LR with all documents created by Cardiology encounters. EHR-LR Documents Repository Cardiologist Practice Clinical Record Document Creator and Consumer EHR-LR Patient/Encounter Level Directory Cardiology Inpatient Clinical Record Document Creator and Consumer Cardiologist Practice Clinical Record Document Creator and Consumer

17. V5 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 level directories where encounters are identified. One such P/E Directory by region. Holds a reference to all encounters made in the region. One such E/D 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 or external. EHR-LR Documents Repository EHR-LR Encounter/Documents Level Directory EHR-LR Patient/Encounter Level Directory

18. V5 IHE 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.

19. V5 Draft IHE IT Infrastructure Roadmap In support of the IHE Integration Profiles focused on the EHR Draft for Comments – 11/03 To be finalized January 2004.

20. V5 IHE IT Infrastructure Roadmap – HIMSS 2004 (1) EHRSecurityCommon 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

21. V5 IHE IT Infrastructure Roadmap - Next Stage (2) EHRSecurityCommon 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

22. V5 IHE IT Infrastructure Roadmap – Stage 3 EHRSecurityCommon 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

23. V5 IHE IT Infrastructure Roadmap – Stage 4 EHRSecurityCommon 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

24. V5 IHE IT Infrastructure Roadmap – Stage 5 EHRSecurityCommon 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