IHE Update to DICOM Committee

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

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

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

5. Overview of Supplements to be specified in 2004

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

9. Product IHE IntegrationStatement IHEConnectathon IHEDemonstration Product With IHE Easy to Integrate Products Standards IHEIntegration Profiles B IHEIntegration Profile A RFP A Proven Standards Adoption Process IHE ConnectathonResults IHETechnicalFramework User Site • 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 – 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

11. 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

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

13. 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

14. 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

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 DirectoryScope Lab Reporting WhitePages Server Healthcare Staff Info Healthcare Staff Info Electronic MedicalRecords 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 DirectoryTechnical 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

19. Patient Demographics QueryAbstract/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 QueryKey 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. Introduction: EHR Cross-EnterpriseClinical 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. 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. EHR-LR Integration Profiles: Publishing & Accessing the EHR-LR EHR-LR Nursing Homes Acute Care (Inpatient) Other Specialized Careor 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. 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 willnot be stored in the EHR-LR. IHE IT Infrastructure – March 2004

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

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

28. 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. 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). EHR-LRRegistry Register EHR-CR Source Query EHR-CR Consumer EHR-LR Repository Retrieve IHE IT Infrastructure – March 2004

31. 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 Query EHR-LRRegistry EHR-CR Source EHR-CR Consumer Provide-Transfer EHR-LR Repository Retrieve IHE IT Infrastructure – March 2004

32. 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-LRDirectory Provide-Transfer EHR-LR Repository IHE IT Infrastructure – March 2004

33. 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