Elektronische Gesundheitskarte und Telematikinfrastruktur
Spezifikation
Verzeichnisdienst
Version |
1. |
Revision |
|
Stand |
|
Status |
|
Klassifizierung |
öffentlich |
Referenzierung |
gemSpec_VZD |
Dokumentinformationen
Änderungen zur Vorversion
Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.
Dokumentenhistorie
Version |
Stand |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
Bearbeitung |
1.2.0 |
17.07.15 |
|
Nutzer der Schnittstelle I_Directory_Maintenance geändert |
gematik |
1.3.0 |
24.08.16 |
|
Anpassungen zum Online-Produktivbetrieb (Stufe 1) |
gematik |
1.4.0 |
28.10.16 |
|
Einarbeitung lt. Änderungsliste |
gematik |
1.5.0 |
19.04.17 |
|
Anpassung nach Änderungsliste |
gematik |
1.6.0 |
14.05.18 |
|
Anpassung nach Änderungslisten P15.2, 15.4 und 15.5 |
gematik |
1.7.0 |
15.05.19 |
|
Einarbeitung der Änderungen gemäß P18.1 |
gematik |
1.8.0 |
28.06.19 |
|
Einarbeitung der Änderungen gemäß P19.1 |
gematik |
1.9.0 |
02.10.19 |
|
Einarbeitung der Änderungen gemäß P20.1 und P16.1/2 |
gematik |
1.10.0 |
30.06.20 |
|
Anpassungen gemäß Änderungsliste P22.1 und Scope-Themen aus Systemdesign R4.0.0 |
gematik |
1.11.0 |
12.11.20 |
|
Anpassungen gemäß Änderungsliste P22.2 und Scope-Themen aus Systemdesign R4.0.1 |
gematik |
1.11.1 |
18.12.20 |
|
Einarbeitung der Änderungen gemäß P22.4 |
gematik |
1.12.0 |
19.02.21 |
|
Anpassungen gemäß Änderungsliste P22.5; |
gematik |
1.13.0 |
06.04.21 |
|
Anpassungen gemäß Änderungsliste KIM_Maintenance_21.1/ |
gematik |
1.13.1 |
20.04.21 |
|
Anpassung C_10533 aus KIM_Maintenance_21.1 vervollständigt (TIP1-A_5586 entfernt) |
gematik |
1.13.2 |
11.10.21 |
|
Umbenennung folgender Begriffe durch: |
gematik |
1.14.0 |
31.01.22 |
|
Anpassung gemäß Änderungsliste VZD-Maintenance 21.1 (C_10737) und VZD-Maintenance 21.2 (C_10918) |
gematik |
1.15.0 |
17.02.23 |
|
Anpassungen des gemSpec_VZD für eGBR und SMC-B ORG (VZD-Maintenance_23.1) |
gematik |
1.16.0 |
|
|
Anpassungen gemäß Änderungsliste KIM_Maintenance_23.2 - KIM 1.5.3 |
gematik |
1.17.0 |
22.03.24 |
|
Anpassungen gemäß Änderungsliste VZD_23.2 und _24.1 |
gematik |
3.1 IT-Sicherheit und Datenschutz
4.1 Schnittstelle I_Directory_Query
4.1.1 Operation search_Directory
4.2 Schnittstelle I_Directory_Maintenance
4.2.1 Operation add_Directory_Entry
4.2.2 Operation read_Directory_Entry
4.2.3 Operation modify_Directory_Entry
4.2.4 Operation delete_Directory_Entry
4.3 Schnittstelle I_Directory_Application_Maintenance
4.3.2 Operation add_Directory_FA-Attributes
4.3.3 Operation delete_Directory_FA-Attributes
4.3.4 Operation modify_Directory_FA-Attributes
4.3.5 Operation get_Directory_FA-Attributes
4.4 Prozessschnittstelle P_Directory_Application_Registration (Provided)
4.5 Prozessschnittstelle P_Directory_Maintenance (Provided)
4.6 Schnittstelle I_Directory_Administration
4.6.1 Operationen der Schnittstelle I_ Directory_Administration
4.6.1.1 I_Directory_Administration - Lesen der Metadaten
4.6.1.2 DirectoryEntry Administration
4.6.1.2.4 PUT - active Attribut
4.6.1.3 Certificate Administration
4.6.1.4 DirectoryEntry Synchronization
4.6.2 Nutzung der Schnittstelle I_Directory_Administration
5 Datenmodell4.6.3 Zusammenführung mehrerer TelematikID´s zu einer Organisation
6 Anhang A – Verzeichnisse5 Datenmodell
6.1 Abkürzungen Anhang A – Verzeichnisse
6.3 Abbildungsverzeichnis2 Glossar
6.4 Tabellenverzeichnis3 Abbildungsverzeichnis
6.5 Referenzierte Dokumente4 Tabellenverzeichnis
6.5.1 Dokumente der gematik Referenzierte Dokumente
6.5.2 Weitere1 Dokumente der gematik
1 Einordnung des Dokumentes
Die Spezifikation des Verzeichnisdienstes (VZD) enthält die Definition der Funktionalität, der Prozesse und der Schnittstellen sowie das Informationsmodell des VZD.
Der VZD ist ein zentraler Dienst der TI-Plattform.
Das Informationsmodell des VZD ist erweiterbar.
Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test, Betrieb, Datenschutz und Informationssicherheit des Produkttyps VZD.
Das Dokument ist maßgeblich für Anbieter und Hersteller von Verzeichnisdiensten
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 mbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.
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 mbH übernimmt insofern keinerlei Gewährleistungen.
Spezifiziert werden in dem Dokument die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird verwiesen (siehe auch 6 Anhang A – Verzeichnisse).
Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps VZD dokumentiert.
Nicht Bestandteil des vorliegenden Dokumentes sind die Festlegungen zum Themenbereich
- Werkzeuge für Fachdienstanbieter, die die Administration von fachdienstspezifischen Daten unterstützen.
Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.
Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]
Dabei umfasst die Anforderung sämtliche innerhalb der Afo-ID und der Textmarke angeführten Inhalte.
Für die Erzeugung der Abbildungen und Informationsmodelle wird das Tool „Enterprise Architect“ verwendet.
Der VZD ist ein Produkttyp der TI gemäß [gemKPT_Arch_TIP].
Abbildung 1: Einordnung des VZD in die TI
Der VZD befindet sich in der zentralen Zone der TI-Plattform.
Die Dateneinträge werden erstellt und gepflegt:
- per Basisdatenadministration durch berechtigte Benutzer (Kartenherausgeber oder von ihnen berechtigte Organisationen sowie von KOM-LE-Anbietern mittels KOM-LE-Fachdienst, wenn für bestimmte LE noch keine Basisdaten eingetragen sind)
- durch fachanwendungsspezifische Dienste (FAD), die fachanwendungsspezifische Daten (Fachdaten) zu bereits bestehenden Basisdaten zufügen.
Der VZD kann durch LDAP-Clients abgefragt werden.
3.1 IT-Sicherheit und Datenschutz
TIP1-A_5546-01 - VZD, Integritäts- u. Authentizitätsschutz
Der Anbieter des VZD MUSS die Integrität und Authentizität der im VZD gespeicherten Daten gemäß den Richtlinien des Bundesamtes für Sicherheit in der Informationstechnik für allgemeine Verzeichnisdienste, [BSI APP.2.1], implementieren. [<=]
TIP1-A_5547-01 - VZD, Löschen ungültiger Zertifikate
Der VZD MUSS täglich die gespeicherten Zertifikate nach Ablaufdatum (TUC_PKI_002 „Gültigkeitsprüfung des Zertifikats“) und Status (TUC_PKI_006 "OCSP-Abfrage) prüfen. Ungültige Zertifikate werden (inklusive der gesamten Zertifikatsstruktur "Certificate" entsprechend Abb_VZD_logisches_Datenmodell) sofort gelöscht. Ein Eintrag ohne gültige Zertifikate wird nach einem Jahr gelöscht und darf nicht durch eine Anfrage über die Operation search_Directory der Schnittstelle I_Directory_Query gefunden werden.
[<=]
Zum Beispiel dürfen gültige RU-/TU-Zertifikate nicht in der PU akzeptiert werden. Die Prüfung über TUC_PKI_018 berücksichtigt entsprechend dem initialisierten Vertrauensanker (aus der jeweiligen Umgebung) die Umgebung.
A_21808 - VZD, Hinzufügen von professionOID und entryType in die Basisdaten
Der VZD MUSS beim Hinzufügen von Zertifikaten prüfen, ob der Wert der enthaltenen professionOID bzw. entryType schon in den Basisdaten vorhanden ist. Falls nicht, MUSS der VZD diese professionOID bzw. entryType zu den existierenden Basisdaten hinzufügen. [<=]
A_21809 - VZD, Löschen von professionOID und entryType aus den Basisdaten
Der VZD MUSS gewährleisten, dass nach dem Löschen von Zertifikaten für die Attribute professionOID und entryType in den Basisdaten nur Werte aus den verbleibenden Zertifikaten erhalten bleiben. [<=]
TIP1-A_5548 - VZD, Protokollierung der Änderungsoperationen
Der VZD MUSS Änderungen der Verzeichnisdiensteinträge protokollieren und muss sie 6 Monate zur Verfügung halten.
[<=]
6 Monate ist die maximale Nachweistiefe ohne in den Bereich der Vorratsdatenspeicherung zu kommen.
TIP1-A_5549 - VZD, Keine Leseprofilbildung
Der VZD DARF Suchanfragen NICHT speichern oder protokollieren.
[<=]
TIP1-A_5550 - VZD, Keine Kopien von gelöschten Daten
Der VZD DARF von gelöschten Daten KEINE Kopien speichern.
[<=]
TIP1-A_5551 - VZD, Sicher gegen Datenverlust
Der Anbieter des VZD MUSS den Dienst gegen Datenverlust absichern.
[<=]
TIP1-A_5552 - VZD, Begrenzung der Suchergebnisse
Der VZD MUSS die Ergebnisliste einer Suchanfrage auf 100 Suchergebnisse begrenzen.
[<=]
TIP1-A_5553 - VZD, Private Schlüssel sicher speichern
Der VZD MUSS seine privaten Schlüssel sicher speichern und ihr Auslesen verhindern um Manipulationen zu verhindern.
[<=]
TIP1-A_5554 - VZD, Registrierungsdaten sicher speichern
Der VZD MUSS die Integrität und Authentizität der gespeicherten Registrierungsdaten der FAD gewährleisten.
[<=]
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.
[<=]
TIP1-A_5556 - VZD, Fehler Logging
Der VZD MUSS lokal und remote erkannte Fehler in seinem lokalen Speicher protokollieren.
[<=]
TIP1-A_5557 - VZD, Unterstützung IPv4 und IPv6
Der VZD MUSS IPv4 und IPv6 für alle seine IP-Schnittstellen im Dual-Stack-Mode unterstützen.
[<=]
TIP1-A_5558 - VZD, Sicheres Speichern der TSL
Der VZD MUSS die Inhalte der TSL in einem lokalen Trust Store sicher speichern und für X.509-Zertifikatsprüfungen lokal zugreifbar halten.
[<=]
TIP1-A_5560 - VZD, Erweiterbarkeit für neue Fachdaten
Der Anbieter des VZD MUSS die Erweiterbarkeit des VZD für die Aufnahme der Fachdaten neuer Fachanwendungen gewährleisten.
[<=]
TIP1-A_5561 - VZD, DNS-SD
Der Anbieter des VZD MUSS alle erforderlichen Einträge zur Dienstlokalisierung der Außenschnittstellen gemäß [RFC6763] beginnend mit folgenden PTR Resource Record-Bezeichnern im Namensdienst der TI-Plattform anlegen:
- für den Zugriff auf die Schnittstelle I_Directory_Query:
_ldap._tcp.vzd.telematik.
- für den Zugriff auf die Schnittstelle I_Directory_Maintenance:
_vzd-bd._tcp.vzd.telematik.
- für den Zugriff auf die Schnittstelle I_Directory_Application_Maintenance:
_vzd-fd._tcp.vzd.telematik.
[<=]
TIP1-A_5562 - VZD, Parallele Zugriffe
Der Betreiber des VZD MUSS sicherstellen, dass Benutzer gleichzeitig auf den VZD zugreifen können. Dies umfasst alle technischen Schnittstellen. In [gemSpec_Perf] ist die Anzahl der parallelen Zugriffe definiert.
[<=]
TIP1-A_5563-01 - VZD, Erhöhung der Anzahl der Einträge
Der Anbieter des VZD MUSS sicherstellen, dass 1.000.000 Einträge gespeichert werden können.
[<=]
TIP1-A_5620 - VZD, Nicht-Speicherung von Leading und Trailing Spaces
Der Anbieter des VZD MUSS Leading und Trailing Spaces abschneiden.
[<=]
A_20331 - VZD, Verhinderung LDAP Injection Attack
Der VZD MUSS an allen Schnittstellen - welche LDAP nutzen bzw. auf LDAP abgebildet werden - LDAP Injection Attacks durch geeignete Sicherheitsprüfungen verhindern.
[<=]
A_20262 - VZD, Maximale Anzahl von KOM-LE Adressen in den Fachdaten
Der VZD MUSS bei dem Hinzufügen von KOM-LE Adressen in den Fachdaten folgende Regeln beachten:
- Wenn maxKOMLEadr im Verzeichniseintrag keinen Wert enthält, MUSS der VZD das Eintragen beliebig vieler KOM-LE Adressen in den Fachdaten erlauben.
- Wenn maxKOMLEadr im Verzeichniseintrag einen Wert enthält, MUSS der VZD das Eintragen von maximal so vielen KOM-LE Adressen in den Fachdaten erlauben.
- Wenn der Wert von maxKOMLEadr im Verzeichniseintrag gleich oder kleiner ist als die Anzahl der KOM-LE Adressen in den Fachdaten (z.B. falls der Wert heruntergesetzt wurde), MUSS der VZD das Eintragen von weiteren KOM-LE Adressen in den Fachdaten ablehnen.
[<=]
A_20263 - VZD, Kein automatisches Löschen von KOM-LE Adressen in den Fachdaten
Der VZD DARF KOM-LE Adressen in den Fachdaten als Folge einer Änderung (Verkleinerung) des Attributwerts von maxKOMLEadr NICHT automatisch löschen.
[<=]
Der betroffene KOM-LE Teilnehmer muss in diesem Fall zusammen mit dem KOM-LE-Anbieter die nicht mehr benötigten KOM-LE Adressen löschen.
A_23179 - VZD, Zeitnahes Aktualisieren von Zertifikaten entsprechend zeitlicher Gültigkeit
Der VZD MUSS - anhand der Attribute notBefore und notAfter in den Zertifikatsdaten - periodisch die zeitliche Gültigkeit der Zertifikate ermitteln und diese entsprechend ihrer Gültigkeit in die flache Liste synchronisieren bzw. aus ihr löschen. Die Periode dieser Prüfung MUSS konfigurierbar sein. [<=]
A_22224 - VZD, konfigurierbares Mapping von professionOID auf entryType
Der VZD MUSS das Mapping von professionOID auf entryType konfigurierbar implementieren, so dass bei Änderung des Mappings oder neuen professionOIDs oder neuen entryTypes keine Anpassung an der Software des VZD erforderlich ist.
Änderungen am Mapping werden durch den Gesamtbetriebsverantwortlichen TI per betrieblichen Change veranlasst.
[<=]
Der VZD beinhaltet alle serverseitigen Anteile des Basisdienstes Verzeichnis_Identitäten gemäß [gemKPT_Arch_TIP]. Dazu zählen die Speicherung der Einträge von Leistungserbringern und Institutionen mit allen definierten Attributen sowie die Speicherung von Fachdaten durch FAD. Mit einer LDAP-Suchanfrage können Clients und FAD Basis- und Fachdaten abfragen (z. B. X.509-Zertifikate).
Einträge des VZD werden durch berechtigte Benutzer sowie durch berechtigte FAD erstellt und gepflegt.
TIP1-A_5564 - VZD, Festlegung der Schnittstellen
Der VZD MUSS die Schnittstellen gemäß Tabelle Tab_PT_VZD_Schnittstellen implementieren („bereitgestellte“ Schnittstellen) und nutzen („benötigte“ Schnittstellen).
Tabelle 1: Tab_PT_VZD_Schnittstellen
Schnittstelle |
bereitgestellt / benötigt |
Bemerkung |
I_Directory_Query |
bereitgestellt |
|
I_Directory_Maintenance |
bereitgestellt |
|
I_Directory_Application_Maintenance |
bereitgestellt |
|
I_Directory_Administration |
bereitgestellt |
|
I_IP_Transport |
benötigt |
Definition in [gemSpec_Net] |
I_DNS_Name_Resolution |
benötigt |
Definition in [gemSpec_Net] |
I_NTP_Time_Information |
benötigt |
Definition in [gemSpec_Net] |
I_OCSP_Status_Information |
benötigt |
Definition in [gemSpec_PKI] |
I_TSL_Download |
benötigt |
Definition in [gemSpec_TSL] |
[<=]
A_22361 - VZD, Filtermöglichkeiten in Leseoperationen
Der VZD MUSS für die Leseoperationen read_Directory_Entry und read_Directory_Entry_for_Sync der Schnittstellen I_Directory_Administration und I_Directory_Application_Maintenance die folgenden Filtermöglichkeiten unterstützen:
- Suche mit Wildcard "*" in den Parametern
- givenName
- sn
- cn
- displayName
- streetAddress
- postalCode
- countryCode
- localityName
- stateOrProvinceName
- title
- organization
- otherName
- telematikID
- specialization
- domainID
- holder
- professionOID - Suche nach Vorhandensein und leerem Inhalt eines Attributs des VZD Datensatzes mit dem Kode \00 in den Parametern.
- givenName
- sn
- cn
- displayName
- streetAddress
- postalCode
- countryCode
- localityName
- stateOrProvinceName
- title
- organization
- otherName
- specialization
- domainID
- holder
- professionOID
- maxKOMLEadr
- changeDateTimeFrom
- changeDateTimeTo
Diese Suche findet sowohl Datensätze mit nicht vorhandenem Attribut wie auch vorhandenem aber leerem Attribut. Der Suchparameter darf nur den Kode \00 enthalten, keine weiteren Zeichen.
Alle Filterparameter einer Leseoperationen werden mit einem UND (&) verknüpft.
[<=]
Beispiel für die Belegung der Filterparameter einer Operation read_Directory_Entry für die Suche nach Einträgen ohne gefülltes Attribut "specialization" UND Postleitzahl 10*:
postalCode 10*
specialization \00
4.1 Schnittstelle I_Directory_Query
Die Schnittstelle ermöglicht LDAPv3-Clients die Suche nach Daten im VZD gemäß der im Informationsmodell (siehe Kapitel 5) definierten Attribute.
TIP1-A_5565 - VZD, Schnittstelle I_Directory_Query
Der VZD MUSS für LDAP Clients die Schnittstelle I_Directory_Query gemäß Tabelle Tab_VZD_Schnittstelle_I_Directory_Query anbieten.
Tabelle 2: Tab_VZD_Schnittstelle_I_Directory_Query
Name |
I_Directory_Query |
|
Version |
wird im Produkttypsteckbrief des VZD definiert |
|
Operationen |
Name |
Kurzbeschreibung |
search_Directory |
Abfragen von Daten des VZD gemäß LDAPv3 Protokoll. |
|
[<=]
4.1.1 Operation search_Directory
TIP1-A_5566 - LDAP Client, LDAPS
Der LDAP Client MUSS die Verbindung zum VZD mittels LDAPS sichern.
Der LDAP Client muss das Zertifikat des VZD C.ZD.TLS-S gemäß TUC_PKI_018 "Zertifikatsprüfung in der TI" und die Rolle (zulässig ist oid_vzd_ti) prüfen. LDAP Clients der Anbieter von WANDA Basic und WANDA Smart sind davon ausgenommen.
Der LDAP Client authentisiert sich nicht.
[<=]
TIP1-A_5567 - VZD, LDAPS bei search_Directory
Der VZD MUSS sicherstellen, dass die Operation search_Directory nur über eine bestehende LDAPS -Verbindung ausgeführt werden kann.
Der VZD muss die TLS-Verbindung 15 Minuten nach dem letzten Meldungsverkehr abbauen, falls sie noch besteht.
[<=]
TIP1-A_5568 - VZD und LDAP Client, Implementierung der LDAPv3 search Operation
Der VZD und die LDAP-Clients MÜSSEN die search Operation gemäß den LDAPv3 Standards [RFC4510], [RFC4511], [RFC4512], [RFC4513], [RFC4514], [RFC4515], [RFC4516], [RFC4517], [RFC4518], [RFC4519], [RFC4520], [RFC4522] und [RFC4523] implementieren.
[<=]
A_17794 - VZD, Testunterstützung
Der VZD MUSS für die Schnittstelle I_Directory_Query einen technischen User in RU/TU bereitstellen, über den eine unlimitierte Abfrage der Daten des Verzeichnisdienstes (searchView) möglich ist.
[<=]
TIP1-A_5569 - VZD, search_Directory, Suche nach definierten Attributen
Der VZD MUSS die enthaltenen Daten so strukturiert haben, dass mit einer einzigen LDAPv3-Suche alle einer Telematik-ID zugeordneten Attribute (Basisdaten und Fachdaten) in Form einer flachen Liste von Attributen ohne ou-Unterstruktur abgefragt werden können.
Die abgefragten Attribute MÜSSEN durch marktübliche E-Mail Clients nutzbar sein.
[<=]
TIP1-A_5570 - LDAP Client, TUC_VZD_0001 „search_Directory”
Der Anbieter des VZD MUSS für die Nutzung durch LDAP Clients den technischen Use Case TUC_VZD_0001 „search_Directory” gemäß Tabelle Tab_TUC_VZD_0001 unterstützen.
Name |
TUC_VZD_0001 “search_Directory” |
|
Beschreibung |
Diese Operation ermöglicht die Suche nach den im VZD gespeicherten Daten. |
|
Vorbedingungen |
Der LDAPS-Verbindungsaufbau muss erfolgreich durchgeführt sein. |
|
Eingangsdaten |
Search Request gemäß [RFC4511]#4.5.1 und Informationsmodell (Abb_VZD_logisches_Datenmodell) |
|
Komponenten |
LDAP Client, Verzeichnisdienst |
|
Ausgangsdaten |
gemäß [RFC4511]#4.5.2 |
|
Standardablauf |
Aktion |
Beschreibung |
Search Request senden |
Der LDAP Client sendet eine Suchanfrage gemäß [RFC4511]#4.5.1 an die Schnittstelle I_Directory_Query des VZD. Die RFCs [RFC4510], [RFC4511], [RFC4513], [RFC4514], [RFC4515], [RFC4516], [RFC4519] und [RFC4522] müssen unterstützt werden. |
|
Search Response empfangen |
Der LDAP Client empfängt das Ergebnis der Suche gemäß [RFC4511]#4.5.2. |
|
Varianten/Alternativen |
keine |
|
Zustand nach erfolgreichem Ablauf |
Die Ergebnisse der Suche liegen im LDAP Client vor. |
|
Fehlerfälle |
Zur Behandlung auftretender Fehlerfälle werden Fehlermeldungen gemäß [RFC4511]#Appendix A verwendet. |
|
[<=]
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 4: 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.
TIP1-A_5575 - VZD, Umsetzung add_Directory_Entry
Der VZD MUSS nach folgenden Vorgaben die Operation add_Directory_Entry implementieren:
- Ein bereits zur Telematik-ID gehörender Basisdatensatz wird gelöscht und neu angelegt.
- Existiert noch kein Basisdatensatz zur Telematik-ID wird ein neuer angelegt.
- 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 5: 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 |
surname |
Verwendung gemäß Tab_VZD_Datenbeschreibung |
n/a |
cn |
commonName |
Verwendung gemäß Tab_VZD_Datenbeschreibung |
n/a |
displayName |
displayName |
|
streetAddress |
streetAddress |
streetAddress |
Alias street |
postalCode |
postalCode |
postalCode |
|
localityName |
localityName |
localityName |
Alias l |
stateOrProvinceName |
stateOrProvinceName |
stateOrProvinceName |
Alias st |
title |
title |
title |
Verwendung gemäß Tab_VZD_Datenbeschreibung |
organization |
organization |
organization |
Alias o |
otherName |
otherName |
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 |
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 |
|
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.
Name |
TUC_VZD_0002 „add_Directory_Entry” |
|
Beschreibung |
Diese Operation ermöglicht die Erzeugung von neuen Basisdaten. |
|
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. |
|
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). |
|
[<=]
4.2.2 Operation read_Directory_Entry
Diese Operation liest einen vollständigen Eintrag aus dem LDAP Verzeichnis aus.
TIP1-A_5577 - VZD, Umsetzung read_Directory_Entry
Der VZD MUSS nach folgenden Vorgaben die Operation I_Directory_Maintenance::read_Directory_Entry implementieren:
- Der zur Telematik-ID gehörende Eintrag wird im LDAP Directory ermittelt.
- 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.
[<=]
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.
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. |
|
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) |
|
[<=]
4.2.3 Operation modify_Directory_Entry
Diese Operation ändert die Daten eines bestehenden Basisdatensatzes im LDAP Verzeichnis.
TIP1-A_5579 - VZD, Umsetzung modify_Directory_Entry
Der VZD MUSS nach folgenden Vorgaben die Operation modify_Directory_Entry implementieren:
- Der zur Telematik-ID gehörende Basisdatensatz wird im LDAP Directory ermittelt.
- 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.
[<=]
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.
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. |
|
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) |
|
[<=]
4.2.4 Operation delete_Directory_Entry
Diese Operation löscht einen bestehenden Datensatz im LDAP Verzeichnis.
TIP1-A_5581 - VZD, Umsetzung delete_Directory_Entry
Der VZD MUSS nach folgenden Vorgaben die Operation I_Directory_Maintenance::delete_Directory_Entry implementieren:
- Ein zur Telematik-ID gehörender vollständiger Eintrag gelöscht.
Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0005 verwendet werden.
[<=]
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.
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. |
|
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) |
|
[<=]
4.3 Schnittstelle I_Directory_Application_Maintenance
Die Schnittstelle ermöglicht die Administration der Fachdaten.
Der VZD stellt diese Schnittstelle als 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_5583-02 - VZD, Schnittstelle I_Directory_Application_Maintenance
Der VZD MUSS die Schnittstelle I_Directory_Application_Maintenance gemäß Tabelle Tab_VZD_Schnittstelle_I_Directory_Application_Maintenance anbieten.
Tabelle 10: Tab_VZD_Schnittstelle_I_Directory_Application_Maintenance
Name |
I_Directory_Application_Maintenance |
|
Version |
wird im Produkttypsteckbrief des VZD definiert |
|
Operationen |
Operation |
Kurzbeschreibung |
getInfo |
Lesen der Metadaten dieser Schnittstelle (nur für die REST-Ausprägung verfügbar) |
|
add_Directory_FA-Attributes |
Erzeugung eines Fachdaten-Eintrags |
|
delete_Directory_FA-Attributes |
Löschen von einzelnen oder allen zu einem FAD gehörenden Fachdaten eines Eintrags. |
|
modify_Directory_FA-Attributes |
Ändern fachspezifischer Attribute |
|
get_Directory_FA_Attributes |
Lesen fachspezifischer Attribute |
|
[<=]
TIP1-A_5584 - VZD, Änderung nur durch registrierte FAD
Der Anbieter des VZD MUSS sicherstellen, dass Fachdaten eines Dienstes nur durch einen beim VZD für diesen Dienst registrierten Fachdienst erzeugt, gelöscht und geändert werden können.
[<=]
Dazu wird bei der Registrierung eine FAD zugeordnet. Unter dieser FAD werden die Fachdaten für den jeweiligen Dienst im VZD abgelegt. Die Zuordnung der FAD zu dem Dienst wird bei Aufruf jeder Operation von Schnittstelle I_Directory_Application_Maintenance durch den VZD geprüft (z.B. anhand des TLS-Client-Zertifikats oder OAuth2 Tokens).
TIP1-A_5585 - VZD, I_Directory_Application_Maintenance, TLS-gesicherte Verbindung
Der VZD MUSS die Schnittstelle I_Directory_Application_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_5586-01 - VZD, I_Directory_Application_Maintenance, Webservice und LDAPv3
Der VZD MUSS die Schnittstelle I_Directory_Application_Maintenance als Webservice (SOAP und REST über HTTPS) und als LDPv3 über LDAPS implementieren. Der Webservice (SOAP) wird durch die Dokumente DirectoryApplicationMaintenance.wsdl und DirectoryApplicationMaintenance.xsd definiert. Der Webservice (REST) wird durch die [Directory_Application_Maintenance.yaml] Datei definiert. Die LDAPv3-Attribute sind in dem Informationsmodell Abb_VZD_logisches_Datenmodell beschrieben.
[<=]
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_5588 - FAD, I_Directory_Application_Maintenance, Nutzung LDAP v3 oder Webservice
Ein FAD, der Fachdaten im VZD verwalten will, MUSS entweder die Webservice- oder die LDAPv3-Schnittstelle nutzen.
[<=]
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 jede Stunde prüfen, ob eine neuere Version des täglich um 4:00 Uhr das FHIR CodeSystems (https://simplifier.net/app-transport-framework/service-identifier-cs/$download?format=json ) mit den Anwendungskennzeichen vorhanden ist und ggf. diese herunterladenaus Simplifier (https://simplifier.net/app-transport-framework/app-tags-cs/$download?format=json ) aktualisieren und persistent speichern. [<=]
Hinweis: Ob eine neuere Version des CodeSystems vorhanden ist kann mit der HTTP HEAD Operation geprüft werden. Die Dateigröße der heruntergeladenen JSON-Datei kann man als Hashfunktion verwenden. Mit Hilfe des Tools curl kann man die HTTP-Methode HEAD verwenden und damit erfahren ob die lokale Kopie der JSON-Datei noch aktuell ist.
Diese Operation liefert die Metadaten der Schnittstelle I_Directory_Application_Maintenance.
A_21788-01 - VZD, Umsetzung I_Directory_Application_Maintenance getInfo (REST)
Der VZD MUSS nach folgenden Vorgaben die Operation getInfo implementieren:
In dem Rückgabewerten müssen die aktuell gültigen Metainformationen für Schnittstelle I_Directory_Application_Maintenance zurückgegeben werden. Insbesondere muss
- der Parameter version die aktuelle Version der Schnittstelle enthalten (entspricht info.version der Schnittstellendefinition DirectoryApplicationMaintenance.yaml)
- der Parameter title den Titel der Schnittstelle enthalten (entspricht info.title der Schnittstellendefinition DirectoryApplicationMaintenance.yaml)
- der Parameter description eine Kurzbeschreibung der Schnittstelle, die Produktversion und einen Link zur aktiven YAML-Datei enthalten.
[<=]
In dem Dokument unter dieser URL muss ein Link zum Download der aktuell genutzten YAML-Datei dieser Schnittstelle hinterlegt sein.
A_21787 - VZD, I_Directory_Application_Maintenance, getInfo
Der VZD MUSS die Operation „getInfo” gemäß Tabelle Tab_VZD „I_Directory_Application_Maintenance-getInfo” umsetzen.
Tabelle 11: Tab_VZD „I_Directory_Application_Maintenance-getInfo”
Name |
getInfo |
|
Beschreibung |
Liefert die Metadaten (unter anderem aus dem InfoObject) dieser OpenAPI-Spezifikation und ergänzt sie. |
|
Eingangsdaten |
REST-Request GET / |
|
Parameter |
Beschreibung |
|
keine |
- |
|
Komponenten |
Nutzer der Schnittstelle |
|
Ausgangsdaten |
REST-Response mit Metadaten (InfoObject). |
|
Ablauf |
Der VZD liefert die Metadaten der Schnittstelle in der Datenstruktur InfoObject zurück. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) und in DirectoryApplicationMaintenance.yaml mit spezifischen Fehlerbeschreibungen ergänzt. |
|
[<=]
4.3.2 Operation add_Directory_FA-Attributes
Diese Operation legt einen neuen Fachdatensatz an oder überschreibt einen bestehenden fachdienstspezifischen Datensatz.
Voraussetzung: Die Fachdaten müssen einem Basisdateneintrag zuordenbar sein.
TIP1-A_5590 - VZD, Umsetzung add_Directory_FA-Attributes (SOAP)
Der VZD MUSS nach folgenden Vorgaben die Operation add_Directory_FA-Attributes implementieren:
- 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. - Ein bereits zur Telematik-ID gehörender Fachdatensatz wird gelöscht und neu angelegt.
- Ein noch nicht existierender Fachdatensatz zur Telematik-ID wird im LDAP Directory neu angelegt.
- Die Daten aus dem SOAP Request werden gemäß VZD_TAB_I_Directory_Application_Maintenance_Add_Mapping zum Basisdatensatz hinzugefügt.
Tabelle 12: VZD_TAB_I_Directory_Application_Maintenance_Add_Mapping
SOAP-Request Element |
LDAP-Directory |
VZD:timestamp |
wird nicht in das LDAP-Directory eingetragen |
VZD:Telematik-ID |
|
<FA-Attributes> |
fachdienstspezifische Attribute. |
Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0006 verwendet werden.
[<=]
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.
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. |
|
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. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS). |
|
[<=]
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 14: VZD_TAB_KOM-LE_Attributes
SOAP-Request Element |
LDAP-Directory |
VZD:timestamp |
wird nicht in das LDAP-Directory eingetragen |
VZD:telematikID |
|
VZD:KOM-LE-EMail-Address |
|
VZD:version |
KOM-LE-Version |
[<=]
TIP1-A_5593 - VZD, Umsetzung add_Directory_FA-Attributes (LDAPv3)
Der VZD MUSS nach folgenden Vorgaben die Operation add_Directory_FA-Attributes implementieren:
- Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einer Fehlermeldung beendet.
- Ein noch nicht existierender Fachdatensatz zur Telematik-ID wird im VZD neu angelegt.
- Der FAD darf nur die zu seinem Dienst gehörenden Fachdaten schreiben.
Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0007 verwendet werden.
[<=]
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.
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. [<=]
A_21458 - VZD, Umsetzung add_Directory_FA-Attributes (REST)
Der VZD MUSS nach folgenden Vorgaben die Operation add_Directory_FA-Attributes implementieren:
- Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einem HTTP-Statuscode beendet:
HTTP-Statuscode: 404 - Ein bereits zur Telematik-ID gehörender Fachdatensatz wird gelöscht und neu angelegt.
- Ein noch nicht existierender Fachdatensatz zur Telematik-ID wird im LDAP Directory neu angelegt.
- Die Daten aus dem Request werden zum dazugehörenden Fachdatensatz hinzugefügt.
[<=]
A_23730 - VZD, I_Directory_Application_Maintenance, Anwendungskennzeichen Prüfung REST
Der VZD MUSS bei Änderungen an KOM-LE-Fachdaten mit den Operationen „add_Directory_FA-Attributes“ und "modify_Directory_FA-Attributes" 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 HTTP-Statuscode 400 (attributeName="appTags" , attributeError="erläuternder Fehlertext") antworten und darf die Operation nicht ausführen. [<=]
A_23819 - VZD, I_Directory_Application_Maintenance, Behandlung komLeData & kimData REST
Der VZD MUSS bei Änderungen an KOM-LE-Fachdaten mit den Operationen „add_Directory_FA-Attributes“ und "modify_Directory_FA-Attributes" den Inhalt von Parameter komLeData wie folgendermassen in die LDAP Datenstruktur eintragen:
- komLeData.mail der REST Operation wird in die LDAP Attribute komLeData.mail und kimData.mail eingetragen.
- komLeData.version der REST Operation wird in die LDAP Attribute komLeData.version und kimData.version eingetragen.
- komLeData.appTags der REST Operation wird in die LDAP Attribut kimData.appTags eingetragen.
Dabei MUSS die Reihenfolge der Attribute im LDAP String gewährleistet werden:
komLeData: version,mail
kimData: mail,version,appTags
Als Trennzeichen der Attribute MUSS ein Komma ',' verwendet werden.
Wenn Attribut appTags mehrere Werte enthält, MUSS als Trennzeichen eine Pipe '|' verwendet werden.
[<=]
Hinweis: Das LDAP Attribut "komLeData" ist aus Performancegründen nicht für die Suche nach der Mail Adresse geeignet. Falls das LDAP Attribut "mail" nicht für die Suche geeignet ist, muss LDAP Attribut "kimData" genutzt werden.
A_21459 - FAD, VZD, TUC_VZD_0012 “add_Directory_FA-Attributes (REST)”
Der FAD MUSS den technischen Use Case TUC_VZD_0012 “add_Directory_FA-Attributes” gemäß Tabelle Tab_TUC_VZD_0012 umsetzen.
Tabelle 3116: Tab_TUC_VZD_0012
Name |
add_Directory_FA-Attributes |
|
Beschreibung |
Mit dieser Operation werden Fachdaten zu einem bestehenden Basisdaten-Eintrag zugefügt. |
|
Vorbedingungen |
Keine. |
|
Eingangsdaten |
REST-Request „add_Directory_FA-Attributes“ |
|
Komponenten |
VZD, FAD |
|
Ausgangsdaten |
REST-Response |
|
Standardablauf |
Aktion |
Beschreibung |
Aufbau TLS-Verbindung |
Falls noch keine TLS-Verbindung besteht, wird eine aufgebaut. |
|
REST-Request senden |
Der FAD ruft die REST-Operation add_Directory_FA-Attributes auf. |
|
REST-Response empfangen |
Die REST-Response enthält den HTTP-Statuscode. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS). |
|
[<=]
A_21825-02 - VZD, I_Directory_Application_Maintenance, KOM-LE_Version Prüfung REST
Der VZD MUSS bei Änderungen an KOM-LE-Fachdaten mit den Operationen „add_Directory_FA-Attributes“ und "modify_Directory_FA-Attributes" 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 HTTP-Statuscode 400 (attributeName="KOM-LE_Version" , attributeError="erläuternder Fehlertext") 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_21826-01 - VZD, I_Directory_Application_Maintenance, Eindeutige Zuordnung von KOM-LE-Adressen zu VZD-Einträgen REST
Der VZD MUSS sicherstellen, dass jede KOM-LE Adresse mit den Operationen „add_Directory_FA-Attributes“ und "modify_Directory_FA-Attributes" 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 HTTP-Statuscode 400 (attributeName="mail" , attributeError="erläuternder Fehlertext") antworten und darf die Operation nicht ausführen.
[<=]
4.3.3 Operation delete_Directory_FA-Attributes
Diese Operation löscht einen Fachdatensatz.
TIP1-A_5595 - VZD, Umsetzung delete_Directory_FA-Attributes
Der VZD MUSS nach folgenden Vorgaben die Operation delete_Directory_ FA-Attributes implementieren:
- 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. - Ein zur Telematik-ID gehörender Fachdatensatz wird gelöscht.
- Ein nicht existierender Fachdatensatz zur Telematik-ID führt zu keiner Aktion.
Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0008 verwendet werden.
[<=]
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 1617: 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. |
|
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. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS). |
|
[<=]
TIP1-A_5597 - VZD, Umsetzung delete_Directory_FA-Attributes (LDAPv3)
Der VZD MUSS nach folgenden Vorgaben die Operation delete_Directory_FA-Attributes implementieren:
- Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request beendet.
- Ein zur Telematik-ID gehörender Fachdatensatz wird gelöscht.
- Ein nicht existierender Fachdatensatz zur Telematik-ID führt zu keiner Aktion.
- 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.
[<=]
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 1718: 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. |
|
[<=]
A_21460 - VZD, Umsetzung delete_Directory_FA-Attributes (REST)
Der VZD MUSS nach folgenden Vorgaben die Operation delete_Directory_ FA-Attributes implementieren:
- Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einem HTTP-Statuscode beendet:
HTTP-Statuscode: 404 - Ein zur Telematik-ID gehörender Fachdatensatz wird gelöscht.
- Ein nicht existierender Fachdatensatz zur Telematik-ID führt zu keiner Aktion und HTTP-Statuscode: 404 im Response.
[<=]
A_21461 - FAD, TUC_VZD_0013 “delete_Directory_FA-Attributes (REST)”
Der FAD MUSS den technischen Use Case TUC_VZD_0013 “delete_Directory_FA-Attributes” gemäß Tabelle Tab_TUC_VZD_0013 umsetzen.
Tabelle 3219: Tab_TUC_VZD_0013
Name |
delete_Directory_FA-Attributes |
|
Beschreibung |
Mit dieser Operation wird ein Fachdaten-Eintrag gelöscht. |
|
Vorbedingungen |
Keine. |
|
Eingangsdaten |
REST-Request „delete_Directory_FA-Attributes“ |
|
Komponenten |
VZD, FAD |
|
Ausgangsdaten |
REST-Response |
|
Standardablauf |
Aktion |
Beschreibung |
Aufbau TLS-Verbindung |
Falls noch keine TLS-Verbindung besteht, wird eine aufgebaut. |
|
REST-Request senden |
Der FAD ruft die REST-Operation delete_Directory_FA-Attributes auf. |
|
REST-Response empfangen |
Die REST-Response enthält den HTTP-Statuscode. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS). |
|
[<=]
4.3.4 Operation modify_Directory_FA-Attributes
Diese Operation überschreibt einen Fachdatensatz.
TIP1-A_5599 - VZD, Umsetzung modify_Directory_FA-Attributes
Der VZD MUSS nach folgenden Vorgaben die Operation modify_Directory_ FA-Attributes implementieren:
- 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. - Ein bereits zur Telematik-ID gehörender Fachdatensatz wird überschrieben.
- Die Daten aus dem SOAP Request werden gemäß VZD_TAB_I_Directory_Application_Maintenance_Modify_Mapping zum Basisdatensatz hinzugefügt.
Tabelle 1820: VZD_TAB_I_Directory_Application_Maintenance_Modify_Mapping
SOAP-Request Element |
LDAP-Directory |
VZD:timestamp |
wird nicht in das LDAP-Directory eingetragen |
VZD:Telematik-ID |
|
<FA-Attributes> |
fachdienstspezifische Attribute. |
Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0010 verwendet werden. [<=]
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 1921: 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. |
|
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. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS). |
|
[<=]
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 2022: VZD_TAB_KOM-LE_Attributes
SOAP-Request Element |
LDAP-Directory |
VZD:timestamp |
wird nicht in das LDAP-Directory eingetragen |
VZD:telematikID |
|
VZD:KOM-LE-EMail-Address |
|
VZD:version |
KOM-LE-Version |
[<=]
TIP1-A_5602 - VZD, Umsetzung modify_Directory_FA-Attributes (LDAPv3)
Der VZD MUSS nach folgenden Vorgaben die Operation modify_Directory_FA-Attributes implementieren:
- Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request beendet.
- Ein bereits zur Telematik-ID gehörender Fachdatensatz wird geändert.
- Der FAD darf nur die zu seinem Dienst gehörenden Fachdaten ändern.
Es müssen die Fehlermeldungen gemäß Tab_TUC_VZD_0011 verwendet werden.
[<=]
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 2123: 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. |
|
[<=]
A_21462 - VZD, Umsetzung modify_Directory_FA-Attributes (REST)
Der VZD MUSS nach folgenden Vorgaben die Operation modify_Directory_ FA-Attributes implementieren:
- Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einem HTTP-Statuscode beendet:
HTTP-Statuscode: 404 - Ein bereits zur Telematik-ID gehörender Fachdatensatz (FADx in Abb_VZD_logisches_Datenmodell) des authentifizierten Fachdienstanbieters wird überschrieben.
- Ein nicht existierender Fachdatensatz zur Telematik-ID führt zu keiner Aktion und HTTP-Statuscode: 404 im Response.
[<=]
A_21463 - FAD, TUC_VZD_0014 “modify_Directory_FA-Attributes (REST)”
Der FAD MUSS den technischen Use Case TUC_VZD_0014 “modify_Directory_FA-Attributes” gemäß Tabelle Tab_TUC_VZD_0014 umsetzen.
Tabelle 3324: Tab_TUC_VZD_0014
Name |
modify_Directory_FA-Attributes |
|
Beschreibung |
Mit dieser Operation wird ein Fachdaten-Eintrag geändert. |
|
Vorbedingungen |
Keine. |
|
Eingangsdaten |
REST-Request „modify_Directory_FA-Attributes“ |
|
Komponenten |
VZD, FAD |
|
Ausgangsdaten |
REST-Response |
|
Standardablauf |
Aktion |
Beschreibung |
Aufbau TLS-Verbindung |
Falls noch keine TLS-Verbindung besteht, wird eine aufgebaut. |
|
REST-Request senden |
Der FAD ruft die REST-Operation modify_Directory_FA-Attributes auf. |
|
REST-Response empfangen |
Die REST-Response enthält den HTTP-Statuscode. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS). |
|
[<=]
4.3.5 Operation get_Directory_FA-Attributes
Diese Operation liest einen Fachdatensatz.
A_21464 - VZD, Umsetzung get_Directory_FA-Attributes (REST)
Der VZD MUSS nach folgenden Vorgaben die Operation get_Directory_FA-Attributes implementieren:
- Wenn kein zur Telematik-ID gehörender Basisdatensatz gefunden wurde, wird der Request mit einem HTTP-Statuscode beendet:
HTTP-Statuscode: 404 - Ein nicht existierender Fachdatensatz zur Telematik-ID führt zur Rückgabe von HTTP-Statuscode: 404 im Response.
[<=]
A_21465 - FAD, TUC_VZD_0015 “get_Directory_FA-Attributes (REST)”
Der FAD MUSS den technischen Use Case TUC_VZD_0015 “get_Directory_FA-Attributes” gemäß Tabelle Tab_TUC_VZD_0015 umsetzen.
Tabelle 3425: Tab_TUC_VZD_0015
Name |
get_Directory_FA-Attributes |
|
Beschreibung |
Mit dieser Operation wird ein Fachdaten-Eintrag gelesen. |
|
Vorbedingungen |
Keine. |
|
Eingangsdaten |
REST-Request „get_Directory_FA-Attributes“ |
|
Komponenten |
VZD, FAD |
|
Ausgangsdaten |
REST-Response mit den Fachdaten |
|
Standardablauf |
Aktion |
Beschreibung |
Aufbau TLS-Verbindung |
Falls noch keine TLS-Verbindung besteht, wird eine aufgebaut. |
|
REST-Request senden |
Der FAD ruft die REST-Operation get_Directory_FA-Attributes auf. |
|
REST-Response empfangen |
Die REST-Response enthält den HTTP-Statuscode und die Fachdaten. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS). |
|
[<=]
Diese Operation liest einen die Liste aller Anwendungskennzeichen (appTags).
A_24007 - VZD, Umsetzung appTags (REST)
Der VZD MUSS nach folgenden Vorgaben die Operation appTags implementieren:
- Der VZD muss seine Liste der zulässigen appTags periodisch aus simplifier aktualisieren.
- Die Periode für die appTags Aktualisierung muss konfigurierbar sein.
- Als Response der Operation appTags gibt der VZD die aktuelle, vollständige Liste der appTags (Anwendungskennzeichen) zurück.
[<=]
A_24008 - FAD, TUC_VZD_0016 “appTags (REST)”
Der FAD MUSS den technischen Use Case TUC_VZD_0016 “TUC_VZD_0016” gemäß Tabelle Tab_TUC_VZD_0016 umsetzen.
Tabelle 3426: Tab_TUC_VZD_0016
Name |
appTags |
|
Beschreibung |
Mit dieser Operation wird die Liste aller Anwendungskennzeichen (appTags) gelesen. |
|
Vorbedingungen |
Keine. |
|
Eingangsdaten |
REST-Request „appTags“ |
|
Komponenten |
VZD, FAD |
|
Ausgangsdaten |
REST-Response mit den appTags |
|
Standardablauf |
Aktion |
Beschreibung |
Aufbau TLS-Verbindung |
Falls noch keine TLS-Verbindung besteht, wird eine aufgebaut. |
|
REST-Request senden |
Der FAD ruft die REST-Operation get_appTags auf. |
|
REST-Response empfangen |
Die REST-Response enthält den HTTP-Statuscode und die Liste der appTags. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS). |
|
[<=]
4.4 Prozessschnittstelle P_Directory_Application_Registration (Provided)
TIP1-A_5604 - VZD, Registrierung FADs
Der Anbieter des VZD MUSS einen Registrierungsprozess für FAD implementieren. Der Anbieter des VZD MUSS dazu überprüfen:
- Gültigkeit des TLS-Client-Zertifikat des FADs C.FD.TLS-C (Prüfschritte wie in TUC_PKI_018 und mit admission gemäß vom GTI vorgegebener OID-Liste ),
- Name der Fachanwendung (z.B. KOM-LE),
- Name des Fachdienstbetreibers.
Der VZD-Anbieter dokumentiert den Prozess und legt ihn dem GTI zur Freigabe vor.
Der Anbieter des VZD informiert alle FAD-Anbieter darüber, wie der Prozess genutzt wird.
[<=]
TIP1-A_5605 - VZD, De-Registrierung FADs
Der Anbieter des VZD MUSS einen Deregistrierungsprozess für FAD implementieren.
Der VZD MUSS alle verbliebenen Fachdaten eines deregistrierten FAD löschen.
Der VZD-Anbieter dokumentiert den Prozess und legt ihn dem GTI zur Freigabe vor.
Der Anbieter des VZD informiert alle FAD-Anbieter wie der Prozess genutzt wird.
[<=]
4.5 Prozessschnittstelle P_Directory_Maintenance (Provided)
TIP1-A_5606 - VZD, Mandat zur Löschung von Einträgen.
Der Anbieter des VZD MUSS einen Prozess implementieren, der es LE ermöglicht ihren Eintrag im VZD ohne zugehörige Smartcard zu löschen.
Der Anbieter des VZD MUSS vom LE einen Nachweis fordern und prüfen, dass die zu löschenden Daten dem LE gehören. Erst nach positivem Ergebnis der Prüfung darf gelöscht werden.
Der VZD-Anbieter dokumentiert den Prozess und legt ihn dem GTI zur Freigabe vor.
[<=]
4.6 Schnittstelle I_Directory_Administration
Der Verzeichnisdienst (VZD) stellt ein Verzeichnis von Leistungserbringern und Organisationen/Institutionen mit den definierten Attributen für die Anwendungen der TI bereit. Zum Füllen und Administrieren dieser Daten durch die Kartenherausgeber wird die Schnittstelle I_Directory_Administration definiert.
Über diese Schnittstelle können Verzeichniseinträge inklusive Untereinträge für Zertifikate erzeugt, aktualisiert und gelöscht werden. Die Administration von Fachdaten erfolgt über die Schnittstelle I_Directory_Application_Maintenance und wird durch die Fachanwendungen durchgeführt. Operation getDirectoryEntries ermöglicht in der Schnittstelle I_Directory_Administration das Lesen eines gesamten Verzeichniseintrags inklusive Zertifikaten und Fachdaten.
Als Clients dieser Schnittstelle sind nur Systeme der TI-Kartenherausgeber und von ihnen berechtigte Organisationen (z.B. TSPs) zulässig. Sie dürfen alle Operationen zur Administration der Verzeichniseinträge nutzen.
Das ACCESS_Token enthält im "sub" claim den Identifier des Clients, der auf die Einträge zugreift. Dieser Identifier wird im Log abgelegt, welcher die Zugriffe über diese Schnittstelle protokolliert.
4.6.1 Operationen der Schnittstelle I_ Directory_Administration
Die – über diese REST Schnittstelle administrierten – Ressourcen werden entsprechend dem logischen Datenmodell des VZD (siehe Abb_VZD_logisches_Datenmodell) in DirectoryAdministration.yaml definiert.
A_18371-04 - VZD, Schnittstelle I_Directory_Administration
Der VZD MUSS die Schnittstelle I_Directory_Administration gemäß Tabelle Tab_VZD_Schnittstelle_I_Directory_Administration im Internet anbieten.
Tabelle 2227: Tab_VZD_Schnittstelle_I_Directory_Administration
Name |
I_Directory_Administration |
|
Version |
wird im Produkttypsteckbrief des VZD definiert |
|
Operationen |
Resource: / (übergreifend für gesamte Schnittstelle) |
|
Name |
Kurzbeschreibung |
|
GET |
Lesen der Metadaten dieser Schnittstelle |
|
Resource: DirectoryEntry |
||
Name |
Kurzbeschreibung |
|
POST |
Hinzufügen eines Verzeichniseintrages inklusive dazugehörendem Zertifikat. |
|
GET |
Abfrage aller Daten von Verzeichniseinträgen. |
|
PUT |
Änderung eines Basisdaten-Verzeichniseintrages. |
|
DELETE |
Löschung eines Verzeichniseintrages (kompletter Datensatz inklusive aller Zertifikate und Fachdaten). |
|
Resource: /DirectoryEntriesSync |
||
Name |
Kurzbeschreibung |
|
GET |
Abfrage aller Daten von Verzeichniseinträgen zu Synchronisationszwecken. |
|
Resource: Certificate |
||
Name |
Kurzbeschreibung |
|
POST |
Hinzufügen eines Zertifikatseintrags zu einem Verzeichniseintrag. |
|
GET |
Abfrage von Zertifikatseinträgen. |
|
DELETE |
Löschen von Zertifikatseinträgen. |
|
[<=]
A_18373 - VZD, Schnittstelle I_Directory_Administration
Der VZD MUSS die Schnittstelle I_Directory_Administration als REST-Webservice über HTTPS implementieren. Der Webservice wird durch das Dokument DirectoryAdministration.yaml definiert.
[<=]
A_18408 - VZD, I_Directory_Administration, Registrierung
Der VZD-Anbieter MUSS für Clients der Schnittstelle I_Directory_Administration einen Registrierungsprozess bereitstellen. Während der Registrierung muss die Berechtigung des Antragstellers (Clients) zur Nutzung von Schnittstelle I_Directory_Administration durch den VZD-Anbieter geprüft und durch die gematik bestätigt werden. Nach erfolgreicher Registrierung MÜSSEN dem Antragsteller alle nötigen Daten - inklusive OAuth Client Credentials, CA-Zertifikat (welches zur Prüfung des Serverzertifikats durch den Client benötigt wird), VZD-Serverzertifikat - zur Nutzung der Schnittstelle bereitgestellt werden.
Der VZD-Anbieter MUSS die erfolgreich registrierten Clients immer mit aktuellen Zertifikaten versorgen.
[<=]
A_20267 - VZD, I_Directory_Administration, Registrierung beim IdP als Relying Party
Der Anbieter des VZD MUSS sich über einen organisatorischen Prozess bei einem vertrauenswürdigen Identity Provider (IDP) der Telematikinfrastruktur als Relying Party registrieren und die Bereitstellung der folgenden Claims in für Nutzer ausgestellte ACCESS_TOKEN mit dem IDP vereinbaren:
- name
- sub
- scope
- acr
damit der VZD die Fachlogik der Autorisierung und Protokollierung auf diesen Attributen umsetzen kann.
[<=]
A_20268 - VZD, Authentifizierung Nutzerrolle
Der VZD MUSS die fachliche Rolle eines Nutzers in jedem Operationsaufruf der Schnittstelle I_Directory_Administration anhand des Attributs "scope" im übergebenen ACCESS_TOKEN feststellen und für die nachfolgende Rollenprüfung je Operationsaufruf verwenden. [<=]
A_20269 - VZD, Authentifizierung Nutzername
Der VZD MUSS den Namen eines Nutzers in jedem Operationsaufruf anhand des Attributs "name" im übergebenen ACCESS_TOKEN feststellen und für die Protokollierung des Zugriffs verwenden. [<=]
A_18470 - VZD, I_Directory_Administration, Client Secret Qualität
Der VZD-Anbieter MUSS bei der Erzeugung der OAuth client_secret‘s 128 Bit Zufall aus einer Zufallsquelle gemäß GS-A_4367 [gemSpec_Krypt] verwenden.
[<=]
A_18409 - VZD, I_Directory_Administration, Sperrung OAuth Client Credentials
Der VZD-Anbieter MUSS – für die gematik und den Client-Betreiber selbst - einen Service zur Sperrung der OAuth Client Credentials anbieten.
[<=]
A_18372 - VZD, I_Directory_Administration, TLS-gesicherte Verbindung
Der VZD MUSS die Schnittstelle I_Directory_Administration durch Verwendung von TLS mit serverseitiger Authentisierung sichern.
Der VZD MUSS für diese TLS-Verbindungen öffentliche Zertifikate nutzen (keine TI-Zertifikate).
Der VZD MUSS sich mit der Server-Identität von Schnittstelle I_Directory_Administration authentisieren.
[<=]
Die Prüfung der öffentliche TLS-Server Zertifikate muss gemäß GS-A_5581 [gemSpec_Krypt] erfolgen. Dabei müssen in (1) von GS-A_5581 statt der "Komponenten-CA-Zertifikate der TI" die CA-Zertifikate der Schnittstelle I_Directory_Administration genutzt werden.
A_18374 - VZD, I_Directory_Administration, Redirect
Der VZD MUSS für die Schnittstelle I_Directory_Administration Anfragen der Clients – welche kein AccessToken entsprechend [RFC 6750] enthalten – durch ein Redirect zu dem OAuth2-Authentifizierungsdienst weiterleiten. [<=]
A_18375 - VZD, I_Directory_Administration, OAuth2 Dienst
Der VZD MUSS einen OAuth2-Dienst bereitstellen. Dieser Dienst MUSS die Clients der Schnittstelle I_Directory_Administration anhand ihrer Client Credentials authentisieren und ihnen ein AccessToken entsprechend [RFC 6750] ausstellen. Das AccessToken muss im "sub" claim den Identifier des Clients enthalten. Die Anfrage des Clients MUSS nach erfolgreicher Authentisierung durch ein Redirect wieder zur VZD I_Directory_Administration Schnittstelle weitergeleitet werden.
[<=]
A_18376 - VZD, I_Directory_Administration, Prüfung AccessToken
Der VZD MUSS das vom Client übergebene AccessToken auf Gültigkeit für Schnittstelle I_Directory_Administration prüfen. Bei negativem Ergebnis muss die Operation mit HTTP Fehler 401 Unauthorized abgebrochen werden.
[<=]
A_18471-01 - VZD, I_Directory_Administration, Datenquelle
Der VZD MUSS bei den Operationen add_Directory_Entry und modify_Directory_Entry das LDAP-Directory-Attribut dataFromAuthority auf den Wert TRUE setzen und bei allen anderen Operationen unverändert belassen.
[<=]
A_18735 - VZD, Disable I_Directory_Maintenance, wenn dataFromAuthority TRUE
Der VZD DARF Änderungen an VZD-Einträgen über die Schnittstelle I_Directory_Maintenance NICHT zulassen, wenn an dem betroffenen VZD-Eintrag das Attribut dataFromAuthority auf TRUE gesetzt ist.
[<=]
A_18472-01 - VZD, I_Directory_Administration, Doubletten
Der VZD MUSS bei den Operationen add_Directory_Entry und modify_Directory_Entry prüfen, ob die Operation eine Doublette im LDAP-Verzeichnis erzeugt und in diesem Fall die Operation mit HTTP-Fehlercode “400 Bad Request“ ablehnen. Zur Prüfung auf eine potentielle Dublette MUSS der VZD alle LDAP-Directory-Attribute des zu erzeugenden Basisdatensatzes (Verzeichnisdienst_Eintrag ohne Certificate und Fachdaten) jedoch ohne den Distinguished Name heranziehen.
[<=]
A_18602 - VZD, I_Directory_Administration, keine Datenänderung über Maintenance Schnittstelle
Der VZD MUSS Änderungen an Basisdatensätzen und Zertifikatseinträgen (Certificate in Abb_VZD_logisches_Datenmodell) über andere Schnittstellen verhindern, wenn für den jeweiligen Eintrag Daten über die Schnittstelle I_Directory_Administration eingetragen wurden (LDAP-Directory Attribut dataFromAuthority == TRUE).
Nicht erlaubte Änderungen MUSS der VZD mit faultcode 4202 (faultstring: SOAP Request enthält Fehler) ablehnen. [<=]
A_23126 - VZD, I_Directory_Administration, Registrierung, Nutzerrolle
Der VZD-Anbieter MUSS für Clients der Schnittstelle I_Directory_Administration im Registrierungsprozess die Auswahl der Nutzerrolle erlauben:
- VZD:DirectoryRead (Erlaubt nur die Nutzung der GET Operationen der Schnittstelle)
- VZD:DirectoryAdministration (Erlaubt die Nutzung aller Operationen der Schnittstelle)
[<=]
4.6.1.1 I_Directory_Administration - Lesen der Metadaten
Über Operation getInfo können die Metadaten der Schnittstelle I_Directory_Administration gelesen werden.
Diese Operation liefert die Metadaten der Schnittstelle I_Directory_Administration.
A_21786 - VZD, I_Directory_Administration, getInfo
Der VZD MUSS Operation „getInfo” gemäß Tabelle Tab_VZD „I_Directory_Administration-Info” umsetzen.
Tabelle 2328: Tab_VZD „I_Directory_Administration-getInfo”
Name |
getInfo |
|
Beschreibung |
Liefert die Metadaten (unter anderem aus dem InfoObject) dieser OpenAPI Spezifikation. |
|
Eingangsdaten |
REST-Request GET / |
|
Parameter |
Beschreibung |
|
keine |
- |
|
Komponenten |
Nutzer der Schnittstelle |
|
Ausgangsdaten |
REST-Response mit Metadaten (InfoObject). |
|
Ablauf |
Der VZD liefert die Metadaten der Schnittstelle in der Datenstruktur InfoObject zurück. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) und in DirectoryAdministration.yaml mit spezifischen Fehlerbeschreibungen ergänzt. |
|
[<=]
A_21789-01 - VZD, Umsetzung I_Directory_Administration (REST)
Der VZD MUSS nach folgenden Vorgaben die Operation implementieren:
In den Rückgabewerten müssen die aktuell gültigen Metainformationen für Schnittstelle I_Directory_Administration zurückgegeben werden. Insbesondere muss
- der Parameter version die aktuelle Version der Schnittstelle enthalten (entspricht info.version der Schnittstellendefinition DirectoryAdministration.yaml)
- der Parameter title den Titel der Schnittstelle enthalten (entspricht info.title der Schnittstellendefinition DirectoryAdministration.yaml
- der Parameter description eine Kurzbeschreibung der Schnittstelle, die Produktversion und einen Link zur aktiven YAML-Datei enthalten.
[<=]
4.6.1.2 DirectoryEntry Administration
Die Pflege der Basiseinträge (Verzeichnisdienst_Eintrag) erfolgt mit den im Folgenden beschriebenen Operationen.
Diese Operation legt einen neuen Eintrag im LDAP-Verzeichnis an.
A_18448 - VZD, I_Directory_Administration, add_Directory_Entry
Der VZD MUSS Operation „add_Directory_Entry” gemäß Tabelle Tab_VZD „add_Directory_Entry” umsetzen.
Tabelle 2429: Tab_VZD „add_Directory_Entry”
Name |
add_Directory_Entry |
|
Beschreibung |
Diese Operation ermöglicht die Erzeugung eines neuen Eintrags im LDAP-Verzeichnis. |
|
Eingangsdaten |
REST-Request POST /DirectoryEntries |
|
Parameter |
Beschreibung |
|
Verzeichnisdienst_Eintrag |
Siehe Abb_VZD_logisches_Datenmodell und Tab_VZD_Datenbeschreibung. |
|
Certificate |
Kann optional belegt werden. |
|
Komponenten |
Nutzer der Schnittstelle, Verzeichnisdienst |
|
Ausgangsdaten |
REST-Response mit dem Distinguished Name (dn) von dem Verzeichnisdienst_Eintrag. |
|
Ablauf |
Der VZD übernimmt entsprechend Tab_VZD_Datenbeschreibung Attribute aus dem Zertifikat und trägt die übergebenen Parameter in den Verzeichniseintrag ein. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) und in DirectoryAdministration.yaml mit spezifischen Fehlerbeschreibungen ergänzt. |
|
[<=]
A_20271-02 - VZD, I_Directory_Administration, add_Directory_Entry, holder setzen
Der VZD MUSS bei Operation „add_Directory_Entry” den Eigentümer des erzeugten Verzeichniseintrags im Attribut "holder" entsprechend folgenden Vorgaben setzen:
- Ist im add_Directory_Entry Request das Attribut "holder" nicht vorhanden oder enthält keine Werte:
- Wird vom VZD in dieses Attribut kein Wert (leeres Attribut) eingetragen.
- Ist im add_Directory_Entry Request das Attribut "holder" vorhanden und mit Inhalten gefüllt
- Ist ein Wert aus dem Request Attribut "holder" nicht gültig, MUSS der VZD die Operation mit HTTP-Status-Code 422 abweisen und die weitere Verarbeitung von diesem Request abbrechen.
- Sind alle Werte aus dem Request Attribut "holder" gültig, MUSS der VZD die Werte aus dem Request entnehmen und sie in das "holder" Attribut des Verzeichniseintrags übernehmen.
[<=]
Das Attribut "holder" wirkt für die Modifikationen der Basisdaten (die Prüfung des Attributs erfolgt nur für Operation modify_Directory_Entry), nicht auf Änderungen der Zertifikats- oder Fachdaten.
A_21791-01 - VZD, Prüfung auf Typ der Zertifikate
Der VZD MUSS beim Hinzufügen von Zertifikaten mit den Operationen „add_Directory_Entry” und "add_Directory_Entry_Certificate" den Typ der Zertifikate prüfen. Der VZD MUSS alle Operationen mit Zertifikaten ablehnen, die nicht vom Zertifikatstyp C.HCI.ENC oder C.HP.ENC (siehe [gemSpec_OID#Tab_PKI_405-01] sind oder nicht keyUsage = (!digitalSignature && keyEncipherment && dataEncipherment) (siehe [gemSpec_PKI]} GS-A_5532-01) gesetzt ist. Im Falle von unzulässigen Zertifikaten MUSS der VZD mit HTTP-Statuscode 422 (attributeName="userCertificate", attributeError="erläuternder Fehlertext") antworten und darf die gesamte Operation nicht ausführen. [<=]
A_21790-02 - VZD, Prüfung auf Gültigkeit der Zertifikate in der korrekten PKI-Umgebung
Der VZD MUSS beim Hinzufügen von Zertifikaten in der PKI-Umgebung PU mit den Operationen „add_Directory_Entry” und "add_Directory_Entry_Certificate" die Gültigkeit der Zertifikate für diese PKI-Umgebung (PU) prüfen (TUC_PKI_018 mit erfolgreichem Status der Prüfung mit Prüfparametern Offline-Modus=nein; Prüfmodus=OCSP; TOLERATE_OCSP_FAILURE=false ). Die Gültigkeit wird anhand der CA und Prüfung gegen PU-TSL durchgeführt. In der PKI-Umgebung PU dürfen nur die Zertifikate akzeptiert werden, die in dieser Umgebung gültig sind. Gültige Zertifikate aus anderen Umgebungen müssen abgelehnt werden. [<=]
A_21824 - VZD, I_Directory_Administration, stateOrProvinceName Prüfung
Der VZD MUSS vor Ausführung der Operationen „add_Directory_Entry” und "modify_Directory_Entry" den Inhalt von Parameter stateOrProvinceName des Operation Requests gegen die gültigen Werte entsprechend [gemILF_Pflege_VZD#Tabelle TAB_VZD_Wertebereiche_der_Attribute] prüfen, wenn es sich um eine deutsche Adresse handelt (countryCode = DE). Im Falle von ungültigen Werten MUSS der VZD mit HTTP-Statuscode 422 (attributeName="stateOrProvinceName" , attributeError="erläuternder Fehlertext") antworten und darf die Operation nicht ausführen. [<=]
Diese Operation liest Verzeichniseinträge aus dem LDAP-Verzeichnis.
A_18449-03 - VZD, I_Directory_Administration, read_Directory_Entry
Der VZD MUSS Operation „read_Directory_Entry” gemäß Tabelle Tab_VZD „read_Directory_Entry” umsetzen.
Tabelle 2530: Tab_VZD „read_Directory_Entry”
Name |
read_Directory_Entry |
|
Beschreibung |
Diese Operation ermöglicht die Suche und Lesen von Verzeichniseinträgen im LDAP-Verzeichnis. |
|
Eingangsdaten |
REST-Request GET /DirectoryEntries |
|
Parameter |
Beschreibung |
|
Parameter zur Selektion der Verzeichniseinträge |
Alle im Datenmodell aufgeführten Felder des Basiseintrags - insbesondere auch dataFromAuthority - können zur Suche genutzt werden. |
|
Komponenten |
Nutzer der Schnittstelle, Verzeichnisdienst |
|
Ausgangsdaten |
REST-Response mit allen zu den Filterparametern passenden Verzeichniseinträgen. Die Verzeichniseinträge werden optional inklusive Zertifikatseinträgen und Fachdaten geliefert. |
|
Ablauf |
Der VZD sucht im LDAP-Verzeichnis die zu den Suchparametern passenden Verzeichniseinträge. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) und in DirectoryAdministration.yaml mit spezifischen Fehlerbeschreibungen ergänzt. |
|
[<=]
Diese Operation aktualisiert den Verzeichniseintrag (ohne Zertifikate und Fachdaten) mit den übergebenen Daten im LDAP-Verzeichnis.
A_18450-0304 - VZD, I_Directory_Administration, modify_Directory_Entry
Der VZD MUSS Operation „modify_Directory_Entry” gemäß Tabelle Tab_VZD „modify_Directory_Entry” umsetzen.
Tabelle 2631: Tab_VZD „modify_Directory_Entry”
Name |
modify_Directory_Entry |
|||
Beschreibung |
Diese Operation ermöglicht die Aktualisierung von Verzeichniseinträgen im LDAP-Verzeichnis. |
|||
Eingangsdaten |
REST-Request PUT /DirectoryEntries/{uid}/baseDirectoryEntries |
|||
|
|
|
||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
Komponenten |
Nutzer der Schnittstelle, Verzeichnisdienst |
|||
Ausgangsdaten |
REST-Response mit dem Distinguished Name (dn) von dem aktualisierten Verzeichnisdienst_Eintrag. |
|||
Ablauf |
Der VZD aktualisiert im LDAP-Verzeichnis den über Parameter „uid“ identifizierten Verzeichniseintrag mit den übergebenen Parametern. |
|||
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) und in DirectoryAdministration.yaml mit spezifischen Fehlerbeschreibungen ergänzt. |
|||
[<=]
A_20272-03 - VZD, I_Directory_Administration, modify_Directory_Entry, Zugriffsrechte
Der VZD MUSS bei Operation „modify_Directory_Entry” für den - über Parameter uid adressierten - Verzeichniseintrag das Attribut "holder" im gespeicherten Verzeichniseintrag und die aktuellen Parameter ("holder" und ACCESS_TOKEN claim scope) der Operation „modify_Directory_Entry” prüfen:
- Wurde im Request Parameters "holder" ein Wert angegeben, der keinen aktuell gültigen Wert für Schnittstelle I_Directory_Administration entspricht, MUSS der VZD die Operation mit HTTP-Status-Code 422 abweisen.
- Wurde im Request Parameters "holder" ein leerer Wert angegeben, MUSS der VZD das Attribut "holder" des Verzeichniseintrags auf einen leeren Wert setzen.
- Ist im Attribut "holder" im gespeicherten Verzeichniseintrags mindestens ein Wert vorhanden
- MUSS der VZD die Operation auszuführen und die übergebenen Werte - nach Prüfung ihrer Gültigkeit - in den Verzeichniseintrag übernehmen wenn der Wert von dem ACCESS_TOKEN claim scope einem Wert des Attributs "holder" des gespeicherten Verzeichniseintrags entspricht. Ist dies nicht der Fall, MUSS der VZD die Operation mit HTTP-Status-Code 401 abweisen.
- Ist im Attribut "holder" im gespeicherten Verzeichniseintrags kein Wert vorhanden und
- in der Operation „modify_Directory_Entry” wurden Werte für dieses "holder" Attribut übergeben, MUSS der VZD die Operation ausführen und diese Werte - nach Prüfung ihrer Gültigkeit - in den Verzeichniseintrag übernehmen.
- in der Operation „modify_Directory_Entry” wurde kein Wert für dieses "holder" Attribut übergeben, MUSS der VZD die Operation ausführen und das Attribut "holder" des Verzeichniseintrags unverändert lassen.
[<=]
A_21823 - VZD, I_Directory_Administration, modify_Directory_Entry, Limit maxKOMLEadr
Der VZD MUSS bei Operation „modify_Directory_Entry” nach erfolgreicher Aktualisierung des VZD-Datensatzes die Anzahl der hinterlegten Mail-Adressen in den KOM-LE Fachdaten mit dem Wert von Attribut maxKOMLEadr vergleichen. Die Anzahl der hinterlegten mail Adressen in den KOM-LE Fachdaten, die den Wert von Attribut maxKOMLEadr übersteigen, MUSS der VZD im Responde der Operation im Header X-maxKOMLEadr-Limit zurückgeben.
[<=]
Beispiele
a) maxKOMLEadr (nach Ausführung des Updates) = 1
hinterlegte Mail-Adressen in den KOM-LE-Fachdaten = 1
Header im Response:
X-maxKOMLEadr-Limit: 0
b) maxKOMLEadr (nach Ausführung des Updates) = 1
hinterlegte Mail-Adressen in den KOM-LE-Fachdaten = 3
Header im Response:
X-maxKOMLEadr-Limit: 2
4.6.1.2.4 PUT - active Attribut
Diese Operation setzt das "active" Attribut des Verzeichniseintrags ohne Änderung anderer Attribute.
A_23180 - VZD, I_Directory_Administration, stateSwitch_Directory_Entry
Der VZD MUSS Operation „stateSwitch_Directory_Entry” gemäß Tabelle Tab_VZD „stateSwitch_Directory_Entry” umsetzen.
Tabelle 2732: Tab_VZD „stateSwitch_Directory_Entry”
Name |
stateSwitch_Directory_Entry |
|
Beschreibung |
Mit dieser Operation kann das Attribut "baseDirectoryEntry.active" des Verzeichniseintrags geändert werden. Dazu muss in der Operation nur das Attribut "active" des Basisdatensatzes angegeben werden. Alle anderen Attribute des VZD Eintrags bleiben unverändert. |
|
Eingangsdaten |
REST-Request PUT /DirectoryEntries/{uid}/active |
|
Parameter |
Beschreibung |
|
uid |
Die „uid“ identifiziert den Verzeichnisdienst_Eintrag (Abb_VZD_logisches_Datenmodell), welcher aktualisiert wird. |
|
active |
Kann optional angegeben werden und überschreibt den Wert im selektierten Verzeichniseintrag. |
|
Komponenten |
Nutzer der Schnittstelle, Verzeichnisdienst |
|
Ausgangsdaten |
REST-Response mit dem HTTP Status als Ergebnis der Operation. |
|
Ablauf |
Der VZD aktualisiert im LDAP-Verzeichnis den über Parameter „uid“ identifizierten Verzeichniseintrag mit den übergebenen Parameter "active". |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) und in DirectoryAdministration.yaml mit spezifischen Fehlerbeschreibungen ergänzt. |
|
[<=]
Diese Operation löscht den gesamten Verzeichniseintrag (inklusive Zertifikaten und Fachdaten).
A_18451 - VZD, I_Directory_Administration, delete_Directory_Entry
Der VZD MUSS Operation „delete_Directory_Entry” gemäß Tabelle Tab_VZD „delete_Directory_Entry” umsetzen.
Tabelle 2833: Tab_VZD „delete_Directory_Entry”
Name |
delete_Directory_Entry |
|
Beschreibung |
Diese Operation ermöglicht die Löschung von kompletten Verzeichniseinträgen (inklusive Zertifikaten und Fachdaten) im LDAP-Verzeichnis. |
|
Eingangsdaten |
REST-Request DELETE /DirectoryEntries/{uid} |
|
Parameter |
Beschreibung |
|
uid |
Die „uid“ identifiziert den Verzeichnisdienst_Eintrag (Abb_VZD_logisches_Datenmodell) welcher inklusive der dazu gehörenden Zertifikate und Fachdaten gelöscht wird. |
|
Komponenten |
Nutzer der Schnittstelle, Verzeichnisdienst |
|
Ausgangsdaten |
REST-Response. |
|
Ablauf |
Der VZD löscht im LDAP-Verzeichnis den über Parameter „uid“ identifizierten Verzeichniseintrag inklusive der dazu gehörenden Zertifikate und Fachdaten. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) und in DirectoryAdministration.yaml mit spezifischen Fehlerbeschreibungen ergänzt. |
|
[<=]
A_20273-01 - VZD, I_Directory_Administration, delete_Directory_Entry, Zugriffsrechte
Der VZD MUSS bei Operation „delete_Directory_Entry” für den - über Parameter uid adressierten - Verzeichniseintrag das Attribut "holder" im gespeicherten Verzeichniseintrag gegen die aktuellen Parameter der Operation „delete_Directory_Entry” prüfen:
- Enthalten die Werte des Attributs "holder" im gespeicherten Verzeichniseintrag den Wert von dem ACCESS_TOKEN claim scope, MUSS der VZD die Operation ausführen.
- Enthält das Attributs "holder" im gespeicherten Verzeichniseintrag keine Werte, MUSS der VZD die Operation ausführen.
- Enthalten die Werte des Attributs "holder" im gespeicherten Verzeichniseintrag nicht den Wert von dem ACCESS_TOKEN claim scope, MUSS der VZD die Operation mit HTTP-Status-Code 401 abweisen.
[<=]
Diese Operation liefert die Log Daten aller zum Filter passenden Verzeichniseinträge.
A_23181 - VZD, I_Directory_Administration, readLog
Der VZD MUSS Operation „readLog” gemäß Tabelle Tab_VZD „readLog” umsetzen.
Tabelle 2934: Tab_VZD „readLog”
Name |
readLog |
|
Beschreibung |
Liefert die - zum Filter passenden - Log Daten. Die angegebenen Parameter werden mit logischen UND verknüpft. |
|
Eingangsdaten |
REST-Request GET /Log |
|
Parameter |
Beschreibung |
|
uid |
Die „uid“ identifiziert den Verzeichnisdienst_Eintrag (Abb_VZD_logisches_Datenmodell), welcher aktualisiert wird. |
|
telematikID |
Erlaubt die Suche mit Hilfe des Attributs telematikID. |
|
holder |
Erlaubt die Suche mit Hilfe des Attributs holder. |
|
logTimeFrom |
Erlaubt die Suche mit Hilfe des Attributs logTime. |
|
logTimeTo |
Erlaubt die Suche mit Hilfe des Attributs logTime. |
|
operation |
Erlaubt die Suche anhand der ausgeführten Operation. |
|
noDataChanged |
Erlaubt die Suche nach Log Daten für Schreiboperationen, die keine Daten geändert haben. |
|
Komponenten |
Nutzer der Schnittstelle, Verzeichnisdienst |
|
Ausgangsdaten |
REST-Response mit den - zum Filter passenden - Log Daten. |
|
Ablauf |
Der VZD liest die - zum Filter passenden - Log Daten und gibt sie zurück. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) und in DirectoryAdministration.yaml mit spezifischen Fehlerbeschreibungen ergänzt. |
|
[<=]
4.6.1.3 Certificate Administration
Die Pflege der Zertifikatseinträge (Certificate in Abb_VZD_logisches_Datenmodell) erfolgt mit den im Folgenden beschriebenen Operationen.
Diese Operation fügt einem existierenden Basisdatensatz einen Zertifikatseintrag im LDAP-Verzeichnis an.
A_18452-01 - VZD, I_Directory_Administration, add_Directory_Entry_Certificate
Der VZD MUSS Operation „add_Directory_Entry_Certificate” gemäß Tabelle Tab_VZD „add_Directory_Entry_Certificate” umsetzen.
Tabelle 3035: Tab_VZD „add_Directory_Entry_Certificate”
Name |
add_Directory_Entry_Certificate |
|
Beschreibung |
Diese Operation fügt einem existierenden Basisdatensatz einen Zertifikatseintrag im LDAP-Verzeichnis an. |
|
Eingangsdaten |
REST-Request POST /DirectoryEntries/{uid}/Certificates |
|
Parameter |
Beschreibung |
|
uid |
Die „uid“ identifiziert den Verzeichnisdienst_Eintrag (Abb_VZD_logisches_Datenmodell) an welchen der Zertifikatseintrag angehangen wird. |
|
userCertificate |
Muss angegeben werden und enthält das Zertifikat. |
|
description |
Kann optional belegt werden. |
|
Komponenten |
Nutzer der Schnittstelle, Verzeichnisdienst |
|
Ausgangsdaten |
REST-Response mit dem Distinguished Name (dn) von dem erzeugten Certificate-Eintrag. |
|
Ablauf |
Der VZD übernimmt entsprechend Tab_VZD_Datenbeschreibung Attribute aus dem Zertifikat und trägt die übergebenen Parameter in den Zertifikatseintrag ein. Der Distinguished Name (dn) von dem erzeugten Certificate wird vom Verzeichnisdienst gefüllt und über dn.uid mit dem übergeordneten Verzeichnisdienst_Eintrag verknüpft. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) und in DirectoryAdministration.yaml mit spezifischen Fehlerbeschreibungen ergänzt. |
|
[<=]
Diese Operation liest Zertifikatseinträge aus dem LDAP-Verzeichnis.
A_18453-01 - VZD, I_Directory_Administration, read_Directory_Certificates
Der VZD MUSS Operation „read_Directory_Certificates” gemäß Tabelle Tab_VZD „read_Directory_Certificates” umsetzen.
Tabelle 3136: Tab_VZD „read_Directory_Certificates”
Name |
read_Directory_Certificates |
|
Beschreibung |
Diese Operation ermöglicht die Suche und das Lesen von Zertifikatseinträgen (Certificate in Abb_VZD_logisches_Datenmodell) im LDAP-Verzeichnis. |
|
Eingangsdaten |
REST-Request GET /DirectoryEntries/Certificates |
|
Parameter |
Beschreibung |
|
uid |
Optionaler Parameter. |
|
certificateEntryID |
Optionaler Parameter. |
|
telematikID |
Optionaler Parameter. |
|
Komponenten |
Nutzer der Schnittstelle, Verzeichnisdienst |
|
Ausgangsdaten |
REST-Response mit allen zu den Filter Parametern passenden Zertifikatseinträgen. |
|
Ablauf |
Der VZD sucht im LDAP Verzeichnis die zu den Such-Parametern passenden Zertifikatseinträge. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) und in DirectoryAdministration.yaml mit spezifischen Fehlerbeschreibungen ergänzt. |
|
[<=]
Diese Operation löscht einen Zertifikatseintrag.
A_18455 - VZD, I_Directory_Administration, delete_Directory_Entry_Certificate
Der VZD MUSS Operation „delete_Directory_Entry_Certificate” gemäß Tabelle Tab_VZD „delete_Directory_Entry_Certificate” umsetzen.
Tabelle 3237: Tab_VZD „delete_Directory_Entry_Certificate”
Name |
delete_Directory_Entry_Certificate |
|
Beschreibung |
Diese Operation ermöglicht die Löschung eines Zertifikatsseintrags im LDAP-Verzeichnis. |
|
Eingangsdaten |
REST-Request |
|
Parameter |
Beschreibung |
|
uid |
Pflichtparameter. |
|
certificateEntryID |
Pflichtparameter. |
|
Komponenten |
Nutzer der Schnittstelle, Verzeichnisdienst |
|
Ausgangsdaten |
REST-Response. |
|
Ablauf |
Der VZD löscht im LDAP-Verzeichnis den über die Parameter „uid“ und „certificateEntryID“ identifizierten Zertifikatseintrag. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) und in DirectoryAdministration.yaml mit spezifischen Fehlerbeschreibungen ergänzt. |
|
[<=]
4.6.1.4 DirectoryEntry Synchronization
Zur Unterstützung der Pflege der Basiseinträge (Verzeichnisdienst_Eintrag) wird die hier beschriebene Operation zur Verfügung gestellt. Sie dient der Synchronisation mit dem Datenbestand des Verzeichnisdienstes und erlaubt – im Gegensatz zur Operation „read_Directory_Entry” – das Lesen beliebig vieler eigener Verzeichniseinträge.
A_21230-03 - VZD, I_Directory_Administration, read_Directory_Entry_for_Sync
Der VZD MUSS Operation „read_Directory_Entry_for_Sync” gemäß Tabelle Tab_VZD „read_Directory_Entry_for_Sync” umsetzen.
Tabelle 3338: Tab_VZD „read_Directory_Entry_for_Sync”
Name |
read_Directory_Entry_for_Sync |
|
Beschreibung |
Diese Operation ermöglicht die Suche und Lesen von Verzeichniseinträgen im LDAP-Verzeichnis. |
|
Eingangsdaten |
REST-Request GET /DirectoryEntries |
|
Parameter |
Beschreibung |
|
Parameter zur Selektion der Verzeichniseinträge |
Alle im Datenmodell aufgeführten Felder des Basiseintrags - insbesondere auch dataFromAuthority - können zur Suche genutzt werden. |
|
Komponenten |
Nutzer der Schnittstelle, Verzeichnisdienst |
|
Ausgangsdaten |
REST-Response mit allen zu den Filterparametern passenden Verzeichniseinträgen. Die Verzeichniseinträge werden optional inklusive Zertifikatseinträgen und Fachdaten geliefert. |
|
Ablauf |
Der VZD sucht im LDAP-Verzeichnis die zu den Suchparametern passenden Verzeichniseinträge. |
|
Fehlerfälle |
Es werden die protokollspezifischen Fehlermeldungen verwendet (TCP, HTTP, TLS) und in DirectoryAdministration.yaml mit spezifischen Fehlerbeschreibungen ergänzt. |
|
[<=]
A_20402-02 - VZD, I_Directory_Administration, read_Directory_Entry_for_Sync, Paging, Berechtigung
Der VZD MUSS für den Paging Mechanismus von Operation „read_Directory_Entry_for_Sync” sicherstellen:
- Der "holder" Suchparameter muss den gleichen Wert enthalten wie der ACCESS_TOKEN claim scope.
- Die pagingSize darf die Maximalgröße entsprechend TIP1-A_5552 nicht überschreiten.
- Die Suchparameter dürfen sich während eines Pagings (mit mehreren Request/Response Sequenzen) nicht ändern (nur das "cookie" ändert sich).
Bei Abweichungen von diesen Festlegungen MUSS der VZD mit einem Fehler (HTTP-Status-Code 403) antworten.
[<=]
4.6.2 Nutzung der Schnittstelle I_Directory_Administration
Der Client der Schnittstelle I_Directory_Administration muss eine TLS-Verbindung mit serverseitiger Authentisierung nutzen. Dabei muss er das Serverzertifikat des VZD prüfen. Bei negativem Ergebnis muss der Verbindungsaufbau abgebrochen werden.
Mit Hilfe der Operationen der Schnittstelle muss der Client die Verzeichniseinträge eintragen und pflegen.
Beispielablauf:
Falls die „uid“ des Verzeichniseintrags nicht bekannt ist erfolgt die Suche nach einem vorhandenen Verzeichniseintrag mit der telematikID (operationId read_Directory_Certificates mit Parameter telematikID)
a. Falls ein Eintrag gefunden wurde:
1. Lesen des Basis-Verzeichniseintrags (operationId read_Directory_Entry mit Parameter „uid“ aus dem read_Directory_Certificates Response)
2. Aktualisieren des Verzeichniseintrags und (je nach Bedarf) der dazugehörigen Zertifikatseinträge (operationId‘s: modify_Directory_Entry, delete_Directory_Entry, modify_Directory_Entry_Certificate, delete_Directory_Entry_Certificate)
b. Falls kein Eintrag gefunden wurde:
1. Erzeugen des Verzeichniseintrags und (je nach Bedarf) anhängen zusätzlicher Zertifikatseinträge (operationId‘s: add_Directory_Entry, add_Directory_Entry_Certificate). Der erste Zertifikatseintrag wird mit Operation add_Directory_Entry erzeugt da jeder Verzeichniseintrag mindestens einen Zertifikatseintrag enthalten muss. Zusätzliche Zertifikatseinträge können mit Operation add_Directory_Entry_Certificate hinzugefügt werden.
4.6.3 Zusammenführung mehrerer TelematikID´s zu einer Organisation
Im LDAP VZD existieren Einträge, die in der Realität eine Organisation darstellen, als einzelne Datensätze. Es haben z.B. Krankenhäuser unterschiedliche Einträge für ihre einzelnen Abteilungen im LDAP VZD. Für jeden dieser LDAP Einträge wird im FHIR VZD eine eigene Organisation generiert.
Entsprechende LDAP Einträge sollen als eine Organisation im VZD FHIR zusammengeführt werden. Damit sollen den VZD Nutzern die zusammengehörenden LDAP VZD Einträge im FHIR VZD als eine Organisation angezeigt werden.
Die Administration zusammengehörender Einträge erfolgt über Schnittstelle I_Directory_Administration.
Dafür wird das Attribut "providedBy" genutzt:
- Ist Attribut "providedBy" im LDAP VZD Eintrag nicht gesetzt, wird für den LDAP Eintrag im FHIR VZD eine Organisation generiert.
- Wird in Attribut "providedBy" im LDAP VZD Eintrag eine TelematikID eingetragen, wird für den LDAP Eintrag im FHIR VZD ein HealthcareService unter der - mit der TelematikID - referenzierten Organisation generiert.
A_24058 - VZD, I_Directory_Administration, providedBy
Der VZD MUSS für die Administration von Attribut "providedBy" gewährleisten:
- Es wird nur eine Hierarchieebene unterstützt. Das Attribut "providedBy" im referenzierten LDAP Datensatz muss deshalb leer sein. In allen anderen Fälle MUSS der VZD mit einem Fehler antworten.
- Der VZD MUSS bei Löschung eines LDAP VZD Eintrags prüfen, ob dieser Eintrag über Attribut "providedBy" von einem anderen Datensatz referenziert wird. Ist dies der Fall, MUSS der VZD die Löschoperation mit einem Fehler ablehnen.
- Das Attribut "providedBy" darf nur eine TelematikID enthalten.
- Wenn Attribut providedBy gesetzt wurde, kann es nur zurückgesetzt (Inhalt auf leer gesetzt) werden. Eine Änderung auf einen anderen Wert wird nicht unterstützt.
- Der VZD MUSS vor dem Setzen von Attribut "providedBy" prüfen, ob der Client auch für den referenzierten LDAP Datensatz als Holder eingetragen ist. Ist dies nicht der Fall, MUSS der VZD die Operation mit einem Fehler ablehnen.
[<=]
A_24059 - VZD, I_Directory_Administration, Synchronisationsregeln für verlinkte LDAP Datensätze
Der VZD MUSS für verlinkte LDAP Datensätze - mit einer TelematikID in Attribut "providedBy" - bei der Synchronisation der LDAP Daten in den FHIR VZD - abweichend von den normalen Synchronisationsregeln - das Mapping der Attribute entsprechend Tab_VZD_Datenmapping_linked durchführen.
Tabelle 39: Tab_VZD_Datenmapping_linked
LDAP Attribut |
FHIR HealthcareServices Attribut |
Bemerkung |
displayName |
name |
Wird für normale Einträge in organization.name gemappt, hier auf HealthcareService.name. |
organization |
- |
Kann einen alternativen Namen enthalten. |
specialization |
speciality |
Mapping auf HealthcareServices.specialty |
domainID |
identifier |
Wird normalerweise auf Organization.identifier gemappt. |
streetAddress, postalCode, countryCode, localityName, stateOrProvinceName |
Location |
Normales Mapping auf Location Attribute und Verlinkung der Location mit dem HealthcareService. |
holder |
- |
Wird nicht in den HelathcareService gemappt. |
telematikID |
identifier |
Wird normalerweise auf Organization.identifier gemappt. |
professionOID |
type |
Wird normalerweise in Organization.type abgelegt. |
active |
- |
Wird nicht in den HelathcareService gemappt. |
[<=]
Änderungen an "providedBy" werden - zusammen mit allen anderen Änderungen - asynchron in den VZD-FHIR synchronisiert. Im Regelfall erfolgt die Übernahme in den FHIR-VZD innerhalb von 5 Minuten.
Wenn "providedBy" gesetzt wird: Im FHIR-VZD wird der HealthcareService der Unterorganisation mit der Organization-Ressource der Hauptorganisation verlinkt und seine Attribute entsprechend dem Mapping Tab_VZD_Datenmapping_linked aktualisiert. Die Organization-Ressource der untergeordneten Organisation wird gelöscht. Die - durch die gematik definierten - Attribute dieser Organization-Ressource sind durch den Owner der Ressource im FHIR-VZD nicht änderbar. Die mit dem HealthcareService verlinkten Ressourcen bleiben erhalten und verlinkt (außer der Oranization).
Wenn "providedBy" geleert wird: Im FHIR-VZD wird für die "ehemalige" Unterorganisation wieder eine Organization-Ressource aus den LDAP-Daten generiert und mit dem HealthcareService der Unterorganisation verlinkt. Die Attribute des HealthcareService werden entsprechend dem normalen Mapping aktualisiert. Die mit dem HealthcareService verlinkten Ressourcen bleiben erhalten und verlinkt (außer der Änderung der Verlinkung mit der Oranization).
Hinweis: Diese Funktionalität dient der Zusammenführung von verschiedenen LDAP-Einträgen, die eigentlich zur gleichen Organisation gehören. Die "normale" Unterstrukturierung von Organisationen erfolgt im FHIR-VZD über die Owner-Schnittstelle.
5 Datenmodell
TIP1-A_5607-1011 - VZD, logisches Datenmodell
Der VZD MUSS das logische Datenmodell nach Abb_VZD_logisches_Datenmodell und Tab_VZD_Datenbeschreibung implementieren. Es wird keine Vorgabe an die technische Ausprägung des Datenmodells gemacht.
Der VZD MUSS sicherstellen, dass ein Eintrag nur Zertifikate aus dem Vertrauensraum der TI mit gleicher Telematik-ID enthält.
Abbildung 2: Abb_VZD_logisches_Datenmodell
Tabelle 3440: Tab_VZD_Datenbeschreibung
LDAP-Directory Attribut |
Pflichtfeld? |
Erläuterung |
givenName |
optional |
HBA-Eintrag: Bezeichner: Vorname, Wird vom VZD aus dem Zertifikatsattribut givenName übernommen, wenn der Client von Schnittstelle I_Directory_Administration keinen Wert angibt. |
sn |
optional |
Wird von E-Mail-Clients für die Suche nach Einträgen und die Anzeige von gefundenen Einträgen verwendet.
SMC-B Eintrag:
|
cn |
obligatorisch |
Wird von E-Mail Clients für die Suche nach Einträgen und die Anzeige von gefundenen Einträgen verwendet |
displayName |
optional |
Bezeichner: Anzeigename, Name, nach dem der Eintrag von Nutzern gesucht wird, und unter dem gefundene Einträge angezeigt werden. |
streetAddress |
optional |
Bezeichner: Straße und Hausnummer |
postalCode |
optional |
Bezeichner: Postleitzahl |
countryCode |
obligatorisch |
Kann beim Anlegen des Datensatzes und beim Ändern gesetzt werden (falls nicht gesetzt, ergänzt der VZD den Defaultwert für Deutschland). |
localityName |
optional |
Bezeichner: Ort |
stateOrProvinceName |
optional |
Bezeichner: Bundesland oder Region |
title |
optional |
HBA: Bezeichner: Titel |
organization |
optional |
HBA: Bezeichner: Name der Organisation oder Name der Betriebsstätte |
otherName |
optional |
Bezeichner: Anderer Name |
specialization |
optional |
Bezeichner: Fachgebiet |
domainID |
optional |
Bezeichner: domänenspezifisches Kennzeichen des Eintrags. |
holder |
optional |
Legt fest, wer Änderungen an den Basisdaten des Eintrags vornehmen darf. Hat keinen Einfluss auf Fachdaten und Zertifikatsdaten. |
maxKOMLEadr |
optional |
Maximale Anzahl von mail Adressen in den KOM-LE-Fachdaten. |
personalEntry |
obligatorisch |
Wird vom VZD eingetragen |
dataFromAuthority |
optional |
Wird vom VZD eingetragen |
active |
obligatorisch |
Mit diesem Attribut im Basiseintrag (Verzeichnisdienst_Eintrag in Abb_VZD_logisches_Datenmodell) kann der Client (Kartenherausgeber, TSP) die Aufnahme des VZD-Eintrags in die flache Liste steuern. Wenn das Attribut beim Anlegen eines VZD-Eintrags mit Zertifikat nicht angegeben wird, setzt der VZD das Attribut active auf TRUE (Default-Wert). |
meta |
optional |
Kann von den pflegenden Clients zur Abstimmung der Prozesse zwischen z. B. Kartenherausgeber und TSP genutzt werden. Dieses Attribut wird durch den VZD nicht ausgewertet. Die Werte für dieses Attribut müssen von den pflegenden Organisationen festgelegt und abgestimmt werden. |
userCertificate |
optional |
Bezeichner: Enc-Zertifikat |
notBefore |
obligatorisch |
Wird vom VZD bei Eintrag eines Zertifikats aus dem Zertifikat entnommen und ist nicht änderbar. |
userCertificate.active |
obligatorisch |
Wird vom VZD eingetragen. |
notAfter |
obligatorisch |
Wird vom VZD bei Eintrag eines Zertifikats aus dem Zertifikat entnommen und ist nicht änderbar. |
serialNumber |
obligatorisch |
Wird vom VZD bei Eintrag eines Zertifikats aus dem Zertifikat entnommen und ist nicht änderbar. |
issuer |
obligatorisch |
Wird vom VZD bei Eintrag eines Zertifikats aus dem Zertifikat entnommen und ist nicht änderbar. |
publicKeyAlgorithm |
obligatorisch |
Wird vom VZD bei Eintrag eines Zertifikats aus dem Zertifikat entnommen und ist nicht änderbar. |
entryType |
optional |
Bezeichner: Eintragstyp |
telematikID |
obligatorisch |
Bezeichner: TelematikID |
providedBy |
optional |
Zusammenhängende Einträge können über das Attribut providedBy gekennzeichnet werden. Siehe Kapitel 4.6.3 Zusammenführung mehrerer TelematikID´s zu einer Organisation |
professionOID |
optional |
Bezeichner: Profession OID |
description |
optional |
Bezeichner: Beschreibung |
optional |
Bezeichner: KOM-LE-Mail-Adresse |
|
komLeData |
optional |
Bezeichner: komLeData
komLeData: 1.0,mc_smcb_za@dom1.komle.telematik-test
|
kimData |
optional |
Bezeichner: kimData
kimData: mc_smcb_za@dom1.komle.telematik-test,1.0,eEB;V1.0 |
changeDateTime |
obligatorisch |
Der VZD setzt dieses Attribut bei jeder Schreiboperation für den Datensatz (Basisdaten und Zertifikate) auf die aktuelle Zeit. Format entsprechend RFC 3339, section 5.6. |
[<=]
Die Abbildung Abb_VZD_logisches_Datenmodell stellt die Datenstruktur des Verzeichnisdienstes als UML-Klassendiagramm dar. Die Basisdaten sind rot, die Fachdaten grün und die als Ergebnis der LDAP-Suche in Form einer flachen Liste gefundenen Einträge sind blau dargestellt. Zu jedem Attribut ist die Kardinalität in eckigen Klammern angegeben.
Unter dem Begriff SMC-B sind alle Ausprägungen zusammengefasst (SMC-B ORG, SMC-B KTR). Wenn eine Differenzierung erforderlich ist, wird die spezifische Ausprägung der SMC-B explizit beschrieben.
In der folgenden Tabelle wird der Wertebereich für das Attribut Eintragstyp (in LDAP == entryType) sowie das Mapping auf die ProfessionOID festgelegt.
Tabelle 3541: Tab_VZD_Mapping_Eintragstyp_und_ProfessionOID
Eintragstyp |
Eintragstyp Bedeutung |
ProfessionOID (ProfessionItem) |
1 |
Berufsgruppe |
1.2.276.0.76.4.30 (Ärztin/Arzt) |
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) |
4 |
Organisation |
1.2.276.0.76.4.187 (Betriebsstätte Leistungserbringerorganisation Vertragszahnärzte) |
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) |
* Definition für G0-HBA bis 23.09.2018 durch die Bundsärztekammer, siehe https://www.bundesaerztekammer.de/aerzte/telematiktelemedizin/earztausweis/technische-spezifikationen/
Kürzel |
Erläuterung |
C.FD.TLS-C |
Client-Zertifikat (öffentlicher Schlüssel) eines fachanwendungsspezifischen Dienstes für TLS Verbindungen |
C.ZD.TLS-S |
Server-Zertifikat (öffentlicher Schlüssel) eines zentralen Dienstes der TI-Plattform für TLS Verbindungen |
DNS-SD |
Domain Name System Service Discovery |
DNSSEC |
Domain Name System Security Extensions |
FAD |
fachanwendungsspezifischer Dienst |
FQDN |
Full Qualified Domain Name |
GTI |
Gesamtbetriebsverantwortlicher der TI |
HBA |
Heilberufsausweis |
http |
hypertext transport protocol |
ID.FD.TLS-C |
Client-Identität (privater und öffentlicher Schlüssel) eines fachanwendungsspezifischen Dienstes für TLS Verbindungen |
ID.ZD.TLS-S |
Server-Identität (privater und öffentlicher Schlüssel) eines zentralen Dienstes der TI-Plattform für TLS Verbindungen |
KOM-LE |
Kommunikation für Leistungserbringer (Fachanwendung) |
LDAP |
Lightweight Directory Access Protocol |
LE |
Leistungserbringer |
OCSP |
Online Certificate Status Protocol |
PKI |
Public Key Infrastructure |
PTR Resource Record |
Domain Name System Pointer Resource Record |
SMC |
Secure Module Card |
SOAP |
Simple Object Access Protocol |
TCP |
Transmission Control Protocol |
TI |
Telematikinfrastruktur |
TIP |
Telematikinfrastruktur-Plattform |
TLS |
Transport Layer Security |
TUC |
Technischer Use Case |
URL |
Uniform Resource Locator |
VZD |
Verzeichnisdienst |
WANDA Basic |
Weitere Anwendungen für den Datenaustausch ohne Nutzung der TI oder derer kryptografischen Identitäten |
WANDA Smart |
Weitere Anwendungen für den Datenaustausch mit Nutzung der TI oder derer kryptografischen Identitäten für eigene Anwendungszwecke |
XML |
Extensible Markup Language |
Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.
Abbildung 1: Einordnung des VZD in die TI
Abbildung 2: Abb_VZD_logisches_Datenmodell
Tabelle 1: Tab_PT_VZD_Schnittstellen
Tabelle 2: Tab_VZD_Schnittstelle_I_Directory_Query
Tabelle 4: Tab_VZD_Schnittstelle_I_Directory_Maintenance
Tabelle 5: Tab_VZD_Daten-Transformation
Tabelle 10: Tab_VZD_Schnittstelle_I_Directory_Application_Maintenance
Tabelle 11: Tab_VZD „I_Directory_Application_Maintenance-getInfo”
Tabelle 12: VZD_TAB_I_Directory_Application_Maintenance_Add_Mapping
Tabelle 14: VZD_TAB_KOM-LE_Attributes
Tabelle 16: Tab_TUC_VZD_00080012
Tabelle 17: Tab_TUC_VZD_00090008
Tabelle 18: VZD_TAB_I_Directory_Application_Maintenance_Modify_MappingTab_TUC_VZD_0009
Tabelle 19: Tab_TUC_VZD_00100013
Tabelle 20: VZD_TAB_KOM-LE_AttributesI_Directory_Application_Maintenance_Modify_Mapping
Tabelle 21: Tab_TUC_VZD_00110010
Tabelle 22: Tab_VZD_Schnittstelle_I_Directory_AdministrationTAB_KOM-LE_Attributes
Tabelle 23: Tab_TUC_VZD „I_Directory_Administration-getInfo”_0011
Tabelle 24: Tab_TUC_VZD „add_Directory_Entry”_0014
Tabelle 25: Tab_TUC_VZD „read_Directory_Entry”_0015
Tabelle 26: Tab_TUC_VZD „modify_Directory_Entry”_0016
Tabelle 27: Tab_VZD „stateSwitch_Schnittstelle_I_Directory_Entry”Administration
Tabelle 28: Tab_VZD „delete„I_Directory_EntryAdministration-getInfo”
Tabelle 29: Tab_VZD „readLog„add_Directory_Entry”
Tabelle 30: Tab_VZD „add„read_Directory_Entry_Certificate”
Tabelle 31: Tab_VZD „read„modify_Directory_CertificatesEntry”
Tabelle 32: Tab_VZD „delete„stateSwitch_Directory_Entry_Certificate”
Tabelle 33: Tab_VZD „read„delete_Directory_Entry_for_Sync”
Tabelle 34: Tab_VZD_Datenbeschreibung „readLog”
Tabelle 35: Tab_VZD_Mapping_Eintragstyp_und_ProfessionOID „add_Directory_Entry_Certificate”
Tabelle 36: Tab_VZD „read_Directory_Certificates”
Tabelle 37: Tab_VZD „delete_Directory_Entry_Certificate”
Tabelle 38: Tab_VZD „read_Directory_Entry_for_Sync”
Tabelle 39: Tab_VZD_Datenmapping_linked
Tabelle 40: Tab_VZD_Datenbeschreibung
Tabelle 41: Tab_VZD_Mapping_Eintragstyp_und_ProfessionOID
6.5 Referenzierte Dokumente
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.
[Quelle] |
Herausgeber: Titel |
[gemGlossar] |
gematik: Glossar der Telematikinfrastruktur |
[gemKPT_Arch_TIP] |
gematik: Konzept Architektur der TI-Plattform |
[gemKPT_PKI_TIP] |
gematik: Konzept PKI der TI-Plattform |
[gemKPT_DS_TIP] |
gematik: Datenschutzkonzept TI-Plattform |
[gemKPT_Sich_TIP] |
gematik: Spezifisches Sicherheitskonzept TI-Plattform |
[gemSpec_Net] |
gematik: Spezifikation Netzwerk |
[gemSpec_OM] |
gematik: Operations und Maintenance Spezifikation |
[gemSpec_OID] |
gematik: Spezifikation Festlegung von OIDs |
[gemSpec_PKI] |
gematik: Spezifikation PKI |
[gemSpec_Perf] |
gematik: Performance und Mengengerüst TI-Plattform |
[gemSpec_TSL] |
gematik: Spezifikation TSL-Dienst |
[gemILF_Pflege_VZD] |
gematik: Implementierungsleitfaden zur Pflege der Daten des Verzeichnisdienstes |
[Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
[BSI APP.2.1] |
Bundesamt für Sicherheit in der Informationstechnik: BSI Grundschutz-Kompendium, Baustein APP.2.1, |
[BSI-SiGw] |
Bundesamt für Sicherheit in der Informationstechnik (o.J.): Konzeption von |
[HL7FHIR] |
FHIR Specification |
[RFC2119] |
RFC 2119 (March 1997): |
[RFC2696] |
RFC 2696 (September 1999) |
[RFC4510] |
RFC 4510 (June 2006): |
[RFC4511] |
RFC 4511 (June 2006): |
[RFC4512] |
RFC 4512 (June 2006): |
[RFC4513] |
RFC 4513 (June 2006): |
[RFC4514] |
RFC 4514 (June 2006): |
[RFC4515] |
RFC 4515 (June 2006): |
[RFC4516] |
RFC 4516 (June 2006): |
[RFC4517] |
RFC 4517 (June 2006): |
[RFC4519] |
RFC 4519 (June 2006): |
[RFC4522] |
RFC 4522 (June 2006): |
[RFC4523] |
RFC 4523 (June 2006): |
[RFC 6750] |
The OAuth 2.0 Authorization Framework: Bearer Token Usage |
[RFC6763] |
RFC 6763 (February 2013): |