gemSpec_VZD_FHIR_Directory_V1.5.0_Aend

 

 

 

 

 

Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

 

 

Spezifikation

Verzeichnisdienst FHIR-Directory

 

 

 

   

Version	1.45.0
Revision	829916975059
Stand	Wert nicht konfiguriert22.03.2024
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

Dokumentinformationen

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

1.2 Zielgruppe

1.3 Geltungsbereich

1.4 Abgrenzungen

1.5 Methodik

2 Systemüberblick

2.1 Nutzer und Rollen

2.2 Nachbarsysteme

3 Zerlegung des Produkttyps

4 Funktionsmerkmale

4.1 FHIR-Directory

4.1.1 Datenmodell

4.1.2 Mapping von LDAP auf FHIR-Ressourcen

4.1.3 FHIR RESTful API

4.2 FHIR-Proxy1.4 Verlinkung von Personen und Organisationen in FHIR

4.2.1 Schnittstellen FHIR-Proxy

4.2.1.1 TLS-Verbindungsaufbau Schnittstellen

4.2.1.2 FHIR Schnittstelle für TI-Messenger-Nutzer FHIRDirectorySearchAPI1 TLS-Verbindungsaufbau

4.2.1.32 FHIR- Schnittstelle für Besitzer FHIRDirectoryOwnerAPITI-Messenger-Nutzer FHIRDirectorySearchAPI

4.2.1.43 FHIR-Schnittstelle FHIRDirectoryTIMProviderAPI (I_VZD_TIM_Provider_Services.yaml)für Besitzer FHIRDirectoryOwnerAPI

4.2.1.54 FHIR Schnittstelle für Versicherte FHIRDirectoryFdvSearchAPIFHIRDirectoryTIMProviderAPI (I_VZD_TIM_Provider_Services.yaml)

4.2.2 Aktualisierung der Basiseinträge1.5 FHIR Schnittstelle für Versicherte FHIRDirectoryFdvSearchAPI

4.2.3 Erzeugung und Bereitstellung der Föderationsliste2 Aktualisierung der Basiseinträge

4.2.4 Lokalisierung einer MXID (Operation whereIs)3 Erzeugung und Bereitstellung der Föderationsliste

4.3 Übergreifende Vorgaben2.4 Lokalisierung einer MXID (Operation whereIs)

4.3.1 Sicherheit und Datenschutz Übergreifende Vorgaben

4.3.2 Betrieb1 Sicherheit und Datenschutz

5 Anwendungsfälle4.3.2 Betrieb

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

5.2 Eigentümer ändert seinen Eintrag und sucht1 TI-Messenger-Nutzer sucht Einträge im FHIR-Directory

5.3 Anwendungsfälle der TI-Messenger-Anbieter im VZD-2 Eigentümer ändert seinen Eintrag und sucht im FHIR-Directory

5.4 Einträge mit dem VZD-LDAP-Directory abgleichen3 Anwendungsfälle der TI-Messenger-Anbieter im VZD-FHIR-Directory

5.5 Versicherter sucht4 Einträge im FHIRmit dem VZD-LDAP-Directory abgleichen

6 Verteilungssicht5.5 Versicherter sucht Einträge im FHIR-Directory

7 Anhang A – Verzeichnisse5.6 Erstellen einer Verlinkungsanfrage

75.1 Abkürzungen7 Bestätigen einer Verlinkungsanfrage

75.2 Glossar8 Löschen einer Verlinkungsanfrage

7.3 Abbildungsverzeichnis6 Verteilungssicht

7.4 Tabellenverzeichnis Anhang A – Verzeichnisse

7.5 Referenzierte Dokumente1 Abkürzungen

7.5.1 Dokumente der gematik2 Glossar

7.5.2 Weitere Dokumente3 Abbildungsverzeichnis

7.6 Versionierung Datenmodell4 Tabellenverzeichnis

7.5 Referenzierte Dokumente

7.5.1 Dokumente der gematik

7.5.2 Weitere Dokumente

7.6 Versionierung Datenmodell

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

Als erste Anwendung wird der TI-Messenger-Dienst das VZD-FHIR-Directory nutzen.

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

ML-123876 - Test gegen die Referenzimplementierung der Nachbarsysteme (VZD-FHIR-Directory)

Es MÜSSEN alle Anwendungsfälle des VZD-FHIR-Directories erfolgreich gegen die Referenzimplementierung der Nachbarsysteme getestet sein.
[<=]

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:

• FHIRDirectorySearchTI API

Geplante Schnittstelle für die Suche der Einträge ohne Authentisierung im geschlossenen Netz der TI (TI-Anbindung erforderlich).

• FHIRDirectoryAdmin API

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

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

ML-123880 - Einschränkung der nutzbaren FHIR-Ressourcen (VZD-FHIR-Directory)

