Entwurf und Transformationskonzepte für flexible klinische Workflow Modelle

Abstract

Zusammenfassung Prozesse der realen Welt werden in der Informationstechnologie oft in Form von Work ows abgebildet. Besondere Anforderungen stellen hierbei hoch exible klinische Prozesse (insbesondere im und um dem OP-Saal) aufgrund von Notfallen, Ausfallen, Komplikationen und Verschiebungen von Personal, Raumlichkeiten, Geraten und Material dar. Zur Beschreibung solcher Eigenschaften ist eine Work owSprache mit Flexibilisierungskonzepten erforderlich. Daruber hinaus stellt sich der Entwurf solcher Work ows mit teilweise schwierig zu erfassenden Parametern sehr aufwendig und fehlerbehaftet dar. Der Entwurf mittels HOPS und YAWL sowie die Analyse und Umsetzung von adaquaten Flexibilisierungskonzepten, im Rahmen des Projektes Perikles, ist Kernthema dieses Artikels. Work ow-Management-Methoden sind eine bewahrte Moglichkeit Vorgange der realen Welt informationstechnisch zu erfassen. Besonders geeignet sind dabei naturlich exakt strukturierte Ablaufe, wie bspw. Arbeits- und Geschaftsprozesse in der Industrie. Aber auch in ungenauen, hochdynamischen und exiblen Umgebungen, wie dem hier gewahlten Einsatzfeld perioperativer klinischer Prozesse, ist Work owManagement geeignet. Im Umfeld eines operativen Zentrums einer Klinik hat man es mit komplexen Koordinationsvorgangen zu tun. Dabei spielen das zeitliche sowie raumliche Management von Personal, Raumen, Geraten und Material eine wesentliche Rolle. Dynamische A nderungen der Arbeitsablaufe sind aufgrund von Notfallen, Ausfallen, unvorhergesehenen Komplikationen und Verschiebungen notwendig. Um diese Herausforderungen adaquat umsetzen zu konnen, werden in diesem Artikel die Aspekte des Entwurfs eines solchen Assistenzsystems sowie geeignete Flexibilisierungskonzepte fur das Work ow-Management vorgestellt und diskutiert. Im folgenden sollen diese Aspekte anhand des Projektes Perikles (Unterstutzung perioperativer klinischer Prozesse durch kooperierende flexible Work ows und AutoIDSensorsysteme) vorgestellt werden. Als Modellierungssprache dient HOPS (Higher-Order Process Speci cation), zur Spezi kation der Work ows wird YAWL (Yet Another Workow Language) genutzt. Auf Basis von YAWL sollen benotigte Flexibilisierungskonzepte analysiert und umgesetzt werden. Das Ziel von Perikles ist die Bereitstellung eines work owbasierten Assistenzsystems, um das OP-Management zu entlasten und wichtige Aufgaben wie Planung, Koordinierung, Kommunikation und U berwachung des perioperativen Prozesses zu vereinfachen.

EINLEITUNG

Das Projekt Perikles wird vom Bundesministerium für Bildung und Forschung (BMBF) unter dem Förderkennzeichen „01S09009“ gefördert. 2.

ENTWURF MIT HOPS

