1 / 75

INTEGRATING THE HEALTHCARE ENTERPISE (IHE) Orientation Workshop

INTEGRATING THE HEALTHCARE ENTERPISE (IHE) Orientation Workshop. International HL7 Interoperability Conference-10 Carlos Guilherme Costa, Product Manager, Alert, IHE US & Eu Connectathon participant Julio Carau, Director, Hospital de Clinicas "Dr. Manuel Quintela", Montevideo, Uruguay.

cliff
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-10 Carlos Guilherme Costa, Product Manager, Alert, IHE US & Eu Connectathon participant Julio Carau, Director,Hospital de Clinicas "Dr. Manuel Quintela", Montevideo, Uruguay

  2. Agenda This Morning: Part 1: THE IHE STANDARDS ADOPTION PROCESS: achieving practical interoperability This Afternoon: Part 2: USERS AND VENDORS WORKING TOGETHER: how can I contribute & benefit from IHE HOW TO USE IHE RESOURCES: hands on experience

  3. Agenda Part 1: THE IHE STANDARDS ADOPTION PROCESS: achieving practical interoperability 3

  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

  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 Regional and National Networks) 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. Radiologysince 1998 PharmacyNEW 2009 Cardiologysince 2004 Pathologysince 2006 Laboratorysince 2004 Eye Caresince 2006 (Healthcare)IT Infrastructuresince 2003 QualityResearch & Public Healthsince 2006 Radiation Oncologysince 2004 Patient Care Devicessince 2005 Patient Care Coordinationsince 2004 The IHE Development Domains 12 Years of Steady Growth 1998 – 2010

  11. International Growth of IHE Switzerland Netherlands Germany Turkey Canada Austria Taiwan France Japan China USA Italy UK Spain 2005 2006 2000 2007 1999 2001 2002 2003 2004 2009 2008 2010 • Local Deployment, National Extensions • Promotional & Live Demonstration Events • Over 300 Organizational Members (all stakeholders) Malaysia Australia 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. 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)

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

  15. Actor Actor Actor The IHE World…. IHETransaction IHETransaction IHE Actor IHE Actor IHETransaction

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

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

  18. 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 Service definition does not result in compatibility “on the wire”. • IHE Integration profiles are supportive of Service Oriented Architecture, but do not “require” use of SOA. IHE is Service Aware ! • Bits have to be compatible on the wire: No way to avoid specifying transaction & content

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

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

  21. 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 Last Connectathon: Chicago, USA, January 11-15, 2010 Bordeaux, France, April 12-16, 2010

  22. http://www.ihe.net/Connectathon/index.cfm

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

  24. IHE Demonstrations: NOT an IHE Connectathon IHE Connectathon is about qualifying “real-world implementations”. Strict process and controlled technical testing activity.  It is the stick ! IHE demonstration is about education and promotion about what some “connectathon tested implementations” can achieve.  It is the carrot ! Implementations participating to an IHE Demonstration are required to have passed an IHE Connectahon. Not all vendors and products are demonstrated. 24

  25. HIMSS Interoperability Showcase

  26. Example: 2010 HIMSS Interoperability Showcase

  27. Implementation Tools (1) Open source implementations are available for XDS, XCA, XCPD, PIX, PDQ, ATNA, CT, and more: Microsoft under codeplex http://ihe.codeplex.com/ NIST under Source Forge http://sourceforge.net/projects/iheos/ HIE-OS under Source Forgehttp://sourceforge.net/projects/hieos/ FHA CONNECT http://www.connectopensource.org More on the next page….. 27

  28. Open source implementations are available for XDS, XCA, XCPD, PIX, PDQ, ATNA, CT, and more, from Open Health Tools: http://www.projects.openhealthtools.org OHT – IHE Profiles (Charter)https://iheprofiles.projects.openhealthtools.org OHT – Open Exchange (Forge) https://openexchange.projects.openhealthtools.org OHT – Model Driven Health Tools (Charter) https://mdht.projects.openhealthtools.org Implementation Tools (2)

  29. Providers and Vendors Working Together to Deliver Interoperable Health Information Systems in the Enterprise and Across Care Settings http://www.ihe.net

  30. 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 documents, and content elements). • Care delivery organizations access patient info through: • Their own local EMR (if they have one) • 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 (may be done in background) • Among them chose to import whole or part in local patient record

  31. 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 • 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.

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

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

  34. IHE Profiles Specifications • Go to: www.ihe.net/Technical_framework • For XDS:Under IT Infrastructure • E.g. IT Infrastructure Technical Framework (XDS.b) • For PIX:Under IT Infrastructure • E.g. IT Infrastructure Technical Framework (PIX, HL7V2) • Or PIXV3 supplement (PIX HL7 V3). • For XDS-MS: Under Patient Care Coordination • E.g. PCC Technical framework (XDS-MS)

  35. The IHE Global Standards Adoption Process First Step: Propose a Use case for Interoperability 35

  36. 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 mapping across other systems’ identifiers for their patients • Optionally, notify domain systems when other systems update identifiers mapping for their patients

  37. Patient Identifier Cross-referencing for MPIValue Proposition • Maintain and linked 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

  38. The IHE Global Standards Adoption Process Second Step: Propose a design and select standards for such an IHE Profile 38

  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 (HL7 2.3.1) • 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. The IHE Global Standards Adoption Process Third Step: Engage implementers for Testing Trial Implementation profile at Connectathons Fourth Step:Based on lessons learned from Connectathons implementers, correct/clarify Profile and Publish as “Final Text” in Domain Technical Framework.  Will be presented in part 2 46

  47. IHE offers a broad collection of Profiles Use Cases addressed are specified in a series of Domain Technical Frameworks (Volume 1) Two broad classes of profiles: Integration (how to move the data) and Content (what the data conveys). A few example of “cross-enterprise” integration and content profiles Complete list on: www.ihe.net/technical_framework 47

  48. Hospital Record 1-Reference to records Clinic Record Specialist Record Index of patients records Clinical IT System Health Info Exchange Clinical Encounter Registering Health Records:IHE-XDS Community Repository ofDocuments Repository ofDocuments

  49. Hospital Record Clinic Record Specialist Record 3-Records Returned 4-Patient data presented to Physician Aggregate Patient Info Index of patients records Clinical IT System HIE 2-Reference to Records for Inquiry Clinical Encounter Access to Shared Records : IHE-XDS Community Repository ofDocuments Repository ofDocuments

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

More Related