1. December, 2012Cross-Organizations eHealth Workflows XDW (Cross-Enterprise Document Workflow) & XBeR-WD (Cross-Enterprise Basic eReferral Workflow Definition) Cross-Organization Workflows in eHealth Part 1 - Overview XDW (Cross-Enterprise Document Workflow) & XBeR-WD (Cross-Enterprise Basic eReferral Workflow Definition) IT Infrastructure and Patient Care Coordination Committees Charles Parisot, GE healthcare Claudio Saccavini, Mauro Zanardini- Arsenàl.IT

2. BACKGROUND ON INTEGRATING THE HEALTHCARE ENTERPRISE 2

3. IHE International Over 500 Member Organizations world-wide Effective multi-stakeholder, multi-country balance www.ihe.net/governance/member_organizations.cfm You may join today ! Free. Even better, organize an IHE initiative in your country and join IHE International ! 3

4. Interoperability: From a problem to a solution 4 Profile Development & testing eHealth Projects 4 Project Specific Extensions IHTSDO IETF Profiling Organizations are well established IHE has a Liaison A with ISO, recognized as SDO by JIC Base Standards

5. 5 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 and tested specifications  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

6. 6 An Alternative ? If your health IT project selects independently its standards: The same requirement addressed with a different mix of standards in different projects Large effort & time needed for detailed project interoperability specifications (12 to 24 months, several man years) Even larger effort to develop custom conformance test tools, and organize own testing efforts (many man years). Initial implementation cost are very high, and on-going costs only increase. No reuse benefit from other eHealth projects.  eHealth Projects shall drive their own requirements but address them by reusing as much as possible robust standards-based profiles or implementation specifications

7. Over the past 13 years, IHE has analyzed hundreds of such “use cases” across 11 domains and responded with over 120 Profile Specifications 7

