gms | German Medical Science

53. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e. V. (GMDS)

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie

15. bis 18.09.2008, Stuttgart

Integration wissensbasierter Funktionen in ein kommerzielles Patientendatenmanagementsystem

Meeting Abstract

  • Stefan Kraus - Lehrstuhl für Medizinische Informatik, Universität Erlangen, Erlangen, Deutschland
  • Thomas Bürkle - Lehrstuhl für Medizinische Informatik, Universität Erlangen, Erlangen, Deutschland
  • Ixchel Castellanos - Anästhesiologische Klinik, Universität Erlangen, Erlangen, Deutschland
  • Hans-Ulrich Prokosch - Lehrstuhl für Medizinische Informatik, Universität Erlangen, Erlangen, Deutschland

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie. 53. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie (gmds). Stuttgart, 15.-19.09.2008. Düsseldorf: German Medical Science GMS Publishing House; 2008. DocSTUD2-4

The electronic version of this article is the complete one and can be found online at: http://www.egms.de/en/meetings/gmds2008/08gmds253.shtml

Published: September 10, 2008

© 2008 Kraus et al.
This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by-nc-nd/3.0/deed.en). You are free: to Share – to copy, distribute and transmit the work, provided the original author and source are credited.


Outline

Text

Einleitung und Fragestellung

Am Klinikum der Friedrich-Alexander-Universität Erlangen-Nürnberg wurde Ende 2006 ein kommerzielles Patientendatenmanagementsystem (PDMS) auf der interdisziplinären operativen Intensivstation (IOI) eingeführt. Dieses verfügt über keine Funktionen zur wissensbasierten Entscheidungsunterstützung bzw. zur Generierung von Warnhinweisen nach komplexeren Regelwerken, obwohl deren Vorteile in der Literatur vielfältig beschrieben wurden [1] und auch im betreffenden klinischen Bereich gewünscht werden.

Parallel dazu wurde im Rahmen einer Dissertation für ein anderes Projekt eine generische Entwicklungs- und Ausführungsumgebung (kurz Ardenumgebung) für die Integration wissensbasierter Funktionen in unterschiedliche klinische Anwendungssysteme entwickelt [2]. Diese basiert auf der Arden Syntax [3] und erlaubt die Definition einzelner unabhängiger Wissensmodule (Medical Logic Modules MLM). Unsere Fragestellung lautete nun: Wie lässt sich diese Ardenumgebung an das kommerzielle PDMS anbinden und welche Einschränkungen entstehen dabei?

Material und Methoden

Das Vorgehen gliederte sich in eine Analyse- und eine Implementierungsphase. In der Analysephase erfolgte eine detaillierte Untersuchung der Ardenumgebung und der Datenschnittstelle des PDMS. Aufgrund dieser Analyse wurden potentielle Problemfelder identifiziert und daraus die Anforderungen für die Implementierung erarbeitet. In der Implementierungsphase wurde eine Reihe von Komponenten entwickelt, mit denen die Problemfelder umgangen werden konnten.

Bereits frühzeitig in der Analysephase wurden Einschränkungen in Form von zwei Rahmenbedingungen deutlich: Erstens war ein direkter Zugriff auf die Patientendatenbank nicht möglich, da das Datenmodell vom Hersteller nicht offengelegt und ein Direktzugriff nicht gestattet wurde. Daher standen auch die in der Arden Syntax zur Erkennung von Auslösern für wissensbasierte Funktionen üblicherweise verwendeten Datenbanktrigger [4] nicht zur Verfügung. An dieser Stelle verfügt das kommerzielle PDMS lediglich über eine Datenexportschnittstelle mit einem proprietären Textformat, die der automatisierten Arztbriefschreibung und der Erzeugung von Berichten und Ausdrucken dient. Zweitens waren keine Änderungen an der verwendeten Ardenumgebung möglich. Diese beinhaltet einen Arden Compiler, der MLMs in Java Bytecode übersetzt und die Möglichkeit bietet, die übersetzten MLMs in einer Wissensbasis zu registrieren. Sie beinhaltet weiterhin eine Arden Engine, welche die Ausführung einzelner MLMs der Wissensbasis ermöglicht, wobei der Aufruf über den MLM-Namen erfolgt. Arden Compiler und Arden Engine werden über eine Webservice-Schnittstelle angesteuert und sind daher sowohl plattform- als auch sprachunabhängig.

Ergebnisse

In der Analysephase konnten mehrere Problemfelder identifiziert werden. Die fehlende direkte Zugriffsmöglichkeit auf die Patientendaten im PDMS (beispielsweise per SQL) und insbesondere das Fehlen eines datengesteuerten Triggermechanismus für wissensbasierte Funktionen erwiesen sich als problematisch. Das Fehlen des direkten Datenzugriffs verursachte entgegen der anfänglichen Erwartung keine unüberwindlichen Schwierigkeiten. Der angebotene Datenexportmechanismus über sogenannte Schlüsselwortterme in eine Textdatei erwies sich als relativ leistungsfähig und geeignet, die meisten Inhalte der PDMS-Datenbank abzufragen. Innerhalb der sogenannten „Curly Braces“ der Arden Syntax [3] fanden diese Schlüsselwortterme Wiederverwendung. Der fehlende Triggermechanismus hingegen erforderte einen entsprechenden Workaround. Die Analyse der Ardenumgebung selbst ergab, dass diese keine Ereignisse direkt verarbeiten, sondern vielmehr lediglich einzelne MLMs über deren Namen aufrufen kann.

