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

IHE IT Infrastructure – March 2004 More Info on IHE To learn more about IHE Integrating the Healthcare Enterprise: www.himss.org/ihe Read the IHE Fact Sheet www.rsna.org/ihe IHE IT Infrastructure – March 2004

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

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

Overview of Supplements to be specified in 2004

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

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

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

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

IHE IT Infrastructure – March 2004 IHE IT Infrastructure – Plan for 2004-2005 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

IHE IT Infrastructure – March 2004 IHE IT Ca rdiology – Plan for 2004-2005 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

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.

IHE IT Infrastructure – March 2004 IHE Radiology – Plan for 2004-2005 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

IHE IT Infrastructure – March 2004 IHE Laboratory – Plan for 2004-2005 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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