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

XDW CROSS-ENTERPRISE DOCUMENT WORKFLOW PROFILE 2

XDW Introduction 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 they coordinate their activities:  No central controller, nor scheduler  Decisions are made by the “edges” (providers, doctors, nurses, etc)  XDW coordinates these activities  XDW organizes data used/produced

Necessity:  Digitizing clinical processes (paperless) and enhancing care coordination across organization and boundaries is focus of many regional and national projects  All expect to manage workflows beyond a single organization:  For example: eReferral workflows  Flexible solution for dynamic and adjustable workflow  Clinical, economic, social and organizational impact XDW Problem Statement

XDW Framework:  Operates in a document sharing context by leveraging an available transport of health information (e.g. based on XDS or XDM profiles)  XDW supports a generic workflow management (workflow interoperability engine). It distinguishes and enables specific Workflow Definitions (specified by IHE Profiles or projects) Benefits:  Increases the consistency across workflows, and enables the easy deployment of interoperable workflow management applications where workflow-specific customization is minimized  Facilitates the integration of multi-organizational workflows with the variety of existing workflow management systems used within the participating organizations (peer-to-peer) XDW framework and benefits

XDW Key Design Elements Key XDW design elements:  A common, workflow-independent approach to interoperability  Enables the support of wide range a specific workflow “as content”  Designed to adapt to the complexity of health services delivery  A means to associate documents to a broad range of workflows  Easy to deploy:  no addt’l centralized infrastructure  Scales to regions & nations.  Builds upon the secured sharing of health documents provided by other IHE profiles (e.g. XDS, ATNA, BPPC, etc.)

XDW Framework Diagram

How does XDW Work ? Role of the Workflow Document in XDW:  Format 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  Workflow driven/enforced by the XDW actors, infrastructure provides transparency

Structure of the task in the XDW Workflow Document Workflow Document Structure:  Overall workflow context  Task level Information Task describes an activity that is planned or has been accomplished. Attributes of the task:  Type  Owner  Current Status (created, in-progress, completed, etc.)  References to documents used for input or produced as output  The Task Event History tracks the past Task Events, up to the present state

Structure of the Workflow Document The XDW Workflow Document has 4 parts:  Part 1: elements derived from HL7 CDA standard  Part 2: two elements, patient and author, defined in the XDWSchema with the structure derived from HL7 R-MIM standard  Part 3: elements defined by IHE XDW Profile  Part 4: the element in which is defined by elements derived from the OASIS WS-HumanTask standard.

XDS Infrastructure 1. Sources post workflow document and referenced document to the XDS Infrastructure 2. Consumers search about patient’s workflows 3. Consumers retrieve selected documents from the XDS Infrastructure XDW Flow and Interactions in an XDS scenario Content Creator Content Consumer Content Updater 4. Sources update the workflow document and post possible new referenced documents 5. Consumers search about patient’s workflows 6. Consumers retrieve selected documents from the XDS Infrastructure Content Consumer

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

XDW Process Flow first task of the process Workflow Document task: REQUESTED Status: COMPLETED Author: Mr.Rossi Time: date/time/utc Inputs: -> Lab Report Outputs: -> eReferralDoc1 taskEventHistory TaskEvent: 1 Status: COMPLETED Inputs: -> Lab Report Outputs: -> eReferralDoc1 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

XDW Process Flow second task of the process, first status Workflow Document REQUESTED task: REFERRED Status: INPROGRESS Author: Mr.Brum Time: date/time/utc Inputs: -> eReferralDoc1 Outputs:-> taskEventHistory TaskEvent: 1 Status: INPROGRESS Inputs: -> eReferralDoc1 Outputs:-> 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

XDW Process Flow second task of the process, second status Workflow Document REQUESTED task: REFERRED Status: COMPLETED Author: Mr.Brum Time: date/time/utc Inputs: -> eReferralDoc1 Outputs: -> ClinicalRepDoc2 taskEventHistory TaskEvent: 1 TaskEvent: 2 Status: COMPLETED Inputs: -> eReferralDoc1 Outputs: -> ClinicalRepDoc3 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

XDWEvolution of shared Workflow DocumentXDWEvolution DocumentWorkflowDescriptionWorkflowDescription Use Case: an example of eReferral workflow

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 definition 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 workflow actors involved in the process and their roles