Daraus ergaben sich folgende Konsequenzen für die nachfolgende prototypische Implementierung: Die Vorgehensweise für die Lösung des Datenzugriffsproblems bestand darin, die von den MLMs benötigten Daten in periodischen Abständen in eine Textdatei zu exportieren und sie dann in eine Datenbank (ProxyDB) umzusetzen, die mithin als Stellvertreter für die nicht zugängliche Patientendatenbank verwendet wurde. Um das Eintreten von Ereignissen trotz des fehlenden datengesteuerten Triggermechanismus erkennen zu können wurde ein Eventhandler entwickelt. Dieser überprüft die periodisch exportierten Daten auf Ereignisse und ruft dann die entsprechenden MLMs auf.

In der Implementierungsphase konnte die prototypische Integration wissensbasierter Funktionen in das PDMS erfolgreich durchgeführt werden. Außerdem wurde eine Webanwendung entwickelt, über die Ereignisdefinitionen und MLMs im System registriert werden können. Die Webanwendung generiert automatisch die erforderlichen Konfigurationsdateien für die Exportschnittstelle, über die periodisch Patientendaten exportiert werden. Der neu entwickelte Eventhandler überprüft diese exportierten Daten auf eingetretene Ereignisse hin. Wird ein Ereignis erkannt, setzt ein in den Eventhandler integrierter Konverter die Daten in die ProxyDB um, von wo die MLMs sie dann auslesen können. Für den anschließenden Aufruf der MLMs wurde ein Evoking-Mechanismus implementiert, der alle MLMS, die einem bestimmten Ereignis zugeordnet sind, der Reihe nach aufruft.

Diskussion

Die prototypische Integration der Ardenumgebung in das PDMS war zwar aufwendig, aber prinzipiell erfolgreich. Erste Tests im Echtsystem sind geplant. Systembedingt existieren allerdings Einschränkungen. Die über Knopfdruck nutzergesteuerte und die reguläre zeitgesteuerte Triggerung von Ereignissen bereitet keine Schwierigkeiten. Probleme aufgrund von zeitlichen Verzögerungen können aber bei der über einen Workaround realisierten datengesteuerten Triggerung von Ereignissen auftreten. Da der fehlende Triggermechanismus über einen periodischen Datenexport simuliert wird, ist keine unmittelbare Reaktion auf Ereignisse möglich. Aufgrund der Eigenschaften der Exportschnittstelle arbeitet der simulierte Triggermechanismus nur dann zuverlässig, wenn Patientendaten ohne starke zeitliche Verzögerung in die Patientendatenbank geschrieben werden. Das trifft für die Übernahme von Medizingerätedaten jeweils zur vollen Stunde nur bedingt zu.

Die in der Analyse genannten Rahmenbedingungen wirken sich ferner nachteilig auf die Systemlast aus. Aufgrund des fehlenden datengesteuerten Triggermechanismus müssen relevante Daten regelmäßig 'auf Verdacht' exportiert werden, was zum unnötigen Verbrauch von Systemressourcen und zu einer merklichen Systemlast auf dem PDMS-Server führt. Erste Praxisversuche im Echtsystem müssen zeigen inwieweit diese zusätzliche Last tolerabel ist und wie leistungsfähig die geschaffene PDMS-Integration von wissensbasierten Funktionen tatsächlich ist. Möglicherweise muss von der Anwendung besonders aufwendiger MLMs abgesehen werden. Dies könnte vermieden werden, indem der PDMS-Hersteller eine datengesteuerte Triggermöglichkeit in die Exportschnittstelle integriert oder, im Idealfall, die Patientendatenbank freigibt. Aktuelle Entwicklungen zielen darauf hin, die Ardenumgebung so anzupassen, dass die MLMs direkt auf Textdateien zugreifen können. Dadurch könnte die bisher notwendige Umsetzung der Daten in die ProxyDB vermieden werden.

Ausblick

Im medizinischen Umfeld werden in der Zukunft immer weniger starre, einmalig programmierte Anwendungen benötigt. Vielmehr ist es zunehmend notwendig, existente Komponenten und Standards auf eine geschickte und flexible Art miteinander zu verbinden, um damit neu auftretende Probleme zu lösen. Die hier dargestellte Anbindung wissensbasierter Funktionen an ein kommerzielles PDMS, welches für diese Aufgaben nicht gerade prädestiniert und aufgrund seiner Architektur nicht gut zugänglich war, mag als Beispiel dienen für eine solche flexible, an den klinischen Bedarf anpassbare Lösung.


Literatur

1.
Johnston M, Langton KB, Haynes R, Mathieu A. Effects of computer-based clinical decision support systems on clinical performance and patient outcome: a critical appraisal of research. 1994
2.
Sojer R. Transformation des Arzneimittelsicherheitsystems KLASSE in eine standardisierte Wissensrepräsentation, Inaugural Dissertation, 2008
3.
ANSI/HL7 Arden V2.5-2005. Health Level Seven Arden Syntax, Version 2.5 (revision of ANSI/HL7 Arden V2.1-2002). April 25, 2005
4.
Hripcsak G, Clayton PD, Jenders RA, Cimino JJ, Johnson S. Design of a clinical event monitor. Comput Biomed Res. 1996;29(3):194-221