2026.3 FHIR 亮点——新的缓存分页样式选项
在 2026.3 版本中，为您的 FHIR 端点引入了一项新的“分页样式”设置。
分页样式会影响 FHIR 搜索结果的分页方式。
这些新的“样式”实际上解决了两个问题：
- 在页面内的“Includes”元素方面，更好地符合FHIR规范
- 提升第一页响应的性能
共有 3 种选项：
- 传统
- 缓存
- 缓存-异步
我将重点说明每种模式的特点，并演示部分行为——
旧版
这是 FHIR 服务器在此版本之前的运行方式（默认且唯一的选项）。
传统分页会在搜索时对完整的结果集进行快照，并针对每一页遍历该快照。这意味着第一页的返回时间会更长，因为它需要等待完整结果的生成，但后续页面的返回速度会更快。另请注意，结果将反映初始搜索时数据的状态。
对于结果集非常庞大、但又希望第一页能快速响应的搜索而言，这种方法的性能可能较差。
此外，此模式会将“include”资源放置在结果集的末尾。所有页面包含的资源数量均相同（由 _count 或默认页面大小决定），无论这些资源是“match”还是“include”资源。
这与 FHIR 标准中关于使用_include（或 _revinclue）进行分页的规定不太一致 ：
当搜索结果分页时，每页搜索结果应包含该页中资源的所有匹配的“include”资源，以便每页都能作为一个完整的、连贯的整体独立存在。
已缓存
这种新样式解决了上述最后一点——它确实包含了 每页中资源的匹配包含项。因此，每页除了包含其包含项外，还将包含“_count”数量的匹配资源。
这种风格在搜索时仍会对完整的结果集进行快照，因此第一页的生成时间与传统风格相似。
缓存-异步
此样式解决了“传统”样式中提到的两个问题。
与“缓存”模式一样，它根据 FHIR 规范在每页中包含 _include 资源。
至于结果集的构建，此模式会立即返回结果的第一页，随后创建一个异步任务来填充结果集中的其余页面。后续页面将在异步任务完成填充后陆续提供。
由于第一页可能在完整结果集生成之前就被返回，因此在后台任务完成之前，将省略“total”字段以及“last”页面链接。
若请求的页面尚未构建完成，将返回 HTTP 503 状态码，此时应重试。
请注意，此设置旨在实现最佳性能；如果您在自定义 Interaction 类中实现了PostProcessSearch() 方法，则在此分页样式下，该方法将不会对您的结果集进行处理。
演示
您可以在“交互策略设置”部分找到此设置：
以下是三种分页样式行为的对比示例：
假设我们的存储库中有 222,714 个观察资源——
首先测试传统方法 ：
我们请求统计 20 条记录，并包含所引用的“遭遇”数据。
让我们观察以下几点：
- 首先是耗时—— 耗时 3.76 秒（而且这并非首次调用）
- 可以看到，资源总数 为 222,714 个
-
可以看到我们有 4 个“链接”，它们是：
具体来说，我们还有一个“最后一页”链接。
- 此外，我们有20条记录。这与我们请求的计数一致，但不包含那些“未匹配”而是“已包含”的Encounter资源。
现在让我们尝试使用“缓存”模式：
再次，让我们检查并比较：
- 这次耗时 更长：7.85秒
- 我们仍然拥有总资源 数。
- 而且我们仍然有4个链接（ 带有“last”）。
-
但是——这里的条目 数量是 23个（而不是20个）。这是因为现在每页还包含了所有被包含的资源。在这种情况下，它包含了3个“遭遇”。
你可以看到，在页面上最后一个“匹配”的观察项之后，我们可以看到那3个“包含”的遭遇：
最后，让我们看看将作为新默认值的“Cached-Async”：
- 我们可以看到响应速度快了很多，从原先的近4秒或近8秒，缩短到了113毫秒！
- 目前没有总数（ 如上文第一页所述，假设我们尚未获得完整结果，则不会显示总数）
- 目前只有 3个链接—— 还没有“最后”一个链接。
- 与之前的样式相同——我们共有 23条记录，其中包括本页显示的 3 次遭遇。
请注意，如果我们访问“下一页”，且异步任务已经完成，我们将看到总数和“最后”链接：
可以看到，页面上不仅显示了总数，还显示了5个导航链接（首页、上一页、当前页、下一页和末页）。