Interoperability in the Real World, Testing, Success Stories and International

1. HIMSS 2005 1 Interoperability in the Real World, Testing, Success Stories and International Didi Davis, Eclipsys Glen Marshall, Siemens IHE IT Planning Committee Co-Chairs

2. HIMSS 2005 2 Providers and Vendors Working Together to Deliver Interoperable Health Information Systems in the Enterprise and across Care Settings

3. HIMSS 2005 3 Standards Alone Are Not Enough Standards offer generality, ambiguity and alternatives. We need to manage domain boundaries, with mapping of information flow across those boundaries. Vendors always have proprietary interests. The result: Complexity!!

4. HIMSS 2005 4 Connecting Standards to Care Care providers must work with vendors to coordinate the implementation of standards to meet their needs Care providers need to identify the key interoperability problems they face Drive industry to develop and make available standards-based solutions Implementers need to follow common guidelines in purchasing and integrating systems that deliver these solutions

5. HIMSS 2005 5 Need for a Standards Implementation Process

6. HIMSS 2005 6 What is  Integrating the Healthcare Enterprise ? IHE provides a common framework for passing health information seamlessly: within the healthcare enterprise across multiple healthcare enterprises for local, regional & national health information networks. IHE is sponsored by healthcare professional associations (ACC, HIMSS, RSNA, etc.). IHE drives standards adoption to address specific clinical needs.

7. HIMSS 2005 7 IHE Maturity and Acceptance More than 100 healthcare vendors worldwide have contributed to IHE and the delivery of ready-to-integrate products to benefit healthcare enterprises of all sizes. IT professionals & clinicians appreciate IHE’s positive impact now expanded to address: radiology, cardiology, laboratory enterprise healthcare IT infrastructures cross-enterprise healthcare IT infrastructures

8. HIMSS 2005 8 Understanding the IHE Initiative IHE has a clear focus IHE is a healthcare domain-based initiative IHE creates synergies for interoperability testing across domains IHE addresses the standards adoption process IHE is both regional and multi-national IHE is both user led and vendor driven

9. HIMSS 2005 9 A Proven Standards Adoption Process

10. HIMSS 2005 10

11. HIMSS 2005 11

12. HIMSS 2005 12 IHE Survey Results 92% of respondents were aware of IHE Potential benefits of IHE ? Improved clinical workflow + access of data = 63% Benefits of IHE products ? Reduce deployment costs = 56%

13. HIMSS 2005 13 IHE: Domain-based for a stepwise approach

14. HIMSS 2005 14

15. HIMSS 2005 15 IHE Process Users identify desired functionality that require coordination and communication among multiple systems E.g., departmental workflow, single sign-on, sharing of documents Find and document standards-based transactions among systems to achieve desired functionality Apply necessary constraints to eliminate useless wiggle room Provide process and tools to encourage vendors to implement MESA software test tools + Connect-a-thon interoperability testing event Provide tools and education to help users acquire and integrate systems using these solutions Connect-a-thon results, public demo & Vendor Integration statements

16. HIMSS 2005 16 IHE Process – 20 month yearly cycle

17. HIMSS 2005 17 What IHE is NOT! A standards development organization Uses established standards (HL7, DICOM, others) to address specific clinical needs Activity complementary to SDOs, formal relationship with HL7, ISO, DICOM, NCCLS, etc. Simply a demonstration project Demos, only one means to the end—adoption Backed up by documentation, tools, testing, and publication of information

18. HIMSS 2005 18 Continuity & Integrity of Patient Information Improved Patient Safety Through Ubiquitous Access to Data Clinical Workflow Optimization Avoidance of Repeating Tasks Reduction of Data Redundancy Enterprise-wide Healthcare Needs Addressed by IHE

19. HIMSS 2005 19 IHE IT Infrastructure Profiles

20. HIMSS 2005 20 Key IHE Concepts Generalized the systems because there are many ways vendors can bundle products. Some PACS may include a Report Creator, others may not. Some Modalities may include a Print Composer, others may not.Generalized the systems because there are many ways vendors can bundle products. Some PACS may include a Report Creator, others may not. Some Modalities may include a Print Composer, others may not.

21. HIMSS 2005 21 The Product World…..

22. HIMSS 2005 22 The IHE World….

23. HIMSS 2005 23 Mapping IHE to Products

24. HIMSS 2005 24 IHE Connectathon Open invitation to all implementers Advanced testing tools (MESA) Testing organized and supervised by project management team Thousands of cross-vendor tests performed Results recorded and published

25. HIMSS 2005 25

26. HIMSS 2005 26

