C_12194 - VZD Änderungen

Inhaltsverzeichnis

1 Änderung in gemSpec_VZD

Es wird Kapitel "3.1 IT-Sicherheit und Datenschutz" wie folgt aufgenommen

3.1 IT-Sicherheit und Datenschutz

...

TIP1-A_5555 - VZD, SOAP-Fehlercodes

Der VZD MUSS für seine SOAP-Schnittstelle die generischen Fehlercodes

• Code 2: Verbindung zurückgewiesen
  
• Code 3: Nachrichtenschema fehlerhaft
  
• Code 4: Version Nachrichtenschema fehlerhaft
  
• Code 6: Protokollfehler
  

aus Tabelle Tab_Gen_Fehler  aus [gemSpec_OM] im SOAP-Fault verwenden. Erkannte Fehler auf Transportprotokollebene müssen auf gematik SOAP Faults (Code 6 aus Tabelle Tab_Gen_Fehler aus [gemSpec_OM]) abgebildet werden.

<=

...

Es wird Kapitel "3.3 Anforderungen an VZD Clients" wie folgt aufgenommen

3.3 Anforderungen an VZD Clients

A_27744 VZD Clients - Nutzung zentraler TI-Systeme durch dezentrale Clients: Verbindungsmanagement

Dezentrale Client-Systeme MÜSSEN dafür sorgen, dass Verbindungen nur im Zusammenhang mit einem konkreten fachlichen Use Case, der die Nutzung der entsprechenden Schnittstelle zwingend erfordert, aufgebaut werden. Verbindungsaufbauten im Rahmen eines Initialisierungsprozesses sind zu vermeiden und sind nur in Kombination mit einem wirksamen Connection-Idle-Timeout zulässig. Das Absetzen regelmäßiger Dummy-Requests zum Umgehen des Idle-Timeouts oder zu anderen Zwecken (z.B. Monitoring) ist nicht erlaubt.

Ein Client hat sicherzustellen, dass gleichzeitig maximal eine Verbindung zur VZD-Schnittstelle aufgebaut wird. Das gleichzeitige Öffnen mehrerer paralleler Verbindungen durch denselben Client ist nicht zulässig, es sei denn, ein verbindliches Maximum wird für eine Schnittstelle explizit definiert.

Im Fall des Fehlschlagens des Verbindungsaufbau MUSS eine Wartezeit bis zum nächsten Verbindungsversuch eingehalten werden (Retry-Intervall). Das Retry-Intervall ist mit zunehmender Anzahl fehlgeschlagener Verbindungsversuch bis zu einem Maximum zu erhöhen.

Verbindungen sind nach Beendigung des fachlichen Use Cases zeitnah zu schließen (5 Sek). Erfolgt dies nicht, MUSS nach Ablauf des Connection-Idle-Timeouts die Verbindung abgebaut werden.

Die maximale Bearbeitungsdauer einer Abfrage ist clientseitig per Konfiguration festzulegen. Um potenzielle Überlastsituationen durch langlaufende Anfragen (> 30 Sekunden) zu vermeiden, durch den VZD eine Begrenzung der maximalen Bearbeitungsdauer serverseitig (TimeOut) mit Beendigung der Abfrage möglich.

<=

A_27749 VZD Client - Nutzung zentraler TI-Systeme durch dezentrale Clients: Verbindungsmanagement, Parameter

Dezentrale Client-Systeme oder Apps MÜSSEN parametrisierbar sein, d.h. folgende Parameter müssen aus der Ferne zentral angepasst werden können. Die Standardwerte (Default) MÜSSEN nach Aufforderung durch die gematik in einem [noch zu definierenden Prozess] innerhalb einer [noch festzulegenden Zeit] anpassbar sein.

Parameter	Beschreibung	Standardwerte (Default)
CONNECTION_IDLE_TIMEOUT (Hinweis: DieParameternamenmüssen ggf. produkt-oder Schnittstellenspezifisch angepasst werden)	Haltedauer der TCP-Verbindung eines Clients zu einem Dienst, in der kein Datenverkehr zwischen Client und Dienst stattfindet.	30 Sek
MAX_CONNECTION	Anzahl der pro Client maximal zulässigen gleichzeitigen Verbindungen.	2
RETRY_TIME	Mindestwartezeit nach den ersten beiden fehlgeschlagenen Verbindungsversuchen. Bei jedem weiteren Versuch nach dem 3. Versuch SOLL die Wartezeit um diesen Wert bis RETRY_TIME_MAX oder mit größer werden Abständen vergrößert werden.	5 Sek
RETRY_TIME_MAX	Maximale Wartezeit zwischen zwei Verbindungsversuchen.	5 min

<=

A_27751 VZD Client - Nutzung zentraler TI-Systeme durch dezentrale Clients: Angepasste Konfiguration und Außerbetriebnahme von Clients

Jeder Client MUSS entsprechend des tatsächlichen Bedarfs, d.h. der zu erwartenden Anwendungsfälle und deren Häufigkeit so konfiguriert werden, dass nicht notwendige Last (Anfrage- und Verbindungslast auf Systemkomponenten durch parallele Verbindungen, häufige Requests oder ineffiziente Nutzung von Schnittstellen) auf den zentralen TI-Systemen vermieden wird.

Clients, die vorübergehend oder langfristig nicht mehr genutzt werden, SOLLEN in angemessen kurzer Zeit deaktiviert werden.

<=

A_28318 VZD Client - Deaktivierung nicht genutzter Clients

VZD Clients, die vorübergehend oder langfristig nicht mehr genutzt werden, SOLLEN in angemessen kurzer Zeit deaktiviert werden.

<=

A_27753 VZD Client - Nutzung zentraler TI-Systeme durch dezentrale Clients: Caching

Zur Lastvermeidung und Erhöhung der Ausfallsicherheit SOLLEN Client-Systeme Antworten von häufig durchgeführten Abfragen kurzzeitig (max. 5 Min.), wenn für den Anwendungsfall nicht explizit anders spezifiziert, aufbewahren (cachen).

<=

A_27755 VZD Client - Nutzung zentraler TI-Systeme durch dezentrale Clients: Fehler-Monitoring

VZD Clients SOLLEN zur frühzeitigen Erkennung von Instabilitäten im Client- oder Netzwerkbereich Metriken wie Antwortzeiten, Fehlerratenund Timeouts erfassen und bei Bedarf an ein zentrales Monitoring-System übermitteln.

<=

Es wird Kapitel "4.2 Schnittstelle I_Directory_Maintenance" gestrichen

4.2 Schnittstelle I_Directory_Maintenance

Die Schnittstelle ermöglicht die Administration der Basisdaten.

TIP1-A_5571 VZD, Schnittstelle I_Directory_Maintenance

Der VZD MUSS die Schnittstelle I_Directory_Maintenance gemäß Tabelle Tab_VZD_Schnittstelle_I_Directory_Maintenance anbieten.

Tabelle 1: Tab_VZD_Schnittstelle_I_Directory_Maintenance

Name	I_Directory_Maintenance
Version	wird im Produkttypsteckbrief des VZD definiert
Operationen	Name	Kurzbeschreibung
	add_Directory_Entry	Erzeugung eines Basisdaten-Verzeichniseintrages oder Überschreiben eines bestehenden Verzeichniseintrages.
	read_Directory_Entry	Abfrage aller Basis- und Fachdaten eines Verzeichniseintrages.
	modify_Directory_Entry	Änderung eines Basisdaten-Verzeichniseintrages.
	delete_Directory_Entry	Löschung eines Verzeichniseintrages (Basisdaten und Fachdaten).

<=

TIP1-A_5572 VZD, I_Directory_Maintenance, TLS-gesicherte Verbindung

Der VZD MUSS die Schnittstelle I_Directory_Maintenance durch Verwendung von TLS mit beidseitiger Authentisierung sichern.
Der VZD muss sich mit der Identität ID.ZD.TLS-S authentisieren.
Der VZD muss das vom FAD übergebene AUT-Zertifikat C.FD.TLS-C hinsichtlich OCSP-Gültigkeit und Übereinstimmung mit einem Zertifikat eines zur Nutzung dieser Schnittstelle registrierten Fachdienstes prüfen. Bei negativem Ergebnis wird der Verbindungsaufbau abgebrochen.

<=

TIP1-A_5574 - VZD und Nutzer der Schnittstelle I_Directory_Maintenance, WebService

Der VZD und Nutzer der Schnittstelle MÜSSEN die Schnittstelle I_Directory_Maintenance als SOAP-Webservice über HTTPS implementieren. Der Webservice wird durch die Dokumente DirectoryMaintenance.wsdl und DirectoryMaintenance.xsd definiert.

<=

4.2.1 Operation add_Directory_Entry

Diese Operation legt einen neuen Basisdatensatz an oder überschreibt einen bestehenden Datensatz im LDAP Verzeichnis.

4.2.1.1 Umsetzung

TIP1-A_5575 - VZD, Umsetzung add_Directory_Entry

Der VZD MUSS nach folgenden Vorgaben die Operation add_Directory_Entry implementieren:

1. Ein bereits zur Telematik-ID gehörender Basisdatensatz wird gelöscht und neu angelegt.
   
2. Existiert noch kein Basisdatensatz zur Telematik-ID wird ein neuer angelegt.
   
3. Die Daten aus dem SOAP Request bilden gemäß Tab_VZD_Daten-Transformation und Tab_VZD_Datenbeschreibung den neuen Basisdatensatz.
   

Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0002 verwendet werden.

<=

In der folgenden Tabelle sind die Regeln zur Transformation von I_Directory_Maintenance Request Elementen zu LDAP-Directory Attributen und die Regeln zur Transformation aus LDAP-Directory Attributen zu I_Directory_Maintenance Response Elementen beschrieben.

Tabelle 2: Tab_VZD_Daten-Transformation