Nur die in Tabelle "VZD-FHIR-Directory, FHIR-Ressourcen" angegebenen Ressourcen dürfen im VZD-FHIR-Directory erzeugt werden. [<=]

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.

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.

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.

3. Verantwortlicher einer Institution (Organisation)
   1. Der Verantwortliche authentisiert sich über das Owner-Authenticate-Verfahren (vereinfachtes Verfahren SMC-B oder IDP-Dienst-Verfahren).
   2. Dabei erhält dieser einen Owner-Authenticate-Token, welcher an der administrativen Schnittstelle genutzt werden kann.

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

ML-143700 - VZD-FHIR-Directory - Sichtbare Verbindung zwischen Personen und Organisationen

Für FHIR VZD Nutzer muss die Zugehörigkeit von Personen (Practitioner) zu Organisationen (Organization) sichtbar sein. Die Zugehörigkeit darf erst nach beidseitiger Bestätigung (von Person und Organisation) sichtbar sein. [<=]

ML-143701 - VZD-FHIR-Directory - Genehmigungspflichtige Verbindung zwischen Personen und Organisationen

Die Verbindung zwischen Personen und Organisationen muss beidseitig von den verlinkten Personen und Organisationen bestätigt werden.  [<=]

ML-143703 - VZD-FHIR-Directory - Dokumentation der Verlinkungs-Genehmigungen zwischen Personen und Organisationen

Die Genehmigungen, Ablehnungen und Löschungen der Verbindung zwischen Personen und Organisationen müssen dokumentiert werden und - durch die beteiligte Person und Organisation - einsehbar sein.  [<=]

ML-143702 - VZD-FHIR-Directory - Widerruf der Verbindung zwischen Personen und Organisationen

Die Widerrufung der Verbindung zwischen Personen und Organisationen muss einseitig möglich sein

• durch den verlinkten Leistungserbringer  und
• als Verantwortlicher einer verlinkten Institution

[<=]

ML-143800 - VZD-FHIR-Directory - Authentisierung für Verlinkung zwischen Personen und Organisationen

Der FHIR VZD muss die Nutzer vor dem Eintragen von Verlinkungsdaten entsprechend ihrer Nutzergruppe authentisieren. Folgende Nutzergruppen müssen berücksichtigt werden

• Leistungserbringer
• Verantwortlicher eine Institution (Organisation)
• Kartenherausgeber (Holder)

[<=]

ML-143878 - VZD-FHIR-Directory - Verbieten von Ressourcen-Verlinkungen ohne Verknüpfungsauftrag

Der FHIR VZD muss das direkte Eintragen der Verbindung zwischen Personen und Organisationen über die FHIR VZD Owner Schnittstelle verhindern. Das Eintragen dieser Verbindung ist nur im beidseitiges Einverständnis zwischen Organisation und Leistungserbringern erlaubt. [<=]

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 ist die URL: https://fhir-directory.vzd.ti-dienste.de/search   

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

In der Testumgebung ist die URL: https://fhir-directory-test.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 "aud" enthält die URL des Endpunktes in der jeweiligen Umgebung RU, TU oder PU.

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

Endpunkte für die Authentisierung

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

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

In der Testumgebung ist die URL: https://fhir-directory-test.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:

2. practitioner.qualification
3. location 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.

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

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

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

In der Testumgebung ist die URL: https://fhir-directory-test.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.

Endpunkte für die Authentisierung

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

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

In der Testumgebung ist die URL: https://vzd-fhir-directory-test.vzd.ti-dienste.de/owner-authenticate  

FHIR VZD Endpunkte für die Authentisierung mit dem SmartcardIDP

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

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

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

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

TI- Anwendung	Endpoint.connectionType code	Endpoint.address
TI Messenger	tim	Format (MXID in URL Form) für User entsprechend [matrix-uri-scheme]:                    matrix:u/localpart:domainpart Beispiel MatrixID:  @1-1tst-auto-ts-ow2:tim.test.gematik.de MatrixID im URL Format in Endpoint.address:  matrix:u/1-1tst-auto-ts-ow2:tim.test.gematik.de

4.2.1.4 Schnittstelle FHIRDirectoryTIMProviderAPI (I_VZD_TIM_Provider_Services.yaml)

Endpunkte

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

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

In der Testumgebung ist die URL: https://fhir-directory-test.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.

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 ist die URL: https://fhir-directory.vzd.ti-dienste.de/ti-provider-authenticate
In der Referenzumgebung ist die URL: https://fhir-directory-ref.vzd.ti-dienste.de/ti-provider-authenticate
In der Testumgebung ist die URL: https://fhir-directory-test.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 ist die URL: https://auth-ref.vzd.ti-dienste.de:9443/auth/realms/TI-Provider/protocol/openid-connect/token 