27. HIMSS 2005 27 Leveraging IHE Integration Statements Vendors Claim IHE Compliance in an explicit way Can rely on an objective and thorough specification(IHE Technical Framework) Willing to accept contractual commitments Willing to correct “implementation errors” Buyers Can compare product integration capabilities Simplify and strengthen their RFPs Can leverage a public and objective commitment Decreased cost and complexity of interface deployment and management

28. HIMSS 2005 28 Participating and Contributing VendorsAmerica Agfa HealthCare Algotec Systems, Ltd. Berdy Camtronics Canon Medical Systems Carefx Cedara Software Corporation Cerner Corporation CSIST Dictaphone DR Systems Dynamic Imaging Eastern Informatics Eastman Kodak Company Emageon Eclipsys Fujifilm Medical Systems

29. HIMSS 2005 29

30. HIMSS 2005 30

31. HIMSS 2005 31

32. HIMSS 2005 32 IHE Radiology Integration Profiles

33. HIMSS 2005 33 Laboratory IHE Integration Profiles Year one (2003) brought the first integration profile « Laboratory Scheduled Workflow ». This profile supports the most common situation: The tests are placed to and performed by a clinical laboratory on specimens collected from a patient correctly identified in the hospital. Year two (2004) is expected to complete the framework with four more profiles: « Laboratory Patient Information Reconciliation » profile provides the messaging to resolve all the exceptional situations: Tests performed on an unidentified patient. Urgent tests performed before the order was generated. Merging of a misidentified patient… « Laboratory Point Of Care Testing » supports specimen testing on the point of care or on the patient’s bedside, by the care unit staff, under the overall supervision of a clinical laboratory. « Laboratory Device Automation » describes the messaging between the laboratory automation manager and all the automated devices (analyzers, robotic decappers, centrifuges, conveyors, aliquoters, …). « Laboratory Code Set Distribution » enables the various actors to rely on a common dictionary of tests and batteries. Some of these new profiles will be achieved in 2004, some others may need one more cycle.Year one (2003) brought the first integration profile « Laboratory Scheduled Workflow ». This profile supports the most common situation: The tests are placed to and performed by a clinical laboratory on specimens collected from a patient correctly identified in the hospital. Year two (2004) is expected to complete the framework with four more profiles: « Laboratory Patient Information Reconciliation » profile provides the messaging to resolve all the exceptional situations: Tests performed on an unidentified patient. Urgent tests performed before the order was generated. Merging of a misidentified patient… « Laboratory Point Of Care Testing » supports specimen testing on the point of care or on the patient’s bedside, by the care unit staff, under the overall supervision of a clinical laboratory. « Laboratory Device Automation » describes the messaging between the laboratory automation manager and all the automated devices (analyzers, robotic decappers, centrifuges, conveyors, aliquoters, …). « Laboratory Code Set Distribution » enables the various actors to rely on a common dictionary of tests and batteries. Some of these new profiles will be achieved in 2004, some others may need one more cycle.

34. HIMSS 2005 34 IHE Cardiology 2004-2005

35. HIMSS 2005 35 IHE IT Infrastructure 2004-2005

36. HIMSS 2005 36

37. HIMSS 2005 37 Local & Regional RHIOs Infrastructure and Interoperability Cross-Enterprise Document Sharing (XDS) minimizes clinical data management by the infrastructure. Transparency = Ease of Evolution XDS works with other IHE Integration Profiles: Audit Trail and Node Authentication (ATNA) and Consistent Time (CT) Patient Id Cross-referencing (PIX) Patient Demographics Query (PDQ) In 2005, IHE plans to finish base set of integration profiles to build regional health networks and interoperable EHRs: Security: Identity Management+ Accountability Content Profiles: DICOM, HL7-CDA-R2/CCR, HL7-Lab, PDF. Notification of Document Availability (with XDS document reference)

38. HIMSS 2005 38 IHE: RHIOs’ Interoperability Partner IHE offers a solid technical foundation to establish interoperability for RHIOs. Standards-based, open, multi-vendor, provider-led. Yearly progress, validation testing built in, backed by a proven process. Implementation by many vendors. RHIOs’ technical architects’ needs direct IHE involvement. Policies easier to establish when based on solid IHE Technical Framework, but are beyond IHE’s scope. They remains RHIOs’ responsibility.

39. HIMSS 2005 39 Experience your HIMSS-WideElectronic Health Record

40. HIMSS 2005 40 Thank YouQuestions ?

41. HIMSS 2005 41 Providers and Vendors Working Together to Deliver Interoperable Health Information Systems in the Enterprise and across Care Settings