（文档）捆绑条目是否总是必须被引用或引用？答案

【问题标题】：Do (document) bundle entries always have to be referenced or referencing?（文档）捆绑条目是否总是必须被引用或引用？
【发布时间】：2022-05-20 21:37:25
【问题描述】：

FHIR 文档的规范似乎要求文档资源中的所有捆绑条目都是以组合条目为根的参考图的一部分。也就是说，它们应该是一直追溯到根条目的引用关系的源或目标。

不幸的是，我无法找到 FHIR 规范中的所有相关段落；在3.3.1 Document Content 中有一个拼写的地方，但目前还不清楚这是否属于全部“文档”类型的包（即，即使是那些恰好是类型代码为“文档”的包，但只是机器可处理数据的集合，没有任何表示 FHIRy 文档的愿望）。

引用要求的问题在于 HAPI 验证器使用线性搜索来检查引用。因此，如果我们必须将 N 个充满数据的捆绑条目发送给付款人，我们必须包含一个包含 N 个引用的列表（每个包含数据的捆绑条目一个）。这导致在验证期间需要花费 O(N) 的努力进行 N 次参考搜索，这使得参考检查的复杂性有效地与条目数量成二次方。

这很容易让最强大的计算机也瘫痪。当前的大小约束有效地将每个文件的条目数限制在大约 25000，并且 HAPI 验证器需要几个小时即使在目前可用的最强大的 CPU 上，也要仔细研究它。如果没有引用，则同一文件的验证将花费不到一分钟的时间。

在我们的用例中，承载数据的条目在包含的捆绑文件之外没有身份。实际上，它们既不需要entry.fullUrl 也不需要entry.resource.id，因为它们的业务标识符包含在包含的base64 blob 中。但是，这些标识符的存在与否对验证所需的时间没有实际影响（即使对于 1 GB 文件也只有几分之一秒），所以谁在乎呢。杀死 HAPI 验证器的是引用列表。

也许可以通过使所有条目都包含对作品的引用来满足引用要求的字母。 HAPI 验证器不关心任何一种方式，所以我不知道这是否有效。但即使它是 FHIRly 有效的，它也将是一个非常愚蠢的解决方法。

有没有办法放弃引用要求？也许通过将捆绑类型更改为“集合”之类的东西，或者使用contained 资源？

P.S.：目前我们正在使用一种解决方法，将验证时间从几小时缩短到不到一分钟，但这是一种 hack，我们目前没有资源来修复 HAPI 验证器。我最关心的是如何更改规范（配置文件）以避免我描述的问题的问题。

【问题讨论】：

标签： hl7-fhir hapi

【解决方案1】：

（即，即使是那些碰巧与类型代码“文档”捆绑在一起但只是机器可处理数据的集合，而没有任何表示 FHIRy 文档的愿望）

如果它不是一个文档，也不打算成为一个文档，请不要使用“文档”捆绑类型。如果你这样做了，我会歪曲 FHIR 试图避免的数据。似乎您想发送不一定相关的资源集合，所以

有没有办法放弃引用要求？也许通过将捆绑类型更改为“集合”之类的东西

是的，我会使用“收集”，或者可能是“批处理/事务”，具体取决于我想告诉接收者如何处理数据。

【讨论】：

文件中的条目是从某种意义上说，它们都是属于同一张发票的处方（在组合物中引用的条目中指定）。实际上，它们属于给定发票的事实已经通过它们包含在同一文件中这一事实来表达，从而消除了对参考列表的（实际）需求。早期的配置文件版本允许每个文件有多个发票，所以当时情况有所不同。
似乎大多数 FHIR 分组/捆绑结构 - 例如列表 - 通过引用使用包含而不是身体包含。这在在线环境中很有意义（其中资源可以通过 FHIR HTTP 服务器独立获得），但在离线环境中意义不大，因为数据在传输的文件之外不存在。
一张发票 25000 件物品相当多……你能和我分享一个例子，让我看看吗？（我编写了验证器，而且我确定它不是为了在生产中与 25k 资源一起使用而编写的）。（发送至 gmail 的 grahameg。如有必要，我可以签署 NDA）
@ Grahame：这是计费中心向给定保险公司开具的月度发票，其中包含由该中心客户的药房为该特定保险公司开具的所有处方。因此，即使像我们这样的小型中心也很容易达到 25000 这个数字，而较大的中心必须将他们的发票分成数十或数百个部分，每个部分 1 GB。有关概述，请参阅simplifier.net/eRezeptAbrechnungsdaten，有关当前生产中的文档资源，请参阅simplifier.net/packages/de.gkvsv.erezeptabrechnungsdaten/1.2.0/…。
我将很快通过电子邮件发送详细信息、示例资源链接和用于生成 1 GB 完整文件的脚本。

【解决方案2】：

文档页面说：

文件包应仅包括：

Composition 资源，以及从中直接或间接（例如递归）引用的任何资源

包含样式表的二进制资源（如下所述）

具有组合目标的出处资源或文档中包含的其他资源
文档是一组冻结的内容，旨在作为经过验证的、人类可读的、冻结的内容集。如果这不是您需要的，请使用不同的 Bundle 类型。但是，如果你做需要“文档”类型，这并不意味着系统必须在运行时验证所有需求

【讨论】：

有问题的资源绝对不是人类可读的文档；这只是一兆吨的数据。但是，将其指定为“文档”类型捆绑包的配置文件是目前每个人都必须遵守的全国性标准。如果我们的工作组能够收集资金充足的技术论据，那么我们可能能够影响标准/配置文件的下一次迭代的样子。现在的要点有两个：查看捆绑类型（例如更改为“集合”）并删除不再用于任何实际目的的参考列表。
尽管如此，是否所有具有“文档”类型的包都必须符合“FHIR 文档”的规范，或者 FHIR 文档是否仅代表所有“文档”类型的包中的一个受限子集，这并不完全清楚。在规范的其他地方，“文档”的范围要广泛得多。此外，人们不能忘记，所讨论的资源有效地替代了纸质文件（纸质处方），或者更确切地说是装满它们的纸箱或卡车。这可以解释简介作者所做的选择。
所有“文档”类型的捆绑包都应遵循 FHIR 文档的规则。这并不意味着它们必须是“临床”文档，但它们肯定必须以 CapabilityStatement 开头，具有通过引用关联的所有资源，并且可以呈现为人类可读的文档。
感谢您的澄清。不过，我认为您的意思是“构成”而不是“能力声明”。 ;-)
确实我做到了:)