In der Testumgebung ist die URL: https://auth-test.vzd.ti-dienste.de:9443/auth/realms/TI-Provider/protocol/openid-connect/token 

In der Produktionsumgebung 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:

4. Angaben zur Rolle (hier TI-Messenger-Anbieter) und Organisation des Antragstellers, Erläuterung der Berechtigung und des Bedarfs (zur Verifikation notwendig)
5. Kontaktdaten zu Ansprechpartnern beim Antragsteller (2 Personen) inkl. Telefonnummer, E-Mail-Adresse, Anschrift
6. Angabe der Betriebsumgebung (RU/PU)
7. 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)
8. falls bereits vorhanden, eine entsprechende Ticketnummer
9. nur bei Deregistrierung durch den Antragsteller: vorab vergebene Client-ID
10. gewünschte Bezeichnung in der clientID.
11. 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 ist die URL: https://fhir-directory.vzd.ti-dienste.de/fdv/search    

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

In der Testumgebung ist die URL: https://fhir-directory-test.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 (Fachdienste) enthält 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 URL des Endpunktes in der jeweiligen Umgebung RU, TU oder PU.

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 ist die URL: https://auth-ref.vzd.ti-dienste.de:9443/auth/realms/Service-Authenticate/protocol/openid-connect/token  

In der Testumgebung ist die URL: https://auth-test.vzd.ti-dienste.de:9443/auth/realms/Service-Authenticate/protocol/openid-connect/token  

In der Produktionsumgebung 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 ist die URL: https://fhir-directory.vzd.ti-dienste.de/service-authenticate 

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

In der Testumgebung ist die URL: https://fhir-directory-test.vzd.ti-dienste.de/service-authenticate 

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

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

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

In der Testumgebung ist die URL: https://fhir-directory-test.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:

6. practitioner.qualification
7. location 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.

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 Föderationsliste MUSS mit einer JWS gemäß RFC7797 signiert werden. Der zu verwendende Signatur-Algorithmus MUSS "ES256" oder "BP256R1" sein. DazuDer 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

ML-123677 - Maßnahmen gegen die Manipulation der Föderationsliste (VZD-FHIR-Directory, Sicherheitsgutachten)

Im Sicherheitsgutachten des VZD-FHIR-Directories sind geeignete Maßnahmen gegen die Manipulation der Föderationsliste beschrieben. [<=]

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.

TIP1-A_5546-01 - VZD, Integritäts- u. Authentizitätsschutz

Der Anbieter des VZD MUSS die Integrität und Authentizität der im VZD gespeicherten Daten gemäß den Richtlinien des Bundesamtes für Sicherheit in der Informationstechnik für allgemeine Verzeichnisdienste, [BSI APP.2.1], implementieren. [<=]

TIP1-A_5548 - VZD, Protokollierung der Änderungsoperationen

Der VZD MUSS Änderungen der Verzeichnisdiensteinträge protokollieren und muss sie 6 Monate zur Verfügung halten.

[<=]

6 Monate ist die maximale Nachweistiefe, ohne in den Bereich der Vorratsdatenspeicherung zu kommen.

TIP1-A_5549 - VZD, Keine Leseprofilbildung

Der VZD DARF Suchanfragen NICHT speichern oder protokollieren.

[<=]

TIP1-A_5550 - VZD, Keine Kopien von gelöschten Daten

Der VZD DARF von gelöschten Daten KEINE Kopien speichern.

[<=]

TIP1-A_5551 - VZD, Sicher gegen Datenverlust

Der Anbieter des VZD MUSS den Dienst gegen Datenverlust absichern.

[<=]

TIP1-A_5552 - VZD, Begrenzung der Suchergebnisse

Der VZD MUSS die Ergebnisliste einer Suchanfrage auf 100 Suchergebnisse begrenzen.

[<=]

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.

TIP1-A_5553 - VZD, Private Schlüssel sicher speichern

Der VZD MUSS seine privaten Schlüssel sicher speichern und ihr Auslesen verhindern um Manipulationen zu verhindern.

[<=]

TIP1-A_5554-01 - VZD, Registrierungsdaten sicher speichern

Der VZD MUSS die Integrität und Authentizität der gespeicherten Registrierungsdaten gewährleisten. [<=]

TIP1-A_5556 - VZD, Fehler Logging

Der VZD MUSS lokal und remote erkannte Fehler in seinem lokalen Speicher protokollieren.

[<=]

TIP1-A_5558 - VZD, Sicheres Speichern der TSL

Der VZD MUSS  die Inhalte der TSL in einem lokalen Trust Store sicher speichern und für X.509-Zertifikatsprüfungen lokal zugreifbar halten.

[<=]

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

