HAUPTBEITRAG / NAVIGIEREN STATT MODELLIEREN }
Navigierenstattmodellieren
Flexible Prozessgestaltung durch Endanwender
Claudia Reuter · Peter Dadam
Hohe Komplexitätund
extreme Flexibilitäts-
anforderungen erschwe-
ren den Einsatzvon Pro-
zesstechnologien in
Kliniken. Guarded Pro-
cess Spaces (GPS) unter-
stützeneineneueArt der
Prozessmodellierung,
diesichandenBedürf-
nissen der Endanwender
orientiert und die flexi-
ble Prozessanpassung
zur Laufzeit ermöglicht.
Einführung
In einer globalisierten
WeltmüssenUnterneh-
men ihre Produkte und
Dienstleistungenzuneh-
mend rascher an sich
veränderndeMarktbe-
dingungenundKunden-
anforderungen anpas-
sen, um wettbewerbs-
fähig zu bleiben. Ein
entscheidenderFaktor
ist hierbei die flexible
Gestaltung der Ge-
schäftsprozesse.Dementsprechend hat die Einfüh-
rung von prozessorientierten Informationssyste-
men (poIS), die die Modellierung, die Ausführung
und das Controlling von Prozessen unterstützen,
bei Entscheidungsträgern vieler Branchen Priori-
tät. Während poIS bzw. die ihnen meist zugrunde
liegenden Prozess-Management-Systeme (PMS)
ursprünglich zur Steuerung von industriellen Ar-
beitsabläufen sowie zur Systemintegration entwi-
ckelt wurden, melden inzwischen auch kunden-
und dienstleistungsorientierte Domänen, wie z. B.
das Gesundheitswesen, ihr Interesse an. Diese An-
wendungsdomänen haben in der Regel erheblich
höhereAnforderungenankurzeRealisierungsfristen
für neue Prozesse, an deren rasche Anpassbarkeit
an veränderte Rahmenbedingungen sowie an die
Flexibilität, die konkrete Prozessausführung im Ein-
zelfall individuell gestalten zu können. Besonders
deutlich wird dies am Beispiel medizinischer Be-
handlungsabläufe. Zum einen sind hier neue medi-
zinische Erkenntnisse stetsohne großen Zeitverzug
in die Behandlungsprozessezu integrieren, zum an-
deren muss jeder Patient und jede Patientin indivi-
duell betrachtet und behandelt werden. Kein PMS
kann dem zuständigen Arzt die Entscheidung und
Verantwortung abnehmen. Das heißt, die derzeit im
industriellen Umfeld gängige, zeitaufwendige Vor-
gehensweisebei der Erfassung, Modellierung, Im-
plementierung und Inbetriebnahme von Prozessen,
die dem Paradigma ,,write once, run forever“ folgt,
ist für solche Anwendungsdomänen ungeeignet;
außerdem ist auch die erforderliche Flexibilität zur
AusführungszeitinderRegelnichtvorhanden [6].
Hinsichtlich der Realisierung neuer und Adap-
tion existierender Prozesse wird, insbesondere in
stark wissensgetriebenen Anwendungsdomänen,
kein Weg daran vorbeiführen, die Fachanwender
sehr viel früher und sehr viel intensiver in die
Prozessentwicklung einzubeziehen. Idealerweise
sollten sie ihre Prozesse selbst realisieren können.
Mit ,,Guarded Process Spaces“ (GPS) haben wir
daher einen Weg zur Prozessmodellierung und
-anpassung durch Endanwender entwickelt, den
wir im Folgenden im Sinne eines Denkanstoßes
vorstellen möchten. Der Beitrag ist wie folgt auf-
gebaut: Im nächsten Abschnitt gehen wir kurz auf
domänenspezifische Modellierungssprachen sowie
DOI 10.1007/s00287-012-0651-2
© Springer-Verlag Berlin Heidelberg 2012
Claudia Reuter
Zühlke Management Consultants AG,
Wiesenstr. 10a, 8952 Schlieren, Schweiz
E-Mail: claudia.reuter@zuehlke.com
Peter Dadam
Universität Ulm, Institut für Datenbanken und
Informationssysteme, 89069 Ulm, Deutschland
E-Mail: [email protected]
{NAVIGIEREN STATT MODELLIEREN
Zusammenfassung
Angesichts des zunehmenden Qualitäts- und
Kostendrucks, werden Technologien zum Ent-
wurf und zur Ausführung standardisierter
Behandlungsprozesse als ,,klinische Pfade“ für
Krankenhäuser immer relevanter. Im Gegensatz
zu stark strukturierten Prozessen in der produ-
zierenden Industrie, müssen Kliniken jedoch
in der Lage sein, ihre Pfade schnell und flexibel
an den Bedürfnissen ihrer Patientinnen und
Patienten auszurichten. Mit Guarded Process
Spaces (GPS) haben wir daher ein formales
Konzept entwickelt, um Endanwendern im
Krankenhaus selbst die Möglichkeit zu geben,
ausführbare Behandlungsprozesse für ihre
Patienten zu erstellen und dynamisch zu ver-
ändern. Unser Ansatz macht dabei Gebrauch
von existierenden Prozesstechnologien, ohne
sich auf ein bestimmtes System und bestimmte
Benutzerschnittstellen festzulegen.
auf Flexibilitätsaspekte von PMS ein und stellen im
Anschluss vor, wie eine prozessorientierte Benut-
zerführung bei klinischen Pfaden aussehen kann.
Im Abschnitt ,,Guarded Process Spaces: Prozess-
modellierung nach dem Navigationsparadigma“
beschreiben wir das Konzept der ,,Guarded Process
Spaces“ (GPS) und die darauf basierende Prozess-
modellierungsmethodik. Anschließend werden
wir darlegen, wie sich Ad-hoc-Änderungen an
klinischen Pfaden aus Anwendersicht realisieren
lassen. Im Abschnitt ,,Implementierung von Guard-
ed Process Spaces“ geben wir einen Einblick in die
Implementierung von GPS. Zum Schluss diskutieren
wir Anforderungen an eine Ausführungsumgebung.
Eine erweiterte Fassung dieses Beitrags findet
sich in [16]; dort gehen wir etwas detaillierter auf
existierende technische Lösungen zur Prozessflexi-
bilisierung ein und stellen dar, wie diese als Basis für
unseren GPS-Ansatz genutzt werden können. In [15]
werden die formalen Grundlagen des Konzeptes
ausführlich beschrieben.
Stand der Technik
Die Modellierungssprachen,die von Prozessexper-
ten genutzt werden, um ausführbare Prozessmodelle
zu erstellen, sind für Endanwender meist zu
kompliziert oder erfordern einen hohen Ein-
arbeitungsaufwand. Aus diesem Grund werden
sogenannte domänenspezifischeSprachen(domain-
specificlanguages,DSL)fürdieProzessmodellierung
entwickelt, die sich an der Begriffs- und Denkwelt
derEndanwenderorientieren [4].ImPrinzipwerden
hierbei DSL-Konzepte, die für Programmierspra-
chen oder Entwurfssprachen für Software- und
Hardwaresysteme entwickelt wurden [10,18], auf
die Prozessmodellierungübertragen. Beispielsweise
gibtes DSLs für die Modellierung von Prozessen in
der öffentlichen Verwaltung [3], für die Erstellung
prozess-orientierter Webanwendungen [8], für Be-
handlungsplänein der integrierten Versorgung [11]
oder für medizinische Leitlinien [7]. In der Regel
sind diese ,,prozessorientierten“ DSLs hinsichtlich
ihresAusführungsverhaltensinformell beschrieben
und modellieren Aspekte wie Informations- bzw.
Datenflüsse eher grobgranular (falls überhaupt).
Somit kann erst nach Transformation in ein for-
males Prozessmodell (z. B. ein hierfür geeignetes
Petri-Netz [2]) mit genau definierten Struktur- und
Verhaltensregeln überprüft werden, ob das vom
Endanwender erstellteProzessmodelltechnischaus-
führbar ist. Eventuelle Modellierungsfehler lassen
sich somit meist erstim Nachhinein feststellen und
beheben.Das heißt, DSLs sind dafür ausgelegt, den
Ist-Prozess zu erfassen oder auch als Vorlage für
den Soll-Prozess zu dienen, sie sind jedoch nicht
dafür geschaffen,um direkt ausführbare Prozesse zu
erstellen.
Wenn aber die Realisierung ausführbarer
Prozesse durch Endanwender das Ziel ist, dann
muss stattdessen eine Modellierungsumgebung
bereitgestellt werden, die für Endanwender intuitiv
benutzbar ist und diese bei der Prozessmodellierung
so führt, dass technische Modellierungsfehler, wie
z.B. Verklemmungen, unvollständige Datenflüsse
usw., möglichst von vornherein vermieden werden.
Der sogenannte Correctness-by-Construction-
Ansatz des ADEPT-Projekts [5,13] zeigt einen guten
Weg auf, wie man dies erreichen kann und hat die
Entwicklung des GPS-Konzepts stark beeinflusst.
Aufseiten der PMSe existiert heute eine
Vielzahl verschiedener Prozessmodellierungs-
sprachen. Mit BPMN 2.0 [23] wurde jüngst der
Versuch unternommen, eine PMS-unabhängige
Modellierungssprache als Industriestandard zu
etablieren. Ob diese aufgrund der großen Funk-
tionalitätsunterschiede auf PMS-Ebene jedoch die
proprietären PMS-Modellierungssprachen einmal
Abstract
Facing increasing cost and quality pressure,
technologies for design and execution of
standardized treatment processes as “clinical
pathways” become more and more interesting
for hospitals. In contrast to well-structured
processes in the producing industry, hospitals
have to adapt their pathways quickly and flexibly
to the ever-changing demands of their patients.
With Guarded Process Spaces (GPS), we de-
veloped a formally based concept that makes
it possible to enable clinicians to create and
change processes themselves. Thereby, our ap-
proach makes use of existing process technology
while abstracting from specific systems and user
interfaces.
in großem Stil ablösen wird oder im Wesentlichen
auf BPEL-basierte PMS [22] beschränkt bleibt, muss
abgewartet werden. Allerdings legt BPMN 2.0 nur
die Syntax und Semantik der Modellkonstrukte
fest. Ob und wie ein Benutzer bei der Prozess-
modellierung vom Modelleditor geführt wird, ist
Sache des jeweiligen Herstellers; und zwar unab-
hängig davon, ob BPMN oder eine andere Notation
verwendet wird. Folglich gibt es auch keinerlei Aus-
sagen darüber, wie man sich Ad-hoc-Änderungen
auf Prozessinstanzebene vorzustellen hat; diese
werden bislang ohnehin nur von ganz wenigen
PMS unterstützt [20]. Nach heutigem Stand der
Technik müsste daher ein Endanwender, der selbst
Ad-hoc-Änderungen durchführen will, sich nicht
nur tief mit Prozessmodellierung im Allgemeinen
(Kontroll- und Datenflussmodellierung), sondern
auch mit der speziellen Modellierungssprache des
zugrunde liegenden PMS auseinandersetzen, um
die gewünschten Modifikationen ausführen zu kön-
nen. Ob das dann auch zu einem technisch robust
ausführbaren Prozess führt, steht wieder auf einem
anderen Blatt. (Dies ist natürlich keine realistische
Option für Endanwender.) Auch hier muss – wie
bei der Prozessmodellierung – ein Weg gefunden
werden, der es Endanwendern auf relativ intuitive
Weise und ohne große Einarbeitung gestattet, ad
hoc gebotene Änderungen auf Prozessinstanzebene
vorzunehmen.
Möglichkeiten der Ad-hoc-Definition und An-
passung von Prozessabläufen werden derzeit auch
unter dem Schlagwort ,,Adaptive Case Management“
diskutiert [19]. Ein ,,Fall“ bzw. ,,Case“ bezeichnet
eine Situation, die durch Auswahl einer Anzahl
von Aktionen zum Abschluss geführt werden soll.
Der Prozessablauf ist dabei nicht oder nur zum Teil
vordefiniert. Die Entscheidung, welche Aufgaben
zu einem gegebenen Zeitpunkt ausgeführt werden,
um zum gewünschten Ergebnis zu gelangen, wird
(zumindest in einem gewissen Umfang) ad hoc von
den verantwortlichen Mitarbeitern getroffen. Im
Gegensatz dazu ermöglicht der von uns entwickelte
Ansatz ,,Guarded Process Spaces“ die Modellierung
von ausführbaren Standardprozessen durch Endan-
wender, die jedoch von FallzuFallvariiertwerden
können.
Prozessorientierte Benutzerführung
bei klinischen Pfaden
Es ist typisch für die ärztliche Vorgehens- und
Denkweise, dass diagnostische oder therapeutische
Tätigkeiten als ,,Weg“ bzw. Prozess verstanden
werden, entlang dessen immer wieder (Auswahl)-
Entscheidungen getroffen werden müssen. Bietet
ein poIS einem Arzt die jeweils anstehenden rele-
vanten Auswahlentscheidungen und Funktionen
an, wird dieser mit einem solchen System sehr
rasch zurechtkommen (sofern die Bedienoberfläche
adäquat gestaltet ist). Abbildung 1veranschaulicht,
wie man sich eine einfach gestaltete ,,Arbeitsliste“
eines Arztes vorstellen kann. Zum einen sieht er
alle aktuell für ihn anstehenden Aufgaben (oberes
Teilfenster in Abb. 1), zum andern kann er auch in
einen Prozess ,,hineinsehen“ und sich den aktuellen
Zustand des Prozesses anzeigen lassen (unteres
Teilfenster in Abb. 1). Auf diese Weise können sich
Ärzte und Krankenschwestern jederzeit ein Bild
vom bisherigen Behandlungsverlauf und von den als
nächstes anstehenden Schritten verschaffen. Gleich-
zeitig unterstützen solche Systeme die medizinische
Dokumentation und sind darüber hinaus auch in der
Lage, die Bereitstellung der benötigten Ressourcen
zu koordinieren.
Abbildung 2illustriert, wie ein Arzt in seinem
Entscheidungsprozess unterstützt werden kann.
Sie zeigt eine mögliche Benutzeroberfläche, nach-
dem eine Aktivität in der Arbeitsliste ausgewählt
wurde. Auf der rechten Seite wird hier ein Aus-
schnitt aus dem Behandlungsverlauf angezeigt
und auf der linken Seite werden die durchzufüh-
renden Untersuchungen zur Auswahl angeboten.
{NAVIGIEREN STATT MODELLIEREN
Abb.1 Visualisierung von Prozessen und Arbeitslisten für Endanwender
Abb.2 Durchführung einer Aufgabe aus der Arbeitsliste und Festlegung des weiteren Prozessverlaufs
Im konkreten Fall sieht der klinische Pfad stan-
dardmäßig die Durchführung einer Röntgen-
und einer MRT-Untersuchung für den Patienten
vor.
Das Anzeigen dieser Tätigkeiten geht in der
Regel weit über eine reine Erinnerungsfunktion hin-
aus. Meist werden bei der Auswahl einer bestimmten
Untersuchung Aufgaben wie Terminvereinbarung,
Reservierung von medizinischen Geräten, Anzeige
der Patientenakte usw. automatisch vom poIS ange-
stoßen und durchgeführt. Auf diese Weise kann das
medizinische Personal von vielen administrativen
Tätigkeiten entlastet werden.
Wie eingangs erwähnt, muss das medizini-
sche Personal jedoch auch die Möglichkeit haben,
im Bedarfsfall vom klinischen Pfad abzuweichen.
Die dafür notwendigen Aktionen von Seiten der
Fachanwender müssen intuitiv sein und sollten
sich nach Möglichkeit auf das Einblenden weiterer
Alternativen und das Setzen zusätzlicher Haken bei
der gewünschten Untersuchung beschränken. Eine
derartige, scheinbar simple Änderung kann jedoch
komplexe technische Auswirkungen haben, die vor
den Fachanwendern komplett verborgen bleiben
müssen. Wie man poISe so einrichten kann, dass
sie jeweils die relevanten Auswahlentscheidungen
darstellen und den Prozess in Abhängigkeit der
ärztlichen Entscheidungen (neu) ausrichten, ist
Gegenstand der folgenden Abschnitte.
GuardedProcess Spaces:
Prozessmodellierung nach dem
Navigationsparadigma
Klinische Pfade lassen sich in Module zerlegen, die
wiederum eine Vielzahl einzelner Behandlungs-
schritte zusammenfassen und meist nicht nur in
einem Pfad, sondern in vielen Pfaden zum Einsatz
kommen können. Sind diese Module identifiziert
und technischimplementiert, können sie vonÄrzten
zu neuen klinischen Pfaden kombiniert oder zur
Anpassung vorhandener Pfade genutzt werden. Die
Herausforderung liegt nun darin, die Fachanwender
bei der Komposition dieser Module nicht sich selbst
zu überlassen, sondern die Komposition so zu
steuern, dass mit minimalem manuellem Aufwand
ein ausführbarer Prozess entsteht, der im Hinblick
auf Kontroll- und Datenflüsse korrekt ist. Um das zu
erreichen, haben wir mit ,,Guarded Process Spaces“
(GPS) ein Werkzeug entwickelt, das es Endanwen-
dern ermöglicht, ausführbare Prozesse nach dem
Navigationsparadigma zu kreieren. Gegenüber dem
Modellierer verhält sich ein GPS wie ein Naviga-
tionssystem, das seinem Nutzer mögliche Routen
aufzeigt, um von der aktuellen Position zu einem
gewünschten Ziel zu gelangen. Den Weg vom Aus-
gangspunkt bis hin zum Ziel muss der Modellierer
in der Regel über mehrere Etappen zurücklegen.
Am Ende einer jeden Etappe präsentiert der GPS
die alternativen Routen, um von dort aus das Ziel
zu erreichen. Mit jeder Etappe nimmt hierdurch die
Menge an Auswahlmöglichkeiten kontinuierlich ab.
Die auf dieseWeise festgelegteRoute vomStartpunkt
bis hin zum Ziel repräsentiert einen bestimmten
ausführbaren klinischen Pfad.
Der GPS gibt eine grobe, hierarchische Struk-
tur vor, in der die Pfadmodule und die jeweiligen
Auswahlmöglichkeiten angeordnet sind. Jedes Pfad-
modul kann weitere Module oder auch bereits
konkrete Aufgaben umfassen. Der Prozessmodel-
lierer navigiert also durch den GPS, um z. B. einen
Standardprozess für die stationäre Behandlung
von Wirbelsäulenerkrankungen zu entwickeln.
Alle Aufgaben, die er im GPS auswählt, werden
im resultierenden Prozessmodell vorhanden sein.
Abbildung 3visualisiert eine mögliche Grundstruk-
tur für einen GPS zur Entwicklung verschiedener
klinischer Pfade in einer Einrichtung.
Auf oberster Ebene unterteilt der GPS klinische
Pfade in Aufnahmetag, OP-Tag, post-operativer Tag
1–nusw. Bei der Erstellung eines klinischen Pfads
für Wirbelsäulenerkrankungen entscheidet der
Prozessmodellierer z.B., dass es einen Aufnahmetag
geben soll; durch diese erste Auswahlentscheidung
werden die Module ,,Administrative Aufnahme“ und
,,klinische Diagnostik“ für die weitere Konfiguration
freigeschaltet. Bei der administrativen Aufnahme
handelt es sich um Routinetätigkeiten, die immer
gleich ablaufen und daher vom Modellierer nicht
weiter konfiguriert werden müssen. Bei der klini-
schen Diagnostik hingegen kann der Modellierer
die nötigen radiologischen und labortechnischen
Untersuchungen auswählen. Seine Wahl bestimmt,
wie der ausführbare Prozess aussieht, der nach
Abschluss der Modellierungsarbeiten automatisch
für das Ziel-PMS generiert wird. Indem der GPS es
erlaubt, Wechselwirkungen zwischen Pfadmodulen
und Aufgaben zu definieren,wird der Prozessmodel-
lierer davon entlastet, selbst die logische Reihenfolge
der Aktivitäten festzulegen. Auch um die korrekte
datentechnische Versorgung der Anwendungskom-
ponenten, die später vom poIS beim Starten einer
Aufgabe ausgeführt werden, muss er sich nicht
kümmern.
Was die Benutzeroberfläche für die Modellie-
rung klinischer Pfade nach dem Navigationspara-
digma angeht, muss sich die Art der Darstellung
im Prinzip nicht von der Darstellung bei der spä-
teren Ausführung des Pfads unterscheiden. Das
{NAVIGIEREN STATT MODELLIEREN
Abb.3 Grundstruktur zur Festlegung eines klinischen Behandlungspfades
heißt, wenn der Prozessmodellierer festlegt, wel-
che konkreten radiologischen Untersuchungen
im klinischen Pfad durchzuführen sind, hat er
im Wesentlichen dieselbe Benutzeroberfläche vor
Augen wie die Ärztin, die den Pfad für ihren Pa-
tienten später instanziiert. In unserem Beispiel
könnte es sich also in beiden Fällen um die in Abb. 2
gezeigte Oberfläche handeln. Der einzige Unter-
schied ist, dass der Modellierer noch alle Aus- und
Abwahlentscheidungen treffen muss, während die
behandelnde Ärztin bereits anhand der gesetzten
Häkchen erkennt, welche Untersuchungen stan-
dardmäßig vorgesehen sind. Trotzdem muss sie die
Freiheit haben, die Auswahl im Sinne ihres Patienten
nachträglich zu verändern. Wie wir noch zeigen
werden, unterstützt der GPS Endanwender auch bei
der flexiblen Anpassung eines klinischen Pfads zur
Laufzeit.
Prozessmodellierung nach dem Navigationspa-
radigma ermöglicht es somit Anwendern, mental
vollständig in ihrer vertrauten Denkwelt zu bleiben
und lediglich die Aktivitäten zu bestimmen, die
ausgeführt werden sollen. Alle daraus folgenden
,,technischen“ Aspekte werden quasi ,,im Ver-
borgenen“ auf Ebene des GPS geregelt. Der GPS
,,weiß“ auch, welche Aufgaben von anderen Ak-
tivitäten abhängen oder welche sich gegenseitig
ausschließen. Auf diese Weise lassen sich – ähnlich
dem ,,Correctness-by-Construction“-Prinzip von
ADEPT [5,13] – bestimmte Modellierungsfehler
automatisch verhindern.
Dynamische Prozessänderung
aus Anwendersicht
Die Instanziierung und Ausführung eines klinischen
Pfads basiert auf der Konfiguration des GPS für
einen bestimmten Zweck, wie z.B. die Behandlung
von Wirbelsäulenerkrankungen. Je nachdem, wie
allgemein der GPS gestaltet wird, kann der GPS
anders konfiguriert werden, um andere Diagnosen
zu behandeln. Genau dieses Prinzip kann man
sich auch zunutze machen, um Standardprozesse
dynamisch zu verändern. Die Anpassung von
Prozessinstanzen erfolgt im Prinzip auf dieselbe
Art und Weise, wie auch der klinische Pfad initial
erstellt wurde: Der Anwender lässt sich vom GPS
(zusätzliche) Routen anzeigen und wählt daraus die
Gewünschte aus.
Bei den erforderlichen Änderungen am kli-
nischen Pfad kann zwischen ,,einfachen“ und
,,komplexen“ Abweichungen unterschieden wer-
den. Bei einfachen Abweichungen werden z. B.
einzelne Aktivitäten abgewählt, die in der Stan-
dardkonfiguration vorhanden sind; oder umgekehrt
Abb. 4 Ad-hoc Änderung der Konfiguration des GPS
selektiert man Aktivitäten, die im Standardablauf
nicht vorkommen. Mit einfachen Abweichungen
lassen sich also im Bedarfsfall z. B. Art und Anzahl
der radiologischen Untersuchungen variieren. Ab-
bildung 3illustriert einen GPS, der standardmäßig
so konfiguriert ist, dass eine Röntgenuntersuchung
und ein MRT durchgeführt werden. Um aber z.B.
einen wiederkehrenden Bandscheibenvorfall von
einer postoperativen Vernarbung unterscheiden
zu können, sind andere Maßnahmen erforderlich.
Der behandelnde Arzt muss hierfür am Patienten
eine Myelografie und anschließend zwei Rönt-
genuntersuchungen vornehmen. Das bedeutet, er
muss den Navigationspunkt ,,Radiologie“ des GPS
rekonfigurieren. In unserem Beispiel deselektiert
er die Aktivität ,,MRT“ und wählt stattdessen die
Aktivität ,,Myelografie“ unterhalb des Navigations-
punktes aus. Auch die Aktivität ,,Röntgen“ wird
rekonfiguriert, indem die Anzahl der Röntgenun-
tersuchungen auf zwei erhöht wird; die maximale
Anzahl, mit der eine Aktivität ausgeführt werden
kann, hängt dabei von der im GPS eingestellten
Knotenkardinalität ab. Mithilfe von im GPS im GPS
hinterlegten Constraints wird im Beispiel system-
seitig außerdem beachtet, dass die Myelografie,
also das Spritzen eines Kontrastmittels, vor den
beiden Röntgenuntersuchungen stattfinden muss.
Abbildung 4zeigt die veränderte Konfiguration
des GPS.
Nach dieser Rekonfiguration enthält der
klinische Pfad des Patienten nun die Aktivität Mye-
lografie gefolgt von zwei Röntgenuntersuchungen.
Die Benutzeroberfläche für den Arzt muss derart
gestaltet sein, dass einfache Abweichungen bzw. Re-
konfigurationen mit minimalem Aufwand realisiert
werden können, etwa durch das Setzen und Ent-
fernen von Häkchen bei möglichen radiologischen
Untersuchungen, wie in Abb. 2dargestellt.
Wie bereits aus dem Beispiel ersichtlich wurde,
setzt die Rekonfiguration bei einfachen Abweichun-
gen sehr weit unten in der baumartigen Hierarchie
des GPS an, nämlich bei solchen Navigationspunk-
ten, die nur noch über elementare Aktivitäten als
Nachfolger verfügen. Das Selektieren und Deselek-
tieren von Aktivitäten hat dementsprechend direkte,
einfach nachvollziehbare Auswirkungen auf die
Gestaltung des klinischen Pfads: Wird z. B. eine Ak-
tivität unterhalb eines Navigationspunktes im GPS
entfernt, verschwindet sie auch aus dem Pfad bzw.
der Pfadinstanz des Patienten. Es braucht nicht viel
Phantasie, um sich vorstellen zu können, dass die
Rekonfiguration von Navigationspunkten, die höher
in der Hierarchie des GPS angesiedelt sind, zu sehr
viel komplexeren Abweichungen im Prozess führen.
{NAVIGIEREN STATT MODELLIEREN
Abb.5 Konfiguration des GPS nach Anwendung einer Prozessvariante
Wählt man beispielsweise statt dem Navigations-
punkt ,,Radiologie“ schon die nächst höhere Ebene
,,Klinische Diagnostik“ zur Rekonfiguration aus, so
wirkt sich dies nicht nur auf sämtliche radiologische
Untersuchungen, sondern auch auf das gesamte
Labor aus. Noch einschneidender sind Änderungen
auf Ebene des stationären Behandlungstags oder gar
der Rekonfiguration des Wurzelknotens des GPS.
Änderungen an solchen Stellen können die radikale
Neuordnung ganzer Prozessabschnitte zur Folge
haben. Je stärker die organisatorische Planung der
Patientenbehandlung auf IT-technisch realisierten
klinischen Pfaden basiert, desto gefährlicher kön-
nen die Konsequenzen komplexer Abweichungen
werden. Nichtsdestotrotz sind solche Abweichungen
medizinisch immer wieder indiziert; bei Diabe-
tespatienten mit erhöhtem Komplikationsrisiko
müssen z. B. ein Blutzuckertagesspiegel erstellt,
Antibiosemaßnahmen ergriffen und die Versorgung
mit Insulin während der Operation sichergestellt
werden. Selbst wenn sich die Änderungen in sol-
chen Fällen auf mehrere einfache Abweichungen
reduzieren lassen, besteht durch ihre Vielzahl doch
die Gefahr, dass notwendige Aktivitäten überse-
hen werden und daher nicht im klinischen Pfad
vorkommen.
Der GPS bietet dank seiner Constraints be-
reits eine Möglichkeit, Abhängigkeiten zwischen
Aktivitäten zu erzwingen und Rekonfiguratio-
nen automatisch zu vervollständigen. Um aber die
Durchführung von komplexen Abweichungen oder
einer Vielzahl von kleineren Abweichungen für
die Benutzer so einfach wie möglich zu machen,
wurde auf Basis von GPS auch ein Konzept für
sogenannte ,,Prozessvarianten“ entwickelt. Pro-
zessvarianten bieten die Möglichkeit, Maßnahmen
zur Rekonfiguration von GPS vorzudefinieren; d. h.
jede Variante besteht aus einer Kette von einzelnen
Änderungsmaßnahmen, die dazu führen, dass
der GPS in der gewünschten Weise automatisch
rekonfiguriert und der klinische Pfad des Patienten
entsprechend angepasstwird. Neben demklinischen
Pfad als Standardprozess können also Prozess-
varianten für besonders häufig vorkommende
Abweichungsursachen (wie z.B. Nebendiagnosen
oder Komplikationen) zur Verfügung gestellt wer-
den. Damit beschränkt sich die Durchführung von
komplexen Abweichungen für die Benutzer auf die
Auswahl einer Prozessvariante. Angenommen, es
wurde eine Prozessvariante für Patienten mit Diabe-
tes mellitus angelegt. In unserem konkreten Beispiel
führt die Anwendung dieser Variante dazu, dass
das Labor am Aufnahmetag um einen Blutzuckerta-
gesspiegelerweitert, am OP-Tag Insulininjektionen
vorbereitet und jeden Tag Antibiosemaßnahmen
vorgesehen werden, um das Infektionsrisiko zu mi-
nimieren. Abbildung 5verdeutlicht beispielhaft, wie
sich die Modifikationen der Prozessvariante durch
den gesamten GPS ziehen. Die Variante ermöglicht
sowohl das Einfügen einmaliger Aktivitäten, wie
z. B. die Erweiterung des Standardlabors am Auf-
nahmetag um einen Blutzuckerspiegel, als auch die
Einplanung wiederkehrender Maßnahmen, wie z. B.
Antibiose bis zur Entlassung des Patienten.
Grundsätzlich können Prozessvarianten zur au-
tomatischen Anpassung von allen klinischen Pfaden
verwendet werden, die auf der Konfiguration des-
selben GPS beruhen. So können Vorerkrankungen
wie Diabetes mellitus unabhängig von der aktuell
zu behandelnden Diagnose berücksichtigt werden.
Da im medizinischen Alltag auch Abweichungen
nicht immer gleich sind – z. B. können nicht alle
Diabetespatienten identisch behandelt werden –
wird in [15] ein Konzept vorgestellt, das Prozessva-
rianten selbst wieder als GPS realisiert. In diesem
Fall können die Anwender sogar Einfluss darauf
nehmen, wie eine Variante in einem konkreten
Behandlungsfall zu wirken hat. Die Vorgehensweise
bei der Konfiguration von Prozessvarianten ist dann
exakt dieselbe wie bei der Modellierung klinischer
Pfade. Im Prinzip kann daher dieselbe Technologie
mit denselben Benutzeroberflächen verwendet
werden.
Wie die manuelle Rekonfiguration kann auch
eine Prozessvariante einen klinischen Pfad nur so
verändern, wie es der GPS zulässt; d. h. die Variante
Abb. 6 Entwicklung ausführbarer Prozesse auf Basis des GPS
muss den Vorgaben bei der Prozessgestaltung ent-
sprechen, die sich z. B. aus der Knotenhierarchie
oder den Constraint-Definitionen des GPS ergeben.
Es können natürlich aber auch Situationen auftreten,
die die Durchführung von Aktivitäten erforderlich
machen, die im GPS nicht vorgesehen sind. Um
auch auf solche Fälle reagieren zu können, ist es
möglich, in allen Teilbereichen des GPS Aktivitä-
ten zur Auswahl zu stellen, die es Endanwendern
erlauben, die aufgetretene Varianz und die ergrif-
fenen Maßnahmen im Prozessablauf textuell zu
dokumentieren. Auf diese Weise kann einerseits
weiterhin prozessorientiert gearbeitet werden und
andererseits wird deutlich, an welchen Stellen der
GPS noch unvollständig ist und ergänzt werden
muss.
Implementierung
von Guarded Process Spaces
Abbildung 6illustriert, wie Prozessmodellierung
nach dem Navigationsparadigma technisch reali-
siert wird. GPS werden als baumartig strukturierte
Graphen implementiert. Die Knoten des Graphen
repräsentieren entweder Navigationspunkte oder
konkrete Prozessaktivitäten. Jeder Navigations-
punkt ist mit einem logischen Operator verknüpft,
wie etwa AND, OR, XOR und OPT (für optional).
Die Operatoren diktieren die Regeln, nach denen die
{NAVIGIEREN STATT MODELLIEREN
untergeordneten Knoten eines Navigationspunkts
ausgewählt werden können. Zum Beispiel ist der
Wurzelknoten des GPS in Abb. 6,,Klinische Dia-
gnostik“ mit einem AND-Operator versehen, was
bedeutet, dass automatisch alle Nachfolgerknoten
selektiert werden. Dem OR-Operator zufolge muss
unterhalb des Navigationspunktes ,,Radiologie“
mindestens eine Aktivität ausgewählt werden.
Die Knoten unterhalb des Navigationspunktes
,,Diabetes mellitus“ müssen aufgrund des OPT-
Operators hingegen nicht selektiert werden. Die
Knotenkardinalität gibt an, dass der Navigations-
punkt ,,Radiologie“ einschließlich seiner Nachfolger
bis zu zwei Mal in einer Konfiguration des GPS
vorkommen darf; dasselbe gilt zusätzlich für die
Aktivitäten ,,Röntgen“, ,,MRT“ und ,,CT“. Mithilfe
von Knotenkardinalitäten ist es also möglich, Schlei-
fen im Prozess zu modellieren. Zur Diagnostik
von Wirbelsäulenerkrankungen werden neben
dem Standardlabor üblicherweise eine Röntgen-
und eine MRT-Untersuchung durchgeführt. Wegen
des Sequence-Constraints soll das Labor vor der
Radiologie stattfinden. Der Requirement-Constraint
hingegen besagt, dass die zusätzlichen Laborunter-
suchungen bezüglich einer Diabetesvorerkrankung
nur dann durchgeführt werden dürfen, wenn das
Standardlabor erledigt ist. Durch den Einsatz von
OPT-Operatoren und das Weglassen von Constraints
lässt sich die Flexibilität bei der Prozessgestaltung
maximieren. Dies ist insbesondere dann sinnvoll,
wenn man nicht zuviel Zeit in die Prozessdefinition
investieren, sondern die verschiedenen Prozessab-
läufe lieber in der Praxis evaluieren möchte. Dieses
Maximum an Flexibilität ist jedoch auch mit dem
höchsten Aufwand für die Endanwender verbunden,
da sie jede Aktivität manuell auswählen müssen.
Eine Anreicherung des GPS durch Constraints und
der Einsatz von anderen Operatoren führen dann
zu einem höheren Maß an Effizienz durch mehr
Standardisierung.
Um sicherzustellen, dass die Einstellungen
in den Navigationspunkten tatsächlich zu kor-
rekten Prozessmodellen führen, wurden in [15]
formale Korrektheitskriterien für GPS definiert.
Diese Kriterien verhindern unter anderem, dass
Constraints im Widerspruch zur Struktur des GPS
oder den logischen Operatoren stehen. Aufgrund
der Flexibilitätsoptionen bei der Modellierung
und Anpassung klinischer Pfade kann die Art und
Anzahl der Datenobjekte, die zur Laufzeit erzeugt
werden, variieren. In [15] wird für jede Anwen-
dungskomponente, die mit Prozessaktivitäten
verknüpft sein kann, eine Schnittstellendefi-
nition angegeben, die auch die erforderlichen
oder optionalen Datenobjekte spezifiziert.
Darüber hinaus wird beschrieben, wie Datenab-
hängigkeiten auf Basis des GPS berücksichtigt
werden können.
Je mehr generelles Wissen in einem GPS
hinterlegt wird, desto einfacher werden die Pro-
zessmodellierung und damit die Generierung
ausführbarer Prozesse durch die Fachanwender.
Um die Entwicklung klinischer Pfade so einfach
zu machen wie oben beschrieben, müssen GPS
alle möglichen Prozessaktivitäten, Entscheidungs-
optionen und Constraints der betrachteten Anwen-
dungsdomäne enthalten. Das Nutzenpotenzial und
die Akzeptanz von GPS hängen deshalb stark davon
ab, wie gut der GPS die Prozessaspekte der Domäne
abdeckt. Aus diesem Grund müssen Endanwender
von vornherein an der Entwicklung von GPS betei-
ligt werden. Die technische Umsetzung des GPS, die
Implementierung ausführbarer Anwendungskom-
ponenten für Prozessaktivitäten oder die Feinheiten
des Datenflusses werden hingegen weiterhin in
der Verantwortung entsprechender IT-Spezialisten
liegen. Um die Komplexität der GPS-Erstellung zu
reduzieren, bietet sich ein iteratives Vorgehen an,
bei dem der GPS erst grob entworfen und nach
jeder Validation zusammen mit den Endanwendern
weiter ausgearbeitet wird. Dabei kann auch der
Handlungsspielraum zwischen Flexibilität und
Standardisierung, den GPS bieten, gezielt genutzt
werden.
Ein wichtiges Ziel bei der Entwicklung von
GPS besteht in der Separierung der Modellierung
und Änderung klinischer Prozesse von spezifischen
Prozesstechnologien bzw. PMS. Aus diesem Grund
sind die Modelle zur Abbildung des GPS und die
daraus abgeleiteten Prozessmodelle und -varianten
systemneutral. Die Transformation in ausführbare
Prozesse gemäß definierten Prozessmodellie-
rungssprachen erfolgt nach formal spezifizierten
Regeln. GPS gestatten im Prinzip die Nutzung unter-
schiedlicher technischer Realisierungsoptionen, um
Prozessflexibilität zu erreichen. Vorstellbar sind z.B.
der Einsatz von bedingten Verzweigungen, Late-
Binding-Mechanismen [1], Variationspunkten [9],
deklarativen [12] oder adaptiven PMS [13]. Aller-
dings führen bedingte Verzweigungen schnell zu
Abb.7 Alternativen zur technischen Realisierung kleinerer Abweichungen vom Standardprozess in ADEPT2
sehr komplexen Prozessmodellen mit einem hohen
Anteil von Redundanz, wie das folgende Beispiel
veranschaulicht.
Abbildung 7illustriert die zwei unterschied-
lichen Optionen, wie der Navigationspunkt
,,Radiologie“ des GPS aus Abb. 6in ein ausführ-
bares Prozessmodell umgewandelt werden kann.
Die erste Alternative zeigt, wie bedingte Verzwei-
gungskonstrukte genutzt werden können, um die
im GPS definierten Möglichkeiten in eine konkrete
Prozessstruktur zu übersetzen. Dabei muss ein
komplexes Konstrukt, bestehend aus einer paralle-
len und vier separaten bedingten Verzweigungen,
erzeugt werden. Aufgrund der Knotenkardinalitä-
ten sind teilweise zusätzlich Schleifenkonstrukte
notwendig. Die zweite Alternative demonstriert,
wie man verfahren kann, wenn man den Prozess
zur Ausführungszeit flexibel um Untersuchungen
ergänzen darf. Der Standardprozess sieht ledig-
lich eine Röntgen- und eine MRT-Untersuchung
vor. In Abb. 7a hat die Ausführung des Prozesses
bereits begonnen. Die Röntgenuntersuchung ist
beendet und die MRT-Untersuchung läuft. Die
behandelnde Ärztin entscheidet sich für eine zu-
sätzliche CT-Untersuchung. Da das Röntgen bereits
abgeschlossen und die MRT-Untersuchung schon
gestartet ist, wird die CT-Untersuchung nicht mehr
parallel, sondern sequenziell hinter den anderen
Aktivitäten eingefügt (siehe Abb. 7b). Wie dieses
Beispiel andeutungsweise zeigt, vereinfacht die
Nutzung ,,echt“ adaptiver PMS die Abbildung zwi-
schen GPS und technischem Prozessmodell ganz
erheblich; darüber hinaus sind Abweichungen
konsequent nachvollziehbar und die Flexibilität
nimmt zu, weil zusätzliche Aktivitäten zu beliebi-
gen Zeitpunkten in das Modell eingefügt werden
können.
Da Late-Binding-Mechanismen und Variati-
onspunkte Flexibilität zur Laufzeit nur in einem
sehr eingeschränkten Umfang zulassen, wurde für
die prototypische Evaluierung des Konzepts als Im-
plementierungsplattform das PMS ADEPT2 [5,13]
bzw. seine kommerzielle Version, die Aristaflow®
BPM Suite [21] eingesetzt, da dieses aufgrund seiner
mächtigen API-Funktionen und seinen umfassen-
den Fähigkeitenin Bezug auf Ad-hoc-Abweichungen
derzeit die optimalen Voraussetzungen für die
Unterstützung GPS-basierter klinischer Pfade bietet
(siehe [15,17] für technische Details).
Zusammenfassung
und abschließende Bemerkungen
Trotz ihrer Potenziale im Hinblick auf Qualitäts-
sicherung, Kostenkontrolle und Reduktion des
administrativen Arbeitsaufwandes werden PMS
in Krankenhäusern bisher selten eingesetzt. Um
{NAVIGIEREN STATT MODELLIEREN
vom medizinischen Personal akzeptiert zu werden,
müssen die Systeme die folgenden Anforderungen
erfüllen: Erstens müssen Endanwender die Möglich-
keit haben, selbständig korrekte und ausführbare
technische Prozessmodelle zu erstellen. Zweitens
müssen sie in der Lage sein, Prozesse auch zur
Ausführungszeit flexibel an die Bedürfnisse ihrer
Patienten anzupassen. Mit Guarded Process Spaces
(GPS) haben wir hier eine Lösung vorgestellt, die es
Endanwendern ermöglicht, Prozesse nach dem Na-
vigationsparadigma zu entwickeln und zu ändern.
Wir haben gezeigt, wie GPS die Endanwender bei
der Auswahl der Prozessaktivitäten unterstützen,
wie sie die Einhaltung bestimmter Bedingungen
und Abhängigkeiten gewährleisten und wie die
zugrunde liegende technische Umsetzung aussieht.
Die Lösung basiert auf einem formalen Konzept, das
bereits prototypisch realisiert wurde, hier aber aus
Platzgründen nur in Ausschnitten präsentiert wer-
den konnte. Eine ausführliche Beschreibung findet
sich in [15]. Bei GPS handelt es sich nicht um eine
zusätzliche domänenspezifische Modellierungsspra-
che, sondern vielmehr um eine neue, alternative
Herangehensweise an die Prozessmodellierung, die
die Möglichkeit zur flexiblen Prozessadaption zur
Laufzeit einschließt. Sie ist im Prinzip unabhängig
von einer bestimmten Prozesstechnologie, erfordert
aber – um das volle Leistungsspektrum der GPS nut-
zen zu können – Prozess-Management-Systeme, die
hinsichtlich Ad-hoc-Abweichungen wesentlich über
das hinausgehen, was heutige Systeme üblicherweise
anbieten [6].
Die meisten der in [15] beschriebenen Konzepte
wurden im Rahmen des SPOT-Projektes [24]als
,,Proof-of-Concept“-Prototyp implementiert und
damit die grundsätzliche Machbarkeit des An-
satzes demonstriert. Darüber hinaus wurden die
Benutzerschnittstellen (siehe Screen-Casts SPOT-
Demonstrator [25]) in enger Zusammenarbeit mit
Ärzten und Pflegepersonal diskutiert. Das sehr
positive Feedback stimmt uns zuversichtlich, dass
der in diesem Beitrag vorgeschlagene Weg sehr viel-
versprechend ist, wobei ein ,,echter“ Praxistest mit
,,echten“ Akzeptanzstudien natürlich erst mit einem
erheblichvollständigerimplementiertenSystem und
entsprechend ,,vollständigem“GPS möglich ist. Dies
gilt natürlich auch für die Beurteilung des Aufwands
sowie die Entwicklung einer geeigneten Vorgehens-
weise zur Erstellung eines echten, praxistauglichen
GPS.
Literatur
1. Adams M, ter Hofstede AHM, Edmond D, van der Aalst WMP (2006) Worklets:
a service-oriented implementation of dynamic flexibility in workflows. In: Proc
CoopIS 2006, 14th Int Conf on Cooperative Information Systems, Montpellier,
France, Oct/Nov 2006, LNCS 4275:291–308
2. Beccuti M, Bottrighi A, Franceschinies G, Montani S, Terenziani P (2009) Modeling
clinical guidelines through Petri Nets. In: Proc AIME’09, 12th Conf on Artificial In-
telligence in Medicine, Verona, Italy, Aug 2009, LNCS 5651:61–70
3. Becker J, Pfeiffer D, Räckers M (2007) Domain specific process modelling in pu-
blic administrations – the PICTURE-approach. In: Proc EGOV 2007, 6th Int Conf on
Electronic Government, Regensburg, Germany, Sep 2007, LNCS 4645:68–79
4. Conradi R, Jaccheri ML () Process modelling languages. In: Software Process: Prin-
ciples, Methodology, and Technology, LNCS 1500:27–52
5. Dadam P, Reichert M (2009) The ADEPT project: a decade of research and deve-
lopment for robust and flexible process support. Comp Sci Res Dev 23(2):81–98
6. Dadam P, Reichert M, Rinderla-Ma S (2011) Prozessmanagementsysteme: nur ein
wenig Flexibilität wird nicht reichen. Informatik-Spektrum 4:364–376
7. De Clearcq P, Kaiser K, Hasman A (2008) Computer-interpretable guideline for-
malisms. In: Computer-based medical guidelines and protocols: a primer and cur-
rent trends. IOS Press, pp 22–43
8. Freudenstein P, Buck J, Nussbaumer M, Gaedke M (2007) Model-driven construc-
tion of workflow-based web applications with domain-specific languages. In: Proc
MDWE’07, 3rd Int Workshop on Model-driven Web Engineering, Milano, Italy,
2007, /CEUR-WS/Vol-261/paper02
9. Hallerbach A, Bauer T, Reichert M (2009) Configuration and management of pro-
cess variants. In: Handbook of Business Process Management, Bd 1, Springer,
pp 237–256
10. Mernik M, Heering J, Sloane AM (2005) When and how to develop domain-
specific languages. ACM Comp Surv 37(2):316–344
11. Neuhaus J, Houta S, Reuter C (2010) Ansätze bei der Umsetzung von Behand-
lungsplanpfaden – Flexibilisierungskonzepte am Beispiel der Behandlung von
Wirbelsäulenerkrankungen. In: Ambulante und Sektoren übergreifende Behand-
lungspfade, Medizinisch Wissenschaftliche Verlagsgesellschaft, Berlin, S 79–97
12. Pesic M, Schonenberg MH, Sidorova N, van der Aalst WMP (2007) Constraint-
based workflow models: change made easy. In: Proc CoopIS 2007, 15th Int Conf
on Cooperative Information Systems, Vilamoura, Portugal, Nov. 2007, LNCS 4803:
77–94
13. Reichert M, Dadam P (1998) ADEPTflex – supporting dynamic changes of work-
flows without losing control. J Intell Inf Sys 10:93–128
14. Reichert M, Weber B (2012) Enabling Flexibility in Process-Aware Information Sys-
tems. Springer
15. Reuter C (2011) Modellierung und dynamische Adaption klinischer Pfade auf Ba-
sis semantischer Prozessfragmente. Dissertation, TU Dortmund
16. Reuter C, Dadam P, Rudolph S, Deiters W, Trillsch S (2011) Guarded Process
Spaces (GPS): a navigation system towards creation and dynamic change of
healthcare processes from the end-user’s perspective. In: Proc BPM 2011 Int
Workshops, Clermont-Ferrand, France, August 2011, LNBIP 100:237–248
17. Rudolph S (2010) Semantische Komposition von Prozessfragmenten im Umfeld
dynamischer Prozessmodellierung. Diplomarbeit, TU Dortmund
18. Strembeck M, Zdun U (2009) An approach for the systematic development of
domain-specific languages. Softw Pract Exp 39:1253–1292
19. Svenson K (ed) (2010) Mastering the Unpredictable. How Adaptive Case Mana-
gement will Revolutionize the Way That Knowledge Workers get Things Done.
Meghan-Kiffer Press, Tampa, Florida
20. Weber B, Sadiq S, Reichert M (2009) Beyond rigidity – dynamic process lifecycle
support – a survey on dynamic changes in process-aware information systems.
Comp Sci Res Dev 23(2):47–66
21. http://www.AristaFlow.com, letzer Zugriff 9.10.2012
22. http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html,letzerZugriff
9.10.2012
23. http://www.omg.org/spec/BPMN/, letzer Zugriff 9.10.2012
24. http://www.spot.fraunhofer.de/Anwendungsbereiche/Gesundheit/,letzerZugriff
9.10.2012
25. http://www.spot.fraunhofer.de/Anwendungsbereiche/Gesundheit/screencast-
gesundheit.jsp, letzer Zugriff 9.10.2012
