Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

TI-Messenger für das ePA FdV
(TI-Messenger Stufe 2)

    

     

      
Version
      
0.5.0_CC
     
     

      
Revision
      
796437
     
     

      
Stand
      
15.12.2023
     
     

      
Status
      
zur Abstimmung freigegeben
     
     

      
Klassifizierung
      
öffentlich_Entwurf
     
     

      
Referenzierung
      
gemSpec_TI-Messenger_ePA-FdV
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einleitung

Versicherte können zukünftig über einen TI-Messenger-Client im Frontend des Versicherten der ePA sicher und schnell medizinische Inhalte austauschen. Dadurch wird der Nutzerkreis für den TI-Messenger um Versicherte erweitert und es ergeben sich neue Möglichkeiten zur Kommunikation im Gesundheitswesen.

1.1 Einordnung des Dokuments

Das vorliegende Dokument stellt die Zusammenfassung der Konzeption und den ersten Entwurf der Spezifikation eines in das Frontend des Versicherten integrierten TI-Messenger-Clients sowie eines TI-Messenger Fachdienstes für Versicherte durch die gematik dar.

1.1.1 Zielsetzung

Im vorliegenden Dokument soll auf Basis der aktuellen Überlegungen der gematik die Architektur des in das Frontend des Versicherten integrierten TI-Messenger-Clients dokumentiert werden.

1.1.2 Zielgruppe

Die Spezifikation richtet sich dabei an alle Stakeholdergruppen der gematik, insbesondere an Vertreter aus der Industrie, Angehörige zukünftiger Nutzerkreise und an die interessierte Öffentlichkeit.

1.1.3 Abgrenzungen

Das vorliegende Dokument dient als Grundlage für Ausschreibungen an die Industrie sowie für die Abstimmung mit Nutzern und als Basis für die nachfolgende Spezifikation.

In dieser Grobspezifikation werden die Änderungen gegenüber den TI-Messenger Spezifikationen in den Versionen 1.1.1, insbesondere für die hier relevante Gruppe der Versicherten, dargestellt. Die nicht geänderten Festlegungen in den Spezifikationen der Versionen 1.1.1 gelten mit, sofern sie für Versicherte relevant sind.

Die hier getroffenen Festlegungen werden nachfolgend mit den Spezifikationen der Versionen 1.1.1 zusammengeführt und als eigenständige Spezifikationen des TI-Messengers für Versicherte veröffentlicht und ersetzen dann die vorliegende Grobspezifikation.

Diese erste Version der Spezifikation des TI-Messengers für Versicherte enthält nur die unbedingt notwendigen Funktionen, damit eine schnelle Einführung zusammen mit dem ePA FdV Version 2.0 möglich ist.

2 Randbedingungen