Das VZD-FHIR-Directory wird betrieblich als eine weitere Servicekomponente im Sinne der Weiterentwicklung des Verzeichnisdienstes betrachtet. Diese Servicekomponente kann, bis auf die Schnittstellen, unabhängig vom VZD-LDAP-Directory entwickelt und deployt werden. Aus Nutzersicht ist weniger die interne, logische Struktur der Verzeichnisdienste relevant, sondern die Verfügbarkeit der Schnittstellen und die im Verzeichnis enthaltenen Daten.

Das VZD-FHIR-Directory MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_VZD_FHIR_Perf unter der für alle Funktionen parallel anliegenden Spitzenlast erfüllen.

Tabelle 6: Tab_VZD_FHIR_Perf

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

5 Anwendungsfälle

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

AF_10036-01 - Nutzer sucht Einträge im FHIR-Directory

 

Abbildung 3: Sequence diagram /search

[<=]

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

ML-123485 - Authentifizierung am Endpunkt /search (VZD-FHIR-Directory, Sicherheitsgutachten)

Am Endpunkt /search des FHIR-Proxy darf die Authentifizierung nur für Requests erfolgreich sein, die ein gültiges search-access_token im Authentication Header enthalten, das vom Auth-Service ausgestellt wurde. Das search-access_token MUSS im aud Feld den Servernamen des VZD-FHIR-Directory und den Endpunkt /search enthalten. [<=]

ML-148295 - Authentifizierung am Endpunkt /fdv/search (VZD-FHIR-Directory, Sicherheitsgutachten)

Am Endpunkt /fdv/search des FHIR-Proxy darf die Authentifizierung nur für Requests erfolgreich sein, die ein gültiges search-access_token im Authentication Header enthalten, das vom Auth-Service ausgestellt wurde. Das search-access_token MUSS im aud Feld den Servernamen des VZD-FHIR-Directory und den Endpunkt /fdv/search enthalten.
[<=]

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

AF_10037-02 - Einträge im VZD-FHIR-Directory ändern und suchen

 

 

Abbildung 4: Sequenzdiagramm VZD-FHIR-Directory Änderung von eigenen OrganizationDirectory- oder PractitionerDirectory-Einträgen 

[<=]

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 gematik-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
(SMC-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

Funktionalität	Anforderung
Bereitstellung des initalen authenticate Endpunkt am Auth-Service	Das VZD-FHIR Directory muss einen /owner-authenticate-decoupled Endpunkt anbieten der POST Request mit dem übergebene grant_type urn:telematik:params:grant-type:decoupled akzeptiert.  neuer owner Endpunkt 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   Erhält das VZD-FHIR Directory eine derartige Anfrage wird ein Autorisierungsauftrag mit den Werten:  auth_reg_id state owner-accesstoken (in diesem Moment noch unbefüllt) code_challenge erstellt und es werden folgende Daten an den Client im Response zurück geliefert:   owner Response expires_in: definiert die Zeit, die die auth_reg_id gültig ist und genutzt werden kann in Sekunden interval: definiert das Mindestwarteintervall zwischen 2 Pollinganfragen
Bereitstellung eines neuen polling Endpunktes am Auth-Service	Das VZD-FHIR Directory muss einen Endpunkt anbieten, der von Clients genutzt werden kann, um den Status eines Autorisierungsauftrages abzufragen. Dazu übergibt ein anfragender Client die folgenden Werte (wobei ist durch VZD festgelegter Endpoint, welcher im Schritt 06 dem Client über poll_uri mitgeteilt wird)  Token Request POST /oauth/v2/oauth-token HTTP/1.1 Host: idsvr.example.com Content-Type: application/x-www-form-urlencoded grant_type=urn%3Atelematik%3Aparams%3Agrant-type%3Adecoupled auth_req_id=bspuw6ea-scst-u5hn-p3nt-37khzwY4g Es wird geprüft, ob für die auth_req_id noch gültig ist und bereits ein owner-accesstoken vorliegt: a) Es liegt ein passendes Token vor: Dann antwortet der Auth-Service in seinem Response mit dem entsprechenden owner-accesstoken:  Token Response Success HTTP/1.1 200 OK     Content-Type: application/json     Cache-Control: no-store     {      "access_token": "G5kXH2wHvUra0sHlDy1iTkDJgsgUO1bN"      "token_typ": "Bearer"      "expires_in": "86400" } b) liegt kein passendes Token vor dann antwortet der Server mit:  Token Response Error HTTP/1.1 400 Bad Request Content-Type: application/json Cache-Control: no-cache, no-store {   "error": [ERROR_REASON] } Die ERROR_REASON kann die folgenden Werte annehmen:  authorization_pending - Der Authentifizierungsprozess ist noch nicht abgeschlossen slow_down - Wenn der Token Request noch nicht abgeschlossen ist und der Client hat den Request schneller als 3 Sekunden gestellt. access_denied - Der Authentifizierungsprozess konnte im Hintergrund nicht erfolgreich durchgeführt werden. Das minimal erlaubte Polling-Interval wird auf 3 Sekunden festlgelegt. Das VZD speichert den Zeitstempel der letzten Polling-Anfrage, sodass bei der nächsten Anfrage mit dem gleichen auth_req_id der letzte Zeitstempel abgerufen werden kann (z.B. in der gleichen Datenbanktabelle). Der Zeitunterschied des aktuellen Zeitstempel und den letzten Zeitstempel muss im Minimum 3 Sekunden betragen.
Bereitstellung einer neuen Redirect_uri	Aktuell liefert die vom VZD-FHIR Directory verwendete Redirect_uri (/signin-gematik-idp-dienst) bei Übergabe des Auth_code und des state einen owner-accesstoken zurück. Diese Rückgabe ist nicht notwendig, wenn der Authenticator die Redirect_uri direkt aufruft.

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

