=Paper=
{{Paper
|id=Vol-93/paper-10
|storemode=property
|title=Integration in der medizinischen Anwendung: Prozessbasierte Datenlogistik
|pdfUrl=https://ceur-ws.org/Vol-93/paper10.pdf
|volume=Vol-93
|dblpUrl=https://dblp.org/rec/conf/eai/MullerLMJ04
}}
==Integration in der medizinischen Anwendung: Prozessbasierte Datenlogistik==
Integration in der medizinischen Anwendung:
Prozessbasierte Datenlogistik1
Sascha Müller, Rainer Lay, Christian Meiler, Stefan Jablonski
Lehrstuhl für Informatik 6 (Datenbanksysteme)
Friedrich-Alexander-Universität Erlangen-Nürnberg
Martensstr. 3, D-91058 Erlangen
{sascha.mueller, rainer.lay, christian.meiler, stefan.jablonski}@informatik.uni-erlangen.de
Zusammenfassung. Die möglichst optimale Integration klinischer
Anwendungssysteme ist vital für den modernen Klinikbetrieb. Wir beschreiben
einen Ansatz zur prozessorientierten Datenlogistik, der es erlaubt, das
medizinische Personal entlang dem Behandlungsprozess mit notwendigen
Daten zu versorgen. Durch Transformation graphischer Prozessmodelle in eine
datenzentrierte Darstellung kann eine automatisierte Konfiguration von
Kommunikationsservern erreicht werden. Im Vordergrund steht dabei die
Datenversorgung der am Behandlungsprozess beteiligten Personen und nicht
die direkte Unterstützung des Prozesses, wie sie durch Workflow-Management-
Systeme erreicht wird. Der Ansatz wird in einer Fallstudie vorgestellt.
1 Einleitung
In der klinischen Datenverarbeitung besteht die Notwendigkeit zur Integration
verschiedenster Anwendungssysteme mit dem Ziel existierende und zukünftige
Behandlungsprozesse optimal zu unterstützen. Zwei grundlegend verschiedene
Ansätze dominieren den Markt: Vollständig integrierte Krankenhausinformationssys-
teme (KIS), die mit einem holistischen Ansatz die Schnittstellenproblematik
weitgehend zu vermeiden versuchen. Als Alternative existieren vor allem
Kommunikationsserver-basierte Lösungen, die mit standardisierten Schnittstellen wie
HL7 („Health Level 7“) [1] den Datenaustausch zwischen Einzelsystemen
ermöglichen.
Im Fall der Kommunikationsserver stellt sich die Frage, wie die Datenflüsse
optimal gestaltet werden können, um jederzeit hohe Datenverfügbarkeit zu
gewährleisten und gleichzeitig die Prozesskosten zu minimieren. Eine Lösung für
diese Problematik könnte eine prozessorientierte Vorgehensweise sein, welche
beispielsweise die Datenverteilung entlang den Behandlungsstationen eines Patienten
organisiert. Die Vorteile einer derartigen prozessbasierten Datenlogistik sind
offensichtlich:
1 Der Sonderforschungsbereich 539: "Glaukome einschließlich Pseudoexfoliations-Syndrom
(PEX)" wird unterstützt von der Deutschen Forschungsgemeinschaft (DFG).
• Konfigurationen für Kommunikationsserver können automatisch aus umfassenden
Prozessmodellen generiert werden.
• Klinische Pfade können abgebildet und fallbasiert unterstützt werden.
• Vorhandene Infrastruktur kann effizienter genutzt werden, da sich die Lücke
zwischen Anwendungswissen und der technischen Umsetzung, beispielsweise der
Konfiguration eines Kommunikationsservers, schließt.
Wir beschreiben im Folgenden einen Ansatz, der die genannten Vorteile der
prozessbasierten Datenlogistik im Krankenhausbereich umsetzt. Dazu betrachten und
bewerten wir im nächsten Abschnitt Basistechnologien wie Kommunikationsserver
und Workflow-Management. Abschnitt 3 beschreibt unseren prozessbasierten
Lösungsansatz und Abschnitt 4 illustriert schließlich mit einer Fallstudie unsere
Methodik.
2 Basistechnologien
Die Basistechnologien Kommunikationsserver und Workflow-Management-Systeme
(WfMS) werden im Folgenden kurz eingeführt und im Anwendungskontext des hier
vorgestellten Ansatzes bewertet.
2.1 Kommunikationsserver
Kommunikationsserver sind eine in Krankenhäusern weit verbreitete Middleware
(MOM, Message-Oriented-Middleware) und ermöglichen den Datenaustausch
zwischen den verschiedenen medizinischen Systemen. Durch die Definition von
Schnittstellen auf Basis von HL7 bilden Kommunikationsserver eine zentrale
Plattform zum asynchronen und quittierten Datenaustausch. Vorteile sind unter
anderem die deutlich reduzierte Schnittstellenanzahl zwischen den einzelnen
Systemen und das standardisierte Nachrichtenformat HL7. Ein
Kommunikationsserver erfüllt dabei im Wesentlichen die drei folgenden
Hauptaufgaben [2]: Empfang von Datenpaketen, semantische und syntaktische
Transformation vom Quell- in das Zielformat und Auslieferung des Datenpakets.
Die Konfiguration erfolgt dabei regelbasiert und oft auf niedrigem
Abstraktionsniveau. Für umfangreiche heterogene Netzwerke ergibt sich so schnell
eine unübersichtliche Konfiguration, die schwer zu überblicken und verifizieren ist.
Entsprechend aufwändig und fehleranfällig gestaltet sich die Wartung. Wir
bezeichnen dieses Vorgehen im Folgenden als Konfiguration auf Instanzebene. Diese
bringt eine Reihe von Problemen mit sich: Es existiert eine semantische Lücke
zwischen Anwendungsdomäne und der tatsächlichen Implementierung. Ohne die
Notwendigkeit derartiger Konfigurationen in Frage zu stellen, sehen wir große
Vorteile durch Modellierungskonzepte auf höherem Abstraktionsniveau.
2.2 Workflow Management
Workflow-Management-Systeme werden in verschiedensten Anwendungsbereichen
eingesetzt und bieten eine umfassende Unterstützung von Anwendungsprozessen. Die
Implementierung einer Workflow-Management-Anwendung erfolgt in zwei Schritten:
In einem ersten Schritt muss ein Workflow-Modell erstellt und validiert werden. In
einem zweiten Schritt wird ein solches Workflow-Modell zur Ausführungszeit
instanziiert. Die Anwender interagieren mit dem System über eine Arbeitsliste,
welche den am Prozess beteiligten Personen eine Liste der zur Ausführung
bereitstehenden Aufgaben präsentiert [3].
Der Einsatz von WfMSen in Krankenhäusern hat eine Reihe von Vorteilen:
WfMSe garantieren die koordinierte Ausführung von Prozessen mit Beteiligung von
Anwendern und Systemen. Insbesondere der Datenaustausch zwischen den beteiligten
Systemen wird organisiert, was WfMSe für den Einsatz im klinischen Umfeld
prädestiniert. Ein oft genannter Vorteil von WfM ist die Eigenschaft, alle
notwendigen Daten bei der Ausführung eines Prozessschrittes zur Verfügung zu
stellen. Gerade in Kliniken kann dieses Merkmal aber auch sehr schnell ins Gegenteil
umschlagen, wenn beispielsweise ein medizinischer Notfall die Abweichung vom
vorgegebenen Workflow erzwingt. In diesem Fall muss das WfMS umgangen werden
und es zeigt sich, dass sehr genau überlegt werden muss, welche Prozesse überhaupt
mit Hilfe eines WfMS verwaltet werden können.
Durch die strenge und unflexible Ausführung von Prozessen ergibt sich eine Reihe
von Nachteilen. Was in Anwendungsgebieten mit einer überschaubaren Anzahl
weitgehend statischer Abläufe, wie beispielsweise dem Banken- oder Versicherungs-
wesen ein gewichtiger Vorteil ist, wird im medizinischen Anwendungsbereich zur
Achillesferse, da hier mit zahlreichen hochgradig variierenden Prozessen zu rechnen
ist. Die resultierende Variantenvielfalt ist mit WfMS in der Praxis kaum zu erreichen,
da diese auf eine strikte Ausführung der vorgegeben Prozesse ausgelegt sind und die
Mächtigkeit der Modellierungssprache im Allgemeinen zu gering ist. Ansätze zur
Flexibilisierung der Workflow-Ausführung (z.B. [4]) sind zwar vorhanden, erhöhen
aber auch die Komplexität des resultierenden Workflow-Modells.
2.3 Bewertung
Sowohl Kommunikationsserver als auch WfMSe bieten Vor- und Nachteile beim
Einsatz in Kliniken. WfMSe bieten die notwendigen Modellierungsmittel, um
klinische Prozesse auf einem sinnvollen Abstraktionslevel umfassend zu beschreiben.
Es zeigte sich aber auch, dass WfMSe oftmals auf einem zu restriktiven
Ausführungsmodell basieren und die notwendige Flexibilität nicht liefern können.
Kommunikationsserver bieten Aufgrund der verwendeten Konfiguration auf
Instanzebene keine problemspezifische Modellsicht, woraus schlechte Wartbarkeit
und Lesbarkeit resultiert. Ihre Stärken liegen in dem einfachen und standardisierten
Aufbau von Kommunikationsbeziehungen zwischen klinischen Systemen. Ausgehend
von diesen Beobachtungen ist es wünschenswert, ein Konzept zu entwickeln, welches
die Vorteile von beiden Ansätzen vereint und die Nachteile nicht übernimmt. Unser
Konzept der prozessorientierten Datenlogistik folgt dieser Forderung.
3 Unser Lösungsvorschlag
Das vorliegende Konzept vereint die Vorteile von WfM und Kommunikationsservern
und bietet eine Lösung für den Bereich der klinischen Kommunikation. Folgende
Kernforderungen werden dabei erfüllt: Datenverfügbarkeit bei Ausführung eines
Prozessschritts, abstrakte Beschreibung der klinischen Prozesse durch Prozessmodelle
und Verwendung der Datenaustauschmechanismen von Kommunikationsservern
(oder ähnlichen Ansätzen).
Die Ergebnisse aus Abschnitt 2 lassen uns zwei Arten der Unterstützung von
klinischen Prozessen erkennen: Modellierungs- und Kommunikationsunterstützung.
Dies veranlasst uns zur Definition von zwei Ebenen: Der Modellierungsebene, welche
eine abstrakte aber umfassende Definition der Kommunikationsbeziehungen enthält
und der Kommunikationsebene, welche diese Spezifikationen umsetzt. WfMS haben
konzeptionelle Stärken auf der Modellierungsebene und können dort verwendet
werden. Zusätzlich kommen Teilkomponenten wie die Workflow-Ausführung auch in
der Kommunikationsebene zur Geltung. Kommunikationsserver sind ein typischer
Vertreter der Kommunikationsebene, aber auch andere Implementierungen können
hier angesiedelt werden, wie beispielsweise der adaptive Replikationsmanager [5].
Wir bezeichnen unser Verfahren um klinische Prozesse zu modellieren und
auszuführen als Prozessbasierte Datenlogistik (PDL). Es fußt auf den Konzepten des
WfM, verzichtet jedoch auf die Ausführung, indem es sich auf die Ableitung von
Kommunikationsregeln aus einem Prozessmodell beschränkt. PDL unterscheidet sich
weiterhin vom strikten Modell des Workflow Management, indem es unauffällig im
Hintergrund dem Anwender die für seine nächsten Schritte benötigten Daten
bereitstellt; eine Interaktion mit dem Anwender ist nicht notwendig. Der Anwender
behält so volle Handlungsfreiheit und profitiert zugleich von hoher
Datenverfügbarkeit. Folgende Schritte charakterisieren PDL:
1. Die klinischen Prozesse müssen aufgenommen und in einem Workflow-Modell
dokumentiert werden.
Analog zum Workflow-Management steht am Anfang eine umfassende
Prozessaufnahme, die auf verfügbaren Informationen basiert, wie z.B.
medizinische Leit- und Richtlinien, medizinisches Personal, EDV-Systemland-
schaft, etc.
2. Das Workflow-Modell muss in ein datenzentriertes Modell umgewandelt werden.
Mit dieser Transformation werden die beteiligten Systeme und die zwischen ihnen
ausgetauschten Daten in den Mittelpunkt der Betrachtung gestellt. Man kann
daraus sehr leicht die Regeln zur Beschreibung der Datenlogistik ableiten. Ein
Workflow-Modell wird in ein datenzentriertes Modell gewandelt (siehe Abb. 1),
indem aus jedem Datenfluss zwischen zwei Prozessschritten ein Datenlogistik-
schritt erzeugt wird. Dieser Datenlogistikschritt benötigt die ausgehenden
Datencontainer des vorhergehenden Workflow-Schritts und die eingehenden
Datencontainer des nachfolgenden Workflow-Schritts. Zusätzlich werden noch die
Systeme der beteiligten Workflow-Schritte benötigt, da diese den Speicherungsort
der zu transportierenden Daten spezifizieren. In unserem Bespiel (vgl. Abb. 1) wird
aus den Schritten „record glaucoma data“ und „store diagnostic data“ ein
Datenlogistikschritt, der die Daten „IOP“ und „Blood Pressure“ von „Telephone
System“ zu „Glaucoma Register“ transportiert. Die Problematik der
Datentransformation bedingt durch unterschiedliche Formate, Terminologien und
Ontologien in Quell- und Zielsystem ist hier nicht näher betrachtet. Eine
Beschreibung der Datencontainer in dieser Hinsicht ist jedoch vorgesehen.
IOP IOP
process step Blood Pressure data container Blood Pressure
record glaucoma data store diagnostic data
Patient Telephone System (TS) Assistant Medical Technician Glaucoma Register (GR)
initiator used application
IOP IOP
Blood Pressure Blood Pressure
MOVE DATA
from : Telephone System
to : Glaucoma Register
incoming phone call YAWA
Abb. 1. Die Abbildung eines Workflow-Schrittes in einen Datenlogistikschritt
3. Die Datenlogistikprozesse müssen ausgeführt werden.
Für diese Aufgabe können verschiedene Techniken zum Einsatz kommen. Denkbar
wären auch WfMSe mit leichten Modifikationen. Es bieten sich im klinischen
Umfeld besonders Kommunikationsserver an, für die automatisiert eine
Konfiguration aus dem datenzentrierten Modell erzeugt werden kann.
Die Hauptvorteile der PDL liegen in der Wiederverwendung bekannter und bewährter
Techniken und in der erheblich vereinfachten und umfassenderen automatischen
Konfiguration von Systemen der Kommunikationsschicht, wie beispielsweise
Kommunikationsserver.
4 Fallstudie: Vom Workflow-Modell zur prozessorientierten
Datenlogistik
In diesem Abschnitt beschreiben wir, wie man ein Workflow-Modell in eine gültige
Konfiguration für ein System der Kommunikationsebene, in unserem Beispiel ein
Wrapper-Framework, transformiert. Der verwendete, vereinfacht dargestellte Prozess
(Abb. 2) entspringt einem Projekt aus dem Sonderforschungsbereich 539 der
Universitätsaugenklinik Erlangen-Nürnberg.
Prozess: Self-Tonometry
Measure specification//
external entry
electronic health record//
Measure specification//
patient id//
comparison data//
Optronic C man.
inner ocular pressure// store patient id//
inner ocular pressure// patient id// diagonstic inner ocular pressure//
measure IOP data in
automatic glaucoma
patient -/- telephony register -/-
system
record creat the
telephone call finding
-/- medic -/-
b.-p. meter man.
Measure update
blood patient data
blood pressure// blood pressure// medical history//
pressure in HIS
patient -/- heart rate// heart rate// -/- patient id//
patient id//
finding//
patient id//
therapy proposal//
patient id// propose
inform patient therapy
-/- medic -/-
external exit
Abb. 2. Der Selbsttonometrie Prozess
Kurz zum medizinischen Hintergrund: Einige Glaukompatienten (Grüner Star)
müssen den Augeninnendruck (IOP, inner ocular pressure) über einen längeren
Zeitraum selbstständig messen. Um den Ablauf zu optimieren, können die Patienten
ihre Daten mit Hilfe eines automatischen Telefoniesystems an die Klinik übermitteln.
Dabei muss der Patient sich authentifizieren und dann seine Daten eingeben. Vom
automatischen Telefoniesystem werden die Daten an das KIS (Abrechnung) und an
die zentrale Glaukomdatenbank (Forschung) weitergeleitet. Ein Augenarzt überprüft
regelmäßig die Daten und verordnet eine Therapie oder eine weitere Untersuchung.
In diesem vereinfachten Beispiel soll die Datenübertragung des automatischen
Telefoniesystems in das KIS und das zentrale Glaukomregister unter Verwendung der
PDL Methodologie konfiguriert werden.
Das abgebildete Prozessmodell ist nicht nur eine graphische Repräsentation des
Prozesses. Das verwendete Modellierungswerkzeug (I>PM [6]) erlaubt eine um-
fassende, aspektorientierte Beschreibung mit allen für die PDL notwendigen Daten.
Um die Beschreibung für die Konfiguration verwenden zu können, wird ein XML
Export des Modells erzeugt. Dieser wird mit Hilfe eines XSLT Skripts in ein
passendes datenzentriertes XML Modell gewandelt. Im folgenden Ausschnitt ist ein
entsprechend transformierter Prozessschritt zu sehen.
Um von dieser Beschreibung zu einer gültigen Konfiguration für das verwendete
Wrapper-Framework YAWA („Yet Another Wrapper Framework“) [7] zu kommen,
sind folgende Schritte notwendig: 1. Lokalisierung, d.h. die Auswahl der verwendeten
Systeme, 2. Erzeugen der Konfiguration für das Wrapper Framework (eine
Teilkonfiguration ist im folgenden Ausschnitt zu sehen), 3. Erzeugung von ECA
Regeln.
SELECT * FROM All_Pressure_Data
IOP
..
Anhand dieser Fallstudie konnte exemplarisch gezeigt werden, dass durch eine
Änderung des Workflow-Modells automatisiert eine Anpassung der Konfiguration
des Kommunikationssystems erfolgen kann.
5 Fazit
Dieses Papier präsentiert einen Ansatz zur prozessbasierten Konfiguration des Daten-
austausches zwischen klinischen Systemen. Ziel ist dabei eine Versorgung des medi-
zinischen Personals mit relevanter Information entlang des Behandlungsprozesses.
Aus graphisch modellierten Prozessmodellen werden hierzu Datenlogistikprozesse
abgeleitet. Eine Fallstudie verdeutlicht den Ansatz.
Literatur
1 Hammond, W. E., De Moore, G. J. E. (Hrsg.) et al.: “HL7: A Protocol for the
Interchange of Healthcare Data.”. Progress in Standardization in Health Care
Informatics. IOS Press, 1993.
2 Lange M., Prokosch H., Hasselbring W., 1999, Eine Taxonomie für
Kommunikationsserver im Krankenhaus. Informatik, Biometrie und Epidemiologie in
Medizin und Biologie 30 (1), 21-34, 1/1999.
3 Jablonski, S.; Bußler, C.: Workflow management - modeling concepts, architecture and
implementation. London. International Thomson Computer Press, 1996.
4 Reichert M.; Dadam P: A Framework for Dynamic Changes in Workflow Management
Systems. DEXA Workshop 1997.
5 Niemann H., Hasselbring W.: Adaptive Replikationsstrategie für heterogene, autonome
Informationssysteme. In Tagungsband zum 14. GI-Workshop Grundlagen von
Datenbanken, 2002.
6 ProDatO GmbH, i>ProcessManager,
http://www.prodato.de/software/processmanager, Retrieved 2003-12-03.
7 Lang, M.; Lay, R.: Yawa - Yet Another Wrapping Architecture. BTW 2003.