1. Integrating the Healthcare Enterprise
Contribution to an EHR Strategy
José Mussi –
Director of Architecture, Canada Health Infoway

2. Goals of IHE
Increase the rate and quality of integration in healthcare environments.
Foster communication among vendors.
Prove that integration is attainable through the use of standards.
Improve the efficiency and effectiveness of clinical practice.

3. EHR Challenges Introduction:
One of the key integration challenges in healthcare today is achieving longitudinal electronic health records (EHR-LR)
Developing EHR solutions requires many integration profiles, some of which IHE has already addressed:
The Patient Cross-Referencing (PIX) profile provides methods for linking patient ID across multiple enterprises
The Retrieve Information Display (RID) profile defines a simple method for accessing clinical data
The Audit Trail (ATNA) profile addresses the need to have centralized logs of activities for privacy related requirements
IHE is now addressing one of the core profiles for the EHR:
The sharing and exchange of clinical documents across multiple healthcare settings
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 to small physician practice management systems.
EHR-LR will be cross-enterprise, possibly across large geographical regions, and may include one or more clinical domains.
EHR-LR will be typically collected and retained over a large period of time, providing a deep historic record for the patient.
EHR-LR is supported by repositories of encounter data that contribute to the patient’s longitudinal healthcare record.
EHR-LR data will be found in multiple repositories that will interoperate and provide a seamless historical view of the patient.
Encounter data will very likely include some clinical documents, state and workflow information that will not be stored in the EHR-LR.

4. EHR Cross-Enterprise Document Sharing
Introduction:
EHR Cross-Enterprise Document Sharing
First step towards the longitudinal dimension of the EHR:
Focus: Clinical Information Exchange between EHRs in care settings to communicate with a distributed longitudinal EHR.
Goal: Meet a broad range of EHR-LR (Longitudinal Record) needs with a distributed, cross-enterprise, document centric document content generic

5. Patient Longitudinal Record
Continuity of Care:
Patient Longitudinal Record
Nursing Homes
Acute Care (Inpatient)
Other Specialized Care (incl. Diagnostics Services)
GPs and Clinics (Outpatient)
Typically, a patient goes through a sequence of encounters in different Care Setting

6. Publishing & Accessing the EHR-LR
EHR-LR Integration Profiles:
Publishing & Accessing the EHR-LR
EHR-LR
Nursing Homes
Acute Care (Inpatient)
Other Specialized Care or Diagnostics Services
GPs and Clinics (Outpatient)
The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems

7. EHR-LR (Longitudinal Record) + EHR-CR (Care Delivery Record)
Two types of Integration : EHR-CR: Health Record as used during care delivery EHR-LR: Health Record as used across-encounters
EHR-LR
Read
Read
EHR-LR
EHR-LR
Create
Update
EHR-CR
Selection of
informations
Decide to
Assess demand
For care
Actions to
order
Define an
action plan
Identification
End of Encounter
Define
healthcare
Objective
Care Delivery Process
EHR-Solution =
EHR-LR (Longitudinal Record) + EHR-CR (Care Delivery Record)

8. EHR-LR Fundamentals Key Statements:
Brings together patient encounter information managed by all types of care delivery systems.
Cross-enterprise, possibly across large geographical regions, and may include many clinical domains.
Typically collected and retained over a large period of time, providing a deep historic record for the patient.
Supported by multiple repositories that contribute to the patient’s longitudinal healthcare record.
Encounter data will very likely include some clinical documents, state and workflow information that will not be stored in the EHR-LR.
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 to small physician practice management systems.
EHR-LR will be cross-enterprise, possibly across large geographical regions, and may include one or more clinical domains.
EHR-LR will be typically collected and retained over a large period of time, providing a deep historic record for the patient.
EHR-LR is supported by repositories of encounter data that contribute to the patient’s longitudinal healthcare record.
EHR-LR data will be found in multiple repositories that will interoperate and provide a seamless historical view of the patient.
Encounter data will very likely include some clinical documents, state and workflow information that will not be stored in the EHR-LR.

9. Key Statements: What is in the EHR-LR?
The EHR-LR data is made of discrete, persistent, clinical documents accessed by an unique identifier.
It may also contain other dynamic objects which are not being addressed by IHE at this time.
Metadata will be provided with each document by the EHR-CR and will be stored in the EHR-LR.
EHR-LR data formats will follow relevant clinical domain standards defined by field experts. EHR-CR is responsible for converting its internal data formats to the standard EHR-LR documents.
EHR-LR documents will kept in the EHR-CR or pushed to a separate EHR-LR repository.
The EHR-LR data is made of discrete, persistent, clinical documents accessed by an unique object identifier.
It may also contain other dynamic objects (e.g. drug profiles, allergy lists, etc.) which are not being addressed by IHE at this time.
EHR-LR data formats 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 a patient encounter, relevant clinical document(s) are published to the EHR-LR. Metadata will be provided with each document and will be stored in the EHR-LR.
The EHR-LR documents will either be kept in the same 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.

