Interaktionen

Folgende FHIR-Standardinteraktionen werden in den Unterkapiteln näher erläutert:

Einleitung

Eine Kommunikation mit dem 116117 Terminservice erfolgt ausschließlich über die hier beschriebenen Interaktionen.


Allgemeingültige Anmerkungen

Für alle Interaktionen gilt:

  • Für eine Suche muss immer ein POST-Request geschickt werden; ein GET-Request führt zu einem Fehler.

  • Alle Suchparameter müssen im Request Body übergeben werden; Suchparameter in der URL werden ignoriert.

  • Alle genutzten Suchparameter und deren Werte sind – ausschließlich zum Zwecke der Nachvollziehbarkeit – im Element Bundle.link.url enthalten. Dadurch wird ersichtlich, welche Parameter überhaupt für die Suche genutzt und welche Standardwerte für nicht übergebene Suchparameter eingesetzt wurden.

  • Die Systeme des 116117 Terminservices nutzen Paging, um die Datenmenge pro Response (Antwort auf eine Suchanfrage des PVS) bei einer hohen Anzahl an Suchergebnissen zu begrenzen. Details hierzu sind im Abschnitt Paging auf dieser Seite zu finden.

  • Alle Suchergebnisse sind über alle Seiten hinweg sortiert. Dadurch wird sichergestellt, dass auch beim mehrfachen Abrufen die Suchergebnisse immer in exakt derselben Reihenfolge zurückgegeben werden.

    • Bitte beachten: Durch das Löschen bestehender Ressourcen kann es passieren, dass beim erneuten Abrufen derselben Seite weitere, noch nicht bekannte Suchergebnisse zurückgegeben werden.

    • Beispielhaft veranschaulicht, bedeutet dies: Ein PVS ruft Appointments ab und erhält Appointment 1 bis 10 vom 116117 Terminservice. Nun wird Appointment 2 gelöscht. Wenn das PVS genau denselben Request wie zuvor erneut schicken würde, würde es Appointment 1 und Appointment 3 bis 11 zurückbekommen (in derselben Reihenfolge wie beim vorherigen Request, nur dass Appointment 2 nicht mehr in den Suchergebnissen enthalten ist).

  • Die Suchergebnisse enthalten – auch über mehrere Seiten hinweg – keine Duplikate.

  • Im Fehlerfall wird ein eigens dafür definiertes OperationOutcome mit Details zum aufgetretenen Fehler zurückgegeben.


Paging

Entsprechend dem FHIR-Standard nutzen die Systeme des 116117 Terminservices Paging bei Suchen (search interactions). Das bedeutet, dass die Suchergebnisse in Seiten aufgeteilt werden und jede Seite einzeln (mit einem separaten Request) abgerufen werden muss.

Für das Paging sind verschiedene Werte relevant, die in den folgenden Abschnitten beschrieben werden. Im Abschnitt Ablauf einer Suche (search interaction) wird außerdem beschrieben, wie die Response auf eine Suchanfrage auszuwerten ist, um alle Seiten der Suchergebnisse abzurufen.


Suchparameter page

Der Suchparameter page definiert, welche Seite der Suchergebenisse abgerufen werden soll.

Wird eine Seitenzahl übergeben, auf der keine Suchergebnisse vorhanden sind, führt dies NICHT zu einem Fehler. Im Response Body ist in diesem Fall ein Searchset Bundle enthalten, in dem das Element Bundle.entry NICHT vorkommt. (Bundle.entry enthält normalerweise die Suchergebnisse.)
Beispielhaft veranschaulicht könnte dies wie folgt aussehen: Das PVS ruft Seite 5 der Suchergebnisse ab. Die Systeme des 116117 Terminservices finden insgesamt 25 Suchergebnisse und geben maximal 10 Suchergebnisse pro Seite zurück. Somit wird das Element Bundle.entry für Seite 5 nicht gesetzt und ist entsprechend nicht im Response Body enthalten.

Details zu diesem Suchparameter sind auf den einzelnen Unterseiten zu den search interactions zu finden.


Suchparameter _count

Der Suchparameter _count definiert die maximale Anzahl an Suchergebnissen, die pro Seite zurückgegeben werden.

Werden insgesamt mehr Suchergebnisse gefunden, als in _count angegeben, gibt es mehrere Seiten mit Suchergebnissen. Die anderen Seiten können über weitere Requests mit dem entsprechenden Wert für den Suchparameter page abgerufen werden.

