等性与并发性 - AWS HealthLake
等能键ETag 在 AWS 中 HealthLake

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

等性与并发性

等能键

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

  • 在处理资源创建的客户端应用程序中实现

注意

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

ETag 在 AWS 中 HealthLake

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 无内容）

  • ETag 匹配当前版本

  • 操作按预期进行

版本冲突（412 前提条件失败）

  • ETag 与当前版本不匹配

  • 为了防止数据丢失，更新被拒绝

最佳实践

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

  • 实现用于处理版本冲突的重试逻辑

  • 使用 If-None-Match:* 用于 create-if-not-exists场景

  • 修改前务必验证 ETag 新鲜度

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