10. Key Statements: Accessing the EHR-LR
EHR-LR shall make available a list of all published documents for a given patient/selection parameters.
The selection of documents is the responsibility of the EHR-LR and not of the consumer applications. This is possible because of the document metadata kept in the EHR-LR.
The EHR-LR must ensure full content fidelity for all clinical documents that have been published.
The actual location of any particular document shall be transparent to the consumer application.
EHR-CR may provide clinical data by processing, extracting, or combining multiple documents.
Upon request from consumer applications, the EHR-LR shall make available a list of all published documents for a given patient and other selection parameters. Logical directories will be used to provide such lists.
The selection of documents based on request parameters is the responsibility of the EHR-LR and not of the consumer applications.
The EHR-LR can provide this filtering service because of the metadata included with each published document.
The EHR-LR must provide with full content fidelity all clinical documents that have been published.
The actual location of any particular document shall be transparent to the consumer application. The EHR-LR will maintain appropriate pointers and access the information directly as required.
EHR-LR 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.

11. Deploying IHE EHR-LR Profiles
Key Statements:
Deploying IHE EHR-LR Profiles
The deployment of EHR-LR integration profiles will initially be focused on a small number of specialties (cardiology, oncology, etc), disease, and/or on key information for continuity of care (e.g. CCR summaries).
The scope of the EHR-LR profiles will expand progressively as other specialties are included in the use cases.

12. EHR-LR Integration Profile: Key Actors (Application Roles)
EHR-CR Source
Healthcare point of service system where clinical information is first collected
EHR-LR Directory
Index and metadata database for all published clinical documents
EHR-LR Documents Repository
Maintains and stores published EHR-LR documents
EHR-LR Consumer
Application system that needs access to EHR-LR documents and information
EHR-CR Recipient
Healthcare point of service system that receives clinical documents as part of a continuity of care transfer

13. EHR-LR with Source Repository
Integration Model 1:
EHR-LR with Source Repository
An EHR-CR completes a phase of care for a patient where it:
Registers documents with an EHR-LR Directory actor.
Keeps these documents in an EHR-LR Repository actor.
Any other EHR-CR may query an EHR-LR Directory actor, find out about documents related to all phases of care for the patient and chose to retrieve some of these documents from any EHR- LR Repository Actor (Used in use Case 1 & 2).
Register
EHR-LR Directory
EHR-CR
Source
Query
EHR-LR
Consumer
EHR-LR
Repository
Retrieve

14. EHR-LR with Third Party Repository
Integration Model 2:
EHR-LR with Third Party Repository
An EHR-CR completes a phase of care for a patient where it:
Registers documents with an EHR-LR Directory Actor.
Provides these documents to an EHR-LR Repository Actor.
Any other EHR-CR may query an EHR-LR Directory Actor, find out about documents related to all phases of care for the patient and chose to retrieve some of these documents from any EHR- LR Repository Actor (Used in use Case 1 & 2).
Register
EHR-LR Directory
Query
EHR-CR
Source
EHR-LR
Consumer
Provide-Transfer
EHR-LR
Repository
Retrieve

15. Direct Patient Transfer-Referral
Integration Model 3:
Direct Patient Transfer-Referral
An EHR-CR completes a phase of care for a patient where it:
Registers and Provides an EHR-CR Recipient Actor that a specific set of documents (newly created and priors of interest documents) are available from an EHR-LR Repository
The EHR-CR Recipient Actor receive both the registration and the documents.
EHR-CR
Recipient
EHR-CR
Source
Register
EHR-LR Directory
Provide-Transfer
EHR-LR
Repository

16. EHR Cross-Enterprise Document Sharing
Conclusion:
EHR Cross-Enterprise Document Sharing
Leverages HL7 CDA (Clinical Document Architecture) and ASTM CCR (Continuity of Care Record).
The proposed strategy addresses one of the key 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.

17. An open process for everyone!
IHE IT Infrastructure
An open process for everyone!
To join IT Infrastructure planning or technical committee:
Contact Joyce Sensmeier, HIMSS.
Suggest new profiles in IHE IT Infrastructure Planning Plan IHE at HIMSS 2005
Produce new profiles in IHE IT Infrastructure Technical Committee

18. For more information…. Web sites: www . himss . org / ihe
www . rsna . org / ihe
Technical Documentation (
IHE IT Technical Framework 2004 – V 1.0
IHE Rad Technical Framework 2003 – V 5.5
IHE Laboratory Technical Framework 2004 – V 1.0
Non-Technical Brochures (
IHE Fact Sheet and IHE FAQ
IHE Integration Profiles: Guidelines for Buyers
IHE Connectathon Results

19. Integrating the Healthcare Enterprise
Thank You