gemSpec_TI-Messenger-Client_V1.0.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

TI-Messenger-Client

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
01.10.2021
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_TI-Messenger-Client
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Beim vorliegenden Dokument handelt es sich um die Festlegungen zur ersten Ausbaustufe des TI-Messengers. Diese Ausbaustufe ist definiert durch die Ad-hoc-Kommunikation zwischen Organisationen des Gesundheitswesens. Dabei wird insbesondere die Ad-hoc-Kommunikation zwischen Leistungserbringern bzw. zwischen Leistungserbringerinstitutionen betrachtet. Festlegungen zur Nutzergruppe der Versicherten und Anforderungen an Kassenorganisationen werden in der zweiten Ausbaustufe des TI-Messengers Berücksichtigung finden und daher im vorliegenden Dokument nicht weiter betrachtet. 

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps TI-Messenger-Client. Der TI-Messenger-Client stellt dem Nutzer die benötigte Funktionalität zur sicheren Ad-hoc-Kommunikation mit anderen Teilnehmern bereit. Aus den Kommunikationsbeziehungen mit dem TI-Messenger-Fachdienst und dem VZD-FHIR-Directory resultieren vom TI-Messenger-Client zu nutzende Schnittstellen. In vorliegendem Dokument wird die Nutzung dieser Schnittstellen zur zur sicheren Ad-hoc-Kommunikation und die dafür benötigten Funktionalitäten beschrieben. Vom TI-Messenger-Client genutzte Schnittstellen werden in den entsprechenden Produkttypspezifikationen definiert.

1.2 Zielgruppe

Das Dokument richtet sich zwecks der Realisierung an Hersteller des Produkttypen TI-Messenger-Client sowie an Anbieter, welche diesen Produkttypen betreiben [gemKPT_Betr]. Alle Hersteller und Anbieter von TI-Anwendungen, die Schnittstellen der Komponente nutzen, oder Daten mit dem Produkttypen TI-Messenger-Client austauschen oder solche Daten verarbeiten, müssen dieses Dokument ebenso berücksichtigen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Anbietertypsteckbrief, u.a.) oder Webplattformen (z. B. gitHub, u.a.) festgelegt und bekanntgegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Spezifiziert werden in dem Dokument die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang, Kap. ).

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps TI-Messenger verzeichnet.

1.5 Methodik

Die Spezifikation ist im Stil einer RFC-Spezifikation verfasst. Dies bedeutet: 

• Der gesamte Text in der Spezifikation ist sowohl für den Hersteller des Produktes TI-Messenger-Client als auch für den betreibenden Anbieter entsprechend  [gemKPT_Betr] verbindlich zu betrachten und gilt sowohl als Zulassungskriterium beim Produkt und Anbieter. 
• Die Verbindlichkeit SOLL durch die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet werden. 
• Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet.
• Die Schlüsselworte KÖNNEN außerdem um Pronomen in Großbuchstaben ergänzt werden, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anwendungsfälle und Akzeptanzkriterien als Ausdruck normativer Festlegungen werden als Grundlage für Erlangung der Zulassung durch Tests geprüft und nachgewiesen. Sie besitzen eine eindeutige, permanente ID, welche als Referenz verwendet werden SOLL. Die Tests werden gegen eine von der gematik gestellte Referenz-Implementierung durchgeführt. 

Anwendungsfälle und Akzeptanzkriterien werden im Dokument wie folgt dargestellt:
<ID> - <Titel des Anwendungsfalles / Akzeptanzkriteriums>
Text / Beschreibung
[<=]

Die einzelnen Elemente beschreiben:

• ID: einen eindeutigen Identifier.
• • Bei einem Anwendungsfall besteht der Identifier aus der Zeichenfolge 'AF_' gefolgt von einer Zahl, 
  • Der Identifier eines Akzeptanzkriterium wird von System vergeben, z.B. die Zeichenfolge 'ML_' gefolgt von einer Zahl
• Titel des Anwendungsfalles / Akzeptanzkriteriums: Ein Titel, welcher zusammenfassend den Inhalt beschreibt
• Text / Beschreibung: Ausführliche Beschreibung des Inhalts. Kann neben Text Tabellen, Abbildungen und Modelle enthalten

Dabei umfasst der Anwendungsfall bzw. das Akzeptanzkriterium sämtliche zwischen ID und Textmarke [<=] angeführten Inhalte.

Der für die Erlangung einer Zulassung notwendige  Nachweis der Erfüllung des Anwendungsfalls wird in den jeweiligen  Steckbriefen festgelegt, in denen jeweils der Anwendungsfall gelistet ist. Akzeptanzkriterien werden in der Regel nicht im Steckbrief gelistet.

Hinweis auf offene Punkte

2 Systemüberblick

