1. Process and IT Infrastructure Standards Drive Healthcare Solutions San Diego, Jan 2004 Charles Parisot IHE Planning Committees: IT, Radiology, Laboratory, Cardiology GE Medical Systems – Information Technology

2. Outline 1. IHE Process Overview 2. IHE for IT Infrastructure 3. IHE for Laboratory 4. IHE for Radiology IHE Cardiology established first output expected for end of 2004

3. IHE Process Overview IHE introduces a novel process to accelerate the adoption and to facilitate use of standards in healthcare

4. HL7 San Diego – January 2004 3 IHE Mission Bring together stakeholders to implement standards for communicating clinical and operational data safely and efficiently throughout the healthcare enterprise

5. HL7 San Diego – January 2004 4 IHE Vision To provide relevant patient information at the point of care to support caregiver decision-making and optimal patient care

6. HL7 San Diego – January 2004 5 What is IHE? A joint initiative to improve systems integration – Process for coordinated adoption of standards – Clinicians/IT staff define needs – Vendors develop solutions—Technical Framework – Professional societies supervise documentation, testing and demonstration/promotion

7. HL7 San Diego – January 2004 6 Goals of IHE Speed up the rate and quality of integration in healthcare environments Foster communication among vendors Prove that integration is attainable based on standards Improve the efficiency and effectiveness of clinical practice

8. HL7 San Diego – January 2004 7 What IHE is NOT! A standards development organization – Uses established standards (HL7, DICOM, RFCs, others) to address specific clinical needs – Activity complementary to SDOs, formal relationship with HL7 and DICOM. Simply a demonstration project – Demos only one means to the end—adoption – Backed up by documentation, tools, testing, and publication of information

9. HL7 San Diego – January 2004 8 IHE Participants Societies Representing Healthcare Segments – ( Radiology, Lab, IT Professional Societies… ) Users – ( Clinicians, Medical Staff, Administrators, CIOs, … ) Information Systems Vendors Clinical Systems and Device Vendors Standards Development Organizations (SDOs) – HL7 – DICOM – Others …

10. HL7 San Diego – January 2004 9 Benefits to IHE Participants Clinicians – Improved workflow – Information when and where needed – Fewer opportunities for errors – Fewer tedious tasks/repeated work Administrators – Improved efficiency – Best of breed opportunities – Decreased cost and complexity of interface deployment and management

11. HL7 San Diego – January 2004 10 Benefits to IHE Participants Vendors – Decreased cost and complexity of interface installation and management – Validation of integration at Connectathon – Focus competition on functionality/service space not information transport space SDOs – Rapid feedback to adjust standards to real-world – Establishment of critical mass and widespread adoption

12. HL7 San Diego – January 2004 11 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 – Foster IHE success stories

13. HL7 San Diego – January 2004 12 A Proven Standards Adoption Process IHE Integration Profiles B IHE Integration Profile A Easy to Integrate Products IHE Connectathon Product With IHE IHE Demonstration User Site RFP Standards IHE Technical Framework Product IHE Integration Statement IHE Connectathon Results 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

14. HL7 San Diego – January 2004 13 IHE Deliverables 1.Venues for discussion between users and vendors 2.Common vocabulary/ view of the world based on: –Standard information models (HL7, DICOM, etc.) –Coded information and their meaning 3.Technical Framework = An Implementation Guide –ACTORS in roles performing TRANSACTIONS to accomplish Specific Processes –Together they form INTEGRATION PROFILES 4.Connect-a-thon: Testing opportunity. 5.Public Demonstrations / Education/ Publications 6.Marketing Tools for compliant products: Connectathon results published Products claim conformance with Integration Statement

15. HL7 San Diego – January 2004 14 Result Matrix of the Radiology Connectathon

16. HL7 San Diego – January 2004 15 The Annual “Connectathon”  Unprecedented Cross-Vendor Testing  Voluntary Participation  Neither a Demo nor a Certification  Well Designed End-to-End Scenarios  Advanced Testing Tools  Unprecedented Pool of Technical Talent  Connectathon for IT Infrastructure San Diego January 26-30, 2004  Connectathon for IT Infrastructure, Laboratory & Radiology - Padova (Italy) March 29-April 2, 2004  Connectathon for Radiology and IT Infrastructure Tokyo – March 2004  Connectathon for Radiology - Chicago October 2004

