Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Verzeichnisdienst FHIR-Directory

Version
1.7.0
Revision
1518083
Stand
17.02.2026
Status
freigegeben
Klassifizierung
öffentlich
Referenzierung
gemSpec_VZD_FHIR_Directory

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

Dieses Dokument beschreibt das FHIR-Directory des Verzeichnisdienstes der TI. Die Spezifikation umfasst Schnittstellen zum Abruf von Informationen der im FHIR-Directory eingetragenen Organization-FHIR-Ressourcen und der Practitioner-FHIR-Ressourcen durch Clientsysteme sowie Schnittstellen und Prozesse zur Pflege der Informationen innerhalb des VZD-FHIR-Directories.

1.1 Zielsetzung

Die Spezifikation soll die Entwicklung und den Betrieb eines VZD-FHIR-Directories für die Telematikinfrastruktur unterstützen, indem die funktionalen und nicht-funktionalen Anforderungen sowie die Sicherheits-Anforderungen an den Dienst festgelegt werden. 

1.2 Zielgruppe

Das Dokument richtet sich zwecks der Realisierung an den Hersteller des VZD-FHIR-Directories sowie an den Anbieter, welcher dieses Produkt betreibt [gemKPT_Betr]. Alle Hersteller und Anbieter von TI-Anwendungen, die das VZD-FHIR-Directory nutzen, müssen dieses Dokument ebenso berücksichtigen. Gleichfalls ist das Dokument auch für die Nutzer relevant, welche die Daten im VZD-FHIR-Directory eintragen, abfragen, ändern und löschen wollen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Anbietertypsteckbrief u.a.) oder Webplattformen (z. B. gitHub u.a.) festgelegt und bekanntgegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Spezifiziert werden in dem Dokument nur die mit dem VZD-FHIR-Directory neu eingeführten Komponenten und Schnittstellen des Verzeichnisdienstes der TI. Das VZD-LDAP-Directory ist in [gemSpec_VZD] spezifiziert. 

Benutzte Schnittstellen werden in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang, Kapitel 8.5 Referenzierte Dokumente).

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps VZD-FHIR-Directory verzeichnet.

1.5 Methodik

Die Spezifikation ist im Stil einer RFC-Spezifikation verfasst. Dies bedeutet: 

• Der gesamte Text in der Spezifikation ist sowohl für den Hersteller des Produktes VZD-FHIR-Directory als auch für den betreibenden Anbieter entsprechend [gemKPT_Betr] als verbindlich zu betrachten und gilt sowohl als Zulassungskriterium beim Produkt und Anbieter.
• Auch für technisch mit dem Produkt und Dienst verbundene Anwendungen ist dieses Dokument verbindlich. Gleichfalls für die Nutzer, welche zur Datenpflege im VZD-FHIR-Directory beitragen oder Daten abfragen.
• Die Verbindlichkeit SOLL durch die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet werden. 
• Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet.
• Die Schlüsselworte KÖNNEN außerdem um Pronomen in Großbuchstaben ergänzt werden, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anwendungsfälle und Akzeptanzkriterien als Ausdruck normativer Festlegungen werden als Grundlage für Erlangung der Zulassung durch Tests geprüft und nachgewiesen. Sie besitzen eine eindeutige, permanente ID, welche als Referenz verwendet werden SOLL. Die Tests werden gegen eine von der gematik gestellte Referenz-Implementierung durchgeführt. 

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

Die einzelnen Elemente beschreiben:

• ID: einen eindeutigen Identifier.
• Bei einem Anwendungsfall besteht der Identifier aus der Zeichenfolge 'AF_' gefolgt von einer Zahl, 
• Der Identifier eines Akzeptanzkriteriums wird von System vergeben, z. B. die Zeichenfolge 'ML_' gefolgt von einer Zahl
• Titel des Anwendungsfalles / Akzeptanzkriteriums: Ein Titel, welcher zusammenfassend den Inhalt beschreibt
• Text / Beschreibung: Ausführliche Beschreibung des Inhalts, kann neben Text Tabellen, Abbildungen und Modelle enthalten

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

Der für die Erlangung einer Zulassung notwendige Nachweis der Erfüllung des Anwendungsfalls wird in den jeweiligen Steckbriefen festgelegt, in denen jeweils der Anwendungsfall gelistet ist. Akzeptanzkriterien werden in der Regel nicht im Steckbrief gelistet.

Hinweis auf offene Punkte

2 Systemüberblick

Das VZD-FHIR-Directory ist eine Erweiterung des bisherigen Verzeichnisdienstes der TI. Im VZD-FHIR-Directory werden Einträge von Organisationen und Leistungserbringern gespeichert. Die VZD-LDAP-Directory Einträge werden in das VZD-FHIR-Verzeichnis synchronisiert. Bei diesem Vorgang erfolgt eine Umsetzung von der LDAP-Datenstruktur auf die Datenstruktur der FHIR-Ressourcen. Personeneinträge der Leistungserbringer werden auf die PractitionerDirectory-Ressource und Organisations-Einträge auf die OrganizationDirectory-Ressource abgebildet. Die synchronisierten Einträge bilden die Basis-Einträge, die durch die Besitzer um zusätzliche Daten ergänzt bzw. erweitert werden können. PractitionerDirectory und OrganizationDirectory sind Profilierungen der FHIR-Ressourcen Practitioner und Organization. Die Anbieter von Fachanwendungen werden ebenfalls als OrganizationDirectory-Einträge im FHIR-Directory eingetragen, um Daten der Fachanwendung zu dieser Organisation zuordnen zu können.

Der Besitzer einer Telematik-ID erhält das Recht, seinen Eintrag zu erweitern (um z. B. Unterstrukturen für eine Organisation einzutragen) und Fachdaten zu ergänzen (z. B. TI-Messenger-Adressen). Die von den Kartenherausgebern eingetragenen Daten dürfen durch die Besitzer nicht verändert werden. Zusätzliche FHIR-Ressourcen (wie z. B. Endpoint und HealthcareService) können durch die Besitzer ergänzt werden, um den Komfort bei der Suche nach Einträgen zu erhöhen.

Alle vom VZD-FHIR-Directory bereitgestellten Schnittstellen sind über das Internet erreichbar und TLS-gesichert. Die Authentisierung erfolgt mit:

• OpenID Connect Authorization Code Flow für Schreibzugriffe der Besitzer von Einträgen
• OAuth2 Client Credential Flow für Schreibzugriffe der Fachdienste
• Matrix-OpenID-Token für Lesezugriffe von TI-Messenger-Nutzern

Eine Nutzung der Schnittstellen des VZD-FHIR-Directory ohne Authentisierung der Nutzer MUSS durch das VZD-FHIR-Directory verhindert werden.

Der TI-Messenger-Dienst hat als erste Anwendung das VZD-FHIR-Directory genutzt.

Abbildung 1: Systemüberblick VZD-FHIR-Directory

