=Paper=
{{Paper
|id=None
|storemode=property
|title=Entwurf und Transformationskonzepte für flexible klinische Workflow Modelle
|pdfUrl=https://ceur-ws.org/Vol-581/gvd2010_4_2.pdf
|volume=Vol-581
|dblpUrl=https://dblp.org/rec/conf/gvd/KuhnBSBHF10
}}
==Entwurf und Transformationskonzepte für flexible klinische Workflow Modelle==
https://ceur-ws.org/Vol-581/gvd2010_4_2.pdf
Entwurf und Transformationskonzepte für flexible
klinische Workflow Modelle
Markus Bandt1 Robert Kühn2 Peter Forbrig1
Sebastian Schick1 Ilvio Bruder2 Andreas Heuer1
1
Universität Rostock
{mb, schick, pforbrig, heuer}@informatik.uni-rostock.de
2
IT Science Center Rügen
{kuehn, bruder}@it-science-center.de
Zusammenfassung nen und Verschiebungen notwendig.
Prozesse der realen Welt werden in der Informationstech- Um diese Herausforderungen adäquat umsetzen zu können,
nologie oft in Form von Workflows abgebildet. Besondere werden in diesem Artikel die Aspekte des Entwurfs eines sol-
Anforderungen stellen hierbei hochflexible klinische Prozes- chen Assistenzsystems sowie geeignete Flexibilisierungskon-
se (insbesondere im und um dem OP-Saal) aufgrund von zepte für das Workflow-Management vorgestellt und disku-
Notfällen, Ausfällen, Komplikationen und Verschiebungen tiert. Im folgenden sollen diese Aspekte anhand des Projek-
von Personal, Räumlichkeiten, Geräten und Material dar. tes Perikles (Unterstützung perioperativer klinischer Pro-
Zur Beschreibung solcher Eigenschaften ist eine Workflow- zesse durch kooperierende flexible Workflows und AutoID-
Sprache mit Flexibilisierungskonzepten erforderlich. Darü- Sensorsysteme) vorgestellt werden. Als Modellierungsspra-
ber hinaus stellt sich der Entwurf solcher Workflows mit che dient HOPS (Higher-Order Process Specification), zur
teilweise schwierig zu erfassenden Parametern sehr aufwen- Spezifikation der Workflows wird YAWL (Yet Another Work-
dig und fehlerbehaftet dar. Der Entwurf mittels HOPS und flow Language) genutzt. Auf Basis von YAWL sollen be-
YAWL sowie die Analyse und Umsetzung von adäquaten nötigte Flexibilisierungskonzepte analysiert und umgesetzt
Flexibilisierungskonzepten, im Rahmen des Projektes Peri- werden.
kles, ist Kernthema dieses Artikels. Das Ziel von Perikles ist die Bereitstellung eines workflow-
basierten Assistenzsystems, um das OP-Management zu ent-
Schlüsselwörter lasten und wichtige Aufgaben wie Planung, Koordinierung,
HOPS, YAWL, workflowbasiertes Assistenzsystem, Work- Kommunikation und Überwachung des perioperativen Pro-
flows zesses zu vereinfachen.
1. EINLEITUNG 2. ENTWURF MIT HOPS
Workflow-Management-Methoden sind eine bewährte Mög-
lichkeit Vorgänge der realen Welt informationstechnisch zu
Vorgehensweise. Ein wesentlicher Teil von Perikles, ist
die Aufgabenanalyse, welche sich an dem szenariobasierten
erfassen. Besonders geeignet sind dabei natürlich exakt struk-
Ansatz von Carroll & Rosson [3] orientiert. Ziel der Aufga-
turierte Abläufe, wie bspw. Arbeits- und Geschäftsprozes-
benanalyse ist es, die Arbeitsabläufe im perioperativen Pro-
se in der Industrie. Aber auch in ungenauen, hochdynami-
zess zu verstehen und die beteiligten Akteure bzw. deren
schen und flexiblen Umgebungen, wie dem hier gewählten
Aufgaben zu beobachten. Dies ist wichtig, da der periopera-
Einsatzfeld perioperativer klinischer Prozesse, ist Workflow-
tive Prozess aus sehr vielen komplexen Arbeitsschritten be-
Management geeignet.
steht, bei denen viele Akteure miteinander interagieren. [6]
Im Umfeld eines operativen Zentrums einer Klinik hat man
beschreibt, dass sich Model-based Design (MDB) als Vorge-
es mit komplexen Koordinationsvorgängen zu tun. Dabei
hensweise und HOPS als Modellierungssprache gut für die
spielen das zeitliche sowie räumliche Management von Perso-
Beschreibung von nebenläufigen, kooperierenden Prozessen
nal, Räumen, Geräten und Material eine wesentliche Rolle.
eignet. Die Vorgehensweise und die Beschreibungsmittel der
Dynamische Änderungen der Arbeitsabläufe sind aufgrund
Anforderungsanalyse ist in Abbildung 1 dargestellt. Die lin-
von Notfällen, Ausfällen, unvorhergesehenen Komplikatio-
ke Spalte beschreibt dabei die aktuelle, die rechte Seite die
zukünftige Situation. Der erste Schritt beinhaltet die Be-
schreibung der Ist-Situation (Abbildung 1, links unten) und
wird im Uhrzeigersinn weiter verfeinert. Für die Analyse
werden vor allem Literatur, Interviews und Hospitationen
Das Projekt Perikles wird vom Bundesministerium für Bildung und eingesetzt. Die aktuelle Situation wird mit Hilfe von HOPS-
Forschung (BMBF) unter dem Förderkennzeichen „01S09009“ gefördert. Modellen, Szenarien, Hospitationsprotokollen, etc. beschrie-
ben. Die in diesem Schritt erlangten Erkenntnisse werden
Copyright is held by the author/owner(s). GvDB Workshop’10, danach verallgemeinert, indem man z. B. von den interview-
25.-28.05.2010, Bad Helmstedt, Germany. ten Akteuren bzw. der hospitierten Einrichtung abstrahiert
rer Ordnung und eine ausführliche Beschreibung von HOPS
wird in [5] gegeben.
HOPS ermöglicht es die formal als Prozess beschriebenen
Systeme durch informale Beschreibungen wie z. B. Fotos,
Abbildungen oder andere Texte anzureichern. Die angerei-
cherten Modelle können animiert werden und bilden somit
die Grundlage für die Diskussion mit den an der Analyse
beteiligten Personen. Damit eignet sich HOPS sehr gut zur
Beschreibung der Ist-Situation, da die Prozesse aus verschie-
denen Perspektiven auf einen Sachverhalt modelliert werden
können und deren Integration ausdrücken. Dank der textuel-
len Notation lassen sich leicht Änderungen in den Modellen
vornehmen. In YAWL dagegen muss der Prozess in XML no-
tiert bzw. mit dem verfügbaren Editor grafisch zusammen-
gebaut werden. Das bedeutet einen enormen Mehraufwand
und daher werden die Ist- und Soll-Modelle zuerst in HOPS
entworfen und anschließend in YAWL transformiert.
Abbildung 1: Vorgehensweise und Beschreibungs- Ein einfaches HOPS Beispiel wird in Abbildung 2 gezeigt.
mittel für die Anforderungsanalyse (nach [4]) Dort wird der Prozess Telefonieren beschrieben. Das Ver-
halten des Prozesses ist in Zeile 11 festgelegt. Die Operatio-
nen sind in den Zeilen 4–8 definiert worden. Telefonieren
(Abbildung 1, links oben). Ziel ist eine sehr detaillierte Be- besteht aus mehreren Teilprozessen Waehlen, Sprechen und
schreibung des perioperativen Prozesses. Dafür ist ein in- Auflegen (Zeile 12–14). Der Teilprozess Waehlen (Zeile 12)
tensiver Austausch mit den Akteuren aus dem perioperati- besteht aus den Operationen hoererAbnehmen, nummerWaeh-
ven Prozess notwendig, da so Fehler frühestmöglich behoben len und warten. Teilprozess Sprechen (Zeile 13) ist optional
werden können. Der nächste Schritt (Abbildung 1, rechts und wird nur ausgeführt, wenn die Gegenseite abnimmt.
oben) ist die Erstellung von abstrakten Soll-Beschreibungen
des perioperativen Prozesses. Hierfür wird das Ist-Modell in
ein Soll-Modell ( was sein könnte“) überführt. Anschließend
”
wird das entstandene Modell von HOPS in YAWL transfor-
miert (siehe Abschnitt 3). Zusätzlich werden die vorgesehe-
nen Interaktionsmöglichkeiten der Akteure mit dem Assis-
tenzsystem durch Use Cases beschrieben. Der letzte Schritt
ist die Erstellung des Prototypen (Abbildung 1, rechts un-
ten). Dabei wird das im vorherigen Schritt beschriebene Mo-
dell implementiert.
Eine alternative Vorgehensweise zu MDB ist der Model Dri-
ven Architecture (MDA) Ansatz. Anders als MDB verzich- Abbildung 2: HOPS-Prozess Telefonieren
tet der MDA Ansatz auf die konkrete Beschreibung der
Ist-Situation. Aus unserer Sicht ist jedoch dieser Schritt ei-
ner der wichtigsten. Dieser ermöglicht es, vorhandene Kon-
flikte und Schwachstellen aufzudecken, die komplexen Ar- 3. MODELLTRANSFORMATION
beitsschritte zu verstehen und ein korrektes Modell der Ist- VON HOPS NACH YAWL
Situation zu entwerfen.
Wie in Abschnitt 2 beschrieben, eignet sich HOPS sehr gut
HOPS. HOPS ist eine universelle Spezifikationssprache zur für die Spezifikation der Ist- und Soll-Modelle. HOPS selbst
Beschreibung der Interaktion zwischen kooperativen Syste- ist jedoch kein Workflow-Management-System (WfMS). Es
men. Diese werden als Prozesse beschrieben. Ein Prozess P fehlen benötigte Funktionalitäten, wie z. B. eine Ressour-
besteht aus mehreren Komponenten, bei denen es sich um cenverwaltung (für menschliche und nicht-menschliche Res-
eigenständige Prozesse handelt. Diese existieren parallel zu sourcen). Um die in HOPS spezifizierten Prozesse für ein
P und besitzen ein eigenständiges Verhalten. Darüber hin- workflowbasiertes Assistenzsystem nutzen zu können, ist es
aus hat Prozess P mehrere atomare Operationen, mit denen notwendig diese in eine Workflow-Sprache zu überführen. Im
das Verhalten des Systems beschrieben werden kann. Zusätz- Projekt Perikles fiel die Wahl dabei aus unterschiedlichen
lich können Vor- oder Nachbedingungen spezifiziert werden, Gründen auf das WfMS YAWL (siehe Abschnitt 4). Aus-
welche vor oder nach der Ausführung der Operation erfüllt schlaggebend war dabei unter anderem, dass YAWL grund-
sein müssen. Ein Prozess gliedert sich in mehrere Teilpro- sätzlich darauf ausgerichtet ist, Prozesse mit hoher mensch-
zesse auf, welche aus einer Folge von Operationen oder Teil- licher Beteiligung, wie sie z. B. im klinischen Bereich haupt-
prozessen bestehen. Zusätzlich bietet HOPS mehrere tem- sächlich auftreten, zu verwalten und zu steuern. Darüber
porale und strukturelle Operatoren an, welche die Ausfüh- hinaus ist es durch die Open Source Lizenz und die mo-
rungsreihenfolge der Operationen beeinflussen können. So dulare, serviceorientierte Architektur des Systems möglich,
ist es möglich Teilverhalten eines Prozesses zu modellieren gegebenenfalls eigene Erweiterungen zu entwickeln sowie be-
und modular zu einem Gesamtprozess zusammenzusetzen. reits bestehende Systeme an das WfMS anzubinden.
Eine formale Einführung in das Konzept der Prozesse höhe- Um die in HOPS beschriebenen Modelle in YAWL-Schemata
umzuwandeln, wird eine entsprechende Transformationsse- in Abhängigkeit einer Bedingung abzubrechen. Der Bereich
mantik benötigt. Die meisten HOPS-Konstrukte lassen sich kann sich auf eine atomare Task aber auch auf vollständige
dabei unmittelbar in YAWL überführen. Eine Sequenz in Netze beziehen.
HOPS z. B. kann in eine YAWL Sequenz transformiert wer- YAWL bietet neben der Kontrollflussperspektive auch die
den. Problematisch sind jedoch Konstrukte, die nicht direkt Möglichkeit Daten zu modellieren und z.B. für den Kon-
von YAWL unterstützt werden. Dazu gehört z. B. das Kon- trollfluss zu nutzen. Hierfür stehen eine Menge von Stan-
strukt Alternative Aktivitäten“ (in HOPS P = a [] b, ent- dard XML-Datentypen zur Verfügung. Wobei das Typsys-
”
weder Aktivität a oder Aktivität b. YAWL unterstützt die- tem von YAWL XML-Schema verwendet, welches um eigene
ses Konstrukt nicht direkt. Es gibt aber verschiedene Hilfs- Typen erweitert werden kann. Variablen werden entweder ei-
konstruktionen, die ein ähnliches Verhalten aufweisen, je- nem Netz oder einer Task zugeordnet. Diese Zuordnung be-
doch verschiedene Vor- oder Nachteile haben. Für das Pro- schreibt zugleich auch den Sichtbarkeitsbereich der Daten.
blem der alternativen Aktivitäten wurden in YAWL ver- Task-Variablen sind immer als Abbildung von bzw. auf Netz-
schiedene Lösungsmöglichkeiten herausgearbeitet. U. a. kön- Variablen unter Verwendung der XML-Anfragesprachen XPa-
nen Benutzereingaben (führe Aktivität a aus) oder Can- th/XQuery beschrieben. Der interne Datentransfer findet
celation Sets (wenn a ausgeführt wurde, wird Aktivität b immer vom Netz zur Task oder umgekehrt statt. Ein Trans-
abgebrochen) verwendet werden. Bei den Benutzeraufgaben fer der Daten von einer Task zu anderen ist nicht erlaubt,
(realisierbar durch Verzweigungen oder den YAWL Worklet- da der Sichtbarkeitsbereich einer Task-Variablen lokal zur
Service) entscheiden die eingegebenen Daten und damit in- Task ist. Der externe Datentransfer muss immer über Task-
direkt der Anwender, wie der weitere Arbeitsablauf ist. Im Variablen durchgeführt werden. Neben dem Datenaustausch
klinischen Bereich sind jedoch zusätzliche Nutzerinteraktio- können die Daten auch für den Kontrollfluss verwendet wer-
nen mit dem System minimal zu halten bzw. häufig nicht den. Hierbei besteht die Möglichkeit ausgehende Kanten eins
erwünscht – die Arbeit am Patienten hat unbedingten Vor- XOR-Splits oder OR-Splits mit Bedingung auf Netz-Variablen
rang. Dieses kleine Beispiel zeigt, dass für einige Teilsche- zu erweitern. Hierbei werden dann entsprechend der Bedin-
mata keine eindeutige Transformation von HOPS in YAWL gungen nur einzelne Kanten aktiviert.
möglich ist. Um eine äquivalente Transformation zu gewähr-
leisten, ist es notwendig einen entsprechenden semantischen Flexibilität . YAWL unterstützt verschiedene Konzepte der
Regelkatalog“ aufzustellen. Mit Hilfe dieser Regeln wird je- Flexibilität. Während der Modellierungsphase kann durch
”
dem HOPS-Konstrukt ein passendes YAWL-Konstrukt zu- Unterspezifikation (hier Late Binding) ein gewisser Grad
geordnet. Bei eventuellen Änderungen im HOPS-Modell sind an Flexibilität erreicht werden. Zur Ausführungszeit kann
diese Änderungen eindeutig auf das YAWL-Schema über- durch Exception-Handling und (eingeschränkt) Jumps Fle-
tragbar. xibilität auf Ebene der Instanzanpassungen erreicht werden.
Late Binding [13] wird in YAWL durch das Konzept der
Worklets [1] umgesetzt. Dabei können über die, in YAWL
4. UMSETZUNG PERIOPERATIVER vorhandene, Web-Service-Schnittstelle zur Laufzeit Worklets
PROZESSE MIT YAWL eingebunden werden. Ein Worklet beschreibt im einfachsten
Fall eine atomare Workflow-Task oder eine vollständige Pro-
YAWL - Formale Grundlagen. Um dem Umstand Rech- zessbeschreibung. Anhand von Regeln kann ein Worklet aus-
nung zu tragen, dass perioperative Prozesse hoch dynamisch gewählt werden. Die Ausführung wird einer speziellen Task
und zum Teil nicht planbar sind, muss das verwendete Work- im Workflow zugeordnet.
flow-Management-System entsprechende Techniken bereit- Das Exception-Handling [13] bietet die Möglichkeit auf uner-
stellen. Hier stellt die flexible Anpassung der modellierten wartete Ereignisse zur Laufzeit zu reagieren und wird durch
Arbeitsabläufe eine besondere Herausforderung dar. YAWL einen vergleichbaren Ansatz wie bei dem vorher vorgestell-
bietet eine Grundlage, mit der einige Flexibilisierungskon- ten Late Binding umgesetzt. Die Exlets [2] bieten neben
zepte bereits unterstützt werden. Für die Modellierung stellt dem Einbinden von Worklets auch die Möglichkeit verschie-
die Sprache 14 Grundelemente bereit. Die Atomic Task bil- dene Ausnahme-Typen zu definieren. Es werden Ereignisse
det einzelne Arbeitsschritte für Menschen oder Maschinen erzeugt, wenn ein Case oder eine Task aufgerufen oder been-
ab. Die Composite Task bindet andere Prozesse ein. Mit Hil- det wird. Anhand eines Regelsystems wird dann entschieden
fe der Condition wird der Status eines Prozesses abgebildet. ob eine Ausnahme eingetreten ist. Um auf die verschiede-
Jedem Arbeitsablauf sind außerdem eine Input- und Output nen Ausnahmen geeignet reagieren zu können, werden ent-
Condition zugeordnet die jeweils den Beginn und das En- sprechende Operationen angeboten. Dabei können einzelne
de eines Prozesses beschreiben. Eine Multiple Instance Task Work-Items oder Cases gelöscht oder angehalten werden.
ermöglicht das gleichzeitige Ausführen mehrerer Instanzen Außerdem kann die Bearbeitung von Work-Items und Ca-
einer Task. Neben den bereits genannten Elementen werden ses wieder fortgesetzt oder neu gestartet werden. Über die
verschiedene Split- und Join- Typen unterstützt. Der AND- Operation Compensate können zum Beispiel Worklets ein-
Split aktiviert alle ausgehenden Kanten und entsprechend gebunden werden, um bereits ausgeführte Arbeitsschritte zu
wird der AND-Join über alle eingehenden Kanten aktiviert. kompensieren.
Ähnlich verhält sich der OR-Split, wobei hier mindestens ei- Das Konzept der Jumps [9] bietet die Möglichkeit zur Lauf-
ne Kante aktiviert wird. Beim OR-Join muss mindestens zeit in den Kontrollfluss der Instanz einzugreifen und so auf
eine der eingehenden Kanten aktiviert sein. Der XOR-Split Ausnahmesituationen zu reagieren. YAWL unterstützt die-
aktiviert genau eine Kante und der XOR-Join wird durch ses Konzept nur zum Teil. Es werden statische Forward-
genau eine Kante aktiviert. Jumps ermöglicht, wobei kein Nachholen“ möglich ist. Ein-
”
Als weiteres Sprachelement bietet die Cancelation Region geschränkte dynamische Forward-Jumps sowie eingeschränk-
die Möglichkeit definierte Bereiche innerhalb eines Prozesses te Backward-Jumps werden auch ermöglicht.
Lösungsansatz. Ein Schwerpunkt der Analysephase be-
stand darin, die spezifischen Anforderungen an Prozess-Fle-
xibilität im klinischen Bereich zu erfassen [8]. Die Arbeit mit
Patienten ist naturgemäß durch hohe Flexibilität gekenn-
zeichnet, da jeder Patient einen individuellen Krankheits-
verlauf aufweist und entsprechend behandelt werden muss.
Schemata, die solche Behandlungsabläufe beschreiben, müs-
sen daher abstrakt und gleichzeitig flexibel sein, um Allge-
meingültigkeit für die jeweiligen therapeutischen Maßnah-
men zu erreichen.
Im Verlauf der Transformation konnten die folgenden Klas-
sen von Flexibilitätskonstrukten identifiziert werden, für die
YAWL keine eindeutige Entsprechung bereitstellt.
Die Klasse der partiellen Ordnung von Aktivitäten
kennzeichnet Prozesse, in denen einige Aktivitäten in festge-
legter Reihenfolge ablaufen müssen, während andere (nicht-
optionale) Aktivitäten an beliebiger Stelle in dieser Sequenz
auftreten können. In YAWL können solche Workflows z. B.
unter Verwendung von parallel geschalteten Cancelation Re- Abbildung 3: YAWL Architektur (abgewandelt aus
gions ausmodelliert werden. Allerdings gewinnt ein entspre- [11])
chendes Workflow-Schema mit zunehmender Anzahl von Ak-
tivitäten (sowohl von festen als auch variablen) bei diesem
Ansatz sehr schnell an Komplexität. Eine mögliche Alter- 5. SYSTEM
native, welche die Komplexität des Schemas nicht erhöht,
bietet in diesem Zusammenhang der kooperierende Einsatz
Anforderungen. Die bisher im Dokument behandelten As-
pekte, vom Entwurf mit HOPS über die Transformation
von deklarativen Systemen wie z. B. DECLARE [12]. YAWL
nach YAWL und die Flexibilitätsanforderungen im klini-
bietet die Möglichkeit, solche Systeme als externe Dienste
schen Bereich bis hin zu entsprechenden Lösungsansätzen
anzubinden.
in YAWL, sind grundlegende Bestandteile des bereits er-
Die Optionalität von Aktivitäten mit Spezifizierung
wähnten Projekts Perikles. Grundsätzlich wird dabei der
zur Laufzeit ist eine weitere Problemstellung, für die es in
Ansatz eines workflowbasierten Assistenzsystems (im kon-
YAWL kein unmittelbares Konstrukt gibt. Allerdings lässt
kreten Fall für die Planung und Koordination von medizi-
sich mit den vorhandenen sprachlichen Mitteln das Konzept
nischen Operationen) verfolgt, welches neben den zugrunde
der Jumps dahingehend realisieren, dass Aktivitäten durch
liegenden Modellen auch die Verwaltung limitierter Ressour-
Auswertung von workflowinternen Daten oder Nutzereinga-
cen, eine integrierte Ereignissverarbeitung sowie den Zugriff
ben übersprungen werden können.
auf externe Datenquellen in die Prozesssteuerung einbindet.
Alternativen von Aktivitäten treten im perioperativen
Insofern unterscheidet sich der Grundgedanke der Prozess-
Kontext häufig auf und können in YAWL mit Hilfe einer
steuerung und -beobachtung von der aktuell üblichen Ver-
Kombination von XOR-Splits und Cancelation Regions um-
fahrensweise im klinischen Bereich, die hauptsächlich darin
gesetzt werden.
besteht, den Behandlungsprozess über die medizinische Do-
Die temporale Synchronisation von Aktivitäten wird
kumentation zu steuern bzw. nachzuvollziehen.
insbesondere dann benötigt, wenn mehrere Aktivitäten un-
Im konkreten Anwendungsszenario im perioperativen Be-
terschiedlicher Benutzer durchgeführt worden sein müssen
reich besteht neben den hohen Anforderungen an die Flexibi-
bevor eine andere Aktivität beginnen kann (z. B. muss so-
lität der Abläufe auch der dringende Bedarf, kontextabhän-
wohl der Patient als auch der OP-Saal auf die Operation
gig große Datenmengen aus unterschiedlichen Datenquellen
vorbereitet worden sein, bevor diese OP beginnen kann).
(z. B. aus Datenbanken oder Diensten als Schnittstellen zu
Dieses Konstrukt lässt sich jedoch durch die Verwendung
externen Systemen) bereit zu stellen. Zum Beispiel erreichen
des Sprachelements AND-Join relativ einfach realisieren.
Patientenakten einen großen Informations- und Datenum-
Der Ausfall von Aktivitäten, welcher zur Modellierungs-
fang und setzen sich unter Umständen aus Befunden meh-
zeit noch nicht spezifiziert werden kann, ist eine weitere Pro-
rerer medizinischer Fachabteilungen (häufig sogar aus ver-
blemklasse, für die es in YAWL derzeit keine direkte Sprach-
schiedenen Einrichtungen) zusammen. Die Integration die-
unterstützung gibt. Mögliche Lösungen stellen hier die Ver-
ser Daten in den Prozess beginnt bei der Modellierung der
wendung von Nutzereingaben oder gezieltes Exception-Han-
Prozesse. Geeignete Beschreibungen der Daten und die Ver-
dling dar.
knüpfung mit den Workflow-Beschreibungen sollen hier eine
Der Abbruch von Aktivitäten ist ein generelles Pro-
bessere Verfügbarkeit der Daten gewährleisten. Ein weiteres
blem im Workflow-Management. Eine mögliche Lösung für
Problem ist die Heterogenität der Datenquellen. Wir schla-
den Einsatz von YAWL bietet hier ebenfalls das Exception-
gen ein allgemeines Konzept für die Integration unterschied-
Handling, welches zusätzlich auch Möglichkeiten zur Kom-
licher Datenquellen im Bereich perioperativer Prozesse vor
pensation bietet.
[10]. Dies erfordert unter anderem eine funktionelle Erweite-
Erwartete und unerwartete Ausnahmen im weitesten
rung der YAWL-Workflow-Engine, welche im folgende kurz
Sinne können in YAWL generell durch Exception-Handling
vorgestellt werden soll.
behandelt und umfassend kompensiert werden. Dies kann
YAWL Architektur. Die Architektur des WfMS YAWL ent-
auch die Verwendung externer Dienste mit einschließen.
spricht weitgehend der in [7] durch die WfMC (Workflow
Management Coalition) vorgestellte Architektur. Als wesent-
liche Änderung zur Architektur der WfMC zeigt sich die fenden Anwendung weiter entwickelt werden. Dazu steht im
konsequent eingeführte service-orientierte Architektur (Ab- nächsten Schritt die Umsetzung der Workflows in einer Si-
bildung 3). Dabei werden alle Komponenten, z. B. Ressour- mulationsumgebung an. Auch hier ist wieder zu überprüfen,
cen aber auch Arbeitslisten für Workflow-Teilnehmer, nur ob die Flexibilisierungskonzepte die realen Bedingungen ab-
über entsprechende Service-Schnittstellen (Custom Services) bilden können. Mit dem entwickelten Assistenzsystem sind
zur Verfügung gestellt. anschließend auch Tests im klinischen Umfeld geplant.
Zugriff auf externe Datenquellen und Dienste. Entspre-
chend der von der WfMC vorgestellten Architektur wer- 7. LITERATUR
den alle für einen Arbeitsablauf benötigten Daten inner-
halb des Workflow-Repositories abgespeichert. Wie in Ab- [1] M. Adams, A. H. M. ter Hofstede, D. Edmond, and
schnitt 4 bereits beschrieben, stehen diese Daten dann als W. M. P. van der Aalst. Worklets: A Service-Oriented
globale Case-Variablen über ein Mapping auch den einzelnen Implementation of Dynamic Flexibility in Workflows.
Tasks bereit. Im vorgestellten Anwendungskontext bringt In R. Meersman and Z. Tari, editors, OTM
diese Vorgehensweise aber verschiedene Probleme mit sich. Conferences (1), volume 4275 of Lecture Notes in
Sollen die Daten innerhalb eines Arbeitsablaufes bereitge- Computer Science, pages 291–308. Springer, 2006.
stellt werden, muss bereits in der Modellierungsphase das [2] M. Adams, A. H. M. ter Hofstede, W. M. P. van der
Modell derart erweitert werden, dass einzelne Tasks hinzu- Aalst, and D. Edmond. Dynamic, Extensible and
gefügt werden, welche nur für den Datenaustausch zwischen Context-Aware Exception Handling for Workflows. In
Workflow-Repository und externen Datenquellen verwendet R. Meersman and Z. Tari, editors, OTM Conferences
werden. Komplexe, unübersichtliche Modelle sind die Folge. (1), volume 4803 of Lecture Notes in Computer
Ein weiteres Problem wird aufgeworfen, wenn die externen Science, pages 95–112. Springer, 2007.
Daten geändert werden und dies nicht an den Arbeitsab- [3] J. M. Carroll, M. B. Rosson, G. Chin, and
lauf propagiert wird. Datenabhängigkeiten des Kontrollflus- J. Koenemann. Requirements Development in
ses haben zum Beispiel inkonsistente Workflow-Zustände zur Scenario-Based Design. IEEE Transactions on
Folge. Änderungen innerhalb einzelner Workflow-Tasks müs- Software Engineering, 24(12):1156–1170, 1998.
sen außerdem in bestimmten Situationen sofort an externe [4] A. Dittmar. Perikles Projektbericht zum Meilenstein
Datenquellen weitergereicht werden. 1, 2009.
Als Lösung schlagen wir vor, Workflow-Variablen an externe [5] A. Dittmar and P. Forbrig. A unified description
Datenquellen zu binden. Datenstrukturen werden mit Hilfe formalism for complex HCI-systems. International
von XML dargestellt. Auf diesen Datenstrukturen sind dann Conference on Software Engineering and Formal
Bedingungen durch XPath/XQuery Ausdrücke beschrieben. Methods, pages 342–351, 2005.
Der Inhalt der externen Datenquellen wird weiterhin als Ko- [6] A. Dittmar and P. Forbrig. Task-based design
pie innerhalb des Workflow-Repositories verwaltet. Neben revisited. In EICS ’09: Proceedings of the 1st ACM
Integritätsbedingungen auf diesen Daten müssen zusätzlich SIGCHI symposium on Engineering interactive
Strategien für die Synchronisation eingeführt werden. Der computing systems, pages 111–116, New York, NY,
Zeitpunkt, wann eine Kopie aktualisiert werden muss oder USA, 2009. ACM.
wann sie an die externe Datenquelle zurückgeschrieben wird [7] D. Hollingsworth. The Workflow Reference Model -
kann hier angegeben werden. Weiterhin müssen geeignete TC00-1003, 1995.
Reaktionen auf verletze Integritätsbedingungen ermöglicht [8] T. Möller. Untersuchung zur Flexibilisierung klinischer
werden. Hier kommen zum Beispiel kompensierende Abläu- Workflows. Diplomarbeit, Universtity of Rostock,
fe, Abbrüche ohne Kompensation, oder auch Alternativen Universtity of Rostock, 2009.
zum Einsatz. Die im Umfeld klinischer Prozesse eingesetz- [9] M. Reichert, P. Dadam, and T. Bauer. Dealing with
ten Datenquellen erstrecken sich über einfache tupelbasierte Forward and Backward Jumps in Workflow
relationale Datenquellen bis hin zu nachrichtenbasierten Da- Management Systems. Software and System Modeling,
tenquellen wie HL7 Datenströmen. 2(1):37–58, 2003.
Die YAWL-Workflow-Engine soll durch einen Custom-Serv-
[10] L. Song. Konzepte für die Integration von
ice mit den vorgestellten Anforderungen erweitert werden.
XML-Schema und Prozessbeschreibungen.
Die bereitgestellten Inferfaces B und X stellen hier eine ge-
Diplomarbeit, Universtity of Rostock, Universtity of
eignete Schnittstelle dar. Die jeweiligen Datenquellen wer-
Rostock, 2009.
den dann über eine entsprechende Plug-In-Architektur inte-
[11] W. M. P. van der Aalst, M. Adams, A. H. M. ter
griert.
Hofstede, M. Pesic, and H. Schonenberg. Flexibility as
a service. In L. C. 0002, C. Liu, Q. Liu, and K. Deng,
6. AUSBLICK editors, DASFAA Workshops, volume 5667 of Lecture
Die im Artikel beschriebenen Arbeiten haben gezeigt, dass Notes in Computer Science, pages 319–333. Springer,
kritische, klinische Prozesse mit ihrer hohen Flexibilität mit- 2009.
tels Workflows umfassend beschreibbar sind. Dabei konn- [12] W. M. P. van der Aalst, M. Pesic, and
te hier ein adäquater Entwurfsprozess definiert und nöti- H. Schonenberg. Declarative workflows: Balancing
ge Transformationen beschrieben werden. Die Umsetzung between flexibility and support. Computer Science -
der Flexibilisierungskonzepte hat gezeigt, dass Workflow- R&D, 23(2):99–113, 2009.
Sprachen prinzipiell geeignet sind, aber dahingehend erwei- [13] B. Weber, S. W. Sadiq, and M. Reichert. Beyond
tert werden müssen. rigidity - dynamic process lifecycle support. Computer
Zukünftig muss der Entwurfsprozess konsequent bis zur lau- Science - R&D, 23(2):47–65, 2009.