Der TI-Messenger-Client wird als eine Anwendung (oder eingebettet in bestehende Anwendungen) auf dem Endgerät eines Nutzers installiert und ermöglicht eine sichere, chatbasierte Kommunikation mit anderen Teilnehmern des TI-Messenger-Dienstes. Der TI-Messenger-Client folgt den offenen Standards des Kommunikationsprotokolls Matrix und synchronisiert, durch die Matrix Foundation festgelegte, JSON-Objekte mit Matrix-Homeservern, welche als Teil der TI-Messenger-Fachdienste bereitgestellt werden.

Die Kommunikation zwischen Teilnehmern des TI-Messenger-Dienstes erfolgt Ende-zu-Ende verschlüsselt in Räumen. Die Nachrichten werden auf dem jeweiligen TI-Messenger-Client erstellt und Ende-zu-Ende verschlüsselt versendet. Die Schlüssel zur Entschlüsselung werden nur mit verifizierten Geräten innerhalb des jeweiligen Raumes geteilt. Die Nachrichten werden verschlüsselt auf dem jeweiligen Matrix-Homeserver gespeichert. Die beteiligten Homeserver können die Nachrichten nicht entschlüsseln.

Die Kommunikation zwischen einem TI-Messenger-Client und einem TI-Messenger-Fachdienst erfolgt über die Messenger-Proxies. Auf den Messenger-Proxies findet die TLS-Terminierung der Verbindungen von den TI-Messenger-Clients statt. Die TI-Messenger-Proxies erlauben nur das Anmelden eines Nutzers durch zugelassene TI-Messenger-Clients. Dies wird ermöglicht, indem während des Logins ein auf dem Client hinterlegtes Zertifikat für den Login verwendet wird. Ein TI-Messenger-Client überprüft während des  Logins, ob es sich um einen zugelassenen Matrix-Homeserver handelt.

Die folgende Abbildung "Systemüberblick (Vereinfachte Darstellung)" zeigt einen Systemüberblick aller am TI-Messenger beteiligten Teilkomponenten in vereinfachter Form.

Abbildung 1: Systemüberblick (Vereinfachte Darstellung)

3 Systemkontext

Der folgende Abschnitt setzt den TI-Messenger-Client in den Systemkontext des TI-Messenger-Dienstes.

3.1 Nachbarsysteme

Die folgende Abbildung zeigt die benachbarten Komponenten des TI-Messenger-Clients:

Abbildung 2: Benachbarte Komponenten des TI-Messenger-Clients

Die im Folgenden benannten Nachbarsysteme des TI-Messenger-Clients werden in der [gemSpec_TI-Messenger-Dienst] und [gemSpec_TI-Messenger-FD] hinreichend beschrieben. Die in diesem Dokument zum jeweiligen Nachbarsystem genannten Punkte sollen an dieser Stelle die für das Funktionieren des TI-Messenger-Clients benötigten Funktionen benennen.

Tabelle 1: Übersicht der Komponenten und deren Funktionen

3.2 TI-Messenger-Clients für unterschiedliche Nutzergruppen

Gemäß der Architektur des TI-Messenger-Dienstes wird zwischen zwei Arten von TI-Messenger-Clients unterschieden. Die Unterscheidung ergibt sich ausschließlich aus der Sicht der Nutzer. Jeder Anbieter eines TI-Messenger-Fachdienstes MUSS für seine Nutzergruppen TI-Messenger-Clients in unterschiedlicher Ausprägung anbieten.  Im Folgenden werden die beiden Ausprägungen beschrieben:

TI-Messenger-Client mit Administrationsfunktionen

Der TI-Messenger-Client mit Administrationsfunktionen ist ein Client für Administratoren einer Organisation. Dieser Client dient zur komfortablen Verwaltung der jeweiligen Messenger-Services bei einem TI-Messenger-Fachdienst sowie der Organisationseinträge auf dem VZD-FHIR-Directory. Mit dem Org-Admin-Client besteht die Möglichkeit mittels SMC-B Schreibzugriffe auf das VZD-FHIR-Directory zu erhalten und im Namen der Organisation FHIR-Ressourcen zur Verfügung zu stellen oder zu bearbeiten. Administratoren einer Organisation haben die Möglichkeit mittels des TI-Messenger-Clients mit Administrationsfunktionen Benutzer und Geräte auf dem jeweiligen Messenger-Service zu verwalten. Es besteht ebenfalls die Möglichkeit über den Org-Admin-Client Sessions von angemeldeten Geräten auf dem Messenger-Service zu invalidieren oder zu verifizieren.

TI-Messenger-Client für Nutzer

