Die Implementierung der FHIR-Suche in der Cloud Healthcare API ist äußerst skalierbar und leistungsstark. Dabei werden weiterhin die Richtlinien und Einschränkungen von REST und der FHIR-Spezifikation eingehalten. Um dies zu erreichen, hat die FHIR-Suche die folgenden Eigenschaften:
Die Suchsumme ist eine Schätzung, bis die letzte Seite zurückgegeben wird. Die von der Methode
fhir.searchzurückgegebenen Suchergebnisse enthalten die Gesamtsumme der Suche (das AttributBundle.total). Dies ist die Gesamtzahl der Übereinstimmungen in der Suche. Die Suchsumme ist eine Schätzung, bis die letzte Seite mit Suchergebnissen zurückgegeben wird. Die auf der letzten Ergebnisseite zurückgegebene Suchsumme ist eine genaue Summe aller Übereinstimmungen in der Suche.Suchergebnisse ermöglichen eine sequenzielle Vorwärtspaginierung. Wenn mehr 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:
- Suche der Reihe nach. Ein Nutzer blättert nacheinander durch eine begrenzte Anzahl von Seiten mit Suchergebnissen. Für jede Seite wird eine geschätzte Gesamtsuchanfrage zurückgegeben.
- Einen Satz von Suchergebnissen verarbeiten. Eine Anwendung ruft eine Reihe von Suchergebnissen ab, liest die Ergebnisse durch und verarbeitet die Daten.
In den folgenden Abschnitten finden Sie mögliche Lösungen für diese Anwendungsfälle.
Sequenzielles Durchsuchen
Sie können eine Anwendung mit niedriger Latenz erstellen, mit der ein Nutzer sequenziell durch die Ergebnisseiten blättern kann, bis er die gewünschte Übereinstimmung gefunden hat. Diese Lösung ist möglich, wenn die Anzahl der Übereinstimmungen so gering ist, dass der Nutzer die gewünschte Übereinstimmung durch seitenweises Durchsuchen der Seite finden kann, ohne die Ergebnisse zu überspringen. Wenn Nutzer in Ihrem Anwendungsfall mehrere Seiten gleichzeitig vorwärts oder rückwärts navigieren müssen, lesen Sie die Informationen unter Zu einer Seite in der Nähe navigieren.
Diese Lösung kann erst dann eine genaue Summe der Suchergebnisse liefern, wenn die letzte Ergebnisseite zurückgegeben wird. Sie kann jedoch eine ungefähre Anzahl von Suchanfragen mit jeder Ergebnisseite angeben. Während eine genaue Suchsumme eine Voraussetzung für einen Hintergrundprozess sein kann, reicht eine ungefähre Gesamtsumme der Suchanfragen für einen menschlichen Nutzer in der Regel aus.
Workflow
Hier ist ein Beispiel-Workflow für diese Lösung:
Eine App ruft die Methode
fhir.searchauf, die die erste Seite mit Suchergebnissen zurückgibt. Die Antwort enthält eine Paginierungs-URL (Bundle.link.url), wenn weitere Ergebnisse zurückgegeben werden sollen. Die Antwort enthält auch die Suchsumme (Bundle.total). Wenn es mehr Ergebnisse als in der ersten Antwort gibt, handelt es sich bei der Summe nur um eine Schätzung. Weitere Informationen finden Sie unter Seitenumbruch und Sortieren.Die Anwendung zeigt die Seite mit den Suchergebnissen, einen Link zur nächsten Ergebnisseite (falls vorhanden) und die Gesamtsumme der Suche an.
Wenn der Nutzer die nächste Ergebnisseite sehen möchte, klickt er auf den Link. Dadurch wird die Paginierungs-URL aufgerufen. Die Antwort enthält eine neue Paginierungs-URL, wenn weitere Ergebnisse zurückgegeben werden sollen. Die Antwort enthält auch die Summe der Suchanfragen. Dies ist eine aktualisierte Schätzung, wenn weitere Ergebnisse zurückgegeben werden können.
Die Anwendung zeigt die neue Seite der Suchergebnisse, einen Link zur nächsten Ergebnisseite (falls vorhanden) und die Gesamtsumme der Suche 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, die für Menschen geeignet ist, um sie ohne Schwierigkeiten zu lesen. Je nach Anwendungsfall können dies 10 bis 20 Übereinstimmungen pro Seite sein. Kleinere Seiten werden schneller geladen und zu viele Links auf einer Seite können für einen Nutzer schwierig zu verwalten sein. Die Seitengröße legen Sie mit dem Parameter _count fest.
Eine Gruppe von Suchergebnissen verarbeiten
Sie können eine Reihe von Suchergebnissen abrufen, indem Sie die Methode fhir.search mit der Paginierungs-URL nacheinander aufrufen. Wenn die Anzahl der Suchergebnisse klein genug ist, erhalten Sie einen vollständigen Satz von Ergebnissen, indem Sie fortfahren, bis keine Seiten mehr zurückgegeben werden. Eine genaue Summe der Suchergebnisse ist auf der letzten Ergebnisseite enthalten. Nachdem die Suchergebnisse abgerufen wurden, kann Ihre Anwendung diese durchlesen und die von Ihnen benötigte Verarbeitung, Analyse oder Zusammenfassung durchführen.
Wenn Sie eine sehr große Anzahl von Suchergebnissen haben, ist es unter Umständen nicht möglich, die letzte Seite der Suchergebnisse (und die genaue Gesamtsumme der Suche) in einem sinnvollen Zeitraum abzurufen.
Workflow
Hier ist ein Beispiel-Workflow für diese Lösung:
Die Anwendung ruft die Methode
fhir.searchauf, die die erste Seite mit Suchergebnissen zurückgibt. Die Antwort enthält eine Paginierungs-URL (Bundle.link.url), wenn weitere Ergebnisse zurückgegeben werden sollen.Wenn mehr Ergebnisse zurückgegeben werden sollen, ruft die Anwendung die Paginierungs-URL aus dem vorherigen Schritt auf, um die nächste Suchergebnisseite abzurufen.
Die Anwendung wiederholt den vorherigen Schritt, bis keine weiteren Ergebnisse mehr zurückgegeben werden oder ein anderes vordefiniertes Limit erreicht ist. Wenn Sie die letzte Seite der Suchergebnisse erreichen, ist die Summe der Suchergebnisse korrekt.
Die App verarbeitet die Suchergebnisse.
Je nach Anwendungsfall kann Ihre Anwendung eine der folgenden Aktionen ausführen:
- Warten Sie, bis alle Suchergebnisse eingegangen sind, bevor Sie die Daten verarbeiten.
- Daten bei jedem aufeinanderfolgenden Aufruf von
fhir.searchso verarbeiten, wie sie empfangen werden. - Legen Sie ein 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, sie aber nicht verarbeiten, oder andere Aktionen ausführen.
Designoptionen
Hier sind einige Designoptionen, die die Suchlatenz verringern können:
Legen Sie eine große Seitengröße fest. Verwenden Sie den Parameter
_count, um eine große Seitengröße festzulegen,z. B. zwischen 500 und 1.000, je nach Anwendungsfall. Bei einer größeren Seitengröße erhöht sich die Latenz für jeden Seitenabruf, unter Umständen aber auch den gesamten Vorgang, da weniger Seitenabrufe erforderlich sind, um alle Suchergebnisse zu erhalten.Schränken Sie die Suchergebnisse ein. Wenn Sie lediglich eine genaue Gesamtsumme der Suche benötigen (Sie müssen keine Ressourceninhalte zurückgeben), setzen Sie den Parameter
_elementsder Methodefhir.searchaufidentifier. Dies kann die Latenz Ihrer Suchanfrage im Vergleich zur Anforderung der Rückgabe vollständiger FHIR-Ressourcen verringern. Weitere Informationen finden Sie unter In Suchergebnissen zurückgegebene Felder beschränken.
Anwendungsfälle, die Prefetch und Caching erfordern
Mit dem einfachen Mechanismus zum aufeinanderfolgenden Aufrufen der Methode fhir.search mithilfe von Paginierungs-URLs benötigen Sie möglicherweise zusätzliche Funktionen. Eine Möglichkeit besteht darin, eine Caching-Ebene zwischen Ihrer Anwendung und dem FHIR-Speicher zu erstellen, die den Sitzungsstatus beibehält, während die Suchergebnisse vorab abgerufen und im Cache gespeichert werden.
Die App kann die Suchergebnisse in kleine "App-Seiten" mit zehn oder 20 Übereinstimmungen gruppieren. Die Anwendung kann dem Nutzer dann diese kleinen Anwendungsseiten basierend auf der Auswahl des Nutzers direkt und nicht sequenziell bereitstellen. Ein Beispiel für diese Art von Workflow finden Sie unter Seite in der Nähe aufrufen.
Seite in der Nähe aufrufen
Sie können eine Lösung mit niedriger Latenz erstellen, mit der ein Nutzer eine große Anzahl von Suchergebnissen durchsuchen kann, bis er die gesuchte Übereinstimmung findet. Es kann auf eine praktisch unbegrenzte Anzahl von Übereinstimmungen skaliert werden. Dabei wird die Latenz niedrig gehalten und der Ressourcenverbrauch steigt relativ gering. Ein Nutzer kann direkt zu einer Suchergebnisseite wechseln, und zwar bis zu einer vorgegebenen Anzahl von Seiten, die von der aktuellen Seite aus vorwärts oder rückwärts angezeigt werden. Für jede Ergebnisseite können Sie eine geschätzte Gesamtsuchsumme angeben. Dieses Design ähnelt dem Design für die Google-Suche.
Workflow
Abbildung 1 zeigt einen Beispielworkflow für diese Lösung. Bei diesem Workflow stellt die App jedes Mal, wenn der Nutzer eine Ergebnisseite zur Ansicht auswählt, Links zu Seiten in der Nähe bereit. In diesem Fall bietet die Anwendung Links zu Seiten, die bis zu fünf Seiten von der ausgewählten Seite zurück und bis zu vier Seiten vorwärts von der ausgewählten Seite sind. Um die vier vorwärts gerichteten Seiten zum Anzeigen verfügbar zu machen, ruft die App 40 zusätzliche Übereinstimmungen im Voraus ab, wenn der Nutzer eine Seite mit Ergebnissen auswählt.
Abbildung 1. Die Anwendung gruppiert 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 im Front-End der Anwendung ein und initiiert die folgenden Aktionen:
Die App ruft die Methode
fhir.searchauf, um die erste Seite der Suchergebnisse vorab abzurufen.Der Parameter
_countwird auf 100 gesetzt, um die Seitengröße der Antwort relativ klein zu halten. Dies führt zu relativ schnellen Antwortzeiten. Die Antwort enthält eine Paginierungs-URL (Bundle.link.url), wenn weitere Ergebnisse zurückgegeben werden sollen. Die Antwort enthält auch die Suchsumme (Bundle.total). Diese ist eine Schätzung, falls weitere Ergebnisse zurückgegeben werden können. Weitere Informationen finden Sie unter Paginierung und Sortierung.Die Anwendung sendet die Antwort an die Caching-Ebene.
In der Caching-Ebene gruppiert die Anwendung die 100 Übereinstimmungen aus der Antwort in 10 Anwendungsseiten mit je 10 Übereinstimmungen. Eine App-Seite ist eine kleine Gruppe von Übereinstimmungen, die die App dem Nutzer anzeigen kann.
Die App zeigt dem Nutzer Seite 1 der App an. App-Seite 1 enthält Links zu den App-Seiten 2 bis 10 sowie die geschätzte Gesamtsuchzahl.
Der Nutzer klickt auf einen Link zu einer anderen App-Seite (in diesem Beispiel App-Seite 10) und ruft folgende Aktionen auf:
Die App ruft die Methode
fhir.searchunter Verwendung der Paginierungs-URL auf, die mit dem vorherigen Prefetch zurückgegeben wurde, um die nächste Seite der Suchergebnisse vorab abzurufen.Der Parameter
_countwird auf 40 gesetzt, um die nächsten 40 Übereinstimmungen aus der Suchanfrage des Nutzers vorab abzurufen. Die 40 Übereinstimmungen gelten für die nächsten vier App-Seiten, die die App dem Nutzer zur Verfügung stellt.Die Anwendung sendet die Antwort an die Caching-Ebene.
In der Caching-Ebene gruppiert die Anwendung die 40 Übereinstimmungen aus der Antwort in vier Anwendungsseiten mit je 10 Übereinstimmungen.
Die App zeigt dem Nutzer Seite 10 der App an. Die App-Seite 10 enthält Links zu den App-Seiten 5 bis 9 (die fünf App-Seiten rückwärts von App-Seite 10) und Links zu den App-Seiten 11 bis 14 (die vier App-Seiten vorwärts von App-Seite 10). Die App-Seite 10 enthält auch die geschätzte Gesamtsuchanfrage.
Dies kann so lange fortgesetzt werden, wie der Nutzer weiter auf Links zu App-Seiten klicken möchte. Wenn der Nutzer von der aktuellen App-Seite rückwärts navigiert und bereits alle App-Seiten in der Nähe im Cache gespeichert sind, können Sie je nach Anwendungsfall keinen neuen Prefetch durchführen.
Diese Lösung ist aus folgenden Gründen schnell und effizient:
- Kleine Prefetches und sogar kleinere App-Seiten werden schnell verarbeitet.
- Im Cache gespeicherte Suchergebnisse müssen nicht mehrmals aufgerufen werden, um dieselben Ergebnisse zu erhalten.
- Der Mechanismus bleibt schnell, unabhängig davon, wie viele Suchergebnisse skaliert werden.
Designoptionen
Hier sind einige Designoptionen, die Sie je nach Anwendungsfall in Betracht ziehen sollten:
Größe der App-Seite: Ihre App-Seiten können mehr als 10 Übereinstimmungen enthalten, wenn es für Ihren Anwendungsfall geeignet ist. Kleinere Seiten werden schneller geladen und zu viele Links auf einer Seite können für den Nutzer schwierig zu verwalten sein.
Anzahl der Links zur App-Seite. In dem 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 nach hinten führen, und vier Links zu den Seiten, die direkt von der aktuellen App-Seite aus weitergeleitet werden. Sie können diese Zahlen an Ihren Anwendungsfall anpassen.
Best Practices
Caching-Ebene nur bei Bedarf verwenden Wenn Sie eine Caching-Ebene eingerichtet haben, sollten Sie diese nur verwenden, wenn dies für Ihren Anwendungsfall erforderlich ist. Bei Suchanfragen, die die Caching-Ebene nicht benötigen, sollte diese umgangen werden.
Verringere die Größe des Cache. Zur Schonung von Ressourcen können Sie die Größe des Cache reduzieren. Löschen Sie dazu die alten Suchergebnisse und behalten Sie die Seiten-URLs bei, mit denen Sie die Ergebnisse erhalten haben. Anschließend können Sie den Cache nach Bedarf rekonstruieren, 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 Sie dauerhaft löschen, wie Sie es dauerhaft löschen und wie oft Sie den Cache leeren, hängt von Ihrem Anwendungsfall ab.
Cache für eine bestimmte Suchanfrage dauerhaft löschen Um Ressourcen zu schonen, können Sie die Ergebnisse inaktiver Suchvorgänge vollständig aus dem Cache entfernen. Entfernen Sie zuerst die Suchanfragen mit der längsten Inaktivität. Wenn eine dauerhaft gelöschte Suche wieder aktiv wird, kann dies zu einem Fehlerstatus führen, der die Caching-Ebene zwingt, die Suche neu zu starten.
Beliebige Seite aufrufen
Wenn Sie möchten, dass ein Nutzer zu einer beliebigen Seite in den Suchergebnissen und nicht nur zu den Seiten in der Nähe der aktuellen Seite navigieren kann, können Sie eine Caching-Ebene verwenden, die der unter Seite in der Nähe navigieren beschriebenen ähnelt. Damit ein Nutzer jedoch zu einer beliebigen App-Seite mit Suchergebnissen wechseln kann, müssen alle Suchergebnisse vorab abgerufen und im Cache gespeichert werden. Bei einer relativ geringen Anzahl von Suchergebnissen ist dies möglich. Bei einer sehr großen Anzahl von Suchergebnissen ist es möglicherweise unpraktisch oder unmöglich, alle im Voraus abzurufen. Selbst bei einer geringen Anzahl von Suchergebnissen kann der Prefetch-Vorgang länger dauern, als zu erwarten ist, dass der Nutzer wartet.
Workflow
Richten Sie einen Workflow ein, der der Option Zu einer Seite in der Nähe navigieren ähnelt. Es gibt jedoch folgenden wichtigen Unterschied: Die App ruft Suchergebnisse im Hintergrund weiter vor, bis alle Übereinstimmungen zurückgegeben werden oder ein anderes vordefiniertes Limit erreicht ist.
Hier ist ein Beispiel-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 Suchsumme (Bundle.total). Dies ist eine Schätzung, falls mehr Ergebnisse zurückgegeben werden sollen.Die Anwendung gruppiert die Übereinstimmungen aus der Antwort in Anwendungsseiten mit jeweils 20 Übereinstimmungen und speichert sie im Cache. Eine App-Seite ist eine kleine Gruppe von Übereinstimmungen, die die App dem Nutzer anzeigen kann.
In der App wird dem Nutzer die erste App-Seite angezeigt. Die App-Seite enthält Links zu den im Cache gespeicherten App-Seiten und die geschätzte Gesamtsuchzahl.
Wenn mehr Ergebnisse zurückgegeben werden sollen, geht die App so vor:
- Ruft die Paginierungs-URL auf, die vom vorherigen Prefetch zurückgegeben wurde, um zur nächsten Suchergebnisseite zu gelangen.
- Gruppiert die Übereinstimmungen aus der Antwort in Anwendungsseiten mit je 20 Übereinstimmungen und speichert sie im Cache.
- Die App-Seite, die sich der Nutzer gerade ansieht, werden mit neuen Links zu den neu abgerufenen und im Cache gespeicherten App-Seiten aktualisiert.
Die Anwendung wiederholt den vorherigen Schritt, bis keine weiteren Ergebnisse mehr zurückgegeben werden oder ein anderes vordefiniertes Limit erreicht ist. Ein genauer Suchergebnis wird mit der letzten Suchergebnisseite zurückgegeben.
Während die App Übereinstimmungen im Hintergrund vorababruft und im Cache speichert, kann der Nutzer weiter auf Links zu im Cache gespeicherten Seiten klicken.
Designoptionen
Hier sind einige Designoptionen, die Sie je nach Anwendungsfall in Betracht ziehen sollten:
Größe der App-Seite: Ihre App-Seiten können mehr oder weniger als 20 Übereinstimmungen enthalten, wenn es für Ihren Anwendungsfall geeignet ist. Kleinere Seiten werden schneller geladen und zu viele Links auf einer Seite können für Nutzer schwierig zu verwalten sein.
Suchsumme aktualisieren. Während Ihre Anwendung Suchergebnisse im Hintergrund vorab abruft und im Cache speichert, können Sie dem Nutzer schrittweise genauere Gesamtsummen der Suche anzeigen. Konfigurieren Sie dazu Ihre Anwendung so:
Rufen Sie in einem festgelegten Intervall die Suchsumme (das Attribut
Bundle.total) aus dem letzten Prefetch in der Caching-Ebene ab. Das ist die aktuelle beste Schätzung der Suchsumme. Zeigen Sie dem Nutzer die Gesamtzahl der Suchanfragen an, um anzuzeigen, dass es sich um eine Schätzung handelt. Bestimmen Sie die Häufigkeit dieser Aktualisierung entsprechend Ihrem Anwendungsfall.Erkennen, wenn die Summe der Suche aus der Caching-Ebene genau ist. Das heißt, die Summe der Suchanfragen stammt von der letzten Seite der Suchergebnisse. Wenn die letzte Seite der Suchergebnisse erreicht ist, zeigt die Anwendung die Gesamtzahl der Suchanfragen an und informiert den Nutzer, dass die Gesamtsumme der Suche korrekt ist. Die Anwendung erhält dann keine Suchsummen mehr aus der Caching-Ebene.
Beachten Sie, dass bei einer großen Anzahl von Übereinstimmungen der Hintergrund-Vorabruf und das Caching möglicherweise nicht die letzte Seite der Suchergebnisse (und die genaue Gesamtsumme der Suche) erreichen, bevor der Nutzer die Suchsitzung beendet hat.
Best Practices
Eingeschlossene Ressourcen deduplizieren. Wenn Sie die Parameter
_includeund_revincludebeim Vorabruf und Caching von Suchergebnissen verwenden, empfehlen wir, die enthaltenen Ressourcen nach jedem Prefetch im Cache zu deduplizieren. Durch Reduzierung der Cache-Größe können Sie Arbeitsspeicher sparen. 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 den Vorabruf und das Caching fest. Bei einer sehr großen Anzahl von Suchergebnissen ist es möglicherweise unpraktisch oder unmöglich, alle im Voraus abzurufen. Wir empfehlen, die Anzahl der Suchergebnisse, die vorab abgerufen werden sollen, zu begrenzen. Dadurch bleibt der Cache überschaubar und spart Arbeitsspeicher. Beispielsweise können Sie die Cache-Größe auf 10.000 oder 20.000 Übereinstimmungen begrenzen. Alternativ können Sie die Anzahl der Seiten für den Prefetch beschränken oder ein Zeitlimit festlegen, nach dem der Prefetch beendet wird. Die Art der Beschränkung und die Art und Weise, wie Sie sie aufsetzen, sind Designentscheidungen, die von Ihrem Anwendungsfall abhängen. Wenn das Limit erreicht ist, bevor alle Suchergebnisse zurückgegeben werden, sollten Sie den Nutzer darauf hinweisen, wobei die Suchsumme weiterhin eine Schätzung ist.
Front-End-Caching
Das Front-End der Anwendung, z. B. ein Webbrowser oder eine mobile App, kann Suchergebnisse im Cache als Alternative zur Einbindung einer Caching-Ebene in die Architektur bereitstellen. Dieser Ansatz kann eine Navigation zur vorherigen Seite oder zu einer beliebigen Seite im Navigationsverlauf ermöglichen, indem AJAX-Aufrufe genutzt und Suchergebnisse und/oder Paginierungs-URLs gespeichert werden. Hier einige Vorteile dieses Ansatzes:
- Sie kann weniger ressourcenintensiv sein als eine Caching-Ebene.
- Da es die Caching-Arbeit auf viele Clients verteilt, ist es skalierbarer.
- So lässt sich leichter feststellen, wann im Cache gespeicherte 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 Seiten, die kleiner als der Wert für „_count“ sind. Unter bestimmten Umständen werden bei einer Suche Seiten zurückgegeben, die weniger Übereinstimmungen enthalten als der von Ihnen angegebene
_count-Wert. Dies kann beispielsweise der Fall sein, wenn Sie eine Seitengröße angeben, die besonders groß ist. Wenn bei der Suche eine Seite zurückgegeben wird, die kleiner als der Wert_countist, und Ihre Anwendung eine Caching-Ebene verwendet, müssen Sie möglicherweise entscheiden, ob Sie (1) auf einer Anwendungsseite weniger Ergebnisse als erwartet anzeigen oder (2) mehr Ergebnisse abrufen möchten, um genügend Ergebnisse für eine vollständige Anwendungsseite zu erhalten. Weitere Informationen finden Sie unter Paginierung und Sortierung.Wiederholen Sie wiederholbare HTTP-Anfragefehler. Die Anwendung sollte wiederholbare HTTP-Anfragefehler wie
429oder500erwarten und sollte es nach Erhalt noch einmal versuchen.
Anwendungsfälle bewerten
Wenn Sie Features wie das Aufrufen einer beliebigen Seite implementieren, genaue Suchsummen abrufen und geschätzte Gesamtsummen aktualisieren, erhöht sich die Komplexität und die Entwicklungskosten Ihrer Anwendung. Diese Funktionen können auch die Latenz erhöhen und die Kosten für die Nutzung von Google Cloud-Ressourcen erhöhen. Wir empfehlen Ihnen, Ihre Anwendungsfälle sorgfältig zu bewerten, um sicherzustellen, dass der Nutzen dieser Funktionen die Kosten rechtfertigt. Beachten Sie dabei Folgendes:
Beliebige Seite aufrufen: Ein Nutzer muss in der Regel nicht eine bestimmte Seite aufrufen, sondern viele Seiten von der aktuellen Seite entfernt. In den meisten Fällen reicht die Navigation zu einer Seite in der Nähe aus.
Genaue Summenwerte für Suchanfragen: Die Summen der Suche können sich ändern, wenn Ressourcen im FHIR-Speicher erstellt, aktualisiert und gelöscht werden. Aus diesem Grund ist eine genaue Gesamtsumme der Suche genau zu dem Zeitpunkt genau, zu dem sie zurückgegeben wird (mit der letzten Seite der Suchergebnisse), kann aber im Laufe der Zeit nicht mehr genau bleiben. Daher können genaue Gesamtsummen der Suche je nach Anwendungsfall von begrenztem Wert für Ihre Anwendung sein.