gemSpec_TI-M_Pro_V1.0.0

PDF HTML Excel XML
gemSpec_TI-M_Pro_V1.0.0






Elektronische Gesundheitskarte und Telematikinfrastruktur





Spezifikation

TI-Messenger Pro




    

     

      Version
      1.0.0
     

     

      Revision
      1043255
     

     

      Stand
      13.11.2024
     

     

      Status
      freigegeben
     

     

      Klassifizierung
      öffentlich
     

     

      Referenzierung
      gemSpec_TI-M_Pro

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Version
 Stand
 Kap./ Seite
 Grund der Änderung, besondere Hinweise
 Bearbeitung
1.0.0 13.11.2024 initiale Erstellung gematik

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Zulassung der Produkttypen TI-M Client Pro und TI-M FD Pro. Dieses Dokument erweitert die Basisspezifikation [gemSpec_TI-M_Basis] um die für die genannten Produkttypen notwendigen Anpassungen. Für die Produkte gelten weiterhin die in der Basisspezifikation beschriebenen Funktionalitäten, sofern Sie nicht in diesem Dokument erweitert oder eingeschränkt werden.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller von TI-M Client Pro, an Hersteller von TI-M FD Pro und an Anbieter, welche die beschriebenen Produkttypen betreiben und diese Institutionen des Gesundheitswesens und ihren Akteuren (z. B. Sachbearbeitern bei Kostenträgern, Pflegern in Krankenhäusern, etc.) zur Verfügung stellen.

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, Leistungsbeschreibung) 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 diesem Dokument die vom 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 ).

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten. Diese sind in den Produkttypsteckbriefen der Produkttypen TI-M_Client_Pro und TI-M_FD_Pro verzeichnet.

1.5 Methodik

Anwendungsfälle und Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID, Anforderungen zusätzlich durch die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

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 werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

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

bzw.

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

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

2 Systemüberblick

2.1 Akteure und Rollen

Aufbauend auf der Beschreibung in der Basisspezifikation des TI-Messengers, wird die Liste der Akteure und Rollen für den TI-Messenger Pro um Nutzer im Besitz eines Heilberufsausweises (HBA) sowie automatisierte Systeme, kurz Chatbots, erweitert. Die folgende Tabelle ist eine Ergänzung zur Tabelle aus der Basisspezifikation.

Tabelle 1: Akteure und Rollen

Welcher Akteur bin ich
 Wie authentisiere ich mich
 Welcher Dienst authentifiziert mich
 Welche Rolle nehme ich ein
Chatbot Authentifizierungsverfahren der Organisation
 Messenger-Service User
Nutzer des TI-Messengers mit Heilberufsausweis (HBA)
 HBA zentraler IDP-Dienst User-HBA

Im Folgenden werden die neuen bzw. erweiterten Akteure und Rollen beschrieben. Das alle Rollen und Akteure betreffende User Management wird in Kapitel 5.4 Management von Akteuren und Rollen behandelt.

2.1.1 Akteur: Chatbot

Chatbots können ebenso wie natürliche Personen Teilnehmer von Chaträumen sein, in welchen sie dann bestimmte Funktionen (z. B. Archivierung) übernehmen. Zu diesem Zweck müssen sie sich gleichermaßen authentisieren.

Chatbots, die als Teilnehmer in einem Chatraum auftreten, sind so wie menschliche Akteure an ihrem jeweiligen Client durch eine kryptographische Identität und das verwendete "Gerät" (Device) gekennzeichnet, auf deren Grundlage Ende-zu-Ende-Verschlüsselung und Authentizitätsprüfung stattfinden.

2.1.2 Rolle: "Org-Admin"

Der Org-Admin im Kontext von TI-M Pro erhält zusätzlich die Fähigkeit Einträge im VZD-FHIR-Directory für seine Organisation zu verwalten.

2.1.3 Rolle: "User-HBA"

Der TI-M Pro führt die Rolle "User-HBA" ein auf Grundlage der Rolle "User" gemäß [gemSpec_TI-M_Basis]. Einem Akteur in der Rolle "User-HBA" stehen somit die gleichen Funktionalitäten wie einem Akteur in der Rolle "User" zur Verfügung. Zusätzlich kann der Akteur diese Rolle einnehmen, wenn er sich mit seinem Heilberufsausweis (HBA) gegenüber dem zentralen IDP-Dienst der gematik authentisiert. In dieser Rolle stehen dem Akteur zusätzliche Funktionen zur Verfügung, die im Anwendungsfall 5.1.2 Akteur (User-HBA) im Verzeichnisdienst hinzufügen beschrieben werden.

2.2 Nachbarsysteme

2.2.1 VZD-FHIR-Directory

Beim VZD-FHIR-Directory gibt es gegenüber der Basisspezifikation die folgenden Anpassungen.

  • Nach der Authentisierung wird für die Akteure in der Rolle "User" ein individueller search-accesstoken bereitgestellt.
  • Für die Suche der Akteure in der Rolle wurde ein eigener Endpunkt bereitgestellt
  • Für die Authentisierung der Akteure in der Rolle "User-HBA" und in der Rolle "Org-Admin" wird ein eigener Authentisierungsendpunkt /owner-authenticate bereitgestellt.

2.3 Zugriffstoken

Für die Nutzung des TI-Messengers kommen unterschiedliche Arten von Token zur Authentisierung und Autorisierung an weiteren Diensten zum Einsatz, die in verschiedenen Anwendungsfällen verwendet werden. Die folgende Tabelle listet die für den TI-M Pro neu hinzukommenden Token und beschreibt ihre Verwendung. Die folgende Tabelle ist eine Ergänzung zur Tabelle aus der Basisspezifikation.

Tabelle 2: Arten von Token

Token ausgestellt vom
 Beschreibung
RegService-OpenID-Token Registrierungs-Dienst Bei dem RegService-OpenID-Token handelt es sich um ein JSON-Web-Token, welches von einem Registrierungs-Dienst bei Bedarf für einen Akteur in der Rolle "Org-Admin" ausgestellt wird.

Das RegService-OpenID-Token wird für die Bearbeitung der FHIR-Ressourcen im VZD-FHIR-Directory benötigt. Hierfür wird das RegService-OpenID-Token im Auth-Service des Verzeichnisdienstes gegen ein owner-accesstoken ersetzt, welches am FHIR-Proxy für die weitere Verarbeitung benötigt wird.
owner-accesstoken Auth-Service des VZD-FHIR-Directory Das owner-accesstoken wird einem berechtigten Akteur durch den Auth-Service das VZD-FHIR-Directory bereitgestellt. Das Token beinhaltet u.a. die Telematik-ID der FHIR-Ressource, für die der Akteur die Rechte zur Verwaltung erhält. Mit dem owner-accesstoken können die entsprechenden Endpunkte zur Bearbeitung der FHIR-Ressource aufgerufen werden.

3 Zerlegung des Produkttyps

3.1 TI-M Client Pro

3.1.1 Ausprägungen nach Nutzergruppen

3.1.1.1 TI-M Client Pro für Akteure in der Rolle "Org-Admin" (Org-Admin-Client)

Der Org-Admin-Client für TI-M Pro erhält zusätzlich die Funktionalität im Namen der Organisation FHIR-Ressourcen im VZD-FHIR-Directory hinzuzufügen/zu verwalten (siehe 5.1.1 Organisationsressourcen im Verzeichnisdienst hinzufügen). Für die Authentisierung kann der Org-Admin ein Token vom Registrierungsdienst verwenden, welches im Kapitel 3.2.1.1 I_requestToken beschrieben wird.

