E-HEALTH-COM ist das unabhängige Fachmagazin für Gesundheitstelematik, vernetzte Medizintechnik , Telemedizin und Health-IT für Deutschland, Österreich und die Schweiz.
Mehr

Für das ePaper anmelden

Geben Sie Ihren Benutzernamen und Ihr Passwort ein, um sich an der Website anzumelden

Anmelden

Passwort vergessen?

Top-Thema |

» Wir müssen so gut sein, dass die Nutzer:innen begeistert sind «

Die digitale Kommunikation im Gesundheitswesen will moderner werden. Ab dem zweiten Quartal 2023 soll der TI-Messenger („TIM“) den behäbigen E-Mail-Dienst („KIM“) ergänzen – umgesetzt auf dem Open-Source-Protokoll der Matrix Foundation. Dr. Niklas Zender hat als Co-Founder des Unternehmens Famedly viel Erfahrung mit Matrix-basierten Messengern. Was kommt da auf uns zu?

Foto: © Famedly

Warum brauchen wir spezifische Messenger für das Gesundheitswesen?
Das Entscheidende ist nicht, dass der Messenger spezifisch für das Gesundheitssystem ist, sondern dass er Messenger-Protokolle nutzt, die interoperabel sind. Um die Heterogenität des Gesundheitswesens zu adressieren, braucht es Standards. Siehe E-Mail-Kommunikation, die funktioniert gut, und sie funktioniert deswegen gut, weil sie interoperable Protokolle nutzt.

Welche prinzipiellen Möglichkeiten gibt es, Messenger technisch aufzusetzen?
Architektonisch gibt es zwei Möglichkeiten. Das eine ist ­eine zentrale Architektur mit einem Server, mit dem alle ­Clients kommunizieren. Die Alternative ist eine dezentrale Architektur mit vielen Servern, das ist etwas komplexer. Dann gibt es das Thema Verschlüsselung: Wer einen Messenger baut, kann existierende Messenger-Protokolle nutzen und überlegt sich dann, inwieweit eine zusätzliche Verschlüsselung nötig ist oder das Protokoll bereits eine Verschlüsselung anbietet. Das dritte Thema ist die „Sprache“ oder das „Framework“. Da gibt es ziemlich viele Optionen.

Und das macht dann jeder Anbieter unterschiedlich?

Jein. Es gab die große Idee von XMPP, das ist ein dezen­trales Messenger-Protokoll, das sich aber nie so ganz durchgesetzt hat, weil es konzeptionell ein Flickenteppich war. Große Messenger haben teilweise mit XMPP angefangen, bevor sie jeweils alles selbst gemacht haben – und dann nicht mehr interoperabel waren. Grundsätzlich lässt sich ein Messenger technisch sehr schnell bauen, mit Google Firebase innerhalb eines Tages. Die Herausforderungen fangen dann aber erst an.

Ihr nutzt bei Famedly das Matrix Messenger Protokoll, das andere junge Messenger-Hersteller, die jetzt das Gesundheitswesen im Blick haben, auch nutzen. Was ist das genau, wo kommt es her?
Das Matrix Messenger Protokoll wird verwaltet von der Matrix Foundation mit Sitz in England. Es ist ein dezen­trales Protokoll, ähnlich wie XMPP, hat aber von Anfang an auch eine Verschlüsselung mit angeboten. Deswegen lässt es sich recht gut nutzen, um datenschutzkonforme Messenger zu bauen. Daneben kümmert sich die Matrix Foundation auch um Implementierung: Die Matrix ­Foundation liefert immer schon eine Proof-of-Concept-­Implementierung mit, und das ist sehr hilfreich. Da sind wir als Famedly auch aktiv beteiligt: Wir geben immer ­wieder eigene Ideen in die Spezifikation der Matrix Foundation – inklusive Implementierung.

Wird dieses Protokoll schon von etablierten Messengern genutzt, oder ist das etwas Neues?
Das Matrix Protokoll ist etwas Neues. Es wird bisher vor allem in datenschutzsensiblen Kontexten verwendet. Daneben gibt es sogenannte Bridges, die bestehende Messenger mit dem Matrix Protokoll verknüpfen. Die können aber dann keine Ende-zu-Ende-Verschlüsselung durchreichen.

Die gematik hat für den Messenger in der Telematikinfrastruktur, TIM, Ende Juli die Spezifikation 1.1 veröffentlicht, die auf dem Matrix Protokoll aufsetzt. War das eine offensichtliche Entscheidung?
Die gematik hat sich sehr lange mit dem Thema beschäftigt und sich verschiedenste Messenger-Lösungen angesehen. Wenn das Ziel Interoperabilität ist, dann ist Matrix aus unserer Sicht die mit Abstand beste Lösung. Es ist ein Protokoll, das dynamisch ist und aktiv weiterentwickelt wird, deswegen ist es besser als XMPP. Und es ist ein freies Protokoll, das nicht irgendeiner einzelnen Firma gehört. Ich vermute, dass das die ausschlaggebenden Faktoren für die gematik waren.

