A_25528 - Kein Bridging

Ein serverseitiges Bridging zu anderen Messaging-Protokollen DARF NICHT vom TI-M FD unterstützt werden. [<=]

A_25641 - Matrix Spezifikationsversion

Als Basis MUSS die Matrix Spezifikation in der Version 1.3 verwendet werden. [<=]

A_25304 - Nachnutzung bestehender Authentifizierungsverfahren

Anbieter des TI-Messenger-Dienstes KÖNNEN für die Authentisierung von Akteuren in der Rolle "User" bestehende Authentifizierungsverfahren der Organisation nachnutzen. [<=]

A_25305 - Verantwortung der Organisation bei Nachnutzung bestehender Authentifizierungsverfahren

Werden bestehende Authentifizierungsverfahren der Organisation für die Authentisierung von Akteuren in der Rolle "User" nachgenutzt, MÜSSEN Anbieter die Organisation und die Administratoren explizit darauf hinweisen, dass die Sicherheit der Nutzerauthentisierung damit in die Verantwortung der Organisation gegeben wird.  [<=]

A_25306 - Kontrolle über genutzte Authentifizierungsverfahren

Der Anbieter MUSS sicherstellen, dass Authentifizierungsverfahren, die von einer Organisation für die Authentisierung von Akteuren in der Rolle "User" verwendet werden, unter Kontrolle der Organisation sind und entsprechende Authentisierungsmittel von dieser verwaltet und gesperrt werden können. Selbiges gilt, wenn der Anbieter die Nachnutzung bestehender Authentifizierungsverfahren der Organisation ermöglicht. [<=]

A_25307 - Verwendung von 2FA

Der Anbieter MUSS sicherstellen, dass zur Authentisierung mindestens zwei Faktoren verwendet werden und die Sicherheitsempfehlungen des BSI [BSI 2-Faktor] Berücksichtigung finden. [<=]

A_25308 - Resilienz der 2FA

Als 2. Faktor MUSS ein Verfahren gewählt werden, dass vom BSI hinsichtlich seiner Resilienz gegenüber Angriffen aus der Ferne mindestens mit "mittel" bewertet wurde [BSI 2-Faktor]. [<=]

A_25491 - Bereitstellung von Datenschutzinformationen

Der TI-M Client MUSS für den Akteur klar erkennbar Datenschutzinformationen bereitstellen. [<=]

A_25495 - Anzeige von Fehlern beim Versand

Der TI-M Client MUSS den Nutzer über Fehler beim Versand informieren. [<=]

A_25512 - Trennung von Mandanten

TI-M Clients MÜSSEN verhindern, dass bei geteilten Endgeräten ein Akteur des TI-M Clients auf Daten oder Funktionen eines anderen Akteurs des TI-M Clients auf diesem Gerät zugreifen kann. [<=]

A_25513 - Mandantentrennung nicht durch Betriebssystem

Für den Schutz der Daten verschiedener Mandanten, DARF sich der TI-Messenger Client NICHT darauf verlassen, dass seitens des Betriebssystems eine Trennung von Nutzern vorgenommen wird, welche den Zugriff auf Daten anderer Akteure verhindert, da derartige Funktionalität nicht notwendigerweise genutzt wird. [<=]

A_25519 - Schnittstelle für Virenscanner

TI-M Clients KÖNNEN über Schnittstellen und Funktionen verfügen, mit denen empfangene entschlüsselte Dateien zur Überprüfung auf Schadsoftware an Virenscanner übergeben werden, bevor diese verarbeitet werden. [<=]

A_25520 - Vorgehen bei Meldung von Schadsoftware

Nutzt ein TI-M Client die Möglichkeit zur Prüfung von Inhalten durch einen Virenscanner und meldet dieser Virenscanner das Vorhandensein von Schadsoftware im geprüften Inhalt, SOLL der TI-M Client diesen Inhalt verwerfen. [<=]

A_25521 - Information über Vorgehen bei Meldung von Schadsoftware

Verwirft der TI-M Client Inhalte, MUSS der Akteur darüber sowie über den Grund informiert werden. [<=]

A_25522 - Fehlschlag der Prüfung auf Schadsoftware

Nutzt ein TI-M Client die Möglichkeit zur Prüfung von Inhalten durch einen Virenscanner und meldet dieser Virenscanner ein Fehlschlagen der Prüfung, MUSS der TI-M Client den Akteur über den Prüfstatus und die mögliche Gefahr informieren. [<=]

A_25523 - Keine Ausführung aktiver Inhalte

Verfügt der TI-M Client über eine Funktion, Dokumente direkt über den TI-M Client ohne Nutzung von Third-Party Software anzuzeigen, MUSS er die Ausführung von aktiven Inhalten verhindern. [<=]

A_25524 - Anzeige von Metadaten

Verfügt der TI-M Client über eine Funktion, Dokumente direkt über den TI-M Client ohne Nutzung von Third-Party Software anzuzeigen, MUSS er es ebenfalls ermöglichen, zugehörige Metadaten auch ohne Öffnen oder Herunterladen der Datei selbst einzusehen. [<=]

A_25525 - Information über Gefahren von Schadsoftware

Der TI-M Client MUSS den Akteur darüber informieren, dass Dokumente Schadsoftware enthalten können und welche Maßnahmen der Akteur zum Selbstschutz vornehmen kann. [<=]

A_25569 - Einbringung von Schlüsseln und Token

TI-M Client-Hersteller MÜSSEN sicherstellen, dass Schlüssel und Token sicher in den TI-M Client eingebracht werden, das heißt unter Nutzung der von der Spezifikation und dem Matrix-Protokoll vorgesehenen Abläufe und Verfahren.
In diesem Sinne werden die verschiedenen Token (siehe Tabelle 2) mittels TLS-gesicherter Verbindung zum jeweiligen Fachdienst eingebracht, der diese nach erfolgreichem Handshake ausstellt. Die Einbringung von Schlüsseln folgt den Vorgaben und Funktionen des Matrix-Protokolls (SSSS, Key Sharing, Wiederherstellung aus verschlüsseltem Offline-Backup, Key Agreement, Schlüsselfortschreibung). [<=]

A_25570 - Speicherung von Schlüsseln und Token

TI-M Client-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-M Clients oder dem [SSSS] des beteiligten Matrix-Homeservers. [<=]

A_25573 - Verwendung von TLS zur Kommunikation mit dem Fachdienst und VZD-FHIR-Directory

TI-M Clients MÜSSEN mit anderen Komponenten des TI-M Dienstes sowie dem VZD-FHIR-Directory über TLS kommunizieren und die dafür erforderlichen Verfahren unterstützen. Hierzu gelten die Festlegungen der [gemSpec_Krypt]. [<=]

A_25574 - Automatische Löschfunktion

TI-M Clients MÜSSEN über eine automatische Löschfunktion verfügen. Von dieser automatischen Löschfunktion sind alle lokal vorgehaltenen Räume und Rauminhalte betroffen, wenn (1) der Nutzer nicht mehr Mitglied des Raumes ist, oder (2) der Raum server-seitig gelöscht wurde. [<=]

A_25575 - Löschung von Nachrichten