17. HL7 San Diego – January 2004 16 IHE Resources Proven process with strong participation Five years of documentation, testing, demos Technical Framework MESA Tools and Connectathon 2003: 36 vendors in USA 2003: 43 vendors in Europe Strong recognition and credibility of concept Promotional opportunities at major professional venues world-wide: HIMSS, RSNA, JRC, Hopital Expo, DRG, UKRC, SIRM, JFR, Medica

18. HL7 San Diego – January 2004 17 IHE Domains and Regions IHE North America United States of America HIMSS, RSNA, ACCE, ACC IT Infrastructure RadiologyLaboratoryCardiology IHE Europe EAR, ECR, COCIR IHE Asia National Extensions Canada Infoway, CAR, France GMSIH, SFR, SFL, Germany DRG, ZVEI Italy SIRM, United Kingdom BIR, RCR, NHS, Norway, Sweden, Dennemark Japan JIRA, JAHIS, METI, JRS, JSRT, JAMI Korea Taiwan National Extensions Global Development Local Deployment IHE Technical Framework IHE Connectathons, Education, Demonstrations

19. HL7 San Diego – January 2004 18 Key IHE Concepts Generalized Systems -> ActorsGeneralized Systems -> Actors Interactions between Actors -> TransactionsInteractions between Actors -> Transactions Problem/Solution Scenarios-> Integration ProfilesProblem/Solution Scenarios-> Integration Profiles For each Integration Profile:For each Integration Profile: the context is described (which real-world problem)the context is described (which real-world problem) the actors are defined (what systems are involved)the actors are defined (what systems are involved) the transactions are defined (what must they do)the transactions are defined (what must they do)

20. HL7 San Diego – January 2004 19 Actors Represent a set of roles and responsibilities performed by a system A real-world system may support several IHE Actors Examples: – Order Placer – Order Filler – Patient Identifier Cross-Referencing Mgr – Laboratory Automation – Report Creator

21. HL7 San Diego – January 2004 20 Transactions Unambiguously defines how actors communicate Using existing standards such as HL7 or DICOM to accomplish a specific task. Examples: – Procedure Scheduled – ADT Update – Retrieve Document for Display

22. HL7 San Diego – January 2004 21 Integration Profiles IHE Integration Profiles define a collection of real world functionality and group together the necessary Actors and Transactions to make it work. Examples: – Enterprise User Authentication – Retrieve Information for Display – Laboratory Scheduled Workflow – Patient Information Reconciliation

23. HL7 San Diego – January 2004 22 IHE: A stepwise approach Cardiology Labora- tory Pharmacy,….. Radiology Patient Identifier Linkage, Registries, SecurityElectronic Health RecordEnterprise Scheduling Patient Management Order Management

24. HL7 San Diego – January 2004 23 IHE Integration Statement

25. HL7 & IHE Joint Demonstration at HIMSS 2004

26. HL7 San Diego – January 2004 25 New at HIMSS in 2004 In 2002 and 2003, IHE and HL7 have held separate demonstration – HL7 demos were « throw away » – IHE demos were « radiology centric » IHE is now in Healthcare IT - 5 new profiles to be showcased at HIMSS 2004 HL7 and IHE have decided this year to combine their demos and convey a 2 tier message: – HL7 broad in scope but leaves choices for interoperability – IHE Profiles are narrow in scope but high interoperability

27. HL7 San Diego – January 2004 26 HL7-IHE Interoperability demo Demo scenario integrates 3 components: - IHE IT Integration Profiles, and selected domain specific Profiles (e.g. Radiology). - HL7 standard functions - HL7 draft standard functions Demo highlights how each component feeds into other and contributes to successful driving of standards in healthcare solutions.

28. HL7 San Diego – January 2004 27 HL7-IHE Interoperability demo Live technology & product interoperability demonstration At the center of the commercial exhibit floor at HIMSS, February 2004 Promoted by HIMSS-signage show-wide.

