gemSpec_VZD_FHIR_Directory_V1.0.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Verzeichnisdienst FHIR-Directory

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
01.10.2021
     
     

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

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 Einträge werden mit den Einträgen im VZD-LDAP-Directory synchronisiert. Bei diesem Vorgang erfolgt eine Umsetzung von der LDAP-Datenstruktur auf die Datenstruktur der FHIR-Ressourcen. Personeneinträge der Leistungserbringer werden auf die TIPractitioner-Ressource und Organisations-Einträge auf die TIOrganization-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. TIPractitioner und TIOrganization sind Profilierungen der FHIR-Ressourcen Practitioner und Organization. Die Anbieter von Fachanwendungen werden ebenfalls als TIOrganization-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. Location 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 ist nicht zulässig.

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

Abbildung 1: Systemüberblick VZD-FHIR-Directory

Das VZD-FHIR-Directory besteht aus den logischen Komponenten FHIR-Directory, FHIR-Proxy und PASSporT-Service.

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

Der FHIR-Proxy terminiert die TLS-Verbindungen, prüft die Zugriffsberechtigung der Nutzer und verteilt die Anfragen der Nutzer auf die Instanzen des FHIR-Directory sowie des PASSporT-Service. Zusätzlich übernimmt und aktualisiert der FHIR-Proxy die Basiseinträge im VZD-FHIR-Directory mit den geänderten Daten des VZD-LDAP-Directories.

Der PASSporT-Service ist eine Komponente, die Personal Assertion Token gemäß [RFC8225] ausstellt. Die Token bestätigen, dass ein Leistungserbringer oder eine Organisation durch die Eintragung der TI-Messenger-Adresse im VZD-FHIR-Directory damit einverstanden ist, dass eine TI-Messenger-Kommunikation zu dieser Adresse aufgebaut werden darf. Für die Signatur des PASSporT wird ein Zertifikat aus der Komponenten PKI der TI verwendet.

3 Systemkontext

3.1 Akteure und Rollen

Das VZD-FHIR-Directory ist ein Dienst der Telematikinfrastruktur und kann von allen Nutzern der TI abgefragt werden. Zusätzlich ist es erforderlich, dass die Einträge gepflegt werden. Dies erfolgt durch die Kartenherausgeber, die Fachanwendungen, falls spezifische Fachdaten den Einträgen zugeordnet sind, und optional durch die Besitzer der Einträge.

Tabelle 1: VZD_FHIR_Directory_Akteure_und_Rollen

3.2 User Stories

• Als TI-Messenger-Nutzer möchte ich komfortabel nach Leistungserbringern und Organisationen suchen können, so dass ich keine Zeit und Nerven damit verschwenden muss, einen geeigneten TI-Messenger-Kommunikationspartner zu finden.
  
• Als TI-Messenger-Nutzer möchte ich die Ortungsfunktion meines Geräts nutzen können, um nahegelegene Leistungserbringer und Organisationen finden zu können, so dass ich spontan den für mich bestgelegene Organisation auswählen kann.
  
• Als TI-Messenger-Nutzer möchte ich in der Lage sein, Organisationen herauszufiltern, die gerade geöffnet haben oder die bald öffnen werden, so dass ich nicht vor verschlossenen Türen stehe, wenn ich die Organisation aufsuchen will.
  
• Als TI-Messenger-Nutzer möchte ich in der Lage sein, mir von meiner bevorzugten Navigations-App eine Route zur ausgewählten Organisation berechnen zu lassen, so dass ich nicht Adressen in meine Navigations-App kopieren muss, um den Weg zu finden.
  