Werden weniger Suchergebnisse auf einer Seite zurückgegeben, als in _count angegeben, kann das zwei Ursachen haben:

  • Der 116117 Terminservice hat insgesamt weniger Suchergebnisse gefunden, als in _count angegeben.

  • Die letzte Seite mit Suchergebnissen ist nicht komplett befüllt (wenn bspw. insgesamt 24 Suchergebnisse gefunden wurden und pro Seite 10 Suchergebnisse zurückgegeben werden sollen, enthält Seite 3 nur 4 Suchergebnisse).

Allgemeine Informationen zu diesem Suchparameter sind in der HL7-Dokumentation im Abschnitt page count zu finden. Details zu diesem Suchparameter in Bezug auf die vorliegende Schnittstelle sind auf den einzelnen Unterseiten zu den search interactions zu finden.


Bitte beachten: Laut FHIR-Standard wäre auch ein Wert von 0 zulässig, um nur die Anzahl aller Suchergebnisse als Antwort zu bekommen. Dies wird von den Systeme des 116117 Terminservices jedoch NICHT unterstützt. Das bedeutet, dass der Parameter _count=0 zu einem Fehler aufgrund eines unzulässigen Wertes für diesen Parameter führt. Die Anzahl aller Suchergebnisse ist immer im Response Body im Element Bundle.total angegeben.


Element Bundle.total

Das Element Bundle.total aus dem Response Body gibt die Gesamtzahl der Suchergebnisse an, also wie viele Suchergebnisse die Systeme des 116117 Terminservices insgesamt gefunden haben. (Diese Anzahl ist unabhängig von der Anzahl der Suchergebnisse pro Seite.) Details zum Bundle sind auf der Seite Profil: Suchergebnisse (Bundle) zu finden.


Bitte beachten: Die Gesamtzahl der Suchergebnisse kann sich zwischen dem Abruf einer Seite und der nächsten Seite der Suchergebnisse ändern. Voraussetzung hierfür ist, dass zwischen diesen zwei Abrufen im 116117 Terminservice Ressourcen gelöscht oder neu erstellt wurden. Dies wird nicht sehr häufig passieren, da das Abrufen der einzelnen Seiten innerhalb kürzester Zeit erfolgt. Es ist dennoch wichtig, da sich dadurch auch die Anzahl der Seiten ändern kann:

  • Wurden neue Ressourcen erstellt, kann es sein, dass es mehr Seiten mit Suchergebnissen gibt als beim vorherigen Abruf.

    • In diesem Fall müssen die neuen Seiten ebenfalls abgerufen werden.

    • Im Response Body (der zuvor letzten Seite der Suchergebnisse) ist dann ein Verweis auf die nächste Seite vorhanden.

    • Ein beispielhafter Ablauf ist am Ende dieser Seite im Tab Beispiel 2 beschrieben.

  • Wurden Ressourcen gelöscht (bspw. aufgrund von gesetzlich vorgeschriebenen Löschfristen), kann es sein, dass es weniger Seiten mit Suchergebnissen gibt als beim vorherigen Abruf.

    • In diesem Fall kann es passieren, dass die aktuell abgerufene Seite keine Suchergebnisse (mehr) enthält. Dann sollte die letzte befüllte Seite erneut abgerufen werden, also die letzte Seite, auf der noch Suchergebnisse vorhanden sind.

    • Wie die letzte befüllte Seite ermittelt werden kann, ist im Abschnitt Ablauf einer Suche (search interaction) beschrieben.

    • Ein beispielhafter Ablauf ist am Ende dieser Seite im Tab Beispiel 4 beschrieben.


Das Element Bundle.link aus dem Response Body enthält Verweise auf die nächste und/oder vorherige Seite, sofern diese vorhanden sind:

  • Der Verweis auf die nächste Seite ist ein Eintrag in Bundle.link, bei dem das Element Bundle.link.relation den Wert next hat.

  • Der Verweis auf die vorherige Seite ist ein Eintrag in Bundle.link, bei dem das Element Bundle.link.relation den Wert previous hat.

Die Verweise sind im Element Bundle.link.url in Form einer URL angegeben. Der Aufbau dieser URL entspricht der URL eines GET-Requests für Suchen gemäß FHIR-Standard: [base]/[type]?[parameter-name]=[parameter-value]&[parameter-name]=[parameter-value]&.... Da die vorliegende Schnittstelle aktuell aber nur POST-Requests mit Suchparametern im Request Body für eine Suche erlaubt, müssen die Suchparameter bei Suchanfragen immer im Request Body übergeben werden.