Vorgehensweise. Ein wesentlicher Teil von Perikles, ist die Aufgabenanalyse, welche sich an dem szenariobasierten Ansatz von Carroll & Rosson [ 3 ] orientiert. Ziel der Aufgabenanalyse ist es, die Arbeitsablaufe im perioperativen Prozess zu verstehen und die beteiligten Akteure bzw. deren Aufgaben zu beobachten. Dies ist wichtig, da der perioperative Prozess aus sehr vielen komplexen Arbeitsschritten besteht, bei denen viele Akteure miteinander interagieren. [ 6 ] beschreibt, dass sich Model-based Design (MDB) als Vorgehensweise und HOPS als Modellierungssprache gut fur die Beschreibung von nebenlau gen, kooperierenden Prozessen eignet. Die Vorgehensweise und die Beschreibungsmittel der Anforderungsanalyse ist in Abbildung 1 dargestellt. Die linke Spalte beschreibt dabei die aktuelle, die rechte Seite die zukunftige Situation. Der erste Schritt beinhaltet die Beschreibung der Ist-Situation (Abbildung 1, links unten) und wird im Uhrzeigersinn weiter verfeinert. Fur die Analyse werden vor allem Literatur, Interviews und Hospitationen eingesetzt. Die aktuelle Situation wird mit Hilfe von HOPSModellen, Szenarien, Hospitationsprotokollen, etc. beschrieben. Die in diesem Schritt erlangten Erkenntnisse werden danach verallgemeinert, indem man z. B. von den interviewten Akteuren bzw. der hospitierten Einrichtung abstrahiert Abbildung 1: Vorgehensweise und Beschreibungsmittel fur die Anforderungsanalyse (nach [ 4 ]) (Abbildung 1, links oben). Ziel ist eine sehr detaillierte Beschreibung des perioperativen Prozesses. Dafur ist ein intensiver Austausch mit den Akteuren aus dem perioperativen Prozess notwendig, da so Fehler fruhestmoglich behoben werden konnen. Der nachste Schritt (Abbildung 1, rechts oben) ist die Erstellung von abstrakten Soll-Beschreibungen des perioperativen Prozesses. Hierfur wird das Ist-Modell in ein Soll-Modell ( was sein konnte\) uberfuhrt. Anschlie end " wird das entstandene Modell von HOPS in YAWL transformiert (siehe Abschnitt 3). Zusatzlich werden die vorgesehenen Interaktionsmoglichkeiten der Akteure mit dem Assistenzsystem durch Use Cases beschrieben. Der letzte Schritt ist die Erstellung des Prototypen (Abbildung 1, rechts unten). Dabei wird das im vorherigen Schritt beschriebene Modell implementiert.

Eine alternative Vorgehensweise zu MDB ist der Model Driven Architecture (MDA) Ansatz. Anders als MDB verzichtet der MDA Ansatz auf die konkrete Beschreibung der Ist-Situation. Aus unserer Sicht ist jedoch dieser Schritt einer der wichtigsten. Dieser ermoglicht es, vorhandene Konikte und Schwachstellen aufzudecken, die komplexen Arbeitsschritte zu verstehen und ein korrektes Modell der IstSituation zu entwerfen.

HOPS. HOPS ist eine universelle Spezi kationssprache zur Beschreibung der Interaktion zwischen kooperativen Systemen. Diese werden als Prozesse beschrieben. Ein Prozess P besteht aus mehreren Komponenten, bei denen es sich um eigenstandige Prozesse handelt. Diese existieren parallel zu P und besitzen ein eigenstandiges Verhalten. Daruber hinaus hat Prozess P mehrere atomare Operationen, mit denen das Verhalten des Systems beschrieben werden kann. Zusatzlich konnen Vor- oder Nachbedingungen spezi ziert werden, welche vor oder nach der Ausfuhrung der Operation erfullt sein mussen. Ein Prozess gliedert sich in mehrere Teilprozesse auf, welche aus einer Folge von Operationen oder Teilprozessen bestehen. Zusatzlich bietet HOPS mehrere temporale und strukturelle Operatoren an, welche die Ausfuhrungsreihenfolge der Operationen beein ussen konnen. So ist es moglich Teilverhalten eines Prozesses zu modellieren und modular zu einem Gesamtprozess zusammenzusetzen. Eine formale Einfuhrung in das Konzept der Prozesse hoherer Ordnung und eine ausfuhrliche Beschreibung von HOPS wird in [ 5 ] gegeben.