• Als TI-Messenger-Nutzer möchte ich, dass die Suchfunktion meiner App fehlertolerant ist, wenn ich mich beim Eingeben des Organisationsnamens vertippe oder es mehrere Organisationen mit ähnlichem Namen gibt.
• Als TI-Messenger-Nutzer möchte ich in meiner App verschiedene Such- und Filterfunktionen kombinieren können wie z.B. die Ortungsfunktion und die Filterung nach Öffnungszeiten, um eine Organisation zu finden.
• Als TI-Messenger-Nutzer möchte ich weitere Informationen zu einer Organisation erhalten, um mich mit ihr in Verbindung setzen bzw. über sie informieren zu können (z.B. TI-Messenger-Adresse, Webseite, E-Mail-Adresse, Telefonnummer, Fax).

• Als Besitzer eines Eintrags im VZD-FHIR-Directory, brauche ich einen supportverantwortlichen Ansprechpartner mit entsprechenden Serviceleveln für die technische Schnittstelle.

• Als Kartenherausgeber brauche ich eine einfache (technische) Möglichkeit, die Daten für die ich verantwortlich bin, im VZD-FHIR-Directory editieren zu können (einstellen, lesen, verändern, löschen).
• Als Kartenherausgeber brauche ich einen supportverantwortlichen Ansprechpartner mit entsprechenden Serviceleveln für die technische Schnittstelle.
• Als Kartenherausgeber  möchte ich komfortabel und in angemessener Antwortzeit nach Leistungserbringern bzw.   Organisationen in meinem Verantwortungsbereich suchen können, so dass ich keine Zeit und Nerven damit  verschwenden muss, die Einträge adäquat verwalten zu können.
• Als  Kartenherausgeber möchte ich meinen Account zum VZD-FHIR-Directory komfortabel erhalten und verwalten können, so dass ich keine Zeit und Nerven damit verschwenden muss.
• Als  Kartenherausgeber möchte ich, dass bei einem Ausfall oder Störungen des VZD-FHIR-Directory die Nutzer und die Kartenherausgeber entsprechendes Feedback und Support erhalten und ggf. Fehlermeldungen korrekt eingestellt und weitergeleitet werden.

• Als Anbieter einer Fachanwendung brauche ich eine einfache (technische) Möglichkeit, die fachlichen Daten meiner Fachanwendung im VZD-FHIR-Directory editieren zu können (einstellen, lesen, verändern, löschen).
• Als Anbieter einer Fachanwendung brauche ich einen supportverantwortlichen Ansprechpartner mit entsprechenden Serviceleveln für die technische Schnittstelle.

• Als Gesamtverantwortlicher für die TI möchte ich steuern können, wer einen Zugriff auf die Pflegeschnittstelle des VZD-FHIR-Directory erhält und jederzeit eine aktuelle Übersicht für alle Umgebungen (RU/TU/PU) haben.
• Als Gesamtverantwortlicher für die TI möchte ich jederzeit wissen, welche Daten im VZD-FHIR-Directory hinterlegt sind und ob diese korrekt sind bzw. Fehlermeldungen vorliegen.
• Als Gesamtverantwortlicher für die TI möchte ich, dass nur berechtigte Institutionen für die Pflege der Informationen im VZD-FHIR-Directory die entsprechenden Berechtigungen (er)halten.
• Als Gesamtverantwortlicher für die TI muss ich sicherstellen, dass bei einem  Ausfall oder Störungen des VZD-FHIR-Directory die Nutzer und die Kartenherausgeber entsprechendes Feedback und  Support erhalten und ggf. Fehlermeldungen korrekt eingestellt und weitergeleitet  werden.

3.3 Nachbarsysteme

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

4 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 PASSPorT-Service. Die Schnittstelle zwischen FHIR-Proxy und PASSporT-Service wird nicht vorgegeben.

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.

5 Funktionsmerkmale

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

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

5.1.1 Datenmodell

Es werden die FHIR-Ressourcen nach folgender Tabelle verwendet.

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

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

code value="tim-domain"

display value="TI-Messenger domain name"

5.1.2 Mapping von LDAP auf FHIR-Ressourcen

Die TIOrganization- und TIPractitioner-Basiseinträge werden durch den FHIR Proxy mit den Daten aus dem VZD-LDAP-Directory initial erzeugt und anschließend fortlaufend aktualisiert. Die 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.