Was haltet ihr konkret von der Spezifikation? Wo seht ihr noch Klärungsbedarf?
Wir haben die gematik bei der Spezifikation in Teilen beraten, das vielleicht als kleiner Disclaimer. Aus unserer Sicht hat die Spezifikation mittlerweile eine Reife, dass Unternehmen damit arbeiten können. Ich bin kein Fan davon, alles bis zum Ende auszuspezifizieren, ohne es in freier Wildbahn je auszuprobieren. So funktioniert Softwareentwicklung nicht. Die Spezifikation ist gut, sie nutzt Matrix und FHIR, damit ist sie interoperabel. Jetzt geht es darum, attraktive Produkte zu bauen.
 
Warum ist Interoperabilität so wichtig? Und warum FHIR?
Es geht darum, Interoperabilität zu Ende zu denken und einen Messenger aufzusetzen, der in vielen unterschiedlichen Szenarien des Gesundheitswesens funktioniert. Das lässt sich gut am Beispiel Videokonsultationen illustrieren, wo die Interoperabilität leider nicht zu Ende gedacht wurde. Die meisten Videotelefonieanbieter im Gesundheitswesen nutzen denselben Standard, das ist WebRTC, das stark von Google geprägt wird. Dieser Standard ist eigentlich interoperabel. Es fehlt aber das Signalling: Ich kann nicht von einem PVS mit Videotelefonie in ein anderes PVS kommunizieren. Bei TIM ermöglicht FHIR genau das. So können nicht nur Pdf-Dokumente von Chatverläufen von einem Primärsystem ins andere kommuniziert werden, sondern auch strukturierte medizinische Datensätze. Das gilt für das Messaging zwischen Einrichtungen des Gesundheitswesens, und genauso für das Messaging in Richtung Patient:innen und deren elektronischen Patientenakten (ePA).

Vielleicht mal ein Beispiel: Arzt A bittet Ärztin B, kurz auf ein Röntgenbild und einen Laborbefund zu schauen. Das könnte ich mit einem Matrix Messenger umsetzen? Und die Bild- und Labordaten könnte Ärztin B dann gegebenenfalls gleich ins eigene System übernehmen?
Genau. Wir exportieren in einem Datenformat, das andere Systeme abarbeiten können. Wie sieht eine Chatnachricht aus? Wie verschickt man ein Bild so, dass es im Chat schon als Vorschau zu sehen ist? Wie definiert man eine Sprachnachricht? Das sind die Dinge, die das Matrix Protokoll vorgibt. Für die Interoperabilität in Primärsysteme hinein bzw. aus diesen heraus brauchen wir zusätzlich FHIR.

Prinzipiell könnte man das ja alles auch mit E-Mail machen, und im gematik-Kontext ist konkret KIM ein sicherer E-Mail-Dienst, der das tut. Warum kommunizieren wir nicht einfach mit KIM?
E-Mail ist extrem interoperabel, nur leider wurde die Verschlüsselung vergessen. Nachträglich Verschlüsselung einzubauen, ist bei E-Mail relativ kompliziert, deswegen hat sich das auch nie in der Fläche durchgesetzt. Natürlich kann ich E-Mail in gesicherten Netzwerken betreiben, siehe KIM. Da sind aber dann keine Patient:innen drin. Der zweite Vorteil von Messengern ist, dass sie ein Chatprotokoll und kein E-Mail-Protokoll nutzen. Das Chatprotokoll ist echtzeitfähig, und damit kann ich nicht nur Textnachrichten, sondern auch Video-Use-Cases und Internet-of-Things-Use-Cases aller Art unkompliziert abbilden. Das ist im Gesundheitswesen attraktiv. Man kann ja nicht jede Sekunde eine E-Mail schicken, wenn man ein Herzgeräusch übertragen will, und schon gar nicht jede dieser E-Mails mit einer Smartcard verschlüsseln. Mit einem Chatprotokoll ist das alles kein Problem. Es verschickt strukturierte, verschlüsselte Nachrichten in eine Datenbank, die mit anderen geteilt wird. Ein weiterer Vorteil: Ich weiß zum Beispiel bei einer E-Mail nicht, ob mein Empfänger die bekommen hat. Bei einer Chatnachricht weiß ich das.

Was brauche ich als Nutzer:in, um einen künftigen TI-Messenger zu nutzen?
Der TI-Messenger funktioniert entweder über eine Web-Applikation oder bei mobiler Nutzung über eine App. Das ist genauso wie bei allen anderen Messengern. Dadurch dass die Nachrichten Ende-zu-Ende verschlüsselt sind, können die TIM-Server unter Beachtung der Vorgaben der DSGVO im Prinzip überall stehen. Für TIM heißt das: Die Server werden nicht innerhalb der TI oder bei der gematik sein, die können im Krankenhaus stehen, in irgendeinem Rechenzentrum, sogar in einer Public Cloud.