Die URL im Element Bundle.link.url enthält alle vom 116117 Terminservice für die Suche verarbeiteten Suchparameter. Dies dient ausschließlich der Nachvollziehbarkeit, da für den Abruf der nächsten oder vorherigen Seite nur der Wert des Suchparameters page um 1 erhöht bzw. verringert werden muss. (Alle anderen Suchparameter bleiben unverändert.) Es ist im Normalfall also nicht notwendig, das Element Bundle.link.url im Detail auszuwerten.

Weitere Details zum Bundle sind auf der Seite Profil: Suchergebnisse (Bundle) zu finden.


Bitte beachten:

  • Der Verweis auf die vorherige Seite enthält immer den Suchparameter page reduziert um 1 im Vergleich zum aktuellen Abruf. Das bedeutet aber auch, dass nicht zwangsweise Suchergebnisse auf der vorherigen Seite vorhanden sind.

    • Beispielhaft veranschaulicht bedeutet dies: Wird Seite 5 der Suchergebnisse abgerufen, ist im Element Bundle.link ein Eintrag mit dem Verweis auf die vorherige Seite (mit page=4) vorhanden – wurden insgesamt aber nur 20 Suchergebnisse gefunden und 10 Suchergebnisse pro Seite zurückgegeben, gibt es weder auf Seite 4 noch auf Seite 5 Suchergebnisse.

  • Wurden zwischen dem Abruf einer Seite und der nächsten / vorherigen Seite Ressourcen im 116117 Terminservice gelöscht, kann es passieren, dass auf der nächsten / vorherigen Seite keine Suchergebnissen vorhanden sind.

  • Die URL für POST-Requests unterscheidet sich im Aufbau (gemäß FHIR-Standard) von der GET-Variante, da der Name der Interaktion in der URL enthalten ist: [base]/[type]/_search


Ablauf einer Suche (search interaction)

Hat das PVS eine valide Suchanfrage an den 116117 Terminservice gestellt, wird im Response Body ein Searchset Bundle zurückgegeben. In diesem Searchset Bundle sind alle in den vorherigen Abschnitten beschriebenen Informationen enthalten.

Um alle Suchergebnisse zu erhalten, muss ein PVS prüfen, ob die aktuelle Seite Suchergebnisse enthält und ob ein weiterer Request notwendig ist. Das folgende Aktivitätsdiagramm veranschaulicht diesen Ablauf:



Erklärung

(1) Das PVS prüft, ob der Wert des Elementes Bundle.total größer als null ist, also: Bundle.total > 0

(2) Das PVS prüft, ob das Element Bundle.entry existiert.

(3) Das PVS speichert die Ressourcen, die in den Einträgen des Elementes Bundle.entry enthalten sind.

(4) Das PVS prüft, ob im Element Bundle.link ein Eintrag vorhanden ist, bei dem das Element Bundle.link.relation den Wert next hat.

(5) Das PVS erhöht den Wert des Suchparameters page um 1 und schickt einen weiteren Request an den 116117 Terminservice.

  • Alle anderen Suchparameter bleiben unverändert.

  • Der Request enthält alle Suchparameter, die auch beim Abruf der vorherigen Seite verwendet wurden.

(6) Das PVS teilt den Wert von Bundle.total durch den Wert von _count und rundet das Ergebnis auf.

  • Mathematisch ausgedrückt: ⌈ Bundle.total / _count ⌉

  • Beispiel: Wenn insgesamt 25 Suchergebnisse gefunden wurden und 10 Suchergebnisse pro Seite zurückgegeben werden, ergibt sich ⌈ 25 / 10 ⌉ = 3. Die Seitenzahl der letzten mit Suchergebnissen befüllten Seite ist demnach 3.

(7) Das PVS setzt den Wert des Suchparameters page auf den Wert, der in Schritt 5 errechnet wurde und schickt einen weiteren Request an den 116117 Terminservice.

  • Alle anderen Suchparameter bleiben unverändert.

  • Der Request enthält alle Suchparameter, die auch beim Abruf der vorherigen Seite verwendet wurden.


Beispiele

