Die FHIR-Suche der Cloud Healthcare API ist hochgradig skalierbar und leistungsfähig und entspricht gleichzeitig den Richtlinien und Einschränkungen von REST und der FHIR-Spezifikation. Dazu bietet die FHIR-Suche die folgenden Eigenschaften:
Die Gesamtzahl der Suchergebnisse ist eine Schätzung, bis die letzte Seite zurückgegeben wird. Die von der Methode
fhir.searchzurückgegebenen Suchergebnisse enthalten die Gesamtzahl der Suchanfragen (EigenschaftBundle.total), also die Gesamtzahl der Übereinstimmungen bei der Suche. Die Gesamtzahl der Suchanfragen ist eine Schätzung, bis die letzte Seite der Suchergebnisse zurückgegeben wird. Die mit der letzten Suchergebnisseite zurückgegebene Gesamtzahl ist eine genaue Summe aller Übereinstimmungen in der Suche.Die Suchergebnisse bieten eine sequenzielle, vorwärtsgerichtete Paginierung. Wenn weitere Suchergebnisse zurückgegeben werden sollen, enthält die Antwort eine Paginierungs-URL (
Bundle.link.url), über die die nächste Ergebnisseite abgerufen werden kann.
Grundlegende Anwendungsfälle
Die FHIR-Suche bietet Lösungen für die folgenden Anwendungsfälle:
- Der Reihe nach durchgehen Ein Nutzer blättert sequenziell durch eine begrenzte Anzahl von Suchergebnisseiten. Auf jeder Seite wird eine geschätzte Gesamtzahl der Suchanfragen zurückgegeben.
- Suchergebnisse verarbeiten Eine App ruft eine Reihe von Suchergebnissen ab, liest sie durch und verarbeitet die Daten.
In den folgenden Abschnitten finden Sie mögliche Lösungen für diese Anwendungsfälle.
Sequenziell durchsuchen
Sie können eine Anwendung mit geringer Latenz erstellen, mit der Nutzer sequenziell durch die Seiten mit Ergebnissen blättern können, bis sie die gewünschte Übereinstimmung finden. Diese Lösung ist möglich, wenn die Anzahl der Übereinstimmungen so gering ist, dass der Nutzer die gewünschte Übereinstimmung finden kann, indem er Seite für Seite durch die Ergebnisse blättert, ohne Ergebnisse zu überspringen. Wenn Nutzer in Ihrem Anwendungsfall mehrere Seiten gleichzeitig vor- oder zurückspringen müssen, lesen Sie den Hilfeartikel Zur nächsten Seite springen.
Mit dieser Lösung kann erst eine genaue Suchanzahl angegeben werden, wenn die letzte Seite der Ergebnisse zurückgegeben wurde. Auf jeder Suchergebnisseite wird jedoch eine ungefähre Gesamtzahl der Ergebnisse angezeigt. Während eine genaue Suchanzahl für einen Hintergrundprozess erforderlich sein kann, ist für einen Nutzer in der Regel eine ungefähre Suchanzahl ausreichend.
Workflow
Hier ist ein Beispiel für einen Workflow für diese Lösung:
Eine App ruft die Methode
fhir.searchauf, die die erste Suchergebnisseite zurückgibt. Die Antwort enthält eine Paginierungs-URL (Bundle.link.url), wenn weitere Ergebnisse zurückgegeben werden können. Die Antwort enthält auch die Gesamtzahl der Suchergebnisse (Bundle.total). Wenn mehr Ergebnisse zurückgegeben werden als in der ursprünglichen Antwort, ist die Gesamtzahl der Suchergebnisse nur eine Schätzung. Weitere Informationen finden Sie unter Paginierung und Sortierung.Die App zeigt die Suchergebnisseite, einen Link zur nächsten Suchergebnisseite (falls vorhanden) und die Gesamtzahl der Suchergebnisse an.
Wenn der Nutzer die nächste Ergebnisseite aufrufen möchte, klickt er auf den Link. Dies führt zu einem Aufruf der Paginierungs-URL. Die Antwort enthält eine neue Paginierungs-URL, wenn weitere Ergebnisse zurückgegeben werden können. Die Antwort enthält auch die Gesamtzahl der Suchanfragen. Dies ist eine aktualisierte Schätzung, wenn noch weitere Ergebnisse zurückgegeben werden können.
Die App zeigt die neue Seite der Suchergebnisse, einen Link zur nächsten Seite der Ergebnisse (falls vorhanden) und die Gesamtzahl der Suchergebnisse an.
Die beiden vorherigen Schritte werden wiederholt, bis der Nutzer die Suche beendet oder die letzte Ergebnisseite zurückgegeben wird.
Best Practice
Wählen Sie eine Seitengröße aus, die für Menschen problemlos lesbar ist. Je nach Anwendungsfall können das 10 bis 20 Übereinstimmungen pro Seite sein. Kleinere Seiten werden schneller geladen und zu viele Links auf einer Seite können für Nutzer schwierig zu verwalten sein. Die Seitengröße wird über den Parameter _count gesteuert.
Suchergebnisse verarbeiten
Sie können eine Reihe von Suchergebnissen abrufen, indem Sie die Methode fhir.search mit der Paginierungs-URL mehrmals aufrufen. Wenn die Anzahl der Suchergebnisse gering genug ist, können Sie alle Ergebnisse abrufen, indem Sie so lange fortfahren, bis keine Seiten mehr zurückgegeben werden. Auf der letzten Ergebnisseite wird die genaue Anzahl der Suchanfragen angezeigt. Nachdem die Suchergebnisse abgerufen wurden, kann Ihre App sie lesen und die erforderliche Verarbeitung, Analyse oder Aggregation ausführen.
Wenn Sie eine sehr große Anzahl von Suchergebnissen haben, ist es möglicherweise nicht möglich, die letzte Seite der Suchergebnisse (und die genaue Suchanzahl) in einem angemessenen Zeitraum abzurufen.
Workflow
Hier ist ein Beispiel für einen Workflow für diese Lösung:
Die App ruft die Methode
fhir.searchauf, die die erste Suchergebnisseite zurückgibt. Die Antwort enthält eine Paginierungs-URL (Bundle.link.url), wenn weitere Ergebnisse zurückgegeben werden sollen.Wenn weitere Ergebnisse zurückgegeben werden sollen, ruft die App die Paginierungs-URL aus dem vorherigen Schritt auf, um die nächste Ergebnisseite abzurufen.
Die App wiederholt den vorherigen Schritt, bis keine Ergebnisse mehr zurückgegeben werden können oder ein anderes vordefiniertes Limit erreicht wird. Wenn Sie die letzte Seite der Suchergebnisse erreichen, ist die Gesamtzahl der Suchergebnisse korrekt.
Die App verarbeitet die Suchergebnisse.
Je nach Anwendungsfall kann Ihre App Folgendes tun:
- Warten Sie, bis alle Suchergebnisse eingegangen sind, bevor Sie die Daten verarbeiten.
- Daten bei jedem nachfolgenden Aufruf von
fhir.searchverarbeiten. - Legen Sie eine Art von Limit fest, z. B. die Anzahl der zurückgegebenen Übereinstimmungen oder die verstrichene Zeit. Wenn das Limit erreicht ist, können Sie die Daten verarbeiten, nicht verarbeiten oder eine andere Aktion ausführen.
Designoptionen
Hier sind einige Designoptionen, mit denen sich die Suchlatenz möglicherweise verringern lässt:
Legen Sie eine große Seitengröße fest. Verwenden Sie den Parameter
_count, um eine große Seitengröße festzulegen,z. B. 500 bis 1.000, je nach Anwendungsfall. Eine größere Seitengröße erhöht die Latenz für jeden Seitenabruf, kann aber den Gesamtprozess beschleunigen, da für die gesamte Anzahl der Suchergebnisse weniger Seitenabrufe erforderlich sind.Suchergebnisse einschränken Wenn Sie nur eine genaue Suchanzahl benötigen und keine Ressourceninhalte zurückgeben müssen, setzen Sie den Parameter
_elementsder Methodefhir.searchaufidentifier. Dies kann die Latenz Ihrer Suchanfrage im Vergleich zur Rückgabe der vollständigen FHIR-Ressourcen verringern. Weitere Informationen finden Sie unter Die in den Suchergebnissen zurückgegebenen Felder einschränken.
Anwendungsfälle, für die Prefetching und Caching erforderlich sind
Möglicherweise benötigen Sie Funktionen, die über den einfachen Mechanismus des aufeinanderfolgenden Aufrufs der fhir.search-Methode mithilfe von Paginierungs-URLs hinausgehen. Eine Möglichkeit besteht darin, eine Caching-Ebene zwischen Ihrer App und dem FHIR-Speicher zu erstellen, die den Sitzungsstatus beibehält, während Suchergebnisse vorab abgerufen und im Cache gespeichert werden.
Die App kann die Suchergebnisse in kleine „App-Seiten“ mit 10 oder 20 Übereinstimmungen gruppieren. Die App kann diese kleinen App-Seiten dann schnell und direkt, nicht sequenziell, basierend auf den Auswahlen des Nutzers bereitstellen. Ein Beispiel für diesen Workflow finden Sie unter Zu einer Seite in der Nähe wechseln.
Zu einer Seite in der Nähe wechseln
Sie können eine Lösung mit geringer Latenz entwickeln, mit der Nutzer eine große Anzahl von Suchergebnissen durchsuchen können, bis sie das gewünschte Ergebnis finden. Sie kann auf eine nahezu unbegrenzte Anzahl von Übereinstimmungen skaliert werden, wobei die Latenz niedrig bleibt und der Ressourcenverbrauch nur relativ geringfügig ansteigt. Ein Nutzer kann direkt zu einer Seite mit Suchergebnissen wechseln, bis zu einer festgelegten Anzahl von Seiten vorwärts oder rückwärts von der aktuellen Seite. Sie können auf jeder Suchergebnisseite eine geschätzte Gesamtzahl der Ergebnisse angeben. Dieses Design ähnelt dem Design der Google Suche.
Workflow
Abbildung 1 zeigt einen Beispiel-Workflow für diese Lösung. Bei diesem Workflow werden jedes Mal, wenn der Nutzer eine Ergebnisseite auswählt, Links zu den nächsten Seiten angezeigt. In diesem Fall enthält die App Links zu Seiten, die bis zu fünf Seiten von der ausgewählten Seite zurück und bis zu vier Seiten von der ausgewählten Seite vor liegen. Damit die vier Seiten nach vorne angezeigt werden können, werden in der App 40 zusätzliche Übereinstimmungen im Voraus abgerufen, wenn der Nutzer eine Ergebnisseite auswählt.
Abbildung 1. Die App gruppiert die Suchergebnisse in „App-Seiten“, die im Cache gespeichert und dem Nutzer zur Verfügung gestellt werden.
Abbildung 1 veranschaulicht diese Schritte:
Der Nutzer gibt eine Suchanfrage in das App-Frontend ein und löst damit die folgenden Aktionen aus:
Die App ruft die Methode
fhir.searchauf, um die erste Seite der Suchergebnisse vorab abzurufen.Der Parameter
_countist auf 100 festgelegt, um die Seitengröße der Antwort relativ klein zu halten, was zu relativ kurzen Antwortzeiten führt. Die Antwort enthält eine Paginierungs-URL (Bundle.link.url), wenn weitere Ergebnisse zurückgegeben werden können. Die Antwort enthält auch die Gesamtzahl der Suchanfragen (Bundle.total). Die Gesamtzahl der Suchanfragen ist eine Schätzung, wenn weitere Ergebnisse zurückgegeben werden können. Weitere Informationen finden Sie unter Paginierung und Sortierung.Die App sendet die Antwort an die Caching-Ebene.
In der Caching-Ebene gruppiert die App die 100 Übereinstimmungen aus der Antwort in 10 App-Seiten mit jeweils 10 Übereinstimmungen. Eine App-Seite ist eine kleine Gruppe von Übereinstimmungen, die der App angezeigt werden können.
Die App zeigt dem Nutzer die App-Seite 1 an. Die App-Seite 1 enthält Links zu den App-Seiten 2–10 und die geschätzte Gesamtzahl der Suchanfragen.
Der Nutzer klickt auf einen Link zu einer anderen App-Seite (in diesem Beispiel App-Seite 10). Dadurch werden die folgenden Aktionen ausgelöst:
Die App ruft die Methode
fhir.searchmit der Paginierungs-URL auf, die mit dem vorherigen Prefetch zurückgegeben wurde, um die nächste Seite mit Suchergebnissen vorab abzurufen.Der Parameter
_countist auf „40“ festgelegt, um die nächsten 40 Übereinstimmungen aus der Suchanfrage des Nutzers vorab abzurufen. Die 40 Übereinstimmungen beziehen sich auf die nächsten vier App-Seiten, die der Nutzer in der App sieht.Die App sendet die Antwort an die Caching-Ebene.
In der Caching-Ebene gruppiert die App die 40 Übereinstimmungen aus der Antwort in vier App-Seiten mit jeweils 10 Übereinstimmungen.
Die App zeigt dem Nutzer die App-Seite 10 an. App-Seite 10 enthält Links zu den App-Seiten 5–9 (die fünf App-Seiten vor App-Seite 10) und zu den App-Seiten 11–14 (die vier App-Seiten nach App-Seite 10). Auf App-Seite 10 ist auch die geschätzte Gesamtzahl der Suchanfragen zu sehen.
Das kann so lange fortgesetzt werden, wie der Nutzer weiterhin auf Links zu App-Seiten klicken möchte. Wenn der Nutzer von der aktuellen App-Seite zurückgeht und Sie alle nahe gelegenen App-Seiten bereits im Cache haben, können Sie je nach Anwendungsfall einen neuen Prefetch ausführen.
Diese Lösung ist aus folgenden Gründen schnell und effizient:
- Kleine Prefetches und noch kleinere App-Seiten werden schnell verarbeitet.
- Durch die Caching-Suchergebnisse müssen nicht mehrere Abrufe für dieselben Ergebnisse durchgeführt werden.
- Der Mechanismus bleibt unabhängig von der Anzahl der Suchergebnisse schnell.
Designoptionen
Je nach Anwendungsfall können Sie folgende Designoptionen in Betracht ziehen:
App-Seitengröße Ihre App-Seiten können mehr als 10 Übereinstimmungen enthalten, wenn dies für Ihren Anwendungsfall geeignet ist. Denken Sie daran, dass kleinere Seiten schneller geladen werden und zu viele Links auf einer Seite für Nutzer schwierig zu verwalten sein können.
Anzahl der Links auf der App-Seite Im hier vorgeschlagenen Workflow gibt jede App-Seite neun Links zu anderen App-Seiten zurück: fünf Links zu den App-Seiten, die direkt von der aktuellen App-Seite aus zurückgehen, und vier Links zu den Seiten, die direkt von der aktuellen App-Seite aus vorgehen. Sie können diese Zahlen an Ihren Anwendungsfall anpassen.
Best Practices
Verwenden Sie die Caching-Ebene nur bei Bedarf. Wenn Sie eine Caching-Ebene einrichten, verwenden Sie sie nur, wenn Ihr Anwendungsfall dies erfordert. Suchanfragen, für die die Caching-Ebene nicht erforderlich ist, sollten sie umgehen.
Reduzieren Sie die Größe des Caches. Um Ressourcen zu sparen, können Sie die Größe des Caches verringern, indem Sie alte Suchergebnisse löschen, aber die Seiten-URLs beibehalten, mit denen Sie die Ergebnisse abgerufen haben. Sie können den Cache dann bei Bedarf neu erstellen, indem Sie die Seiten-URLs aufrufen. Beachten Sie, dass sich die Ergebnisse mehrerer Aufrufe derselben Paginierungs-URL im Laufe der Zeit ändern können, da Ressourcen im FHIR-Speicher im Hintergrund erstellt, aktualisiert und gelöscht werden. Ob, wie und wie oft der Cache geleert werden soll, sind Designentscheidungen, die vom jeweiligen Anwendungsfall abhängen.
Cache für eine bestimmte Suche leeren Um Ressourcen zu sparen, können Sie die Ergebnisse inaktiver Suchanfragen vollständig aus dem Cache entfernen. Entfernen Sie zuerst die Suchanfragen, die am längsten inaktiv waren. Wenn eine gelöschte Suche wieder aktiv wird, kann dies zu einem Fehlerstatus führen, der die Caching-Ebene dazu zwingt, die Suche neu zu starten.
Eine beliebige Seite aufrufen
Wenn Nutzer jede Seite in den Suchergebnissen aufrufen können sollen, nicht nur die Seiten in der Nähe der aktuellen Seite, können Sie eine Caching-Ebene verwenden, die der in Zur nächsten Seite wechseln beschriebenen ähnelt. Damit Nutzer jedoch jede App-Seite mit Suchergebnissen aufrufen können, müssen alle Suchergebnisse vorab abgerufen und im Cache gespeichert werden. Bei einer relativ geringen Anzahl von Suchergebnissen ist das möglich. Bei einer sehr großen Anzahl von Suchergebnissen ist es möglicherweise nicht praktikabel oder unmöglich, alle vorab zu laden. Selbst bei einer geringen Anzahl von Suchergebnissen kann der Prefetch-Vorgang länger dauern, als ein Nutzer zu warten bereit ist.
Workflow
Richten Sie einen Workflow ein, der dem Workflow Zu einer Seite in der Nähe wechseln ähnelt, mit folgendem wichtigen Unterschied: Die App lädt Suchergebnisse im Hintergrund weiter vorab, bis alle Übereinstimmungen zurückgegeben wurden oder ein anderes vordefiniertes Limit erreicht wird.
Hier ist ein Beispiel für einen Workflow für diese Lösung:
Die App ruft die Methode
fhir.searchauf, um die erste Suchergebnisseite aus der Suchanfrage des Nutzers vorab abzurufen. Die Antwort enthält eine Paginierungs-URL (Bundle.link.url), wenn weitere Ergebnisse zurückgegeben werden sollen. Die Antwort enthält auch die Gesamtzahl der Suchergebnisse (Bundle.total). Dies ist eine Schätzung, wenn weitere Ergebnisse zurückgegeben werden.Die App gruppiert die Übereinstimmungen aus der Antwort auf App-Seiten mit jeweils 20 Übereinstimmungen und speichert sie im Cache. Eine App-Seite ist eine kleine Gruppe von Übereinstimmungen, die der App angezeigt werden können.
Die App zeigt dem Nutzer die erste App-Seite an. Die App-Seite enthält Links zu den im Cache gespeicherten App-Seiten und die geschätzte Gesamtzahl der Suchanfragen.
Wenn weitere Ergebnisse zurückgegeben werden sollen, geschieht Folgendes:
- Ruft die Paginierungs-URL auf, die vom vorherigen Prefetch zurückgegeben wurde, um die nächste Seite mit Suchergebnissen abzurufen.
- Gruppiert die Übereinstimmungen aus der Antwort auf App-Seiten mit jeweils 20 Übereinstimmungen und speichert sie im Cache.
- Die App-Seite, die der Nutzer gerade aufruft, wird mit neuen Links zu den neu vorab abgerufenen und im Cache gespeicherten App-Seiten aktualisiert.
Die App wiederholt den vorherigen Schritt, bis keine Ergebnisse mehr zurückgegeben werden können oder ein anderes vordefiniertes Limit erreicht wird. Eine genaue Suchanzahl wird mit der letzten Seite der Suchergebnisse zurückgegeben.
Während die App im Hintergrund Vorab-Suchanfragen ausführt und Ergebnisse im Cache speichert, kann der Nutzer weiterhin auf Links zu im Cache gespeicherten Seiten klicken.
Designoptionen
Je nach Anwendungsfall können Sie folgende Designoptionen in Betracht ziehen:
App-Seitengröße Ihre App-Seiten können mehr oder weniger als 20 Übereinstimmungen enthalten, je nach Anwendungsfall. Beachten Sie, dass kleinere Seiten schneller geladen werden und zu viele Links auf einer Seite für Nutzer schwierig zu bewältigen sein können.
Aktualisieren Sie die Gesamtzahl der Suchanfragen. Während Ihre App Suchergebnisse im Hintergrund im Voraus lädt und im Cache speichert, können Sie dem Nutzer zunehmend genauere Suchergebnisse anzeigen. Konfigurieren Sie dazu Ihre App so, dass
Die Gesamtzahl der Suchanfragen (
Bundle.total-Property) wird in einem festgelegten Intervall aus dem letzten Prefetch in der Caching-Ebene abgerufen. Dies ist die aktuell beste Schätzung der Gesamtzahl der Suchanfragen. Zeigen Sie dem Nutzer die Suchsumme an und geben Sie an, dass es sich um eine Schätzung handelt. Legen Sie die Häufigkeit dieser Aktualisierung entsprechend Ihrem Anwendungsfall fest.Erkennen, wann die Suchsumme aus der Caching-Ebene korrekt ist Die Gesamtzahl der Suchanfragen bezieht sich also auf die letzte Suchergebnisseite. Wenn die letzte Seite der Suchergebnisse erreicht ist, zeigt die App die Gesamtzahl der Suchergebnisse an und informiert den Nutzer, dass diese korrekt ist. Die App erhält dann keine Suchsummen mehr aus der Caching-Ebene.
Bei einer großen Anzahl von Übereinstimmungen wird die letzte Seite der Suchergebnisse und die genaue Anzahl der Suchergebnisse möglicherweise nicht durch das Vorabladen im Hintergrund und das Caching erreicht, bevor der Nutzer die Suchsitzung beendet.
Best Practices
Enthaltene Ressourcen deduplizieren Wenn Sie die Parameter
_includeund_revincludebeim Vorabladen und Caching von Suchergebnissen verwenden, empfehlen wir, die enthaltenen Ressourcen im Cache nach jedem Vorabladen zu deduplizieren. Dadurch wird der Arbeitsspeicher gespart, da die Größe des Caches reduziert wird. Wenn Sie Übereinstimmungen in App-Seiten gruppieren, fügen Sie jeder App-Seite die entsprechenden enthaltenen Ressourcen hinzu. Weitere Informationen finden Sie unter Zusätzliche Ressourcen in Suchergebnisse einbeziehen.Legen Sie ein Limit für das Vorabladen und Caching fest. Bei einer sehr großen Anzahl von Suchergebnissen ist es möglicherweise nicht praktikabel oder unmöglich, alle vorab zu laden. Wir empfehlen, die Anzahl der Suchergebnisse, die vorab abgerufen werden sollen, zu begrenzen. So bleibt der Cache überschaubar und Sie sparen Arbeitsspeicher. Sie können die Cache-Größe beispielsweise auf 10.000 oder 20.000 Übereinstimmungen begrenzen. Alternativ können Sie die Anzahl der Seiten begrenzen, die vorab geladen werden sollen, oder ein Zeitlimit festlegen, nach dem das Vorabladen beendet wird. Die Art der Beschränkung und die Art und Weise, wie Sie sie einführen, sind Designentscheidungen, die vom jeweiligen Anwendungsfall abhängen. Wenn das Limit erreicht wird, bevor alle Suchergebnisse zurückgegeben wurden, sollten Sie den Nutzer darüber informieren und darauf hinweisen, dass die Gesamtzahl der Suchanfragen weiterhin eine Schätzung ist.
Frontend-Caching
Das Anwendungs-Frontend, z. B. ein Webbrowser oder eine mobile App, kann ein gewisses Caching der Suchergebnisse als Alternative zur Einführung einer Caching-Ebene in die Architektur bereitstellen. Mit diesem Ansatz können Sie die vorherige Seite oder eine beliebige Seite im Navigationsverlauf aufrufen, indem Sie AJAX-Aufrufe verwenden und Suchergebnisse und/oder Paginierungs-URLs speichern. Hier sind einige Vorteile dieses Ansatzes:
- Sie kann weniger ressourcenintensiv sein als eine Caching-Ebene.
- Es ist skalierbarer, da die Caching-Arbeit auf viele Clients verteilt wird.
- Es ist einfacher zu ermitteln, wann zwischengespeicherte Ressourcen nicht mehr benötigt werden, z. B. wenn der Nutzer einen Tab schließt oder die Suchoberfläche verlässt.
Allgemeine Best Practices
Im Folgenden finden Sie einige Best Practices, die für alle Lösungen in diesem Dokument gelten.
Planen Sie, dass Seiten kleiner als der Wert für „_count“ sind. Unter Umständen werden bei einer Suche Seiten zurückgegeben, die weniger Übereinstimmungen als der von Ihnen angegebene Wert
_countenthalten. Das kann beispielsweise passieren, wenn Sie eine besonders große Seitengröße angeben. Wenn Ihre Suche eine Seite zurückgibt, die kleiner als der Wert von_countist, und Ihre App eine Caching-Ebene verwendet, müssen Sie möglicherweise entscheiden, ob (1) weniger Ergebnisse als erwartet auf einer App-Seite angezeigt werden sollen oder (2) einige weitere Ergebnisse abgerufen werden sollen, um eine vollständige App-Seite zu erhalten. Weitere Informationen finden Sie unter Paginierung und Sortierung.Wiederholen Sie HTTP-Anfragefehler, die wiederholt werden können. Ihre App sollte mit wiederholbaren HTTP-Anfragefehlern wie
429oder500rechnen und nach Erhalt einen neuen Versuch starten.
Anwendungsfälle bewerten
Wenn Sie Funktionen wie das Wechseln zu einer beliebigen Seite, das Abrufen genauer Suchergebnisse und das Aktualisieren der geschätzten Gesamtzahl implementieren, erhöhen sich die Komplexität und die Entwicklungskosten Ihrer App. Außerdem können diese Funktionen die Latenz erhöhen und die Kosten für die Nutzung von Google Cloud-Ressourcen steigen. Wir empfehlen Ihnen, Ihre Anwendungsfälle sorgfältig zu prüfen, um sicherzustellen, dass der Wert dieser Funktionen die Kosten rechtfertigt. Beachten Sie dabei Folgendes:
Auf eine beliebige Seite zugreifen Ein Nutzer muss in der Regel nicht viele Seiten von der aktuellen Seite aus auf eine bestimmte Seite zugreifen. In den meisten Fällen reicht es aus, zu einer nahe gelegenen Seite zu wechseln.
Genaue Suchanfragen insgesamt Die Gesamtzahl der Suchanfragen kann sich ändern, wenn Ressourcen im FHIR-Speicher erstellt, aktualisiert und gelöscht werden. Aus diesem Grund ist die Gesamtzahl der Suchanfragen zum Zeitpunkt der Rückgabe (mit der letzten Seite der Suchergebnisse) korrekt, aber sie kann sich im Laufe der Zeit ändern. Daher sind genaue Suchsummen je nach Anwendungsfall möglicherweise nur von begrenztem Wert für Ihre App.