本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 等性与并发性
<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
+ 在处理资源创建的客户端应用程序中实现

**注意**  
对于要求严格数据准确性并防止重复医疗记录的医疗保健系统而言，此功能特别有用。

## ETag 在 AWS 中 HealthLake
<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 无内容）  
+ ETag 匹配当前版本
+ 操作按预期进行

版本冲突（412 前提条件失败）  
+ ETag 与当前版本不匹配
+ 为了防止数据丢失，更新被拒绝

### 最佳实践
<a name="healthlake-etag-practices"></a>
+ 包含 ETags 在所有更新和删除操作中
+ 实现用于处理版本冲突的重试逻辑
+ 使用 If-None-Match:\$1 用于 create-if-not-exists场景
+ 修改前务必验证 ETag 新鲜度

这种并发控制系统对于维护医疗保健数据的完整性至关重要，尤其是在有多个用户或系统访问和修改相同资源的环境中。