HOPS ermoglicht es die formal als Prozess beschriebenen Systeme durch informale Beschreibungen wie z. B. Fotos, Abbildungen oder andere Texte anzureichern. Die angereicherten Modelle konnen animiert werden und bilden somit die Grundlage fur die Diskussion mit den an der Analyse beteiligten Personen. Damit eignet sich HOPS sehr gut zur Beschreibung der Ist-Situation, da die Prozesse aus verschiedenen Perspektiven auf einen Sachverhalt modelliert werden konnen und deren Integration ausdrucken. Dank der textuellen Notation lassen sich leicht A nderungen in den Modellen vornehmen. In YAWL dagegen muss der Prozess in XML notiert bzw. mit dem verfugbaren Editor gra sch zusammengebaut werden. Das bedeutet einen enormen Mehraufwand und daher werden die Ist- und Soll-Modelle zuerst in HOPS entworfen und anschlie end in YAWL transformiert. Ein einfaches HOPS Beispiel wird in Abbildung 2 gezeigt. Dort wird der Prozess Telefonieren beschrieben. Das Verhalten des Prozesses ist in Zeile 11 festgelegt. Die Operationen sind in den Zeilen 4{8 de niert worden. Telefonieren besteht aus mehreren Teilprozessen Waehlen, Sprechen und Auflegen (Zeile 12{14). Der Teilprozess Waehlen (Zeile 12) besteht aus den Operationen hoererAbnehmen, nummerWaehlen und warten. Teilprozess Sprechen (Zeile 13) ist optional und wird nur ausgefuhrt, wenn die Gegenseite abnimmt.

Abbildung 2: HOPS-Prozess Telefonieren 3.

MODELLTRANSFORMATION

VON HOPS NACH YAWL

Wie in Abschnitt 2 beschrieben, eignet sich HOPS sehr gut fur die Spezi kation der Ist- und Soll-Modelle. HOPS selbst ist jedoch kein Work ow-Management-System (WfMS). Es fehlen benotigte Funktionalitaten, wie z. B. eine Ressourcenverwaltung (fur menschliche und nicht-menschliche Ressourcen). Um die in HOPS spezi zierten Prozesse fur ein work owbasiertes Assistenzsystem nutzen zu konnen, ist es notwendig diese in eine Work ow-Sprache zu uberfuhren. Im Projekt Perikles el die Wahl dabei aus unterschiedlichen Grunden auf das WfMS YAWL (siehe Abschnitt 4). Ausschlaggebend war dabei unter anderem, dass YAWL grundsatzlich darauf ausgerichtet ist, Prozesse mit hoher menschlicher Beteiligung, wie sie z. B. im klinischen Bereich hauptsachlich auftreten, zu verwalten und zu steuern. Daruber hinaus ist es durch die Open Source Lizenz und die modulare, serviceorientierte Architektur des Systems moglich, gegebenenfalls eigene Erweiterungen zu entwickeln sowie bereits bestehende Systeme an das WfMS anzubinden. Um die in HOPS beschriebenen Modelle in YAWL-Schemata umzuwandeln, wird eine entsprechende Transformationssemantik benotigt. Die meisten HOPS-Konstrukte lassen sich dabei unmittelbar in YAWL uberfuhren. Eine Sequenz in HOPS z. B. kann in eine YAWL Sequenz transformiert werden. Problematisch sind jedoch Konstrukte, die nicht direkt von YAWL unterstutzt werden. Dazu gehort z. B. das Konstrukt Alternative Aktivitaten\ (in HOPS P = a [] b, ent" weder Aktivitat a oder Aktivitat b. YAWL unterstutzt dieses Konstrukt nicht direkt. Es gibt aber verschiedene Hilfskonstruktionen, die ein ahnliches Verhalten aufweisen, jedoch verschiedene Vor- oder Nachteile haben. Fur das Problem der alternativen Aktivitaten wurden in YAWL verschiedene Losungsmoglichkeiten herausgearbeitet. U. a. konnen Benutzereingaben (fuhre Aktivitat a aus) oder Cancelation Sets (wenn a ausgefuhrt wurde, wird Aktivitat b abgebrochen) verwendet werden. Bei den Benutzeraufgaben (realisierbar durch Verzweigungen oder den YAWL WorkletService) entscheiden die eingegebenen Daten und damit indirekt der Anwender, wie der weitere Arbeitsablauf ist. Im klinischen Bereich sind jedoch zusatzliche Nutzerinteraktionen mit dem System minimal zu halten bzw. hau g nicht erwunscht { die Arbeit am Patienten hat unbedingten Vorrang. Dieses kleine Beispiel zeigt, dass fur einige Teilschemata keine eindeutige Transformation von HOPS in YAWL moglich ist. Um eine aquivalente Transformation zu gewahrleisten, ist es notwendig einen entsprechenden semantischen Regelkatalog\ aufzustellen. Mit Hilfe dieser Regeln wird je" dem HOPS-Konstrukt ein passendes YAWL-Konstrukt zugeordnet. Bei eventuellen A nderungen im HOPS-Modell sind diese A nderungen eindeutig auf das YAWL-Schema ubertragbar.

UMSETZUNG PERIOPERATIVER

PROZESSE MIT YAWL

YAWL - Formale Grundlagen. Um dem Umstand Rechnung zu tragen, dass perioperative Prozesse hoch dynamisch und zum Teil nicht planbar sind, muss das verwendete Workow-Management-System entsprechende Techniken bereitstellen. Hier stellt die exible Anpassung der modellierten Arbeitsablaufe eine besondere Herausforderung dar. YAWL bietet eine Grundlage, mit der einige Flexibilisierungskonzepte bereits unterstutzt werden. Fur die Modellierung stellt die Sprache 14 Grundelemente bereit. Die Atomic Task bildet einzelne Arbeitsschritte fur Menschen oder Maschinen ab. Die Composite Task bindet andere Prozesse ein. Mit Hilfe der Condition wird der Status eines Prozesses abgebildet. Jedem Arbeitsablauf sind au erdem eine Input- und Output Condition zugeordnet die jeweils den Beginn und das Ende eines Prozesses beschreiben. Eine Multiple Instance Task ermoglicht das gleichzeitige Ausfuhren mehrerer Instanzen einer Task. Neben den bereits genannten Elementen werden verschiedene Split- und Join- Typen unterstutzt. Der ANDSplit aktiviert alle ausgehenden Kanten und entsprechend wird der AND-Join uber alle eingehenden Kanten aktiviert. A hnlich verhalt sich der OR-Split, wobei hier mindestens eine Kante aktiviert wird. Beim OR-Join muss mindestens eine der eingehenden Kanten aktiviert sein. Der XOR-Split aktiviert genau eine Kante und der XOR-Join wird durch genau eine Kante aktiviert.

Als weiteres Sprachelement bietet die Cancelation Region die Moglichkeit de nierte Bereiche innerhalb eines Prozesses in Abhangigkeit einer Bedingung abzubrechen. Der Bereich kann sich auf eine atomare Task aber auch auf vollstandige Netze beziehen.

YAWL bietet neben der Kontroll ussperspektive auch die Moglichkeit Daten zu modellieren und z.B. fur den Kontroll uss zu nutzen. Hierfur stehen eine Menge von Standard XML-Datentypen zur Verfugung. Wobei das Typsystem von YAWL XML-Schema verwendet, welches um eigene Typen erweitert werden kann. Variablen werden entweder einem Netz oder einer Task zugeordnet. Diese Zuordnung beschreibt zugleich auch den Sichtbarkeitsbereich der Daten. Task-Variablen sind immer als Abbildung von bzw. auf NetzVariablen unter Verwendung der XML-Anfragesprachen XPath/XQuery beschrieben. Der interne Datentransfer ndet immer vom Netz zur Task oder umgekehrt statt. Ein Transfer der Daten von einer Task zu anderen ist nicht erlaubt, da der Sichtbarkeitsbereich einer Task-Variablen lokal zur Task ist. Der externe Datentransfer muss immer uber TaskVariablen durchgefuhrt werden. Neben dem Datenaustausch konnen die Daten auch fur den Kontroll uss verwendet werden. Hierbei besteht die Moglichkeit ausgehende Kanten eins XOR-Splits oder OR-Splits mit Bedingung auf Netz-Variablen zu erweitern. Hierbei werden dann entsprechend der Bedingungen nur einzelne Kanten aktiviert.

Flexibilität . YAWL unterstutzt verschiedene Konzepte der Flexibilitat. Wahrend der Modellierungsphase kann durch Unterspezi kation (hier Late Binding) ein gewisser Grad an Flexibilitat erreicht werden. Zur Ausfuhrungszeit kann durch Exception-Handling und (eingeschrankt) Jumps Flexibilitat auf Ebene der Instanzanpassungen erreicht werden. Late Binding [ 13 ] wird in YAWL durch das Konzept der Worklets [ 1 ] umgesetzt. Dabei konnen uber die, in YAWL vorhandene, Web-Service-Schnittstelle zur Laufzeit Worklets eingebunden werden. Ein Worklet beschreibt im einfachsten Fall eine atomare Work ow-Task oder eine vollstandige Prozessbeschreibung. Anhand von Regeln kann ein Worklet ausgewahlt werden. Die Ausfuhrung wird einer speziellen Task im Work ow zugeordnet.

Das Exception-Handling [ 13 ] bietet die Moglichkeit auf unerwartete Ereignisse zur Laufzeit zu reagieren und wird durch einen vergleichbaren Ansatz wie bei dem vorher vorgestellten Late Binding umgesetzt. Die Exlets [ 2 ] bieten neben dem Einbinden von Worklets auch die Moglichkeit verschiedene Ausnahme-Typen zu de nieren. Es werden Ereignisse erzeugt, wenn ein Case oder eine Task aufgerufen oder beendet wird. Anhand eines Regelsystems wird dann entschieden ob eine Ausnahme eingetreten ist. Um auf die verschiedenen Ausnahmen geeignet reagieren zu konnen, werden entsprechende Operationen angeboten. Dabei konnen einzelne Work-Items oder Cases geloscht oder angehalten werden. Au erdem kann die Bearbeitung von Work-Items und Cases wieder fortgesetzt oder neu gestartet werden. U ber die Operation Compensate konnen zum Beispiel Worklets eingebunden werden, um bereits ausgefuhrte Arbeitsschritte zu kompensieren.

Das Konzept der Jumps [ 9 ] bietet die Moglichkeit zur Laufzeit in den Kontroll uss der Instanz einzugreifen und so auf Ausnahmesituationen zu reagieren. YAWL unterstutzt dieses Konzept nur zum Teil. Es werden statische ForwardJumps ermoglicht, wobei kein Nachholen\ moglich ist. Ein" geschrankte dynamische Forward-Jumps sowie eingeschrankte Backward-Jumps werden auch ermoglicht.

Lösungsansatz. Ein Schwerpunkt der Analysephase bestand darin, die spezi schen Anforderungen an Prozess-Flexibilitat im klinischen Bereich zu erfassen [ 8 ]. Die Arbeit mit Patienten ist naturgema durch hohe Flexibilitat gekennzeichnet, da jeder Patient einen individuellen Krankheitsverlauf aufweist und entsprechend behandelt werden muss. Schemata, die solche Behandlungsablaufe beschreiben, mussen daher abstrakt und gleichzeitig exibel sein, um Allgemeingultigkeit fur die jeweiligen therapeutischen Ma nahmen zu erreichen.

Im Verlauf der Transformation konnten die folgenden Klassen von Flexibilitatskonstrukten identi ziert werden, fur die YAWL keine eindeutige Entsprechung bereitstellt. Die Klasse der partiellen Ordnung von Aktivitaten kennzeichnet Prozesse, in denen einige Aktivitaten in festgelegter Reihenfolge ablaufen mussen, wahrend andere (nichtoptionale) Aktivitaten an beliebiger Stelle in dieser Sequenz auftreten konnen. In YAWL konnen solche Work ows z. B. unter Verwendung von parallel geschalteten Cancelation Regions ausmodelliert werden. Allerdings gewinnt ein entsprechendes Work ow-Schema mit zunehmender Anzahl von Aktivitaten (sowohl von festen als auch variablen) bei diesem Ansatz sehr schnell an Komplexitat. Eine mogliche Alternative, welche die Komplexitat des Schemas nicht erhoht, bietet in diesem Zusammenhang der kooperierende Einsatz von deklarativen Systemen wie z. B. DECLARE [ 12 ]. YAWL bietet die Moglichkeit, solche Systeme als externe Dienste anzubinden.

Die Optionalitat von Aktivitaten mit Spezi zierung zur Laufzeit ist eine weitere Problemstellung, fur die es in YAWL kein unmittelbares Konstrukt gibt. Allerdings lasst sich mit den vorhandenen sprachlichen Mitteln das Konzept der Jumps dahingehend realisieren, dass Aktivitaten durch Auswertung von work owinternen Daten oder Nutzereingaben ubersprungen werden konnen.

Alternativen von Aktivitaten treten im perioperativen Kontext hau g auf und konnen in YAWL mit Hilfe einer Kombination von XOR-Splits und Cancelation Regions umgesetzt werden.

Die temporale Synchronisation von Aktivitaten wird insbesondere dann benotigt, wenn mehrere Aktivitaten unterschiedlicher Benutzer durchgefuhrt worden sein mussen bevor eine andere Aktivitat beginnen kann (z. B. muss sowohl der Patient als auch der OP-Saal auf die Operation vorbereitet worden sein, bevor diese OP beginnen kann). Dieses Konstrukt lasst sich jedoch durch die Verwendung des Sprachelements AND-Join relativ einfach realisieren. Der Ausfall von Aktivitaten, welcher zur Modellierungszeit noch nicht spezi ziert werden kann, ist eine weitere Problemklasse, fur die es in YAWL derzeit keine direkte Sprachunterstutzung gibt. Mogliche Losungen stellen hier die Verwendung von Nutzereingaben oder gezieltes Exception-Handling dar.

Der Abbruch von Aktivitaten ist ein generelles Problem im Work ow-Management. Eine mogliche Losung fur den Einsatz von YAWL bietet hier ebenfalls das ExceptionHandling, welches zusatzlich auch Moglichkeiten zur Kompensation bietet.

Erwartete und unerwartete Ausnahmen im weitesten Sinne konnen in YAWL generell durch Exception-Handling behandelt und umfassend kompensiert werden. Dies kann auch die Verwendung externer Dienste mit einschlie en. Abbildung 3: YAWL Architektur (abgewandelt aus [ 11 ])

5. SYSTEM

Anforderungen. Die bisher im Dokument behandelten Aspekte, vom Entwurf mit HOPS uber die Transformation nach YAWL und die Flexibilitatsanforderungen im klinischen Bereich bis hin zu entsprechenden Losungsansatzen in YAWL, sind grundlegende Bestandteile des bereits erwahnten Projekts Perikles. Grundsatzlich wird dabei der Ansatz eines work owbasierten Assistenzsystems (im konkreten Fall fur die Planung und Koordination von medizinischen Operationen) verfolgt, welches neben den zugrunde liegenden Modellen auch die Verwaltung limitierter Ressourcen, eine integrierte Ereignissverarbeitung sowie den Zugri auf externe Datenquellen in die Prozesssteuerung einbindet. Insofern unterscheidet sich der Grundgedanke der Prozesssteuerung und -beobachtung von der aktuell ublichen Verfahrensweise im klinischen Bereich, die hauptsachlich darin besteht, den Behandlungsprozess uber die medizinische Dokumentation zu steuern bzw. nachzuvollziehen.

Im konkreten Anwendungsszenario im perioperativen Bereich besteht neben den hohen Anforderungen an die Flexibilitat der Ablaufe auch der dringende Bedarf, kontextabhangig gro e Datenmengen aus unterschiedlichen Datenquellen (z. B. aus Datenbanken oder Diensten als Schnittstellen zu externen Systemen) bereit zu stellen. Zum Beispiel erreichen Patientenakten einen gro en Informations- und Datenumfang und setzen sich unter Umstanden aus Befunden mehrerer medizinischer Fachabteilungen (hau g sogar aus verschiedenen Einrichtungen) zusammen. Die Integration dieser Daten in den Prozess beginnt bei der Modellierung der Prozesse. Geeignete Beschreibungen der Daten und die Verknupfung mit den Work ow-Beschreibungen sollen hier eine bessere Verfugbarkeit der Daten gewahrleisten. Ein weiteres Problem ist die Heterogenitat der Datenquellen. Wir schlagen ein allgemeines Konzept fur die Integration unterschiedlicher Datenquellen im Bereich perioperativer Prozesse vor [ 10 ]. Dies erfordert unter anderem eine funktionelle Erweiterung der YAWL-Work ow-Engine, welche im folgende kurz vorgestellt werden soll.

YAWL Architektur. Die Architektur des WfMS YAWL entspricht weitgehend der in [ 7 ] durch die WfMC (Work ow Management Coalition) vorgestellte Architektur. Als wesentliche A nderung zur Architektur der WfMC zeigt sich die konsequent eingefuhrte service-orientierte Architektur (Abbildung 3). Dabei werden alle Komponenten, z. B. Ressourcen aber auch Arbeitslisten fur Work ow-Teilnehmer, nur uber entsprechende Service-Schnittstellen (Custom Services) zur Verfugung gestellt.

AUSBLICK

Die im Artikel beschriebenen Arbeiten haben gezeigt, dass kritische, klinische Prozesse mit ihrer hohen Flexibilitat mittels Work ows umfassend beschreibbar sind. Dabei konnte hier ein adaquater Entwurfsprozess de niert und notige Transformationen beschrieben werden. Die Umsetzung der Flexibilisierungskonzepte hat gezeigt, dass Work owSprachen prinzipiell geeignet sind, aber dahingehend erweitert werden mussen.

Zukunftig muss der Entwurfsprozess konsequent bis zur laufenden Anwendung weiter entwickelt werden. Dazu steht im nachsten Schritt die Umsetzung der Work ows in einer Simulationsumgebung an. Auch hier ist wieder zu uberprufen, ob die Flexibilisierungskonzepte die realen Bedingungen abbilden konnen. Mit dem entwickelten Assistenzsystem sind anschlie end auch Tests im klinischen Umfeld geplant. 7.

LITERATUR

References

[1] M. Adams , A. H. M. ter Hofstede , D. Edmond , and W. M. P. van der Aalst. Worklets: A Service-Oriented Implementation of Dynamic Flexibility in Work ows . In R. Meersman and Z . Tari, editors, OTM Conferences (1) , volume 4275 of Lecture Notes in Computer Science, pages 291 { 308 . Springer, 2006 .

[2] M. Adams , A. H. M. ter Hofstede , W. M. P. van der Aalst , and D. Edmond . Dynamic, Extensible and Context-Aware Exception Handling for Work ows . In R. Meersman and Z . Tari, editors, OTM Conferences (1) , volume 4803 of Lecture Notes in Computer Science, pages 95 { 112 . Springer, 2007 .

[3] J. M. Carroll , M. B. Rosson , G. Chin, and J. Koenemann . Requirements Development in Scenario-Based Design . IEEE Transactions on Software Engineering , 24 ( 12 ): 1156 { 1170 , 1998 .

[4] A. Dittmar . Perikles Projektbericht zum Meilenstein 1 , 2009 .

[5] A. Dittmar and P. Forbrig . A uni ed description formalism for complex HCI-systems . International Conference on Software Engineering and Formal Methods , pages 342 { 351 , 2005 .

[6] A. Dittmar and P. Forbrig . Task-based design revisited . In EICS '09: Proceedings of the 1st ACM SIGCHI symposium on Engineering interactive computing systems , pages 111 { 116 , New York, NY, USA, 2009 . ACM.

[7] D. Hollingsworth . The Work ow Reference Model - TC00-1003 , 1995 .

[8] T. Mo ller. Untersuchung zur Flexibilisierung klinischer Work ows . Diplomarbeit, Universtity of Rostock, Universtity of Rostock, 2009 .

[9] M. Reichert , P. Dadam , and T. Bauer . Dealing with Forward and Backward Jumps in Work ow Management Systems . Software and System Modeling , 2 ( 1 ): 37 { 58 , 2003 .

[10] L. Song . Konzepte fur die Integration von XML-Schema und Prozessbeschreibungen . Diplomarbeit, Universtity of Rostock, Universtity of Rostock, 2009 .

[11] W. M. P. van der Aalst , M. Adams , A. H. M. ter Hofstede , M. Pesic , and H. Schonenberg . Flexibility as a service . In L. C. 0002, C. Liu , Q. Liu , and K. Deng, editors, DASFAA Workshops , volume 5667 of Lecture Notes in Computer Science, pages 319 { 333 . Springer, 2009 .

[12] W. M. P. van der Aalst , M. Pesic, and H. Schonenberg . Declarative work ows: Balancing between exibility and support . Computer Science - R&D, 23 ( 2 ): 99 { 113 , 2009 .

[13] B. Weber , S. W. Sadiq , and M. Reichert . Beyond rigidity - dynamic process lifecycle support . Computer Science - R&D, 23 ( 2 ): 47 { 65 , 2009 .