Zur Veranschaulichung, wie Suchen mit unterschiedlichen Suchparametern ablaufen können, wenn sich die Gesamtzahl der Suchergebnisse ändert, sind im Folgenden einige beispielhafte Abläufe beschrieben:

  • Beispiel 1 (mit Suchparameter bsnr): Zwischen zwei Abrufen erhöht sich die Gesamtzahl der Suchergebnisse, die Anzahl der befüllten Seiten bleibt unverändert.

  • Beispiel 2 (mit Suchparameter bsnr und _count): Zwischen zwei Abrufen erhöht sich die Gesamtzahl der Suchergebnisse UND die Anzahl der befüllten Seiten.

  • Beispiel 3 (ohne Suchparameter): Zwischen zwei Abrufen verringert sich die Gesamtzahl der Suchergebnisse, die Anzahl der befüllten Seiten bleibt unverändert.

  • Beispiel 4 (mit Suchparameter bsnr, _count und page): Zwischen zwei Abrufen verringert sich die Gesamtzahl der Suchergebnisse UND die Anzahl der befüllten Seiten.

Szenario: Zwischen zwei Abrufen erhöht sich die Gesamtzahl der Suchergebnisse, die Anzahl der befüllten Seiten bleibt unverändert.

  1. Das PVS ruft Ressourcen (bspw. Appointments) vom 116117 Terminservice ab. Der Request Body enthält nur den Suchparameter bsnr mit der BSNR der Praxis.

  2. Die Systeme des 116117 Terminservice stellen fest, dass der Request valide ist und verarbeiten diesen. Für folgende Suchparameter werden dabei die Standardwerte eingesetzt: page=1 und _count=10. Anschließend wird die Suchanfrage ausgeführt und eine Response an das PVS zurückgeschickt.

  3. Der Request des PVS wird mit dem HTTP-Statuscode 200 OK und einem Response Body beantwortet, der ein Searchset Bundle mit folgenden Informationen enthält:

    • Bundle.total hat den Wert 11.

    • Bundle.link hat 2 Einträge:

      • einen mit <relation value="self" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr]&page=1&_count=10 />

      • einen mit <relation value="next" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr]&page=2&_count=10 />

    • Bundle.entry enthält insgesamt 10 Einträge mit den tatsächlichen Suchergebnissen (bspw. Appointments) sowie weitere Einträge mit Ressourcen, die in den tatsächlichen Suchergebnissen referenziert werden (bspw. Patients). (Welche Ressourcen im Searchset Bundle inkludiert sind, ist den einzelnen Unterseiten zu den search interactions oder der Seite Profil: Suchergebnisse (Bundle) zu entnehmen.)

  4. Das PVS prüft, ob der Wert des Elementes Bundle.total größer als 0 ist. Da dies der Fall ist, prüft das PVS anschließend, ob das Element Bundle.entry im Response Body existiert. Da auch dies der Fall ist, speichert das PVS die Ressourcen, die in den Einträgen des Elementes Bundle.entry enthalten sind:

    • Ressourcen, die noch nicht im PVS vorhanden sind, müssen im PVS neu erstellt werden.

    • Ressourcen, die bereits im PVS vorhanden sind, müssen im PVS überschrieben werden.

  5. Das PVS registriert, dass es (mindestens) eine weitere Seite mit Suchergebnissen gibt, da ein Eintrag mit dem Wert next im Element Bundle.link.relation existiert.

  6. Während das PVS die Response auf den ersten Request verarbeitet, werden im 116117 Terminservice 2 neue Ressourcen erstellt.

  7. Das PVS schickt einen weiteren Request an den 116117 Terminservice. Der Request Body enthält neben dem Suchparameter bsnr (wie beim ersten Request) auch den Suchparameter page=2.

  8. Die Systeme des 116117 Terminservice stellen fest, dass der Request valide ist und verarbeiten diesen. Für den folgenden Suchparameter wird dabei der Standardwert eingesetzt: _count=10. Anschließend wird die Suchanfrage ausgeführt und eine Response an das PVS zurückgeschickt.

  9. Der Request des PVS wird mit dem HTTP-Statuscode 200 OK und einem Response Body beantwortet, der ein Searchset Bundle mit folgenden Informationen enthält:

    • Bundle.total hat jetzt den Wert 13.

    • Bundle.link hat 2 Einträge:

      • einen mit <relation value="self" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr]&page=2&_count=10 />

      • einen mit <relation value="previous" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr]&page=1&_count=10 />

    • Bundle.entry enthält insgesamt 3 Einträge mit den tatsächlichen Suchergebnissen sowie weitere Einträge mit Ressourcen, die in den tatsächlichen Suchergebnissen referenziert werden.

  10. Das PVS prüft, ob der Wert des Elementes Bundle.total größer als 0 ist. Da dies der Fall ist, prüft das PVS anschließend, ob das Element Bundle.entry im Response Body existiert. Da auch dies der Fall ist, speichert das PVS die Ressourcen, die in den Einträgen des Elementes Bundle.entry enthalten sind (äquivalent zu Schritt 4).

  11. Das PVS registriert, dass es keinen Verweis auf eine nächste Seite gibt, da KEIN Eintrag mit dem Wert next im Element Bundle.link.relation existiert. Da auf der aktuellen Seite aber Suchergebnisse vorhanden waren (siehe Schritt 10), weiß das PVS, dass kein weiterer Request notwendig und die Suche beendet ist.