Tabelle 3: VZD-FHIR-Directory_Mapping_LDAP_to_FHIR

5.1.3 FHIR RESTful API

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

5.2 FHIR-Proxy und PASSporT-Service

5.2.1 Schnittstellen

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

5.2.1.2 FHIR Schnittstelle für TI-Messenger-Nutzer

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

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

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

In der Testumgebung ist die URL: https://tu-vzd-fhir-directory-test.vzd.ti-dienste.de/tim-search 

Authentisierung

Um die Schnittstelle nutzen zu können MÜSSEN sich die Clients mit einem gültigen Accesstoken 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, dass für Suchanfragen des TI-Messenger-Clients verwendet wird. Die Gültigkeitsdauer ist 24 Stunden.

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.

Endpunkte für die Authentisierung

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

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

In der Testumgebung ist die URL: https://tu-vzd-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.

PASSporT-Service

Das VZD-FHIR-Directory MUSS für alle gefundenen MXIDs PASSporT erzeugen und in die Response einfügen (siehe AF_10036).

Der Aufbau des PASSporT MUSS wie im RFC[8225] beschrieben erfolgen. Die Befüllung der gezeigten Header Elemente MUSS wie im RFC[8225] gefordert erfolgen und wie folgt aufgebaut sein:

Die TI-Messenger spezifischen PASSporT-Claims sind durch den PASSporT-Service wie folgt zu befüllen. Der Claim mit dem Bezeichner "orig" ist die MXID des Nutzers der den GET /tim_search Request ausgeführt hat. Der Claim "dest" wird mit der MXID des gefundenen Eintrags befüllt. Die MXIDs werden in url Notation angegeben. Das folgende Beispiel zeigt eine solche Struktur.

Dieses erzeugte PASSporT wird dann durch den PASSporT-Service signiert und anschließend an die gefundene MXID angefügt (matrix:u/you:example.org/?PASSporT=[PASSporT-String]).

Die ausgestellten PASSporT werden mit einem Zertifikat aus der Komponenten PKI der TI signiert. Die Zertifikate haben die keyUsage = digitalSignature.

5.2.1.3 FHIR-Schnittstelle für Besitzer

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 (TIPractitioner oder TIOrganization) 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://vzd-fhir-directory.vzd.ti-dienste.de/owner 

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

In der Testumgebung ist die URL: https://tu-vzd-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 TIOrganization-Eintrag KÖNNEN weitere TIOrganization-Einträge erstellt und mit dem eigenen 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.

Endpunkte für die Authentisierung

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

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

In der Testumgebung ist die URL: https://tu-vzd-fhir-directory-test.vzd.ti-dienste.de/owner-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.

5.2.1.4 Schnittstelle I_VZD_TIM_Provider_Services

Endpunkte

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

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

In der Testumgebung ist die URL: https://tu-vzd-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 mit einem Accesstoken authentisieren, das vom OAuth-Server des VZD-Anbieters ausgestellt wurde. Das Accesstoken hat eine Gültigkeitsdauer von 30 Minuten.

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.

Endpunkte für die Authentisierung

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

In der Referenzumgebung ist die URL: https://ru-oauth-test.vzd.ti-dienste.de/authenticate 

In der Testumgebung ist die URL: https://tu-oauth-test.vzd.ti-dienste.de/authenticate 

Registrierung

Für die Zugriff auf den OAuth-Server MUSS der TI-Messenger-Anbieter für seinen Registrierungsdienst beim VZD-Anbieter Client-Credentials beantragen. Die Beantragung erfolgt über einen Service-Request an betrieb@gematik.de mit dem Betreff "VZD-FHIR-Directory (De-)/Registrierung" notwendig.

Die Registrierung und Vergabe der Credentials erfolgt dabei auf Organisationsebene.

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

• Angaben zur Rolle (hier Admin_TI_Messenger_Data) 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 im OAuth2-Server ID_TOKEN claim scope

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/master/src/I_VZD_TIM_Provider_Services.yaml 

