1 / 33

EHR Profiles for Interoperability between DI and Registries Diagnostic Imaging Program

EHR Profiles for Interoperability between DI and Registries Diagnostic Imaging Program Canada Health Infoway. September 29, 2004. Peter Bak Ron Parker Sharon Moore. Agenda. Overview of Canada Health Infoway ( Infoway ) What is Infoway all about?

monte
Download Presentation

EHR Profiles for Interoperability between DI and Registries Diagnostic Imaging Program

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. EHR Profiles for Interoperability between DI and Registries Diagnostic Imaging Program Canada Health Infoway September 29, 2004 Peter Bak Ron Parker Sharon Moore

  2. Agenda • Overview of Canada Health Infoway (Infoway) • What is Infoway all about? • What is the DI Program within Infoway? • Overview of DI-5 Project: EHR Interoperability Profiles for DI-r • Problem Statement • Solution Proposal • Deliverables • Current thinking • Jurisdictional EIP • Cross-jurisdictional EIP • IISIG input • Discuss existing initiatives / alignment with this project • Discuss how IISIG can contribute to the process/solution

  3. Overview of Canada Health Infoway…

  4. About Infoway • Infoway was created in response to a commitment of Canada's First Ministers to "work together to strengthen a Canada-wide health infostructure to improve quality, access and timeliness of health care for Canadians." • Infoway is an independent, not-for-profit corporation. Our members are the deputy ministers of health from across Canada. • Infoway now has $1.1 billion in investment capital. The Government of Canada allocated an initial $500 million in 2001, and provided an additional $600 million following the 2003 First Ministers' Accord on Health Care Renewal.

  5. About Infoway cont… • Infoway is a strategic investor. Our priority is interoperable electronic health record (EHR) solutions and related telehealth development. • Our business is investing with partners to develop, replicate and deploy robust, reusable interoperable EHR solutions faster, better and more cost effectively than any of our partners can do alone. • Once investment decisions are made, our partners lead the development, implementation and deployment of the EHR solutions. • Infoway’s planenvisions having the basic elements of interoperable EHR solutions in place in half of all Canadian jurisdictions by 2010.

  6. Infoway’s Mission and Vision Infoway’s mission is to foster and accelerate the development and adoption of electronic health information systems with compatible standards and communications technologies on a pan-Canadian basis, with tangible benefits to Canadians. Infoway will build on existing initiatives and pursue collaborative relationships in pursuit of our mission. Our vision is a high-quality, sustainable and effective Canadian health care system supported by an infostructure that provides residents of Canada and their health care providers timely, appropriate and secure access to the right information when and where they enter into the health care system. Respect for privacy is fundamental to this vision.

  7. Infoway’s Strategy Mandate: Develop the key elements of a pan-Canadian interoperable EHR solutions – six year timeframe The Strategy • Focus on six Investment Programs • Collaborative planning with health ministries and other partners • Form strategic alliances with private sector • Focus on end-users to gain acceptance • Public sector sponsors with investment in projects Infoway’s Investing Philosophy • Accelerate the development of EHRS involves breaking new ground • Reduce costs and overall risk; accelerate implementation • Adjust strategy to reflect learning and experience

  8. Building Blocks of the EHRS • Registries – applications that serve as the source of truth for patients, physicians and facilities • Laboratory Information Systems (LIS) – applications that collect, manage and distribute laboratory results • Diagnostic Imaging (DI) Systems – applications that collect, manage and distribute diagnostic imaging results • Drug Information Systems (Rx) – applications that manage and track drug prescribing and usage • Infostructure – applications that allow EHR applications to inter-operate and users to access information from anywhere and at anytime i.e. the “glue” of the EHR • Telehealth – applications that allow for distance medicine • Public Health Surveillance – application to monitor exceptional health events

  9. EHRS Blueprint • Infostrcture Program • EHR • HIAL • Clinical Domain Programs • Rx • Lab • DI • Registries Program • Client • Provider • Location

  10. Implementation Strategy Taking a “bottom up” approach • Implement components of the EHR using existing infrastructure • Develop standards to ensure interoperability • Connect the components when they are ready

  11. Infoway DI Investment Program

  12. Infoway Diagnostic Imaging (DI) Program • Mandate • Facilitate the EHR by deploying Diagnostic Imaging domain repositories (DI-r) across Canada • Connect facilities together through the DI-r • Drive “filmless” operation in every facility in the country • Deploy DI-r within half of all Canadian jurisdictions within the next six years • Delivered through five projects, each with a different focus • System Definition: Diagnostic Imaging Repository • A solution that allows “view-only” access to DI images and reports (“results”) by physicians from any location and regardless of where the exam was completed • A PACS (Picture Archive and Communication System) application shared among hospitals in a jurisdiction with over 1M population, and scalable to over 1.5M exams annually • A PACS application integrated with Hospital Information Systems (HIS), Radiology Information Systems (RIS), Modalities (CT, MRI, X-Ray, etc.) and the Infoway EHRS using interoperability standards

  13. DI Investment Targets • DI investment estimate $220-280M • Assumes a total of 22 to 25 implementations @ $8-12M

  14. DI Architecture Approach • Challenges • To achieve filmless operation in the smaller rural facilities in a cost effective and timely fashion • To allow the sharing of DI results among stakeholders within and across jurisdictions • Approach: “shared system” • Minimize the amount of PACS infrastructure deployed in the smaller facilities by centralizing it at a regional “hub” or the DI-r • Share PACS management resources across the region • Leverage economies of scale to drive down capital and operating costs • Implement “Interoperability” profiles for DI-r

  15. DI Architecture Approach • Single centralized PACS • Single PACS database managed out of a single facility. • No local cache and no local database • Reliant on high bandwidth network • Single vendor / distributedPACS • Centralized primary database and long term archive (DI-r) • Multiple instances of the database and local cache deployed at facilities within the region • Multiple vendor / distributed PACS • Centralized DI-r • Multiple instances of PACS deployed throughout the region. These PACS are from multiple vendors and are connected to the DI-r

  16. Overview of the DI-5 Project…

  17. Problem Statement • Client and provider registries are being considered for replication in several provinces. • In five provinces (NL, NS, NB, SK and MB) one or more registries will be deployed in conjunction with a Provincial DI repository (DI-r). • While the EHRS Blueprint provides the high-level descriptions of the role each component plays, it does not include detailed requirements and specifications on how components will interoperate. • Within the next few months, Infoway will have to provide guidance to the Provinces on how to integrate these components in a standard approach.

  18. Solution Proposal • Develop the required EHR interoperability specifications through a cross-program project, including: • Registries and DI programs • Solution architecture group • Group of external experts • Define the business and technical requirements for integration between DI, registries and EHR users • Identify and scope the standards development effort of creating the messages required to meet these requirements • Promote adoption by IHE

  19. Deliverables • EHR Interoperability Profiles • Between DI-r and Client Registry • Between DI-r and Provider Registry • Between DI-r and EHR users • EHR Business Use Cases • Express use cases using standards based methodology e.g. UML as per IHE • EHR Application Role definition (functional requirements) • Identification of solution models • Includes DI Repository, client and provider registries • Definition of EHR Transactions • Interaction diagrams for EHR Transactions

  20. Current thinking…

  21. Jurisdictional EIP • Following the IHE Cross Enterprise Document Sharing (XDS) Profile nomenclature… …a jurisdiction is defined by • A single affinity domain • A single document registry (preferred) • One or more document repositories • Multiple document sources • Multiple document consumers

  22. Jurisdictional EIP • Based on IHE Cross Enterprise Document Sharing (XDS) Profile • “Document Repository” – hosts DI images and reports • DI-r • Expected to be based on a PACS application • “Document Registry” – index of documents = EHR Directory • Eventually become the “registry” for all EHR “documents”: Lab results, Rx, etc. • For DI, includes images, reports and orders • “Document Source” • RIS or Voice Recognition system provide reports • Modalities, but more likely a PACS, provide images • XDS assumes a normalized PID is available at the document source. However, in Canada… • … we wish to limit the number of Patient ID Consumers that interact with the Client Registries • … most CR implementations will NOT provide a UPI to consumer systems • … we need a variation to the current XDS profile!

  23. Jurisdictional EIP • XDS does not prescribe the service for delivery of “documents” • XDS notifies consumer of document type • Up to implementation model to define the delivery method of the document e.g. transfer syntax for images • Current information distribution solutions are proprietary • Images via proprietary wavelet and streaming techniques • Reports via a multitude of formats: Structured report, CDA, html, etc. … we need to standardize how information is delivered to document consumers

  24. Client Registry (Patient Identity X-Ref Mgr) ADT Patient Identity Source DocumentEntry Dm=C Pid=Pc XDS Document Source XDS Doc Reports XDS Doc Images EIP within a Jurisdiction/Affinity Domain Jd = NL Dm=C Pid=Pd Jd = NL Dm=D2 Pid=P1 Dm=C Pid=Pc Jd = NL Dm=D2 Pid=Pa Jd = NL Dm=D2 Pid=Pz Patient Identification Domain C Patient Identification Domain D2 XDS Document Registry (Patient Identity Consumer) XDS Document Consumer EMR EHR Portal Report (RIS) Images (PACS) Dm=C Pid=Pc Reading Station Dm=D2 Pid=Pd Register Document MRN Document ID (OID) RIS RIS XDS Document Repository PACS?

  25. Client Registry (Patient Identity X-Ref Mgr) ADT Patient Identity Source DocumentEntry Dm=C Pid=Pc XDS Document Source Images Reports XDS Doc XDS Doc EIP within a Jurisdiction/Affinity Domain Jd = NL Dm=C Pid=Pd Jd = NL Dm=D2 Pid=P1 Dm=C Pid=Pc Jd = NL Dm=D2 Pid=Pa Jd = NL Dm=D2 Pid=Pz Patient Identification Domain C Patient Identification Domain D2 XDS Document Registry (Patient Identity Consumer) • Reports: • Could come from the RIS or VR system • Images: • PACS serves as the document source as it may be impractical to have all modalities comply as document sources • PID • Make use of local MRN – do not normalize PID with Client Registry • Need to pass accession # and possibly other #s even though the document registry is OID based XDS Document Consumer EMR EHR Portal Report (RIS) Images (PACS) Dm=C Pid=Pc Reading Station Dm=D2 Pid=Pd Register Document MRN Document ID (OID) RIS RIS XDS Document Repository PACS?

  26. Client Registry (Patient Identity X-Ref Mgr) ADT Patient Identity Source DocumentEntry Dm=C Pid=Pc XDS Document Source Reports Images XDS Doc XDS Doc EIP within a Jurisdiction/Affinity Domain Jd = NL Dm=C Pid=Pd Jd = NL Dm=D2 Pid=P1 Dm=C Pid=Pc Jd = NL Dm=D2 Pid=Pa Jd = NL Dm=D2 Pid=Pz • Reports: • The RIS may be the Document repository for the reports • The PACS may be the Document repository for the reports • Need to consider “actors” specifically for reports (??) • Images: • PACS is the likely candidate to be the repository • Document Registration • As per XDS profile Patient Identification Domain C Patient Identification Domain D2 XDS Document Registry (Patient Identity Consumer) XDS Document Consumer EMR EHR Portal Report (RIS) Images (PACS) Dm=C Pid=Pc Reading Station Dm=D2 Pid=Pd Register Document MRN Document ID (OID) RIS RIS XDS Document Repository PACS?

  27. Client Registry (Patient Identity X-Ref Mgr) ADT Patient Identity Source DocumentEntry Dm=C Pid=Pc XDS Document Source Images Reports XDS Doc XDS Doc EIP within a Jurisdiction/Affinity Domain Jd = NL Dm=C Pid=Pd Jd = NL Dm=D2 Pid=P1 Dm=C Pid=Pc Jd = NL Dm=D2 Pid=Pa Jd = NL Dm=D2 Pid=Pz Patient Identification Domain C Patient Identification Domain D2 XDS Document Registry (Patient Identity Consumer) XDS Document Consumer EMR EHR Portal Report (RIS) Images (PACS) • Serve as a peer to the Client Registry • Maintain x-ref of patient IDs • Respond to document queries with a full list of OIDs and MRNs • CR to Document Registry interface • Could follow IHE PIX Profile actor • May need expansion – looking into this • Access Control • Does the registry need to manage access rights or does this reside with the document consumer to reconcile (with other actors)? • Do we need to support transactions that address access controls? Dm=C Pid=Pc Reading Station Dm=D2 Pid=Pd Register Document MRN Document ID (OID) RIS RIS XDS Document Repository PACS?

  28. Client Registry (Patient Identity X-Ref Mgr) ADT Patient Identity Source DocumentEntry Dm=C Pid=Pc XDS Document Source Images Reports XDS Doc XDS Doc EIP within a Jurisdiction/Affinity Domain Jd = NL Dm=C Pid=Pd Jd = NL Dm=D2 Pid=P1 Dm=C Pid=Pc Jd = NL Dm=D2 Pid=Pa Jd = NL Dm=D2 Pid=Pz Patient Identification Domain C Patient Identification Domain D2 XDS Document Registry (Patient Identity Consumer) • Reading Stations – Document Consumer: • On-demand architectures are proprietary • How do we make use of the Document registry • Does the “PACS” reconcile with the document registry or does the workstation – do we care? • Should we add more meta data in the document registry to support workflow • Hanging protocol resolution • Key image notes • Etc. XDS Document Consumer EMR EHR Portal Report (RIS) Images (PACS) Dm=C Pid=Pc Reading Station Dm=D2 Pid=Pd Register Document MRN Document ID (OID) RIS RIS XDS Document Repository PACS?

  29. Client Registry (Patient Identity X-Ref Mgr) ADT Patient Identity Source DocumentEntry Dm=C Pid=Pc XDS Document Source Images Reports XDS Doc XDS Doc EIP within a Jurisdiction/Affinity Domain Jd = NL Dm=C Pid=Pd Jd = NL Dm=D2 Pid=P1 Dm=C Pid=Pc Jd = NL Dm=D2 Pid=Pa Jd = NL Dm=D2 Pid=Pz Patient Identification Domain C Patient Identification Domain D2 XDS Document Registry (Patient Identity Consumer) XDS Document Consumer EMR EHR Portal • Web Clients – Document Consumer: • Assume local MRN as the ID • Need to respond with multiple MRNs and OIDs – how to modify the transaction specification? • Information Distribution • Do we use WADO? • Do we use JPEG2000 and JPIP? • ?? Report (RIS) Images (PACS) Dm=C Pid=Pc Reading Station Dm=D2 Pid=Pd Register Document MRN Document ID (OID) RIS RIS XDS Document Repository PACS?

  30. Cross-Jurisdictional EIP • Multiple affinity domains • Multiple document registries • Our thinking so far… • Reconciliation of available documents is between document registries • Document consumers do not query every document registry • …. We have not detailed the transaction diagrams for this nor developed the message sets • Challenge (one of many) • How do we deliver documents from a document repository outside of the affinity domain to the diagnostic reading station… • … on-demand architectures require images to be on the local PACS short term storage (cache) • ... do we copy images from one repository to another (not desirable) • … do we stream images directly into the reading stations: how, what standard, will vendors accept this ???

  31. Client Registry (Patient Identity X-Ref Mgr) Client Registry (Patient Identity X-Ref Mgr) Client Registry (Patient Identity X-Ref Mgr) DocumentEntry DocumentEntry DocumentEntry Dm=C Pid=Pc Dm=C Pid=Pc Dm=C Pid=Pc XDS Doc XDS Doc Images Reports Images Images Reports XDS Doc Reports EIP across multiple Jurisdictions/Affinity Domains Dm=C Pid=Pc Dm=C Pid=Pc Dm=C Pid=Pc XDS Document Registry (Patient Identity Consumer) XDS Document Registry (Patient Identity Consumer) XDS Document Registry (Patient Identity Consumer) XDS Document Consumer EMR EHR Portal Register Document MRN Document ID (OID) Register Document MRN Document ID (OID) Register Document MRN Document ID (OID) Dm=D2 Pid=Pd XDS Document Repository XDS Document Repository XDS Document Repository PACS?

  32. IISIG input

  33. IISIG input • Comments from IISIG • Status of HL7 v3 artifacts relevant to this initiative • Is a collaboration between IISIG and this project desirable and possible? • Suggestions for Next Steps

More Related