Wissensbasierte Systeme zur Unterstützung der Therapie auf Intensivstationen

Größe: px
Ab Seite anzeigen:

Download "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 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

Patientenübergreifende Entscheidungsunterstützung durch grafische Dashboards als Anwendung der Arden-Syntax

Patientenübergreifende Entscheidungsunterstützung durch grafische Dashboards als Anwendung der Arden-Syntax GMDS - ConHIT Satellitenworkshop - 13.4.2015 Stefan Kraus Patientenübergreifende Entscheidungsunterstützung durch grafische Dashboards als Anwendung der Arden-Syntax Lehrstuhl für medizinische Informatik

Mehr

Methoden und Erfahrungen der. für die Arzneimitteltherapie

Methoden und Erfahrungen der. für die Arzneimitteltherapie Methoden und Erfahrungen der elektronischen Entscheidungsunterstützung für die Arzneimitteltherapie 19.04.2010 Dr. Reinhold Sojer Lehrstuhl für Medizinische Informatik Friedrich-Alexander-Universität Erlangen-Nürnberg

Mehr

Group and Session Management for Collaborative Applications

Group and Session Management for Collaborative Applications Diss. ETH No. 12075 Group and Session Management for Collaborative Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZÜRICH for the degree of Doctor of Technical Seiences

Mehr

ISO 15504 Reference Model

ISO 15504 Reference Model Prozess Dimension von SPICE/ISO 15504 Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define

Mehr

Distributed testing. Demo Video

Distributed testing. Demo Video distributed testing Das intunify Team An der Entwicklung der Testsystem-Software arbeiten wir als Team von Software-Spezialisten und Designern der soft2tec GmbH in Kooperation mit der Universität Osnabrück.

Mehr

Diplomarbeit. vorgelegt von. Ivan Mahnet. Matrikel Nr. 612904 13. Fachsemester. Wintersemester 2009/2010

Diplomarbeit. vorgelegt von. Ivan Mahnet. Matrikel Nr. 612904 13. Fachsemester. Wintersemester 2009/2010 Diplomarbeit Zur Erlangung des akademischen Titels Diplom-Gesundheitsökonom (FH) Dimensionierung einer Rohrpostanlage in einem Krankenhaus der Maximalversorgung vorgelegt von Ivan Mahnet Matrikel Nr. 612904

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme Fakultät für Mathematik, Informatik und Naturwissenschaften Forschungsgruppe Softwarekonstruktion Diplomarbeit Entwurf eines generischen Prozessleitstandes für Change Request Systeme Development of a Generic

Mehr

Vorstellung der Diplomarbeit

Vorstellung der Diplomarbeit Vorstellung der Diplomarbeit Integration of a medical documentation and image archiving system in hospital information systems with the utilization of a web-based user interface Holger Schmuhl 12.01.2006

Mehr

Forms2Net Die neue Migrations-Software

Forms2Net Die neue Migrations-Software Forms2Net Die neue Migrations-Software Forms2Net transportiert Ihre Oracle Forms Anwendungen perfekt nach Microsoft.NET Darauf haben viele gewartet. Vielleicht auch Sie! Forms2Net ist ein Produktpaket,

Mehr

Customer-specific software for autonomous driving and driver assistance (ADAS)

Customer-specific software for autonomous driving and driver assistance (ADAS) This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Integrated Data Repository Toolkit (IDRT)

Integrated Data Repository Toolkit (IDRT) Integrated Data Repository Toolkit (IDRT) TMF-Projekt V091-MI_03 AP5.2: Realisierung USE CASE Clinical DWH Report Igor Engel Sebastian Mate Jan Christoph Prof. Dr. Hans-Ulrich Prokosch Dr. Thomas Ganslandt

Mehr

Uptime Services AG Brauerstrasse 4 CH-8004 Zürich Tel. +41 44 560 76 00 Fax +41 44 560 76 01 www.uptime.ch. ARTS Workflow.