Selected Standards & Systems  XDW Supplement introduces a new “content” profile for a workflow management document  OASIS Human Task for task structure and encoding  HL7 CDA for provider description  HL7 R-MIM for patient and author description  No new transaction are introduced. Leverages existing ITI IHE Profiles:  XDS.b, DSUB, XDR, XDM, BPPC, ATNA  No XDS Metadata extension, but specific rules about XDS Metadata content for the registry entry associated to the XDW Workflow Document

XDW Security/Privacy  XDW relies on the security controls in the underlining transport (e.g. XDS)  In order to adhere to the principle of least privilege organizations want to prevent clinical documents from being replaced by other organizations, while allowing XDW Workflow Documents to be replaced (exception based on classCode)  When a Workflow Description Profile is created, a risk assessment following the Security Cookbook may result in additional security considerations beyond those for the usual clinical report

XDW references  Trial Implementation status  XDW Supplement  Underlying Technical Framework content  ITI XDS.b profile

Conclusion The objective of this profile is:  The standardization of the workflows’ management transactions and the associated workflow tracking structure linked with clinical events  The creation of a document structure able to respond to the present and possibly to extend to future requirements  This profile proposal benefits many domains. So it increases the consistency of workflow interoperability and the skill to solve the requests of the various care areas. It will avoid that different competing solutions are developed in the different IHE domains.

Conclusion The value statement of this profile is:  Provides a platform upon which a wide range of specific workflows can be defined with minimal specification and implementation efforts (e.g., eReferrals Workflow, Prescriptions Workflow, Home Care Workflow).  Increases the consistency of workflow interoperability, and enables the development of interoperable workflow management applications where workflow-specific customization is minimized  Facilitates the integration of multi-organizational workflows with the variety of existing workflow management systems used within the participating organizations (peer-to-peer)

WORKFLOW DEFINITION PROFILES 23

Specific Wokflow Definitions Workflow Definition Profiles (based on XDW)  PCC Domain (Trial Implementation Issued September 2012)  XBeR-WD Cross Enterprise Basic eReferral Workflow Definition Profile  XTHM-WD Cross Enterprise TeleHomeMonitoring Workflow Definition Profile  XTB-WD Cross Enterprise Tumor Board Workflow Definition Profile  Pharmacy Domain (Trial Implementation Issued October 2012)  CMPD Community Medication Prescription and Dispense Profile includes a Workflow Definition First step in Radiology  Radiology Domain (White paper to be issued November 2012)  Cross Enterprise Screening Mammography Workflows Note: XBeR-WD has the potential to serve many clinical domains.

From the use-case to a Workflow Definition Profile 25 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

Cross Enterprise Basic eReferral Workflow Definition XBeR-WD Process Flow 26

eReferral Workflow Tasks 27 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.

eReferral Process Evolution 28 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)

Cross Enterprise Basic eReferral Workflow Definition XBeR-WD Workflow Participants 29

eReferral Workflow Actors 30 Any participant that affects the evolution of the process:  Referral Requester: e.g. GP starting process requesting a referral  Referral Scheduler: e.g. Administrative HCP that schedules the visit  Referral Performer: e.g. a Specialist that starts/completes consultation  Workflow Monitor: e.g. a system that tracks referrals and produces statistics or issues reminders

Process Flows Between Workflow Actors 31

Cross Enterprise Basic eReferral Workflow Definition XBeR-WD Use Cases 32

33 XBeR-WD Basic Process Flow Failing of Requesting and Scheduling

XDW Document and XBeR-WD Basic Process Flow 34

35 Failing of Visit - Failing of Reception Phase

36 XBeR-WD Scheduling Cancellation Process

XBeR-WD Workflow Participants grouping with Workflow Definition Actors 37 Workflow Participant Workflow Definition Actor Referral Requester Referral Requester Actor Referral SchedulerReferral Scheduler Actor Referral PerformerReferral Performer Actor Workflow MonitorWorkflow Monitor Actor

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) 38