Szenario: Zwischen zwei Abrufen erhöht sich die Gesamtzahl der Suchergebnisse UND die Anzahl der befüllten Seiten.

  1. Das PVS ruft Ressourcen (bspw. Appointments) vom 116117 Terminservice ab. Der Request Body enthält den Suchparameter bsnr mit der BSNR der Praxis sowie den Suchparameter _count=4.

  2. Die Systeme des 116117 Terminservice stellen fest, dass der Request valide ist und verarbeiten diesen. Für den folgenden Suchparameter wird dabei der Standardwert eingesetzt: page=1. Anschließend wird die Suchanfrage ausgeführt und eine Response an das PVS zurückgeschickt.

  3. Der Request des PVS wird mit dem HTTP-Statuscode 200 OK und einem Response Body beantwortet, der ein Searchset Bundle mit folgenden Informationen enthält:

    • Bundle.total hat den Wert 12.

    • Bundle.link hat 2 Einträge:

      • einen mit <relation value="self" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr]&page=1&_count=4 />

      • einen mit <relation value="next" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr]&page=2&_count=4 />

    • Bundle.entry enthält insgesamt 4 Einträge mit den tatsächlichen Suchergebnissen (bspw. Appointments) sowie weitere Einträge mit Ressourcen, die in den tatsächlichen Suchergebnissen referenziert werden (bspw. Patients). (Welche Ressourcen im Searchset Bundle inkludiert sind, ist den einzelnen Unterseiten zu den search interactions oder der Seite Profil: Suchergebnisse (Bundle) zu entnehmen.)

  4. Das PVS prüft, ob der Wert des Elementes Bundle.total größer als 0 ist. Da dies der Fall ist, prüft das PVS anschließend, ob das Element Bundle.entry im Response Body existiert. Da auch dies der Fall ist, speichert das PVS die Ressourcen, die in den Einträgen des Elementes Bundle.entry enthalten sind:

    • Ressourcen, die noch nicht im PVS vorhanden sind, müssen im PVS neu erstellt werden.

    • Ressourcen, die bereits im PVS vorhanden sind, müssen im PVS überschrieben werden.

  5. Das PVS registriert, dass es (mindestens) eine weitere Seite mit Suchergebnissen gibt, da ein Eintrag mit dem Wert next im Element Bundle.link.relation existiert.

  6. Während das PVS die Response auf den ersten Request verarbeitet, wird im 116117 Terminservice 1 neue Ressource erstellt.

  7. Das PVS schickt einen weiteren Request an den 116117 Terminservice. Der Request Body enthält neben den Suchparametern bsnr und _count (wie beim ersten Request) auch den Suchparameter page=2.

  8. Die Systeme des 116117 Terminservice stellen fest, dass der Request valide ist und verarbeiten diesen. Anschließend wird die Suchanfrage ausgeführt und eine Response an das PVS zurückgeschickt.

  9. Der Request des PVS wird mit dem HTTP-Statuscode 200 OK und einem Response Body beantwortet, der ein Searchset Bundle mit folgenden Informationen enthält:

    • Bundle.total hat jetzt den Wert 13.

    • Bundle.link hat 3 Einträge:

      • einen mit <relation value="self" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr]&page=2&_count=4 />

      • einen mit <relation value="next" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr]&page=3&_count=4 />

      • einen mit <relation value="previous" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr]&page=1&_count=4 />

    • Bundle.entry enthält insgesamt 4 Einträge mit den tatsächlichen Suchergebnissen sowie weitere Einträge mit Ressourcen, die in den tatsächlichen Suchergebnissen referenziert werden.

  10. Äquivalent zu Schritt 4 und 5 speichert das PVS die Ressourcen, die in den Einträgen des Elementes Bundle.entry enthalten sind und registriert, dass es (mindestens) eine weitere Seite mit Suchergebnissen gibt.

  11. Äquivalent zu Schritt 7 bis 9 schickt das PVS einen weiteren Request mit page=3 und bekommt den HTTP-Statuscode 200 OK und einen Response Body zurück, der ein Searchset Bundle mit folgenden Informationen enthält:

    • Bundle.total hat weiterhin den Wert 13.

    • Bundle.link hat 3 Einträge:

      • einen mit <relation value="self" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr]&page=3&_count=4 />

      • einen mit <relation value="next" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr]&page=4&_count=4 />

      • einen mit <relation value="previous" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr]&page=2&_count=4 />

    • Bundle.entry enthält insgesamt 4 Einträge mit den tatsächlichen Suchergebnissen sowie weitere Einträge mit Ressourcen, die in den tatsächlichen Suchergebnissen referenziert werden.

  12. Äquivalent zu Schritt 4 und 5 speichert das PVS die Ressourcen, die in den Einträgen des Elementes Bundle.entry enthalten sind und registriert, dass es (mindestens) eine weitere Seite mit Suchergebnissen gibt.

  13. Äquivalent zu Schritt 7 bis 9 schickt das PVS einen weiteren Request mit page=4 und bekommt den HTTP-Statuscode 200 OK und einen Response Body zurück, der ein Searchset Bundle mit folgenden Informationen enthält:

    • Bundle.total hat weiterhin den Wert 13.

    • Bundle.link hat 2 Einträge:

      • einen mit <relation value="self" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr]&page=4&_count=4 />

      • einen mit <relation value="previous" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr]&page=3&_count=4 />

    • Bundle.entry enthält insgesamt 1 Eintrag mit den tatsächlichen Suchergebnissen sowie weitere Einträge mit Ressourcen, die in den tatsächlichen Suchergebnissen referenziert werden.

  14. Äquivalent zu Schritt 4 speichert das PVS die Ressourcen, die in den Einträgen des Elementes Bundle.entry enthalten sind.

  15. Das PVS registriert, dass es keinen Verweis auf eine nächste Seite gibt, da KEIN Eintrag mit dem Wert next im Element Bundle.link.relation existiert. Da auf der aktuellen Seite aber Suchergebnisse vorhanden waren (siehe Schritt 14), weiß das PVS, dass kein weiterer Request notwendig und die Suche beendet ist.

