IHE Update to DICOM Committee

IHE Update to DICOM CommitteeIHE Update to DICOM Committee

Charles Parisot, GE Healthcare ITIHE IT Infrastructure Technical Committee co-chair

IHE IT Infrastructure – March 2004 2

More Info on IHEMore Info on IHE

To learn more about IHEIntegrating the Healthcare Enterprise:

www.himss.org/iheRead the IHE Fact Sheet

www.rsna.org/ihe


IHE IT InfrastructureIHE IT Infrastructure5 Current Integration Profiles5 Current Integration Profiles

Enterprise User Authentication

Provide users a single nameand

centralized authentication process

across all systems



centralized authentication process

across all systems

Retrieve Information for Display

Access a patient’s clinical information and documents in a

format ready to be presentedto the requesting user




Patient Identifier Cross-referencing

for MPI

Map patient identifiers across independent

identification domains


for MPI



Synchronize multiple applications on a desktop to the same patient

Patient Synchronized Applications



Consistent Time

Coordinate time across networked

systems

Consistent Time


systems


IHE IT Infrastructure ProgressIHE IT Infrastructure ProgressIHE 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.

Overview of Supplements to be Overview of Supplements to be specified in 2004specified in 2004


Prof. Societies Sponsorship

Healthcare Providers & Vendors

Healthcare IT Standards HL7, DICOM, etc.

General IT Standards Internet, ISO, etc.

Interoperable Healthcare IT Solution Specifications

IHE Integration Profile Interoperable Healthcare IT

Solution Specifications IHE Integration Profile

Interoperable Healthcare IT Solution Specifications

IHE Integration Profile Interoperable Healthcare IT

Solution Specifications IHE Integration Profile

IHE Process

IHE drives healthcare standards based-integration IHE drives healthcare standards based-integration


IHE

EHR- Longitudinal Record

IHE Cardiology

IHE Laboratory

IHE Radiology

IHE

Future Domain

IHE

Future Domain

IHE

IT Infrastructure Intra-Enterprise

Cross-Enterprise

12 Integration Profiles

1 Integration Profile



IHE 2003 achievements and expanding scope IHE 2003 achievements and expanding scope

Over 80 vendors involved world-wide, 4 Technical Frameworks24 Integration Profiles, Testing at yearly Connectathons,

Demonstrations at major exhibitions world-wide

Provider-Vendor cooperation to accelerate standards adoption


IHE ProcessIHE 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…)


A Proven Standards Adoption ProcessA Proven Standards Adoption Process

IHEIntegrationProfiles B

IHEIntegrationProfile A

Easy toIntegrateProducts

IHEConnectathon

ProductWith IHE

IHEDemonstration

User Site

RFPRFP

Standards

IHETechnical

Framework

Product IHE IntegrationProduct IHE IntegrationStatementStatement

IHE IHE ConnectathonConnectathonResultsResults

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 – Plan for 2004-2005

• IT Infrastructure Development Plan:• IHE ITI Planning Committee decision:IHE ITI Planning Committee decision: mid-Februarymid-February• Issue Public Comment version: June 2004• Public Comment Due: July 2004• Issue Trial Implementation version: Issue Trial Implementation version: August 2004August 2004• IHE Connectathon: January 2005• HIMSS Demo: HIMSS Demo: February 2005February 2005

• Profiles under development are:• Audit Trail and Node AuthenticationAudit Trail and Node Authentication• Personnel White Page Directory Personnel White Page Directory • Patient Demographics QueryPatient Demographics Query• EHR-Cross-Enterprise Clinical Document SharingEHR-Cross-Enterprise Clinical Document Sharing


IHE IT Cardiology – Plan for 2004-2005 • IT Cardiology Development Plan:

• IHE Card Planning Committee decision:IHE Card Planning Committee decision: mid-Februarymid-February• Issue Public Comment version: July 2004• Public Comment Due: August 2004• Issue Trial Implementation version: Issue Trial Implementation version: September 2004September 2004• IHE Connectathon (USA): January 2005• IHE Connectathon (EU): March 2005• ACC Demo: ACC Demo: March 2005March 2005• ESC Demo: ESC Demo: August 2005August 2005

• Profiles under development :• CathLab WorkflowCathLab Workflow• EchoLab WorkflowEchoLab Workflow• Enterprise ECG Reports AccessEnterprise ECG Reports Access• Retrieve Info for Display (in Cardio - extension)Retrieve Info for Display (in Cardio - extension)• Audit Trail and Node AuthenticationAudit Trail and Node Authentication• Patient Id Cross-ReferencingPatient Id Cross-Referencing

2004 IHE Integration Profiles2004 IHE Integration Profiles



centralized authentication

processacross all systems



centralized authentication

processacross all systems








for MPI




for MPI







Consistent Time


systems

Consistent Time


systems

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 Procedure

s

Post-

Processing Workflow

Reporting Workflow

Charge

Posting

Scheduled Workflow




Laboratory Scheduled WorkflowAdmit, Discharge, Transfer a patient, order lab tests,

collect specimen, perform tests, report results.

IT InfrastructureIT InfrastructureRadiology,Radiology, LaboratoryLaboratory


IHE Radiology – Plan for 2004-2005

