Die Mail-Adressen werden VZD-LDAP-seitig nicht sortiert. 

Der OpenDJ-Server speichert die Einträge in der Reihenfolge des internen Erstellungsdatums. Bei einer Wiederherstellung des OpenDJ-Inhalts geht diese Sortierung aufgrund der Neu-Anlage der Einträge verloren. Eine explizite Sortierung der Einträge nach Erstellungsdatum oder Adresse ist per Anforderung nicht vorgesehen. 

Kontext: Plausibilisierungsregeln

Welche Fehlermeldungen werden generiert,
wenn die Felder falsch befüllt werden?

Die Fehlermeldungen sind für die einzelnen Plausibilisierungsregeln nicht detailliert spezifiziert. In der Regel weisen 4XX-Fehlermeldungen den Client auf ein fehlerhaftes Verhalten hin, wobei überwiegend die Fehlermeldung "400 Bad Request" verwendet wird.

Wo möglich, werden zusätzlich aussagekräftige Fehlermeldungen bereitgestellt, um die Problemursache klarer zu kommunizieren.

In Einzelfällen können jedoch bestimmte Konstellationen zu abweichenden Fehlercodes oder wenig aussagekräftigen Fehlermeldungen führen. Sollten Sie auf einen solchen Fall stoßen, bitten wir Sie, uns entsprechend zu informieren.

Warum schlägt mein POST/PUT-Request auf baseDirectoryEntries fehl, obwohl alle Pflichtfelder befüllt sind?

Ein häufiger Fehler beim Aufruf der Schnittstelle PUT /DirectoryEntries/{id}/baseDirectoryEntries liegt in der übergebenen JSON-Struktur.

Beispiel eines fehlerhaften Aufrufs

{
  "DirectoryEntryBase": {
    "givenName": null,
    ...
  }
}

Diese Struktur ist nicht korrekt, da der äußere Wrapper "DirectoryEntryBase" nicht erforderlich ist. Die API erwartet die Felder direkt auf oberster Ebene, z. B.:

{
  "givenName": null,
  "sn": "Zahnmedizinisches Zentrum am Rothaarsteig MVZ GMBH",
  "postalCode": "59929",
  "countryCode": "DE",
  ...
}

Hintergrund
Die falsch verschachtelte Struktur kann nicht korrekt geparst und gemappt werden. Dadurch bleiben z. B. postalCode und countryCode leer (null). In der Folge kann es zu Validierungsfehlern kommen, z. B.:

validateCountryCode-211 - entry.getCountryCode:'null'
validateCountryCode-220 - Wenn countryCode=DE muss postalCode 5-stellige Nummer sein: 'null'

Zusätzlich wichtig
Die Fehlermeldung in V002 ist lediglich ein Seiteneffekt dieser falschen Datenstruktur – nicht die eigentliche Ursache.

Lösung
Bitte übermitteln Sie den Request ohne äußere Klammer "DirectoryEntryBase" und stellen Sie sicher, dass alle Pflichtfelder (z. B. countryCode, postalCode) korrekt befüllt sind. Führen Sie anschließend den Request erneut aus.

Gibt es zeitliche Vorgaben der gematik für Massenoperationen und was bedeutet "Too many requests" beim POST auf I_Directory_Administration?

Gibt es festgelegte Zeiträume für Massenoperationen durch die gematik?

• Nein. Seitens gematik und Arvato Systems sind keine Zeitfenster festgelegt

• Es gibt keine Auswirkungen auf die LDAP View Server, sofern keine großen parallelen LDAP-Abfragen erfolgen.

Warum erscheint die Fehlermeldung „Too many requests“ beim POST auf I_Directory_Administration?

• Zwischen 05:00–20:00 Uhr gilt eine Lastbegrenzung:

  • Maximal 50 parallele Requests sind erlaubt.

  • Nur ein Schreibzugriff pro Sekunde wird durchgelassen, weitere Anfragen landen im Delay.

Wann wird ein ungültiges Zertifikat aus einem Verzeichniseintrag entfernt?

• Die Gültigkeit und Status der Zertifikate werden täglich geprüft.

