FAQ

Ist es für die kontinuierliche Synchronisation ausreichend, nur die Terminbuchungen (Appointments) abzurufen oder müssen zwangsweise die Änderungen (Provenances) abgerufen werden?

Ein regelmäßiger Abruf der Terminbuchungen (Appointments) ist ausreichend, um die kontinuierliche Synchronisation zu gewährleisten. Der Endpunkt zum Abrufen der Änderungen (Provenances) stellt lediglich eine Alternative dar. Um das Audit für die Schnittstelle Abrechnungsinformationen – PVS erfolgreich zu absolvieren, ist es demnach NICHT erforderlich, das Abrufen der Provenances zu implementieren.

Hintergrund: Da bei der Schnittstelle Terminsynchronisation – TVS neben Appointments noch weitere Ressourcen aus dem 116117 Terminservice für die Synchronisierung relevant sind, bietet hier der Provenance-Abruf für die kontinuierliche Synchronisation deutliche Vorteile gegenüber dem separaten Abruf aller Ressourcen. Um beide Schnittstellen möglichst ähnlich aufzubauen, gibt es den Endpunkt zum Abrufen der Provenances auch bei der vorliegenden Schnittstelle für die Abrechnungsinformationen.


Warum kommt ein Fehler zurück, wenn eine Suche (search interaction) mit einem GET-Request durchgeführt wird?

Um eine Suche (search interaction) durchzuführen, muss ein POST-Request an den 116117 Terminservice geschickt werden. Auch wenn laut FHIR-Standard eine Suche mit einem GET-Request und Suchparametern in der URL zulässig ist, wird dies durch die Systeme des 116117 Terminservice aktuell NICHT unterstützt.


Das zurückgegebene Searchset Bundle enthält einen Link zur nächsten Seite der Suchergebnisse. Warum kann der Link nicht direkt aufgerufen werden?

Auch wenn laut FHIR-Standard eine Suche mit einem GET-Request und Suchparametern in der URL zulässig ist, wird dies durch die Systeme des 116117 Terminservice aktuell NICHT unterstützt. Dies lässt sich im Searchset Bundle jedoch nicht abbilden, da im Element Bundle.link nur eine URL (und kein Request Body) angegeben werden kann. Das bedeutet, dass die Einträge im Element Bundle.link lediglich der Nachvollziehbarkeit dienen, welche Suchparameter für die Suche genutzt wurden und ob eine nächste Seite mit Suchergebnissen existiert. Um diese nächste Seite tatsächlich abzurufen, muss jedoch ein POST-Request geschickt werden, bei dem alle Suchparameter im Request Body übergeben werden.

Dabei ist zu beachten, dass sich (entsprechend des FHIR-Standards) die URL bei einer Suche mittels GET-Request von der URL unterscheidet, die für eine Suche mittels POST-Requests genutzt wird: bei einem POST-Request muss am Ende der URL (hinter dem Ressourcentyp) statt eines ? (bei GET-Requests) der Namen der gewünschten Interaktion angegeben werden, also [base]/[ResourceType]/_search. Das bedeutet, dass die URL aus dem Element Bundle.link.url nicht 1:1 als Request-URL für die nächste Suche übernommen werden kann.


Warum werden Suchergebnisse zurückgeliefert, die nicht den übergebenen Suchparametern entsprechen?

Dies kann unterschiedliche Ursachen haben:

  • Die Suchparameter wurden in der URL übergeben. Auch wenn laut FHIR-Standard Suchparameter in der URL (sowohl für GET- als auch für POST-Requests) zulässig sind, wird dies durch die Systeme des 116117 Terminservice aktuell NICHT unterstützt. Das bedeutet, dass alle Suchparameter im Request Body als key value pair übergeben werden müssen.
  • Es wurden nicht unterstützte Suchparameter übermittelt. Alle unterstützten Suchparameter sind auf den jeweiligen Seiten zu den Suchen (search interactions) gelistet. Suchparameter, die dort nicht zu finden sind, werden von den Systemen des 116117 Terminservice NICHT ausgewertet und verarbeitet.

Um zu prüfen, welche Suchparameter die Systeme des 116117 Terminservices ausgewertet und verarbeitet haben, kann der Eintrag im Element Bundle.link ausgewertet werden, der im Element Bundle.link.relation den Wert self hat. In der URL, die in Bundle.link.url steht, sind alle Suchparameter enthalten, die für die Suche genutzt wurden.

Beispiele und ausführlichere Informationen zu den einzelnen Suchparametern sind auf den einzelnen Seiten zu den Suchen (search interactions) zu finden.


Als Response bei einer Suche kommt der HTTP-Statuscode 200 OK zurück, aber das Bundle mit den Suchergebnissen enthält keine Einträge. Woran liegt das und was ist zu tun?

