本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
FHIR 搜索一致性级别
AWS HealthLake 的搜索索引在搜索GET操作的最终一致性模型上运行。POST为了最终保持一致性,如果某个资源的搜索索引有待更新,则在索引更新完成之前,搜索结果将排除该资源的 N-1 版本。
AWS HealthLake 现在可以选择更新后的资源的一致性模型的行为方式。开发人员可以包含 “最终一致性”(上述默认行为)或 “强一致性”。强一致性将允许搜索索引更新待处理的资源的 N-1 版本包含在搜索结果中。这可用于即使搜索索引更新尚未完成也需要在结果中使用所有资源的用例场景。客户可以使用x-amz-fhir-history-consistency-level请求标头控制这种行为。
一致性级别
- 强一致性
-
设置为
x-amz-fhir-history-consistency-level: strong返回所有匹配的记录,包括那些有待更新的搜索索引的记录。当需要在更新后立即搜索资源时,请使用此选项。 - 最终一致性
-
设置
x-amz-fhir-history-consistency-level: eventual为仅返回已完成搜索索引更新的记录。如果未指定一致性级别,则这是默认行为。
用法示例
-
更新资源时:
POST <baseURL>/Patient Content-Type: application/fhir+json x-amz-fhir-history-consistency-level: strong { "resourceType": "Patient", "id": "123", "meta": { "profile": ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"] }, "identifier": [ { "system": "http://example.org/identifiers", "value": "123" } ], "active": true, "name": [ { "family": "Smith", "given": ["John"] } ], "gender": "male", "birthDate": "1970-01-01" } -
后续搜索:
GET <baseURL>/Patient?_id=123
最佳实践
-
当需要立即搜索最近更新的资源时,请使用强一致性
-
在即时可见性并不重要的一般查询中,使用最终一致性
-
考虑一下即时可见性和潜在性能影响之间的权衡
注意
一致性级别设置会影响更新的资源在搜索结果中的显示速度,但不会影响资源的实际存储。
将可选标x-amz-fhir-history-consistency-level头设置为 “strong” 会使每个资源的写入容量消耗增加一倍。
此功能仅适用于启用了版本历史记录的数据存储(默认情况下,在 2024 年 10 月 25 日之后创建的所有数据存储都启用了该功能)。