Der TI-Messenger-Client für Nutzer unterstützt die meisten aller, durch die Matrix-Spezifikation festgelegten Funktionalitäten eines Matrix-Messengers. Nutzer können mit Hilfe des TI-Messenger-Clients Ende-zu-Ende-verschlüsselte Chatnachrichten senden und empfangen. Innerhalb der Chaträume erfolgt der Zugriff auf Chatverläufe, oder das Austauschen von Medien. Ebenfalls besteht für Nutzer die Möglichkeit eigene Geräte und Geräte von Gesprächspartnern zu verifizieren und das VZD-FHIR-Directory nach Organisationen zu durchsuchen, um eine neue Chatkonversation mit einer Organisation zu starten. Es ist den Herstellern freigestellt wie die Oberfläche gestaltet wird. So besteht beispielsweise die Möglichkeit Chaträume nach unterschiedlichen Verwendungszwecken zu organisieren. HBA-Inhaber haben zusätzlich die Möglichkeit, die eigene MXID als Kontaktadresse des bereits vorhandenen Practitoner-Eintrages zu setzen. Das Eintragen der MXID gewährt die Suche nach anderen, auf dem VZD-FHIR-Directory eingetragenen HBA-Inhabern und ermöglicht das Auffinden durch andere HBA-Inhaber. 

3.3 TI-Messenger-Clients für unterschiedliche Plattformen

Anbieter eines TI-Messenger-Clients MÜSSEN einen mobilen- und einen desktopfähigen TI-Messenger-Client zur Verfügung stellen. TI-Messenger-Clients haben je nach Installationsort (Mobil/Stationär) unterschiedliche Anforderungen an Sicherheit, Datenschutz und Funktionen. Im Folgenden werden die zu unterstützenden Plattformen beschrieben:

Mobil

Es handelt sich hierbei um einen TI-Messenger-Client, der speziell für die Nutzung auf mobilen Geräten entwickelt wurde. Dabei handelt es sich um eine native mobile Anwendung oder eine Integration in eine bestehende native Anwendung. Die mobile Anwendung MUSS die betriebssystemseitigen Funktionen in Bezug auf Sicherheit nutzen und sicherstellen, dass die Speicherung von Daten getrennt und verschlüsselt vom Dateisystem erfolgt. Ein unerlaubter Zugriff durch Dritte MUSS aktiv verhindert werden. 

Web

Der TI-Messenger-Client KANN als Web-Frontend für den stationären Einsatz zur Verfügung gestellt werden. Es MUSS sichergestellt werden, dass die Web-Applikation vor unerlaubten Zugriff durch andere Nutzer geschützt wird. Es MUSS sichergestellt werden, dass bei Aufruf des Web-Frontends durch Nutzer auf dem Mobilgerät ein entsprechender Nutzungshinweis angezeigt wird.

Desktop

Der TI-Messenger-Client KANN als native- oder Web-Applikation für Desktop-Geräte zur Verfügung gestellt werden.

Integriert

Für die Nutzung des TI-Messenger-Dienstes KANN die Integration eines TI-Messenger-Clients in existierende Primärsysteme erfolgen. Diese Primärsysteme können sowohl mobile als auch stationäre Anwendungen sein.

4 Übergreifende Festlegungen

4.1 Datenschutz und Sicherheit

Für die datenschutzrechtlichen Anforderungen an den TI-Messenger wird auf die Stellungnahme der Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder vom 29. April 2021 zum Thema "Technische Datenschutzanforderungen an Messenger-Dienste im Krankenhausbereich" verwiesen. Die Inhalte der Stellungnahme werden hier zusammenfassend und vereinfachend als Akzeptanzkriterium an den TI-Messenger-Client dargestellt. Anforderungen, die durch andere Systemkomponenten sichergestellt werden, sind hier nicht dargestellt.

Maßnahmenvorschläge:

• Prüfen, ob Dokumenten-Format und Inhalt mit dem angegebenen Dokumententyp in den Metadaten übereinstimmt 
• Vor der Anzeige eines Dokumentes sind Sonder- und Meta-Zeichen im Dokument für die jeweilige Anzeigesoftware mit der richtigen Escape-Syntax zu entschärfen.
  
• Die Anzeigesoftware in einer Sandbox betreiben.

Zusatzfunktionen sind Funktionen des TI-Messenger-Clients und verwenden den gleichen Speicherbereich, sofern es sich nicht um Drittprogramm konzipierte Zusatzfunktionen handelt.

4.2 Benutzerführung

Mittels einer geeigneten Benutzerführung wird eine hohe Akzeptanz des Nutzers erreicht. Hierzu zählt eine einfache und selbsterklärende Bedienung der Oberfläche, die sich an gängige auf dem Markt zu findenden App-Design-Empfehlungen orientiert. Ebenfalls MÜSSEN alle infrage kommenden Zielgruppen betrachtet werden. Es MÜSSEN folgende interoperablen Funktionen durch den Hersteller bereitgestellt werden, um ein Mindestmaß an Nutzererfahrung zu erreichen. 

Präsenzanzeige

