December, 2012 Cross-Organizations eHealth Workflows

Cross-Organization Workflowsin eHealth

Part 1 - Overview

XDW (Cross-Enterprise Document Workflow) &

XBeR-WD (Cross-Enterprise Basic eReferral Workflow Definition)

IT Infrastructure and Patient Care Coordination CommitteesCharles Parisot, GE healthcare

Claudio Saccavini, Mauro Zanardini- Arsenàl.IT

2

BACKGROUNDON

INTEGRATING THE HEALTHCARE ENTERPRISE

IHE InternationalOver 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

Interoperability: From a problem to a solution

4

Profile Development& testing

eHealth Projects

4

Project Specific ExtensionsIHTSDO

IETF

Profiling Organizations are well establishedIHE has a Liaison A with ISO, recognized as SDO by

JIC

Base Standards

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

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

Over the past 13 years, IHE has analyzed hundreds of such “use cases” across 11 domains and

responded with over 120 Profile Specifications

7

Overview of IHE profiles (1)(see current list at http://www.ihe.net/profiles/ )

8

IHE IT Infrastructure Profiles [ATNA] Audit Trail and Node Authentication [BPPC] Basic Patient Privacy Consents [CT] Consistent Time [XCA] Cross-Community Access [XDM] Cross-enterprise Document Media Interchange [XDR] Cross-enterprise Document Reliable Interchange [XDS] Cross Enterprise Document Sharing [XDS-SD] Cross-enterprise Sharing of Scanned Documents [XUA] Cross-Enterprise User Assertion [EUA] Enterprise User Authentication [MPQ] Multi-Patient Queries [PAM] Patient Administration Management [PDQ] Patient Demographics Query [PIX] Patient Identifier Cross Referencing [PDQv3] Patient Demographics Query HL7 v3 [PIXv3] Patient Identifier Cross-Reference HL7 v3 [PSA] Patient Synchronized Application [PWP] Personnel White Pages [RID] Retrieve Information for Display [XCF] Cross Community Fetch [XCPD] Cross-Community Patient Discovery [XDW] Cross Enterprise Workflow [DEN] Document Encryption [DRR] Document-based Referral Request [DSG] Document Digital Signature [DSUB] Document Metadata Subscription [HPD] Healthcare Provider Directory

[NAV] Notification of Document Availability [RFD] Retrieve Form for Data Capture [SVS] Sharing Value Sets [XPID] XAD-PID Change Management

IHE Anatomic Pathology Profiles [APW] - Anatomic Pathology Workflow [ARPH] - Anatomic Pathology Reporting to Public Health [APSR] - Anatomic Pathology Structured Report

IHE Cardiology Profiles [CATH] - Cardiac Cath Workflow [ECHO] - Echocardiography Workflow [ECG] - Retrieve ECG for Display [ED] - Evidence Documents [STRESS] - Stress Testing Workflow [DRPT] - Displayable Reports [REWF] - Resting ECG Workflow [IEO] - Image-Enabled Office Workflow [CIRC] - Cardiac Imaging Report Content

IHE Eyecare Profiles [EYECARE] - Eye Care Workflow [CHG] - Charge Posting [ECED] - Eye Care Evidence Documents [ECDR] - Eye Care Displayable Report

- Final Text – Stable- Trial Implementation - Frozen for trial use; corrections expected

Overview of IHE profiles (2)(see current list at http://www.ihe.net/profiles/ )

9

IHE Patient Care Coordination Profiles [MS] Medical Summaries [XPHR] Exchange of Personal Health Record [FSA] Functional Status Assessments [QED] Query for Existing Data [IC] Immunization Content [CM] Care Management [PPOC] Patient Plan of Care [RCG] Request for Clinical Guidance [EDR] Emergency Department Referral

Emergency Department Encounter Profiles [TN] Triage Note [NN] Nursing Note [CTNN] Composite Triage and Nursing Note. [EDPN] ED Physician Note

Antepartum Profiles [APS] Antepartum Summary [APHP] Antepartum History and Physical [APL] Antepartum Laboratory [APE] Antepartum Education

Labor and Delivery Profiles [LDHP] Labor and Delivery History and Physical [LDS] Labor and Delivery Summary [MDS] Maternal Discharge Summary

IHE Patient Care Device Profiles [DEC] Device Enterprise Communication [PIV] Point of Care Infusion Verification [IDCO] Implantable Device Cardiac Observation [RTM] Rosetta Terminology Mapping [ACM] Alarm Communication Management [IPEC] Infusion Pump Event Communication

IHE Pharmacy Profiles

[CMPD] Community Medication Prescription and Dispense [PRE] Pharmacy Prescription Document [PADV] Pharmacy Pharmaceutical Advice Document [DIS] Pharmacy Dispense Document [HMW] Hospital Medication Workflow

IHE Laboratory Profiles

[LTW] - Laboratory Testing Workflow [XD-LAB] - Sharing Laboratory Reports [LDA] - Laboratory Device Automation [LBL] - Laboratory Barcode Labeling [LPOCT] - Laboratory Point Of Care Testing [LCSD] - Laboratory Code Sets Distribution [ILW] - Inter Laboratory Workflow [LAW] - Laboratory Analytical Workflow

- Final Text – Stable- Trial Implementation - Frozen for trial use; corrections expected

Overview of IHE profiles (3)(see current list at http://www.ihe.net/profiles/ )

10

IHE Radiology Profiles Profiles for Workflow

[SWF] Scheduled Workflow [PIR] Patient Information Reconciliation [PWF] Post-Processing Workflow [RWF] Reporting Workflow [IRWF] Import Reconciliation Workflow [MAWF] Mammography Acquisition Workflow.

Profiles for Content [NMI] Nuclear Medicine Image [MAMMO] Mammography Image [ED] Evidence Documents [SINR] Simple Image and Numeric Report [REM] Radiation Exposure Monitoring. [PERF] CT/MR Perfusion Imaging [DIFF] MR Diffusion Imaging

Profiles for Presentation [KIN] Key Image Note [CPI] Consistent Presentation of Images [PGP] Presentation of Grouped Procedures. [FUS] Image Fusion [BIR] Basic Image Review

Profiles for Infrastructure [PDI] Portable Data for Imaging [XDS-I.b] Cross-enterprise Document Sharing for

Imaging.b [TCE] Teaching File and Clinical Trial Export [ARI] Access to Radiology Information

[ATNA] Audit Trail and Node Authentication - Radiology Option

[CHG] Charge Posting

IHE Radiation Oncology Profiles

[BRTO] Basic Radiation Therapy Objects [MMRO] Multimodality Registration for Radiation

Oncology [ARTI] Advanced Radiotherapy Objects Interoperability [TDW] Treatment Delivery Workflow [DCOM] Dose Compositing [ECSI] Enterprise-Centric Scheduling Interoperability

IHE Quality, Research, and Public Health Profiles

[CRD] Clinical Research Document [DSC] Drug Safety Content [EHCP] Early Hearing Care Plan [MCH-BFDrpt] Maternal Child Health-Birth and Fetal

Death Reporting [PRPH-Ca] Physician Reporting to a Public Health

Repository – Cancer Registry [RPE] Retrieve Process for Execution

- Final Text – Stable- Trial Implementation - Frozen for trial use; corrections expected

IHE Region & IHE NationalIHEInternational

11

Standards Adoption Process

Document Use Case RequirementsDocument Use Case Requirements

Identify available standards (e.g. HL7, DICOM, IETF, OASIS)

Identify available standards (e.g. HL7, DICOM, IETF, OASIS)

Develop technical

specifications

Develop technical

specifications

Testing at ConnectathonsTesting at Connectathons

IHE DemonstrationsIHE Demonstrations

Products with IHEProfiles

Products with IHEProfiles

Timely access to informationTimely access to information Easy to integrate

productsEasy to integrate products

REQUIREMENTS ANDSTATE OF THE ART

FORCROSS-ORGANIZATION

WORKFLOWS IN EHEALTH

12

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

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.

INTRODUCING IHE PROFILES FOR

CROSS-ENTERPRISE WORKFLOWS IN EHEALTH

15

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

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

Approach of the XDW ProfileThe 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

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

Pt of Care

Work

XDS Registry & Repositories

Pt of Care

XDW XDW

Document Sharing (e.g. XDS, ATNA, CT)

Workflow Definition Profile A

Workflow

Document

Defines workflow Tasks/states,rules & referenced docs

Tracks progress of Task for a workflow with

reference to input/ouput documents

Sharing of workflow and referenced input/output

documents

Application Application

Ref’d Doc

Ref’d Doc

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

XDW technical approach

The detailed description of the technical approach used by XDW:

ftp://ftp.ihe.net/IT_Infrastructure/ITI_EducationalMaterials/CurrentPublished/IHE-XDW_2012-03-06.ppt

21

OVERVIEW OF THEBASIC REFERRAL

WORKFLOW DEFINITION PROFILE

22

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

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

eReferral Process Flows Between Workflow Participants

25

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.

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)

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

eReferral XDS-SDClinical Report of the Visit

XDS-SD

EDR

PPOC

XD-LAB

ECDR

CIRC

DRPT

APSR 

Exception Report

XDS-SD

Clinical Input

  

 

XDS-SD

PPOC

XD-LAB

ECDR

CIRC

DRPT

APSR

Reminder Note XDS-SD

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

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

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

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

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

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

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

Workflow Document Ver.3APPROVED

The visit process is in execution.

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.1DEPRECATED

Workflow Document Ver.2DEPRECATED

Clinical Report of the Visit

Workflow Document Ver.3DEPRECATED

Workflow Document 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

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 and XBeR-WD ReferencesXDW 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