Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Idempotenza e concorrenza

Chiavi di idempotenza

AWS HealthLake supporta le chiavi di idempotenza per le POST operazioni FHIR, fornendo un meccanismo robusto per garantire l'integrità dei dati durante la creazione delle risorse. Includendo un UUID univoco come chiave di idempotenza nell'intestazione della richiesta, le applicazioni sanitarie possono garantire che ogni risorsa FHIR venga creata esattamente una volta, anche in scenari che prevedono instabilità di rete o tentativi automatici.

Questa funzionalità è particolarmente importante per i sistemi sanitari in cui la duplicazione delle cartelle cliniche potrebbe avere gravi conseguenze. Quando una richiesta viene ricevuta con la stessa chiave di idempotenza di una richiesta precedente, HealthLake restituirà la risorsa originale invece di crearne una duplicata. Ad esempio, ciò potrebbe verificarsi durante un ciclo di tentativi o a causa di pipeline di richieste ridondanti. L'utilizzo della chiave di idempotenza consente di mantenere la coerenza dei dati fornendo HealthLake al contempo un'esperienza senza interruzioni per le applicazioni client che gestiscono problemi di connettività intermittenti.

Implementazione

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

Scenari di risposta

Best practice

ETag in AWS HealthLake

AWS HealthLake utilizza ETags un controllo ottimistico della concorrenza nelle risorse FHIR, fornendo un meccanismo affidabile per gestire le modifiche simultanee e mantenere la coerenza dei dati. An ETag è un identificatore univoco che rappresenta una versione specifica di una risorsa, che funziona come un sistema di controllo della versione tramite intestazioni HTTP. Durante la lettura o la modifica delle risorse, le applicazioni possono utilizzarle ETags per prevenire sovrascritture involontarie e garantire l'integrità dei dati, in particolare in scenari con potenziali aggiornamenti simultanei.

Esempio di implementazione

// 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

Scenari di risposta

Best practice

Questo sistema di controllo simultaneo è essenziale per mantenere l'integrità dei dati sanitari, specialmente in ambienti con più utenti o sistemi che accedono e modificano le stesse risorse.