冪等和並行 - AWS HealthLake
等冪性金鑰AWS HealthLake 中的 ETag

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

冪等和並行

等冪性金鑰

AWS HealthLake 支援 FHIR POST操作的等冪性金鑰，提供強大的機制，以確保資源建立期間的資料完整性。透過在請求標頭中將唯一的 UUID 作為等冪性金鑰，醫療保健應用程式可以保證每個 FHIR 資源只建立一次，即使在涉及網路不穩定或自動重試的情況下也是如此。

此功能對於醫療保健系統特別重要，因為重複的醫療記錄可能會造成嚴重的後果。當收到具有與先前請求相同等冪性金鑰的請求時，HealthLake 會傳回原始資源，而不是建立重複的資源。例如，這可能會在重試迴圈期間發生，或是因為備援請求管道。使用冪等性金鑰可讓 HealthLake 維持資料一致性，同時為處理間歇性連線問題的用戶端應用程式提供無縫體驗。

實作

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

回應案例

第一個請求 （已建立 201)

  • 已成功建立新資源

  • 回應包含資源 ID

重複請求 (409 衝突）

  • 偵測到相同的等冪性金鑰

  • 傳回的原始資源

  • 未建立新的資源

無效請求 (400 個無效的請求）

  • 格式錯誤的 UUID

  • 缺少必要欄位

最佳實務

  • 為每個新資源建立產生唯一的 UUID

  • 儲存等冪索引鍵以重試邏輯

  • 使用一致的金鑰格式：建議使用 UUID v4

  • 在處理資源建立的用戶端應用程式中實作

注意

對於需要嚴格資料準確性和防止重複醫療記錄的醫療保健系統來說，此功能特別重要。

AWS HealthLake 中的 ETag

AWS HealthLake 使用 ETags FHIR 資源中實現樂觀並行控制，提供可靠的機制來管理並行修改和維護資料一致性。ETag 是代表資源特定版本的唯一識別符，可透過 HTTP 標頭做為版本控制系統。讀取或修改資源時，應用程式可以使用 ETags 來防止意外覆寫並確保資料完整性，尤其是在具有潛在並行更新的情況下。

實作範例

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

回應案例

操作成功 (200 OK 或 204 No Content)

  • ETag 符合目前版本

  • 操作會如預期進行

版本衝突 (412 先決條件失敗）

  • ETag 與目前版本不相符

  • 拒絕更新以防止資料遺失

最佳實務

  • 在所有更新和刪除操作中包含 ETags

  • 實作處理版本衝突的重試邏輯

  • 使用 If-None-Match：* 表示 create-if-not-exists 案例

  • 修改前一律驗證 ETag 新鮮度

此並行控制系統對於維護醫療保健資料的完整性至關重要，尤其是在具有多個使用者或系統存取和修改相同資源的環境中。