I_Directory_Maintenance Request Element	LDAP-Directory Attribut	I_Directory_Maintenance Response Element	Zusatzinformation
n/a	givenname	givenname	Verwendung gemäß Tab_VZD_Datenbeschreibung
n/a	sn SMC-B: Wird vom VZD als Kopie von otherName eingetragen.	surname	Verwendung gemäß Tab_VZD_Datenbeschreibung
n/a	cn Wird vom VZD als Kopie von otherName eingetragen.	commonName	Verwendung gemäß Tab_VZD_Datenbeschreibung
n/a	displayName Wird vom VZD als Kopie von otherName eingetragen.	displayName
streetAddress	streetAddress	streetAddress	Alias street Der Alias-Wert wird in der LDAP Response verwendet.
postalCode	postalCode	postalCode
localityName	localityName	localityName	Alias l Der Alias-Wert wird in der LDAP Response verwendet.
stateOrProvinceName	stateOrProvinceName	stateOrProvinceName	Alias st Der Alias-Wert wird in der LDAP Response verwendet.
title	title	title	Verwendung gemäß Tab_VZD_Datenbeschreibung
organization	organization	organization	Alias o Der Alias-Wert wird in der LDAP Response verwendet. Verwendung gemäß Tab_VZD_Datenbeschreibung
otherName	otherName SMC-B: wird vom VZD zusätzlich in displayName, surname und cn eingetragen	otherName	Verwendung gemäß Tab_VZD_Datenbeschreibung
subject	specialization	subject	Verwendung gemäß Tab_VZD_Datenbeschreibung
n/a	domainID	n/a
n/a	personalEntry	n/a	Verwendung gemäß Tab_VZD_Datenbeschreibung
x509CertificateEnc	userCertificate	x509CertificateEnc	Verwendung gemäß Tab_VZD_Datenbeschreibung
n/a	entryType	n/a	Verwendung gemäß Tab_VZD_Datenbeschreibung
n/a	telematikID	telematikID	Verwendung gemäß Tab_VZD_Datenbeschreibung
n/a	professionOID	n/a	Verwendung gemäß Tab_VZD_Datenbeschreibung
n/a	description	n/a
timestamp	n/a	timestamp	Datum und Zeit des Requests bzw. der Response
variant	n/a HBA: Wenn variant == full, dann werden givenName und sn aus dem Zertifikat in die gleichnamigen LDAP Attribute übernommen.	n/a
givenname	n/a	n/a
surname	n/a	n/a
commonName	n/a	n/a
serviceData	n/a	n/a
n/a	n/a	status

4.2.1.2 Nutzung

TIP1-A_5576 - Nutzer der Schnittstelle, TUC_VZD_0002 „add_Directory_Entry”

Der Nutzer der Schnittstelle MUSS den technischen Use Case TUC_VZD_0002 „add_Directory_Entry” gemäß Tabelle Tab_TUC_VZD_0002 umsetzen.
Der SOAP-Requests MUSS gemäß Tab_VZD_Datenbeschreibung mit der Bedeutung entsprechenden Daten ausgefüllt sein.

Tabelle 3: Tab_TUC_VZD_0002

Name	TUC_VZD_0002 „add_Directory_Entry”
Beschreibung	Diese Operation ermöglicht die Erzeugung von neuen Basisdaten. Bestehende Basisdaten werden überschrieben.
Vorbedingungen	keine
Eingangsdaten	SOAP-Request „addDirectoryEntry“
Komponenten	Nutzer der Schnittstelle, Verzeichnisdienst
Ausgangsdaten	SOAP-Response „VZD:responseMsg“
Standardablauf	Aktion	Beschreibung
	Aufbau TLS-Verbindung	Wenn noch keine Verbindung besteht initiiert der Nutzer der Schnittstelle den Verbindungsaufbau. Der Nutzer der Schnittstelle authentisiert sich mit dem AUT-Zertifikat C.FD.TLS-C.
	SOAP-Request senden	Der Nutzer der Schnittstelle ruft die SOAP-Operation VZD:addDirectoryEntry auf.
	SOAP-Response empfangen	Die SOAP-Response VZD:responseMsg mit dem VZD:status wird empfangen.
Varianten/Alternativen	keine
Fehlerfälle	Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS). Fehler bei der Verarbeitung des SOAP Requests werden als gematik SOAP-Fault versendet: faultcode 4211,  faultstring: Operation fehlerhaft ausgeführt, Basisdaten konnten nicht angelegt werden (Fehler im Verzeichnisdienst) faultcode 4202,  faultstring: SOAP Request enthält Fehler faultcode 4201,  faultstring: Operation enthält ungültige Daten Erkannte Fehler auf Transportprotokollebene müssen auf gematik SOAP Faults (Code 6 aus Tabelle Tab_Gen_Fehler aus [gemSpec_OM]) abgebildet werden. Zusätzlich müssen die generischen gematik SOAP-Faults Code 2: Verbindung zurückgewiesen Code 3: Nachrichtenschema fehlerhaft Code 4: Version Nachrichtenschema fehlerhaft unterstützt werden.

<=

4.2.2 Operation read_Directory_Entry

Diese Operation liest einen vollständigen Eintrag aus dem LDAP Verzeichnis aus.

4.2.2.1 Umsetzung

TIP1-A_5577 - VZD, Umsetzung read_Directory_Entry

Der VZD MUSS nach folgenden Vorgaben die Operation I_Directory_Maintenance::read_Directory_Entry implementieren:

1. Der zur Telematik-ID gehörende Eintrag wird im LDAP Directory ermittelt.
   
2. Es wird eine SOAP Response VZD:readResponseMsg aus dem kompletten Eintrag (Basisdaten + Fachdaten) gemäßTab_VZD_Daten-Transformation und Tab_VZD_Datenbeschreibung erzeugt.
   

Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0003 verwendet werden.

4.2.2.2 Nutzung

TIP1-A_5578 - Nutzer der Schnittstelle, TUC_VZD_0003 „read_Directory_Entry”

Der Nutzer der Schnittstelle MUSS den technischen Use Case TUC_VZD_0003 „read_Directory_Entry” gemäß Tabelle Tab_TUC_VZD_0003 umsetzen. Der Webservice wird durch die Dokumente DirectoryMaintenance.wsdl und DirectoryMaintenance.xsd definiert.
Die SOAP-Response ist gemäß Tabelle Tab_VZD_Datenbeschreibung mit den zur Telematik-ID gehörenden Daten aus dem VZD ausgefüllt.

Tabelle 4: Tab_TUC_VZD_0003

Name	TUC_VZD_0003 „read_Directory_Entry”
Beschreibung	Diese Operation liest einen vollständigen Eintrag aus dem VZD aus.
Vorbedingungen	Keine
Eingangsdaten	SOAP-Request „readDirectoryEntry“
Komponenten	Nutzer der Schnittstelle, Verzeichnisdienst
Ausgangsdaten	SOAP-Response „readResponseMsg“
Standardablauf	Aktion	Beschreibung
	Aufbau TLS-Verbindung	Wenn noch keine Verbindung besteht initiiert der Nutzer der Schnittstelle den Verbindungsaufbau. Der Nutzer der Schnittstelle authentisiert sich mit dem AUT-Zertifikat C.FD.TLS-C.
	SOAP-Request senden	Der Nutzer der Schnittstelle ruft die SOAP-Operation VZD:readDirectoryEntry auf.
	SOAP-Response empfangen	Die SOAP-Response VZD:readResponseMsg mit allen Basisdaten wird empfangen.
Varianten/Alternativen	keine
Fehlerfälle	Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) Fehler bei der Verarbeitung des SOAP Requests werden als gematik SOAP-Fault versendet: faultcode 4221, faultstring: Operation fehlerhaft ausgeführt, Basisdaten konnten nicht gelesen werden (Fehler im Verzeichnisdienst) faultcode 4312,  faultstring: Basisdaten konnten nicht gefunden werden faultcode 4202,  faultstring: SOAP Request enthält Fehler Erkannte Fehler auf Transportprotokollebene müssen auf gematik SOAP Faults (Code 6 aus Tabelle Tab_Gen_Fehler aus [gemSpec_OM]) abgebildet werden. Zusätzlich müssen die generischen gematik SOAP-Faults Code 2: Verbindung zurückgewiesen Code 3: Nachrichtenschema fehlerhaft Code 4: Version Nachrichtenschema fehlerhaft unterstützt werden.

<=

4.2.3 Operation modify_Directory_Entry

Diese Operation ändert die Daten eines bestehenden Basisdatensatzes im LDAP Verzeichnis.

4.2.3.1 Umsetzung

TIP1-A_5579 - VZD, Umsetzung modify_Directory_Entry

Der VZD MUSS nach folgenden Vorgaben die Operation modify_Directory_Entry implementieren:

1. Der zur Telematik-ID gehörende Basisdatensatz wird im LDAP Directory ermittelt.
   
2. Die Daten im Basisdatensatz werden durch die Daten aus dem SOAP Request gemäß Tab_VZD_Daten-Transformation und Tab_VZD_Datenbeschreibung geändert.

Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0004 verwendet werden.

<=

4.2.3.2 Nutzung

TIP1-A_5580 - Nutzer der Schnittstelle, TUC_VZD_0004 „modify_Directory_Entry”

Der Nutzer der Schnittstelle MUSS den technischen Use Case TUC_VZD_0004 „modify_Directory_Entry” gemäß Tabelle Tab_TUC_VZD_0004 umsetzen. Der Webservice wird durch die Dokumente DirectoryMaintenance.wsdl und DirectoryMaintenance.xsd definiert.
Der SOAP-Requests MUSS gemäß Tabelle VZD_TAB_modifyDirectoryEntry_Mapping mit der Bedeutung entsprechenden Daten ausgefüllt sein.

Tabelle 5: Tab_TUC_VZD_0004

