Wissensbasierte Systeme zur Unterstützung der Therapie auf Intensivstationen

Transkript

1 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

2 Als Dissertation genehmigt von der Medizinischen Fakultät der Friedrich-Alexander-Universität Erlangen-Nürnberg Tag der mündlichen Prüfung: 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

3 MEINEM VATER 2013

4 Inhaltsverzeichnis 1 Einleitung Grundlagen ICM und seine Exportschnittstelle AutoExport Wissensbasierte Systeme Die Arden Syntax for Medical Logic Systems Medical Logic Modules Datentypen der Arden-Syntax Das EAV-Datenmodell Die Ergebnisse der Diplomarbeit Procalcitonin als Sepsismarker Methoden Bereitstellung der technischen Plattform Methoden der Analysephase Methoden der Implementierungsphase Datenbereitstellung und Ereigniserkennung Implementierung des Arden-Servers Präsentationsmechanismen Methoden der Evaluierungsphase Die Vorstudie Die PCT-Studie Ergebnisse Ergebnisse der technischen Bereitstellung Ergebnisse der Analysephase Ergebnisse der Implementierungsphase Datenbereitstellung und Ereigniserkennung Bereitstellung des Arden-Servers Präsentationsmechanismen Ergebnisse der PCT-Studie Die Vorstudie Die PCT-Studie Zusammenfassung der Ergebnisse Diskussion Implementierungsphase Datenbereitstellung und Ereigniserkennung Arden-Server Präsentationsmechanismen Diskussion der Evaluierungsphase Erfahrungen mit der Arden-Syntax... 79

5 6 Ausblick Abkürzungsverzeichnis Anhang PCT-Raten der Studienphasen Publikation zur technischen Anbindung Danksagung Literaturverzeichnis... 94

6 Abbildungsverzeichnis Abbildung 1: Screenshot der ICM-Tageskurve... 8 Abbildung 2: Grundprinzip von AutoExport... 9 Abbildung 3: Die Funktionsweise von Schlüsselworttermen Abbildung 4: Typische Architektur eines medizinischen Expertensystems Abbildung 5: Aufbau eines MLMs Abbildung 6: Gundprinzip der Verarbeitung eines MLMs Abbildung 7: Grundprinzip einer Arden-Engine Abbildung 8: Vergleich der konventionellen Modellierung mit dem EAV-Modell Abbildung 9: Architektur des in der Diplomarbeit erstellten Systems Abbildung 10: Ansatz zur Erkennung von datengesteuerten Ereignissen Abbildung 11: Herstellung der Mandantenfähigkeit Abbildung 12: Prinzip der Generierung von Tabellen Abbildung 13: Phasen der PCT-Studie Abbildung 14: Ausschnitt aus der Vorschlagsliste Abbildung 15: Architektur des Zielsystems Abbildung 16: Ersetzungsmechanismus bei Curly-Braces-Methoden Abbildung 17: Integration über ArdenHostInterface Abbildung 18: Bereitstellung der MiBi-Daten Abbildung 19: Grundprinzip des Aliaskonzeptes Abbildung 20: Beispiel einer per MLM generierten SMS-Nachricht Abbildung 21: Screenshot des MLM-Viewers Abbildung 22: Beispiel für einfache Tabellengenerierung Abbildung 23: Beispiel für Generierung von Lineplots Abbildung 24: Die Bereiche der IOI Abbildung 25: Sonderlaboranforderung für einen Patienten der IOI Abbildung 26: Häufige Verlaufsform des PCT-Spiegels Abbildung 27: Aggregierte Daten der Studienphasen Abbildung 28: Boxplots der PCT-Raten der Studienphasen Abbildung 29: Nutzung des PCT-MLMs nach Tagen Abbildung 30: Vergleich der ON-Phasen bzgl. Neuaufnahmen, SAPS II und APACHE II Abbildung 31: Beispiel eines MLMs für DRG-Coder... 83

7 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. 1

8 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 datadriven 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. 2

9 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 Entscheidungsfindung 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 Patientendatenmanagementsystem (PDMS) "Integrated Care Manager" (ICM) der Firma Dräger Medical 3

10 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: 4

