gemSpec_TI-M_Pro_V1.0.0_CC

Prereleases:

PDF HTML Excel XML
gemSpec_TI-M_Pro_V1.0.0_CC






Elektronische Gesundheitskarte und Telematikinfrastruktur





Spezifikation

TI-Messenger Pro 




    

     

      Version
      1.0.0_CC
     

     

      Revision
      968339
     

     

      Stand
      16.08.2024
     

     

      Status
      zur Abstimmung freigegeben
     

     

      Klassifizierung
      öffentlich_Entwurf
     

     

      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_CC 16.08.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.

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. Dokumentenlandkarte, 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

2.1.1 Akteur: Chatbot

Chatbots können ebenso wie natürliche Personen Teilnehmer von Chaträumen sein, in welchen sie dann bestimmte Funktionen übernehmen. Zu diesem Zweck müssen sie sich gleichermaßen authentisieren. Folgende Funktionen wurden bisher für die Erfüllung durch ein automatisiertes System identifiziert:

  • Archivierungssystem

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]. Ein Akteur kann 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 in Kapitel   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.

Der TI-M Client Pro bekommt für Akteure in der Rolle "User-HBA" zusätzliche Funktionalität, damit diese ihre eigenen Einträge im VZD-FHIR Directory hinzufügen/anpassen können (siehe 5.1.2 Akteur (User-HBA) im Verzeichnisdienst hinzufügen).

3.1.2 Ausprägungen nach Plattform

Der TI-M Client Pro kann auch als Web-Anwendung zur Nutzung in einem Bowser 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

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

A_25326 - Öffentliche Räume Encryption

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 Usern 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 mit Hilfe von vorliegenden Stammdaten (KVNR und IK-Nummer) zu generieren, ist es notwendig eine Schnittstelle zu schaffen, die Auskunft über die Domain liefert, auf der Versicherte mit einer bestimmten IK-Nummer ihren Account haben.

A_26445 - Domainermittlung über IK-Nummer

Der Messenger-Proxy Pro MUSS eine Schnittstelle auf Basis der [api-messenger/src/openapi/TiMessengerInformation.yaml] implementieren, um die Domain zu einer IK-Nummer ermitteln zu können. [<=]

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.

Hinweis: Die vorangegangenen Anforderungen regeln lediglich die Authentisierung, die notwendig ist, um ein Token zu erhalten, mit dem sich Nutzer gegenüber dem TI-Messenger-Fachdienst authentisieren können.

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 informiert wird, welche Daten in welches Drittsystem weitergeleitet werden.  [<=]

A_25509 - Verhinderung von Bildschirmaufnahmen

Der TI-M Client Pro für mobile Szenarien SOLL eine Funktion zur Verhinderung der Anfertigung von Bildschirmaufnahmen anbieten. [<=]

A_26352 - Standardeinstellung für Verhinderung von Bildschirmaufnahmen

Bietet der TI-M Client Pro eine Funktion zur Verhinderung von Bildschirmaufnahmen an, MUSS er diese Funktion standardmäßig aktivieren. [<=]

A_25511 - Opt-Out für Verhinderung von Bildschirmaufnahmen

Bietet der TI-M Client Pro eine Funktion zur Verhinderung von Bildschirmaufnahmen an, MUSS er es dem Akteur ermöglichen, diese Funktion zu deaktivieren. [<=]

A_25510 - Warnung vor mangelndem Schutz von Bildschirmaufnahmen

Bietet der TI-M Client Pro für mobile Szenarien keine Funktion zur Verhinderung von Bildschirmaufnahmen an oder ist die Funktion deaktiviert, so MUSS er Akteure 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 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)

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 - TI - Messenger Fachdienst Bestandsdaten (Pro)

Der TI-Messenger-Fachdienst Pro 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,
    "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 - Rohdaten - Spezifika Fachdienst TI-M (Rohdatenerfassung v.02)

Das Produkt MUSS bei Rohdaten-Performance-Berichten 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 - Rohdaten -Spezifika Fachdienst TI-M - Umfang (Rohdatenerfassung v.02)

Der Produkttyp Fachdienst TI-Messenger 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 - Rohdaten - Spezifika Fachdienst TI-M Pro - Duration (Rohdatenerfassung v.02)

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