Für eine Echtzeitnutzererfahrung, MÜSSEN TI-Messenger-Clients gemäß [Präsenzanzeige] eine Präsenzanzeige für andere Gesprächspartner zur Verfügung stellen. Die Präsenzanzeige MUSS an- und abschaltbar sein und MUSS gemäß Privacy-by-default (Art. 25 Abs. 2 DSGVO und nachgelagert ML-123607) standardmäßig deaktiviert sein.

Erwähnungen

TI-Messenger-Clients MÜSSEN es ermöglichen, dass über das Eingabefeld andere Nutzer gemäß [Erwähnung] im jeweiligen Chatraum erwähnt werden können. Dazu MUSS der TI-Messenger-Client eine entsprechende Nutzerliste anzeigen, sobald der Nutzer ein neues Wort mit "@" startet, oder einen entsprechenden "@" Knopf im Chatraum anbieten. TI-Messenger-Clients MÜSSEN Nutzererwähnungen entsprechend als "Pile" in dem Chatraum anzeigen. Handelt es sich um einen TI-Messenger-Client für mobile Geräte, oder Geräte mit Push-Funktionalität, MUSS der Client eine entsprechende Push-Benachrichtigung anzeigen, wenn der Nutzer die entsprechenden Push-Regeln eingestellt hat.

Lesebestätigungen

Lesebestätigungen dienen dem Ziel einen Aufschluss darüber zu geben, wann, ob und von wem eine Nachricht innerhalb eines Chatraums gelesen wurde. Aus diesem Grund MÜSSEN mobile TI-Messenger-Clients die Matrix-Spezifikation gemäß [Lesebestätigungen] vollständig implementieren. TI-Messenger-Clients für Nutzer MÜSSEN diese Funktion des Anzeigens und Sendens von Lesebestätigungen vollständig implementieren. Der TI-Messenger-Client MUSS Fully-Readmarkers unterstützen. Lesebestätigungen MÜSSEN an- und abschaltbar sein und MÜSSEN gemäß Privacy-by-default (Art. 25 Abs. 2 DSGVO und nachgelagert ML-123607) standardmäßig deaktiviert sein.

Eingabebenachrichtigungen

Mobile TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [Eingabebenachrichtigungen] vollständig implementieren. TI-Messenger-Clients SOLLEN Nutzern anzeigen, wenn die Gegenseite eine Nachricht in einem Chatraum schreibt. Die Eingabebenachrichtigungen MÜSSEN an- und abschaltbar sein und MÜSSEN gemäß Privacy-by-default (Art. 25 Abs. 2 DSGVO und nachgelagert ML-123607) standardmäßig deaktiviert sein. 

Barrierefreiheit

4.3 Konfiguration des TI-Messenger-Clients

Im folgenden Kapitel werden alle zu konfigurierenden Funktionen beschrieben, die im TI-Messenger-Client durch den Nutzer konfigurierbar sein müssen.

Einstellung von Push-Benachrichtigungen

TI-Messenger-Clients MÜSSEN über eine Funktion verfügen, um Push-Benachrichtigungen auf einem Gerät konfigurieren zu können. Dazu MÜSSEN neben [Push-Rules] auch geräteseitige Einstellungsmöglichkeiten den Nutzern zur Verfügung gestellt werden.

Nutzer ignorieren

TI-Messenger-Clients MÜSSEN über eine Funktion verfügen, um Nachrichten anderer Nutzer zu ignorieren. Daher MÜSSEN mobile TI-Messenger-Clients die Matrix-Spezifikation gemäß [Nutzer ignorieren] vollständig implementieren.

TI-Messenger-Clients MÜSSEN eine Liste aller ignorierten Nutzer anzeigen und die Möglichkeit bieten das Ignorieren von Nutzern rückgängig zu machen.

Raum-Historie

Mobile TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [Raum Historie] vollständig implementieren.

TI-Messenger-Clients MÜSSEN Einstellungen zur Verfügung stellen, um die Sichtbarkeit der Raum-Historie festlegen zu können. Als Standard SOLLTE die Raum-Historie ab dem Zeitpunkt des Beitritts sichtbar sein.

4.4 Test

Produkttests zur Sicherstellung der Konformität mit der Spezifikation sind vollständig in der Verantwortung der Anbieter/Hersteller des TI-Messenger-Clients. Die gematik konzentriert sich bei der Zulassung auf das Zusammenspiel der Produkte durch E2E- und IOP Tests.

Die eigenverantwortlichen Produkttests bei den Industriepartnern umfassen:

• Testumgebung entwickeln,
• Testfallkatalog erstellen (für eigene Produkttests) und
  
• Produkttest durchführen und dokumentieren

Die Hersteller der TI-Messenger-Fachdienste MÜSSEN zusichern, dass die gematik die Produkttests der Industriepartner in Form von Reviews der Testkonzepte, Testspezifikationen, Testfälle sowie mit dem Review der Testprotokolle (Log- und Trace-Daten) überprüfen kann.