Name	TUC_VZD_0004 „modify_Directory_Entry”
Beschreibung	Diese Operation ermöglicht die Änderung von Basisdaten.
Vorbedingungen	keine
Eingangsdaten	SOAP-Request „modifyDirectoryEntry“
Komponenten	Nutzer der Schnittstelle, Verzeichnisdienst
Ausgangsdaten	SOAP-Response „responseMsg“
Standardablauf	Aktion	Beschreibung
	Aufbau TLS-Verbindung	Wenn noch keine Verbindung besteht initiiert der Nutzer der Schnittstelle den Verbindungsaufbau. Der Nutzer der Schnittstelle authentisiert sich mit dem AUT-Zertifikat C.FD.TLS-C.
	SOAP-Request senden	Der Nutzer der Schnittstelle ruft die SOAP-Operation VZD:modifyDirectoryEntry auf.
	SOAP-Response empfangen	Die SOAP-Response VZD:responseMsg mit dem VZD:status wird empfangen.
Varianten/Alternativen	keine
Fehlerfälle	Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) Fehler bei der Verarbeitung des SOAP Requests werden als gematik SOAP-Fault versendet: faultcode 4231,  faultstring: Operation fehlerhaft ausgeführt, Basisdaten konnten nicht modifiziert werden (Fehler im Verzeichnisdienst) faultcode 4312,  faultstring: Basisdaten konnten nicht gefunden werden faultcode 4202,  faultstring: SOAP Request enthält Fehler Erkannte Fehler auf Transportprotokollebene müssen auf gematik SOAP Faults (Code 6 aus Tabelle Tab_Gen_Fehler aus [gemSpec_OM]) abgebildet werden. Zusätzlich müssen die generischen gematik SOAP-Faults Code 2: Verbindung zurückgewiesen Code 3: Nachrichtenschema fehlerhaft Code 4: Version Nachrichtenschema fehlerhaft unterstützt werden.

<=

4.2.4 Operation delete_Directory_Entry

Diese Operation löscht einen bestehenden Datensatz im LDAP Verzeichnis.

4.2.4.1 Umsetzung

TIP1-A_5581 - VZD, Umsetzung delete_Directory_Entry

Der VZD MUSS nach folgenden Vorgaben die Operation I_Directory_Maintenance::delete_Directory_Entry implementieren:

1. Ein zur Telematik-ID gehörender vollständiger Eintrag gelöscht.
   

Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0005 verwendet werden.

<=

4.2.4.2 Nutzung

TIP1-A_5582 - Nutzer der Schnittstelle, TUC_VZD_0005 „delete_Directory_Entry”

Der Nutzer der Schnittstelle MUSS den technischen Use Case TUC_VZD_0005 „delete_Directory_Entry” gemäß Tabelle Tab_TUC_VZD_0005 umsetzen. Der Webservice wird durch die Dokumente DirectoryMaintenance.wsdl und DirectoryMaintenance.xsd definiert.

Tabelle 6: Tab_TUC_VZD_0005

Name	TUC_VZD_0005 „delete_Directory_Entry”
Beschreibung	Diese Operation ermöglicht die Löschung  von Basisdaten inkl. der zugehörigen Fachdaten.
Vorbedingungen	keine
Eingangsdaten	SOAP-Request „deleteDirectoryEntry“
Komponenten	Nutzer der Schnittstelle, Verzeichnisdienst
Ausgangsdaten	SOAP-Response „responseMsg“
Standardablauf	Aktion	Beschreibung
	Aufbau TLS-Verbindung	Wenn noch keine Verbindung besteht initiiert der Nutzer der Schnittstelle den Verbindungsaufbau. Der Nutzer der Schnittstelle authentisiert sich mit dem AUT-Zertifikat C.FD.TLS-C.
	SOAP-Request senden	Der Nutzer der Schnittstelle ruft die SOAP-Operation VZD:deleteDirectoryEntry auf.
	SOAP-Response empfangen	Die SOAP-Response VZD:responseMsg mit dem VZD:status wird empfangen.
Varianten/Alternativen	keine
Fehlerfälle	Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) Fehler bei der Verarbeitung des SOAP Requests werden als gematik SOAP-Fault versendet: faultcode 4241,  faultstring: Operation fehlerhaft ausgeführt, Basisdaten konnten nicht gelöscht werden (Fehler im Verzeichnisdienst) faultcode 4312,  faultstring: Basisdaten konnten nicht gefunden werden faultcode 4202,  faultstring: SOAP Request enthält Fehler Erkannte Fehler auf Transportprotokollebene müssen auf gematik SOAP Faults (Code 6 aus Tabelle Tab_Gen_Fehler aus [gemSpec_OM]) abgebildet werden. Zusätzlich müssen die generischen gematik SOAP-Faults Code 2: Verbindung zurückgewiesen Code 3: Nachrichtenschema fehlerhaft Code 4: Version Nachrichtenschema fehlerhaft unterstützt werden.

<=

Es wird Kapitel "4.3 Schnittstelle I_Directory_Application_Maintenance" wie folgt angepasst

4.3 Schnittstelle I_Directory_Application_Maintenance

Die Schnittstelle ermöglicht die Administration der Fachdaten.

Der VZD stellt diese Schnittstelle als REST Schnittstelle LDAPv3 und Webservice (SOAP und REST) bereit. Deshalb sind die Unterkapitel „Nutzung“ und „Umsetzung“ jeweils für LDAPv3 und Webservice (SOAP und REST) vorhanden.

...

TIP1-A_5587 - VZD, Implementierung der LDAPv3 Schnittstelle

Der VZD MUSS die Schnittstelle I_Directory_Application_Maintenance gemäß den LDAPv3 Standards [RFC4510], [RFC4511], [RFC4512], [RFC4513], [RFC4514], [RFC4515], [RFC4516], [RFC4517], [RFC4518], [RFC4519], [RFC4520], [RFC4522] und [RFC4523] implementieren.

<=

TIP1-A_5589 - FAD, Implementierung der LDAPv3 Schnittstelle

Der FAD, der die LDAPv3-Schnittstelle I_Directory_Application_Maintenance des VZD nutzt, MUSS diese Schnittstelle gemäß den LDAPv3 Standards [RFC4510], [RFC4511], [RFC4512], [RFC4513], [RFC4514], [RFC4515], [RFC4516], [RFC4517], [RFC4518], [RFC4519], [RFC4520], [RFC4522] und [RFC4523] implementieren. Die LDAPv3-Attribute sind in dem Informationsmodell Abb_VZD_logisches_Datenmodell beschrieben.

<=

A_23728-01 - VZD, I_Directory_Application_Maintenance, Aktualisierung zulässiger Anwendungskennzeichen

Der VZD MUSS täglich um 4:00 Uhr das FHIR CodeSystems mit den Anwendungskennzeichen aus Simplifier  (https://simplifier.net/app-transport-framework/app-tags-cs/$download?format=json ) aktualisieren und persistent speichern.

<=

Es werden Kapitel 4.3.2.1, 4.3.2.2, 4.3.2.3 und 4.3.2.4 gestrichen

4.3.2.1 Umsetzung SOAP

TIP1-A_5590 - VZD, Umsetzung add_Directory_FA-Attributes (SOAP)

Der VZD MUSS nach folgenden Vorgaben die Operation add_Directory_FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einem gematik SOAP-Fault beendet:
   faultcode: 4312,
   faultstring: Basisdaten konnten nicht gefunden werden.
   
2. Ein bereits zur Telematik-ID gehörender Fachdatensatz wird gelöscht und neu angelegt.
   
3. Ein noch nicht existierender Fachdatensatz zur Telematik-ID wird im LDAP Directory neu angelegt.
   
4. Die Daten aus dem SOAP Request werden gemäß VZD_TAB_I_Directory_Application_Maintenance_Add_Mapping zum Basisdatensatz hinzugefügt.
   

Tabelle 7: VZD_TAB_I_Directory_Application_Maintenance_Add_Mapping

SOAP-Request Element	LDAP-Directory Basisdatensatz Attribut
VZD:timestamp	wird nicht in das LDAP-Directory eingetragen
VZD:Telematik-ID
<FA-Attributes>	fachdienstspezifische Attribute. Die SOAP-Request-Elemente werden namensgleich als LDAP-Attribute übernommen.

Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0006 verwendet werden.

<=

4.3.2.2 Nutzung SOAP

TIP1-A_5591 - FAD, TUC_VZD_0006 “add_Directory_FA-Attributes (SOAP)”

Der FAD MUSS den technischen Use Case TUC_VZD_0006 “add_Directory_FA-Attributes” gemäß Tabelle Tab_TUC_VZD_0006 umsetzen.
Tabelle 8: Tab_TUC_VZD_0006

Name	add_Directory_FA-Attributes
Beschreibung	Mit dieser Operation werden Fachdaten zu einem bestehenden Basisdaten-Eintrag zugefügt.
Vorbedingungen	Keine.
Eingangsdaten	SOAP-Request „addDirectoryFAAttributes“
Komponenten	VZD, FAD
Ausgangsdaten	SOAP-Response „responseMsg“
Standardablauf	Aktion	Beschreibung
	Aufbau TLS-Verbindung	Falls noch keine TLS-Verbindung besteht, wird eine aufgebaut. Der FAD authentisiert sich mit ID.FD.TLS-C.
	SOAP-Request senden	Der FAD ruft die SOAP-Operation VZD:addDirectoryFAAttributes auf.
	SOAP-Response empfangen	Die SOAP-Response VZD:responseMsg enthält den vzd:status. Im Fehlerfall wird eine gematik SOAP-Fault Response empfangen
Fehlerfälle	Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS). Fehler bei der Verarbeitung des SOAP Requests werden als gematik SOAP-Fault versendet: faultcode 4311,  faultstring: Operation fehlerhaft ausgeführt, Fachdaten konnten nicht angelegt werden (Fehler im Verzeichnisdienst) faultcode 4312,  faultstring: Basisdaten konnten nicht gefunden werden faultcode 4202,  faultstring: SOAP Request enthält Fehler

<=

TIP1-A_5592-03 - FAD, KOM-LE_FA_Add_Attributes

Der FAD MUSS für die FA KOM-LE die Fachdaten nach VZD_TAB_KOM-LE_Add_Attributes administrieren.

Tabelle 9: VZD_TAB_KOM-LE_Attributes