3.1.2 Ausprägungen nach Plattform

Der TI-M Client Pro kann auch als Web-Anwendung zur Nutzung in einem Browser zur Verfügung gestellt werden. Für diese Ausprägung gelten die im folgenden Kapitel gesondert aufgeführten Anforderungen.

3.1.2.1 TI-M Client als Web-Anwendung

A_25507 - Abmeldung statt Sperre bei Web-Clients

Ein browserbasierter TI-M Client Pro MUSS anstelle einer App-Sperre über eine Funktion zur automatischen Abmeldung verfügen, die nach einer bestimmten Zeit der Inaktivität ausgelöst wird. [<=]

A_25508 - Dauer der Inaktivität für automatische Abmeldung

Die Dauer der Inaktivität, nach der ein browserbasierter TI-M Client Pro automatisch abmeldet, MUSS durch den Akteur konfigurierbar und standardmäßig auf eine Stunde eingestellt sein. [<=]

A_26282 - Automatische Abmeldung bei geschlossenem Client

Die automatische Abmeldung des browserbasierten TI-M Client Pro MUSS auch dann wirksam sein, wenn der Client zum Zeitpunkt der Auslösung nicht geöffnet ist. [<=]

A_25536 - Abschottung von Inhalten in Web-Clients

Web-Clients MÜSSEN sicherstellen, dass sensible Daten im Browser (z. B. OLM-Keys, ACCESS_TOKEN) nicht durch andere Anwendungen, die ebenfalls im Browser ausgeführt werden, ausgelesen werden können. [<=]

3.1.3 Matrix Spezifikation

3.1.3.1 Weitere Ergänzungen/Einschränkungen zur Matrix-Spezifikation

A_25325 - Öffentliche Räume Client

Der TI-M Client Pro MUSS das Anlegen von öffentlichen Räumen durch den Akteur unterstützen. [<=]

Hinweis: Der TI-M Client Pro kann dem Akteur erlauben, die Verschlüsselung beim Anlegen eines öffentlichen Raumes zu deaktivieren.

A_26347 - Hinweis vor Einladung weiterer Chatteilnehmer

Der TI-M Client Pro SOLL dem Nutzer vor Einladung weiterer Teilnehmer in einen Raum einen Hinweis anzeigen, der darauf hinweist, dass nur entsprechend legitimierte Nutzer (bspw. bei Versicherten deren Stellvertreter) eingeladen werden dürfen. [<=]

3.1.4 VZD-FHIR-Directory

A_26172-01 - Schnittstelle für die VZD-FHIR-Directory Suche

Der TI-M Client Pro MUSS für die Suche im VZD-FHIR-Directory die Schnittstelle /search verwenden. [<=]

3.1.4.1 Schreibzugriff

Für den Schreibzugriff nutzen TI-M Clients Pro ein owner-accesstoken, welches vom Auth-Service des VZD-FHIR-Directory ausgestellt wurde. Um ein gültiges owner-accesstoken zu erhalten, muss ein Akteur in der Rolle "User-HBA" sich mit seinem HBA gegenüber dem zentralen IDP-Dienst der gematik authentisieren.

Eine Besonderheit bietet sich dem Akteur in der Rolle "Org-Admin", da dieser sich bei der Registrierung seiner Organisation bereits mit der SM(C)-B der Organisation authentisiert hat und somit die Möglichkeit bekommt, beim zuständigen Registrierungs-Dienst einen RegService-OpenID-Token anzufragen, welcher anschließend am /owner-authenticate Endpunkt gegen ein owner-accesstoken eingetauscht werden kann.

Durch den Aufruf der Schnittstelle /owner am FHIR-Proxy des VZD-FHIR-Directory erhält ein Akteur unter Vorlage des owner-accesstoken Schreibzugriffe auf das FHIR-Directory. In der folgenden Tabelle wird die zu verändernde FHIR-Ressource in Abhängigkeit zu der verwendeten Identität eines Akteurs beschrieben.

Tabelle 3: Schreibzugriff - VZD-FHIR-Ressourcen

Rolle Identität FHIR-Ressource Beschreibung
Org-Admin SM(C)-B (stellvertretend durch einen RegService-OpenID-Token)
 HealthcareService
 Ein Akteur in der Rolle "Org-Admin" kann mit Hilfe des Org-Admin Clients und nach Authentisierung mit einem RegService-OpenID-Token, FHIR-Ressourcen im Namen der Organisation im Organisationsverzeichnis des VZD-FHIR-Directory bearbeiten, um zum Beispiel einen neuen Endpunkt unterhalb eines HealthcareService zu hinterlegen. Das RegService-OpenID-Token erhält der Akteur in der Rolle "Org-Admin" nach erfolgreicher Anmeldung am Registrierungs-Dienst durch Aufruf der vom Anbieter bereitgestellten Schnittstelle  I_requestToken.
User-HBA HBA PractitionerRole Ein Akteur in der Rolle "User-HBA" kann, nachdem er sich mit seinem HBA gegenüber dem zentralen IDP-Dienst der gematik authentisiert hat,
das Attribut PractitionerRole.endpoint modifizieren, um dort die eigene Erreichbarkeit über TI-M (connectionType Code = "tim") inkl. MXID sowie Informationen zur eigenen Sichtbarkeit zu hinterlegen.

3.1.5 Sichtbarkeit

Akteure in der Rolle "User-HBA" können die Sichtbarkeit ihrer hinterlegten Informationen an einem Endpoint im VZD-FHIR Directory für Akteure in der Rolle "Versicherter"1 konfigurieren (siehe AF_10376 - Practitioner - FHIR-VZD Sichtbarkeit für Versicherte setzen). Akteure in der Rolle "Org-Admin" können die gleichen Einstellungen für die Endpoints vornehmen, die sie stellvertretend für ihre Organisation verwalten (siehe AF_10377 - Organization - FHIR-VZD Sichtbarkeit für Versicherte setzen).

1 Rolle "Versicherter" definiert in [gemSpec_TI-M_ePA]

3.2 TI-M FD Pro

3.2.1 Registrierungs-Dienst

Der Registrierungs-Dienst darf Akteuren in der Rolle "Org-Admin" einen RegService-OpenID-Token ausstellen, welcher die Telematik-ID der SM(C)-B enthält, die bei der Anlage des Org-Admin Accounts verwendet wurde. Dieses Token kann der Org-Admin-Client anschließend beim VZD-FHIR-Directory gegen ein owner-accesstoken eintauschen, um Zugriff auf die eigenen Ressourcen im VZD-FHIR-Directory zu erlangen.

3.2.1.1 I_requestToken

Über die Schnittstelle I_requestToken stellt der Registrierungs-Dienst RegService-OpenID-Token aus. Das Token wird für die Authentifizierung am FHIR-Proxy des VZD-FHIR-Directory benötigt, damit ein Akteur in der Rolle "Org-Admin" Organisationseinträge ändern kann. Die Ausgestaltung der Schnittstelle am Registrierungs-Dienst (I_requestToken) ist dem jeweiligen TI-Messenger-Anbieter überlassen. Das Token muss signiert werden, damit das VZD-FHIR-Directory dem Aussteller vertraut. Hierzu ist ein Zertifikat über einen TI-ITSM Service Request zu beantragen, welches im Anschluss für die Signatur genutzt werden kann.