• Wenn ein Zertifikat noch nicht gültig (notBefore) ist, bleibt es im Eintrag erhalten, aber das Attribut certificateActive wird auf false gesetzt.

• Sobald das Zertifikat gültig wird, setzt eine Routine (Scheduler) certificateActive automatisch auf true.

• Abgelaufene und gesperrte Zertifikate werden spätestens nach einem Tag aus dem Eintrag entfernt.
  (Die Prüfung findet um 18 Uhr statt. Danach eingespielte Zertifikate werden am Folgetag entfernt. Bitte wenn möglich beachten. Ungültige Zertifikate führen in KIM-Kontext zu Problemen. Ursache ist kein Fehler im KIM-Client(Modul) sondern eine Einschränkung im Konnektor.) → Filterung im KIM-Client(Modul) bei der Abfrage der Zertifikate möglich? 
  

• Verzeichniseinträge ohne gültiges Zertifikat (also leeres Zertifikatsfeld) werden nach einem konfigurierten Zeitraum (RU, TU, PU = 1 Jahr) automatisch gelöscht.

• Bei der Anlieferung eines Zertifikats wird dessen Gültigkeitszeitraum und OCSP-Status geprüft:

  • Noch nicht gültig oder OCSP = Unknown → certificateActive = false

  • Abgelaufen oder OCSP = REVOKED → Der Request wird abgelehnt
    

Aus Effizienzgründen wird empfehlen die FHIR-Suchen so kurz wie möglich zu gestalten, da jede Suche zu einer entsprechenden Abfrage an der Datenbank führt. So können die Suchen wie SQL-Datenabfragen auf ihre Geschwindigkeit optimiert werden. Folgende Maßnahmen werden empfohlen

1. Verwendung des _text-Suchattributs (siehe Volltextsuche zur Performanceoptimierung unten)
2. Verwendung der Orts-Angabe unabhängig vom _text-Attribut. Damit ist die Unterscheidung zwischen "Suche nach einem Arzt in Berlin" und "Suche nach Dr. Berlin" gewährleistet. 
3. Bei Bedarf: Einbinden ("_include") von abhängigen Sub-Ressourcen zur Vermeidung von weiteren Abfragen. 

Beispiel-Abfrage

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

Zur Verbesserung der Suchergebnisse und zur Reduzierung unnötiger Systemlast wurden / werden folgende Anpassungen implementiert 

1. Entfernung des _text-Parameters aus der Volltextsuche wenn Parameter ohne Inhalt oder nur 1 Zeichen beinhaltet (1.2.0-12) 
   
   
2. Entfernen von Sonderzeichen "-" (1.2.0-11) / "," (1.2.0-11)  / ". " (1.2.0-12), falls keine Exakte-Suche (Nutzung doppelte Anführungszeichen) ausgeführt wird.
   
   1. “. ” wird nur entfernt wenn danach ein Leerzeichen folgt (z.B. “Dr. Max Mustermann”)
   2. Suche nach ProfessionOid ist weiterhin über Volltext möglich. (z.B. “1.2.276.0.76.4.50”)
   3. “,” als or-Verknüpfung bleibt hiervon unberührt 
      
      
