Nachdem im ersten Teil ein paar Grundelemente der CMMN angerissen wurden, soll es im zweiten Teil ein wenig ins Detail gehen. Die Tasks sind wieder dran und was man mit ihnen so alles an Kennzeichen mitgeben kann. Dazu werde ich das Beispiel aus dem ersten Teil noch mal aufgreifen und weiterführen.

Was bisher geschah…

Im ersten Teil lernten wir, dass ein Case ein CasePlanModel und ein CaseFile hat. Das CaseFile enthält in Form von CaseFileItems alle Informationen, mit denen der Case arbeiten kann. Das CasePlanModel enthält dagegen sämtliches Verhalten, das mit Tasks und Sentrys beschrieben wird. Wenn jetzt jemand aufschreit und wissen will, was mit den Stages ist, so will ich diese auch noch kurz erklären ;)

Eine Stage stellt eine Art Episode innerhalb eines Cases dar und kann sowohl Tasks als auch weitere Stages enthalten. Auch die Verwendung von Sentrys ist mit Stages möglich. Stages werden über Rechtecke mit abgeschrägten Ecken dargestellt. Das CasePlanModel ist technisch übrigens auch eine Stage, die allerdings nicht wie andere Stages durch ein Achteck, sondern durch den Case-Ordner selbst dargestellt wird. Diese Stage heißt auch äußerste Stage.

Das Beispiel

Als erstes soll der Patient untersucht werden. Abhängig vom Untersuchungsergebnis wird dann vom Arzt ein Medikament verschrieben oder zu einem Facharzt überwiesen. In jedem Fall soll die Leistung in Rechnung gestellt werden.

Aber was würde hier wirklich passieren, falls wir dieses Diagramm in eine Engine schmeißen und ausführen lassen?

Zunächst einmal nichts :) Erst wenn der Arzt oder die Ärztin einen neuen Case beginnt, geschehen Dinge, und zwar diese:

• Der Case wird erzeugt und ist dann aktiv.
• Die CaseFileItems werden erzeugt und sind dann verfügbar.
• Das CasePlanModel wird erzeugt und ist dann aktiv.
• Die Tasks werden erzeugt und aktiviert und sind dann verfügbar.

Jetzt wird es spannend: Wenn ein Task verfügbar ist, bleibt er das so lange, wie sein Entry Criterion Falsch ist. Der Task „Patient untersuchen“ hat kein explizites Entry-Criterion, deswegen wird angenommen, es sei implizit vorhanden und Wahr! Die nächste Frage, die sich stellt, ist: Wird der Task dann automatisch aktiviert oder muss der Benutzer ihn explizit starten?

Die Antwort darauf liefert die Manual Activation Rule.

Manual Activation Rule

Die Manual Activation Rule befindet sich an Stages und Tasks und entscheidet darüber, ob das entsprechende Element durch einen Menschen explizit aktiviert werden werden muss oder ob es automatisch aktiviert wird, sobald alle Vorbedingungen (Entry Criteria, Zustand der umgebenden Stage) erfüllt sind. Sie besteht aus einem Ausdruck, der einen boolschen Wert ergeben muss. Existiert die Rule nicht, so wird so getan, als, sei sie vorhanden und ergäbe Wahr. Nur wenn sie tatsächlich besteht und Falsch ergibt, man sie also explizit abgeschaltet hat, wird der Task auch automatisch aktiviert.

Ist eine Manual Activation Rule vorhanden – und damit meine ich: vorhanden – wird in dem Task ein weiß-gefülltes Dreieck, ähnlich dem Play-Symbol von Kassettenrecodern CD-Playern MP3-Playern, dekoriert. Andernfalls wird das Symbol auch nicht angezeigt. Um das nochmal deutlich zu machen: Es ist unerheblich, ob die Rule zu Wahr oder Falsch evaluiert; wichtig für die Anzeige ist nur, ob sie vorhanden ist. D.h., ein leerer, undekorierter Task hat keine Rule, was letztlich zur Folge hat, dass er immer von Hand aktiviert werden muss.

Mit diesem Wissen geht es jetzt weiter und wir schauen mal, was in unserem Case weiter passiert:

Der Task „Patient untersuchen“ ist soeben verfügbar geworden und wird dann – aufgrund des fehlenden Entry Criterions und der fehlenden Manual Activation Rule – freigeschaltet und wartet nun darauf, vom Benutzer gestartet zu werden.

Der Benutzer spannt uns auch nicht allzulange auf die Folter und startet den Task, führt die Aufgabe aus (hier: die Untersuchung des Patienten) und markiert sie in seiner Anwendung als abgeschlossen. Nun passieren weitere Dinge:

Die Entry Criterions der abhängigen Tasks „Medikament verschreiben“, „Zum Facharzt überweisen“ und „Rechnung stellen“ sind jetzt mit Abschluss des von ihnen referenzierten Tasks „Patient untersuchen“ erfüllt und werden – da auch ihnen die Manual Activation Rule fehlt – freigeschaltet. Der Arzt hat jetzt also drei Tasks zur Auswahl, die er in beliebiger Reihenfolge – oder auch gar nicht – ausführen kann.

Äh, Moment! Gar nicht ausführen? Und was ist mit der Rechnung? Die muss doch immer gemacht werden.

Auftritt: Required Rule

Die Required Rule kann ebenso wie die Manual Activation Rule sowohl an Tasks als auch an Stages gehängt werden. Auch hierhinter steckt ein Ausdruck, der einen boolschen Wert ergeben muss. Allerdings wird hier im Unterschied zur Manual Activation Rule ein Fehlen nicht durch ein implizites Wahr gleichgesetzt. Bei der Required Rule wird stattdessen in diesem Fall ein Falsch angenommen.

Wenn die Required Rule eines Tasks, auf welchen Weg auch immer, Wahr ist, dann kann die umgebende Stage nicht abgeschlossen werden, bevor dieser Task nicht abgeschlossen wurde.

Wie bei der Manual Activation Rule ist auch hier allein das Vorhandensein der Rule dafür entscheidend, ob das Symbol – ein Ausrufezeichen – angezeigt wird oder nicht.

Damit unser Arzt jetzt nicht vergisst, die Rechnung zu stellen – was schon mittelfristig schlimme Konsequenzen für den Fortbestand der medizinischen Versorgung in der Gegend haben könnte – muss unser Case etwas anders modelliert werden: Wir fügen dem Rechnungs-Task eine Required Rule hinzu.

Jetzt haben wir das gewünschte Verhalten und können sicher sein, dass der Arzt nicht wegen vergessener Rechnungsstellung pleite geht.

Schließlich…

Allerdings, ein Problem gibt es noch:
Was macht der Arzt, wenn er den Patienten zu mehreren Fachärzten überweisen oder ihm verschiedene Medikamente verschreiben möchte? Kann er das gemäß dem Modell überhaupt machen?

Diese und viele andere Fragen werden in einem der nächsten Teile erklärt werden.