SOAP-Request Element	LDAP-Directory Basisdatensatz Attribut
VZD:timestamp	wird nicht in das LDAP-Directory eingetragen
VZD:telematikID
VZD:KOM-LE-EMail-Address	mail
VZD:version	KOM-LE-Version

<=

4.3.2.3 Umsetzung LDAPv3

TIP1-A_5593 - VZD, Umsetzung add_Directory_FA-Attributes (LDAPv3)

Der VZD MUSS nach folgenden Vorgaben die Operation add_Directory_FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einer Fehlermeldung beendet.
   
2. Ein noch nicht existierender Fachdatensatz zur Telematik-ID wird im VZD neu angelegt.
   
3. Der FAD darf nur die zu seinem Dienst gehörenden Fachdaten schreiben.
   

Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0007 verwendet werden.

<=

4.3.2.4 Nutzung LDAPv3

TIP1-A_5594 - FAD, TUC_VZD_0007 “add_Directory_FA-Attributes (LDAPv3)”

Der FAD MUSS den technischen Use Case TUC_VZD_0007 „add_Directory_FA-Attributes(LDAPv3)” gemäß Tabelle Tab_TUC_VZD_0007 unterstützen.

Tabelle 10: Tab_TUC_VZD_0007

Name	add_Directory_FA-Attributes(LDAPv3)
Beschreibung	Mit dieser Operation werden Fachdaten zu einem bestehenden Eintrag zugefügt.
Vorbedingungen	Der LDAPS-Verbindungsaufbau muss erfolgreich durchgeführt sein.
Eingangsdaten	Add-Request gemäß [RFC4511]#4.7 und Informationsmodell (Abb_VZD_logisches_Datenmodell)
Komponenten	LDAP Client des FAD, Verzeichnisdienst
Ausgangsdaten	gemäß [RFC4511]#4.7
Standardablauf	Aktion	Beschreibung
	Add Request senden	Der LDAP Client des FAD sendet den Add-Request gemäß [RFC4511]#4.7 an den VZD. Die RFCs [RFC4510], [RFC4511], [RFC4513], [RFC4514], [RFC4515], [RFC4516], [RFC4519] und [RFC4522] müssen unterstützt werden.
	Add Response empfangen	Der LDAP Client empfängt das Ergebnis der Operation gemäß [RFC4511]#4.7.
Varianten/Alternativen	keine
Zustand nach erfolgreichem Ablauf	Das Ergebnis der Operation liegt im LDAP Client des FAD vor.
Fehlerfälle	Zur Behandlung auftretender Fehlerfälle werden Fehlermeldungen gemäß [RFC4511]#Appendix A verwendet.

<=

A_21834 - VZD, I_Directory_Application_Maintenance, KOM-LE_Version Prüfung LDAP

Der VZD MUSS bei Änderungen an KOM-LE-Fachdaten mit den Operationen “add_Directory_FA-Attributes (LDAPv3)” und "modify_Directory_FA-Attributes (LDAPv3)" den Inhalt von Parameter KOM-LE_Version des Operation Requests gegen die Liste der gültigen Werte prüfen. Im Falle von ungültigen Werten MUSS der VZD mit LDAP Result Code constraintViolation (19) antworten und darf die Operation nicht ausführen. Der VZD MUSS die Liste der gültigen Werte von Attribut KOM-LE_Version konfigurierbar realisieren und der gematik Änderungensmöglichkeiten über einen Service Request bieten.

<=

A_21835 - VZD, I_Directory_Application_Maintenance, Eindeutige Zuordnung von KOM-LE Adressen zu VZD-Einträgen LDAP

Der VZD MUSS sicherstellen, dass jede KOM-LE-Adresse mit den Operationen “add_Directory_FA-Attributes (LDAPv3)” und "modify_Directory_FA-Attributes (LDAPv3)" nur an maximal einen VZD-Eintrag angehängt wird. Hierzu MUSS er vor einer Eintragung einer KOM-LE Adresse prüfen, ob diese bereits im VZD hinterlegt ist. Ist sie bereits hinterlegt, MUSS der VZD mit LDAP Result Code attributeOrValueExists (20) antworten und darf die Operation nicht ausführen.

<=

A_23729 - VZD, I_Directory_Application_Maintenance, Anwendungskennzeichen Prüfung LDAP

Der VZD MUSS bei Änderungen an KOM-LE-Fachdaten mit den Operationen “add_Directory_FA-Attributes (LDAPv3)” und "modify_Directory_FA-Attributes (LDAPv3)" den Inhalt von Parameter Anwendungskennzeichen (appTags) des Operation Requests gegen die Liste der gültigen Werte prüfen. Im Falle von ungültigen Werten MUSS der VZD mit LDAP Result Code constraintViolation (19) antworten und darf die Operation nicht ausführen.

<=

Es werden Kapitel 4.3.3.1, 4.3.3.2, 4.3.3.3 und 4.3.3.4 gestrichen

4.3.3.1 Umsetzung SOAP

TIP1-A_5595 - VZD, Umsetzung delete_Directory_FA-Attributes

Der VZD MUSS nach folgenden Vorgaben die Operation delete_Directory_ FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einem gematik SOAP-Fault beendet:
   faultcode: 4312,
   faultstring: Basisdaten konnten nicht gefunden werden.
   
2. Ein zur Telematik-ID gehörender Fachdatensatz wird gelöscht.
   
3. Ein nicht existierender Fachdatensatz zur Telematik-ID führt zu keiner Aktion.
   

Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0008 verwendet werden.

<=

4.3.3.2 Nutzung SOAP

TIP1-A_5596 - FAD, TUC_VZD_0008 “delete_Directory_FA-Attributes (SOAP)”

Der FAD MUSS den technischen Use Case TUC_VZD_0008 “delete_Directory_FA-Attributes” gemäß Tabelle Tab_TUC_VZD_0008 umsetzen.
Tabelle #: Tab_TUC_VZD_0008

Name	delete_Directory_FA-Attributes
Beschreibung	Mit dieser Operation wird ein Fachdaten-Eintrag gelöscht.
Vorbedingungen	Keine.
Eingangsdaten	SOAP-Request „deleteDirectoryFAAttributes“
Komponenten	VZD, FAD
Ausgangsdaten	SOAP-Response „responseMsg“
Standardablauf	Aktion	Beschreibung
	Aufbau TLS-Verbindung	Falls noch keine TLS-Verbindung besteht, wird eine aufgebaut. Der FAD authentisiert sich mit ID.FD.TLS-C.
	SOAP-Request senden	Der FAD ruft die SOAP-Operation VZD:deleteDirectoryFAAttributes auf.
	SOAP-Response empfangen	Die SOAP-Response VZD:responseMsg enthält den vzd:status. Im Fehlerfall wird eine gematik SOAP-Fault Response empfangen
Fehlerfälle	Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS). Fehler bei der Verarbeitung des SOAP Requests werden als gematik SOAP-Fault versendet: faultcode 4321,  faultstring: Operation fehlerhaft ausgeführt, Fachdaten konnten nicht gelöscht werden (Fehler im Verzeichnisdienst) faultcode 4312,  faultstring: Basisdaten konnten nicht gefunden werden faultcode 4202,  faultstring: SOAP Request enthält Fehler

<=

4.3.3.3 Umsetzung LDAPv3

TIP1-A_5597 - VZD, Umsetzung delete_Directory_FA-Attributes (LDAPv3)

Der VZD MUSS nach folgenden Vorgaben die Operation delete_Directory_FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request beendet.
   
2. Ein zur Telematik-ID gehörender Fachdatensatz wird gelöscht.
   
3. Ein nicht existierender Fachdatensatz zur Telematik-ID führt zu keiner Aktion.
   
4. Der FAD darf nur die zu seinem Dienst gehörenden Fachdaten löschen.
   

Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0009 verwendet werden.

<=

4.3.3.4 Nutzung LDAPv3

TIP1-A_5598 - FAD, TUC_VZD_0009 “delete_Directory_FA-Attributes (LDAPv3)”

Der FAD MUSS den technischen Use Case TUC_VZD_0009 „delete_Directory_FA-Attributes(LDAPv3)” gemäß Tabelle Tab_TUC_VZD_0009 unterstützen.

Tabelle 12: Tab_TUC_VZD_0009

Name	delete_Directory_FA-Attributes(LDAPv3)
Beschreibung	Mit dieser Operation werden alle Fachdaten zu einem bestehenden Eintrag gelöscht.
Vorbedingungen	Der LDAPS-Verbindungsaufbau muss erfolgreich durchgeführt sein.
Eingangsdaten	Delete-Request gemäß [RFC4511]#4.8 und Informationsmodell (Abb_VZD_logisches_Datenmodell)
Komponenten	LDAP Client des FAD, Verzeichnisdienst
Ausgangsdaten	gemäß [RFC4511]#4.8
Standardablauf	Aktion	Beschreibung
	Delete Request senden	Der LDAP Client des FAD sendet den delete-Request gemäß [RFC4511]#4.8 an den VZD. Die RFCs [RFC4510], [RFC4511], [RFC4513], [RFC4514], [RFC4515], [RFC4516], [RFC4519] und [RFC4522] müssen unterstützt werden.
	Delete Response empfangen	Der LDAP Client empfängt das Ergebnis der Operation gemäß [RFC4511]#4.8.
Varianten/Alternativen	keine
Zustand nach erfolgreichem Ablauf	Das Ergebnis der Operation liegt im LDAP Client des FAD vor.
Fehlerfälle	Zur Behandlung auftretender Fehlerfälle werden Fehlermeldungen gemäß [RFC4511]#Appendix A verwendet.

<=

Es wird Kapitel "4.3.3.5 Umsetzung REST" wie folgt angepasst

4.3.3.5 Umsetzung REST

Es werden Kapitel 4.3.4.1, 4.3.4.2, 4.3.4.3 und 4.3.4.4 gestrichen

4.3.4.1 Umsetzung SOAP

TIP1-A_5599-01 - VZD, Umsetzung modify_Directory_FA-Attributes