3. Unterstützung von Synonymen (liefert inhaltlich verwandte Ergebnisse, z.B. "Straße" findet auch "Str." / "Uniklinik" findet auch "Universitätsklinikum" (1.2.0-12)
   
   
4. Such-Operation: Apotheken-Umkreissuche (geöffnete Apotheken im gewünschten Umkreis zum Standort) (1.2.0-12)
   
   
5. [Aktivierung der "Fuzzy-Search" (Ignoriert Typos bis max. 1 Zeichen, z.B. "Beriln" findet auch "Berlin") (1.2.0-13)]
   
   
6. [Entfernung von Oder-Verknüpfungen / Suchparameter (z.B. Org.Type) bei exzessiver Nutzung. (1.2.0-13)]

Aufgrund von technischen Restriktionen musste das HAPI-FHIR-Server eigene Paging deaktiviert werden. 

Bisher liegen Lösungsansätze für ein Paging vor, davon wurde bisher aber noch nichts implementiert.

Ein Paging kann je nach Priorisierung zukünftig eingeplant und umgesetzt werden.

Bitte die besondere Bedeutung von Sonderzeichen in Suchstrings beachten: https://github.com/gematik/api-vzd/blob/main/docs/FHIR_VZD_HOWTO_Search.adoc#characters-with-special-meaning-in-the-full-text-search

Um dieses Problem zu Umgehen, werden folgende Sonderzeichen serverseitig aus der Volltextsuche entfernt, falls keine Exakte-Suche (Nutzung doppelte Anführungszeichen) ausgeführt wird.

"-" / ";" / "."​

“.” wird nur entfernt wenn danach ein Leerzeichen folgt (z.B. “Dr. Max Mustermann”) ​
Suche nach ProfessionOid ist weiterhin über Volltext möglich. (z.B. “1.2.276.0.76.4.50”

Vielleicht helfen auch die Suchbeispiele auf der GitHub Seite (Full-text search examples).

Die Suchperformance ist stark abhängig von der Anzahl der verwendeten Suchparameter. (Technischer Hintergrund: Jeder zusätzlich Suchparameter auf Sub-Ressourcen (Organization, Practitioner, Location, Endpoint) führt zu ein oder mehreren Datenbank-JOIN-Statements. So können Anfragezeiten von >600 msec. generiert werden.

Lösung: 
Abfragen auf die Sub-Ressourcen reduzieren und stattdessen den Volltext verwenden.

​Folgende Informationen aus den Ressourcen sind im Volltext enthalten:

Inhalt der _text-Feld für Organisationen

Folgenden Werte werden in das _text-Feld der HealthcareService der Organisationen gespeichert:

Inhalt des _text-Feld für Personen

Folgenden Werte werden in das _text-Feld der PractitionerRole der Person gespeichert:

“Access Token unknown or expired ErrorCode=[....]”

Nach der Authentisierung am OAuth-Server wird erfolgreich ein service-authz-token erzeugt und beim damit ein earch-access_token angefragt.

Das VZD FHIR Staging sieht folgende Umgebungen vor:

• Arvato-interne Entwicklungs- / Testsumgebung
• Gematik Testumgebung (TU)
• Referenzumgebung (RU)
• Produktionsumgebung (PU). 

In der FHIR VZD Spezifikation sind TU, RU und PU genannt. 

Aktuell sind in der TU lediglich gematik exklusive Gesamtintegrationstests vorgesehen. 

Zulassungstests erfolgen in der Referenzumgebung (RU)

RU am Beispiel von Service-Authenticate / FDV-Search 

Auth-Server (Keycloak):
https://auth-ref.vzd.ti-dienste.de:9443/auth/realms/Service-Authenticate/protocol/openid-connect/token

Service-Authenticate:
https://fhir-directory-ref.vzd.ti-dienste.de/service-authenticate

FDV-Search (VZD FHIR):
https://fhir-directory-ref.vzd.ti-dienste.de/fdv/search/HealthcareService?organization.active=true&......

TU am Beispiel von Service-Authenticate / FDV-Search 

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

Service-Authenticate (VZD FHIR):
https://fhir-directory-tu.vzd.ti-dienste.de/service-authenticate

FDV-Search (VZD FHIR):
https://fhir-directory-tu.vzd.ti-dienste.de/fdv/search/HealthcareService?organization.active=true&......

Ja, die gematik hat in beiden Umgebungen Testdaten eingepflegt

• In die Referenzumgebung RU wurden 9000 Organisationen und 18000 Practitioner eingespielt.
• In die Testumgebung TU wurden insgesamt 9000 Organisationen mit 18000 Practitionern eingespielt.

Die Organisationen und Practitioner sind jeweils in unterschiedlichen Ausprägungen (Spezialisierungen, ProfessionOID) vorhanden.
Für Apotheken wurden zudem unterschiedliche Zusammenstellungen von angebotenen Service und Öffnungszeiten hinzugefügt.

Die Adressen sind willkürliche, reale Adressen aus Deutschland. Für einzelne Apotheken zusätzlich mit den dazugehörigen Geo-Koordinaten.

Diese Testdaten für Organisationen sind erkenntlich an der Namensnomeklatur "Organisation xx-xxx-ARVxxxx"