11 Z1: Implementierung einer vollwertigen technischen Plattform für die Ausführung von Arden-Syntax MLMs in ICM mit Mechanismen für Datenzugriff und Ereignisbenachrichtigung unter Verwendung der Arden-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 Implementierungsschritten doch immer die möglichst einfache Benutzbarkeit angestrebt werden 1. 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. 5

12 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? 6

13 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 7

14 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 Mandanten 2 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 aktuelle 3 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. 8

15 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 steuert Target Text und Schlüsselwortterme Eingabe Schlüsselwortparser Ausgabe Freitext (z.b. Arztbrief), CSV, HTML, XML 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 Daten 5 ORDERS Daten der Tageskurve SYSTEM Systeminformationen, z.b. der angemeldete User CODES ICD 6 - und OPS 7 -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 9

16 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üssen 8. 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. Template Patname = [D:Patname, Patvorname] Username = [System:Username] Leukozyten = [Orders: TreatmentName=Leukozyten; Range=all; Records=all; Format=!(({CT_Sample} am {AdminDate}, )\BKSP\BKSP)] Target Patname = Mustermann, Max Username = doejn Leukozyten = am :38, am :00, am :13, am :00 Abbildung 3: Die Funktionsweise von Schlüsselworttermen 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. 10

17 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 sind 9 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. 11

18 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äsentationsformates. 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-Regeln 10 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 Schlussfolgerungsfähigkeit qualifizierter Fachleute auf eng begrenzten Aufgabengebieten nachgebildet werden soll. [37]" Expertensystem-Shell Benutzer Benutzerschnittstelle Erklärungskomponente Inferenzmaschine Wissenseditor Wissensbasis Faktenbasis Abbildung 4: Typische Architektur eines medizinischen 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. 12

19 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 13

20 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 socalled '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 Fallzahlen 11. 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. 14

21 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 verglichen 13. 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 PAST 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. 15

22 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 schreiben 14. 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-Braces 15 -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 adresse als Kommunikationsendpunkt (Mapping von Arden-Syntax-Datentypen auf das - Nachrichtenformat): LET glucose_values BE READ {Parameter=Glucose, CaseID=4711}; LET _study_nurse BE DESTINATION { jane.doe@institution.org}; 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 16

23 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] 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 TITLE MLMNAME ARDEN VERSION INSTITUTION AUTHOR SPECIALIST DATE VALIDATION LIBRARY PURPOSE EXPLANATION KEYWORDS CITATIONS LINKS KNOWLEDGE TYPE DATA PRIORITY EVOKE LOGIC ACTION URGENCY 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. 17

24 EVOKE: Definiert das Ereignis 17, 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: MLM beenden false EVENT Bezug erforderlicher Daten Treffen einer klinischen Entscheidung conclude true Ausführen von Aktionen Abbildung 6: Gundprinzip der Verarbeitung eines MLMs 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 erforderlich 18. 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. 18

25 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 ist 19. 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. Arden Engine EVENT MLM MLM MLM MLMMLM MLM MLM Data-Slot Logic-Slot read { } DB Knowledge Base Action-Slot Message 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 19

26 Personal ermöglichen. Auch die Speicherung von per MLM generiertem Mehrwert in der Patientenakte ist sinnvoll 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 flachgeklopft 20. 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. 20

27 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-Score 21 eines Patienten. Es benötigt drei Eingabeparameter: Einen Bilirubin-, einen Serumkreatinin- und einen INR-Wert 22. Die Übergabe der Parameter erfolgt unter Nutzung von Listen folgendermaßen: Parameterübergabe im aufrufenden MLM: LET meldscore BE CALL calculate_meldscore WITH bilirubin, 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. 21

28 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. 22

29 fall kalium kalium_zeitstempel glucose glucose_zeitstempel :00: :00: :00: :00:00 fall attribut wert zeitstempel 4711 kalium :00: glucose :00: kalium :00: glucose :00:00 Abbildung 8: Vergleich der konventionellen Modellierung 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 23

30 <Eventname> <Eventname>.jcf template.txt execute.bat ICM Targetkonverter Event- Handler MLM- Evoker 1 Target AutoExport PatDB 3 2 ProxyDB Arden Engine D 4 read {...} C EventDB Web-Anwendung E A 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. Event- Definition MLM B Abbildung 9: Architektur des in der Diplomarbeit erstellten 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 24