Das FHIR-Directory ist eine Implementierung der FHIR-Spezifikation (http://hl7.org/fhir/summary.html ).

2.1 Nutzer und Rollen

Tabelle 1: Nutzer und Rollen 

Tabelle 2: Kommunikationsbeziehungen zu IT-Systemen

Alle Schnittstellen mit Ausnahme (6) sind über das Internet erreichbar. Die Schnittstellen stellen folgende Funktionen bereit:

1. Für Nutzer gibt es eine Schnittstelle zur Suche nach Einträgen im FHIR-Directory Organisationsverzeichnis und Personenverzeichnis. Die Schnittstelle kann nur nach erfolgreicher Authentisierung genutzt werden. Alle TI-Messenger Nutzer können sich authentisieren und bekommen vom FHIR-Directory ein Accesstoken ausgestellt, das für die Suchanfragen verwendet wird. Die Suche ermöglicht es, komfortabel nach Volltext oder nach bestimmten Werten der einzelnen Attribute über die verlinkten Ressourcen zu suchen. Gefundene Ressourcen werden in einem Bundle von FHIR Ressourcen zurück geliefert. Das Datenformat ist json.
2. Für Administratoren der Organisationen des Gesundheitswesens und für LE gibt es eine Schnittstelle zur Änderung ihres Eintrags im Organisationsverzeichnis. Zur Nutzung der Schnittstelle ist eine Authentifizierung mit OIDC Authorization Code Flow erforderlich. Über diese Schnittstelle kann im Organisationsverzeichnis der eigene Eintrag der Organisation über eine Verlinkung um zusätzliche Einträge erweitert werden. TI-Messenger Nutzer, die auch LE sind, können diese Schnittstelle nutzen, um ihre TI-Messenger-Adresse in ihrem Eintrag im Personenverzeichnis zu speichern, sodass sie von anderen LE gefunden werden können. Auch hier erfolgt die Authentifizierung über OIDC. Das FHIR-Datenformat ist json.
3. Für Kartenherausgeber gibt es die Schnittstelle I_Directory_Administration, um Einträge im LDAP-Directory anzulegen und zu pflegen. Das Datenformat ist json und ist in der OpenAPI-yaml-Datei DirectoryAdministration.yaml festgelegt. Zukünftig ist vorgesehen, dass die Kartenherausgeber auch direkt die Schnittstelle zum FHIR-Directory nutzen können. Dann ist das Datenformat FHIR in der Ausprägung JSON. Die Authentifizierung der Kartenherausgeber erfolgt mit OAuth Client Credential Flow.
4. TI-Messenger-Fachdienste pflegen im FHIR-Directory für die von ihnen angebotenen Messenger-Services die TI-Messenger-Domänen. Zusätzlich können die TI-Messenger-Anbieter die Föderationsliste abfragen. Sie beinhaltet alle an der Föderation des TI-Messengers beteiligte Domains. Um die Kommunikationskontrolle zu ermöglichen, fragen TI-Messenger-Fachdienste auch ab, in welchem Verzeichnis (Personen- oder Organisationsverzeichnis) sich die TI-Messenger-Adressen befinden. Die Authentifizierung der TI-Messenger-Fachdienste erfolgt mit OAuth Client Credential Flow.
5. Fachdienste können - nach Registrierung beim FHIR-Directory-Anbieter - search-access_token beziehen. Diese search-access_token können sie an ihre Clients verteilen.
6. Die gematik hat Schnittstellen, um die Daten-Qualität der Einträge zu prüfen. Dazu wird die Schnittstelle der Kartenherausgeber genutzt. Die gematik hat nur Leserechte.
7. Die Einträge im LDAP-Directory werden in das FHIR-Directory Organisations- und Personenverzeichnis synchronisiert. Es handelt sich um eine interne Schnittstelle des Verzeichnisdienstes der TI.

2.2 Nachbarsysteme

Die Nachbarsysteme des VZD-FHIR-Directory sind Client- und Serverkomponenten des TI-Messenger-Dienstes, das VZD-LDAP-Directory, die IDPs aus der TI-IDP-Föderation und die Betriebsdatenerfassung der gematik. 

3 Zerlegung des Produkttyps

Die folgende Abbildung zeigt die Teilkomponenten des bisherigen VZD-LDAP-Directory und die rot dargestellten neuen Komponenten des VZD-FHIR-Directory.

Abbildung 2: Zerlegung des VZD

Das VZD-FHIR-Directory besteht aus den Komponenten FHIR-Proxy und FHIR-Directory sowie Auth-Service.

Die vom VZD-FHIR-Directory zu liefernden Rohdaten zur Ermittlung der Auslastung und Performance werden in den bereits vorhandenen Betriebsdaten-Erfassungs-Client (BDE-Client) des Verzeichnisdienstes integriert.

4 Funktionsmerkmale

In diesem Kapitel werden die Komponenten des VZD-FHIR-Directories beschrieben.

Das FHIR-Directory stellt folgende Schnittstellen bereit:

• FHIRDirectoryAuthorizationService

Stellt Accesstokens zum Zugriff auf FHIRDirectory APIs aus. Es wird zukünftig zum anwendunsspezifischen Policy Decision Point (PDP) ausgebaut.

Hierbei werden die folgenden REST-Schnittstellen

• /tim-authenticate
• /service-authenticate und
• /owner-authenticate

verwendet. Die Schnittstelle /tim-authenticate erwartet ein Matrix-OpenID-Token, wohingegen bei der Schnittstelle /owner-authenticate ein ID_TOKEN übergeben werden muss. Die Schnittstelle /service-authenticate akzeptiert ein service-authz-token.

• FHIRDirectorySearchAPI

Die REST-Schnittstelle /search ermöglicht die Suche nach Personen und Institutionen.

Genutzt wird die Standard FHIR Suchoperation https://build.fhir.org/search.html 

Zur Nutzung der Suchoperation muss ein entsprechendes Accesstoken vom FHIRDirectoryAuthorizationService vorliegen.

• FHIRDirectoryFdvSearchAPI

Die REST-Schnittstelle /fdv/search ermöglicht die Suche durch Versicherte nach Personen und Institutionen.

Genutzt wird die Standard FHIR Suchoperation https://build.fhir.org/search.html 

Zur Nutzung der Suchoperation muss ein entsprechendes Accesstoken vom FHIRDirectoryAuthorizationService vorliegen.

• FHIRDirectoryTIMProviderAPI

Die REST-Schnittstelle /tim-provider-services ermöglicht die eigenverantwortliche Verwaltung von Föderationslisteneinträgen für TI-Messenger Provider. 

Diese REST Schnittstelle wird hier definiert: https://github.com/gematik/api-vzd/ unter src/openapi/I_VZD_TIM_Provider_Services.yaml

• FHIRDirectoryOwnerAPI

Die REST-Schnittstelle /owner ermöglich die Anpassung der Einträge durch Identitätseigentümer zzgl. Autoritativer Daten der Kartenherausgeber.

Genutzt werden die Standard FHIR Operationen https://build.fhir.org/http.html mit der Einschränkung auf eigene Resourcen und die autoritativen Daten der Kartenherausgeber.

Zur Nutzung dieser Operation muss ein entsprechendes owner-access_token vom FHIRDirectoryAuthorizationService vorliegen.

• ProviderAuthorizationService

Ermöglicht Authentisierung und Autorisierung der TI-Anbieter zum Zugriff auf FHIR Directory. Am Anfang nur TI-Messenger Anbieter, später auch KIM-Anbieter und zukünftige Anbieter.

Bei Aufruf der REST-Schnittstelle /tim-provider-services wird ein Accesstoken (provider-accesstoken) benötigt. Hierfür muss sich der Client bei dem ProviderAuthorizationService des VZD-FHIR-Directory mittels OAuth2 Client Credentials Flow authentisieren. Zuvor MUSS der Client beim VZD-Anbieter Client-Credentials beantragen.

Geplante FHIR-Directory Schnittstellen in zukünftigen Releases:

• FHIRDirectoryAdmin API

Geplante Schnittstelle für die Administration der Daten im FHIR Verzeichnisdienst als Nachfolger für REST Pflegeschnittstelle (DirectoryAdministration).

• FHIRDirectorySync API

Geplante Schnittstelle zum Auslesen größerer Datenmengen aus dem FHIR Verzeichnisdienst.

4.1 FHIR-Directory

Das FHIR-Directory ist eine Implementierung der HL7-FHIR-Spezifikation Release 4.0.1 (https://www.hl7.org/fhir/http.html).

Das FHIR-Directory ist nur über den FHIR-Proxy erreichbar.

4.1.1 Datenmodell

Es werden die FHIR-Ressourcen gemäß folgender Tabelle verwendet.

Alle Änderungen und Erweiterungen der FHIR Ressourcen sind in https://simplifier.net/vzd-fhir-directory veröffentlicht.

Tabelle 3: VZD-FHIR-Directory, FHIR-Ressourcen

4.1.2 Mapping von LDAP auf FHIR-Ressourcen

Die OrganizationDirectory- und PractitionerDirectory-Basiseinträge werden durch den FHIR Proxy mit den Daten aus dem VZD-LDAP-Directory initial erzeugt und anschließend fortlaufend aktualisiert. Die synchronisierten Daten können nicht durch die Besitzer (Leistungserbringer und Organisationen) geändert werden.

Die Daten aus dem VZD-LDAP-Directory werden wie folgt den FHIR-Ressourcen zugeordnet: https://github.com/gematik/api-vzd/blob/master/docs/LDAP2FHIR_Sync.adoc.

Zu jedem LDAP-VZD-SM-B-Eintrag werden im FHIR VZD je eine Instanz der Ressourcen "Organization", "HealthcareService" und "Location" erzeugt bzw. aktualisiert.

Zu jedem LDAP-VZD-HBA-Eintrag werden im FHIR VZD je eine Instanz der Ressourcen "Practitioner", "PractitionerRole" und "Location" erzeugt bzw. aktualisiert.

Berücksichtigung der Zertifikate im LDAP VZD

Der Status von LDAP- und FHIR-VZD-Einträgen wird über das "active" Attribut des LDAP-Basiseintrags, der FHIR Organization Ressource und der FHIR Practitioner Ressource abgebildet. Das "active" Attribut des LDAP-Basiseintrags wird auf die "active" Attribute der FHIR Ressourcen gemappt.

Im LDAP VZD werden VZD-Einträge nicht gefunden, wenn keine gültigen Zertifikate für sie im LDAP VZD vorhanden sind. Diesem Mechanismus wird oft vertraut und der VZD-Eintrag am Ende seiner Laufzeit (bzw. am Ende der Laufzeit seiner Zertifikate) nicht über das "active" Attribut des LDAP-Basiseintrags gesperrt. Im FHIR VZD sind diese VZD-Einträge aktuell aktiv ("active" Attribut der FHIR Ressourcen) und können genutzt werden. Da dies zu Problemen führt (z.B. Zuweisung von eRezepten, die dann nicht abgerufen werden können), wird das Mapping vom LDAP VZD in den FHIR VZD erweitert.

Das Mapping der LDAP-Einträge in die FHIR-Einträge berücksichtigt die Zertifikate im LDAP VZD wie folgt:

• Ist für einen VZD-Eintrag kein aktives Zertifikat im LDAP VZD verknüpft, wird der Datensatz im VZD FHIR deaktiviert (active = false). Dies erfolgt unabhängig vom "active" Attribut des LDAP-VZD-Basiseintrags.
  
• Wird dem LDAP-VZD-Eintrag nachträglich ein aktives Zertifikat hinzugefügt, wird der Datensatz erneut synchronisiert. Der Status (“active”) wird von dem Attribut "active" des LDAP-VZD-Basiseintrags übernommen.
  
• Die Deaktivierung von VZD-Einträgen über das "active" Attribut des LDAP-VZD-Basiseintrags wird unabhängig von der Datenkonsistenz des LDAP-VZD-Eintrags in den VZD FHIR synchronisiert. Damit werden auch VZD-Einträge mit inkonsistenten Daten im LDAP VZD im FHIR VZD deaktiviert.

4.1.3 FHIR RESTful API

Die Operationen der FHIR-Schnittstelle sind durch die FHIR-Spezifikation festgelegt (https://www.hl7.org/fhir/http.html).

Die Anzahl der mittels /search und /fdv/search Operation gefundenen und zurückgegebenen Einträge wird initial auf 100 begrenzt. Dieser Wert MUSS durch den FHIR VZD Anbieter konfigurierbar sein. Die zurückgegebenen Einträge werden in einem FHIR-Ressource-Bundle zusammengefasst. Im Attribut Bundle.total MUSS die Gesamtanzahl der Einträge im Bundle zurückgegeben werden. Für die Ermittlung der Gesamtzahl der gefundenen Einträge kann die Suchoperation _summary=count (https://hl7.org/fhir/search.html#summary) genutzt werden. Das Suchergebnis enthält dann in Bundle.total die Gesamtzahl der gefundenen Einträge, aber nicht die Einträge selbst.

Mit Angabe des Parameters _total=accurate (https://www.hl7.org/fhir/search.html#_total ) in der Suchoperation enthält das Suchergebnis die gefundenen Einträge (maximal 100) und in Attribut Bundle.total die gesamte Anzahl der Suchergebnisse im FHIR VZD (ohne Einschränkung auf 100 Ergebnisse).

Bei Verwendung von Parameter _total=accurate bitte beachten, dass die Suche mit diesem Suchparameter für den FHIR VZD performance-intensiver ist, da er die akkurate Gesamtanzahl ermitteln muss. Dieser Parameter darf deshalb durch den Client nur benutzt werden, wenn er diese Anzahl benötigt. 

4.1.4 Verlinkung von Personen und Organisationen in FHIR

Im FHIR VZD kann die Zugehörigkeit von Personen (Practitioner) zu Organisationen (Organization) hinterlegt werden. Das Eintragen dieser Verlinkung erfolgt im beidseitigen Einverständnis zwischen Organisation und Leistungserbringern.

Die Verlinkungsanfragen und Bestätigungen werden nicht in FHIR Daten abgelegt, sondern separat abgelegt. Erst mit Erteilung des beidseitigen Einverständnisses wird die Verlinkung in die FHIR Daten eingetragen.

Für das Eintragen der Verlinkungsdaten muss sich der Nutzer authentisieren. Die Authentisierung erfolgt je Rolle über folgende Authentisierungstoken.

1. Leistungserbringer
   
1. Ein Leistungserbringer authentisiert sich über das Owner-Authenticate-Verfahren (mit IDP-Dienst).
   
2. Dabei erhält dieser einen Owner-Authenticate-Token, welcher an der administrativen Schnittstelle genutzt werden kann.
   
2. Verantwortlicher einer Institution (Organisation)
   
1. Der Verantwortliche authentisiert sich über das Owner-Authenticate-Verfahren (vereinfachtes Verfahren SM-B oder IDP-Dienst-Verfahren).
   
2. Dabei erhält dieser einen Owner-Authenticate-Token, welcher an der administrativen Schnittstelle genutzt werden kann.
   
3. Kartenherausgeber (Holder)
   
1. Ein Kartenherausgeber authentisiert sich über die neue Schnittstelle Holder-Authenticate.
   
2. Hierzu verwendet er den bereits bekannten Keycloak, um sich ein entsprechenden Keycloak-IdToken per Client-Secret-Verfahren zu holen.
   
3. Im Anschluss tauscht er diesen Token gegen einen Holder-AccessToken aus, welcher an der administrativen Schnittstelle genutzt werden kann.
   

Akzeptanzkriterien

4.2 FHIR-Proxy

4.2.1 Schnittstellen

Alle Verbindungen des FHIR-Proxy sind TLS-verschlüsselt. Der Proxy weist sich gegenüber den Clients aus. Für den Zugriff der Clients auf den FHIR-VZD werden signierte Access-Tokens vergeben.

4.2.1.1 TLS-Verbindungsaufbau

Der FHIR-Proxy MUSS sich beim TLS-Verbindungsaufbau an den Endpunkten gegenüber Clients mit einem Extended Validation TLS-Zertifikat eines Herausgebers gemäß [CAB-Forum] authentisieren. Das Zertifikat MUSS an die Schnittstelle des Eingangspunkts für Clientsysteme gebunden werden, damit Clientsysteme beim TLS-Verbindungsaufbau eine vereinfachte Zertifikatsprüfung mit TLS-Standardbibliotheken durchführen können.

4.2.1.2 FHIR Schnittstelle für TI-Messenger-Nutzer FHIRDirectorySearchAPI

Endpunkte für die Suche von Einträgen im VZD-FHIR-Directory durch TI-Messenger-Clients

In der Produktionsumgebung (PU) ist die URL: https://fhir-directory.vzd.ti-dienste.de/search   

In der Referenzumgebung (RU) ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/search  

In der Testumgebung (TU) ist die URL: https://fhir-directory-tu.vzd.ti-dienste.de/search 

Authentisierung

Um die Schnittstelle nutzen zu können, MÜSSEN sich die Clients mit einem gültigen Token authentisieren, das von einem Matrix-Homeserver aus der TI-Messenger-Föderation ausgestellt wurde. Im Folgenden werden diese Accesstoken Matrix-OpenID-Token genannt. Nach erfolgreicher Prüfung des Matrix-OpenID-Token stellt der FHIR-Proxy dem TI-Messenger-Client ein neues OAuth Accesstoken aus (search-access_token), das für Suchanfragen des TI-Messenger-Clients verwendet wird.

Das search-access_token enthält folgende Attribute:

Das Attribut "iss" enthält die URL des Endpunktes für die Authentisierung in der jeweiligen Umgebung RU, TU oder PU.

Das Attribut "iss" enthält die URL des Endpunktes für die Authentisierung in der jeweiligen Umgebung RU, TU oder PU.

Das Attribut "aud" enthält die URLs der Endpunkte in der jeweiligen Umgebung RU, TU oder PU.

Das Attribut "sub" enthält die TI-Messenger Adresse des authentifizierten Nutzers.

Die zeitliche Gültigkeit des search-access_tokens beträgt 24 Stunden.

Endpunkte für die Authentisierung

In der Produktionsumgebung (PU) ist die URL: https://fhir-directory.vzd.ti-dienste.de/tim-authenticate   

In der Referenzumgebung (RU) ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/tim-authenticate 

In der Testumgebung (TU) ist die URL: https://fhir-directory-tu.vzd.ti-dienste.de/tim-authenticate 

Operationen

Die FHIR-Operationen für die Suche nach Einträgen im VZD-FHIR-Directory sind in der HL7-FHIR-Spezifikation (https://www.hl7.org/fhir/http.html ) festgelegt.

Zusätzlich zur HL7-FHIR-Spezifikation muss der FHIR VZD folgende Suchparameter unterstützen:

• practitioner.qualification
• endpoint.address (z.B. Suche nach TI-Messenger Adresse)

4.2.1.3 FHIR-Schnittstelle für Besitzer FHIRDirectoryOwnerAPI

Die Schnittstelle ermöglicht es den Besitzern einer Telematik-ID, ihren Eintrag im VZD-FHIR-Directory zu ändern. Im bei der Authentifizierung verwendeten Accesstoken ist die Telematik-ID des Nutzers enthalten. Nur der Eintrag (PractitionerDirectory oder OrganizationDirectory) mit der eigenen Telematik-ID darf verändert werden. Dabei dürfen nur die Attribute verändert werden, die nicht vom VZD-LDAP-Directory synchronisiert werden.

Holder können diese Schnittstelle ebenfalls zur Bearbeitung aller FHIR VZD Einträge in ihrer Zuständigkeit (sie sind als Holder im Datensatz eingetragen) nutzen. Die änderbaren Attribute für Holder werden schrittweise ausgebaut. Aktuell können die "Mehrwertdaten" von Apotheken und NCPeH Attribute - die nicht über den LDAP VZD gepflegt werden können - administriert werden. FHIR VZD Datensätze ohne gesetztes Holder Attribut können nicht durch Holder im FHIR VZD gepflegt werden. Dazu muss erst das Holder Attribut des Datensatzes gesetzt werden. Das kann über den LDAP VZD oder durch einen FHIR VZD Super-Administrator erfolgen.

Endpunkte für das Ändern von eigenen Einträgen im VZD-FHIR-Directory durch TI-Messenger Clients und Org-Admin-Clients

In der Produktionsumgebung (PU) ist die URL: https://fhir-directory.vzd.ti-dienste.de/owner  

In der Referenzumgebung (RU) ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/owner 

In der Testumgebung (TU) ist die URL: https://fhir-directory-tu.vzd.ti-dienste.de/owner 

Authentisierung

Um die Schnittstelle nutzen zu können, MÜSSEN sich die Clients mit einem gültigen Accesstoken authentisieren, das vom FHIR-Proxy ausgestellt wurde. Wenn kein gültiges Accesstoken im Client vorhanden ist, dann muss sich der Client an einem IDP der TI-IDP-Föderation authentisieren.

Nur der eigene Eintrag mit einem Identifier passend zur Telematik-ID aus dem Accesstoken KANN bearbeitet werden. Für einen eigenen OrganizationDirectory-Eintrag KÖNNEN weitere HealthcareService-Einträge erstellt und mit dem eigenen OrganizationDirectory-Eintrag verlinkt werden.

Das Accesstoken enthält folgende Attribute:

Das Attribut "iss" enthält die URL des Endpunktes für die Authentisierung in der jeweiligen Umgebung RU, TU oder PU.

Das Attribut "aud" enthält die URL des Endpunktes in der jeweiligen Umgebung RU, TU oder PU.

Die zeitliche Gültigkeit des Owner Accesstokens beträgt 24 Stunden.

Das Holder-Access-Token enthält folgende Attribute:

Das Attribut "iss" enthält die URL des Endpunktes für die Authentisierung in der jeweiligen Umgebung RU, TU oder PU.

Das Attribut "aud" enthält die URL des Endpunktes in der jeweiligen Umgebung RU, TU oder PU.

Die zeitliche Gültigkeit des Holder-Access-Tokens beträgt 24 Stunden.

Das Attribut "Scope" enthält die Rechte, zukünftig auch owner:write.

Endpunkte für die Authentisierung

In der Produktionsumgebung (PU) ist die URL: https://fhir-directory.vzd.ti-dienste.de/owner-authenticate  

In der Referenzumgebung (RU) ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/owner-authenticate   

In der Testumgebung (TU) ist die URL: https://fhir-directory-tu.vzd.ti-dienste.de/owner-authenticate  

FHIR VZD Endpunkte für die Authentisierung mit dem SmartcardIDP

In der Produktionsumgebung (PU) ist die URL: https://fhir-directory.vzd.ti-dienste.de/signin-gematik-idp-dienst 

In der Referenzumgebung (RU) ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/signin-gematik-idp-dienst   

In der Testumgebung (TU) ist die URL: https://fhir-directory-test.vzd.ti-dienste.de/signin-gematik-idp-dienst  

FHIR-VZD-Endpunkte für die Authentisierung mit dem gematik Authenticator und Polling Endpunkt

In der Produktionsumgebung (PU) sind die URLs:

• https://fhir-directory.vzd.ti-dienste.de/owner-authenticate-decoupled 
• https://fhir-directory.vzd.ti-dienste.de/owner-authenticate-poll 
• https://fhir-directory.vzd.ti-dienste.de/signin-gematik-idp-dienst-decoupled 

In der Referenzumgebung (RU) sind die URLs: 

• https://fhir-directory-ref.vzd.ti-dienste.de/owner-authenticate-decoupled 
• https://fhir-directory-ref.vzd.ti-dienste.de/owner-authenticate-poll
• https://fhir-directory-ref.vzd.ti-dienste.de/signin-gematik-idp-dienst-decoupled 

In der Testumgebung (TU) sind die URLs:

• https://fhir-directory-tu.vzd.ti-dienste.de/owner-authenticate-decoupled 
• https://fhir-directory-tu.vzd.ti-dienste.de/owner-authenticate-poll 
• https://fhir-directory-tu.vzd.ti-dienste.de/signin-gematik-idp-dienst-decoupled 

FHIR-VZD-Endpunkte für die Holder Authentisierung (Keycloak-AccessToken) mit Client Credentials

• In der Produktionsumgebung (PU) ist die URL:

https://auth.vzd.ti-dienste.de:9443/auth/realms/RSDirectoryAdministration/protocol/openid-connect/token   

• In der Referenzumgebung (RU) ist die URL:

 https://auth-ref.vzd.ti-dienste.de:9443/auth/realms/RSDirectoryAdministration/protocol/openid-connect/token  

• In der Testumgebung (TU) ist die URL: 

https://auth-test.vzd.ti-dienste.de:9443/auth/realms/RSDirectoryAdministration/protocol/openid-connect/token 

FHIR-VZD-Endpunkte für den Tausch des Keycloak-AccessTokens gegen das Holder-AccessToken

• In der Produktionsumgebung (PU) ist die URL: https://fhir-directory.vzd.ti-dienste.de/holder-authenticate 
• In der Referenzumgebung (RU) ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/holder-authenticate  
• In der Testumgebung (TU) ist die URL: https://fhir-directory-tu.vzd.ti-dienste.de/holder-authenticate 

Operationen

Die FHIR-Operationen für das Ändern von eigenen Einträgen im VZD-FHIR-Directory sind in der HL7-FHIR-Spezifikation (https://www.hl7.org/fhir/http.html ) festgelegt.

Daten

Das VZD-FHIR-Directory Datenmodell wird in Simplifier beschrieben [Simplifier-FHIR-VZD].

Für TI-Anwendungen werden die Kommunikationsadressen in den FHIR Endpoint eingetragen:

Tabelle 4: Tab_VZD_TI-Anwendungen_Endpoint

4.2.1.4 Schnittstelle FHIRDirectoryTIMProviderAPI (I_VZD_TIM_Provider_Services.yaml)

Endpunkte

In der Produktionsumgebung (PU) ist die URL: https://fhir-directory.vzd.ti-dienste.de/tim-provider-services 

In der Referenzumgebung (RU) ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/tim-provider-services 

In der Testumgebung (TU) ist die URL: https://fhir-directory-tu.vzd.ti-dienste.de/tim-provider-services 

Authentisierung

Um die Schnittstelle nutzen zu können, muss sich der Registrierungsdienst des TI-Messenger-Anbieters zuerst mit einem ti-provider-accesstoken authentisieren, das vom TI-Provider OAuth-Server des VZD-Anbieters ausgestellt wurde. Das ti-provider-accesstoken hat eine Gültigkeitsdauer von 5 Minuten. Dieses tauscht er bei dem VZD-FHIR-Directory Auth-Service gegen ein provider-accesstoken, das zur Authentifizierung an der Schnittstelle genutzt wird. 

Das provider-accesstoken enthält folgende Attribute:

Das Attribut "iss" enthält die URL des Endpunktes für die Authentisierung in der jeweiligen Umgebung RU, TU oder PU.

Das Attribut "aud" enthält die URL des Endpunktes in der jeweiligen Umgebung RU, TU oder PU.

Das Attribut "scope" enthält die Berechtigungen.

Die zeitliche Gültigkeit des provider-accesstokens beträgt 24 Stunden. 

Endpunkte für die Authentisierung am VZD-FHIR-Directory Auth-Service

In der Produktionsumgebung (PU) ist die URL: https://fhir-directory.vzd.ti-dienste.de/ti-provider-authenticate
In der Referenzumgebung (RU) ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/ti-provider-authenticate
In der Testumgebung (TU) ist die URL: https://fhir-directory-tu.vzd.ti-dienste.de/ti-provider-authenticate

Endpunkte um mit Client Credentials ein Token zu erhalten, das am Endpunkt ti-provider-authenticate eingetauscht werden kann

In der Referenzumgebung (RU) ist die URL:

 https://auth-ref.vzd.ti-dienste.de:9443/auth/realms/TI-Provider/protocol/openid-connect/token 

In der Testumgebung (TU) ist die URL:

 https://auth-test.vzd.ti-dienste.de:9443/auth/realms/TI-Provider/protocol/openid-connect/token 

In der Produktionsumgebung (PU) ist die URL:

 https://auth.vzd.ti-dienste.de:9443/auth/realms/TI-Provider/protocol/openid-connect/token  

Registrierung

Für den Zugriff auf den TI-Provider OAuth-Server MUSS der TI-Messenger-Anbieter für seinen Registrierungsdienst beim VZD-Anbieter Client-Credentials beantragen. Die Beantragung erfolgt über einen genehmigungspflichtigen Service-Request im TI-ITSM-System.

Die Registrierung und Vergabe der Credentials erfolgt dabei auf Anbieterebene.

Der Antrag MUSS folgende Informationen enthalten, um weiter bearbeitet werden zu können:

• Angaben zur Rolle (hier TI-Messenger-Anbieter) und Organisation des Antragstellers, Erläuterung der Berechtigung und des Bedarfs (zur Verifikation notwendig)
• Kontaktdaten zu Ansprechpartnern beim Antragsteller (2 Personen) inkl. Telefonnummer, E-Mail-Adresse, Anschrift
  
• Angabe der Betriebsumgebung (RU/PU)
• E-Mail-Adresse und dazugehöriges S/MIME-Zertifikat (in einer ZIP-Datei als Anhang), an welche die Zugangsdaten verschlüsselt übermittelt werden können (kostenlose Zertifikate sind z. B. beim DGN erhältlich)
  
• falls bereits vorhanden, eine entsprechende Ticketnummer
• nur bei Deregistrierung durch den Antragsteller: vorab vergebene Client-ID
• gewünschte Bezeichnung in der clientID.
• Registrierungsserver id_token Signatur-Zertifikat (wird für die vereinfachte Authentisierung an dieser Schnittstelle bei der Token Prüfung benötigt)
  

Nach Prüfung der Angaben, werden die Zugangsdaten direkt vom Anbieter Zentrale Plattformdienste (vgl. gemKPT_Betr) an die gewünschte E-Mail-Adresse übermittelt.

Es ist zu beachten, dass dieser Prozess ausschließlich für Neuanlagen und Löschungen vorgesehen ist. Änderungen oder der Neuversand von Zugangsdaten können nicht bearbeitet werden.

Operationen

Die Schnittstelle ist in I_VZD_TIM_Provider_Services.yaml als OpenAPI RESTful Service spezifiziert.

https://github.com/gematik/api-vzd/blob/main/src/openapi/I_VZD_TIM_Provider_Services.yaml 

Tabelle 5: Tab_VZD_TIM-Provider-Services_Operations

Im Attribut "sub" des Accesstokens ist die client_id des TI-Messenger-Registrierungsdienstes enthalten.

Bei Hinzufügen einer Domain zur Föderation (addTiMessengerDomain) MUSS der FHIR VZD prüfen, ob für die dazugehörende telematikID eine aktive Organisation vorliegt.

4.2.1.5 FHIR Schnittstelle für Versicherte FHIRDirectoryFdvSearchAPI

Endpunkte für die Suche von Einträgen im VZD-FHIR-Directory durch Versicherte

In der Produktionsumgebung (PU) ist die URL: https://fhir-directory.vzd.ti-dienste.de/fdv/search    

In der Referenzumgebung (RU) ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/fdv/search  

In der Testumgebung (TU) ist die URL: https://fhir-directory-tu.vzd.ti-dienste.de/fdv/search 

Authentisierung

Um die Schnittstelle nutzen zu können, MÜSSEN sich die Clients mit einem gültigen search-access_token authentisieren, das vom FHIR-Directory Auth-Service ausgestellt wurde. Das search-access_token erhalten Fachdienste nach Authentisierung am FHIR-OAuth-Server /token Endpunkt im Austausch gegen das service-authz-token und TIM-Clients von Versicherten nach Authentisierung am Matrix-Homeserver im Austausch gegen das Matrix-OpenID-Token.

Das search-access_token enthält - bei Authentisierung über Client Credentials (Fachdienste und Versicherte) - folgende Attribute:

Das search-access_token (TIM-Clients von Versicherten) enthält folgende Attribute:

Das Attribut "iss" enthält die URL des Endpunktes für die Authentisierung in der jeweiligen Umgebung RU, TU oder PU.

Das Attribut "aud" enthält die URLs der Endpunkte in der jeweiligen Umgebung RU, TU oder PU.

Das Attribut "sub" enthält die TI-Messenger Adresse des authentifizierten Nutzers bzw. die ClientID bei Authentisierung über Client Credentials.

Die zeitliche Gültigkeit des search-access_tokens beträgt 24 Stunden.

Endpunkte um mit Client Credentials ein Token zu erhalten, das am Endpunkt service-authenticate eingetauscht werden kann

In der Referenzumgebung (RU) ist die URL:

 https://auth-ref.vzd.ti-dienste.de:9443/auth/realms/Service-Authenticate/protocol/openid-connect/token  

In der Testumgebung (TU) ist die URL:

 https://auth-test.vzd.ti-dienste.de:9443/auth/realms/Service-Authenticate/protocol/openid-connect/token 

In der Produktionsumgebung (PU) ist die URL:

 https://auth.vzd.ti-dienste.de:9443/auth/realms/Service-Authenticate/protocol/openid-connect/token   

Endpunkte für die Authentisierung (Fachdienste)

In der Produktionsumgebung (PU) ist die URL: https://fhir-directory.vzd.ti-dienste.de/service-authenticate 

In der Referenzumgebung (RU) ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/service-authenticate 

In der Testumgebung (TU) ist die URL: https://fhir-directory-tu.vzd.ti-dienste.de/service-authenticate 

Endpunkte für die Authentisierung (TIM-Clients von Versicherten)

In der Produktionsumgebung (PU) ist die URL: https://fhir-directory.vzd.ti-dienste.de/tim-authenticate   

In der Referenzumgebung (RU) ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/tim-authenticate 

In der Testumgebung (TU) ist die URL: https://fhir-directory-tu.vzd.ti-dienste.de/tim-authenticate 

Operationen

Die FHIR-Operationen für die Suche nach Einträgen im VZD-FHIR-Directory sind in der HL7-FHIR-Spezifikation (https://www.hl7.org/fhir/http.html ) festgelegt.

Zusätzlich zur HL7-FHIR-Spezifikation muss der FHIR VZD folgende Suchparameter unterstützen:

• practitioner.qualification
• endpoint.address (z.B. Suche nach TI-Messenger Adresse)

Falls der Versicherte im Rahmen einer Anwendung nur eine Teilmenge aus dem VZD-FHIR-Directory sehen soll (z.B. nur Apotheken oder nur bestimmte Organisationen), muss das durch den Client durch eine geeignete Suche sichergestellt werden.

Sichtbarkeit von FHIR-Ressourcen

Die Sichtbarkeit von definierten FHIR-Ressourcen kann vom Eigentümer (Owner) des FHIR-VZD-Eintrags eingeschränkt werden. Folgende Einschränkungen der Sichtbarkeit sind möglich:

• Die gesamte Organisation (FHIR Ressource "Organization" über Organization.extension:organizationVisibility == hide-versicherte)
• Kommunikations-Endpunkte (FHIR Ressource "Endpoint" über Endpoint.extension:endpointVisibility == hide-versicherte)

FHIR-Ressourcen mit eingeschränkter Sichtbarkeit werden an Schnittstelle FHIRDirectoryFdvSearchAPI (/fdv/search) durch den FHIR VZD aus dem Suchergebnis entfernt. Bei der FHIR-Ressource "Organization" werden auch alle verlinkten FHIR-Ressourcen aus dem Suchergebnis entfernt.

Die Sichtbarkeit seiner FHIR-Ressourcen kann der Eigentümer (Owner) über die Schnittstelle für Besitzer FHIRDirectoryOwnerAPI (/owner) verwalten.

4.2.1.6 Schnittstelle zum Lesen von Zertifikaten von Verzeichniseinträgen I_FHIR_VZD_Certificates

Endpunkte zum Lesen von Zertifikaten von Verzeichniseinträgen (read_FhirVZD_Certificates)

In der Produktionsumgebung (PU) ist die URL: https://fhir-directory.vzd.ti-dienste.de/certificates/Certificates  

In der Referenzumgebung (RU) ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/certificates/Certificates  

In der Testumgebung (TU) ist die URL: https://fhir-directory-tu.vzd.ti-dienste.de/certificates/Certificates  

Abfrageschnittstelle Zertifikat-Version (getInfo)

In der Produktionsumgebung (PU) ist die URL: https://fhir-directory.vzd.ti-dienste.de/certificates/

In der Referenzumgebung (RU) ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/certificates/

In der Testumgebung (TU) ist die URL: https://fhir-directory-tu.vzd.ti-dienste.de/certificates/

Authentisierung

Um die Schnittstelle nutzen zu können, MÜSSEN sich die Clients mit einem gültigen Token authentisieren, das vom FHIR-Directory Auth-Service ausgestellt wurde. Akzeptiert werden die folgenden Token:

• search-access_token von der FHIRDirectorySearchAPI Schnittstelle (/search)
• search-access_token von der FHIRDirectoryFdvSearchAPI Schnittstelle (/fdv/search)
• Accesstoken von der FHIRDirectoryOwnerAPI Schnittstelle (/owner) 

Operationen

Die Schnittstelle ist in I_FHIR_VZD_Certificates.yaml als OpenAPI RESTful Service spezifiziert.

https://github.com/gematik/api-vzd/blob/main/src/openapi/I_FHIR_VZD_Certificates.yaml 

Tabelle 6: Tab_I_FHIR_VZD_Certificates_Operations

Akzeptanzkriterien

4.2.1.7 Schnittstelle zum Lesen der fachlichen Logs I_FHIR_VZD_Fachliches_Log

Berechtigte Nutzer (Owner oder Holder) können per Schnittstellenabfrage relevante Informationen aus dem fachlichen Log erhalten.

Die Schnittstelle ist in I_FHIR_VZD_Fachliches_Log.yaml als OpenAPI RESTful Service spezifiziert:
https://github.com/gematik/api-vzd/blob/main/src/openapi/I_FHIR_VZD_Fachliches_Log.yaml

Endpunkte zum Lesen der fachlichen Logs

• In der Produktionsumgebung (PU) ist die URL:  ttps://fhir-directory.vzd.ti-dienste.de/fachliches-log/log
• In der Referenzumgebung (RU) ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/fachliches-log/log
• In der Testumgebung (TU) ist die URL:  https://fhir-directory-tu.vzd.ti-dienste.de/fachliches-log/log

Um die Schnittstelle nutzen zu können, müssen sich die Clients mit einem gültigen Token authentisieren, das vom FHIR-Directory Auth-Service ausgestellt wurde. Akzeptiert werden die folgenden Token:

• Accesstoken von der FHIRDirectoryOwnerAPI Schnittstelle I_VZD_Owner
  
• Accesstoken von der FHIRDirectoryHolderAPI Schnittstelle I_VZD_Holder_Authenticate_Service
  

Die Schnittstelle ist in I_FHIR_VZD_Fachliches_Log.yaml als OpenAPI RESTful Service spezifiziert:
https://github.com/gematik/api-vzd/blob/main/src/openapi/I_FHIR_VZD_Fachliches_Log.yaml

Tabelle 7: Tab_I_FHIR_VZD_Fachliches_Log_Operations

Der Inhalt des fachlichen Logs wird in Tab_I_FHIR_VZD_Fachliches_Log_Inhalt erläutert.

Tabelle 8: Tab_I_FHIR_VZD_Fachliches_Log_Inhalt

4.2.2 Aktualisierung der Basiseinträge

Der FHIR-Proxy aktualisiert regelmäßig die Basiseinträge im VZD-FHIR-Directory mit den geänderten Daten des VZD-LDAP-Directories (siehe AF_10047 Einträge mit dem VZD-LDAP-Directory abgleichen). Das Intervall für die regelmäßige Aktualisierung MUSS konfigurierbar sein und wird initial auf 2 Stunden festgelegt. 

Es MUSS (analog dem Background-Sync-Verfahren in die LDAP flache Liste) eine weitere Synchronisation mittels PUSH in den FHIR VZD möglich sein.

Zukünftig ist vorgesehen, dass Kartenherausgeber direkt die Basiseinträge ihrer Mitglieder im VZD-FHIR-Directory über eine FHIR-Schnittstelle verwalten können.

4.2.3 Erzeugung und Bereitstellung der Föderationsliste

Die Föderationsliste MUSS bei Änderung der Domains und/oder telematikIDs durch TI-Messenger-Anbieter neu erzeugt und zum Download über die Schnittstelle I_VZD_TIM_Provider_Services bereitgestellt werden.

Die Föderationsliste hat folgende Struktur:

Zu Domänen, die Accounts von Versicherten bereitstellen (isInsurance: true) MUSS mindestens ein Institutionskennzeichen (IK) eingetragen werden. Bei Einträgen mit dem Wert (isInsurence:false) DARF kein IK hinterlegt werden. Ein IK DARF in der gesamten Föderationsliste nur einmal enthalten sein.

Das VZD-FHIR-Directory MUSS für das Format des IK sicherstellen:

Das Institutionskennzeichen MUSS aus einer neunstelligen Ziffernfolge bestehen, deren erste 2 Stellen (Klassifikation für Krankenversicherungsträger) einem Wert aus einer konfigurierbaren Liste entsprechen muss. Initial enthält diese konfigurierbare Liste die Werte

• "10" (Krankenversicherungsträger),
• "16" (Private Krankenversicherungen) und
• "95" (Krankenversicherungsträger außerhalb der gesetzlichen Krankenversicherung).

Beim Hinterlegen von Institutionskennzeichen MÜSSEN diese - entsprechend [GR-IK-2023-11] Kapitel 1.2.5 - gegen die enthaltene Prüfziffer validiert werden und nur bei erfolgreicher Prüfung der Eintrag erstellt werden.

Der Wert für "timAnbieter" MUSS vom AZPD bei der Beantragung der Credentials des TI-Messenger Anbieters/-Herstellers erfasst und bei jeder Änderung der anderen Felder vom VZD-FHIR-Directory aktualisiert werden. Der Wert für "timAnbieter" DARF AUSSCHLIEßLICH durch den AZPD bzw. durch das VZD-FHIR-Directory geändert werden. Mit dieser Automatisierung sollen manuelle Fehler beim Setzen durch die Nutzer vermieden werden.

Die redirectDomains werden mit dem Förderationseintrag persistiert und vom Proxy freigeschaltet.
Ohne entsprechende Pflege von RedirectDomains ist der Aufruf entsprechender URLs bei der Matrix-Server-Discovery (z.B. bei einem Redirect) nicht möglich.

Die Föderationsliste MUSS mit einer JWS gemäß RFC7797 signiert werden. Der zu verwendende Signatur-Algorithmus MUSS "ES256" oder "BP256R1" sein. Der Signatur-Algorithmus wird vom Client - beim Abruf der Föderationsliste - über Parameter "sigAlg" gewählt. Für die Signatur MUSS ein Signatur-Zertifikat der Komponenten-PKI der TI (C.FD.SIG) verwendet werden. Das Signatur-Zertifikat MUSS im Signatur-Header enthalten sein.

Der Signatur-Header hat folgende Struktur:

Die signierte Föderationsliste hat gemäß RFC7797 folgende Struktur:

Signatur-Header.Föderationsliste.Signatur

Die einzelnen Bestandteile der signierten Föderationsliste sind Base64 kodiert.  

Ein Beispiel für die Föderationsliste:   

eyJhbGciOiJCUDI1NlIxIiwieDVjIjpbIk1JSUMrVENDQXFDZ0F3SUJBZ0lDYkFZd0NnWUlLb1pJemowRUF3SXdnWVF4Q3pBSkJnTlZCQVlUQWtSRk1SOHdIUVlEVlFRS0RCWm5aVzFoZEdscklFZHRZa2dnVGs5VUxWWkJURWxFTVRJd01BWURWUVFMRENsTGIyMXdiMjVsYm5SbGJpMURRU0JrWlhJZ1ZHVnNaVzFoZEdscmFXNW1jbUZ6ZEhKMWEzUjFjakVnTUI0R0ExVUVBd3dYUjBWTkxrdFBUVkF0UTBFMU1DQlVSVk5VTFU5T1RGa3dIaGNOTWpNd01USTFNVEEwTXpVMldoY05Namd3TVRJME1UQTBNelUxV2pCek1Rc3dDUVlEVlFRR0V3SkVSVEV5TURBR0ExVUVDZ3dwWVhKMllYUnZJRk41YzNSbGJYTWdSMjFpU0NCVVJWTlVMVTlPVEZrZ0xTQk9UMVF0VmtGTVNVUXhFREFPQmdOVkJBVVRCekF3TURBeExVRXhIakFjQmdOVkJBTU1GVlphUkMxR1NFbFNMVVpNYVhOMExWTnBaMjVsY2pCYU1CUUdCeXFHU000OUFnRUdDU3NrQXdNQ0NBRUJCd05DQUFRWXRpc3hVUEpTdUMwdG85bE9zMXpkblJwZWJaMGljaGNnaTFzTnQ4YnVDMm5IVFBIQm5DVHJ3ZklNS1k5TEFSYU9zM05RQUlsM0xSM1podVRHcWM4bW80SUJEekNDQVFzd0hRWURWUjBPQkJZRUZKK20wTnh3RHc2L1BxRmw5NzlxdWMwYlA0YWJNQjhHQTFVZEl3UVlNQmFBRkRyaXFpV1NUcXlwbEgzUEdXbnFFd2E1cUREVE1FOEdDQ3NHQVFVRkJ3RUJCRU13UVRBL0JnZ3JCZ0VGQlFjd0FZWXphSFIwY0RvdkwyOWpjM0F5TFhSbGMzUnlaV1l1YTI5dGNDMWpZUzUwWld4bGJXRjBhV3N0ZEdWemRDOXZZM053TDJWak1BNEdBMVVkRHdFQi93UUVBd0lIZ0RBaEJnTlZIU0FFR2pBWU1Bb0dDQ3FDRkFCTUJJRWpNQW9HQ0NxQ0ZBQk1CSUZMTUF3R0ExVWRFd0VCL3dRQ01BQXdOd1lGS3lRSUF3TUVMakFzTUNvd0tEQW1NQ1F3Rmd3VVZtVnllbVZwWTJodWFYTmthV1Z1YzNRdFZFa3dDZ1lJS29JVUFFd0VnU3N3Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUlnVDJCUmJDSUltT3BTVUgvNTB5U1EvQ1ppOEV6bEF4Qkg0RXJMdGxvWURHY0NJR1hjUjJZZzRocG9VS2U3cHFIamJQSGU5Y2liUjNHZGVtNG5uQ25NVHJ1ZSJdLCJ0eXAiOiJKV1QifQ.eyJ2ZXJzaW9uIjoxMjgyLCJkb21haW5MaXN0IjpbeyJkb21haW4iOiJkdW1teURvbWFpbiIsInRlbGVtYXRpa0lEIjoiMS0xZ2VtdGVzdC1vd25lci0wMDAxIiwidGltQW5iaWV0ZXIiOm51bGwsImlzSW5zdXJhbmNlIjpmYWxzZX0seyJkb21haW4iOiJEdW1teURvbWFpbjIiLCJ0ZWxlbWF0aWtJRCI6IjEtMWdlbXRlc3Qtb3duZXItMDAwMSIsInRpbUFuYmlldGVyIjpudWxsLCJpc0luc3VyYW5jZSI6ZmFsc2V9LHsiZG9tYWluIjoibWVzc2VuZ2VyLnNwaWxpa2luLmRldiIsInRlbGVtYXRpa0lEIjoiMS0yYXJ2dHN0LWFwMDAwMDAwIiwidGltQW5iaWV0ZXIiOm51bGwsImlzSW5zdXJhbmNlIjpmYWxzZX0seyJkb21haW4iOiJ0aS1tZXNzZW5nZXIuZG9tYWluIiwidGVsZW1hdGlrSUQiOiIxLTJhcnZ0c3QtYXAwMDAwOTQiLCJ0aW1BbmJpZXRlciI6bnVsbCwiaXNJbnN1cmFuY2UiOmZhbHNlfSx7ImRvbWFpbiI6InRpLW1lc3Nlbmdlci5nZG9tYWluIiwidGVsZW1hdGlrSUQiOiIxLTJhcnZ0c3QtYXAwMDAwOTQiLCJ0aW1BbmJpZXRlciI6bnVsbCwiaXNJbnN1cmFuY2UiOmZhbHNlfSx7ImRvbWFpbiI6IjI5ZGg5MmdzMzNqZDAxMC5sb2NhbGhvc3QiLCJ0ZWxlbWF0aWtJRCI6IjI5ZGg5MmdzMzNqZCIsInRpbUFuYmlldGVyIjoiT1JHLTAwMjI6QlQtMDE1MiIsImlzSW5zdXJhbmNlIjpmYWxzZX0seyJkb21haW4iOiIyNjE2YjNmMzczYjkwMDEudHUudGltcmVmLmFrcXVpbmV0Lm54Mi5kZXYiLCJ0ZWxlbWF0aWtJRCI6IjI2MTZiM2YzNzNiOSIsInRpbUFuYmlldGVyIjoiT1JHLTAwMjI6QlQtMDE1MiIsImlzSW5zdXJhbmNlIjpmYWxzZX0seyJkb21haW4iOiIyOWRoOTJnczMzamQwMDEudHUudGltcmVmLmFrcXVpbmV0Lm54Mi5kZXYiLCJ0ZWxlbWF0aWtJRCI6IjI5ZGg5MmdzMzNqZCIsInRpbUFuYmlldGVyIjoiT1JHLTAwMjI6QlQtMDE1MiIsImlzSW5zdXJhbmNlIjpmYWxzZX0seyJkb21haW4iOiIyOWRoOTJnczMzamQ1MGYudHUudGltcmVmLmFrcXVpbmV0Lm54Mi5kZXYiLCJ0ZWxlbWF0aWtJRCI6IjI5ZGg5MmdzMzNqZCIsInRpbUFuYmlldGVyIjoiT1JHLTAwMjI6QlQtMDE1MiIsImlzSW5zdXJhbmNlIjpmYWxzZX0seyJkb21haW4iOiJtc2dzcnYxLmRldi50aW1wbHVzLmFydmF0by1zeXN0ZW1zLmRlIiwidGVsZW1hdGlrSUQiOiIxMS1TTUMtQi1UZXN0a2FydGUtODgzMTEwMDAwMTM5ODU4IiwidGltQW5iaWV0ZXIiOm51bGwsImlzSW5zdXJhbmNlIjpmYWxzZX0seyJkb21haW4iOiJtYXRyaXguZGV2LnNlcnZpY2UtdGkuZGUiLCJ0ZWxlbWF0aWtJRCI6IjEtMWdlbXRlc3Qtb3duZXItMDAwMSIsInRpbUFuYmlldGVyIjpudWxsLCJpc0luc3VyYW5jZSI6ZmFsc2V9LHsiZG9tYWluIjoidHAwNGEuZGUiLCJ0ZWxlbWF0aWtJRCI6IjEtMjAwMTA1NDc0NjIiLCJ0aW1BbmJpZXRlciI6bnVsbCwiaXNJbnN1cmFuY2UiOmZhbHNlfSx7ImRvbWFpbiI6InRwMDYuMDYuZGUiLCJ0ZWxlbWF0aWtJRCI6IjEtMjAwMTAyODAwNDEiLCJ0aW1BbmJpZXRlciI6bnVsbCwiaXNJbnN1cmFuY2UiOmZhbHNlfSx7ImRvbWFpbiI6IjI5ZGg5MmdzMzNqZDAxMS5sb2NhbGhvc3QiLCJ0ZWxlbWF0aWtJRCI6IjI5ZGg5MmdzMzNqZCIsInRpbUFuYmlldGVyIjoiT1JHLTAwMjI6QlQtMDE1MiIsImlzSW5zdXJhbmNlIjpmYWxzZX0seyJkb21haW4iOiJ0cDA1LjAxLmZyIiwidGVsZW1hdGlrSUQiOiIxLTIwMDEwNjMyNTExIiwidGltQW5iaWV0ZXIiOm51bGwsImlzSW5zdXJhbmNlIjpmYWxzZX0seyJkb21haW4iOiJwZXJmb3JtYW5jZTU5LnRlc3QuYXJ2YXRvLmRlIiwidGVsZW1hdGlrSUQiOiIxLTIwNzIwMjQ4MDQ0IiwidGltQW5iaWV0ZXIiOm51bGwsImlzSW5zdXJhbmNlIjp0cnVlfSx7ImRvbWFpbiI6InBlcmZvcm1hbmNlMTAudGVzdC5hcnZhdG8uZGUiLCJ0ZWxlbWF0aWtJRCI6IjEtMjA3MjA1MTA1NDIiLCJ0aW1BbmJpZXRlciI6bnVsbCwiaXNJbnN1cmFuY2UiOmZhbHNlfSx7ImRvbWFpbiI6InRwMDYuZGUiLCJ0ZWxlbWF0aWtJRCI6IjEtMjAwMTA1MjM0NDIiLCJ0aW1BbmJpZXRlciI6bnVsbCwiaXNJbnN1cmFuY2UiOmZhbHNlfSx7ImRvbWFpbiI6InRwMDdQYXJ0aWFsTmFtZS5kZSIsInRlbGVtYXRpa0lEIjoiMS0yMDQ3MDAxMjA4MyIsInRpbUFuYmlldGVyIjpudWxsLCJpc0luc3VyYW5jZSI6ZmFsc2V9LHsiZG9tYWluIjoidHAwNi0wMS5kZSIsInRlbGVtYXRpa0lEIjoiMS0yMDAxMDk4OTk4MyIsInRpbUFuYmlldGVyIjpudWxsLCJpc0luc3VyYW5jZSI6ZmFsc2V9LHsiZG9tYWluIjoidHAwNi0wMi5kZSIsInRlbGVtYXRpa0lEIjoiMS0yMDAxMDc2NzY1NiIsInRpbUFuYmlldGVyIjpudWxsLCJpc0luc3VyYW5jZSI6ZmFsc2V9LHsiZG9tYWluIjoidHAwNi0wMy5kZSIsInRlbGVtYXRpa0lEIjoiMS0yMDAxMDI4ODQ2NiIsInRpbUFuYmlldGVyIjpudWxsLCJpc0luc3VyYW5jZSI6ZmFsc2V9LHsiZG9tYWluIjoidHAwNi0wNC5kZSIsInRlbGVtYXRpa0lEIjoiMS0yMDAxMDYxOTM4OCIsInRpbUFuYmlldGVyIjpudWxsLCJpc0luc3VyYW5jZSI6ZmFsc2V9LHsiZG9tYWluIjoiYXJ2YXRvLnR1LnRpbXJlZi5ha3F1aW5ldC5ueDIuZGV2IiwidGVsZW1hdGlrSUQiOiIxLTJhcnZ0c3QtYXAwMDAwMDAiLCJ0aW1BbmJpZXRlciI6bnVsbCwiaXNJbnN1cmFuY2UiOmZhbHNlfSx7ImRvbWFpbiI6InRwMDYuMDUuZGUiLCJ0ZWxlbWF0aWtJRCI6IjEtMjAwMTA0NzM1NzYiLCJ0aW1BbmJpZXRlciI6bnVsbCwiaXNJbnN1cmFuY2UiOmZhbHNlfSx7ImRvbWFpbiI6InRwMDcuMDMuZGUiLCJ0ZWxlbWF0aWtJRCI6IjEtMjA0NzAyNzI3OTAiLCJ0aW1BbmJpZXRlciI6bnVsbCwiaXNJbnN1cmFuY2UiOmZhbHNlfSx7ImRvbWFpbiI6InRwMDgtMDEuZGUiLCJ0ZWxlbWF0aWtJRCI6IjEtMjA0NzA2MTQ1MjAiLCJ0aW1BbmJpZXRlciI6bnVsbCwiaXNJbnN1cmFuY2UiOmZhbHNlfSx7ImRvbWFpbiI6InRwMDkuMDAuZGUiLCJ0ZWxlbWF0aWtJRCI6IjEtMWFydnRzdC10ZXN0b3JnLXRwMDkuMDAiLCJ0aW1BbmJpZXRlciI6bnVsbCwiaXNJbnN1cmFuY2UiOmZhbHNlfSx7ImRvbWFpbiI6InRwMDkuMDEuZGUiLCJ0ZWxlbWF0aWtJRCI6IjEtMWFydnRzdC10ZXN0b3JnLXRwMDkuMDEiLCJ0aW1BbmJpZXRlciI6bnVsbCwiaXNJbnN1cmFuY2UiOmZhbHNlfSx7ImRvbWFpbiI6InRwMDkuMDIuZGUiLCJ0ZWxlbWF0aWtJRCI6IjEtMWFydnRzdC10ZXN0b3JnLXRwMDkuMDIiLCJ0aW1BbmJpZXRlciI6bnVsbCwiaXNJbnN1cmFuY2UiOmZhbHNlfSx7ImRvbWFpbiI6InRpLW1lc3Nlbmdlci50ZXN0Mi5nZG9tYWluIiwidGVsZW1hdGlrSUQiOiIxLTJhcnZ0c3QtYXAwMDAwOTMiLCJ0aW1BbmJpZXRlciI6bnVsbCwiaXNJbnN1cmFuY2UiOmZhbHNlfV19.TLmI56NcYPyMT6DcS56RnCeuJ9NuCZfqmQhjmSoLm29V91ez-7uRuVcRHgu4tdLSk7Zldt-yM3MUST95CdMq3Q

4.2.4 Lokalisierung einer MXID (Operation whereIs)

Die Operation prüft, in welchem Teil des Directorys (Organisation, Person) eine MXID enthalten ist, und gibt das Prüfergebnis zurück. Übergeben wird die MXID an die Operation in URL Form.
Damit diese Operation performant ist, darf bei Aufruf der Operation nicht der gesamte FHIR Datenbestand durchsucht werden. Dies kann z. B. durch eine Performance-optimierte Tabelle mit den MXIDs und dazugehörigem Ergebnis gewährleistet werden.

Die Authentisierung des Clients erfolgt für Operation whereIs entsprechend Kapitel 4.2.1.4 Schnittstelle FHIRDirectoryTIMProviderAPI.

Der FHIR-Proxy MUSS die Lokalisierung einer MXID über Operation whereIs performant bereitstellen. Dazu MUSS der FHIR-Proxy bei jeder Änderung an den Endpoint-Einträgen (der MXID darin) die benötigten Daten für die performante Antwort der whereIs Operation aktualisieren. Der FHIR-Proxy DARF NICHT die originalen FHIR-Daten für die Ausführung der whereIs Operation durchsuchen.

4.3 Übergreifende Vorgaben

4.3.1 Sicherheit und Datenschutz

Die folgenden Vorgaben gelten auch für den FHIR-VZD.

Die 100 Suchergebnisse beziehen sich auf die FHIR-Ressourcen HealthcareService bzw. PractitionerRole. Alle referenzierten und durch Suchparameter "_include" einbezogenen Ressourcen werden bei der Begrenzung der Suchergebnisse nicht mitgezählt.

Das Bundle im FHIR-Suchergebnis MUSS immer zu jeder enthaltenen FHIR-Ressource HealthcareService bzw. PractitionerRole alle referenzierten und durch "_include" einbezogenen Ressourcen enthalten und damit ein vollständiges Paket der enthaltenen Ressourcen darstellen.

Das X.509-Root-CA Zertifikat MUSS für Zertifikatsprüfungen im Truststore des FHIR VZD gespeichert sein.

Der FHIR VZD MUSS wöchentlich prüfen, ob neue X.509-Root-CA-Versionen existieren und Cross-Zertifikate verfügbar sind. Falls dies der Fall ist, so MUSS der FHIR VZD diese neuen Root-Versionen in seinen Truststore importieren.

Nach der Erzeugung einer neuen Root-Version der X.509-Root-CA der TI wird dessen selbstsigniertes Zertifikat und Cross-Zertifikate auf den Download-Punkt gemäß [ROOT-CA] abgelegt. Automatisiert kann der FHIR VZD von dort die Verfügbarkeit neuer Versionen überwachen. Zusätzlich kann der folgende Download-Punkt unter [ROOT-CA-JSON] verwendet werden. Dort werden die aktuellen Root-Zertifikate inkl. deren Cross-Zertifikate gepflegt. Im Regelfall wird alle zwei Jahre eine neue Root-Version erzeugt. Die Dateigröße der heruntergeladenen JSON-Datei kann man als Hashfunktion verwenden. Hiermit kann man beispielsweise mit Hilfe des Tools curl die HTTP-Methode HEAD verwenden und damit erfahren ob die lokale Kopie der JSON-Datei noch aktuell ist. Die JSON-Datei ist ein Array, in dem Associative Arrays als Elemente aufgeführt werden. Diese Elemente enthalten je ein Root-Zertifikat inkl. Cross-Zertifikate für das chronologisch vorhergehende und das nachfolgende Root-Zertifikat. D. h., kryptographisch gesehen stellt dies eine doppelt verkettete Liste dar.

Die Sub-CA Zertifikate werden auf dem Download-Punkt gemäß [Sub-CA] abgelegt.

4.3.2 Betrieb

In diesem Kapitel werden übergreifende, betriebliche Anforderungen getroffen oder auf Kapitel mit speziellen Ausprägungen für den Verzeichnisdienst FHIR Directory in normativen Querschnittsdokumenten verwiesen.

Die vollständige Auflistung aller Schnittstellen und Endpunkte finden sich in [gemKPT_Betr#5.3.2.26].

Die spezifischen Anforderungen zu Last und Performance finden sich in [gemSpec_Perf#3.24.1.3].

Die spezifischen Anforderungen zur Lieferung von Betriebsdaten finden sich in [gemSpec_Perf#3.24.2].

4.3.3 FHIR-Suchoptionen

Die Suche im FHIR VZD basiert auf den Standard-FHIR-Suchmöglichkeiten https://build.fhir.org/search.html.

In diesem Kapitel werden Suchoptionen mit besonderer Bedeutung für TI-Anwendungen beschrieben.

4.3.3.1 FHIR-Umkreissuche

Der FHIR VZD muss die Umkreissuche um eine bestimmte Geoposition unterstützen. Dafür muss die FHIR-Suche über den "near" Parameter für Location Ressourcen erlaubt werden https://www.hl7.org/fhir/location.html#8.7.6.1.1, https://build.fhir.org/location.html#search 

Der Client muss bei der Umkreissuche alle "near" Suchparameter obligatorisch angeben ([latitude]|[longitude]|[distance]|[units]).

4.3.4 Anforderungen an FHIR-VZD-Clients

Zur Vermeidung von betrieblichen Problemen wird in diesem Kapitel das gewünschte Verhalten von VZD Clients beschrieben. Diese Anforderungen werden in der PU nicht automatisch durchgesetzt. Bei Auffälligkeiten und betrieblichen Problemen in der PU erfolgt eine manuelle Analyse z.B. auf Basis des Monitorings. Mit den Herstellern/Betreibern der betroffenen Clients erfolgen Rücksprachen zur Klärung. Eine Sperrung des VZD-Zugangs für Clients wird nur manuell in dringenden Fällen erfolgen.
Bei Zulassungen kann die Einhaltung der Vorgaben durch diese Anforderungen geprüft werden.

In diesem Kapitel wird unter einem "VZD Client" die Instanz der Softwarekomponente verstanden, die eine Verbindung zum VZD aufbaut (z.B. KIM Clientmodul, Primärsystem, Thunderbird, FdV, Softwarekomponente der Kartenherausgeber zur Administration ihrer Daten,...). Wenn diese Softwarekomponente mandantenfähig ist, wird jeder Mandant als VZD Client angesehen. Damit können die Mandanten unabhängig voneinander mit dem VZD kommunizieren. Parallele Prozesse (z. B. Threads) innerhalb einer Komponente werden nicht als eigenständige VZD-Clients betrachtet.

Beispielhafte Abfrage zur effizienten Arztsuche:

https://fhir-directory-tu.vzd.ti-dienste.de/fdv/search/HealthcareService?organization.active=true &_text=Mustermann&_include=HealthcareService%3Aorganization &_include=HealthcareService%3Alocation

Diese Abfrage kombiniert Volltextsuche mit gezieltem Einbinden abhängiger Ressourcen in einer einzigen Anfrage und reduziert dadurch zusätzliche Roundtrips zur FHIR-Schnittstelle.

5 Anwendungsfälle

5.1 TI-Messenger-Nutzer sucht Einträge im FHIR-Directory

Akzeptanzkriterien für den Anwendungsfall AF_10036 Nutzer sucht OrganizationDirectory- und PractitionerDirectory-Einträge im VZD-FHIR-Directory

5.2 Eigentümer ändert seinen Eintrag und sucht im FHIR-Directory

Ein Org-Admin-Account kann am Registrierungsdienst nur angelegt werden, wenn eine erfolgreiche Authentisierung einer Organisation durchgeführt wurde. Dafür muss das FHIR-Directory den Registrierungsdiensten aller TI-Messenger-Anbieter vertrauen und die erforderlichen Daten (telematikID, Zertifikatstyp, technische Rolle) im id_token des Registrierungsdienstes prüfen.

Das Vertrauen zu den Registrierungsdiensten der TI-Messenger Anbieter wird bei der Registrierung des TI-Messenger-Anbieters
beim FHIR-Directory für die Schnittstelle I_VZD_TIM_Provider_Services hergestellt (siehe auch Kap. 4.2.1.4 Schnittstelle FHIRDirectoryTIMProviderAPI).

• Bei der Registrierung des TI-Messenger-Anbieters wird das Signatur-Zertifikat, das für die Signatur des id_tokens verwendet wird, im FHIR-Directory hinterlegt.

• Dieses Signatur-Zertifikat wird bei der Token-Prüfung gegen das verwendete Signatur-Zertifikat geprüft (siehe Akzeptanzkriterium ML-136890).

Die Abfrage der owner-access_token erfolgt entsprechend dem Kontext / Client / relevanten IDP über die dazu passende URL.
Aktuell wird nur der IDP-Dienst unterstützt und damit ist die entsprechende URL /signin-gematik-idp-dienst
Nach erfolgreicher Prüfung stellt das FHIR-Directory ein owner-access_token aus und gibt es zurück.
Wird der Auth-Service des VZD-FHIR-Directory ohne Token aufgerufen, muss er die Authentifizierung entsprechend OpenID Connect durchführen.
Der Auth-Service soll die Authentifizierung entsprechend OpenID Connect auch für Zugriffe durch Org-Admins  (SM-B/Organization) - zusätzlich zur Authentifizierung mit RegService-OpenID-Token - unterstützen.

TI-Messenger Authentifizierung mit dem gematik Authenticator - Anbieten eines Polling Endpunktes
Wenn der Authenticator der gematik von Clients genutzt wird, um eine Authentifizierung auf Basis von Smartcards zu realisieren, dann ist es notwendig, am Ende des Prozesses die Kontrolle wieder an den Client zu übergeben und diesen mit den notwendigen Informationen für die weiteren Prozessschritte zu versorgen. Im folgenden werden die Anpassungen am Auth-Service des VZD-FHIR Directories beschrieben, die notwendig sind, um eine Anmeldung unter Verwendung des gematik Authenticators zu realisieren.
Beim Anmeldevorgang verwendet der User eine Smartcard als Authentifizierungsmittel. Der Ablauf orientiert sich hierbei an den OIDC-Vorgaben zur Client initiated backchannel authentication. Um die Kollisionen mit standard OAuth2 Grants zu vermeiden, definiert die gematik einen eigenen Grant urn:telematik:params:grant-type:decoupled als Extension.
Für die Authentifizierung über den gematik-Authenticator übernimmt der Client den Aufruf des Authenticators und das VZD-FHIR-Directory stellt einen Endpunkt bereit, über den der Status des Authentifizierungsvorgangs abgefragt werden kann.

Abbildung 5: Sequence diagram - Authentifizierung mit dem gematik Authenticator

Der FHIR VZD muss für diese Authentifizierung folgende Funktionalitäten bereitstellen

POST /owner-authenticate-decoupled HTTP/1.1
Host: https://fhir-directory-ref.vzd.ti-dienste.de/
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Atelematik%3Aparams%3Agrant-type%3Adecoupled

Akzeptanzkriterien für den Anwendungsfall AF_10037 OrganizationDirectory-Einträge im VZD-FHIR-Directory ändern

5.3 Anwendungsfälle der TI-Messenger-Anbieter im VZD-FHIR-Directory

AF_10048-02 - Anwendungsfälle der TI-Messenger-Anbieter im VZD-FHIR-Directory

Attribute	Bemerkung
Beschreibung	Für den Betrieb eines TI-Messenger-Fachdienstes ist es erforderlich, alle an der Föderation beteiligten Matrix-Domänen zu kennen, um nicht an der Föderation beteiligte Matrix-Domänen ausschließen zu können. Die Domänen werden im VZD-FHIR-Directory in der Föderationsliste gespeichert.  Der TI-Messenger-Anbieter verwaltet seine Einträge im VZD-FHIR-Directory selbst. Dazu beantragt der TI-Messenger-Anbieter für seinen Registrierungsdienst Client Credentials für die Nutzung der Schnittstelle I_VZD_TIM_Provider_Services. Mit den Credentials erhält der Registrierungsdienst vom VZD TI-Provider-OAuth-Server ein ti-provider-accesstoken. Dieses tauscht er bei dem VZD-FHIR-Directory Auth-Service gegen ein provider-accesstoken, das zur Authentifizierung an der Schnittstelle genutzt wird. Nach erfolgreicher Authentisierung kann der Registrierungsdienst die Operationen zur Verwaltung der Föderationsliste nutzen. Um die Gesamtheit der an der Föderation beteiligten Matrix-Domainnamen zu erhalten, wird die Operation GET /FederationList aufgerufen. Optional KANN die bereits bekannte Version im Request angegeben werden. Als Ergebnis erhält der Registrierungsdienst eine Liste der Hashes der an der Föderation beteiligten Domainnamen oder keine Liste, falls keine neuere Version existiert. Die Hashes der Domainnamen werden verwendet, um zu verhindern, dass jeder TI-Messenger-Anbieter alle Domainnamen im Klartext kennt.
Vorbedingung	Der Registrierungsdienst des TI-Messenger-Anbieters ist bereits als Nutzer des VZD-FHIR-Directories registriert und hat TI-Provider OAuth Client Credentials (client_id und client_secret) für die Umgebungen RU, TU und PU erhalten.

Abbildung 6: VZD-FHIR-Directory_Sequenzdiagramm_TI-Messenger-Provider-Services

[<=]

5.3.1 Eintragen einer Matrix Domain - Matrix-Server Discovery

Über die Matrix-Server Discovery muss der TI-Messenger-Registrierungsdienst 

• beim Eintragen einer Domain (POST /tim-provider-services/federation) und
• periodisch für alle vorhandenen Domains in der Föderationsliste

über die Matrix Funktion “Server Discovery” die konkrete Matrix-Chat-Server-URL inkl. verwendeten Port ermitteln und in die Föderationsliste übernehmen.

Dies ist notwendig, da der Standardport 443 nicht von allen Matrix-Servern verwendet wird, die Matrix-Chat-Server-URL von der gewünschten Domain abweichen kann und sich Konfigurationen nachträglich ändern können.

Server-URL-Syntax

<Matrix-Homeserver-URL>:443/.well-known/matrix/server 

Beispiel-URL

https://matrix.dev.service-ti.de/.well-known/matrix/server/

Beispiel Ergebnis

{

  "m.server": "delegated.example.com:1234"

}

Bei dem Aufruf des WellKnown-Dokuments (Server Discovery) muss es möglich sein, Redirect-URLs zu folgen. Damit diese Redirect-URLs nicht durch die Firewall blockiert werden, können in Schnittstelle I_VZD_TIM_Provider_Services über die "domainAdministration" Operationen (addTiMessengerDomain, updateTiMessengerDomain) mit dem optionalen Attribut “redirectDomains” Redirect-URLs übergeben werden. Diese werden persistiert und in der Firewall freigeschaltet.

Die persistierten redirectDomains müssen im Ergebnis der Operation getTiMessengerDomain enthalten sein, dürfen aber nicht in der Föderationsliste enthalten sein (Operation getFederationList).

Bei redirectDomains ist zu beachten

• Die Pflege einer Wildcard-Domäne (Beispiele *.domain.de) ist nicht zulässig und führt zu einem Fehler. “Wildcard domains are not allowed.”
• Domänen-Namen länger als 255 Zeichen werden mit einem Fehler abgelehnt.
• Domänen-Namen mit Präfix “http / https” werden mit einem Fehler abgelehnt.

Initiale Ermittlung des Server-Ports inkl. ServerUrl-Anpassung

1. Bei dem Hinzufügen von Einträgen (Matrix-Servern) in der Federations-Liste wird die Matrix-Chat-Server-URL mit dem Standardport 443 gesetzt.
   
2. Zudem muss der konkrete Port asynchron durch das von Matrix bereitgestellte Discovery-Dokument ermittelt werden.
   (Für die Beschreibung Server Discovery siehe Matrix-Spezifikation Server-Server API ).
   
1. Der Server Discovery Lookup erfolgt asynchron. Die Häufigkeit wird durch Konfigurationsparameter gesteuert.
   
2. Es kommt vor, dass das Discovery-Dokument zum Zeitpunkt der Ermittlung aufgrund von einer ausstehender Firewall/Squid-Freigabe nicht erreichbar ist.
   Eine entsprechende Warning muss im TI-Service-Provider-Log protokolliert werden.
   Mit dem nächsten Lauf (je nach konfigurierter Häufigkeit) muss der nächste Versuch erfolgen.
   
3. Das Server-Disovery-Dokument muss zwingend auf dem Port 443 erreichbar sein.
   

Aktualisierung des Server-Ports inkl. ServerUrl-Anpassung

Regelmäßig muss für alle in der Federations-Liste enthaltenen Einträge der Server-Port ermittelt und aktualisiert werden.

Das Vorgehen muss dabei wie folgt umgesetzt werden.

1. Der Server Discovery Lookup erfolgt asynchron. Die Häufigkeit wird durch Konfigurationsparameter gesteuert.
   
2. Es kommt vor, dass das Discovery-Dokument zum Zeitpunkt der Ermittlung aufgrund von einer ausstehender Firewall/Squid-Freigabe nicht erreichbar ist.
   Eine entsprechende Warning muss im TI-Service-Provider-Log protokolliert werden.
   Mit dem nächsten Lauf (je nach konfigurierter Häufigkeit) muss der nächste Versuch erfolgen.
   
3. Das Server Disovery Dokument muss zwingend auf dem Port 443 erreichbar sein.

5.4 Einträge mit dem VZD-LDAP-Directory abgleichen

AF_10047-01 - Einträge mit dem VZD-LDAP-Directory abgleichen

Attribute

Bemerkung

Beschreibung

Der FHIR-Proxy aktualisiert regelmäßig in einem konfigurierbaren Intervall die im VZD-LDAP-Directory seit der letzten Aktualisierung geänderten Einträge. Da es sich um eine interne Schnittstelle des Verzeichnisdienstes handelt, wird nicht vorgegeben, wie die Schnittstelle zu implementieren ist. Die Übertragung der Daten MUSS TLS-verschlüsselt in einem internen Netzwerk des Verzeichnisdienstes erfolgen. Es werden alle geänderten Einträge seit der letzten Aktualisierung durch den FHIR-Proxy vom VZD-LDAP-Directory abgefragt und gemäß [VZD-FHIR-Directory_Mapping_LDAP_to_FHIR] aktualisiert. Dabei MÜSSEN auch im VZD-LDAP-Directory gelöschte Einträge erkannt und ebenfalls im VZD-FHIR-Directory gelöscht werden. Im VZD-FHIR-Directory wird der Wert von Organization.active bzw. PractitionerDirectory.active bei der Synchronisation aus dem VZD-LDAP-Directory entsprechend LDAP Basiseintrags-Attributs "active" gesetzt.

Abbildung 7: VZD-FHIR-Directory, Aktualisierung der Basiseinträge

[<=]

5.5 Versicherter sucht Einträge im FHIR-Directory

AF_10219-02 - Versicherter sucht Einträge im FHIR-Directory

Attribute	Bemerkung
Beschreibung	Für die Suche von Versicherten im FHIR-Directory nach Organisationen (HealthcareServiceDirectory-Einträgen), Practitioner'n (PractitionerRoleDirectory-Einträgen) und Endpoints (EndpointDirectory-Einträgen) eine Authentisierung der Fachanwendung am Auth-Service patient-authenticate Endpunkt erforderlich. Der Ablauf entsprechend Abbildung "Sequence diagram /fdv/search": Der Client prüft, ob er ein gültiges search-access_token vom FHIR VZD Auth-Service vorliegen hat. [1] Client Anfrage von search-access_token [2] Wenn im Client kein gültiges search-access_token vom FHIR VZD Auth-Service vorhanden ist, stellt der Client eine Anfrage an den Fachdienst (siehe I_FHIR_VZD_token_FD.yaml). Vor dieser Anfrage muss sich der Client des Versicherten gegenüber dem Fachdienst authentisiert haben. Der Fachdienst benötigt zur Authentisierung gegenüber dem OAuth-Server Client Credentials. Diese erhält er in einem Registrierungsprozess vom Betreiber FHIR-Directory und kann sie z.B. in einem Konfigurationsfile auf dem Fachdienst ablegen. [3] Authentisierung des Fachdiensts mit Client Credentials [4-6] Der Fachdienst authentisiert sich mit seinen Client Credentials und erhält nach erfolgreicher Prüfung ein service-authz-token. Abruf search-access_token [7-10] Der Fachdienst tauscht das service-authz-token gegen ein search-access_token ein. Cachen vom search-access_token [11] Optional kann der Fachdienst das search-access_token cachen und für Anfragen mehrerer Clients nutzen, solange die zeitliche Gültigkeit  von dem search-access_token ausreicht. Rückgabe von dem search-access_token an den Client [12] Suche im FHIR-Directory [13-17] Mit dem search-access_token kann der Client im FHIR-Directory suchen und erhält eine Antwort mit dem Suchergebnis. Wenn das search-access_token ungültig ist (z.B. zeitlich abgelaufen), erhält er als Antwort den HTTP Status Code 401. Bei der Suche über Endpunkt HealthcareServices werden Ressourcen (HealthcareService, referenzierte Organization, referenzierte Location, ggf. referenzierte Endpoints) vom FHIR VZD aus dem Ergebnis entfernt sobald die referenzierte Organization das Flag (Extension) Organization.organizationVisibility = “hide-versicherte" gesetzt hat. Bei allen Suchen über /fdv/search werden vom FHIR VZD aus dem Ergebnis die Endpoints entfernt, deren Attribut (Extension) Endpoint.extension:endpointVisibility = “hide-versicherte” gesetzt hat. Falls der Client für die interne Verarbeitung in dem fachlichen Anwendungsfall mit “hide-versicherte” markierte FHIR VZD Ressourcen benötigt, kann er diese über den FHIR VZD /search Endpunkt abfragen. Diese FHIR VZD Ressourcen dürfen für die interne Verarbeitung genutzt, dem Versicherten aber nicht direkt als Suchergebnis angezeigt werden.
Vorbedingung	Der Versicherte ist bei seiner Kasse registriert. Der Client des Versicherten hat sich gegenüber dem Fachdienst authentisiert. Der Fachdienst des Versicherten hat sich beim FHIR VZD Anbieter für die Schnittstelle /fdv/search registriert und Client Credentials vorliegen.
Nachbedingung	Der Client hat alle gefundenen Einträge empfangen.

Abbildung 8: Sequence diagram /fdv/search 

[<=]

Hinweis für Hersteller und Anbieter von Clients für Versicherte: Die Client Secrets zur Authentifizierung am OAuth-Server dürfen nur auf einem zentralen Fachdienst/Server verwendet und sicher abgelegt werden, nicht im Client des Versicherten.

5.6 Erstellen einer Verlinkungsanfrage

AF_10208 - FHIR-Directory - Erstellen einer Verlinkungsanfrage

Attribute	Bemerkung
Beschreibung	Der authentisierte Institutionsverantwortliche oder Leistungserbringer erstellt eine Verbindungsanfrage für seine Organisation bzw. Practitioner. In der Anfrage vermerkt er mit welchen HealthcareService bzw.PractitionerRole sein FHIR VZD Datensatz verbunden werden sollen.  Für jeden HealthcareService kann eine Verlinkungsanfrage zu jeder PractitionerRole gestellt werden und für  jede PractitionerRole zu jedem HealthcareService. Der FHIR-VZD MUSS dabei sicherstellen, dass für jede Verlinkungsanfrage genau eine PractitionerRole und ein HealthcareService angegeben wird. Die Bestätigung der Verlinkung erfolgt beidseitig. Die Antragsteller stimmt bereits mit dem Verlinkungsantrag zu.
Vorbedingung	Die Institution und der Leistungserbringer sind bereits im FHIR VZD eingetragen. Der Nutzer ist authentisiert.
Nachbedingung	Die Verlinkungsanfrage wurde erfasst. Die Verlinkung ist noch nicht im FHIR VZD sichtbar.

Abbildung 9: Sequence diagram - Erstellen einer Verlinkungsanfrage

[<=]

Akzeptanzkriterien für den Anwendungsfall AF_10208 FHIR-Directory - Erstellen einer Verlinkungsanfrage

5.7 Bestätigen einer Verlinkungsanfrage

Akzeptanzkriterien für den Anwendungsfall AF_10207 FHIR-Directory - Bestätigung einer Verlinkungsanfrage

5.8 Löschen einer Verlinkungsanfrage

AF_10209 - FHIR-Directory - Löschen einer Verlinkung

Attribute	Bemerkung
Beschreibung	Der authentisierte Institutionsverantwortliche oder Leistungserbringer löscht eine Verlinkung für seine Organisation bzw. Practitioner. Die Löschung der Verlinkung erfolgt einseitig und kann von jeder verlinkten Partei durchgeführt werden.
Vorbedingung	Die Institution und der Leistungserbringer sind im FHIR VZD verlinkt. Der Nutzer ist authentisiert.
Nachbedingung	Die Verlinkung wurde gelöscht. Die Verlinkungsdaten wurden aktualisiert. Die Verlinkung ist im FHIR VZD nicht mehr sichtbar.

Abbildung 11: Sequence diagram - Löschen einer Verlinkung

[<=]

Akzeptanzkriterien für den Anwendungsfall AF_10209 FHIR-Directory - Löschen einer Verlinkung

5.9 Leistungserbringer/Organisation sucht im FHIR-Directory

5.10 Holder sucht im FHIR-Directory

5.11 Fachdienst sucht Einträge im FHIR-Directory

AF_10403 - Fachdienst sucht Einträge im FHIR-Directory

Attribute	Bemerkung
Beschreibung	Für die Suche von Fachdiensten am FHIR-Directory nach Organisationen (HealthcareServiceDirectory-Einträgen) ist eine Authentisierung des Fachdienstes am Auth-Service Endpunkt erforderlich. Der Ablauf entsprechend Abbildung "Sequence diagram /search": Der Fachdienst prüft, ob er ein gültiges search-access_token vom FHIR VZD Auth-Service vorliegen hat. [1] Der Fachdienst benötigt zur Authentisierung gegenüber dem OAuth-Server Client Credentials. Diese erhält er in einem Registrierungsprozess vom Betreiber FHIR-Directory und kann sie z.B. in einem Konfigurationsfile auf dem Fachdienst ablegen. [2] Authentisierung des Fachdiensts mit Client Credentials [3-5] Der Fachdienst authentisiert sich mit seinen Client Credentials und erhält nach erfolgreicher Prüfung ein service-authz-token. Abruf search-access_token [6-9] Der Fachdienst tauscht das service-authz-token gegen ein search-access_token ein. Cachen vom search-access_token [10] Optional kann der Fachdienst das search-access_token cachen solange die zeitliche Gültigkeit  von dem search-access_token ausreicht. Suche im FHIR-Directory [11-13] Mit dem search-access_token kann der Fachdienst im FHIR-Directory suchen und erhält eine Antwort mit dem Suchergebnis. Wenn das search-access_token ungültig ist (z.B. zeitlich abgelaufen), erhält er als Antwort den HTTP Status Code 401.
Vorbedingung	Der Fachdienst hat sich bei FHIR VZD Anbieter für Schnittstelle /fdv/search registriert und Client Credentials vorliegen.
Nachbedingung	Der Fachdienst hat alle gefundenen Einträge empfangen.

Abbildung 12: Sequence diagram - Fachdienst Authentisierung und Suche

[<=]

5.12 Holder Authentifizierung

AF_10404 - FHIR VZD - Holder Authentifizierung

Attribute	Bemerkung
Beschreibung	Für die Suche am FHIR-Directory durch einen Holder ist eine Authentisierung am Auth-Service Endpunkt erforderlich. Der Ablauf entsprechend Abbildung "Sequence diagram /search": Der Holder/Client prüft, ob er ein gültiges Holder-Access-Token vorliegen hat. [1] Der Holder benötigt zur Authentisierung gegenüber dem FHIR VZD Client Credentials. Diese erhält er in einem Registrierungsprozess vom Betreiber FHIR-Directory. Authentisierung des Holders mit Client Credentials [2-4] Der Holder authentisiert sich mit seinen Client Credentials und erhält nach erfolgreicher Prüfung ein Key Cloak Holder-Access-Token. Abruf Holder-Access-Token [5-8] Der Holder/Client tauscht das Key Cloak Holder-Access-Token gegen ein Holder-Access-Token ein. Optional kann der Holder/Client das Holder-Access-Token cachen solange die zeitliche Gültigkeit ausreicht.
Vorbedingung	Der Holder hat sich bei FHIR VZD Anbieter registriert und Client Credentials vorliegen.
Nachbedingung	Der Holder hat das Holder-Access-Token vorliegen.

Abbildung 13: Sequence diagram - Holder Authentisierung

[<=]

5.13 Nutzer setzt Sichtbarkeit für Versicherte

5.14 Lesen von Zertifikaten I_FHIR_VZD_Certificates

AF_10407 - Lesen von Zertifikaten von Verzeichniseinträgen I_FHIR_VZD_Certificates

Attribute	Bemerkung
Akteure	FHIR VZD Client
Beschreibung	Für manche Anwendungsfälle von TI Anwendungen werden Zertifikate benötigt. Diese können aus dem FHIR VZD - über Schnittstelle I_FHIR_VZD_Certificates - gelesen werden. Um die Schnittstelle I_FHIR_VZD_Certificates nutzen zu können, MÜSSEN sich die FHIR VZD Clients mit einem gültigen Token authentisieren, das vom FHIR-Directory Auth-Service ausgestellt wurde. Akzeptiert werden die folgenden Token: search-access_token von der FHIRDirectorySearchAPI Schnittstelle (/search) search-access_token von der FHIRDirectoryFdvSearchAPI Schnittstelle (/fdv/search) Accesstoken von der FHIRDirectoryOwnerAPI Schnittstelle (/owner)  Mit der FHIR VZD Operation GET /Certificates "read_FhirVZD_Certificates" werden die Zertifikate vom FHIR VZD abgefragt. Die Operationen von Schnittstelle I_FHIR_VZD_Certificates sind in I_FHIR_VZD_Certificates.yaml definiert.
Vorbedingung	Der FHIR VZD Client benötigt ein gültiges Token. Der FHIR VZD Client muss den FHIR VZD Eintrag kennen - z.B. die TelematikID vorliegen haben - für den er die Zertifikate lesen will.
Nachbedingung	Der FHIR VZD Client hat die Zertifikate für den selektierten FHIR VZD Eintrag vorliegen.

[<=]

6 Verteilungssicht

Das VZD-FHIR-Directory unterstützt initial die Anwendung TI-Messenger; wird zukünftig aber auch die anderen Anwendungen wie ePA und KIM in deren Folgeversionen sowie bisher unbekannte Fachanwendungen und neue Nutzergruppen unterstützen. Es ist daher erforderlich, dass das VZD-FHIR-Directory mit der Anzahl der Nutzerzugriffe skalieren und anwendungsspezifische Ressourcen speichern kann.

Der FHIR-Proxy MUSS in mehreren Instanzen betrieben werden können, die die Schnittstellen Richtung Internet für Abfragen der TI-Messenger-Nutzer und Änderungen durch die Besitzer implementieren. Das Load-Balancing der Client-Requests erfolgt per DNS, indem für jede Instanz des FHIR-Proxy ein A und ein AAAA Resource Record für die RU, TU und PU FQDNs der Schnittstellen im DNS eingetragen wird. Instanzen des FHIR-Proxies werden je nach Last hinzugefügt oder entfernt.

Die FHIR-Proxy sind auch die HTTP-Load-Balancer für die Lesezugriffe auf FHIR-Directory-Instanzen. Für den Schreibzugriff wird eine Instanz implementiert. Die Datenbanken der Instanzen für den Lesezugriff werden mit der Datenbank für den Schreibzugriff synchronisiert.

Eine weitere Komponente setzt die Aktualisierung der Basiseinträge im FHIR-Directory mit den geänderten Daten aus dem VZD-LDAP-Directory um. Zusätzlich implementiert diese Komponente die Schnittstelle I_VZD_TIM_Provider_Services.

Abbildung 15: VZD-FHIR-Directory, Verteilungssicht  

7 VZD Self-Service Portal

Das „VZD Self-Service Portal“ dient der sicheren und effizienten Verwaltung und Einsicht von Gesundheitsdaten für „Leistungserbingende“ und „leistungserbringende Institutionen“, Kartenherausgeber und die gematik. Das Portal ermöglicht es den Nutzern, Daten zu lesen, zu ändern und zu verwalten, basierend auf den ihnen zugewiesenen Berechtigungen und Zuständigkeiten.

Hinweis: Die in diesem Kapitel genannten Begriffe "Karte", "Karteninhaber" und "Kartenherausgeber" schließen ebenfalls die Nutzung der kartenlosen SM-B ein.

7.1 Akteure

Zielgruppen des VZD Self-Service Portals sind

• HBA-Inhaber:
• Einsicht in die FHIR VZD Daten.
• Organisationen des Gesundheitswesens (SM-B Inhaber):
• Einsicht in die FHIR VZD Daten.
• Für definierte Sektoren des Medizinwesens die Möglichkeit, eigene definierte "Mehrwertdaten" zu ändern.
• Kartenherausgeber - Die Herausgabe des HBA und der SM-B erfolgt für berechtigte Heilberufsgruppen und deren Institutionen durch die zuständigen Kartenherausgeber (z.B. KVen). Für die Krankenkassen erfolgt die Herausgabe der SM-B durch den GKV-SV. Die Kartenherausgeber sind verantwortlich für die VZD Daten ihrer Karteninfrastruktur. Die Kartenherausgeber können den Eintrag der VZD Basisdaten auch an einen TSP delegieren.
• Einsicht in die FHIR VZD Daten.
• Änderbarkeit aller Daten ihrer Karteninfrastruktur.
• TSPs tragen die Zertifikate in den LDAP VZD ein, wenn sie vom zuständigen Kartenherausgeber dafür beauftragt wurden. Die Kartenherausgeber können auch den Eintrag der VZD Basisdaten an einen TSP delegieren. TSPs können die LDAP VZD Daten - über die vom LDAP VZD angebotenen Schnittstellen - einsehen.
• TSPs können - auf Antrag durch ihre Kartenherausgeber - lesenden Zugriff auf die FHIR VZD Daten über das Self-Service Portal erhalten sowie auch schreibenden Zugriff für die VZD Basisdaten.
• gematik:
• Einsicht in die FHIR VZD Daten.
• Mit Beauftragung durch Kartenherausgeber und bei TI-Störungen Änderbarkeit aller FHIR VZD Daten.

Zur Einordnung des Self-Service Portals eine Übersicht über die Möglichkeiten zur Pflege der verschiedenen Datenarten:

• Basisdaten: Pflege erfolgt über Kartenherausgeber (der diese Aufgabe an einen TSP delegieren kann) über den LDAP VZD.
• Mehrwertdaten: Die Pflege erfolgt durch den Owner im FHIR VZD. Das kann über sein Primärsystem oder das Self-Service Portal erfolgen.
• KIM Fachdaten: Die Pflege erfolgt über die KIM-Anbieter im LDAP VZD.
• TIM Fachdaten:  Die Pflege erfolgt durch den Owner im FHIR VZD.

7.2 Funktionale Anforderungen

7.2.1 Architektur des VZD Self-Service Portals

Das VZD Self-Service Portal muss aus folgenden Komponenten bestehen:

• Zentrale Komponente (Server-Seite): Ein zentraler Server (Web-Server), der die gesamte Logik, Verbindungen und Kommunikation mit den Clients und dem FHIR VZD übernimmt.
• Client-Seite: Web-Browser, die keine zusätzliche Installation benötigen. Das Vorhandensein des gematik Authenticators darf für die Kommunikation mit den Karten vorausgesetzt werden. Wenn der gematik Authenticator auf der Client-Seite nicht vorhanden ist, müssen die Authentisierungsverfahren ohne Karten nutzbar sein.

Browser und Auflösung

Es müssen die aktuellen modernen Webbrowser unterstützt werden. Der Nachweis der korrekten Umsetzung erfolgt mit dem aktuellen Google Chrome-Browser unter Windows.

Das VZD Self-Service Portal muss mit einer Bildschirm Auflösung von >= 1024px Breite x 800px Höhe nutzbar sein.

7.2.2 Benutzerverwaltung, Authentisierung und Berechtigungen

Im VZD Self-Service Portal müssen folgende Benutzergruppen unterstützt werden:

Karteninhaber (Owner)

• Die Anmeldung erfolgt mittels SM-B- oder HBA.
  
• Die Identifikation des Owners erfolgt über die der Karte zugeordnete Telematik-ID.
  
• Karteninhaber können bestimmte Informationen einsehen und unter definierten Bedingungen bearbeiten. Welche Informationen ergänzt bzw. bearbeitet werden können, ist aus [FHIR-VZD-ILF-Data] Spalte "Changable by owner" in den Tabellen ersichtlich.
• Für Karteninhaber erfolgt die Benutzerverwaltung über ihre Karten und die Gültigkeit dieser Karten. Mit einem gültigen - und dem FHIR VZD bekannten - HBA bzw. SM-B muss die Authentisierung am VZD Self-Service Portal möglich sein. Die Anmeldung mit allen anderen Karten muss abgelehnt werden, auch wenn ein IDP für diese Karten Token ausstellt.

Einfache Benutzer mit Leseberechtigung

• Anmeldung per Benutzername und Passwort.
• Die Benutzerverwaltung muss über die Registrierung bei der gematik und Verwaltung des Benutzeraccounts bei dem VZD Betreiber erfolgen.
• Diese Benutzer verfügen über das Standardrecht vzd-ssp-read und haben ausschließlich lesenden Zugriff auf die freigegebenen Informationen.
  

Administrativer Benutzer mit erweiterten Rechten

• Anmeldung ebenfalls per Benutzername und Passwort.
• Die Benutzerverwaltung muss über die Registrierung bei der gematik und Verwaltung des Benutzeraccounts bei dem VZD Betreiber erfolgen.
• Diese können zusätzlich zu den Leseoperationen definierte Inhalte bearbeiten.
  

Kartenherausgeber (Holder)

• Auch hier erfolgt die Anmeldung per Benutzername und Passwort.
• Die Benutzerverwaltung muss über die Registrierung bei der gematik und Verwaltung des Benutzeraccounts bei dem VZD Betreiber erfolgen.
• Besitzen das Recht vzd-ssp-holder, das erweiterte administrative Zugriffe auf die FHIR VZD Daten ihrer Karteninfrastruktur ermöglicht.
  

Alle übertragenen Daten müssen Ende-zu-Ende verschlüsselt werden, um den Schutz der Daten während der Übertragung zu gewährleisten.

Das Portal muss alle relevanten Datenschutzbestimmungen, insbesondere die Datenschutz-Grundverordnung (DSGVO), einhalten.

7.2.2.1 Funktionsspezifische Unterschiede

Je nach Rolle unterscheiden sich die zur Verfügung stehenden Funktionen innerhalb des Systems:

7.2.2.1.1 Suche und Anzeige

Suche und Anzeige von Detail-Informationen

Die Suchfunktion steht allen Benutzergruppen zur Verfügung. Auch die Detailinformationen können von allen Gruppen eingesehen werden.
Unterschiede in den erweiterten Einsichts- oder Bearbeitungsrechten werden in den folgenden Abschnitten näher beschrieben.

Die Eingabe der Suchkriterien muss für den Nutzer einfach - ähnlich wie bei den aktuellen Internetsuchmaschinen - möglich sein.

Die Suche muss als Ergebnis liefern:

• Trefferliste mit Suchfeld. Treffer befinden sich in einer Tabelle, welche über die Art der Einträge “Praxis, Apotheke, Person” mittels Tabellen-Tabs gefiltert werden kann.
• Die Liste muss sowohl aktive als auch inaktive VZD-Einträge enthalten.

Durch Selektion eines VZD-Eintrags in der Trefferliste müssen die Detailinformationen dieses Eintrags dargestellt werden. In den Detailinformationen müssen die wesentlichen Attribute des VZD-Eintrags für den Anwender leicht verständlich aufbereitet dargestellt werden.

Zusätzlich zu den Detailinformationen müssen folgende Daten einsehbar sein:

Anzeige Zertifikatsinformationen

Die Zertifikatsinformationen sind mit den Einträgen verknüpft und werden unter dem Reiter "Telematik" dargestellt.

Die Zertifikatsinformationen haben einen öffentlichen Charakter und können von allen Benutzern eingesehen werden.

Anzeige Fachliches Log (VZD FHIR + VZD LDAP)

Im Reiter „Historie“ werden alle Änderungen an einem Eintrag inklusive Bearbeiter und Änderungsinhalt dokumentiert.

• Karteninhaber (Owner) sehen nur das Log ihrer eigenen Einträge, basierend auf der zugeordneten Telematik-ID.
  
• Administrative Benutzer und zukünftig Kartenherausgeber (Holder) können das Log aller Einträge einsehen.
  

Anzeige Rohdaten

Im Reiter „Rohdaten“ werden die zugrunde liegenden FHIR-Ressourcen im JSON-Format dargestellt.
Dies dient der technischen Nachvollziehbarkeit und ermöglicht detaillierte Prüfungen auf Datenebene.

• Karteninhaber (Owner) können ausschließlich die Rohdaten ihrer eigenen Einträge einsehen, basierend auf ihrer Telematik-ID.
  
• Administrative Benutzer sowie zukünftig auch Kartenherausgeber (Holder) erhalten Einsicht in die Rohdaten aller Einträge.
  

7.2.2.1.2 Datenänderung über das VZD Self-Service Portal

Änderung von Mehrwertdaten (inkl. Endpunkte)

Mehrwertdaten umfassen zusätzliche Informationen zu einem Eintrag, wie:

• Telekommunikationsdaten
  
• Geokoordinaten (Breiten-/Längengrad)
  
• Verknüpfte technische Endpunkte
  
• angebotene Apothekenservices
  
• Öffnungszeiten
  

Diese Daten dürfen ausschließlich von Karteninhabern (Owner) und administrativen Benutzern bearbeitet werden. Karteninhabern (Owner) dürfen nur Daten ihres eigenen VZD Eintrags bearbeiten (identifiziert über Telematik-ID), administrative Benutzer nur VZD Einträge innerhalb der eigenen Zuständigkeit (identifiziert über das Holder Attribut).

Karteninhabern (Owner) dürfen nur die Daten bearbeiten, für welche in [FHIR-VZD-ILF-Data] Tabellen-Spalte "Changable by owner" für Änderungen freigegeben sind.

Aktuell ist eine Bearbeitung für Karteninhaber nur für Apotheken, einschließlich EU-Versandapotheken, vorgesehen. Die Erweiterung für andere Sektoren muss möglich sein.

Datenvalidierung:  Daten - die geändert werden - müssen durch das Self-Service Portal validiert werden, um sicherzustellen, dass die Qualität der Daten gewährleistet ist.

7.2.3 Benutzeroberfläche und Benutzererfahrung

Die Benutzeroberfläche muss einfach und intuitiv zu bedienen sein, um eine hohe Akzeptanz bei den Nutzern zu gewährleisten.

Benutzerfreundlichkeit (Usability):

• Die Navigation muss logisch aufgebaut und leicht verständlich sein. 
  
• Elemente wie Schaltflächen, Menüs und Formulare müssen eindeutig beschriftet und leicht auffindbar sein. 
  

Effizienz:

• Die Benutzeroberfläche muss es Benutzern ermöglichen, Aufgaben schnell und effizient zu erledigen. 
  
• Kurze Reaktionszeiten, welche die VZD Antwortzeiten nicht merklich verlangsamen. 
  
• Häufig genutzte Funktionen müssen leicht zugänglich sein und nicht durch viele Zwischenschritte erreicht werden müssen. 
  

Konsistenz:

• Die Gestaltung und Funktionsweise verschiedener Elemente innerhalb der Benutzeroberfläche muss konsistent erfolgen. 
  
• Gleichartige Elemente müssen immer auf die gleiche Weise dargestellt und bedient werden. 
  

Barrierefreiheit:

• Die Benutzeroberfläche muss für Menschen mit Behinderungen zugänglich sein. 
  
• Dies kann beispielsweise durch angepasste Farben und Schriftgrößen oder die Verwendung von Tastaturkürzeln erfolgen. 
  

Fehlerbehandlung:

• Die Benutzeroberfläche muss Benutzer auf Fehler hinweisen. 
  
• Fehlermeldungen müssen klar und verständlich sein und auf die Fehlerursache bzw. deren Behebung hinweisen. 
  

7.2.4 Anwendungsfälle

7.2.4.1 Authentisierung über HBA/SM-B

AF_10414 - FHIR VZD Self-Service Portal - Authentisierung über HBA/SM-B

Attribute	Bemerkung
Akteure	Mitarbeiter im Gesundheitswesen (Authentisierung via HBA) Administratoren von Organisationen im Gesundheitswesen (Authentisierung via SM-B)
Beschreibung	Für die Nutzung des Self-Service Portals ist eine Authentisierung erforderlich. Hier erfolgt die Authentisierung über einen HBA oder eine  SM-B. Der Nutzer ruft das Self-Service Portal für die gewünschte Umgebung (RU, TU oder PU) über die jeweilige URL im Web Browser der Praxis bzw. Organisation auf. [1] Das Self-Service Portal Frontend bietet die Auswahl der Authentisierungsmethode an [2]. Der Nutzer wählt im Self-Service Portal die Authentisierung via HBA bzw. SM-B.  [3] Das Self-Service Portal Frontend startet den Authentisierungs-Flow der Authenticator-App. [4] Dafür werden zuerst die benötigten Austauschinformationen generiert (PKCE_code_challange, PKCE_code_verifier, state). [5] Anschließend ruft der Browser die lokal-laufende Authenticator-App [6] und dieser wiederum den Gematik-IDP auf. [7] Nach einem erfolgreichen Austausch folgt die Authenticator-App der Redirect-URI. [8] Das Self-Service Portal Frontend übergibt die bekannten Austauschinformationen auth_code und key_verifier an den Token-Endpunkt des Gematik-IDP. [9][10] Sind die übergebenen Informationen korrekt, erhält der Auth-Service das signierte id_token zurück. [11] Das id_token wird auf seine zeitliche Gültigkeit sowie auf die Signatur überprüft. [12] Für die Validierung der Signatur wird das öffentliche Zertifikat des Gematik-IDP benutzt. Dieses wurde zuvor von der OpenID-Konfigurations-Seite des IDP heruntergeladen. Ist der id_token gültig, wird es an das SSP-Frontend weitergeleitet. [12][13] Intern wird die Benutzeranmeldung im SSP-Frontend zwischengespeichert. [14] Der Benutzer ist anschließend erfolgreich angemeldet. Nach erfolgreicher Anmeldung wird dem Benutzer die Suchseite der Webanwendung angezeigt, wobei im Hintergrund die REST-Schnittstelle des SSP-Backends aufgerufen wird und ein vom SSP-selbst-signiertes AccessToken im Authorization-Header an den FHIR-VZD übertragen wird. Der VZD FHIR validiert den Token auf zeitliche Gültigkeit und seine Signatur.
Vorbedingung	Die Organisation oder der Leistungserbringer hat bereits einen Basiseintrag im VZD-FHIR-Directory. Eine Authenticator-App des IDP steht zur Verfügung, mit der die Organisations-Identität oder die Leistungserbringer-Identität bei einem IDP der TI-IDP-Föderation bestätigt werden kann.
Nachbedingung	Die Organisation oder der Leistungserbringer sind authentisiert und können das Self-Service Portal nutzen.

[<=]

7.2.4.2 Authentisierung von administrativen Nutzern

AF_10415 - FHIR VZD Self-Service Portal - Authentisierung über Passwort

Attribute	Bemerkung
Akteure	Administrative Nutzer im Gesundheitswesen (Authentisierung via Passwort), z.B. Kartenherausgeber, gematik.
Beschreibung	Für die Nutzung des Self-Service Portals ist eine Authentisierung erforderlich. Hier erfolgt die Authentisierung über Credentials (Username/Passwort). Der Nutzer ruft das Self-Service Portal für die gewünschte Umgebung (RU, TU oder PU) über die jeweilige URL im Web Browser auf. [1] Das Self-Service Portal Frontend bietet die Auswahl der Authentisierungsmethode an [2]. Der Nutzer wählt im Self-Service Portal die Authentisierung via Passwort.  [3] Das Self-Service Portal Frontend zeigt die Login Maske für die Eingabe der Credentials an. [4] Der Nutzer gibt die Credentials im  Self-Service Portal Frontend (Browser) ein und bestätigt sie [5]. Der FHIR VZD Auth-Service validiert die eingegebenen Credentials. [6] Sind die eingegebenen Credentials gültig, wird ein Token erzeugt und zusammen mit den Account Informationen an das SSP-Frontend weitergeleitet. [7] Intern wird die Benutzeranmeldung im SSP-Frontend zwischengespeichert. [8] Der Benutzer ist anschließend erfolgreich angemeldet. Nach erfolgreicher Anmeldung wird dem Nutzer die Suchseite der Webanwendung angezeigt, wobei im Hintergrund die REST-Schnittstelle des SSP-Backends aufgerufen wird und ein vom SSP-selbst-signiertes AccessToken im Authorization-Header an den FHIR-VZD übertragen wird. [9] Der VZD FHIR validiert den Token auf zeitliche Gültigkeit und seine Signatur.
Vorbedingung	Der Administrative Nutzer ist bei der gematik und dem Self-Service Portal Betreiber registriert und hat seine Credentials erhalten.
Nachbedingung	Der Administrative Nutzer ist authentisiert und kann das Self-Service Portal nutzen.

      [<=]

7.2.4.3 Suche und Anzeige von FHIR VZD Einträgen

AF_10416 - FHIR VZD Self-Service Portal - Suche und Anzeige von Einträgen

Attribute	Bemerkung
Akteure	Mitarbeiter im Gesundheitswesen Administratoren von Organisationen im Gesundheitswesen Administrative Nutzer im Gesundheitswesen
Beschreibung	Der Benutzer formuliert im SSP Frontend/Browser seine Suchanfrage. [1] Das SSP Frontend sendet die Suchanfrage zusammen mit dem vorliegenden Token an das SSP Backend. [2] Das SSP Backend validiert das Token & ermittelt die Berechtigungen. [3] Das SSP Backend leitet die Suchanfrage zusammen mit dem Token an das FHIR-Directory weiter. [4] Die FHIR-Directory Antwort wird über SSP Backend und SSP Frontend zurückgegeben. [5,6] Das SSP Frontend stellt dem Benutzer das Suchergebnis dar. [7]
Vorbedingung	Der Benutzer wurde authentisiert und die erforderlichen Nutzerdaten liegen im SSP Frontend vor.
Nachbedingung	Dem Benutzer liegt die Antwort auf seine Suchanfrage vor.

                                         
[<=]

7.2.4.4 Änderung von FHIR VZD Einträgen

AF_10417 - FHIR VZD Self-Service Portal - Suche und Änderung von Einträgen

Attribute	Bemerkung
Akteure	Mitarbeiter im Gesundheitswesen Administratoren von Organisationen im Gesundheitswesen Administrative Nutzer im Gesundheitswesen
Beschreibung	Der Benutzer ändert den VZD-Eintrag. [1] Das SSP Frontend sendet den aktualisierten VZD-Eintrag zusammen mit dem vorliegenden Token an das SSP Backend. [2] Das SSP Backend validiert das Token und ermittelt die Berechtigungen. [3] Das SSP Backend übergibt den aktualisierten VZD-Eintrag zusammen mit dem SSP Backend Token an das FHIR-Directory. [4] Das Ergebnis der Datenänderung wird vom FHIR-Directory über FHIR-Proxy, SSP Backend und SSP Frontend zurückgegeben. [5] Das SSP Frontend stellt dem Benutzer das Ergebnis der Datenänderung dar. [6]
Vorbedingung	Der Benutzer wurde authentisiert und die erforderlichen Nutzerdaten liegen im SSP Frontend vor. Der Benutzer hat eine Suche nach dem zu ändernden VZD Datensatz durchgeführt und das Suchergebnis liegt im SSP Frontend vor.
Nachbedingung	Dem Benutzer wird das Ergebnis der Datenänderung dargestellt.

                                                                                 [<=]

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

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

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis

8.5 Referenzierte Dokumente

8.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.

8.5.2 Weitere Dokumente

Mitgeltende Dokumente und Web-Inhalte

8.6 Versionierung Datenmodell

Folgende Versionen der Datenmodell Ressourcen (https://simplifier.net/vzd-fhir-directory/ ) sind für die vorliegende Spezifikation relevant:

• de.gematik.fhir.directory/1.0.1