=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== https://ceur-ws.org/Vol-93/paper10.pdf
            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.