Der Gesetzgeber hat die gematik beauftragt Maßnahmen durchzuführen, um einen Sofortnachrichtendienst("TI-Messenger“) im Gesundheitswesen zu etablieren. In der ersten Ausbaustufe des TI-Messengers können Leistungserbringer miteinander kommunizieren (vgl. §311 SGB V). In der zweiten Ausbaustufe können Versicherte den TI-Messenger als Kommunikationsmittel mit Leistungserbringern und Krankenkassen verwenden (vgl. 342, Absatz 2 SGB V).

3 Lösungsstrategie

Für Versicherte, als neue Nutzergruppe des TI-Messengers - im Folgenden auch kurz "TI-M" genannt -, sind zusätzliche Funktionen und Änderungen an bestehenden Funktionen des TI-Messengers der ersten Stufe erforderlich. Daher wird ein spezifischer TI-M Client für Versicherte als neuer Produkttyp eingeführt, der viele Eigenschaften des bisherigen TI-Messenger-Clients für Akteure übernimmt, aber auch versichertenspezifische Änderungen enthält.

Um eine Trennung zwischen Versicherten und den TI-M Akteuren aus der TI-M 1.x-Spezifikation zu erreichen, wird neben einem TI-M Client für Versicherte auch ein entsprechender TI-M Fachdienst für Versicherte als neuer Produkttyp eingeführt. Der Org-Admin-Client bleibt als solcher bestehen und dient der Krankenkasse zur Verwaltung ihrer Messenger-Services.

Aus den Erfahrungen mit der Entwicklung von TI-Messenger Lösungen wurde erkannt, dass das Berechtigungsmodell vereinfacht werden muss. Grundsätzlich gilt nun, dass jeder mit jedem TI-M Nutzer kommunizieren kann; mit der Ausnahme, dass Versicherte untereinander keine Kommunikation aufbauen können. Um zu ermöglichen, dass die Nutzer entscheiden können, mit wem oder welchen Nutzergruppen sie kommunizieren möchten, ermöglicht der TI-M Client die Konfiguration von Regeln, die die Erreichbarkeit durch andere Nutzer und Nutzergruppen steuern.

Die Identifizierung sowie Authentifizierung und Autorisierung um einen TI-Messenger Account zu erhalten, erfolgt unter Nutzung des sektoralen IDPs. Die Authentifizierung des Versicherten am ePA Fachdienst soll für den TI-Messenger mittels Single Sign On nachgenutzt werden können, sofern dies der sektorale IDP unterstützt.

Die Suche für Versicherte im Verzeichnisdienst (VZD, FHIR-Directory) nach LE und LEI wird nicht eingeschränkt. Durch das neue Berechtigungsmodell kann jeder Versicherte für sich die Erreichbarkeit durch andere Nutzer einstellen. Das bedeutet jedoch, dass das neue Berechtigungsmodell auch für TIM 1.x Implementierungen eingeführt werden muss.

Damit Leistungserbringer (LE) mit ihren Patienten über den TI-Messenger kommunizieren können, muss die TI-M Adresse (MXID) des Patienten bekannt sein. Der Arzt kann aus den Stammdaten des Patienten die MXID anhand einer Bildungsregel ableiten.

4 Kontextabgrenzung

4.1 Fachlicher Kontext

In diesem Konzept werden der TI-M Client für Versicherte und der TI-M Fachdienst für Versicherte betrachtet. Anpassungen für andere Nutzergruppen werden nur betrachtet, wenn es für die Interoperabilität erforderlich ist.

Abbildung 1: Kontextabgrenzung

Der TI-M Client für Versicherte hat Schnittstellen

• zu anderen TI-M Clients zum Austausch von Kontaktinformationen,
• zu Zero Trust Komponenten, sobald verfügbar,
• zum sektoralen IDP. Es werden die gleichen Verfahren wie beim ePA FdV (mit Single Sign On, wenn vorhanden (siehe [gemSpec_IDP_Frontend]) verwendet,
• zum Verzeichnisdienst zur Suche nach Kontakten in Organisationen,
• zum externen Push Provider um Benachrichtigungen zu erhalten,
• zum TI-Messenger-Fachdienst für Versicherte.

Der TI-M Fachdienst für Versicherte hat Schnittstellen

• zu TI-M Clients für Versicherte,
• zu Zero Trust Komponenten, sobald verfügbar,
• zum sektoralen IDP. Es werden die gleichen Verfahren wie beim ePA FdV mit Single Sign On verwendet, wenn vorhanden (siehe [gemSpec_IDP_Sek]),
• zum FHIR-Verzeichnisdienst zur Pflege und zum Bezug der Föderationsliste,
• zur Komponenten PKI für die Erzeugung und Prüfung von Zertifikaten aus dem Vertrauensraum der TI,
• zu anderen TI-Messenger Fachdiensten um innerhalb der TI-Messenger Föderation die Kommunikation mit Nutzern anderer TI-Messenger-Fachdienste,
• zum Push Gateway um Benachrichtigungen für Nutzer zu versenden.

4.2 Technischer- oder Verteilungskontext

Die Schnittstellen des TI-Messengers für Versicherte haben sich gegenüber dem bisherigen TI-Messenger teilweise geändert, sodass die externen Systeme angepasst werden müssen. In den folgenden Kapiteln wird explizit darauf hingewiesen, wenn Änderungen an bestehenden externen Systemen erforderlich sind.

Da Zero Trust für die Telematikinfrastruktur (TI) noch nicht verfügbar ist, werden die Zero Trust Schnittstellen später am TI-Messenger für Versicherte nachgerüstet.

5 Bausteinsicht

In den folgenden Kapiteln werden die Komponenten des Clients und der Services in einer Bausteinansicht visualisiert.

5.1 Clientmodule

Die folgende Grafik zeigt die Komponenten eines TI-Messenger-Clients. Farblich hervorgehoben sind diejenigen Komponenten, die im Rahmen der in diesem Konzept vorgestellten Features angepasst werden müssen (blau) und Komponenten, die neu hinzugekommen sind (grün).

Abbildung 2: TI-Messenger-Client Komponentendiagramm

5.2 Servermodule

Die folgende Grafik visualisiert die Komponenten auf Serverseite, die im Rahmen der in diesem Dokument beschriebenen Features hinzukommen oder angepasst werden müssen. Farblich hervorgehoben sind diejenigen Komponenten, die im Rahmen der in diesem Konzept vorgestellten Features angepasst werden müssen (blau) und Komponenten, die neu hinzugekommen sind (grün).

Abbildung 3: TI-Messenger-Service Komponentendiagramm

6 Features

6.1 Feature Anwenderidentifikation

6.1.1 Ausgangslage

Versicherte erhalten von ihrer Krankenkasse eine App bereitgestellt, die es ihnen ermöglicht die TI-Anwendungen ePA, E-Rezept und TI-Messenger zu nutzen. Die Krankenkasse stellt den Versicherten eine Gesundheits-ID und einen IDP bereit, der es ermöglicht, die Versicherten der Krankenkasse zu authentifizieren und Identitätsinformationen der Versicherten in den Diensten der TI zu nutzen.

6.1.2 Anwendungsfall

Die Versicherten möchten den TI-Messenger im FdV ihrer Krankenkasse nutzen. Dazu MÜSSEN sich die Versicherten am TI-Messenger Service der Krankenkasse registrieren. Die Registrierung ist ein einmaliger Vorgang bei dem eine Authentifizierung der Versicherten erfolgt. Als Ergebnis der Registrierung erhält die Versicherte einen Zugang zum TI-Messenger Service der Krankenkasse. Wenn die Versicherte weitere Geräte mit einem TI-Messenger-Client verwenden möchte, dann ist ein Login mit erneuter Authentifizierung am sektoralen IDP erforderlich.

6.1.3 Lösung und Architekturentscheidungen

Die Authentifizierung der Versicherten für die Registrierung von TI-Messenger Accounts und für das Login am Homeserver erfolgt am sektoralen IDP mittels OIDC. Dadurch muss am FdV nur eine Authentifizierungstechnologie unterstützt werden.

Die Matrix-Homeserver Implementierung Synapse unterstützt keine Pushed Authorization Requests, die vom sektoralen IDP gefordert sind. Die Kompatibilität zum sektoralen IDP lässt sich jedoch über Anpassungen am Ablauf durch den TI-Messenger Proxy herstellen.

Der Homeserver muss so konfiguriert werden, dass für ein Device nur ein zeitlich begrenzt gültiges access token zusammen mit einem refresh token ausgestellt wird, um zu verhindern, dass gestohlene access token missbräuchlich genutzt werden können. Wenn das access token ungültig geworden ist, dann kann mit dem refresh token ein neues access token und ein neues refresh token vom Matrix Homeserver angefordert werden. Das alte refresh token verliert damit seine Gültigkeit.

Die Suche im VZD FHIR-Directory erfordert ein gültiges access token, das vom VZD Auth-Service ausgestellt wurde. Die Authentifizierung um das access token zu erhalten, erfolgt wie im TI-Messenger (Release 1.1.1, siehe
https://github.com/gematik/api-vzd/blob/gemILF_VZD_FHIR_Directory/1.0.2/docs/FHIR_VZD_HOWTO_Authenticate.adoc)
über den Besitz eines Accounts am TI-Messenger-Service.

6.1.3.1 Laufzeitsicht

Die folgende Abbildung zeigt die Registrierung eines Accounts und den Login am TI-Messenger Service. Als Matrix-Homeserver wurde Synapse gewählt. Synapse unterstützt die Authentifizierung mit OIDC, jedoch nicht in der Variante Pushed Authorization Requests (siehe https://datatracker.ietf.org/doc/html/rfc9126 ), wie es vom sektoralen IDP gefordert ist. Daher ist in den Schritten (13) bis (16) das Verhalten des Homeservers durch den TI-Messenger Proxy an Pushed Authorization Requests gemäß den Anforderungen des sektoralen IDP angepasst.

Abbildung 4: Registrierung und Login eines Versicherten am Matrix Homeserver

6.1.4 Anforderungen

Durch diese Anforderung soll verhindert werden, dass gestohlene access token missbräuchlich genutzt werden können. Nach Ablauf der Gültigkeit des access token kann mit dem refresh token ein neues access token und refresh token angefordert werden. Das bisherige refresh token wird dadurch ungültig.

6.2 Feature Bildungsregel MXID

6.2.1 Ausgangslage

Für den TI-Messenger (Release 1.1.1) wurde keine Bildungsregel für die MXID definiert, sondern die Ausgestaltung dem Anbieter überlassen. Die MXID ist die eindeutige Adresse eines Anwenders im Umfeld des TI-Messengers, setzt sich aus den Teilen Localpart und domain zusammen und muss den Anforderungen der Matrix-Spezifikation zum User Identifier entsprechen.

6.2.2 Anwendungsfall

Im Kontext der Versicherten soll der Arzt in die Lage versetzt werden, die MXID eines Versicherten bestimmen zu können, wenn ihm im Rahmen des Behandlungskontextes die Stammdaten des Versicherten vorliegen. Zu diesen Stammdaten zählen u.a. die KVNR und die IK-Nummer der Krankenkasse. Diese beiden Elemente sollen genutzt werden, um die MXID des Versicherten herzuleiten.

6.2.3 Lösung und Architekturentscheidungen

Um dem Arzt zu ermöglichen aus den Stammdaten die MXID abzuleiten, soll diese sich für den Versicherten aus den Bestandteilen zusammensetzen:

• KVNR für den Localpart
• Domäne für die Versicherten für den Domainteil zusammensetzen.

Für einen Versicherten mit der KVNR "I123456789" bei der gematiker-KK ergibt sich somit die MXID @I123456789:gematiker-kk.de. Die Voraussetzungen für die Eindeutigkeit sind gegeben, da die KVNR bei einer Krankenkasse ein eindeutiges Identifikationsmerkmal darstellt. Da dem Arzt neben der KVNR auch die IK-Nummer zur Verfügung steht, muss er befähigt werden, über die IK-Nummer die Domäne des Messenger-Service bestimmen zu können, der den Benutzeraccount des Versicherten verwaltet. Um dies sicherzustellen, wird die Föderationsliste um eine Liste mit IK-Nummern erweitert, die von dieser Domäne verwaltet werden. Eine IK-Nummer DARF in der gesamten Föderationsliste nur einmal enthalten sein. Die IK-Nummer MUSS aus einer neunstelligen Ziffernfolge bestehen, deren erste 2 Stellen mit "10" abgebildet sein MÜSSEN (Klassifikation für Krankenversicherungsträger). IK-Nummern DÜRFEN nur zu Domänen hinzugefügt werden, die Accounts von Versicherten bereitstellen. Beim Hinterlegen der IK-Nummer MUSS diese gegen die enthaltene Prüfziffer validiert werden.

Für den Client der Leistungserbringer MUSS der Messenger-Proxy, dem die Föderationsliste vorliegt, eine API bereitstellen, die bei übergebener IK-Nummer, die hinterlegte Domäne zurück liefert. Hierzu ist ein Endpunkt nach folgender Spezifikation zu implementieren (eine vollständige OpenAPI-Spezifikation wird im Rahmen des Spezifikationsreleases dann auf github veröffentlicht werden):

6.2.4 Anforderungen

6.3 Feature - Keine direkte Versichertenkommunikation

6.3.1 Ausgangslage

Der TI-Messenger dient in seiner ersten Version der Kommunikation zwischen Leistungserbringern (LE) und Leistungserbringerinstitutionen (LEI).
In der Ausbaustufe für die elektronische Patientenakte soll eine Kommunikation zwischen Versicherten und ihren LE bzw. LEI ermöglicht werden. Der TI-Messenger dient der Kommunikation im Gesundheitswesen und nicht einer allgemeinen Kommunikation. Daher darf keine direkte Kommunikation zwischen Versicherten initiiert werden. Diese Einschränkung kann mit dem aktuellen Berechtigungskonzept des TI-Messengers nicht umgesetzt werden und wird daher explizit definiert.

6.3.2 Anwendungsfall

Als Krankenversicherung möchte ich nicht zulassen, dass die Versicherten andere Versicherte in einen Chat einladen können. Für die direkte Kommunikation zwischen Versicherten steht diesen frei, einen Account auf einem freien Matrix-Server zu nutzen.

6.3.3 Lösung und Architekturentscheidungen

Um zu unterbinden, dass ein Versicherter einen anderen Versicherten in einen Direktchat oder eine Gruppe einlädt, müssen die Prüfungen der Berechtigungsstufe 1 gemäß [gemSpec_TI-Messenger-Dienst#8.3] angepasst werden. Um eine Berechtigungsentscheidung treffen zu können, sind die TI-Messenger-Akteure als Versicherte zu identifizieren. Hierzu sind bereits im VZD-FHIR-Directory die entsprechenden Vorbereitungen getroffen worden. Beim Hinterlegen einer Domain in der Föderationsliste muss der Anbieter die folgenden Informationen hinterlegen:

• Die Domain, die er in der Föderationsliste hinterlegen möchte.
• Die Telematik-ID der Organisation für die diese Domain registriert wird.
• Die Zuweisungsgruppe im TI-ITSM-System für den Anbieter.
• Eine Kennzeichnung, ob unter dieser Domain die Benutzerkonten von Versicherten verwaltet werden.

Bei einer Anfrage MUSS der Messenger-Proxy des TI-Messenger Services (Release 1.1.1) sowohl auf der einladenden, als auch auf der eingeladenen Seite anhand der Föderationsliste prüfen, ob alle Kommunikationspartner Teil der Föderation sind. Somit liegt die Föderationsliste dem Messenger-Proxy vor und ermöglicht diesem die enthaltenen Informationen zur Kennzeichnung der Versichertendomain für eine zusätzliche Prüfung zu nutzen. Es MUSS geprüft werden, ob sowohl der einladende als auch der eingeladene Akteur ihre TI-Messenger Accounts auf einer Versichertendomain haben. Trifft dies zu, MUSS die Einladung vom Messenger-Proxy unterbunden werden. Somit ist sichergestellt, dass TI-Messenger Akteure in der Rolle Versicherter keine anderen Akteure in der Rolle Versicherter einladen können. Voraussetzung für die Umsetzung ist, dass unter einer Domain Akteure in der Rolle Versicherter nicht mit anderen Akteuren in Rollen, die keine Versicherter sind, gemischt werden (z.B. Mitarbeiter der Krankenversicherung).

6.3.3.1 Laufzeitsicht

Die Laufzeitansicht zeigt exemplarisch am Anwendungsfall "Einladung von Akteuren innerhalb einer Organisation" die Einbettung der zusätzlichen Prüfung auf Versichertenzugehörigkeit (rot hervorgehoben). Das Ergebnis wird anschließend verwendet, um zu identifizieren, ob eine Kommunikation aufgebaut werden darf. Sind beide Akteure - der Einladende und der Einzuladende - Versicherte, dann wird die Einladung nicht weitergeleitet und der Einladende erhält eine Fehlermeldung.

Abbildung 5: Laufzeit Versichertenprüfung

6.3.3.2 Verteilungssicht

Die folgende Grafik zeigt, welche Komponenten der Fachdienste, die zusätzliche Prüflogik übernehmen müssen. Die Versichertenprüfung soll an der Client-Server-API durchgeführt werden und zur weiteren Absicherung ebenfalls an der Server-Server-API zwischen den TI-Messenger Fachdiensten. Die zur Prüfung zu verwendenden Informationen und der Ablauf der Prüfung werden im folgenden Kapitel beschrieben.

Abbildung 6: Versichertenprüfung Komponentenbeteiligung

6.3.4 Anforderungen

Hinweis: Ein TI-Messenger-Service für Versicherte darf ausschließlich für Versicherte verwendet werden, da sonst wegen der Unterbindung der Versichertenkommunikation die Nutzbarkeit stark eingeschränkt ist.

6.4 Feature - Userzentriertes Berechtigungsmanagement

6.4.1 Ausgangslage

Das Berechtigungskonzept des TI-Messenger Fachdienstes (Release 1.1.1) ist in drei Stufen unterteilt:

• Es wird geprüft, ob beide Kommunikationsteilnehmer (Akteure) Teil der Föderation sind,
• Sind beide Akteure nicht Mitglieder derselben Organisation, dann wird die Kommunikation nur zugelassen, wenn:
  
• der einladende Akteur auf der Empfängerseite in der persönlichen Kontaktliste ist,
• der einzuladende Akteur mit seiner MXID im Organisationsverzeichnis hinterlegt ist,
• der einladende Akteur und der einzuladende Akteur beide ihre MXID im Practitioner-Verzeichnis des VZD hinterlegt haben.

Das Berechtigungsmodell ist sehr restriktiv und gerade für den HBA-Besitzer sehr schwer konfigurierbar, da für die Verwaltung des Eintrags im Practitioner-Verzeichnis, der Einsatz der Smartcard (HBA) notwendig ist, meist in Kombination mit einem Konnektor und einem Kartenterminal.

6.4.2 Anwendungsfall

Als TI-Messenger Nutzer möchte ich steuern können, wer mich zum Chat in neue Räume einladen darf, damit ich u.a. die Kontrolle über mein chatbezogenes Arbeitsaufkommen habe.

Der Nutzer muss einstellen können:

• dass jeder andere TI-Messenger Nutzer ihn einladen darf,
• dass nur interne TI-Messenger Nutzer (gleiche Organisation) ihn einladen dürfen,
• dass nur Nutzer im eigenen Adressbuch ihn einladen dürfen,
• dass nur TI-Messenger Nutzer auf der von ihm gepflegten Allow-List ihn einladen dürfen,
• dass TI-Messenger Nutzer auf der von ihm gepflegten Block-List ihn nicht einladen dürfen.

Als TI-Messenger Nutzer möchte ich einen einfachen Zugang zu meinen Berechtigungen haben und diese nicht erst durch den Einsatz einer Smartcard konfigurieren können.

6.4.3 Lösung und Architekturentscheidungen

Für den TI-Messenger für Versicherte wird das Berechtigungsmanagement in die Hand der Akteure gelegt. Wie Abbildung 4 zeigt, verbleibt nur die Föderationsprüfung in der Hoheit des Anbieters und wird über den Messenger Proxy realisiert, wie schon im TI-Messenger(Release 1.1.1) beschrieben. Um die Multidevice-Fähigkeit des TI-Messengers zu unterstützen soll die Berechtigungskonfiguration in den Accountdaten des Anwenders auf dem Matrix Homeserver hinterlegt werden. Somit ist sichergestellt, dass die Konfiguration auch auf einem anderen Client, an dem sich der Anwender anmeldet, zur Verfügung steht. Für die Ablage der Konfiguration in den Accountdaten des Home-Servers https://spec.matrix.org/v1.8/client-server-api/#client-config wird der folgende Namespace reserviert:

• de.gematik.tim.account.permissionconfig
  

Der Anwender kann die Berechtigungen über die folgenden unterschiedlichen Varianten konfigurieren:

• Basiseinstellung ist "allow all" und der Anwender pflegt eine BlockedUser-Liste, in die auch Gruppen aufgenommen werden können,
• Basiseinstellung ist "block all" und der Anwender lässt den Kontakt für andere Akteure über die Pflege einer AllowedUser-Liste zu, die auch Gruppen enthalten kann.

Hinweis: Die Struktur der Berechtigungseinstellungen wird in der Folgespezifikation veröffentlicht.

Gruppen, die bereits unterstützt werden können sind z.B. alle User auf dem gleichen Homeserver, alle User von einer bestimmten Domain. Für weitere Ausbaustufen des TI-Messengers ist somit die Grundlage geschaffen, dem Anwender weitere Gruppen für die Berechtigungsverwaltung zur Verfügung zu stellen (z. B. Eigenschaften einer Organisation) oder auf dem Client zeitabhängige Konfigurationen zu ermöglichen (z. B. Urlaubsabwesenheiten).

Die folgende Abbildung zeigt den Ablauf zum Setzen der Berechtigungen:

Abbildung 7: Berechtigungen setzen

Alle Einstellungen können vom Anwender durchgeführt werden ohne eine Smartcard benutzen zu müssen und er erhält mit der Einführung von Gruppen die Möglichkeit Berechtigungen einfacher zu konfigurieren.

6.4.3.1 Laufzeitsicht

Die folgende Grafik zeigt am Beispiel der Übermittlung eines Invite Events zwischen zwei Messenger-Services, welche Komponenten zu welchen Zeitpunkten die Berechtigungsprüfungen durchführen, nachdem der Anwender in seinem Client die Berechtigungskonfiguration vorgenommen hat. Der Messenger-Proxy prüft, ob beide Kommunikationsteilnehmer der Föderation angehören und mindestens einer der Kommunikationspartner kein Versicherter ist. Die weitere Berechtigungsprüfung der Einladung erfolgt dann auf dem Messenger-Client des Eingeladenen.

Abbildung 8: Berechtigungsprüfungen

6.4.3.2 Verteilungssicht

Im TI-Messenger-Service (Release 1.1.1) ist die Berechtigungskomponente im Messenger-Proxy untergebracht. Um den Anwendern die maximale Flexibilität in der Konfiguration der Berechtigungen zu ermöglichen, wird ein Großteil der Berechtigungslogik in den Client verlagert. Im Messenger-Proxy bleibt nur noch die Föderationsprüfung. Da es sich beim TI-Messenger um eine Anwendung handelt, die Multidevice-fähig ist, muss sichergestellt werden, dass dies auch bei der Verwaltung des neuen Berechtigungskonzepts entsprechend berücksichtigt wird und die Konfiguration allen Clients zur Verfügung steht. Da der Matrix-Homeserver hierfür bereits einen Datenspeicher bereitstellt, liegt es nahe, diesen direkt zu verwenden. Die folgende Grafik illustriert den Vergleich mit dem TI-Messenger (Release 1.1.1).

Abbildung 9: Berechtigungsprüfung

6.4.4 Anforderungen

6.5 Feature Information über neue Nachricht

6.5.1 Ausgangslage

Bisher unterstützen TI-Messenger (Release 1.1.1) Push-Notifications für iOS- und Android - Betriebssysteme. Dabei werden vom TI-Messenger Fachdienst das Push Gateway und ein externer Push-Anbieter, z.B.

• Apple Push Notification service (APNs) für iOS
  
• Firebase Cloud Messaging (FCM) für Android

verwendet.

Für das Frontend der Versicherten MÜSSEN Push-Notifications für die Anwendungen TI-Messenger unterstützt werden und es ist ein Konzept vorzusehen, welches die zukünftige Nutzung von Push-Notifications auch für andere Anwendungen(z.B. ePA / E-Rezept) in derselben App unterstützt.

6.5.2 Anwendungsfall

Die Versicherte hat ihre App der Krankenkasse (FdV) installiert und entscheidet sich dafür, Push-Notifications z.B. für die Anwendungen ePA (bei neu eingestellten Dokumenten oder bei Lesezugriffen) und TI-Messenger (bei neu eingegangenen Nachrichten oder Einladungen) zu erhalten.

Je nachdem, für welche Ereignisse die Push-Notifications konfiguriert wurden, wird nach Eintritt eines der konfigurierten Ereignisse, eine Benachrichtigung auf dem Smartphone der Versicherten angezeigt.

6.5.3 Lösung und Architekturentscheidungen

Eine besondere Herausforderung beim FDV besteht darin, dass eine App (das FDV) die Client-Logik zur Kommunikation mit drei unterschiedlichen Fachdiensten (ePA, E-Rezept, TI-M) sicherstellen muss. Um die Flexibilität hinsichtlich multipler Fachdienste und unterschiedlicher Clients sicherzustellen muss das Push-Gateway idealerweise aus den TI-Messenger-Fachdiensten herausgelöst und separat zur Verfügung gestellt werden. Eine ausführliche Beschreibung der Lösung ist im Kapitel hinterlegt.

Die Push Nachrichten MÜSSEN als Silent Push ausgeführt werden. Die Push Nachrichten DÜRFEN KEINE inhaltlichen Informationen über die Benachrichtigung enthalten. Der Ablauf zwischen den Komponenten und den übermittelten Inhalten wird im folgenden Kapitel dargestellt.

Für den TI-Messenger lässt sich abschließend festhalten, dass dieser bereits die geforderten Anforderungen erfüllt. Es ist eine öffentliche API vorhanden (https://spec.matrix.org/v1.8/client-server-api/#push-notifications ), über die der Client dem Fachdienst die Konfiguration für die Verarbeitung von Push-Nachrichten übermitteln kann.  Die Schnittstelle zwischen dem TI-Messenger-Fachdienst und dem API Gateway ist einheitlich spezifiziert: https://spec.matrix.org/v1.8/push-gateway-api/ und für die geforderte Datensparsamkeit existiert das Format event_id_only bei dem nur die Informationen event_id, room_id, counts, und devices zugeliefert werden. Für andere Fachdienste sind entsprechend separate Endpunkte zur Verfügung zu stellen, deren Ausgestaltung über die kommenden Spezifikationsreleases zum ePA-FDV oder dem E-Rezept im ePA-FDV erfolgen wird.

6.5.3.1 Laufzeitsicht

Die folgende Grafik illustriert das Zusammenspiel zwischen einer Smartphone-Anwendung, einem Push-Anbieter und dem zu einer Anwendung zugehörigen Fachdienst.

Abbildung 10: Ablauf Push-Benachrichtigung

Die App registriert sich beim externen Push-Anbieter und erhält einen Token (Registration Token bei FCM, Device Token bei APN). Die App sendet den Token an den Fachdienst mit der Information, für welche Ereignisse der Versicherte Push Notifications konfiguriert hat. Zusätzlich teilt die App dem Fachdienst mit über welches Push-Gateway sie beliefert werden soll.

Wenn eines der konfigurierten Ereignisse an einem der Fachdienste eintritt, dann sendet der Fachdienst eine Silent Push Nachricht an das von der App hinterlegte Push-Gateway. Die Nachricht enthält nur die notwendigsten Metadaten, um sie im Push-Gateway zu verarbeiten und an den Push-Anbieter (z.B. APNs oder FCM) übermitteln zu können. Das Push-Gateway speichert die Nachricht für den Fall, dass das Gerät des Versicherten nicht online ist. Wenn das Gerät online ist, wird die Nachricht vom externen Push-Anbieter an das Gerät der Versicherten weitergeleitet. Dort wird die Benachrichtigung nicht angezeigt (Silent Push Nachricht), sondern die FdV-App aktiviert und die Nachricht an die App übergeben. Die App bestimmt anhand der Daten in der Nachricht welcher Teil der Anwendungslogik für die Verarbeitung zuständig ist. Dieser holt dann die eigentlichen Benachrichtigungsdaten vom Fachdienst ab, um letztendlich eine passende Benachrichtigung auf dem Gerät des Versicherten anzuzeigen.

6.5.3.2 Verteilungssicht

Die nachfolgende Grafik illustriert ein fiktives Szenario. Es existiert bereits einen E-Rezept-Fachdienst der über ein Push-Gateway die Push-Dienste von Google und Apple angebunden hat, um die E-Rezept-App sowohl unter Android als auch unter iOS mit Push-Benachrichtigungen zu versorgen. Nun möchte die gematiker Krankenkasse eine App den Versicherten zur Verfügung stellen, die Push-Benachrichtigungen der integrierten Fachdienste ePA, E-Rezept und TI-Messenger verarbeiten kann. Hierzu ist es notwendig den bereits existierenden E-Rezept-Fachdienst anzubinden, sowie auf Seiten des Versicherten (in der App) die Benachrichtigungen sauber zu trennen.

Abbildung 11: Push-Gateway

Wie die Abbildung zeigt stellt die gematiker Krankenkasse ein Push-Gateway für ihre FdV-App zur Verfügung und registriert die App beim Push-Anbieter. Durch die Registrierung erhält die App vom Anbieter ein Token über welches die Anwendung beim Senden von Push-Benachrichtigungen eindeutig identifiziert werden kann. Dieses Token und die Information welches Gateway zu verwenden ist, stellt die App den von ihr genutzten Fachdiensten zur Verfügung. Dazu ist es notwendig, dass die in der Grafik gelb markierten Schnittstellen öffentlich verfügbar und für beliebige Clients nutzbar sein müssen. Ebenfalls müssen die Schnittstellen der Fachdienste zu den Gateways öffentlich einsehbar sein, damit die gematiker Krankenkasse an ihrem Push-Gateway eine Schnittstelle bereitstellen kann, die vom E-Rezept-Fachdienst auch verstanden wird. Die beiden deckungsgleichen Schnittstellen sind rot markiert. Die grün markierten Schnittstellen am Push Gateway der gematiker Krankenkasse werden im Beispielszenario nicht von anderen Apps genutzt, Müssen jedoch auch öffentlich verfügbar sein, damit andere App-Entwickler für ihre Anwendungen ein Push-Gateway mit identischen Schnittstellen bereitstellen können. Das vorgestellte Konzept hat den Vorteil, dass die Push-Anbieter spezifischen Credentials beim Push-Gateway des App-Anbieters verbleiben können und dass es dem App Anbieter überlassen ist zu entscheiden, wie er die Trennung der Inhalte übernimmt. Z.B. kann die gematiker Krankenkasse selbst in der Logik ihres Gateways entscheiden, ob sie in den Inhalt der Benachrichtigung einen Indikator aufnimmt, welcher Fachdienst die Benachrichtigung gesendet hat oder bei Nutzung von FCM diese Unterscheidung über eigene Topics für die verschiedenen Fachdienste realisiert.

6.5.4 Anforderungen

7 Querschnittliche Aspekte

7.1 Verteilungssicht

Für den TI-Messenger für Versicherte werden Dienste bei verschiedenen Betreibern genutzt.

Abbildung 12: Verteilungssicht

7.2 Testvorgehen

7.2.1 Testtreiber Schnittstelle

Für die Anbieter-Zulassung müssen:

• die TI-Messenger Fachdienste für Versicherte
• die TI-Messenger-Clients FdV

bereitgestellt werden. Um einen automatisierten Test für den TI-Messenger-Dienst zu ermöglichen, müssen die Test-Apps des TI-Messenger-Clients  und des TI-Messenger-Clients FdV zusätzlich ein Testtreiber-Modul (intern oder extern) zur Verfügung stellen. In den folgenden Abbildungen wird das interne sowie das externe Testtreiber-Modul dargestellt.

Abbildung 13: internes Testtreiber-Modul 

Abbildung 14: externes Testtreiber-Modul 

Das Testtreiber-Modul muss Bestandteil der Test-APPs sein (internes Testtreiber-Modul) oder einen Zugang zum Test-Environment des Herstellers gewährleisten (externes Testtreiber-Modul). Weiterhin muss das Testtreiber-Modul die Funktionalitäten der produktspezifischen Schnittstellen des TI-Messenger-Clients und des TI-Messenger-Clients FdV über eine standardisierte Schnittstelle von außen zugänglich machen und einen Fernzugriff ermöglichen. 

Die Schnittstelle wird gemäß [Testtreiber API] durch die gematik spezifiziert und bereitgestellt. Das Testtreiber-Modul muss die von TI-Messenger-Client/TI-Messenger-Clients FdV über eine produktspezifische Schnittstelle angebotene Funktionalität nutzen, um die Operationen des TI-Messenger-Clients/TI-Messenger-Clients FdV umzusetzen. Bei einem internen Testtreiber-Modul wird die REST-Schnittstelle in die Test-App integriert (der Zugriff erfolgt hierbei direkt über das Endgerät).

Für die Durchführung der Tests werden Organisationen, TI-Messenger-Dienste und TI-Messenger-Dienste für Versicherte benötigt. Diese Organisationen und Messenger-Services müssen von den Herstellern vor Beginn der Testphase eingerichtet und die Daten (Organisationsnamen, URLs etc.) an die gematik übermittelt werden.
Das Testtreiber-Modul darf die Ausgaben der Clients gemäß der technischen Schnittstelle verarbeiten, aber darf die Inhalte nicht verfälschen. Das Testtreiber-Modul darf nicht die Fachlogik des TI-Messenger Clients oder des FdV umsetzen. Der produktive TI-Messenger Client und der produktive TI-Messenger Clients FdV darf nicht die Testtreiber-Module enthalten. Der Einsatz des Testtreiber-Module ist auf das Zulassungsverfahren beschränkt und darf nicht in Wirkbetriebs-Apps genutzt werden.

Wenn ein Client in mehreren Ausprägungen zur Verfügung gestellt wird, wird für jede Ausprägung eine Zulassung mit einem eigenen Testtreiber-Modul benötigt.

Abbildung 15: Anschaltung der Clients

Eine genaue Beschreibung zur Nutzung und die Anforderungen an die Testtreiberschnittstelle befindet sich auch in der von der gematik veröffentlichten [TI-Messenger Testsuite].

7.2.2 TI-Messenger Testsuite

Das Testvorgehen für TI-Messenger ePA-FdV setzt auf das Testvorgehen des TI-Messenger-Dienst 1.1.1-1 [gemSpec_TI-Messenger-Dienst] auf und die existierende Testtreiberschnittstelle und Testsuite wird entsprechend erweitert. Alle Tests innerhalb der Testsuite sind separat ausführbar, somit ist es möglich die TI-Messenger-Dienst 1.1.1-1 Anwendungsfälle [gemSpec_TI-Messenger-Dienst] und die TI-Messenger ePA-FdV zusammen oder einzeln zu testen. Die erweiterte Testtreiberschnittstelle und die Testsuite werden auf github veröffentlicht und sind für alle Hersteller zugänglich. Während der Zulassungstests werden genau die veröffentlichten Testfälle geprüft. Die Testfälle bilden die definierten Anwendungsfälle aus der Spezifikation ab. Produkttests zur Sicherstellung der Konformität mit der Spezifikation der für die TI-Messenger-Fachdienste ,TI-Messenger-Clients , TI-Messenger Fachdienst für Versicherte, TI-Messenger-Clients für Versicherte und die TI-Messenger-Clients FdV liegen vollständig in der Verantwortung der Anbieter/Hersteller. Die gematik konzentriert sich bei der Zulassung auf das Zusammenspiel der Produkte durch E2E- und IOP-Tests.

Die eigenverantwortlichen Produkttests bei den Industriepartnern umfassen unter anderem:

• Testumgebung entwickeln inklusive Testtreiber-Modul,
• Testfallkatalog erstellen (für eigene Produkttests) und
• Produkttest durchführen und dokumentieren.

Die Hersteller müssen zusichern, dass die gematik die Produkttests der Industriepartner in Form von Reviews der Testkonzepte, der Testspezifikationen, der Testfälle und mit dem Review der Testprotokolle (Log- und Trace-Daten) überprüfen kann.

Die gematik testet im Rahmen der Zulassungsverfahren auf Basis von Anwendungsfällen. Dabei wird sich auf die Anwendungsfälle aus der [gemSpec_TI-Messenger-Dienst] und aus diesem Dokument bezogen. Hierbei wird versucht, möglichst viele Funktionsbereiche der Komponenten des TI-Messenger-Dienstes und seines TI-Messenger-Clients FdV einzubeziehen.

Der TI-Messenger-Anbieter muss eine Referenzinstanz und mindestens eine Testinstanz des TI-Messenger-Fachdienstes und TI-Messenger-Clients inklusive Testtreiberschnittstelle bereitstellen und betreiben. 

Abbildung 16: Testinstanzen

Die Hersteller von Versicherten-Frontends müssen ebenfalls das FdV und die Testtreiberschnittstelle bereitstellen. Bei Problemen im Rahmen der Zulassung müssen die Anbieter bei der Analyse unterstützen. In der folgenden Abbildung ist eine Systemumgebung für den Zulassungstest dargestellt.

Abbildung 17: Zulassungstest

Die Tests werden zunächst gegen die Referenzimplementierung der gematik durchgeführt. In diesem Schritt wird die Funktionalität des Zulassungsobjekts TI-Messenger-Dienst 2.0 geprüft. Anschließend wird mit den IOP- und E2E-Tests die Interoperabilität zwischen den verschiedenen TI-Messenger-Anbietern nachgewiesen. Hierfür werden dann alle bereits zur Verfügung stehenden TI-Messenger-Dienste (die Test-Instanzen der einzelnen Hersteller) zusammengeschlossen und anschließend gegeneinander getestet.

Abbildung 18: Testumgebung TI-Messenger 2.0

Die Testinstanz dient den Herstellern bei der Entwicklung neuer TI-Messenger-Clients, FdV und TI-Messenger Fachdienste Versionen und wird für die Zulassung gegen die Referenzimplementierung verwendet, Die Referenz-Instanz hat die gleiche Version wie die Produktionsumgebung und kann von anderen Herstellern für Tests und Entwicklung gegen die zugelassene Version benutzt werden. Weiterhin wird die Referenz-Instanz für die Reproduktion aktueller Fehler/Probleme aus der Produktionsumgebung genutzt. Der Zugriff auf die Referenz-Instanz/Testtreiberschnittstelle  muss für die gematik zur Fehleranalyse gewährleistet sein.
Für die IOP-Tests zwischen den verschiedenen TI-Messenger-Anbietern können sowohl die Tests als auch die Referenzinstanz genutzt werden.
Der TI-Messenger-Anbieter/TI-Messenger-Anbieter für Versicherte muss die verschiedenen Benutzer der Referenz-Instanz und der Test-Instanz koordinieren (Verwaltung eines Test-/Nutzungsplans). Bei Bedarf (Entwicklung verschiedener Versionen, hoher Auslastung durch andere Hersteller oder durch die gematik) muss der TI-Messenger-Anbieter auch mehrere Test-Instanzen mit derselben oder mit verschiedenen Versionen bereitstellen und betreiben. Die gematik stellt eine TI-Messenger-Dienst Referenzimplementierung zur Verfügung. Zur Sicherstellung der Interoperabilität zwischen verschiedenen TI-Messenger-Fachdiensten innerhalb des TI-Messenger-Dienstes muss der TI-Messenger-Fachdienst eines TI-Messenger-Anbieters bzw. TI-Messenger-Fachdienst für Versicherte  gegen eine Referenzimplementierung Instanz getestet werden. Diese Instanz kann bei der gematik bestellt werden und dient zur Vorbereitung der Zulassungstests. Die TI-Messenger-Dienste müssen gegen die Referenzimplementierung erfolgreich getestet werden und die Testergebnisse sind der gematik vorzulegen

Abbildung 19: Referenzinstanz für einen Hersteller

Zusätzlich zu den bereits durchgeführten IOP- und E2E-Tests werden weitere Interoperabilitätstests von verschiedenen TI-Messenger-Lösungen nach der Zulassung durch die gematik durchgeführt. Die folgende Abbildung zeigt die Nutzung der existierenden Testumgebung durch die gematik während der Zulassungs- und Interoperabilitätstests.

Abbildung 20: Testumgebung Zulassungs- und Interoperabilitätstests

Um eine größere Abdeckung zu erhalten werden die Hersteller in Pools eingeteilt. Somit können mehrere Hersteller gleichzeitig getestet werden und anschließend werden die Pools wieder neu gemischt.

Abbildung 21: IOP Test Pools

7.2.3 Überblick über die Teststufen

Analog zu TI-Messenger-Dienst 1.x werden von der gematik die folgenden Teststufen für jedes Betriebssystem durchlaufen. Eine feste Reihenfolge gibt es dabei nicht.

• automatisierte Tests inklusive Prüfung der Interoperabilität  
• manuelle Tests
• Look & Feel Workshop für jeden Client

7.3 Betriebsmodell

Entsprechend der Architektur ergeben sich zwei neue Produkttypen:

• TI-Messenger Fachdienst für Versicherte und
• TI-Messenger-Client für Versicherte.
  

Der TI-Messenger Anbieter verantwortet den TI-Messenger Fachdienst für Versicherte (vgl. [gemKPT_Betr#Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer]). Somit können die Krankenkassen z.B. einen TI-Messenger Fachdienst  entsprechend der gematik-Vorgaben von einem zugelassenen TI-Messenger Anbieter erwerben.

Damit bleibt das bestehende TI-Messenger Anbietermodell fortbestehen und die Krankenkassen nehmen die Rolle eines Kunden bei einem selbst gewählten TI-Messenger ein, um den von ihnen eingekauften Service an ihre Versicherten durchzureichen.

Weil der TI-Messenger-Client FdV als Komponente im Versicherten FdV betrachtet wird, verbleibt die Verantwortung dafür beim Hersteller des FdV.

Die betriebliche Governance seitens der gematik beschränkt sich hierbei auf die bisherigen Möglichkeiten der Überwachung der TI-Messenger Anbieter und ihrer Komponenten (Fachdienst und Client) im Betrieb. Die Dienstleistersteuerung für die eingekauften Services gegenüber den Versicherten obliegt damit der jeweiligen Krankenkasse.

Abbildung 22: Betriebsmodell

Hinweise:
1. Die Darstellung stellt das Betriebsmodell des TI-Messengers im Kontext der ePA für alle in den Fokus, nicht das TI-M 1.x Betriebsmodell
2. Die Darstellung zeigt eine mögliche Rollenverteilung. D.h. dass eine Krankenkasse auch selbst z.B. Anbieter TI-Messenger werden kann.
3. Unterauftragnehmer und Auslagerungen im Betrieb sind möglich, aber zur einfacheren Verständlichkeit nicht abgebildet.

7.4 Sicherheitsbetrachtung

Die vorliegende Grobspezifikation nimmt noch keine Detaillierung vor, die eine Trennung in funktionale und sicherheitstechnische Anforderungen erlaubt. Dies erfolgt im Rahmen des zuvor erwähnten Spezifikationsreleases, welches zusätzlich die aus dem aktuell gültigen TI-Messenger-Release 1.1.1 normativen Festlegungen übernehmen, und nach Bedarf anpassen und erweitern wird.

Der TI-Messenger-Fachdienst für Versicherte weist eine hohe Unabhängigkeit von den anderen Fachdiensten auf. Abgesehen davon, dass beispielsweise für die Zustellung von Push-Notifications ein Fachdienst-übergreifender Ansatz benötigt wird, kann der TI-Messenger-Fachdienst für Versicherte weitestgehend als eigenständiges Produkt hergestellt und angeboten werden. Die aktuell geltenden Sicherheitsanforderungen aus Produkt- und Anbietertypsteckbrief des Release 1.1.1 sind in hohem Maße auch auf diesen anwendbar und werden deshalb als verbindlich betrachtet.

Der TI-Messenger-Client steht als Komponente eines Anwendungs-übergreifenden FdV hingegen in einem Abhängigkeitsverhältnis zu den anderen Anwendungen, die in diesem FdV aufgehen. Deshalb werden Sicherheitsanforderungen, die aus der Spezifikation des TI-Messenger-Clients (Release 1.1.1) übernommen werden mit denen der anderen Programmanteile harmonisiert. Sicherheitsanforderungen, die TI-Messenger-spezifisch sind, werden in ähnlicher Ausprägung für die Spezifikation des umfassenden FdV übernommen werden. Andere, generelle Anforderungen, die in ähnlicher Form auch für ePA- und eRp-FdV gestellt werden, werden inhaltlich angeglichen, sodass diese nicht mehrfach an das umfassende FdV gestellt werden. Treten bei der Angleichung inhaltlich ähnlicher Anforderungen Abweichungen hinsichtlich der Prüfverfahren auf, wird zugunsten des tiefergehenden Prüfverfahrens entschieden.

8 Mitgeltende Inhalte aus TI-Messenger 1.1.1

Die folgenden Kapitel geben einen Überblick welche Inhalte der TI-Messenger 1.1.1 Spezfikation auch für den TI-Messenger-Client im ePA FDV und den TI-Messenger-Fachdienst für Versicherte gelten, bzw. auf welche normativen Vorgaben verzichtet werden kann. 

8.1 gemSpec_TI-Messenger-Client

Tabelle 1: Anpassungen zu gemSpec_TI-Messenger-Client v1.1.1

8.2 gemSpec_TI-Messenger-Dienst

Tabelle 2: Anpassungen zu gemSpec_TI-Messenger-Dienst v1.1.1

8.3 gemSpec_TI-Messenger-FD

Tabelle 3: Anpassungen zu gemSpec_TI-Messenger-FD v1.1.1

9 Anhang – Verzeichnisse

9.1 Abkürzungen

9.2 Glossar

Das Projektglossar wird als eigenständiges Dokument zur Verfügung gestellt.

9.3 Abbildungsverzeichnis

9.4 Tabellenverzeichnis

9.5 Referenzierte Dokumente

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

Weitere Referenzierungen: