1 / 98

INTEGRATING THE HEALTHCARE ENTERPISE (IHE) Orientation Workshop

INTEGRATING THE HEALTHCARE ENTERPISE (IHE) Orientation Workshop. International HL7 Interoperability Conference-08 Charles Parisot, IHE Europe, GE Healthcare, Buc, France Eric Poiseau, IHE Europe Technical Project Manager, INRIA Rennes. Agenda.

kaoru
Download Presentation

INTEGRATING THE HEALTHCARE ENTERPISE (IHE) Orientation Workshop

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. INTEGRATING THE HEALTHCARE ENTERPISE (IHE)Orientation Workshop International HL7 Interoperability Conference-08 Charles Parisot, IHE Europe, GE Healthcare, Buc, France Eric Poiseau, IHE Europe Technical Project Manager, INRIA Rennes

  2. Agenda 08:30-10:30 THE IHE STANDARDS ADOPTION PROCESS: achieving practical interoperability - Charles Parisot Coffee Break 11:00-12:30 USERS AND VENDORS WORKING TOGETHER: how can I contribute & benefit from IHE – Charles Parisot Lunch Break 13:30-15:00 HOW TO USE IHE RESOURCES: hands on experience– Eric Poiseau

  3. Agenda 08:30-10:30 THE IHE STANDARDS ADOPTION PROCESS: achieving practical interoperability Coffee Break 11:00-12:30 USERS AND VENDORS WORKING TOGETHER: how can I contribute & benefit from IHE – Charles Parisot Lunch Break 13:30-15:00 HOW TO USE IHE RESOURCES: hands on experience – Eric Poiseau

  4. IHE: A Framework for Interoperability A common framework for harmonizing and implementing multiple standards Application-to-application System-to-system Setting-to-setting Enables seamless health information movement within and between enterprises, regions, nations Promotes unbiased selection and coordinated use of established healthcare and IT standards to address specific clinical needs 4

  5. Standards: Necessary…Not Sufficient • Standards are • Foundational - to interoperability and communications • Broad - varying interpretations and implementations • Narrow - may not consider relationships between standards domains • Plentiful - often redundant or disjointed • Focused - standards implementation guides focus only on a single standard IHE provides a standard process for implementing multiple standards

  6. IHE: Connecting Standards to Care • Healthcare professionals work with industry • Coordinate implementation of standards to meet clinical and administrative needs • Clinicians and HIT professionals identify the key interoperability problems they face • Providers and industry work together to develop and make available standards-based solutions • Implementers follow common guidelines in purchasing and integrating effective systems IHE: A forum for agreeing on how to implement standards and processes for making it happen

  7. Testing at Connectathons IHE Demonstrations Develop technical specifications Products with IHE Identify available standards (e.g. HL7, DICOM, IETF, OASIS) Timely access to information Document Use Case Requirements Easy to integrate products Standards Adoption Process

  8. Stakeholder Benefits • Healthcare providers and support staff • Improved workflows • Information whenever and wherever needed • Fewer opportunities for errors • Fewer tedious tasks/repeated work • Improved report turnaround time • Vendors • Align product interoperability with industry consensus • Decreased cost and complexity of interface installation and management • 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

  9. IHE Implementation Strategy • Leverage established standards to allow rapid deployment and plan for futurePragmatic, Ease of Evolution • Enable architectural freedom (patient vs. provider centric, centralized vs. decentralized, scalable (from office to enterprise to IDN to RHIO) Configurationflexibility • Support breakthrough use cases: variety of care settings, care coordination, public health, PHR, EHRInteroperability for broad constituencies IHE: Offers consistent, standards-based record sharing for EHRs and other information systems

  10. Veterinary Endoscopy Pharmacy Growth in IHE Domains • Over 200 vendors involved world-wide • 8 Technical Frameworks • 64 Integration Profiles • Testing at “Connectathons” world-wide • Demonstrations at major conferences world-wide Public Health, Quality and Research Pathology Patient Care Devices (3 profiles) Patient Care Coord. (5 profiles) Radiation Oncology (3 profiles) Eye Care (4 profiles) Laboratory (6 profiles) Cardiology (7 profiles) IT Infrastructure for Healthcare (20 profiles) Radiology (18 profiles) 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008

  11. International Growth of IHE Netherlands Germany Norway Canada Austria Taiwan France Japan Korea China USA Italy UK Spain 2005 2006 2000 2007 1999 2001 2002 2003 2004 2088 Australia • Local Deployment • National Extensions • Promotional & Live Demonstration Events • Funding Pragmatic global standards harmonization + best practices sharing 11

  12. IHE Integration Profiles - Model • Actors in precisely defined roles • Abstracts a specific function of information system • …Executing precisely defined transactions • Using existing standards • ……To solve real world interoperability problems • Specifying Integration Profiles

  13. An Integration Profile : • A Set of Actors • Exchanging Transactions Use casesProcess Flows Actors Transactions • For each transaction: • Std referenced • Options specified • Mapping required IHE Technical FrameworksImplementation Guide for each Integration Profile

  14. Organization of Technical Frameworks • Volume 1: Integration and content Profiles • Describes clinical need and use cases • Identifies : • the actors and transactions or, • content modules • Volume 2+ of Technical Framework • Provides implementation specification for transactions or content modules

  15. Key IHE Concepts • Generalized Systems -> Actors • Interactions between Actors -> Transactions • Problem/Solution Scenarios -> IntegrationProfiles • For each Integration Profile: • the context is described (which real-world problem) • the actors are defined (what systems are involved) • the transactions are defined (what must they do)

  16. 1st key concept: Actor • Represents a set of application roles and responsibilities performed by a system • Always supported by a real-world system • A real-world system may support several IHE Actors Examples: • Order Placer • Order Filler • Patient Admission, Discharge and Transfer (ADT) • Laboratory Automation Manager • Point Of Care Analyzer IHE leaves the definition of products to users and vendors

  17. Order Placer Order Filler New order Order accepted Battery replaced → Placer order management [LAB-1] Acknowledgement Status change Order Placer Order Filler Acknowledgement 2nd key concept: Transaction Example: Transaction LAB-1 « Placer order management » • A set of interactions or messages defined between two Actors for a specific task. • Defines unambiguously how the Actors must cooperate to achieve this task. • Using existing standards such as HL7, DICOM, NCCLS etc. IHE defines transactions at a user-level workflow

  18. Integration Profile … Actor Actor Actor … … … Transaction Transaction Transaction Transaction Transaction Referenced standard (e.g. HL7) Detailed messaging info -------------------------- Roles 3rd key concept: Integration Profile Solves an Integration Problem: A collection of real world information exchange capabilities supported by a set of specific Actors using Standards-based Transactions Examples:  • Enterprise User Authentication • Retrieve Information for Display • Laboratory Scheduled Workflow • Echo Laboratory Workflow • Cross-Enterprise Document Sharing

  19. Product XYZfrom Vendor T The Product World…..

  20. Actor Actor Actor The IHE World…. IHETransaction IHETransaction IHE Actor IHE Actor IHETransaction

  21. Actor Actor Actor Product XYZfrom Vendor T Mapping IHE to Products IHETransaction IHETransaction IHE Actor IHE Actor IHETransaction

  22. IHE and Service Oriented Architectures • SOA is a powerful business driven design methodology • SOA “wraps” interoperability in “services”, but does not solve interoperability: • E.g. Web Services may or may not be used in SOA. IHE Profiles are largely (not always) based on Web Services. • Standardizing Services “offered” along with the “protocols” is 20 years old (Open System Interconnect). Good, but a precise Service definition does not result in compatibility “on the wire”. • IHE Integration profiles are supportive of Service Oriented Architecture, but do not “require” them. Service Aware ! • Bits have to be compatible on the wire: No way to avoid specifying transaction & content

  23. Testing at Connectathons IHE Demonstrations Develop technical specifications Products with IHE Identify available standards (e.g. HL7, DICOM, IETF, OASIS) Timely access to information Document Use Case Requirements Easy to integrate products Standards Adoption Process

  24. IHE Connectathon • Open invitation to vendor and other implementors community • Advanced testing tools (MESA, KUDO, GAZELLE) • Testing organized and supervised by project management team • Thousands of cross-vendor tests performed • Results recorded and published

  25. Vendors do not pass… until an IHE Project Manager attest it ! IHE Connectathons Massive yearly events : 70-80 vendors 250-300 engineers 100-120 systems ….integrated in 5 days Next Connectathon: Wien, Austria, April 20-24, 2008

  26. www.ihe.net/Events/connectathon_results.cfm

  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. Example: 2008 HIMSS Interoperability Showcase Next Demonstration at WoHIT, Copenhagen, Nov 4-6, 2008

  29. Feb 2008 HIMSS Interoperability Showcase Next Demonstration at WoHIT, Copenhagen, Nov 4-6, 2008

  30. Featured this year in the HIMSS Showcase… The 2008 Cast: • 76 connected applications, 32 IHE profiles • Secured Health Information Exchange with broad content • Clinical Scenarios, focusing on clinician and patient access and information sharing across the continuum of care • Population Health, Quality and Research • Privacy and Security • HITSP Interoperability Specifications Health information exchange with patient care devices Personal health record solutions Financial and administrative systems for billing and claims attachments (CAQH/CORE) Expanded distributed demonstration in an HIE format showing connectivity with vendor booths

  31. Providers and Vendors Working Together to Deliver Interoperable Health Information Systems in the Enterprise and Across Care Settings  Health Information Exchange (HIE)or shared EHR http://www.ihe.net

  32. Requirements for an open HIE/EHR • Bring trust and ease of use for healthcare professionals: • Care delivery organizations choose information to share: • Based on patient health status • When they see fit (discharge, end of encounter, etc.) • What information to share (pick relevant types of documents, and content elements). • Care delivery organizations access patient information through: • their own local EMR (if they have one), or • through a shared portal/service otherwise. • When accessing patient info: • Find quickly if relevant information is available or not (single query). • May select among relevant records, which ones to see (may be done in background) • Among those of interest, chose to import in whole or part in its own EMR patient record (responsibility).

  33. Requirements for an open HIE/EHR(2) • Bring trust and privacy to patients: • Only authorized organizations and authenticated healthcare providers may transact in the HIE: • Each node or IT system interfaced is strongly authenticated • Each user shall be authenticated on the edge system (where context is best known) • All traffic trough the infrastructure is encrypted • Patient consent needs multiple choices or levels • Unless opt-in, no data about a specific patient may be shared • Several data sharing policies offered to the patient consent • Each shared record/document is assigned to specific policies (or not shared) at encounter time. • Healthcare providers may only access records/documents compatible with their role.

  34. Categories of Healthcare Communication Services HIEs and Shared EHRs Hospitals Patient and Provider ID Mgt e.g. access to last 6 months historical labs and encounter summaries e.g. get a current list of allergies or med list from a source e.g. order a lab test, track status and receive results Security Document Sharing Dynamic Information Access Workflow Management Source-persisted and attested health records Specific info snapshot provided on demand 2 or more entities synchronize a task

  35. Categories of Healthcare Communication Services HIEs and Shared EHRs Hospitals Patient and Provider ID Mgt Medical Summary (XDS-MS) e.g. access to last 6 months historical labs and encounter summaries e.g. get a current list of allergies or med list from a source e.g. order a lab test, track status and receive results Security Cross-Enterprise Document Sharing (XDS) Document Sharing Dynamic Information Access Workflow Management Source-persisted and attested health records Specific info snapshot provided on demand 2 or more entities synchronize a task Patient Id Cross-Referencing (PIX)

  36. IHE Profiles Specifications • Go to: www.ihe.net/Technical_frameworks • For XDS:Under IT Infrastructure • IT Infrastructure Technical Framework 5.0 (XDS.b) • Until 5.0 published: use XDS.b+XDS Stored Query supplements. • For PIX:Under IT Infrastructure • IT Infrastructure Technical Framework 4.0 or 5.0 (PIX, HL7V2) • Or PIXV3 supplement (PIX HL7 V3). • For XDS-MS: Under Patient Care Coordination • PCC Technical framework 3.0

  37. Patient Identifier Cross-referencing for MPIServices • Allow all enterprise participants to register the identifiers they use for patients in their domain • Participants retain control over their own domain’s patient index(es) • Support domain systems’ queries for other systems’ identifiers for their patients • Optionally, notify domain systems when other systems update identifiers for their patients

  38. Patient Identifier Cross-referencing for MPIValue 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

  39. Patient Identifier Cross-referencing for MPITransaction Diagram

  40. Patient Identifier Cross-referencing for MPIProcess Flow Showing ID Domains & Transactions

  41. B:X456C: ? B:X456C: 2RT Patient Identity Cross References Patient Identifier Cross-referencing for MPI

  42. Patient Identifier Cross-referencing for MPIActors Patient Identity Source • Definition • Assigns patient identities within its own domain • Notifies Patient Identifier Cross-reference Manager of all events related to patient identification (creation, merge, etc.) • Example: Registration (ADT) Actor in IHE Radiology Scheduled Workflow (SWF) Profile • Transaction Supported - Required • Patient Identity Feed [ITI-8] (as sender)

  43. Patient Identifier Cross-referencing for MPIActors Patient Identifier Cross-reference Consumer • Definition • Requires information about patient identifiers in other domains • Requests patient identifier information from Patient Identifier Cross-reference Manager • Transaction Supported - Required • PIX Query [ITI-9] (as sender) • Transaction Supported - Optional • PIX Update Notification [ITI-10] (as receiver)

  44. Patient Identifier Cross-referencing for MPIActors Patient Identifier Cross-reference Manager • Definition • Serves a well-defined set of Patient Identifier Domains • Receives patient identifier information from Patient Identity Source Actors • Manages cross-referencing of identifiers across domains • Transactions Supported - Required • Patient Identity Feed [ITI-8] (as receiver) • PIX Query [ITI-9] (as receiver) • PIX Update Notification [ITI-10] (as sender)

  45. Patient Identifier Cross-referencing for MPIStandards Used: 2 Profiles PIX: HL7 Version 2.5 • 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) PIX V3: HL7 V3 • Leverage Web Services (harmonized WS by IHE Appendix V)

  46. PIX Integration Profile & MPIThe typical view PIX Server acting as MPI Patient Identity Cross-reference Manager Master (A) PatientIdentity Source Patient Identification Domain A (Master Domain) Patient Identification Domain B Patient Identification Domain C

  47. PIX Integration Profile & MPIThe Equivalent IHE Model Linking PIX Server Patient Identity Cross-reference Manager Patient Identification Domain A (Master Domain) Master (A) PatientIdentity Source Patient Identification Domain B Patient Identification Domain C

  48. Hospital Record 1-Reference to records Clinic Record Specialist Record 3-Records Returned 4-Patient data presented to Physician Aggregate Patient Info Index of patients records Clinical IT System Sharing System 2-Reference to Records for Inquiry Clinical Encounter Introduced at HIMSS in 2005 : IHE-XDS Community or sub-network Repository ofDocuments Repository ofDocuments

  49. Health Information Exchanges Interoperability: Cross-enterprise Document Sharing • Cross-Enterprise Document Sharing simplifies clinical data management by defining interoperable infrastructure. Transparency = Ease of Evolution • Patients have guaranteed portability and providers may share information without concerns of aggregation errors.Digital Documents = Patients and providers empowerment • Supports both centralized and decentralized repository architectures. Ease of federation nationally. Flexible privacy, Flexibility of configurations • Addresses the need for a longitudinal healthcare data (health records). Complements to interactive workflow or dynamic access to data.

  50. Cross-Enterprise Document Sharing (XDS) Standards Used • Implemented world-wide by close to 100 vendors/open source. • Adopted in several national & regional projects:Italy, Austria, Canada, USA, Japan, South Africa, France, etc.) HealthcareContent Standards HL7 CDA header extract Electronic BusinessStandards ebXML Registry, SOAP, Web Services … Internet Standards HTML, HTTP,ISO, IETF …

More Related