8. Overview of IHE profiles (1) (see current list at http://www.ihe.net/profiles/ ) http://www.ihe.net/profiles/ 8 - Final Text – Stable - Trial Implementation - Frozen for trial use; corrections expected

9. Overview of IHE profiles (2) (see current list at http://www.ihe.net/profiles/ ) http://www.ihe.net/profiles/ 9 - Final Text – Stable - Trial Implementation - Frozen for trial use; corrections expected

10. Overview of IHE profiles (3) (see current list at http://www.ihe.net/profiles/ ) http://www.ihe.net/profiles/ 10 - Final Text – Stable - Trial Implementation - Frozen for trial use; corrections expected

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

12. REQUIREMENTS AND STATE OF THE ART FOR CROSS-ORGANIZATION WORKFLOWS IN EHEALTH 12

13. Multi-organization Workflows in eHealth (1) Business Use Case: Coordinate the activities and associated tasks related to patient-centric workflows in a multi-organizational environment. Business Actors: Health Professionals/GPs, various specialized clinics, diagnosis/pharmacies/care support organizations, acute care hospitals, etc. Key Requirements:  Focus should be “workflows” between the participating organizations  Keep workflows within the organizations unconstrained  Decentralize workflow decisions to be largely made by the health professionals within each collaborating organizations  Workflow to be patient centric, influence how workflows unfold  Support decentralized workflow control  Ensure flexible workflow deployment, with participating organizations joining and leaving (clinically and technically)  The definition of specific workflows need to scale to 1000’s of workflows & workflow variants

14. Multi-organization Workflows in eHealth (2) Current State of the Art: Mostly failures. Heavy deployment, one workflow at a time (e.g. lab orders to a specific lab, ePrescription). Typical Approach: Creates a central workflow hub, where the workflow is defined and managed. Participating organizations manage their participation either manually (e.g. web browser) or through scripted messages (e.g. HL7 V2). Key Issues:  Requires co-deployment of central hub and custom interfacing of each participating organizations  Challenged by health professionals in the collaborating organizations, where exceptions are difficult to address  Patients influence is generally excluded  Centralized workflow control, creates complex consensus  Workflow deployment is one workflow at a time and very slow (5-15 years). Silo approach. No scaling to other workflows.

15. INTRODUCING IHE PROFILES FOR CROSS-ENTERPRISE WORKFLOWS IN EHEALTH 15

16. Outline  High level description of a clinical process that can be tracked and managed using XDW approach.  Use of an instrument (Workflow Document) in a common scenario such as Referral Process  Overview on a Workflow Definition profile and explanation of its relationship with XDW  Definition of simple guidelines to fit process rules into a Workflow Definition profile. 16

17. Use-case: eReferral Process 17  a physician requests a specialist’s consultation for the patient;  the patient schedules a visit at the out-patient center of a hopsital;  the patient visits the specialist for a consultation which may span one or more visits;  the specialist at the out-patient center of a hopsital completes the consultation and produces a report;  The referring physician reviews the specialist’s report. visit;  Flexible solution for dynamic and adjustable workflow  Clinical, economic, social and organizational impact

18. Approach of the XDW Profile multi-organizational to manage and track the tasks related to patient-centric workflows The Cross-Enterprise Document Workflow (XDW) profile enables participants in a multi-organizational environment to manage and track the tasks related to patient-centric workflows as organizations coordinate their activities:  No central controller (reduce deployment costs)  No central scheduler (the referral scheduler is not known at the start of the process)  Decisions are made by the “edges” (each actor involved can influence the evolution of the workflow)  Information related to the workflow, and documents produced (eReferral document, clinical input, report, oversight) are shared between all actors involved

19. XDW Workflow management infrastructure Workflow Document in XDW:  Specified by XDW is generic across specific workflow definitions  Manages workflow specific status with relationship to input/output documents  Tracking the current/past steps of the workflow and engaged health care entities

20. XDW profile and Workflow Definition profile  Cross Enterprise Document Workflow is:  a framework to manage workflows  a platform upon which a wide range of specific workflows can be defined with minimal specification and implementation efforts  workflow definitions independent  applicable on different document sharing infrastructures  Workflow Definition Profile is:  the definition of a specific clinical process  a set of rules and task definition which characterize the process  the definition of the actors involved in the process and their roles

21. XDW technical approach  The detailed description of the technical approach used by XDW: ftp://ftp.ihe.net/IT_Infrastructure/ITI_EducationalMaterials/CurrentPublished/I HE-XDW_2012-03-06.ppt 21

22. OVERVIEW OF THE BASIC REFERRAL WORKFLOW DEFINITION PROFILE 22

23. From the use-case to a Workflow Definition Profile 23 To define for a Workflow Definition profile:  Actors involved: any participant with specific role that can condition the evolution of the process changing the status of the workflow.  Workflow tasks: a structured action that describes process steps in a simple and standardized way  Allowed evolutions of the process: any workflow path that can be followed in response to specific triggers.  Documents produced during the process: clinical information shared between actors involved

24. eReferral Workflow Participants 24 Any participant that affects the evolution of the process:  GP: acts as Referral Requester, starting process with a referral request  Admin : acts as Referral Scheduler, scheduling the visit  Specialist : acts as Referral Performer, starting and completing the visit  Process Oversight : acts as Workflow Monitor, managing exceptions

25. eReferral Process Flows Between Workflow Participants 25

26. eReferral Workflow Tasks 26 Any simple/complex action performed by an enterprise that needs to be externally “visible”:  Referral Requested: a type of task that tracks the request for a referral process.  Referral Scheduled: a type of task that tracks the taking in charge of the eReferral by an HCP.  Referral Referred: task type that tracks the progress and the completion of the referral.

27. eReferral Process Evolution 27 Identify events that affect the evolution of the process as triggers:  Completion of Request (Task “Referral Requested” in status COMPLETED)  Completion of Scheduling (Task “Referral Scheduled” in status COMPLETED)  Start of the consultation (Task “Referral Referred” in status IN_PROGRESS)  Completion of the Referral (Task “Referral Referred” in status COMPLETED)

28. Clinical/Other Content Generated in Workflow is Handled Through Referenced Documents 28 Any clinical or administrative information conveyed between actors involved:  eReferral: document that describe the referral requested and probably the reason for the request  Clinical Report of the visit: document that tracks results of the specialist's consultation  Exception Report: document produced in case of exception situation  Clinical Input: clinical information tracked to justify the request  Reminder Note: document that tracks information reated to the scheduling of the visit Document Label Example of content profile eReferralXDS-SD Clinical Report of the Visit XDS-SD EDR PPOC XD-LAB ECDR CIRC DRPT APSR Exception ReportXDS-SD Clinical Input XDS-SD PPOC XD-LAB ECDR CIRC DRPT APSR Reminder NoteXDS-SD

29. Workflow Definition Profiles Specific Features: Define alternative paths and rules, and suggest the use of other profiles to define sharing infrastructure and content of shared documents:  Workflow Options: can be selected by a specific project implementation, and allows the profile to be more flexible through different local scenarios. (e.g. the Referral process in a specific implementation can evolve without the scheduling phase. In this case a specific option is selected and rules for transition between tasks are changed. Options selected is not an information conveyed between actors but a “foundation” upon which any actor is created inside the specific project implementation)  Grouping of profiles: used to require:  Specific document sharing infrastructures (e.g. XDW, XDS, XDM, XDR)  Including referenced content in standardized way (e.g. XDS-SD, XD-LAB, XDS-I, XPHR, XDS-MS) 29

30. Referral Request (1) 30 The GP’s software, as Referral Requester, produces the eReferral Document and the related Workflow Document characterized by: eReferral document Workflow Document Ver.1APPROVED Ver.1APPROVED XDS infrastructure  WorkflowStatus=OPEN  Workflow Document includes one task “Referral Referred” with status COMPLETED  The “eReferral” document is attached to the Workflow Document Documents produced are shared by submission to the XDS Infrastructure The eReferral document is now available, along with its related status tracked by the Workflow Document, to all organizations

31. Scheduling the Referral (2) 31 The patient calls for appointment. Administrative person on Hospital System, as Referral Scheduler, checks the status of the eReferral workflow by consuming the Workflow Document :  Visit needs to be scheduled (task “Referral Requested” status COMPLETED) eReferral document Workflow Document Ver.1DEPRECATED Ver.1DEPRECATED  Use the “eReferral” document as input  Set appointment  Add a new task “Referral Scheduled” in status COMPLETED  Updates the Workflow Document The visit can be cancelled by an administrative person, changing the status of the task “Referral Scheduled” to:  IN_PROGRESS: needs to re-schedule the visit (same Provider)  FAILED: eReferral is released by the Health Care Provider Workflow Document Ver.2APPROVED Ver.2APPROVED

32. Start of the Consultation (3) 32 The patient visits the specialist. The specialist’s software, as Referral Performer, checks the status of the workflow.  By consuming the Workflow Document  Sees that the visit has been scheduled (task “Referral Scheduled” in status COMPLETED) eReferral document Workflow Document Ver.1DEPRECATED Ver.1DEPRECATED   Reviews the eReferral document related.   Referral Performer starts the visit process updating the Workflow Document   Adding a new task “Referral Referred” in status IN_PROGRESS Workflow Document Ver.2DEPRECATED Ver.2DEPRECATED Ver.3APPROVED Ver.3APPROVED The visit process is in execution.

33. End of the Consultation (4) 33 The specialist’s software, as Referral Performer, completes the visit process producing the “Clinical Report Of The Visit” and closes the Referral process completing the Referral Referred task: eReferral document Workflow Document Ver.1 DEPRECATE D Workflow Document Ver.1 DEPRECATE D Workflow Document Ver.2 DEPRECATE D Workflow Document Ver.2 DEPRECATE D Clinical Report of the Visit Workflow Document Ver.3 DEPRECATE D Workflow Document Ver.3 DEPRECATE D Workflow Document Ver.4APPROVED Ver.4APPROVED   Set the task “Referral Referred” status to COMPLETED   Close the workflow by setting the WorkflowStatus to CLOSED   Reference the “Clinical Report of the Visit” document as output of the Referral Referred task The Referral process is completed

34. XDW Workflow Encapsulates Organization 2 - Schedule Appointment 3- Start of the Consultation 4 – End of the consultation and creation of the clinical report 5 – Possible notification to the GP 1-Visit and production of eReferral The workflow within the organization is encapsulated into a few selected XDW steps

35. XDW and XBeR-WD References XDW supplement:  Trial Implementation status  Good feedback for the first testing session in EU Connectathon  First testing planned for US Connectathon - Jan 2013 XBeR-WD supplement:  Trial Implementation status  Adoption is related to XDW dissemination  First product announced at RSNA December 2012

36. 36