ML-123874 - Nur Einträge mit eigener Telematik-ID verändern (VZD-FHIR-Directory)

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

ML-148324 - Authentifizierung am Endpunkt /owner (VZD-FHIR-Directory, Sicherheitsgutachten)

Am Endpunkt /owner des FHIR-Proxy darf die Authentifizierung nur für Nutzer erfolgreich sein, die ein gültiges Accesstoken vom VZD-FHIR-Directory vorweisen. Das Accesstoken MUSS im aud Feld den Servernamen des VZD-FHIR-Directory und den Endpunkt /owner enthalten. .
[<=]

ML-138040 - Selbst angelegte HealthcareDirectory-Einträge MÜSSEN mit dem eigenen Basiseintrag verlinkt sein (VZD-FHIR-Directory)

Alle selbst durch den Besitzer angelegten FHIR-Einträge MÜSSEN mit dem eigenen Basiseintrag providedBy verlinkt sein. Wenn keine korrekte Verlinkung angegeben ist, dann MUSS der FHIR-Proxy das Erzeugen oder die Änderung des HealthcareDirectory-Eintrags mit der Fehlermeldung (HTTP 422 Unprocessable Entity) ablehnen. [<=]

ML-136899 - AF_10037 IDP-Dienst ID-TOKEN Prüfung (VZD-FHIR-Directory)

Die ID_TOKEN Prüfung basiert auf Informationen aus dem IDP Discovery Dokument des IDP-Dienstes.
Die URL des Downloadpunktes lautet im Internet: "https://idp.app.ti-dienste.de/.well-known/openid-configuration". 
Das Discovery Dokument muss vor Ausführung der Prüfungen für die aktuelle Umgebung (RU/TU/PU) eingelesen worden sein.

• Prüfung der Signatur des Discovery Dokument: Das VZD-FHIR-Directory muss die Signatur des Discovery Dokument mathematisch prüfen und auf ein zeitlich gültiges C.FD.SIG-Zertifikat mit der Rollen-OID oid_idpd zurückführen können, welches von einer ihm bekannten CA der Komponenten-PKI ausgestellt wurde.
• Prüfung des Signaturzertifikats gegen das X.509-Root-CA Zertifikat der TI.
• OCSP Prüfung des Signaturzertifikats über die OCSP Responder
     Test/RU für EC Zertifikate: http://download-testref.crl.ti-dienste.de/ocsp/ec
      Test/RU für EC Zertifikate: http://download.crl.ti-dienste.de/ocsp/ec
• Regelmäßiges Laden des Discovery Dokuments: Das VZD-FHIR-Directory muss das Discovery Dokument regelmäßig alle 24 Stunden von seinem Downloadpunkt laden und nach seiner erfolgreichen Prüfung die enthaltenen Daten zur Prüfung  von ID_TOKEN verwenden.

Die vom IDP-Dienst ausgestellten ID_TOKEN müssen vom VZD-FHIR-Directory nach folgenden Kriterien geprüft werden:

