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.