Die gematik fördert eine enge Zusammenarbeit und unterstützt Industriepartner dabei, die Qualität der Produkte zu verbessern. Dies erfolgt durch die Organisation früher IOP-Tests, die Synchronisierung von Meilensteinen und regelmäßige industriepartnerübergreifenden Test-Sessions. Die Test-Sessions umfassen gegenseitige IOP- und E2E Tests.

Die gematik stellt eine TI-Messenger-Fachdienst 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 gegen die Referenzimplementierung (TI-Messenger-Client und TI-Messenger Fachdienst) getestet werden.

Die gematik testet in den Zulassungsverfahren auf Basis von Anwendungsfällen. Dabei werden die Anwendungsfälle durchgespielt und es wird versucht viele Funktionsbereiche und Teile der Anwendung mit einzubeziehen. Anschließend wird mit den IOP Tests die Interoperabilität zwischen den verschiedenen Anbieter nachgewiesen. Für das Zulassungsverfahren des TI-Messenger-Dienst müssen die TI-Messenger-Clients und TI-Messenger FD bereitgestellt werden. Um einen automatisierten Test für den TI-Messenger-Dienst zu ermöglichen, muss die Test-App des TI-Messenger-Clients zusätzlich ein Testtreiber-Modul beinhalten, welcher die Funktionalitäten der produktspezifischen Schnittstelle des TI-Messenger-Clients über eine standardisierte Schnittstelle von außen zugänglich macht und einen Fernzugriff ermöglicht.

Abbildung 3: Testtreiberschnittstelle

Das Testtreiber-Modul darf die Ausgaben des TI-Messenger-Clients gemäß der technischen Schnittstelle aufarbeiten, aber darf die Inhalte nicht verfälschen. Die konkrete Ausgestaltung der Schnittstellen wird im Fachportal der gematik und in GitHub zur Verfügung gestellt.

Der Einsatz des Testtreiber-Moduls ist auf das Zulassungsverfahren in Test-Apps beschränkt und darf nicht in Wirkbetriebs-Apps genutzt werden.

4.5 Betriebliche Aspekte

Die Betriebsbereitschaft des bzw. der Clients vom TI-Messenger Anbieter bezieht sich in diesem Kapitel auf serverseitige Systeme welche notwendig sind, damit der Client vom Nutzer sicher-funktional betrieben werden kann. Der sichere Betrieb im Sinne der Nutzung auf ihren Endgeräten des TI-Messenger-Clients liegt letztendlich in der Verantwortung bei den Nutzern des TI-Messengers.

Der TI-Messenger-Anbieter MUSS seine Nutzer dabei unterstützen, einen sicheren und funktionalen Betrieb der TI-Messenger-Clients zu ermöglichen.

Der TI-Messenger-Client MUSS mit einer vollumfänglich-funktionalen Verfügbarkeit von 98 % betreibbar sein. 

Der Anbieter TI-Messenger MUSS sein Produkt TI-Messenger-Client mit einer vollumfänglich-funktionalen Verfügbarkeit von 98% seinen Nutzern anbieten.

5 Funktionsmerkmale

Die Funktionen des TI-Messenger-Clients ergeben sich aus den Funktionen der Matrix-Spezifikation. Die hier beschriebenen Funktionen MÜSSEN durch den jeweiligen TI-Messenger-Client unterstützt werden. Funktionen, welche durch Matrix bereitgestellt wurden, aber nicht Teil dieser Spezifikation sind und keine Fallbacks bieten, DÜRFEN NICHT implementiert werden, um die Interoperabilität zu gewährleisten.

5.1 Authentisierung

SSO Login

TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [SSO Login] vollständig implementieren.

OpenID

TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [OpenID] vollständig implementieren.

Gäste Accounts

Der Hersteller eines TI-Messenger-Client MUSS sicherstellen, dass eine Erstellung von Gäste-Accounts verhindert wird.

5.2 Matrix-Client-Server-API

