Konsistenzstufen für die FHIR-Suche - AWS HealthLake
KonsistenzstufenVerwendungsbeispielBewährte Methoden

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Konsistenzstufen für die FHIR-Suche

HealthLakeDer Suchindex von AWS basiert auf einem Eventual Consistency Model für GET und POST mit SEARCH-Vorgängen. Bei eventueller Konsistenz schließen die Suchergebnisse Version N-1 der Ressource aus, wenn ein Suchindex-Update für eine Ressource aussteht, bis die Indexaktualisierung abgeschlossen ist.

AWS bietet HealthLake jetzt die Möglichkeit, auszuwählen, wie sich das Konsistenzmodell für aktualisierte Ressourcen verhalten soll. Entwickler können entweder „Eventual Consistency“, das oben beschriebene Standardverhalten, oder „Strong Consistency“ angeben. Strong Consistency ermöglicht es, die N-1-Version der Ressource für Ressourcen mit ausstehenden Aktualisierungen des Suchindexes in die Suchergebnisse aufzunehmen. Dies kann für Anwendungsszenarien verwendet werden, in denen alle Ressourcen für das Ergebnis benötigt werden, auch wenn die Aktualisierung des Suchindex noch nicht abgeschlossen ist. Kunden können dieses Verhalten mithilfe des x-amz-fhir-history-consistency-level Anforderungsheaders steuern.

Konsistenzstufen

Starke Konsistenz

Legt festx-amz-fhir-history-consistency-level: strong, dass alle übereinstimmenden Datensätze zurückgegeben werden, auch solche mit ausstehenden Aktualisierungen des Suchindexes. Verwenden Sie diese Option, wenn Sie unmittelbar nach Aktualisierungen nach Ressourcen suchen müssen.

Letztendliche Datenkonsistenz

Legt festx-amz-fhir-history-consistency-level: eventual, dass nur Datensätze zurückgegeben werden, für die die Aktualisierung des Suchindex abgeschlossen wurde. Dies ist das Standardverhalten, wenn keine Konsistenzstufe angegeben ist.

Verwendungsbeispiel

  1. Gehen Sie beim Aktualisieren einer Ressource wie folgt vor:

    POST <baseURL>/Patient
Content-Type: application/fhir+json
x-amz-fhir-history-consistency-level: strong

{
  "resourceType": "Patient",
  "id": "123",
  "meta": {
    "profile": ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"]
  },
  "identifier": [
    {
      "system": "http://example.org/identifiers",
      "value": "123"
    }
  ],
  "active": true,
  "name": [
    {
      "family": "Smith",
      "given": ["John"]
    }
  ],
  "gender": "male",
  "birthDate": "1970-01-01"
}

  2. Nachfolgende Suche:

    GET <baseURL>/Patient?_id=123

Bewährte Methoden

  • Verwenden Sie starke Konsistenz, wenn Sie sofort nach kürzlich aktualisierten Ressourcen suchen müssen

  • Verwenden Sie Eventual-Konsistenz für allgemeine Abfragen, bei denen sofortige Sichtbarkeit nicht entscheidend ist

  • Berücksichtigen Sie den Kompromiss zwischen sofortiger Sichtbarkeit und potenziellen Auswirkungen auf die Leistung

Anmerkung

Die Einstellung der Konsistenzstufe wirkt sich darauf aus, wie schnell aktualisierte Ressourcen in den Suchergebnissen angezeigt werden, hat jedoch keinen Einfluss auf die tatsächliche Speicherung der Ressourcen.

Wenn der optionale x-amz-fhir-history-consistency-level Header auf „strong“ gesetzt wird, verdoppelt sich der Schreibkapazitätsverbrauch pro Ressource.

Diese Funktion ist nur für Datenspeicher verfügbar, bei denen der Versionsverlauf aktiviert ist (bei allen Datenspeichern, die nach dem 25. Oktober 2024 erstellt wurden, ist sie standardmäßig aktiviert).