Diesen Artikel habe ich ursprünglich im SAP Community Network veröffentlicht.

Hintergrundinformationen

Eine Kernfunktion des Klinischen Systems i.s.h.med ist die Verwaltung klinischer Dokumente. Unabhängig von der Darstellung und Struktur der Inhalte haben klinische Dokumente einen gemeinsamen Satz von Verwaltungsdaten, einschließlich wichtiger Referenzdaten: Zu welchem Patienten, Fall, welcher Bewegung oder Leistung gehört dieses Dokument? Man muss die Dokumentreferenzebene angeben, wenn man den sogenannten Dokumenttyp erstellt, und das System stellt dann sicher, dass ein Dokument, das einem Fall zugeordnet werden muss, erst erstellt werden kann, wenn eine Fallnummer angegeben wurde. Bei der normalen Entwicklung und Wartung neigen die meisten Administratoren dazu, diese Referenzebenen als transitiv zu betrachten: Ein Fall spezifiziert immer einen bestimmten Patienten, eine Bewegung identifiziert immer eindeutig einen Fall und so weiter. Leider ist das nicht ganz richtig. Es ist möglich, Leistungen zu erfassen und zu verarbeiten, die einem Patienten zugewiesen sind, aber (noch) keinem Fall zugewiesen wurden. Dies kann beispielsweise bei der Planung von Leistungen für einen Patienten der Fall sein, der in Zukunft wieder aufgenommen wird: Die Leistung wird dem Patienten zugewiesen, aber sonst nichts. Normalerweise sollte der Benutzer erst nach der Aufnahme und der Erstellung des Falls Dokumente und andere klinische Daten erstellen, aber manchmal kommt es zu Verwechslungen. Dies führt dazu, dass mehrere Dokumente mit Bezug auf einen Patienten und eine Leistung erstellt werden, aber kein Fall- oder Bewegungsbezug besteht, was wiederum zu allen möglichen Folgeproblemen führt.

Shades of Grey

(Billy Joel, nicht 50)

Die erste Reaktion auf diese Situation war in etwa: „Wir wollen sowieso keine Dokumente auf Patientenebene: Genehmigungen, Behandlungsverträge, dürfen nie freigegeben werden – nein. Jedes Dokument muss einem Fall zugeordnet werden. Können Sie nicht etwas zusammenstellen, das verhindert, dass dies jemals wieder passiert?“. Eine genauere Untersuchung ergab, dass es - wie üblich - keine feste Regel ohne Ausnahmen gibt. In diesem Fall gibt es zwei Institutionen mit unterschiedlichen Regeln - für eine Institution müssen zwei Dokumentenkategorien von dieser Regel ausgenommen werden, während für eine andere Institution drei komplexere Ausschlusssätze mit verschiedenen Kombinationen aus Dokumentenkategorie und dokumentierender Organisationseinheit (OE) berücksichtigt werden müssen. Dies deutet bereits darauf hin, dass die Ausnahmen nicht nur etwas komplexer sein können als ursprünglich angenommen, sondern dass sie sich im Laufe der Zeit auch erheblich ändern können, da sich sowohl Dokumentkategorien als auch Organisationsstrukturen im Laufe der Zeit weiterentwickeln. Fazit: Eine harte Codierung ist wahrscheinlich keine gute Idee.

Der klassische Ansatz