Die Kernbestandteile des TI-Messenger-Clients basieren auf der Matrix-Client-Server-API. Diese umfasst neben dem eigentlichen Funktionsumfang für einen Ad-hoc-Nachrichtendienst auch die Verwaltung der Sessions, Benachrichtigungen etc., worauf in dieser Spezifikation nicht weiter eingegangen wird. TI-Messenger-Clients MÜSSEN die Matrix-Client-Server-API gemäß [Matrix Foundation#Client_Server API] umsetzen.

Room Upgrades

TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [Room Upgrades] vollständig implementieren. TI-Messenger-Clients MÜSSEN mit Raum Upgrades umgehen können. Der Nutzer SOLLTE NICHT bemerken, dass eine neue Raumversion vorliegt.

Send-to-Device messaging

TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [Send-to-Device messaging] vollständig implementieren und umsetzen.

Geräteverwaltung

TI-Messenger-Clients MÜSSEN eine Geräteverwaltung für die eigenen Geräte eines Nutzers, für die Geräte anderer Nutzer in einem Chatraum, sowie für die Geräte aller Nutzer eines Messenger-Services in der Rolle des Org-Admin unterstützen. Daher MÜSSEN TI-Messenger-Clients die Matrix-Spezifikation gemäß [Geräteverwaltung] vollständig implementieren.

Ende-zu-Ende-Verschlüsselung

TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [Ende-zu-Ende-Verschlüsselung] vollständig implementieren. TI-Messenger-Clients MÜSSEN eine Ende-zu-End-Verschlüsselung entsprechend der Matrix-Spezifikation unterstützen. Der Hersteller von TI-Messenger-Clients MUSS verhindern, dass nicht Ende-zu-Ende verschlüsselten Nachrichten versendet werden.

Reporting von Inhalten

TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [Reporting-content] implementieren und den Nutzern die Möglichkeit geben, unerwünschten Inhalt an Nutzer in der Rolle Org-Admin zu melden.

5.3 Instant Messaging

Instant Messaging MUSS von einem TI-Messenger-Client vollständig nach der Matrix-Spezifikation gemäß [Instant Messaging] implementiert werden. Ein TI-Messenger-Client MUSS sicherstellen, dass alle eingehenden und ausgehenden Events in der richtigen chronologischen  Reihenfolge dem Nutzer angezeigt werden. Ein TI-Messenger-Client MUSS eine Wiederholungslogik für das Senden von Nachrichten unterstützen. TI-Messenger-Clients SOLLEN die MXID eines Nutzers verstecken und SOLLEN den Displaynamen anzeigen. TI-Messenger-Clients MÜSSEN Nutzer informieren, falls ein Event nicht oder fehlerhaft versendet wurde.

Folgende Events und Msgtypes MÜSSEN unterstützt werden:

Tabelle 2: Events und Msgtypes

Nachrichten in Matrix können sowohl im Plaintext als auch in HTML-formatierter Form versendet werden. Für den Fall, dass ein Client keine formatierten Nachrichten unterstützt, ist ein Fallback im Plaintext für beispielsweise Replies spezifiziert:

https://spec.matrix.org/unstable/client-server-api/#fallbacks-for-rich-replies 

TI-Messenger-Clients MÜSSEN Fallbacks für folgende Events unterstützen:

• Fallback für Antworten/Zitieren
• Fallback für m.text, m.notice

Hinweis: Unter einem Fallback versteht man, dass der TI-Messenger-Client neben dem formatierten Body auch einen unformatierten Body sendet, welcher von TI-Messenger-Clients ohne die jeweilige Formatierung genutzt werden kann.

5.4 Direct Messaging

TI-Messenger-Clients MÜSSEN eine Funktion anbieten, um Direktnachrichten gemäß [Direct Messaging] mit anderen Nutzern des TI-Messenger-Dienstes auszutauschen. Direktnachrichten bedeutet, dass ein Chatraum nur zwischen zwei Personen erstellt wird. Dieser Chatraum kann nicht um weitere Teilnehmer erweitert werden. Soll ein Chatraum für mehr als zwei Teilnehmer erstellt werden, ist Group Messaging zu verwenden . Chaträume, die mit einer Organisation geführt werden sollen, unterliegen grundsätzlich dem Group Messaging. Die folgenden Möglichkeiten MÜSSEN dabei vom TI-Messenger-Client angeboten werden:

5.5 Group Messaging

TI-Messenger-Clients MÜSSEN eine Funktion anbieten, um Gruppenunterhaltungen zu starten und Nachrichten innerhalb einer Chatgruppe mit unbegrenzt vielen Nutzern des TI-Messenger-Dienstes auszutauschen. TI-Messenger-Clients MÜSSEN alle Teilnehmer einer Chatgruppe anzeigen. Darüberhinaus MÜSSEN TI-Messenger-Clients alle Teilnehmer einer Gruppe benachrichtigen, wenn ein weiterer Teilnehmer in die Chatgruppe hinzugefügt wurde. Teilnehmer dürfen nur mittels Einladung in eine Chatgruppe hinzugefügt werden.

5.6 Push-Benachrichtigungen

Mobile TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [Push-Benachrichtigungen] vollständig implementieren.

5.6.1 Allgemein

Abbildung 4: Push-Benachrichtigung für Mobilgeräte

Die Abbildung "Push-Benachrichtigung für Mobilgeräte" zeigt den Fluss von Push-Benachrichtigungen, die an ein Mobiltelefon gesendet werden, bei dem die Push-Benachrichtigungen über den Anbieter des Mobiltelefons übermittelt werden . Dies geschieht wie folgt:

1. Der TI-Messenger-Client meldet sich bei einem Matrix-Homeserver an.
2. Der TI-Messenger-Client meldet sich beim Push-Anbieter an und erhält ein Routing-Token.
3. Der TI-Messenger-Client verwendet die Matrix-Client/Server-API, um einen "Pusher" hinzuzufügen, indem die URL des Push-Gateways angegeben wird, das für den TI-Messenger-Client konfiguriert ist und gibt das Routing-Token weiter.
4. Der Matrix-Homeserver leitet Push-Benachrichtigungen an das unter der URL angegebene Push-Gateway. Das Push-Gateway leitet diese Benachrichtigung an den Push-Anbieter weiter und übergibt dabei das Routing-Token zusammen mit allen erforderlichen privaten Anmeldeinformationen, die der Anbieter zum Senden von Push-Benachrichtigungen benötigt.
5. Der Push-Anbieter sendet die Benachrichtigung an das Gerät.
6. Das  Betriebssystem des Endgeräts reicht die Benachrichtigung an den TI-Messenger-Client weiter.
7. Der TI-Messenger-Client entschlüsselt die Benachrichtigung.
8. Der TI-Messenger-Client synchronisiert mit dem Matrix-Homeserver und zeigt die Benachrichtigung lokal an.

5.6.2 Push-Anbieter

Ein Push-Anbieter ist ein vom Gerätehersteller verwalteter Dienst, der Benachrichtigungen direkt an das Gerät senden kann. Ein mobiler TI-Messenger-Client MUSS den jeweiligen Push-Anbieter des Systems unterstützen.

5.6.3 Push-Gateway

Ein Push-Gateway wird vom TI-Messenger-Anbieter zur Verfügung gestellt und ist ein Server, der Ereignisbenachrichtigungen von Matrix-Homeservern empfängt und  diese an andere Dienste weiterleitet. Die TI-Messenger-Clients erhalten organisatorisch ein Routing-Token durch den TI-Messenger-Anbieter und teilen dem Matrix-Homeserver mit, an welches Push-Gateway die Benachrichtigungen gesendet werden sollen. Ein mobiler TI-Messenger-Client MUSS organisatorisch mit dem Push-Gateway des TI-Messenger-Anbieters verknüpft sein. Der TI-Messenger-Client MUSS sicherstellen, dass das Routing-Token sicher auf dem Endgerät verwahrt wird.

5.6.4 Push-Regel

Eine Push-Regel ist eine einzelne Regel, die festlegt, unter welchen Bedingungen ein Ereignis an ein Push-Gateway weitergeleitet werden soll und wie die Benachrichtigung präsentiert werden soll. Diese Regeln werden auf dem Matrix-Homeserver des Benutzers gespeichert. Der TI-Messenger-Client MUSS Nutzern die Möglichkeit geben, Push-Regeln für jeden Raum zu erstellen und anzuzeigen.

5.6.5 Push-Regelsatz

Ein Push-Regelsatz deckt einen Satz von Regeln nach bestimmten Kriterien ab. Beispielsweise können einige Regeln nur für Nachrichten von einem bestimmten Absender, einem bestimmten Raum oder standardmäßig angewendet werden. Der Push-Regelsatz enthält den gesamten Satz an Geltungsbereichen und Regeln. Ein mobiler TI-Messenger-Client MUSS dem Nutzer Möglichkeiten anbieten Push-Regelsätze zu verwalten.

5.6.6 Opt-In

Der Hersteller eines TI-Messenger-Clients MUSS ein Opt-In Verfahren für Push-Benachrichtigungen durch Nutzer bereitstellen. Das Opt-In Verfahren MUSS jeweils pro Endgerät bereitgestellt werden.

5.7 Weitere Funktionen

Erstellung des Localparts

Der TI-Messenger-Client MUSS bei der Erstellung des Localparts der MXID eines Nutzers sicherstellen, dass keine personenbezogenen Daten entstehen. Dazu MUSS der TI-Messenger-Client den local-Part der verwendeten MXID des Nutzers als Base32 SHA256 Hash berechnen.

Beispiel einer MXID

@74c1fecc710ce4c8a8bbe310fbc5954c2a5e1e9ef5f70d651da1bfc4c9abe43f:<domain>.de

Displayname

Der TI-Messenger-Client MUSS sicherstellen, dass nur Nutzer in der Rolle Org-Admin den Displaynamen von Nutzern bearbeiten können. Es MUSS sichergestellt werden, dass Nutzer den eigenen Displaynamen nicht ändern können. 

Server Administration

Mobile TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [Server Administration] vollständig implementieren.

TI-Messenger-Clients MÜSSEN entsprechende Administrationsfunktionen für einen Messenger-Service zur Verfügung stellen. Dazu gehören:

• Benutzerverwaltung (Liste aller Benutzer, Anlegen, Bearbeiten, Löschen)
• Geräteverwaltung (Anzeigen, Abmelden, Löschen aller Geräte des Homeservers)
• VZD-FHIR-Directory (Schreibzugriff mittels SMC-B)
• Systemmeldungen an Nutzer eines Messenger-Services
• Nutzerverzeichnis: Sichtbarkeit zwischen Nutzern kann durch den Nutzer in der Rolle Org-Admin eingeschränkt werden

Hinweis: Die Funktionen der Server Administration können in einen separaten Administrations-Client ausgelagert werden. Sofern reguläre Nutzerfunktionen und Administrationsfunktionen in derselben Applikation angeboten werden, so sollte auf eine klar erkennbare Unterscheidung zwischen Nutzer- und Administrationsfunktionen geachtet werden. Es MUSS sichergestellt werden, dass nur Akteure in der Rolle Org-Admin die Administrationsfunktionen nutzen können. 

Third Party Networks / Bridging

Das Bridging zu Drittsystemen zur Zwecken der Kommunikation (Austausch von Matrix-Events) ist nicht erlaubt. Das Bridging zu Drittsystemen ist nur zum Archivieren von Chatinhalten erlaubt. Es MUSS sichergestellt werden, dass eine Ende-zu-Ende Verschlüsselung mittels OLM/MEGOLM zu jeder Zeit erfolgt. 

Nutzerverzeichnis eines Messenger-Services

Der TI-Messenger-Client KANN eine Funktion bereitstellen, dass Nutzer auf dem jeweiligen Messenger-Service ein Verzeichnis von Nutzern aufrufen oder durchsuchen können.

Suchabfragen VZD-FHIR-Directory

Der TI-Messenger-Client MUSS eine Funktion bereitstellen, dass Nutzer das VZD-FHIR-Directory nach Ressourcen durchsuchen können. Der TI-Messenger-Client MUSS eine Funktion bereitstellen, um Detailinformationen der auf dem VZD-FHIR-Directory gespeicherten Ressourcen anzuzeigen. Weitere Spezifikationen finden sich in [gemSpec_VZD_FHIR_Directory].

Verbindung nur mit in der Föderation vorhandenen Messenger-Services

Der TI-Messenger-Client MUSS sicherstellen, dass eine Nutzung nur mit Matrix-Homeservern möglich ist die Teil der Föderation sind. Verbindet sich der TI-Messenger-Client mit einem Matrix-Homeserver, welcher nicht Teil der Föderation ist, MUSS der Nutzer direkt ausgeloggt werden.

Ende-zu-Ende Verschlüsselung

Der TI-Messenger-Client MUSS sicherstellen, dass sämtliche Nachrichteninhalte Ende-zu-Ende [Ende-zu-Ende Verschlüsselung] verschlüsselt werden. Das Senden von Nachrichten ohne Ende-zu-Ende Verschlüsselung MUSS technisch unterbunden werden.

Archivierung von Gesprächsinhalten mittels Chatbot-Clients

Für eine echtzeitnahe und automatische Archivierung von Gesprächsinhalten zu Nachweiszwecken werden vom Anbieter des TI-Messenger-Homeservers sog. Archivbots bereitgestellt, bei welchen es sich um funktional eingeschränkte Matrix-Clients handelt. Diese können entweder von Leistungserbringern zu Gesprächen eingeladen werden oder sind für bestimmte Gesprächsraumtypen automatisch bei der Raumerstellung eingeladen (konfigurierbar durch LE-Organisation).

Der einzige Zweck des Archivbots besteht darin, eine Unterhaltung oder Teile dieser zu entschlüsseln und zu archivieren. Hierzu betritt der Archivbot den Gesprächsraum, in den er eingeladen wurde und kann somit darin versandte Nachrichten entschlüsseln und als FHIR-Ressource archivieren. Der Archivbot liegt in der Leistungserbringerumgebung und kommuniziert zum Ablegen archivierter Nachrichten mittels TLS mit einem Endpunkt, z.B. des PVS/KIS oder einem LE-Archivierungs-Backend.

Der Archivbot ist als Gesprächsteilnehmer für alle anderen Teilnehmer sichtbar und klar als rein funktionaler Archivbot benannt. Es wird empfohlen, dass der Archivbot bei Betreten eines Gesprächsraums ein kurzes Statement zu seiner Funktion abgibt, um Missverständnisse zu vermeiden.

Es ist vorgesehen, dass auch Gespräche ohne Archivbot geführt werden können, welche dementsprechend nicht archiviert werden. Bei Archivbots handelt es sich nicht um vollwertige TI-Messenger-Clients, weswegen sie bezüglich der Client-Anforderungen gesondert betrachtet werden müssen.

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

6.2 Glossar

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

6.3 Abbildungsverzeichnis

6.4 Tabellenverzeichnis

6.5 Referenzierte Dokumente

6.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

6.5.2 Weitere Dokumente