Und als Nutzer:in bin ich auch unabhängig von Konnektoren und Karten?
Ja und nein. Konnektoren sind nicht nötig. Aber natürlich müssen Nutzer:innen authentifiziert werden. Das kann man auf unterschiedliche Weise machen. Die Karten haben da ein paar Vorteile: Sie liefern das kryptographische Material, das wir brauchen, also die digitalen Schlüssel, die sonst irgendwo anders digital abgelegt werden müssten. Die gematik-Vorgabe lautet: Die Nutzer:innen sollen mit Blick auf eine gute Usability möglichst wenig mit den Karten machen müssen. Deswegen werden die Karten beim TI-Messenger nur beim Onboarding benötigt – und bei administrativen Aufgaben. Das ist auch ein Novum und ein wichtiges Merkmal der TI-Messenger: Die medizinischen Einrichtungen können ihre eigenen Arbeitsstrukturen im Messenger abbilden, z.B. selbstständig Kontaktstellen für die Kardiologie, die Augenheilkunde usw. einrichten und diese in das gematik-Verzeichnis eintragen. Kliniken können ihren Messenger also selbst mithilfe der Karten und des zentralen Verzeichnisses bei der gematik administrieren, ohne den Weg über die Kartenherausgeber. So können ganz einrichtungsindividuelle Kommunikationsprozesse abgebildet werden.

Welche Karten genau werden denn genutzt? SMC-B? HBA? Beides?
So wie es im Moment geplant ist, startet man in den TI-Messenger immer als Organisation. Das heißt, für das Onboarding ist primär eine SMC-B nötig, sei es die einer Praxis oder die eines Krankenhauses. Denkbar ist natürlich auch, dass zum Beispiel Ärzteverbände für ihre Mitglieder TI-Messenger zur Verfügung stellen. Auch dann ist es aber nicht der einzelne Arzt, sondern der jeweilige Verband, der sich gegenüber der gematik authentifiziert. Der HBA kommt dann ins Spiel, wenn sich Ärzt:innen unabhängig von Organisationen untereinander vernetzen wollen. Wenn ich also Teil einer gegenüber der gematik authentifizierten Organisation bin, kann ich zusätzlich eine Authentifikationsstufe hochgehen und mich als Person mit dem HBA authentifizieren. Das schaltet mich dann frei, sodass ich auch andere HBA-Inhaber sehen und mit ihnen direkt kommunizieren kann. Der jeweilige HBA-Inhaber soll dabei wählen können, ob er im Verzeichnisdienst für alle sichtbar ist oder nicht. Das alles erspart der gematik, für ein paar Millionen Menschen im Gesundheitswesen Account-Management zu machen. Das ist Aufgabe der jeweiligen Organisationen, und da ist es auch besser aufgehoben.

Die gematik plant das Go-live für TIM in der Version 1.1 für das zweite Quartal 2023. Realistisch?

Realistisch. Wir warten auf die Testinfrastruktur, gegen die wir testen können, und würden dann sofort in die Zulassung gehen.

TIM soll dann weiterentwickelt werden in Richtung TIM 2.0. Ab etwa 2024 sollen dann auch Patient:innen anbindbar sein. Wie könnte man sich eine solche Anbindung konkret vorstellen?
Was die Kommunikation angeht, muss TIM sicherstellen, dass Patient:innen zwar in Chatgruppen mit Ärzt:innen bzw. Einrichtungen eingebunden werden können. Sie dürfen aber nicht untereinander ohne Leistungserbringer:innen kommunizieren, denn TIM soll ja nicht private Messenger ersetzen. Das ist aus unserer Sicht mit der TIM-Spezifikation gut umsetzbar. Was die Authentisierung angeht, sehen wir die Krankenkassen als naheliegende Organisationen an. Ich sehe keinen Grund, warum die Patient:innen ihre digitale Identität, die sie für die ePA erhalten, nicht auch für TIM nutzen sollen.

TIM Version Stufe 3.0 soll Videokonsultationen ermöglichen, mit Zeithorizont 2025. Technisch geht das?
Wir haben Videotelefonie schon integriert. Die Eins-zu-eins-Videotelefonie ist fest im Matrix Protokoll verankert, die Gruppenvideotelefonie wird gerade spezifiziert. Da muss die gematik dann nicht mehr viel machen.

Was ist eure Strategie, wenn es in 2023 ernst wird? Wie geht ihr an den Markt heran? Wer sind eure Ansprechpartner:innen?

