1. IHE Update to DICOM Committee
Charles Parisot, GE Healthcare IT
IHE IT Infrastructure Technical Committee co-chair

2. IHE IT Infrastructure – March 2004
More Info on IHE
To learn more about IHE
Integrating the Healthcare Enterprise:
Read the IHE Fact Sheet
IHE IT Infrastructure – March 2004

3. IHE IT Infrastructure 5 Current Integration Profiles
Retrieve Information for Display
Access a patient’s clinical information and documents in a format ready to be presented to the requesting user
Enterprise User Authentication
Provide users a single name and centralized authentication process across all systems
Synchronize multiple applications on a desktop to the same patient
Patient Synchronized Applications
Patient Identifier Cross-referencing for MPI
Map patient identifiers across independent identification domains
Consistent Time
Coordinate time across networked systems
IHE IT Infrastructure – March 2004

4. IHE IT Infrastructure Progress
IHE IT Connect-a-thons held in the USA (January 2004) and Europe (March 2004).
Successful HL7-IHE joint demonstration at HIMSS (Orlando). 2 IHE Radiology and 5 IT Infrastructure Integration were demonstrated by 12 vendors with 30 actors.
**Consider making the cycle graphic
Incremental approach: Can’t solve all at once
Connectathon – Practical measure of progress, Validates the integration work accomplished. Refer the Scorecard.
Demo – promotes standards based integration to users/purchasers
IHE IT Infrastructure – March 2004

5. Overview of Supplements to be specified in 2004

6. IHE IT Infrastructure – March 2004
IHE drives healthcare standards based-integration
IHE IT Infrastructure – March 2004

7. IHE 2003 achievements and expanding scope
Over 80 vendors involved world-wide, 4 Technical Frameworks
24 Integration Profiles, Testing at yearly Connectathons,
Demonstrations at major exhibitions world-wide
Provider-Vendor cooperation to accelerate standards adoption
IHE IT Infrastructure – March 2004

8. IHE IT Infrastructure – March 2004
IHE Process
Users and vendors work together to identify and design solutions for integration problems
Intensive process with annual cycles:
Identify key healthcare workflows and integration problems
Research & select standards to specify a solution
Write, review and publish IHE Technical Framework
Perform cross-testing at “Connectathon”
Demonstrations at tradeshows (HIMSS/RSNA…)
**Consider making the cycle graphic
Incremental approach: Can’t solve all at once
Connectathon – Practical measure of progress, Validates the integration work accomplished. Refer the Scorecard.
Demo – promotes standards based integration to users/purchasers
IHE IT Infrastructure – March 2004

9. A Proven Standards Adoption Process
Product IHE Integration Statement
IHE Connectathon Results
IHE Connectathon
Product
With IHE
IHE Demonstration
Easy to
Integrate
Products
IHE Technical Framework
Standards
IHE Integration
Profiles B
Profile A
User Site
RFP
IHE Integration Profiles at the heart of IHE :
Detailed selection of standards and options each solving a specific integration problem
A growing set of effective provider/vendor agreed solutions
Vendors can implement with ROI
Providers can deploy with stability
IHE IT Infrastructure – March 2004

10. IHE IT Infrastructure – March 2004
IHE IT Infrastructure – Plan for
IT Infrastructure Development Plan:
IHE ITI Planning Committee decision: mid-February
Issue Public Comment version: June 2004
Public Comment Due: July 2004
Issue Trial Implementation version: August 2004
IHE Connectathon: January 2005
HIMSS Demo: February 2005
Profiles under development are:
Audit Trail and Node Authentication
Personnel White Page Directory
Patient Demographics Query
EHR-Cross-Enterprise Clinical Document Sharing
IHE IT Infrastructure – March 2004

11. IHE IT Infrastructure – March 2004
IHE IT Ca rdiology – Plan for
IT Cardiology Development Plan:
IHE Card Planning Committee decision: mid-February
Issue Public Comment version: July 2004
Public Comment Due: August 2004
Issue Trial Implementation version: September 2004
IHE Connectathon (USA): January 2005
IHE Connectathon (EU): March 2005
ACC Demo: March 2005
ESC Demo: August 2005
Profiles under development :
CathLab Workflow
EchoLab Workflow
Enterprise ECG Reports Access
Retrieve Info for Display (in Cardio - extension)
Audit Trail and Node Authentication
Patient Id Cross-Referencing
IHE IT Infrastructure – March 2004