Szenario: Zwischen zwei Abrufen verringert sich die Gesamtzahl der Suchergebnisse, die Anzahl der befüllten Seiten bleibt unverändert.

  1. Das PVS ruft Ressourcen (bspw. Appointments) vom 116117 Terminservice ab. Der Request Body enthält keine Suchparameter.

  2. Die Systeme des 116117 Terminservice stellen fest, dass der Request valide ist und verarbeiten diesen. Für folgende Suchparameter werden dabei die Standardwerte eingesetzt: page=1 und _count=10. Für den Suchparameter bsnr werden alle BSNRs gesetzt, die im Access Token (von der Authentifizierung) enthalten sind. (Wenn es sich um einen Praxisverbund mit einer Haupt- und mindestens einer Nebenbetriebsstätte handelt, werden hier mehrere BSNRs gesetzt). Anschließend wird die Suchanfrage ausgeführt und eine Response an das PVS zurückgeschickt.

  3. Der Request des PVS wird mit dem HTTP-Statuscode 200 OK und einem Response Body beantwortet, der ein Searchset Bundle mit folgenden Informationen enthält:

    • Bundle.total hat den Wert 24.

    • Bundle.link hat 2 Einträge:

      • einen mit <relation value="self" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr1,bsnr2,bsnr3]&page=1&_count=10 />

      • einen mit <relation value="next" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr1,bsnr2,bsnr3]&page=2&_count=10 />

    • Bundle.entry enthält insgesamt 10 Einträge mit den tatsächlichen Suchergebnissen (bspw. Appointments) sowie weitere Einträge mit Ressourcen, die in den tatsächlichen Suchergebnissen referenziert werden (bspw. Patients). (Welche Ressourcen im Searchset Bundle inkludiert sind, ist den einzelnen Unterseiten zu den search interactions oder der Seite Profil: Suchergebnisse (Bundle) zu entnehmen.)

  4. Das PVS prüft, ob der Wert des Elementes Bundle.total größer als 0 ist. Da dies der Fall ist, prüft das PVS anschließend, ob das Element Bundle.entry im Response Body existiert. Da auch dies der Fall ist, speichert das PVS die Ressourcen, die in den Einträgen des Elementes Bundle.entry enthalten sind:

    • Ressourcen, die noch nicht im PVS vorhanden sind, müssen im PVS neu erstellt werden.

    • Ressourcen, die bereits im PVS vorhanden sind, müssen im PVS überschrieben werden.

  5. Das PVS registriert, dass es (mindestens) eine weitere Seite mit Suchergebnissen gibt, da ein Eintrag mit dem Wert next im Element Bundle.link.relation existiert.

  6. Während das PVS die Response auf den ersten Request verarbeitet, werden im 116117 Terminservice 3 Ressourcen gelöscht.

  7. Das PVS schickt einen weiteren Request an den 116117 Terminservice. Der Request Body enthält den Suchparameter page=2.

  8. Die Systeme des 116117 Terminservice stellen fest, dass der Request valide ist und verarbeiten diesen. Für den folgenden Suchparameter wird dabei der Standardwert eingesetzt: _count=10. Für den Suchparameter bsnr werden alle BSNRs gesetzt, die im Access Token enthalten sind. Anschließend wird die Suchanfrage ausgeführt und eine Response an das PVS zurückgeschickt.

  9. Der Request des PVS wird mit dem HTTP-Statuscode 200 OK und einem Response Body beantwortet, der ein Searchset Bundle mit folgenden Informationen enthält:

    • Bundle.total hat jetzt den Wert 21.

    • Bundle.link hat 3 Einträge:

      • einen mit <relation value="self" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr1,bsnr2,bsnr3]&page=2&_count=10 />

      • einen mit <relation value="next" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr1,bsnr2,bsnr3]&page=3&_count=10 />

      • einen mit <relation value="previous" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr1,bsnr2,bsnr3]&page=1&_count=10 />

    • Bundle.entry enthält insgesamt 10 Einträge mit den tatsächlichen Suchergebnissen sowie weitere Einträge mit Ressourcen, die in den tatsächlichen Suchergebnissen referenziert werden.

  10. Äquivalent zu Schritt 4 und 5 speichert das PVS die Ressourcen, die in den Einträgen des Elementes Bundle.entry enthalten sind und registriert, dass es (mindestens) eine weitere Seite mit Suchergebnissen gibt.

  11. Äquivalent zu Schritt 7 bis 9 schickt das PVS einen weiteren Request mit page=3 und bekommt den HTTP-Statuscode 200 OK und einen Response Body zurück, der ein Searchset Bundle mit folgenden Informationen enthält:

    • Bundle.total hat weiterhin den Wert 21.

    • Bundle.link hat 2 Einträge:

      • einen mit <relation value="self" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr1,bsnr2,bsnr3]&page=3&_count=10 />

      • einen mit <relation value="previous" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr1,bsnr2,bsnr3]&page=2&_count=10 />

    • Bundle.entry enthält insgesamt 1 Eintrag mit dem tatsächlichen Suchergebnis sowie weitere Einträge mit Ressourcen, die im tatsächlichen Suchergebnis referenziert werden.

  12. Äquivalent zu Schritt 4 speichert das PVS die Ressourcen, die in den Einträgen des Elementes Bundle.entry enthalten sind.

  13. Das PVS registriert, dass es keinen Verweis auf eine nächste Seite gibt, da KEIN Eintrag mit dem Wert next im Element Bundle.link.relation existiert. Da auf der aktuellen Seite aber Suchergebnisse vorhanden waren (siehe Schritt 12), weiß das PVS, dass kein weiterer Request notwendig und die Suche beendet ist.

