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

# 冪等和並行
<a name="managing-fhir-resources-idempotency"></a>

## 等冪性金鑰
<a name="idempotency-keys"></a>

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

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

### 實作
<a name="implementation"></a>

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

### 回應案例
<a name="response-scenarios"></a>

第一個請求 （已建立 201)  
+ 已成功建立新資源
+ 回應包含資源 ID

重複請求 (409 衝突）  
+ 偵測到相同的等冪性金鑰
+ 傳回的原始資源
+ 未建立新的資源

無效請求 (400 個無效的請求）  
+ 格式錯誤的 UUID
+ 缺少必要欄位

### 最佳實務
<a name="best-practices"></a>
+ 為每個新資源建立產生唯一的 UUID
+ 儲存等冪索引鍵以重試邏輯
+ 使用一致的金鑰格式：建議使用 UUID v4
+ 在處理資源建立的用戶端應用程式中實作

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

## AWS HealthLake 中的 ETag
<a name="healthlake-etag"></a>

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

### 實作範例
<a name="healthlake-etag-implementation"></a>

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

### 回應案例
<a name="healthlake-etag-scenarios"></a>

操作成功 (200 OK 或 204 No Content)  
+ ETag 符合目前版本
+ 操作會如預期進行

版本衝突 (412 先決條件失敗）  
+ ETag 與目前版本不相符
+ 拒絕更新以防止資料遺失

### 最佳實務
<a name="healthlake-etag-practices"></a>
+ 在所有更新和刪除操作中包含 ETags 
+ 實作處理版本衝突的重試邏輯
+ 使用 If-None-Match：\$1 表示 create-if-not-exists 案例
+ 修改前一律驗證 ETag 新鮮度

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