TI-M Clients MÜSSEN über eine nachrichtenbasierte Löschfunktion verfügen, die es Akteuren erlaubt, ihre eigenen Nachrichten gemäß [Client-Server API/#redactions] zu löschen. [<=]

A_25576 - Lokales Löschen bei Entfernung von Nachrichten aus dem Room State

Wurde eine Nachricht durch einen anderen Akteur gemäß [Client-Server API/#redactions] gelöscht, so MÜSSEN TI-M Clients, die sich im selben Raum befinden, die entsprechende Nachricht auch lokal löschen und kennzeichnen. [<=]

A_25577 - Kennzeichnung gelöschter Nachrichten

TI-M Clients MÜSSEN im Rahmen der Kennzeichnung gelöschter Nachrichten den löschenden Akteur, das Datum und die Uhrzeit der Löschung enthalten. [<=]

A_25578 - Privacy by Default

TI-M Clients MÜSSEN stets die datenschutzfreundlichste Voreinstellung als Standardeinstellung verwenden. [<=]

A_25580 - Sicherheitsrisiken von Software Bibliotheken minimieren

Der TI-M Client MUSS Maßnahmen umsetzen, um die Auswirkung von unentdeckten Schwachstellen in benutzten Software-Bibliotheken zu minimieren. [<=]

A_25584 - Selbst-Update des TI-M Clients aus vertrauenswürdigen Quellen

Lädt und appliziert ein TI-M Client Selbstaktualisierungen, so MUSS er sicherstellen, dass Updates nur von bekannten und vertrauenswürdigen Quellen bezogen werden, nachdem die Authentizität der Quelle technisch erfolgreich verifiziert wurde. [<=]

A_25598 - Einsatz auditierter Verschlüsselung

TI-M Clients MÜSSEN für die Verschlüsselung von Nachrichten eine auditierte und für ausreichend sicher befundene Implementierung von Olm/Megolm verwenden.  [<=]

A_25599 - Verwendung anderer Implementierungen von Olm/Megolm

Sollte für die Umsetzung von Olm/Megolm eine andere Implementierung als eine der von der gematik vorgesehenen genutzt werden, MUSS der Hersteller einen Sicherheitsnachweis erbringen, welcher nach Art, Umfang und Ergebnis den Audits von Vodozemac und libolm entspricht und von nachweislich geeigneten und vom Hersteller unabhängigen Personen erbracht wurde. [<=]

A_25609 - Konfigurierbare Frist zur Erinnerung an Löschung

TI-M Clients MÜSSEN über eine konfigurierbare Frist zur Erinnerung an die Löschung von Räumen und Rauminhalten verfügen, welche die Löschung aller Daten, die älter als die konfigurierte Frist sind, anbietet. [<=]

A_25610 - Voreinstellung zur Erinnerung an Löschung

Die konfigurierbare Frist in TI-M Clients zur Erinnerung an die Löschung von Räumen und Rauminhalten MUSS auf sechs Monate voreingestellt sein und bezieht sich auf den Zeitstempel der Erstellung der letzten Nachricht in einem Raum. [<=]

A_25611 - Durchführung der Löschung

Ist die im TI-M Client konfigurierte Frist zur Erinnerung an die Löschung von Räumen und Rauminhalten verstrichen, so MUSS der Client den Nutzer darauf hinweisen und die Löschung des Raumes und dessen Inhalten empfehlen. Stimmt der Nutzer zu, so wird er aus dem Raum entfernt, was auch zu einer Benachrichtigung des Servers führt. [<=]

A_25501 - Sperre des TI-Messenger Clients

Es MUSS sichergestellt sein, dass der Zugriff auf den TI-M Client erst nach Überwindung einer App-Sperre möglich ist. Geeignete Faktoren für eine App-Sperre sind:

• 6-stelliger PIN
• starke Passphrase
• Fido-Token
• Biometrie

A_26023 - Mehr-Faktor-Authentisierung für den TI-M Client zzgl. Ersatzverfahren

Der TI-M Client MUSS, da er medizinische Daten lokal zwischenspeichern kann, dem Akteur mindestens eine Authentisierungsart mit mehreren Faktoren für dessen Authentisierung am TI-M Client anbieten. [<=]

A_25502 - Entsperrung per Biometrie

Wird für die Überwindung der Sperre zum Zugriff auf den TI-M Client das Mittel Biometrie gewählt, MUSS es den Vorgaben aus [BSI-TR-03166] Kap. 2.3.1.5 oder 2.3.1.6 genügen. [<=]

A_26024 - Hinweise zu Authentisierungsarten

Der TI-M Client SOLL dem Nutzer die verfügbaren Authentisierungsarten in verständlicher Form darstellen und erklärende Hinweise zur Verfügung stellen. [<=]

A_25503 - Notwendigkeit der Entsperrung

Die Überwindung der Sperre zum Zugriff auf den TI-M Client MUSS nach jeder Abmeldung, jedem Benutzerwechsel, jedem Schließen der Anwendung oder spätestens zwölf Stunden nach letzter Entsperrung erneut durch den Akteur vorgenommen werden. [<=]

A_25472 - User Sessions Anzeige

Der Org-Admin-Client MUSS aktive und inaktive Sessions der Devices anzeigen, von denen sich ein User angemeldet hat. [<=]

A_25473 - User abmelden

Der Org-Admin-Client MUSS dem Org-Admin die Möglichkeit bieten die Access-Token & Refresh-Token der einzelnen Devices oder aller Devices zu invalidieren, um den User abzumelden. [<=]

A_25474 - Infomeldungen

Der Org-Admin-Client MUSS das Senden von Informationen/Systemmeldungen an die an einem Messenger-Service angemeldeten TI-M Clients ermöglichen. [<=]

A_25601 - Separate Benutzeroberflächen für Administration und Kommunikation

TI-M Clients, die sowohl als Client für die Kommunikation, als auch als Org-Admin-Client genutzt werden, MÜSSEN zur Bereitstellung der Funktionalitäten für die jeweilige Rolle separate User-Interfaces verwenden, welche die für den jeweiligen Zweck relevanten Informationen anzeigen und Funktionen bereitstellen.  [<=]

A_25492 - Löschfunktion des Clients

Der TI-M Client MUSS Löschfunktionen implementieren, die es dem Akteur ermöglichen, Daten sowohl lokal auf dem Client zu löschen, bspw. durch Verlassen eines Raumes, bei dem der gesamte Raum samt Inhalt vom Client entfernt wird, als auch server-seitig, wenn es sich dabei um Daten handelt, die der Nutzer selbst eingebracht hat, bspw. indem er eine von ihm verfasste Nachricht in einem Chat-Raum löscht ("redact"). [<=]

A_25398 - QR-Code erstellen

Der TI-M Client für mobile Szenarien MUSS eine Funktion bereitstellen, 2D-Barcodes zu erstellen und diese auf dem Display des Endgerätes anzuzeigen. Hierbei MUSS der 2D-Code in eine QR-Code-Darstellung gemäß ISO/IEC 18004:2006 kodiert werden. Als Inhalt für die Generierung des 2D-Codes MÜSSEN mindestens die Felder des folgenden vCard-Objektes verwendet werden:

A_25422 - QR-Code verarbeiten

Der TI-M Client für mobile Szenarien MUSS eine Funktion bereitstellen, die es dem Akteur erlaubt, über die Kamera des Endgerätes einen 2D-Barcode (in einer QR-Code-Darstellung) einzuscannen. Der TI-Messenger MUSS den eingescannten 2D-Code gemäß ISO/IEC 18004:2006 decodieren und mindestens den vollständigen Namen sowie die Matrix-User-ID aus den Parameter N und IMPP dem Akteur anzeigen, damit dieser die Daten in seine Kontaktliste übernehmen kann. [<=]

A_25496 - Keine dauerhafte Standortdatenerhebung

Der TI-M Client DARF Standortdaten NICHT dauerhaft erheben. [<=]

A_25500 - Auslösung der Standorterhebung

Bei der Erhebung von Standortdaten MUSS sichergestellt sein, dass diese Erhebung ausschließlich durch einen menschlichen Benutzer ausgelöst wird und nach Beendigung des Anwendungsfalls, der die Standortdaten erhebt, diese wieder aus dem TI-M Client-Kontext gelöscht werden. [<=]

A_25527 - Prüfung der Geräteintegrität

TI-M Clients für mobile Plattformen MÜSSEN 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. [<=]

A_25535 - Abschottung von Inhalten auf mobilen Plattformen

TI-M Clients für mobile Plattformen MÜSSEN sicherstellen, dass Daten, die lokal durch den TI-M Client selbst gespeichert und nicht explizit durch den Nutzer für die Verwendung in anderen Kontexten exportiert wurden, in einem geschützten Speicherbereich auf dem Endgerät abgelegt werden. Hierzu genügen die von mobilen Betriebssystemen üblicherweise zur Verfügung gestellten Mechanismen wie die Verschlüsselung des Dateisystems und die Kapselung von Anwendungen untereinander. [<=]

A_25579 - Schutz gegen OWASP Mobile Top 10 Risiken

Hersteller von TI-M Clients für mobile Szenarien MÜSSEN für die von ihnen angebotenen mobilen TI-M Clients gewährleisten, dass der Client resistent bezüglich der im aktuellen und den beiden vorherigen OWASP Mobile Top 10 Report(s) ausgewiesenen Risiken ist. [<=]

A_25505 - Prüfung auf konforme Gerätesperre

Wird der TI-M Client ohne aktive App-Sperre auf einem Mobilgerät verwendet, MUSS er regelmäßig und wenigstens beim Öffnen prüfen, ob eine konforme Gerätesperre aktiviert ist und bei negativem Prüfergebnis eine dedizierte App-Sperre aktivieren. [<=]

A_25497 - Schutz gespeicherter Daten in Desktop-Clients

Handelt es sich bei dem TI-M Client um eine Desktop-Applikation, MUSS dieser für empfangene und gesendete Daten, die nicht explizit durch den Nutzer für die Verwendung in anderen Kontexten exportiert wurden, gewährleisten, dass diese im Falle der Speicherung auch nur durch den TI-M Client und nach Authentifizierung des jeweiligen Nutzers gelesen werden können. [<=]

A_25396 - Client-Server API

TI-M Clients MÜSSEN die clientspezifischen Anteile der Matrix Client-Server API gemäß [Client-Server API] umsetzen. [<=]

A_25345 - Appendices TI-M Clients

TI-M Clients MÜSSEN die [Matrix Appendices] gemäß der Matrix-Spezifikationen umsetzen. [<=]

A_25395 - Matrix Module

Die folgende Tabelle listet die Module aus der Matrix Spezifikation und die Neudefinition der Vorgaben.

Tabelle 3: Matrix Module

A_25397 - create Room

Der TI-M Client MUSS sicherstellen, dass im createRoom-Event maximal die Einladung einer MXID enthalten ist.  [<=]

A_25323 - Anlegen von Räumen

Der TI-M Client MUSS beim Anlegen eines Raumes als Default einen nicht öffentlichen und verschlüsselten Raum anbieten. [<=]

A_25324 - Verschlüsselung von Räumen

Der TI-M Client DARF dem Akteur beim Anlegen privater Räume NICHT erlauben, die Verschlüsselung zu deaktivieren. [<=]

A_25559 - Unterstützung von Olm und Megolm

TI-M Clients MÜSSEN eine Ende-zu-Ende-Verschlüsselung auf Basis von Olm und Megolm unterstützen und dafür der Matrix-Spezifikation gemäß [Client-Server API/#end-to-end-encryption] folgen. [<=]

A_25561 - Hinweis auf unverschlüsselte Kommunikation

Der TI-M Client MUSS Räume, in denen unverschlüsselt kommuniziert wird, durch geeignete UI-Elemente als solche kennzeichnen, sodass der Akteur sich dessen gewahr ist. [<=]

A_25562 - Hinweis auf Öffentlichkeit eines Raums

Der TI-M Client MUSS öffentliche Räume durch geeignete UI-Elemente als solche kennzeichnen, sodass der Nutzer sich der Öffentlichkeit des Raums gewahr ist. [<=]

A_25517 - Größe versendeter Inhalte

TI-M Clients MÜSSEN in der Lage sein, Dateien mit einer Größe von mindestens 100 MB zu versenden. [<=]

A_25518 - Beschränkung der Größe versendeter Inhalte

TI-M Clients MÜSSEN die in m.upload.size definierte Größenbeschränkung zu versendender Inhalte berücksichtigen. [<=]

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

TI-M Clients MÜSSEN die Funktionen Cross-Signing und Secure Secret Storage and Sharing ([SSSS]) zur Device Verification unterstützen und dafür der Matrix-Spezifikation gemäß [Client-Server API/#sharing-keys-between-devices] folgen. [<=]

A_25394 - Anforderung von refresh token durch den TI-M Client

Der TI-M Client MUSS bei Aufruf der [Client-Server API] Endpoints /register und /login den Parameter refresh_token mit dem Wert true benutzen. [<=]

A_25458 - Verwendung von refresh token

Der TI-M Client MUSS einen nicht mehr gültigen access_token durch Verwendung des refresh_token erneuern. [<=]

A_25399 - Displaynamen anpassen

Das Editieren des Displayname eines Akteurs in der Rolle "User" DARF NICHT durch den Akteur selbst möglich sein. [<=]

A_25431 - Eingabebenachrichtigungen

Eingabebenachrichtigungen MÜSSEN an- und abschaltbar sein und MÜSSEN gemäß Privacy-by-default (Art. 25 Abs. 2 DSGVO) standardmäßig deaktiviert sein. [<=]

A_25436 - Präsenzanzeige

Die Präsenzanzeige MUSS an- und abschaltbar sein und MUSS gemäß Privacy-by-default (Art. 25 Abs. 2 DSGVO) standardmäßig deaktiviert sein. [<=]

A_25437 - Erwähnungen

TI-M Clients MÜSSEN es ermöglichen, dass über das Eingabefeld andere Nutzer gemäß [Client-Server API/#user-and-room-mentions] im jeweiligen Chatraum erwähnt werden können. Dazu MUSS der TI-M Client eine entsprechende Nutzerliste anzeigen, sobald der Nutzer ein neues Wort mit "@" startet. [<=]

A_25481 - Raum Historie

Als Default-Einstellung MUSS beim Anlegen eines Raumes die Sichtbarkeit für die Raum-Historie ab dem Zeitpunkt der Einladung ("invited") zu einem Chatraum definiert sein. [<=]

A_25423 - Retry and Order

Das unter [Client-Server API/#recommendations-when-sending-messages] beschriebene Verhalten für das Retry und die Order auf Clientseite ist mit MUSS und nicht mit SHOULD zu implementieren. [<=]

A_25514 - Key-Sharing zwischen Geräten eines Akteurs

TI-M Clients MÜSSEN sicherstellen, dass das Key-Sharing zwischen Geräten desselben Akteurs nur verifizierte Geräte umfasst. Geräte, die im Namen eines bestimmten Akteurs angemeldet, aber nicht verifiziert sind, sind vom Key-Sharing ausgeschlossen. [<=]

A_25430 - Barrierefreiheit

Hersteller eines TI-M 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. [<=]

A_25483 - TI-M Client User-Agent

Der TI-M Client für Akteure und der Org-Admin-Client MÜSSEN folgende User-Agent-Kennung bei jedem Verbindungsaufbau zum TI-M FD übermitteln:

X-TIM-User-Agent: $ua-client_id, $ua-OSv

Hinweise:
1) Zur Beschreibung der Datenfelder, siehe [A_25823].
2) Im  muss der Header nicht explizit gesetzt werden, solange die geforderten Informationen auch anderweitig am TI-M FD korrekt erfasst werden können. [<=]

A_25424 - Archivierung in Archivsysteme

Der TI-M Client MUSS sicherstellen, dass Chatverläufe aus dem TI-M 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. [<=]

A_25585 - Verbot von Werbe-Tracking

Der TI-M Client DARF NICHT Werbe-Tracking verwenden. [<=]

A_25587 - Keine Auswertung durch Dritte

Der datenschutzrechtlich Verantwortliche für die TI-M Clients MUSS die Verarbeitung und Auswertung etwaiger gesammelter Tracking- und/oder Reporting-Daten der TI-M Clients selbst durchführen und DARF die Verarbeitung und Auswertung NICHT von einem Drittanbieter durchführen lassen. [<=]

A_25589 - Einschränkung der Art übermittelter Informationen

Der TI-M Client MUSS, falls er Tracking- und/oder Reporting-Funktionen ohne Einwilligung des Akteurs nutzt, sicherstellen, dass die übermittelten Informationen 

• sich nur auf 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 Akteurs verknüpft werden,
• über die unweigerlich anfallenden Verbindungsdaten hinaus weder personenbezogene noch pseudonymisierte personenbezogene Daten enthalten,
• keine nutzerbezogenen IDs oder gerätespezifischen IDs der Nutzergeräte enthalten,
• 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,
• nicht durch die Verknüpfung mit personenbezogenen Daten aus anderen Quellen de-anonymisiert werden können

A_25590 - Information über Tracking und Reporting

Der TI-M Client MUSS, falls er Tracking- und/oder Reporting-Funktionen ohne Einwilligung des Akteurs nutzt, den Akteur über das Tracking und/oder Reporting im TI-M Client in verständlicher und leicht zugänglicher Form sowie in einer klaren und einfachen Sprache informieren, bevor die Informationen erhoben werden. [<=]

A_25591 - Zufällige Nutzungs-Identifier

Der TI-M Client MUSS, falls er Tracking- und/oder Reporting-Funktionen ohne Einwilligung des Akteurs nutzt, für jede Clientnutzung neue Nutzungs-Identifier zufällig generieren. [<=]

A_25592 - Neugenerierung zufälliger Nutzungs-Identifier

Der Akteur MUSS jederzeit in der Lage sein, die Neugenerierung von Nutzungs-Identifiern, die vom TI-M Client im Rahmen von Tracking- und/oder Reporting-Funktionen genutzt werden, zu erzwingen. [<=]

A_25593 - Opt-In für Verknüpfung von Informationen

Der TI-M Client MUSS, falls er Tracking- und/oder Reporting-Funktionen mit Verknüpfung der Informationen mehrerer Clientnutzungen implementiert, technisch sicherstellen, dass diese Tracking- und/oder Reporting-Funktionen bei der Installation des TI-M Clients standardmäßig deaktiviert sind und nur nach expliziter Einwilligung durch den Akteur aktiviert werden (Opt-in). Die Ablehnung der Nutzung solcher Funktionen darf die Standardfunktionen des TI-M Clients nicht einschränken. Eine Umgehung des Opt-In unter Verweis auf AGBs oder Nutzungsbedingungen ist nicht zulässig. [<=]

A_25594 - Zweck von Tracking und Reporting

Falls der TI-M Client Tracking- und/oder Reporting-Funktionen implementiert, die erst nach expliziter Einwilligung aktiviert werden (Opt-In), MUSS der TI-M Client dem Akteur vor der Einwilligung in die Aktivierung dieser Funktionen in verständlicher und leicht zugänglicher Form sowie in einer klaren und einfachen Sprache folgende Einwilligungsinformationen anzeigen: 

• 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 Akteurs möglich wären,
• wer die Empfänger der Daten sind,
• wie lange die Daten gespeichert werden.

A_25595 - Deaktivierbarkeit zuvor aktivierten Trackings und Reportings

Falls der TI-M Client Tracking- und/oder Reporting-Funktionen implementiert, MÜSSEN diese jederzeit durch den Akteur deaktivierbar sein. [<=]

A_26001 - Information über die Deaktivierbarkeit des Trackings

Der TI-M Client MUSS den Akteur in klarer und einfacher Sprache über die Möglichkeit der Deaktivierung von Tracking und Reporting informieren. [<=]

A_25596 - Kein wiederholtes Erfragen der Einwilligung

Der TI-M Client DARF NICHT wiederholt beim Akteur anfragen um diesen durch Belästigung zu einer Einwilligung in die Nutzung von Tracking- und/oder Reporting-Funktionen zu nötigen. Nach einmaliger Ablehnung erfolgt die erneute Anzeige des zugehörigen Dialogs nur auf Veranlassung durch den Akteur. [<=]

A_26077 - Server-seitiges Schlüssel-Backup

Der TI-M Client MUSS die für die Nutzung des serverseitigen Schlüssel-Backups [Client-Server API/#server-side-key-backups] benötigte Funktionalität implementieren und dem Akteur zur Verwendung anbieten.  [<=]

A_25613 - Hinweis bei passwort-basiertem Schlüssel-Backup

Bietet der TI-M Client für den Schutz von kryptographischem Material (im Rahmen des Schlüssel-Backups) die Verwendung von Passwörtern an, um den Schlüssel für das Schlüssel-Backup zu verschlüsseln, so MUSS er den Nutzer zum Zeitpunkt der Passwortvergabe explizit darauf hinweisen, dass sich das zu vergebene Passwort zwingend von dem Passwort für das Nutzerkonto am Matrix-Homeserver unterscheiden muss, weil sonst die Ende-zu-Ende-Verschlüsselung wenigstens gegenüber dem Homeserver und jenen Akteuren, die diesen kontrollieren, nicht mehr wirksam ist. [<=]

A_25614 - Vorschlag von Passwörtern für das Schlüssel-Backup

Der TI-M Client SOLL dem Nutzer im Rahmen der Passwortvergabe ein Passwort vorschlagen, das eine zufällige Kombination von mindestens 14 Zeichen Länge aufweist, die sich aus Zahlen, Sonderzeichen, sowie Groß- und Kleinbuchstaben zusammensetzt. [<=]

A_25615 - Quelle des Zufalls für Vorschläge

Die Quelle für Zufall, die der TI-M Client zum Vorschlagen von Passwörtern verwendet, MUSS wenigstens die Güte haben, wie jene Quellen, die er im Rahmen der Aushandlung von Schlüsselmaterial für die Kommunikation benutzt. [<=]

A_25616 - Parameter für die passwort-basierte Schlüsselableitung

Bei der passwort-basierten Schlüsselableitung (PBKDF2) im Rahmen des Schlüssel-Backups MUSS der TI-M Client gemäß [OWASP PBKDF2] >= 210.000 Iterationen wählen; die Hash-Funktion ist mit SHA-512 durch die Matrix-Spezifikation vorgegeben. [<=]

A_25617 - Möglichkeit der Verwahrung von Passwörtern

Der TI-M Client KANN dem Nutzer Funktionen zur Verfügung stellen, die ihm eine sichere Verwahrung von Passwort oder Schlüssel erleichtern, beispielsweise indem ein Export in einen installierten Passwort-Manager angeboten wird. [<=]

A_25618 - Nutzung von Passphrasen

Schlägt der TI-M Client nicht Passwörter, sondern Passphrasen vor, so MUSS die Länge der Phrasen so weit erhöht werden, dass eine vergleichbare Entropie wie bei der Verwendung von Passwörtern nach A_25614 erreicht wird. [<=]

A_25479 - Search Token

Der TI-M Client MUSS dem Akteur einen search-accesstoken für die Suche im VZD-FHIR-Directory bereitstellen. [<=]

A_25428 - VZD-FHIR-Directory Inhalte

Der TI-M Client MUSS eine Funktion bereitstellen, damit Akteure das VZD-FHIR-Directory nach Ressourcen durchsuchen und die Ergebnisse inklusive Detailinformationen anzeigen können. [<=]

A_25363 - Testtreiber-Modul

Für jeden TI-M Client MUSS für die Zulassung ein Testtreiber Modul bereitgestellt werden, welches die von der gematik vorgegebene Schnittstelle [api-Testtreiber] anbietet. [<=]

A_25360 - kein Testtreiber in der produktiven Anwendung

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

A_25361 - keine Modifikation der Inhalte

Das Testtreiber-Modul KANN die Ausgaben des TI-M Clients gemäß der technischen Schnittstelle aufarbeiten, aber DARF NICHT die Inhalte verfälschen und keine Fachlogik des Clients umsetzen. [<=]

A_25354 - Registrierung einer Organisation

Für die initiale Registrierung einer Organisation, MUSS der TI-Messenger-Anbieter die Identität der Organisation mittels SM(C)-B feststellen. [<=]

A_25357 - Verfahren zum Nachweis der Identität einer Organisation

TI-Messenger-Anbieter MÜSSEN für die Feststellung der Identität einer Organisation im Rahmen deren Registrierung wenigstens eines der beiden folgenden Verfahren unterstützen:

• OpenID Connect-Verfahren mit SM(C)-B
  
• KIM-Verfahren

A_25359 - Authorization Code Flow mit PKCE

Der TI-Messenger-Anbieter MUSS sicherstellen, dass bei Verwendung des OpenID Connect-Verfahrens der Authroization Code Flow mit PKCE zum Einsatz kommt. [<=]

A_25362 - Durchführung der PKCE-Challenge

Bei Verwendung des OpenID Connect-Verfahrens, MUSS der Registrierungs-Dienst den PKCE-Code erzeugen und später den Verifier dieser Challenge zusammen mit dem Authorization Code beim zentralen IDP-Dienst gegen ein ID_TOKEN einlösen. [<=]

A_25364 - Validierung von ID_TOKEN

Der Registrierungs-Dienst MUSS das durch den zentralen IDP-Dienst ausgestellte ID_TOKEN validieren und die darin enthaltene ProfessionOID gegen die in der Tabelle "Tab_PKI_403-x OID-Festlegung Institutionen im X.509-Zertifikat der SMC-B" gelisteten OIDs gemäß [gemSpec_OID] prüfen. [<=]

A_25365 - Registrierung am IDP

Registrierungs-Dienste MÜSSEN am zentralen IDP-Dienst gemäß [gemSpec_IDP_FD] registriert sein und den von diesem IDP-Dienst ausgestellten ID_TOKEN vertrauen. [<=]

A_25366 - Claims in ID_TOKEN für Organisationen

Der Anbieter des TI-Messengers MUSS über einen organisatorischen Prozess beim zentralen IDP-Dienst folgende Claims für ID_TOKEN, die auf Basis der Authentisierung mittels SM(C)-B ausgestellt werden, vereinbaren:

• ProfessionOID
• idNummer
• organizationName
• acr
• aud

A_25369 - Prüfung der KIM-Adresse

Bietet der TI-Messenger-Anbieter das KIM-Verfahren an und entscheidet sich die Organisation, deren Identität festgestellt werden soll, dieses Verfahren zu nutzen, MUSS der TI-Messenger-Anbieter die ProfessionOID sowie die TelematikID für die von der Organisation mitgeteilte KIM-Adresse durch Abfrage am LDAP-VZD ermitteln und die ProfessionOID gegen die in der Tabelle "Tab_PKI_403-x OID-Festlegung Institutionen im X.509-Zertifikat der SMC-B" gelisteten OIDs gemäß [gemSpec_OID] prüfen. [<=]

A_25373 - Versand der KIM-Nachricht nach erfolgreicher Prüfung

War die Prüfung der KIM-Adresse hinsichtlich zugehöriger ProfessionOID und TelematikID, welche im Rahmen des KIM-Verfahrens durchgeführt wird, erfolgreich, MUSS der TI-Messenger-Anbieter eine KIM-Nachricht an die angegebene KIM-Adresse senden, welche eine URL enthält, die zurück in den Registrierungsprozess leitet. [<=]

A_25374 - Information zum Zweck der KIM-Nachricht

Versendet der TI-Messenger-Anbieter im Rahmen des KIM-Verfahrens eine KIM-Nachricht zur Fortführung des Registrierungsprozesses, MUSS er den Registrierenden über den Versand der KIM-Nachricht informieren und ihn dazu auffordern den Anweisungen innerhalb der KIM-Nachricht zu folgen. [<=]

A_25377 - Verifikation des Registrierenden

Um sicherzustellen, dass derjenige, der die KIM-Nachricht empfängt und die enthaltene URL aufruft auch der Registrierende ist, MUSS der Registrierungs-Dienst in dem Prozessschritt, der zum Versand der KIM-Nachricht führt, einen zufälligen sechsstelligen Code anzeigen, welcher innerhalb einer Eingabemaske nach Aufruf der URL vom Registrierenden einzugeben ist. [<=]

A_25375 - Form der KIM-Nachricht

Die vom TI-Messenger-Anbieter versendete KIM-Nachricht zur Fortführung des Registrierungsprozesses MUSS kenntlich machen, dass es sich hierbei um eine Authentifizierungsmail handelt und das E-Mail-Header Element X-KIM-Dienstkennung: Auth;Verification;V1.0 enthalten. [<=]

A_25376 - Form der URL innerhalb der KIM-Nachricht

Um das Erraten der URL zu verhindern, MUSS der TI-Messenger-Anbieter sicherstellen, dass die URL innerhalb der KIM-Nachricht, die den Registrierenden zurück in den Registrierungsprozess führt, aus dem FQDN des Registrierungs-Dienstes und einer eindeutigen ID (UUID) gemäß [RFC4122] besteht. [<=]

A_25309 - Authentisierung mittels SM(C)-B

Für Akteure in der Rolle "Org-Admin" MUSS der Registrierungs-Dienst sicherstellen, dass mindestens eine Authentisierung mittels SM(C)-B unterstützt wird.  [<=]

A_25370 - Anlegen eines Org-Admin-Kontos

Konnte die Identität einer sich registrierenden Organisation bestätigt werden, MUSS der Registrierungs-Dienst des TI-Messenger-Anbieters ein Org-Admin-Konto für diese Organisation anlegen und in diesem Konto die ProfessionOID sowie die TelematikID der Organisation für den Org-Admin unveränderlich speichern. [<=]

A_25356 - Registrierung von TI-M Diensten

Der TI-Messenger-Anbieter MUSS sicherstellen, dass Registrierungen von TI-M Diensten nur durch einen authentifizierten Org-Admin durchgeführt werden können und auch nur für die jeweilige Organisation, der er - der Org-Admin - gemäß initialer Registrierung der Organisation angehört. [<=]

A_25628 - Bereitstellung von Messenger-Services

Der Org-Admin MUSS über das Frontend des Registrierungs-Dienstes neue Messenger-Services anlegen und diesen Domains zuweisen können. [<=]

A_25708 - I_Admin Zugriff

Der Registrierung-Dienst MUSS sicherstellen, dass ein Akteur in der Rolle "Org-Admin" über die Schnittstelle I_Admin nur Zugriff auf die Messenger-Services erhält, die er sich über den Anwendungsfall AF_10060-02 - Bereitstellung eines Messenger-Service für eine Organisation angelegt hat. [<=]

A_25607 - I_internVerification

Der Registierungs-Dienst MUSS den Messenger-Proxies eine Schnittstelle für die Bereitstellung der Föderationsliste zur Verfügung stellen. [<=]

A_25636 - Maximale Alter der Föderationsliste

Der Messenger-Proxy MUSS die Kommunikation zu anderen Matrix-Homeservern einstellen, wenn Alter_Föderationsliste den Wert von TTL_Föderationsliste erreicht. [<=]

A_25637 - Aktualisierung der Föderationsliste

Der Registrierungs-Dienst MUSS jede Stunde die Aktualität seiner Föderationsliste gegenüber der vom VZD-FHIR-Directory bereitgestellten Liste prüfen. [<=]

A_25638 - Abfrage beim VZD-FHIR-Directory

Der Registrierungs-Dienst MUSS die Föderationsliste für Abfragen der Messenger-Proxies cachen, um nicht bei jeder Anfrage eines Proxies eine Anfrage an das VZD-FHIR-Directory zu stellen. [<=]

A_25625 - Registrierungs-Dienst VZD Provider Login

Der Registrierungs-Dienst MUSS die 2-stufige Anmeldung am VZD-FHIR-Directory für die tim-provider-services Schnittstelle unterstützen. [<=]

A_25626 - TI-M Provider Services

Der Registrierungs-Dienst MUSS die an der Schnittstelle I_VZD_TIM_Provider_Services angebotenen Funktionen, den Messenger-Proxies und dem Frontend des Registrierungs-Dienstes zur Verfügung stellen. [<=]

A_25378 - Forward- und Reverse-Proxy

Der Messenger-Proxy MUSS für jeden Messenger-Service als Forward sowie Reverse-Proxy bereitgestellt werden. [<=]

A_25368 - Invites beim createRoom

Der Messenger-Proxy MUSS sicherstellen, dass beim Anlegen eines Raumes das Attribut "invite" mit maximal einer MXID befüllt ist. [<=]

A_25538 - Too many invites

Ist das Attribute "invite" mit mehr als einem Element befüllt, dann MUSS der Messenger-Proxy an den TI-M Client das folgenden JSON-Objekt zurückgeben: 

A_25630 - Forward Proxy

Die Kommunikation des Matrix Homeservers in das Internet MUSS immer über den eigenen Messenger-Proxy (in der Funktion als Forward-Proxy) erfolgen.  [<=]

A_25539 - Userinfo für VZD-FHIR-Directory

Der Messenger-Proxy MUSS dem VZD-FHIR-Directory Zugriff auf den Endpunkt /_matrix/federation/v1/openid/userinfo der Matrix-Homeserver ermöglichen.  [<=]

A_25632 - Signatur der Föderationsliste

Der Messenger-Proxy MUSS zur Prüfung der Signatur der Föderationsliste das im Signatur-Header enthaltene Signaturzertifikat (öffentliche Schlüssel) und das X.509-Root-CA Zertifikat der TI verwenden. [<=]

A_25635 - OCSP-Responder

Die Gültigkeit des Signaturzertifikates MUSS mit Hilfe des [OCSP-Responder] validiert werden. [<=]

A_25634 - Zertifikatsaktualisierung

Der Messenger-Proxy MUSS wöchentlich prüfen, ob neue X.509-Root-CA-Versionen existieren und Cross-Zertifikate verfügbar sind. Ist dies der Fall, MUSS der Messenger-Proxy diese neuen Root-Versionen in seinen Truststore importieren. [<=]

A_25530 - Client-Server API

TI-M FD MÜSSEN sicherstellen, dass die Matrix-Homeserver die [Client-Server API] umsetzen. [<=]

A_25344 - Server-Server API

TI-M FD MÜSSEN sicherstellen, dass die Matrix-Homeserver die [Server-Server API] umsetzen. [<=]

A_25531 - Appendices TI-M FD

TI-M FD MÜSSEN sicherstellen, dass die Matrix-Homeserver [Matrix Appendices] umsetzen. [<=]

A_25393 - Ausgabe von access token durch den TI-M FD

Der TI-M FD MUSS die Komponente Matrix-Homeserver so implementieren, dass bei erfolgreichem Aufruf der [Client-Server API] Endpoints /login und /register neue access token und refresh token ausgegeben werden. [<=]

A_25352 - Gültigkeitsdauer von access token des TI-M FD

Der TI-M FD MUSS die Komponente Matrix-Homeserver so implementieren, dass vom Matrix-Homeserver ausgestellte access token eine Gültigkeitsdauer von max. 24 Stunden haben. [<=]

A_25353 - Gültigkeitsdauer von refresh token des TI-M FD

Der TI-M FD MUSS die Komponente Matrix-Homeserver so implementieren, dass vom Matrix-Homeserver ausgestellte refresh token eine Gültigkeitsdauer von max. 6 Monaten haben. [<=]

A_25322 - Create Room

Der Matrix-Homeserver MUSS beim Aufruf der API zum Anlegen eines Raumes nur die Einladung maximal einer MXID zulassen.  [<=]

A_25318 - Löschfunktion für Matrix-Homeserver

Matrix-Homeserver MÜSSEN eine Funktion anbieten, durch die Events, Gesprächsinhalte und mit einzelnen Gesprächen assoziierte Daten (z. B. versandte Dateien) nach einem festgelegten Zeitraum seit letzter Aktivität in einem Raum gelöscht werden. [<=]

A_25319 - Zeitraum zur Auslösung der Löschfunktion für Matrix-Homeserver

Die Löschfunktion für Matrix-Homeserver MUSS auf sechs Monate voreingestellt und durch einen Akteur in der Rolle "Org-Admin" konfigurierbar sein. [<=]

A_25320 - Umsetzung der Löschfunktion für Matrix-Homeserver

Die Löschfunktion für Matrix-Homeserver KANN derart realisiert werden, dass nach Verstreichen des festgelegten Zeitraums die Teilnehmer einen Gesprächsraum verlassen - bspw. indem sie vom Homeserver aus diesem entfernt werden - und der Raum nach Verlassen aller Teilnehmer automatisch gelöscht wird. [<=]

A_25321 - Deaktivierung der Löschfunktion für Matrix-Homeserver

Die Löschfunktion für Matrix-Homeserver KANN per Opt-Out durch den Akteur in der Rolle "Org-Admin" deaktivierbar sein. [<=]

A_25298 - Vertragsverpflichtungen

Der TI-Messenger-Anbieter MUSS die den TI-M Dienst nutzende Organisation vertraglich dazu verpflichten, dass TI-Messenger-Accounts nur für Akteure erstellt werden, mit denen ein Vertragsverhältnis besteht, das zur Nutzung berechtigt. Funktionsaccounts (in Verbindung mit einem automatisierten System, d.h. Bot,) sind von den Vertragsverpflichtungen ausgenommen.
[<=]

A_25299 - Flächendeckende Verwendung von TLS

Sämtliche Kommunikation zwischen Komponenten des TI-M Dienstes MUSS TLS-verschlüsselt erfolgen, sofern die Kommunikation die Grenzen einer virtuellen/physischen Maschine überschreitet.
[<=]

A_25303 - Mindestens serverseitiges TLS

Im Rahmen der Kommunikation per TLS MUSS mindestens serverseitiges TLS verwendet werden.
[<=]

A_25301 - Authentifizierung von Clients

Server MÜSSEN Clients authentifizieren, bevor Ihnen - den Clients - Zugriff auf Ressourcen gewährt wird, die nicht frei zur Verfügung stehen.
[<=]

A_25302 - Art der Client-Authentifizierung

Clients SOLLEN sich gegenüber Servern per TLS-Client-Zertifikat oder einem Verfahren mit vergleichbarem Sicherheitsniveau authentisieren. [<=]

A_25311 - Minimale Qualität von Passwörtern

Der Anbieter des TI-M FD MUSS Vorgaben zur minimalen Qualität von Passwörtern entsprechend [BSI ORP.4] A.22 machen und die Einhaltung dieser Vorgaben an allen Stellen gewährleisten, an denen Passwörter im Rahmen der Konfiguration festzulegen sind.  [<=]

A_25312 - Instruktion über Einhaltung von Vorgaben zu Passwörtern

Der Anbieter MUSS die Organisation, welche den TI-Messenger Dienst von ihm bezieht, über die Notwendigkeit der Einhaltung der Vorgaben aus [BSI ORP.4] A8 instruieren. Diese beinhalten sicherheitsrelevante Anforderungen hinsichtlich der Nutzung und des Umgangs mit Passwörtern, richten sich jedoch an den operativen Betrieb durch die Leistungserbringerinstitution bzw. den Kostenträger, der vom Anbieter nicht kontrolliert werden kann. [<=]

A_25313 - Zwangsabmeldung und Sperrung von Akteuren

Wird ein Akteur in der Rolle "User" des TI-M Dienstes einer Organisation durch einen Akteur in der Rolle "Org-Admin" der Organisation gesperrt oder seine aktive Sitzung beendet - das heißt, er wird zwangsweise ausgeloggt -, so MUSS der TI-M FD die Weiterleitung von Nachrichten, die an diesen Akteur in der Rolle "User" gesendet werden oder von diesem gesendet werden, mit sofortiger Wirkung einstellen. [<=]

A_25314 - Einbringung kryptographischen Materials zur Authentisierung gegen das VZD-FHIR-Directory

TI-Messenger-Anbieter MÜSSEN sicherstellen, dass kryptographisches Material zur Authentisierung gegen das VZD-FHIR-Directory sicher eingebracht wird. Zum Nachweis der Umsetzung ist eine Prüfung des Prozesses zur Einbringung des kryptografischen Materials erforderlich. Die Prüfung umfasst die Beschreibung und Durchführung des Prozesses. Eine Auditierung der Umsetzung ist optional. [<=]

A_25315 - Explizites Verbot von Profiling für TI-Messenger-Hersteller

TI-Messenger-Hersteller DÜRFEN NICHT Daten zu Profilingzwecken sammeln. Dies betrifft insbesondere eine Überwachung, welche Akteure mit welchen anderen Akteuren kommunizieren. [<=]

A_25316 - Explizites Verbot von Profiling für TI-Messenger-Anbieter

TI-Messenger-Anbieter DÜRFEN NICHT Daten zu Profilingzwecken sammeln. Dies betrifft insbesondere eine Überwachung, welche Akteure mit welchen anderen Akteuren kommunizieren.  [<=]

A_25317 - Protokollierung zum Zwecke der Fehler- bzw. Störungsbehebung

Falls im TI-M FD eine Protokollierung zum Zwecke der Fehler- bzw. Störungsbehebung erfolgt, MUSS der Fachdienst unter Berücksichtigung des Art. 25 Abs. 2 DSGVO sicherstellen, dass in den Protokolldaten entsprechend dem Datenschutzgrundsatz nach Art. 5 DSGVO nur personenbezogene Daten in der Art und dem Umfang enthalten sind, wie sie zur Behebung erforderlich sind und dass die erzeugten Protokolldaten im Fachdienst nach der Behebung unverzüglich gelöscht werden. Sofern andere gesetzliche Grundlagen wie §331 SGB V nicht überwiegen, sind hierzu nur anonymisierte Daten zu protokollieren. [<=]

A_25327 - Sicherheitsrisiken von Software-Bibliotheken minimieren

TI-M FD-Hersteller MÜSSEN Maßnahmen umsetzen, um die Auswirkung von unentdeckten Schwachstellen in benutzten Software-Bibliotheken zu minimieren. [<=]

A_25328 - Wirksamkeit von Maßnahmen zur Minimierung von Sicherheitsrisiken

Die zur Minimierung der Auswirkungen von unentdeckten Schwachstellen in benutzten Software-Bibliotheken umgesetzten Maßnahmen MÜSSEN wenigstens die gleiche Wirksamkeit aufweisen, wie die Kapselung gemäß [OWASP Proactive Control#C2 Punkt 4]. [<=]

A_25333 - Abweichungen vom Matrix-Standard

TI-M FD-Hersteller MÜSSEN sämtliche nicht in der TI-Messenger-Spezifikation beschriebenen Abweichungen vom Matrix-Protokoll oder den MUST- oder SHOULD-Empfehlungen des Matrix-Protokolls dokumentieren und begründen. [<=]

A_25334 - Interoperabilität von Zusatzfunktionen für den TI-M FD

TI-M FD-Hersteller MÜSSEN sicherstellen, dass alle implementierten Funktionen, die über den gewöhnlichen Funktionsumfang einer TI-Messenger-Komponente hinausgehen, die Sicherheit des Produkts nicht gefährden und die Interoperabilität mit anderen TI-Messenger-Produkten gewährleisten. [<=]

A_25342 - Einsatz geschulter Administratoren

TI-Messenger-Anbieter MÜSSEN als Administratoren Personal einsetzen, welches für die damit verbundenen Aufgaben und Themen der Informationssicherheit geschult und sensibilisiert wurden. [<=]

A_25343 - Berechtigung von Administratoren

TI-Messenger-Anbieter MÜSSEN technisch sicherstellen, dass nur die berechtigten Administratoren administrativen Zugriff auf die zu verwaltenden Messenger-Services haben. [<=]

A_25556 - Test des TI-M Clients gegen die Referenzimplementierung

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

A_25623 - Test des TI-M FD gegen die Referenzimplementierung

Der Hersteller des TI-M FD MUSS den Fachdienst gegen die Referenzimplementierung erfolgreich testen. Die Testergebnisse sind der gematik vorzulegen. [<=]

A_25619 - TI-Messenger Instanzen

Der TI-Messenger-Anbieter MUSS eine Referenzinstanz und mindestens eine Testinstanz des TI-M FD und TI-M Clients bereitstellen und betreiben. [<=]

A_25620 - Nutzung der Referenz- und Testinstanzen

Der TI-Messenger-Anbieter MUSS die verschiedenen Benutzer der Referenzinstanz und der Testinstanz koordinieren (.z.B. Verwaltung eines Test-/Nutzungsplans). [<=]

A_25621 - Weitere Testinstanzen

Bei Bedarf (Entwicklung verschiedener Versionen, hoher Auslastung durch andere Hersteller oder durch die gematik) MUSS der TI-Messenger-Anbieter auch mehrere Testinstanzen mit der gleichen oder mit verschiedene Versionen bereitstellen und betreiben. [<=]

A_25622 - Umsetzung des Testkonzepts

Die TI-Messenger Hersteller MÜSSEN sicherstellen, dass das Testkonzept [gematik Testkonzept] vollständig umgesetzt wird. [<=]

A_25250 - TI-Messenger Anbieter - Produktverantwortung (Basis)

Der TI-Messenger Anbieter MUSS mindestens einen:

• TI-Messenger Fachdienst

A_25379 - TI-M Gültigkeitsprüfung der Organisation am VZD-FHIR-Directory

Der TI-M FD MUSS mindestens alle 24 Stunden, für alle bei ihm registrierten Organisationen mit einem Messenger-Service, prüfen, ob diese im VZD-FHIR-Directory als "active" (Organization.active) eingetragen sind. [<=]

A_25380 - TI-M Information bei ausgetragener Organisation am VZD-FHIR-Directory

Wenn die Organisation nicht mehr im VZD-FHIR-Directory "active" (Organization.active) ist, MUSS der TI-Messenger-Anbieter diese darüber informieren. [<=]

A_25381 - TI-M Sperrung der Organisation mit ungültigem SM-B bzw. ungültiger SMC-B

Wenn die Organisation länger als 30 Kalendertage nicht im VZD-FHIR-Directory "active" (Organization.active) ist, MUSS der TI-Messenger-Anbieter die Domäne dieses Messenger-Service aus der Föderation löschen (siehe FHIR-VZD: I_VZD_TIM_Provider_Services, DELETE /federation/{domain}). Dann DARF erst nach erneuter Authentifizierung per SM(C)-B der Dienst wieder genutzt werden, siehe AF_10103. [<=]

A_26095 - logische Trennung Messenger-Services

Werden durch einen TI-Messenger-Anbieter mehrere Domains in einem gemeinsamen Messenger-Service betrieben, so MUSS die logische Trennung der Matrix-Domains sichergestellt werden.

Hinweis: Die Anforderungen A_25381 & A_25382 erfordern die Zuordnung einer Organisation zu einer Domain, um einer Organisation die Teilnahme an der Föderation zu entziehen.
[<=]

A_25382 - TI-M kontrollierte Außerbetriebnahme

Wenn z. B. das Vertragsverhältnis zwischen Kunde und TI-Messenger-Anbieter ausläuft, so MUSS der TI-Messenger-Anbieter die dazugehörige Domäne dieses Messenger-Service aus der Föderation löschen (siehe FHIR-VZD: I_VZD_TIM_Provider_Services, DELETE /federation/{domain}) und den Messenger-Service abschalten, so dass dieser nicht mehr erreicht werden kann. [<=]

A_25627 - Bereitstellung Messenger-Services

Die Bereitstellung der Messenger-Services erfolgt über den Registrierungs-Dienst eines TI-M FD und KANN on-premise oder zentral innerhalb von Rechenzentren stattfinden. [<=]

A_23658-01 - Produktnachweise im Rahmen der kontrollierten Inbetriebnahme

Das Produkt MUSS die Vorgaben zur Funktionalität, Sicherheit und Interoperabilität entsprechend des jeweiligen Produkttypsteckbriefs in der Produktivumgebung erfüllen. Die Nachweise dafür MÜSSEN entsprechend und im Rahmen des Konzepts zur kontrollierten Inbetriebnahme erbracht werden. [<=]

A_25823 - TI-Messenger Fachdienst Bestandsdaten (Basis)

Der TI-Messenger-Fachdienst MUSS die nachfolgenden Informationen täglich in folgendem JSON Format als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß [gemSpec_SST_LD_BD] liefern:

{
  "abfragezeitpunkt": <Zeitstempel der Abfrage als String im Format ISO 8601: YYYY-MM-DDThh:mm:ssZ>,
  "ci": <CI-ID des abgefragten Fachdienstes gemäß [A_17764] als String>,
  "anzMs": <Anzahl der zum Abfragezeitpunkt instanziierten Messenger-Service als Integer>,
  "anzNu": <Anzahl der zum Abfragezeitpunkt registrierten Nutzer über alle Messenger-Services als Integer>,
  "anzAktNu": <Anzahl der zum Abfragezeitpunkt innerhalb der letzten 30 Tage aktiven Nutzer über alle Messenger-Services als Integer>,
  "anzRa": <Anzahl der zum Abfragezeitpunkt offenen Räume als Integer>,
  "anzEv": <Anzahl Message-Events als Integer, kumuliert>,
  "uaList": [{
    "uaKen": $ua-ken,
    "uaPtv": $ua-Produkttypversion,
    "uaPv": $ua-Produktversion,
    "uaAus": $ua-Auspraegung,
    "uaPlat": $ua-Plattform,
    "uaOsv": $ua-OSv,
    "uaCid": $ua-client_id,
  }],
  "afList": [{
    "md": "$md",
    "TIM.UC_10103-02a_01": $anzahl,
    "TIM.UC_10103-02a_02": $anzahl,
    "TIM.UC_10103-02b_01": $anzahl,
    "TIM.UC_10103-02b_02": $anzahl,
    "TIM.UC_10103-02_03": $anzahl,
    "TIM.UC_10060-02_01": $anzahl,
    "TIM.UC_10060-02_02": $anzahl,
    "TIM.UC_10057-01_01": $anzahl,
    "TIM.UC_10057-01_02": $anzahl,
    "TIM.UC_10104-02_01": $anzahl,
    "TIM.UC_10104-02_02": $anzahl,
    "TIM.UC_10104-02_03": $anzahl,
    "TIM.UC_10063-01_01": $anzahl,
    "TIM.UC_10061-02_01": $anzahl,
    "TIM.UC_10061-02_02": $anzahl,
    "TIM.UC_10062-02_01": $anzahl,
    "TIM.UC_10062-02_02": $anzahl,
  }]
}

• uaList: Das Array MUSS mit Werten entsprechend ihrer Beschreibung befüllt werden. Es DÜRFEN NUR neue Kombinationen der Attribute übermittelt werden, welche zuvor noch nicht übermittelt wurden.
• uaKen: Datentyp String, SHA1 (Base64-kodiert). Für $ua-ken MUSS die mit SHA1 kodierte Kennung einer bestimmten Client-Ausprägung eingetragen werden. Die Kennung MUSS eindeutig für jede einzigartige Kombination der User-Agent Attribute vergeben werden.*
• uaPtv: Datentyp String. Für $ua-Produkttypversion MUSS die Produkttypversion des TI-Messenger Clients eingetragen werden.
• uaPv: Datentyp String. Für $ua-Produktversion MUSS die Produktversion des TI-Messenger Clients eingetragen werden.
• uaAus: Datentyp String. Für $ua-Auspraegung MUSS die Ausprägung des Clients entsprechend der Spezifikation eingetragen werden. Es DÜRFEN AUSSCHLIEßLICH die Werte "Org-Admin-Client" oder "Messenger-Client" verwendet werden.
• uaPlat: Datentyp String. Für $ua-Plattform MUSS die Plattform des Clients eingetragen werden. Es DÜRFEN AUSSCHLIEßLICH die Werte "mobil", "stationaer" oder "web" verwendet werden.
• uaOsv: Datentyp String. Für $ua-OSv MUSS das entsprechende Betriebssystem mit der Version eingetragen werden. Zum Beispiel "Windows 10 Enterprise", "iOS 16.6", "macOS Ventura 13.5.1", "Android 13", "Ubuntu 22.04 LTS" etc.
• uaCid: Datentyp String. Für $ua-client_id MUSS die client_id eingetragen werden wie sie auch dem TI-Messenger Fachdienst gemäß A_25483 übermittelt wird.
• afList: Das Array enthält alle Teilschritte aller Anwendungsfälle die am Fachdienst erfasst werden MÜSSEN. Die Keys MÜSSEN alle exakt wie dargestellt übermittelt werden. Die erfasste Anzahl an Aufrufen je Teilschritt (inkl. Fehler) MUSS für $anzahl als Wert (Integer) übermittelt werden. Wenn ein Teilschritt in einem Zeitintervall nicht registriert wurde, MUSS der Wert 0 eingetragen werden.
• md: Datentyp String. Für $md MUSS die eigene Matrix-Domain des Messenger-Services eingetragen werden, wie sie auch in der Föderationsliste hinterlegt ist.

A_25383 - TI-M Client Anbietersupport

Der TI-Messenger-Anbieter MUSS seine Nutzer bzw. die Akteure dabei unterstützen, einen sicheren und funktionalen Betrieb der TI-M Clients zu ermöglichen. [<=]

A_25384 - TI-M Client Betreibbarkeit

Der TI-M Client MUSS mit einer vollumfänglich-funktionalen Verfügbarkeit von 98 % betreibbar sein.  [<=]

A_25385 - TI-M Client Verfügbarkeit

Der TI-Messenger-Anbieter MUSS die Produkt(e) TI-M Client mit einer vollumfänglich-funktionalen Verfügbarkeit von 98 % seinen Nutzern anbieten. [<=]

A_25548 - Information über Updates für den Client

Hersteller des TI-M Client MÜSSEN sicherstellen, dass Akteure über die Veröffentlichung von Updates für ihre TI-M Clients informiert werden, bspw. durch Mitteilung innerhalb und mittels des TI-M Clients. [<=]

A_25549 - Information über Notwendigkeit von Sicherheitsupdates

Hersteller des TI-M Clients MÜSSEN sicherstellen, dass Akteure geeignet über die Notwendigkeit der Installation sicherheitskritischer Updates informiert werden, um den TI-M Client weiterhin nutzen zu können. [<=]

A_25550 - Sperrung von Clients ohne Sicherheitsupdates

TI-M Client-Hersteller MÜSSEN sicherstellen, dass nach einer geeigneten Frist eine weitere Nutzung des TI-M Clients ohne vorheriges Sicherheitsupdate nicht möglich ist. Hierzu genügt eine client-seitige Sperre anstatt eines Nachweises gegenüber dem Matrix-Homeserver. [<=]

A_25551 - Fähigkeit zum Update im gesperrten Zustand

Ist ein TI-M Client wegen ausgebliebener Installation von Sicherheitsupdates nicht mehr für die Kommunikation nutzbar, MUSS die Möglichkeit der Installation von Updates weiterhin gegeben sein. [<=]

A_25552 - Information und Nachweis der Eignung

Der Hersteller des TI-M Clients MUSS die gematik bei Veröffentlichung einer neuen Produktversion informieren und eine Erklärung zur sicherheitstechnischen Eignung liefern. [<=]

A_25565 - Explizites Verbot von Profiling für TI-M Clients

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

A_25582 - Vertrauenswürdige Bezugsquellen für den TI-M Client

Der Hersteller eines TI-M Clients MUSS Akteure über die vertrauenswürdigen Quellen informieren, von denen Akteure den TI-M Client beziehen können und wie sie die Vertrauenswürdigkeit der Quelle erkennen können. [<=]

A_25583 - Möglichkeit der Authentizitätsprüfung

Der Hersteller MUSS sicherstellen, dass der Akteur bei Erstbezug eines TI-M Clients die Authentizität der vertrauenswürdigen Bezugsquelle verifizieren kann. [<=]

AF_10103-02 - Authentisieren einer Organisation am TI-M Dienst

Mit diesem Anwendungsfall authentisiert ein Akteur, in der Rolle "Org-Admin", seine Organisation bei einem TI-Messenger-Anbieter. Für die Authentisierung einer Organisation stellt der TI-M FD eine Schnittstelle an seinem Registrierungs-Dienst bereit. Diese wird über das Frontend des Registrierungs-Dienstes für die Authentisierung verwendet. Die Authentisierung der Organisation erfolgt individuell und nutzungsabhängig durch einen Akteur in der Rolle "Org-Admin". Im Rahmen der Authentifizierung MUSS der Besitz einer gültigen SM(C)-B nachgewiesen werden, da nur Organisationen des Gesundheitswesens berechtigt sind einen Messenger-Service zu erhalten. Als Nachweis ist eines der folgenden Verfahren zu verwenden:

• Verfahren 1: bei der Authentisierung am zentralen IDP-Dienst eine freigeschaltete SM(C)-B verwendet werden oder
• Verfahren 2: eine KIM-Nachricht an die Adresse der Organisation mit der freigeschalteten SM(C)-B gesendet werden.
  

Tabelle 6: Tabelle : AF - Authentisieren einer Organisation am TI-M Dienst

Abbildung 10: Laufzeitsicht - Authentisieren einer Organisation am TI-M Dienst 

A_25805 - AF_10103 - Organisation wurde erfolgreich verifiziert

Die im ID_TOKEN enthaltene ProfessionOID MUSS in der in [gemSpec_OID] in der Tabelle "Tab_PKI_403-x OID-Festlegung Institutionen im X.509-Zertifikat der SMC-B" gelisteten OIDs vorhanden sein. [<=]

A_25806 - AF_10103 - ID-Token wurde geprüft

Die Signatur des vom IDP-Dienst ausgestellten ID_TOKEN MUSS geprüft werden. [<=]

AF_10060-02 - Bereitstellung eines Messenger-Service für eine Organisation

Mit diesem Anwendungsfall wird einer zuvor am Registrierungs-Dienst authentifizierten Organisation ein Messenger-Service für diese Organisation durch einen Akteur in der Rolle "Org-Admin" bereitgestellt. Die Beantragung zur Bereitstellung eines Messenger-Service wird durch den Akteur in der Rolle "Org-Admin" am Frontend des Registrierungs-Dienstes vorgenommen. Dieser MUSS sich zuvor mit dem Admin-Account der Organisation am Registrierungs-Dienst anmelden. Für eine zeitnahe Adaption des TI-M Dienstes MUSS eine schnelle Bereitstellung von Messenger-Services gewährleistet sein. TI-Messenger-Anbieter sind verpflichtet, Prozesse zu etablieren, damit Messenger-Services für Organisationen schnell und ggf. automatisiert bereitgestellt werden können. Nach erfolgreicher Bereitstellung eines Messenger-Service wird dieser in die Föderation des TI-M Dienstes aufgenommen. Werden mehrere Messenger-Services für eine Organisation benötigt KANN dieser Anwendungsfall mehrfach ausgeführt werden.

Tabelle 7: AF - Bereitstellung eines Messenger-Service für eine Organisation

Abbildung 11: Laufzeitsicht - Bereitstellung eines Messenger-Service für eine Organisation   

AF_10064-02 - Föderationszugehörigkeit eines Messenger-Service prüfen

Dieser Anwendungsfall prüft, ob ein Messenger-Service zugehörig zur TI-Messenger-Föderation ist, und gilt für alle Anwendungsfälle, welche die Matrix-Domain eines Messenger-Services überprüfen müssen. Für die Prüfung der Zugehörigkeit der Matrix-Domain zur TI-Messenger-Föderation verwendet der Messenger-Proxy eine Föderationsliste, die vom Registrierungs-Dienst seines TI-M FD bereitgestellt wird. Die Speicherdauer der Föderationsliste des Messenger-Proxies ist limitiert. Die Aktualisierung der Föderationsliste erfolgt wie in 5.1.8 Aktualisierung der Föderationsliste  beschrieben.

Tabelle 8: Föderationszugehörigkeit eines Messenger-Service prüfen

Abbildung 12: Laufzeitsicht - Föderationszugehörigkeit eines Messenger-Service prüfen 

A_26017 - AF_10064 - Matrix-Domain Teil der Föderationsliste & Aktualitätscheck

Es MUSS sichergestellt werden, dass der Registrierungs-Dienst die Föderationsliste auf Aktualität überprüft, bevor eine aktualisierte Liste durch den Messenger-Proxy abgerufen werden kann. Ebenfalls MUSS sichergestellt werden, dass der Messenger-Proxy tatsächlich überprüft, ob die Matrix-Domain des anderen Messenger-Service Teil der Föderationsliste ist.
[<=]

A_26018 - AF_10064 - Aktualität - Föderationsliste Messenger-Proxy

Es MUSS sichergestellt werden, dass die Föderationsliste vom Messenger-Proxy aktuell ist. Dafür MUSS der Messenger-Proxy in einem festen Intervall von einmal pro Stunde eine aktuelle Liste beim Registrierungs-Dienst anfordern.
[<=]

AF_10057-01 - Anmeldung eines Akteurs am Messenger-Service

Mit diesem Anwendungsfall meldet sich ein Akteur an einem in der TI-Föderation zuständigen Messenger-Service an und registriert seinen TI-M Client als Endgerät. Der Akteur MUSS die Matrix-Domain des gewünschten Messenger-Service direkt im TI-M Client eingeben können. Die Eingabe KANN dabei automatisiert oder durch andere Hilfsmittel wie beispielweise durch einen QR-Code-Scan unterstützt werden. Die Authentifizierung erfolgt hierbei nach den Vorgaben der jeweiligen Organisation.

Tabelle 9: AF - Anmeldung eines Akteurs am Messenger-Service

Abbildung 13: Laufzeitsicht - Anmeldung eines Akteurs am Messenger-Service

AF_10104-02 - Einladung von Akteuren innerhalb einer Organisation

In diesem Anwendungsfall wird ein Akteur, der zu einer gemeinsamen Organisation gehört, in einen Raum eingeladen, um Aktionen auszuführen. Für die Suche nach Akteuren innerhalb einer gemeinsamen Organisation durchsucht ein TI-M Client das Nutzerverzeichnis seiner Organisation auf dem Matrix-Homeserver. Anschließend wird die Einladung vom Einladenden an den Messenger-Proxy übermittelt. Dieser prüft ob die beteiligten Akteure bei ihm registriert sind. Ist dies der Fall erfolgt die Weiterleitung an den Matrix-Homeserver der Akteure. Ist dies nicht der Fall, handelt es sich bei dem einzuladenden Akteur nicht um einen Akteur innerhalb der Organisation und das Invite-Event wird für die externe Zustellung weitergeleitet. Der Anwendungsfall   zeigt den sich daraus ergebenden Verlauf.

Tabelle 10: Einladung von Akteuren innerhalb einer Organisation

Abbildung 14: Einladung von Akteuren innerhalb einer Organisation

A_26019 - AF_10104 - Matrix-Homeserver nach Akteuren durchsuchen

Der TI-M Client erlaubt das Suchen eines Akteurs in der Liste aller Akteure am Matrix-Homeserver. [<=]

AF_10063-01 - Austausch von Events zwischen Akteuren innerhalb einer Organisation

Dieser Anwendungsfall ermöglicht es Akteuren, welche sich in einem gemeinsamen Raum innerhalb eines Messenger-Service befinden, Nachrichten auszutauschen und weitere durch die Matrix-Spezifikation festgelegte Aktionen (Events) auszuführen.

Tabelle 11: Austausch von Events zwischen Akteuren innerhalb einer Organisation

In der Laufzeitsicht sind die Interaktionen zwischen den Komponenten, die durch den Anwendungsfall genutzt werden, dargestellt. Hierbei handelt es sich um eine vereinfachte Laufzeitansicht, in der zum Beispiel die TLS-Terminierung am Messenger-Proxy auf Grund der Übersichtlichkeit nicht berücksichtigt wurde. Die in der Abbildung rot dargestellten Linien symbolisieren den Kommunikationsverlauf des auslösenden Matrix-Request. Für die vereinfachte Darstellung wird vorausgesetzt, dass die TI-M Clients der beteiligten Akteure online sind.

Abbildung 15: Laufzeitsicht - Austausch von Events zwischen Akteuren innerhalb einer Organisation

AF_10061-02 - Einladung von Akteuren außerhalb einer Organisation

In diesem Anwendungsfall wird ein Akteur außerhalb einer Organisation eingeladen. Für die Suche nach Akteuren außerhalb der Organisation KANN das VZD-FHIR-Directory verwendet werden. Ist die MXID des gesuchten Akteurs dort nicht vorhanden, MUSS es die Möglichkeit geben, die Kontaktaufnahme auch auf anderen Wegen zu ermöglichen. Es MUSS mindestens die Kontaktaufnahme mit Hilfe eines QR-Code Scans angeboten werden. Weitere Optionen zur Eingabe der MXID (z. B. manuelle Eingabe) sind zulässig.

Tabelle 12 AF - Einladung von Akteuren außerhalb einer Organisation

AF_10062-02 - Austausch von Events zwischen Akteuren außerhalb einer Organisation

In diesem Anwendungsfall können Akteure, welche sich in einem gemeinsamen Raum befinden, Nachrichten austauschen und weitere in der Matrix-Spezifikation festgelegte Aktionen ausführen. Dieser Anwendungsfall setzt die erfolgreiche Annahme eines Invite-Events durch einen oder mehrere beteiligte Akteure voraus. Die Prüfung auf Domainzugehörigkeit findet bei jedem Event der Server-Server Kommunikation statt. In diesem Anwendungsfall sind die beteiligten Akteure in einem gemeinsamen Chatraum und auf unterschiedlichen Messenger-Services verteilt.

Tabelle 13: AF - Austausch von Events zwischen Akteuren außerhalb einer Organisation 

Abbildung 17: Laufzeitsicht - Austausch von Events zwischen Akteuren außerhalb einer Organisation

AF_10235 - Einträge im VZD-FHIR-Directory suchen

Der Anwendungsfall beschreibt, wie ein Akteur im VZD-FHIR-Directory nach HealthcareService- und PractitionerRole-Ressourcen sucht. Dies setzt eine erfolgreiche Anmeldung des Akteurs an einem Messenger-Service voraus.

Tabelle 14: Einträge im VZD-FHIR-Directory suchen

Abbildung 21 : Laufzeitsicht - Einträge im VZD-FHIR-Directory suchen  

A_25532 - Prüfung Föderationszugehörigkeit

Bei jedem Invite-Event MUSS der Messenger-Proxy prüfen, ob die in der Anfrage enthaltenen Matrix-Domains zur TI-Föderation gehören (siehe Kapitel 5.1.3 Föderationszugehörigkeit prüfen).  [<=]

A_25537 - Aktualisierung Föderationsliste

Kann eine zu prüfende Domain nicht in der Föderationsliste gefunden werden MUSS der Messenger-Proxy bei seinem Registrierungs-Dienst eine neue Version der Föderationsliste abrufen. [<=]

A_25534 - Fehlschlag Föderationsprüfung

Kann nach der Aktualisierung der Föderationsliste die Domain nicht in der Föderationsliste gefunden werden, dann MUSS der Messenger-Proxy die Anfrage mit dem folgenden JSON-Objekt ablehnen:

A_25533 - Server Föderationszugehörigkeit

Bei jedem Event MUSS der Messenger-Proxy die Föderationszugehörigkeit der im Event enthaltenen Matrix-Domains prüfen (siehe Kapitel 5.1.3 Föderationszugehörigkeit prüfen).  [<=]

A_25540 - Server Prüfung eingehende Kommunikation

Bei eingehender Kommunikation MUSS der Messenger-Proxy gemäß [Server-Server API/#request-authentication] die im Authorization-Header Attribut "origin" enthaltene Domain auf Föderationszugehörigkeit prüfen. [<=]

A_25541 - Server Prüfung ausgehende Kommunikation

Bei ausgehender Kommunikation MUSS der Messenger-Proxy gemäß [Server-Server API/#request-authentication] die im Authorization-Header Attribut "destination" enthaltene Domain auf Föderationszugehörigkeit prüfen. [<=]

A_25045 - Funktionsumfang der Berechtigungskonfiguration

Der TI-M Client MUSS für die Konfiguration der Berechtigungskonfiguration folgende Varianten unterstützen:

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

A_26016 - Basiseinstellung vorgeben

Der TI-M Client MUSS ermöglichen, dass ein TI-Messenger-Anbieter die Basiseinstellung der Berechtigungskonfiguration vordefinieren kann.  [<=]

A_25043 - Berechtigungskonfiguration in Accountdaten speichern

Der TI-M Client MUSS die Berechtigungskonfiguration aus den Accountdaten des Matrix-Homeservers [Client-Server API/#client-config] beziehen und Änderungen an der Berechtigungskonfiguration in den Accountdaten des Matrix-Homeservers speichern. [<=]

A_25044 - Namespace für Berechtigungskonfiguration

Der TI-M Client MUSS für die Nutzung der Berechtigungskonfiguration in den Accountdaten des Matrix-Homeservers den Namespace de.gematik.tim.account.permissionconfig.v1 verwenden. [<=]

A_25258 - Schema der Berechtigungskonfiguration

Die Daten der Berechtigungskonfiguration MÜSSEN dem JSON-Schema [api-messenger/src/schema/permissionConfig.json] entsprechen. [<=]

A_26021 - Durchsetzung der Berechtigungskonfiguration - Fachdienst

Der TI-M FD KANN die hinterlegte Berechtigungskonfiguration durchsetzen. [<=]

A_25046 - Durchsetzung der Berechtigungskonfiguration - Client

Der TI-M Client MUSS die hinterlegte Berechtigungskonfiguration durchsetzen, wenn der verwendete Fachdienst die Durchsetzung nicht anbietet. [<=]

A_22965-01 - Push-Benachrichtigungen Messenger-Anbieter

TI-Messenger-Anbieter MÜSSEN sicherstellen, dass Push-Benachrichtigungen erst nach expliziter Zustimmung der Nutzer erfolgen (Opt-In) dürfen. [<=]

A_25033 - Bereitstellung Push Gateway

Für TI-M Clients für mobile Szenarien MUSS ein Push-Gateway bereitgestellt werden, über welches die App mit Push-Benachrichtigungen beliefert wird. [<=]

A_25286 - Push-Gateway API

Das Push-Gateway MUSS für Homeserver eine API gemäß [Push Gateway API] bereitstellen. [<=]

A_25034 - TI-M Fachdienst - Push Notifications Datenschutz

Der TI-M Fachdienst MUSS das Push-Format "event_id_only" beim Anlegen eines Pushers über die [Client-Server API/#push-notifications] durchsetzen. [<=]

A_22808-01 - Push-Benachrichtigungen Timing

Push-Nachrichten MÜSSEN vor dem Versenden um einen Zufallswert von 0-10 Sekunden verzögert werden, um timingbasierte Profilbildung zu erschweren. [<=]

A_25999 - spezifische Custom State Events nur in dafür vorgesehenen Custom Room Types

Der TI-M Client MUSS sicherstellen, dass Custom State Events mit dem Präfix "de.gematik.tim.room" nur in Custom Room Types mit dem Präfix "de.gematik.tim.roomtype" erzeugt werden. [<=]

A_25810 - Endpunkt-Aufrufe in spezifischen Chatroom-Typen

Der TI-M Client MUSS es ermöglichen, dass raumbezogene Endpunkt-Aufrufe, z. B. /_matrix/client/v3/rooms/{roomId}/invite nach der Verwendung von Custom State Events und Räumen mit einem Custom Room Type ohne Einschränkungen erfolgen können. [<=]

A_25820 - Entgegennehmen von spezifischen State Events und Room Types

Der Matrix-Homeserver MUSS die Event Types der folgenden Custom State Events entgegennehmen können, ohne diese auszuwerten, abzuweisen oder auf diese mit einer Fehlermeldung zu reagieren:

• Custom State Events
  
• de.gematik.tim.room.name
• de.gematik.tim.room.topic

A_25821 - Ausschluss von Wechselwirkungen spezifischer State Events mit Room Versions

Die Erzeugung von Custom State Events der Event Types "de.gematik.tim.room.name" und "de.gematik.tim.room.topic" DARF NICHT die Definition einer neuen oder angepassten Matrix Room Version zur Folge haben. Vorhandene Raumdefinitionen MÜSSEN gemäß der Default Room Version der anzuwendenden Matrix-Protokollversion vollständig erhalten bleiben. [<=]

A_25755 - Verwendung eines spezifischen Chatroom-Typen für fallbezogene Kommunikation

Der TI-M Client MUSS den Custom Room Type "de.gematik.tim.roomtype.casereference.v1" für die fallbezogene Kommunikation mit Hilfe eines parametrisierten Aufrufs des /createRoom Endpunktes erzeugen und verwenden. [<=]

A_25756 - Pflichtparameter bei der Chatroom-Erzeugung für fallbezogene Kommunikation

Der Custom Room Type "de.gematik.tim.roomtype.casereference.v1" MUSS über den Aufruf des /createRoom Endpunkts erzeugt werden. Diese Pflichtparameter sind dabei zu verwenden (dargestellt als sortierte hierarchische Liste):

• creation_content
• type: de.gematik.tim.roomtype.casereference.v1
• initial_state (State Event Liste)
• de.gematik.tim.room.casereference.v1 (Custom State Event)
• Event type: de.gematik.tim.room.casereference.v1
  Event state_key: <vom Sender festgelegt>
  Event content: <wird in [simplifier] definiert>
• de.gematik.tim.room.name (Custom State Event)
• <Beschreibung siehe Abschnitt "Basis-Anwendungsfall">
  
• de.gematik.tim.room.topic (Custom State Event)
• <Beschreibung siehe Abschnitt "Basis-Anwendungsfall">
• name
• <leer> (0-Längen-Zeichenkette)
• topic
• <leer> (0-Längen-Zeichenkette)

A_25757 - Verwendung von spezifischen FHIR-Ressourcen im Event Content für fallbezogene Kommunikation

Für die Abbildung der fallbezogenen Kommunikation MÜSSEN spezifische FHIR-Ressourcen im Event Content als JSON-Daten eingetragen werden. Weiterhin MÜSSEN diese FHIR-Ressourcen als FHIR-Bundle zusammengefasst werden. Diese FHIR-Ressourcen MÜSSEN den Profilvorgaben aus dem Simplifier-Projekt [simplifier] entsprechen. [<=]

A_25808 - Erzeugung von spezifischen State Events für fallbezogene Kommunikation

Der TI-M Client MUSS ein Custom State Event mit dem Event Type "de.gematik.tim.room.casereference.v1" in einem Chatroom-Typ des Custom Room Types "de.gematik.tim.roomtype.casereference.v1" erzeugen können. [<=]

A_25809 - Vermeidung bestimmter State Events und Ersatznutzung für fallbezogene Kommunikation

Der TI-M Client MUSS Custom State Events mit den Event Types "de.gematik.tim.room.topic" und "de.gematik.tim.room.name" erzeugen und in "de.gematik.tim.roomtype.casereference.v1" Room Types verwenden können. Dabei MUSS durch den TI-M Client sichergestellt werden, dass die State Events m.room.topic und m.room.name leer sind (0-Längen-Zeichenkette). [<=]

A_25811 - Entgegennehmen von spezifischen State Events und Room Types für die fallbezogene Kommunikation

Der Matrix-Homeserver MUSS die folgenden Custom Room Types sowie die folgenden Event Types der Custom State Events entgegennehmen können, ohne diese auszuwerten, abzuweisen oder auf diese mit einer Fehlermeldung zu reagieren:

• Custom Room Type: de.gematik.tim.roomtype.casereference.v1
• Custom State Event: de.gematik.tim.room.casereference.v1

A_25812 - Ausschluss von Wechselwirkungen spezifischer State Events und Room Types mit Room Versions für die fallbezogene Kommunikation

Die Erzeugung von Chatrooms mit Custom Room Types "de.gematik.tim.roomtype.casereference.v1" sowie von Custom State Events des Event Types "de.gematik.tim.room.casereference.v1" DARF NICHT die Definition einer neuen oder angepassten Matrix Room Version zur Folge haben. Vorhandene Raumdefinitionen gemäß der Default Room Version der anzuwendenden Matrix-Protokollversion aus [Matrix Specification] müssen vollständig erhalten bleiben. [<=]

A_25426 - Verwendung des Chatroom-Typen für föderierte und intersektorale Kommunikation

Der TI-M Client MUSS den Custom Room Type "de.gematik.tim.roomtype.default.v1" für die föderierte und intersektorale Kommunikation mit Hilfe eines parametrisierten Aufrufs des /createRoom Endpunktes erzeugen und verwenden. [<=]

A_25814 - Verwendung des Chatroom-Typen für föderierte und intersektorale Kommunikation als Standard-Chatroom-Typ

Der TI-M Client MUSS den Custom Room Type "de.gematik.tim.roomtype.default.v1" als Default bzw. Standard-Chatroom-Typ verwenden, sofern nicht explizit ein anderer Custom Room Type durch den raumerzeugenden Nutzer ausgewählt wird und sofern mindestens ein weiterer Teilnehmer aus anderen Organisationen bzw. der Föderation eingeladen werden. [<=]

A_25813 - Pflichtparameter bei der Chatroom-Erzeugung für föderierte und intersektorale Kommunikation

Der Custom Room Type "de.gematik.tim.roomtype.default.v1" wird über den Aufruf des /createRoom Endpunkts erzeugt. Diese Pflichtparameter sind dabei zu verwenden (dargestellt als sortierte hierarchische Liste):

• creation_content
• type: de.gematik.tim.roomtype.default.v1
• initial_state (State Event Liste)
• de.gematik.tim.room.default.v1 (Custom State Event)
• Event type: de.gematik.tim.room.default.v1
  Event state_key: <vom Sender festgelegt>
  Event content: <wird in [simplifier] definiert>
• de.gematik.tim.room.name (Custom State Event)
• <Beschreibung siehe Abschnitt "Basis-Anwendungsfall">
  
• de.gematik.tim.room.topic (Custom State Event)
• <Beschreibung siehe Abschnitt "Basis-Anwendungsfall">
• name
• <leer> (0-Längen-Zeichenkette)
• topic
• <leer> (0-Längen-Zeichenkette)

A_25816 - Erzeugung von spezifischen State Events für föderierte und intersektorale Kommunikation

Der TI-M Client MUSS ein Custom State Event mit dem Event Type "de.gematik.tim.room.default.v1" in einem Chatroom-Typ des Custom Room Types "de.gematik.tim.roomtype.default.v1" erzeugen können. [<=]

A_25817 - Vermeidung bestimmter State Events und Ersatznutzung für föderierte und intersektorale Kommunikation

Der TI-M Client MUSS Custom State Events mit den Event Types "de.gematik.tim.room.topic" und "de.gematik.tim.room.name" erzeugen und in "de.gematik.tim.roomtype.default.v1" Room Types verwenden können. Dabei MUSS durch den TI-M Client sichergestellt werden, dass die State Events m.room.topic und m.room.name leer sind (0-Längen-Zeichenkette). [<=]

A_25818 - Entgegennehmen von spezifischen State Events und Room Types für föderierte und intersektorale Kommunikation

Der Matrix-Homeserver MUSS die folgenden Custom Room Types sowie die folgenden Event Types der Custom State Events entgegennehmen können, ohne diese auszuwerten, abzuweisen oder auf diese mit einer Fehlermeldung zu reagieren:

• Custom Room Type: de.gematik.tim.roomtype.default.v1
• Custom State Event: de.gematik.tim.room.default.v1

A_25819 - Ausschluss von Wechselwirkungen spezifischer State Events und Room Types mit Room Versions für föderierte und intersektorale Kommunikation

Die Erzeugung von Chatrooms mit Custom Room Types "de.gematik.tim.roomtype.default.v1" sowie von Custom State Events des Event Types "de.gematik.tim.room.default.v1" DARF NICHT die Definition einer neuen oder angepassten Matrix Room Version zur Folge haben. Vorhandene Raumdefinitionen gemäß der Default Room Version der anzuwendenden Matrix-Protokollversion aus [Matrix Specification] müssen vollständig erhalten bleiben. [<=]