Tabelle 4: Tab_VZD_TIM-Provider-Services_Operations

Im Attribut "sub" des Accesstoken ist die client_id des TI-Messenger-Registrierungsdienstes enthalten. Wenn der TI-Messenger-Registrierungsdienst einen TIOrganization-Eintrag erzeugt, dann MUSS die client_id im Element alias des Eintrage enthalten sein

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

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

5.2.3 Erzeugung und Verteilung der Föderationsliste

Der FHIR-Proxy MUSS bei jeder Änderung an den Endpoint-Einträgen der TIM-Anbieter über die Schnittstelle I_VZD_TIM_Provider_Services die Föderationsliste aktualisieren und dabei die Versionsnummer erhöhen und anschließend über ein internes Netzwerk des Anbieters auf alle FHIR-Proxy-Instanzen verteilen sowie für die Abfrage über die Schnittstelle I_VZD_TIM_Provider_Services bereithalten.

Die Föderationsliste wird vollständig erzeugt, indem alle Endpoint Einträge abgefragt werden, die das CodeSystem connectionType.System = https://gematik.de/fhir/VZD-FHIR-Directory/CodeSystem/TIMessengerCS 

und den connectionType.code == "tim-domain" haben.

Für jeden Endpoint-Eintrag wird aus dem Wert des Elements "name" mit dem Hash-Algorithmus "SHA-256" ein hash gebildet und in die Föderationsliste eingetragen. In der Föderationsliste MUSS das Element hashAlgorithm den Wert "SHA-256" haben

(siehe I_VZD_TIM_Provider_Services.yaml).