Eine gängige Methode, diese Aufgabe anzugehen, besteht darin, eine transparente Tabelle zu definieren, die die Kombinationen enthält, die je nach tatsächlicher Implementierung entweder erlaubt oder verboten sind. Die Tabelle würde mit einer Pflegeview und einer generierten Viewpflegeanwendung ausgestattet, sodass Einträge geändert und Änderungen bei Bedarf transportiert werden können. Dieses Muster ist zwar bereits viel besser als die feste Programmierung der Logik, hat aber dennoch einige Nachteile:

  • Man muss die Logik so programmieren, dass sie die Tabelleninhalte lesen und auswerten kann. Das mag trivial klingen, wird aber bei zunehmender Komplexität schnell zu einer Herausforderung.
  • Man kann Klauseln, die „und“, „oder“, „außer“ und „nur wenn“ enthalten, nicht einfach mithilfe von benutzerdefinierten Tabellen ausdrücken – stattdessen muss man alle möglichen Kombinationen aufzählen. Im Laufe der Zeit führt dies tendenziell zu großen Mengen von Einträgen, die zu Performance- und/oder Handhabungsproblemen führen können.
  • Wenn man generische Einträge (*) oder komplexere Bedingungen wie „beginnt mit ABC*“ oder „zwischen DEF1000 und DEF1999“ unterstützen möchte, muss man diese erneut manuell codieren.
  • Heute wissen wir, dass wir die Einrichtung, den Dokumenttyp und die dokumentierende Organisationseinheit berücksichtigen müssen, sodass dies wahrscheinlich Schlüsselfelder der Tabelle sein müssen. Wenn in Zukunft mehr oder andere Kriterien erforderlich sind, um Ausnahmen auszudrücken, muss die Struktur der Tabelle geändert werden. Je nach Komplexität und tatsächlicher Implementierung kann dies zu erheblichen Änderungen im Code sowie zur Anpassung der Tabelleninhalte führen, was den Gesamtaufwand jeder Änderung erhöht. Unbeabsichtigte Nebeneffekte der Änderung können sich sehr leicht einschleichen.
  • Es ist normalerweise nicht möglich, Dokumentation zu Einträgen einer Customizing-Tabelle hinzuzufügen – im besten Fall kann man ableiten, was ein bestimmter Eintrag bewirkt, aber nicht, warum er erstellt wurde.
  • Wenn man es nicht explizit selbst programmiert, gibt es keine Testumgebung und auch keine Protokollierung, was es schwierig macht, die Korrektheit des Inhalts der Customizing-Tabelle zu überprüfen und Fehler in der Implementierung zu beseitigen.

Angesichts all dieser Schwächen sollte man sich fragen: Gibt es nicht einen besseren Ansatz?

Einführung in BRFplus

BRFplus ist ein Business Rules Framework, das für die Handhabung von Anwendungen wie dieser (und auch für viel komplexere Fälle) entwickelt wurde. Ich werde nicht noch eine weitere Einführung in BRFplus schreiben, in der alle seine Funktionen und seine herausragende Flexibilität im Detail beschrieben werden. Es gibt eine ganze Reihe von Einsteigerartikeln sowie eine recht umfassende Online-Dokumentation und einige gute Bücher. Ich habe Business Rule Management mit ABAP von Thomas Albrecht, Matthias Kucharska, Christian Lechner, Daniel Ridder, Wolfgang Schaper, Tobias Trapp und Carsten Ziegler und kann es sehr empfehlen, um sich mit BRFplus vertraut zu machen. Für englischsprachige Leser gibt es ein älteres Buch, das noch erhältlich ist – ich habe keinen Zugriff mehr auf dieses Buch, aber ich erinnere mich vage daran, dass es ebenfalls von sehr hoher Qualität war. Es hat keinen Sinn, das zu wiederholen, was bereits von Leuten geschrieben wurde, die viel mehr Ahnung haben als ich.

Statt einer Einführung möchte ich daher folgendes versprechen: Wenn Sie BRFplus zur Implementierung der oben genannten Geschäftsregeln verwenden,

  • können Sie den Regelsatz innerhalb einer sehr angemessenen Zeit vollständig ausdrücken,
  • erhalten Sie eine unglaubliche Flexibilität und sind somit viel besser auf zukünftige Änderungen vorbereitet,
  • können Sie die Regeln einfach dokumentieren,
  • erhalten Sie die gleichen Transportmöglichkeiten (wenn Sie möchten) ohne zusätzlichen Aufwand,
  • können Sie vorbildliche Test- und Rückverfolgungsrahmen ohne zusätzliche Implementierung auf Ihrer Seite verwenden und
  • erhalten Sie all dies mit sehr wenig ABAP-Codierung, und der erforderliche Code wird sich höchstwahrscheinlich nicht ändern.

Interessiert? Dann folgen Sie mir in die Tiefen des Systems und überzeugen Sie sich selbst.

Disclaimer: Dieser Artikel wurde von meinem damaligen Arbeitgeber, der St. Georg IT Gesellschaft mbH, unterstützt. Bitte besuchen Sie deren Website für weitere Informationen.