Szenario: Zwischen zwei Abrufen verringert sich die Gesamtzahl der Suchergebnisse UND die Anzahl der befüllten Seiten.

  1. Das PVS ruft Ressourcen (bspw. Appointments) vom 116117 Terminservice ab. Der Request Body enthält folgende Suchparameter: page=1, _count=2 und bsnr mit der BSNR der Praxis sowie der BSNR einer Nebenbetriebsstätte der Praxis.

  2. Die Systeme des 116117 Terminservice stellen fest, dass der Request valide ist und verarbeiten diesen. Anschließend wird die Suchanfrage ausgeführt und eine Response an das PVS zurückgeschickt.

  3. Der Request des PVS wird mit dem HTTP-Statuscode 200 OK und einem Response Body beantwortet, der ein Searchset Bundle mit folgenden Informationen enthält:

    • Bundle.total hat den Wert 17.

    • Bundle.link hat 2 Einträge:

      • einen mit <relation value="self" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr1,bsnr2]&page=1&_count=2 />

      • einen mit <relation value="next" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr1,bsnr2]&page=2&_count=2 />

    • Bundle.entry enthält insgesamt 2 Einträge mit den tatsächlichen Suchergebnissen (bspw. Appointments) sowie weitere Einträge mit Ressourcen, die in den tatsächlichen Suchergebnissen referenziert werden (bspw. Patients). (Welche Ressourcen im Searchset Bundle inkludiert sind, ist den einzelnen Unterseiten zu den search interactions oder der Seite Profil: Suchergebnisse (Bundle) zu entnehmen.)

  4. Das PVS prüft, ob der Wert des Elementes Bundle.total größer als 0 ist. Da dies der Fall ist, prüft das PVS anschließend, ob das Element Bundle.entry im Response Body existiert. Da auch dies der Fall ist, speichert das PVS die Ressourcen, die in den Einträgen des Elementes Bundle.entry enthalten sind:

    • Ressourcen, die noch nicht im PVS vorhanden sind, müssen im PVS neu erstellt werden.

    • Ressourcen, die bereits im PVS vorhanden sind, müssen im PVS überschrieben werden.

  5. Das PVS registriert, dass es (mindestens) eine weitere Seite mit Suchergebnissen gibt, da ein Eintrag mit dem Wert next im Element Bundle.link.relation existiert.

  6. Äquivalent zu den oben beschriebenen Schritten 1 bis 5 ruft das PVS auch die Seiten 2 bis 8 mit Suchergebnissen ab.

  7. Während das PVS die Response auf den letzten Request (Seite 8 der Suchergebnisse) verarbeitet, werden im 116117 Terminservice 4 Ressourcen gelöscht.

  8. Das PVS schickt einen weiteren Request an den 116117 Terminservice. Der Request Body enthält folgende Suchparameter: page=9, _count=2 und bsnr mit der BSNR der Praxis sowie der BSNR einer Nebenbestriebsstätte der Praxis.

  9. Die Systeme des 116117 Terminservice stellen fest, dass der Request valide ist und verarbeiten diesen. Anschließend wird die Suchanfrage ausgeführt und eine Response an das PVS zurückgeschickt.

  10. Der Request des PVS wird mit dem HTTP-Statuscode 200 OK und einem Response Body beantwortet, der ein Searchset Bundle mit folgenden Informationen enthält:

    • Bundle.total hat jetzt den Wert 13.

    • Bundle.link hat 2 Einträge:

      • einen mit <relation value="self" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr1,bsnr2]&page=9&_count=2 />

      • einen mit <relation value="previous" /> und <url value=[baseURL]/[resourceType]?bsnr=[bsnr1,bsnr2]&page=8&_count=2 />

    • Das Element Bundle.entry existiert nicht im Response Body, da durch die Löschung der Ressourcen Seite 9 nicht mehr notwendig bzw. nicht mehr befüllt ist.

  11. Das PVS prüft, ob der Wert des Elementes Bundle.total größer als 0 ist. Da dies der Fall ist, prüft das PVS anschließend, ob das Element Bundle.entry im Response Body existiert. Da dies NICHT der Fall ist, weiß das PVS nun, dass die letzte befüllte Seite erneut abgerufen werden sollte.

  12. Das PVS berechnet die Seitenzahl der letzte befüllten Seite. Dazu teilt das PVS den Wert des Elementes Bundle.total durch den Wert des Suchparameters _count und rundet das Ergebnis auf, also: ⌈ 13 / 2 ⌉ = 7.

  13. Das PVS schickt einen weiteren Request an den 116117 Terminservice, um die letzte befüllte Seite der Suchergebnisse abzurufen. Der Request Body enthält folgende Suchparameter: page=7 (entsprechend der Berechnung aus Schritt 12), _count=2 und bsnr mit der BSNR der Praxis sowie der BSNR einer Nebenbestriebsstätte der Praxis.

  14. Die Verarbeitung des Requests durch den 116117 Terminservice sowie die Verarbeitung der Response durch das PVS verlaufen äquivalent zu den oben beschriebenen Schritten 2 bis 4.

  15. Das PVS registriert, dass es keinen Verweis auf eine nächste Seite gibt, da KEIN Eintrag mit dem Wert next im Element Bundle.link.relation existiert. Da auf der aktuellen Seite aber Suchergebnisse vorhanden waren (siehe Schritt 14), weiß das PVS, dass kein weiterer Request notwendig und die Suche beendet ist.