A_25566 - I_requestToken

Der TI-M Fachdienst Pro MUSS die Schnittstelle I_requestToken für die Ausstellung eines ID_TOKENS (RegService-OpenID-Token) am Registrierungs-Dienst bereitstellen. [<=]

A_25567 - Authentifizierte Akteure

Der Registrierungs-Dienst MUSS sicherstellen, dass nur für authentifizierte Akteure in der Rolle "Org-Admin" ein RegService-OpenID-Token ausgestellt wird. [<=]

A_25572 - Zertifikatsablauf

Bevor das Signaturzertifikat für den RegService-OpenID-Token abläuft, MUSS vom TI-Messenger-Anbieter ein neues beantragt werden und das neue Signaturzertifikat an das VZD-FHIR-Directory übermittelt werden. [<=]

3.2.1.1.1 RegService-OpenID-Token

A_25564 - Aufbau des RegService-OpenID-Token

Das RegService-OpenID-Token ist ein JSON-Web-Token und MUSS folgende Attribute enthalten:

HEADER
{
  "alg": "BP256R1",
  "typ": "JWT"
 
  "x5c": [
 "<X.509 Sig-Cert, base64-encoded DER>" ]
}
PAYLOAD
{
  "sub": "1234567890",
  "iss": "<URL des Registrierungs-Dienst-Endpunkts, über den das Token ausgestellt wurde>",
  "aud": "<URL des owner-authenticate-Endpunkts am VZD-FHIR-Directory>",
  "professionOID": "<ProfessionOID der Organisation>",
 
  "idNummer": "<TelematikID der Organisation>",

  "iat": "1516239022",

  "exp": "1516242622"
}
[<=]

A_25571 - Signatur RegService-OpenID-Token

Für die Signatur des RegService-OpenID-Token MUSS der private Schlüssel des Signaturzertifikats C.FD.SIG verwendet werden. [<=]

A_25568 - Gültigkeitsdauer RegService-OpenID-Token

Die Gültigkeitsdauer des RegService-OpenID-Tokens DARF NICHT mehr als eine Stunde betragen. [<=]

3.2.2 Messenger-Service

Damit ein Akteur in der Rolle "User" den TI-M Client Pro nutzen kann, um die MXID eines Versicherten mit Hilfe von vorliegenden Stammdaten (KVNR und IK-Nummer) herzuleiten, ist es notwendig aus einer IK-Nummer den zugehörigen Servernamen abzuleiten.

Zur Durchsetzung des Berechtigungskonzeptes im Client ist es zusätzlich nötig für eine gegebene MXID festzustellen ob es sich um einen Versicherten handelt oder nicht. Hierfür muss der zugehörige Homeserver gegen die Föderationsliste abgeglichen werden.

Die oben genannten Operationen werden durch die Schnittstelle [api-messenger/src/openapi/TiMessengerInformation.yaml] am Messenger-Proxy bereitgestellt.

A_26445 - TiMessengerInformation Schnittstelle

Der Messenger-Proxy Pro MUSS eine Schnittstelle auf Basis von [api-messenger/src/openapi/TiMessengerInformation.yaml] implementieren. [<=]

3.2.3 Matrix Spezifikation

3.2.3.1 Weitere Ergänzungen/Einschränkungen zur Matrix-Spezifikation

A_26515 - Öffentliche Räume beitreten

Der TI-M FD MUSS sicherstellen, dass nur Nutzer dem öffentlichen Raum beitreten können, die ihren Account auf demselben Homeserver haben auf dem der öffentliche Raum erstellt wurde. [<=]

A_26518 - Öffentliche Räume Client-API Auth

Der TI-M FD MUSS Requests zu den Endpunkten

  • /_matrix/client/v3/directory/list/room/{roomId}¹
  • /_matrix/client/v3/publicRooms2
