gemSpec_TI-M_Pro_V1.0.0_CC
Prereleases:
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.
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.
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.
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)
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,
}]
}
* 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
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. [<=]
$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]).
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 |
|
Vorbedingungen |
|
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.
[<=]
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.
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 |
|
Vorbedingungen |
|
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.
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.
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 |
|
Vorbedingungen |
|
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.
[<=]
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.
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 |
|
Vorbedingungen |
|
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.
[<=]
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.
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 |
|
Vorbedingungen |
|
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).
[<=]
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.
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.
Rolle | Client | Administration | Wo |
---|---|---|---|
Org-Admin | TI-Messenger Client mit Administrationsfunktionen (Org-Admin-Client) |
|
Matrix-Homeserver (User Directory) |
|
VZD-FHIR-Directory (Organisationsverzeichnis) |
||
User | TI-Messenger Client |
|
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
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
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
- Abbildung 1: Betriebsmodell TI-M Pro
- Abbildung 2: Laufzeitsicht - Organisationsressourcen im Verzeichnisdienst hinzufügen
- Abbildung 3: Laufzeitsicht - Akteur (User-HBA) im Verzeichnisdienst hinzufügen
- Abbildung 4: Laufzeitsicht - Practitioner - FHIR-VZD Sichtbarkeit für Versicherte setzen
- Abbildung 5: Laufzeitsicht - Organization - FHIR-VZD Sichtbarkeit für Versicherte setzen
- Abbildung 6: Einladung von Akteuren innerhalb einer Organisation
- Abbildung 7: Beispielhaftes UI zum Setzen der Berechtigungen
6.4 Tabellenverzeichnis
- Tabelle 1: Akteure und Rollen
- Tabelle 2: Arten von Token
- Tabelle 3: Schreibzugriff - VZD-FHIR-Ressourcen
- Tabelle 4: Berichtsformat_TI-Messenger-Fachdienst Pro <3
- Tabelle 5: AF - Organisationsressourcen im Verzeichnisdienst hinzufügen
- Tabelle 6: AF - Akteur (User-HBA) im Verzeichnisdienst hinzufügen
- Tabelle 7: Practitioner - FHIR-VZD Sichtbarkeit für Versicherte setzen
- Tabelle 8: Organization - FHIR-VZD Sichtbarkeit für Versicherte setzen
- Tabelle 9: Einladung von Akteuren innerhalb einer Organisation
- Tabelle 10: Überblick der Benutzerverwaltung in Abhängigkeit der Rolle
- Tabelle 11: Im Dokument verwendete Abkürzungen
- Tabelle 12: Im Dokument verwendete Begriffe
- Tabelle 13: Referenzierte Dokumente der gematik
- Tabelle 14: Weitere Dokumente
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.
[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
[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 |