Wir wissen mittlerweile sehr gut, was funktioniert und was nicht, und konzentrieren uns deswegen aktuell voll auf das Produkt. Am Ende muss das Produkt so gut sein, dass die Nutzer:innen begeistert sind, einen Messenger zu nutzen. Das Zweite ist das Thema Enterprise-Fähigkeit. Matrix und FHIR bilden viel ab, aber natürlich muss sich TIM in die Prozesse der jeweiligen Einrichtungen einfügen, es muss verwaltbar sein, es müssen Löschroutinen und Ähnliches implementiert werden. Das sind ganz zentrale Themen, mit denen wir uns im Moment beschäftigen, und wir reden dazu sehr viel mit den Nutzer:innen und den Einrichtungen, um wirklich eine Lösung anbieten zu können, die den Bedarf adressiert. Was die Ansprechpartner:innen angeht: Wir arbeiten aktuell vor allem mit großen Kliniken, schon deswegen, weil wir als Gründer beide Klinikärzte waren. Wir glauben, dass der Mehrwert eines guten Messengers innerhalb des Klinik­umfelds und in der Kommunikation zwischen dem Klinikum und kooperierenden Einrichtungen besonders hoch ist. Parallel arbeiten wir außerdem mit einigen Herstellern von Primärsystemen zusammen, für die es attraktiv sein kann, den Messenger in die eigenen Produkte zu integrieren. Das kann gerade auch im ambulanten Markt Sinn machen, wo viele Ärzt:innen aus guten Gründen partout nicht noch ein zusätzliches System parallel nutzen wollen.

Vielleicht noch mal ganz konkret zwei Szenarien: Zum einen Zuweiserkommunikation, zum anderen oberärztlicher Bereitschaftsdienst im Krankenhaus. Wie kann ein TI-Messenger hier sinnvoll eingesetzt werden?

Nehmen wir die Kardiologie, die einen Zuweiser-Workflow für den Herzkatheter umsetzen will. Da würde das Krankenhaus seine Zuweiser als Kommunikationsteilnehmer administrieren. Die könnten dann mit der Kardiologie per TIM kommunizieren, idealerweise aus dem PVS heraus. Wir würden dann Kommunikations-Workflows hinterlegen, die sicherstellen, dass die Kardiologie auch alle Informationen bekommt, die sie benötigt bzw. dass fehlende Informationen automatisch nachgefragt werden. Was Bereitschaftsdienste angeht: Hier sind oft rollenbasierte Workflows sinnvoll, die nicht Person XY ansteuern, sondern zum Beispiel den diensthabenden HNO-Arzt. Hier bieten wir mit unserem Produkt Lösungen an, die genau solche rollenbasierten Workflows ermöglichen.

Wie aufwendig sind derartige Integrationen?

Wir werden besser. Im Idealfall verstehen die KIS-Hersteller bzw. die Krankenhäuser über eine Interoperabilitätsschicht FHIR und können dann unsere FHIR-Schnittstelle direkt nutzen, um sich Daten zu holen oder sie an uns zu übermitteln. Das ist das Einfachste. Die andere Möglichkeit besteht darin, unseren Clienten einzubinden ins KIS. Da ist dann allerdings etwas Programmieraufwand nötig. Wir würden deswegen lieber über eine inter­operable FHIR-Datenschicht gehen, was auch den Vorteil hat, dass sich die Primärsystemhersteller bzw. die Krankenhäuser nicht noch mit der Matrix-Welt auseinandersetzen müssen.

Was ist das komplexeste Szenario, das ihr in euren Pilotierungen bisher umgesetzt habt?

Der komplexeste Prozess, den wir aktuell abbilden, ist an der Uniklinik Frankfurt. Hier werden Patient:innen in die Klinik aufgenommen, und wenn bestimmte Kriterien erfüllt sind, wird quasi ein fallbasierter Chatraum erstellt. Und dann laden wir rollenbasiert die Personen ein, die für die Versorgung jeweils verantwortlich sind und zeigen die auch an. Ärzt:innen und Pflegekräfte haben entsprechend eine Liste all ihrer Patient:innen mit den jeweiligen Chaträumen und können da jeweils kommunizieren. Die Nachrichten, die in diese Chaträume eingestellt werden, werden ins KIS exportiert und erscheinen dort als Chatverlauf. Außerdem wird zusätzlich der komplette Chatverlauf ins Archivsystem übertragen. Mittlerweile tracken wir in Frankfurt auch den aktuellen Aufenthaltsort der Patient:innen und können die Zusammensetzung des Personals in den Chaträumen entsprechend ändern. Wenn also ein Patient von der Augenheilkunde in die Innere geht, dann ändert sich die Zusammensetzung der betreuenden Personen im Chatraum. Das ist schon sehr cool, und es eröffnet gerade auch im Zusammenhang mit Dienstarztszenarien enorme Möglichkeiten.