Blog

CMMN erklärt: Teil 1 – ein kleines Grundgerüst

Mit dem Aufleben von Adaptive Case Management kommt auch eine neue Modellierungssprache daher: die „Case Management Model and Notation“, kurz CMMN.

Die Version 1.0 wurde just im Mai dieses Jahres veröffentlicht und hilfreiche Dokumentation ist entsprechend spärlich. Das soll sich nun ändern! In einer Reihe von Blogbeiträgen möchten wir die CMMN verbraucherfreundlich erklären.

Als Erstes geht es darum, genug Handwerkszeug zu bekommen, um ein Big Picture modellieren zu können. Dazu werden wir uns durch das Beispiel „Patient behandeln“ hangeln. Im Beispiel soll ein Arzt einen Patienten untersuchen und ihm dann ein Mittel gegen seine Beschwerden verschreiben oder ihn an einen Facharzt überweisen.

Zum Anfang aber erstmal etwas Erwartungsmanagement: Was ACM ist, wird hier nicht erklärt, das würde den Umfang deutlich sprengen. Ich setze also ein entsprechendes Grundverständnis von ACM voraus. Meine Kollegen Roman Schlömmer und Sven Polte haben bereits etwas dazu geschrieben, das ich hier gern als weiterführende Ressourcen nennen möchte:

Nun aber los mit der CMMN! Das ‚C‘ steht ja für ‚Case‘, und mit dem wollen wir auch gleich anfangen.

Der Case

Vereinfacht gesagt, besteht ein Case aus Daten und Aufgaben. Und Planungstabellen. Und Beziehungen zwischen Aufgaben und Daten und Aufgaben untereinander. Und Rollen gibt es auch. Hatte ich schon Stages und Meilensteine erwähnt?

Ich fange noch mal an: Vereinfacht gesagt, besteht ein Case aus Daten und Aufgaben. ;)

Strukturell ist der Case das Wurzelelement in der CMMN und dient als Klammer für die verschiedenen Elemente. Der Case selbst wird nicht grafisch repräsentiert, dafür aber das Case Plan Model, das jeder Case hat. Da zwischen den beiden eine 1:1-Beziehung herrscht, muss man sie in den meisten Fällen nicht unterscheiden.  Das Case Plan Model jedenfalls wird durch einen Ordner repräsentiert, der den Namen des Cases in seinem einzigen Reiter trägt:

Case "Patient Behandeln"

Jetzt haben wir einen Case – das ist toll! :) Aber ganz allein auch irgendwie nutzlos. Die leere Fläche lädt doch irgendwie zum Malen ein …

Das Case File Item

ACM nimmt eine datenzentrierte Sicht auf die Welt ein, in der Aufgaben auf Daten aufsetzen Während bei BPM typischerweise der Ablauf im Vordergrund steht, verbunden mit der Frage, welche Daten benötigt werden, um den Ablauf zu steuern, legt ACM den Fokus auf die Daten und stellt die Frage, welche Aufgaben mit den vorliegenden Daten sinnvoll und machbar sind.

Daten werden in einem Case File gesammelt. Das Case File (es gibt nur eines in einem Case) dient als Sammelbecken für ein oder mehrere Case File Items, welche die eigentlichen Daten darstellen. Ein Case File Item kann wiederum weitere Case File Items enthalten.

Case Files werden als Dateien innerhalb des Cases (sorry, des Case Plan Models!) dargestellt:

Case "Patient Behandeln" mit Patientenakte

Die Tasks

Nun, da wir ein paar (nicht näher spezifzierte) Daten haben, können wir mit diesen auch arbeiten. Dazu gibt es die Tasks.

Tasks können näher beschrieben werden als Human Tasks, Process Tasks oder Case Tasks. Sie werden dargestellt als Rechtecke mit abgerundeten Ecken und dem Typ in der linken oberen Ecke:

Verschiedene Typen von Tasks

Tasks können andere Tasks als Voraussetzung haben, das wird dann als eine gestrichelte Linie mit einem leeren Diamanten am Ende dargestellt. Der Diamant ist übrigens ein Entry Criterion und gehört damit zu den Sentrys. Ein schwarzer Diamant wäre übrigens ein Exit Criterion. Natürlich hat die gestrichelte Linie auch einen eigenen Begriff: Connector.

In dem Bild oben sieht man eine einfache Abhängigkeit, eine UND-Verknüpfung und eine ODER-Verknüpfung.

Zwischenstand

Wir haben jetzt ein vereinfachtes Modell in der Hand, mit dem wir einen Case mit Daten, Aufgaben und Abhängigkeiten zwischen Aufgaben modellieren können. Unser anfangs genanntes Beispiel können wir jetzt wie folgt modellieren:

Case "Patient Behandeln" mit Patientenakte und Aufgaben