nur authentifizierten Akteuren erlauben.
¹ [Client-Server API/#get_matrixclientv3directorylistroomroomid]
2 [Client-Server API/#get_matrixclientv3publicrooms] [<=]

Hinweis: Erfolgt ein Zugriff von einem unauthentifizierten Akteur soll sich der Fachdienst wie bei allen anderen Endpunkten der Client-Server-API verhalten. [Client-Server-API/#using-access-tokens]

A_26520 - Öffentliche Räume Server-API

Der TI-M FD MUSS Requests zum Endpunkt /_matrix/federation/v1/publicRooms mit einer HTTP 403 Response ablehnen. [<=]

4 Übergreifende Festlegungen

4.1 Datenschutz und Sicherheit

Zur Sicherstellung des Datenschutzes und der Sicherheit im Rahmen des TI-Messenger-Dienstes werden im Folgenden zu erfüllende Anforderungen an den TI-Messenger-Fachdienst und den TI-Messenger-Client, beziehungsweise deren Hersteller und Anbieter beschrieben. Anforderungen, die durch andere Systemkomponenten zu erfüllen sind, werden hier nicht aufgeführt.

Hinweis: Clients und Server im Sinne der folgenden Anforderung sind alle Komponenten des TI-Messenger-Dienstes, die miteinander kommunizieren, wobei der Client der Initiator einer Verbindung zu einem Server ist, der eine Ressource zur Verfügung stellt. Wenn TI-Messenger-Clients und TI-Messenger-Fachdienste gemeint sind, werden diese auch explizit als TI-Messenger-Clients und TI-Messenger-Fachdienste bezeichnet.

A_25544 - Nutzung des TI-Messenger-Clients durch Drittsysteme

Um eine nahtlose Integration in z.B. Primär- (PVS, ZPVS, KIS, AVS etc.) oder Archivsysteme zu ermöglichen, KANN der TI-M Client Pro eine Schnittstelle zum Zugriff auf Daten durch Drittsysteme anbieten. [<=]

A_25545 - Information über Nutzung des TI-Messenger-Clients durch Drittsysteme

Bietet der TI-M Client Pro eine Schnittstelle zur Nutzung durch Drittsysteme, z.B. Primär- (PVS, ZPVS, KIS, AVS etc.) oder Archivsysteme an, MUSS er sicherstellen, dass Akteure bei Verwendung einer solchen Funktion geeignet darüber informiert werden, dass sie Daten aus dem geschützten Bereich des Clients hinausbewegen. Geeignet bedeutet dabei, dass darüber zumindest einmalig informiert wird, welche Daten in welches Drittsystem weitergeleitet werden.  [<=]

A_25509 - Verhinderung von Bildschirmaufnahmen

Der TI-M Client Pro für mobile Szenarien MUSS die Anfertigung von Bildschirmaufnahmen standardmäßig verhindern. [<=]

Hinweis:  Der Client kann die Anfertigung von Bildschirmaufnahmen nach Konfiguration durch den Akteur erlauben.

A_25510 - Warnung vor mangelndem Schutz von Bildschirmaufnahmen

Wurde die Verhinderung von Bildschirmaufnahmen durch den Akteur deaktiviert, so MUSS der TI-M Client Pro für mobile Szenarien den Akteur bei Anfertigung von Bildschirmaufnahmen darüber informieren, dass diese nicht durch den Client geschützt sind und sich daraus Risiken ergeben können. [<=]

A_25506 - Nachnutzung der Sperre übergeordneter Systeme

Der TI-M-Client Pro KANN eine vorhandene Sperre des übergeordneten Systems nachnutzen, um auf eine eigene App-Sperre zu verzichten. Im Fall von eigenständigen Clients kann dies eine Sperre des Betriebssystems sein, bei integrierten Clients die von KIS, PVS, AVS und ähnlichen. [<=]

A_25505 - Prüfung auf konforme Sperre des übergeordneten Systems

Wird der TI-M Client, der kein Web-Client ist, ohne aktive App-Sperre verwendet, MUSS er regelmäßig und wenigstens beim Öffnen prüfen, ob eine konforme Sperre im übergeordneten System (z.B. Betriebssystem, KIS, PVS, AVS etc.) aktiviert ist und bei negativem Prüfergebnis eine dedizierte App-Sperre aktivieren. [<=]

4.2 Betrieb

Im Betrieb verantwortet ein Anbieter des TI-Messengers das Produkt:

  • TI-M Fachdienst Pro
  • TI-Messenger Client für Akteure (inkl. Org-Admin)

A_26397 - TI-Messenger Anbieter - Produktverantwortung (Pro)

Jeder Anbieter eines TI-Messenger Fachdienstes Pro, MUSS für Organisationen, die einen Messenger-Service vom Anbieter erhalten, sowohl den TI-M Client für Akteure in der Rolle "User" als auch den TI-M Client für Akteure in der Rolle "Org-Admin" (Org-Admin-Client) anbieten. [<=]

Abbildung 1: Betriebsmodell TI-M Pro

Hinweis zur Abbildung: Die Abbildung bildet die organisatorischen Kommunikationsbeziehungen aus Sicht des TI-ITSM-Systems zwischen den jeweiligen Entitäten/Anbieterrollen ab.

A_26420 - Performance - Bestandsdaten - Spezifika TIM Fachdienst

Der TI-Messenger Fachdienst MUSS die nachfolgenden Informationen als Bestandsdaten täglich in folgendem JSON Format gemäß [gemSpec_SST_LD_BD] liefern:

{
  "abfragezeitpunkt": < Zeitangabe als String gemäß ISO 8601 unter expliziter Angabe einer Zeitzone, z.B. YYYY-MM-DDTHH:mm:ss[.fff]Z, als String >,
  "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,
    "TIM.UC_10036-01_01": $anzahl,
    "TIM.UC_10036-01_02": $anzahl,
    "TIM.UC_10059-02_01": $anzahl,
    "TIM.UC_10059-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.
* Hinweis: Die Kennung dient in erster Linie dem Anbieter zur Differenzierung der Clients im anbieterübergreifenden Betrieb falls der TI-M Client (als zugelassenes Produkt) selbst keine unterschiedliche Kennung (client_id) aufweist. [<=]

A_26278 - Performance - Betriebsdatenlieferung v2 - Spezifika TIM Fachdienst - Message

Das Produkt MUSS bei Betriebsdatenlieferungen im "message"-Feld folgende Informationen im JSON-Format übermitteln:

{ "afid": "$afid", "md": "$md", "uaKen": "$uaKen", "sizeInKb": $sizein_kb, "sizeOutKb": $sizeout_kb, "telid": "$telid", "proid": "$proid", "res": "$res" }

  • $afid: Datentyp String, SHA1 (Base64-kodiert). Für $afid MUSS der kodierte Wert nach SHA1 einer ID welche pro Aufruf eines Anwendungsfalls gemäß [gemSpec_TI-M_Basis] vergeben wird und zwischen den Teilschritten eines Anwendungsfalls gleich bleibt, ähnlich einer Session-ID, einzutragen. Die Instanz-ID SOLL somit für die jeweiligen Teilschritte innerhalb der Session eines Anwendungsfalls gleich vergeben werden. Die vergebene ID soll SHA1 kodiert übermittelt werden. "Instanz" bezieht sich hierbei auf die Instanziierung des Anwendungsfalls, nicht die physische Instanz des Messenger-Services o.ä.
  • $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. 
  • $uaKen: Datentyp String, SHA1 (Base64-kodiert). Für $uaKen MUSS die mit SHA1 kodierte Kennung einer bestimmten Client-Ausprägung in Synchronisation mit A_25823-* bzw. A_26420-* eingetragen werden. Die Kennung MUSS eindeutig für jede einzigartige Kombination der User-Agent Attribute vergeben und nachgenutzt werden. Für Messpunkte zwischen den Fachdiensten MUSS der Wert "FD_FD" eingetragen werden.
  • $sizeInKb: Datentyp unsigned Integer. Für $sizeInKb MUSS das eingehende übertragene Datenvolumen in Kilobyte als Integer eingetragen werden. Der Messpunkt beim TI-Messenger-Fachdienst ist dabei der Messenger-Proxy.
  • $sizeOutKb: Datentyp unsigned Integer. Für $sizeOutKb MUSS das ausgehende übertragene Datenvolumen in Kilobyte als Integer eingetragen werden. Der Messpunkt beim TI-Messenger-Fachdienst ist dabei der Messenger-Proxy.
  • $telid: Datentyp String. Für $telid MUSS die telematikID der zur Domäne zugehörigen SMC-B eingetragen werden.
  • $proid: Datentyp String. Für $proid MUSS die professionOID der zugehörigen SMC-B eingetragen.
  • $res: Datentyp String. Für $res MUSS der Statuscode als Rückmeldung der entsprechenden Anwendungsfälle im Einklang mit A_22500-* eingetragen werden.
Bei der Erstellung des message-Feldes ist darauf zu achten, dass weder Whitespaces noch Newlines zwischen JSON-Elementen enthalten sind (kein Indenting) und Vorgaben nach [RFC7493] eingehalten werden. [<=]

A_24464 - Performance - Betriebsdatenlieferung v2 - Spezifika TIM Fachdienst - Umfang

Der Produkttyp TI-Messenger Fachdienst MUSS für folgende Teilschritte von Anwendungsfällen AUSSCHLIEßLICH Operationen mit dem HTTP-Statuscode 5xx übermitteln:

  • TIM.UC_10104-03_01
  • TIM.UC_10104-03_02
  • TIM.UC_10063-01_01
  • TIM.UC_10061-03_01
  • TIM.UC_10061-03_02
  • TIM.UC_10062-03_01
  • TIM.UC_10062-03_02
  • TIM.UC_10036-01_01
  • TIM.UC_10036-01_02
Hinweis:
Somit sollen für diese Anwendungsfälle bzw. ihre Teilschritte ausschließlich serverseitige Fehler in den Rohdaten übermittelt werden. Operationen mit 5xx und anderen HTTP-Statuscodes sollen weiterhin gezählt und in den Bestandsdaten kumuliert berichtet werden.
[<=]

A_26422 - Performance - Betriebsdatenlieferung v2 - Spezifika TIM Fachdienst - Duration

Der Produkttyp TI-Messenger Fachdienst MUSS bei Betriebsdatenlieferungen die Inhalte des Feldes "duration_in_ms" nach den Vorgaben der Tabelle "Berichtsformat_TI-Messenger-Fachdienst" entsprechend der Spalten "Start der Messung" und "Ende der Messung" für die jeweilige TIM-Operation befüllen. [<=]

A_26423 - Performance - Betriebsdatenlieferung v2 - Spezifika TIM Fachdienst - Operation

Der Produkttyp TI-Messenger Fachdienst MUSS bei Betriebsdatenlieferungen bzgl. des Feldes "operation" gemäß A_21981-02, die Angabe entsprechend der Spalte "$TIM-Operation" aus Tabelle "Berichtsformat_TI-Messenger-Fachdienst" befüllen. [<=]

Tabelle 4: Berichtsformat_TI-Messenger-Fachdienst

$TIM-Operation
(Referenz Use Case / Anwendungsfall)
 Beschreibung Start der Messung
 Ende der Messung
TIM.UC_10103-02a_01 AF - Authentisieren einer Organisation (OIDC):
Redirect to IdP
 2 POST I_Registration 4 Redirect to IDP Authorization Endpoint
TIM.UC_10103-02a_02 AF - Authentisieren einer Organisation (OIDC):
Authentisierung über IDP
 13 Post I_Registration (auth code) 30 Status
TIM.UC_10103-02b_01 AF - Authentisieren einer Organisation (KIM):
KIM Adresse angeben
 18 POST I_Registration
(Eingabe KIM-Adresse)
 22 KIM Nachricht mit URL
TIM.UC_10103-02b_02 AF - Authentisieren einer Organisation (KIM):
KIM Authentisierung
 23 URL in KIM-Nachricht öffnen 30 Status
TIM.UC_10103-02_03 AF - Authentisieren einer Organisation:
Admin Account anlegen
 33 POST I_Registration (Admin-Account Credentials + 2. Faktor) 36 Status
TIM.UC_10060-02_01 AF - Bereitstellung eines Messenger-Service für eine Organisation:
Admin Login
 2 POST /login (Client-Credentials) 4 status
TIM.UC_10060-02_02 AF - Bereitstellung eines Messenger-Service für eine Organisation:
Messenger Service erstellen
 7 POST /create (Matrix-Domain) 25 status
TIM.UC_10057-01_01 AF - Anmeldung eines Akteurs am Messenger-Service:
Auswahl Auth-Verfahren und client_id
 2 GET /_matrix/client/login 5 HTTP(S) Forward
TIM.UC_10057-01_02 AF - Anmeldung eines Akteurs am Messenger-Service:
Anmeldung, Matrix-ACCESS_TOKEN an Client
 9 POST /_matrix/client/login 17 HTTP(S) Forward
TIM.UC_AF_10059-02_01 AF - Organisationsressourcen im Verzeichnisdienst hinzufügen:
Login
 4 Login mit Client-Credentials + 2. Faktor 6 status
TIM.UC_AF_10059-02_02
 AF - Organisationsressourcen im Verzeichnisdienst hinzufügen:
RegService-OpenID-Token		 8 RegService-OpenID-Token anfragen (z.B. GET /regserv/request_Token) 10 RegService-OpenID-Token {telematikID, professionOID, Signaturzertifikat (x5c)}
TIM.UC_10104-03_01 AF - Einladung von Akteuren innerhalb einer Organisation:
Akteur suchen
 2 POST /_matrix/client/user_directory/search 6 HTTP(S) Forward
TIM.UC_10104-03_02 AF - Einladung von Akteuren innerhalb einer Organisation:
Akteur einladen
 8 POST /_matrix/client/v3/rooms/{roomId}/invite (roomId) 12 HTTP(S) Forward 200
TIM.UC_10063-01_01 AF - Austausch von Events zwischen Akteuren innerhalb einer Organisation:
Matrix-Request
 2 Matrix-Request 6 HTTP(S) Forward
TIM.UC_10061-03_01 AF - Einladung von Akteuren außerhalb einer Organisation:
Einladung Sendersystem
 1 POST /_matrix/client/r0/rooms/{roomsId}/invite 20 "Nutzer in den Raum eingeladen"
TIM.UC_10061-03_02 AF - Einladung von Akteuren außerhalb einer Organisation:
Einladung Empfangssystem
 7 HTTP(S) Forward 17 HTTP(S) Forward
TIM.UC_10062-03_01 AF - Austausch von Events zwischen Akteuren außerhalb einer Organisation:
Event Sendersystem
 2 Matrix-Request 6 Status
TIM.UC_10062-03_02 AF - Austausch von Events zwischen Akteuren außerhalb einer Organisation:
Event Empfangssystem(e)
 9 HTTP(S) Forward 16 HTTP(S) Forward
TIM.UC_10036-01_01 TI-Messenger-Nutzer sucht Einträge im FHIR-Directory
(Client-Anfrage am TIM-FD)
 3 POST /_matrix/client/r0/user/{userId}/openid/request_roken 4 HTTP Response
TIM.UC_10036-01_02 TI-Messenger-Nutzer sucht Einträge im FHIR-Directory
(Token Validierung von FHIR-VZD)
 8 GET matrix.service-ti.de:{PORT}/_matrix/federation/v1/openid/userinfo?access_token=... 9 HTTP Response

Hinweis: Für die gelb-markierten Anwendungsfälle sollen entsprechend A_24464-* nur die Fehlerfälle in den Rohdaten übertragen werden (siehe A_24464).

5 Funktionsmerkmale

5.1 Anwendungsfälle

5.1.1 Organisationsressourcen im Verzeichnisdienst hinzufügen

AF_10059-02 - Organisationsressourcen im Verzeichnisdienst hinzufügen

Mit diesem Anwendungsfall macht ein Akteur in der Rolle "Org-Admin" Akteure seiner Organisation im TI-M Dienst für andere Akteure auffindbar und erreichbar. Dafür werden Endpoint-Ressourcen mit ihrer jeweiligen MXID im Organisationsverzeichnis (HealthcareService) des VZD-FHIR-Directory hinterlegt. Organisationen können mehrere FHIR-Ressourcen administrieren und somit eingehende Kommunikationsprozesse organisatorisch und thematisch strukturieren (siehe [gemSpec_VZD_FHIR_Directory]).

Tabelle 5: AF - Organisationsressourcen im Verzeichnisdienst hinzufügen

AF_10059 Organisationsressourcen im Verzeichnisdienst hinzufügen
Akteur  Beauftragter Mitarbeiter einer Organisation in der Rolle "Org-Admin"
Auslöser Der Akteur in der Rolle "Org-Admin" möchte seine Organisation erreichbar machen, indem die MXIDs der Akteure der Organisation im VZD-FHIR-Directory hinterlegt werden.
Komponenten
  • Org-Admin-Client
  • TI-Messenger Registrierungs-Dienst
  • Auth-Service
  • FHIR-Proxy
  • FHIR-Directory
Vorbedingungen
  1. Für die Organisation wurde ein Messenger-Service bereitgestellt und es existiert ein Eintrag der Organisation im FHIR-Directory.
  2. Der Administrator der Organisation verfügt über einen Org-Admin-Client
  3. Es existiert eine Vertrauensbeziehung zwischen dem Registrierungs-Dienst und dem VZD-FHIR-Directory (Übergabe des Zertifikates).
  4. Der Administrator der Organisation wurde vom Registrierungs-Dienst authentifiziert.
Eingangsdaten Org-Admin-Credentials, FHIR-Organisations-Ressourcen
Ergebnis FHIR-Organisations-Ressourcen aktualisiert, Status
Ausgangsdaten Aktualisierte VZD-FHIR-Directory-Datensätze 

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 FHIR-Proxy auf Grund der Übersichtlichkeit nicht berücksichtigt wurde.


Abbildung 2: Laufzeitsicht - Organisationsressourcen im Verzeichnisdienst hinzufügen 

[<=]

5.1.2 Akteur (User-HBA) im Verzeichnisdienst hinzufügen

AF_10058-02 - Akteur (User-HBA) im Verzeichnisdienst hinzufügen

Mit diesem Anwendungsfall wird ein Akteur in der Rolle "User-HBA" für Akteure anderer Messenger-Services auffindbar und erreichbar gemacht. Dafür werden FHIR-Ressourcen mit ihrer jeweiligen MXID des Akteurs im Personenverzeichnis (PractitionerRole) des VZD-FHIR-Directory hinterlegt. Um diesen Anwendungsfall ausführen zu können ist der Besitz eines HBA notwendig.

Tabelle 6: AF - Akteur (User-HBA) im Verzeichnisdienst hinzufügen

AF_10058 Akteur (User-HBA) im Verzeichnisdienst hinzufügen
Akteur  Akteur in der Rolle "User-HBA"
Auslöser Ein Akteur in der Rolle "User-HBA" möchte sich im Personenverzeichnis erreichbar machen, indem er seine MXID in seinen Practitioner-Datensatz im VZD-FHIR-Directory hinterlegt.
Komponenten
  • TI-Messenger-Client
  • Authenticator
  • zentraler IDP-Dienst
  • FHIR-Proxy
  • Auth-Service
  • FHIR-Directory
Vorbedingungen
  1. Der Akteur ist bei einem gültigen Messenger-Service angemeldet.
  2. Der Akteur verfügt über einen zugelassenen TI-Messenger-Client.
  3. Das VZD-FHIR-Directory ist beim zentralen IDP-Dienst registriert.
  4. Der Akteur kann sich mit dem HBA am zentralen IDP-Dienst authentisieren.
Eingangsdaten HBA, FHIR-Practitioner-Ressourcen
Ergebnis FHIR-Practitioner-Ressourcen aktualisiert, Status
Ausgangsdaten aktualisierter Practitioner-Datensatz

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 FHIR-Proxy auf Grund der Übersichtlichkeit nicht berücksichtigt wurde. Darüber hinaus kann bei Nutzung NFC-fähiger HBAs und Endgeräte die Signatur der IDP Challenge auch ohne Konnektor direkt im Endgerät implementiert werden.

Abbildung 3: Laufzeitsicht - Akteur (User-HBA) im Verzeichnisdienst hinzufügen

[<=]

5.1.3 FHIR-VZD Sichtbarkeit für Versicherte setzen

AF_10376 - Practitioner - FHIR-VZD Sichtbarkeit für Versicherte setzen

Mit diesem Anwendungsfall kann ein Akteur in der Rolle "User-HBA" die Sichtbarkeit seiner Endpoint Einträge im VZD-FHIR-Directory verwalten. Möchte der Akteur verhindern, dass Akteure in der Rolle "Versicherter" seine MXID über die Suche finden können, dann kann er dies am Endpunkt konfigurieren oder im umgekehrten Fall wieder zurücknehmen. 

Tabelle 7: Practitioner - FHIR-VZD Sichtbarkeit für Versicherte setzen

Attribute Bemerkung
Akteur Akteur in der Rolle "User-HBA"
Auslöser Ein Akteur in der Rolle "User-HBA" möchte, seinen Endpunkt im VZD-FHIR Directory für Versicherte
nicht sichtbar (a) bzw. sichtbar (b) schalten.
Komponenten
  • TI-Messenger-Client
  • FHIR-Proxy
  • FHIR-Directory
Vorbedingungen
  1. Der Akteur ist bei einem zugelassenen TI-Messenger-Client angemeldet.
  2. Der Akteur hat durch erfolgreiche Anmeldung mit seinem HBA die Rolle "User-HBA" eingenommen und ein gültiges owner-accesstoken liegt vor.
  3. Die seinem Practitioner-Eintrag zugehörigen Endpoints aus dem VZD-FHIR-Directory liegen dem Client vor.
Eingangsdaten FHIR-Endpoint mit neuer endpointVisibility
Ergebnis Der Eintrag ist in der Suche für Akteure in der Rolle "Versicherter" nicht sichtbar (a) bzw. sichtbar (b).
Ausgangsdaten FHIR-Endpoint mit aktualisierter endpointVisibility

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 FHIR-Proxy auf Grund der Übersichtlichkeit nicht berücksichtigt wurde.

Abbildung 4: Laufzeitsicht - Practitioner - FHIR-VZD Sichtbarkeit für Versicherte setzen

[<=]

AF_10377 - Organization - FHIR-VZD Sichtbarkeit für Versicherte setzen

Mit diesem Anwendungsfall kann ein Akteur in der Rolle "Org-Admin" die Sichtbarkeit der Endpoint Einträge der Organisation, die er vertritt, im VZD-FHIR-Directory verwalten. Möchte der Akteur verhindern, dass Akteure in der Rolle "Versicherter" eine für die Organisation hinterlegte MXID über die Suche finden können, dann kann er dies am Endpunkt konfigurieren oder im umgekehrten Fall wieder zurücknehmen. 

Tabelle 8: Organization - FHIR-VZD Sichtbarkeit für Versicherte setzen

Attribute Bemerkung
Akteur  Akteur in der Rolle "Org-Admin"
Auslöser  Ein Akteur in der Rolle "Org-Admin" möchte einen Endpunkt im VZD-FHIR Directory für Versicherte
nicht sichtbar (a) bzw. sichtbar (b) schalten.
Komponenten 
  • Org-Admin-Client
  • FHIR-Proxy
  • FHIR-Directory
Vorbedingungen 
  1. Der Akteur ist bei einem zugelassenen Org-Admin-Client angemeldet.
  2. Der Akteur hat erfolgreich ein RegService-OpenID-Token gegen ein owneraccess-token für seine Organisation eingetauscht
  3. Die seinem Organization-Eintrag zugehörigen Endpoints aus dem VZD-FHIR-Directory liegen dem Client vor.
Eingangsdaten  FHIR-Endpoint mit neuer endpointVisibility
Ergebnis Der Eintrag ist in der Suche für Akteure in der Rolle "Versicherter" nicht sichtbar (a) bzw. sichtbar (b).
Ausgangsdaten FHIR-Endpoint mit aktualisierter endpointVisibility

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 FHIR-Proxy auf Grund der Übersichtlichkeit nicht berücksichtigt wurde.

Abbildung 5: Laufzeitsicht - Organization - FHIR-VZD Sichtbarkeit für Versicherte setzen

[<=]

5.1.4 Anmeldung eines Akteurs am Messenger-Service

AF_10057-04 - Anmeldung eines Akteurs am Messenger-Service

Mit diesem Anwendungsfall meldet sich ein Akteur an einen in der TI-Föderation zuständigen Messenger-Service an und registriert seinen TI-M Client als Endgerät. Der TI-M Client kann die Auswahl der Matrix-Domain des gewünschten Messenger-Service automatisieren oder durch andere Hilfsmittel wie z. B. QR-Codes unterstützten. Erfolgt dies nicht, so muss der TI-M Client dem Akteur die freie Eingabe der Matrix-Domain ermöglichen.

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

AF_10057 Anmeldung eines Akteurs am Messenger-Service
Akteur  Akteur in der Rolle "User"
Auslöser Ein Akteur möchte sich mit seinem TI-M Client bei einem Messenger-Service anmelden.
Komponenten
  • TI-M Client
  • Messenger-Proxy
  • Matrix-Homeserver
Vorbedingungen
  1. Der Akteur verfügt über einen vom Anbieter unterstützen TI-M Client.
  2. Der Akteur kennt die URL des Messenger-Services oder die URL ist bereits in seinem TI-M Client konfiguriert.
  3. Der Akteur kann sich durch ein beim Matrix-Homeserver unterstütztes Authentisierungsverfahren identifizieren. Wird durch die Organisation ein eigenes Authentifizierungsverfahren verwendet, MUSS eine Anbindung an den Matrix-Homeserver erfolgt sein.
    Hinweis: Bei dem zweiten Faktor muss es sich nicht um für die Nutzer individuelle Faktoren handeln. Dieses schließt die gemeinsame Nutzung der SMC-B oder des HSM-B der LEI oder des KTR durch Angehörige dieser Institution als zweiten Faktor mit ein.
  4. Der verwendete Matrix-Homeserver ist in die Föderation integriert (valider Messenger-Service).
Eingangsdaten URL des Matrix-Homeservers
Ergebnis Ein Akteur hat sich erfolgreich an einem gültigen Messenger-Service angemeldet und mit einem zugelassenen Authentifizierungsverfahren erfolgreich authentisiert.
Ausgangsdaten Matrix-ACCESS_TOKEN, Matrix-REFRESH_TOKEN, MXID, device_id, Status

In der Laufzeitsicht sind die Interaktionen zwischen den Komponenten, die durch den Anwendungsfall genutzt werden, dargestellt. In dieser wird der Prozess einer Anmeldung eines Akteurs an einem Messenger-Service dargestellt. Sollte ein Akteur noch nicht an einem Matrix-Homeserver registriert sein, dann wird zunächst eine Registrierung des Akteurs mit der Operation POST /_matrix/client/register durchgeführt. Der Ablauf der Registrierung ist analog dem des Login-Verfahrens.


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

[<=]

5.1.5 Einladung von Akteuren innerhalb einer Organisation

AF_10104-03 - 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 die Einladung wird für die externe Zustellung weitergeleitet.

Tabelle 10: Einladung von Akteuren innerhalb einer Organisation

AF_10104 Einladung von Akteuren innerhalb einer Organisation
Akteur Akteur in der Rolle "User"
Auslöser Akteur A möchte Akteur B seiner Organisation in einen gemeinsamen Raum einladen.
Komponenten
  • TI-Messenger Client A + B
  • Messenger-Proxy
  • Matrix-Homeserver
  • Push-Gateway
Vorbedingungen
  1. Die Akteure sind am selben Messenger-Service angemeldet.
  2. Jeder Akteur hat einen zugelassenen TI-M Client.
  3. Einladender ist Mitglied des Chatraums, in den eingeladen wird.
  4. Einladender verfügt in diesem Chatraum über einen hinreichenden Powerlevel, um einen Teilnehmer einladen zu können.
Eingangsdaten Invite-Event
Ergebnis Akteur A und Akteur B sind beide im Chatraum, zu dem die Einladung ausgesprochen wurde.
Optional erfolgt eine Benachrichtigung an Akteur B über die Einladung in den Chatraum. (Hat Akteur B den Akteur A auf seine BlockedUser-Liste gesetzt, dann erfolgt keine Benachrichtigung.)
Ausgangsdaten Status

In der Laufzeitsicht sind die Interaktionen zwischen den Komponenten, die durch den Anwendungsfall genutzt werden, dargestellt. Der für die zukünftige Kommunikation genutzte Chatraum wurde durch den einladenden Akteur bereits erstellt. Daher wird in diesem Anwendungsbeispiel ein /_matrix/client/v3/rooms/{roomId}/invite Event am Messenger-Proxy geprüft. Die folgende Darstellung zeigt lediglich die Einladung zwischen zwei Akteuren. Weitere Akteure können unabhängig von dieser Laufzeitsicht eingeladen werden (Hinweis: Group-Messaging).

Abbildung 7: Einladung von Akteuren innerhalb einer Organisation

[<=]

5.2 Funktionsaccounts

Einrichtungen im Gesundheitswesen sind sehr unterschiedlich strukturiert und wollen hinsichtlich ihrer Erreichbarkeit flexibel eigene Strukturen abbilden können. Daher sind beim TI-M Dienst Accounts notwendig, die es ermöglichen, Akteure unterhalb der Struktur erreichbar zu machen. Der anfragende Akteur muss dann nicht die genaue interne Struktur der Organisation kennen. Diese speziellen Accounts werden im folgenden als Funktionsaccounts bezeichnet.

Folgende Beispielszenarien können umgesetzt werden:

  • Die Credentials für einen Funktionsaccount werden an mehrere Mitarbeiter verteilt und somit können alle stellvertretend für die Organisation antworten.
  • Hinter dem Funktionsaccount verbirgt sich ein Automatismus, der z.B. den diensthabenden Arzt in den Chatraum hinzuholt.
  • Hinter dem Funktionsaccount verbirgt sich ein Automatismus, der selbstständig Antworten generiert.

Ein Funktionsaccount ist als eine Endpoint-Ressource eines HealthcareService einer Organisation anzulegen. Somit kann der Funktionsaccount unterhalb der Organisationsstruktur von einem Akteur gefunden und kontaktiert werden.

A_26523 - Funktionsaccount als Endpunkt

Der Org-Admin-Client MUSS einen Funktionsaccount als Endpoint-Ressource mit dem "payloadTyp: TI-Messenger chat" eines HealthcareService einer Organisation angelegen. [<=]

A_26524 - Funktionsaccount Address

Der Org-Admin-Client MUSS das address Attribut der Endpoint-Ressource mit der MXID des Funktionsaccounts im URI Format befüllen. [<=]

A_26525 - Funktionsaccount Name

Der Org-Admin-Client MUSS das name Attribut der Endpoint-Ressouce mit dem Displaynamen des Funktionsaccounts befüllen. [<=]

A_25546 - ConnectionType persönlicher Funktionsaccount

Der Org-Admin-Client MUSS für einen Funktionsaccount, der von einer oder mehreren natürlichen Personen betreut wird, an der Endpoint-Ressource den Code des EndpointDirectoryConnectionType auf "tim-fa" setzen. [<=]

5.2.1 Chatbot

Chatbots sind spezielle Akteure, die stellvertretend für eine Person oder Organisation die Kommunikation mit einem Akteur führen. Chatbots können die Kommunikation vollständig automatisiert abschließen (z. B. Terminvergabe) oder in der Organisation hinterlegte natürliche Personen dem Chat hinzuziehen (z. B. Ausstellen eines Rezeptes). Treten Chatbots als Kommunikationsteilnehmer des TI-Messengers auf, so sind diese im jeweiligen Chat als Chatbot zu kennzeichnen. Ein Beispiel für eine Kommunikation ist unter [api-messenger/docs/anwendungsfaelle/COM-chatbot.adoc] hinterlegt.

A_25547 - ConnectionType Funktionsaccount Chatbot

Der Org-Admin-Client MUSS für einen Funktionsaccount, der von einem automatisierten System abgebildet wird, an der Endpoint-Ressource den Code des EndpointDirectoryConnectionType auf "tim-bot" setzen. [<=]

A_25553 - Displayname Chatbot

Wird ein Akteur durch einen Chatbot realisiert, MUSS folgende Bildungsregel für den Displaynamen auf dem Homeserver verwendet werden: <Name des Funktionsaccounts> (Chatbot). [<=]

5.3 Berechtigungsmanagement - Anpassungen

5.3.1 Akteursspezifische Berechtigungskonfiguration

Für die Akteure des TI-M Pro wird die Möglichkeit geschaffen, bestimmte Nutzergruppen in der Berechtigungskonfiguration nutzen zu können. Als erste Benutzergruppe wird die Gruppe der Versicherten eingeführt. Die Zuordnung einer MXID zu dieser Gruppe kann über die Schnittstelle [api-messenger/src/openapi/TiMessengerInformation.yaml] erfolgen. Die folgende Abbildung zeigt beispielhaft die Verwendung der Gruppe anhand einer UI.

Abbildung 8: Beispielhaftes UI zum Setzen der Berechtigungen

Um die Berechtigung auf Gruppenebene nutzen zu können, wird für die Berechtigungskonfiguration für den TI-M Pro der folgende Namespace und das folgende Schema definiert. 

A_26389 - Event Type für Berechtigungskonfiguration

Der TI-M Client Pro MUSS für die Ablage der Berechtigungskonfiguration in den Accountdaten des Matrix-Homeservers de.gematik.tim.account.permissionconfig.pro.v1 als Event Type verwenden. [<=]

A_26390 - Schema der Berechtigungskonfiguration

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

5.4 Management von Akteuren und Rollen

Aufgrund der Vielzahl an Teilnehmern wird eine komfortable Benutzerverwaltung innerhalb des TI-Messenger-Dienstes benötigt. In diesem Kapitel werden die für das User Management notwendigen Rollen und Nutzer-Verzeichnisse beschrieben.

Voraussetzung für die Nutzung des TI-Messenger-Dienstes ist zunächst, dass sich ein Akteur über ein Authentifizierungsverfahren am Matrix-Homeserver seiner Organisation authentifizieren kann und ein Nutzer-Account auf dem Matrix-Homeserver angelegt wurde. Der Nutzer-Account auf dem Matrix-Homeserver wird vom Akteur in der Rolle "Org-Admin" seiner Organisation bereitgestellt. Alternativ ist auch eine automatisierte Provisionierung möglich.

Bei der Erstellung des Nutzer-Accounts wird die MXID des Akteurs erzeugt sowie der Displayname des Akteurs festgelegt. Nach der Erstellung des Nutzer-Accounts am Matrix-Homeserver wird die MXID des Akteurs im User-Directory des Matrix-Homeservers hinterlegt. Alle im User-Directory des Matrix-Homeservers hinterlegten MXIDs sind anschließend durch andere Akteure seiner Organisation auffindbar und erreichbar. Soll der Akteur auch von außerhalb der Organisation auffindbar werden, so muss dieser mit seiner MXID in das Organisationsverzeichnis im VZD-FHIR-Directory hinterlegt werden. Das Hinterlegen der MXID eines Akteurs in das Organisationsverzeichnis muss durch den Akteur in der Rolle "Org-Admin" erfolgen. Voraussetzung ist das Vorhandensein einer HealthcareService-Ressource der Organisation. Die MXIDs werden in Endpoint-Ressourcen hinterlegt, die der HealthcareService-Ressource zugeordneten sind. Die Einrichtung einer HealthcareService-Ressource einer Organisation erfolgt durch den Akteur in der Rolle "Org-Admin". Möchte ein Akteur ohne Zugehörigkeit zu einer Organisation gefunden werden, so muss seine MXID in das Personenverzeichnis des VZD-FHIR-Directory hinterlegt werden. Voraussetzung hierfür ist der Besitz eines HBAs.

Die folgende Tabelle zeigt einen zusammenfassenden Überblick der Benutzerverwaltung.

Tabelle 11: Überblick der Benutzerverwaltung in Abhängigkeit der Rolle

Rolle Client Administration Wo
Org-Admin TI-Messenger Client mit Administrationsfunktionen
(Org-Admin-Client)
  • Nutzer-Account anlegen
  • Nutzer-Account verwalten
 Matrix-Homeserver
(User Directory)
  • HealthcareService-Ressource anlegen
  • Endpoint einer HealthcareService-Ressource anlegen
  • Endpoint einer HealthcareService-Ressource verwalten
 VZD-FHIR-Directory
(Organisationsverzeichnis)
User TI-Messenger Client
  • Nutzer-Account anlegen
 Matrix-Homeserver
(User Directory)

Hinweis: Der TI-M Fachdienst Anbieter kann eine automatisierte Provisionierung von Nutzer-Accounts umsetzen. Details eines entsprechenden Verfahrens werden von der gematik nicht spezifiziert und obliegen dem Anbieter.

5.5 Unterbindung der Versichertenkommunikation beim Verlassen eines Raumes

A_26463 - Sperrung der weiterführenden Kommunikation nach Verlassen des Raumes

Der Anbieter MUSS die Organisation, welche den TI-Messenger Dienst von ihm bezieht, darüber informieren, dass Leistungserbringer vor dem Verlassen eines Raumes, in dem ausschließlich Versicherte verbleiben, diesen so zu konfigurieren, dass eine weiterführende Kommunikation unter den Versicherten unterbunden wird. Diese Konfiguration kann z. B. durch Entfernen der Versicherten aus dem Raum oder die Einstellung entsprechender Power Levels im Raum erfolgen. [<=]

Hinweis: Die Unterbindung der weiterführenden Kommunikation zwischen Versicherten erfolgt unter Erhalt der zuvor in den jeweiligen Räumen ausgetauschten Nachrichten, sodass Versicherten versorgungsrelevante Informationen nicht verloren gehen.

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

Tabelle 12: Im Dokument verwendete Abkürzungen

Kürzel
 Erläuterung
API Application Programming Interface
ePA elektronische Patientenakte
FD Fachdienst
IdP Identity Provider
KIM Kommunikation im Medizinwesen
TLS Transport Layer Security
VZD Verzeichnisdienst

6.2 Glossar

Tabelle 13: Im Dokument verwendete Begriffe

Begriff
 Erläuterung
Funktionsmerkmal Der Begriff beschreibt eine Funktion oder auch einzelne, eine logische Einheit bildende Teilfunktionen der TI im Rahmen der funktionalen Zerlegung des Systems.

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

6.3 Abbildungsverzeichnis

6.4 Tabellenverzeichnis

6.5 Referenzierte Dokumente

6.5.1 Dokumente der gematik

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

Tabelle 14: Referenzierte Dokumente der gematik

[Quelle]
 Herausgeber: Titel
[api-messenger] gematik: Implementierungsleitfaden zum TI-Messenger
https://github.com/gematik/api-ti-messenger
[gemGlossar] gematik: Einführung der Gesundheitskarte – Glossar
[gemSpec_SST_LD_BD] gematik: Spezifikation Logdaten- u. Betriebsdatenerfassung
[gemSpec_TI-M_Basis] gematik: Spezifikation TI-Messenger (Basis)
[gemSpec_TI-M_ePA] gematik: Spezifikation TI-Messenger (ePA)
[gemSpec_VZD_FHIR_Directory] gematik: Spezifikation Verzeichnisdienst FHIR-Directory

6.5.2 Weitere Dokumente

Tabelle 15: Weitere Dokumente

[Quelle]
 Herausgeber (Erscheinungsdatum): Titel
[Client-Server API] Matrix Foundation: Matrix Specification - Client-Server API
https://spec.matrix.org/v1.11/client-server-api/
[RFC2119] IETF: Key words for use in RFCs to Indicate Requirement Levels
https://datatracker.ietf.org/doc/html/rfc2119
[Server-Server API] Matrix Foundation: Matrix Specification - Server-Server API
https://spec.matrix.org/v1.11/server-server-api