gms | German Medical Science

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

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie

06.09. - 09.09.2015, Krefeld

Transformation von medizinischen Gerätedaten mittels Raspberry Pi

Meeting Abstract

  • Toni Barthel - Technische Hochschule Mittelhessen, Gießen, Deutschland
  • Ljudmila Mursina - Technische Hochschule Mittelhessen, Gießen, Deutschland
  • Andreas Weissflog - ThoraTech GmbH, Gießen, Deutschland
  • Keywan Sohrabi - Technische Hochschule Mittelhessen, Gießen, Deutschland; Kompetenzzentrum für Informationstechnologie (KITE), Gießen, Deutschland

GMDS 2015. 60. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (GMDS). Krefeld, 06.-09.09.2015. Düsseldorf: German Medical Science GMS Publishing House; 2015. DocAbstr. 163

doi: 10.3205/15gmds085, urn:nbn:de:0183-15gmds0851

Published: August 27, 2015

© 2015 Barthel et al.
This is an Open Access article distributed under the terms of the Creative Commons Attribution 4.0 License. See license information at http://creativecommons.org/licenses/by/4.0/.


Outline

Text

Einleitung: In den vergangen Jahren haben kleine Minicomputer, wie der Raspberry Pi, die Elektronikwelt nachhaltig verändert. Die immer kleiner und günstiger werdende Technik ermöglicht es, leistungsfähige Komponenten auf einer Platine in der Größe einer EC-Karte unterzubringen. Doch wie können diese kleinen Minicomputer in der medizinischen Informatik Anwendung finden?

Eine Möglichkeit ist es, mittels dieser kleinen Computer medizinische Geräte in ein klinisches Netzwerk einzubinden. Die Anbindung von medizinischen Geräten ist ein zentrales Thema in der medizinischen Informatik. In den vergangen Jahren bestand die Tendenz darin, medizinische Geräte über ein zentrales Kommunikations-Gateway anzubinden [1]. Häufig erfolgt die Anbindung der Geräte über eine zusätzliche Hardwarekomponente [2]. Anschließend werden die Rohdaten an einen Kommunikationsserver übermittelt. Der Kommunikationsserver übersetzt daraufhin die Parameter in eine Syntax, die das Zielsystem verarbeiten kann.

Mittels der kleinen Minicomputer müsste es möglich sein, die Daten aus einem medizinischen Gerät auszulesen, zu transformieren und direkt an das Zielsystem zu senden. Der Vorgang könnte dabei ohne den Umweg über einen Kommunikationsserver und damit dezentral erfolgen. Daraus ergibt sich eine weitere Fragestellung: Könnte sich mittels eines Minicomputers der Kommunikationsserver als „Single-Point-of-Failure“ umgehen lassen? Dafür wäre es erforderlich, die Eigenschaft der Daten-Transformation des Kommunikationsservers mit der Fähigkeit des Auslesens von Gerätedaten einer externen Hardwarebox zu verknüpfen.

Material und Methoden: Zur Lösung der Problemstellung wird ein Raspberry Pi 2 Model B [3] verwendet und die Transformations-Software in der Programmiersprache Java entwickelt. Die entwickelte Box wird anschließend mit einem Beatmungsgerät und dem PDMS verbunden, um die Funktionalität in einer testgetrieben Entwicklung sicherzustellen. Die Gerätedaten werden über eine RS232-Schnitstelle abgefragt, in der Applikation gepuffert und anschließend zu einem HL7-ORU-Datensatz (HL7v2x) [4] zusammengesetzt. Die Konfiguration des angebundenen Gerätes erfolgt über ein durch XSD validiertes XML-File. Der Speicherplatz der Box beträgt 64Gb.

Um die entwickelte Lösung methodisch mit bisherigen Ansätzen zu vergleichen wurde ein Standard-Schnittstellentreiber auf einem PC installiert, welcher mit dem Beatmungsgerät verbunden ist. Der Computer kommuniziert mit einem Mirth-Connect-Kommunikationsserver (vergleiche [2]), dabei werden die Rohdaten des Beatmungsgeräts übermittelt. Der Mirth-Connect-Server [5] transformiert diese Daten in einen HL7v2x-Stream und sendet diesen an ein eine Filemaker-Datenbank (als PDMS-Ansatz). Die HL7-Nachrichten werden über eine Java-Schnittstelle direkt in die Filemaker-Datenbank eingetragen.

Ergebnisse: Im Projekt wurde die gesamte Soft- und Hardwarekomponente erfolgreich entwickelt. Das Kernstück der Software ist das entwickelte Konfigurationsfile, welches beliebig viele Parameter vom angebunden medizinischen Gerät, als Konzepte, abbildet. Weiter ist durch die Abbildung des proprietären Protokolls auf XML-Ebene die Möglichkeit gegeben, viele andere Gerätetreiber zu übersetzen. Aufgrund dessen, dass für jedes angebundene Gerät eine individuelle Konfiguration erfolgt, ist es möglich, für jedes Gerät ein beliebiges Zielsystem zu definieren. In der Konfigurationsebene der angebundenen Geräte können zwei unterschiedliche Intervalle angegeben werden. Das erste Intervall fragt die Daten vom Gerät in angegebener Frequenz ab und das zweite Intervall schickt die Daten an das entsprechende PDMS. Die in der Zwischenzeit ermittelten Datensets werden gespeichert. Somit wird eine rückwirkende Datenübernahme ermöglicht. Hinzukommt, dass alle abgefragten Gerätedaten mind. 72 Stunden auf der Box gespeichert werden. Nicht erfolgreich gesendete HL7-Mitteilungen werden gesendet, sobald das Zielsystem wiederverfügbar ist. Die Patientenzuordnung erfolgt ebenfalls in der Gerätekonfiguration, via Standard-Angabe in HL7 oder über ein HL7-Z-Segment.