Die Aktualisierung der Föderationsliste KANN so implementiert werden, dass nur die geänderten Endpoint-Einträge in der Föderationsliste aktualisiert werden (z. B. über FHIR R4.5.1 Subscriptions; siehe https://build.fhir.org/subscription.html ).

Der Anbieter des VZD-FHIR-Directories MUSS geeignete Maßnahmen vorsehen, die verhindern, dass die Föderationsliste manipuliert werden kann.

5.3 Übergreifende Vorgaben

5.3.1 Sicherheit

Schutz vor Sicherheits-Risiken

Das VZD-FHIR-Directory MUSS Maßnahmen zum Schutz vor Sicherheits-Risiken gemäß der aktuellen Version der OWASP-Top-10 umsetzen (https://owasp.org/www-project-top-ten/ ).

Es gelten Die Anforderungen an TLS-Verbindungen gemäß [gemSpec_Krypt#3.3.2] TLS-Verbindungen.

5.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 mit einer vollumfänglich-funktionalen Verfügbarkeit von 99,8 % zur Hauptzeit und 99 % zur Nebenzeit betreibbar sein.

Der Anbieter des VZD-FHIR-Directorys MUSS sein Produkt VZD-FHIR-Directory mit einer vollumfänglich-funktionalen Verfügbarkeit von 99,8 % zur Hauptzeit und 99 % zur Nebenzeit betreiben.

6 Anwendungsfälle

6.1 TI-Messenger-Nutzer sucht TIOrganization- und TIPractitioner-Einträge im VZD-FHIR-Directory

AF_10036 - TI-Messenger-Nutzer sucht TIOrganization- und TIPractitioner-Einträge im VZD-FHIR-Directory

Attribute	Bemerkung
Beschreibung	TI-Messenger-Clients können im VZD-FHIR-Directory nach TIOrganization- und TIPractitioner-Einträgen suchen. Wenn im TI-Messenger-Client kein gültiges Accesstoken vom FHIR-Proxy vorhanden ist, wird vom TI-Messenger-Client am Matrix-Homeserver ein Matrix-OpenID-Token abgefragt und mit dem Matrix-OpenID-Token im Auth-Header der Endpunkt /tim-search mit den Suchparametern aufgerufen. Der FHIR-Proxy prüft das vom TI-Messenger-Client übergebene Matrix-OpenID-Token. Dabei MUSS der im Matrix-OpenID-Token angegebene matrix_server_name in der TI-Messenger Föderationsliste enthalten sein. Der FHIR-Proxy ruft am Matrix-Homeserver die Operation GET/openid/userinfo mit dem Matrix-OpenID-Token als Parameter auf und erhält die Bestätigung für die MXID des TI-Messenger-Nutzers. Damit ist die Authentisierung des Nutzers abgeschlossen. Der FHIR-Proxy erstellt ein Accesstoken, dass die MXID des TI-Messenger-Nutzers enthält und sendet es an den TI-Messenger-Client. Der TI-Messenger-Client sendet ein GET Request gemäß FHIR-Spezifikation an den Endpunkt /tim-search des FHIR-Proxy. Im Authentication Header ist das Accesstoken (inklusive MXID des Nutzers) enthalten. Wenn nach TIPractitioner-Einträgen gesucht wird, dann prüft der FHIR-Proxy, ob die MXID des anfragenden Nutzers in einem TIPractitioner-Eintrag im FHIR-Directory gespeichert ist. Falls nicht, dann werden keine TIPractitioner-Einträge gesucht. Der GET Request gemäß FHIR-Spezifikation wird vom FHIR-Proxy an das FHIR-Directory per http-Forward weitergeleitet. Der FHIR-Proxy erhält vom FHIR-Directory eine Response mit den gefundenen Einträgen als json Daten. Die gefundenen TIOrganization- und TIPractitioner-Einträge können in telecom Elementen MXIDs in url Notation enthalten sein. Der FHIR-Proxy prüft jedes telecom Element. Wenn eine MXID url enthalten ist und kein period.end Element angegeben ist, dass in der Vergangenheit liegt, wird über die logische Komponente PASSporT-Service ein PASSporT erzeugt, dass die MXID des anfragenden Nutzers (im Attribut orig) und die MXID des gefundenen Nutzers (im Attribut dest) enthält. Das PASSporT wird in die json Datenstruktur der Response an die url notierte MXID des gefundenen Nutzers in folgender Form angehängt: matrix:u/localpart:tim-domain/?PASSporT=[PASSporT-String]. Gefundene Einträge ohne MXID und PASSporT werden aus der Response entfernt. Die so geänderte Response wird an den TI-Messenger-Client gesendet.  Die Anzahl der gefundenen und zurückgegebenen Einträge wird initial auf 100 begrenzt. Dieser Wert MUSS konfigurierbar sein. Zusätzlich MUSS konfigurierbar sein, ob Paging eingesetzt wird und wie groß die page_size ist. Paging ist initial eingeschaltet mit page_size = 10.
Vorbedingung	Der Nutzer ist an seinem Homeserver registriert.
Nachbedingung	Der TI-Messenger-Client hat alle gefundenen Einträge empfangen. Für MXIDs, mit denen eine Kommunikation begonnen werden darf liegt ein PASSporT vor.

Abbildung 3: Sequence diagram /tim-search

[<=]

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

6.2 TIOrganization-Einträge oder TIPractitioner-Einträge im VZD-FHIR-Directory ändern

AF_10037 - TIOrganization-Einträge oder TIPractitioner-Einträge im VZD-FHIR-Directory ändern

Attribute	Bemerkung
Beschreibung	Organisationen können ihren Eintrag im VZD-FHIR-Directory an die eigenen Strukturen anpassen. Leistungserbringer können z. B. die TI-Messenger-Adresse in ihrem Eintrag hinzufügen. Der Basiseintrag einer Organisation oder eines Leistungserbringers wird wie bisher durch die Kartenherausgeber erstellt. Die Organisation KANN eigene mit dem Basiseintrag verlinkte Organisationseinträge mit eigenen Daten erstellen, um die Struktur der Organisation abzubilden. Zum Beispiel können Krankenhäuser ihre Fachabteilungen als Organisations-Einträge abbilden, die mit dem Basis-Eintrag verlinkt sind. Der ausführende Akteur hat die Rolle Admin_Owner. Wenn kein gültiges Accesstoken vom VZD-FHIR-Directory im Client vorliegt, muss die Authentisierung mittels OIDC an einem IDP der TI-IDP-Föderation erfolgen. Nach erfolgreicher Authentisierung ist die durch den IDP bestätigte Telematik-ID des Leistungserbringers oder der Organisation am FHIR-Proxy bekannt. Dadurch erhält der Client das Recht den Eintrag im FHIR-Directory mit dieser Telematik-ID zu ändern. Für den Aufruf der FHIR-Operationen durch den Client stellt der FHIR-Proxy ein Accesstoken aus, dass auch die Telematik-ID des LE oder der Organisation enthält. Voraussetzung für das Erzeugen oder Ändern von TIOrganization-Einträgen unterhalb des Basiseintrags ist, dass immer eine partOf Referenz zum Basiseintrag der eigenen Organisation angegeben ist. Wenn eine Kette von TIOrganization-Einträgen mit partOf Referenzen erzeugt werden soll, dann MUSS am Ende der Kette immer die eigene TIOrganization verlinkt sein.
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.
Fehlermeldungen	HTTP 422 Unprocessable Entity: Request zum Erstellen oder Ändern eines TIOrganisation-Eintrags enthält keine partOf Verlinkung zum TIOrganisation-oder TIPractitioner-Basiseintrag.

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

[<=]

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

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

AF_10048 - 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 Endpoint-Einträgen gespeichert. Die Endpoint-Einträge eines TI-Messenger-Anbieters sind verlinkt mit seinem TIOrganization-Eintrag. 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 OAuth-Server ein Accesstoken, das zur Authentifizierung an der Schnittstelle genutzt wird. Nach erfolgreicher Authentisierung kann der Registrierungsdienst die FHIR-Operationen zur Verwaltung des eigenen TIOrganisation-Eintrags und der eigenen Endpoint-Einträge 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. Das VZD-FHIR-Directory stellt für gefundene MXIDs (Matrix-Adressen) Personal Assertion Token (PASSporT) aus. Die PASSporT werden vom TI-Messenger-Service geprüft. Um die PASSporT-Signatur prüfen zu können wird das zugehörige Zertifikat benötigt. Mit der Operation GET /PASSporTCertificates können die Zertifikate abgefragt werden. Siehe auch: https://github.com/gematik/api-vzd/blob/master/src/I_VZD_TIM_Provider_Services.yaml
Vorbedingung	Der Registrierungsdienst des TI-Messenger-Anbieters ist bereits als Nutzer des VZD-FHIR-Directories registriert und hat OAuth Client Credentials (client_id und client_secret) für die Umgebungen RU, TU und PU erhalten.

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

[<=]

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

AF_10047 - 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äß Tabelle 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. Einträge ohne Zertifikat erhalten im VZD-FHIR-Directory den Wert TIOrganization.active = false bzw. TIPractitioner.active = false Wird zu einem Eintrag im VZD-LDAP-Directory wieder ein Enc-Zertifikat ergänzt, dann erhält der Eintrag im VZD-FHIR-Directory den Wert TIOrganization.active = true bzw. TIPractitioner.active = true.

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

[<=]

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

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

9 Anhang B - Beispiele

9.1 FHIR Operationen

9.1.1 Abfrage von TIOrganisation Einträgen

9.1.1.1 Client Code

// Create a client (only needed once)
FhirContext ctx = new FhirContext();
IGenericClient client = ctx.newRestfulGenericClient("http://hapi.fhir.org/baseR4");

// Invoke the client
Bundle bundle = client.search().forResource(TIOrganization.class).where(new StringClientParam("address").matches().value("10117"))
.include(new Include("TIOrganization:endpoint"))
.prettyPrint()
.execute();

9.1.1.2 Request

GET http://hapi.fhir.org/baseR4/TIOrganization?address=10117&_include=TIOrganization:endpoint&_pretty=true

9.1.1.3 Request Headers

Accept-Charset: utf-8
Accept: application/fhir+xml;q=1.0, application/fhir+json;q=1.0, application/xml+fhir;q=0.9, application/json+fhir;q=0.9
User-Agent: HAPI-FHIR/5.5.0-PRE1-SNAPSHOT (FHIR Client; FHIR 4.0.1/R4; apache)
Accept-Encoding: gzip

9.1.1.4 Response

HTTP 200 OK

9.1.1.5 Response Headers

x-request-id: hr3p6Pi0jorUblN7
date: Fri, 06 Aug 2021 10:22:24 GMT
last-modified: Fri, 06 Aug 2021 10:22:23 GMT
server: nginx/1.18.0 (Ubuntu)
transfer-encoding: chunked
x-powered-by: HAPI FHIR 5.5.0-PRE1-SNAPSHOT/1703568840/2021-05-28 REST Server (FHIR Server; FHIR 4.0.1/R4)
connection: keep-alive
content-type: application/fhir+json;charset=utf-8

9.1.1.6 Response Body

{
  "resourceType": "Bundle",
  "id": "ec8a4846-5719-4760-833f-606f01ea6055",
  "meta": {
    "lastUpdated": "2021-08-06T06:56:44.620+00:00"
  },
  "type": "searchset",
  "total": 2,
  "link": [ {
    "relation": "self",
    "url": "http://hapi.fhir.org/baseR4/TIOrganization?_include=TIOrganization%3Aendpoint
&_pretty=true&address=10117"
  } ],
  "entry": [ {
    "fullUrl": "http://hapi.fhir.org/baseR4/TIOrganization/2500949",
    "resource": {
      "resourceType": "TIOrganization",
      "id": "2500949",
      "meta": {
        "versionId": "1",
        "lastUpdated": "2021-08-04T15:51:20.261+00:00",
        "source": "#0j3wXiC80VNH7wON"
      },
      "name": "Test Organisation der TI",
      "telecom": [ {
        "system": "url",
        "value": "matrix:u/testorg:gematik.de"
      } ],
      "address": [ {
        "line": [ "Friedrichstr. 136" ],
        "city": "Berlin",
        "state": "Berlin",
        "postalCode": "10117",
        "country": "Germany"
      } ]
    },
    "search": {
      "mode": "match"
    }
  }, {
    "fullUrl": "http://hapi.fhir.org/baseR4/TIOrganization/2500973",
    "resource": {
      "resourceType": "TIOrganization",
      "id": "2500973",
      "meta": {
        "versionId": "1",
        "lastUpdated": "2021-08-04T16:55:16.931+00:00",
        "source": "#q5G1swl1SHzfbbjj"
      },
      "name": "Test Organisation 2 der TI",
      "telecom": [ {
        "system": "url",
        "value": "matrix:u/testorg2:gematik.de"
      } ],
      "address": [ {
        "line": [ "Friedrichstr. 136" ],
        "city": "Berlin",
        "state": "Berlin",
        "postalCode": "10117",
        "country": "Germany"
      } ],
      "endpoint": [ {
        "reference": "Endpoint/2500968"
      } ]
    },
    "search": {
      "mode": "match"
    }
  }, {
    "fullUrl": "http://hapi.fhir.org/baseR4/Endpoint/2500968",
    "resource": {
      "resourceType": "Endpoint",
      "id": "2500968",
      "meta": {
        "versionId": "1",
        "lastUpdated": "2021-08-04T16:27:54.228+00:00",
        "source": "#bsfK2WXBApjsoYj8"
      },
      "connectionType": {
        "system": "https://gematik.de/fhir/VZD-FHIR-Directory/CodeSystem/TIMessengerCS",
        "code": "tim-domain"
      },
      "name": "gematik.de",
      "managingOrganization": {
        "reference": "TIOrganization/2500949"
      }
    },
    "search": {
      "mode": "include"
    }
  } ]
}