1. Validierung der gemäß [RFC7519 # section-7.1] vorgeschriebenen Struktur der ID_TOKEN gemäß [RFC7519 # section-7.2]. 
2. Entschlüsselung der verschlüsselten ID_TOKEN entsprechend dem für diese Übertragung vorgesehenen Verfahren mit dem durch das VZD-FHIR-Directory gewählten "token_key". Unverschlüsselte ID_TOKEN sind ungültig und abzulehnen.
3. Prüfung der Signatur der ID_TOKEN gegen den öffentlichen Schlüssel des Token-Endpunktes PUK_IDP_SIG. Das VZD-FHIR-Directory muss den öffentlichen Schlüssel PUK_IDP_SIG zuvor dem Discovery Document des IDP-Dienstes entnehmen.
   1.                     Algorithmus:  "alg": Muss einem zulässigen Wert aus dem Discovery Dokument des IDP-Dienstes, Attribut "id_token_signing_alg_values_supported" entsprechen. Z.B. "BP256R1"
   2.                     Reaktion bei ungültiger oder fehlender Signatur des "ID_TOKEN": Das VZD-FHIR-Directory muss alle mit dem ID_TOKEN verbundenen Vorgänge abbrechen, wenn das ID_TOKEN nicht signiert oder dessen Signatur fehlerhaft ist.
4. Das VZD-FHIR-Directory muss sicherstellen, dass der Zeitraum der Verwendung des Tokens zwischen den im Token mitgelieferten Werten der Attribute iat und exp liegt.
5. Telematik-ID Prüfung: Das ID_Token muss im Attribut idNummer eine Telematik-ID enthalten. ID_Token mit leerem Attribut idNummer müssen abgelehnt werden.
6. Das VZD-FHIR-Directory muss ID_TOKEN ablehnen, wenn die in einem Attribut vorgetragenen Werte nicht dem schematisch erwarteten Datentyp des Attributes entsprechen.

2. Das VZD-FHIR-Directory muss den Claim "aud" des ID_TOKEN gegen seine beim IDP-Dienst registrierte client-id prüfen. Nur wenn diese übereinstimmen, gilt die Prüfung als positiv validiert.
3. Das VZD-FHIR-Directory muss die im ID_TOKEN übertragenen Attribute mit denen vergleichen, die mit dem IDP-Dienst bei der Registrierung vereinbart wurden und alle mit dem ID_TOKEN in Verbindung stehenden Vorgänge abbrechen, wenn dem ID_TOKEN für die Verarbeitung notwendige Claims fehlen oder aber andere als die mit dem IDP-Dienst vereinbarten personenbezogenen Attribute vorhanden sind. 
   • Hinweis: Als unerwartete personenbezogenes Attribute gelten gemäß Tabelle: [gemSpec_IDP_FD#TAB_IDP_DIENST_0005] die Claims given_name, family_name, und organizationName

• Optional: Wenn das VZD-FHIR-Directory im Authorization Request an den IDP-Dienst einen nonce-Parameter gesetzt hat, dann enthält das vom IDP-Dienst ausgestellten ID-Token genau dieser Wert als claim. Das VZD-FHIR-Directory muss dann prüfen, ob der von im im Authorization-Request übergebene nonce-Wert mit dem im ID-Token übereinstimmt.

[<=]

ML-136890 - AF_10037 TIM Registrierungsdienst id_token Prüfung (VZD-FHIR-Directory)

Die vom Registrierungsdienst ausgestellten id_token müssen vom VZD-FHIR-Directory geprüft werden:

• Validierung der gemäß [RFC7519 # section-7.1] vorgeschriebenen Struktur der id_token gemäß [RFC7519 # section-7.2]. 
• Prüfung Signatur des id_token gemäß RFC7515 (das verwendete Zertifikat muss aus der Komponenten-PKI der TI stammen)
  • Zertifikatstyp: C.FD.SIG
  • technische Rolle: oid_tim
• Die telematikID muss im Token Attribut idNummer  enthalten sein.
• Prüfung des id_token Signatur-Zertifikats (oder sein Hash) gegen das bei der Beantragung der Credentials für die Schnittstelle I_VZD_TIM_Provider_Services übergebenen Signatur-Zertifikates.

• OCSP Prüfung des id_token Signatur-Zertifikats
• Prüfung Algorithmus:  "alg": "ES256" oder "BP256R1" 
• Prüfung des Signaturzertifikats gegen das X.509-Root-CA Zertifikat der TI.
• Prüfung der zeitlichen Gültigkeit des id_token für den Zugriff auf den VZD-FHIR-Directory: Das VZD-FHIR-Directory muss sicherstellen, dass der Zeitraum der Verwendung des Tokens zwischen den im Token mitgelieferten Werten der Attribute iat und exp liegt.
• Das VZD-FHIR-Directory muss die im id_token übertragenen Attribute mit denen vergleichen, die mit dem Registrierungsdienst vereinbart wurden und alle mit dem id_token in Verbindung stehenden Vorgänge abbrechen, wenn dem id_token für die Verarbeitung notwendige Claims fehlen oder aber andere als die mit dem IDP-Dienst vereinbarten personenbezogenen Attribute vorhanden sind.
  • Hinweis: Als unerwartete personenbezogenes Attribute gelten gemäß Tabelle: [gemSpec_IDP_FD#TAB_IDP_DIENST_0005] die Claims given_name, family_name, und organizationName
• Audience: "aud": URL der Schnittstelle z.B. "https://fhir-directory.vzd.ti-dienste.de/owner-authenticate"
• Die TelematikID aus dem Token Attribut idNummer muss in der Föderationsliste enthalten sein und der Föderationslisten-Eintrag muss vom gleichen TIM-Provider eingetragen worden sein der auch das Token ausgestellt hat.

[<=]

ML-136887 - AF_10037 TI-Provider-Access-Token Prüfung (VZD-FHIR-Directory)

Die TI-Provider-Access-Token müssen vom VZD-FHIR-Directory für den Endpunkt /tim-provider-services geprüft werden:

• Validierung der gemäß [RFC7519 # section-7.1] vorgeschriebenen Struktur der ACCESS_TOKEN gemäß [RFC7519 # section-7.2].
• Sicherstellung der korrekten Signatur des Tokens gemäß RFC7515:
  • Zertifikatstyp: C.FD.SIG
  • technische Rolle: oid_vzd_ti
  • OCSP Prüfung des Signatur-Zertifikats: Nein
• Zeitliche Gültigkeit: Das VZD-FHIR-Directory muss sicherstellen, dass der Zeitraum der Verwendung des Tokens zwischen den im Token mitgelieferten Werten der Attribute iat und exp liegt.
• Die telematikID muss im Token "sub" claim enthalten sein.

• Das VZD-FHIR-Directory muss die im ACCESS_TOKEN übertragenen Attribute mit denen vergleichen, die vereinbart wurden und alle mit dem ACCESS_TOKEN in Verbindung stehenden Vorgänge abbrechen, wenn dem ID_TOKEN für die Verarbeitung notwendige Claims fehlen oder aber andere als die vereinbarten personenbezogenen Attribute vorhanden sind.
  • Prüfung Audience "aud" aus dem Token (muss der /tim-provider-services Schnittstelle entsprechen, z.B. https://fhir-directory.vzd.ti-dienste.de/tim-provider-services)
  • Hinweis: Als unerwartete personenbezogenes Attribute gelten gemäß Tabelle: [gemSpec_IDP_FD#TAB_IDP_DIENST_0005] die Claims given_name, family_name, und organizationName

• Sicherstellung der korrekten Signatur des Tokens gemäß RFC7515:
  • Prüfung Algorithmus:  "alg": "ES256" oder "BP256R1" 

[<=]

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

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

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

[<=]

ML-123881 - Authentifizierung an der Schnittstelle I_VZD_TIM_Provider_Services (VZD-FHIR-Directory, Sicherheitsgutachten)

An der Schnittstelle I_VZD_TIM_Provider_Services darf die Authentifizierung nur für Clients erfolgreich sein, die ein gültiges provider-accesstoken vom OAuth-Server des VZD-Anbieters vorweisen.
[<=]

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

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

 

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

[<=]

ML-134278 - Synchronisierung VZD-LDAP-Directory mit FHIR-Directory (VZD-FHIR-Directory)

Der VZD FHIR-Proxy muss gewährleisten, dass nach einem konfigurierbaren Intervall die im VZD-LDAP-Directory seit der letzten Aktualisierung geänderten Einträge in das VZD FHIR-Directory synchronisiert wurden.
[<=]

5.5 Versicherter sucht Einträge im FHIR-Directory

AF_10219 - Versicherter sucht Einträge im FHIR-Directory

Abbildung 78: Sequence diagram /fdv/search

[<=]

ML-146154 - Authentifizierung am Endpunkt /fdv/search (VZD-FHIR-Directory, Sicherheitsgutachten)

Am Endpunkt /fdv/search des FHIR-Proxy darf die Authentifizierung nur für Requests erfolgreich sein, die ein gültiges search-access_token im Authentication Header enthalten, das vom Auth-Service service-authenticate Endpunkt oder tim-authenticate Endpunkt für den Endpunkt /fdv/search ausgestellt wurde. [<=]

5.6 Erstellen einer Verlinkungsanfrage

AF_10208 - FHIR-Directory - Erstellen einer Verlinkungsanfrage

Abbildung 9: Sequence diagram - Erstellen einer Verlinkungsanfrage

[<=]

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

ML-143802 - Erstellen einer Verlinkungsanfrage

Der FHIR VZD muss für Verlinkungsanfragen sicherstellen:

• Nur authentisierte Nutzer dürfen Verlinkungsanfragen für ihre FHIR VZD Einträge stellen.
• Die Verlinkungsanfragen werden gespeichert und sind noch nicht in den normalen FHIR VZD Daten sichtbar.

[<=]

5.7 Bestätigen einer Verlinkungsanfrage

AF_10207 - FHIR-Directory - Bestätigen einer Verlinkungsanfrage

Abbildung 10: Sequence diagram - Bestätigen einer Verlinkungsanfrage

[<=]

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

ML-143808 - Bestätigung einer Verlinkungsanfrage

Der FHIR VZD muss für die Bestätigung von Verlinkungsanfragen sicherstellen:

• Nur authentisierte Nutzer dürfen offene Verlinkungsanfragen für ihre FHIR VZD Einträge bestätigen.
• Die Verlinkungsbestätigungen werden in den Verlinkungsdaten gespeichert.
• In den FHIR VZD Daten wurde die Verlinkung ergänzt.
• Der Nutzer/Client muss alle relevanten Informationen über den Status der Verlinkungsanfragen einsehen können, an denen er beteiligt ist.
  Dazu zählen zum Beispiel seine offenen Verlinkungsanfragen (als Anfragender oder als Bestätigender), die Bestätigung oder Ablehnung seiner Verlinkungsanfragen und die Löschung von Verlinkungen, an denen er beteiligt ist.

[<=]

ML-143872 - Ablehnung einer Verlinkungsanfrage

Der FHIR VZD muss die Ablehnung von Verlinkungsanfragen (über Anwendungsfall AF_10209 "Löschen einer Verlinkungsanfrage") erlauben:

• Nur authentisierte Nutzer dürfen offene Verlinkungsanfragen für ihre FHIR VZD Einträge ablehnen/zurückziehen (beide beteiligten Seiten).
• Die Verlinkungsablehnungen werden in den Verlinkungsdaten gespeichert.
• In den FHIR VZD Daten wurde die Verlinkung nicht eingetragen.
• Der Nutzer/Client muss alle relevanten Informationen über den Status der Verlinkungsanfragen einsehen können, an denen er beteiligt ist. Dazu zählen zum Beispiel seine offenen Verlinkungsanfragen (als Anfragender oder als Bestätigender), die Bestätigung oder Ablehnung seiner Verlinkungsanfragen und die Löschung von Verlinkungen, an denen er beteiligt ist.

[<=]

5.8 Löschen einer Verlinkungsanfrage

AF_10209 - FHIR-Directory - Löschen einer Verlinkung

 

Abbildung 11: Sequence diagram - Löschen einer Verlinkung

[<=]

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

ML-143811 - Löschen einer Verlinkung

Der FHIR VZD muss für die Löschung von Verlinkungen sicherstellen:

• Nur authentisierte Nutzer dürfen Verlinkung für ihre FHIR VZD Einträge bzw. für ihren Zuständigkeitsbereich löschen.
• Die Löschung der Verlinkung wird in den Verlinkungsdaten gespeichert.
• In den FHIR VZD Daten wurde die Verlinkung gelöscht.

[<=]

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 812: VZD-FHIR-Directory, Verteilungssicht  

7 Anhang A – Verzeichnisse

7.1 Abkürzungen

7.2 Glossar

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

7.3 Abbildungsverzeichnis

Abbildung 1: Systemüberblick VZD-FHIR-Directory

Abbildung 2: Zerlegung des VZD

Abbildung 3: Sequence diagram /search

Abbildung 4: Sequenzdiagramm VZD-FHIR-Directory Änderung von eigenen OrganizationDirectory- oder PractitionerDirectory-Einträgen 

Abbildung 5: VZD-FHIR-Directory_Sequenzdiagramm_TI-Messenger-Provider-Services : Sequence diagram - Authentifizierung mit dem gematik Authenticator

Abbildung 6:  VZD-FHIR-Directory, Aktualisierung der Basiseinträge_Sequenzdiagramm_TI-Messenger-Provider-Services

Abbildung 7: Sequence diagram /fdv/search VZD-FHIR-Directory, Aktualisierung der Basiseinträge

Abbildung 8: VZD-FHIR-Directory, Verteilungssicht   Sequence diagram /fdv/search

7.4 Tabellenverzeichnis

Tabelle 1: Nutzer und Rollen Abbildung 9: Sequence diagram - Erstellen einer Verlinkungsanfrage

Tabelle 2: Kommunikationsbeziehungen zu IT-SystemenAbbildung 10: Sequence diagram - Bestätigen einer Verlinkungsanfrage

Tabelle 3: VZD-FHIR-Directory, FHIR-RessourcenAbbildung 11: Sequence diagram - Löschen einer Verlinkung

Tabelle 4: Tab_VZD_TI-Anwendungen_EndpointAbbildung 12: VZD-FHIR-Directory, Verteilungssicht  

7.4 Tabellenverzeichnis

Tabelle 5: Tab_VZD_TIM-Provider-Services_Operations 1: Nutzer und Rollen 

Tabelle 6: Tab_VZD_FHIR_Perf 2: Kommunikationsbeziehungen zu IT-Systemen

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

Tabelle 4: Tab_VZD_TI-Anwendungen_Endpoint

Tabelle 5: Tab_VZD_TIM-Provider-Services_Operations

7.5 Referenzierte Dokumente

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

7.5.2 Weitere Dokumente

Mitgeltende Dokumente und Web-Inhalte

7.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/0.10.2