29. HL7 San Diego – January 2004 28 The Product World….. Product XYZ from Vendor T

30. HL7 San Diego – January 2004 29 The IHE World…. IHE Actor Actor IHE Transaction IHE Actor

31. HL7 San Diego – January 2004 30 Mapping IHE to Products Poduct XYZ from Vendor T IHE Actor Actor IHE Transaction IHE Actor

32. HL7 San Diego – January 2004 31 The IHE Technical Approach Identify the transactions required to integrate a specific information flow between several information systems/devices For each transaction, select a single standard (e.g.HL7 messages, RFC) for use in implementing the transaction Specify in detail the use of the standard in implementing the transaction

33. HL7 San Diego – January 2004 32 IHE : An Integration Profile A Solution to an Integration Problem  24: Report Submission Structured Report Export: 28   25: Report Issuing Report Creator  26: Query Reports  27: Retrieve Reports Report Repository Report Reader External Report Repository Access Report Manager Enterprise Report Repository Transactions Actors cooperating through Transactions to perform a specific task

34. Overview of IHE IT Infrastructure Integration Profiles

35. HL7 San Diego – January 2004 34 IHE IT Infrastructure 5 Integration Profiles Enterprise User Authentication Provide users a single name and centralized authentication process across all systems 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 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 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 Synchronize multiple applications on a desktop to the same patient Patient Synchronized Applications Consistent Time Coordinate time across networked systems Consistent Time Coordinate time across networked systems

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

37. HL7 San Diego – January 2004 36 Abstract / Scope Simple and rapid access to patient information Access to existing persistent documents in well- known presentation formats: CDA, PDF, JPEG. Access to specific key patient-centric information for presentation to a clinician : allergies, current medications, summary of reports, etc.. Links with other IHE profiles - Enterprise User Authentication & Patient Identifier Cross-referencing. Retrieve Information for Display

38. HL7 San Diego – January 2004 37 Value Proposition: User Convenience: – Healthcare providers can "see" the information. A significant integration step. – Workflows from within the users’ on-screen workspace or application. – Complements multiple simultaneous apps workflow of Patient Synchronized Apps Broad Enterprise-Wide access to information: – Web technology for simple clients – Clinical data handling fully assumed by the information source that holds clinical data. Retrieve Information for Display

39. HL7 San Diego – January 2004 38 Key Technical Properties: Standards Used: – Web Services (WSDL for HTTP Get). – General purpose IT Presentation Formats: XHTML, PDF, JPEG plus CDA L1. – Client may be off-the-shelf browser or display application. Two services : – Retrieve of Specific Information: Patient centric: patient ID Type of Request (see next slide) Date, Time, nMostRecent – Retrieve a Document Object Unique Instance Identifier (OID) Type of Request Content Type Expected Retrieve Information for Display

40. HL7 San Diego – January 2004 39 Transaction Diagram Retrieve Information for Display Display Information Source Retrieve Specific Info for Display [11] Summary of All Reports Summary of Laboratory Reports Summary of Radiology Reports Summary of Cardiology Reports Summary of Surgery Reports Summary of Intensive Care Reports Summary of Emergency Reports Summary of Discharge Reports List of Allergies List of Medications Retrieve Document for Display [12] Persistent Document Types of Requests

41. HL7 San Diego – January 2004 40 IHE IT Infrastructure 5 Integration Profiles Enterprise User Authentication Provide users a single name and centralized authentication process across all systems 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 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 Patient Identifier Cross-referencing for MPI Map patient identifiers across independent identification domains Consistent Time Coordinate time across networked systems Consistent Time Coordinate time across networked systems Synchronize multiple applications on a desktop to the same patient Patient Synchronized Applications Synchronize multiple applications on a desktop to the same patient Patient Synchronized Applications

42. HL7 San Diego – January 2004 41 Abstract / Scope Patient synchronization of multiple disparate applications Single patient selection When combined with PIX Profile, allows patient synchronization across patient identity domains Patient Synchronized Applications