31 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]" 25

32 "Nach neuesten Erhebungen des vom BMBF geförderten Kompetenznetzwerkes Sepsis (SepNet) erkranken in Deutschland pro Jahr Einwohner (110 von ) an einer schweren Sepsis bzw. septischem Schock und (116 von ) an einer Sepsis. Mit ca 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 Patienten an einer schweren Sepsis; in den USA sind es bis zu 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 26

33 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 interindividual 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. 27

34 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 Konzeptionsund 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 28

35 Kommunikationsendpunkte sowie Präsentationsmechanismen implementiert. Das resultierende System soll als ICM-Arden bezeichnet werden 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 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 IDE 23 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). 29

36 vom MLM aus per SQL ausgeführt werden konnte. Für den zentralen Analysevorgang des ArdenHostInterfaces wurde ein Projekt in Eclipse 24 angelegt und die Arden-Engine als externe Bibliothek eingebunden 25. 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 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) 30

37 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-Insert 26, wobei diese Schritte als Transaktion gekapselt sind. t n-1 t n t n+1 Zeit Wert Zeitstempel Wert Zeitstempel Wert Zeitstempel : : : : : : : : : :22 Alle Werte in Export t n waren bereits im Export t n-1 enthalten kein Ereignis eingetreten Export t n+1 enthält einen Wert, der in Export t n nicht enthalten war Ereignis eingetreten Abbildung 10: Ansatz zur Erkennung von datengesteuerten 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', ' :00:00'); insert into eav_table values ('4711', 'glucose', '128', ' :00:00'); insert into eav_table values ('4711', 'glucose', '144', ' :00:00'); So kann man diese zu einem einzigen Bulk-Insert zuammenfassen: insert into eav_table values ('4711', 'glucose', '126', ' :00:00'), ('4711', 'glucose', '128', ' :00:00'), ('4711', 'glucose', '144', ' :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. 31

38 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-VM Mandant 1 Export- Job Export- Handler Export-VM Mandant 2 Export- Job Export- Handler Export-VM Mandant n Export- Job Export- Handler Ereignismeldungen (SOAP) Aktualisierung (SQL) Arden- Server Datenzugriff (SQL) ProxyDB 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 identifiziert 27 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. 32

39 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 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 (WSAS 28 von WSO2) integriert. Dieser wurde wegen seiner komfortablen Administrierbarkeit ausgewählt. Er bietet beispielsweise die Möglichkeit, POJO-Klassen 29 per Mausklick als Web-Services bereitzustellen, wobei die SOAP-Schnittstelle und die WSDL 30 -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 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 33

40 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 adressen. Hierfür wurde die JavaMail 31 -API in das ArdenHostInterface eingebunden. Als format wurde text/html gewählt, um die HTML- und JavaScriptbasierten Präsentationsmechanismen (siehe unten) auch in s 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 s 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 Präsentationsmechanismen Die Implementierung des MLM-Viewers erfolgte in der Skriptsprache AutoIT 32 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 Ein Wrapper für die native Windows-API, siehe 34

41 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). 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 LET table BE CALL ListToTable WITH critical_calcium_values; String table enthält HTML-Code <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 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 35

42 Beschreibungsobjektes werden auf HTML-Elemente abgebildet und zu einer Tabelle zusammengesetzt. Skalierbare Grafiken mit Highlighting (Lineplots) Lineplots wurden unter Verwendung der freien JavaScript-Bibliothek Flot 33 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

43 erfassten Daten. Alle Auswertungen wurden unter Nutzung eines Standardwerkes der medizinischen Statistik durchgeführt [94] 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üssen 34. 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 R 35. 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

44 Messungen wurden versäumt. Diese Versäumnisse wurden durch eine Analyse der Zeitabstände quantitativ abgeschätzt 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 38

45 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 OFF1 1. Ausschalten des PCT-MLMs ON2 2. Einschalten des PCT-MLMs OFF2 2. Ausschalten des PCT-MLMs POST 4-Wochen-Zeitraum nach Studienende 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. 39