Im Fahrzeug ist die Medizin längst angekommen: Tritt dort ein Defekt auf, werden Diagnosesysteme eingesetzt, um mögliche Ursachen zu ermitteln. Fahrer können über Health-Checks jederzeit den Gesundheitszustand ihrer Fahrzeuge überprüfen. Umgekehrt gibt es in der Medizintechnik bislang scheinbar wenig Impulse aus dem Automotive-Bereich. Aber haben Patienten und Fahrzeuge etwas gemeinsam? Auf den ersten Blick: Nein.
Weitet man jedoch den Blick und filtert die Wahrnehmungen nach IT-Gesichtspunkten, kann man durchaus Übereinstimmungen finden. In diesem Beitrag wollen wir deshalb eine Brücke schlagen, von der Ist-Situation bei Telematik IT-Architekturen im Fahrzeug, hin zu den Chancen und Möglichkeiten, die sich daraus für Patientensysteme ergeben.
Message-Broker Architekturen als Rückgrat des Connected Car
In der erweiterten Automotive-IT und insbesondere im Telematik-Umfeld haben Message-basierte Architekturen Einzug gehalten und bewähren sich in der täglichen Praxis. Worum geht es dabei? Ein zentraler Message-Broker sammelt Telemetriedaten des Fahrzeuges, genauer gesagt von Fahrzeugsensoren, und stellt sie abnehmenden Systemen zur Verfügung. Bewegungs- und Statusdaten eines Fahrzeugs werden von dem Message-Broker temporär gehalten und auf Anfrage verteilt.
Carsharing Anwendungsfälle nutzen beispielsweise solche Message-Broker Architekturen, um auf Basis der Telemetriedaten Mietvorgänge zu starten und zu beenden, Vorschläge für Ladevorgänge zu erstellen, Angebote bei Zwischenstopps zu unterbreiten oder Vorhersagen über die Verfügbarkeit der Mietflotte zu treffen.
Wie funktioniert eine Message-Broker Architektur?
Gängige Message-Broker Architekturen basieren auf dem MQTT-Protokoll (Message Queuing Telemetry Transport). Ein Netzwerkprotokoll, das ursprünglich für die Machine-to-Machine Kommunikation (M2M) von Telemetriedaten im IoT (Internet of Things) entworfen wurde. MQTT-Architekturen ermöglichen den Nachrichtenaustausch trotz Verzögerungen oder eingeschränkter Netzwerkinfrastruktur.
Ein Fahrzeug ist kurzfristig offline und kann Nachrichten nicht empfangen, weil es durch einen Tunnel fährt. Eine MQTT-basierte Architektur berücksichtigt das und hält die Nachricht so lange vor, bis das Tunnelende erreicht ist.
Eine MQTT-Architektur beruht auf folgenden Prinzipien:
- Die beteiligten Systeme bestehen aus MQTT-Clients (liefern und beziehen Nachrichten) und einem MQTT-Broker (verteilt Nachrichten)
- Der Nachrichtenaustausch basiert auf dem publish / subscribe Muster: Als MQTT-Client kann man Nachrichten liefern (publish) oder sich auch für den Bezug von Nachrichten anmelden (subscribe)
- Nachrichten werden über ein hierarchische Topic-Struktur verwaltet. Ein MQTT-Client kann sich auf verschieden abstrakten Ebenen der hierarchischen Baumstruktur anmelden.
- Nachrichten werden vom Broker an den Client nach vorab definierten Service-Leveln geliefert – sogenannten Quality of Service (QoS): höchstens einmal, mindestens einmal oder genau einmal.
Vom vernetzten Fahrzeug zum vernetzten Patienten
Zwischen den Anwendungen im Connected Car-Umfeld und dem Healthcare-Bereich gibt es Parallelen: Wie beim Fahrzeug liefern viele Sensoren bzw. analysierende Systeme Informationen des bzw. über den Patienten: Vitaldatenmonitore, Infusomate, Mini-EKG Geräte, etc. Die Liste ließe sich beliebig lange fortsetzten. Zugegeben, die Telemtriedaten des Patienten werden heute schon an die betreffenden Stellen weitergeleitet, aber oft auf proprietären Infrastrukturen und in lokale Datensenken.
Aber was wäre möglich, wenn man – basierend auf dem für IoT-Geräte optimiertem MQTT-Protokoll – die Daten vereint und daraus Mehrwert ziehen könnte?
Die wichtigsten Use Cases für die Telemedizin
Der entspannte Patient
Der Pfleger läuft auf dem Krankenhausgang an einem Patientenzimmer vorbei und sieht auf seinem Tablet, Smartphone oder sonstigem Endgerät den Infusionsstatus des Patienten. Der Pfleger wird nicht erst dann informiert, wenn die Infusion abgelaufen ist, sondern hat zu jedem Zeitpunkt den Überblick. Der Patient kann entspannt bleiben und muss sich nicht darum kümmern, den Pfleger zu informieren, dass die Infusion abgelaufen ist (was ohnehin vermieden werden soll).
Die Daten liefern die Infusomate an einen zentralen MQQT-Broker. Ein AR Service nimmt als MQQT-Client die Statusdaten ab und liefert sie an eine AR-Brille.
Wo ist der nächste Rollstuhl?
Ein Termin in der Radiologie steht an und der Patient muss mit einem Rollstuhl dorthin gebracht werden. Aber wo ist der nächste freie Rollstuhl? Ganz einfach: GPS basierte tags sind an Rollstühlen befestigt und liefern ihre Position an einen MQTT-Broker. Ist ein Teil des Krankenhauses mit WLAN nicht abgedeckt, kann eine Kamera mit Rollstuhl-Bilderkennung die Position übermitteln.
Wieder könnte ein Endgerät für den Pfleger den Hinweis auf den nächsten freien Rollstuhl liefern, inkl. die Navigation dorthin. Oder der Pfleger wird über eine mobile Anwendung informiert: Patient X hat in 10 min. einen Termin in der Radiologie (Terminkalender kommuniziert seinen Termin) und der nächste freie Rollstuhl steht am Ende des Nachbargangs (Abgleich Termin mit dem nächsten freien Rollstuhl).
Messrunden vermeiden
Heute nimmt der Pfleger in sogenannten Messrunden Patientendaten vor Ort auf: Puls, Temperatur, Blutdruck oder den Blutzuckerwert. Die Werte werden manuell erfasst und geben den Status zu einem Zeitpunkt wieder.
Was wäre möglich, wenn die Daten stetig und ohne manuellen Aufwand zentral vorliegen würden? Ein an den MQTT-Broker verknüpfter Service erkennt einen Puls von 92 und die Blutdruckwerte von 100/40, schließt daraus eine potenzielle innere Blutung (z.B. gastrointestinal) und informiert die Pfleger*innen.
Bessere Message-Broker Architekturen durch Datenmodellierung
Ein wichtiger, wenn nicht gar ein entscheidender Erfolgsfaktor, beim Aufsetzen einer Message-basierten Architektur ist die Datenmodellierung. Ein MQTT-Broker beschreibt einen Teil der Daten in einer sogenannten Topic-Struktur. Mit ihrer Hilfe kann zu den Teilaspekten eines Objektes navigiert werden; oder der Navigationspfad beinhaltet selbst fachliche Daten. Die Topic-Struktur eines MQTT-Brokers ist hierarchisch. Aus unserer Erfahrung gilt es zu klären: wie bildet man ein fachliches Modell hierarchisch ab und wann nimmt man redundante hierarchische Pfade in Kauf, z.B. aus Performance-Gesichtspunkten?
Der Patient als zentrales Objekt
Zentrales Objekt muss dabei immer der Patient sein. Für ihn liefern Systeme auf unterschiedlichsten Ebenen Daten: von ADT-Nachrichten basierten Systemen bis hin zu Diagnosesystemen. Message-basierte Systeme sind dabei kein Selbstzweck und sollen Daten nicht ohne Ziel integrieren: Es kommt darauf an, einen Mehrwert aus der Kombination abzuleiten (der Patient hat einen Termin, der Patient muss transportiert werden, wo steht ein freier Rollstuhl zur Verfügung).
Mit Vernetzung und geeigneten Systemarchitekturen lassen sich sowohl für Patienten als auch für Pflegekräfte ehebliche Erleichterungen erzielen. Informationen und Daten liegen bereits vor. Sie müssen lediglich zusammengebracht und daraus Synergien gezogen werden.
Ulrich Bonn ist Projektbereichsleiter bei iteratec und beschäftigt sich dort schwerpunktmäßig mit Digitalisierungslösungen für die Automotive- und Gesundheitsindustrie sowie den öffentlichen Sektor.