750 likes | 758 Views
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.
E N D
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
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
Agenda Part 1: THE IHE STANDARDS ADOPTION PROCESS: achieving practical interoperability 3
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
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
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
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
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
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
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
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
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
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)
Product XYZfrom Vendor T The Product World…..
Actor Actor Actor The IHE World…. IHETransaction IHETransaction IHE Actor IHE Actor IHETransaction
Actor Actor Actor Product XYZfrom Vendor T Mapping IHE to Products IHETransaction IHETransaction IHE Actor IHE Actor IHETransaction
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
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
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
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
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
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
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
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
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)
Providers and Vendors Working Together to Deliver Interoperable Health Information Systems in the Enterprise and Across Care Settings http://www.ihe.net
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
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.
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
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)
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)
The IHE Global Standards Adoption Process First Step: Propose a Use case for Interoperability 35
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
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
The IHE Global Standards Adoption Process Second Step: Propose a design and select standards for such an IHE Profile 38
Patient Identifier Cross-referencing for MPITransaction Diagram
Patient Identifier Cross-referencing for MPIProcess Flow Showing ID Domains & Transactions
B:X456C: ? B:X456C: 2RT Patient Identity Cross References Patient Identifier Cross-referencing for MPI
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)
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)
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)
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)
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
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
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
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
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.