43. HL7 San Diego – January 2004 42 Value Proposition: User Convenience: – Eliminates the repetitive task of selecting the patient in each application – Permits the user to select the patient in the application for which they are most familiar and / or appropriate to the clinical workflow Patient Safety: – Ensures all data being viewed across applications is for the same patient Patient Synchronized Applications

44. HL7 San Diego – January 2004 43 Key Technical Properties: Standards Used: – HL7 Context Management “CCOW” Standard, Version 1.4 – Support for both Windows and Web Technology – Support of “Patient Subject” IHE Constraints: – Specifies use of Patient.Id.IdList item Ensures maximum interoperability with PIX Profile Protects against future deprecation of patient identifier items (HL7 2.3.1, 2.4, 2.5, CCOW). Patient Synchronized Applications

45. HL7 San Diego – January 2004 44 Transaction Diagram Patient Synchronized Applications

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

47. HL7 San Diego – January 2004 46 Patient Identifier Cross-referencing Abstract / Scope Allow all enterprise participants to register the identifiers they use for patients in their domain Support domain systems’ queries for other systems’ identifiers for their patients Optionally, notify domain systems when other systems update identifiers for their patients

48. HL7 San Diego – January 2004 47 Patient Identifier Cross-referencing Value Proposition Maintain all systems’ identifiers for a patient in a single location Use any algorithms (encapsulated) to find matching patients across disparate identifier domains Lower cost for synchronizing data across systems – No need to force identifier and format changes onto existing systems Leverages standards and transactions already used within IHE

49. HL7 San Diego – January 2004 48 Patient Identifier Cross-referencing ID Domains & Transactions

50. HL7 San Diego – January 2004 49 Patient Identifier Cross-referencing Key Technical Properties Standards Used – HL7 Version 2.3.1 and Version 2.4 ADT Registration and Update Trigger Events –A01: inpatient admission –A04: outpatient registration –A05: pre-admission –A08: patient update –A40: merge patient Queries for Corresponding Identifiers (ADT^Q23/K23) Notification of Identifiers Lists Updates (ADT^A31) Key Properties – ADTs remain in charge of their domains – No need for a master ID or MRN, but supported as another ID domain

51. HL7 San Diego – January 2004 50 IHE IT Infrastructure 5 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 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 Patient Identifier Cross-referencing for MPI Map patient identifiers across independent identification domains Consistent Time Coordinate time across networked systems Consistent Time Coordinate time across networked systems Synchronize multiple applications on a desktop to the same patient Patient Synchronized Applications Synchronize multiple applications on a desktop to the same patient Patient Synchronized Applications Enterprise User Authentication Provide users a single name and centralized authentication process across all systems Enterprise User Authentication Provide users a single name and centralized authentication process across all systems

52. HL7 San Diego – January 2004 51 Enterprise User Authentication Abstract / Scope Support a single enterprise governed by a single set of security policies and having a common network domain. Establish one name per user that can then be used on all of the devices and software in a healthcare enterprise. Facilitate centralized user authentication management. Provide users with single sign-on.

53. HL7 San Diego – January 2004 52 Enterprise User Authentication Value Proposition Start at the beginning – Recognize user authentication as a necessary step for most application and data access operations. – Enable benefits from future integration profiles, such as authorization management. Achieve cost savings/containment. – Centralize user authentication management. – Simplify multi-vendor implementations Provide workflow improvement for users. – Increase user acceptance. – Decrease unproductive user task-switching time. Increase level of assurance in security protection.

54. HL7 San Diego – January 2004 53 Enterprise User Authentication Key Technical Properties Standards Used – Kerberos v5 (RFC 1510) Stable since 1993, Widely implemented on current operating system platforms Successfully withstood attacks in its 10-year history Fully interoperable among all platforms – HL7 CCOW user subject Minimal Application Changes – Eliminate application-specific, non-interoperable authentication. – Replace less secure proprietary security techniques.

55. HL7 San Diego – January 2004 54 Enterprise User Authentication Transaction Diagram

56. HL7 San Diego – January 2004 55 IHE IT Infrastructure 5 Integration Profiles Enterprise User Authentication Provide users a single name and centralized authentication process across all systems 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 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 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 Synchronize multiple applications on a desktop to the same patient Patient Synchronized Applications Consistent Time Coordinate time across networked systems Consistent Time Coordinate time across networked systems