Die gesamte Konfiguration der Hardware-Box erfolgt individuell über einen Webservice (dezentral) oder im Cluster (zentral).

Weiter wird mit der entwickelten Box das Netzwerk deutlich entlastet. Dieser Faktor ist abhängig von dem gewählten Übertragungsintervall. Dies ist in der Tatsache begründet, dass die vielen Datensets, die bei der Abfrage des Gerätes erzeugt werden, nicht mehr unmittelbar nach Erzeugung über das Netzwerk kommuniziert werden. Bei 100%iger Übertragung der erzeugten Daten, ergibt sich eine Entlastung von ~97% pro Gerät. Dies sei wie folgt definiert: Ein Datensatz besitzt die Größe von 10kb und wird unmittelbar alle 60s an den Kommunikationsserver geschickt. Das Datenvolumen beträgt nach 10 Minuten 600kb. Werden diese Daten aber zwischengespeichert und im Standardintervall nur alle 5 Minuten verschickt reduziert sich das zu übertragende Gesamtvolumen auf 20kb in 10 Minuten da nur zwei Übertragung erfolgen.

Diskussion: Die ersten Feldversuche mit einem turbinen-gesteuerten Beatmungsgerät zeigen, dass Minicomputer einen zweckmäßigen Einsatz in der medizinischen Geräteanbindung haben können. Die Kombination von Eigenschaften eines Kommunikationsservers (Transformation und Routing von Daten) und einer zusätzlichen Hardwarekomponente (Auslesen von Gerätedaten) zeigen eine deutliche Vereinfachung der Gerätestruktur.

Gleichzeitig stellt sich bei näherer Betrachtung heraus, dass auch sicherheitstechnische Aspekte anders zu bewerten sind [6]. Ein Kommunikationsserver fungiert häufig als Mittelpunkt in einem Kommunikations-Gateway. Damit bildet er einen „Single-Point-of-Failure“ und eignet sich hervorragend für eine „Man-in-the-Middle“-Attacke. Durch die entwickelte Lösung werden beide Problemstellungen umgangen. Damit ist durch den Einsatz der Hardware-Box eine höhere Systemsicherheit gegeben.

Weiter ist beim Aufbau der Testumgebung mit dem verwendeten Kommunikationsserver Mirth-Connect aufgefallen, wie einfach korrumpierte Daten durch eine fehlerhafte Translationseinstellung erzeugt werden können. Eine solche Einstellung betrifft immer den gesamten Kommunikationskanal und somit mehrere medizinische Geräte. Korrumpierten Daten bergen ein hohes Sicherheitsrisiko für den Patienten, da auf Basis der von den Gerätedaten übermittelten Vitalparameter ggf. falsche medizinische Entscheidungen getroffen werden. Bei der entwickelten dezentralen Lösung wird jedes Gerät einzeln konfiguriert. Folglich können großflächig korrumpierte Daten vermieden werden. Aber auch mit der entwickelten Box ist es nicht absolut außerhalb jeder Wahrscheinlichkeit, dass durch fehlerhafte Konfiguration korrumpierte Daten entstehen.

Gleichzeitig zeigt die Verbindung der Eigenschaften eines Kommunikationsservers mit denen einer Hardwarebox, dass der administrative Aufwand anders zu bewerten ist. Der Konfigurationsaufwand wird bei der ersten Inbetriebnahme etwas höher sein, da jede Box einzeln integriert werden muss. Durch die Möglichkeit der Administration mehrerer Boxen im Cluster ist jedoch eine vereinfachte Möglichkeit zur Verwaltung mehrerer Boxen gegeben. Durch weitere Praxistests muss evaluiert werden, wie komfortabel eine solche Cluster-Administration tatsächlich ist. Letztlich wird zukünftig auch eine Übersetzung in HL7v3 notwendig sein.

Eine nachfolgende Zielstellung des Projektes ist es, einem „Plug and Play“-Gedanken gerecht zu werden und eine allgemein gültige Bibliothek zur Translation von proprietären Geräteprotokollen zu entwickeln.


Literatur

1.
Sunyaev A, Leimeister JM, Schweiger A, Krcmar H. Integrationsarchitektur für das Krankenhaus. In: IMC Information Management & Consulting. 2006. S. 28-35.
2.
Röhrig R, Rüth R. Intelligente Telemedizin in der Intensivstation. Bundesgesundheitsblatt für Gesundheitsforschung und Gesundheitsschutz. 2009:279-286.
3.
Raspberry Pi, Raspberry Pi 2 Model B. http://www.raspberrypi.org/products/raspberry-pi-2-model-b/, letzter Besuch 20.02.2015 External link
4.
Health Level 7 Dokumentation, HL7 Deutschland e.V. http://www.hl7.de/standard/standards.php, letzter Besuch 20.02.2015 External link
5.
Mirth-Connect-Server. https://www.mirth.com/Products-and-Services/Mirth-Connect, letzter Besuch 21.06.2015 External link
6.
Gärnter A. IEC 80001: Risikomanagement vernetzter Systeme. In: Telemedizinführer Deutschland. 2008. S. 40-44.
7.
Moxa®. UC-7408, UC-7408 Plus. http://de.moxa.com/product/UC-7408.htm, letzter Besuch: 20.02.2015 External link