Aus dem Bild allein geht schon einiges hervor, aber damit die Sache richtig rund wird, darf noch ein wenig Prosa hinzugefügt werden:

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

  • Soll ein Medikament verschrieben werden, kann der Arzt aus einer Liste von bekannten Medikamenten wählen bzw. in dieser suchen. Das Rezept wird dann automatisch ausgedruckt, so dass der Arzt es dem Patienten gleich mitgeben kann.
  • Bei einer Überweisung kann der Arzt aus bekannten Fachärzten auswählen oder eine neue Adresse eingeben. Der Überweisungsschein wird auch sofort ausgedruckt und kann mitgegeben werden.
  • Bei der Rechnungsstellung wird anhand der vorliegenden Patientenakte erkannt, ob es sich um einen Kassen- oder Privatpatienten handelt, und die Rechnung entsprechend erstellt.

Schlusssatz

Ich denke, dass man mit diesen wenigen Elementen genug in der Hand hat, um z.B. in Workshops schnell ein paar Ideen am Whiteboard festzuhalten, bevor man sich daran macht, sie im Detail zu spezifizieren. Anschließend macht man ein Foto und schickt es mit einigen Kommentaren an die Beteiligten. So einfach kann das sein :)

 

 

Über den Autor

5 Kommentare

  1. Hallo Malte,

    toller und hilfreicher Blogbeitrag! Ich habe dazu eine Frage: Du sprichst davon, dass Tasks andere Tasks als Voraussetzung haben können. Soweit klar. In dem Beispiel sagst du: Nach der Untersuchung wird der Patient zu einem Facharzt überwiesen oder bekommt ein Medikament verschrieben (oder beides oder keines von beiden?). In jedem Fall wird eine Rechnung gestellt.

    „Patient untersuchen“ hat also immer „Leistung in Rechnung stellen“ zur Folge. Das kann ich aus dem Modell nicht ablesen. Kann man das genauer spezifizieren? Wäre in dem Fall ein exit criterion geeigneter?

    Viele Grüße,
    Stefan

    • Hi Stefan!

      Ich denke du hast recht! Aus der Notation geht nur hervor, dass man einen Patient untersucht haben muss, bevor man

      a) eine Leistung in Rechnung stellen kann.
      b) ein Medikament verschreiben kann.
      c) zum Facharzt überweisen kann.

      Alles folgende ist kann, kein muss. Ich hatte mich auch beim Lesen auch schon gefragt, wofür dann der schwarze Diamant da ist. Folgt bestimmt in Teil 2. :)

      • Hallo Stefan, hallo Julian,

        danke, jetzt habe ich ja schon mal einen Aufhänger für den zweiten Teil :)

        Um euch nicht auf die Folter zu spannen, nehme ich es aber schon mal vorweg:
        Das Exit Criterion dient dazu, etwas von Außen zu beenden. Es ist also ein Eingabe- und kein Ausgabekanal.

        Außerdem gibt es noch die Möglichkeit, den „Rechnung stellen“ Task als Required zu kennzeichnen, damit wäre er dann nicht mehr optional. Damit würde dieses Modell hier sicherlich noch etwas mehr Klarheit erlangen. Ich habe mich auch nur knapp dagegen entschieden, es im 1. Teil schon zu erwähnen, weil ich damit einen größeren Themenblock angeschnitten hätte.

        Also, freut euch auf den 2. Teil! :)

  2. Sehr geehrter Herr Sörensen,

    ich möchte meine Bachelorarbeit über CMMN und deren Bezug zur BPMN schreiben und bin bei der ersten Informationssuche auf ihre interessanten Blogeinträge gestoßen – diese waren sehr hilfreich. Ich würde nur gerne wissen, ob es denn Literatur zum Thema CMMN gibt die sie empfehlen können?

    Mit freundlichen Grüßen
    Andreas Henschel

    • Hallo Herr Henschel,

      leider ist mir keine Literatur zur CMMN bekannt.

      Aber es gibt natürlich die Spezifikation der OMG, aber ich nehme an, dass Ihnen diese bereits geläufig ist. Und zudem gibt es von Bruce Silver einen interessanten Blog-Artikel zum Vergleich von BPMN und CMMN.

      Gleichwohl ist die CMMN auch nicht ohne Kontext, weswegen es sich vielleicht für Sie lohnt, sich mit dem Thema Thema (Adaptive) Case Management etwas zu befassen. Dieses Wissen kann durchaus helfen, den Einsatzzweck und den Entwurf der CMMN besser zu verstehen – gerade im Vergleich zur BPMN, die im Rahmen von BPM zu betrachten ist.

      Zu dem Thema ACM werden Sie dann auch reichlich Literatur finden. „Taming the Unpredictable“ von Keith Swenson kommt mir da spontan in den Sinn.

      Ich hoffe, Ihnen geholfen zu haben :)

      Viele Grüße,
      Malte Sörensen

Antwort hinterlassen