12. 2004 IHE Integration Profiles
Patient Infor-mation Reconci-liation ,
Access to Radiology Information
Consistent Presentation of Images
Basic Security -
Evidence Documents
Key Image Notes
Simple Image and Numeric Reports
Presentation of Grouped Procedures
Post-Processing Workflow
Reporting Workflow
Charge Posting
Scheduled Workflow
Enterprise User Authentication
Provide users a single name and centralized authentication process across all systems
Retrieve Information for Display
Access a patient’s clinical information and documents in a format ready to be presented to the requesting user
Patient Identifier Cross-referencing for MPI
Map patient identifiers across independent identification domains
Synchronize multiple applications on a desktop to the same patient
Patient Synchronized Applications
Consistent Time
Coordinate time across networked systems
IT Infrastructure
Radiology,
Laboratory
Retrieve Information for Display
Access a patient’s clinical information and documents in a format ready to be presented to the requesting user
Laboratory Scheduled Workflow
Admit, Discharge, Transfer a patient, order lab tests, collect specimen, perform tests, report results.

13. IHE IT Infrastructure – March 2004
IHE Radiology – Plan for
Radiology Development Plan:
IHE Rad Planning Committee decision: mid-October
Issue Public Comment version: February 2004
Public Comment Due: March 2, 2004
Issue Trial Implementation version: April 2004
IHE Connectathon (USA): January 2005
IHE Connectathon (EU): March 2005
Supplements under development:
Imaging Patient Record on Media
Appointment Notification (SWF Option)
Report Report (HL7 V2-OBX) (SINR Option)
Instance Availability Notification
White Paper on Departmental Workflow
IHE IT Infrastructure – March 2004

14. IHE IT Infrastructure – March 2004
IHE Laboratory – Plan for
Laboratory Development Plan:
IHE Lab Planning Committee decision: May 2004
Issue Public Comment version: August 2004
Public Comment Due: September, 2004
Issue Trial Implementation version: October 2004
IHE Connectathon (USA): January 2005
IHE Connectathon (EU): March 2005
Supplements Under Discussion:
Lab Patient Info Reconciliation
Point of Care Testing
Lab Analyzer Management
Lab Report Access
IHE IT Infrastructure – March 2004

15. IHE Authentication Audit Trail
Scope
Ensures that only permitted system/devices connect to network
Authentication is node-to-node
Note: User authentication covered by the EUA profile or local procedures.
Support for a central repository of audit information. Facilitates audit review and includes:
General security events such as logins, file access, and detection of unauthorized activity
Healthcare privacy events such as access to patient data and applications.
Imaging privacy/security events such as access to patient images.
IHE IT Infrastructure – March 2004

16. IHE Authentication and Audit
Key technical properties
Node-to-node authentication uses X.509 certificates, but PKI is not specified by IHE yet.
Audit messages use a standardized XML format (IETF RFC Pending)
Transport for audit messages may use syslog or reliable syslog
Backwards compatibility with IHE Radiology (year 2002) is preserved.
IHE IT Infrastructure – March 2004

17. Personnel White Pages Directory Scope
Lab Reporting
White Pages
Server
Healthcare Staff Info
Healthcare Staff Info
Electronic
Medical Records
Healthcare Staff Info
Pharma
Provide access to healthcare staff information to systems in a standard manner.
IHE IT Infrastructure – March 2004

18. Personnel White Pages Directory Technical Properties
LDAP based directory location service
LDAP based requests of person info leveraging inetOrgPerson.
Specializes for Healthcare: Contact Info (Phone Numbers, address, etc), and user interface friendly info (Salutation, First name, Last name, office building, user certificate list-no PKI).
Access certificate revocation list (no use rule defined).
IHE IT Infrastructure – March 2004

19. Patient Demographics Query Abstract/Scope
Allow quick retrieval of common patient name, identifier, and location in a standard manner at the point of care.
Enable selection of correct patient when full identification data may not be available
Protect patient- and enterprise-sensitive clinical information
IHE IT Infrastructure – March 2004