57. HL7 San Diego – January 2004 56 Consistent Time Scope and Value Proposition Ensures that the system clocks and time stamps of the many computers in a network are well synchronized A median error under 1 second is sufficient for most purposes. Consistent Time profile specifies the use of the Network Time Protocol (NTP) defined in RFC 1305.

58. HL7 San Diego – January 2004 57 IHE IT Infrastructure 5 Integration Profiles Enterprise User Authentication Provide users a single name and centralized authentication process across all systems 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 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 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 Synchronize multiple applications on a desktop to the same patient Patient Synchronized Applications Consistent Time Coordinate time across networked systems Consistent Time Coordinate time across networked systems

59. Synergy between IHE IT Int. Profiles RID with EUA/CT & PIX Display Client Authentication Agent Time Client Information Source Kerberos Authentication Server Time Server Patient Identity Consumer Patient Identity X-ref Manager Example of support of multiple actors/profiles 58

60. Synergy between IHE IT Int. Profiles Apps with PSA, EUA & PIX Application A Client Authentication Agent Time ClientKerberos Authentication Server Time Server Patient Identity Consumer Patient Identity X-ref Manager Context Manager Application B Context participant Example of support of multiple actors/profiles 59

61. How to proceed with IHE IT Infra 1. Read IHE Fact Sheet & this presentation www.himss.org/ihe 2. Read ITI Technical Framework Vol 1 Integration Profiles www.himss.org/ihe 3. Read ITI Technical Framework Vol 2 Transactions www.himss.org/ihe 4. Enter comments on http://forums.rsna.org 5. IHE IT Infrastructure Tech. Committee has issued the trial for implementation technical framework in August for HIMSS HL7-IHE Demo. 6. Final IT Infrastructure Technical Framework to be issued in February 2004. 60

62. HL7 San Diego – January 2004 61 Integration profiles, the easy way to deal with transactions easy-to-understand, coherent functional sets and a convenient way for users and vendors to communicate about integration requirements and needed functionality in daily life.

63. Overview of the IHE Laboratory Integration Profile

64. HL7 San Diego – January 2004 63 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. 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 Laboratory Integration Profiles 1 now, 4 planned Provide users a single name and centralized authentication process across all systems Point of Care Testing(Future) Extend laboratory testing with bedside testing devices Synchronize multiple applications on a desktop to the same patient Patient Synchronized Applications Cooperation with external laboratory Outside Healthcare Enterprise Testing (Future) Provide users a single name and centralized authentication process across all systems Laboratory Patient Information Reconciliation (Future) Updates resulting from unidentified or misidentified Patient Provide users a single name and centralized authentication process across all systems Lab Analyzer Management (Future) Extend laboratory testing with intra-lab testing devices

65. HL7 San Diego – January 2004 64 IHE-Lab Technical Framework 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. Lab-TF Trial Implementation has been issued on November 15, 2003

66. HL7 San Diego – January 2004 65 Laboratory Scheduled Workflow Abstract / Scope Spans ordering, conformity of specimens, lab automation, results delivery. Handles all major types of workflows: – Externally placed order with identified specimens – Externally placed order with specimens unidentified or to be collected by the laboratory – Internally placed order with specimens identified by third party or collected by the laboratory Shares ADT transactions with Radiology

67. HL7 San Diego – January 2004 66 Laboratory Scheduled Workflow Value Proposition A comprehensive workflow approach – Spans all countries – Address specimen linkage – most lab specialties: Blood gases, Chemistry, Hematology, Immunology, Laboratory, Microbiology, Mycobacteriology, Mycology, Serology, Toxicology, Virology. Provides workflow improvement – Increases continuity and integrity of clinical data – Decreases user need for manual tasks.

