Embed Size (px)
Citation preview
Wissensbasierte Systeme
zur Unterstützung der Therapie
auf Intensivstationen
Aus dem Institut für Medizininformatik, Biometrie und Epidemiologie
Lehrstuhl für Medizinische Informatik
der Friedrich-Alexander-Universität Erlangen-Nürnberg
Direktor: Prof. Dr. biol. hom. H.-U. Prokosch
Der Medizinischen Fakultät
der Friedrich-Alexander-Universität
Erlangen-Nürnberg
zur
Erlangung des Doktorgrades Dr. rer. biol. hum.
vorgelegt von
Stefan Kraus
aus Nürnberg
Als Dissertation genehmigt
von der Medizinischen Fakultät
der Friedrich-Alexander-Universität Erlangen-Nürnberg
Tag der mündlichen Prüfung: 19.3.2014
Vorsitzender des Promotionsorgans:
Prof. Dr. med. Dr. h.c. Jürgen Schüttler
Gutachter:
PD Dr. med. Thomas Bürkle
Prof. Dr. med. Dr. h.c. Jürgen Schüttler
Prof. Dr. Richard Lenz
MEINEM VATER
† 2013
Inhaltsverzeichnis
1 Einleitung .......................................................................................................................... 3
2 Grundlagen....................................................................................................................... 7
2.1 ICM und seine Exportschnittstelle AutoExport ......................................................... 7
2.2 Wissensbasierte Systeme ....................................................................................... 11
2.3 Die Arden Syntax for Medical Logic Systems ........................................................ 15
2.3.1 Medical Logic Modules ..................................................................................... 17
2.3.2 Datentypen der Arden-Syntax .......................................................................... 20
2.4 Das EAV-Datenmodell ............................................................................................ 22
2.5 Die Ergebnisse der Diplomarbeit ........................................................................... 23
2.6 Procalcitonin als Sepsismarker .............................................................................. 25
3 Methoden ....................................................................................................................... 28
3.1 Bereitstellung der technischen Plattform................................................................ 28
3.1.1 Methoden der Analysephase ............................................................................ 29
3.1.2 Methoden der Implementierungsphase ............................................................ 30
3.1.2.1 Datenbereitstellung und Ereigniserkennung .................................................. 31
3.1.2.2 Implementierung des Arden-Servers ............................................................. 33
3.1.2.3 Präsentationsmechanismen ........................................................................... 34
3.2 Methoden der Evaluierungsphase ......................................................................... 36
3.2.1 Die Vorstudie .................................................................................................... 37
3.2.2 Die PCT-Studie ................................................................................................. 38
4 Ergebnisse ..................................................................................................................... 42
4.1 Ergebnisse der technischen Bereitstellung ............................................................ 42
4.1.1 Ergebnisse der Analysephase .......................................................................... 42
4.1.2 Ergebnisse der Implementierungsphase .......................................................... 46
4.1.2.1 Datenbereitstellung und Ereigniserkennung .................................................. 47
4.1.2.2 Bereitstellung des Arden-Servers .................................................................. 49
4.1.2.3 Präsentationsmechanismen ........................................................................... 51
4.2 Ergebnisse der PCT-Studie .................................................................................... 54
4.2.1 Die Vorstudie .................................................................................................... 54
4.2.2 Die PCT-Studie ................................................................................................. 57
4.3 Zusammenfassung der Ergebnisse ....................................................................... 61
5 Diskussion ...................................................................................................................... 65
5.1 Implementierungsphase ......................................................................................... 65
5.1.1 Datenbereitstellung und Ereigniserkennung .................................................... 66
5.1.2 Arden-Server .................................................................................................... 70
5.1.3 Präsentationsmechanismen ............................................................................. 73
5.2 Diskussion der Evaluierungsphase ........................................................................ 75
5.3 Erfahrungen mit der Arden-Syntax ......................................................................... 79
6 Ausblick .......................................................................................................................... 88
7 Abkürzungsverzeichnis .................................................................................................. 89
8 Anhang ........................................................................................................................... 90
8.1 PCT-Raten der Studienphasen .............................................................................. 90
8.2 Publikation zur technischen Anbindung ................................................................. 92
9 Danksagung ................................................................................................................... 93
10 Literaturverzeichnis .................................................................................................... 94
Abbildungsverzeichnis
Abbildung 1: Screenshot der ICM-Tageskurve ........................................................................ 8
Abbildung 2: Grundprinzip von AutoExport .............................................................................. 9
Abbildung 3: Die Funktionsweise von Schlüsselworttermen ................................................. 10
Abbildung 4: Typische Architektur eines medizinischen Expertensystems............................ 12
Abbildung 5: Aufbau eines MLMs .......................................................................................... 17
Abbildung 6: Gundprinzip der Verarbeitung eines MLMs ...................................................... 18
Abbildung 7: Grundprinzip einer Arden-Engine...................................................................... 19
Abbildung 8: Vergleich der konventionellen Modellierung mit dem EAV-Modell .................... 23
Abbildung 9: Architektur des in der Diplomarbeit erstellten Systems .................................... 24
Abbildung 10: Ansatz zur Erkennung von datengesteuerten Ereignissen ............................. 31
Abbildung 11: Herstellung der Mandantenfähigkeit ............................................................... 32
Abbildung 12: Prinzip der Generierung von Tabellen............................................................. 35
Abbildung 13: Phasen der PCT-Studie .................................................................................. 38
Abbildung 14: Ausschnitt aus der Vorschlagsliste ................................................................. 39
Abbildung 15: Architektur des Zielsystems ............................................................................ 43
Abbildung 16: Ersetzungsmechanismus bei Curly-Braces-Methoden ................................... 45
Abbildung 17: Integration über ArdenHostInterface ............................................................... 46
Abbildung 18: Bereitstellung der MiBi-Daten ......................................................................... 47
Abbildung 19: Grundprinzip des Aliaskonzeptes.................................................................... 50
Abbildung 20: Beispiel einer per MLM generierten SMS-Nachricht....................................... 51
Abbildung 21: Screenshot des MLM-Viewers ........................................................................ 52
Abbildung 22: Beispiel für einfache Tabellengenerierung ...................................................... 53
Abbildung 23: Beispiel für Generierung von Lineplots ........................................................... 54
Abbildung 24: Die Bereiche der IOI ....................................................................................... 55
Abbildung 25: Sonderlaboranforderung für einen Patienten der IOI ..................................... 55
Abbildung 26: Häufige Verlaufsform des PCT-Spiegels ......................................................... 56
Abbildung 27: Aggregierte Daten der Studienphasen ............................................................ 57
Abbildung 28: Boxplots der PCT-Raten der Studienphasen .................................................. 58
Abbildung 29: Nutzung des PCT-MLMs nach Tagen ............................................................. 58
Abbildung 30: Vergleich der ON-Phasen bzgl. Neuaufnahmen, SAPS II und APACHE II ..... 59
Abbildung 31: Beispiel eines MLMs für DRG-Coder .............................................................. 83
1
Zusammenfassung
Hintergrund und Ziele
Wissensbasierte Systeme können einen erheblichen Beitrag zu Qualität und Erfolg der Behandlung im
Krankenhaus leisten. Am Universitätsklinikum Erlangen ist ein Patientendatenmanagementsystem
(PDMS) zur intensivmedizinischen Dokumentation im Einsatz, das auf Anforderung der Anwender um
wissensbasierte Funktionen erweitert werden sollte. Das erste Ziel dieser Arbeit bestand in der
Integration einer kommerziellen Ausführungsumgebung für Wissensmodule auf Basis der Arden-
Syntax, einer Sprache zur Repräsentation von medizinischem Wissen, in das PDMS. Das zweite Ziel
bestand in der Evaluierung eines Wissensmoduls zur Erkennung vermeidbarer Laboranforderungen
des Biomarkers Procalcitonin (PCT), der für die Erkennung der Sepsis relevant ist.
Methoden
Da das PDMS die für die Integration erforderlichen Schnittstellen nicht bereitstellte, mussten diese
zunächst implementiert werden. Der Zugriff auf die Patientendaten wurde durch deren periodische
Replikation auf Basis der proprietären Exportschnittstelle des PDMS in eine externe Datenbank
realisiert, die Erkennung von Ereignissen über den Vergleich der Exporte. Zur Präsentation der von
den Wissensmodulen generierten Informationen wurde eine Reihe von Kommunikationsendpunkten
sowie eine Reihe von Präsentationsmechanismen implementiert. Die prospektive Evaluierungsstudie
wurde in einem ON-OFF-ON-OFF-Design durchgeführt. Hierzu wurde in den ON-Phasen ein
Wissensmodul freigeschaltet, das auf Knopfdruck eine Liste von Hinweisen zur Notwendigkeit von
PCT-Messungen auf Basis eines von ärztlicher Seite vorgegebenen Regelsatzes generierte.
Ergebnisse und Beobachtungen
Die Integration der Arden-Syntax-Umgebung in das PDMS konnte erfolgreich durchgeführt werden,
indem die fehlenden Schnittstellen durch Workarounds bereitgestellt wurden. Das resultierende
System erlaubt die benutzer-, zeit- und datengesteuerte Ausführung von Wissensmodulen. Es zeigt
aber eine gewisse Trägheit bei Ereigniserkennung und Datenbereitstellung, die auf seine Abhängigkeit
von periodischen Exporten zurückzuführen ist. Zudem zieht diese Lösung einen erheblichen
Ressourcenverbrauch nach sich. In der Evaluierungsstudie zeigte sich in der ersten ON-Phase ein
ausgeprägter Effekt in Form einer Senkung der täglichen PCT-Messrate. In der zweiten ON-Phase
konnte dieser Effekt nicht mehr beobachtet werden. Dies lässt sich auf nachlassende Nutzung des
Wissensmoduls zurückführen, bedingt durch dessen fehlende Integration in den klinischen Workflow.
Praktische Schlussfolgerungen
Diese Arbeit zeigte, dass die Integration einer Arden-Syntax-Ausführungsumgebung in ein
kommerzielles klinisches System auf der Basis periodischer Exporte zu einem praxistauglichen, wenn
auch etwas reaktionsträgen System führen kann. Allerdings lässt der erhebliche Ressourcenverbrauch
die Forderung nach vollwertigen Schnittstellen laut werden. In der Evaluierungsstudie zeigte sich
hinsichtlich der Anforderung von Labormessungen ein deutliches Einsparpotential durch
entscheidungsunterstützende Wissensmodule. Um die Einsparungen dauerhaft zu erzielen, ist aber
eine entsprechende Worklow-Integration erforderlich. Im weiteren Sinne zeigte sich, dass neuere
Versionen der Arden-Syntax so leistungsfähig sind, dass man einen Einsatz als universelle
Programmiersprache für die medizinische Domäne in Betracht ziehen könnte.
2
Abstract
Background Information and Objectives
Knowledge-based systems can make a significant contribution to the quality and success of hospital
treatment. The University Hospital Erlangen uses a patient management system (PDMS) for
documenting intensive care, which was to be extended by adding knowledge-based functions at the
request of users. The first objective of this thesis was to integrate a commercial runtime environment
for knowledge-based functions in the PDMS on the basis of the Arden Syntax, a language for
representing medical knowledge. The second objective was to evaluate a knowledge module for
identifying unnecessary laboratory requests for the biomarker Procalcitionin, which is relevant for
detecting sepsis.
Methods
The interfaces required for integration had to be implemented initially because these were not provided
by the PDMS. Access to patient data was realized by means of periodic replication in an external
database on the basis of the proprietary export interface provided by the PDMS. Events were detected
by comparing exports. A series of communication end points and presentation mechanisms were
implemented for presenting the information generated by the knowledge modules. The prospective
evaluation study was carried out using an ON-OFF-ON-OFF design. A knowledge module was
accessed in the ON-phases, which generated a list of information about the necessity of PCT
measurements on the basis of a rule set specified by an experienced physician.
Results and Observations
The Arden syntax runtime environment was successfully integrated in the PDMS by providing the
missing interfaces by workarounds. The resulting system supports user-driven, time-driven and data-
driven execution of knowledge modules. However, the system shows a delay in event detection and
data provision because it is dependent on periodic exports. This solution also consumes a significant
level of resources. The first ON-phase during the evaluation study showed a significant reduction in
daily PCT measurement rate. This effect was not observed during the second ON-phase. This was
because of reduced use of the knowledge module due to the fact that it was not integrated in the
clinical workflow.
Practical Conclusions
This thesis showed that the implementation of an Arden syntax runtime environment in a commercial
clinical system on the basis of periodic exports can result in a practical but slightly sluggish system.
The significant consumption of resources does mean there is a requirement for adequate interfaces.
The evaluation study showed that a significant savings potential can be achieved with regard to
laboratory measurement requests by means of knowledge modules for decision support. Relevant
integration of workflows is however required in order to achieve long-term savings. Furthermore, the
study showed that the Arden Syntax in later versions has such a high performance that it could even be
considered for use as a universal programming language for medicinal domain.
3
1 Einleitung
Unter wissensbasierten Systemen versteht man EDV-Systeme, die Wissen eines
Fachgebietes auf Fakten (im klinischen Umfeld sind dies typischerweise die in der
elektronischen Patientenakte enthaltenen Patientendaten) anwenden, wobei das Wissen in
einem maschinell verarbeitbaren Repräsentationsformat vorliegen muss [1]. Im
medizinischen Umfeld werden wissensbasierte Systeme zur klinischen
Entscheidungsunterstützung und zum klinischen Ereignismonitoring genutzt. Der
Unterschied zwischen diesen beiden Anwendungsgebieten besteht darin, dass bei der
Entscheidungsunterstützung das wissensbasierte System während der Entscheidungs-
findung mit dem Benutzer interagiert, um ihn beim Treffen einer Entscheidung zu helfen, ihn
also gewissermaßen bei seinem Entscheidungsprozess berät. Ein Beispiel hierfür ist die
Unterstützung bei der Anordnung von Medikamenten durch Generierung von
Dosierungsvorschlägen oder therapeutischen Alternativen. Beim Ereignismonitoring
hingegen überwacht das wissensbasierte System auftretende Ereignisse vollautomatisch im
Hintergrund und meldet sich nur, wenn ein Handlungsbedarf erkannt wurde. Ein Beispiel
hierfür ist die automatisierte Überwachung von Laborwerten.
In einer großen Anzahl von Studien konnte gezeigt werden (siehe dazu die systematischen
Reviews [2-6]), dass wissensbasierte Systeme einen Beitrag zur Verbesserung sowohl der
Behandlungsqualität als auch des Behandlungserfolgs in Krankenhäusern leisten können.
Dies gilt in erhöhtem Maße für den intensivmedizinischen Bereich mit seiner hohen
Datendichte. Durch den Einsatz wissensbasierter Systeme können beispielsweise
unerwünschte Arzneimittelereignisse vermieden [7-9], das Auftreten von Infektionen erkannt
[10-12], Laborwerte automatisch überwacht [13, 14] und Liege- oder Beatmungszeiten
verkürzt werden [15, 16]. Die exakte Quantifizierung einer aus dem Einsatz wissensbasierter
Systeme resultierenden Kostenersparnis bleibt allerdings schwierig [17].
Um wissensbasierte Systeme einsetzen zu können, muss das medizinische Wissen in einer
maschinell verarbeitbaren Form vorliegen. Ein derartiger Formalismus ist die "Arden Syntax
For Medical Logic Systems" [18] (im Folgenden in der deutschen Schreibweise kurz als
Arden-Syntax bezeichnet), die den einzigen internationalen Standard zur Repräsentation von
Wissen im medizinischen Bereich darstellt und durch Integration in kommerzielle Systeme
eine gewisse Verbreitung in der klinischen Routine gefunden hat. Medizinisches Wissen wird
hierbei in voneinander unabhängige Wissensmodule gegliedert, die als Medical Logic
Modules (MLMs) [19] bezeichnet werden. Bei der Konzeption der Arden-Syntax wurden
zwei Designziele verfolgt: Die Unterstützung des Wissenstransfers zwischen Institutionen
und die möglichst einfache Benutzbarkeit der Sprache [20].
Am Universitätsklinikum Erlangen (UKER) wurde Ende 2006 das Patientendaten-
managementsystem (PDMS) "Integrated Care Manager" (ICM) der Firma Dräger Medical
4
eingeführt. Derzeit (Stand April 2013) ist es auf insgesamt acht Intensivstationen im Einsatz,
weitere sind in Planung. Im Rahmen einer Diplomarbeit wurde im Jahre 2008 eine erste
prototypische Unterstützung für Arden-Syntax-MLMs in ICM integriert [21]. Dabei wurde eine
am Lehrstuhl für medizinische Informatik (LMI) der Friedrich-Alexander-Universität Erlangen-
Nürnberg (FAU) im Rahmen eines Dissertationsprojektes entwickelte servicebasierte Arden-
Syntax-Ausführungsumgebung [22, 23] genutzt. In der Diplomarbeit konnte ein Konzept für
den externen Zugriff auf die Patientendaten entwickelt werden, den ICM von Haus aus nicht
unterstützt. Die Ausführung von MLMs konnte dabei allerdings nur benutzer- und
zeitgesteuert, nicht aber datengesteuert erfolgen. Ein echtes Clinical Event Monitoring im
Sinne eines "tireless observers" (siehe Hripcsak et al. [24]) ließ sich daher in ICM bisher
nicht durchführen.
Aus den während der prototypischen Anbindung gemachten Erfahrungen ergab sich ein
starkes Interesse, diese Thematik tiefergehend zu erforschen und die Integration
wissensbasierter Funktionen in klinische Systeme voranzutreiben. Dies beschränkte sich
aber nicht nur auf die Aspekte der technischen Anbindung einer Plattform zur Ausführung
von MLMs. Im weiteren Sinne sollte auch die Leistungsfähigkeit und die daraus
resultierenden Anwendungsgebiete neuerer Versionen der sich beständig
weiterentwickelnden Arden-Syntax untersucht werden, beispielsweise deren Einsatz zum
Zweck der Entscheidungsunterstützung direkt am Bettplatz oder die Bereitstellung von
Präsentationsmechanismen. Ein ideales Umfeld zur Erforschung dieser Fragestellungen bot
eine Forschungskooperation, die der LMI in den Jahren von 2008 bis 2012 mit Dräger
durchführte. Sie diente unter anderem dem Ziel, die Integration wissensbasierter Funktionen
in ICM weiter voranzutreiben und insbesondere ein vollwertiges Clinical Event Monitoring zu
realisieren. Im Rahmen dieser Kooperation sollten Wissensmodule unterschiedlicher
Komplexität zum Einsatz gebracht werden. Das medizinische Wissen sollte hierbei, ebenso
wie bei der ersten prototypischen Implementierung, in Form von Arden-Syntax-MLMs
repräsentiert werden. Im Rahmen der Forschungskooperation wurde zu diesem Zweck eine
kommerzielle Arden-Syntax-Entwicklungs- und Ausführungsumgebung (kurz Arden-
Umgebung) der Firma Medexter Healthcare zur Verfügung gestellt. Diese musste zunächst
technisch an ICM angebunden werden, was die Realisierung eines Zugriffs von den
Wissensmodulen aus auf die Patientendaten sowie die Implementierung eines mit der
Produktpolitik von Dräger verträglichen datengesteuerten Triggermechanismus erforderlich
machte. Weiterhin war die Implementierung von Benachrichtigungsmechanismen
erforderlich, um das medizinische Personal in einer praxistauglichen Weise über auftretende
Meldungen informieren zu können. Die erste Fragestellung dieser Arbeit lautete also, wie die
Arden-Umgebung und das PDMS miteinander verbunden werden können, um
wissensbasierte Funktionen auf Basis von MLMs ausführen zu können, und wie die MLMs
mit dem medizinischen Personal interagieren können. Das erste Ziel hatte damit einen rein
technischen Charakter und ließ sich folgendermaßen formulieren:
5
Z1: Implementierung einer vollwertigen technischen Plattform für die
Ausführung von Arden-Syntax MLMs in ICM mit Mechani smen für Datenzugriff
und Ereignisbenachrichtigung unter Verwendung der A rden-Engine von
Medexter.
Dieses Ziel beinhaltete folgende Aufgabenstellungen mit den jeweiligen Fragestellungen:
• A1.1: Realisierung eines datengesteuerten Triggermechanismus zur Auslösung von
Wissensmodulen.
o F1.1: Wie kann die datengesteuerte Ausführung von MLMs ohne Unterstützung
durch ICM und ohne den Einsatz von Datenbanktriggern erkannt und an die
Arden-Engine gemeldet werden?
• A1.2: Anbindung der Arden-Engine an ICM.
o F1.2.1: Welche Schnittstellen werden von der Arden-Engine bereitgestellt?
o F1.2.2: Wie können diese Schnittstellen mit ICM gekoppelt werden und welche
Implementierungsschritte sind dazu notwendig?
• A1.3: Realisierung einer externen Zugriffsmöglichkeit auf die Patientendaten
o F1.3: Ist der in der Diplomarbeit entwickelte Datenbereitstellungsmechanismus
für die zu entwickelnde Plattform ausreichend? Gibt es Einschränkungen oder
notwendige Anpassungen?
• A1.4: Konzeption und Implementierung von Präsentationsmechanismen, die es dem
Wissensingenieur mit möglichst geringem Aufwand ermöglichen, die von den MLMs
erzeugten Informationen übersichtlich und schnell erfassbar darstellen zu können.
o F1.4: Welche Präsentationsmechanismen werden von den Anwendern gefordert
und inwieweit lassen sie sich umsetzen?
• A1.5: Konzeption und Implementierung von Benachrichtigungsmechanismen sowie
deren möglichst funktionale Integration in ICM.
o F1.5: Welche Kommunikationsendpunkte sind sinnvoll, um die klinischen
Anwender zu benachrichtigen?
Auch wenn es nicht explizit als Ziel formuliert wurde, so sollte bei allen Implementierungs-
schritten doch immer die möglichst einfache Benutzbarkeit angestrebt werden1.
Neben der Frage nach dem "wie" der technischen Integration stellte sich auch die Frage
nach dem Nutzen, den man aus einer Ausführungsplattform für MLMs am UKER ziehen
kann. Diese Fragestellung sollte anhand einer prospektiven Interventionsstudie zur
1 Als größter Flaschenhals beim Einsatz wissensbasierter Systeme gilt die Wissensakquisition. Durch eine einfache
Benutzbarkeit des Systems kann die Vision vom Mediziner als Wissensingenieur ("doctors as programmers") in
greifbare Nähe rücken.
6
Evaluierung eines dafür geeigneten MLMs untersucht werden. Ausgewählt wurde hierfür ein
Wissensmodul zur Erkennung von verzichtbaren Laboranforderungen des für die
Sepsiserkennung wichtigen Biomarkers Procalcitonin (PCT), da hierzu eine Anforderung von
klinischer Seite bestand und aufgrund einer hohen Meßrate ausreichend Fallzahlen
vorlagen, um einen kurzen Evaluierungszeitraum zu ermöglichen. Das zweite Ziel lautete
also:
Z2: Implementierung und Evaluierung eines MLMs zur Erkennung verzichtbarer PCT-
Messungen.
Dieses Ziel beinhaltete folgende Aufgabenstellungen mit den jeweiligen Fragestellungen:
• A2.1: Formulierung der Regeln zur Erkennung von vermeidbaren PCT-Messungen
o F2.1.1: Nach welchen Kriterien lassen sich verzichtbare PCT-Messungen
erkennen?
o F2.1.2: Lassen sich diese Kriterien als Regeln in Arden-Syntax formulieren?
• A2.2: Erstellung einer Vorstudie und eines Studienprotokolls
o F2.2.1: Wie kann der zu erwartende Effekt des MLMs eingeschätzt werden?
o F2.2.2: Welches Studiendesign ist für die Evaluierung geeignet?
• A2.3: Entwicklung und Einsatz eines geeigneten MLMs
o F2.3.1: In wie weit lässt sich die Studie per MLM vollständig automatisieren?
• A2.4: Auswertung der Studie
o F2.4.1: In welchem Umfang haben die Ärzte an der Studie teilgenommen?
o F2.4.2: Sind technische oder andere Probleme während der Studie aufgetreten?
o F2.4.3: Kann die Nullhypothese abgelehnt, d.h. ein Effekt nachgewiesen
werden?
7
2 Grundlagen
In diesem Kapitel sollen die zum Verständnis der Arbeit notwendigen technischen und
medizinischen Grundlagen dargestellt werden. Die technischen beschäftigen sich mit den
Grundlagen wissensbasierter Systeme und der Arden-Syntax als Formalismus zur
medizinischen Wissensrepräsentation. Weiterhin werden die beiden Komponenten
beschrieben, die es zur Bereitstellung der technischen Plattform zu verbinden galt: Das
PDMS ICM von Dräger Medical mit seiner Exportschnittstelle "AutoExport" und die Arden-
Umgebung "Arden Syntax IDE" von Medexter Healthcare. Ebenso soll eine kurze
Zusammenfassung der Ergebnisse der Diplomarbeit dargestellt werden, die eine Vorarbeit
zu dieser Dissertation darstellt und in deren Rahmen die Arden-Engine des "Erlangen
Decision Support Frameworks" (EDSF) prototypisch an ICM angebunden wurde.
Abschließend soll eine kurze Einführung in die medizinischen Grundlagen der PCT-Studie
stattfinden.
2.1 ICM und seine Exportschnittstelle AutoExport
Ein Patientendatenmanagementsystem (PDMS) ist ein klinisches Arbeitsplatzsystem (KAS)
für die Intensivmedizin [25, 26] (zur Unterscheidung KIS/KAS siehe Prokosch [27]). Es
ermöglicht eine vollständige patientenzentrierte Dokumentation aller medizinischen Daten
der Intensivpatienten. Die Dokumentationsdichte in einem PDMS ist wesentlich größer als im
KAS einer Normalstation. Dies liegt vor allem an einer automatisierten Erfassung von Daten
über Geräteschnittstellen, z.B. von den Patientenmonitoren. Werden auf einer Normalstation
Parameter wie beispielsweise Blutdruck und Körpertemperatur zweimal täglich von einer
Pflegeperson manuell gemessen, so werden sie auf Intensivstation in vielen Fällen über
arterielle Sonden oder Temperatursensoren in kurzen Zeitabständen automatisch erfasst,
wodurch täglich mehrere Hundert Werte pro Parameter in die Patientenakte eingehen
können. Auf der neonatologischen Intensivstation ist das Intervall für die Übernahme der
Daten von arteriellen Blutdrucksonden bei vielen Patienten auf 5 Minuten gestellt, so dass
pro Tag 288 Blutdruckwerte in die Patientenakte einfließen. Durch die hohe Datendichte ist
ein PDMS eine besonders interessante Datenquelle für wissensbasierte Systeme, da
beispielsweise die zeitnahe Erkennung aktueller Trends eine entsprechende Datendichte
voraussetzt.
Im Jahre 2006 wurde das PDMS ICM auf der interdisziplinären operativen Intensivstation
(IOI) der anästhesiologischen Klinik des UKER eingeführt (siehe hierzu Castellanos et al.
[28], Bürkle et. al. [29], Castellanos und Bürkle [30] sowie Tech [31]. Ein Bericht zur
Einführung von ICM auf einer anästhesiologischen Intensivstation am UK Hamburg-
Eppendorf findet sich bei Prause [32]). Derzeit (Stand April 2013) ist es am UKER auf
insgesamt acht Intensivstationen im Einsatz, weitere sind in Planung. Dokumentiert wird mit
ICM direkt am Patientenbett (Abbildung 1 zeigt einen Screenshot der Tageskurve). Dazu
8
stehen spezielle mobile Bettplatzrechner bereit, die ausschließlich der medizinischen
Dokumentation dienen und auf denen ICM als einzig verfügbare Applikation automatisch
gestartet wird. Verschiedene klinische Anwendungen wie das KAS der Normalstationen
(Siemens SOARIAN), der Radiologie-Viewer, das Laborsystem oder der Abteilungs-
Sharepoint können allerdings über integrierte Schaltflächen aufgerufen werden. Neben den
Bettplatzrechnern gibt es auch administrative Rechner, die meist in den Stützpunkten der
Stationen sowie in den Arztzimmern stehen.
Abbildung 1: Screenshot der ICM-Tageskurve
ICM speichert die Patientendaten aller Mandanten2 in einer zentralen SQL-Datenbank
(PatDB). Die PatDB ist von Herstellerseite für den Kunden nicht freigegeben, d.h. ein
externer Direktzugriff per SQL ist dem Kunden nicht gestattet. Die einzige für den Kunden
freigegebene Schnittstelle von ICM für den Zugriff auf aktuelle3 Patientendaten ist eine
Exportschnittstelle namens AutoExport, die für die automatisierten Arztbriefschreibung und
2 Ein Mandant ist eine Organisationseinheit mit eigener Konfiguration. Im Normalfall entspricht ein Mandant einer
Intensivstation. 3 Jeder Mandant verfügt zusätzlich über eine Reportingdatenbank, die ebenfalls über AutoExport befüllt wird.
Allerdings findet die Aktualisierung nur einmal pro Tag statt, damit ist sie mangels Aktualität als Datenquelle für
wissensbasierte Funktionen weitgehend ungeeignet. Für diejenigen MLMs, die von den DRG-Codern erst nach
Entlassung des Patienten ausgeführt werden, wäre die Anbindung der Reportingdatenbanken an die Arden-Engine
eventuell sinnvoll.
9
die Generierung von Berichten konzipiert wurde. AutoExport stellt zwei Funktionen bereit:
Das Generieren von Textdateien mit Patientendaten sowie das Starten von Programmen.4
Job Control File
Template
Text undSchlüsselwortterme
Target
Freitext (z.B. Arztbrief),CSV, HTML, XML…
Schlüsselwort-parser
steuert
Eingabe Ausgabe
Abbildung 2: Grundprinzip von AutoExport
Das Generieren von Textdateien funktioniert über Vorlagendateien, sogenannte Templates.
Die Templates enthalten Schlüsselwortterme, das sind Ausdrücke zur Anfrage an die PatDB,
die in einer proprietären Syntax formuliert sind. AutoExport liest die Templates ein und ein
Schlüsselwortparser ersetzt die Schlüsselwortterme textuell durch das Ergebnis der
jeweiligen Anfrage. Die so generierten Textdateien werden als Targets bezeichnet. Das
Grundprinzip ist in Abbildung 2 dargestellt. Die Definition eines Exportjobs erfolgt mittel eines
Job-Control-Files (JCF). Dies ist eine Steuerdatei, die eine Liste aller erforderlichen
Parameter enthält. Ein JCF enthält jeweils drei Sektionen:
• Die Jobsteuerung, in der das generelle Verhalten des Exportjobs (z.B. das zeitliche
Intervall zwischen den Exporten) festgelegt wird.
• Die Jobliste, eine Liste von Namen von Jobdefinitionen, die bei Ausführung des
Exportjobs abgearbeitet werden sollen.
• Die Jobdefinitionen mit ihren Templates und Targets.
Die in den Templates enthaltenen Schlüsselwortterme sind Ausdrücke in eckigen Klammern,
die eine Anfrage an die PatDB spezifizieren. Sie beinhalten als ersten Parameter ein
Schlüsselwort, das die Art der angefragten Daten spezifiziert. Folgende Schlüsselworte sind
im Rahmen dieser Arbeit von besonderer Bedeutung:
Schlüsselwort Anfrageergebnis
D Demografische Daten5
ORDERS Daten der Tageskurve
SYSTEM Systeminformationen, z.B. der angemeldete User
CODES ICD6- und OPS7-Codes
4 Über AutoExport können Exporte auch ohne Speicherung direkt an einen Drucker gesendet werden, diese
Funktion ist aber im Rahmen dieser Arbeit nicht relevant. 5 In der Diplomarbeit wurde stattdessen das inzwischen veraltete Schlüsselwort Pat verwendet. Pat kann
weiterverwendet werden, Dräger empfiehlt aber die Umstellung auf D, da es erheblich performanter ist. 6 International Classification of Diseases
10
Ein Schlüsselwortterm kann entweder einen Einzelwert (wie bei D oder SYSTEM) oder eine
Liste von Tupeln zurückliefern, wobei ein Tupel einer Zeile einer Tabelle entspricht. Wie die
Liste textuell abgebildet wird (CSV, HTML, XML...), wird durch die Angabe einer
sogenannten Formatanweisung gesteuert. Dies ist ein Ausdruck in einer proprietären
Sprache, die im Wesentlichen aus geschachtelten Schleifenkonstrukten besteht, die
Bezeichner enthalten. Die Bezeichner sind entweder Spaltennamen aus der ICM-Datenbank,
sofern die benötigten Daten explizit in der PatDB gespeichert sind, oder Namen von Makros,
sofern die benötigten Daten von der Geschäftslogik berechnet werden müssen8. Die
Verarbeitung von Schlüsselworttermen soll nun anhand des Beispiels in Abbildung 3
erläutert werden. Die ersten beiden Schlüsselwortterme liefern den Patientennamen und den
Namen des aktuell in ICM angemeldeten Nutzers. Der dritte Schlüsselwortterm liefert die
Leukozytenwerte des Patienten. Die Formatanweisung erzeugt bei jedem Durchlauf die
Zeichenkette "{CT_Sample} am {AdminDate}, ", wobei die Bezeichner in den
geschweiften Klammern durch Wert und Zeitstempel ersetzt werden. Die Zeichenketten
werden konkateniert, Komma und Leerzeichen am Ende des Gesamtstrings werden durch
die beiden Steuerzeichen "\BKSP" (für Backspace) entfernt. Formatanweisungen können
deutlich komplexer werden als das dargestellte Beispiel, insbesondere wenn über mehrere
Maßnahmen bzw. Maßnahmengruppen iteriert wird. Damit können hierarchische Strukturen
abgebildet werden, z.B. in Form geschachtelter XML-Elemente.
TemplatePatname = [D:Patname, Patvorname]Username = [System:Username]Leukozyten = [Orders: TreatmentName=Leukozyten; Range=all; Records=all; Format=!(({CT_Sample} am {AdminDate}, )\BKSP\BKSP)]
TargetPatname = Mustermann, MaxUsername = doejnLeukozyten = 20.83 am 30.10.2011 00:38, 12.27 am 30.10.2011 06:00, 25.82 am 30.10.2011 22:13, 18.15 am 31.10.2011 06:00
Abbildung 3: Die Funktionsweise von Schlüsselwortter men
AutoExport unterstützt die benutzergesteuerte (d.h. auf Knopfdruck in der ICM-Oberfläche)
und die zeitgesteuerte (d.h. in periodischen Abständen) Auslösung von Exporten. Eine
datengesteuerte Auslösung, d.h. automatisch bei Eingang neuer Daten in die PatDB, wird
aber nicht unterstützt. Die Logik der zeitgesteuerten Ausführung basiert auf drei Parametern:
Dem Pollingintervall, dem zeitlichen Kontext CTX und dem Parameter PERIOD, der das
7 Operationen- und Prozedurenschlüssel 8 Dies ist beispielsweise bei aggregierten Perfusor-Laufraten der Fall.
11
Exportintervall festlegt. Das Pollingintervall bestimmt, in welchen Zeitabständen geprüft
werden soll, ob ein Export notwendig ist. CTX legt dabei einen Referenzzeitpunkt für die
Schlüsselwortterme fest. Nach erfolgtem Export wird der Wert von PERIOD zu CTX addiert.
Der nächste Export findet statt, wenn beim nächsten Polling der neue Wert von CTX erreicht
oder überschritten wurde. Mit diesem Mechanismus ist es möglich, die Zeitachse über ein
wanderndes Zeitfenster lückenlos abzudecken. Unterbleiben die Exporte für eine bestimmte
Zeit, so wird bei deren Wiederaufnahme das Zeitfenster beschleunigt verschoben, bis CTX
wieder im Bereich der aktuellen Systemzeit ist.
2.2 Wissensbasierte Systeme
Bei der Einarbeitung in dieses Fachgebiet kann man schnell feststellen, dass die Termini
"wissensbasierte Systeme" bzw. "wissensbasierte Funktionen" nicht einheitlich definiert sind9
und teilweise sogar ein wenig willkürlich verwendet werden. Prokosch stellt hierzu fest, dass
„der Begriff ‚wissensbasiertes System’ ein Modewort ist, das in der Fachliteratur wieder und
wieder verwendet wird, ohne dass seine Bedeutung eindeutig festgelegt wäre.[33] “
Im Englischen hat sich für wissensbasierte Systeme der Begriff "Clinical Decision Support
Systems (CDSS)" etabliert. Die Definition dieses Begriffes ist oft rein funktionaler Natur:
"Clinical decision support systems are tools designed to help humans make better clinical
decisions. [34]"
"A medical decision-support system is any computer program designed to help health
professionals make clinical decisions. [35]"
Derartige Definitionen sind häufig anzutreffen und haben auch ihre Berechtigung. Ein
wissensbasiertes System ist nicht selten eine Black Box, so dass gar keine andere
Möglichkeit besteht, als es über seine Funktionalität zu klassifizieren. Andererseits sind
solche Definitionen wiederum recht unscharf, so dass man damit beispielsweise auch eine
statische Webanwendung mit Fachinformationen zu Arzneimitteln als wissensbasiertes
System bezeichnen könnte. Ebenso unterstützt auch ein KAS oder PDMS, selbst wenn es
als reines Dokumentationssystem fungiert, den Arzt beim Treffen klinischer Entscheidungen,
so dass hier die Grenzen verschwimmen können. Prokosch bemüht sich um klarere
Grenzen und definiert im Sinne einer Spezialisierung den Begriff der wissensverarbeitenden
Funktionen:
„In einer wissensverarbeitenden Funktion wird explizit repräsentiertes Wissen aktiv auf aktuell
gegebene Fakten angewendet. Damit kann entweder der Prozess der menschlichen
Entscheidungsfindung unterstützt (Entscheidungsunterstützung) oder aber eine getroffene
Entscheidung mit vorliegendem Wissen verglichen und dadurch abgesichert werden
(Entscheidungsmonitoring). [33]“
9 Die Begriffe "wissensbasierte Systeme" und "wissensbasierte Funktionen", die man beide in der
deutschsprachigen Literatur vorfindet, werden im Rahmen dieser Arbeit als Synonyme betrachtet.
12
Wenn im weiteren Verlauf dieser Arbeit von wissensbasierten Systemen die Rede ist, so sind
eigentlich wissensverarbeitende Systeme im Sinne obiger Definition gemeint. Der Begriff
"wissensbasierte Systeme" wird aber weiter verwendet, da er in der Fachliteratur etabliert ist.
Ein wichtiger Unterschied zwischen einem wissensbasierten System und herkömmlicher
Software ist also die explizite Repräsentation von Wissen, d.h. die Speicherung des Wissens
in einer separaten Wissensdatenbank unter Verwendung eines geeigneten Repräsentations-
formates. Auch herkömmliche Software verarbeitet Wissen, allerdings ist dieses implizit im
Programmcode selbst enthalten. Bei wissensbasierten System wird das Wissen
beispielsweise in Form maschinell verarbeitbarer WENN-DANN-Regeln10 in der
Wissensbank hinterlegt, Wissen stellt also in diesem Kontext eine Form von Daten dar. Die
obige Definition weist stark in die Richtung sogenannter medizinischer Expertensysteme. In
der Fachliteratur wird der Begriff des Expertensystems häufig als weitgehend
deckungsgleich mit dem des wissensbasierten Systems betrachtet [36]. Puppe definiert
Expertensysteme wie folgt:
,,Expertensysteme sind Programme, mit denen das Spezialwissen und die Schlussfolgerungs-
fähigkeit qualifizierter Fachleute auf eng begrenzten Aufgabengebieten nachgebildet werden
soll. [37]"
Expertensystem-Shell
Ben
utze
rsch
nitts
telle
Inferenzmaschine
Wissensbasis
Faktenbasis
Erklärungskomponente
WissenseditorBenutzer
Abbildung 4: Typische Architektur eines medizinisch en Expertensystems
Neben der Speicherung von Wissen ist also auch eine Schlussfolgerungsfähigkeit
erforderlich, die von einer entsprechenden Komponente (Inferenzmaschine) bereitgestellt
wird. Betrachtet man weitere erforderliche Komponenten, so kann man die Architektur eines
Expertensystems in dessen Definition mit einbeziehen, was zu einer weiteren Präzisierung
beiträgt. Über die Architektur eines Expertensystems herrscht in der Literatur ein starker
Konsens. Abbildung 4 zeigt eine typische Darstellung (nach Coppin [38]). Die Wissensbasis
enthält das Fachbereichswissen, beispielsweise in Form von Regeln wie "WENN starker
Anstieg des Kreatininwertes DANN Verdacht auf Nierenversagen". Die Faktenbasis enthält
10 WENN-DANN-Regeln werden als Produktionsregeln bezeichnet, die verarbeitenden Systeme entsprechend als
Produktionssysteme.
13
die fallbezogenen medizinischen Daten, also die Patientendaten des angebundenen
klinischen Systems. Die Inferenzmaschine wendet die in der Wissensbasis gespeicherten
Regeln auf die Fakten an. Die Erklärungskomponente macht die Entscheidungen des
Systems nachvollziehbar, was im medizinischen Bereich natürlich sehr wichtig ist, da falsche
Entscheidungen nicht vollständig ausgeschlossen werden und evtl. schwerwiegende
medizinische und juristische Konsequenzen haben können:
"For the first- and second-generation expert systems in medicine, the ability to reason about the
diagnostic process was of paramount importance [...] [39]"
Der Wissenseditor dient der Befüllung der Wissensbasis mit Regeln. Die Einheit aus
Benutzerschnittstelle, Inferenzmaschine, Erklärungskomponente und Wissenseditor wird oft
als Expertensystem-Shell bezeichnet. Diese ist insoweit generisch, als dass ein Einsatz in
einem anderen Fachbereich lediglich den Austausch der Wissensbasis erfordert.
Hinsichtlich der Definition eines wissensbasierten Systems kann nun zusammenfassend
gesagt werden: Am weitesten gefasst ist die rein funktionale Definition a la Shortliffe, wobei
aber nach Möglichkeit auf enger gefasste Definitionen zurückgegriffen werden sollte, die die
Architektur des Systems mit einbeziehen, womit man bei den medizinischen
Expertensystemen ankommt.
Bereits in der Anfangszeit der Forschung zu wissensbasierten Systemen hat man erkannt,
dass deren Stärke nicht von ausgeklügelten Inferenzmechanismen abhängt, sondern im
Wesentlichen von der Qualität der Wissensbank [36]. Ebenso gab es einen stetigen Trend
zur Spezialisierung: Wurde in den 60er Jahren noch über generische
fachbereichsübergreifende Problemlösungsstrategien geforscht ("General Problem Solver"),
so war man in den 80ern bereits bei stark spezialisierten Systemen angelangt, deren
Einsatzgebiet sich auf eng umgrenzte Fachbereiche beschränkt, so wie auch das Wissen
eines herausragenden menschlichen Experten sich meist auf ein sehr enges Spezialgebiet
bezieht [36]. In diesem zeitlichen Kontext ist auch die Entstehung der Arden-Syntax
anzusiedeln, der "Arden Retreat" [40], der zur Schaffung der Arden-Syntax führte, fand 1989
statt (zum historischen Verlauf der Entwicklung wissensbasierter Systeme siehe Haun [41]).
Auch wenn die Konzeption und Implementierung eines wissensbasierten Systems einen
erheblichen Aufwand bedeuten kann, so trifft man nach der technischen Bereitstellung auf
ein noch schwerwiegenderes Problem. Die größte Hürde beim Einsatz eines medizinischen
wissensbasierten Systems ist nämlich nicht dessen Konstruktion, sondern die Befüllung der
Wissensbank:
"Knowledge acquisition is the biggest bottleneck in the development of expert systems. [42]"
Der Flaschenhalscharakter der Wissensakquisition wird bei der Anbindung eines
wissensbasierten Systems an ein klinisches Informationssystem nicht sofort offensichtlich,
da der Fokus zunächst auf den zu bewältigenden technischen Problemen liegt. Sobald aber
die technische Anbindung vollzogen ist, steht die Befüllung der Wissensbank an. Diese
14
Arbeit wird in der Praxis meist von einem Team aus Mediziner ("Domain Expert",
Fachbereichsexperte) und Informatiker ("Knowledge Engineer", Wissensingenieur)
vorgenommen und ist deshalb so aufwendig, weil dem Informatiker oft das medizinische
Fachwissen fehlt und dem Mediziner oft das technische:
"Various challenges exist in medical knowledge engineering. One challenge is that the
knowledge engineer is not familiar with the complex and comprehensive medical terminology in
the medical ontologies. As a result, the application domain remains opaque to him and he
cannot verify the knowledge engineering process. [...] The major challenge, however, is the so-
called 'knowledge acquisition bottleneck.' We cannot easily acquire the necessary medical
knowledge that ought to be used in the software application as it is hidden in the heads of
medical experts. [43]"
Im in der Praxis leider recht seltenen Idealfall sind der Wissensingenieur und der
Fachbereichsexperte ein und dieselbe Person, d.h. der medizinische Experte kodiert sein
Wissen selbständig ohne die Unterstützung eines Informatikers. Nadkarni bezeichnet diesen
Idealfall mit dem Schlagwort "doctors as programmers" [44]. Damit der medizinische Experte
als Wissensingenieur agieren kann, muss er den verwendeten Formalismus zur
Repräsentation des Wissens beherrschen. Aus eben diesem Grund war eines der beiden
Designziele der Arden-Syntax deren einfache Benutzbarkeit [20].
Der Einfluss wissensbasierter Systeme auf die klinische Routine ist über einen Zeitraum von
inzwischen mehr als drei Jahrzehnten in zahlreichen Studien untersucht worden, zu Beginn
vor allem am HELP-System (siehe Evans et al. [45-47]). Die Zahl der Studien ist inzwischen
so umfangreich, dass es eine Reihe systematischer Reviews gibt, welche die "Effects of
clinical decision-support systems on practitioner performance and patient outcomes"
(typischer Titel eines solchen Reviews) untersuchen. Die betrachteten Zielgrößen sind also
typischerweise "practitioner performance" (Behandlungsqualität) und "patient outcome"
(Behandlungserfolg). Siehe dazu die Reviews von Jaspers et al. [2], Hunt et al. [3], Garg et
al. [4], Johnston et al. [5] sowie Randell et al. [6]. Die Reviews zeigen, dass der Einfluss
wissensbasierter Funktionen auf die Behandlungsqualität deutlich häufiger nachgewiesen
werden kann als der auf den Behandlungserfolg. Das ist auch intuitiv verständlich, wie man
sich am Beispiel von Warnmeldungen bei Hypoglykämien klarmachen kann: Betrachtet man
die Zeitdauer vom Auftreten einer Hypoglykämie bis zu ihrer Behandlung als Maß für die
Behandlungsqualität, so kann diese durch Warnmeldungen oft erheblich verbessert werden.
Dies bedeutet aber nicht zwangsläufig eine statistisch signifikante Auswirkung auf den
Behandlungserfolg (z.B. eine Senkung der Mortalitätsrate), schon gar nicht bei derartig
seltenen Ereignissen mit geringen Fallzahlen11.
Beim Einsatz wissensbasierter Systeme muss sorgfältig darauf geachtet werden, dass sie
vom Benutzer als unterstützend empfunden werden. Dies betrifft insbesondere das Alerting,
also das Versenden von Warnmeldungen. Wird der Benutzer mit Meldungen "bombardiert",
so kann es passieren, dass er diese in zunehmendem Maße als störend empfindet. Dieser 11 Auf der IOI treten durchschnittlich etwa sieben Hypoglykämien (Glucose < 50 mg/dl) pro Monat auf.
15
Effekt wird als "Alert Fatigue" bezeichnet. Dies kann sich steigern zum "Alert Overriding".
Damit bezeichnet man das Hinweggehen des Benutzers über die Warnmeldungen
("Wegklicken"), selbst wenn diese wichtige Informationen beinhalten. Ebenso problematisch
sind falsch-positive oder -negative Meldungen, die sich nicht immer vermeiden lassen. Recht
umfassend untersucht wurde dies im Kontext der Arzneimitteltherapiesicherheit, siehe dazu
Lin et al. [48], Weingart et al. [49], Isaac et al. [50] und Van der Sijs et al. [51, 52]. Eine
empfehlenswerte Einführung in die Thematik bietet die Dissertation von Van der Sijs [53].
2.3 Die Arden Syntax for Medical Logic Systems
Die Arden Syntax For Medical Logic Systems ist eine Sprache zur Repräsentation von
medizinischem Wissen. Sie stellt in diesem Bereich den einzigen internationalen Standard
dar und wurde stark von den älteren Systemen HELP [54] und CARE [55] beeinflusst. Im
Gegensatz zu manch anderen Realisierungsansätzen für wissensbasierte Funktionen, die
nur im akademischen Umfeld eingesetzt wurden, ist die Arden-Syntax als HL7-Standard in
einigen kommerziellen Systemen verfügbar (z.B. in den KAS Soarian von Siemens, das am
UKER eingesetzt wird, sowie ORBIS von Agfa Healthcare als Zusatzmodul "Experter"12).
Bei der Schaffung der Arden-Syntax wurden zwei Designziele verfolgt [20]:
1. Die Arden-Syntax sollte den Transfer von Wissen zwischen Institutionen
ermöglichen.
2. Die Regeln zur Wissensrepräsentation sollten einfach zu formulieren sein.
Um den Transfer von Wissen zu ermöglichen, wird es in modular unabhängige Module
gegliedert. Modular unabhängig bedeutet, dass Modul A auch dann noch funktioniert, wenn
Modul B aus der Wissensbasis entfernt wird. Die Arden-Syntax lehnt sich syntaktisch stark
an die zum Entstehungszeitpunkt gängigen prozeduralen Sprachen an und wird mehrfach
mit der Programmiersprache Pascal verglichen13. Da die Arden-Syntax sich konsequent auf
diejenigen Konstrukte beschränkt, die für ihren zugedachten Zweck benötigt werden, ist sie
relativ schlank und damit schnell zu lernen. Zudem bietet sie Formulierungsmöglichkeiten
an, die sehr nah an der menschlichen Sprache sind [56], wodurch sie in einem gewissen
Grade selbstdokumentierend ist und die Verifikation der Wissensmodule erleichtert. Benötigt
man beispielsweise das Maximum der Kreatininwerte der letzten 24 Stunden eines
Patienten, so kann man dieses durch folgende Anweisung berechnen:
LET creatinine_max24h BE THE MAXIMUM OF
(creatinine_values WHERE THEY OCCURRED WITHIN THE P AST 24 HOURS);
Eine solche Anweisung ist intuitiv verständlich und wesentlich weniger “informatisch” als ihre
Entsprechungen in verschiedenen gängigen Programmiersprachen. Die Arden-Syntax
12 Dieses Zusatzmodul ist nach Aussage von Agfa derzeit nur für den US-amerikanischen Markt verfügbar. 13 Zum Zeitpunkt der Einführung der Arden-Syntax war Pascal weit verbreitet. Von den heute verbreiteten Sprachen
erinnert die Arden-Syntax stark an Python. Interessanterweise war das Designziel von Python die einfache
Benutzbarkeit, was ja auch ein Designziel der Arden-Syntax war.
16
verfügt über eine umfangreiche Menge an Operatoren, die speziell auf den medizinischen
Einsatzbereich zugeschnitten sind. Ein Beispiel ist der SLOPE-Operator, der eine
Trenderkenung durch die Methode der kleinsten Quadrate durchführt und das Ergebnis auf
24-Stunden-Einheiten herunterbricht. Damit kann man beispielsweise auf der Pädiatrie
komfortabel den Trend bei der täglichen Gewichtszunahme ermitteln, ohne explizite
Berechnungen anstellen zu müssen.
Die in heutigen Programmiersprachen gängigen objektorientierten Konzepte fehlen in der
Arden-Syntax. Sie sind aber für deren Anwendungszweck auch nicht notwendig und ihr
fehlen hält die Sprache einfach und schnell erlernbar. Während das Erlernen einer Sprache
wie Java meist Monate dauert und viel Lerneifer erfordert, kann selbst ein
programmiertechnischer Laie innerhalb weniger Tage einfache Wissensmodule schreiben14.
Seit einigen Jahren gibt es eine Erweiterung zur Verarbeitung unscharfer Logik namens
Fuzzy-Arden-Syntax [57-59], die jeder Variable einen Grad der Anwendbarkeit zuordnet und
diesen bei der Verarbeitung des Moduls kontinuierlich adaptiert.
Die Nutzung der Arden-Syntax in einem klinischen Informationssystem setzt die Lösung des
Curly-Braces15-Problems voraus. Damit wird der erforderliche Abbildungsprozess von
Datentypen der Arden-Syntax auf Daten- und Nachrichtentypen des anzubindenden
Systems und vice versa bezeichnet. Der Name stammt von den geschweiften Klammern, in
denen die für den Abbildungsprozess erforderlichen Parameter enthalten sind:
"Because the developers of the Arden Syntax recognized that Agreement on a common clinical
database schema, query language, and vocabulary would require many years, if it ever would
occur at all, they introduced a construct known as the curly braces for the characters used to
enclose it ({ }). This provides a mechanism for the author to include institution-specific database
mappings and links in an otherwise standard syntax. [...] Site-specific mappings enclosed in
curly braces also are used to define events that are included as triggers in the evoke slot as well
as delineation of destinations for messages from the CDS system. [60]"
Nachfolgend zwei Beispiele für Curly-Braces-Ausdrücke: Ein READ-Statement zum
Auslesen von Glucosewerten (Mapping von DB-Datentypen auf Arden-Syntax-Datentypen),
sowie ein DESTINATION-Statement zum Festlegen einer Emailadresse als
Kommunikationsendpunkt (Mapping von Arden-Syntax-Datentypen auf das Email-
Nachrichtenformat):
LET glucose_values BE READ {Parameter=Glucose, Case ID=4711};
LET email_study_nurse BE DESTINATION
{email:[email protected]};
14 Natürlich gilt auch bei der Arden-Syntax, dass sich komplexe Probleme nicht einfach formulieren lassen. Die
Arden-Syntax ist also kein "Königsweg" der Wissensrepräsentation. 15 In manchen Publikationen wird "Brackets" statt "Braces" verwendet
17
Es gibt von Seiten der Arden-Syntax-Spezifikation keinerlei Vorgaben für den Inhalt der
Curly-Braces. Dieser ist von der nutzenden Institution selbst zu spezifizieren. Dieses Fehlen
einer Abstraktionsschicht wird von Nadkarni als Schwachpunkt der Arden-Syntax kritisiert
[44]. Das Curly-Braces-Problem besteht natürlich nicht nur bei der Arden-Syntax, sondern
bei jedem wissensbasierten System, das an ein KAS/PDMS angebunden werden soll.
Daneben gibt es noch ein weiteres Problem: Die Tatsache, dass die Entwicklung eines
Arden-Compilers zeitaufwendig und teuer ist (Kim et al. [61] bezeichnen dies als "Compiler
Problem"). Mit Arden2ByteCode ist seit dem Jahr 2010 eine Open-Source-Implementierung
einer Arden-Umgebung (Arden-Syntax Version 2.5) frei verfügbar [62].
2.3.1 Medical Logic Modules
Die Wissensbasis wird bei der Arden-Syntax in modular unabhängige Wissensmodule
namens Medical Logic Modules (MLMs) gegliedert.16 Ein MLM hat einen hierarchisch
strukturierten Aufbau, der in Abbildung 5 dargestellt ist.
MLM
MAINTENANCE
PURPOSEEXPLANATIONKEYWORDSCITATIONSLINKS
TITLEMLMNAMEARDENVERSIONINSTITUTIONAUTHORSPECIALISTDATEVALIDATION
LIBRARY KNOWLEDGE
TYPEDATAPRIORITYEVOKELOGICACTIONURGENCY
Abbildung 5: Aufbau eines MLMs
Ein MLM ist in drei Hauptabschnitte namens MAINTENANCE, LIBRARY und KNOWLEDGE
gegliedert, die als Kategorien bezeichnet werden. MAINTENANCE enthält Informationen
technisch/organisatorischer, LIBRARY inhaltlich/medizinischer Art. KNOWLEDGE enthält
das eigentliche medizinische Wissen. Kategorien sind in Unterabschnitte gegliedert, die als
Slots bezeichnet werden. Von besonderer Bedeutung bei der Ausführung eines MLMs sind
die Slots EVOKE, DATA, LOGIC und ACTION der Kategorie KNOWLEDGE:
16 Das Paradigma der modularen Unabhängigkeit wird durch die Verwendung von Sub-MLMs für wiederkehrende
Berechnungen etwas aufgeweicht, aber nicht durchbrochen. Man muss beim Wissenstransfer darauf achten, alle
erforderlichen Sub-MLMs mit auszutauschen.
18
• EVOKE: Definiert das Ereignis17, das die Ausführung des MLMs auslöst.
• DATA: Definiert sämtliche erforderliche Mappingprozesse, insbesondere die der
Patientendaten, die vom MLM beim Abarbeiten der Entscheidungslogik
benötigt werden.
• LOGIC: Enthält die eigentliche medizinische Entscheidungslogik
• ACTION: Beschreibt die Aktion, die je nach Entscheidung evtl. ausgeführt wird.
Innerhalb des LOGIC-Slots trifft ein MLM die Entscheidung, ob der ACTION-Slot ausgeführt
werden soll oder nicht. Die grundlegende Entscheidung eines MLMs lautet also: Soll die im
ACTION-Slot definierte Aktion ausgeführt werden oder nicht? Ein MLM entspricht damit einer
Rule im Rules-Based-Ansatz [60]. Gesteuert wird diese Entscheidung über das
CONCLUDE-Statement. Trifft der Kontrollfluss auf "CONCLUDE TRUE“, so wird der
ACTION-Slot ausgeführt, trifft er auf "CONCLUDE FALSE“, so wird die Ausführung des
MLMs sofort beendet. Erreicht der Kontrollfluss das Ende des ACTION-Slots, ohne auf ein
CONCLUDE-Statement getroffen zu sein, so wird implizit „CONCLUDE false“ ausgelöst. Das
geschilderte Grundprinzip ist in Abbildung 6 grafisch dargestellt. MLMs können während der
Ausführung über das CALL-Statement andere MLMs aufrufen, sowohl synchron als auch
asynchron.
DATA: LOGIC: ACTION:
Bezugerforderlicher
Datenconclude
Treffen einerklinischen
Entscheidung
Ausführenvon AktionenEVENT
MLM beenden
false
true
Abbildung 6: Gundprinzip der Verarbeitung eines MLM s
Um MLMs im klinischen Betrieb einsetzen zu können, ist eine Reihe technischer
Voraussetzungen erforderlich. Ein MLM muss zunächst in eine ausführbare Form gebracht
werden. Dazu ist ein Arden Compiler erforderlich18. Die in der Literatur beschriebenen Arden
Compiler übersetzen das MLM nicht in Maschinencode, sondern in eine andere
Programmiersprache. In neueren Publikationen ist das in der Regel Java [22, 62-65], in
älteren Publikationen wird u.a. die Verwendung von C++ [66-68] oder MUMPS [69]
beschrieben. Es wurde auch die Übersetzung in Stored Procedures des verwendeten
17 Es können auch mehrere Ereignisse definiert werden, durch logisches Oder verknüpft. 18 MLMs können natürlich auch interpretiert werden, typischerweise werden sie aber kompiliert. Dies ist sinnvoll, da
sich ein MLM im Status ‚production’ kaum noch ändert und die häufige Ausführung eines kompilierten MLMs meist
performanter ist als seine häufige Interpretierung.
19
Datenbanksystems beschrieben, so bei Tafazzoli [70] in PL/SQL (Oracle) und bei Liang und
Chang [71] in TSQL (Microsoft).
Die Ausführung der kompilierten MLMs wird von der Arden-Engine gesteuert, deren
Funktionsprinzip in Abbildung 7 dargestellt ist19. Eine Arden-Engine verarbeitet klinische
Ereignisse, die vom KAS/PDMS in Form einer Nachricht gesendet werden. Nach Hripcsak
[24] unterscheidet man dabei vier Typen von Ereignissen:
• benutzergesteuerte Ereignisse: Ein Benutzer interagiert mit der GUI des PDMS, z.B.
indem er eine Schaltfläche betätigt.
• zeitgesteuerte Ereignisse: Ein Punkt auf der Zeitachse wird erreicht.
• datengesteuerte Ereignisse: Eingang eines neuen Datums, z.B. eines Laborwertes,
in die PatDB.
• zusammengesetzte Ereignisse: Kombinationen der anderen Typen.
Data-Slot
Logic-Slot
Action-Slot
Arden Engine
MLMMLMMLMMLM
MLM
EVENT
DB
Message
read { }
Knowledge Base
MLMMLMMLMMLM
MLMMLM
Data-Slot
Logic-Slot
Action-Slot
Arden Engine
MLMMLMMLMMLM
MLM
EVENT
DB
Message
read { }
Knowledge Base
MLMMLMMLMMLM
MLMMLM
Abbildung 7: Grundprinzip einer Arden-Engine
Erhält die Arden-Engine eine Ereignismeldung, so führt sie all jene MLMs in ihrer
Wissensbasis aus, die dem gemeldeten Ereignis zugeordnet sind. Für den Einsatz einer
Arden-Engine zum Zweck des Clinical Event Monitorings im Sinne von „tireless observers,
constantly monitoring clinical events“ [24] ist eine datengesteuerte Ereigniserkennung
zwingend erforderlich. Idealerweise wird diese vom KAS/PDMS bereitgestellt. Damit die
MLMs auf Patientendaten zugreifen können, ist eine entsprechende Schnittstelle
erforderlich. Zur Anbindung einer Arden-Engine an ein KAS/PDMS müssen also mindestens
zwei Voraussetzungen erfüllt sein:
• Die Bereitstellung eines Mechanismus zur Ereigniserkennung
• Eine Möglichkeit des Zugriffs auf die Patientendaten
Diese beiden Voraussetzungen sind bei vielen kommerziellen KAS/PDMS nicht gegeben.
Weiterhin sind Mechanismen erforderlich, die das Versenden von Nachrichten an das
19 Abbildung nach Tiffe aus einem Handout der HL7-Jahrestagung 2005, zu finden auf
http://www.hl7.de/veranstaltung/termine/2005_07_01.php.
20
Personal ermöglichen. Auch die Speicherung von per MLM generiertem Mehrwert in der
Patientenakte ist sinnvoll.
2.3.2 Datentypen der Arden-Syntax
Das Typsystem der Arden-Syntax ist bewusst einfach gehalten. Die wichtigsten Datentypen
entsprechen den nach Nadkarni in elektronischen Patientenakten typischerweise
vorkommenden primitiven Typen [44]:
• NULL: Nicht vorhandenes oder unsicheres Wissen
• BOOLEAN: Boolsche Werte
• NUMBER: Alle numerischen Typen (Ganzzahl und Gleitkomma)
• STRING: Zeichenketten beliebiger Länge
• TIME: Zeitstempel (Granularität theoretisch beliebig)
Jedem Datentyp der Arden-Syntax ist ein Zeitstempel zugeordnet, die sogenannte "Primary
Time“. In MLMs wird zusätzlich häufig der Datentyp DURATION für Zeiträume verwendet.
Daten dieses Typs werden aber meist nicht aus der Patientenakte gelesen, sondern im MLM
zur Laufzeit durch Arithmetik mit Zeitstempeln berechnet.
Über einen Zeitraum von ca. 15 Jahren (vor Version 2.5) stellten Listen den einzigen
zusammengesetzten Datentyp der Arden-Syntax dar. Listen können aus beliebigen
elementaren Typen zusammengesetzt werden. Die Arden-Syntax kennt keine strukturierten
Listen, d.h. keine Listen von Listen. Bei der Konkatenation zweier Listen ist das Ergebnis
immer eine flache Liste, die Listen werden beim Konkatenieren flachgeklopft20. Wird ein
READ-Statement ausgeführt, so wird das Ergebnis immer in Form von Listen zurückgeliefert.
Dabei sind zwei Varianten zu unterscheiden:
Das READ-Statement liefert eine einzige Liste zurück, z.B.:
LET glucose BE READ {...glucose...};
Das READ-Statement liefert mehrere Listen zurück, z.B.:
LET (icd10code, icd10text) BE READ {...icd10...};
Im letzteren Fall werden also mehrere Listen gleichzeitig befüllt. Betrachtet man das
Ergebnis eines READ-Statements als Tabelle, so wird jede Liste mit dem Inhalt einer Spalte
befüllt. Im Beispiel erhält man also zwei flache Listen zurück: icd10code mit den
Diagnosenschlüsseln und icd10text mit den zugehörigen Langtexten der Diagnosen.
Je mehr die Komplexität der Daten in einem MLM und insbesondere bei der Datenübergabe
zwischen MLMs zunimmt, je stärker zeigen sich die Beschränkungen der flachen Listen.
20 Eine Ausnahme gibt es beim MLM-Aufruf. Rufen sich MLMs gegenseitig auf, so ist es hier (und nur hier) möglich,
in den Statements CALL, ARGUMENT und RETURN eine Liste von Parametern anzugeben, deren Elemente selber
Listen sein können.
21
Jenders et al. [72] schlugen 2003 die Einführung von Objekten zur Überwindung dieser
Beschränkung vor. Dieser Vorschlag wurden im Jahre 2005 mit der Version 2.5 der Arden-
Syntax [73] umgesetzt. Objekte der Arden-Syntax entsprechen nicht denen aus
objektorientierten Sprachen wie Java, sondern den zusammengesetzten Datentypen, wie sie
in C als Structs und in Pascal als Records bekannt sind. Das Zusammensetzen einzelner
Variablen zu einem komplexen Datentyp ist die einzige Erweiterung, die Objekte in der
Arden-Syntax bieten. Im Gegensatz zu Listen, in denen auf Elemente nur über ihre Position
zugegriffen werden kann, können bei Objekten die Elemente über ihren Namen
angesprochen werden.
Der Unterschied zwischen der Verwendung von Listen und Objekten soll nun mit einem
einfachen Beispiel illustriert werden. Das Sub-MLM calculate_meldscore berechnet den
MELD-Score21 eines Patienten. Es benötigt drei Eingabeparameter: Einen Bilirubin-, einen
Serumkreatinin- und einen INR-Wert22. Die Übergabe der Parameter erfolgt unter Nutzung
von Listen folgendermaßen:
Parameterübergabe im aufrufenden MLM:
LET meldscore BE CALL calculate_meldscore WITH bili rubin, kreatinin,
inr;
Parameterübernahme im MLM calculate_meldscore:
LET args BE ARGUMENT;
LET bilirubin BE args[1];
LET kreatinin BE args[2];
LET inr BE args[3];
Der Zugriff auf die übergebenen Parameter erfolgt also über ihre Position in der
übergebenen Liste, wobei die Reihenfolge der Parameter dem MLM-Entwickler bekannt sein
muss. Unter Nutzung von Objekten sieht die Übergabe folgendermaßen aus:
LET mp BE NEW meldscoreparameters;
LET mp.bilirubin BE bilirubin;
LET mp.kreatinin BE kreatinin;
LET mp.inr BE inr;
LET meldscore BE CALL calculate_meldscore WITH mp;
Parameterübernahme im MLM calculate_meldscore:
LET args BE ARGUMENT;
LET bilirubin BE args.bilirubin;
LET kreatinin BE args.kreatinin;
LET inr BE args.inr;
21 MELD = Model for End-stage Liver Disease. Dieser Score dient der Bewertung der Leberfunktion. 22 INR = International Normalized Ratio, bewertet die Blutgerinnungszeit.
22
Hier muss der Wissensingenieur die Reihenfolge der Parameter nicht kennen, er muss
lediglich die Namen der Elemente des Objektes kennen. Bei einem so einfachen Beispiel
mag der Vorteil des Zugriffes über Namen nicht deutlich hervortreten, aber bei komplexeren
Datenstrukturen (inbesondere hierarchisch strukturierten) werden Programmierung und
Wartung erheblich vereinfacht. Listen und Objekte können beliebig ineinander geschachtelt
werden. Damit ist die "Flachheit“ der früheren Versionen überwunden, die auf dem impliziten
Flachklopfen konkatenierter Listen beruht. Beim Aufruf eines MLMs können damit z.B. Teile
der Patientenakte als Aufrufargument in strukturierter Form übergeben werden. Mit den
Objekten wurde auch eine Erweiterung des READ-Statements eingeführt, nämlich das
READ-AS-Statement. Dieses ermöglicht ein Einlesen von Daten als Liste von Objekten. So
kann z.B. über
LET patientlist BE READ AS patient {…};
eine Liste von Patientenobjekten ausgelesen werden. Dies erfordert bei komplexen
Strukturen entsprechende Metadaten, in denen das Patientenobjekt mit seinen Elementen
und deren Datentypen definiert ist, analog zu den Klassen im EAV/CR-Modell von Nadkarni
(siehe nachfolgenden Abschnitt).
Die Arden-Syntax bietet weiterhin ein Statement namens INTERFACE. Damit können
Funktionalitäten integriert werden, die nicht in Arden-Syntax selbst implementiert werden
können. Über INTERFACE kann beliebiger externer Code angebunden werden, der dann
über CALL aufgerufen werden kann. Ein typisches Anwendungsbeispiel hierfür ist der Aufruf
eines Web-Service-Clients.
2.4 Das EAV-Datenmodell
Entity-Attribute-Value (EAV) [74, 75] bezeichnet ein Datenmodell, das im medizinischen
Umfeld weit verbreitet ist und hier eine lange Tradition vorweisen kann:
"The first major use of EAV for clinical data was in the pioneering HELP system built at LDS
Hospital in Utah starting from the late 70s. [76]"
Beim EAV-Modell werden Attribute nicht über Spalten, sondern über Zeilen modelliert ("row
modelling"). Das Grundprinzip ist in Abbildung 8 dargestellt. Die obere Tabelle ist
konventionell modelliert, jeder Laborwert steht in einer eigenen Spalte. Die untere Tabelle ist
EAV-modelliert.
Das "Kippen" des Datenmodells in das EAV-Format bietet einige Vorteile. Der im
medizinischen Bereich wohl wichtigste besteht darin, dass beim Hinzufügen neuer Attribute
keine Änderung des Datenbankschemas nötig ist. Zudem sind im medizinischen Umfeld die
Attribute pro Patient sehr heterogen, so dass im konventionellen Modell viel Speicherplatz
durch dünn besetzte Tabellen verschwendet wird.
23
2012-06-02 08:00:001222012-06-02 08:00:003.94712
2012-06-01 12:00:001412012-06-01 12:00:004.14711
glucose_zeitstempelglucosekalium_zeitstempelkaliumfall
2012-06-02 08:00:001222012-06-02 08:00:003.94712
2012-06-01 12:00:001412012-06-01 12:00:004.14711
glucose_zeitstempelglucosekalium_zeitstempelkaliumfall
2012-06-02 08:00:00122glucose4712
2012-06-02 08:00:003.9kalium4712
2012-06-01 12:00:00141glucose4711
2012-06-01 12:00:004.1kalium4711
zeitstempelwertattributfall
2012-06-02 08:00:00122glucose4712
2012-06-02 08:00:003.9kalium4712
2012-06-01 12:00:00141glucose4711
2012-06-01 12:00:004.1kalium4711
zeitstempelwertattributfall
Abbildung 8: Vergleich der konventionellen Modellie rung mit dem EAV-Modell
Die Verwendung des EAV-Modells hat aber auch Nachteile. Der schwerwiegendste ist der
Verlust der semantischen Kontrolle, insbesondere der Typsicherheit. So könnte man in oben
dargestellter EAV-Tabelle Werte eintragen, deren Typ hier nicht sinnvoll ist. Ein weiterer
Nachteil ist die hohe Komplexität und schlechte Performance attributzentrierter Abfragen.
Allerdings werden diese in MLMs kaum verwendet, da der Datenzugriff typischerweise für
genau eine Entity in Form einer Fallnummer erfolgt ("object at a time"), was den Zugriff bei
entsprechender Indizierung der Attribute sehr performant macht.
Zum EAV-Modell gibt es eine sehr leistungsfähige Erweiterung namens EAV/CR (EAV with
Classes and Relationships). Damit ist es möglich, Datensätze zu hierarchisch strukturierten
Objekten zusammenzusetzen und Beziehungen zwischen Objekten zu modellieren. Dies
erfordert eine Anreicherung des Datenmodells mit Metadaten, ebenso ist externer
Programmcode erforderlich. Eine umfassende und leicht verständliche Einführung in EAV
und EAV/CR findet sich im aktuellen Werk "Metadata-driven Software Systems in
Biomedicine: Designing Systems that can adapt to Changing Knowledge" von Nadkarni [44].
2.5 Die Ergebnisse der Diplomarbeit
Im Jahre 2008 wurde am LMI die Diplomarbeit "Integration wissensbasierter Funktionen in
ein kommerzielles PDMS“ [21] erstellt, in deren Rahmen eine prototypische Anbindung der
Arden-Engine des EDSF vorgenommen wurde. Diese verfügt über eine Web-Service-
Schnittstelle und ermöglicht einen Datenzugriff per SQL. Die Anbindung an ICM musste über
AutoExport erfolgen, weshalb keine datengesteuerten Auslösung zur Verfügung stand. Bei
der Arden-Engine bestand das Problem, dass sie keine Ereignisnachrichten verarbeiten,
sondern nur einzelne MLMs starten konnte. Deshalb wurde ein Evoking-Mechanismus
implementiert, der die Zuordnung zwischen Ereignissen und MLMs herstellte.
Da die Arden-Engine nur SQL-Zugriffe unterstützte, AutoExport aber nur Textdateien
generieren konnte, bestand das Grundkonzept für den Datenzugriff in der Umsetzung der
exportierten Textdateien in eine SQL-Datenbank (ProxyDB), die als EAV-Datenbank
konzipiert war. Dazu wurde ein strukturiertes Format für die Targets konzipiert, das von
einem Export-Handler auf das Format der ProxyDB abgebildet wurde. Die zeitraubende
24
Tätigkeit der Neuerstellung und Änderung der JCFs und Templates wurde über eine
Webanwendung weitgehend automatisiert.
Die ProxyDB diente als reiner temporärer Zwischenspeicher für die Daten der jeweils
aktuellen Patienten. Bei jedem Knopfdruck oder Timerablauf wurden die Patientendaten
unmittelbar vor der MLM-Ausführung aktualisiert. Da ein vollwertiges Clincal Event
Monitoring eine datengesteuerte Ereigniserkennung erfordert, ICM diese aber nicht
unterstützt, wurde nach alternativen Lösungsansätzen gesucht. Die Einrichtung eines DB-
Triggers war mangels Zugriff auf die PatDB nicht möglich. Daher wurde untersucht, ob man
die datengesteuerte Auslösung über die zeitgesteuerte simulieren kann.
AutoExport bietet die Möglichkeit, ein Zeitfenster lückenlos in kurzen Intervallen über die
Zeitachse zu schieben. Allerdings werden auf der IOI viele Daten nicht direkt in die PatDB
geschrieben, sondern müssen zuerst manuell bestätigt werden. Je nach Arbeitsaufwand
kann dies mehrere Stunden dauern. Bei einem im Minutenbereich wandernden Fenster
können Ereignisse daher leicht verpasst werden. Lässt man das Zeitfenster dagegen sehr
langsam wandern, um dies zu vermeiden, so wird die Erkennung extrem reaktionsträge. Um
beide Effekte zu vermeiden und damit eine praxistaugliche Ereigniserkennung
bereitzustellen, müssten die Exporte in sehr kurzen Abständen stattfinden und sich zugleich
soweit in die Vergangenheit überlappen, dass keine spät bestätigten Ereignisse verpasst
werden. Da dies einen erheblichen Ressourcenverbrauch bedeutet hätte, wurde dieser
Ansatz verworfen und zunächst auf die datengesteuerte Auslösung von MLMs verzichtet.
ICM
AutoE
xport
PatDBTarget
ArdenEngine
read {...}4
3 2
1
MLM
<Eventname>
<Eventname>.jcf
template.txtexecute.bat
Web-Anwendung
Event-Definition
ProxyDB
E
C
BA
D EventDB
MLM-Evoker
Target-konverter
Event-Handler
Abbildung 9: Architektur des in der Diplomarbeit erst ellten Systems
Das Gesamtsystem ist in Abbildung 9 dargestellt. Um MLMs ausführen zu können, müssen
diese über die Web-Service-Schnittstelle in die Wissensbasis eingespielt werden (B).
Ebenso müssen Ereignisse definiert werden, auf die das System reagieren soll (A). Die
25
Webanwendung generiert bei der Definition von Ereignissen die erforderlichen
Konfigurationsdateien (E) und DB-Einträge (C). Zudem ermöglicht sie die Registrierung von
MLMs (A), die in der Wissensbasis der Arden-Engine abgelegt werden (D). Bei zeit- oder
benutzergesteuerter Auslösung von AutoExport werden alle erforderlichen Patientendaten in
ein Target geschrieben und ein Handler aufgerufen (1). Dieser enthält einen Konverter, der
die enthaltenen Daten in die ProxyDB umsetzt (2), sowie einen MLM-Evoker, der das
eingetretene Ereignis an die Arden-Engine meldet (3). Die MLMs beziehen die benötigten
Daten bei Ausführung über READ-Statements aus der ProxyDB (4). Die Ergebnisse werden
in Form eines Popup-Fensters dargestellt.
2.6 Procalcitonin als Sepsismarker
Die Sepsis ist eine schwerwiegende Komplikation bei der Behandlung von
Krankenhauspatienten und kann folgendermaßen definiert werden:
"Die Sepsis ist die systemische Entzündungsantwort auf eine Infektion, in deren Folge es oft zu
einer Minderperfusion der Organe und konsekutiv zum Organversagen kommt. [77]"
Die Bezeichnung "systemisch" bedeutet, dass es zu einer Reaktion des gesamten
Organismus und nicht nur des betroffenen Körperteils kommt. Der Verlauf einer Sepsis wird
in die vier Stufen SIRS, Sepsis, schwere Sepsis und septischer Schock eingeteilt [78]:
• SIRS steht für "Systemic Inflammatory Response Syndrome" und bezeichnet die
systemische Reaktion des Organismus, die über mindestens zwei
Grenzwertverletzungen einer Reihe von Parametern (z.B. Temperatur, Herz- oder
Atemfrequenz) bestimmt wird. SIRS kann als generalisierte Überreaktion des
Immunsystems betrachtet werden.
• Eine Sepsis liegt vor, wenn eine Infektion mit einem pathogenen Erreger als Ursache
des SIRS nachgewiesen werden kann.
• Eine Sepsis wird zur schweren Sepsis, wenn es zu Organversagen oder einer
anderen schwerwiegenden Komplikation wie einer Azidose oder einer
Bewusstseinsstörung kommt.
• Ein septischer Schock liegt vor, wenn der Blutdruck des Patienten trotz
ausreichender Volumensubstitution und des Einsatzes von Vasopressoren dauerhaft
abfällt (Hypotonie).
Die Sepsis stellt vor allem deswegen eine gefürchtete Komplikation dar, weil sie sehr häufig
zum Tod des Patienten führt:
"Sepsis und septischer Schock sind trotz Fortschritten in der Intensivmedizin die
Haupttodesursachen auf den nichtkardiologischen Intensivstationen in den westlichen Ländern.
[77]"
26
"Nach neuesten Erhebungen des vom BMBF geförderten Kompetenznetzwerkes Sepsis
(SepNet) erkranken in Deutschland pro Jahr 75.000 Einwohner (110 von 100.000) an einer
schweren Sepsis bzw. septischem Schock und 79.000 (116 von 100.000) an einer Sepsis. Mit
ca. 60.000 Todesfällen stellen septische Erkrankungen die dritthäufigste Todesursache nach
dem akuten Myokardinfarkt dar. [79]"
Neben der großen Gefahr für den Patienten gibt es bei der Sepsis natürlich auch einen
wirtschaftlichen Aspekt. Die Sepsis verursacht durch hohe Behandlungskosten einen
erheblichen volkswirtschaftlichen Schaden:
"Die direkten anteiligen Kosten, die allein für die intensivmedizinische Behandlung von
Patienten mit schwerer Sepsis anfallen, liegen bei ca. 1,77 Milliarden Euro. Ca. 30% des
Budgets für Intensivmedizin werden damit in die Behandlung der Sepsis investiert. [79]"
"Pro Jahr erkranken in Deutschland schätzungsweise 75.000 Patienten an einer schweren
Sepsis; in den USA sind es bis zu 750.000. Die Kosten der Intensivtherapie sind bei diesem
Patientengut aufgrund langer Verweildauern und aufwändiger Therapien außerordentlich hoch.
Ergänzt man die indirekten Kosten, die der Gesellschaft z. B. durch den Krankheitsausfall
entstehen, dann resultiert infolge der hohen Inzidenz insgesamt eine beachtliche
sozioökonomische Belastung. In Deutschland betragen die jährlichen Kosten der Sepsis für die
Gesellschaft schätzungsweise zwischen EUR 3,6 und 7,8 Mrd. Die schwere Sepsis ist somit
nicht nur aus der Perspektive der Intensivstation oder des Krankenhauses, sondern auch aus
gesundheitsökonomischer Sicht von beträchtlicher Relevanz. [80]"
Dies wirft die Frage auf, wie man die negativen Folgen der Sepsis eindämmen kann. Kumar
et al. [81] haben in einer umfassenden multizentrischen Studie den Einfluss verschiedener
Faktoren auf die Überlebensrate beim septischen Schock untersucht und kamen zu dem
Ergebnis, dass der allein entscheidende Faktor der zeitliche Abstand zwischen dem Beginn
der sepsisbedingten Hypotonie und der Gabe eines effektiven Antibiotikums ist, wobei eine
Sanierung des Infektionsherdes vorausgesetzt wird. Generell gilt also, dass Erkennung und
Behandlung der Sepsis so schnell wie möglich erfolgen müssen.
Ein wichtiges Hilfsmittel hierfür ist der Biomarker Procalcitonin (PCT), welcher der Diagnostik
von bakteriellen Infektionen dient [82] (eine übersichtliche Einführung zu Biomarkern in der
Intensivmedizin findet sich bei Standage und Wong [83]). Seit der Entdeckung seines
Potentials bei der Erkennung der Sepsis in den 90er Jahren [84] hat sein diagnostischer
Stellenwert kontinuierlich zugenommen. Laut Balci et al. [85] ist PCT anderen Biomarkern
bei der Unterscheidung zwischen SIRS und Sepsis klar überlegen, laut Nijsten et al. [86] ist
PCT anderen Markern auch in Punkto Reaktionszeit überlegen, d.h. der PCT-Spiegel des
Patienten reagiert vergleichsweise schnell auf eine sich entwickelnde Sepsis.
Die Grenzwerte für PCT als Sepsismarker sind nicht standardisiert. Zu Absolutwerten finden
sich bei Harbarth et al. [87] folgende Medianwerte für Aufnahmepatienten: 0,6 ng/ml für
SIRS, 3,5 ng/ml für Sepsis, 6,2 ng/ml für schwere Sepsis und 21,3 ng/ml für septischen
Schock, wobei der PCT-Wert durchaus auf Werte von über 100 ng/ml ansteigen kann. Oft
wird ein Richtwert von etwa 2 ng/ml als Untergrenze für den Verdacht auf Sepsis
27
angegeben, so z.B. bei Cheng [88] sowie bei Wilhelm [89]. Als untere Nachweisgrenze bei
der Laborbestimmung geben Gendrel und Bohuon einen Wert von 0,1 ng/ml an [90].
Eine Sepsis kann aber nicht allein über den PCT-Spiegel mit Sicherheit bestimmt werden.
Dieser kann auch ohne Vorhandensein einer Sepsis hoch sein, insbesondere nach großen
chirurgischen Eingriffen oder großflächigen Verletzungen. Umgekehrt kann es durchaus
vorkommen, dass der PCT-Spiegel auch bei Sepsis unauffällig ist, es müssen also immer
auch weitere Faktoren berücksichtigt werden [91]. Lichtenstern et al. betonen, dass dies
generell für Biomarker gilt und weisen auch auf erhebliche interindividuelle Unterschiede bei
der Entzündungsreaktion hin:
"Clinical decision just based on a biomarker is still not feasible because of the huge inter-
individual differences in the inflammatory response. [92]"
Neben seinem Stellenwert bei der Sepsiserkennung kann über den PCT-Spiegel auch die
Dauer der Antibiose mit ihren Kosten und Risiken gesenkt werden. So beschreiben Nobre et
al. [93] eine Senkung der Antibiosedauer von durchschnittlich 4 Tagen bei regelmäßigen
PCT-Messungen zur Wirkungskontrolle. Dabei ging die Aufenthaltsdauer auf der
Intensivstation um durchschnittlich 2 Tage zurück.
28
3 Methoden
In diesem Kapitel soll die Vorgehensweise zum Erreichen der beiden Ziele dieser Arbeit
dargestellt werden. Diese Ziele lauten:
• Z1: Bereitstellung einer vollwertigen technischen Plattform, im folgenden als ICM-
Arden bezeichnet, zur Ausführung von MLMs in ICM.
• Z2: Evaluierung eines MLMs zur Erkennung vermeidbarer PCT-Messungen.
Diese beiden Ziele weisen einen recht eigenständigen Charakter auf, daher wurde der
Methodenteil entsprechend strukturiert. Die Methoden der Bereitstellung der technischen
Plattform werden in Abschnitt 3.1 dargestellt. Das Vorgehen bestand in der Ermittlung und
Umsetzung eines Kataloges technischer und klinischer Anforderungen. Die technischen
Anforderungen ergaben sich aus den Eigenschaften der zu koppelnden Komponenten, die
klinischen wurden durch periodische Befragungen der Anwender bestimmt.
Die Methoden der PCT-Studie sind in Abschnitt 3.2 dargestellt. Das Vorgehen bestand in der
Durchführung einer Vorstudie und einer prospektiven Evaluierungsstudie. In der Vorstudie
wurde der klinische Workflow bei der Anforderung von PCT-Messungen untersucht und
bisherige Messungen analysiert. In der Evaluierungsstudie wurde der Einfluss eines MLMs
zur Erkennung vermeidbarer Messungen auf die tägliche PCT-Rate untersucht.
3.1 Bereitstellung der technischen Plattform
Die im Rahmen dieser Arbeit genutzen Materialien sind das PDMS ICM von Dräger und die
kommerzielle Arden-Umgebung "Arden Syntax IDE" von Medexter Healthcare. Der Prozess
der Integration dieser Komponenten gliederte sich in eine Analyse- sowie eine Konzeptions-
und Implementierungsphase (letztere im Folgenden zusammenfassend als
Implementierungsphase bezeichnet).
In der Analysephase wurden die Anforderungen an das zu erstellende System untersucht.
Die technischen Anforderungen wurden ermittelt, indem die Leistungsmerkmale der zu
koppelnden Komponenten mit denen einer idealen Arden-Umgebung kontrastiert wurden.
Die klinischen Anforderungen hingegen wurden direkt von den zukünftigen Anwendern
gestellt. Sie wurden durch periodische Interviews ermittelt, wobei der Hauptansprechpartner
für die Interviews ein Oberarzt der anästhesiologischen Klinik war, der eng mit dem LMI
zusammenarbeitet.
In der nachfolgenden Implementierungsphase wurde der Anforderungskatalog umgesetzt.
Dazu wurde zunächst eine Möglichkeit des Zugriffs auf die Patientendaten sowie eine
Möglichkeit zur datengesteuerten Auslösung implementiert, um überhaupt die
Grundvoraussetzungen für die Ausführung von MLMs zu schaffen. Danach wurde die Arden-
Engine durch Integration in einen Application-Server zum Arden-Server erweitert und
29
Kommunikationsendpunkte sowie Präsentationsmechanismen implementiert. Das
resultierende System soll als ICM-Arden bezeichnet werden.
3.1.1 Methoden der Analysephase
Das erste Ziel dieser Arbeit war die Bereitstellung einer vollwertigen Plattform zur
Ausführung von MLMs. Dies warf zunächst einmal die Frage auf, was man unter dem Begriff
"vollwertig" überhaupt zu verstehen hat. Gemeint ist damit einerseits, dass ICM-Arden alle
Merkmale unterstützen sollte, die im Leistungsspektrum der Arden-Syntax in der
verwendeten Version 2.5 enthalten sind. Dies beinhaltet auch die in Abschnitt 2.3.1
dargestellte Auslösearten von MLMs (benutzer, zeit- und datengesteuert). Der Prototyp der
Diplomarbeit war in diesem Sinne nicht vollwertig, da eine datengesteuerte Ausführung von
MLMs nicht möglich war. Gemeint ist mit "vollwertig" andererseits, dass sich ICM-Arden
möglichst eng an den Vorgaben der klinischen Anwender orientiert. Der Prototyp war auch
hier nicht vollwertig, da er als Kommunikationsendpunkte lediglich unformatierte Popup-
Meldungen unterstützte, was von den Anwendern nicht als optimal betrachtet wurde.
Hinsichtlich der Anforderungen der Anwender war es sehr von Vorteil, dass diese den
Prototypen aus der Diplomarbeit kannten und daher bereits eine recht gute Vorstellung
hatten, was die Arden-Syntax überhaupt ist und wozu man MLMs einsetzen kann. Die
Interviews konzentrierten sich auf folgende Fragen:
• Durch welche Ereignisse sollen MLMs ausgelöst werden?
• Welche Kommunikationsendpunkte sind zu implementieren, d.h. wie sollen die
Anwender benachrichtigt werden?
• Welche Mechanismen zur Präsentation von MLM-Ergebnissen sind gefordert?
Zur Bestimmung der technischen Anforderungen war eine Analyse der zu koppelnden
Komponenten, insbesondere deren Schnittstellen, erforderlich. Zu untersuchen waren also
die Arden-Umgebung mit ihrer Schnittstelle ("ArdenHostInterface") und das PDMS ICM mit
seiner Schnittstelle AutoExport.
Die Arden-Umgebung von Medexter wurde dem LMI Ende 2009 bereitgestellt. Nach einer
Prüfung der Systemvoraussetzungen wurde sie auf einem Entwicklungsrechner installiert.
Danach wurden unter Verwendung der IDE23 eine Reihe von MLMs geschrieben und ihre
Funktion unter Verwendung der integrierten MLM-Testumgebung auf Korrektheit überprüft.
Zudem wurde untersucht, wie man MLMs mittels der Testumgebung mit Eingabedaten
versorgen kann. Ebenso wurde die Arden-Engine durch Aufruf von einem externen Java-
Programm aus getestet, indem ein im Lieferumfang enthaltenes Codebeispiel an die eigenen
Bedürfnisse angepasst wurde. Das Beispiel wurde so erweitert, dass ein erster Datenzugriff 23 IDE steht für Integrated Development Environment. Die eigentliche IDE ist nicht zu verwechseln mit "Arden
Syntax IDE". Arden Syntax IDE ist der Name des kompletten Produktes von Medexter (beinhaltet die eigentliche
IDE mit ihrer Testumgebung, den Compiler und die Engine).
30
vom MLM aus per SQL ausgeführt werden konnte. Für den zentralen Analysevorgang des
ArdenHostInterfaces wurde ein Projekt in Eclipse24 angelegt und die Arden-Engine als
externe Bibliothek eingebunden25. Nun wurde ein Testprogramm zum Aufruf einzelner MLMs
geschrieben, um zu prüfen, wie die Arden-Engine mit dem ArdenHostInterface interagiert. Zu
diesem Zweck wurden in den ausgeführten MLMs diejenigen Arden-Syntax-Anweisungen
aufgerufen, die Curly-Braces-Expressions enthalten (z.B. das READ-Statement). Das
ArdenHostInterface wurde dazu so erweitert, dass bei jedem Aufruf die an dieses
übergebenen Parameter formatiert ausgegeben werden. In der Gegenrichtung wurde
geprüft, wie Daten vom ArdenHostInterface an die MLMs zurückgegeben werden. Dies
wurde mit primitiven Typen, Listen und Objekten untersucht. Es wurde also untersucht, wie
Datentypen der Programmiersprache Java auf Datentypen der Arden-Syntax abgebildet
werden können und vice versa.
Die ICM-Exportschnittstelle AutoExport war bereits im Rahmen der Diplomarbeit einer
Analyse unterzogen worden. Da seitdem mehrere Releasezyklen vergangen waren, wurde
die Analyse erneut durchgeführt. Dazu wurde zunächst die aktuellste Version der
Dokumentation von Dräger angefordert und mit der in der Diplomarbeit verwendeten Version
verglichen. Ein neu hinzugekommenes Feature zum Export von Medikationsdaten im
Anordnungsdialog wurde durch Anlegen eines Exportbuttons und Aufsetzen eines
Exportjobs getestet. Im speziellen Kontext der mikrobiologischen Daten (MiBi-Daten) wurde
AutoExport einer detaillierten Analyse unterzogen. MiBi-Daten sind von hoher klinischer
Relevanz und insbesondere im Rahmen eines Infektionsmonitorings von hoher Wichtigkeit,
zudem gab es von klinischer Seite eine Anforderung für eine aufbereitete Darstellung.
Hierfür wurden entsprechende Exportjobs erstellt, wobei die erzeugten Targets aber schnell
zeigten, dass die gelieferten MiBi-Daten nicht ausreichend strukturiert sind, um sie in MLMs
verarbeiten zu können. Daher wurde ein Parser geschrieben, der möglichst viele
Detailinformationen aus den MiBi-Daten extrahiert.
3.1.2 Methoden der Implementierungsphase
Die Ergebnisse der Analysephase (siehe Abschnitt 4.1.1) zeigten, dass in der
Implementierungsphase drei Teilschritte erforderlich waren: Der erste Schritt erforderte die
Implementierung von Workarounds für externen Datenzugriff und datengesteuerte
Ereigniserkennung, da beide Funktionalitäten von AutoExport nicht bereitgestellt werden, für
die Implementierung von ICM-Arden aber eine elementare Grundvoraussetzung darstellten.
Der zweite Schritt bestand in der Bereitstellung des Arden-Servers, was die Implementierung
des ArdenHostInterfaces als Schnittstelle zur Kommunikation zwischen Arden-Engine und
PDMS beinhaltet. Der dritte Schritt bestand in der Implementierung von
Präsentationsmechanismen, um die Darstellung von MLM-Ergebnissen auf eine Weise zu
ermöglichen, die den Anforderungen der klinischen Anwender entsprach. 24 Eclipse ist eine freie Entwicklungsumgebung für Java. 25 Die Engine selbst wurde als einzelnes jar-File ausgeliefert (jar steht für Java Archive)
31
3.1.2.1 Datenbereitstellung und Ereigniserkennung
Das Grundkonzept der Datenbereitstellung wurde aus der Diplomarbeit übernommen. Der
Mechanismus wurde im Rahmen dieser Arbeit aber erheblich erweitert. Alle von den MLMs
benötigten Patientendaten werden per Exportjob periodisch in eine externe Datenbank
namens ProxyDB repliziert. Die MLMs greifen dann statt auf die PatDB auf die replizierten
Daten der ProxyDB zu. Hierfür wurde eine Reihe von Exportjobs aufgesetzt, die im Abstand
von wenigen Minuten alle relevanten Daten in strukturierter Form in ein Target exportiert. Ein
Export-Handler wurde entwickelt, der die Targets unmittelbar nach jedem Exportlauf parst
und die enthaltenen Daten in die ProxyDB schreibt. Dabei wurden verschiedene
Aktualisierungsstrategien erprobt. Als zweckmäßigste, da performanteste Lösung erwies
sich die Aktualisierung im Snapshot-Modus durch Löschen aller Daten aller aktuellen
Patienten und anschließendes Wiederbefüllen per Bulk-Insert26, wobei diese Schritte als
Transaktion gekapselt sind.
Zeittn tn+1tn-1
Wert Zeitstempel
132 4.11.2009 18:31
146 4.11.2009 19:04
140 4.11.2009 19:46
Wert Zeitstempel
132 4.11.2009 18:31
146 4.11.2009 19:04
140 4.11.2009 19:46
Wert Zeitstempel
132 4.11.2009 18:31
146 4.11.2009 19:04
140 4.11.2009 19:46
138 4.11.2009 20:22
Alle Werte in Export tn warenbereits im Export tn-1 enthalten� kein Ereignis eingetreten
Export tn+1 enthält einen Wert,der in Export tn nicht enthalten war
� Ereignis eingetreten
Abbildung 10: Ansatz zur Erkennung von datengesteue rten Ereignissen
Nach erfolgter Datenbereitstellung musste eine Möglichkeit zur datengesteuerten
Ausführung von MLMs gefunden werden. Dies warf die Frage auf, wie man dies unter
Verwendung einer reinen Exportschnittstelle, die gar keine datengesteuerte Auslösung
26 Ein Bulk-Insert ist ein Insert-Befehl, mit dem gleichzeitig mehrere Tupel in eine Tabelle eingefügt werden. Fügt
man beispielsweise drei Tupel über folgende drei Insert-Befehle ein:
insert into eav_table values ('4711', 'glucose', '126', '2012-04-28 22:00:00');
insert into eav_table values ('4711', 'glucose', '128', '2012-04-29 07:00:00');
insert into eav_table values ('4711', 'glucose', '144', '2012-04-29 15:00:00');
So kann man diese zu einem einzigen Bulk-Insert zuammenfassen:
insert into eav_table values ('4711', 'glucose', '126', '2012-04-28 22:00:00'), ('4711', 'glucose', '128', '2012-04-29
07:00:00'), ('4711', 'glucose', '144', '2012-04-29 15:00:00');
Ein derartiger Bulk-Insert ist bei sehr großen Tupelmengen (bei der ProxyDB zehntausende von Tupeln pro
Aktualisierung) um Größenordnungen performanter als viele sequentielle Inserts.
32
kennt, überhaupt realisieren kann. Diese Überlegung wurde bereits im Rahmen der
Diplomarbeit angestellt, der entsprechende Ansatz damals aber verworfen, da durch die
permanent stattfindenden Exporte, die sich hinsichtlich der Zeiträume der exportierten Daten
auch noch überlappen müssen, sehr viele Systemressourcen verbraucht werden. Da dies
aber auch mit der aktuellen Version von AutoExport die einzige Möglichkeit darstellte, die
Ereigniserkennung überhaupt realisieren zu können, wurde dieser Ansatz nun doch
implementiert und der daraus resultierende Ressourcenverbrauch billigend in Kauf
genommen. Das Grundprinzip der Ereigniserkennung ist in Abbildung 10 dargestellt (in der
Abbildung sind nur die für das grundlegende Verständnis notwendigen Felder dargestellt).
Es besteht im Vergleich des jeweils aktuellen Exportes mit den Daten der vorhergehenden
Exporte. Enthält der aktuelle Export einen Wert, der bisher noch nie exportiert wurde, so wird
ein Ereignis gemeldet. Der Vergleich wird vom Export-Handler zusammen mit der
Datenbereitstellung erledigt. Zum Versand von Ereignismeldungen wurde ein SOAP-Client in
den Export-Handler integriert.
Export-Job
Export-Handler
Export-VM Mandant n
Export-Job
Export-Handler
Export-VM Mandant 2
Export-Job
Export-Handler
Export-VM Mandant 1
ProxyDBArden-Server
…
Ereignismeldungen (SOAP) Aktualisierung (SQL)
Datenzugriff (SQL)
Abbildung 11: Herstellung der Mandantenfähigkeit
Um MLMs auf verschiedenen Mandanten ausführen zu können, mussten
Datenbereitstellung und Ereigniserkennung mandantenübergreifend funktionieren. Dazu
wurde untersucht, ob ein Exportrechner eines Mandanten auch Patientendaten anderer
Mandanten exportieren kann. Allerdings kann ein Exportrechner bei ICM grundsätzlich nur
Daten des eigenen Mandanten exportieren, weswegen ein verteilter Ansatz notwendig
wurde. Zunächst wurde eine Anfrage an Dräger gestellt, ob die ICM-interne Fall-ID, die einen
Fall eindeutig identifiziert27 und in allen Tabellen der ProxyDB als Schlüssel verwendet wird,
mandantenübergreifend eindeutig ist, was positiv beantwortet wurde. Die Tabellen der
ProxyDB wurden an den entsprechenden Stellen um eine Mandanten-ID erweitert. Der
bisherige Export-Handler wurde so angepasst, dass alle mandantenspezifischen Anteile in
27 Die SAP-Aufnahmenummer ist hierfür nicht geeignet, da ein Patient innerhalb eines Krankenhausaufenthaltes
mehrfach zwischen Intensiv- und Normalstation verlegt werden kann. Die Aufnahmenummer ist in diesem Fall
immer die gleiche, während für jeden Intensivaufenthalt eine andere interne Fall-ID vergeben wird.
33
Include-Dateien ausgelagert wurden. Dies dient einer vereinfachten Wartung des Systems.
Bei Anpassungen am Export-Handler kann er somit zentral verteilt und auf allen Mandanten
mit der neuen Version überschrieben werden. Der Ansatz zur Herstellung der
Mandantenfähigkeit ist in Abbildung 11 dargestellt. Für jeden Mandanten wurde ein virtueller
Jobrechner eingerichtet und als Exportrechner konfiguriert sowie mit einem Export-Handler
versehen, der die ProxyDB aktualisiert und Ereignismeldungen an den Arden-Server sendet.
Für den Spezialfall der MiBi-Daten wurde eine Sonderlösung implementiert, da AutoExport
diese nicht in einer Form liefern kann, die ausreichend strukturiert ist, um alle benötigten
Elemente zuverlässig herauszuparsen. Deshalb wurde der Nachrichtenstrom zwischen dem
Laborsystem und ICM am Kommunikationsserver dupliziert. Ein Parser für die eingehenden
HL7-Nachrichten (MiBi-Parser) wurde entwickelt, der die relevanten Daten (Anforderungen,
Befunde, Kommentare, Diagnosenvorschläge) extrahiert und in entsprechende Tabellen der
ProxyDB schreibt. Diese Tabellen wurden konventionell modelliert, da das EAV-Format hier
aufgrund der starren Struktur und fehlender Nullwerte nicht sinnvoll gewesen wäre.
3.1.2.2 Implementierung des Arden-Servers
Nach erfolgreicher Bereitstellung von Workarounds für Datenzugriff und Ereigniserkennung
konnte nun die eigentliche Integration von ICM und der Arden-Engine in Angriff genommen
werden. Hierfür mussten die Ansteuermethoden für die Arden-Engine und die Curly-Braces-
Methoden des ArdenHostInterfaces implementiert werden.
Die Ansteuermethoden wurden auf der Basis von SOAP-Web-Services realisiert. Dazu
wurde die komplette Arden-Engine in einen Open-Source-Java-Application-Server (WSAS28
von WSO2) integriert. Dieser wurde wegen seiner komfortablen Administrierbarkeit
ausgewählt. Er bietet beispielsweise die Möglichkeit, POJO-Klassen29 per Mausklick als
Web-Services bereitzustellen, wobei die SOAP-Schnittstelle und die WSDL30-Datei
automatisch generiert werden. Zwei Ansteuermethoden wurden implementiert, eine für den
direkten Aufruf einzelner MLMs sowie eine für die Meldung von Ereignissen an die Arden-
Engine. Zusätzlich wurde die Klasse ICMArdenService implementiert und dem
ArdenHostInterface vorgeschaltet. Diese enthält Methoden, die SOAP-Nachrichten
entgegennehmen und an die entsprechenden Ansteuermethoden des ArdenHostInterfaces
weiterleiten.
Die Implementierung der Curly-Braces-Methoden begann mit der Methode zur Verarbeitung
des READ-Statements. Um den Inhalt der Curly-Braces für den Anwender möglichst
verständlich zu machen, wurde ein Aliaskonzept implementiert, das mittels parametrierbarer 28 http://wso2.com/products/application-server/ 29 POJO steht für Plain Old Java Object und bezeichnet „normale“ Klassen ohne Java-EE-Technologie. WSAS
benötigt keine Annotierung der Methoden, um die Web-Service-Schnittstelle zu generieren. Damit dies beim
Rückgabetyp funktioniert, muss dieser der Java-Bean-Konvention entsprechen. 30 WSDL steht für "Web Service Description Language". Eine WSDL-Datei enthält eine vollständige Beschreibung
einer Web-Service-Schnittstelle im XML-Format und ermöglicht die komfortable Instanziierung eines passenden
Client-Objektes, siehe http://www.w3.org/TR/wsdl.html
34
Statements von der SQL-Schnittstelle abstrahiert, indem es die SQL-Abfrage zur Laufzeit
aus den Curly-Braces-Parametern generiert. Die ausgelesenen Patientendaten werden in
Arden-Syntax-Listen konvertiert und über die von der Arden-Engine bereitgestellte API an
diese zurückgeliefert.
Die Implementierung der Kommunikationsendpunkte für das WRITE-Statement begann mit
den Emailadressen. Hierfür wurde die JavaMail31-API in das ArdenHostInterface
eingebunden. Als Emailformat wurde text/html gewählt, um die HTML- und JavaScript-
basierten Präsentationsmechanismen (siehe unten) auch in Emails nutzen zu können. Für
den Versand von SMS-Nachrichten an DECT-Telefonnummern wurde das SMS-Gateway der
Hausverwaltung angebunden, welches sich über strukturierte Emails an einen speziellen
Server ansteuern lässt. Für die Darstellung von MLM-Ergebnissen bei der
benutzergesteuerten Ausführung wurde kein Kommunikationsendpunkt für WRITE
implementiert, sondern ein alternativer Ansatz gewählt, der im folgenden Abschnitt
beschrieben wird.
3.1.2.3 Präsentationsmechanismen
Die Implementierung des MLM-Viewers erfolgte in der Skriptsprache AutoIT32 in Form eines
bewusst minimalistisch gehaltenen Browsers, der eine ebenfalls bewusst minimalistisch
gehaltene Web-Anwendung anzeigt. Diese enthält eine Buttonleiste und einen
Anzeigebereich für die MLM-Ergebnisse. In diese Web-Anwendung wurde ein SOAP-Client
integriert, der bei Nutzung eines Buttons eine Ereignisnachricht an den Arden-Server sendet
und das zurücklieferte Ergebnis, bestehend aus den Return-Werten aller ausgelösten MLMs,
im Anzeigebereich darstellt. Ein Screenshot des Viewers findet sich im Ergebnisteil in
Abbildung 21.
Zur Generierung der geforderten Anzeigeelemente wurde eine Präsentationsschicht direkt in
Arden-Syntax in Form von Sub-MLMs geschrieben. Diese MLMs generieren ausschließlich
HTML/CSS/JavaScript und wurden als dynamische Templates konzipiert, in die die
Aufrufparameter an den entsprechenden Stellen eingesetzt werden. Ein Päsentations-MLM
ist also eine parametrierbare Schablone für HTML- bzw- JavaScript-Code. Wo ein simples
Einsetzen in das Template nicht ausreicht, werden einzelne Anzeigebestandteile durch
Schleifen und bedingte Verzweigungen generiert und dynamisch zusammengesetzt. Dabei
liefert jedes MLM einen Anzeigeblock in Form eines Strings zurück, der z.B. formatierten
Text oder eine Tabelle enthält. Diese Anzeigeblöcke werden dann vom aufrufenden MLM
zum finalen Rückgabewert verkettet und an den Viewer gesendet.
Formatierung von Zeitangaben
Die Formatierung von Zeitstempeln (Datentyp TIME) wird von der Arden-Syntax direkt über
den FORMATTED-WITH-Operator unterstützt. Hierfür wurden die geforderten Formate per 31 http://www.oracle.com/technetwork/java/javamail/ 32 Ein Wrapper für die native Windows-API, siehe http://www.autoitscript.com/site/autoit/
35
Formatstring in die Arden-Egine integriert. Zur Formatierung von Zeitdauern (Datentyp
DURATION) wurde externer Code über INTERFACE angebunden, der die Zeitangaben über
reguläre Ausdrücke von Englisch auf Deutsch übersetzt und ICM-konform darstellt.
Formatierung von Text
Hierfür wurde das MLM FontFormatter geschrieben. Der übergebene Text wird,
entsprechend der weiteren Übergabeparameter (Schriftstil, -größe, -farbe), in entsprechende
HTML-Tags gekapselt.
Generierung von Tabellen
Für die Generierung von Tabellen wurden zwei verschiedene MLMs geschrieben. In vielen
Fällen basieren Tabellen auf einfachen Listen, beispielsweise einer Liste von
Grenzwertverletzungen eines Laborparameters oder einer Liste von berechneten
Scorewerten. Hierfür wurde das MLM ListToTable geschrieben, dem eine Arden-Syntax-Liste
als Parameter übergeben wird. Das Prinzip von Aufruf und Verarbeitung ist in Abbildung 12
dargestellt. Das Sub-MLM durchläuft die übergebene Liste in einer Schleife und generiert
eine dreispaltige Tabelle (fortlaufende Nummer, Wert, Zeitstempel).
<table><tr><th>#</th><th>Wert</th><th>Zeitstempel</th></tr><tr><td>1.</td><td>1.35</td><td>…
Von ListToTable erzeugter HTML-Code Darstellung des HTML-Codes im Browser
LET table BE CALL ListToTable WITH critical_calcium _values;
String “table“enthält HTML-Code
…for element in valuelist do
…table := table || "<tr>";table := table || "<td>" || linenumber || ".</td>";table := table || "<td>" || value || "</td>";table := table || "<td>" || timestamp || "</td>"; table := table || "</tr>";
enddo;…
Arden-Syntax-Code im Sub-MLM ListToTable
Abbildung 12: Prinzip der Generierung von Tabellen
Für komplexe Tabellen, die sich nicht aus einfachen Listen generieren lassen, wurde das
MLM TableGenerator geschrieben, das mit einem Beschreibungsobjekt von Typ
TableDescription aufgerufen wird. Dieses enthält unter anderem eine Liste von
Spaltenbeschreibungen, wiederum in Form von Beschreibungsobjekten. Die Elemente des
36
Beschreibungsobjektes werden auf HTML-Elemente abgebildet und zu einer Tabelle
zusammengesetzt.
Skalierbare Grafiken mit Highlighting (Lineplots)
Lineplots wurden unter Verwendung der freien JavaScript-Bibliothek Flot33 realisiert. Das
Vorgehen bestand darin, zuerst händisch in einem Editor den JavaScript-Code einer Grafik
mit den gewünschten Eigenschaften auf Basis der Labordaten eines geeigneten Patienten
zu erstellen. Nachdem die Grafik sukzessive den Anforderungen der klinischen Anwender
angepasst werden konnte, wurde der JavaScript-Code in ein MLM eingefügt und so
erweitert, dass die Werte und Gestaltungsparameter dynamisch aus den Aufrufparametern in
den Code übernommen werden. Das MLM liefert also einen String mit gültigem JavaScript-
Code zurück, der die Grafik in einem JavaScript-fähigen Browser zeichnet. Da hier recht
umfangreiche Aufrufparameter wie Grenzwertlinien oder zu markierende Einzelwerte nötig
sein können, wurde das Arden-Syntax-Objekt DiagramDescription definiert. Dieses wird vom
aufrufenden MLM als Aufrufparameter an das Lineplotter-MLM übergeben.
Auf- und Zuklappen von Bereichen
Das Auf- und Zuklappen von Anzeigebereichen wurde unter Nutzung des HTML-Elementes
"DIV" realisiert. Dies ist ein HTML-Element, mit dem beliebige Abschnitte einer HTML-Seite
für den Betrachter unsichtbar gekapselt und mit einer ID zur Ansteuerung versehen werden
können. Der JavaScript-Code wurde so angepasst, dass der Bereich über einen
Aufrufparameter auf sichtbar oder unsichtbar gesetzt werden kann. Das MLM generiert
derartigen Code und liefert neben dem gekapselten Anzeigebereich einen Hyperlink zurück,
mit dem dieser auf- und zugeklappt werden kann. Der Code wurde so gestaltet, dass sich
die Beschriftung des Hyperlinks automatisch an die Sichtbarkeit des Anzeigebereichs
anpasst.
3.2 Methoden der Evaluierungsphase
In der Evaluierungsphase wurde der Einfluss eines MLMs auf die tägliche Rate an PCT-
Messungen untersucht. Hierfür bestand eine Anforderung von klinischer Seite, da auf der IOI
beobachtet wurde, dass regelmäßig mehr PCT-Messungen angeordnet werden, als
medizinisch erforderlich sind. Da die Bestimmung des PCT-Spiegels mit relativ hohen
Laborkosten verbunden ist, wurde eine Anfrage an den LMI gestellt, ob ein MLM zur
Erkennung vermeidbarer Messungen (im Folgenden als PCT-MLM bezeichnet) erstellt
werden kann. Der Einfluss des PCT-MLMs auf die täglichen Anforderungen sollte in einer
prospektiven Studie evaluiert werden. Die Evaluierung gliederte sich in zwei Phasen: Die
Vorstudie zur a-priori-Analyse der relevanten Parameter und des klinischen Workflows sowie
die eigentliche Studie (im Folgenden als PCT-Studie bezeichnet) mit der Auswertung der
33 http://www.flotcharts.org/
37
erfassten Daten. Alle Auswertungen wurden unter Nutzung eines Standardwerkes der
medizinischen Statistik durchgeführt [94].
3.2.1 Die Vorstudie
Die Vorstudie begann mit der Befragung der klinischen Mitarbeiter, um den Workflow von der
Anordnung einer PCT-Messung bis zum Eingang des Messergebnisses in ICM
nachvollziehen zu können. Der Parameter PCT wurde in die Liste der in die ProxyDB zu
replizierenden Daten aufgenommen, um Vergleichsdaten für spätere statistische Tests zu
sammeln. Die Phase der Erfassung der Vergleichsdaten soll im Folgenden als PRE
bezeichnet werden. Als Zielgröße für die spätere PCT-Studie wurde die tägliche PCT-Rate
gewählt, d.h. die Anzahl der PCT-Messungen eines Tages geteilt durch die Zahl der
Patienten im Sinne der Bettenbelegung dieses Tages, wobei die Patienten mindestens einen
Liegetag aufweisen müssen34. Die Regeln für die Erkennung vermeidbarer Messungen (im
Folgenden als "Regelsatz" bezeichnet) und die zugehörigen Grenzwerte wurden dabei von
ärztlicher Seite vorgegeben. Auch die Auswahl des Studiendesigns erfolgte in enger
Zusammenarbeit mit dem Oberarzt der IOI. Eine Randomisierung wurde als problematisch
erkannt und ein Crossover-Design von ärztlicher Seite abgelehnt, daher wurde letztlich ein
ON-OFF-ON-OFF-Design vereinbart.
Die Analyse der Vergleichsdaten erfolgte mit der Open-Source-Statistiksoftware R35. Zur
Prüfung des Typs der Wahrscheinlichkeitsverteilung wurde der Shapiro-Wilk-Test auf die
Vergleichsdaten angewendet. Für die Fallzahlplanung war eine Abschätzung des zu
erwartenden Effektes notwendig, der vom Oberarzt mit 15% Senkung angegeben wurde.
Um überprüfen zu können, ob diese auf Erfahrung beruhende Schätzung auf Basis der
Vergleichsdaten bestätigt werden kann, wurde zunächst der Regelsatz in Arden-Syntax
übersetzt und in ein MLM integriert, das von anderen MLMs mit einer Liste von PCT-Werten
eines Patienten als Eingabeparameter aufgerufen werden kann. Für die Verifikation des
Regelsatz-MLMs von ärztlicher Seite wurde ein MLM geschrieben und im Produktiv-System
freigeschaltet, das auf Knopfdruck die PCT-Werte eines Patienten ausliest und mittels des
Regelsatz-MLMs sowohl einen aktuellen Vorschlag als auch eine Analyse der bisherigen
PCT-Messungen hinsichtlich ihrer Vermeidbarkeit generiert. Nach erfolgter Verifikation wurde
der Regelsatz auf den Vergleichszeitraum PRE anwendet und der Anteil der PCT-
Messungen bestimmt, die nach dem Regelsatz vermeidbar gewesen wären.
Anzumerken ist hierbei, dass Im Rahmen der Vorstudie auch eine Reihe von Fällen entdeckt
wurden, die einen unzulässig hohem Zeitabstand zwischen zwei Messungen aufwiesen. In
diesen Fällen wurden also nicht zu viele Messungen gemacht, sondern notwendige
34 Ein abrechenbarer Liegetag liegt vor, wenn sich Aufnahmetag und Entlassungstag unterscheiden. Es kommt
durchaus vor, dass ein Patient am Aufnahmetag wieder entlassen wird und damit keinen vollen Liegetag aufweist.
Diese Patienten fallen hinsichtlich PCT aber kaum ins Gewicht, da für sie nur wenige Messungen (ca. 0,7% aller
Messungen) angefordert werden. 35 http://www.r-project.org/
38
Messungen wurden versäumt. Diese Versäumnisse wurden durch eine Analyse der
Zeitabstände quantitativ abgeschätzt.
3.2.2 Die PCT-Studie
Nachdem die Vorstudie eine Beurteilung des zu erwartenden Effektes erlaubt hatte, konnte
die eigentliche Evaluierung vorgenommen werden. Die Grundlage der Evaluierungsstudie
bildete folgendes Studienprotokoll:
Typ der Studie
Die PCT-Studie wurde als prospektive Interventionsstudie konzipiert.
Studiendesign
Die PCT-Studie hatte ein ON-OFF-ON-OFF-Design, also zweimaliges Ein- und Ausschalten
der Intervention (ON = Intervention eingeschaltet, OFF = Intervention ausgeschaltet) wie in
Abbildung 13 ersichtlich. Dabei ist S der Startzeitpunkt und PD die Phasendauer von 28
Tagen.
Abbildung 13: Phasen der PCT-Studie
Intervention
Die Intervention war die Freischaltung des PCT-MLMs im Produktivsystem. Das PCT-MLM
generierte auf Knopfdruck eine Liste von Vorschlägen mit Begründungen. Abbildung 14 zeigt
einen Ausschnitt aus der Vorschlagsliste (die links neben den Vorschlägen stehenden
Patientendaten wurden aus Datenschutzgründen abgeschnitten). Die Ärzte wurden vom
Oberarzt vor Studienbeginn über die notwendigen Details informiert und um Teilnahme
gebeten. Freischaltung und Abschaltung des PCT-MLMs erfolgten vollautomatisch unter
Nutzung der temporalen Operatoren der Arden-Syntax.
Da die Sonderlaborliste für jeden Bereich separat erstellt wird, wäre es für die erstellenden
Ärzte umständlich gewesen, eine einzige Liste mit Vorschlägen für alle Patienten
anzuzeigen. Stattdessen wurden zwei separate Buttons für den herz- und den
39
allgemeinchirurgischen Bereich angelegt, die beide das PCT-MLM aufrufen. Dieses konnte
anhand der Ereignisnachricht erkennen, über welchen Button es aufgerufen wurde, und
schränkte die Vorschlagsliste auf den entsprechenden Bereich ein.
Abbildung 14: Ausschnitt aus der Vorschlagsliste
Studienteilnehmer
Zu den Teilnehmern der Studie zählten alle Stationsärzte, die während der ON-Phasen für
die Erstellung der Sonderlaborliste zuständig waren. Es gab keine weiteren Ein- oder
Ausschlusskriterien.
Zeitlicher Ablauf
Alle vier Phasen der Studie hatten die gleiche Dauer von 28 Tagen. Zusätzlich zu diesen vier
Phasen wurden die PCT-Raten für weitere vier Wochen erfasst (POST), um den weiteren
Verlauf in die Analyse einzubeziehen. Die nachstehende Tabelle listet alle Phasen mit
Beginn und Ende auf. Der Phasenwechsel erfolgte jeweils um Mitternacht.
Phase Beschreibung von bis
einschließlich
ON1 1. Einschalten des PCT-MLMs 17.01.2011 13.02.2011
OFF1 1. Ausschalten des PCT-MLMs 14.02.2011 13.03.2011
ON2 2. Einschalten des PCT-MLMs 14.03.2011 10.04.2011
OFF2 2. Ausschalten des PCT-MLMs 11.04.2011 08.05.2011
POST 4-Wochen-Zeitraum nach Studienende 09.05.2011 05.06.2011
Zielgröße
Die Zielgröße, d.h. der Untersuchungsgegenstand, war die tägliche PCT-Rate. Diese wurde
berechnet aus der Anzahl der PCT-Messungen des jeweiligen Tages geteilt durch die Anzahl
der Patienten des jeweiligen Tages.
40
Datenerfassung
Die Datenerfassung erfolgte automatisch. Die Aufrufe des PCT-MLMs und die generierten
Vorschläge wurden über die Log-Tabellen des Arden-Servers erfasst, die durchgeführten
PCT-Messungen durch Export in die ProxyDB im Rahmen der Datenreplikation. Zusätzlich
wurde bei Nutzung des PCT-MLMs ein Bestätigungsbutton angezeigt. Die Ärzte wurden
gebeten, die Nutzung der Vorschlagsliste über diesen Button zu bestätigen.
Statistische Auswertung
Die statistische Analyse erfolgte über einen zweiseitigen T-Test (in der Variante des Zwei-
Stichproben-Welch-Tests) bei einem Signifikanzniveau von 5% und einer Teststärke von
80%. Die Nullhypothese lautete, dass es in den Studienphasen keine signifikante
Veränderung der PCT-Rate gegenüber dem Vergleichszeitraum PRE gab. Die Analyse und
die Erstellung der Boxplots wurden mit R durchgeführt. Die Eingabedaten für R wurden über
ein Analyse-MLM erzeugt, das tageweise die PCT-Messungen und Patientenzahlen
auszählt, die PCT-Rate berechnet und diese in Form von R-Vektoren darstellt.
Nachdem bei der statistischen Analyse der erfassten Daten deutlich wurde, dass es in ON1
einen ausgeprägten, in ON2 aber keinen Effekt gab, wurden potentielle Einflussfaktoren
analysiert. Hierzu wurden die Anzahl der Neuaufnahmen36, der tägliche SAPS37 II und der
APACHE38 II bei der Aufnahme für beide Phasen verglichen. Diese drei Parameter erlauben
eine Abschätzung des Behandlungsaufwandes. Es war nämlich durchaus denkbar, dass sich
der fehlende Effekt in ON2 auf einen wesentlich höheren Arbeitsaufwand zurückführen lässt.
Die Daten für den Vergleich wurden von der IOI geliefert.
Um im Nachhinein abschätzen zu können, inwieweit die Senkung der PCT-Rate auf die
Befolgung der Vorschläge zum Unterlassen einer Messung zurückgeführt werden kann,
musste eine entsprechende Metrik gefunden werden. Hier war zu berücksichtigen, dass eine
scheinbare Befolgung eines Vermeidungsvorschlags durchaus ein Zufall sein kann. Wenn
das MLM für einen bestimmten Patienten die Unterlassung der Messung vorschlägt und
diese tatsächlich nicht angeordnet wird, so kann dies durchaus eine zufällige
Übereinstimmung sein. Es war also erforderlich, das Ausmaß der zufälligen
Übereinstimmung zu ermitteln ("den Zufall herauszurechnen"), um die Befolgung in den ON-
Phasen dazu in Relation setzen zu können. Dies war notwendig, da die Sonderlaborliste
papierbasiert erfasst wird. Daher war es nicht möglich, einen Vorher-Nachher-Vergleich
durchzuführen, da nur die abschließende Entscheidung des Arztes nach Konsultation der
36 Der Arbeitsaufwand ist am Tag der Neuaufnahme besonders hoch, da eine Vielzahl von Maßnahmen notwendig
ist (beispielsweise Intubation, Legen von Zugängen, Einstellen der Medikation, Anschluss an die Patientenmonitore
und Organersatzverfahren). 37 Simplified Acute Physiology Score 38 Acute Physiology And Chronic Health Evaluation
41
Vorschlagsliste bekannt war, aber nicht seine ursprüngliche Absicht. Die zufällige Befolgung
wurde berechnet, indem der Regelsatz auf die Vergleichsdaten angewendet und die
Übereinstimmung zwischen Vermeidungsvorschlägen und nicht angeordneten Messungen
ermittelt wurde. Sollte eine Senkung der PCT-Rate auf die Befolgung von Vorschlägen
zurückgehen, so müsste sich dies in einem entsprechenden Anstieg der Befolgungsquote
niederschlagen. Als Metrik wurde daher die relative Änderung der Befolgungsquote
gegenüber der Zufallsquote gewählt.
Der letzte Schritt der Studie bestand in der Durchführung eines semistrukturierten Interviews
der Ärzte, die an der PCT-Studie teilnahmen. Die Ärzte wurden angeschrieben und um
persönliche oder telefonische Teilnahme am Interview gebeten. Sofern keine Reaktion
erfolgte, wurden sie zwei Wochen später erneut angeschrieben. Im Interview wurden
folgende Fragen gestellt:
1. Fragen zur Motivation der PCT-Studie
a) Bitte beschreiben Sie die Motivation der PCT-Studie
b) Wie hoch schätzen Sie die Kosten einer Messung?
c) Sind sie der Meinung, dass zu viele PCT-Messungen angeordnet werden?
d) Halten Sie eine Reduktion für erstrebenswert?
Fragen zur Erstellung der Sonderlaborliste
a) Wie viele Minuten benötigen Sie für die Erstellung?
b) Stehen Sie dabei unter Zeitdruck?
c) Wie überprüfen Sie, ob eine Messung notwendig ist?
d) Erhöht die Prüfung den Zeitaufwand?
Fragen zum Einsatz des PCT-MLMs
a) Wie beeinflusste das PCT-MLM die Erstellung der Sonderlaborliste?
b) Welche Ursachen vermuten Sie für die nachlassende Nutzung und den fehlenden Effekt
in ON2?
Fragen zu alternativen Ansätzen
a) Was halten sie von einer (teil-)automatisierten Erstellung der Sonderlaborliste?
b) Haben Sie weitere Verbesserungsvorschläge oder Anmerkungen?
42
4 Ergebnisse
In diesem Kapitel sollen die Ergebnisse dargestellt werden, die sich aus der Anwendung der
in Kapitel 3 dargestellten Methoden ergeben haben. Nach Analyse der klinischen und
technischen Anforderungen konnte ICM zum System ICM-Arden erweitert werden, das die
Ausführung von MLMs ermöglicht und mit kleinen Abstrichen als vollwertig bezeichnet
werden kann. Weiterhin konnte ein MLM zur Erkennung vermeidbarer PCT-Messungen in
einer prospektiven Studie evaluiert werden. Die Studie führte zu dem Ergebnis, dass der
Einsatz des MLMs die tägliche PCT-Rate deutlich senkte, dass der Effekt aber nur von
kurzer Dauer war.
4.1 Ergebnisse der technischen Bereitstellung
Das entwickelte System ICM-Arden unterstützt die benutzer-, zeit- und datengesteuerte
Ausführung von MLMs, ebenso deren Zugriff auf die Patientendaten und die Präsentation
von MLM-Ergebnissen an verschiedenen Kommunikationsendpunkten. Hierzu waren einige
Schwierigkeiten zu überwinden, die auf fehlenden Leistungsmerkmalen von AutoExport
beruhen, nämlich der fehlenden datengesteuerten Auslösung sowie der fehlenden
Möglichkeit eines aktiven externen Datenzugriffes. Beide Features konnten in der
Implementierungsphase durch die Konzeption von Workarounds weitgehend bereitgestellt
werden. Als Einschränkung bleibt allerdings eine gewisse Reaktionsträgheit des Systems
bestehen, ebenso resultiert aus den Workarounds ein erheblicher Ressourcenverbrauch.
ICM-Arden ist mandantenfähig und bietet Präsentationsmechanismen, die dem
Wissensingenieur ermöglichen, MLM-Ergebnisse ohne Unterstützung von IT-Seite mit
einfachen Mitteln darzustellen. Eine Zusammenfassung der technischen Bereitstellung
wurde publiziert [95] (siehe Anhang).
4.1.1 Ergebnisse der Analysephase
Aus den recht klaren Anforderungen der Anwender konnte eine Zielarchitektur abgeleitet
werden, die in Abbildung 15 in leicht vereinfachter Form dargestellt ist. Gefordert wurde die
daten-, zeit- und benutzergesteuerte Ausführung von MLMs. Letztere sollte über eine
Schaltfläche in der ICM-GUI ("Arden-Button") möglich sein. Der Arden-Button startet einen
grafischen MLM-Viewer, der die Ausführung von MLMs über weitere Buttons ermöglicht.
Dieser Ansatz wurde gefordert, da man nicht einfach eine beliebige Menge von Buttons
direkt in der ICM-GUI anlegen kann, schon allein aus Platzgründen. Man könnte zwar
Buttons einsparen, indem man mehrere MLMs über ein- und denselben Button ausführt,
aber dann addieren sich auch die Laufzeiten der MLMs. Der Viewer sollte auch die
Ausführung von MLMs für bereits entlassene Patienten aus dem Patientenarchiv heraus
ermöglichen. Zudem sollte sichergestellt sein, dass der Patientenkontext synchron ist, d.h.
dass es nicht möglich ist, in ICM zu einem neuen Patienten zu wechseln, solange im Viewer
43
noch der alte angezeigt wird, da es sonst zu Verwechslungen kommen könnte. Als
Kommunikationsendpunkte für daten- und zeitgesteuerte Ausführung wurden DECT-Telefone
(SMS) und Emailadressen gefordert. Popup-Nachrichten waren ausdrücklich unerwünscht.
Trigger-mechanismus
Patienten-datenbank
Ardenengine
Ard
enH
ostIn
terf
ace
Wissens-basis
Datenzugriff
MLM-ViewerHTML
JavaScript
SMS, EmailAnwender
Daten- und zeitgest. Ereignisse
GUI-Ereignis (Arden-Button)Benutzergesteuerte Ereignisse
PDMS
Abbildung 15: Architektur des Zielsystems
Recht detaillierte Vorgaben gab es hinsichtlich der Präsentation von MLM-Ergebnissen bei
der benutzergesteuerten Ausführung. Die Anforderungen lauteten:
• Formatierung zeitlicher Angaben (TIME und DURATION) : Hier wurde eine
Darstellung wie in ICM gefordert, also DIN- statt ISO-Format mit minutengenauer
Granularität.
• Textformatierung: Schriftart, Schriftgröße und Schriftstil sollten anpassbar sein, um
Informationen gezielt hervorheben zu können und bedingte Formatierung zu
ermöglichen.
• Tabellen: Von MLMs erzeugte Informationen wie kritische Laborwerte oder
Scorewerte sollten in tabellarischer Form angezeigt werden können.
• Lineplots: Oft ist nicht nur der aktuelle Wert einer Formel- oder Scoreberechnung
interessant, sondern auch der Verlauf über einen bestimmten Zeitraum oder die
gesamte Aufenthaltsdauer des Patienten. Eine Darstellung des Verlaufs in
Tabellenform ist umständlich zu lesen, daher sollte der Verlauf als Grafik dargestellt
werden können. Dabei sollte es die Möglichkeit geben, Grenzwerte als farbige Linien
einzuzeichnen, Grenzwertverletzungen optisch hervorzuheben und bestimmte Werte
zu markieren..
• Auf- und Zuklappen von Anzeigebereichen: Beliebige Anzeigebereiche sollen per
Mausklick auf- und zuklappbar sein, um eine übersichtliche Darstellung zu
gewährleisten. So sollten MLM bei bestimmten Berechnungen die
Berechnungsgrundlage darstellen können, diese sollte aber aus Gründen der
Übersicht initial zugeklappt sein.
44
Die Analyse von AutoExport erbrachte, dass auch in den neueren Versionen eine
datengesteuerte Auslösung von Exporten nicht unterstützt wird. Ebenso ist es nach wie vor
nicht möglich, Exporte außerhalb von ICM anzustoßen. Der Leistungsumfang entspricht also
weitgehend dem der Vorgängerversionen, an den schwerwiegendsten Beschränkungen hat
sich nichts geändert. Neu hinzugekommen ist die Möglichkeit, Exporte per Button im
Anordnungsdialog der Medikation zu starten, wobei markierte Elemente von Auswahlboxen
exportiert werden können. Dieses Feature ist im Kontext der Arzneimitteltherapiesicherheit
hochinteressant und ermöglicht Entscheidungsunterstützung per MLM bei der Anordnung.
Neu hinzugekommen ist weiterhin die Möglichkeit, in der Stationsübersicht Symbole am
Patientenbett durch Ereignisnachrichten im HL7-Format zu setzen. Diese werden vom
Hersteller als IBACOs bezeichnet. An jedem Bett können bis zu drei IBACOs gleichzeitig
angezeigt werden. Werden weitere gesetzt, so überschreiben sie sich entsprechend einer
konfigurierbaren Priorität. Ein Klick auf ein IBACO erlaubt die Bestätigung der auslösenden
Meldung, wodurch das zugehörige IBACO wieder verschwindet.
Hinsichtlich der MiBi-Daten zeigte die Analyse, dass sie von AutoExport nicht in ausreichend
strukturierter Form geliefert werden, sondern in Textblöcken, die lediglich über Einrückungen
schwach strukturiert sind. Eine zuverlässige Datenextraktion durch Parsen dieser Textblöcke
war nicht möglich. Darüber hinaus werden MiBi-Befunde teilweise vor der Speicherung
gruppiert, was zu einem Informationsverlust führen kann. So werden beispielsweise die
Befunde verschiedener Katheterarten unter „Katheter“ zusammengefasst und es lässt sich
nach dem Export nicht mehr feststellen, wie der genaue Typ des Katheters war. Für das
Monitoring beispielsweise von ZVK39-assoziierten Infektionen ist aber nur die Erregerzahl am
ZVK erforderlich.
Die erneute Analyse der von AutoExport generierten Targets zeigte, dass zu den
Patientendaten keine Typinformationen exportiert werden können. Alle Patientendaten liegen
im Target als Strings vor. Ein metadatengesteuertes Typmapping wird also nicht unterstützt.
Immerhin ist bei Zeitstempeln eine Identifizierung des Datentyps möglich, da diese über
spezielle Bezeichner ausgelesen werden.
Die Analyse der Arden-Umgebung ergab, dass sie sich aus drei Komponenten
zusammensetzt: Einem Arden-Compiler, einer Arden-Engine und einer Entwicklungs- und
Testumgebung (IDE). Der Compiler kann von der Kommandozeile oder über die IDE
ausgeführt werden. Letztere besteht aus einem MLM-Editor und einer MLM-Verwaltung.
MLMs können in einer Testumgebung ausgeführt werden, die den Aufruf mit
Eingangsparametern und die Simulation eines Datenzugriffes per READ unterstützt.
Zur Anbindung der Arden-Engine an ein klinisches System muss das ArdenHostInterface
implementiert werden40. Dieses kapselt all jene Methoden, die die nutzende Institution selber
39 Zentraler Venenkatheter 40 in Java besteht ein Interface aus einer Liste von Methodennamen und deren Signaturen, also Aufruf- und
Rückgabeparameter
45
implementieren muss, also diejenigen, welche Arden-Syntax-Statements mit Curly-Braces
enthalten (Curly-Braces-Methoden). Sie werden von der Engine implizit aufgerufen, wenn
der Kontrollfluss auf ein entsprechendes Statement trifft. Der im jeweiligen Statement
enthaltene Curly-Braces-Ausdruck wird der Methode als String übergeben, den sie dann
parsen kann. Wird beispielsweise ein READ-Statement verarbeitet, so ruft die Arden-Engine
die Methode evaluateRead auf. Diese erhält den Curly-Braces-Ausdruck als String und kann
sich die Parameter herausparsen und eine Datenbankabfrage erstellen. Dabei gibt es einen
integrierten Ersetzungsmechanismus, um Werte von deklarierten Variablen in den Curly-
Braces-Methoden nutzen zu können. Dieser ist in Abbildung 16 exemplarisch dargestellt: Da
die Variable "fallid" deklariert ist, wird der Teilstring "fallid" in der Curly-Braces-Expression
textuell durch die Stringrepräsentation des Wertes der Variablen ersetzt.
LET fallid BE 4711;LET glucose be READ { glucose , fallid };
Textuelle Ersetzung
Aufruf von evaluateRead mit “{ glucose , 4711 } “
Abbildung 16: Ersetzungsmechanismus bei Curly-Braces -Methoden
Um aus einer Datenquelle ausgelesene Patientendaten am Ende einer Curly-Braces-
Methode an das MLM zurückliefern zu können, müssen sie mittels von der Engine
bereitgestellter API in Arden-Syntax-Datentypen konvertiert werden. Ein erheblicher Teil der
Curly-Braces-Methoden besteht also aus der Konvertierung von Datentypen der Arden-
Syntax in solche der Programmiersprache Java und umgekehrt.
Die Arden-Engine selbst ist für den Programmierer eine Black Box. Die Teile, die er selber
implementieren muss, sind die Methoden des ArdenHostInterfaces. Neben den Curly-
Braces-Methoden enthält das ArdenHostInterface auch Methoden zur Ansteuerung der
Arden-Engine von außen ("Ansteuermethoden"), insbesondere zur Meldung von
Ereignissen. Abbildung 17 zeigt die Position des ArdenHostInterfaces zwischen dem PDMS
und der Arden-Engine. Die Ansteuermethoden werden von der PDMS-Seite her aufgerufen,
die Curly-Braces-Methoden von der Arden-Engine beim Verarbeiten entsprechender
Befehle. Für die Ansteuermethoden bot sich die Nutzung einer Web-Service-Schnittstelle an,
die Arden-Engine wurde dadurch zum Arden-Server.
46
Arden Engine
Core-Engine
ArdenHostInterface
PDMS Ansteuermethoden
Curly-Braces-Methoden
z.B.reportEvent
z.B.evaluateRead
Abbildung 17: Integration über ArdenHostInterface
Um die Arden-Engine von Medexter auf einem System nutzen zu können, ist eine MLM-
Handler-Datei erforderlich. Ist ein MLM dort nicht registriert, so wird es von der Arden-Engine
auch nicht ausgeführt. Die Handler-Datei kann entweder manuell oder automatisch von der
IDE verwaltet werden. Aus administrativen Gründen wurde am UKER die manuelle Variante
gewählt. Dies gewährleistet eine stärkere Kontrolle des Systems bei der verteilten
Entwicklung von MLMs.
Zusammenfassend ließen sich die in der Analysephase eruierten Anforderungen in drei klar
voneinander abgegrenzte Bereiche gliedern:
• Datenzugriff und Ereigniserkennung: Hier galt es, Workarounds zur Behebung
der Mängel von AutoExport zu finden, nämlich das Fehlen einer Möglichkeit für
einen externen Zugriff auf Patientendaten sowie das Fehlen einer
Ereigniserkennung im Sinne eines datengesteuerten Triggermechanismus. Für den
Sonderfall der MiBi-Daten war eine Lösung zu finden, die nicht auf AutoExport
basiert.
• Bereitstellung des Arden-Servers: Hier war die Implementierung des
ArdenHostInterfaces erforderlich, also zum einen die Implementierung der Curly-
Braces-Methoden, insbesondere für Datenzugriff und Nachrichtenversand, zum
anderen die Implementierung der Ansteuermethoden, um die Engine an das PDMS
anzuflanschen.
• Präsentationsmechanismen: Hier war eine Möglichkeit zu schaffen, um dem
Anwender die von den MLMs generierten Ergebnisse auf dem Bildschirm
anzuzeigen. Dies erforderte zunächst die Bereitstellung eines geeigneten MLM-
Viewers, weiterhin waren aber auch Mechanismen zu schaffen, um die von den
Anwendern geforderten Anzeigeelemente (z.B. Tabellen und Lineplots) zu
generieren.
4.1.2 Ergebnisse der Implementierungsphase
Im Zuge der Implementierungsphase konnte das von den Anwendern geforderte System
implementiert werden, wobei als Einschränkung eine gewisse Reaktionsträgheit besteht,
47
bedingt durch die periodischen Exporte in die ProxyDB. ICM-Arden unterstützt alle
geforderten Auslösearten, einen Zugriff auf die Patientendaten und alle geforderten
Präsentationsmechanismen.
4.1.2.1 Datenbereitstellung und Ereigniserkennung
Patientendaten werden den MLMs bereitgestellt, indem sie periodisch in die ProxyDB
exportiert werden. Das Replikationsintervall liegt dabei derzeit im Bereich von wenigen
Minuten, je nach Bettenzahl der jeweiligen Station (auf der IOI mit 25 Betten beträgt es 10
Minuten). Bei jedem Exportlauf wird ein Reihe von Targets generiert, die Patientendaten in
einem Format beinhalten, das aus benannten Listen von Datensätzen besteht. Dieses
Format wurde konzipiert, da vergleichende Messungen zeigten, dass es deutlich
performanter zu verarbeiten ist als XML. Nach erfolgtem Export wird ein Export-Handler
aufgerufen, der die Targets parst und die enthaltenen Daten in verschiedene Tabellen der
ProxyDB schreibt. Diese Tabellen wurden im EAV-Format modelliert, mit Ausnahme der
Falldaten, für die das EAV-Format nicht sinnvoll wäre.
Eine Ausnahme stellt die Bereitstellung der MiBi-Daten dar. Diese erfolgt nicht über
AutoExport, sondern über den Kommunikationsserver (eGate [96]). Der Ablauf der
Bereitstellung ist in Abbildung 18 dargestellt:
1. Die MiBi-Daten werden vom Laborsystem per HL7-Nachricht an das eGate
übertragen.
2. Vom eGate dort werden sie als HL7-Nachricht an die Inbound-Schnittstelle von ICM
weitergeschickt.
3. Am eGate werden die Inhalte der HL7-Nachrichten dupliziert und per FTP in das
MiBi-Eingangsverzeichnis des Arden-Servers übertragen.
4. Dort werden alle unverarbeiteten Nachrichten in periodischen Abständen vom MiBi-
Parser verarbeitet.
5. Die extrahierten und aufbereiteten Daten werden in der ProxyDB abgelegt
Abbildung 18: Bereitstellung der MiBi-Daten
48
Neben den MiBi-Anforderungen und den zugehörigen Kulturergebnissen werden auf
Wunsch der Anwender auch die in den HL7-Nachrichten enthaltenen Kommentare mit DRG-
Kodierungsvorschlägen abgelegt, um sie per MLM im Viewer darstellen zu können.
Folgende Tabellen der ProxyDB enthalten replizierte Patientendaten:
• proxydb_fall: Falldaten (konventionelles Schema).
• proxydb_eav: Sämtliche Daten, die sich als Wert-/Zeitstempelpaare abbilden
lassen, beispielsweise Laborwerte (EAV-Format).
• proxydb_codes: ICD10- und OPS-Codes inklusive Langtext (EAV).
• proxydb_fromto: Zeitbereichsdaten, das sind Maßnamen mit einem von- und
einem bis-Datum, beispielsweise Sauerstoffinsufflation (EAV).
• proxydb_medikation: Aktuell angesetzte Medikation des Patienten (EAV).
• proxydb_mibianf: Anforderungen an die Mikrobiologie (konventionell).
• proxydb_mibibef: Vom Labor ermittelte Befunde zu den Anforderungen inklusive
Keimzahlen (konventionell).
• proxydb_mibikommentar: Befundkommentare mit enthaltenen ICD10-Diagnose-
vorschlägen (konventionell).
Dabei werden sämtliche Werte mangels Typinformationen als Strings gespeichert. Bei den
Zeitbereichsdaten gibt es zusätzlich noch eine einfache Gruppierungsmöglichkeit für
Maßnahmen. Diese dient dazu, ähnliche Maßnahmen im MLM nicht einzeln abfragen zu
müssen. Ein Beispiel hierfür ist die Infusion von Natrium, für die es fast ein Dutzend
ähnlicher Maßnahmen gibt, mit verschiedenen Konzentrationen und Trägerlösungen. Hier
möchte man im MLM nicht alle diese Maßnahmen einzeln per READ abfragen, um eine
Natriumgabe erkennen zu können. Über den Gruppenschlüssel kann man diesen
Sachverhalt mit einem einzigen READ-Statement klären.
Die Ereigniserkennung zur datengesteuerten Auslösung von MLMs konnte erfolgreich über
den Vergleich konsekutiver Exporte realisiert werden. Sie ist allerdings reaktionsträge, da
Ereignisse immer nur zum Exportzeitpunkt erkannt werden können. Es kann also bis zu 10
Minuten dauern, bis ein Ereignis erkannt wird. Dieser Wert ist ein Kompromiss zwischen
Performance und Ressourcenverbrauch. Nach mehrfacher Optimierung konnte die Dauer
eines Exportlaufs auf etwa 3 Minuten reduziert werden, wobei sie bei starker Last auf dem
VM-Cluster auf bis zu 5 Minuten ansteigen kann. Diese Angaben beziehen sich auf eine
durchschnittliche Bettenbelegung. Bei hoher Bettenbelegung, insbesondere mit vielen
Langliegern, kann die Dauer eines Exportlaufs bei starker Systemlast auf bis zu sieben
Minuten ansteigen. Daher wurde ein Intervall von 10 Minuten gewählt, um selbst bei starker
Last noch eine zeitliche Reserve zu haben, damit sich die Exportläufe nicht überlappen. Der
Vergleich der exportierten Daten wird vom Export-Handler durchgeführt. Dieser merkt sich
unter Zuhilfenahme temporärer Tabellen, welche Werte bereits exportiert wurden. Enthält ein
49
Export ein bisher unbekanntes Datum, so wird eine Ereignisnachricht vom integrierten
SOAP-Client an den Arden-Server gesendet.
4.1.2.2 Bereitstellung des Arden-Servers
Die Arden-Engine wurde an ICM angebunden, indem das ArdenHostInterface41 mit seinen
Ansteuer- und Curly-Braces-Methoden implementiert sowie die komplette Engine in einen
Application-Server integriert und mit einer Web-Service-Schnittstelle versehen wurde. Das
resultierende Gesamtsystem wurde als Arden-Server bezeichnet.
Zwei Ansteuermethoden wurden in das ArdenHostInterface integriert: Die erste Methode
("executeMlm") dient der Ausführung eines einzelnen MLMs über dessen Namen. Diese
Methode ist nicht für den Produktiveinsatz gedacht, sondern dient der Ausführung von MLMs
mit Echtdaten zu Test- und Entwicklungszwecken. Die zweite Methode ("reportEvent") dient
der Meldung von Ereignissen an den Arden-Server. Diese Ereignisse werden entweder vom
Export-Handler gemeldet, nachdem sie durch Vergleich von Exporten erkannt wurden, oder
von der weiter unten beschriebenen Webanwendung, die bei Betätigung eines Buttons eine
Nachricht versendet. Die Ereignisnachrichten enthalten einen Datensatz aus Fall- und
demografischen Daten (interne Fall-ID, ISH-Aufnahmenummer, Patientenname,
Aufnahmedatum etc.), der vom Arden-Server in ein Arden-Syntax-Objekt konvertiert und
jedem MLM übergeben wird, das mit dem Ereignis verknüpft ist. Alle Bestandteile der
Ereignisnachricht können also direkt im MLM verwendet werden.
Das ArdenHostInterface enthält Curly-Braces-Methoden für READ, DESTINATION und
WRITE, die hinsichtlich Benutzerfreundlichkeit optimiert sind. Beim READ-Statement kann
ein Aliaskonzept genutzt werden, damit beim MLM-Ersteller keine SQL-Kenntnisse
vorausgesetzt werden müssen. Gibt es im Anfrageergebnis eine Spalte mit dem Namen
primary_time42, so werden die darin enthaltenen Zeitstempel den Werten als Primary Times
zugewiesen. Das Aliaskonzept funktioniert auch bei der Variante des READ-Statements, bei
der mehrere Listen gleichzeitig befüllt werden. Das Grundprinzip ist in Abbildung 19
dargestellt: Der String "fallid" wird durch den in Abschnitt 4.1.1 (siehe Abbildung 16)
erläuterten Mechanismus durch den Wert der gleichnamigen Variablen ersetzt (1). Die
Methode evaluateRead extrahiert den Aliasnamen, löst ihn auf (2) und ersetzt die Platzhalter
durch die beiden Parameter (3).
41 Streng genommen ist das ArdenHostInterface ein Java-Interface, das mit einer weitgehend leeren
Implementierung namens StandardArdenHostInterface ausgeliefert wurde. Von dieser wurde die Klasse
ICMArdenHostInterface abgeleitet und implementiert. Da diese Hierarchie aber für das Verständnis dieser Arbeit
sekundär ist, wird vereinfachend nur vom ArdenHostInterface gesprochen. 42 Falls die Tabellenspalte mit den Zeitstempeln anders heißt, kann der AS-Operator von SQL angewendet werden.
50
LET kreatinin BE READ { labordaten | kreatinin , falli d };
1. Textuelle Ersetzung von “fallid“, Aufruf der Curly-Braces-Methode
evaluateRead ( “{ labordaten | kreatinin , 4711 }“ )
2. Auflösung des Aliasnamens “labordaten“
Select pval, primary_timefrom proxydb_eav where pkey=‘#‘ and fallid=‘#‘
3. Ersetzung der Platzhalter durch Parameter
Select pval, primary_timefrom proxydb_eav where pkey=‘kreatinin‘ and fallid=‘471 1‘
Abbildung 19: Grundprinzip des Aliaskonzeptes
Als Kommunikationsendpunkte wurden Emailadressen und DECT-Telefone implementiert.
Ein Beispiel für eine von einem MLM versendete SMS ist in Abbildung 20 dargestellt. Sie
wird vom MLM "icm_glucosemonitoring" erzeugt und meldet einen kritischen Wert,
zusammen mit den Initialen43 und der Bettnummer des Patienten. Der Versand von
Nachrichten erfolgt im ACTION-Slot eines MLMs über das WRITE-Statement, wie das
folgende Codebeispiel demonstriert:
DATA:
LET mailaddress BE DESTINATION {email|stefan.kraus@ uk-erlangen.de};
LET dectphone BE DESTINATION {sms|12345};
ACTION:
WRITE mailtext AT mailaddress;
WRITE smstext AT dectphone;
43 Vollständige Patientennamen waren aus Datenschutzgründen nicht gewünscht.
51
Abbildung 20: Beispiel einer per MLM generierten SMS -Nachricht
Bei Emails kann ein Betreff gesetzt werden, außerdem können durch das verwendete
Emailformat die im nachfolgenden Abschnitt erläuterten Präsentationsmechanismen voll
genutzt werden. Bei den SMS-Nachrichten besteht das Problem, dass das angebundene
SMS-Gateway der Hausverwaltung keine Bestätigung für einen erfolgreichen Versand
zurückliefert. Zu beachten ist dabei die limitierte Kapazität des Gateways, das ca. eine SMS
pro Sekunde verarbeiten kann. Adressiert werden können nur hausinterne DECT-Telefone.
Zeitlich verteilte Testmessungen zeigten einen zügigen Versand, die Nachrichten kamen
innerhalb weniger Sekunden an, die längste Verzögerung betrug etwa 30 Sekunden.
Die Returnwerte aller vom Arden-Server verarbeiteten MLMs werden dauerhaft in einer
Tabelle archiviert. Im Falle der benutzergesteuerten Ausführung von MLMs werden deren
Returnwerte zusätzlich im MLM-Viewer angezeigt.
4.1.2.3 Präsentationsmechanismen
Alle von den Anwendern geforderten Präsentationsmechanismen konnten vollständig
umgesetzt werden. Der MLM-Viewer wird über eine Schaltfläche in den ärztlichen
Berichtsseiten gestartet, Abbildung 21 zeigt einen Screenshot. Außer der Formatierung von
Zeitangaben wurden alle Präsentationsmechanismen durch Implementierung von Sub-MLMs
realisiert, die Anzeigeelemente in Form von HTML und/oder JavaScript zurückliefern, die
direkt in einem Browser dargestellt werden können. Die Sub-MLMs nutzen Arden-Syntax-
Objekte, um eine komfortable Parameterübergabe zu ermöglichen.
52
Abbildung 21: Screenshot des MLM-Viewers
Formatierung von Zeitangaben
Der Wissensingenieur kann das gewünschte Format der Zeitstempel aus einer Reihe von
Varianten auswählen und über den Arden-Syntax-Operator FORMATTED WITH (vgl.
Spezifikation [73] Abschnitt 9.8.2) anwenden44. Zur Anpassung von Zeitdauern (Datentyp
DURATION) steht ihm das Interface "DurationFormatter" zur Verfügung, das den
Aufrufparameter in eine ICM-konforme deutsche Darstellung konvertiert.
Formatierung von Text
Die Formatierung von Text erfolgt über das MLM "FontFormatter“. Es ermöglicht die
Einstellung von Schriftgröße, Schriftfarbe, Fettschrift und Unterstrich. Die Schriftgröße ist in
Punkten (pt) anzugeben. Beispiel:
<var> := CALL fontformatter WITH <var>, “16pt“, “ro t“, “fett“;
Der Inhalt von <var> wird dadurch in der Schriftgröße 16pt in der Schriftfarbe rot in Fettschrift
dargestellt. Das obige Beispiel wird in folgenden HTML-Code umgesetzt:
<FONT STYLE=“font:16pt red bold“><var></FONT>
Die von den Anwendern geforderte bedingte Formatierung kann hiermit vom
Wissensingenieur durch Verwendung von IF-THEN-ELSE-Statements realisiert werden.
44 Hierzu müssen Formatstrings definiert werden. Die Arden-Engine von Medexter stellt eine entsprechende
Methode zum Setzen bei der Initialisierung des ArdenHostInterfaces bereit.
53
Generierung von Tabellen
Die Forderung nach einer Möglichkeit zur Generierung von Tabellen wurde in zwei
verschiedenen Varianten realisiert. Die erste Variante ist für den einfachen Fall, dass eine
Arden-Syntax-Liste in tabellarischer Form angezeigt werden soll. Das hierfür geschriebene
MLM ListToTable generiert aus der übergebenen Liste eine HTML-Tabelle mit drei Spalten
für eine fortlaufende Nummer, den jeweiligen Wert sowie dessen Zeitstempel. Abbildung 22
zeigt ein Beispiel mit Code für den Aufruf und Darstellung des Ergebnisses.
LET table BE CALL list_to_table WITH critical_calcium _values;
Abbildung 22: Beispiel für einfache Tabellengenerier ung
Die zweite Variante ist für den komplexeren Fall und dient der Generierung beliebiger
Tabellen. Dazu wurde das MLM TableGenerator geschrieben, dessen Aufruf mit einem
Beschreibungsobjekt vom Typ TableDescription erfolgt, dessen Struktur die der zu
erstellenden Tabelle widerspiegelt.
Skalierbare Grafiken mit Highlighting (Lineplots)
Zur Generierung von Grafiken wurde das MLM "LinePlotter" erstellt. Es liefert JavaScript-
Code zurück, der im Browser eine Grafik generiert. Der Aufruf erfolgt mit einem
Beschreibungsobjekt, in dem eine Reihe von Optionen gesetzt werden können. So können
Grenzlinien eingezeichnet und Werte hervorgehoben werden. Die Grafiken unterstützen die
Vergrößerung beliebiger Ausschnitte und die optische Hervorhebung von Informationen beim
Überfahren mit dem Mauszeiger. Durch Markieren eines Ausschnittes kann in diesen
hineingezoomt werden, durch Doppelklick wird der Zoommodus beendet. In Abbildung 23 ist
ein einfaches Beispiel für die Generierung eines Lineplots dargestellt. Ein Objekt vom Typ
DiagramDescription wird instanziiert und eine Reihe von Attributen versorgt. Als Werte wird
eine Liste von MELD-Scores verwendet, die unter Nutzung eines Calculator-MLMs erstellt
wurde. Der Aufruf des MLMs LinePlotter mit dem Beschreibungsobjekt als Parameter liefert
einen String mit JavaScript-Code zurück, der das dargestellte Diagramm zeichnet.
54
LET dd BE NEW diagramdescription;LET dd.label BE “Meldscore“;LET dd.values BE meldscorelist;LET dd.fromdate BE stay.admissiondate;LET dd.todate BE NOW;LET diagram BE CALL lineplotter WITH dd;
Abbildung 23: Beispiel für Generierung von Lineplots
Auf- und Zuklappen von Bereichen
Das Auf- und Zuklappen beliebiger Anzeigebereiche wurde über das MLM HideShow
realisiert. Es kapselt den Anzeigebereich in einen DIV-Tag und generiert JavaScript-Code,
der den gekapselten Bereich auf sichtbar oder unsichtbar setzt. Zudem liefert es einen
Hyperlink zurück, der an beliebiger Stelle innerhalb der Ausgabe des aufrufenden MLMs
platziert werden kann. Durch Klicken auf den Link wird die Sichtbarkeit ein- und
ausgeschaltet. Die initiale Sichtbarkeit kann über einen Aufrufparameter gesetzt werden.
4.2 Ergebnisse der PCT-Studie
In der Vorstudie wurde der Workflow bei der Anforderung von PCT-Messungen auf Basis der
Sonderlaborliste untersucht und die Grundlagen für die Evaluierung geschaffen, indem ein
Regelsatz zur Erkennung vermeidbarer Messungen in Arden-Syntax formuliert und auf die
Vergleichsdaten angewendet wurde. In der eigentlichen Evaluierung wurde der Einfluss des
PCT-MLMs auf die tägliche PCT-Rate untersucht. Es zeigte sich ein starker Effekt, der aber
nur von kurzer Dauer war.
4.2.1 Die Vorstudie
Die IOI ist in zwei Bereiche unterteilt, nämlich einen allgemeinchirurgischen und einen
herzchirurgischen. Die beiden Bereiche der IOI sind in Abbildung 24 dargestellt (links
allgemeinchirurgisch mit 16 Betten, rechts herzchirurgisch mit 9 Betten). Jeder Bereich wird
von mindestens einem Stationsarzt betreut. An Wochentagen gibt es drei Schichten zu
jeweils acht Stunden, an Wochenenden zwei Schichten zu jeweils 12 Stunden.
55
Abbildung 24: Die Bereiche der IOI
Auf der IOI werden täglich PCT-Messungen von den Stationsärzten angeordnet. Dieser
Vorgang wird an Wochentagen gegen acht Uhr vormittags, an Wochenenden gegen 2 Uhr
nachts durchgeführt. Die Anordnung einer Messung erfolgt durch Ankreuzen eines
Kästchens („Sepsis“) in der papierbasierten Sonderlaborliste. In Abbildung 25 ist ein
Segment der Sonderlaborliste dargestellt, von denen es eines pro Bett gibt.
Abbildung 25: Sonderlaboranforderung für einen Pati enten der IOI
Beim Erstellen der Sonderlaborliste herrscht oft Zeitmangel, daher kann nicht immer in Ruhe
überprüft werden, ob eine PCT-Messung unbedingt erforderlich ist. Eine händische Kontrolle
aller Patienten bedeutet einen erheblichen Zeitaufwand, schon allein weil der Arzt sich
aufgrund des Fehlens einer listenbasierten Darstellung in ICM für jeden Patienten durch
dessen Akte klicken muss. Nach der Fertigstellung der Sonderlaborliste wird sie einem
Mitarbeiter übergeben, der die Entnahme der Blutproben veranlasst. Diese werden mit
einem Barcode versehen und an das Zentrallabor gesendet. Nach erfolgter Messung werden
56
die Befunde vom Laborsystem per HL7-Nachricht an die Labordatenschnittstelle von ICM
gesendet und in die Patientenakte eingetragen. Die Kosten einer Messung belaufen sich auf
14 Euro.
Die von ärztlicher Seite vorgegebenen Regeln mit ihren Grenzwerten zur Erkennung
vermeidbarer Messungen besagten, dass eine Messung dann zu empfehlen ist, wenn
mindestens eine der folgenden Bedingungen zutrifft:
1. die letzte Messung älter als 36 Stunden ist.
2. die letzte Messung über dem Grenzwert von 1 ng/dl liegt.
3. der Anstieg zwischen der beiden letzten PCT-Werten über dem Grenzwert von 0,2
ng/dl/24h liegt.
Nur falls keine der drei Bedingungen erfüllt ist, ist eine Messung als vermeidbar zu bewerten.
Die dritte Regel ist nur anzuwenden, wenn mindestens zwei Messungen vorhanden sind.
Falls bisher keine Messungen für einen Patienten durchgeführt wurden, dann soll auch kein
Vorschlag erfolgen. Stattdessen soll ein Hinweis angezeigt werden, dass für diesen
Patienten keine Bewertungsgrundlage vorhanden ist. Die drei Regeln ließen sich sehr leicht
in Arden-Syntax übersetzen und in ein Analyse-MLM integrieren. Abbildung 26 zeigt die
Anwendung des Analyse-MLMs auf einen Patienten der Vergleichsdaten (die Grafik wurde
über das LinePlotter-MLM erzeugt). Man sieht eine häufige Verlaufsform des PCT-Spiegels.
Am Beginn des Aufenthaltes fand ein sprunghafter Anstieg infolge einer bakteriellen Infektion
statt. Durch die erfolgreiche Gabe von Antibiotika sank der PCT-Spiegel kontinuierlich.
Sobald der Grenzwert zum unkritischen Bereich (rote Linie) unterschritten wurde, wäre eine
tägliche Messung des PCT-Spiegels nicht mehr notwendig gewesen, solange keine
Komplikationen auftreten. Die nach dem Regelsatz erkannten vermeidbaren Messungen
sind durch die vertikalen Linien markiert. Im abgebildeten Beispiel waren 7 von 25
Messungen (28%) laut Regelsatz vermeidbar.
Abbildung 26: Häufige Verlaufsform des PCT-Spiegels
57
Die Anwendung des Analyse-MLMs auf alle in den Vergleichsdaten enthaltenen PCT-
Messungen zeigte, dass insgesamt 22% dieser Messungen nach dem Regelsatz vermeidbar
waren. Die Schätzung des Oberarztes von 15% war also realistisch.
Im Vergleichszeitraum PRE gab es insgesamt 1.974 PCT-Messungen bei 2.453 Liegetagen.
Die Gesamtkosten für PCT lagen damit in PRE bei 27.636 Euro, was 227 Euro pro Tag
bedeutet. Der Mittelwert der täglichen PCT-Rate betrug 0,807 bei einer Standardabweichung
von 0,156. Der Shapiro-Wilk-Test auf den Vergleichsdaten zeigte, dass die PCT-Rate eine
Normalverteilung aufwies und damit in der Evaluierung der T-Test verwendet werden konnte.
Der von ärztlicher Seite vorgebrachte Wunsch, die Phasendauer möglichst auf zwei,
höchstens aber auf drei Wochen zu begrenzen, konnte nicht erfüllt werden, da die
Standardabweichung hierfür zu hoch war. Bei erwarteter Senkung um 15% erbrachte die
Fallzahlplanung eine notwendige Phasendauer von 27 Tagen. Die Phasendauer wurde aus
organisatorischen Gründen um einen Tag erhöht, damit jede Phase an einem Montag um
0 Uhr startete.
4.2.2 Die PCT-Studie
Das PCT-MLM schaltete sich planmäßig zu den Phasenwechseln ein und aus. Der Arden-
Server lief während der Studie stabil, so dass es bei der Generierung der Vorschlagslisten
keine Fehlermeldungen gab. Allerdings kam es in ON2 einmal (am 30.3.2011) vor, dass die
Datenreplikation in den frühen Morgenstunden ausfiel, so dass zum Erstellungszeitpunkt der
Sonderlaborliste die aktuellsten PCT-Werte nicht verfügbar waren, was 17 Messungen
betraf. Bezogen auf die Anzahl der Messungen bestand daher eine Verfügbarkeit des PCT-
MLMs von 100% in ON1 und 95,8% in ON2.
Die in Abbildung 27 dargestellte Tabelle zeigt für jede Studienphase die summierten
Liegetage und Messungen, die Mittelwerte, Standardabweichungen und Mediane der
täglichen PCT-Rate sowie die p-Werte der T-Tests der jeweiligen Phase gegenüber dem
Vergleichszeitraum PRE.
Phase Liegetage Messungen MW PCT-Rate SD PCT-Rate Median PCT-Rate p-WertPRE 2453 1974 0,807 0,156 0,800 1ON1 575 376 0,662 0,149 0,643 0,00004OFF1 564 410 0,733 0,155 0,743 0,029ON2 511 406 0,803 0,173 0,857 0,925OFF2 558 440 0,792 0,190 0,795 0,708POST 558 447 0,807 0,166 0,816 0,985
Abbildung 27: Aggregierte Daten der Studienphasen
Der Vergleich der einzelnen Phasen ist in Abbildung 28 in Form von Boxplots45 dargestellt. In
ON1 kam es gegenüber PRE zu einer signifikanten Senkung der PCT-Rate (p=0,00004). In
OFF1 war die PCT-Rate immer noch signifikant niedriger als in PRE (p=0,029), was einen
45 Die Abbildung zeigt die Standarddarstellung von Boxplots in R. Die Boxen stellen die mittleren 50% der Werte dar,
der horizontale Strich in der Box ist der Median. Die gestrichelten Linien stellen den kompletten Wertebereich dar.
58
Sensibilisierungseffekt anzeigt. In ON2 und auch danach kam es nicht mehr zu einer
signifikanten Änderung der PCT-Rate gegenüber PRE.
Phase: PRE ON1 OFF1 ON2 OFF2 POSTp-Wert: 0,00004 0,029 0,925 0,708 0,985
Abbildung 28: Boxplots der PCT-Raten der Studienphasen
Die Analyse der Logfiles zeigte erhebliche Unterschiede bei der Nutzung des PCT-MLMs in
ON1 und ON2. Die in Abbildung 29 dargestellte Übersicht zeigt ein starkes Nachlassen der
Nutzung in ON2 im allgemeinchirurgischen Bereich. Gab es in ON1 nur einzelne Tage ohne
Nutzung, so wurde das PCT-MLM in ON2 bis zu sechs Tage am Stück nicht genutzt.
Aufgeschlüsselt nach Einzelmessungen ergibt sich eine Nutzung des MLMs in ON1 von
92%, in ON2 von 62,3%.
ON1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
Allg.Herz
ON2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
Allg.Herz
MLM wurde genutzt MLM wurde nicht genutzt
Abbildung 29: Nutzung des PCT-MLMs nach Tagen
Das Ausfiltern der Tage ohne Nutzung in ON2 erbrachte keine relevante Veränderung der
Ergebnisse (lediglich der Median sank von 0,857 auf 0,8). Daraus konnte geschlossen
werden, dass in ON2 auch an Tagen mit Nutzung des MLMs die Vorschläge zur Vermeidung
kaum befolgt wurden.
Die Untersuchung der zufälligen Befolgung in PRE zeigte, dass sich die nicht durchgeführten
Messungen zu 35,3% mit den Vorschlägen des MLMs zur Vermeidung von Messungen
decken. In ON1 gab es einen relativen Anstieg der Befolgung gegenüber der zufälligen
Befolgung um 22,3%, was recht gut mit der Senkung des Mittelwertes der PCT-Rate um
59
18% korreliert. In ON2 hingegen betrug der relative Anstieg der Befolgung gegenüber der
zufälligen Befolgung lediglich 3,6%.
Das Fehlen eines Effektes in ON2 konnte nicht auf einen verstärkten Arbeitsaufwand
zurückgeführt werden, wie in Abbildung 30 ersichtlich ist. Die Zahl der Neuaufnahmen war
in ON2 sogar deutlich geringer als in ON1. Hinsichtlich des täglichen SAPS II und des
APACHE II bei der Aufnahme waren ON1 und ON2 fast identisch.
1 2
24
68
1012
1 2
020
4060
80
1 2
020
4060
80
ON1 ON2 ON1 ON2 ON1 ON2
Neuaufnahmen APACHE II AufnahmeSAPS II täglich
Abbildung 30: Vergleich der ON-Phasen bzgl. Neuaufna hmen, SAPS II und APACHE II
An der PCT-Studie nahmen 15 Ärzte teil, von denen einer das UKER kurz nach der Studie
verließ und nicht mehr erreichbar war. Von den anderen 14 Ärzten erklärten sich sechs
bereit, am Interview teilzunehmen. Von den anderen acht Ärzten erfolgte auch nach
zweimaligem Anschreiben keine Reaktion. Nachfolgend findet sich eine Zusammenfassung
der Antworten der Interviewteilnehmer.
Fragen zur Motivation der PCT-Studie
Alle befragten Ärzte konnten die Motivation der PCT-Studie korrekt wiedergeben. Einem Arzt
waren die genauen Kosten von 14 Euro bekannt, zwei machten keine Angabe, die anderen
drei schätzten zu niedrig (4 Euro, 6 Euro, 10 Euro). Alle Ärzte waren der Meinung, dass in
der Summe zu viele PCT-Messungen gemacht werden. Vier Ärzte betonten aber, dass dies
nicht generalisiert werden darf, sondern sich vor allem auf stabile Langlieger bezieht, bei
denen weiterhin täglich gemessen wird, obwohl hier längere Intervalle zwischen den
einzelnen Messungen unproblematisch wären. Bei neuen Patienten dagegen seien
Messungen auch dann sinnvoll sind, wenn sie nach den Regeln vermeidbar wären, da sie
helfen, den Zustand des Patienten zu beurteilen. Am Anfang der Behandlung ist also die
Kostenersparnis nebensächlich, bei stabilen Langliegern gibt es ein klares Zuviel an
Messungen.
60
Fragen zur Erstellung der Sonderlaborliste
Die Dauer der Erstellung der Sonderlaborliste wurde mit durchschnittlich etwa 8 Minuten
angeben (3, 3-5, 6-7, 10, 10-15, 10-15). Fünf Ärzte gaben an, dass sie dabei immer unter
Zeitdruck standen, nur einer hatte zumindest gelegentlich keinen Zeitdruck. Zur Prüfung der
Notwendigkeit einer Messung gaben drei Ärzte an, immer zu prüfen, zwei gaben an, die
Prüfung bei starkem Zeitdruck zu unterlassen, einer gab an, die Anordnungen auf Basis
eines persönlichen Merkzettel vorzunehmen.
Das Vorgehen bei der Prüfung der Notwendigkeit bestand einerseits im Durchsuchen der
Patientenakte (PCT-Vorwerte, aber auch andere Entzündungszeichen), andererseits aber
auch aus dem persönlichen Gesamteindruck, den sich der Arzt vom Patienten machen
konnte. Alle Ärzte gaben an, dass die Prüfung den Zeitaufwand bei der Erstellung der
Sonderlaborliste erhöht, teilweise deutlich.
Fragen zum Einsatz des PCT-MLMs
Zwei Ärzte gaben an, dass das PCT-MLM eine Vereinfachung darstellte, die den
Zeitaufwand bei der Erstellung der Sonderlaborliste verringerte, da es das Blättern in der
Patientenakte nach früheren PCT-Werten ersparte. Vier Ärzte gaben jedoch an, dass die
Nutzung des MLMs den Zeitaufwand (meist geringfügig) erhöhte.
Als Ursachen für den fehlenden Effekt in ON2 wurden folgende Vermutungen geäußert:
• Rückkehr zum "großen Kreuz", um Zeit zu sparen. Zitat: "Es gibt Tage, an denen ist
man froh um jede Sekunde, die man spart".
• Der Zweck des PCT-MLMs war zu wenig bekannt.
• Der Eindruck am Patientenbett hat Priorität bei der Entscheidung, nicht das MLM.
• Kommunikationsproblem, mancher war vielleicht einfach nicht informiert.
• Monatlicher Mitarbeiterwechsel, vielleicht wurden neue Mitarbeiter nicht informiert.
• Der Arzt hatte von der Nutzung des MLMs keinen persönlichen Vorteil, sondern eher
einen erhöhten Aufwand (zumindest gegenüber dem "großen Kreuz").
• Messungen können auch der Absicherung und Rechtfertigung des Arztes dienen.
Beispielsweise wenn der Chefarzt bei der Visite nach dem PCT-Wert fragt, kann es
ungünstig sein, keinen nennen zu können.
Verbesserungsvorschläge und Anmerkungen
Die Aussagen der Ärzte zeigten deutlich, dass die Sonderlaborliste unbeliebt ist. An einer
automatischen Erstellung (nicht nur für PCT, möglichst für alle Anforderungen) bestand
großes Interesse, wobei aber stets betont wurde, dass Änderungen von Seiten der Ärzte
jederzeit möglich sein müssen. Die Liste sollte also durch Anwendung von Regeln
vorausgefüllt werden, mit Nachkontrolle durch den Arzt.
Ein Arzt, der von den hohen Kosten einer Messung überrascht war, empfahl die Anzeige der
Kosten in Sonderlaborliste. Mehrfach kritisiert wurden fehlende Informationen, welche
61
Anforderungen in Kombimaßnahmen wie LTX (für Lebertransplantationen) enthalten sind.
Hier wurde die Anbringung von Hinweisen angeregt.
4.3 Zusammenfassung der Ergebnisse
Als Abschluss des Ergebnisteils können nun die Fragen beantwortet werden, die zu Beginn
dieser Arbeit gestellt wurden.
F1.1: Wie kann die datengesteuerte Ausführung von MLMs ohne Unterstützung durch ICM
und ohne den Einsatz von Datenbanktriggern erkannt und an die Arden-Engine gemeldet
werden?
Ereignisse können durch den Vergleich periodischer Exporte erkannt werden. Hierfür merkt
sich der Export-Handler, welche Daten bereits exportiert wurden. Da sich das Intervall
zwischen den Exporten nicht beliebig verkürzen lässt, resultiert aus diesem Ansatz immer
eine gewisse Reaktionsträgheit, d.h. Ereignisse werden mit Verzögerung erkannt. Diese
Verzögerung liegt auf der IOI, die mit 25 Betten eine recht große Intensivstation darstellt und
damit eine entsprechend lange Exportdauer aufweist, im Bereich von bis zu 10 Minuten.
F1.2.1: Welche Schnittstellen werden von der Arden-Engine bereitgestellt?
Die Arden-Engine von Medexter stellt eine Schnittstelle namens ArdenHostInterface bereit,
die sowohl Methoden zur Ansteuerung von außen als auch solche zur Verarbeitung von
Curly-Braces-Ausdrücken enthält. Letztere werden von der Arden-Engine dann aufgerufen,
wenn der Kontrollfluss auf entsprechende Statements trifft. Das ArdenHostInterface ist frei
programmierbar und bietet damit maximale Flexibilität bei der Anbindung an beliebige
Systeme.
F1.2.2: Wie können diese Schnittstellen mit ICM gekoppelt werden und welche
Implementierungsschritte sind dazu notwendig?
Das ArdenHostInterface konnte nicht direkt mit ICM gekoppelt werden, da ICM keine
Schnittstellen für Datenzugriff und Ereigniserkennung bereitstellt. Diese mussten über
Workarounds auf der Basis periodischer Exporte realisiert werden. Die eigentliche
Anbindung an ICM erforderte dann die Implementierung einer Ansteuermethode zur
Meldung von Ereignissen (reportEvent) und einer Curly-Braces-Methode zum Zugriff auf die
Patientendaten per READ-Statement (evaluateRead).
F1.3: Ist der in der Diplomarbeit entwickelte Datenbereitstellungsmechanismus für die zu
entwickelnde Plattform ausreichend? Gibt es Einschränkungen oder notwendige
Anpassungen?
Der grundlegende Ansatz, die benötigten Teile der PatDB in die ProxyDB zu replizieren,
wurde beibehalten. Allerdings wurde das Datenbankschema deutlich erweitert. Zudem dient
die ProxyDB nicht mehr nur als temporärer Speicher für aktuelle Patienten, sondern die
62
Daten werden dauerhaft gespeichert, um MLMs auch für bereits entlassene Patienten
ausführen zu können. Im Falle der MiBi-Daten konnte die Bereitstellung nicht über
AutoExport realisiert werden, hier war das Duplizieren des HL7-Nachrichtenstroms vom
Laborsystem erforderlich.
F1.4: Welche Präsentationsmechanismen werden von den Anwendern gefordert und
inwieweit lassen sie sich umsetzen?
Die Anwender hatten sehr klare Vorstellungen hinsichtlich der Präsentationsmechanismen.
Gefordert wurde die Anpassung zeitlicher Angaben, die Formatierung von Text, die
Generierung von Tabellen und Lineplots sowie das Auf- und Zuklappen beliebiger
Anzeigeelemente per Mausklick. Alle geforderten Präsentationsmechanismen ließen sich
vollständig umsetzen. Hierfür wurden Präsentations-MLMs entwickelt, die Anzeigeelemente
in Form von HTML und JavaScript generieren. Diese können in jedem Browser angezeigt
und auch per Email verschickt werden. Die Benutzung der Präsentationsmechanismen ist für
den Wissensingenieur recht komfortabel. Er muss lediglich die Präsentations-MLMs über ein
CALL-Statement aufrufen. Die zurückgelieferten Anzeigebausteine können durch
Konkatenation auf einfache Weise zur MLM-Ausgabe zusammengesetzt werden.
F1.5: Welche Kommunikationsendpunkte sind sinnvoll, um die klinischen Anwender zu
benachrichtigen?
Neben dem MLM-Viewer als Endpunkt für die benutzergesteuerte Ausführung von MLMs
können Emailadressen und DECT-Telefonnummern adressiert werden. In den Emails
können die Präsentationsmechanismen voll genutzt werden. Durch den Versand von SMS-
Nachrichten kann beim Event Monitoring eine zeitnahe Benachrichtigung erfolgen. Allerdings
liefert das SMS-Gateway keine Bestätigungsmeldung zurück, so dass die erfolgreiche
Zustellung nicht sichergestellt werden kann. Für den weiteren Ausbau des Systems
empfiehlt sich die Integration zusätzlicher Endpunkte, insbesondere sollte eine tiefergehende
Integration durch das Schreiben in die Patientenakte ermöglicht werden.
F2.1.1: Nach welchen Kriterien lassen sich verzichtbare PCT-Messungen erkennen?
Verzichtbare PCT-Messungen lassen sich anhand dreier Regeln ("Regelsatz") erkennen, die
von ärztlicher Seite vorgegeben wurden. Die Regeln überprüfen das Alter und den Wert der
letzten PCT-Messung sowie den aktuellen Trend.
F2.1.2: Lassen sich diese Kriterien als Regeln in Arden-Syntax formulieren?
Eine Übersetzung der Regeln in Arden-Syntax war problemlos möglich, da diese auf
Grenzwertvergleichen basieren. Der Grenzwertvergleich des Alters der letzten Messung wird
durch die temporalen Operatoren der Arden-Syntax unterstützt. Die Trenderkennung wird
63
komfortabel vom SLOPE-Operator unterstützt, der den 24-Stunden-Trend einer Liste von
Werten zurückliefert.
F2.2.1: Wie kann der zu erwartende Effekt des MLMs eingeschätzt werden?
Die Prognose eines Oberarztes auf 15% Senkung der PCT-Rate konnte als realistisch
bewertet werden, indem der Regelsatz auf die gesammelten Vergleichsdaten angewendet
und die nach den Regeln vermeidbaren Messungen ausgezählt wurden. Dies erbrachte
einen Anteil von 22% und bestätigte damit die Prognose.
F2.2.2: Welches Studiendesign ist für die Evaluierung geeignet?
Die PCT-Studie war für eine Randomisierung nicht geeignet, da dies bedeutet hätte, für
Patienten der Kontrollgruppe keine Vorschläge anzuzeigen, was von ärztlicher Seite
abgelehnt wurde. Ein Crossover-Design wurde ebenso als problematisch empfunden, so
dass nur ein ON-OFF-Design möglich war. Um einen potentiellen Effekt genauer beobachten
zu können, wurde eine zweite ON-Phase angehängt, also ein ON-OFF-ON-OFF-Design
gewählt.
F2.3.1: In wie weit lässt sich die Studie per MLM vollständig automatisieren?
Ein- und Ausschalten des MLMs ließ sich über die temporalen Operatoren der Arden-Syntax
automatisieren, die Anforderungsergebnisse wurden über die Datenreplikation in die
ProxyDB geschrieben, die Aufrufe des MLMs wurden über die Log-Tabellen des Arden-
Servers erfasst. Lediglich der Button zur Bestätigung der Nutzung musste manuell betätigt
werden.
F2.4.1: In welchem Umfang haben die Ärzte an der Studie teilgenommen?
In Phase ON1 wurde das PCT-MLM von den Ärzten bei 92% der Anforderungen aufgerufen.
Die Quote der Befolgung von Vermeidungsvorschlägen lag 22,3% über der Zufallsquote. In
ON2 wurde das MLM nur noch bei 62,3% der Anforderungen aufgerufen und die
Befolgungsquote lag nur 3,6% über der Zufallsquote. Die Ärzte haben also in ON1 in
deutlichem Umfang an der Studie teilgenommen, in ON2 aber kaum noch.
F2.4.2: Sind technische oder andere Probleme während der Studie aufgetreten?
ICM-Arden lief während der Studie stabil und es kam beim Aufruf des PCT-MLMs nicht zu
Fehlern. Allerdings kam es in ON2 an einem Tag zu einem Absturz des Replikationsjobs, der
erst nach der Erstellung der Sonderlaborliste behoben werden konnte, so dass die
Vorschläge des MLMs an diesem Tag nicht auf den aktuellsten Messungen basierten.
64
F2.4.3: Kann die Nullhypothese abgelehnt, d.h. ein Effekt nachgewiesen werden?
Die Nullhypothese kann für ON1 abgelehnt werden. Hier gab es einen ausgeprägten Effekt
mit einer Senkung des Mittelwertes der PCT-Rate um 18%. Für ON2 kann sie nicht
abgelehnt werden, hier gab es keinen beobachtbaren Effekt mehr.
65
5 Diskussion
Im Rahmen dieser Arbeit wurde eine weitgehend vollwertige Plattform zur Ausführung von
MLMs in ICM auf der Basis einer kommerziellen Arden-Engine bereitgestellt. Die
Schwierigkeiten lagen dabei nicht auf der Seite der Arden-Engine, deren frei
programmierbares ArdenHostInterface flexibel an alle Bedürfnisse angepasst werden
konnte, sondern auf der Seite des PDMS, das als Black Box eine Schnittstelle anbietet, die
nicht für einen derartigen Einsatzzweck konzipiert wurde und dafür nur eingeschränkt
geeignet ist. Die Implementierungsphase soll in Abschnitt 5.1 diskutiert werden. Neben der
Kopplung von PDMS und Arden-Engine soll dabei auch auf die Umsetzung der von den
Anwendern geforderten Präsentationsmechanismen eingegangen werden.
Auf Basis der in der Implementierungsphase bereitgestellten Plattform wurde ein MLM zur
Erkennung vermeidbarer PCT-Messungen erstellt und evaluiert. In der prospektiven Studie
wurde anfangs eine deutliche Senkung der täglichen PCT-Rate beobachtet, die aber nicht
von Dauer war. Die Evaluierungsphase wird in Abschnitt 5.2 diskutiert.
Während der Implementierungsphase konnten zudem umfangreiche Erfahrungen mit einer
neueren Version der Arden-Syntax gesammelt werden, die durch die Unterstützung von
Objekten erheblich über den Leistungsumfang der bisher am LMI verwendeten hinausgeht
und dadurch neue Perspektiven für den Einsatz von MLMs eröffnet. Dabei hat sich eine
Reihe von Aspekten gezeigt, die für weitere Forschungsarbeiten interessant sein könnten.
Diese Erfahrungen werden in Abschnitt 5.3 diskutiert.
5.1 Implementierungsphase
Sichtet man Publikationen zur Arden-Syntax, so stellt man schnell fest, dass diese
hinsichtlich der Beschreibung der technischen Integration meist nur die konzeptuelle Ebene
beschreiben. Detaillierte Informationen zu Implementierungsaspekten finden sich selten. Zu
den Ausnahmen zählen die Arbeiten zum Datenmapping von Arkad et al. [97] und
Johansson et al. [98] sowie die Dissertation von Tafazzoli [70] mit ihrer recht ausführlichen
Beschreibung der Integration einer Arden-Umgebung in das Gießener Tumor-
dokumentationssystem GTDS.
Eine Besonderheit der vorliegenden Arbeit besteht darin, dass die gekoppelten
Komponenten beide kommerzieller Art sind. Auf der einen Seite stand das PDMS ICM mit
seiner Exportschnittstelle AutoExport und den zu konzipierenden Lösungsansätzen für
Ereigniserkennung und Datenbereitstellung. Auf der anderen Seite stand die Arden-Engine
von Medexter, die es durch Implementierung des ArdenHostInterfaces und die Integration in
einen Application-Server zu einem servicebasierten Arden-Server zu erweitern galt.
66
5.1.1 Datenbereitstellung und Ereigniserkennung
Die Datenbereitstellung ist ein zentraler Aspekt für die Integration wissensbasierter
Funktionen in ein klinisches Informationssystem. Sie ist eine notwendige Vorbedingung,
ohne die Möglichkeit eines Datenzugriffes ist der Einsatz von MLMs nicht sinnvoll. Ist der
Datenzugriff nicht gegeben, so kann das wissensbasierte System zwar in einem
zeitaufwendigen Dialog vom Nutzer händisch mit Daten gefüttert werden, aber
Praxistauglichkeit und Nutzerakzeptanz sinken dadurch natürlich drastisch. Auf diesen
Umstand ist nach Musen et al. [99] die Tatsache zurückzuführen, dass technisch
wegweisende historische Systeme wie MYCIN [100], Internist-1 [101] und QMR [102] sich
nie in der klinischen Routine etabliert haben, im Gegensatz zu HELP [54, 103], bei dem die
Wissensmodule durch die Integration mit dem KIS auf die Patientendaten zugreifen konnten.
Patientendaten dürften heutzutage fast immer in einer relationalen Datenbank vorliegen, die
über eine SQL-Schnittstelle verfügt. Rein technisch gesehen sind also keine Hindernisse
beim Datenzugriff zu erwarten. Allerdings muss ein externer SQL-Zugriff auch vom Hersteller
gestattet sein, d.h. die SQL-Schnittstelle muss zur Nutzung freigegeben sein, was bei
kommerziellen Systemen wie ICM selten der Fall ist.
In der Literatur sind einige Fälle beschrieben, in denen eine Arden-Umgebung in ein
klinisches Informationssystem integriert wurde, beispielsweise am CPMC [104], am LDS
Hospital [105], am Henri-Mondor-Hospital [63], an der Universität Linköping [106] und der
Universität Gießen [70, 107]. In den beschriebenen Fällen bestand entweder ein direkter
Zugriff auf die Patientendaten oder dieser wurde zumindest nicht als problematisch
dargestellt, so dass man von einer freigegebenen Schnittstelle ausgehen kann. Eine
Datenreplikation über eine proprietäre Exportschnittstelle war hier nicht erforderlich. Die
Verwendung einer Datenbank zur Zwischenspeicherung von Patientendaten (also analog zur
ProxyDB) wird nur bei Fehre und Adlassnig beschrieben:
"Durch Integration einer internen Datenbank ist es möglich, dass sich die Rule-Engine-Software
über einen Datenimport mit Rohdaten aus einem bestehenden Informationssystem versorgt und
die Bewertung und Interpretation dieser Rohdaten dem Anwender über eine Weboberfläche
übermittelt. [108]"
Die ProxyDB wurde als EAV-Datenbank konzipiert. Daten im EAV-Format lassen sich
unkompliziert in MLMs einlesen (siehe dazu Arkad et al. [97] und Johansson et al. [98]), da
sie sich leicht auf Listen abbilden lassen. In der ProxyDB werden alle Werte in Form von
Strings gespeichert, so wie sie von ICM geliefert werden. Dieser Art der Speicherung wird
von Nadkarni [44] in einem Vergleich der Varianten des EAV-Ansatzes klar als die
schlechteste Lösung bezeichnet, die nach Möglichkeit vermieden werden sollte. Dies wirft
natürlich die Frage auf, wieso im Rahmen dieser Arbeit ausgerechnet der schlechteste
Ansatz zur Modellierung der ProxyDB verwendet wurde. Der Grund dafür findet sich in der
Tatsache, dass AutoExport keine Metadaten wie Typinformationen zur Verfügung stellt, die
für die besseren Varianten erforderlich sind. Lediglich bei den Zeitstempeln kann der
Datentyp bestimmt werden, da diese im Gegensatz zu den Werten über einen speziellen
67
Spaltenbezeichner aus der PatDB ausgelesen werden und im Target über ihre Position zu
identifizieren sind. Da alle Werte von AutoExport nur als Strings bereitgestellt werden,
werden sie vom ArdenHostInterface auch generell auf den Arden-Syntax-Datentyp STRING
gemappt. Dies hat zur Folge, dass numerische Daten im MLM explizit in den Datentyp
NUMBER konvertiert werden müssen, sofern man mit ihnen rechnen will. Strings werden bei
der Arden-Syntax nicht implizit konvertiert, wenn mathematische Operatoren darauf
angewendet werden, so wie dies bei manchen Skriptsprachen wie beispielsweise PHP der
Fall ist. Die Arden-Syntax stellt zur expliziten Konvertierung den Operator AS NUMBER zur
Verfügung, der sowohl auf elementare Typen als auch auf Listen angewendet werden kann
(siehe Spezifikation [73], Abschnitt 9.16.17). Alternativ könnte das ArdenHostInterface über
reguläre Ausdrücke eine Überprüfung durchführen und so numerische Werte erkennen und
konvertieren. Dies wäre aber eine Konvertierung "auf Verdacht" und deshalb problematisch,
da auch bei numerischen Parametern gelegentlich Hinweise (unkodierter Freitext) aus dem
Laborsystem enthalten sind, beispielsweise bei unzureichender Probenmenge oder anderen
Problemen. So hätte man im MLM eventuell Listen mit gemischten Datentypen. Zudem gibt
es in ICM Felder ohne Integritätsbedingungen. Daher erscheint es derzeit sinnvoller,
implizite Typkonvertierungen zu unterlassen und im MLM bei Bedarf explizit zu konvertieren.
Bei der Diskussion der ProxyDB sollte nicht vergessen werden, dass sie nur ein
Zwischenspeicher ist, der aus der Not heraus entstanden ist, da es aufgrund fehlender
Schnittstellen keine Alternative bei der Datenbereitstellung gab. Bei der
Zwischenspeicherung werden die Daten so abgelegt, wie sie von AutoExport geliefert
werden. Die semantische Kontrolle der Patientendaten fällt nicht in die Zuständigkeit des
Zwischenspeichers, sondern in die des PDMS bzw. der PatDB. Es bleibt zu hoffen, dass die
Anforderung auf eine Schnittstelle für den externen Datenzugriff vom Hersteller erfüllt und
damit der Replikationsprozess und damit auch die ProxyDB überflüssig wird. Mit den von der
zukünftigen Schnittstelle gelieferten Typinformationen kann das ArdenHostInterface dann ein
automatisches Typmapping durchführen, wie es beispielsweise von der EDSF-Engine auf
Basis der JDBC46-Metadaten einer SQL-Abfrage bereitgestellt wird.
Ein weiterer Kritikpunkt am Replikationsprozess ist der daraus resultierende erhebliche
Ressourcenverbrauch. Für jeden Mandanten ist ein separater Exportrechner erforderlich, der
stark unter Last steht, weil die Exporte in möglichst kurzen Intervallen stattfinden müssen.
Zudem können die Exportrechner nicht parallel zu den Exporten als Arbeitsplatzrechner
genutzt werden, da die Exporte nur laufen, wenn sich ICM im Bildschirmschonermodus
befindet, was man wohl als Anachronismus bezeichnen kann. Wright et al. [34] untersuchten
die den US-amerikanischen Markt anführenden klinischen Informationssysteme auf
Schnittstellen, die für die Anbindung wissensbasierter Systeme erforderlich sind. Die Quote
an vorhandenen Schnittstellen erscheint überraschend hoch, allerdings finden sich beim
Datenzugriff keine Details über die Art der Schnittstelle. Es bleibt zu hoffen, dass ICM um
eine Schnittstelle für den aktiven externen Datenzugriff erweitert wird. Da der Hersteller 46 Java Database Connectivity
68
verständlicherweise sein internes Datenmodell nicht offenlegen möchte, wäre wohl eine
servicebasierte Schnittstelle am besten geeignet, da bei dieser das zugrunde liegende
Datenbankschema verborgen bleiben kann.
Neben einem Workaround für die Datenbereitstellung musste in dieser Arbeit ein weiterer für
die Ereigniserkennung gefunden werden. AutoExport unterstützt die benutzer- und
zeitgesteuerte Auslösung von MLMs, nicht aber die datengesteuerte, ohne die ein
Ereignismonitoring, für das die Arden-Syntax ja ursprünglich konzipiert wurde, nicht möglich
ist. Zur Triggerung von MLMs findet man in der Literatur meist eher unspezifische Aussagen
wie
"A MLM is triggered each time a patient microbiology laboratory result is uploaded to the central
repository. [10]"
ohne weitergehende Informationen über die technische Realisierung. Eine Möglichkeit
besteht in der Nutzung eines Datenbanktriggers. Beim GTDS wird ein solcher Trigger direkt
aus den EVOKE-Slots der MLMs generiert [70]. Auch Arkad et al. beschreiben den Einsatz
von Datenbanktriggern in einer objektorientierten Datenbank [109]. Diese Möglichkeit stand
in unserem Falle nicht zu Verfügung und wäre vermutlich auch aus Sicht der Performance
problematisch gewesen47. Aber auch bei anderen Autoren wird der Einsatz von Workarounds
erwähnt. In der von Johansson und Bergqvist beschriebenen Arden-Integration wurde die
Ereigniserkennung mangels Datenbanktrigger über eine externe Überwachungskomponente
realisiert:
"Our LIS database is not active and has no trigger capabilities, a separate process is
responsible for sending the event message. The process supervises the LIS result database
and detects all new laboratory test results. An event message is created for each new result
stored in the LIS. [106]"
Auch Karadimas et al. beschreiben den Mangel von Datenbanktriggern bei einer an Arden/J
angebundenen Datenbank, der ebenfalls durch periodische Datenbankabfragen behoben
wurde [63]. In diesen Fällen bestand aber immerhin die Möglichkeit des direkten
Datenbankzugriffes, der ja im Falle von ICM nicht gegeben war. Der bei uns eingesetzte
Workaround zur Ereigniserkennung durch Vergleich von Exporten hat sich, ein wenig zu
unserer Überraschung, als recht praxistauglich erwiesen. Die Reaktionsträgheit im Bereich
von bis zu 10 Minuten stellt aber einen deutlichen Nachteil dar. Erkennt ein MLM
beispielsweise eine ausgeprägte Hypoglykämie, die ein ernsthaftes Risiko für den Patienten
darstellt, so sollte der Versand der Warnmeldung unverzüglich erfolgen. Mit einem in die
Geschäftslogik von ICM integrierten Triggermechanismus könnte der Versand innerhalb
47 Ein Trigger auf einer zentralen EAV-Tabelle kann die Performance stark beeinflussen. Für einen einzelnen
Patienten können täglich viele Tausend Tupel eingetragen werden, auf einer großen Intensivstation wie der IOI
würde das bedeuten, dass der Trigger sekündlich oder sogar noch schneller feuert.
69
weniger Sekunden durchgeführt werden. Hierfür bietet sich beispielsweise eine HL7-
Outbound-Schnittstelle an.
Eine Alternative zum Vergleich von Exporten wäre die Ereigniserkennung anhand von HL7-
Nachrichten am Kommunikationsserver. In Abbildung 18 wurde dargestellt, wie der HL7-
Nachrichtenstrom für die Mikrobiologie dupliziert wurde, um die ProxyDB mit stark
strukturierten MiBi-Daten anzureichern. Dieser Mechanismus kann natürlich für beliebige
Daten genutzt werden, die über den Kommunikationsserver geschickt werden. Beim
Eingang einer Nachricht kann dann ein Ereignis gemeldet werden und die enthaltenen Daten
gleich in die ProxyDB geschrieben werden. Dieser Ansatz ist aber dann problematisch, wenn
getriggerte MLMs zusätzlich Daten aus der ProxyDB benötigen, die nicht über den
Kommunikationsserver kommen, sondern von AutoExport geliefert werden. Dann wäre nur
eine Teilmenge der Daten in der ProxyDB auf dem neuesten Stand und es könnte zu
falschen Schlussfolgerungen kommen. Hier erscheint es geraten, einem konsistenten
Datenbestand durch DB-Snapshot den Vorzug zu geben.
Zur Datenbereitstellung sei abschließend noch gesagt, dass der Einsatz einer nativen XML-
Datenbank wie eXist48 für die ProxyDB eine diskussionswürdige Alternative darstellt. Mittels
AutoExport kann man mit wenig Aufwand valides XML erzeugen. Bei jedem Exportlauf
könnte man Patientenakten im XML-Format generieren und direkt in der XML-DB ablegen.
Ein Datenzugriff vom MLM aus auf eine native XML-Datenbank stellt kein Problem dar, das
in Abschnitt 4.1.2.2 dargestellte Aliaskonzept könnte weiterverwendet werden und XPath
statt SQL generieren. Der Vorteil wäre, dass man die Targets nicht mehr per Export-Handler
parsen müsste. Das Parsen der Targets und Aktualisieren der ProxyDB nach dem Export
dauert zwar pro Mandant nur wenige Sekunden, durch die kurzen Exportintervalle ergibt sich
in der Summe und bei steigender Mandantenzahl aber eine erhebliche Systemlast. Der
XML- Ansatz wurde hauptsächlich deswegen nicht gewählt, da man aufgrund der fehlenden
Ereigniserkennung in ICM auch hier die Exporte parsen müsste, um Ereignisse durch
Vergleich auf neu hinzugekommene Daten zu erkennen, was den hypothetischen Vorteil
wieder zunichte macht. Sollte Dräger in zukünftigen Versionen eine Outbound-Schnittstelle
für Ereignisnachrichten bereitstellen, wäre ein Umstieg auf eine native XML-Datenbank
erneut zu diskutieren. Auch deswegen, da man mit den neu hinzugekommenen Objekten
komplexe XML-Elemente direkt auf Arden-Syntax-Objekte abbilden könnte. Man könnte
durchaus in Betracht ziehen, beim Aufruf eines MLMs die komplette Patientenakte auf ein
einziges Arden-Syntax-Objekt zu mappen und damit einen komfortablen Zugriff auf die
Patientendaten zu ermöglichen. Dies stellt ein lohnenswertes Thema für weitere Forschung
dar, auch deshalb, weil am UKER in zunehmenden Maße alte trennzeichenbasierte Formate
durch XML-basierte ersetzt werden, wie derzeit beim Pathologiesystem.
48 http://exist-db.org
70
5.1.2 Arden-Server
Die Anbindung einer Arden-Engine an ein klinisches Informationssystem erfordert die
Lösung des Curly-Braces-Problems. Dazu muss die Arden-Engine eine Komponente
bereitstellen, die als Interface zum anzubindenden System dient und die Ansteuermethoden
und die Curly-Braces-Methoden enthält. Im Falle der Arden-Engine von Medexter ist dies
das ArdenHostInterface. Bei der EDSF-Engine [22] ist diese Komponente bereits
implementiert und im System gekapselt. Es kann daher nicht von der nutzenden Institution
angepasst werden, sofern der Quellcode nicht bereitgestellt wird. Dafür enthält es aber eine
vollständige und komfortable Implementierung für den Datenbankzugriff per SQL mit
Aliaskonzept und implizitem Typmapping. Die Open-Source-Variante Arden2Bytecode geht
einen Mittelweg. Hier gibt es eine Komponente namens ExecutionContext [62], die in zwei
Varianten ausgeliefert wird. Die eine ist leer, die andere enthält eine JDBC-Implementierung
für SQL-Zugriffe.
Die ursprüngliche Entscheidung, das Datenmapping vollständig der nutzenden Institution zu
überlassen, war zum Zeitpunkt des Arden-Retreats 1989 sicher sinnvoll. Angesichts heutiger
Standards wie JDBC49, die sich in den 90er Jahren etablierten, erscheint die fehlende SQL-
Unterstützung ein wenig anachronistisch. Es wäre der Verbreitung der Arden-Syntax sicher
zuträglich, wenn die Interface-Komponente einer Arden-Engine von Haus aus SQL-Zugriffe
unterstützte, wobei ein Aliaskonzept zur Vereinfachung empfohlen werden kann.
Um ein klinisches System an eine Arden-Engine anzubinden muss zunächst einmal der
Zugriff auf die Patientendaten ermöglicht werden, indem die entsprechende Curly-Braces-
Methode implementiert wird. Dabei sollte möglichst darauf geachtet werden, ein einfaches
und intuitiv verständliches Format für die Curly-Braces-Expressions zu konzipieren, um das
"doctors as programmers"-Paradigma zu unterstützen. In der Literatur wurde mehrfach
darauf hingewiesen, dass komplizierte oder gar kryptische Curly-Braces-Expressions eine
starke Barriere für die Wissensakquisition darstellen, beispielsweise bei Jenders et al.:
"Unfortunately, in our experience, clinicians and programmers have difficulty learning to write
MLMs because of the need to understand our local query syntax and data structures - features
not defined in the Syntax and left to local implementation. Moreover, busy clinicians and
researchers are reluctant to spend time to master these complexities when they require only
one or two MLMs. This problem has hindered the growth of our knowledge base. [110]"
Da beim Schreiben eines MLMs in der Regel der DATA-Slot mit seinen Curly-Braces-
Expressions zuerst geschrieben wird, stellt er sozusagen die erste Hürde dar, die es bei der
MLM-Erstellung zu nehmen gilt. Ein "abschreckendes" Beispiel dazu findet sich bei Jenders
et al. [111]:
READ LAST {'dam' = "PDQRES2" , constraints = "C**** " ; ; '32308'};
49 oder analoger Standards, sofern die Arden-Engine nicht in Java implementiert ist. Sämtliche seit dem Jahre 2002
publizierten Implementierungen wurden in Java durchgeführt.
71
Dass der dargestellte Curly-Braces-Ausdruck die Glucosewerte des Patienten anfordert, ist
ohne Detailwissen über das Speichersystem (in diesem Fall des CPMC) nicht zu erkennen.
In manchen Publikationen [106, 112] findet sich SQL in den Curly-Braces, was neben
Detailwissen über das Speichersystem auch noch SQL-Kenntnisse beim Wissensingenieur
voraussetzt. Jenders und Dasgupta [113] bieten dem Knowledge-Engineer einen Editor, der,
nach Auswahl der gewünschten Parameter aus einer Liste, SQL-Code für die Curly-Braces-
Expressions generiert und in das MLM einfügt.
In der vorliegenden Arbeit wurde von Anfang an ein einfaches Format für die Curly-Braces-
Expressions angestrebt. Das verwendete Aliaskonzept wurde weitgehend von der EDSF-
Engine übernommen (konzipiert von Sojer [22], detaillierter beschrieben bei Kraus [21]) und
an die Medexter-Engine angepasst. Damit können beispielsweise Glucosewerte
folgendermaßen ausgelesen werden:
READ {labordaten | glucose ; fallid};
Dies ist sicher verständlicher als das obige kryptische Beispiel (der Ersetzungsmechanismus
für die Variable "fallid" wurde in Abschnitt 4.1.2.2 beschrieben). Dies könnte sogar noch
vereinfacht werden, indem man die interne Fall-ID, die dem ArdenHostInterface aus der
Ereignisnachricht bekannt ist, implizit ersetzt. Außerdem ist der Alias "labordaten" der mit
Abstand am häufigsten verwendete. Man könnte ihn als Default-Alias definieren, der dann
verwendet wird, wenn kein Alias angegeben wird. Dadurch würde sich das Beispiel maximal
vereinfachen zu:
READ { glucose };
Hripcsak et al. [114] haben darauf hingewiesen, dass der weitaus größte Teil der Laufzeit
eines MLMs von den READ-Statement beansprucht wird. Die Auflösung eines Alias kostet
einen weiteren Datenbankzugriff. Sollte es bei wachsender Wissensbasis zu Performance-
problemen kommen, kann die Aliastabelle auch direkt (beispielsweise als Hashmap) in den
Code des ArdenHostInterfaces integriert werden, um ein wenig Last zu sparen.
Das in der Version 2.5 der Arden-Syntax neu hinzugekommene READ-AS-Statement
(Spezifikation Abschnitt 11.2.1.9), mit dem sich Patientendaten direkt auf Arden-Syntax-
Objekte mappen lassen, wurde im Rahmen dieser Arbeit nicht genutzt, da hierfür erst die
ProxyDB in Zusammenarbeit mit den Ärzten mit entsprechenden Metadaten angereichert
werden müsste. Für das bisherige Anwendungsszenario am UKER ist das beschriebene
Konzept bisher voll ausreichend. Es zeichnen sich aber bereits sinnvolle Anwendungsfälle
für weiterentwickelte Ansätze des Datenmappings ab, wie das Mapping ganzer
Maßnahmengruppen.
Als Kommunikationsendpunkte für den Versand von Nachrichten bei der datengesteuerten
MLM-Ausführung wurden Emailadressen und DECT-Telefonnummern implementiert.
Emailadressen sind geeignet für nicht zeitkritische Benachrichtigungen. In den Emails
können sämtlich per Sub-MLM erzeugten Präsentationsmechanismen genutzt werden. Der
72
Versand von SMS-Nachrichten an DECT-Telefone ist sinnvoll für zeitkritische
Benachrichtigungen wie Glucosewarnmeldungen (siehe Abbildung 20). Hierbei ist kritisch,
dass das angebundene SMS-Gateway keine Bestätigung für den erfolgreichen Versand
zurückliefert. Man kann sich also nicht darauf verlassen, dass die Benachrichtigung auch
beim Empfänger angekommen ist, was natürlich ein schwerwiegendes Problem darstellt,
das im Rahmen dieser Arbeit nicht gelöst werden konnte. Wünschenswert ist hier ein
Upgrade des Telefonsystems auf das Leistungsspektrum kommerzieller Anbieter50, die eine
Rückmeldung über die erfolgreiche Übertragung zum Empfänger an den Sender
zurückliefern können.
Im Sommer 2012 wurde im Rahmen einer Bachelorarbeit eine API entwickelt, die das
Setzen von IBACOs in der Patientenübersicht ermöglicht [115]. Hierbei wird eine HL7-
Nachricht an einen Integrationsserver verschickt und nach Bestätigung der Annahme in einer
Datenbanktabelle gespeichert. Diese wird dann von einem Befundübernahmerechner
weiterverarbeitet, was bei entsprechender ICM-Konfiguration zum Setzen des IBACOs führt.
Auch hier ist eine Unterbrechung der Übermittlungskette durch Ausfall des
Befundübernahmerechners nicht völlig auszuschließen, allerdings würde dies sofort
auffallen. Das größere Problem besteht darin, dass nicht sichergestellt werden kann, dass
ein korrekt gesetztes IBACO auch zeitnah von einem klinischen Mitarbeiter bemerkt wird. Es
arbeitet nicht immer ein Mitarbeiter an einem ICM-Rechner, und selbst wenn dies der Fall ist,
kann das IBACO übersehen werden. Dies wirft die Forderung nach einer Eskalationskette
auf. Der zuverlässige Versand von Meldungen an klinische Mitarbeiter ist also derzeit noch
nicht sichergestellt. Dies muss als klarer Schwachpunkt von ICM-Arden bezeichnet werden.
Die Anzeige von MLM-Ergebnissen bei der benutzergesteuerten Ausführung wurde nicht
über DESTINATION/WRITE implementiert. Stattdessen wird der Rückgabewert des
aufgerufenen MLMs im MLM-Viewer dargestellt. Darauf wird in Abschnitt 5.1.3 näher
eingegangen.
Der am UKER implementierte Arden-Server wird von außen über Ereignisnachrichten
angesteuert, die vom Export-Handler generiert werden. Der Arden-Server besitzt hierfür eine
SOAP-Web-Service-Schnittstelle. Die Anbindung basiert also auf der Service Oriented
Architecture (SOA), die in der neueren Literatur meist als empfehlenswerter Ansatz zur
Kopplung klinischer Komponenten beschrieben wird, beispielsweise bei Wright und Sittig:
"An SOA provides more modularity than other architectures, allowing for work to be distributed.
With a fully realized architecture medical specialty societies might, for example, each produce
guidelines in their area of expertise, but make them available for consumption by anyone. [116]"
Auch die EDSF-Engine und der aktuell von Medexter vertriebene Arden Server (beschrieben
bei Fehre et al. [64]) bieten eine Web-Service-Schnittstelle. Eine SOA muss nicht
50 Viele kommerzielle Web-SMS-Dienste bieten eine HTTP-API, mit der die Ankunft einer SMS auf dem
Empfängerhandy überprüft werden kann.
73
zwangsläufig mit SOAP-Web-Services umgesetzt werden. So beschreiben Müller et al. [117]
die Integration wissensbasierter Funktionen auf der Basis von CORBA.
5.1.3 Präsentationsmechanismen
In der Implementierungsphase wurde deutlich, dass den Präsentationsmechanismen von
Seiten des klinischen Personals ein hoher Stellenwert zukommt. Sobald die Ausgabe von
MLMs mehr als einige wenige Zeilen umfasste, wurde ausdrücklich eine übersichtliche
Formatierung gewünscht, meist im Tabellenformat. Auch eine Darstellung von Listen als
Liniendiagramme wurde bald gefordert. Derartige Darstellungselemente sind für MLMs
allerdings untypisch. Von MLMs generierte Meldungen enthalten meist nur kurze
Zeichenketten, die eine knappe Information enthalten. Eine typische von einem MLM
generierte Meldung findet sich bei Karadimas et al. [63] und hat lediglich folgenden Inhalt
(MLM- und Patientenname sind dabei über das User Interface einsehbar):
"Serum potassium (3.3) is low (minimum is 3.5)."
Für derart kurze Meldungen ist eine Aufbereitung kaum erforderlich. Die Displays vieler
Endgeräte im klinischen Einsatz, beispielsweise ältere DECT-Telefone und Pager, könnten
aufbereitete Informationen auch gar nicht darstellen51. Auch einfache Alertboxen auf einem
PC-Bildschirm, so wie sie beispielsweise vom Windows-Nachrichtendienst oder über die
Windows-API mancher Programmiersprachen generiert werden, können nicht unbedingt
aufbereitete Informationen darstellen. Dementsprechend findet sich kaum Literatur zur
Präsentation von MLM-Ergebnissen. Karlsson et al. beschreiben die benutzergesteuerte
Ausführung von MLMs im Rahmen einer telemedizinischen Konsultationsplattform, bei der
die Darstellung per HTML aufbereitet wurde:
"The results of the fired MLMs, usually pieces of text in the action slot, are aggregated into a
single hypertext page and passed back, via the WWW server, to the client. [118]"
Dort wird also eine Reihe von Textbausteinen, die von MLMs geliefert werden, in ein HTML-
Template integriert. Allerdings wird diese Integration von einer Webanwendung
vorgenommen. Bei ICM-Arden hingegen wird die Integration vom aufrufenden MLM
vorgenommen. Auch liefern die Sub-MLMs nicht nur Textbausteine, sondern vollständige
Präsentationselemente zurück. Die Generierung von Elementen und die Integration in
HTML-Templates können hier beliebig hierarchisch geschachtelt werden und finden immer
innerhalb von MLMs statt.
Die Anzeige im MLM-Viewer ist immer der Rückgabewert des aufgerufenen MLMs. Sind
mehrere MLMs mit einem Button verknüpft, so werden die Rückgabewerte untereinander
angezeigt. Dabei sollte man nicht zu viele MLMs an einen einzigen Button hängen, da sich
die Laufzeiten addieren und bei komplexen MLMs unzumutbare Wartezeiten entstehen
können (Das erste Gebot der "Ten commandments for effective clinical decision support"
51 Natürlich schreitet die Technik hier rasant vorwärts. Displays von Telefonen werden zunehmend HTML-fähig.
74
lautet nicht umsonst "Speed is everything" [119]). Man hätte alternativ den MLM-Viewer auch
als Kommunikationsendpunkt für DESTINATION/WRITE implementieren können, aber es
erschien konsequenter, den Ansatz für die Sub-MLMs, die immer einen String mit
HTML/JavaScript zurückliefern, bis auf die oberste Hierarchieebene fortzusetzen. Mit der
Spezifikation ist dieser Ansatz verträglich.
Der entscheidende Vorteil der im Rahmen dieser Arbeit entwickelten Präsentations-
mechanismen auf Basis von MLMs ist die Unterstützung des Wissenstransfers. Beim
Wissenstransfer können die Präsentations-Sub-MLMs einfach mit ausgetauscht werden und
der Empfänger sieht die gleiche Darstellung, ohne sein System adaptieren zu müssen.
Erforderlich ist dazu lediglich ein Webbrowser, wie er heutzutage überall verfügbar ist.
Ein weiterer Vorteil des beschriebenen Ansatzes besteht darin, dass alle Anzeigeelemente
auch in Emails weiterverwendet werden können, sofern die Implementierung des WRITE-
Statements den Content-type text/html unterstützt. Man kann also problemlos Tabellen und
Lineplots per Email versenden und der Empfänger sieht die gleiche Darstellung wie im MLM-
Viewer. Das Gleiche gilt für den Inhalt der Log-Tabellen, in denen der Arden-Server alle
MLM-Ergebnisse ablegt. Ruft man diese zu einem späteren Zeitpunkt auf, so sieht man
exakt die Darstellung, die dem Anwender ursprünglich angezeigt wurde.
Natürlich sind für die Präsentation von MLM-Ergebnissen alternative Ansätze denkbar. Ein
im Rahmen dieser Arbeit in Erwägung gezogener Ansatz besteht darin, dass die MLMs
anstelle von Strings programmiersprachliche Objekte zurückliefern, die erst zum
Anzeigezeitpunkt für die Darstellung aufbereitet werden. Seit Version 2.5 kann die Arden-
Syntax auch im Returnwert beliebige hierarchische Kombinationen von Listen und Objekten
zurückliefern. Damit ist es möglich, Objekte zurückzuliefern, aus deren Elementen
Anzeigebausteine wie auf- und zuklappbare Textblöcke, Tabellen oder Lineplots erstellt
werden können. Über die Web-Service-Schnittstelle des Arden-Servers können diese auf
programmiersprachliche Objekte des Web-Service-Clients gemappt werden. Dieser Ansatz
befreit den MLM-Ersteller aber nicht davon, die Präsentation der Ergebnisse berücksichtigen
zu müssen, da er die Strukturierung des Returnwertes selber vornehmen muss. Der
Aufwand hierfür dürfte kaum geringer sein als der für den expliziten Aufruf von
Präsentations-MLMs.
Wird der Returnwert strukturiert zurückgeliefert, so muss er zum Anzeigezeitpunkt
aufbereitet werden, bevor er in einem Viewer dargestellt werden kann. Der Mechanismus zur
Aufbereitung muss dann in den Viewer integriert sein (anstatt in die MLMs selber), und das
stellt einen Nachteil dar, da es den Austausch von MLMs zwischen Institutionen erschwert.
Man könnte auch einen Mittelweg zwischen diesen Alternativen gehen. Die MLMs könnten
Strings mit strukturierten Daten im XML-Format zurückliefern, wobei die Präsentation über
ein XSLT-Stylesheet generiert wird. Beim Wissenstransfer wäre dann das Stylesheet mit
auszutauschen. Dabei gibt es aber zu bedenken, dass es für den Wissensingenieur in
diesem Fall wohl schwerer sein dürfte, Anpassungen am Layout vorzunehmen, da hierzu
XSLT-Kenntnisse erforderlich sind.
75
Ein Einsatz von Sub-MLMs zur Präsentation im Sinne einer Template-Engine ist bisher in der
Literatur noch nicht beschrieben worden, was vor allem auf den oben beschriebenen
Umstand zurückzuführen sein dürfte, dass er für das traditionelle Anwendungsgebiet der
Arden-Syntax einfach nicht benötigt wurde. Der Ansatz kann vor allem deswegen als
vorteilhaft bewertet werden, weil er das Designziel des Wissenstransfers optimal unterstützt.
5.2 Diskussion der Evaluierungsphase
In der Literatur findet sich ein starker Konsens, dass im klinischen Umfeld regelmäßig
deutlich mehr Labormessungen als nötig durchgeführt werden (dieser Effekt wird als
"Overutilization" beschrieben). Es findet sich eine Fülle von Zitaten wie diesen:
"For decades, there has been the perception that many laboratory tests are ordered
inappropriately. Most often, this is seen as overutilization of tests - too many unnecessary lab
tests ordered. [120]"
Unnecessary laboratory testing is widely perceived as being pervasive. This perception is
supported by widely varying test ordering patterns at different sites for similar patient
populations, the observation that test ordering varies by the day of the week even though the
patient population remains constant, and variability in individual physician test ordering to
determine the number of tests necessary for diagnosis and patient management. Further
complicating this issue is the apparent lack of agreement about what constitutes appropriate
laboratory testing. [121]"
Trotz der Übereinstimmung auf der qualitativen Ebene gibt es erhebliche Unterschiede bei
der Quantifizierung. In einem systematischen Review geben van Walraven et al. [122] eine
Spanne zwischen 4,5% und 95% an. Die Quantifizierung ist auch deshalb schwierig, weil ein
nicht pathologisches Testergebnis nicht zwangsläufig bedeutet, dass der Test vermeidbar
war, was man anhand der PCT-Studie deutlich sehen kann: Auch bei einem stabilen
Langlieger mit unauffälligen Werten muss nach den Regeln alle 48 Stunden ein Test
erfolgen, der meist unkritisch und trotzdem keineswegs vermeidbar ist.
Zur Reduzierung der Overutilization gibt es ein ganzes Spektrum von Ansätzen. Eine
aktuelle und detaillierte Übersicht findet sich bei Janssens [123], der elf verschiedene
Ansätze unterscheidet, darunter "raising awareness through education and training", was in
der Literatur meist kurz als "Educational Approach" bezeichnet wird, sowie "using
computerised clinical decision support systems (CDSS)", also den Einsatz wissensbasierter
Systeme. Deren Einfluss auf den Effekt der Overutilization wurde in einer Reihe von Studien
untersucht, ein systematischer Review findet sich bei Roshanov et al. [124].
Bei der Betrachtung einzelner Studien stellt man schnell fest, dass diese meist auf einen
oder einige wenige Laborparameter fokussieren. Bereits 1977 führten Eisenberg et al. [125]
eine ON-OFF-Studie durch, die einige Parallelen zur PCT-Studie aufweist. Auch hier wurden
gezielt zwei Laborparameter ausgewählt, die sehr häufig angefordert werden, um einen
möglichst kurzen Evaluierungszeitraum zu ermöglichen. Das System lieferte einen Hinweis,
wenn eine Messung als vermeidbar erkannt wurde. Dieser Hinweis ging aber nicht direkt an
76
den Arzt, sondern wurde vorher noch von einem Mitarbeiter überprüft. Danach wurde der
entsprechende Arzt in schriftlicher Form benachrichtigt. Diese Studie hatte nur eine ON-
Phase, in der für beide Parameter über 50% der angeforderten Messungen als vermeidbar
erkannt wurden. Allerdings hatten die Benachrichtigungen an die Ärzte keinen signifikanten
Einfluss auf den Anteil vermeidbarer Messungen und die Autoren kamen zu folgender
Schlussfolgerung:
"The results indicate that overutilization of laboratory tests occurs and can be monitored by a
computer-based audit program but that modifying the clinical behavior of physicians cannot be
accomplished simply by the educational program which we used. [125]"
Trotz der EDV-basierten Erkennung vermeidbarer Messungen ordnen die Autoren ihre
Vorgehensweise dem erzieherischen Ansatz zu, wohl auch deswegen, weil 1977 die
Kategorisierung als CDSS-basierter Ansatz noch weitgehend unbekannt war. In der Literatur
herrscht Konsens, dass dem erzieherischen Ansatz selten – wenn überhaupt – langfristiger
Erfolg beschieden ist, beispielsweise bei May et al.:
"In academic settings such as ours, it has been well demonstrated that the educational
approach is shortlived, with promising effects disappearing shortly after cessation of the
educational effort. [121]"
Die PCT-Studie ist zwischen dem erzieherischen und dem CDSS-basierten Ansatz
einzuordnen. Die Meldungen werden zwar von einem wissensbasierten System generiert,
die Nutzung der Vorschlagsliste hängt aber, da eine echte Workflowintegration der
papierbasierten Liste nicht möglich war, vom Verhalten des jeweiligen Arztes ab. Die obige
Aussage, dass vielversprechende Effekte nach kurzer Zeit aufhören, kann im Kontext der
PCT-Studie voll bestätigt werden. In ON1 war mit einer relativen Senkung von 18% ein
deutlicher Effekt zu beobachten, der sich gut mit der Prognose des Oberarztes und den
Ergebnissen der Vorstudie deckte und bei dauerhaftem Anhalten eine Ersparnis in der
Größenordnung von 15000 Euro pro Jahr bedeutet hätte. In der Phase ON2 war der Effekt
bereits vollständig verschwunden. Das zweite Einschalten des MLM brachte also den
Erkenntnisgewinn, dass der Effekt, zumindest ohne Workflowintegration, nicht von Dauer
ist. Ohne dieses zweite Einschalten hätte die Gefahr bestanden, das PCT-MLM mit falschen
Erwartungen dauerhaft in den Routinebetrieb zu übernehmen. Stattdessen ist nun nach
alternativen Ansätzen zur Reduktion der PCT-Rate suchen, die langfristigen Erfolg
versprechen.
Die erweiterten Möglichkeiten der Umstellung auf EDV-basierte Erfassung von
Laboranforderungen lassen sich gut anhand eines Vergleichs mit einer von Bates et al. [126]
durchgeführten randomisierten Studie aufzeigen. Dort wurden zunächst die
Laboranforderungen elektronisch erfasst. Danach wurden die Anordnungen für Patienten auf
Vermeidbarkeit überprüft. Wurde eine Anforderung als vermeidbar erkannt, so erschien bei
Patienten der Interventionsgruppe eine Bildschirmmeldung mit einer Begründung für die
Vermeidbarkeit sowie der Möglichkeit, die Anforderung zu stornieren. Dies führte zu einem
Anteil von 27% vermeidbaren Messungen in der Interventionsgruppe gegenüber 51% in der
77
Kontrollgruppe. Eine EDV-basierte Erstellung der Sonderlaborliste würde ein
entsprechendes Studiendesign ermöglichen. Durch Abbildung auf ein HTML-Formular
könnte man MLMs mit Formularelementen wie Checkboxen verknüpfen, was über AJAX52
problemlos möglich ist. Dabei könnte man umgekehrt den Haken für eine Messung
automatisch setzen, wenn das MLM eine notwendige Messung erkennt. Im Rahmen der
Vorstudie wurden nämlich auch Fälle gefunden, in denen eine notwendige Messung nicht
erfolgte, was man per MLM vermeiden könnte. Bei einem derartigen Ansatz sind dauerhafte
Effekte möglich, wenn eine entsprechende Integration in den Workflow erfolgt. Die
Vorschlagsliste des PCT-MLMs konnte der Arzt leicht ignorieren, indem er sie gar nicht
aufrief, was in ON2 zunehmend der Fall war.
Das Studiendesign von Bates et al. hat noch einen weiteren Vorteil. Es bietet erheblich
bessere Möglichkeiten der statistischen Analyse, da man für jede einzelne Anforderung
ermitteln kann, ob die Meldung zu einer Änderung führte. Man kann also einen genauen
Vorher-Nachher-Vergleich durchführen, was bei papierbasierter Erfassung nicht möglich ist,
da man nur das Nachher kennt. Der Vorher-Nachher-Vergleich bietet auch die Möglichkeit,
Einflüsse wie beispielsweise einen allgemeinen Sensibilisierungseffekt zu analysieren. Die
immer noch signifikante Senkung der PCT-Rate in OFF1 zeigte, dass es auch bei der PCT-
Studie einen Sensibilierungseffekt gab. Dass allein die Sensibilisierung für das Problem der
Overutilization eine große Auswirkung haben kann, ist in der Literatur beschrieben,
beispielsweise bei Stuebing und Miner [127]. Am Beispiel der PCT-Studie zeigt sich also
deutlich, dass papierbasierte Anforderungen, die im klinischen Bereich immer noch weit
verbreitet sind, als Hemmschuh für den profitablen Einsatz entscheidungsunterstützender
Verfahren betrachtet werden müssen. Baron und Dighe merken hierzu an:
Clinicians have traditionally ordered laboratory tests using paper-based orders and requisitions.
However, paper orders are becoming increasingly incompatible with the complexities,
challenges, and resource constraints of our modern healthcare systems and are being replaced
by electronic order entry systems [128].
Früher oder später wird die papierbasierte Erfassung der Sonderlaborliste der Vergangenheit
angehören. Dann wird man die PCT-Studie gut als Vergleichsmaterial für die Evaluierung
einer in den Workflow integrierten EDV-basierten Erfassung nutzen können, die hoffentlich
eine dauerhafte Senkung der Overutilization nach sich zieht. Die Antworten im Interview
zeigten deutlich, dass die Ablösung der unbeliebten papierbasierten Erfassung durch eine
EDV-basierte mit über Regeln vorausgefüllten Formularen ganz im Sinne der Ärzte wäre.
Solange die Sonderlaborliste noch papierbasiert erstellt wird empfiehlt sich die Anbringung
von Hinweisen auf die Kosten einer Messung, wie von manchen Interviewteilnehmern
angeregt wurde. Denn mit einer Ausnahme waren den befragten Ärzten die Kosten einer
PCT-Messung nicht bekannt. Sofern eine Schätzung abgegeben wurde, war diese zu
52 Advanced JavaScript And XML
78
niedrig. Tierney et al. [129] untersuchten in einer randomisierten Studie den Einfluss von
Kostenhinweisen auf Laboranforderungen. Bei der EDV-basierten Anforderung eines
Labortests wurden für Patienten der Interventionsgruppe die Kosten des Tests sowie die
Summe der Tageskosten aller Tests dieses Patienten angezeigt. Die Zahl der Tests pro
Patient war in der Interventionsgruppe um 14% niedriger als in der Kontrollgruppe. Auch
sollte die Sonderlaborliste um Hinweise ergänzt werden, welche Anforderungen in den
Kombipaketen enthalten sind. Das Fehlen solcher Hinweise wurde von fast allen
Interviewteilnehmern bemängelt.
Die PCT-Studie hat gezeigt, dass ein eher einfaches MLM mit nur drei Regeln einen
deutlichen Einfluss auf die PCT-Rate haben kann, dass dieser aber von der Motivation der
Ärzte, das MLM auch zu benutzen, abhängig war. Aus den Angaben der interviewten Ärzte
kann man den Schluss ziehen, dass die meisten Nutzer schnell wieder zur üblichen
Vorgehensweise bei der Erstellung der Sonderlaborliste übergingen, also zum "großen
Kreuz", ohne weitergehende Prüfung. Dies stellt für die Ärzte die zeitsparendste Methode
dar. Ohne Umstellung auf EDV-basierte Anforderung wird das aller Voraussicht nach so
bleiben. Geeignete Ansätze zur Reduzierung der Overutilization können nach dieser
Umstellung konzipiert und untersucht werden. Die für die Ärzte mit ihrer hohen
Arbeitsbelastung ideale Methode wäre die vollautomatische Erstellung der Sonderlaborliste
per MLM, was auch gelegentlich von ärztlicher Seite angeregt wurde. Dies wird sich aber in
der Praxis kaum realisieren lassen. Erstens ist die Gesamtheit aller Faktoren, die zuverlässig
über die Notwendigkeit einer Anforderung entscheiden, oft so komplex, dass man dies, wenn
überhaupt, nur über einen sehr komplexen Regelsatz automatisieren könnte. Zweitens
entsteht eine Anforderung oft aus der Berufserfahrung des Arztes, verbunden mit seinem
persönlichen Eindruck vom Zustand des Patienten, was sich naturgemäß überhaupt nicht
automatisieren lässt. Drittens gibt es dabei noch einen medicolegalen Aspekt, da die
Entscheidung über eine Anforderung aus juristischen Gründen von einem verantwortlichen
Arzt getroffen werden muss.
Aber man muss nicht gleich das Maximalziel der vollautomatischen Erstellung der
Sonderlaborliste anstreben. Eine realistische Zielsetzung ist das regelbasierte Vorausfüllen
der Sonderlaborliste (und anderer Anforderungen), die dann in einem zweiten Schritt vom
Arzt geprüft und abgesegnet wird. Hier können MLMs eine erhebliche Unterstützung
darstellen. Im Kontext der PCT-Messungen können sie den Arzt auf diejenigen recht
zahlreichen Fälle hinweisen, in denen bei einem stabilen Langlieger eine
höchstwahrscheinlich überflüssige Messung angeordnet wird, wobei bei EDV-basierter
Anforderung eine Langzeitevaluierung der Kostenersparnis ohne Mehraufwand für die Ärzte
möglich sein sollte.
An dieser Stelle sei erneut erwähnt, dass es nicht nur ein Zuviel, sondern auch ein Zuwenig
an Labormessungen ("Underutilization") geben kann. Bei der Analyse der PCT-Raten
wurden einige Fälle gefunden, in den über längere Zeiträume keine PCT-Messungen
angeordnet wurden. In einem extremen Fall gab es eine Lücke von zehn Tagen. Von
79
ärztlicher Seite wurde auf Anfrage bestätigt, dass bei diesem Patienten Messungen nötig
gewesen wären. Derartige Fälle lassen sich bei EDV-basieter Anordnung zuverlässig per
MLM vermeiden, indem das MLM den Haken für die Anforderung setzt. Hier kann
vollautomatisch entschieden werden, da hier, im Gegensatz zu einer unterlassenen
Messung, keine Gefährdung für den Patienten entsteht. So erreicht man zwar keine
unmittelbare Kostenreduktion, verbessert aber die Behandlungsqualität. Die Fälle, in denen
eine nötige PCT-Messung versäumt wurde, lassen sich nicht exakt quantifizieren, da man in
den Lücken keine PCT-Werte hat, auf die man den Regelsatz anwenden könnte. Eine
Abschätzung ist aber möglich, da nach dem Regelsatz mindestens alle 2 Tage eine
Messung gemacht wird. Eine diesbezügliche Untersuchung von PRE erbrachte einen
Schätzwert von 54 verpassten Messungen. Bezogen auf die Gesamtzahl der Messungen
wurde damit etwa jede 38. Messung versäumt.
Zur Diskussion des gewählten Studiendesigns ist zu sagen, dass die PCT-Studie nicht von
Anfang an als ON-OFF-ON-OFF-Studie geplant war. Ursprünglich wurde eine
Randomisierung angestrebt, da randomisierte Studien in der klassischen Evidenzhierarchie
weiter oben angesiedelt sind, das heißt, ihnen wird eine stärkere Aussagekraft zugemessen
[130]. Allerdings erwies sich der zu untersuchende Sachverhalt für eine Randomisierung als
ungeeignet. Zur reibungslosen Abarbeitung der generierten Vorschläge bei der Erstellung
der Sonderlaborliste wurde von ärztlicher Seite gefordert, dass für jeden Patienten ein
Vorschlag angezeigt werden muss. Die Randomisierung hätte bedeutet, dass Vorschläge
nur für die Patienten der Interventionsgruppe angezeigt werden. In Medikamentenstudien
bekommen die Patenten der Kontrollgruppe ein Placebo, was ethisch unproblematisch ist,
solange die Wirksamkeit des Medikamentes unbewiesen ist. In der PCT-Studie war es
natürlich nicht möglich, eine "Placebomeldung" zu generieren, außerdem ist der hohe
diagnostische Wert einer PCT-Messung unbestritten. Als Alternative wurde ein Crossover-
Design in Betracht gezogen. Dieses hätte auch den Vorteil gehabt, dass es relativ kurze
Studienphasen erlaubt. Das Crossover wäre dabei über Bereiche erfolgt, d.h. das MLM wäre
abwechselnd für den allgemeinchirurgischen und den herzchirurgischen Bereich
freigeschaltet worden. Die ärztliche Forderung nach einer Vorschlagsliste für alle Patienten
ließ aber letztlich nur ein ON-OFF-Design zu.
5.3 Erfahrungen mit der Arden-Syntax
Die Arden-Syntax kann inzwischen auf eine über zwanzigjährige Geschichte zurückblicken.
Im Gegensatz zu anderen wissensbasierten Ansätzen hat sie es durch Integration in
kommerzielle Systeme über den akademischen Bereich hinaus in den klinischen
Routineeinsatz geschafft, auch wenn sie im kommerziellen Umfeld keine allzu umfangreiche
80
Verbreitung erfahren hat. Das traditionelle Einsatzgebiet der Arden-Syntax ist das Alerting53,
das heißt das Verschicken von Warnmeldungen:
"Because of the programming effort and medical domain knowledge required, development of
alerts can be a resource intensive process. This has prompted the development of the Arden
Syntax as an attempt to allow less technical personnel to create alerts and to facilitate sharing
of alerts. [131]"
Das obige Zitat weist zusätzlich darauf hin, dass die Arden-Syntax auch klinischen
Mitarbeitern die selbständige Bereitstellung von Alerting-Funktionen erlaubt. Ein typisches
Alerting-MLM, das den Anstieg des Hämatokritwertes eines Patienten mit einem Grenzwert
vergleicht, findet sich bei Hripcsak [19]. Auf einen derartigen Einsatzzweck ist der Aufbau der
MLMs (siehe Abbildung 6) gezielt zugeschnitten. Samwald et al. bezeichnen die Struktur
eines MLMs dementsprechend als "rigide", also als starr:
"All MLMs follow a rigid structure to ensure that processing code representing medical
knowledge and program logic, such as formal rules derived from clinical guidelines, is kept
separate from more technical code, such as variable declarations and interfacing with external
data sources and services. This division helps to improve the transparency of the MLM code.
[56]"
Trotz dieser Optimierung der Arden-Syntax für das datengesteuerte Alerting bzw. Event
Monitoring sind in der Literatur einige Ansätze zu ihrer anderweitigen Nutzung beschrieben,
die über das Alerting hinausgehen, wie bei Sailors et al. [132] (mit dem bezeichnenden Titel
"Moving Arden Syntax Outside of the (Alert) Box"), Sherman et al. [133] oder Starren et al.
[134] zur Abbildung von Behandlungsplänen und klinischen Protokollen. Auch komplexe
MLM-Packages wie MONI [11] oder Hepaxpert [135, 136] gehen weit über konventionelles
Alerting hinaus. Song et al. [137] beschreiben den Einsatz der Arden-Syntax zur
regelbasierten Steuerung eines Ergometers zur Behandlung von Patienten mit obstruktiver
Atemwegserkrankung.
Die meisten der im Rahmen dieser Arbeit erstellten MLMs passen ebenfalls nicht ins
klassische Alerting-Schema, schon allein weil sie benutzergesteuert statt datengesteuert
ausgeführt werden. Manche Autoren scheinen sich des Potentials der Arden-Syntax jenseits
der Alert-Box gar nicht bewusst zu sein. So findet sich bei Wright und Sittig folgende
Aussage:
"Arden syntax has two key limitations: first, it can only be used to encode event-driven, patient-
specific rules. For use cases such as drug–drug interaction checking, or panic lab value
alerting, this modality is sufficient. However, because Arden Syntax is patient-specific, it cannot
be used for population-based decision support (such as a quality-of-care dashboard), and
because it is event-driven, it cannot be used for point-of-care reference or information retrieval
support. [138]"
53 Das sieht man sehr deutlich an der Tatsache, dass der TYPE-Slot, der den Aufbau der Kategorie KNOWLEDGE
spezifiziert, nur den Wert DATA-DRIVEN (datengesteuert) kennt.
81
In diesem Zitat findet sich eine ganze Reihe von Aussagen, die aus unseren Erfahrungen mit
der Arden-Syntax nicht bestätigt werden können. MLMs sind zwar tatsächlich üblicherweise
patientenspezifisch54, aber man kann durchaus über Patientenkollektive iterieren, wie ja
auch das PCT-MLM anschaulich zeigt. Populationsbasierte Entscheidungsunterstützung wie
beispielsweise das Erkennen von Infektionsausbrüchen ist damit grundsätzlich möglich.
Ebenso können MLMs sehr wohl am Point-Of-Care genutzt werden, alle unsere
benutzergesteuerten MLMs können am Patientenbett aufgerufen werden. Auch Information
Retrieval per MLM ist möglich. Man kann leicht erraten, wie die Autoren zu ihren Aussagen
kamen. Höchstwahrscheinlich arbeiteten sie mit einem System mit integrierter Arden-Engine,
bei dem diese Einschränkungen tatsächlich galten, und konnten keine frei programmierbare
Interface-Komponente wie das ArdenHostInterface nutzen. So wurde beispielsweise bei der
Modellimplementierung am CPMC die Ausführung von MLMs auf den Kontext eines
Einzelpatienten eingeschränkt:
"As is the case with most installations of the Arden Syntax, the CPMC knowledge base retains a
single-patient focus. This is manifest particularly in the definition of events that can be detected
by the CDSS and the scope of queries that can be performed within MLMs evoked by a clinical
event monitor [10]."
Man hätte ICM-Arden ebenfalls so konzipieren können, dass alle oben genannten
Einschränkungen zutreffen. Dies bedeutet aber nicht, dass diese Einschränkungen generell
für den Sprachstandard per se gelten. Man muss hier also unterscheiden zwischen den
Beschränkungen einer konkreten Implementierung und denen der Sprache an sich. So hat
Hripcsak bezüglich der obigen Behauptung, man könnte die Arden-Syntax nur "event-driven"
(gemeint ist wohl "data-driven") einsetzen, bereits 1994 klargestellt:
"The knowledge category contains the MLM's medical knowledge. The type slot is intended to
allow future slot variations within the knowledge category. At present, the type is always data-
driven. (This does not mean, however, that the MLM must necessarily be triggered by the
storage of data; it could be triggered by any event or called by another MLM.) [19]"
Eine schwerwiegende Beschränkung für einen Einsatz der Arden-Syntax jenseits des
Alertings bestand vor der Einführung von Version 2.5 darin, dass flache Listen, auf deren
Elemente nur über die Position, nicht aber über Namen zugegriffen werden konnte, den
einzigen zusammengesetzten Datentyp darstellten. Damit waren zwar einfache
Monitoringfunktionen problemlos möglich, allerdings wurde dadurch die Abbildung
komplexerer Sachverhalte stark erschwert, was insbesondere im Zusammenhang mit der
Forschung zur Automatisierung klinischer Leitlinien kritisiert wurde [139, 140]. Die
Beschränkung auf flache Listen war ursprünglich bewusst gewählt und die daraus
54 Wenn ein Triggermechanismus einen neuen Laborwert für einen bestimmten Patienten erkennt, dann wird das
MLM natürlich im Kontext genau dieses Patienten ausgeführt. Bei benutzer- oder zeitgesteuerter Ausführung gibt es
aber viele sinnvolle Anwendungsfälle für die Verarbeitung von Patientenkollektiven.
82
resultierende Einfachheit der Arden-Syntax wird in einigen Quellen als wesentlicher Faktor
für ihren Erfolg beschrieben. Die Spezifikation merkt hierzu an:
"Arden Syntax was originally designed to be very simple, and was limited to a single method of
combining data: the ordered list. To simplify list handling, and avoid complexities of things like
lists containing lists, the syntax specifies that lists contain only individual items. This has some
significant limitations. [73]"
Die "signifikanten Limitationen" wurden durch die Einführung des Objekt-Datentyps in
Version 2.5 überwunden. Arden-Syntax-Objekte erlauben die beliebige hierarchische
Gruppierung von Daten. Sie sind allerdings nicht mit denen objektorientierter Sprachen zu
vergleichen, da es keine Methoden und kein Vererbungskonzept gibt. Der Datenzugriff
erfolgt über die Namen der Attribute, wobei im hierarchischen Fall Pfade mit Punktnotation
angegeben werden können (beispielsweise "patientenakte.falldaten.aufnahmedatum"). Die
Umsetzung basiert weitgehend auf dem Vorschlag von Jenders er al [72]. Die Auswirkungen
auf das Einsatzpotential der Arden-Syntax sind erheblich. Der Begriff des
Paradigmenwechsels gilt zwar in der akademischen Literatur als überstrapaziert und sollte
sparsam eingesetzt werden, hier erscheint er aber durchaus als angebracht. Auch die
Spezifikation spricht wörtlich von einem dramatischen Anstieg der Möglichkeiten:
"Objects are new in Arden 2.5. These have been added as an enhancement to the Arden
Syntax to address user and vendor concerns about Arden limitations, and to dramatically
increase the capabilities of the syntax. [...]. Items in a list can only be referred to via their index
(a number) which is not easy to read or understand. Structured data is actually a simplifying
concept. Introducing structured data types, while allowing complex structures, tends to make
any given usage simpler because of the ability to declare names and relationships. [73]"
Die leichte Benutzbarkeit der im Rahmen dieser Arbeit in Arden-Syntax implementierten
Präsentationsmechanismen wäre ohne Objekte zwar technisch möglich, aber kaum
anwendertauglich gewesen. Dies hätte erfordert, sämtliche Parameter in flache Listen zu
packen und diese an die Sub-MLMs zu übergeben. Mangels Zugriff über Namen wäre deren
Code deutlich schwerer zu verstehen und zu warten gewesen. Unter Nutzung von Objekten
hingegen kann das aufrufende MLM ein einziges hierarchisch strukturiertes
Beschreibungsobjekt für eine Tabelle, eine Grafik etc. erzeugen und an das Präsentations-
MLM übergeben, wo dann ein komfortables und leicht nachvollziehbares Auslesen möglich
ist. Die neuen Versionen der Arden-Syntax bieten also zusätzliche Einsatzmöglichkeiten
jenseits der Wissensrepräsentation. So kann man die Arden-Syntax in ihren neuen
Versionen über ihre ursprüngliche Bestimmung zur medizinischen Wissensrepräsentation
hinaus als Kandidat für eine generische Plugin-Sprache für klinische Systeme empfehlen.
Der duale Charakter der Arden-Syntax wird auch in der sehr lesenswerten Publikation von
Samwald et al. herausgestrichen:
83
"Arden Syntax can be seen as a hybrid between classical production rules and procedural
representation of clinical algorithms. [...] For projects in which Arden Syntax code was only
created and maintained within our group, we preferred to use a succinct coding style,
resembling other established programming languages. For projects in which the code was
shared and needed to be understood by non-experts in computer science, we used the more
verbose coding style that was closer to natural language. [56]"
Einige Anwendungsgebiete der Arden-Syntax, die sich in dieser Arbeit eröffnet haben, sind in
der Literatur bisher noch nicht beschrieben worden. Am UKER ist eine Reihe von MLMs für
DRG-Coder entstanden, mit denen einige zeitaufwendige Routineschritte bei der Analyse der
Patientenakte nach Entlassung des Patienten auf Knopfdruck durchgeführt werden können.
Die Logfiles zeigen deutlich, dass die DRG-Coder eifrige Benutzer der MLMs sind. Dies ist
leicht nachvollziehbar, da sich manche zeitraubenden Suchaktionen in der Patientenakte auf
einen Knopfdruck reduzieren lassen. Abbildung 31 zeigt einen Ausschnitt aus der Ausgabe
eines MLMs zur Prüfung auf korrekte OPS-Codes in der Kinderklinik. Bestimmte Codes sind
nur bei Neugeborenen erlaubt, es kommt aber gelegentlich vor, dass diese Codes in die Akte
eines älteren Patienten eingetragen werden. Die sehr einfache Logik des MLMs besteht im
Wesentlichen aus zwei Bedingungen und einer Schleife, ein derartiges MLM ist in kurzer Zeit
erstellt und kann einen dauerhaften Mehrwert erbringen.
Abbildung 31: Beispiel eines MLMs für DRG-Coder
Es sind auch einige MLMs entstanden, die Daten filtern und optisch aufbereiten. Diese
MLMs enthalten keine Entscheidungslogik im herkömmlichen Sinne, sondern dienen nur
einer verbesserten Anzeige von Patientendaten. Ein bei den Ärzten beliebtes Beispiel ist ein
MLM zur Generierung einer kompakten Übersicht über die MiBi-Befunde aller Patienten der
letzten sieben Tage.
Im Rahmen dieser Arbeit wurden von den Klinikern einige MLMs angefordert, die Scores
berechnen, die ICM bisher nicht unterstützt, wie den MELD-Score, den PRISM-III-Score, den
RIFLE/AKIN-Score und den Lung-Injury-Score nach Murray. Die entwickelten MLMs konnten
anfangs nur den jeweils aktuellen Score-Wert zurückliefern. Später wurden sie so erweitert,
dass sie auch den zeitlichen Verlauf der Scores berechnen können, wobei auch die
84
Anforderungen an die Darstellung immer höher wurden. Dies brachte einen Aspekt ins Spiel,
der zu Beginn dieser Arbeit gar nicht als möglicher Untersuchungsgegenstand in Betracht
gezogen wurde, nämlich die Wiederverwendung von Wissen ("knowledge reuse"). Diese ist
zu unterscheiden vom Wissenstransfer ("knowledge transfer"), für den die Arden-Syntax ja
ausdrücklich konzipiert wurde. Shwe et al. [141] treffen folgende Unterscheidung:
Wissenstransfer bedeutet, dass MLM A von einer Institution X zu Institution Y übertragen und
dort in Betrieb genommen wird. Wiederverwendung von Wissen bedeutet, dass Teile des in
MLM A enthaltenen Wissens in einem anderen MLM B derselben Institution X
wiederverwendet werden. Die Autoren beschreiben die schlechte Eignung der Arden-Syntax
zur Wiederverwendung von Wissen, die auf die prozedurale Repräsentation zurückgeführt
wird (siehe dazu auch Sherman et al. [133]). Bereits in der Rationale [20] wurde ausdrücklich
darauf hingewiesen, dass die Wiederverwendung von Wissen kein Designziel der Arden-
Syntax darstellt. Dies führte in der Praxis meist dazu, dass neue MLMs erstellt wurden,
indem bestehende kopiert und modifiziert wurden. So bestand auch am UKER die erste
Form der Wiederverwendung im Kopieren von MLMs. War ein MLM zur Prüfung der
Kaliumwerte fertiggestellt, so wurde eine Kopie erstellt und diese auf Natrium etc.
angepasst. Bei ähnlicher Funktionalität und geringer Komplexität ist dies problemlos
möglich. Nachdem aber das Anwendungsspektrum für MLMs immer breiter wurde, entstand
der Bedarf nach Wiederverwendung von Wissen. Hier zeigte sich schnell, dass unter
Verwendung der neu eingeführten Objekte die naheliegendste Form der Wiederverwendung
problemlos möglich ist: Die Modularisierung. Immer wiederkehrende Codesequenzen
wurden in Sub-MLMs ausgelagert. Es dürfte sich lohnen, den Weg vom MLM zum MLM-
Package bzw. Medical Knowledge Package [142] weiterzugehen und die Modularisierung
auch im Kontext eines Rapid Prototypings zu betreiben. dies erfordert natürlich eine
entsprechende generische Programmierweise. Um dies am konkreten Beispiel zu
verdeutlichen: Berechnungsvorschriften für Scores und Formeln wurden in MLMs mit dem
Präfix "calculate_" ausgelagert, beispielsweise "calculate_meldscore". Der Aufruf erfolgt
immer mit einem Objekt, das alle benötigten Parameter ("MeldScoreParameters") enthält.
Um nun mittels eines Calculator-MLMs ein zeitliches Verlaufsprofil zu erstellen, wird immer
die selbe Methode angewendet, nämlich ein Zeitfenster, das über die Zeitachse wandert, die
Parameter extrahiert und aggregiert und daraus das Parameterobjekt generiert. Dieser
Vorgang könnte ebenfalls weitgehend über generische Sub-MLMs abgebildet werden. Von
klinischer Seite wurde bei manchen Scoreprofilen eine Anzeige der Berechnungsgrundlage
gefordert, in Form einer Tabelle mit allen Eingabeparametern für jeden einzelnen Scorewert.
Auch die Anzeige der Berechnungsgrundlage könnte man per Sub-MLM automatisieren.
Man kann sich also beispielsweise ein komplexes MLM-Package vorstellen, bei dem der
Wissensingenieur nur das Top-Level-MLM und das Calculator-MLM erstellen muss, um mit
wenig Aufwand für beliebige Scores und Formeln den aktuellen Wert, das zeitliche Profil, die
Bewertungsgrundlage und beliebige weitere Elemente zu generieren, beispielsweise eine
Liste von Grenzwertverletzungen, eine Trendanalyse oder eine Verlaufsgrafik.
85
Die Arden-Syntax genießt im akademischen Umfeld einen hohen Bekanntheitsgrad und ist
Gegenstand einer respektablen Zahl von Publikationen. Trotzdem ist ihr Verbreitungsgrad in
der klinischen Routine als eher gering anzusehen. Vielleicht ist ein Einflussfaktor für die
mäßige Verbreitung der Arden-Syntax ihr früher Entstehungszeitpunkt. Sie wurde zu einer
Zeit entwickelt, als an vielen Kliniken überhaupt noch keine klinischen EDV-Systeme
geschweige denn PDMS im Einsatz waren55. Gewichtiger dürfte allerdings sein, dass die
Integration einer Arden-Umgebung für kommerzielle Anbieter klinischer Systeme wenig
attraktiv ist. Bekanntermaßen ist die Industrie an Standards wenig interessiert, da diese die
Systeme in einem gewissen Grade austauschbar machen. Den Herstellern ist daran kaum
gelegen, da sie von einer auf proprietären Leistungsmerkmalen basierenden Abhängigkeit
des Kunden profitieren56. Ein weiterer wichtiger Aspekt ist das Medizinproduktegesetz. Bei
Integration einer Arden-Umgebung kann ein klinisches System kaum noch als reines
Dokumentationssystem klassifiziert werden, was für den Hersteller den hohen Aufwand einer
Zertifizierung als Medizinprodukt nach sich zieht [143]. Sollte eine Institution die Arden-
Syntax in Eigenregie in ein bestehendes klinisches System integrieren wollen, so kann sie
dies über eine externe Arden-Umgebung wie die von Medexter realisieren. Dies setzt
natürlich das Vorhandensein geeigneter Schnittstellen voraus.
Mit der Verfügbarkeit einer ausgereiften kommerziellen Arden-Umgebung und einer
vollwertigen Open-Source-Variante könnte die Arden-Syntax einen Aufschwung zu erleben.
Pohl et al. bezeichnen die Arden-Syntax als antiquiert, empfehlen aber trotzdem ihren
Einsatz, solange sich keine Alternativen etabliert haben:
"Ein zweiter Schwachpunkt bei der Arden-Syntax liegt in der antiquierten (Fortran-ähnlichen)
Programmiersprache für die Implementierung der Logik. Deklarative Sprachelemente, welche
es erlauben, medizinische Regeln ohne spezielle Computerkenntnisse darzustellen, würden
den Aufbau vor allem auch größerer Wissensbasen besser unterstützen. Andererseits waren
vielleicht gerade die hohe Flexibilität beim Datenzugriff und die vertraute Nähe zu
konventionellen Programmiersprachen wichtige Elemente für den Erfolg der Arden-Syntax in
den letzten Jahren. Es sei deshalb an dieser Stelle auch den deutschen Labor-EDV-Herstellern
empfohlen, die Arden-Syntax in ihren Systemen zu unterstützen. Dies schließt den
gleichzeitigen Einsatz 'besserer' eigener Basissprachen zur Wissensrepräsentation keineswegs
aus. [144]"
Nadkarni geht sogar noch einen Schritt weiter. Er würdigt die Arden-Syntax insbesondere
unter dem Aspekt der Identifizierung von im klinischen Umfeld sinnvollen Operatoren,
beschreibt sie aber wie einen historischen Ansatz und betont, dass viele damalige Motive für
die Schaffung der Arden-Syntax heute ihre Gültigkeit verloren hätten, da sie keinen Vorteil
mehr gegenüber modernen Allzwecksprachen wie Java oder .NET aufweisen könne [44].
55 Auch am UK Erlangen mit einer recht fortschrittlichen IT-Ausstattung sind PDMS erst seit 2006 im Einsatz. 56 Das soll kein Vorwurf sein. Auf einem hart umkämpften Markt, bei dem der Verlust eines Kunden das
wirtschaftliche Überleben gefährden kann, ist dieses Verhalten verständlich.
86
Zu diesen Aussagen ist folgendes anzumerken: Die Syntax wird in anderen Quellen mit
Pascal und nicht mit Fortran verglichen (beispielsweise [19, 145, 146]). Gerade diese
Pascal-ähnliche Syntax wurde von einigen Anwendern am UKER ausdrücklich als
angenehm, da leicht verständlich, bezeichnet. Die Ähnlichkeit zu Pascal wurde in älteren
Publikationen gerade deswegen betont, weil Pascal seinerzeit als besonders einfach zu
erlernende Sprache galt. Unter den heute aktuellen Sprachen erinnert die Arden-Syntax
syntaktisch an Python57. Dabei ist bemerkenswert, dass bei der Schaffung von Python ein
einziges Designziel verfolgt wurde, nämlich die einfache Erlernbarkeit, was ja auch eines der
beiden Designziele der Arden-Syntax war. Man sollte also leichte Verständlichkeit nicht
unbedingt mit Antiquiertheit gleichsetzen.
Zur Aussage von Nadkarni stellt sich die Frage, wie der Einsatz einer Allzwecksprache im
Kontext von "doctors as programmers" in der Praxis aussehen soll. Um beim von ihm
angeführten Beispiel der Programmiersprache Java zu bleiben: Damit ist es dem
Informatiker möglich, Zusatzfunktionen für ein klinisches System zu erstellen. Aber es
erscheint wenig ratsam, den Kliniker zu dieser Tätigkeit aufzufordern. Manche
Entwicklungsumgebungen sind so komplex, dass selbst der Informatiker den Durchblick
verlieren kann. Java ist derart mächtig und erfordert ein derartig hohes Programmierwissen,
dass man anzweifeln kann, ob auf diese Weise jemals brauchbare Komponenten entstehen.
Hier wird die hohe Flexibilität und Leistungsfähigkeit der Allzwecksprachen paradoxerweise
zum Nachteil und führt zum in den Grundlagen beschriebenen Knowledge Acquisition
Bottleneck. Aus rein technischer Sicht ist Nadkarni voll und ganz zuzustimmen, da alles, was
sich in Arden-Syntax implementieren lässt, auch mit Allzwecksprachen realisieren lässt. Aber
die rein technische Perspektive wird den Anforderungen der medizinischen Domäne nicht
gerecht, was sich gut an einem Beispiel illustrieren lässt, das wir am LMI im Rahmen
unserer Vorlesung zu wissensbasierten Systemen verwenden. Zur Berechnung des RIFLE-
Scores ist ein Referenzwert erforderlich, und zwar das Minimum der Kreatininwerte, die
zwischen zwei und drei Tage alt sind. In Arden-Syntax lässt sich der Referenzwert
folgendermaßen bestimmen:
LET referencevalue BE THE MINIMUM OF (
creatininevalues WHERE THEY OCCURRED
WITHIN 3 DAYS AGO TO 2 DAYS AGO);
Dies dürfte für die meisten klinischen Anwender und potentiellen Wissensingenieure viel
leichter verständlich sein als eine Bestimmung in Java (die Formulierung des obigen
Beispiels in Java sei dem geneigten Leser überlassen). Zudem besteht bei
Allzwecksprachen eine gewisse Gefahr, dass absichtlich oder unabsichtlich ein Schaden
angerichtet und eventuell sogar der korrekte Betrieb des klinischen Systems gefährdet wird.
Die Arden-Syntax hingegen ist in ihren Möglichkeiten vergleichsweise beschränkt, und zwar
auf das, was in ihrer Domäne benötigt wird. Über das ArdenHostInterface besteht volle
57 http://www.python.org/
87
Kontrolle, auf welche Daten der MLM-Ersteller zugreifen kann und welche Arten von
Nachrichten er an welche Ziele versenden kann. Interessanterweise ist das Curly-Braces-
Problem unter einem Sicherheitsaspekt betrachtet gar nicht unbedingt ein Problem, sondern
ein Schutzmechanismus, da man das Interface sehr restriktiv auf diejenigen Operationen
einschränken kann, die der Wissensingenieur auch können darf.
Man kann es so formulieren: Die Arden-Syntax ist ein Spezialwerkzeug, das auf die Nutzung
in einem eng umgrenzten Einsatzgebiet zugeschnitten ist. Innerhalb ihrer Domäne ist sie
den Allzwecksprachen in einigen Aspekten sogar überlegen.
88
6 Ausblick
Im Rahmen dieser Arbeit ist eine technische Plattform entstanden, die für den
Routineeinsatz tauglich ist. Um sie auf weiteren Intensivstationen in Betrieb zu nehmen, ist
zunächst eine entsprechende Lizenzierung der Arden-Engine erforderlich, da die bisherigen
Arbeiten mit einer Lizenz für Forschung und Lehre durchgeführt wurden. Der nächste Schritt
besteht somit in der Finanzierung des Systems.
Von Seiten des PDMS wären vollwertige Schnittstellen wünschenswert, um nicht mehr auf
Workarounds zurückgreifen zu müssen, nämlich eine Outbound-Schnittstelle für
Ereignisnachrichten und eine Schnittstelle für den externen Datenzugriff. Hier ist der
Hersteller des PDMS aufgefordert, diese Komponenten zu entwickeln. An den Hersteller der
Arden-Engine bestehen keine Anforderungen, da sich diese als stabil und voll praxistauglich
erwiesen hat. An das UKER besteht die Anforderung, einen sicheren Weg für die
Benachrichtigung der Ärzte bereitzustellen. Die derzeit fehlende Bestätigung für einen
erfolgreichen SMS-Versand ist als sehr problematisch zu bewerten. Die von den MLMs
generierten Meldungen werden sozusagen blind verschickt. Hier sollte eine API
bereitstehen, über die die Ankunft der Nachricht beim Empfänger überprüft werden kann.
Die PCT-Studie hat gezeigt, dass ein einzelnes MLM mit wenigen Regeln einen erheblichen
Einfluss auf die Anforderungen eines Laborparameters und die damit verbundenen Kosten
haben kann. Dieser Einfluss war zwar nur von kurzer Dauer, dies kann aber auf die
papierbasierte Anforderung mit fehlender Workflowintegration zurückgeführt werden. Bei
Umstellung von papierbasierter auf EDV-basierte Anforderung sollte es möglich sein,
dauerhafte Resultate zu erzielen. Findet man weitere geeignete Anwendungsgebiete für
MLM, so ist die Hoffnung durchaus realistisch, dass die Summe der Einsparungen deutlich
höher liegt als Lizenz- und Personalkosten. Zudem ist der positive Einfluss wissensbasierter
Systeme auf Behandlungsqualität und -erfolg unbestritten.
Für den universitären Bereich gibt es einige Felder, in denen die Arden-Syntax ein
lohnendes Forschungsobjekt darstellt. Erstens sollten weitere MLMs im klinischen Umfeld
evaluiert werden, um den Nutzwert der Arden-Syntax weiter zu präzisieren. Zweitens sollte
die Eignung von MLMs für einen Einsatz jenseits des datengesteuerten Alertings weiter
untersucht werden, beispielsweise als Werkzeug für DRG-Coder und für die
benutzergesteuerte Entscheidungsunterstützung am Patientenbett. Drittens besteht klarer
Bedarf für Forschung zum Mapping komplexer Daten, insbesondere EAV/CR-Objekte und
Daten im XML-Format, auf Arden-Syntax-Objekte. Hierbei sollte auch untersucht werden, ob
der traditionelle Umgang mit dem Curly-Braces-Problem noch zeitgemäß ist.
89
7 Abkürzungsverzeichnis
AJAX Advanced JavaScript And XML
CDSS Clinical Decision Support System
CPMC Columbia Presbyterian Medical Center
CSS Cascading Style Sheets
DRG Diagnosis Related Groups
EAV(/CR) Entity-Attribute-Value (with Classes and Relationships)
HELP Health Evaluation through Logical Processing
HTML Hypertext Markup Language
ICD International Classification of Diseases
ICM Integrated Care Manager
IDE Integrated Development Environment
INR International Normalized Ratio
IOI Interdisziplinäre Operative Intensivstation
Java EE Java Platform, Enterprise Edition
JCF Job Control File
JDBC Java Database Connectivity
KAS Klinisches Arbeitsplatzsystem
LDS Latter Day Saints Hospital
LMI Lehrstuhl für medizinische Informatik
MELD Model for End-stage Liver Disease
MLM Medical Logic Module
OPS Operationen- und Prozedurenschlüssel
PCT Procalcitonin (Biomarker)
PHP PHP Hypertext Preprocessor
PDMS Patientendatenmanagementsystem
POJO Plain Old Java Object
SIRS Systemic Inflammatory Response Syndrome
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SQL Structured Query Language
UKER Universitätsklinikum Erlangen
WSAS Web Service Application Server
WSDL Web Service Description Language
XML Extensible Markup Language
XSL-T Extensible Stylesheet Language Transformation
90
8 Anhang
8.1 PCT-Raten der Studienphasen
Legende: B = Bettenbelegung im Sinne abrechenbarer Liegetage; M = Anzahl der PCT-
Messungen; R = PCT-Rate, berechnet als Quotient aus M und B
Einzelwerte des Vergleichszeitraums PRE
Datum B M R Datum B M R Datum B M R Datum B M R01.03.2010 23 17 0,739 01.04.2010 20 14 0,700 02.05.2010 20 13 0,650 02.06.2010 20 16 0,80002.03.2010 21 18 0,857 02.04.2010 19 12 0,632 03.05.2010 20 14 0,700 03.06.2010 18 18 1,00003.03.2010 22 15 0,682 03.04.2010 18 18 1,000 04.05.2010 19 16 0,842 04.06.2010 19 13 0,68404.03.2010 23 23 1,000 04.04.2010 19 16 0,842 05.05.2010 20 16 0,800 05.06.2010 20 19 0,95005.03.2010 21 18 0,857 05.04.2010 18 13 0,722 06.05.2010 22 18 0,818 06.06.2010 19 19 1,00006.03.2010 20 18 0,900 06.04.2010 20 12 0,600 07.05.2010 20 13 0,650 07.06.2010 23 23 1,00007.03.2010 20 19 0,950 07.04.2010 22 13 0,591 08.05.2010 19 17 0,895 08.06.2010 20 18 0,90008.03.2010 25 16 0,640 08.04.2010 21 16 0,762 09.05.2010 19 18 0,947 09.06.2010 19 20 1,05309.03.2010 21 18 0,857 09.04.2010 20 13 0,650 10.05.2010 20 17 0,850 10.06.2010 20 16 0,80010.03.2010 21 15 0,714 10.04.2010 19 19 1,000 11.05.2010 18 14 0,778 11.06.2010 19 18 0,94711.03.2010 21 13 0,619 11.04.2010 19 20 1,053 12.05.2010 18 17 0,944 12.06.2010 20 12 0,60012.03.2010 21 19 0,905 12.04.2010 19 17 0,895 13.05.2010 18 14 0,778 13.06.2010 19 14 0,73713.03.2010 18 16 0,889 13.04.2010 20 20 1,000 14.05.2010 18 15 0,833 14.06.2010 20 12 0,60014.03.2010 17 17 1,000 14.04.2010 22 20 0,909 15.05.2010 17 15 0,882 15.06.2010 21 13 0,61915.03.2010 20 17 0,850 15.04.2010 22 22 1,000 16.05.2010 19 20 1,053 16.06.2010 21 19 0,90516.03.2010 21 19 0,905 16.04.2010 22 19 0,864 17.05.2010 22 16 0,727 17.06.2010 18 10 0,55617.03.2010 21 18 0,857 17.04.2010 20 16 0,800 18.05.2010 19 13 0,684 18.06.2010 19 14 0,73718.03.2010 22 11 0,500 18.04.2010 18 14 0,778 19.05.2010 20 11 0,550 19.06.2010 18 8 0,44419.03.2010 20 19 0,950 19.04.2010 20 14 0,700 20.05.2010 22 11 0,500 20.06.2010 19 10 0,52620.03.2010 19 15 0,789 20.04.2010 22 15 0,682 21.05.2010 19 13 0,684 21.06.2010 20 17 0,85021.03.2010 19 14 0,737 21.04.2010 19 15 0,789 22.05.2010 17 10 0,588 22.06.2010 20 20 1,00022.03.2010 22 13 0,591 22.04.2010 20 19 0,950 23.05.2010 19 13 0,684 23.06.2010 20 15 0,75023.03.2010 23 15 0,652 23.04.2010 19 15 0,789 24.05.2010 19 13 0,684 24.06.2010 19 18 0,94724.03.2010 21 14 0,667 24.04.2010 17 14 0,824 25.05.2010 21 19 0,905 25.06.2010 20 18 0,90025.03.2010 25 17 0,680 25.04.2010 17 11 0,647 26.05.2010 19 19 1,000 26.06.2010 19 15 0,78926.03.2010 24 16 0,667 26.04.2010 19 19 1,000 27.05.2010 18 22 1,222 27.06.2010 18 14 0,77827.03.2010 22 18 0,818 27.04.2010 25 19 0,760 28.05.2010 22 26 1,182 28.06.2010 21 17 0,81028.03.2010 22 17 0,773 28.04.2010 19 21 1,105 29.05.2010 20 12 0,600 29.06.2010 23 15 0,65229.03.2010 23 22 0,957 29.04.2010 21 20 0,952 30.05.2010 20 13 0,650 30.06.2010 21 15 0,71430.03.2010 20 20 1,000 30.04.2010 20 21 1,050 31.05.2010 22 14 0,63631.03.2010 22 20 0,909 01.05.2010 19 13 0,684 01.06.2010 19 19 1,000
Einzelwerte der Studienphase ON1
Datum B M R Datum B M R Datum B M R Datum B M R17.01.2011 24 13 0,542 24.01.2011 19 13 0,684 31.01.2011 19 19 1,000 07.02.2011 20 11 0,55018.01.2011 24 11 0,458 25.01.2011 25 14 0,560 01.02.2011 17 15 0,882 08.02.2011 20 12 0,60019.01.2011 21 14 0,667 26.01.2011 24 10 0,417 02.02.2011 19 13 0,684 09.02.2011 22 13 0,59120.01.2011 22 14 0,636 27.01.2011 21 16 0,762 03.02.2011 22 16 0,727 10.02.2011 21 9 0,42921.01.2011 23 13 0,565 28.01.2011 20 13 0,650 04.02.2011 18 14 0,778 11.02.2011 19 11 0,57922.01.2011 21 21 1,000 29.01.2011 19 13 0,684 05.02.2011 19 12 0,632 12.02.2011 21 13 0,61923.01.2011 20 16 0,800 30.01.2011 17 13 0,765 06.02.2011 20 10 0,500 13.02.2011 18 14 0,778
91
Einzelwerte der Studienphase OFF1
Datum B M R Datum B M R Datum B M R Datum B M R14.02.2011 19 17 0,895 21.02.2011 19 14 0,737 28.02.2011 22 17 0,773 07.03.2011 24 20 0,833
15.02.2011 18 15 0,833 22.02.2011 18 12 0,667 01.03.2011 20 18 0,900 08.03.2011 22 14 0,636
16.02.2011 17 17 1,000 23.02.2011 18 15 0,833 02.03.2011 22 18 0,818 09.03.2011 25 14 0,560
17.02.2011 20 19 0,950 24.02.2011 19 13 0,684 03.03.2011 22 14 0,636 10.03.2011 22 10 0,455
18.02.2011 18 18 1,000 25.02.2011 21 8 0,381 04.03.2011 19 13 0,684 11.03.2011 22 18 0,818
19.02.2011 17 14 0,824 26.02.2011 19 11 0,579 05.03.2011 21 11 0,524 12.03.2011 20 15 0,750
20.02.2011 18 11 0,611 27.02.2011 21 16 0,762 06.03.2011 22 14 0,636 13.03.2011 19 14 0,737
Einzelwerte der Studienphase ON2
Datum B M R Datum B M R Datum B M R Datum B M R14.03.2011 20 16 0,800 21.03.2011 21 11 0,524 28.03.2011 19 9 0,474 04.04.2011 20 12 0,600
15.03.2011 18 18 1,000 22.03.2011 20 14 0,700 29.03.2011 18 18 1,000 05.04.2011 18 13 0,722
16.03.2011 21 18 0,857 23.03.2011 18 14 0,778 30.03.2011 18 17 0,944 06.04.2011 18 17 0,944
17.03.2011 17 20 1,176 24.03.2011 19 14 0,737 31.03.2011 16 15 0,938 07.04.2011 22 11 0,500
18.03.2011 20 18 0,900 25.03.2011 19 18 0,947 01.04.2011 18 17 0,944 08.04.2011 17 12 0,706
19.03.2011 18 11 0,611 26.03.2011 19 13 0,684 02.04.2011 14 12 0,857 09.04.2011 16 14 0,875
20.03.2011 18 16 0,889 27.03.2011 19 11 0,579 03.04.2011 16 14 0,875 10.04.2011 14 13 0,929
Einzelwerte der Studienphase OFF2
Datum B M R Datum B M R Datum B M R Datum B M R11.04.2011 19 18 0,947 18.04.2011 22 14 0,636 25.04.2011 20 16 0,800 02.05.2011 21 16 0,762
12.04.2011 21 20 0,952 19.04.2011 20 13 0,650 26.04.2011 19 16 0,842 03.05.2011 20 10 0,500
13.04.2011 19 19 1,000 20.04.2011 17 15 0,882 27.04.2011 21 14 0,667 04.05.2011 23 17 0,739
14.04.2011 21 19 0,905 21.04.2011 21 12 0,571 28.04.2011 21 13 0,619 05.05.2011 20 12 0,600
15.04.2011 20 20 1,000 22.04.2011 19 15 0,789 29.04.2011 19 17 0,895 06.05.2011 20 6 0,300
16.04.2011 20 23 1,150 23.04.2011 19 16 0,842 30.04.2011 20 19 0,950 07.05.2011 20 12 0,600
17.04.2011 19 15 0,789 24.04.2011 19 21 1,105 01.05.2011 19 15 0,789 08.05.2011 19 17 0,895
Einzelwerte der Studienphase POST
Datum B M R Datum B M R Datum B M R Datum B M R09.05.2011 19 17 0,895 16.05.2011 18 17 0,944 23.05.2011 19 19 1,000 30.05.2011 20 8 0,400
10.05.2011 18 17 0,944 17.05.2011 21 16 0,762 24.05.2011 20 22 1,100 31.05.2011 22 15 0,682
11.05.2011 18 19 1,056 18.05.2011 21 12 0,571 25.05.2011 21 21 1,000 01.06.2011 21 13 0,619
12.05.2011 20 15 0,750 19.05.2011 22 15 0,682 26.05.2011 23 16 0,696 02.06.2011 22 14 0,636
13.05.2011 19 17 0,895 20.05.2011 20 12 0,600 27.05.2011 19 15 0,789 03.06.2011 23 21 0,913
14.05.2011 19 14 0,737 21.05.2011 19 16 0,842 28.05.2011 19 13 0,684 04.06.2011 22 17 0,773
15.05.2011 19 16 0,842 22.05.2011 17 17 1,000 29.05.2011 17 16 0,941 05.06.2011 20 17 0,850
92
8.2 Publikation zur technischen Anbindung
Die Publikation "Stefan Kraus, Ixchel Castellanos, Dennis Toddenroth, Hans-Ulrich
Prokosch, Thomas Bürkle: Integrating Arden-Syntax-based clinical decision support with
extended presentation formats into a commercial patient data management system" ist in der
elektronischen Fassung dieser Dissertation aus Copyright-Gründen nicht enthalten. Sie ist
unter folgendem Link verfügbar:
http://link.springer.com/article/10.1007/s10877-013-9430-0
Auf PubMed ist die Publikation unter folgendem Link gelistet:
http://www.ncbi.nlm.nih.gov/pubmed/23354988
93
9 Danksagung
Ich möchte mich bei meinem Betreuer Thomas Bürkle bedanken. Zunächst einmal dafür,
dass Du mich mit dem Thema Arden-Syntax in Kontakt gebracht und mir die Promotion und
die Stelle als wissenschaftlicher Mitarbeiter angeboten hast, außerdem für Deine
Unterstützung vor allem bei der Konzeption der PCT-Studie und der schriftlichen
Ausarbeitung, und nicht zuletzt für Deine Geduld, wenn es mal wieder "a weng länger"
gedauert hat.
Bedanken möchte ich mich weiterhin bei Ixchel Castellanos, unserem klinischen
Hauptansprechpartner bei der Arden-Integration. Deine umfangreichen Erfahrungen in der
klinischen Routine haben mir viele Einsichten zu den praktischen Erfordernissen der
Implementierung gebracht, die ich bei der Programmierung am Schreibtisch wohl nie
gewonnen hätte.
"Last, but not least" möchte ich mich bei Steve Ralph bedanken für die Hilfe bei der
Übersetzung der Publikation und des Abstracts.
94
10 Literaturverzeichnis 1. Kurbel K. Entwicklung und Einsatz von Expertensystemen: eine anwendungsorientierte Einführung in
wissensbasierte Systeme: Springer Verlag; 1992.
2. Jaspers MWM, Smeulers M, Vermeulen H, Peute LW. Effects of clinical decision-support systems on practitioner performance and patient outcomes: a synthesis of high-quality systematic review findings. Journal of the American Medical Informatics Association. 2011;18(3):327.
3. Hunt DL, Haynes RB, Hanna SE, Smith K. Effects of computer-based clinical decision support systems on physician performance and patient outcomes. JAMA: the journal of the American Medical Association. 1998;280(15):1339-1346.
4. Garg AX, Adhikari NKJ, McDonald H, Rosas-Arellano MP, Devereaux P, Beyene J, Sam J, Haynes RB. Effects of computerized clinical decision support systems on practitioner performance and patient outcomes. JAMA. 2005;293(10):1223-1238.
5. Johnston ME, Langton KB, Haynes RB, Mathieu A. Effects of computer-based clinical decision support systems on clinician performance and patient outcome: a critical appraisal of research. Annals of Internal Medicine. 1994;120(2):135-142.
6. Randell R, Mitchell N, Dowding D, Cullum N, Thompson C. Effects of computerized decision support systems on nursing performance and patient outcomes: a systematic review. Journal of Health Services Research and Policy. 2007;12(4):242-251.
7. Mahoney CD, Berard-Collins CM, Coleman R, Amaral JF, Cotter CM. Effects of an integrated clinical information system on medication safety in a multi-hospital setting. American Journal of Health-System Pharmacy. 2007;64(18):1969.
8. Kuperman GJ, Bobb A, Payne TH, Avery AJ, Gandhi TK, Burns G, Classen DC, Bates DW. Medication-related clinical decision support in computerized provider order entry systems: a review. Journal of the American Medical Informatics Association. 2007;14(1):29-40.
9. Wolfstadt JI, Gurwitz JH, Field TS, Lee M, Kalkar S, Wu W, Rochon PA. The effect of computerized physician order entry with clinical decision support on the rates of adverse drug events: a systematic review. Journal of General Internal Medicine. 2008;23(4):451-458.
10. Jenders RA, Shah A. Challenges in using the Arden Syntax for computer-based nosocomial infection surveillance. Proc AMIA Symp. 2001:289-293.
11. Adlassnig KP, Blacky A, Koller W. Artificial-intelligence-based hospital-acquired infection control. Stud Health Technol Inform. 2009;149:103-110.
12. Chizzali-Bonfadin C, Adlassnig KP, Koller W. MONI: an intelligent database and monitoring system for surveillance of nosocomial infections. Medinfo. 1995;8 Pt 2:1684. Epub 1995/01/01.
13. Kane-Gill SL, Visweswaran S, Saul MI, Wong AKI, Penrod LE, Handler SM. Computerized detection of adverse drug reactions in the medical intensive care unit. Int J Med Inform. 2011;80(8):570.
14. Handler SM, Altman RL, Perera S, Hanlon JT, Studenski SA, Bost JE, Saul MI, Fridsma DB. A systematic review of the performance characteristics of clinical event monitor signals used to detect adverse drug events in the hospital setting. Journal of the American Medical Informatics Association. 2007;14(4):451-458.
15. Lellouche F, Mancebo J, Jolliet P, Roeseler J, Schortgen F, Dojat M, Cabello B, Bouadma L, Rodriguez P, Maggiore S, Reynaert M, Mersmann S, Brochard L. A multicenter randomized trial of computer-driven protocolized weaning from mechanical ventilation. American journal of respiratory and critical care medicine. 2006;174(8):894-900.
16. Mersmann S, Dojat M. SmartCare™-Automated Clinical Guidelines in Critical Care. 16th European Conference on Artificial Intelligence (ECAI 2004). 2004:745-749.
17. Wu S, Chaudhry B, Wang J, Maglione M, Mojica W, Roth E, Morton SC, Shekelle PG. Systematic review: impact of health information technology on quality, efficiency, and costs of medical care. Annals of Internal Medicine. 2006;144(10):742-752.
18. Pryor TA, Hripcsak G. The Arden syntax for medical logic modules. International Journal of Clinical Monitoring and Computing. 1993;10(4):215-224.
95
19. Hripcsak G. Writing Arden Syntax Medical Logic Modules. Comput Biol Med. 1994;24(5):331-363.
20. Hripcsak G, Ludemann P, Pryor TA, Wigertz OB, Clayton PD. Rationale for the Arden Syntax. Computers and Biomedical Research. 1994;27(4):291-324.
21. Kraus S. Integration wissensbasierter Funktionen in ein kommerzielles PDMS [Diplomarbeit]. Erlangen: Universität Erlangen-Nürnberg; 2008.
22. Sojer R. Transformation des Arzneimittelsicherheitsystems KLASSE in eine standardisierte Wissensrepräsentation [Dissertation]: Universität Erlangen-Nürnberg; 2008.
23. Sojer R, Bürkle T, Criegee-Rieck M, Neubert A, Brune K, Prokosch HU. Knowledge Modelling and Knowledge Representation in Hospital Information Systems to Improve Drug Safety. The Journal on Information Technology in Healthcare. 2006:29.
24. Hripcsak G, Clayton PD, Jenders RA, Cimino JJ, Johnson SB. Design of a clinical event monitor. Computers and Biomedical Research. 1996;29(3):194-221.
25. Fretschner R, Bleicher W, Heininger A, Unertl K. Patient data management systems in critical care. Journal of the American Society of Nephrology. 2001;12(suppl 1):S83-S86.
26. Gocke P, Debatin JF, Baehr M. IT im Krankenhaus: Von der Theorie in die Umsetzung. Berlin: MWV Medizinisch Wiss. Verl.-ges.; 2011.
27. Prokosch HU. KAS, KIS, EKA, EPA, EGA, E-Health:--Ein Pladoyer gegen die babylonische Begriffsverwirrung in der Medizinischen Informatik. Informatik Biometrie und Epidemiologie in Medizin und Biologie. 2001;32(4):371-382.
28. Castellanos I, Bürkle T, Prokosch H, Schüttler J. Konzept zur flächendeckenden Einführung eines Patientendatenmanagementsystems am Großklinikum – eine interdisziplinäre Herausforderung. Anästh Intensivmed. 2009(50):618-629.
29. Burkle T, Castellanos I, Tech H, Prokosch HU. Implementation of a patient data management system - an evaluation study of workflow alterations. Stud Health Technol Inform. 2010;160(Pt 2):1256-1260.
30. Castellanos IB, T. Chancen und Risiken für Qualitätsmanagement (QM) und Patientensicherheit durch ein Patientendatenmanagementsystem (PDMS). Forum der Medizin-Dokumentation und Medizin-Informatik. 2009;3:131-136.
31. Tech H. Longitudinale Evaluation der Einführung eines Patientendatenmanagement-System auf der Interdisziplinären-Operativen-Intensivstation des Klinikums der Universität Erlangen [Dissertation]: Universität Erlangen-Nürnberg; 2009.
32. Prause A. EDV im rauhen Alltag der Intensivstation. Erfahrungsbericht über die Einführung des „Intensive Care Manager “(ICM, Dräger Medical, Lübeck). Anaesthesiol Intensivmed Notfallmed Schmerzther. 2002;37(8):483-487.
33. Prokosch H. Ein Referenzmodell für den Einsatz wissensbasierter und wissensverarbeitender Funktionen innerhalb eines Krankenhaus-Informationssystems [Habilitationsschrift]: Justus-Liebig-Universität Gießen; 1994.
34. Wright A, Sittig DF, Ash JS, Sharma S, Pang JE, Middleton B. Clinical decision support capabilities of commercially-available clinical information systems. Journal of the American Medical Informatics Association. 2009;16(5):637.
35. Shortliffe EH. Computer programs to support clinical decision making. JAMA: the journal of the American Medical Association. 1987;258(1):61-66.
36. Waterman DA. A guide to expert systems. Reading, Mass. [u.a.]: Addison-Wesley; 1986. XVIII, 419 S p.
37. Puppe F. Einführung in Expertensysteme. 2. Aufl ed. Berlin [u.a.]: Springer; 1991.
38. Coppin B. Artificial intelligence illuminated: Jones & Bartlett Learning; 2004.
39. Dreiseitl S, Binder M. Do physicians value decision support? A look at the effect of decision support systems on physician opinion. Artif Intell Med. 2005;33(1):25-30.
96
40. Clayton PD, Pryor TA, Wigertz OB, Hripcsak G. Issues and structures for sharing medical knowledge among decision-making systems: the 1989 Arden Homestead Retreat. Proc Annu Symp Comput Appl Med Care. 1989:116-121.
41. Haun M. Wissensbasierte Systeme.: Eine praxisorientierte Einführung: expert verlag; 2000.
42. Olson JR, Rueter HH. Extracting expertise from experts: Methods for knowledge acquisition. Expert systems. 1987;4(3):152-168.
43. Sonntag D, Wennerberg P, Buitelaar P, Zillner S. Pillars of ontology treatment in the medical domain. Journal of Cases on Information Technology (JCIT). 2009;11(4):47-73.
44. Nadkarni PM. Metadata-driven Software Systems in Biomedicine Designing Systems that can adapt to Changing Knowledge. London: Springer-Verlag London Limited; 2011.
45. Evans RS, Classen DC, Pestotnik SL, Clemmer TP, Weaver LK, Burke JP. A decision support tool for antibiotic therapy. Proc Annu Symp Comput Appl Med Care. 1995:651-655.
46. Evans RS, Pestotnik SL, Classen DC, Clemmer TP, Weaver LK, Orme Jr JF, Lloyd JF, Burke JP. A computer-assisted management program for antibiotics and other antiinfective agents. New England Journal of Medicine. 1998;338(4):232-238.
47. Evans RS, Pestotnik SL, Classen DC, Horn SD, Bass SB, Burke JP. Preventing adverse drug events in hospitalized patients. Annals of Pharmacotherapy. 1994;28(4):523-527.
48. Lin CP, Payne TH, Nichol WP, Hoey PJ, Anderson CL, Gennari JH. Evaluating clinical decision support systems: monitoring CPOE order check override rates in the Department of Veterans Affairs' Computerized Patient Record System. Journal of the American Medical Informatics Association. 2008;15(5):620-626.
49. Weingart SN, Toth M, Sands DZ, Aronson MD, Davis RB, Phillips RS. Physicians' decisions to override computerized drug alerts in primary care. Archives of Internal Medicine. 2003;163(21):2625.
50. Isaac T, Weissman JS, Davis RB, Massagli M, Cyrulik A, Sands DZ, Weingart SN. Overrides of medication alerts in ambulatory care. Archives of Internal Medicine. 2009;169(3):305.
51. Van Der Sijs H, Aarts J, Vulto A, Berg M. Overriding of drug safety alerts in computerized physician order entry. Journal of the American Medical Informatics Association. 2006;13(2):138-147.
52. van der Sijs H, Mulder A, van Gelder T, Aarts J, Berg M, Vulto A. Drug safety alert generation and overriding in a large Dutch university medical centre. Pharmacoepidemiology and drug safety. 2009;18(10):941-947.
53. Sijs IH. Drug safety alerting in computerized physician order entry: Unraveling and counteracting alert fatigue: Erasmus University Rotterdam; 2009.
54. Pryor TA, Gardner RM, Clayton PD, Warner HR. The HELP system. Journal of Medical Systems. 1983;7(2):87-102.
55. McDonald CJ, Blevins L, Tierney WM, Martin DK. The Regenstrief medical records. MD Computing. 1988;5(5):34-47.
56. Samwald M, Fehre K, de Bruin J, Adlassnig KP. The Arden Syntax standard for clinical decision support: experiences and directions. Journal of biomedical informatics. 2012;45(4):711-718.
57. Vetterlein T, Mandl H, Adlassnig KP. Processing gradual information with Fuzzy Arden syntax. Stud Health Technol Inform. 2010;160(Pt 2):831-835.
58. Vetterlein T, Mandl H, Adlassnig KP. Fuzzy Arden Syntax: A fuzzy programming language for medicine. Artif Intell Med. 2010;49(1):1-10.
59. Tiffe S. FuzzyARDEN: Representation and Interpretation of Vague Medical Knowledge by Fuzzified Arden Syntax [Dissertation]: Technische Universität Wien; 2003.
60. Greenes RA. Clinical decision support: the road ahead: Academic Press; 2007.
61. Kim S, Haug PJ, Rocha RA, Choi I. Modeling the Arden Syntax for medical decisions in XML. Int J Med Inform. 2008;77(10):650-656.
97
62. Gietzelt M, Goltz U, Grunwald D, Lochau M, Marschollek M, Song B, Wolf KH. ARDEN2BYTECODE: a one-pass Arden Syntax compiler for service-oriented decision support systems based on the OSGi platform. Comput Methods Programs Biomed. 2012;106(2):114-125.
63. Karadimas HC, Chailloleau C, Hemery F, Simonnet J, Lepage E. Arden/J: an architecture for MLM execution on the Java platform. Journal of the American Medical Informatics Association. 2002;9(4):359-368.
64. Fehre K, Mandl H, Adlassnig KP. Service-Oriented, Arden-Syntax-Based Clinical Decision Support. Proceedings of eHealth2011. 2011:123-128.
65. Carroll AE, Biondich P, Anand V, Dugan TM, Downs SM. A randomized controlled trial of screening for maternal depression with a clinical decision support system. Journal of the American Medical Informatics Association : JAMIA. 2013;20(2):311-316.
66. Kuhn RA, Reider RS. A C++ framework for developing Medical Logic Modules and an Arden Syntax compiler. Computers in Biology and Medicine. 1994;24(5):365-370.
67. Gao X, Johansson B, Shahsavar N, Arkad K, Åhlfeldt H, Wigertz O. Pre-compiling medical logic modules into C++ in building medical decision support systems. Comput Methods Programs Biomed. 1993;41(2):107-119.
68. Johansson BG, Wigertz OB. An object oriented approach to interpret medical knowledge based on the Arden syntax. Proc Annu Symp Comput Appl Med Care. 1992:52-56.
69. McCauley B, Young I, Clark I, Peters M. Incorporation of the Arden Syntax within the reimplementation of a closed-loop decision support system. Computers and Biomedical Research. 1996;29(6):507-518.
70. Tafazzoli AG. Klinisch einsetzbare wissensverarbeitende Funktionen in einem onkologischen Informationssystem [Dissertation]: Justus-Liebig-Universität Giessen; 1999.
71. Liang YC, Chang P. The development of variable MLM editor and TSQL translator based on Arden Syntax in Taiwan. AMIA Annu Symp Proc. 2003:908.
72. Jenders RA, Corman R, Dasgupta B. Making the standard more standard: a data and query model for knowledge representation in the Arden syntax. AMIA Annu Symp Proc. 2003:323-330.
73. V2.5-2005 AHA. Health Level Seven Arden Syntax, Version 2.5 (revision of ANSI/HL7 Arden V2.1-2002). 2005.
74. Nadkarni PM. Data Extraction and Ad Hoc Query of an Entity—Attribute—Value Database. Journal of the American Medical Informatics Association. 1998;5(6):511-527.
75. Nadkarni PM, Marenco L, Chen R, Skoufos E, Shepherd G, Miller P. Organization of heterogeneous scientific data using the EAV/CR representation. Journal of the American Medical Informatics Association. 1999;6(6):478-493.
76. Nadkarni PM. Clinical patient record systems architecture: an overview. Journal of Postgraduate Medicine. 2000;46(3):199.
77. Weigand M, Bardenheuer H, Böttiger B. Klinisches Management bei Patienten mit Sepsis. Der Anaesthesist. 2003;52(1):3-22.
78. Bone RC, Balk RA, Cerra FB, Dellinger RP, Fein AM, Knaus WA, Schein RM, Sibbald WJ. Definitions for sepsis and organ failure and guidelines for the use of innovative therapies in sepsis. The ACCP/SCCM Consensus Conference Committee. American College of Chest Physicians/Society of Critical Care Medicine. 1992. Chest. 2009;136(5 Suppl):e28.
79. Reinhart K, Brunkhorst F, Bone HG, Gerlach H, Gründling M, Kreymann G, Kujath P, Marggraf G, Mayer K, Meier-Hellmann A. Diagnose und Therapie der Sepsis. Clinical Research in Cardiology. 2006;95(8):429-454.
80. Moerer O, Burchardi H. Kosten der Sepsis. Der Anaesthesist. 2006;55:36-42.
81. Kumar A, Roberts D, Wood KE, Light B, Parrillo JE, Sharma S, Suppes R, Feinstein D, Zanotti S, Taiberg L. Duration of hypotension before initiation of effective antimicrobial therapy is the critical determinant of survival in human septic shock*. Critical Care Medicine. 2006;34(6):1589.
82. Reinhart K, Meisner M. Biomarkers in the critically ill patient: procalcitonin. Critical Care Clinics. 2011;27(2):253-263.
98
83. Standage SW, Wong HR. Biomarkers for pediatric sepsis and septic shock. Expert review of anti-infective therapy. 2011;9(1):71-79.
84. Karzai W, Oberhoffer M, Meier-Hellmann A, Reinhart K. Procalcitonin—a new indicator of the systemic response to severe infections. Infection. 1997;25(6):329-334.
85. BalcI C, Sungurtekin H, Gurses E, Sungurtekin U, Kaptanoglu B. Usefulness of procalcitonin for diagnosis of sepsis in the intensive care unit. CRITICAL CARE-LONDON-. 2003;7(1):85-89.
86. Nijsten MWN, Olinga P, de Vries EGE, Koops HS, Groothuis GMM, Limburg PC, ten Duis HJ, Moshage H, Hoekstra HJ, Bijzet J. Procalcitonin behaves as a fast responding acute phase protein in vivo and in vitro. Critical Care Medicine. 2000;28(2):458.
87. HARBARTH S, HOLECKOVA K, FROIDEVAUX C, Pittet D, RICOU B, GRAU GE, VADAS L, Pugin J. Diagnostic value of procalcitonin, interleukin-6, and interleukin-8 in critically ill patients admitted with suspected sepsis. American journal of respiratory and critical care medicine. 2001;164(3):396.
88. Cheng H. The usefulness of procalcitonin as a marker of bacterial infection in the clinical setting: a retrospective review of patients with prolonged fever or leucocytosis in a public hospital. 2010.
89. Wilhelm W. Praxis der Intensivmedizin: konkret, kompakt, interdisziplinär. Berlin: Springer; 2011.
90. Gendrel D, Bohuon C. Procalcitonin, a marker of bacterial infection. Infection. 1997;25(3):133-134.
91. Koeze J, Hendrix MGR, van den Bergh FA, Brouwer RML, Zijlstra JG. In critically ill patients the procalcitonin level can be misleading. Critical Care. 2011;15(2):1-2.
92. Lichtenstern C, Brenner T, Bardenheuer HJ, Weigand MA. Predictors of survival in sepsis: what is the best inflammatory marker to measure? Current opinion in infectious diseases. 2012;25(3):328.
93. Nobre V, Harbarth S, Graf J, Rohner P, Pugin J. Use of procalcitonin to shorten antibiotic treatment duration in septic patients: a randomized trial. American journal of respiratory and critical care medicine. 2008;177(5):498-505.
94. Altman DG. Practical Statistics For Medical Research. London: Chapman and Hall; 1991.
95. Kraus S, Castellanos I, Toddenroth D, Prokosch HU, Burkle T. Integrating Arden-Syntax-based clinical decision support with extended presentation formats into a commercial patient data management system. Journal of clinical monitoring and computing. 2013. Epub 2013/01/29.
96. Wentz B, Kraska D, Seggewies C, Bell R, Seibold H. The Erlangen university hospital communication hub--proprietary and standardised communication. Stud Health Technol Inform. 1998;52:995.
97. Arkad K, Gao XM, Åhlfeldt H. Query-handling in MLM-based decision support systems. Informatics for Health and Social Care. 1995;20(3):229-240.
98. Johansson B, Shahsavar N, Åhlfeldt H, Wigertz O. Database and knowledge base integration-a data mapping method for Arden Syntax knowledge modules. Methods Inf Med. 1996;35:302-308.
99. Musen MA, Shahar Y, Shortliffe EH. Clinical decision-support systems. Biomedical Informatics. 2006:698-736.
100. Shortliffe EH, Davis R, Axline SG, Buchanan BG, Green CC, Cohen SN. Computer-based consultations in clinical therapeutics: explanation and rule acquisition capabilities of the MYCIN system. Computers and Biomedical Research. 1975;8(4):303-320.
101. Miller RA, Pople HE, Jr., Myers JD. Internist-1, an experimental computer-based diagnostic consultant for general internal medicine. New England Journal of Medicine. 1982;307(8):468-476.
102. Miller R, Masarie FE, Myers JD. Quick medical reference (QMR) for diagnostic assistance. MD Computing. 1986;3(5):34-48.
103. Pryor TA. The HELP medical record system. MD Computing. 1988;5(5):22-33.
104. Hripcsak G, Cimino JJ, Johnson SB, Clayton PD. The Columbia-Presbyterian Medical Center decision-support system as a model for implementing the Arden Syntax. Proc Annu Symp Comput Appl Med Care. 1991:248-252.
99
105. Haug PJ, Gardner RM, Tate KE, Evans RS, East TD, Kuperman G, Pryor TA, Huff SM, Warner HR. Decision support in medicine: examples from the HELP system. Computers and Biomedical Research. 1994;27(5):396-418.
106. Johansson B, Bergqvist Y. Integrating decision support, based on the Arden Syntax, in a clinical laboratory environment. Proc Annu Symp Comput Appl Med Care. 1993:394-398.
107. Tafazzoli AG, Altmann U, Wachter W, Katz FR, Holzer S, Dudeck J. Integrated knowledge-based functions in a hospital cancer registry--specific requirements for routine applicability. Proc AMIA Symp. 1999:410-414.
108. Fehre K, Adlassnig KP. Rule-Engine-Technologie als Innovationspotential für Telemedizin. Tagungsband der TELEMED 2010: Telemedizin – Erfolgsmodell für moderne Patientenversorgung. 2010:64-69.
109. Arkad K, Ahlfeldt H, Gao X, Shahsavar N, Wigertz O, Jean FC, Degoulet P. Integration of data driven decision support into the HELIOS environment. Int J Biomed Comput. 1994;34(1):195-205.
110. Jenders RA, Dasgupta B. Assessment of a knowledge-acquisition tool for writing Medical Logic Modules in the Arden Syntax. Proc AMIA Annu Fall Symp. 1996:567-571.
111. Jenders RA, Sujansky W, Broverman CA, Chadwick M. Towards improved knowledge sharing: assessment of the HL7 Reference Information Model to support medical logic module queries. Proc AMIA Annu Fall Symp. 1997:308-312.
112. Prokosch H, Kamm S, Wieczorek D, Dudeck J. Knowledge representation in pharmacology. A possible application area for the Arden Syntax? Proc Annu Symp Comput Appl Med Care. 1991:243-247.
113. Jenders RA, Dasgupta B. Challenges in implementing a knowledge editor for the Arden Syntax: knowledge base maintenance and standardization of database linkages. Proc AMIA Symp. 2002:355-359.
114. Hripcsak G, Johnson SB, Clayton PD. Desperately seeking data: knowledge base-database links. Proc Annu Symp Comput Appl Med Care. 1993:639-643.
115. Zikarsky B. Kommunikation zwischen einer Arden-Engine und einem PDMS [Bachelorarbeit]. Erlangen: Universität Erlangen-Nürnberg; 2012.
116. Wright A, Sittig DF. SANDS: a service-oriented architecture for clinical decision support in a National Health Information Network. J Biomed Inform. 2008;41(6):962-981.
117. Müller ML, Ganslandt T, Eich HP, Lang K, Ohmann C, Prokosch HU. Towards integration of clinical decision support in commercial hospital information systems using distributed, reusable software and knowledge components. Int J Med Inform. 2001;64(2-3):369-377.
118. Karlsson D, Ekdahl C, Wigertz O, Shahsaver N, Gill H, Forsum U. Extended telemedical consultation using Arden Syntax based decision support, hypertext and WWW technique. Methods Inf Med. 1997;36(2):108-114.
119. Bates DW, Kuperman GJ, Wang S, Gandhi T, Kittler A, Volk L, Spurr C, Khorasani R, Tanasijevic M, Middleton B. Ten commandments for effective clinical decision support: making the practice of evidence-based medicine a reality. Journal of the American Medical Informatics Association. 2003;10(6):523-530.
120. Catrou PG. Is that lab test necessary? American Journal of Clinical Pathology. 2006;126(3):335-336.
121. May TA, Clancy M, Critchfield J, Ebeling F, Enriquez A, Gallagher C, Genevro J, Kloo J, Lewis P, Smith R. Reducing unnecessary inpatient laboratory testing in a teaching hospital. American Journal of Clinical Pathology. 2006;126(2):200-206.
122. Van Walraven C, Naylor CD. Do we know what inappropriate laboratory utilization is? Journal of the American Medical Association. 1998;280(6):550-558.
123. Janssens PM. Managing the demand for laboratory testing: options and opportunities. Clinica chimica acta; international journal of clinical chemistry. 2010;411(21-22):1596-1602.
124. Roshanov PS, Misra S, Gerstein HC, Garg AX, Sebaldt RJ, Mackay JA, Weise-Kelly L, Navarro T, Wilczynski NL, Haynes RB. Computerized clinical decision support systems for chronic disease management: A decision-maker-researcher partnership systematic review. Implement Sci. 2011;6(1):92.
125. Eisenberg JM, Williams SV, Garner L, Viale R, Smits H. Computer-based audit to detect and correct overutilization of laboratory tests. Medical Care. 1977:915-921.
100
126. Bates DW, Kuperman GJ, Rittenberg E, Teich JM, Fiskio J, Ma'Luf N, Onderdonk A, Wybenga D, Winkelman J, Brennan TA. A randomized trial of a computer-based intervention to reduce utilization of redundant laboratory tests. The American journal of medicine. 1999;106(2):144.
127. Stuebing EA, Miner TJ. Surgical vampires and rising health care expenditure: reducing the cost of daily phlebotomy. Arch Surg. 2011;146(5):524-527.
128. Baron JM, Dighe AS. Computerized provider order entry in the clinical laboratory. Journal of pathology informatics. 2011;2:35.
129. Tierney WM, Miller ME, McDonald CJ. The effect on test ordering of informing physicians of the charges for outpatient diagnostic tests. New England Journal of Medicine. 1990;322(21):1499-1504.
130. Windeler J, Antes G, Behrens J, Donner-Banzhoff N, Lelgemann M. Randomisierte klinische Studien (RCTF). Zeitschrift für Evidenz, Fortbildung und Qualität im Gesundheitswesen. 2008;102(5):321-325.
131. Oppenheim MI, Mintz RJ, Boyer AG, Frayer WW. Design of a clinical alert system to facilitate development, testing, maintenance, and user-specific notification. Proc AMIA Symp. 2000:630-634.
132. Sailors RM, Bradshaw RL, East TD. Moving Arden Syntax Outside of the (Alert) Box: A Paradigm for Supporting Multi-Step Clinical Protocols. Proc Amia Symp. 1998:1071.
133. Sherman EH, Hripcsak G, Starren J, Jenders RA, Clayton P. Using intermediate states to improve the ability of the Arden Syntax to implement care plans and reuse knowledge. Proc Annu Symp Comput Appl Med Care. 1995:238-242.
134. Starren J, Hripcsak G, Jordan D, Allen B, Weissman C, Clayton P. Encoding a post-operative coronary artery bypass surgery care plan in the Arden Syntax. Comput Biol Med. 1994;24(5):411-417.
135. Adlassnig KP, Horak W, Rappelsberger A, Hayashi Y, editors. Embedded knowledge-based diagnostic intelligence to interpret hepatitis serology test results. 2005: IEEE.
136. Rudigier S, Brenner R, Adlassnig KP. Expert-System-Based Interpretation of Hepatitis Serology Test Results as App Store iPhone Application. Tagungsband der eHealth2010, Österreichische Computer Gesellschaft, Wien; 2010.
137. Song B, Wolf KH, Gietzelt M, Al Scharaa O, Tegtbur U, Haux R, Marschollek M. Decision support for teletraining of COPD patients. Methods Inf Med. 2010;49(1):96-102.
138. Wright A, Sittig DF. A four-phase model of the evolution of clinical decision support architectures. Int J Med Inform. 2008;77(10):641-649.
139. Peleg M, Boxwala AA, Bernstam E, Tu S, Greenes RA, Shortliffe EH. Sharable representation of clinical guidelines in GLIF: relationship to the Arden Syntax. J Biomed Inform. 2001;34(3):170-181.
140. Peleg M, Ogunyemi O, Tu S, Boxwala AA, Zeng Q, Greenes RA, Shortliffe EH. Using features of Arden Syntax with object-oriented medical data models for guideline modeling. Proc Amia Symp. 2001:523-527.
141. Shwe M, Sujansky W, Middleton B. Reuse of knowledge represented in the Arden syntax. Proc Annu Symp Comput Appl Med Care. 1992:47-51.
142. Adlassnig K, Rappelsberger A. Medical knowledge packages and their integration into health-care information systems and the World Wide Web. Stud Health Technol Inform. 2008;136:121.
143. Kaiser JG, U.M.; Reng, M.; Prokosch, H.U.;Bürkle, T. Risiken und Nebenwirkungen der Integration medizinischer Software in klinische IT-Strukturen – Erlanger Memorandum. GMS Med Inform Biom Epidemiol. 2012;8(1):Doc03.
144. Pohl B, Mix D, Beringer L, Beringen C, Trendelenburg C. Integration von wissensbasierten Pro. MD-Systemen in den medizinischen Befundungsprozeß. LaboratoriumsMedizin/Journal of Laboratory Medicine. 2009;21(5):259-266.
145. Musen M, Tu S, Das A, Shahar Y. A component-based architecture for automation of protocol-directed therapy. Artif Intell Med. 1995:1-13.
146. Arkad K, Gill H, Ludwigs U, Shahsavar N, Gao XM, Wigertz O. Medical logic module (MLM) representation of knowledge in a ventilator treatment advisory system. Int J Clin Monit Comput. 1991;8(1):43-48.