• Radiology Development Plan:• IHE Rad Planning Committee decision:IHE Rad Planning Committee decision: mid-Octobermid-October• Issue Public Comment version: February 2004• Public Comment Due: March 2, 2004• Issue Trial Implementation version: Issue Trial Implementation version: April 2004April 2004• IHE Connectathon (USA): January 2005• IHE Connectathon (EU): March 2005

• Supplements under development:• Imaging Patient Record on MediaImaging Patient Record on Media• Appointment Notification (SWF Option)Appointment Notification (SWF Option)• Report Report (HL7 V2-OBX) (SINR Option)Report Report (HL7 V2-OBX) (SINR Option)• Instance Availability NotificationInstance Availability Notification• White Paper on Departmental WorkflowWhite Paper on Departmental Workflow


IHE Laboratory – Plan for 2004-2005

• Laboratory Development Plan:• IHE Lab Planning Committee decision:IHE Lab Planning Committee decision: May 2004May 2004• Issue Public Comment version: August 2004• Public Comment Due: September, 2004• Issue Trial Implementation version: Issue Trial Implementation version: October 2004October 2004• IHE Connectathon (USA): January 2005• IHE Connectathon (EU): March 2005

• Supplements Under Discussion:• Lab Patient Info ReconciliationLab Patient Info Reconciliation• Point of Care TestingPoint of Care Testing• Lab Analyzer ManagementLab Analyzer Management• Lab Report AccessLab Report Access


IHE Authentication Audit TrailIHE Authentication Audit TrailScope

– 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 Authentication and AuditIHE 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.


Personnel White Pages DirectoryPersonnel White Pages DirectoryScopeScope

WhitePagesServer

Healthcare Staff Info

Provide access to healthcare staff informationProvide access to healthcare staff information to systems in a standard manner. to systems in a standard manner.

Lab Reporting

ElectronicElectronicMedicalMedicalRecordsRecords

Pharma




Personnel White Pages DirectoryPersonnel White Pages DirectoryTechnical PropertiesTechnical Properties

LDAP based directory location service

LDAP based requests of person info leveraging inetOrgPerson.

Specializes for Healthcare: Contact Info (Phone Numbers, email 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).


Patient Demographics QueryPatient Demographics QueryAbstract/ScopeAbstract/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


Patient Demographics QueryPatient Demographics QueryKey Technical PropertiesKey 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.


Introduction:EHR Cross-EnterpriseEHR Cross-EnterpriseClinical Document SharingClinical Document Sharing

First step towards the First step towards the longitudinal dimension of the EHRlongitudinal dimension of the EHR::

Focus:Focus: Clinical Information Exchange between EHRs in Clinical Information Exchange between EHRs in care settings to communicate with a distributed care settings to communicate with a distributed longitudinal EHR.longitudinal EHR.

Goal:Goal: Meet a broad range of EHR-LR (Longitudinal Record) Meet a broad range of EHR-LR (Longitudinal Record) needs with a needs with a distributed, distributed, cross-enterprise, cross-enterprise, document centric document centric

document content generic document content generic


Acute Care (Inpatient)

GPs and Clinics (Outpatient)

Nursing Homes

Other Specialized Care(incl. Diagnostics Services)

Continuity of Care: Patient Longitudinal RecordPatient Longitudinal Record

Typically, a patient goes through a sequence of encounters in different Care Setting


Acute Care (Inpatient)

GPs and Clinics (Outpatient)

Nursing Homes

Other Specialized Careor Diagnostics Services

EHR-LR Integration Profiles: Publishing & Accessing the EHR-LRPublishing & Accessing the EHR-LR

EHR-LR

The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems


Key Statements:EHR-LR FundamentalsEHR-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.


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


Key Statements: IHE EHR Profiles ConstraintsIHE 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.


Key Statements: Accessing the EHR-LRAccessing 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.


Key Statements: Deploying IHE EHR-LR ProfilesDeploying 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.)


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

EHR-LR Integration Profile: Key Actors (Application Roles)Key Actors (Application Roles)


Integration Model 1: EHR-LR with Source RepositoryEHR-LR with Source Repository

1. An EHR-CR completes a phase of care for a patient where it:

1. Registers documents with an EHR-LR Registry actor.

2. Keeps these documents in an EHR-LR Repository actor.

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

EHR-CRSource

EHR-LRRegistry

EHR-LRRepository

EHR-CRConsumer

Register

Retrieve

Query


Integration Model 2:EHR-LR with Third Party RepositoryEHR-LR with Third Party Repository


1. Registers documents with an EHR-LR Registry Actor.

2. Provides these documents to an EHR-LR Repository Actor.

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

EHR-CREHR-CRSourceSource

EHR-LREHR-LRRegistryRegistry

EHR-LREHR-LRRepositoryRepository

EHR-CR EHR-CR ConsumerConsumer

Register

Retrieve

Query

Provide-Transfer


EHR-CR EHR-CR ConsumerConsumer

Integration Model 3: Direct Patient Transfer-Referral Direct Patient Transfer-Referral


• 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

2. The EHR-CR Consumer Actor receives both the registration and the documents.

EHR-CREHR-CRSourceSource

Register

Provide-Transfer

EHR-LREHR-LRDirectoryDirectory

EHR-LREHR-LRRepositoryRepository


Conclusion:Conclusion:EHR Cross-Enterprise Document SharingEHR 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.