Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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


Published on

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.

  • Be the first to comment

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

  1. 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-07Stv. Leiter „eHealth Suisse“Dr. Sang-Il 1
  2. 2. Agenda • Problem Definition und Motivation • Basiskonzept IHE XDW • IHE Workflow Definition Profiles als Bsp. Prozess- Unterstützung entlang Behandlungspfad • Bezug eHealth Schweiz, IntegrationsmöglichkeitenStv. Leiter „eHealth Suisse“Dr. Sang-Il 2
  3. 3. EPD ist „Datensenke“ keine Prozessunterstützung bisher definiert EPDStv. Leiter „eHealth Suisse“Dr. Sang-Il 3
  4. 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ütztStv. Leiter „eHealth Suisse“Dr. Sang-Il 4
  5. 5. Lösungskonzept von IHE • Dezentrale Workflow-Steuerung • Aufbauend auf Bestehendem • Schichtenmodell • Trennung von Transport, Prozessbeschreibung und InhaltStv. Leiter „eHealth Suisse“Dr. Sang-Il 5
  6. 6. Cross-EnterpriseDocument Workflow
  7. 7. XDW IntroductionThe Cross-Enterprise Document Workflow (XDW)profile enables participants in a multi-organizationalenvironment to manage and track the tasks relatedto patient-centric workflows as they coordinate theiractivities:  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. 8. XDW Key Design ElementsKey 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. 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. 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. 11. XDW Framework Diagram 11
  12. 12. Structure of the task in the XDW Workflow DocumentWorkflow 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. 13. Structure of the Workflow DocumentThe 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. 14. XDW Flow and Interactions in an XDS scenarioContent ContentCreator 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’sConsumer workflows 4. Sources update the workflow document and post possible new 6. Consumers retrieve referenced selected documents documents from the XDS Infrastructure 14
  16. 16. Specific Wokflow DefinitionsWorkflow 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 DefinitionFirst step in Radiology Radiology Domain (White paper to be issued November 2012)  Cross Enterprise Screening Mammography WorkflowsNote:XBeR-WD has the potential to serve many clinical domains. 16
  17. 17. eReferral Workflow ParticipantsAny 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. 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. 19. eReferral Workflow ActorsAny 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. 20. eReferral Process Flows Between Workflow Participants 20
  21. 21. eReferral Process EvolutionIdentify events that affect theevolution of the process astriggers:Completion of Request(Task “Referral Requested” in statusCOMPLETED)Completion of Scheduling(Task “Referral Scheduled” in statusCOMPLETED)Start of the consultation (Task“Referral Referred” in status IN_PROGRESS)Completion of the Referral(Task “Referral Referred” in statusCOMPLETED) 21
  22. 22. Clinical/Other Content Generated in Workflow is Handled Through Referenced Documents Document ExampleAny clinical or administrative Label of contentinformation conveyed between actors profile eReferral XDS-SDinvolved: 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 specialists 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. 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 – Possiblenotification 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. 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 taskEventHistoryproduction of TaskEvent: 1 eReferral Status: COMPLETED Inputs: -> Lab Report Outputs: -> eReferralDoc1 24
  25. 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: -> eReferralDoc1Task 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. 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 COMPLETEDnotification 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. 27. XDW and XBeR-WD ReferencesXDW supplement (started 2011): Trial Implementation status Good feedback for the first testing session in EU Connectathon – May 2012 Successful testing at US Connectathon - Jan 2013XBeR-WD supplement: Trial Implementation status Adoption is related to XDW dissemination First product announced at RSNA December 2012 27
  28. 28. Cross Enterprise Tumor Board Workflow Definition 28
  29. 29. XTB-WD Cross Enterprise Tumor Board Workflow Definition Profile 29
  30. 30. XTM-WD Cross EnterpriseTele Home Monitoring Workflow Definition 30
  31. 31. XTHM-WD Process Flow Care Manager Start 4 2 3 6b Telemo New Protocol Requested nitoring ActivationGeneral 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. 32. CMPD Community PharmacyMedication Prescription and Dispense(See IHE Pharmacy Technical Framework) 32
  33. 33. 33
  34. 34. Integration in eHealth Architektur Schweiz?• baut auf IHE ITI auf (XDS, ATNA,BPPC, etc.)• Wiederverwendung von existierendenmedizinischen Dokumenten• keine neuen zentralen Komponentennö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 34
  35. 35. www. - - .chStv. Leiter „eHealth Suisse“Dr. Sang-Il 35
  36. 36. ScreenshotsIHE-Schulung 2013-01-30S. Kim
  37. 37. IHE-Schulung 2013-01-30S. Kim
  38. 38. IHE-Schulung 2013-01-30S. Kim 38
  39. 39. IHE-Schulung 2013-01-30S. Kim 39
  40. 40. Links• IHE Wiki:• detailed description of the technical approach used by XDW: IHE-Schulung 2013-01-30 S. Kim 40