Der VZD MUSS nach folgenden Vorgaben die Operation modify_Directory_ FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einem gematik SOAP-Fault beendet:
   faultcode: 4312,
   faultstring: Basisdaten konnten nicht gefunden werden.
   
2. Ein bereits zur Telematik-ID gehörender Fachdatensatz wird überschrieben.
   
3. Die Daten aus dem SOAP Request werden gemäß VZD_TAB_I_Directory_Application_Maintenance_Modify_Mapping zum Basisdatensatz hinzugefügt.
4. Für die Koexistenz dieser Operation mit den Erweiterungen für das Anwendungskennzeichen MÜSSEN folgende Vorgaben umgesetzt werden:
1. Beim Aufruf von modify_Directory_ FA-Attributes wird das Attribut "Mail" übergeben. KimData MUSS basierend auf der übergebenen Mail-Adresse gefüllt werden, wobei die Subattribute "Version" und "AppTags" (falls vorhanden) erhalten bleiben.
2. Wenn das KimData-Attribut für eine Mail-Adresse vor dem Aufruf von modify_Directory_ FA-Attributes gepflegt ist, das KomLeData-Attribut jedoch leer ist, DÜRFEN keine Änderungen an den Attributen KomLeData und KimData für diese Mail-Adresse vorgenommen werden.
3. Bestehende KimData-Einträge DÜRFEN durch modifyDirectoryFAAttributes NICHT entfernt werden.

Tabelle 13: VZD_TAB_I_Directory_Application_Maintenance_Modify_Mapping

SOAP-Request Element	LDAP-Directory Basisdatensatz Attribut
VZD:timestamp	wird nicht in das LDAP-Directory eingetragen
VZD:Telematik-ID
<FA-Attributes>	fachdienstspezifische Attribute. Die SOAP-Request-Elemente werden namensgleich als LDAP-Attribute übernommen.

Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0010 verwendet werden.

<=

4.3.4.2 Nutzung SOAP

TIP1-A_5600 - FAD, TUC_VZD_0010 “modify_Directory_FA-Attributes (SOAP)”

Der FAD MUSS den technischen Use Case TUC_VZD_0010 “modify_Directory_FA-Attributes” gemäß Tabelle Tab_TUC_VZD_0010 umsetzen.

Tabelle 14: Tab_TUC_VZD_0010

Name	modify_Directory_FA-Attributes
Beschreibung	Mit dieser Operation werden Fachdaten geändert.
Vorbedingungen	Keine.
Eingangsdaten	SOAP-Request „modifyDirectoryFAAttributes“
Komponenten	VZD, FAD
Ausgangsdaten	SOAP-Response „responseMsg“
Standardablauf	Aktion	Beschreibung
	Aufbau TLS-Verbindung	Falls noch keine TLS-Verbindung besteht, wird eine aufgebaut. Der FAD authentisiert sich mit ID.FD.TLS-C.
	SOAP-Request senden	Der FAD ruft die  SOAP-Operation VZD:modifyDirectoryFAAttributes auf.
	SOAP-Response empfangen	Die SOAP-Response VZD:responseMsg enthält den vzd:status. Im Fehlerfall wird eine gematik SOAP-Fault Response empfangen
Fehlerfälle	Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS). Fehler bei der Verarbeitung des SOAP Requests werden als gematik SOAP-Fault versendet: faultcode 4331,  faultstring: Operation fehlerhaft ausgeführt, Fachdaten konnten nicht geändert werden (Fehler im Verzeichnisdienst) faultcode 4312,  faultstring: Basisdaten konnten nicht gefunden werden faultcode 4202,  faultstring: SOAP Request enthält Fehler

<=

TIP1-A_5601-03 - FAD, KOM-LE_FA_Modify_Attributes

Der FAD MUSS für die FA KOM-LE die Fachdaten nach VZD_TAB_KOM-LE_Modify_Attributes administrieren.

Tabelle 15: VZD_TAB_KOM-LE_Attributes

SOAP-Request Element	LDAP-Directory Basisdatensatz Attribut
VZD:timestamp	wird nicht in das LDAP-Directory eingetragen
VZD:telematikID
VZD:KOM-LE-EMail-Address	mail
VZD:version	KOM-LE-Version

<=

4.3.4.3 Umsetzung LDAPv3

TIP1-A_5602 - VZD, Umsetzung modify_Directory_FA-Attributes (LDAPv3)

Der VZD MUSS nach folgenden Vorgaben die Operation modify_Directory_FA-Attributes implementieren:

1. Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request beendet.
   
2. Ein bereits zur Telematik-ID gehörender Fachdatensatz wird geändert.
   
3. Der FAD darf nur die zu seinem Dienst gehörenden Fachdaten ändern.
   

Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0011 verwendet werden.

<=

4.3.4.4 Nutzung LDAPv3

TIP1-A_5603 - FAD, TUC_VZD_0011 “modify_Directory_FA-Attributes (LDAPv3)”

Der FAD MUSS den technischen Use Case TUC_VZD_0011 „modify_Directory_FA-Attributes(LDAPv3)” gemäß Tabelle Tab_TUC_VZD_0011 unterstützen.

Tabelle 16: Tab_TUC_VZD_0011

Name	modify_Directory_FA-Attributes(LDAPv3)
Beschreibung	Mit dieser Operation werden Fachdaten zu einem bestehenden Eintrag geändert.
Vorbedingungen	Der LDAPS-Verbindungsaufbau muss erfolgreich durchgeführt sein.
Eingangsdaten	Modify-Request gemäß [RFC4511]#4.6 und Informationsmodell (Abb_VZD_logisches_Datenmodell)
Komponenten	LDAP Client des FAD, Verzeichnisdienst
Ausgangsdaten	gemäß [RFC4511]#4.6
Standardablauf	Aktion	Beschreibung
	Modify Request senden	Der LDAP Client des FAD sendet den modify-Request gemäß [RFC4511]#4.6 an den VZD. Die RFCs [RFC4510], [RFC4511], [RFC4513], [RFC4514], [RFC4515], [RFC4516], [RFC4519] und [RFC4522] müssen unterstützt werden.
	Modify Response empfangen	Der LDAP Client empfängt das Ergebnis der Operation gemäß [RFC4511]#4.6.
Varianten/Alternativen	keine
Zustand nach erfolgreichem Ablauf	Das Ergebnis der Operation liegt im LDAP Client des FAD vor.
Fehlerfälle	Zur Behandlung auftretender Fehlerfälle werden Fehlermeldungen gemäß [RFC4511]#Appendix A verwendet.

<=

Es wird Kapitel "4.3.7 Operation search_Directory_FA-Attributes" wie folgt angepasst

Die Anwendungsdaten können mit der im Folgenden beschriebenen Operation eingesehen werden.

4.3.7.1 Umsetzung REST

4.3.7.2 Nutzung REST

Es wird Kapitel "4.3.8 Operation readLog" wie folgt angepasst

Die Logdaten können mit der im Folgenden beschriebenen Operation eingesehen werden.

4.3.7.1 Umsetzung REST

4.3.7.2 Nutzung REST

Es wird Kapitel "4.6.1 Operationen der Schnittstelle I_ Directory_Administration" wie folgt angepasst

4.6.1 Operationen der Schnittstelle I_ Directory_Administration

...

...

Es wird Kapitel "4.6.1.4 DirectoryEntry Synchronization" wie folgt angepasst

4.6.1.4 DirectoryEntry Synchronization

...

...

Es wird Kapitel "5 Datenmodell" wie folgt angepasst

...

Tabelle 46: Tab_VZD_Mapping_Eintragstyp_und_ProfessionOID 