A_26423 - Performance - Rohdaten - Spezifika Fachdienst TI-M Pro - Operation (Rohdatenerfassung v.02)

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

Tabelle 4: Berichtsformat_TI-Messenger-Fachdienst Pro <3

$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_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
 6 POST /_matrix/client/r0/rooms/{roomsId}/invite 25 "Nutzer in den Raum eingeladen"
TIM.UC_10061-03_02 AF - Einladung von Akteuren außerhalb einer Organisation:
Einladung Empfangssystem
 12 HTTP(S) Forward 22 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).

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. [<=]

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 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 9: 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 6: 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. 
Ein Funktionsaccount ist als eine Endpoint-Ressource (mit dem "payloadTyp: TI-Messenger chat") eines HealthcareService einer Organisation anzulegen. Der HealthcareService bildet im FHIR-Directory eine Struktur (z. B. Station in einem Krankenhaus) der Organisation ab. Zur Erreichbarkeit dieser Struktur wird die MXID eines Chatbots oder eines Akteurs (der stellvertretend für die Organisation eintritt) im URI Format im "address" Attribut der Endpoint Ressource hinterlegt. Somit kann die angelegte Struktur der Organisation über den Funktionsaccount und dessen hinterlegten Namen (Endpoint.name) im VZD-FHIR-Directory von einem Akteur gefunden werden.

A_25546 - ConnectionType persönlicher Funktionsaccount

Wird durch den Org-Admin-Client des TI-M Client Pro im VZD-FHIR-Directory eine Endpoint-Ressource für einen Funktionsaccount angelegt, der von einer oder mehreren natürlichen Personen betreut wird, dann MUSS der code des EndpointDirectoryConnectionType auf "tim-fa" gesetzt werden. [<=]

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). Beispiele für Chatbots sind unter [Matrix Bots] zu finden. 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 Chatbot

Wird durch den Org-Admin-Client des TI-M Client Pro im VZD-FHIR-Directory eine Endpoint-Ressource für einen Chatbot angelegt, dann MUSS der code des EndpointDirectoryConnectionType auf "tim-bot" gesetzt werden. [<=]

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 den TI-M Pro wird für alle Akteure die Voreinstellung der Berechtigungskonfiguration auf "block all" gesetzt.

A_26305 - Voreinstellung der Berechtigungseinstellungen für bestimmte Rollen

Der TI-M Client Pro MUSS sicherstellen, dass für User des TI-M Pro die Voreinstellung der Basiseinstellung der Berechtigungskonfiguration die Variante "block all" ist. [<=]

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 folgende Abbildung zeigt beispielhaft die Verwendung der Gruppe anhand einer UI.

Abbildung 7: 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 Namespache 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. [<=]

Für die Zuordnung einer MXID zu einer Gruppe ist es notwendig diese Information bereitzustellen.

A_26392 - Zusätzliche Profilinformationen

Der TI-M Fachdienst Pro MUSS an der API [Client-Server API/#get_matrixclientv3profileuserid] den Response zusätzlich um das Feld "roles" mit dem Wert ["insuree"] anreichern, wenn die angefragte User-ID einen Account auf einem Versichertenserver abbildet. [<=]

Hinweis: Für die Verfügbarkeit dieser Information wurde die [Server-Server API/#get_matrixfederationv1queryprofile] des TI-M Fachdienste ePA erweitert (Details siehe Afo Zusätzliche Profilinformationen in [gemSpec_TI-M_ePA]). Diese Pro-Afo wurde eingeführt, da ein Synapse Server an der [Client-Server API] nicht das ganze Profil des anderen Servers weiterreicht, sondern explizit nur einzelne Felder verwendet.

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 10: Ü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)

A_26350 - Automatisierte Provisionierung von Nutzer-Accounts

Der TI-M Fachdienst Anbieter KANN eine automatisierte Provisionierung von Nutzer-Accounts umsetzen. Details eines entsprechenden Verfahrens werden von der gematik nicht spezifiert 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. [<=]

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

Tabelle 11: 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 12: 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. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

Tabelle 13: 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 14: 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/
[Matrix Bots] https://matrix.org/ecosystem/integrations/
[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