1. EHR Profiles for Interoperability between DI and Registries Diagnostic Imaging Program Canada Health Infoway Peter Bak Ron Parker Sharon Moore September 29, 2004

2. 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. 3 Overview of Canada Health Infoway…

4. 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. 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 plan envisions having the basic elements of interoperable EHR solutions in place in half of all Canadian jurisdictions by 2010.

6. 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. 7 Infoway’s Strategy Mandate: Develop the key elements of a pan-Canadian interoperable EHR solutions – six year timeframe The Strategy 1. Focus on six Investment Programs 2. Collaborative planning with health ministries and other partners 3. Form strategic alliances with private sector 4. Focus on end-users to gain acceptance 5. 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. 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. 9 EHRS Blueprint Registries Program Client Provider Location Clinical Domain Programs Rx Lab DI Infostrcture Program EHR HIAL

10. 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. 11 Infoway DI Investment Program

12. 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. 13 DI Investment Targets DI investment estimate $220- 280M Assumes a total of 22 to 25 implementations @ $8-12M

14. 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. 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 / distributed PACS 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. 16 Overview of the DI-5 Project…

17. 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. 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. 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. 20 Current thinking…

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

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

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

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

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

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

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

32. 32 IISIG input

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