68. HL7 San Diego – January 2004 67 Laboratory Scheduled Workflow Key Technical Properties Standard Used : HL7 V2.5 – Released 2003 – Includes significant extensions developed by HL7 UK and Germany for specimen tracking – Leverages broad acceptance world-wide of HL7 V2 – Offers the option to support HL7V2-XML IHE Integration Profile value-add: – A robust data model supporting all necessary workflow concepts. – Offers a significant improvement over V2.3 for a reasonable incremental effort.

69. HL7 San Diego – January 2004 68 Laboratory Scheduled workflow Already defined In Radiology TF

70. IHE Looking to the future...

71. HL7 San Diego – January 2004 70 IHE plans for 2004 6 Candidate Integration Profiles 1. EHR-Longitudinal Record Management 2. Patient Demographics Query 3. Enterprise Audit Trail Mgt 4. Cross-Node Security (Authentication, Encryption) 5. Healthcare Staff White Page Directory 6. Basic Configuration Mgt Selection by January 2004 Public Comment Supplements by June 2004

72. HL7 San Diego – January 2004 71 IHE Integration Profiles Focused on the EHR Under development in 2004 An IHE Integration Profile organizes a set of coordinated, standards- based transactions between a subset of the functional components of healthcare enterprises in order to address a specific clinical or infrastructure need. IHE develops such solutions for IT systems integration in a stepwise and pragmatic manner, focusing on the most common integration challenges. IHE has developed close to 20 Integration Profiles focuses on IT Infrastructure (MPI, Security, etc.), Radiology, Laboratory and is now expanding to Cardiology. This is an intra-enterprise, bottom-up approach. In this proposal, IHE explains how it intends to approach the longitudinal dimension of the EHR with a distributed, cross-enterprise, document centric, top-down point of view. Feedback on this approach and expanding collaborations are sought.

73. HL7 San Diego – January 2004 72 Acute Care (Inpatient) GPs and Clinics (Outpatient) Nursing Homes Other Specialized Care or Diagnostics Services Continuity of Care: Patient Longitudinal Record Across Encounters A typical patient goes through a sequence of encounters in different Care Setting (incl. Diagnostics Services).

74. HL7 San Diego – January 2004 73 Acute Care (Inpatient) GPs and Clinics (Outpatient) Nursing Homes Other Specialized Care or Diagnostics Services Integration : Feeding & Accessing the Longitudinal Health Record Information EHR-LR The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems

75. HL7 San Diego – January 2004 74 Care Delivery Process Selection of informations Decide to Assess demand For care Actions to order Define an action plan Identification End of Encounter Define healthcare Objective EHR-CR EHR-CR : EHR information supporting immediate care delivery EHR-LR EHR-LR : EHR information supporting long term care delivery Two types of Integration : Health Record as used during care delivery Health Record as used across-encounters EHR-CR Read EHR-LR Read EHR-LR Create Update

76. HL7 San Diego – January 2004 75 EHR-LR Documents Repository Custodian for an unspecified time of Documents recorded from patient encounters. EHR-LR Virtual Documents Repository Custodian for an unspecified time of Documents recorded from local patient encounters. EHR-LR Directory EHR-LR Actors: Directory & Repository Actors EHR-LR Documents Repository Custodian for an unspecified time of Documents recorded from patient encounters. EHR-CR

77. HL7 San Diego – January 2004 76 IHE Integration Profiles Focused on the EHR IHE proposes an approach to obtaining a longitudinal view of the EHR, with a distributed, cross-enterprise, document centric solution.IHE proposes an approach to obtaining a longitudinal view of the EHR, with a distributed, cross-enterprise, document centric solution. The strategy is to progressively bridge the gap between the EHR-LR Integration Profiles and the domain integration profiles as new integration profiles are developed. Feedback on this approach and expanding collaborations are sought. Is this a useful “brick” ? The proposed strategy is a scoping exercise to address one of the many 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.

78. HL7 San Diego – January 2004 77 Where is More Information Available? www.himss.org/IHE IHE IT Technical framework – V1.0 IHE RAD Technical framework – V5.5 IHE LAB Technical framework – V1.0 Non-Technical Brochures : IHE Primer and IHE FAQ IHE Integration Profiles: Guidelines for Buyers IHE Connectathon Results IHE Integration Statements from Vendors

79. IHE Thank You