Swiss eHealth Forum | 8. März 2013 | Referat Dr. Sang-Il Kim Die Präsentation erläutert das neue IHE Integrationsprofil IHE XDW (Cross Enterprise Document Workflow) und zeigt die möglichen Anwendungsfelder und Use Cases. Der Bezug zur eHealth Strategie Schweiz und die Integration in ein elektronisches Patientendossiers werden aufgezeigt. Beispiele von automatisierter Prozessunterstützung entlang von Behandlungspfaden konkretisieren die möglichen Nutzeneffekte.

1. Standardisierte Prozess-Unterstützung
mithilfe IHE XDW Profil
Stv. Leiter Koordinationsorgan „eHealth Suisse“, Bern Swiss eHealth Forum 2013
Dr. Sang-Il Kim, 2013-03-07
Stv. Leiter „eHealth Suisse“
Dr. Sang-Il Kim
www.e-health-suisse.ch 1

2. Agenda
• Problem Definition und Motivation
• Basiskonzept IHE XDW
• IHE Workflow Definition Profiles als Bsp. Prozess-
Unterstützung entlang Behandlungspfad
• Bezug eHealth Schweiz, Integrationsmöglichkeiten
Stv. Leiter „eHealth Suisse“
Dr. Sang-Il Kim
www.e-health-suisse.ch 2

3. EPD ist „Datensenke“
keine Prozessunterstützung
bisher definiert
EPD
Stv. Leiter „eHealth Suisse“
Dr. Sang-Il Kim
www.e-health-suisse.ch 3

4. Problem Metapher „Datensenke“
• Behandelnde arbeiten heute peer-to-peer, z.B. Fax,
email
• Fehlende standardisierte Notifikationsmechanismen
• Nutzenaspekt für Behandelnde wird vor allem in
Prozessunterstützung gesehen
• Integrierte Versorgung entlang eines
Behandlungspfades nur teilweise unterstützt
Stv. Leiter „eHealth Suisse“
Dr. Sang-Il Kim
www.e-health-suisse.ch 4

5. Lösungskonzept von IHE
• Dezentrale Workflow-Steuerung
• Aufbauend auf Bestehendem
• Schichtenmodell
• Trennung von Transport, Prozessbeschreibung und
Inhalt
Stv. Leiter „eHealth Suisse“
Dr. Sang-Il Kim
www.e-health-suisse.ch 5

6. Cross-Enterprise
Document Workflow

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

8. XDW Key Design Elements
Key XDW design elements:
 A common, workflow-independent approach to interoperability
 Enables the support of wide range specific workflows “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.)
8

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

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

11. XDW Framework Diagram
11

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

13. 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 <TaskList> in which is
defined by elements derived from the
OASIS WS-HumanTask standard.
13

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

15. WORKFLOW DEFINITION
PROFILES
15

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

17. eReferral Workflow Participants
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
17

18. Use-case: eReferral Process
 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.
18

19. eReferral Workflow Actors
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
19

20. eReferral Process Flows Between Workflow
Participants
20

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

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

23. XDW Process Flow
workflow definition
2-
Admission of
the patient
1-Visit and production
of eReferral 3- Start of the
Consultation
The workflow within
5 – Possible
notification to the GP 4 – End of the the organization is
consultation and
creation of the clinical
encapsulated into a
report single XDW step
23

24. XDW Process Flow
first task of the process
Workflow Document
task: REQUESTED
Status: COMPLETED
Author: Mr.Rossi
Time: date/time/utc
Inputs:
-> Lab Report
Task A: Requested
Outputs:
Status 1: Completed -> eReferralDoc1
1-Visit and taskEventHistory
production of TaskEvent: 1
eReferral Status:
COMPLETED
Inputs:
-> Lab Report
Outputs:
-> eReferralDoc1
24

25. XDW Process Flow
second task of the process, first status
Workflow Document
REQUESTED
task: REFERRED
Status:
INPROGRESS
2- Author: Mr.Brum
Admission of Time: date/time/utc
the patient
Inputs:
-> eReferralDoc1
Task B: Referred
Outputs:
Status 1: In Progress ->
taskEventHistory
TaskEvent: 1
Status:
The workflow INPROGRESS
within the Inputs:
organization is -> eReferralDoc1
encapsulated into Outputs:
a single XDW step ->
25

26. 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:
Task B: Referred -> eReferralDoc1
Status 2: Completed Outputs:
-> ClinicalRepDoc2
3- Start of the taskEventHistory
Consultation TaskEvent: 1
TaskEvent: 2
Status:
5 – Possible
The workflow COMPLETED
notification to the 4 – End of the within the
GP consultation and organization is
Inputs:
-> eReferralDoc1
creation of the
clinical report encapsulated into Outputs:
a single XDW step ->
ClinicalRepDoc3
26

27. XDW and XBeR-WD References
XDW supplement (started 2011):
 Trial Implementation status
 Good feedback for the first testing session in EU
Connectathon – May 2012
 Successful testing at US Connectathon - Jan 2013
XBeR-WD supplement:
 Trial Implementation status
 Adoption is related to XDW dissemination
 First product announced at RSNA December 2012
27

28. Cross Enterprise Tumor Board
Workflow Definition
28

29. XTB-WD Cross Enterprise Tumor Board
Workflow Definition Profile
29

30. XTM-WD
Cross Enterprise
Tele Home Monitoring
Workflow Definition
30

31. XTHM-WD Process Flow
Care Manager
Start
4
2 3 6b
Telemo New Protocol
Requested nitoring Activation
General Clinician
(Completed) (Completed)
Manager
1 Analysis and
no actions
Approved (Completed)
Requested
Analysis and
clinical actions
Consult Request
(Completed)
(Completed)
Close
Analysis and
change protocol
Visit Result (Completed)
Analysis and
(Completed)
request visit
6a 5b
5c 5d
Consult Manager
5a
31

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

33. 33

34. Integration in eHealth Architektur Schweiz?
• baut auf IHE ITI auf (XDS, ATNA,
BPPC, etc.)
• Wiederverwendung von existierenden
medizinischen Dokumenten
• keine neuen zentralen Komponenten
nötig
• neue Dokumententypen (z.B. Workflow-
Definitionen) und Metadaten nötig
Offene Fragen:
• Berechtigungsthematik?
• über Gemeinschaftsgrenzen hinweg?
• welche Erweiterungen sind nötig an
Primärsystemen und/oder EPD-
Komponenten?
•…?
Stv. Leiter „eHealth Suisse“
Dr. Sang-Il Kim
www.e-health-suisse.ch 34

35. www. - - .ch
Stv. Leiter „eHealth Suisse“
Dr. Sang-Il Kim
www.e-health-suisse.ch 35

36. Screenshots
IHE-Schulung 2013-01-30
S. Kim 36
www.e-health-suisse.ch

37. IHE-Schulung 2013-01-30
S. Kim 37
www.e-health-suisse.ch

38. IHE-Schulung 2013-01-30
S. Kim 38 38
www.e-health-suisse.ch

39. IHE-Schulung 2013-01-30
S. Kim 39
www.e-health-suisse.ch 39

40. Links
• IHE Wiki:
http://wiki.ihe.net/index.php?title=Cross_Enterprise_Workflow
• 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
IHE-Schulung 2013-01-30
S. Kim 40
www.e-health-suisse.ch