Eintragstyp	Eintragstyp Bedeutung	ProfessionOID (ProfessionItem)
1	Berufsgruppe	1.2.276.0.76.4.30 (Ärztin/Arzt) 1.3.6.1.4.1.24796.4.11.1 (Ärztin/Arzt)* 1.2.276.0.76.4.31 (Zahnärztin/Zahnarzt) 1.2.276.0.76.4.32 (Apotheker/-in) 1.2.276.0.76.4.33 (Apothekerassistent/-in) 1.2.276.0.76.4.34 (Pharmazieingenieur/-in) 1.2.276.0.76.4.35 (pharmazeutisch-technische/-r Assistent/-in) 1.2.276.0.76.4.36 (pharmazeutisch-kaufmännische/-r Angestellte) 1.2.276.0.76.4.37 (Apothekenhelfer/-in) 1.2.276.0.76.4.38 (Apothekenassistent/-in) 1.2.276.0.76.4.39 (Pharmazeutische/-r Assistent/-in) 1.2.276.0.76.4.40 (Apothekenfacharbeiter/-in) 1.2.276.0.76.4.41 (Pharmaziepraktikant/-in) 1.2.276.0.76.4.42 (Stud.pharm. oder Famulant/-in) 1.2.276.0.76.4.43 (PTA-Praktikant/-in) 1.2.276.0.76.4.44 (PKA Auszubildende/-r) 1.2.276.0.76.4.45 (Psychotherapeut/-in) 1.2.276.0.76.4.46 (Psychologische/-r Psychotherapeut/-in) 1.2.276.0.76.4.47 (Kinder- und Jugendlichenpsychotherapeut/-in) 1.2.276.0.76.4.48 (Rettungsassistent/-in) 1.2.276.0.76.4.178 (Notfallsanitäter/-in)  1.2.276.0.76.4.232 (Gesundheits- und Krankenpfleger/-in, Gesundheits- und Kinderkrankenpfleger/-in) 1.2.276.0.76.4.233 (Altenpfleger/-in) 1.2.276.0.76.4.234 (Pflegefachfrauen und Pflegefachmänner) 1.2.276.0.76.4.235 (Hebamme) 1.2.276.0.76.4.236 (Physiotherapeut/-in) 1.2.276.0.76.4.237 (Augenoptiker/-in und Optometrist/-in) 1.2.276.0.76.4.238 (Hörakustiker/-in) 1.2.276.0.76.4.239 (Orthopädieschuhmacher/-in) 1.2.276.0.76.4.240 (Orthopädietechniker/-in) 1.2.276.0.76.4.241 (Zahntechniker/-in) 1.2.276.0.76.4.274 (Ergotherapeut/-in) 1.2.276.0.76.4.275 (Logopäde/Logopädin) 1.2.276.0.76.4.276 (Podologe/Podologin) 1.2.276.0.76.4.277 (Ernährungstherapeut/-in Leistungserbringer/-in Ernährungstherapie) 1.2.276.0.76.4.305 (Orthopädieschuhmacher/-in und Orthopädietechniker/-in) 1.2.276.0.76.4.308 (Augenoptiker/-in, Optometrist/-in und Hörakustiker/-in) 1.2.276.0.76.4.312 Hilfsmittelerbringer/-in (Hinweis: Berufsgruppen der Hilfsmittelerbringer/-innen, die nicht den Gesundheitshandwerken zugeordnet sind) 1.2.276.0.76.4.313 Frisör/-in 1.2.276.0.76.4.315 Masseur/-in und medizinische/-r Bademeister/-in 1.2.276.0.76.4.316 Leistungserbringer/-in Soziotherapie 1.2.276.0.76.4.318 Leistungserbringer/in Stimm-, Sprech-, Sprach- und Schluck-Therapie 1.2.276.0.76.4.319 Diätassistent/-in
2	Versicherte/-r	1.2.276.0.76.4.49 (Versicherte/-r)
3	Leistungserbringer- institution	1.2.276.0.76.4.50 (Betriebsstätte Arzt) 1.2.276.0.76.4.51 (Zahnarztpraxis) 1.2.276.0.76.4.52 (Betriebsstätte Psychotherapeut) 1.2.276.0.76.4.53 (Krankenhaus) 1.2.276.0.76.4.54 (Öffentliche Apotheke) 1.2.276.0.76.4.55 (Krankenhausapotheke) 1.2.276.0.76.4.56 (Bundeswehrapotheke) 1.2.276.0.76.4.57 (Betriebsstätte Mobile Einrichtung Rettungsdienst) 1.2.276.0.76.4.245 (Betriebsstätte Gesundheits-, Kranken- und Altenpflege)  1.2.276.0.76.4.246 (Betriebsstätte Geburtshilfe) 1.2.276.0.76.4.247 (Betriebsstätte Physiotherapie) 1.2.276.0.76.4.248 (Betriebsstätte Augenoptiker) 1.2.276.0.76.4.249 (Betriebsstätte Hörakustiker) 1.2.276.0.76.4.250 (Betriebsstätte Orthopädieschuhmacher) 1.2.276.0.76.4.251 (Betriebsstätte Orthopädietechniker) 1.2.276.0.76.4.252 (Betriebsstätte Zahntechniker) 1.2.276.0.76.4.253 (Rettungsleitstelle) 1.2.276.0.76.4.254 (Betriebsstätte Sanitätsdienst Bundeswehr) 1.2.276.0.76.4.255 (Betriebsstätte Öffentlicher Gesundheitsdienst) 1.2.276.0.76.4.256 (Betriebsstätte Arbeitsmedizin) 1.2.276.0.76.4.257 (Betriebsstätte Vorsorge- und Rehabilitation) 1.2.276.0.76.4.278 (Ergotherapiepraxis) 1.2.276.0.76.4.279 (Logopaedische Praxis) 1.2.276.0.76.4.280 (Podologiepraxis) 1.2.276.0.76.4.281 (Ernährungstherapeutische Praxis) 1.2.276.0.76.4.304 (Betriebsstätte Augenoptiker und Hörakustiker) 1.2.276.0.76.4.306 (Betriebsstätte Orthopädieschuhmacher und Orthopädietechniker) 1.2.276.0.76.4.311 Betriebsstätte Hilfsmittelerbringer (Hinweis: Betriebsstätten der Hilfsmittelerbringer, welche nicht den Gesundheitshandwerken zugeordnet sind) 1.2.276.0.76.4.314 Betriebsstätte Frisör 1.2.276.0.76.4.317 Betriebsstätte Soziotherapie
4	Organisation	1.2.276.0.76.4.187 (Betriebsstätte Leistungserbringerorganisation Vertragszahnärzte) 1.2.276.0.76.4.58 (Betriebsstätte gematik)   1.2.276.0.76.4.190 (AdV-Umgebung bei Kostenträger) 1.2.276.0.76.4.210 (Betriebsstätte Leistungserbringerorganisation Kassenärztliche Vereinigung) 1.2.276.0.76.4.223 (Betriebsstätte GKV-Spitzenverband) 1.2.276.0.76.4.226 (Betriebsstätte Mitgliedsverband der Krankenhäuser) 1.2.276.0.76.4.227 (Betriebsstätte der Deutsche Krankenhaus TrustCenter und Informationsverarbeitung GmbH) 1.2.276.0.76.4.228 (Betriebsstätte der Deutschen Krankenhausgesellschaft) 1.2.276.0.76.4.224 (Betriebsstätte Apothekerverband) 1.2.276.0.76.4.225 (Betriebsstätte Deutscher Apothekerverband) 1.2.276.0.76.4.229 (Betriebsstätte der Bundesärztekammer) 1.2.276.0.76.4.230 (Betriebsstätte einer Ärztekammer) 1.2.276.0.76.4.231 (Betriebsstätte einer Zahnärztekammer) 1.2.276.0.76.4.242 (Betriebsstätte der Kassenärztlichen Bundesvereinigung) 1.2.276.0.76.4.243 (Betriebsstätte der Bundeszahnärztekammer) 1.2.276.0.76.4.244 (Betriebsstätte der Kassenzahnärztlichen Bundesvereinigung) 1.2.276.0.76.4.262 (Betriebsstätte Pflegeberatung nach § 7a SGB XI) 1.2.276.0.76.4.263 (Betriebsstätte Psychotherapeutenkammer) 1.2.276.0.76.4.264 (Betriebsstätte Bundespsychotherapeutenkammer) 1.2.276.0.76.4.265 (Betriebsstätte Landesapothekerkammer) 1.2.276.0.76.4.266 (Betriebsstätte Bundesapothekerkammer) 1.2.276.0.76.4.267 (Betriebsstätte elektronisches Gesundheitsberuferegister) 1.2.276.0.76.4.268 (Betriebsstätte Handwerkskammer) 1.2.276.0.76.4.269 (Betriebsstätte Register für Gesundheitsdaten) 1.2.276.0.76.4.270 (Betriebsstätte Abrechnungsdienstleister) 1.2.276.0.76.4.271 (Betriebsstätte PKV-Verband) 1.2.276.0.76.4.284 (Betriebsstätte Weitere Kostenträger im Gesundheitswesen)  1.2.276.0.76.4.285 (Weitere Organisationen der Gesundheitsversorgung)  1.2.276.0.76.4.292 (NCPeH Fachdienst)
5	Krankenkasse	1.2.276.0.76.4.59 (Betriebsstätte Kostenträger)
6	Krankenkasse ePA	1.2.276.0.76.4.273 (ePA KTR-Zugriffsautorisierung)
7	KIM	1.2.276.0.76.4.286 (KIM-Hersteller und -Anbieter)
8	TIM	1.2.276.0.76.4.295 (TIM-Hersteller und -Anbieter)
9	DiGA	1.2.276.0.76.4.282 (DIGA-Hersteller und Anbieter)
10	Ombudsstelle	1.2.276.0.76.4.303 (Ombudsstelle eines Kostenträgers)

...

2 Änderung in gemSpec_VZD_FHIR_Directory

Es wird Kapitel "4.2.1.2" wie folgt angepasst

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

...

Das search-access_token enthält folgende Attribute:

{   "iss": "https://fhir-directory-test.vzd.ti-dienste.de/tim-authenticate",   "sub": "@usr02:matrix.dev.service-ti.de",   "aud": [     "https://fhir-directory.vzd.ti-dienste.de/search",     "https://fhir-directory.vzd.ti-dienste.de/certificates"   ],   "exp": 1759841621,   "scope": "search:read certificate:read",   "iat": 1759755221 }

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

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

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

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

...

Es wird Kapitel "4.2.1.3" wie folgt angepasst

4.2.1.3 FHIR-Schnittstelle für Besitzer FHIRDirectoryOwnerAPI

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

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

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

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

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

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

Authentisierung

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

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

Das Accesstoken enthält folgende Attribute:

{   "iss": "https://fhir-directory.vzd.ti-dienste.de/owner-authenticate",   "sub": "<telematikID>",   "aud": [     "https://fhir-directory-ref.vzd.ti-dienste.de/owner",     "https://fhir-directory-ref.vzd.ti-dienste.de/search",     "https://fhir-directory-ref.vzd.ti-dienste.de/PersonInstitutionLink",     "https://fhir-directory-ref.vzd.ti-dienste.de/certificates",     "https://fhir-directory-ref.vzd.ti-dienste.de/fachliches-log"   ],   "iat": 1630306800,   "exp": 1630393200   "scope": "owner:read owner:write search:read link:suggest link:approve             link:deny link:read certificate:read log:read" }

...

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

{   "scope": "search:read owner:read owner:write link:read link:deny certificate:read             log:read",   "iss": "https://fhir-directory.vzd.ti-dienste.de/holder-authenticate",   "aud": [     "https://fhir-directory.vzd.ti-dienste.de/holder-services",     "https://fhir-directory.vzd.ti-dienste.de/owner",     "https://fhir-directory.vzd.ti-dienste.de/search",     "https://fhir-directory.vzd.ti-dienste.de/PersonInstitutionLink",     "https://fhir-directory.vzd.ti-dienste.de/certificates",     "https://fhir-directory.vzd.ti-dienste.de/fachliches-log"   ],   "iat": 1759753474,   "exp": 1759839874,   "sub": null,   "clientId": "<Die ClientID des authentifizierten Holders>",   "holderId": "<Die HolderID>" }

...

Endpunkte für die Authentisierung

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

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

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