Workflow Definition Actors and Options 39 XBeR-WD Workflow Definition Actor optionVolume & Section Referral Requester actor No options selected Referral Scheduler actor Reminder Note OptionPCC TF-1: X Referral Performer actor Process without Scheduling Phase Option PCC TF-1: X Workflow Monitor actor No options selected-

XBeR-WD Grouping with other Profiles 40

XBeR-WD Workflow Definition Actors grouping with XDW Actors 41 Workflow Definition Actor Shall be grouped with: Referral Requester ActorXDW Content Creator XDW Content Consumer XDW Content Updater Referral Scheduler ActorXDW Content Updater XDW Content Consumer Referral Performer ActorXDW Content Updater XDW Content Consumer Workflow Monitor ActorXDW Content Updater XDW Content Consumer

Use Of XDS Metadata by XBeR-WD 42 XDS Metadata Attribute Definition typeCodeFor the Workflow Document which tracks the XBeR-WD process the code for the typeCode shall be: This code will be assigned by LOINC classCodeFor the Workflow Document which tracks the XBeR-WD process the code for the classCode is defined by the XDW profile. See XDW Supplement Section eventCodeListRule 1: An XBeR-WD workflow shall be created with code OPEN and shall remain in this status until it is set to CLOSED. Rule 2: An XBeR-WD workflow should be set to CLOSED when: - one of the tasks has the status FAILED (except for the scheduling cancellation process); or - when you complete the workflow with the Referral Referred task in status COMPLETED. See ITI TF-3: for a general description of this attribute. serviceStartTimeIt is the time at which work began on the first task for this workflow. serviceStopTimeIt is the time at which the status of the overall Workflow is changed from OPEN to CLOSED. It shall be empty when the workflow is still in OPEN state.

XBeR-WD Tasks Specifications 43 Task TypeRequi- rement For task initiation Task Statuses *valid when task initiated Task Property Input Docs OptionOutput Docs Option Referral Requested At XDW doc creation COMPLETED* IN_PROGRESS FAILED Cardinality: 1..1 Removable: no Clinical Input OeReferralR Exception Report C: (If the request is aborted just created) Referral Scheduled When Referral Requested is COMPLETED, or Referral Scheduled is FAILED (in case of scheduling cancellation) COMPLETED* IN_PROGRESS FAILED* Cardinality: 1..n Removable: no * These may change if Workflow Options are selected eReferralRException Report C: (If the visit can’t be scheduled) Reminder Note O * This may change if Workflow Options are selected Referral Referred When Referral Scheduled is COMPLETED IN_PROGRESS* COMPLETED FAILED* Cardinality: 1..1 Removable: no eReferralRException Report C: (if task status is failed) Clinical Report of the visit R

Tasks Specification: Referral Referred 44

Clinical/Other Content Generated in Workflow is Handled Through Referenced Documents 45 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

Cross Enterprise Tumor Board Workflow Definition 46

XTB-WD Cross Enterprise Tumor Board Workflow Definition Profile 47

48

49 XTB-WD Basic Process Flow XTB-WD Failed Process

XTM-WD Cross Enterprise Tele Home Monitoring Workflow Definition 50

XTHM-WD Workflow Participants 51 Workflow Participants Description Care ManagerParticipant responsible for the management of the telemonitored data sent by the patient from his home and of the alarm situations incurring when data go outside of the thresholds General Clinician Manager Participant responsible for the request of activation of the telemonitoring process and producing the telemonitoring Workflow Document Consult Manager Participant responsible for the management of the clinical care process of the patient from the activation of the telemonitoring service with the clinical management of alarm situations reported by the Care Manager

XTHM-WD Process Flow 52

53 XTHM-WD – Normal Monitoring Data Out of Threshold Clinical Action Required

CMPD Community Pharmacy Medication Prescription and Dispense (See IHE Pharmacy Technical Framework) 54

Discussion The value statement of the XDW profile and associated Workflow Definition Profiles is:  Provides a platform upon which a wide range of specific workflows can be defined with minimal specification and implementation efforts (e.g., eReferrals Workflow, Prescriptions Workflow, Home Care Workflow).  Increases the consistency of workflow interoperability, and enables the development of interoperable workflow management applications where workflow-specific customization is minimized  Facilitates the integration of multi-organizational workflows with the variety of existing workflow management systems used within the participating organizations (peer-to-peer)

56