Mögliche Ursache: Der Request an sich ist valide und konnte auch erfolgreich verarbeitet werden. Im 116117 Terminservice sind jedoch keine Ressourcen vorhanden, die zurückgegeben werden können.

  • Möglichkeit 1: Die gesetzten Suchparameter sind nicht widersprüchlich, dennoch wurden mit den Suchparametern keine Ressourcen im 116117 Terminservice gefunden.

    • Ein Beispiel hierfür ist eine Suche nach Appointments mit einer ANR als Suchparameter: Existiert im 116117 Terminservice keine Terminbuchung, die dem Arzt mit der angegebenen ANR zugeordnet ist, enthält das Bundle mit den Suchergebnissen keinen Eintrag.

  • Möglichkeit 2: Die angegebenen Suchparameter schließen sich gegenseitig aus.

    • Wie auf den Seiten zu den jeweiligen search interactions beschrieben, prüfen die Systeme des 116117 Terminservices nur bedingt auf Plausibilität.

    • Ein Beispiel hierfür ist die Suche nach Appointments mit einer ANR und einer BSNR als Suchparameter: Die Systeme des 116117 Terminservices prüfen vorab NICHT, ob der Arzt mit der angegebenen ANR tatsächlich in der Praxis mit der angegebenen BSNR tätig ist. Ist der Arzt nicht in der Praxis tätig, wird kein Fehler sondern ein leeres Bundle zurückgegeben.

Mögliche Lösung: Die angegebenen Suchparameter sollten geprüft und ggf. angepasst werden.


Als Response auf einen Request kommt der HTTP-Statuscode 400 Bad Request zurück. Woran liegt das und was ist zu tun?

Mögliche Ursache: Der gesendete Request ist nicht valide.

  • Beispiel: Unerlaubte Werte oder Zeichen in einem Suchparameter

Mögliche Lösung: Der Request muss korrigiert werden.

  • Das im Response Body enthaltene OperationOutcome enthält nähere Informationen zum aufgetrenen Fehler.

Als Response auf einen Request kommt der HTTP-Statuscode 401 Unauthorized zurück. Woran liegt das und was ist zu tun?

Mögliche Ursache: Der Access Token, der im Header Authorization übergeben wurde, ist ungültig.

Mögliche Lösung: Es muss ein neuer Access Token angefragt werden.


Als Response auf einen Request kommt der HTTP-Statuscode 403 Forbidden zurück. Woran liegt das und was ist zu tun?

Mögliche Ursache: Die Authentifizierung für die Schnittstelle war erfolgreich, aber der Anfragende ist nicht für die gewünschte Aktion autorisiert. Das bedeutet, dass der Access Token, der im Header Authorization übergeben wurde, an sich gültig ist. Die BSNR der Praxis, für die Ressourcen abgerufen werden sollen, ist jedoch NICHT im Access Token enthalten.

Mögliche Lösung: Der Access Token und der Request müssen überprüft und ggf. korrigiert werden.

  • Wurde der Access Token für die richtige BSNR angefordert?
  • Beim Abrufen von Ressourcen mit dem Suchparameter BSNR: Ist die BSNR korrekt, die im Request Body als Suchparameter angegeben wurde?

Als Response auf einen Request kommt der HTTP-Statuscode 405 Method Not Allowed zurück. Woran liegt das und was ist zu tun?

Mögliche Ursache: Der angefragte Endpunkt existiert, aber die im Request verwendete HTTP-Methode ist für diesen Endpunkt nicht zulässig.

Mögliche Lösung: Die HTTP-Methode muss korrigiert werden.

  • Die erforderliche HTTP-Methode ist auf den Seiten zu den jeweiligen Interaktionen zu finden.

Als Response auf einen Request kommt der HTTP-Statuscode 412 Precondition Failed zurück. Woran liegt das und was ist zu tun?

Mögliche Ursache: Ein verpflichtender Request Header fehlt oder enthält einen nicht erlaubten Wert.

Mögliche Lösung: Der Request Header muss korrigiert werden.

  • Die erforderlichen Request Header inkl. der erlaubten Werte und Beispiele sind auf den Seiten zu den jeweiligen Interaktionen zu finden.

Als Response auf einen Request kommt der HTTP-Statuscode 415 Unsupported Media Type zurück. Woran liegt das und was ist zu tun?

Mögliche Ursache: Der Request Header Content-Type fehlt oder enthält einen nicht erlaubten Wert oder der Request Body hat das falsche Format.

Mögliche Lösung: Entweder muss der Request Header Content-Type oder der Request Body korrigiert werden.

  • Die erlaubten Werte für alle Request Header sowie Beispiele für den Request Body sind auf den Seiten zu den jeweiligen Interaktionen zu finden.

Als Response auf einen Request kommt der HTTP-Statuscode 500 Internal Server Error zurück. Woran liegt das und was ist zu tun?

Mögliche Ursache: Es gibt ein technisches Problem beim 116117 Terminservice.

Mögliche Lösung: Es sollte ein Support-Ticket vom Typ Fehler mit folgenden Angaben im Serviceportal 116117 Terminservice der kv.digital GmbH erstellt werden:

  • Angabe des betroffenen Systems
  • Angabe der betroffenen Komponente
  • Request-Details (URL, Request Header und Request Body)
  • Response-Details (HTTP-Statuscode, Response Header und Response Body)
  • Zeitpunkt, wann der Fehler aufgetreten ist
  • Sonstige Details, die für die Repdroduktion des Fehlers relevant sein könnten.

Es gibt Fragen oder Probleme, die nicht im vorliegenden Implementation Guide oder der zugehörigen Spezifikation beschrieben sind?

Im Serviceportal 116117 Terminservice der kv.digital GmbH kann ein Support-Ticket vom Typ Fehler, Frage oder Wunsch erstellt werden, um Fehler zu melden, Verständnisfragen zu klären oder Verbesserungsvorschläge zu machen.