Ja, lang ist’s her mit dem dritten Teil dieser Reihe… heute geht’s weiter mit den Discretionary Items.

In der Zwischenzeit hat sich auch viel getan – die CMMN ist in der Version 1.1 veröffentlicht und die Toolunterstützung ist auch besser geworden. :)

Dementsprechend ist dieser Beitrag auch auf die 1.1 gemünzt und nicht auf die 1.0 wie die bisherigen Teile.

In einem Kommentar zum zweiten Teil hatte ich schon mal kurz beschrieben, dass die Discretionary Items „im Gegensatz zu den „normalen“ Tasks erst zur Laufzeit und auf ausdrücklichen Wunsch des Users dem Repertoire an verfügbaren Tasks hinzugefügt“ werden. Es geht also um Pläne und Planung zur Laufzeit.

Was gehört alles dazu?

Discretionary Items können alles sein, was die CMMN als Plan Item kennt:

• alle Arten von Tasks
• Stages
• Milestones
• anderes Zeug, das gerade nicht wichtig ist

Außerdem gehören noch die Planning Tables dazu. Ein Planning Table enthält immer Discretionary Items und optional Regeln (sog. Applicability Rules) zur Steuerung, wer was wann planen darf.

Planning Tables können sich an Human Tasks und Stages (und infolgedessen auch am Case Plan Model) befinden. Außerdem kann ein Planning Table weitere Planning Tables enthalten. Was das genau impliziert, ist hier aber nicht das Thema. Hier bleibt’s einfach.

Die Planung findet übrigens nicht in irgendeiner Anfangsphase beim Starten eines Cases statt, sondern kann jederzeit erfolgen. Selbst ein beendeter Case darf neu geplant werden. Wiesoweshalbwarum das, ist eine spannende Frage :) Die Planung selbst ist der Vorgang des Aufnehmens von Discretionary Items in das Case Plan Model.

In einer hinkenden Fußballanalogie ausgedrückt (wir haben ja gerade EM :)), könnte man sagen, dass die Discretionary Items die Spieler auf der Ersatzbank sind und die (eingeplanten) Items im Case Plan Model die Feldspieler.

Nicht das Beispiel schon wieder …

Nehmen wir mal zum Verdeutlichen das leicht verbrauchte Arzt-Beispiel (nur um es endlich ganz aufzubrauchen):

Der Arzt stellt nach eingehender Untersuchung die Diagnose, dass der Patient krank ist und eine langwierige Therapie benötigt. Ist jetzt auch egal, was er hat, wichtig ist nur:

• der Arzt muss fallbezogen einen Plan für einen längeren Zeitraum erstellen
• und der Plan muss regelmäßig überprüft und angepasst werden

Hier kann man gut mit Discretionary Items arbeiten.

Im einfachsten Fall haben wir einen stage- und milestonelosen „Behandlungsplan“-Case, der alle Items in sich beherbergt. Würde man das jetzt so lassen, wäre dem Arzt und seinen MTAs jederzeit alles möglich. Kann man so machen, aber erstens wird das unübersichtlich und zweitens weiß man beim zweiten Besuch des Patienten nicht mehr, was man sich damals als Behandlung vorgenommen hat.

Als Erstes fügen wir dem Case daher ein Planning Table hinzu. Danach werden alle Items, die nicht allgemeingültig sind (z.B. „Ultraschall machen“), diesem Planning Table hinzugefügt. Wenn der Arzt nun einen Behandlungsablauf „plant“, fügt er diesem alle aus seiner Sicht notwendigen Schritte hinzu.

Was man jetzt im Modell sieht, ist das unfertige Tic-Tac-Toe-Feld am oberen Rand des Case Plan Models, das den Planning Table repräsentiert, und die gestrichelt umrandeten Items, die sich nun Discretionary nennen dürfen.

Aus Usersicht würde sich das in etwa so offenbaren:

Über die Funktion zur Neuanlage eines Behandlungsplans kommt man in eine spezielle Maske, in der man zwei Listen von Items hat. Die eine zeigt die planbaren, die andere die eingeplanten Items. Letztere enthält immer die allgemeingültigen, nicht dem Planning Table zugeordneten Items. Diese sind auch nicht entfernbar. Der Arzt kann jetzt die Discretionary Items zwischen diesen Listen hin und her schieben.

Ist der Plan angelegt, ist er über die Patientenakte erreichbar. Er öffnet sich in einer weiteren speziellen Ansicht, in der man eine Liste der aktuell verfügbaren Items sieht – die Taskliste eben. Hier sind wieder andere, ganz normale Dinge entscheidend: Sentries, Rules usw., die steuern, wann ein Item gestartet werden kann, wiederholbar ist etc.

Typischerweise werden Behandlungspläne in Form von Heil- und Kostenplänen bei Krankenkassen eingereicht. Deswegen tun wir hier auch mal so, als wenn sie sich niemals ändern und nur einmal zu Beginn festgelegt werden.

Ein anderes Szenario

Was kann man denn noch mit Planning Tables machen? Wie erwähnt, haben wir ja noch die Applicability Rules. Vielleicht kann man mit denen ja noch was Nettes machen?

Tun wir mal so, als gäbe es weltweit operierende Unternehmen, die ihre Geschäftsprozesse global vereinheitlichen möchten, aber dabei aber die lokalen Gesetze und Abläufe einhalten müssen. Zum Beispiel die Zollabwicklung. Es müssen ja immer wieder Dinge aus einem Land ex- und in ein anderes Land importiert werden. Manchmal muss man da auch mal einen Beamten von der Richtigkeit der Zolldeklaration überzeugen, ohne dass er in die Kisten schaut.

Wir können das erreichen, indem wir den betreffenden Items ein Entry Criterion mitgeben, das in seinem If-Part eine Konfiguration auswertet. Die Konfiguration hält für alle Länder und alle betreffenden Items vor, ob ein bestimmtes Item in einem bestimmten Land vorhanden ist. So matrix-like halt.

Leider wird dabei in dem Modell nicht klar, welche besondere Bedeutung die Entry Criteria haben – dienen sie dann der Steuerung der Abläufe, also der fachlich notwendigen Einschränkung der Dynamik, ihrem eigentlichen Zweck, oder dienen sie nur der Anpassung des Modells an die Laufzeitumgebung?

Ein anderer Ansatz ist, die Items per Planning Table bzw. Applicability Rule zu steuern. Die Rules werten dabei dieselbe Konfiguration wie im ersten Ansatz aus. Die nach Anwendung der Konfiguration noch übriggebliebenen Items können dann wie im Behandlungsplan-Beispiel verwendet werden.

Das Modell wird ein wenig übersichtlicher und wenn man möchte, kann man auch Sentries wieder für ihren richtigen Zweck einsetzen. Aber auch diese Lösung ist nicht ganz einwandfrei, denn hier werden die Discretionary Items zweckentfremdet. Sie dienen der Planung zur Laufzeit, dem Aufnehmen von fachlich erlaubten, weiteren Schritten, nach Analyse des vorliegenden Falles –  eine Konfiguration dagegen ist schon vor dem Starten bekannt und hat nichts mit dem fachlichen Sachverhalt zu tun.

Ende

Zusammenfassend lässt sich sagen, dass Discretionary Items eine wunderbare Bereicherung sind, das Model aber auch komplizierter machen können und ihr Einsatz daher wohl überlegt sein will.

Bis zum nächsten Teil, wann immer das sein mag ;)