gemSpec_TI-Messenger-Client_V1.1.0_Aend

 

 

 

 

 

Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

 

 

Spezifikation

TI-Messenger-Client

 

 

 

   

   

Version	1.01.0
Revision	408371557497
Stand	01.10.202129.07.2022
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

DokumentinformationenDokumentinformationen

InhaltsverzeichnisInhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

1.2 Zielgruppe

1.3 Geltungsbereich

1.4 Abgrenzungen

1.5 Methodik

2 Systemüberblick

3 Systemkontext

3.1 Nachbarsysteme

3.2 Ausprägungen der TI-Messenger-Clients für unterschiedliche Nutzergruppen

3.3 TI-Messenger-Clients für unterschiedliche Plattformen3.2.1 Nutzergruppen

4 Übergreifende Festlegungen3.2.2 Plattformen

4.1 Datenschutz und Sicherheit3.2.3 Weitere Festlegungen

4.2 Benutzerführung4 Übergreifende Festlegungen

4.3 Konfiguration des TI-Messenger-Clients4.1 Datenschutz und Sicherheit

4.4 Test4.2 Authentifizierung am VZD-FHIR-Directory

4.5 Betriebliche Aspekte4.3 Benutzerführung

5 Funktionsmerkmale4.4 Konfiguration

5.1 Authentisierung4.5 Test

5.2 Matrix-Client-Server-API4.6 Betriebliche Aspekte

5.3 Instant Messaging5 Funktionsmerkmale

5.4 Direct Messaging5.1 Authentifizierungsverfahren

5.5 Group Messaging5.2 Matrix Client-Server API

5.6 Push-Benachrichtigungen5.2.1 Sofortnachrichten

5.6.1 Allgemein5.2.2 Direktnachrichten

5.6.2 Push-Anbieter5.2.3 Gruppenunterhaltungen

5.6.3 Push-Gateway5.2.4 Push-Benachrichtigungen

5.6.4 Push-Regel5.3 Administrationsfunktionen

5.6.5 Push-Regelsatz5.4 Weitere Funktionen

5.6.6 Opt-In6 Anhang A – Verzeichnisse

5.7 Weitere Funktionen6.1 Abkürzungen

6 Anhang A – Verzeichnisse6.2 Glossar

6.1 Abkürzungen6.3 Abbildungsverzeichnis

6.2 Glossar6.4 Tabellenverzeichnis

6.3 Abbildungsverzeichnis6.5 Referenzierte Dokumente

6.4 Tabellenverzeichnis6.5.1 Dokumente der gematik

6.5 Referenzierte Dokumente6.5.2 Weitere Dokumente

6.5.1 Dokumente der gematik

6.5.2 Weitere Dokumente

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 KassenorganisationenKrankenversicherungsorganisationen 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 AkzeptanzkriteriumAkzeptanzkriteriums 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 NutzersAkteurs installiert und ermöglicht eine sichere, chatbasiertenachrichtenbasierte Kommunikation mit anderen TeilnehmernAkteuren 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 derdes Messenger-Services eines TI-Messenger-FachdiensteFachdienstes bereitgestellt werden.

Die Kommunikation zwischen Teilnehmernden Akteuren 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ätengesendeten Nachrichten werden verschlüsselt auf dem jeweiligen Matrix-Homeserver gespeichert. Der für die Entschlüsselung benötigte Schlüssel wird nur mit verifizierten Endgeräten innerhalb des jeweiligen Raumes geteilt. Die Nachrichten werden verschlüsselt auf dem jeweiligenbeteiligten 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 zugelasseneAkteurs mit zugelassenen TI-Messenger-Clients. Dies wird ermöglicht, indem während des Logins eindie auf dem Client hinterlegtes Zertifikat für den Login verwendet wird. Ein TI-Messenger-Client überprüft während des  Loginshinterlegte client_id durch den Messenger-Proxy überprüft wird. Zusätzlich wird während des Anmeldevorgangs durch den TI-Messenger-Client am Auth-Service des VZD-FHIR-Directory geprüft, ob es sich um einen zugelassenen Matrix-Homeserver handelt.

Die folgendeIn der folgenden Abbildung "Systemüberblick (Vereinfachte Darstellung)" zeigt einen Systemüberblick aller am TI-Messenger beteiligten Teilkomponenten in vereinfachter Formsind alle beteiligten Komponenten der TI-Messenger-Architektur in vereinfachter Form dargestellt. Der in der Abbildung grün dargestellte TI-Messenger-Client zeigt die Komponente die in dieser Spezifikation beschrieben wird.

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

Der TI-Messenger-Client ermöglicht es den Akteuren mit dem TI-Messenger-Dienst zu interagieren. Für die Interaktion mit dem TI-Messenger-Dienst werden vom TI-Messenger-Client weitere Systeme benötigt. Die folgende Abbildung zeigt die benachbarten Komponenten des TI-Messenger-Clients:

 

Abbildung 2: Benachbarte Komponenten des TI-Messenger-Clients

Die im Folgendenin der Abbildung 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 FunktionierenFür die Einordnung der Komponenten im Kontext des TI-Messenger-Clients benötigten Funktionen benennenwerden diese im Folgenden kurz erläutert.

Tabelle 1: Übersicht der Komponenten und deren Funktionen