FHIR VZD Endpunkte für die Authentisierung mit dem SmartcardIDP

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

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

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

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

In der Produktionsumgebung (PU) sind die URLs:

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

In der Referenzumgebung (RU) sind die URLs: 

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

In der Testumgebung (TU) sind die URLs:

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

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

• In der Produktionsumgebung (PU) ist die URL:

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

• In der Referenzumgebung (RU) ist die URL:

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

• In der Testumgebung (TU) ist die URL: 

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

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

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

Operationen

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

Daten

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

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

Tabelle 22: Tab_VZD_TI-Anwendungen_Endpoint

TI- Anwendung	Endpoint. connectionType code	Endpoint. payloadType code	Endpoint.address
TI Messenger	tim	tim-chat	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

Es wird Kapitel "4.2.1.4" wie folgt angepasst

4.2.1.4 Schnittstelle FHIRDirectoryTIMProviderAPI (I_VZD_TIM_Provider_Services.yaml)

...

Das provider-accesstoken enthält folgende Attribute:

{   "iss": "https://fhir-directory.vzd.ti-dienste.de/ti-provider-authenticate",   "sub": "<client_id>",   "aud": [     "https://fhir-directory-ref.vzd.ti-dienste.de/tim-provider-services",     "https://fhir-directory-ref.vzd.ti-dienste.de/certificates"   ],   "scope": "federation:read federation:write",   "iat": 1630306800,   "exp": 1630308600,   "clientId": "<client_id>" }

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

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

Das Attribut "scope" enthält die Berechtigungen.

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

...

Es wird Kapitel "4.2.1.5" wie folgt angepasst

4.2.1.5 FHIR Schnittstelle für Versicherte FHIRDirectoryFdvSearchAPI

...

Das search-access_token (Fachdienste) enthält folgende Attribute:

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

{   "sub": "<ClientID>",   "scope": "certificate:read fdv_search:read search:read",   "iss": "https://fhir-directory.vzd.ti-dienste.de/service-authenticate",   "aud": [     "https://fhir-directory.vzd.ti-dienste.de/fdv/search",     "https://fhir-directory.vzd.ti-dienste.de/search",     "https://fhir-directory.vzd.ti-dienste.de/certificates"   ],   "iat": 1759827516,   "exp": 1759913916 }

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

{   "iss": "https://fhir-directory-test.vzd.ti-dienste.de/tim-authenticate",   "sub": "@usr02:matrix.dev.service-ti.de",   "aud": [     "https://fhir-directory.vzd.ti-dienste.de/search",     "https://fhir-directory.vzd.ti-dienste.de/certificates"   ],   "exp": 1759841621,   "scope": "search:read certificate:read",   "iat": 1759755221 }

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

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

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

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

...

Es wird Kapitel "4.2.1.7" wie folgt eingefügt

4.2.1.7 Schnittstelle zum Lesen der fachlichen Logs I_FHIR_VZD_Fachliches_Log

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

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

Endpunkte zum Lesen der fachlichen Logs

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

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

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

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

Tabelle 23: Tab_I_FHIR_VZD_Fachliches_Log_Operations

Operation	Beschreibung
GET /log	Log von Verzeichniseinträgen lesen

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

Tabelle 24: Tab_I_FHIR_VZD_Fachliches_Log_Inhalt

Frage	Inhalt	Ausprägung
WER	Origin	Owner-Schnittstelle (TI-FHIR-Provider): OwnerID abhängig der TelematikId (aus Token) LDAP-Syncronisation (VZD-Converter): “SYSTEM”
WANN	Zeitstempel	DateTime
OBJECTTYP	RessourceType	HealthcareService, PractitionerRole, Location, Endpoint, Organization, Practitioner
OPERATION	Durchgeführte Operation	CREATE, UPDATE, DELETE
UID	Ressource-ID	UUID (HAPI-FHIR-UUID)
TID	TelematikId	TelematikId des Ressourcenbündels (HealthcareService, Organisation, Location, Endpoint bzw. PractitionerRole, Practitioner, Location, Endpoint). Die ID befindet sich in dem Telematik-Identifier der jeweiligen Organisation bzw. Practitioner-Ressource.
Sync-Quelle	LDAP-uid	String entsprechend LDAP-uid

Es wird Kapitel "4.3.1" wie folgt angepasst

...

...

 

 ...

Es wird Kapitel "4.3.4 Anforderungen an VZD Clients" wie folgt aufgenommen

4.3.4 Anforderungen an VZD Clients

A_27752 VZD Client - Nutzung zentraler TI-Systeme durch dezentrale Clients: Vermeidung der Gesamtauslese des VZD durch Clients

Ein Client DARF NICHT eine Gesamtauslese (systematische Abfrage aller verfügbaren Einträge über Einzelabfragen statt Nutzung dafürvorgesehener Exportmechanismen) des Verzeichnisdienstes (VZD) durchführen. Stattdessen SOLLEN die dedizierten Schnittstellen, falls vorhanden, für einen entsprechenden Export genutzt werden.
Clients, bei denen durch kontinuierliche Abfragen eine unzulässige Gesamtauslese vermutet wird, KÖNNEN im Zweifel gesperrt werden.

<=

Beispielhafte Abfrage zur effizienten Arztsuche:

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

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

Es wird Kapitel "5.1" wie folgt angepasst

Es wird Kapitel "5.2" wie folgt angepasst

In Kapitel "5.2", Abschnitt "Akzeptanzkriterien für den Anwendungsfall AF_10037 OrganizationDirectory-Einträge im VZD-FHIR-Directory ändern" wird wie folgt aufgenommen

...

...

Es wird Kapitel "5.2" wie folgt angepasst

...

Es wird Kapitel "7 VZD Self-Service Portal" wie folgt aufgenommen

7 VZD Self-Service Portal

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

7.1 Akteure

Zielgruppen des VZD Self-Service Portals sind

• HBA-Inhaber:
• Einsicht in die FHIR VZD Daten.
• Organisationen des Gesundheitswesens (SMC-B Inhaber):
• Einsicht in die FHIR VZD Daten.
• Für definierte Sektoren des Medizinwesens die Möglichkeit, eigene definierte "Mehrwertdaten" zu ändern.
• Kartenherausgeber:
• Einsicht in die FHIR VZD Daten.
• Änderbarkeit aller Daten ihrer Karteninfrastruktur.
• gematik:
• Einsicht in die FHIR VZD Daten.
• Mit Beauftragung durch Kartenherausgeber und bei TI-Störungen Änderbarkeit aller FHIR VZD Daten.

7.2 Funktionale Anforderungen

7.2.1 Architektur des VZD Self-Service Portals

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

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

Browser und Auflösung

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

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

7.2.1. Benutzerverwaltung, Authentisierung und Berechtigungen

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

Karteninhaber (Owner)

• Die Anmeldung erfolgt mittels SMC-B- oder HBA-Karte.
  
• Die Identifikation des Owners erfolgt über die der Karte zugeordnete Telematik-ID.
  
• Karteninhaber können bestimmte Informationen einsehen und unter definierten Bedingungen bearbeiten.
• Für Karteninhaber erfolgt die Benutzerverwaltung über ihre Karten und die Gültigkeit dieser Karten. Mit einem gültigen - und dem FHIR VZD bekannten - HBA bzw. SMC-B muss die Authentisierung am VZD Self-Service Portal möglich sein. Die Anmeldung mit allen anderen Karten muss abgelehnt werden, auch wenn ein IDP für diese Karten Token ausstellt.

Einfache Benutzer mit Lese-Berechtigung

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

Administrativer Benutzer mit erweiterten Rechten

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

Kartenherausgeber (Holder)

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

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

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

7.2.1.1. Funktionsspezifische Unterschiede

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

7.2.1.1.1. Suche und Anzeige

Suche und Anzeige von Detail-Informationen

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

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

Die Suche muss als Ergebnis liefern:

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

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

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

Anzeige Zertifikatsinformationen

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

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

Anzeige Fachliches Log (VZD FHIR + VZD LDAP)

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

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

Anzeige Rohdaten

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

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

7.2.1.1.2. Datenänderung über das VZD Self-Service Portal

Änderung von Mehrwertdaten (inkl. Endpunkte)

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

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

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

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

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

7.2.6. Benutzeroberfläche und Benutzererfahrung

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

Benutzerfreundlichkeit (Usability):

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

Effizienz:

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

Konsistenz:

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

Barrierefreiheit:

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

Fehlerbehandlung:

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

7.2.8  Anwendungsfälle

7.2.8.1 Authentisierung über HBA/SMC-B

7.2.8.2 Authentisierung von administrativen Nutzern

7.2.8.3 Suche und Anzeige von FHIR VZD Einträgen

7.2.8.4 Änderung von FHIR VZD Einträgen

Es wird Kapitel "7.5.2" wie folgt angepasst

8.5.2 Weitere Dokumente

...

Mitgeltende Dokumente und Web-Inhalte

Quelle	Herausgeber: Bezeichnung / URL	Version  Branch / Tag
[VZD-FHIR-PACKAGE-DIRECTORY]	https://simplifier.net/packages/de.gematik.fhir.directory/0.10.25  https://simplifier.net/packages/de.gematik.fhir.directory/1.0.0	0.11.24 1.0.0

Es wird Kapitel "7.6" wie folgt angepasst

8.6 Versionierung Datenmodell

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

• de.gematik.fhir.directory/0.11.25

• de.gematik.fhir.directory/1.0.0

3 Änderungen in Steckbriefen

3.1 Änderungen in gemProdT_VZD_PTV

Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemProdT_VZD_PTV]. Alle Anforderungen der Tabelle des Orig

inaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.

Tabelle 25: Festlegungen zur funktionalen Eignung "Produkttest/Produktübergreifender Test"

