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.

Idempotenz und Parallelität

Idempotenzschlüssel

AWS HealthLake unterstützt Idempotenzschlüssel für POST FHIR-Operationen und bietet so einen robusten Mechanismus zur Sicherstellung der Datenintegrität bei der Ressourcenerstellung. Durch die Aufnahme einer eindeutigen UUID als Idempotenzschlüssel in den Anforderungsheader können Anwendungen im Gesundheitswesen garantieren, dass jede FHIR-Ressource genau einmal erstellt wird, selbst in Szenarien mit Netzwerkinstabilität oder automatischen Wiederholungsversuchen.

Diese Funktion ist besonders wichtig für Gesundheitssysteme, in denen doppelte Patientenakten schwerwiegende Folgen haben könnten. Wenn eine Anfrage mit demselben Idempotenzschlüssel wie eine vorherige Anfrage eingeht, HealthLake wird die ursprüngliche Ressource zurückgegeben, anstatt ein Duplikat zu erstellen. Dies kann beispielsweise während einer Wiederholungsschleife oder aufgrund redundanter Anforderungspipelines auftreten. Die Verwendung des Idempotenzschlüssels ermöglicht HealthLake die Aufrechterhaltung der Datenkonsistenz und bietet gleichzeitig ein reibungsloses Erlebnis für Client-Anwendungen, die mit zeitweiligen Verbindungsproblemen umgehen.

Implementierung

POST /<baseURL>/Patient
x-amz-fhir-idempotency-key: 123e4567-e89b-12d3-a456-426614174000
{
    "resourceType": "Patient",
    "name": [...]
}

Reaktionsszenarien

Bewährte Methoden

ETag in AWS HealthLake

AWS HealthLake dient ETags zur optimistischen Kontrolle der Parallelität in FHIR-Ressourcen und bietet so einen zuverlässigen Mechanismus zur Verwaltung gleichzeitiger Änderungen und zur Wahrung der Datenkonsistenz. An ETag ist ein eindeutiger Bezeichner, der für eine bestimmte Version einer Ressource steht und über HTTP-Header als Versionskontrollsystem fungiert. Beim Lesen oder Ändern von Ressourcen können ETags Anwendungen unbeabsichtigte Überschreibungen verhindern und die Datenintegrität sicherstellen, insbesondere in Szenarien mit potenziellen gleichzeitigen Aktualisierungen.

Beispiel für eine Implementierung

// Initial Read
GET /fhir/Patient/123
Response: 
ETag: W/"1"

// Update with If-Match
PUT /fhir/Patient/123
If-Match: W/"1"
{resource content}

// Create with If-None-Match
PUT /fhir/Patient/123
If-None-Match: *
{resource content}
// Succeeds only if resource doesn't exist
// Fails with 412 if resource exists

Reaktionsszenarien

Bewährte Methoden

Dieses System zur Kontrolle der Parallelität ist für die Aufrechterhaltung der Integrität von Gesundheitsdaten unerlässlich, insbesondere in Umgebungen, in denen mehrere Benutzer oder Systeme auf dieselben Ressourcen zugreifen und diese ändern.