SeHF 2013 | Standardisierte Prozess-Unterstützung mithilfe IHE XDW Profil (Sang-Il Kim)

Post on 29-Nov-2014

1.170 views 0 download

description

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.

Transcript of SeHF 2013 | Standardisierte Prozess-Unterstützung mithilfe IHE XDW Profil (Sang-Il Kim)

Stv. Leiter „eHealth Suisse“ Dr. Sang-Il Kim www.e-health-suisse.ch 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

Agenda

• Problem Definition und Motivation

• Basiskonzept IHE XDW

• IHE Workflow Definition Profiles als Bsp. Prozess-Unterstützung entlang Behandlungspfad

• Bezug eHealth Schweiz, Integrationsmöglichkeiten

2

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

EPD ist „Datensenke“

EPD

keine Prozessunterstützung bisher definiert

3

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

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

4

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

Lösungskonzept von IHE • Dezentrale Workflow-Steuerung

• Aufbauend auf Bestehendem

• Schichtenmodell

• Trennung von Transport, Prozessbeschreibung und Inhalt

5

Cross-Enterprise Document Workflow

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

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

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

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

XDW Framework Diagram

11

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

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

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

14

WORKFLOW DEFINITION PROFILES

15

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

eReferral Workflow Participants

17

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

Use-case: eReferral Process

18

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.

eReferral Workflow Actors

19

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

eReferral Process Flows Between Workflow Participants

20

eReferral Process Evolution

21

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

22

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 related to the scheduling of the visit

Document Label

Example of content

profile eReferral XDS-SD Clinical 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

XDW Process Flow workflow definition

2- Admission of the patient

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 single XDW step

23

XDW Process Flow first task of the process

1-Visit and production of

eReferral

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

Task A: Requested Status 1: Completed

24

XDW Process Flow second task of the process, first status

Task B: Referred Status 1: In Progress

2- Admission of the patient

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

The workflow within the organization is encapsulated into a single XDW step

25

XDW Process Flow second task of the process, second status

5 – Possible notification to the

GP

3- Start of the Consultation

4 – End of the consultation and creation of the clinical report

The workflow within the organization is encapsulated into a single XDW step

Task B: Referred Status 2: Completed

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

26

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

Cross Enterprise Tumor Board Workflow Definition

28

XTB-WD Cross Enterprise Tumor Board Workflow Definition Profile

29

XTM-WD Cross Enterprise

Tele Home Monitoring Workflow Definition

30

XTHM-WD Process Flow

31

Start

Requested (Completed)

Approved Requested

Telemonitoring

Consult Request (Completed)

Analysis and request visit

Analysis and change protocol

(Completed)

Analysis and no actions

(Completed)

Visit Result (Completed)

New Protocol Activation

(Completed) General Clinician

Manager 1

2 3 4

5a

6a

6b

5b

5c

Close

Consult Manager

Care Manager

Analysis and clinical actions

(Completed)

5d

CMPD Community Pharmacy

Medication Prescription and Dispense

(See IHE Pharmacy Technical Framework)

32

33

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

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? •…?

34

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

www. - - .ch

35

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

Screenshots

36

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

37

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

38 38

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

39 39