Komponente	Funktion
Push-Gateway	Weiterleitung von  Push-Benachrichtigungen an Push-Dienste im Internet
Messenger-Service	•   Stellt für  TI-Messenger-Clients Schnittstellen gemäß [Matrix Foundation#Client_Server] bereit •   Liefert Matrix-OpenID-Token für Lesezugriff VZD-FHIR-Directory
RegistrierungsPush-Dienst	Der TI-Messenger-Client benötigt für diverse Aktionen eine Verbindung zum Registrierungs-Dienst. Dazu gehören:  Bereitstellung einer Registrierungsmaske / Endpunkte für Erstellung von Messenger-ServicesPush-Dienste (z. B. FCM / APN) sind Services von Push-Anbietern und werden für die native Unterstützung von Push-Benachrichtigungen auf mobilen Geräten benötigt.
IDP-Dienst	•   OpenID-Connect für Schreibzugriff auf VZD-FHIR-Directory (mittels HBA/SMC-B)
VZD-FHIR-DirectoryMessenger-Service	Lesezugriff aufStellt für einen Nutzer freigegebene, hinterlegte Attribute die TI-Messenger-Client-Schnittstellen gemäß [Client-Server API] bereit. Schreibzugriff zum Eintragen von  FHIR-RessourcenTerminiert die TLS-Verbindung der TI-Messenger-Clients. Prüft Anfragen der TI-Messenger-Clients. Stellt eine Schnittstelle zur Pflege der persönlichen Freigabeliste bereit. Stellt für die TI-Messenger-Clients Matrix-OpenID-Token aus.
TI-Messenger-ClientIDP-Dienst	Für den Aufbau einer Kommunikation ohne das VZD-FHIR-Directory kann der TI-Messenger-Client eine direkte Verbindung zu einem anderen TI-Messenger-Client aufbauen. Ziel dieser Verbindung ist der Austausch der MXID und PASSporT, damit ein Invite Request durch die jeweiligen Messenger-Services validiert werden kannStellt ID_TOKEN aus, um sich beispielweise an einem Matrix-Homeserver mittels OpenID-Connect zu authentisieren.
Push-Dienst VZD-FHIR-Directory	Push-Dienste sind Services von Push-Anbietern und werden für die native Unterstützung von Push-Benachrichtigungen auf der Mehrzahl mobiler Geräte benötigt.Ausstellen von access-tokens (search-accesstoken und owner-accesstoken) Lesen oder Schreiben von FHIR-Ressourcen

3.2 Ausprägungen der TI-Messenger-Clients für unterschiedliche

3.2.1 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.  Akteure. Im Folgenden werden die beiden Ausprägungen beschrieben:.

TI-Messenger-Client mit Administrationsfunktionen (Org-Admin-Client)

Der TI-Messenger-Client mit Administrationsfunktionen ist ein Client für Administratoren einer Organisation. Dieser wird im TI-Messenger-Kontext auch als Org-Admin-Client bezeichnet. Der Org-Admin-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. Ebenfalls haben Administratoren einer Organisation haben die Möglichkeit mittelsmit Hilfe des TI-MessengerOrg-Admin-Clients mit Administrationsfunktionen Benutzer und Geräte auf dem jeweiligen Messenger-Service zu verwalten. EsDarüber hinaus besteht ebenfalls die Möglichkeit, über den Org-Admin-Client Sessions von angemeldeten Geräten auf dem Messenger-Service zu invalidierenverifizieren oder zu verifiziereninvalidieren. Das bedeutet zum Beispiel, dass ein Akteur in der Rolle "Org-Admin" einen TI-Messenger-Client eines Akteurs bei Bedarf abmelden kann. Weiterhin können über den Org-Admin-Client Funktionsaccounts  gemäß [gemSpec_TI-Messenger-Dienst#Funktionsaccounts] für die übergreifende Kommunikation innerhalb einer Organisationsstruktur des TI-Messenger-Fachdienstes administriert werden.

TI-Messenger-Client für NutzerAkteure

Der TI-Messenger-Client für NutzerAkteure unterstützt die meisten aller, durch die Matrix-Spezifikation festgelegten Funktionalitäten eines Matrix-Messengers. NutzerAkteure können mit Hilfe des TI-Messenger-dieses 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 NutzerAkteure 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-InhaberAkteure in der Rolle "User-HBA" haben zusätzlich die Möglichkeit, die eigene MXID als Kontaktadresse des bereits vorhandenen Practitoner Practitioner-Eintrages zu setzenauf dem VZD-FHIR-Directory hinzuzufügen. Das Eintragen der MXID gewährt die Suche nach anderen, auf dem VZD-FHIR-Directory eingetragenen HBA-InhabernAkteuren in der Rolle "User-HBA" und ermöglicht das Auffinden durch andere HBA-Inhaber. Akteure.

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 InstallationsortHinweis: Die beiden oben beschriebenen Ausprägungen KÖNNEN auch in einem TI-Messenger-Client integriert sein. Die Art der Umsetzung obliegt dem jeweiligen TI-Messenger-Client-Hersteller.

3.2.2 Plattformen

TI-Messenger-Clients haben je nach Plattform (Mobil/Stationär) unterschiedliche Anforderungen an Sicherheit, Datenschutz und FunktionenFunktionalität. Im Folgenden werden die zu unterstützenden Plattformen näher beschrieben:.

MobilTI-Messenger-Client für mobile Szenarien

Es handelt sich hierbei um eineneine TI-Messenger-Client, der Anwendung, die speziell für die Nutzung auf mobilen Geräten entwickelt wurde (z. Dabei handelt es sich um eineB. Android/IOS). Die Bereitstellung KANN als native mobile Anwendung erfolgen oder als eine Integration in einebereits bestehende native AnwendungAnwendungen. Die mobile Anwendung MUSS die betriebssystemseitigen Funktionen in Bezug auf Sicherheit nutzen. undDie Anwendung MUSS sicherstellen,  dass die Speicherung von Daten getrennt und verschlüsselt vom Dateisystem erfolgt. Ein unerlaubter Zugriff durch Dritte MUSS aktiv verhindert werden.  (z. B. durch PIN-Abfrage beim Öffnen der Anwendung).

Web

DerTI-Messenger-Client für stationäre Szenarien

Es handelt sich hierbei um eine TI-Messenger-Client KANN als Web-Frontend für denAnwendung, die speziell für die Nutzung auf 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.Endgeräten entwickelt wurde (z. B. Windows/MacOS). Die Bereitstellung KANN sowohl als eigenständige Lösung erfolgen oder als eine Integration in bereits bestehende Lösungen.

TI-Messenger-Client als Web-Anwendung

Die Ausführung des TI-Messenger-Client als lokale Web-Anwendung in einem Webbrowser ist ebenfalls möglich. Die Ver- und Entschlüsselung MUSS lokal im Browser auf dem Endgerät erfolgen. Ebenfalls MUSS sichergestellt werden, dass bei Nutzung einer lokalen Web-Anwendung ein unerlaubter Zugriff durch Dritte aktiv verhindert wird (z. B. durch Invalidieren der Session oder durch eine aktive Abmeldung).

3.2.3 Weitere Festlegungen

Jeder Anbieter eines TI-Messengers MUSS für Organisationen, die einen Messenger-Service vom Anbieter erhalten, sowohl den TI-Messenger-Client für Akteure als auch den TI-Messenger-Client mit Administrationsfunktionen (Org-Admin-Client) anbieten. 

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 dargestelltZur Sicherstellung des Datenschutzes und der Sicherheit im Rahmen des TI-Messenger-Dienstes werden im Folgenden zu beachtende Anforderungen an den TI-Messenger-Client beschrieben. Anforderungen, die durch andere Systemkomponenten sichergestellt werden, sind hier nicht dargestellt.

ML-124880 -weiter aufgeführt.

Hinweis: Für datenschutzrechtlichen Anforderungen aus der Konferenz der unabhängigen Datenschutzaufsichtsbehörden

•   Deran den TI-Messenger-Client MUSS für den Nutzer klar erkennbar Datenschutzinformationen bereitstellen. 

•    

•   Der mobile TI-Messenger-Client DARF KEINEN Zugriff (weder lesen noch schreibend) auf das Adressbuch des Endgerätes haben.

•   Der TI-Messenger-Client MUSS eine allgemeine und selektive Lösch-Funktion unterstützen.

•    

Der TI-Messenger-Client MUSS Inhalte verschlüsselt, separat vom allgemeinen Speicherbereich des Endgeräts speichern. Datenbanken MÜSSEN verschlüsselt sein und der jeweilige Schlüssel in den vom Betriebssystem bereitgestellten sicheren Speicherbereich abgespeichert werden. Medien und Dokumente MÜSSEN separat vom allgemeinen Speicherbereich gespeichert werden.Dienst wird auf die Stellungnahme der Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder gemäß [DSK2021] verwiesen. Die Inhalte der Stellungnahme werden in den Anforderungen [A_22715] und [A_22955] vereinfacht zusammengefasst.
 

A_22715 - Anforderungen-Herstellererklärung aus der Konferenz der unabhängigen Datenschutzaufsichtsbehörden

• Der TI-Messenger-Client KANN eine Funktion zur Unkenntlichmachung von Ausschnitten von Bildaufnahmen implementieren.MUSS für den Akteur klar erkennbar Datenschutzinformationen bereitstellen. 

•    

• Der TI-Messenger-Client MUSS bei der Nutzung von Fehleranalysetools datenschutzfreundliche Voreinstellungen (standardmäßig deaktiviert, bei opt-in klar erkennbar, etc.) treffeneine allgemeine und selektive Löschfunktion unterstützen.

• Der TI-Messenger-Client MUSS die Ende-zu-Ende-Verschlüsselung nach den Vorgaben unter 5.15. sowohl in Einzel- als auch Gruppenunterhaltungen fehlerfrei implementieren.KANN eine Funktion zur Unkenntlichmachung von Ausschnitten von Bildaufnahmen implementieren.

• Der TI-Messenger-Client MUSS beim Versand von Nachrichten oder Dokumenten in Teilen sicherstellen, dass alle Teile gesendet werden.  

• Der TI-Messenger-Client MUSS den Nutzer über Fehler beim Versand informieren.

1.                        Der TI-Messenger-Client DARF Metadaten zu KEINEM anderen Zweck nutzen als zur Übermittlung der Kommunikation und Sicherstellung des Betriebs.

1.                        Der TI-Messenger-Client MUSS sicherstellen, dass die Nutzersession bei Sperrung oder Abmeldung durch einen Nutzer in der Rolle Org-Admin beendet wird. 

• Der TI-Messenger-Client DARF Standortdaten NICHT dauerhaft erheben.

1.                        Der TI-Messenger-Client MUSS über (teil-)automatisierte Updateprozesse verfügen.

[<=] 

ML-123584 - Authentisierung des Nutzers gegenüber dem TI-Messenger-Client[<=]

A_22955 - Anforderungen-Gutachten aus der Konferenz der unabhängigen Datenschutzaufsichtsbehörden

• Der TI-Messenger-Client MUSS über ein 2-Faktor-Authentisierungsverfahren verfügen, um sich zu authentisieren gibt der Nutzer bei jedem Start der Applikation eine sechsstellige PIN ein, um die Applikation zu entsperren. Nach jeder Abmeldung, jedem Benutzerwechsel, jedem Schließen der Applikation, oder spätestens 12 Stunden nach letzter Entsperrung MUSS diese Authentisierung erneut vorgenommen werden. Alternativ zum Authentisierungsmittel PIN sind auch die Mittel Biometrie, starke Passphrase oder Fido-Token zulässig. Falls das Merkmal Biomentrie gewählt wird, MUSS es den Vorgaben von [BSI-TR-03166] Kap. 2.3.1.5 oder 2.3.1.6 genügen. Als zweiten Faktor MUSS der TI-Messenger-Client prüfen, ob er auf dem Gerät gestartet wurde, an welches er gebunden ist. Für Webclients entfällt diese Authentisierung. Diese Funktionen DÜRFEN NICHT abschaltbar sein und MÜSSEN unabhängig von den Entsperrfunktionen der Endgeräte sein.
  Der Hersteller SOLL eine Sperre implementieren, die nach längerer Inaktivität an Webclients die weitere Nutzung verhindert, bis sich erneut wie zuvor beschrieben authentisiert wird. Die nötige Dauer der Inaktivität MUSS durch den Nutzer konfigurierbar und auf eine Stunde voreingestellt sein.
  Der TI-Messenger-Client MUSS den Nutzer bei Erstverwendung des TI-Messenger-Clients, falls das Merkmal PIN oder Passphrase gewählt wurde, dazu zwingen eine solche festzulegen. Dabei ist technisch zu prüfen, dass ein PIN oder Passphrase entsprechend sicher ist. Dies kann beispielsweise durch das Anzeigen von Fortschrittbalken dem Nutzer dargestellt werden. Dieser wird erst grün, sobald eine entsprechende Güte erreicht wurde. Der Hersteller KANN eine Funktion implementieren, die zufallsgenerierte Vorschläge für PIN oder Passphrase erstellt. Diese Vorschläge MÜSSEN auf sichere Erzeugung von Zufallszahlen gemäß [gemSpec_Krypt] basieren.Inhalte verschlüsselt, separat vom allgemeinen Speicherbereich des Endgeräts speichern. Datenbanken MÜSSEN verschlüsselt sein und der jeweilige Schlüssel in den vom Betriebssystem bereitgestellten sicheren Speicherbereich abgespeichert werden. Medien und Dokumente MÜSSEN separat vom allgemeinen Speicherbereich gespeichert werden.
• Der TI-Messenger-Client MUSS sicherstellen, dass die Nutzersession bei Sperrung oder Abmeldung durch einen Akteur in der Rolle "Org-Admin" beendet wird.

[<=]

A_23114 - App-Sperre TI-Messenger-Client

TI-Messenger-Clients MÜSSEN bei der Entsperrung (der App oder des Geräts) mindestens eine 6-stellige PIN verwenden. Alternativ sind auch die Mittel Biometrie, starke Passphrase oder Fido-Token zulässig. Falls das Mittel Biometrie gewählt wird, MUSS es den Vorgaben aus [BSI-TR-03166] Kap. 2.3.1.5 oder 2.3.1.6 genügen. Nach jeder Abmeldung, jedem Benutzerwechsel, jedem Schließen der Anwendung oder spätestens 12 Stunden nach letzter Entsperrung MUSS die erneute Entsperrung durch den Akteur vorgenommen werden.
Der TI-Messenger-Client MUSS prüfen, ob eine Gerätesperre aktiv ist. Ist eine konforme Gerätesperre aktiviert, dann muss keine zusätzlich App-Sperre vorgesehen werden. Ist keine konforme Gerätesperre aktiviert, dann ist eine konforme App-Sperre vorzusehen.
Für ein in ein Drittsystem (KIS, PVS, AVS, etc.) integriertes TI-Messenger-Clientmodul KANN eine vorhandene Sperre des übergeordneten Systems nachgenutzt werden. 
App-Sperren für TI-Messenger-Clients und integrierte TI-Messenger-Clientmodule MÜSSEN vom Akteur deaktivierbar sein.
Für browserbasierte TI-Messenger-Clients ist keine App-Sperre erforderlich. Der browserbasierte Web-Client MUSS über eine Sperre verfügen, die nach längerer Inaktivität eine automatische Abmeldung durchführt. Die nötige Dauer der Inaktivität MUSS durch den Akteur konfigurierbar und per Default auf eine Stunde eingestellt sein. 
[<=]

ML-123585A_22717 - Verhinderung der Erstellung von Screenshots

Mobile TI-Messenger-Clients MÜSSEN für mobile Szenarien MÜSSEN Screenshots und Screencapturing verhindern, sofern das Betriebssystem dies zulässt, oder NutzerAkteure nach AufnahmeErstellen eines Screenshots klar darauf hinweisen, dass dieser nicht durch den TI-Messenger geschützt werden kann-Client geschützt werden kann. Diese Funktion MUSS durch Opt-Out der Akteure deaktivierbar sein. Wird die Funktion deaktiviert, MÜSSEN Akteure auf die Risiken von Screenshots sensibler Inhalte hingewiesen werden.
[<=]

ML-123589A_22718 - Mandantenfähigkeit von TI-Messenger-Clients

Hersteller des TI-Messenger-Clients MÜSSEN sicherstellen, dass TI-Messenger-Clients eine geeignete Mandantentrennung unterstützen, die verhindertverhindern, dass bei geteilten Endgeräten ein NutzerAkteur des TI-Messenger-Clients auf Daten oder Funktionen der TI-Messenger-Client-Devices eines anderen NutzersAkteurs auf diesem Gerät zugreifen kann.
[<=]

ML-123610A_22719 - Datenschutzfreundliche MXIDs

Der TI-Messenger-Client MUSS sicherstellen, dassSOLL MXIDs so generiert werdengenerieren, dass sie keine personenbezogenen Daten als Klarinformation beinhalten. NutzerAkteure des TI-Messenger haben keinen-Clients DÜRFEN NICHT Einfluss auf die Bildung der MXID haben.
[<=]

ML-123583A_22720 - Informationspflicht bzgl. Gefahren unsicherer Endgeräte

DerAkteure eines TI-Messenger-Client MUSS den NutzerClients als Web-Anwendung MÜSSEN in einem Hinweistext auf die Gefahren hinweisenhingewiesen werden, die bei einem Betrieb des Clients Nutzung auf Hardware, die nicht unter der Kontrolle des NutzernAkteurs steht, gegeben sind. Das betrifft neben geteilten Endgeräten ohne IT-Security-Überwachung insbesondere öffentlich zugängliche Endgeräte. Der NutzerAkteur MUSS die Empfehlung erhalten auf solchen Geräten den TI-Messenger-Client nicht zu nutzen.
Der TI-Messenger-Client MUSS den Akteur in einem Hinweistext auf die Gefahren hinweisen, die bei einem Betrieb des TI-Messenger-Clients auf Hardware, die nicht unter der Kontrolle des Akteurs steht, gegeben sind.
Es sind die Prüfvorschriften gemäß [BSI Frontend] zu berücksichtigen. 
[<=]

ML-123586A_22721 - Key-Sharing zwischen Geräten eines NutzersAkteurs

Um Synchronisation von Nachrichteninhalten zwischen mehreren Devices eines Nutzers zu ermöglichen, verfügt Matrix über vorgesehene Key-Sharing-Funktionalität. Der Hersteller MUSSTI-Messenger-Clients MÜSSEN die Matrix Vorgabe SHOULD "Key-Sharing nur für verifizierte Geräte" als MUST umsetzen.


Hinweis: Die Anforderung ist essentiell, um die Synchronisation von Nachrichteninhalten zwischen mehreren Geräten eines Akteurs über die von Matrix vorgesehene Key-Sharing-Funktionalität zu ermöglichen.
[<=]

ML-124004A_22722 - Key-Sharing zwischen Geräten innerhalb eines Chatraums

Hersteller des TI-Messenger-Clients MÜSSEN sicherstellen, dass TI-Messenger-Clients über eine Funktion verfügen, innerhalb eines Chatraums Key-Sharing Anfragen an andere Geräte zu stellen und Key-Sharing Anfragen von anderen Geräten anzunehmen oder abzulehnen.
[<=]

ML-123587A_22723 - Versand von Dateien mittels Matrix

Für den Versand von Dateien gemäß der Matrix-Spezifikation über den TI-Messenger-Client gilt:

1.                      Der Hersteller MUSS sicherstellen, dass dieTI-Messenger-Clients MÜSSEN Verschlüsselung für übertragene Inhalte aktiviert istverwenden.
2.                      Der Hersteller MUSS sicherstellen, dassTI-Messenger-Clients MÜSSEN in der Lage sein, mindestens Dateien mit einer Größe von 25MB versendet werden können100  MB zu versenden.
3.                      Der Hersteller SOLLTI-Messenger-Clients MÜSSEN über eine Größenbeschränkung für versendete Dateien implementierenzu versendender Inhalte verfügen.
4.                      Der Hersteller MUSS sicherstellen, dass die Möglichkeit besteht,TI-Messenger-Clients für stationäre Szenarien KÖNNEN über eine Schnittstelle und Funktionen verfügen, mit denen empfangene und entschlüsselte Dateien an eine StelleSchnittstelle bekannter Virenscanner zur Schadsoftwareprüfung zu übermitteln und prüfen zu lassenübermittelt und geprüft werden können, bevor diese verarbeitet werden. Dateien, die eine solche Prüfung nicht erfolgreich durchlaufen, SOLLEN verworfen werden. Falls eine Datei verworfen wird, MUSS der NutzerAkteur darüber undsowie über den Grund informiert werden.
5.                      NutzerTI-Messenger-Clients MÜSSEN Akteure bei der VerwendungFehlschlagen einer nicht erfolgreich geprüften Datei auf dessenDateiprüfung auf deren Prüfstatus - und mögliche Gefahren - hingewiesen werdenhinweisen.

Sofern der HerstellerTI-Messenger-Clients über eine Funktion implementiertverfügen, Dokumente direkt über den TI-Messenger-Client ohne Nutzung von Third-party softwareSoftware anzuzeigen, MUSSMÜSSEN diese die Ausführung von aktiven Inhalten verhindern. Ebenfalls MUSS diese Funktion es ermöglichen, zugehörige Metadaten auch ohne Öffnen oder Herunterladen der Datei selbst einzusehen. 

Der NutzerTI-Messenger-Client MUSS darüber informiert werdenden Akteur darüber informieren, dass Dokumente Schadsoftware enthalten können und welche Maßnahmen der NutzerAkteur zum Selbstschutz vornehmen kann. 

Der TI-Messenger-Client MUSS, wenn er Dokumenteninhalte direkt anzeigt, Maßnahmen zum Schutz vor Schadsoftware in den Dokumenten umsetzen. [<=]

Hinweis: Maßnahmenvorschläge zum Schutz vor Schadsoftware:

1.                      Prüfen, ob Dokumenten-Format unddas Dokumentenformat und dessen Inhalt mit dem angegebenen Dokumententyp in den Metadaten übereinstimmt .
2.                      Vor der Anzeige eines Dokumentes im TI-Messenger-Client sind Sonder- und Meta-Zeichen im Dokument für die jeweilige Anzeigesoftware mit der richtigen Escape-Syntax zu entschärfenersetzen.
    
3.                      Die Anzeigesoftware des TI-Messenger-Clients in einer Sandbox betreiben.

ML-123588 - Abschottung der TI-Messengerinhalte

Mobile A_23115 - Prüfung Device Integrität

TI-Messenger-Clients für mobile Szenarien MÜSSEN sicherstellen, dass Daten, die lokal gespeichert werden, nicht im allgemeinen Speicher des Geräts abgelegt werden, sondern in einem TI-Messenger-Client spezifischen Speicherbereich auf dem Endgerät.
Mobile TI-Messenger-Clients MÜSSEN sicherstellen, dass andere Applikationen auf den Endgeräten nicht auf Inhalte des TI-Messengers zugreifen können. Hierzu SOLL der Hersteller eine Abschottung des Speichers, den der TI-Messenger für Nutzerdaten belegt, implementieren prüfen, ob ein Rooting des Gerätes vorliegt. Ist dies der Fall, MUSS dem Nutzer eine Warnung angezeigt werden und der Versand von Anhängen verhindert werden. 
Bei der Verwendung von TI-Messenger-Clients, die auf dem Betriebssystem Android basieren, MUSS zur Integritätsprüfung Safetynet verwendet werden.
[<=]

A_22724 - Abschottung der Inhalte im TI-Messenger-Client

TI-Messenger-Clients für mobile Szenarien MÜSSEN sicherstellen, dass Daten, die lokal gespeichert werden, in einem geschützten Speicherbereich auf dem Endgerät abgelegt werden.
Hierzu SOLLEN Clients eine Abschottung des Speichers, den der TI-Messenger-Client für Nutzerdaten belegt, vornehmen. Hierzu genügen die vom Betriebssystem i.d.R. zur Verfügung gestellten Mittel.
Webclients MÜSSEN sicherstellen, dass sensible Daten im Browser (z. B. OLM-Keys, ACCESS_TOKEN) nicht durch andere ApplikationenAnwendungen ausgelesen werden können.
TI-Messenger-Clients MÜSSEN ein Öffnen von über den TI-Messenger empfangenen Dateien durch Drittprogramme ermöglich. Hierbei MUSS er sicherstellen, dass eine solche Ausleitung von Daten nur ausgelöst durch den TI-Messenger-Client erfolgt. Der TI-Messenger-Client KANN eine Funktion enthalten, mittels derer empfangene Dateien außerhalb des dedizierten Speichers im Gerätespeicher abgelegt werden. Der TI-Messenger-Client MUSS sicherstellen, dass Nutzer[<=]

A_23130 - Nutzung von Daten durch Drittsysteme

Um eine nahtlose Integration von TI-Messenger-Clients in z.B. Primär- (PVS, ZPVS, KIS, AVS etc.) oder Archivsysteme zu ermöglichen, KÖNNEN TI-Messenger-Clients eine Schnittstelle zum Zugriff auf ihre Daten durch Drittsysteme anbieten.
Der TI-Messenger-Client MUSS sicherstellen, dass Akteure bei Verwenden einer solchen Funktion geeignet darüber informiert werden, dass sie Daten aus dem geschützten Bereich des TI-Messengers hinausbewegen.
Messenger-Clients hinausbewegen. Geeignet bedeutet dabei, dass darüber informiert wird, welche Daten in welches Drittsystem weitergeleitet werden. 
[<=]

ML-123590A_22725 - Sicherheitskritische Updates

Anbieter des TI-Messenger-ClientsClient-Hersteller MÜSSEN sicherstellen, dass NutzerAkteure über die Veröffentlichung von Updates für ihre TI-Messenger-ClientsoftwareClients informiert werden. Bei sicherheitskritischen Updates MÜSSEN sie sicherstellen, dass nach einer geeigneten Frist eine weitere Nutzung des TI-Messenger-Clients ohne vorheriges Sicherheitsupdate nicht möglich ist. Hierzu genügt eine clientseitige Sperre im Gegensatz zu einem Nachweisanstatt eines Nachweises gegenüber dem Matrix-Homeserver. Die Möglichkeit weiter Updates einzuspielen MUSS in diesem Fall weiterhin gegeben sein. NutzerAkteure MÜSSEN geeignet darüber informiert werden, dass sie sicherheitskritische Updates installieren müssen um den TI-Messenger-Client weiterhin zu nutzen.
Der Hersteller des TI-Messenger-Clients MUSS die gematik bei Veröffentlichung einer neuen Produktversion informieren und eine Erklärung zur sicherheitstechnischen Eignung liefern.
[<=]

ML-124867 - Resilienz von Clients

Hersteller MÜSSEN sicherstellen, dass TI-Messenger-Clients resilient auf unerwartete Eingaben reagieren.
[<=]

ML-123591 - Zusatzfunktionen für TI-Messenger-Clients

Hersteller des TI-Messenger-Clients MÜSSEN sicherstellen, dass alle implementierten Funktionen, die über den gewöhnlichen Funktionsumfang eines TI-Messenger-Clients hinausgehen die Sicherheit des Produkts nicht gefährden und die Interoperabilität mit anderen TI-Messenger-Produkten erhalten.
Der Hersteller MUSS sicherstellen, dass alle Zusatzfunktionen des TI-Messenger-Clients von den Basisfunktionen unterscheidbar sind.
[<=]

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

ML-123629 - Device Verification, Cross-Signing und SSSS für TI-Messenger-Clients

Hersteller MÜSSEN sicherstellen, dass die Funktionen Cross-Signing und Secure Secret Storage and Sharing (SSSS)  zur Device Verification unterstützt werden. Es MUSS die Spezifikation 12.11.2 (https://spec.matrix.org/unstable/client-server-api/#device-verification) und 12.11.3 (https://spec.matrix.org/unstable/client-server-api/#sharing-keys-between-devices) vollständig befolgt werden.
[<=]

ML-123861 - Ende-zu-Ende-Verschlüsselung

Hersteller MÜSSEN sicherstellen, dass eine vollständige Ende-zu-Ende-Verschlüsselung auf Basis von OLM/MEGOLM unterstützt wird. Dazu MUSS der Spezifikation 12.11 (https://spec.matrix.org/unstable/client-server-api/#end-to-end-encryption ) und 12.12 (https://spec.matrix.org/unstable/client-server-api/#secrets ) gefolgt werden.
[<=]

ML-124006 - Explizites Verbot von Profiling für TI-Messenger-Clients

Hersteller und Anbieter von TI-Messenger-Komponenten DÜRFEN NICHT Daten zu Profiling-Zwecken sammeln. Dies betrifft insbesondere eine Überwachung welche Akteure mit welchen anderen Akteuren kommunizieren.

A_22792 - Device Verification, Cross-Signing und SSSS für TI-Messenger-Clients

TI-Messenger-Clients MÜSSEN die Funktionen Cross-Signing und Secure Secret Storage and Sharing (SSSS)  zur Device Verification unterstützen. Es MUSS der Spezifikation gemäß [Client-Server API#Sharing keys between devices] gefolgt werden.
[<=]

A_22793 - Ende-zu-Ende Verschlüsselung

TI-Messenger-Clients MÜSSEN eine Ende-zu-Ende-Verschlüsselung auf Basis von OLM/MEGOLM unterstützen. Dazu MUSS der Spezifikation gemäß [Client-Server API#End-to-End Encryption] gefolgt werden.
TI-Messenger-Clients MÜSSEN für das Versenden von Nachrichten diese Verschlüsselung nutzen.
[<=]

A_22794 - Explizites Verbot von Profiling für TI-Messenger-Clients

TI-Messenger-Client-Hersteller und -Anbieter DÜRFEN NICHT Daten zu Profiling-Zwecken sammeln. Dies betrifft insbesondere eine Überwachung welche Akteure mit welchen anderen Akteuren kommunizieren.

Hinweis:
Die gematik kann nach § 331 Abs. 2 SGB V Daten festlegen, die Anbieter von Komponenten und Dienste der gematik offenzulegen bzw. zu übermitteln haben, sofern diese erforderlich sind, um den gesetzlichen Auftrag der gematik zur Überwachung des Betriebs zur Gewährleistung der Sicherheit, Verfügbarkeit und Nutzbarkeit der Telematikinfrastruktur zu erfüllen. Nur die hierfür erforderlichen personenbezogenen Daten dürfen von den Anbietern und Herstellern als Ausnahme vom Profilingverbot erhoben und ausschließlich für den genannten Zweck verwendet werden.


[<=]

ML-123593A_22795 - Einbringung und Speicherung von Schlüsseln und Token

Hersteller von TI-Messenger-ClientsClient-Hersteller MÜSSEN sicherstellen, dass Schlüssel und Token sicher in den TI-Messenger-Client eingebracht werden. Hierzu genügt eine Prüfung des Prozesses.
Hersteller von  
TI-Messenger-ClientsClient-Hersteller MÜSSEN technisch sicherstellen, dass Schlüssel und Token nicht in andere Speicher ausgelagert werden können, als die dafür vorgesehenen Speicher der TI-Messenger-Clients oder dem SSSS [Matrix-SSSS] des beteiligten Homeservers.
[<=]

ML-123596A_22796 - Verwendung von TLS zur Kommunikation mit dem Fachdienst und VZD-FHIR-Directory

Der Hersteller MUSS sicherstellen, dass der TI-Messenger-ClientClients MÜSSEN in der Lage istsein, Verbindungen zu anderen BestandteilenKomponenten des TI-MessengersMessenger-Dienstes über TLS aufzubauen. Hierzu gelten die Festlegungen der [gemSpec_Krypt]. Entsprechende Anforderungen werden dem Produkttypsteckbrief zugeordnet.
 
[<=]

ML-123597 - Löschfunktionen für TI-Messenger-Inhalte

Der Hersteller von A_22797 - Automatische Löschfunktion

TI-Messenger-Clients MUSS eine automatisierteMÜSSEN über eine automatische Löschfunktion für vom Nutzer im TI-Messenger-Client-Nachrichten implementieren. Diese MUSS eine zumutbare voreingestellte Löschfrist enthalten, welche für Nutzer konfigurierbar ist erstellte Datenverfügen. Die Löschfrist MUSS hierbeikonfigurierbar und auf den minimal einstellbaren Wert initialisiert sein. Nach Verstreichen der eingestellten Löschfrist MÜSSEN Gesprächsinhalte aus dem TI-Messenger-Client sicher gelöscht werden. Der Hersteller MUSS zusätzlich eine nachrichtenbasierte Löschfunktion vorsehen, die es Nutzern6 Monate voreingestellt sein. 
[<=]

A_23112 - Funktion zum Nachhalten von Löschungen und Änderung von TI-Messenger Inhalten

TI-Messenger-Clients MÜSSEN über eine nachrichtenbasierte Lösch- und Änderungsfunktion verfügen, die es Akteuren erlaubt ihre eigenen Nachrichten händisch nicht nur vom eigenen TI-Messenger-Client, sondern auch aus demim Room State zu löschen.anzupassen. Wurde von einem anderen Client eine Löschung bzw. Änderung vorgenommen, so MUSS die Löschung/Änderung der Nachricht auch auf allen weiteren Clients, die an der Kommunikation beteiligt sind, durchgeführt und gekennzeichnet werden. Die Kennzeichnung MUSS den löschenden/ändernden Akteur, das Datum und die Uhrzeit der Löschung /Änderung enthalten.  
[<=]

ML-123607A_22798 - Privacy by Default

Der Hersteller eines TI-Messenger-Clients MUSS für die Standardeinstellungen des TI-Messenger-ClientsMÜSSEN stets die datenschutzfreundlichste Voreinstellung konfigurierenals Standardeinstellung verwenden.
[<=]

ML-123608A_22799 - Verwendung von OWASP Mobile

Der Hersteller eines mobilen TI-Messenger-ClientsClient für mobile Szenarien MUSS bei der Entwicklung von TI-Messenger-Clients die Maßnahmen und Vorgaben der aktuellen Version der OWASP-Top-10-Mobile-Risiken [OWASPMobileTop10OWASP MobileTop10] umsetzen. Hierbei SOLLEN die Vorgaben der Prüfvorschrift für den Produktgutachter des „ePA-Frontend des Versicherten“gemäß [BSI Frontend] analog für den TI-Messenger-Client umgesetzt werden, mit Ausnahme folgender Punkte:
 

Darüber hinaus sind folgende Punkte der OWASP-Top-10-Mobile-Risiken nur für eingeschränkte Clients relevant. Andere Client-Typen KÖNNEN auf die Umsetzung dieser Punkte verzichten: 

 

[<=]

ML-123630A_22800 - Sicherheitsrisiken von Software Bibliotheken minimieren

Der TI-Messenger-Client MUSS Maßnahmen umsetzen, um die Auswirkung von unentdeckten Schwachstellen in benutzten Software-Bibliotheken zu minimieren.


Hinweis:  Beispielmaßnahmen sind in [OWASP Proactive Control#C2] zu finden. Das gewählte Verfahren muss die gleiche Wirksamkeit aufweisen, wie die Kapselung gemäß [OWASP Proactive Control#C2 Punkt 4].
[<=]

ML-123606 - Ausführung nur von begutachtetem CodeA_22801 - Sicheres Beziehen von fremden Programmbestandteilen

Der Hersteller des TI-Messenger-Clients MUSS technisch sicherstellen, dass nur im Rahmen eines Produktgutachtens begutachteter Code ausgeführt wird oder Code-Änderungen nach Vorgaben der gematik durch den Hersteller als nicht zulassungsrelevant bewertet wurden.
Der Hersteller MUSS die Software-Komponenten des TI-Messenger-Clients, die nicht vom Hersteller selbst entwickelt oder zur Entwicklung beauftragt werden (z. B. TLS-Bibliotheken oder Matrix-Implementierungen), aus bekannten und vertrauenswürdigen Quellen beziehen.
[<=]

ML-123600A_22802 - Sichere Softwareverteilung

Der Hersteller eines TI-Messenger-Clients MUSS NutzerAkteure über die vertrauenswürdigen Quellen informieren, von denen NutzerAkteure den TI-Messenger-Client beziehen können und wie sie die Vertrauenswürdigkeit der Quelle erkennen können. Der Hersteller MUSS sicherstellen, dass der NutzerAkteur bei Erstbezug eines TI-Messenger-Clients die Authentizität der vertrauenswürdigen Bezugsquelle verifizieren kann. Der TI-Messenger-Client MUSS sicherstellen, dass Updates nur von bekannten und vertrauenswürdigen Quellen bezogen werden, nachdem die Authentizität der Quelle technisch erfolgreich verifiziert wurde.
[<=]

ML-123602 - Lokale Ausführung des TI-Messenger-Clients

Der TI-Messenger-Client MUSS sicherstellen, dass alle TI-Messenger-Clientspezifischen Anteile lokal auf dem Gerät des Nutzers ausgeführt werden, sofern die Betriebsumgebung des Clients dies zulässt.
[<=]

ML-123605 Der TI-Messenger-Client MUSS nach Installation und Update eine technische Prüfsumme generieren und anzeigen, anhand derer die Integrität der Installation überprüft werden kann.
[<=]

A_22804 - Datenschutzkonformes Tracking

Der TI-Messenger-Client DARF NICHT Werbe-Tracking verwenden.
Im Folgenden wird unter Tracking auch Usability-Tracking sowie Crash-Reporting verstanden.
Der TI-Messenger-Client MUSS sicherstellen, falls er Tracking-Funktionen implementiert, dass in den übermittelten Tracking-Informationen keine Sicherheitsmerkmale, wie Device-ID oder Daten mit Sicherheitsbezug, enthalten sind.
Der Datenschutzrechtlich-Verantwortliche für den TI-Messenger-Clients MUSS die Verarbeitung und Auswertung etwaiger gesammeltengesammelter Tracking-Daten des TI-Messenger-Clients selbst durchführen und nicht von einem Drittanbieter durchführen lassen.
Der TI-Messenger-Client MUSS sicherstellen, falls er Tracking-Funktionen nutzt, dass die Tracking-Daten keine Daten enthalten, die natürliche Personen direkt identifizieren.
Der TI-Messenger-Client MUSS, falls er Tracking-Funktionen ohne Einwilligung des NutzersAkteurs nutzt, sicherstellen, dass die Tracking-Daten

1.                      sich nur auf eine Clientnutzung (von der ersten Interaktion des Nutzers mit dem Client bis zum Schließen des Clients bzw. bis zum Inaktivitätstimeout) beziehen und nicht mit anderen Clientnutzungen des NutzersAkteurs verknüpft werden,
2.                      weder personenbezogene noch pseudonymisierte personenbezogene Daten enthalten,
3.                      keine nutzerbezogenen IDs oder gerätespezifischen IDs der Nutzergeräte enthalten,
4.                      keinen Rückschluss auf Versicherte, deren Vertreter, Leistungserbringer oder Kostenträger ermöglichen, insbesondere Rückschlüsse anhand des Nutzerverhaltens über die Zeit oder über Clientnutzungen hinweg,
5.                      nicht durch die Verknüpfung mit personenbezogenen Daten aus anderen Quellen de-anonymisiert werden können.

Der TI-Messenger-Client MUSS, falls er Tracking-Funktionen ohne Einwilligung des NutzersAkteurs nutzt, den NutzerAkteur über das Tracking im TI-Messenger-Client in verständlicher und leicht zugänglicher Form sowie in einer klaren und einfachen Sprache informieren, bevor die Trackingdaten erhoben werden. 

Der TI-Messenger-Client MUSS, falls er Tracking-Funktionen ohne Einwilligung des NutzersAkteurs nutzt, für jede Clientnutzung neue Nutzungsidentifier zufällig generieren. Der NutzerAkteur MUSS in der Lage sein jederzeit die Neugenerierung dieser Identifier zu erzwingen. 

Der TI-Messenger-Client MUSS, falls er Tracking-Funktionen mit Verknüpfung der Tracking-Daten mehrerer Clientnutzungen implementiert, technisch sicherstellen, dass diese Tracking-Funktionen bei der Installation des TI-Messenger-Clients standardmäßig deaktiviert sind und nur nach expliziter Einwilligung durch den NutzerAkteur aktiviert werden (Opt-in). Die Ablehnung der Nutzung solcher Funktionen darf die Standardfunktionen des TI-Messenger-Clients nicht einschränken. 

  

Falls solche Funktionen implementiert werden, MUSS den NutzernAkteuren vor der Einwilligung in die Aktivierung dieser Tracking-Funktionen in verständlicher und leicht zugänglicher Form sowie in einer klaren und einfachen Sprache folgende Einwilligungsinformationen angezeigt werden:

• welche Daten durch die Tracking-Funktionen erhoben werden,
• zu welchen Zwecken die Daten erhoben werden,
• welche Informationen durch die Auswertung der erhobenen Daten gewonnen werden und ob Rückschlüsse auf den Gesundheitszustand des NutzersAkteurs möglich wären,
• wer die Empfänger der Daten sind,
• wie lange die Daten gespeichert werden.

Diese Funktionen DÜRFEN NICHT aktiviert werden, bis eine explizite Einwilligung durch den Nutzerdie Akteure erfolgt ist und MUSS jederzeit durch diese deaktivierbar sein. 

Ein Verweis auf AGBs oder Nutzungsbedingungen des TI-MessengersMessenger-Clients ist hierzu NICHT ausreichend. Unter verständlicher und leicht zugänglicher Form wird explizit eine kurze Erklärung in einfacher und nicht juristischer Sprache verstanden, die direkt im TI-Messenger-Client angezeigt wird. 

Der HerstellerClient DARF NICHT wiederholt beim NutzerAkteur anfragen um eine Einwilligung durch Belästigung zu erzwingen. Nach einmaliger Ablehnung durch den NutzerAkteur MUSS jede Anzeige des Dialogs explizit durch den NutzerAkteur initiiert werden. 

[<=]

ML-123632A_22805 - CC-Evaluierung als Ersatz für das Gutachten

Falls der Hersteller entscheidet, eine CC-Zertifizierung statt eines Produktgutachtens durchzuführen, MUSS der Hersteller bei der Einreichung eines CC-Zertifizierungsantrags sein Security Target Dokument der gematik zur Verfügung stellen. In diesem müssen mindestens beschrieben sein:

• die zusätzlichen Funktionen des TI-Messenger-Client des Nutzers, Clients,
• die in den zusätzlichen Funktionen verarbeiteten Daten,
• die Schnittstellen zwischen dem TI-Messenger-Client des NutzersAkteurs und den ggf. genutzten Backend-Diensten der zusätzlichen Funktionen inklusive ihrer Sicherheitsmaßnahmen und 
• die Sicherheitsannahmen an dasden TI-Messenger-Client des NutzersAkteurs und die Ausführungsumgebung

[<=]

ML-123631 - Sichere Produktentwicklung und Nachweise

Der Hersteller MUSS innerhalb des Produktlebenszyklus (Entwicklung, Betrieb, Außerbetriebnahme) seines Produktes Sicherheitsaktivitäten integrieren und anwenden, d. h. in einschlägigen Fachkreisen anerkannte, erprobte und bewährte Regeln anwenden.
Der Hersteller MUSS die Sicherheits- und Datenschutzmaßnahmen für sein Produkt in einem Sicherheits- und Datenschutzkonzept dokumentieren und auf Verlangen der gematik zur Verfügung stellen.
Der Hersteller MUSS einen Testplan für Sicherheitstests erstellen und auf Verlangen der gematik zur Verfügung stellen. Dieser MUSS umgesetzt werden und der gematik bei jeder Veröffentlichung einer Produktversion als neuer Bericht vorgelegt werden.
Der Hersteller des TI-Messenger-Clients des Nutzers MUSS während der Entwicklung des Produktes implementierungsspezifische Sicherheitsanforderungen dokumentieren und umsetzen.
Der Hersteller MUSS ein sicherheitsrelevantes Softwarearchitektur-Review durchführen und identifizierte Architekturschwachstellen beheben. Dieses Review MUSS nach jeder Architekturänderung mit Sicherheitsrelevanz wiederholt werden.
Der Hersteller MUSS eine Bedrohungsanalyse durchführen und Maßnahmen gegen die identifizierten Bedrohungen implementieren.
Der Hersteller MUSS während der Entwicklung des Produktes sicherheitsrelevante Quellcode-Reviews oder automatisierte sicherheitsrelevante Quellcode-Scans durchführen.
Der Hersteller MUSS während der Entwicklung des Produktes automatisierte Sicherheitstests durchführen.
Der Hersteller MUSS einen Schulungsplan zur regelmäßigen Schulung von Entwicklern in sicherer Entwicklung und Secure-Coding-Techniken dokumentieren und umsetzen.
Der Hersteller MUSS alle Entwickler des Produktes in sicherer Entwicklung und Secure-Coding-Techniken schulen. Hierzu MUSS der Hersteller sicherstellen, dass alle Entwickler zu Beginn der Entwicklung geschult sind. Er SOLL für diese anschließend auch laufende Weiterbildung durchführen.
Der Hersteller MUSS den verwendeten sicheren Produktlebenszyklus und deren Teilprozesse dokumentieren und auf Nachfrage der gematik zur Verfügung stellen. Die Dokumentation soll mindestens die folgenden Sicherheitsaktivitäten beschreiben:

•   Erfassen und Umsetzen von implementierungsspezifischen Sicherheitsanforderungen für den Client und von Best-Practice- Sicherheitsanforderungen,

•   Durchführen von sicherheitsrelevanten Architektur- und Design-Reviews,

•   Durchführen von Bedrohungsanalyse,

•   Durchführen von sicherheitsrelevanten Quellcode-Reviews,

•   Durchführen von Sicherheitstests während der Qualitätssicherungsphase,

•   Etablieren von Quality Gates, die eine Veröffentlichung des Clients mit 'Mittel' oder 'Hoch' bewerteten Sicherheitsfehlern verhindert

•   Änderungs- und Konfigurationsmanagement,

•   Schwachstellen-Management

Der Hersteller MUSS während der Entwicklung des Produktes einen Änderungs- und Konfigurationsmanagementprozess verwenden. Das Änderungsmanagement umfasst mindestens den Entscheidungsprozess über vorgeschlagene Änderungen und die Autorisierung der Änderungen. Das Konfigurationsmanagement liefert mindestens zu jedem Zeitpunkt die eindeutige Zusammensetzung des Produktes bezüglich seiner eindeutigen Komponenten (Dritt-Software wie Bibliotheken und Frameworks) und den vorgenommenen Änderungen an eigenen Komponenten.
Der Hersteller MUSS bei Veröffentlichung einer neuen Produktversion des Produktes die Einhaltung der Herstellererklärung sicherheitstechnische Eignung durch seinen Datenschutzbeauftragten verifizieren.
[<=] 

ML-124881 - Kein Schreibzugriff für Clients auf Room-States

TI-Messenger-Clients MÜSSEN verhindern, dass Nutzer mittels Nutzereingaben Informationen in Room-States bringen. Sobald durch die geplante Matrix-Spec-Changes (MSCs) die Möglichkeit geschaffen wurde, vertrauliche Informationen sicher im Room-State zu speichern, wird dies direkt durch die Matrix-Spezifikation abgedeckt. [<=]A_22806 - Kein Schreibzugriff für TI-Messenger-Clients auf Room-States

TI-Messenger-Clients MÜSSEN verhindern, dass Akteure die Möglichkeit erhalten zusätzliche Informationen in Room-States einzutragen.
[<=]

A_22937 - Einsatz nur von auditierter Verschlüsselung

TI-Messenger-Clients MÜSSEN für die Verschlüsselung von Nachrichten eine auditierte und ausreichend sichere Implementierung von OLM/MEGOLM verwenden. Sollte eine andere Implementierung genutzt werden, als die von der gematik vorgesehene, MUSS der Hersteller einen Sicherheitsnachweis, z. B. in Form eines beauftragten Audits, erbringen. [<=]

Hinweis: Die gematik hat in Kooperation mit der Matrix-Foundation ein Audit für die OLM/MEGOLM Rust-Implementierung Vodozemac der in Auftrag gegeben. Auf Basis dieses Audits wird Vodozemac als die von der gematik vorgesehene Implementierung benannt.
 

A_22938 - Nur Verbindung zu validen Messenger-Services

TI-Messenger-Clients MÜSSEN bei der Konfiguration des zu nutzenden Messenger-Service dem Akteur nur valide Messenger-Services, die zum gewählten Anbieter gehören, zur Auswahl anbieten.
[<=]

A_22964 - Zugriffsschutz auf Administrationsfunktionen

TI-Messenger-Clients, die eine Doppelrolle als gewöhnlicher Client und als Org-Admin-Client wahrnehmen, MÜSSEN für beide Funktionalitäten separate User-Interfaces bereitstellen. Um den Akteur auf  Org-Admin-Client Funktionalitäten zugreifen zu lassen MUSS der TI-Messenger eine neue Authentisierung des Akteurs gegenüber dem TI-Messenger-Client erzwingen. [<=]

4.2 Authentifizierung am VZD-FHIR-Directory

Für den Zugriff auf den FHIR-Proxy des VZD-FHIR-Directory ist ein durch den Auth-Service ausgestelltes access-token notwendig. Hierfür MÜSSEN die am Auth-Service bereitgestellten REST-Schnittstellen vom TI-Messenger-Client aufgerufen werden.

Für den Schreibzugriff auf das FHIR-Directory MUSS der TI-Messenger-Client prüfen, ob ein gültiges owner-accesstoken lokal vorhanden ist. Wenn kein gültiges owner-accesstoken vorhanden ist MUSS der TI-Messenger-Client dies beim Auth-Service des VZD-FHIR-Directory mittels des Aufrufes GET /owner-authenticate unter Vorlage eines gültigen ID_TOKEN vom zuständigen IDP-Dienst anfragen. Für den Lesezugriff auf das VZD-FHIR-Directory MUSS der TI-Messenger-Client prüfen, ob ein gültiges search-accesstoken lokal vorliegt. Wenn kein gültiges search-accesstoken vorhanden ist MUSS der TI-Messenger-Client dies beim Auth-Service des VZD-FHIR-Directory mittels des Aufrufes GET /tim-authenticate unter Vorlage eines Matrix-OpenID-Token anfragen.

4.23 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 interoperableninteroperable Funktionen durch den Hersteller bereitgestellt werden, um ein Mindestmaß an NutzererfahrungAkzeptanz bei den Nutzern zu erreichen.  Diese werden im Folgenden beschrieben.

Präsenzanzeige für andere Nutzer

Für eine Echtzeitnutzererfahrung, MÜSSEN TI-Messenger-Clients gemäß [PräsenzanzeigeClient-Server API#Presence] 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-123607gemäß [A_22798]) standardmäßig deaktiviert sein.

Erwähnungen von Nutzern im Chatraum

TI-Messenger-Clients MÜSSEN es ermöglichen, dass über das Eingabefeld andere Nutzer gemäß [ErwähnungClient-Server API#User, room, and group mentions] 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,Szenarien MUSS der TI-Messenger-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ändigClient-Server API#Receipts] implementieren. TI-Messenger-Clients für Nutzer MÜSSEN diese Funktiondie Funktionen des Anzeigens und des 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-123607gemäß [A_22798]) standardmäßig deaktiviert sein.

Eingabebenachrichtigungen

Mobile TI-Messenger-Clients für mobile Szenarien MÜSSEN die Matrix-Spezifikation gemäß [Eingabebenachrichtigungen] vollständigClient-Server API#Typing Notifications] 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-123607gemäß [A_22798]) standardmäßig deaktiviert sein. 

Barrierefreiheit

ML-123582 - Standards zur Barrierefreiheit

Hersteller eines TI-Messenger-Clients SOLLEN die in [ISO 9241] aufgeführten Qualitätsrichtlinien zur Sicherstellung der Ergonomie interaktiver Systeme und Anforderungen aus der Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (Barrierefreie-Informationstechnik-Verordnung – [BITV 2.0]) beachten.
[<=]

4.34 Konfiguration des TI-Messenger-Clients

Im folgenden Kapitel werden alle zu konfigurierenden Funktionen beschrieben, die im TI-Messenger-Client durch den NutzerAkteur konfigurierbar sein müssenMÜSSEN.

Einstellung von Push-Benachrichtigungen

TI-Messenger-Clients MÜSSEN über eine Funktion verfügen, um Push-Benachrichtigungen auf einem GerätEndgerät konfigurieren zu können. Dazu MÜSSEN neben [Push-Rules gemäß [Client-Server API#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 ignorierenignorieren zu können. Daher MÜSSEN mobile TI-Messenger-Clients die Matrix-Spezifikation gemäß [Nutzer ignorieren] vollständigClient-Server API#Ignoring Users] 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 eine Liste aller ignorierten Nutzer anzeigen und die Möglichkeit bieten das Ignorieren von Nutzern rückgängig zu machen.

Raum-Historie

TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [Raum Historie] vollständigClient-Server API#Room History Visibility] 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 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 zu einem Chatraum sichtbar sein.

Sichtbarkeit

TI-Messenger-Clients MÜSSEN über eine Funktion verfügen die die Sichtbarkeit eines Akteurs in der Rolle "User-HBA" für den TI-Messenger-Dienst im Personenverzeichnis des VZD-FHIR-Directory ein bzw. ausschalten kann. Hierfür MUSS über die REST-Schnittstelle /owner am FHIR-Proxy des VZD-FHIR-Directory das Attribut status des Endpoints einer Practitioner-Ressource auf den Wert status == active für das einschalten oder status == off für das ausschalten gesetzt werden. Wenn der Akteur den status von active nach off ändert, MUSS der TI-Messenger-Client über die REST-Schnittstelle /search am FHIR-Proxy des VZD-FHIR-Directory prüfen, ob diese MXID auch im Organisationsverzeichnis eingetragen ist. Wird die MXID ebenfalls im Organisationsverzeichnis gefunden und ist der hinterlegte status in diesem Verzeichnis active, dann MUSS der TI-Messenger-Client dem Akteur einen Hinweis anzeigen, dass eine Inkonsistenz in der hinterlegten Sichtbarkeit vorliegt. Aus dem Hinweis MUSS hervorgehen, dass ein Kontaktieren des Administrators seiner Organisation notwendig ist, um die gewünschte Sichtbarkeit ebenfalls im Organisationsverzeichnis zu hinterlegen. 

4.5 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, der Testspezifikationen, der Testfälle sowieund 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üherzeitnaher IOP-Tests, die Synchronisierung von Meilensteinen und regelmäßige industriepartnerübergreifendenindustriepartnerübergreifende Test-Sessions. Die Test-Sessions umfassen gegenseitige IOP- und E2E -Tests.

Die gematik stellt eine TI-Messenger-FachdienstDienst 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.

ML-124204 - Test des TI-Messenger-Clients gegen die Referenzimplementierung

Der TI-Messenger-Client MUSS gegen die Referenzimplementierung erfolgreich getestet werden. Die Testergebnisse sind der gematik vorzulegen.
[<=]

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 FDFür die Anbieter-Zulassung MÜSSEN die TI-Messenger-Fachdienste und TI-Messenger-Clients vom TI-Messenger-Anbieter bereitgestellt werden. Um einen automatisierten Test für den TI-Messenger-Dienst zu ermöglichen, mussMUSS 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öglichtintern oder extern zur Verfügung stellen. In den folgenden Abbildungen wird das interne sowie das externe Testtreiber-Modul dargestellt.

Abbildung 3: Testtreiberschnittstelleinternes Testtreiber-Modul

Das externe Testtreiber-Modul erlaubt den Zugriff auf die Testumgebung des Herstellers und steuert so die Test-App.

Abbildung 4: externes Testtreiber-Modul

Das Testtreiber-Modul MUSS die Funktionalitäten der produktspezifischen Schnittstellen des TI-Messenger-Clients über eine standardisierte Schnittstelle von außen zugänglich machen und einen Fernzugriff ermöglichen. Dieses Testtreiber-Module MUSS Bestandteil der Test-APP sein (internes Testtreiber-Modul) oder ein Zugang zum Test-Environment des Herstellers gewährleisten (externes Testtreiber-Modul). Die Schnittstelle wird gemäß [Testtreiber API] durch die gematik spezifiziert und bereitgestellt. Das Testtreiber-Modul MUSS die durch den TI-Messenger-Client über eine produktspezifische Schnittstelle angebotene Funktionalität nutzen, um die Operationen des TI-Messenger-Clients umzusetzen. Bei einem internen Testtreiber-Modul wird die REST-Schnittstelle in die Test-App integriert (der Zugriff erfolgt hierbei direkt über das Endgerät). Der Test von Web-Clients (TI-Messenger-Client als Web-Anwendung) findet ausschließlich über externe Treiber-Module statt. Für die Ausführung der Tests werden Organisationen und Messenger-Services benötigt. Diese Organisationen und Messenger-Services MÜSSEN von den Herstellern vor Beginn der Testphase eingerichtet und die Daten (Organisationsnamen usw.) MÜSSEN an die gematik übermittelt werden.

 

ML-124877 - Test-App des TI-Messenger-Clients und Testtreiber-Modul

Die Test-App des TI-Messenger-Clients MUSS ein Testtreiber-Modul beinhalten, welches eine Schnittstelle für automatisierte Tests anbietet. Diese Schnittstelle wird durch die gematik spezifiziert und bereitgestellt oder einen Zugang zum Test-Environment des Herstellers gewährleisten. Das Testtreiber-Modul MUSS die durch den TI-Messenger-Client – (dem Zulassungsgegenstand) – über eine produktspezifische Schnittstelle angebotene Funktionalität nutzen, um die Operationen der Schnittstellen umzusetzen.
[<=]

Das Testtreiber-Modul darf Das Testtreiber-Modul DARF die Ausgaben des TI-Messenger-Clients gemäß der technischen Schnittstelle aufarbeiten, aber darfDARF NICHT die Inhalte nicht verfälschen.

Hinweis: Die konkrete Ausgestaltung der Schnittstellen wird im Fachportal der gematik und in GitHub zur Verfügung gestellt.Schnittstelle gemäß [Testtreiber API] wird durch die gematik spezifiziert und bereitgestellt.
[<=]

ML-124878 - Beschränkung Einsatzdes Einsatzes des Testtreiber-ModulModuls

Der produktive TI-Messenger-Client DARF NICHT ein Testtreiber-Modul NICHT enthalten.
[<=]

Der Einsatz des Testtreiber-Moduls ist auf das Zulassungsverfahren in Test-Apps beschränkt und darf nicht Der Einsatz des Testtreiber-Moduls ist auf das Zulassungsverfahren in Test-Apps beschränkt und DARF NICHT in Wirkbetriebs-Apps genutzt werden.
[<=]

ML-124879 - Keine Fachlogik in Testtreiber-Modul

Das Testtreiber-Modul DARF NICHT die fachliche LogikFachlogik des TI-Messenger-Clients umsetzen. 
[<=]

4.5
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] bezogen. Hierbei wird versucht, möglichst viele Funktionsbereiche der Komponenten des TI-Messenger-Dienstes einzubeziehen. Die Tests werden zunächst gegen die Referenzimplementierung der gematik durchgeführt. In diesem Schritt wird die Funktionalität des Zulassungsobjektes "TI-Messenger-Dienst" 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ßen gegeneinander getestet. Alle Anbieter MÜSSEN bereits im Vorfeld diesen IOP- und E2E-Tests selbständig und eigenverantwortlich durchführen. Bei Problemen im Rahmen der Zulassung MÜSSEN die Anbieter bei der Analyse unterstützen. In der folgenden Abbildung ist eine Systemumgebung für Herstellertests dargestellt.

Abbildung 5: Testumgebung für Herstellertests

Zusätzlich zu den bereits durchgeführten IOP- und E2E-Tests werden weitere Interoperabilitätstests von verschiedenen TI-Messenger-Lösungen vor und 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 6: Testumgebung gematik

4.6 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 Nutzernder Nutzer bzw. Akteure des TI-Messengers.

Der TI-Messenger-Anbieter MUSS seine Nutzer bzw. die Akteure 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-Anbieter MUSS seindas/die Produkt(e) TI-Messenger-Client mit einer vollumfänglich-funktionalen Verfügbarkeit von 98%98 % seinen Nutzern anbieten.

5 Funktionsmerkmale

Die Funktionen Der Funktionsumfang des TI-Messenger-Clients ergebenergibt sich aus den Funktionen der Matrix-Spezifikation. Die hier beschriebenen Funktionen MÜSSENund MUSS durch den jeweiligen TI-Messenger-Client unterstützt werden. FunktionenFunktionalitäten, welche durch die Matrix bereitgestelltFoundation beschrieben wurden, aber nicht Teil dieser Spezifikation sind und keine Fallbacks bieten, DÜRFEN NICHT implementiert werden, um die Interoperabilität zu gewährleistennicht zu gefährden.

5.1 AuthentisierungAuthentifizierungsverfahren

SSO Login

TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [SSO Login] vollständig implementieren.mindestens die folgenden Authentifizierungsverfahren unterstützen:

• SSO Login gemäß [Client-Server API#SSO client login/authentication] und
• OpenID-Connect gemäß [Client-Server API#OpenID]

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

Gäste Accounts

Der Hersteller eines TI-Messenger-Client MUSSWird ein in der Organisation bereits genutztes Authentifizierungsverfahren verwendet, so MUSS der TI-Messenger-Client die Eingabe der dafür benötigen Client Credentials unterstützen.

Zusätzlich MUSS der Hersteller eines TI-Messenger-Clients 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_Client-Server API] umsetzen.in der Version v1.3 umsetzen. Bei der Umsetzung der Matrix Client-Server API ist folgendes zu beachten:

Room Upgrades

TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [RoomClient-Server API#Room Upgrades] vollständig implementieren. TI-Messenger-Clients MÜSSEN mit RaumRoom 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äß [SendClient-Server API#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, unterstützen. TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [Client-Server API#Device Management] ausschließlich für die eigene Geräteverwaltung implementieren. Bei der Implementierung DARF NICHT die Geräteverwaltung 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 implementierenunterstützt werden.

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üsseltenClient-Server API#End-to-End Encryption] implementieren und unterstützen. Die TI-Messenger-Clients MÜSSEN verhindern, dass nicht Ende-zu-Ende verschlüsselte Nachrichten versendet werden.

Reporting von Inhalten

TI-Messenger-Clients MÜSSEN die Matrix-Spezifikation gemäß [Reporting-contentClient-Server API#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 Messaging2.1 Sofortnachrichten

Instant Messaging MUSS von einem TI-Messenger-Client vollständig nach der Matrix-Spezifikation gemäß [Instant Messaging] implementiert werdenClients MÜSSEN eine Funktion anbieten, um Sofortnachrichten gemäß [Client-Server API#Instant Messaging] in einem Chatraum austauschen zu können. 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 SOLLENMÜSSEN die MXID eines NutzersAkteurs verstecken und SOLLEN den Displaynamen anzeigen. TI-Messenger-Clients MÜSSEN Nutzer informieren, falls ein Event nicht oder fehlerhaft versendet wurde.

FolgendeDie folgenden Events und Msgtypes MÜSSEN vom TI-Messenger-Client unterstützt werden:

Tabelle 2: Events und Msgtypes

Events	Msgtypes
m.room.message	m.text
m.room.name	m.emote
m.room.topic	m.notice
m.room.avatar	m.image
	m.file
	m.audio
	m.location
	m.video

Nachrichten in Matrix können sowohl im Plaintext als auch in HTML-formatierter Form versendet werden. Für den Fall, dass ein TI-Messenger-Client keine formatierten Nachrichten unterstützt, ist MUSS ein Fallback im Plaintext für beispielsweise Replies spezifiziert:als Plaintext gemäß [Client-Server API#Fallbacks for rich replies] möglich sein.

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

TI-Messenger-Clients MÜSSEN Fallbacks für folgendeDabei MUSS der TI-Messenger-Client folgende Fallback Events unterstützen:

• Fallback für Antworten/Zitieren und
• 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 Messaging2.2 Direktnachrichten

TI-Messenger-Clients MÜSSEN eine Funktion anbieten, um Direktnachrichten gemäß [DirectClient-Server API#Direct Messaging] mit anderen Nutzern des TI-Messenger-Dienstes auszutauschen. Direktnachrichten bedeutet, dass ein Chatraum nur zwischen zwei PersonenAkteuren erstellt wird. Dieser Chatraum kann nicht um weitere TeilnehmerAkteure erweitert werden, es sei denn, es handelt sich um ein technisches System zum Zweck der Archivierung. Soll ein Chatraum für mehr als zwei TeilnehmerAkteure erstellt werden, istMUSS Group Messaging zu(Gruppenunterhaltungen) verwenden . Chaträume, die mit einer Organisation geführt werden sollen, unterliegen grundsätzlich dem Group Messaging. werden. 

Die folgenden Möglichkeiten MÜSSEN dabei vom TI-Messenger-Client angeboten werden:

Tabelle 3:Ablauf - Direktnachrichten

Direktnachrichten zwischen Akteuren innerhalb eines Messenger-Serviceseiner Organisation
Userstory: Suchen eines Akteurs über das Nutzerverzeichnis des Matrix-Homeservers	NutzerAkteur möchte eine neue Unterhaltung starten TI-Messenger-Client zeigt alle Akteure seiner Organisation im Nutzerverzeichnis des Matrix-Homeservers an NutzerAkteur wählt einen Gesprächspartner aus und startet Chatden Chat Der TI-Messenger-Client zeigt an, dass es sich um einen Direktchat handelt. Eine Umwandlung in einen Gruppenchat ist nicht möglich.
Direktnachrichten zwischen verschiedenen Messenger-ServicesAkteuren außerhalb einer Organisation
Userstory mittels : Suche eines Akteurs über das Personenverzeichnis des VZD-FHIR-Directory	Nutzer A (verifizierter HBA-Inhaber) Akteur A in der Rolle "User-HBA" möchte eine neue Unterhaltung mit Nutzer B (verifizierten HBA-Inhaber)Akteur B in der Rolle "User-HBA" starten NutzerAkteur A durchsucht das Personenverzeichnis des VZD-FHIR-Directory nach NutzerAkteur B TI-Messenger-Client zeigt Profil (z. B. Name, Organisationszugehörigkeit, Berufsgruppe etc.) von NutzerAkteur B an NutzerAkteur A startet den Chat mit NutzerAkteur B Der TI-Messenger-Client zeigt an, dass es sich um einen Direktchat handelt. Eine Umwandlung in Gruppeeinen Gruppenchat ist nicht möglich.
Userstory: Austausch der Kontaktdaten mittels QR-Scan	NutzerAkteur A und NutzerAkteur B treffen sich in Person NutzerAkteur A und NutzerAkteur B wählen jeweils im TI-Messenger-Client "neue Unterhaltung starten" aus NutzerAkteur A wählt "QR-Code teilen" aus NutzerAkteur B wählt "QR-Code scannen" aus und scannt "QR-Code" von NutzerAkteur A und erhält die MXID von Akteur A NutzerAkteur A und NutzerAkteur B klicken "weiter" NutzerAkteur B bekommt einen QR-Code angezeigt, NutzerAkteur A bekommt den QR-Code Scanner angezeigt NutzerAkteur A scannt Nutzerden QR-Code von Akteur B 8.   Nutzer A bekommt Dialog, dass Chatraum erstell wird, Nutzer B kann QR-Code schließen Die in diesem Ablauf ausgetauschten Token haben eine Gültigkeit von 10 MinutenAkteur B kann optional die Eintragung der MXID von Akteur A in seiner Freigabeliste durchführen Akteur A bekommt einen Dialog angezeigt, dass der Chatraum erstellt wird, Akteur B kann den QR-Code schließen Der TI-Messenger-Client zeigt an, dass es sich um einen Direktchat handelt. Eine Umwandlung in einen Gruppenchat ist nicht möglich.

5.5 Group Messaging2.3 Gruppenunterhaltungen

TI-Messenger-Clients MÜSSEN eine Funktion anbieten, um Gruppenunterhaltungen zu starten und Nachrichten innerhalb einer Chatgruppe mit unbegrenzt vielen NutzernmitNutzern des TI-Messenger-Dienstes auszutauschen. TI-Messenger-Clients MÜSSEN alle Teilnehmer einer Chatgruppe anzeigen. Darüberhinaus können. Darüber hinaus 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. Chaträume, die mit einer Organisation geführt werden sollen, MÜSSEN grundsätzlich Group Messaging verwenden.

Die folgenden Möglichkeiten MÜSSEN dabei vom TI-Messenger-Client angeboten werden:

Tabelle 4: Ablauf - Gruppenunterhaltungen

5.62.4 Push-Benachrichtigungen

Mobile TI-Messenger-Clients für mobile Szenarien MÜSSEN die Matrix-Spezifikation gemäß [Client-Server API#Push Notifications] implementieren. Die folgende Abbildung zeigt den Fluss von Push-Benachrichtigungen] vollständig implementieren, die an ein Mobiltelefon gesendet werden, bei dem die Push-Benachrichtigungen über den Anbieter des Mobiltelefons übermittelt werden.

5.6.1 Allgemein

Abbildung 47: Push-Benachrichtigung für MobilgeräteEndgerä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
Hinweis: In der Abbildung wurde der Messenger-Proxy aus Gründen der Übersichtlichkeit nicht dargestellt.

Fluss:

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ätEndgerä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 sich 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ätEndgerä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 für mobile Szenarien 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 und nicht missbräuchlich verwendet werden kann.

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 für mobile Szenarien 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.73 Administrationsfunktionen

Der TI-Messenger-Client mit Administrationsfunktionen ist ein Client für Akteure einer Organisation in der Rolle "Org-Admin". Dieser wird im Kontext des TI-Messenger-Dienstes auch als Org-Admin-Client bezeichnet. Der Org-Admin-Client dient der komfortablen Verwaltung der Messenger-Services bei einem TI-Messenger-Fachdienst. Die Bereitstellung des Org-Admin-Clients KANN als eigenständiger Client erfolgen oder als eine Integration in einen TI-Messenger-Client für Akteure. Sofern reguläre Nutzerfunktionen und Administrationsfunktionen in dem selben Client angeboten werden, MUSS auf eine klar erkennbare Unterscheidung zwischen Nutzer- und Administrationsfunktionen geachtet werden.  TI-Messenger-Clients mit Administrationsfunktionen MÜSSEN die Matrix-Spezifikation gemäß [Client-Server API#Server Administration] implementieren. Im Folgenden werden die durch den Org-Admin-Client bereitzustellenden Administrationsfunktionen genauer beschrieben.

Der Org-Admin-Client MUSS die Administration von Akteuren und Geräten auf den seiner Organisation zugeordneten Messenger-Services ermöglichen. Ebenfalls MUSS der Org-Admin-Client Sessions von angemeldeten Geräten auf dem Messenger-Service verifizieren und invalidieren können. Das bedeutet zum Beispiel, dass ein Akteur in der Rolle "Org-Admin" einen TI-Messenger-Client eines Akteurs abmelden kann. Darüber hinaus MUSS der Org-Admin-Client das Senden von Informationen/Systemmeldungen an die an einem Messenger-Service angemeldeten TI-Messenger-Clients ermöglichen.

Mit dem Org-Admin-Client besteht die Möglichkeit im Namen der Organisation FHIR-Ressourcen im VZD-FHIR-Directory zu verwalten. Hierfür MUSS der Org-Admin-Client die FHIR-Ressource HealthcareService über die Schnittstelle /owner im VZD-FHIR-Directory administrieren können. Ebenfalls MUSS der Org-Admin-Client über die Schnittstelle /search Einträge im VZD-FHIR-Directory lesen können. Für das Administrieren von Datensätze auf dem VZD-FHIR-Directory MUSS der Org-Admin-Client zunächst dem Akteur in der Rolle "Org-Admin" die betreffenden Einträge anzeigen bevor dieser die Daten durch Aufruf der /owner Schnittstelle im VZD-FHIR-Directory ändert.

Über den Org-Admin-Client MUSS es möglich sein Funktionsaccounts in das VZD-FHIR-Directory als Endpoint einer HealthcareService Ressource einer Organisation einzutragen. Bei der Konfiguration des Endpoints durch den Akteur in der Rolle "Org-Admin" MUSS der Displayname den Marker Chatbot enthalten, wenn der Funktionsaccount über einen Chatbot realisiert wird. Dabei ist folgende Bildungsregel für den Displaynamen zu verwenden: [Name des Funktionsaccounts] (Chatbot).

Zusammenfassung

• Benutzerverwaltung (Liste aller Akteure, Anlegen, Bearbeiten, Löschen)
• Geräteverwaltung (Anzeigen, Abmelden, Löschen aller Geräte eines Messenger-Service seiner Organisation)
• die Verwaltung von Einträgen im VZD-FHIR-Directory
• Systemmeldungen an Akteure eines Messenger-Services senden (z. B. Wartungsfenster bekannt machen)
• Einrichtung von Funktionsaccounts

5.4 Weitere Funktionen

Im folgenden Kapitel werden weitere Funktionalitäten beschrieben, die der TI-Messenger-Client implementieren MUSS.

Anmeldung an einem Messenger-Service

Der TI-Messenger-Client KANN beim Anmeldevorgang dem Akteur eine Liste aller vom TI-Messenger-Anbieter unterstützten Messenger-Services anzeigen. Wird dies vom Anbieter nicht unterstützt so MUSS dem Akteur eine Möglichkeit angeboten werden, den gewünschten Messenger-Service konfigurieren zu können.

Hinweis: Die Bereitstellung der vom Akteur zu verwendenden Parameter (z. B. Matrix-Domain des Messenger-Service) bleibt dem jeweiligen Anbieter überlassen.

Authentifizierungsmaske

Der TI-Messenger-Client MUSS dem Akteur beim Anmeldevorgang eine Authentifizierungsmaske mit den vom Messenger-Service unterstützten Authentifizierungsverfahren anzeigen.

Erstellung des Localparts

Der TI-Messenger-Client MUSSKANN bei der Erstellung des Localparts der MXID eines NutzersAkteurs sicherstellen, dass keine personenbezogenen Daten entstehenerkennbar sind. Dazu MUSSKANN der TI-Messenger-Client den local-PartLocalpart der verwendeten MXID des NutzersAkteurs als Base32 SHA256 Hash berechnen. Wird diese Variante zur Erstellung des Localparts der MXID nicht gewünscht, kann dies ein Akteur deaktivieren.

Beispiel einer MXID:

@74c1fecc710ce4c8a8bbe310fbc5954c2a5e1e9ef5f70d651da1bfc4c9abe43f:<domain>.de

ML-124045 - Base32 SHA256 Hash

Der TI-Messenger-Client MUSSSOLL für die MXID einen Hash-Wert mittels Base32 SHA256 zu berechnen.
[<=]

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. bei der initialen Vergabe des Displayname die folgende Bildungsregel anwenden: [Name], [Vorname]. Ebenfalls MUSS Der TI-Messenger-Client sicherstellen, dass ein Akteur seinen eigenen Displaynamen nachträglich nicht ändern kann.
 

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. ML-132303 - Editierbarkeit von Displaynamen

Das Editieren des Displayname eines Akteurs in der Rolle "User / User-HBA" ist durch den Akteur selbst nicht möglich. [<=]

Identifikationsmerkmale

Zur Sicherstellung, dass nur zugelassenen TI-Messenger-Clients verwendet werden, MUSS durch den TI-Messenger-Client-Hersteller eine User-Agent-Kennung in den TI-Messenger-Client implementiert werden. Die davon zulassungsrelevanten Anteile MUSS der TI-Messenger-Client-Hersteller dem TI-Messenger-Anbieter nach jeder Änderung zur Verfügung stellen, damit diese bei der Prüfung am Messenger-Proxy eines Messenger-Services verwendet werden können. Die User-Agent-Kennung MUSS bei jedem Aufruf im HTTP Header übertragen werden.
 

A_23104 - TI-M Client Useragent

Der TI-Messenger-Client für Akteure und der TI-Messenger-Client mit Administrationsfunktionen (Org-Admin-Client) MUSS folgende Useragent-Kennung bei jedem Verbindungsaufbau zum TI-Messenger-Fachdienst übermitteln:

"Useragent":
  {
    "Produkttypversion": $Produkttypversion,
    "Produktversion": $Produktversion,
    "Auspraegung": $Auspraegung,
    "Plattform": $Plattform,
    "OS": $OS,
    "OS-Version": $OS-Version,
    "client_id": $client_id,
  }

Zur Beschreibung der jeweiligen Datenfelder, siehe [gemSpec_TI-Messenger-FD#A_22940].
[<=]

Übersicht über verwendete Geräte/Devices

Der TI-Messenger-Client MUSS dem Akteur eine Übersicht der angemeldeten Geräte anzeigen können. Die Anzeige MUSS eine Unterteilung in verifizierte und nicht verifizierte Geräte vorsehen.  Für jedes angezeigte Gerät MUSS der letzte Aktivitätsstatus angezeigt werden und der Akteur MUSS einzelne Gerät abmelden und somit dessen Matrix-ACCESS_TOKEN invalidieren können. 

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 Akteur direkt abgemeldet werden.

Third Party Networks / Bridging

DasEin 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. anderen Messaging-Protokollen DARF NICHT stattfinden. Als Messaging-Protokoll MUSS ausschließlich die Matrix-Client-Server- und die Matrix-Server-Server-API verwendet werden. Ein clientseitiger bidirektionaler Austausch mit Drittsystemen KANN möglich sein, um zum Beispiel das Archivieren von Chatnachrichten oder Chatbots zu erlauben. Dazu KANN der TI-Messenger-Client als Modul in ein bestehendes System integriert werden.

Ende-zu-Ende Verschlüsselung

Der TI-Messenger-Client MUSS sicherstellen, dass sämtliche Nachrichteninhalte Ende-zu-Ende gemäß [Client-Server API#End-to-End Encryption] verschlüsselt werden. Das Senden von Nachrichten ohne Ende-zu-Ende Verschlüsselung MUSS technisch unterbunden werden.

Nutzerverzeichnis eines Messenger-Services

Der TI-Messenger-Client KANNMUSS eine Funktion bereitstellen, dass NutzerAkteure auf dem jeweiligen Matrix-Homeserver eines Messenger-ServiceServices ein Verzeichnis von Nutzernanderen Akteuren innerhalb ihrer Organisation aufrufen oderund durchsuchen können.

Suchabfragen VZD-FHIR-Directory

Der TI-Messenger-Client MUSS eine Funktion bereitstellen, dass NutzerAkteure 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, anzeigen zu können. Weitere Spezifikationen finden sich in [gemSpec_VZD_FHIR_Directory].

Verbindung nur mit in der Föderation vorhandenen Messenger-ServicesAdministration der Freigabeliste

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.eine Funktion bereitstellen, mit der ein Akteur eine Freigabe für Einladungen in einen Chatraum für andere Akteure ermöglicht. Hierfür MUSS der TI-Messenger-Client die Operationen des RESTful Webservice /tim-contact-mgmt/v1.0 gemäß [api-messenger#TiMessengerContactManagement.yaml] in der Version 1.0 am Messenger-Proxy seines Messenger-Service aufrufen. Der TI-Messenger-Client MUSS es ermöglichen, dem Akteur eine Liste anzuzeigen, in der alle Akteure die eine Freigabe erhalten haben gezeigt werden. Ebenfalls MUSS der TI-Messenger-Client es ermöglichen, Freigaben zu erstellen und diese zu bearbeiten.

Hinweis: Die Freigabeliste wird benötigt, wenn eine Kontaktaufnahme der Akteure in Person mittels eines QR-Scan erfolgte. Es ist empfehlenswert die Freigabe des Einladenden Akteurs in diesem Zusammenhang auf der Seite des Einzuladenden im TI-Messenger-Client zu ermöglichen.

Archivierung von Gesprächsinhalten

Um den Dokumentationspflichten von Ärzten nachzukommen, ist es notwendig, dass Chatverläufe mit Fallbezug auch über Löschung der Gesprächsdaten hinaus aufbewahrt werden können. Daher MUSS der TI-Messenger-Client sicherstellen, dass Chatverläufe aus dem TI-Messenger-Client extrahiert werden können, damit diese beispielweise in Archivsysteme überführt werden können. Die gematik macht keine Vorgaben wie die Archivierung zu gestalten ist, da sowohl die Art der Archivierung als auch die anzubindenden Systeme stark variieren.

Fallbezogene Kommunikation

Die fallbezogene Kommunikation ermöglicht es den Nutzern strukturierte Daten zu einem medizinischen Fall auszutauschen und in ihrem Primärsystem weiter zu verarbeiten. Hierfür MUSS der TI-Messenger-Client FHIR-Ressourcen in den Room-State eines existierenden Chatraumes hinzufügen.

Art des Events: state event
Event state_key: <vom Sender festgelegt>
Event type: "de.gematik.tim.casereference"
Die FHIR-Ressourcen werden im Element content als json-Daten eingetragen und als FHIR-Bundle (type message) zusammengefasst.

Die Profile der FHIR-Ressourcen befinden sich im Simplifier-Projekt [simplifier].

Die Canonical URLs der Ressourcen enthalten immer: http://gematik.de/fhir/TIM/CaseReference

Abbildung 8: CaseReference Ressourcen

Hinweis: Voraussetzung für die produktive Nutzung ist die Umsetzung des MSC3414 Encrypted state events (https://github.com/matrix-org/matrix-spec-proposals/pull/3414). 

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

Abbildung 1: Systemüberblick (Vereinfachte Darstellung)

Abbildung 2: Benachbarte Komponenten des TI-Messenger-Clients

Abbildung 3: Testtreiberschnittstelleinternes Testtreiber-Modul

Abbildung 4: Push-Benachrichtigung für MobilgeräteAbbildung 4: externes Testtreiber-Modul

Abbildung 5: Testumgebung für Herstellertests

Abbildung 6: Testumgebung gematik

Abbildung 7: Push-Benachrichtigung für Endgeräte

Abbildung 8: CaseReference Ressourcen

6.4 Tabellenverzeichnis

Tabelle 1: Übersicht der Komponenten und deren Funktionen

Tabelle 2: Events und Msgtypes

Tabelle 3:Ablauf - Direktnachrichten

Tabelle 4: Ablauf - Gruppenunterhaltungen

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