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.
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.
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:
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?
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.
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).
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.
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?
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.