20. Patient Demographics Query Key Technical Properties
Employs HL7 Conformance Based Queries
Defined in HL7 Version 2.5, Chapter 5
Query by Parameter (QBP) with Segment Pattern Response (RSP)
User enters identifiers for patients of interest
Server returns information in HL7 V2.5 patient data segments.
IHE IT Infrastructure – March 2004

21. IHE IT Infrastructure – March 2004
Introduction:
EHR Cross-Enterprise Clinical 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
IHE IT Infrastructure – March 2004

22. IHE IT Infrastructure – March 2004
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
IHE IT Infrastructure – March 2004

23. IHE IT Infrastructure – March 2004
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
IHE IT Infrastructure – March 2004

24. IHE IT Infrastructure – March 2004
Key Statements:
EHR-LR Fundamentals
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.
IHE IT Infrastructure – March 2004

25. IHE IT Infrastructure – March 2004
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.
IHE IT Infrastructure – March 2004

26. IHE IT Infrastructure – March 2004
Key Statements:
IHE EHR Profiles Constraints
Although the EHR-LR data domains are primarily clinical, other information and services are needed to provide a complete view of the patient longitudinal record. These include patient demographics, access security, consent policies and others – some have already been addressed by IHE integration profiles.
The EHR-LR and EHR-CR repositories may be using different Patient Identification numbers. The longitudinal view is made possible by using standard cross-patient identification services (IHE PIX Integration Profile).
The way data is stored and managed internally by the EHR-CR is out of scope for the EHR-LR IHE Integration Profiles.
IHE IT Infrastructure – March 2004

27. IHE IT Infrastructure – March 2004
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.
IHE IT Infrastructure – March 2004

28. IHE IT Infrastructure – March 2004
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.
The IHE Cross-Enterprise Document Sharing (XDS) Profile provides the document management infrastructure to be used in conjunction with future IHE Clinical Document Content-Oriented Integration Profiles.
A set of Care Delivery Organizations (EHR-CR) sharing Clinical Documents per the XDS Integration Profile form a “ Clinical Affinity Domain”. An EHR-CR may belong to multiple Clinical Affinity Domains (a community network, a research team, etc.)
IHE IT Infrastructure – March 2004

29. EHR-LR Integration Profile: Key Actors (Application Roles)
EHR-CR Document Source
Healthcare point of service system where clinical information is first collected
EHR-LR Document Registry
Index and metadata database for all published clinical documents
EHR-LR Documents Repository
Maintains and stores published EHR-LR documents
EHR-CR Document Consumer
Application system that needs access to EHR-LR documents and information
IHE IT Infrastructure – March 2004

30. IHE IT Infrastructure – March 2004
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 Registry actor.
Keeps these documents in an EHR-LR Repository actor.
Any other EHR-CR may query an EHR-LR Registry 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 model 1 & 2).
Register
EHR-LR Registry
EHR-CR
Source
Query
EHR-CR
Consumer
EHR-LR
Repository
Retrieve
IHE IT Infrastructure – March 2004

31. IHE IT Infrastructure – March 2004
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 Registry Actor.
Provides these documents to an EHR-LR Repository Actor.
Any other EHR-CR may query an EHR-LR Registry 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 model 1 & 2).
Register
EHR-LR Registry
Query
EHR-CR
Source
EHR-CR
Consumer
Provide-Transfer
EHR-LR
Repository
Retrieve
IHE IT Infrastructure – March 2004

32. IHE IT Infrastructure – March 2004
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 Consumer Actor that a specific set of documents (newly created and priors of interest documents) are available from an EHR-LR Repository
The EHR-CR Consumer Actor receives both the registration and the documents.
EHR-CR
Consumer
EHR-CR
Source
Register
EHR-LR Directory
Provide-Transfer
EHR-LR
Repository
IHE IT Infrastructure – March 2004

33. IHE IT Infrastructure – March 2004
Conclusion:
EHR Cross-Enterprise Document Sharing
Leverages HL7 CDA (Clinical Document Architecture).
Leverages content from ASTM CCR (Continuity of Care Record), DICOM Objects, EHRCOM Compositions and others.
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 (EuroREC, CCR, etc.), IHE expects to contribute at a more cost-effective and rapid deployment.
IHE IT Infrastructure – March 2004