Afo-ID	Afo-Bezeichnung	Quelle (Referenz)
TIP1-A_5555	VZD, SOAP-Fehlercodes	gemSpec_VZD
TIP1-A_5572	VZD, I_Directory_Maintenance, TLS-gesicherte Verbindung	gemSpec_VZD
TIP1-A_5574	VZD und Nutzer der Schnittstelle I_Directory_Maintenance, WebService	gemSpec_VZD
TIP1-A_5575	VZD, Umsetzung add_Directory_Entry	gemSpec_VZD
TIP1-A_5576	Nutzer der Schnittstelle, TUC_VZD_0002 „add_Directory_Entry”	gemSpec_VZD
TIP1-A_5577	VZD, Umsetzung read_Directory_Entry	gemSpec_VZD
TIP1-A_5578	Nutzer der Schnittstelle, TUC_VZD_0003 „read_Directory_Entry”	gemSpec_VZD
TIP1-A_5579	VZD, Umsetzung modify_Directory_Entry	gemSpec_VZD
TIP1-A_5580	Nutzer der Schnittstelle, TUC_VZD_0004 „modify_Directory_Entry”	gemSpec_VZD
TIP1-A_5581	VZD, Umsetzung delete_Directory_Entry	gemSpec_VZD
TIP1-A_5582	Nutzer der Schnittstelle, TUC_VZD_0005 „delete_Directory_Entry”	gemSpec_VZD
TIP1-A_5586-02	VZD, I_Directory_Application_Maintenance, Webservice und LDAPv3	gemSpec_VZD
TIP1-A_5587	VZD, Implementierung der LDAPv3 Schnittstelle	gemSpec_VZD
TIP1-A_5590	VZD, Umsetzung add_Directory_FA-Attributes (SOAP)	gemSpec_VZD
TIP1-A_5591	FAD, TUC_VZD_0006 “add_Directory_FA-Attributes (SOAP)”	gemSpec_VZD
TIP1-A_5592-03	FAD, KOM-LE_FA_Add_Attributes	gemSpec_VZD
TIP1-A_5593	VZD, Umsetzung add_Directory_FA-Attributes (LDAPv3)	gemSpec_VZD
TIP1-A_5594	FAD, TUC_VZD_0007 “add_Directory_FA-Attributes (LDAPv3)”	gemSpec_VZD
A_21834	VZD, I_Directory_Application_Maintenance, KOM-LE_Version Prüfung LDAP	gemSpec_VZD
A_21835	VZD, I_Directory_Application_Maintenance, Eindeutige Zuordnung von KOM-LE Adressen zu VZD-Einträgen LDAP	gemSpec_VZD
A_23729	VZD, I_Directory_Application_Maintenance, Anwendungskennzeichen Prüfung LDAP	gemSpec_VZD
TIP1-A_5595	VZD, Umsetzung delete_Directory_FA-Attributes	gemSpec_VZD
TIP1-A_5596	FAD, TUC_VZD_0008 “delete_Directory_FA-Attributes (SOAP)”	gemSpec_VZD
TIP1-A_5597	VZD, Umsetzung delete_Directory_FA-Attributes (LDAPv3)	gemSpec_VZD
TIP1-A_5598	FAD, TUC_VZD_0009 “delete_Directory_FA-Attributes (LDAPv3)”	gemSpec_VZD
A_21460-01	VZD, Umsetzung delete_Directory_FA-Attributes (REST)	gemSpec_VZD
TIP1-A_5599-01	VZD, Umsetzung modify_Directory_FA-Attributes	gemSpec_VZD
TIP1-A_5600	FAD, TUC_VZD_0010 “modify_Directory_FA-Attributes (SOAP)”	gemSpec_VZD
TIP1-A_5601-03	FAD, KOM-LE_FA_Modify_Attributes	gemSpec_VZD
TIP1-A_5602	VZD, Umsetzung modify_Directory_FA-Attributes (LDAPv3)	gemSpec_VZD
TIP1-A_5603	FAD, TUC_VZD_0011 “modify_Directory_FA-Attributes (LDAPv3)”	gemSpec_VZD
A_18602-01	VZD, I_Directory_Administration, keine Datenänderung über Maintenance Schnittstelle	gemSpec_VZD
A_20402-04	VZD, I_Directory_Administration, read_Directory_Entry_for_Sync, Paging, Berechtigung	gemSpec_VZD

Tabelle 26: Festlegungen zur funktionalen Eignung "Herstellererklärung"

Afo-ID	Afo-Bezeichnung	Quelle (Referenz)
TIP1-A_5571	VZD, Schnittstelle I_Directory_Maintenance	gemSpec_VZD
A_23728-01	VZD, I_Directory_Application_Maintenance, Aktualisierung zulässiger Anwendungskennzeichen	gemSpec_VZD
TIP1-A_5607-13	VZD, logisches Datenmodell	gemSpec_VZD

Tabelle 27: Festlegungen zur funktionalen Eignung "Sich.techn Eignung: Gutachten"

Afo-ID	Afo-Bezeichnung	Quelle (Referenz)
TIP1-A_5548-01	VZD, Protokollierung der Änderungsoperationen	gemSpec_VZD

3.2 Änderungen in gemProdT_FD_KOMLE

Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemProdT_FD_KOMLE]. Alle Anforderungen der Tabelle des Orig

inaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.

Tabelle 28: Festlegungen zur funktionalen Eignung "Herstellererklärung"

Afo-ID	Afo-Bezeichnung	Quelle (Referenz)
TIP1-A_5588-01	FAD, I_Directory_Application_Maintenance, Nutzung Webservice	gemSpec_VZD
A_28423	FAD, TUC_VZD_0017 “search_Directory_FA-Attributes (REST)”	gemSpec_VZD
A_28424	FAD, TUC_VZD_0018 “readLog (REST)”	gemSpec_VZD
TIP1-A_5589	FAD, Implementierung der LDAPv3 Schnittstelle	gemSpec_VZD
TIP1-A_5591	FAD, TUC_VZD_0006 “add_Directory_FA-Attributes (SOAP)”	gemSpec_VZD
TIP1-A_5592-03	FAD, KOM-LE_FA_Add_Attributes	gemSpec_VZD
TIP1-A_5594	FAD, TUC_VZD_0007 “add_Directory_FA-Attributes (LDAPv3)”	gemSpec_VZD
TIP1-A_5596	FAD, TUC_VZD_0008 “delete_Directory_FA-Attributes (SOAP)”	gemSpec_VZD
TIP1-A_5598	FAD, TUC_VZD_0009 “delete_Directory_FA-Attributes (LDAPv3)”	gemSpec_VZD
TIP1-A_5600	FAD, TUC_VZD_0010 “modify_Directory_FA-Attributes (SOAP)”	gemSpec_VZD
TIP1-A_5601-03	FAD, KOM-LE_FA_Modify_Attributes	gemSpec_VZD
TIP1-A_5603	FAD, TUC_VZD_0011 “modify_Directory_FA-Attributes (LDAPv3)”	gemSpec_VZD
A_28423	FAD, TUC_VZD_0017 “search_Directory_FA-Attributes (REST)”	gemSpec_VZD
A_28424	FAD, TUC_VZD_0018 “readLog (REST)”	gemSpec_VZD

3.3 Änderungen in gemProdT_CM_KOMLE

Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemProdT_CM_KOMLE]. Alle Anforderungen der Tabelle des Originaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.

Tabelle 29: Festlegungen zur funktionalen Eignung "Herstellererklärung"

Afo-ID	Afo-Bezeichnung	Quelle (Referenz)
A_27744	VZD Clients - Nutzung zentraler TI-Systeme durch dezentrale Clients: Verbindungsmanagement	gemSpec_VZD
A_27749	VZD Client - Nutzung zentraler TI-Systeme durch dezentrale Clients: Verbindungsmanagement, Parameter	gemSpec_VZD
A_27751	VZD Client - Nutzung zentraler TI-Systeme durch dezentrale Clients: Angepasste Konfiguration und Außerbetriebnahme von Clients	gemSpec_VZD
A_28318	VZD Client - Deaktivierung nicht genutzter Clients	gemSpec_VZD
A_27752	VZD Client - Nutzung zentraler TI-Systeme durch dezentrale Clients: Vermeidung der Gesamtauslese des VZD durch Clients	gemSpec_VZD
A_27753	VZD Client - Nutzung zentraler TI-Systeme durch dezentrale Clients: Caching	gemSpec_VZD
A_27754	VZD Client - Nutzung zentraler TI-Systeme durch dezentrale Clients: Effiziente Gestaltung von FHIR-Suchanfragen	gemSpec_VZD
A_27755	VZD Client - Nutzung zentraler TI-Systeme durch dezentrale Clients: Fehler-Monitoring	gemSpec_VZD

3.4 Änderungen in gemProdT_VZD_FHIR

Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemProdT_VZD_FHIR]. Alle Anforderungen der Tabelle des Originaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.

Tabelle 30: Festlegungen zur funktionalen Eignung "Herstellererklärung"

Afo-ID	Afo-Bezeichnung	Quelle (Referenz)
AF_10036-04	Nutzer sucht Einträge im FHIR-Directory	gemSpec_VZD_FHIR_Directory
AF_10037-04	Einträge im VZD-FHIR-Directory ändern und suchen	gemSpec_VZD_FHIR_Directory
AF_10219-02	Versicherter sucht Einträge im FHIR-Directory	gemSpec_VZD_FHIR_Directory
AF_10414	FHIR VZD Self-Service Portal - Authentisierung über HBA/SMC-B	gemSpec_VZD_FHIR_Directory
AF_10415	FHIR VZD Self-Service Portal - Authentisierung über Passwort	gemSpec_VZD_FHIR_Directory
AF_10416	FHIR VZD Self-Service Portal - Suche und Anzeige von Einträgen	gemSpec_VZD_FHIR_Directory
AF_10417	FHIR VZD Self-Service Portal - Suche und Änderung von Einträgen	gemSpec_VZD_FHIR_Directory

Tabelle 31: Festlegungen zur funktionalen Eignung "Sich.techn Eignung: Gutachten"

Afo-ID	Afo-Bezeichnung	Quelle (Referenz)
TIP1-A_5548-01	VZD, Protokollierung der Änderungsoperationen	gemSpec_VZD_FHIR_Directory