Uptime Services AG Brauerstrasse 4 CH-8004 Zürich Tel. +41 44 560 76 00 Fax +41 44 560 76 01 www.uptime.ch. ARTS Workflow. Uptime Services AG Brauerstrasse 4 CH-8004 Zürich Tel. +41 44 560 76 00 Fax +41 44 560 76 01 www.uptime.ch ARTS Workflow Funktionalitäten 22.05.2014 Sie möchten Informationen in Ihrem Betrieb anderen Stellen

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Dokumentation zur Anlage eines JDBC Senders

Dokumentation zur Anlage eines JDBC Senders Dokumentation zur Anlage eines JDBC Senders Mithilfe des JDBC Senders ist es möglich auf eine Datenbank zuzugreifen und mit reiner Query Datensätze auszulesen. Diese können anschließend beispielsweise

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Employment and Salary Verification in the Internet (PA-PA-US)

Employment and Salary Verification in the Internet (PA-PA-US) Employment and Salary Verification in the Internet (PA-PA-US) HELP.PYUS Release 4.6C Employment and Salary Verification in the Internet (PA-PA-US SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten.

Mehr

IDRT: Unlocking Research Data Sources with ETL for use in a Structured Research Database

IDRT: Unlocking Research Data Sources with ETL for use in a Structured Research Database First European i2b2 Academic User Meeting IDRT: Unlocking Research Data Sources with ETL for use in a Structured Research Database The IDRT Team (in alphabetical order): Christian Bauer (presenter), Benjamin

Mehr

Lautheitsaussteuerung, Normalisierung und zulässiger Maximalpegel von Audiosignalen

Lautheitsaussteuerung, Normalisierung und zulässiger Maximalpegel von Audiosignalen EBU Empfehlung R 128 Lautheitsaussteuerung, Normalisierung und zulässiger Maximalpegel von Audiosignalen Status: EBU Empfehlung This German version of EBU R 128 has been kindly provided by Messrs G. Spikofski

Mehr

Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision

Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision Zielsetzung: System Verwendung von Cloud-Systemen für das Hosting von online Spielen (IaaS) Reservieren/Buchen von Resources

Mehr

p^db=`oj===pìééçêíáåñçêã~íáçå=

p^db=`oj===pìééçêíáåñçêã~íáçå= p^db=`oj===pìééçêíáåñçêã~íáçå= Error: "Could not connect to the SQL Server Instance" or "Failed to open a connection to the database." When you attempt to launch ACT! by Sage or ACT by Sage Premium for

Mehr

DVMD Tagung Hannover 2011

DVMD Tagung Hannover 2011 DVMD Tagung Hannover 2011 Vorstellung der Bachelorarbeit mit dem Thema Schwerwiegende Verstöße gegen GCP und das Studienprotokoll in klinischen Studien - Eine vergleichende Analyse der Regularien der EU-Mitgliedsstaaten

Mehr

O N E SOLUTION. VIS//ON Overview Module Datacenter and Cablemanagement. VIS//ON Übersicht Module Datacenter und Kabelmanagement

O N E SOLUTION. VIS//ON Overview Module Datacenter and Cablemanagement. VIS//ON Übersicht Module Datacenter und Kabelmanagement O N E SOLUTION VIS//ON Overview Module Datacenter and Cablemanagement VIS//ON Übersicht Module Datacenter und Kabelmanagement Ü B E R S C H R I F T A R T I K E L I N N E N S E I T E C O M PA N Y OVERV

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

MOSAIC: Zentrales Datenmanagement als Methode zur Verbesserung der Nachnutzbarkeit medizinischer Forschungsdaten

MOSAIC: Zentrales Datenmanagement als Methode zur Verbesserung der Nachnutzbarkeit medizinischer Forschungsdaten MOSAIC: Zentrales Datenmanagement als Methode zur Verbesserung der Nachnutzbarkeit medizinischer Forschungsdaten Martin Bialke Institut für Community Medicine (Abt. VC) Universitätsmedizin Greifswald 25.

Mehr

DOKUMENTATION PASY. Patientendaten verwalten

DOKUMENTATION PASY. Patientendaten verwalten DOKUMENTATION PASY Patientendaten verwalten PASY ist ein Programm zur einfachen und zuverlässigen Verwaltung von Patientendaten. Sämtliche elektronisch gespeicherten Dokumente sind sofort verfügbar. Neue

Mehr

Verbesserte Datenverfügbarkeit im Transportnetz

Verbesserte Datenverfügbarkeit im Transportnetz Verbesserte Datenverfügbarkeit im Transportnetz Neue Funktionalitäten der ENTSOG Transparency Platform Martin Reisner Jahrestagung Energiewirtschaft Robotron // ECG 23 24/11/2011 Inhalt der Präsentation

Mehr

Vorgehensmodelle und webbasierte Technologien zur Integration von Systemen zur Unterstützung der Collaboration in Communities

Vorgehensmodelle und webbasierte Technologien zur Integration von Systemen zur Unterstützung der Collaboration in Communities Synopsis I Vorgehensmodelle und webbasierte Technologien zur Integration von Systemen zur Unterstützung der Collaboration in Communities Abschlussarbeit zur Erlangung des Grades Master of Science (MSc)

Mehr

Business Application Framework für SharePoint Der Kern aller PSC-Lösungen

Business Application Framework für SharePoint Der Kern aller PSC-Lösungen Business Application Framework für SharePoint Der Kern aller PSC-Lösungen Überblick pscbaf Dieses Dokument liefert die Antworten auf folgende Fragen: Was ist das Portal Systems Business Application Framework

Mehr

Rechnergestützte Steuerung von Behandlungspfaden im Krankenhaus als Grundlage für ein integriertes Wissensmanagement

Rechnergestützte Steuerung von Behandlungspfaden im Krankenhaus als Grundlage für ein integriertes Wissensmanagement Rechnergestützte Steuerung von Behandlungspfaden im Krankenhaus als Grundlage für ein integriertes Wissensmanagement Prof. Dr. Hermann Krallmann 1 und Dr. Michael Cebulla 2 1 Fachgebiet Systemanalyse und

Mehr

Health Level Seven (HL7)

Health Level Seven (HL7) FuE-Bereich IuK-Systeme im Gesundheitswesen IG Health Level Seven (HL7) Sascha Koch IG HL7 = Health Level Seven Health: Kommunikationsstandard speziell für das Gesundheitswesen Primäres Einsatzgebiet:

Mehr

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08 Security Patterns Benny Clauss Sicherheit in der Softwareentwicklung WS 07/08 Gliederung Pattern Was ist das? Warum Security Pattern? Security Pattern Aufbau Security Pattern Alternative Beispiel Patternsysteme

Mehr

eurex rundschreiben 094/10

eurex rundschreiben 094/10 eurex rundschreiben 094/10 Datum: Frankfurt, 21. Mai 2010 Empfänger: Alle Handelsteilnehmer der Eurex Deutschland und Eurex Zürich sowie Vendoren Autorisiert von: Jürg Spillmann Weitere Informationen zur

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7 Berichte aus der Medizinischen Informatik und Bioinformatik Günther Schadow Krankenhauskommunikation mit HL7 Analyse, Implementation und Anwendungeines Protokollstandards für medizinische Datenkommunikation

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Ohne CAPA geht es nicht

Ohne CAPA geht es nicht ZKS Köln Ohne CAPA geht es nicht Corrective and Preventive Actions in der klinischen Forschung Jochen Dress Christine Georgias Heike Mönkemann Ursula Paulus BMBF 01KN0706 2 Axiom Qualität in der klinischen

Mehr

Mobil informiert Mobil dokumentiert

Mobil informiert Mobil dokumentiert Mobil informiert Mobil dokumentiert SAP EMR, Erweiterungen für i.s.h.med Harald Bartl Wien, 27.09.2012 Mobile Anwendungen Ich glaube an das Pferd. Das Automobil ist nur eine vorübergehende Erscheinung.

Mehr

1 Zusammenfassung/Summary

1 Zusammenfassung/Summary 1 Zusammenfassung/Summary Zusammenfassung: Wissensdatenbanken gewinnen zunehmend an Bedeutung, wenn es darum geht, die Informationen, die ungeordnet in einem Unternehmen vorliegen, zu strukturieren und

Mehr

Geschäftsprozessmanagement

Geschäftsprozessmanagement Geschäftsprozessmanagement Der INTARGIA-Ansatz Whitepaper Dr. Thomas Jurisch, Steffen Weber INTARGIA Managementberatung GmbH Max-Planck-Straße 20 63303 Dreieich Telefon: +49 (0)6103 / 5086-0 Telefax: +49

Mehr

Workflow Systeme mit der Windows Workflow Foundation

Workflow Systeme mit der Windows Workflow Foundation Studiengang Electronic Business (EB) Diplomarbeit (280000) Workflow Systeme mit der Windows Workflow Foundation externe Betreuung durch Christoph Müller vorgelegt bei Prof. Dr. Michael Gröschel von Hans-Martin

Mehr

Post-Market-Surveillance & PMCF Wann ist eine PMCF-Studie angezeigt? PD Dr. med. Ulrich Matern

Post-Market-Surveillance & PMCF Wann ist eine PMCF-Studie angezeigt? PD Dr. med. Ulrich Matern Post-Market-Surveillance & PMCF Wann ist eine PMCF-Studie angezeigt? PD Dr. med. Ulrich Matern Das Gesetz Clinical investigations shall be performed unless it is duly justified to rely on existing clinical

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

Informationssysteme im Gesundheitswesen. Institut für Medizinische Informatik

Informationssysteme im Gesundheitswesen. Institut für Medizinische Informatik Informationssysteme im Gesundheitswesen Institut für Medizinische Informatik Informationssysteme im Gesundheitswesen Organisatorisches Organisatorisches Vertiefungsmodul für Wirtschaftsinformatikstudenten

Mehr

Objektorientiertes Programmieren für Ingenieure

Objektorientiertes Programmieren für Ingenieure Uwe Probst Objektorientiertes Programmieren für Ingenieure Anwendungen und Beispiele in C++ 18 2 Von C zu C++ 2.2.2 Referenzen und Funktionen Referenzen als Funktionsparameter Liefert eine Funktion einen

Mehr

English. Deutsch. niwis consulting gmbh (https://www.niwis.com), manual NSEPEM Version 1.0

English. Deutsch. niwis consulting gmbh (https://www.niwis.com), manual NSEPEM Version 1.0 English Deutsch English After a configuration change in the windows registry, you have to restart the service. Requirements: Windows XP, Windows 7, SEP 12.1x With the default settings an event is triggered

Mehr

Patientenübergreifende, multiple Verwendung von Gesundheitsdaten mit Hilfe von openehr-archetypen

Patientenübergreifende, multiple Verwendung von Gesundheitsdaten mit Hilfe von openehr-archetypen Institut für Medizinische Biometrie und Informatik: Medizinische Informatik Patientenübergreifende, multiple Verwendung von Gesundheitsdaten mit Hilfe von openehr-archetypen Christian Kohl Gliederung Einleitung

Mehr

OSS/J als Basis für Enterprise Application Integration

OSS/J als Basis für Enterprise Application Integration OSS/J als Basis für Enterprise Application Integration Geschäftsprozessgesteuerte EAI im Telekommunikationsbereich r A business of PwC Agenda OSS-Architekturen als Integrationsherausforderung OSS/J als

Mehr

Proseminar Website-Management-Systeme ZOPE/CMF. Andreas M. Weiner

Proseminar Website-Management-Systeme ZOPE/CMF. Andreas M. Weiner Proseminar Website-Management-Systeme ZOPE/CMF Andreas M. Weiner Technische Universität Kaiserslautern Fachbereich Informatik Arbeitsgruppe Softwaretechnik Betreuer: Dipl. Inf. Christian Stenzel Überblick

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

Scriptbasierte Testautomatisierung. für Web-Anwendungen

Scriptbasierte Testautomatisierung. für Web-Anwendungen Scriptbasierte Testautomatisierung für Web-Anwendungen Scriptbasierte Testautomatisierung + Web-Anwendung: Erstes Einsatzgebiet, Ergebnisse aber allgemein übertragbar + Test aus Benutzersicht - Nicht Unit-Test,

Mehr

Die folgenden Features gelten für alle isquare Spider Versionen:

Die folgenden Features gelten für alle isquare Spider Versionen: isquare Spider Die folgenden s gelten für alle isquare Spider Versionen: webbasiertes Management (Administratoren) Monitoring Sichten aller gefundenen Beiträge eines Forums Statusüberprüfung Informationen

Mehr

A Platform for Complex Event Processing

A Platform for Complex Event Processing A Platform for Complex Event Processing Einführung Business Process Technology Prof. Dr. Mathias Weske Matthias Kunze Nico Herzberg Business Process Technology Seit 2001 Untersuchung realer Probleme des

Mehr

MatchPoint. Wirtschaftlichkeit von SharePoint Plattformen optimieren

MatchPoint. Wirtschaftlichkeit von SharePoint Plattformen optimieren MatchPoint Wirtschaftlichkeit von SharePoint Plattformen optimieren MatchPoint at a Glance Build Solutions in Less Time Provide a Better User Experience Maintain Your Platform at Lower Cost 2 MatchPoint

Mehr

Wissensmanagement als Schlüssel zu integrierter Versorgung und Systemmedizin

Wissensmanagement als Schlüssel zu integrierter Versorgung und Systemmedizin Wissensmanagement als Schlüssel zu integrierter Versorgung und Systemmedizin Dr. Klaus Heumann Biomax Informatics AG www.biomax.com Biomax Steckbrief - Wissensmanagement Seit mehr als 15 Jahren weltweit

Mehr

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering,

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Manfred Broy Lehrstuhl für Software & Systems Engineering Technische Universität München Institut für Informatik ISO 26262 Functional

Mehr

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem 1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem Management, Access Management a. Event Management b. Service Desk c. Facilities Management d. Change Management e. Request Fulfilment

Mehr

Das Knowledge Grid. Eine Architektur für verteiltes Data Mining

Das Knowledge Grid. Eine Architektur für verteiltes Data Mining Das Knowledge Grid Eine Architektur für verteiltes Data Mining 1 Gliederung 1. Motivation 2. KDD und PDKD Systeme 3. Knowledge Grid Services 4. TeraGrid Projekt 5. Das Semantic Web 2 Motivation Rapide

Mehr

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

Interoperabilität planen, entwickeln und fördern: Werkzeuge und Strategien

Interoperabilität planen, entwickeln und fördern: Werkzeuge und Strategien SESSION 15: Vorsitz: Interoperabilität planen, entwickeln und fördern: Werkzeuge und Strategien Dr. Christof Geßner, gematik - Gesellschaft für Telematikanwendungen der Gesundheitskarte GmbH Modellbasierte

Mehr

Unser Auftraggeber ist einer der vier Global Player in den Bereichen Wirtschaftsprüfung,

Unser Auftraggeber ist einer der vier Global Player in den Bereichen Wirtschaftsprüfung, Case Study Testautomatisierung mit Coded UI Die Aufgabe Unser Auftraggeber ist einer der vier Global Player in den Bereichen Wirtschaftsprüfung, Steuerberatung und Unternehmens- bzw. Managementberatung.

Mehr

Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation

Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation WF2Trans Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation Aus unserer langjährigen Erfahrung in Kundenprojekten wissen wir, dass ein klares und eindeutiges

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

Änderungen ISO 27001: 2013

Änderungen ISO 27001: 2013 Änderungen ISO 27001: 2013 Loomans & Matz AG August-Horch-Str. 6a, 55129 Mainz Deutschland Tel. +496131-3277 877; www.loomans-matz.de, info@loomans-matz.de Die neue Version ist seit Oktober 2013 verfügbar

Mehr

TMF projects on IT infrastructure for clinical research

TMF projects on IT infrastructure for clinical research Welcome! TMF projects on IT infrastructure for clinical research R. Speer Telematikplattform für Medizinische Forschungsnetze (TMF) e.v. Berlin Telematikplattform für Medizinische Forschungsnetze (TMF)

Mehr

Timeline Figure - Grafische Darstellung eines Subjekts in der klinischen Forschung

Timeline Figure - Grafische Darstellung eines Subjekts in der klinischen Forschung Timeline Figure - Grafische Darstellung eines Subjekts in der klinischen Forschung Poster Endri Endri DataFocus GmbH Lothringer Straße 23 D-50667 Köln endri0501@yahoo.de Zusammenfassung Eine Timeline-Grafik

Mehr

Ingest von Fachverfahren. Werkzeuge des Landesarchivs Baden-Württemberg

Ingest von Fachverfahren. Werkzeuge des Landesarchivs Baden-Württemberg Ingest von Fachverfahren. Werkzeuge des Landesarchivs Baden-Württemberg 13. Tagung des AK Archivierung von Unterlagen aus digitalen Systemen 27.4.2009, St. Gallen Dr. Christian Keitel und Rolf Lang Übersicht

Mehr

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

Mehr

Microsoft Office SharePoint Services Workflow Limitierungen

Microsoft Office SharePoint Services Workflow Limitierungen Microsoft Office SharePoint Services Workflow Limitierungen Dorner Stefan, namics AG April 2007 Inhaltsverzeichnis Allgemeines... 3 Workflow Foundation Thread Pool-Modelle... 5 DefaultWorkflowSchedulerService...

Mehr

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird.

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. AGILO HOWTO Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. ROLLEN IM TEAM In Scrum hat jedes Teammitglied eine

Mehr

MySQL Queries on "Nmap Results"

MySQL Queries on Nmap Results MySQL Queries on "Nmap Results" SQL Abfragen auf Nmap Ergebnisse Ivan Bütler 31. August 2009 Wer den Portscanner "NMAP" häufig benutzt weiss, dass die Auswertung von grossen Scans mit vielen C- oder sogar

Mehr

Phase-II-Paket. R-Paket und Software-Tool für Planung, Monitoring und Auswertung onkologischer Phase-II-Studien

Phase-II-Paket. R-Paket und Software-Tool für Planung, Monitoring und Auswertung onkologischer Phase-II-Studien Phase-II-Paket R-Paket und Software-Tool für Planung, Monitoring und Auswertung onkologischer Phase-II-Studien Impressum TMF Technologie- und Methodenplattform für die vernetzte medizinische Forschung

Mehr

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek Speaker Andreas Holubek VP Engineering andreas.holubek@arlanis.com arlanis Software AG, D-14467 Potsdam 2009, arlanis

Mehr

Eine Studie was ist das? Grundlagen klinischer Studien

Eine Studie was ist das? Grundlagen klinischer Studien Eine Studie was ist das? Grundlagen klinischer Studien Grundlagen klinischer Studien Eine Studie ist eine systematische Sammlung von Daten, die dazu dient, eine oder mehrere Fragen zu beantworten. Eine

Mehr

Comparing Software Factories and Software Product Lines

Comparing Software Factories and Software Product Lines Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

Die BPM-Trilogie BPMN, CMMN, DMN mehr als Schlagworte?

Die BPM-Trilogie BPMN, CMMN, DMN mehr als Schlagworte? Die BPM-Trilogie BPMN, CMMN, DMN mehr als Schlagworte? Wann Sie die neuen Standards anwenden sollten und wie wir die Konzepte dahinter vermitteln können Präsentation auf dem Process Solutions Day 2015

Mehr

GIPS 2010 Gesamtüberblick. Dr. Stefan J. Illmer Credit Suisse. Seminar der SBVg "GIPS Aperitif" 15. April 2010 Referat von Stefan Illmer

GIPS 2010 Gesamtüberblick. Dr. Stefan J. Illmer Credit Suisse. Seminar der SBVg GIPS Aperitif 15. April 2010 Referat von Stefan Illmer GIPS 2010 Gesamtüberblick Dr. Stefan J. Illmer Credit Suisse Agenda Ein bisschen Historie - GIPS 2010 Fundamentals of Compliance Compliance Statement Seite 3 15.04.2010 Agenda Ein bisschen Historie - GIPS

Mehr

CHAMPIONS Communication and Dissemination

CHAMPIONS Communication and Dissemination CHAMPIONS Communication and Dissemination Europa Programm Center Im Freistaat Thüringen In Trägerschaft des TIAW e. V. 1 CENTRAL EUROPE PROGRAMME CENTRAL EUROPE PROGRAMME -ist als größtes Aufbauprogramm

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

vap 2006 R2 Datenbankzugriff mit Windows Integrated Security Technische Dokumenation

vap 2006 R2 Datenbankzugriff mit Windows Integrated Security Technische Dokumenation vap 2006 R2 Datenbankzugriff mit Windows Integrated Security Technische Dokumenation www.visionapp.com Inhalt 1 Einleitung... 2 2 Voraussetzungen... 2 3 Installation... 2 3.1 Infrastrukturelle Anforderungen...

Mehr

Closed-Loop Healthcare Monitoring in a Collaborative Heart Failure Network

Closed-Loop Healthcare Monitoring in a Collaborative Heart Failure Network Closed-Loop Healthcare Monitoring in a Collaborative Heart Failure Network Graduelle Anpassung der Versorgungsstruktur R. Modre-Osprian 1,*, G. Pölzl 2, A. VonDerHeidt 2, P. Kastner 1 1 AIT Austrian Institute

Mehr

Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation

Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation Eine Betrachtung im Kontext der Ausgliederung von Chrysler Daniel Rheinbay Abstract Betriebliche Informationssysteme

Mehr

Whitepaper Walkyre Enterprise Resource Manangement

Whitepaper Walkyre Enterprise Resource Manangement Whitepaper Walkyre Enterprise Resource Management Seite 1 Whitepaper Walkyre Enterprise Resource Manangement Stand 15.11.2004 Inhalt 1. Hinweis... 2 2. Grundsätzliches zur Funktionalität... 3 3. Der Walkyre-Client...

Mehr

Requirements-Engineering Requirements-Engineering

Requirements-Engineering Requirements-Engineering -Engineering Copyright Chr. Schaffer, Fachhochschule Hagenberg, MTD 1 Was ist ein Requirement? IEEE-Standard (IEEE-726 83) A condition or capability needed by a user to solve a problem or achieve an objective.

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

SLA4D-Grid! Einführung, Konzepte und Ergebnisse

SLA4D-Grid! Einführung, Konzepte und Ergebnisse Service Level Agreements for D-Grid SLA4D-Grid! Einführung, Konzepte und Ergebnisse Philipp Wieder, Service Computing, TU Dortmund SLAs in Grid und Cloud Workshop 09. September 2010, Karlsruhe, DE http://www.sla4d-grid.de

Mehr

REQUEST FOR YOUR MEDICAL SECOND OPINION REPORT ANTRAG AUF IHR MEDIZINISCHES ZWEITE MEINUNG - GUTACHTEN

REQUEST FOR YOUR MEDICAL SECOND OPINION REPORT ANTRAG AUF IHR MEDIZINISCHES ZWEITE MEINUNG - GUTACHTEN REQUEST FOR YOUR MEDICAL SECOND OPINION REPORT ANTRAG AUF IHR MEDIZINISCHES ZWEITE MEINUNG - GUTACHTEN SECOND OPINION REPORT ZWEITE MEINUNG GUTACHTEN netto Euro brutto Euro medical report of a medical

Mehr

Microsoft Visio 2010 Funktionalitäten und Leistungen

Microsoft Visio 2010 Funktionalitäten und Leistungen Microsoft Visio 2010 Funktionalitäten und Leistungen Die fortgeschrittenen Funktionen zur Diagrammerstellung von Visio 2010 helfen Ihnen, komplexe Inhalte und Zusammenhänge schneller und einfacher zu vermitteln.

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Behandlungsunterstützung mittels App. Lars Erdmann, Partner, Q_PERIOR AG SAP Mobile Forum, 17. April 2013

Behandlungsunterstützung mittels App. Lars Erdmann, Partner, Q_PERIOR AG SAP Mobile Forum, 17. April 2013 Behandlungsunterstützung mittels App Lars Erdmann, Partner, Q_PERIOR AG SAP Mobile Forum, 17. April 2013 Agenda Hintergrund Warum eine mobile Lösung? Lösungsansatz Was sind die Vorteile? Technische Umsetzung

Mehr

ORM & OLAP. Object-oriented Enterprise Application Programming Model for In-Memory Databases. Sebastian Oergel

ORM & OLAP. Object-oriented Enterprise Application Programming Model for In-Memory Databases. Sebastian Oergel ORM & OLAP Object-oriented Enterprise Application Programming Model for In-Memory Databases Sebastian Oergel Probleme 2 Datenbanken sind elementar für Business-Anwendungen Gängiges Datenbankparadigma:

Mehr

Zabbix 2.4. What's new? What's new in Zabbix 2.4. 1 of

Zabbix 2.4. What's new? What's new in Zabbix 2.4. 1 of Zabbix 2.4 What's new? 1 of What's new in Zabbix 2.4 About me Name: Pascal Schmiel Email: Schmiel@dv-loesungen.de WEB: www.dv-loesungen.de Senior Consultant Zabbix Certified Professional 2 of What's new

Mehr

Transaktionsverwaltung

Transaktionsverwaltung Transaktionsverwaltung VU Datenbanksysteme vom 21.10. 2015 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Transaktionsverwaltung

Mehr

KURZANLEITUNG. Firmware-Upgrade: Wie geht das eigentlich?

KURZANLEITUNG. Firmware-Upgrade: Wie geht das eigentlich? KURZANLEITUNG Firmware-Upgrade: Wie geht das eigentlich? Die Firmware ist eine Software, die auf der IP-Kamera installiert ist und alle Funktionen des Gerätes steuert. Nach dem Firmware-Update stehen Ihnen

Mehr

Der BPM-Lebenszyklus in Theorie und Praxis. Prof. Dr. Mathias Weske

Der BPM-Lebenszyklus in Theorie und Praxis. Prof. Dr. Mathias Weske Der BPM-Lebenszyklus in Theorie und Praxis Prof. Dr. Mathias Weske Hasso Plattner Institut 2 An-Institut der Universität Potsdam, aus privaten Mitteln von SAP- Gründer Hasso Plattner finanziert Bachelor

Mehr

Continuous Auditing eine gut gemeinte aber schlechte Idee kommt zurück

Continuous Auditing eine gut gemeinte aber schlechte Idee kommt zurück Continuous Auditing eine gut gemeinte aber schlechte Idee kommt zurück Michel Huissoud Lic.iur, CISA, CIA 5. November 2012 - ISACA/SVIR-Fachtagung - Zürich Überwachung Continuous Monitoring Continuous

Mehr