(文档)包条目总是必须被引用或引用吗？

Question

FHIR文档的规范似乎要求文档资源中的所有包条目都是根植于组合条目的引用图的一部分。也就是说，它们应该是一直跟踪到根条目的引用关系的源或目标。

不幸的是，我未能找到FHIR规范中的所有相关段落；其中一个地方是3.3.1文件内容，但尚不清楚这是否适用于所有类型‘文档’的包(即那些恰好与类型代码'document‘捆绑在一起，但仅仅是计算机可处理数据的集合，而没有任何表示FHIRy文档的愿望)。

引用性要求的问题在于HAPI验证器使用线性搜索来检查引用。因此，如果我们必须将装满数据的N个捆绑条目发送给付费人，我们必须包含一个包含N个引用的列表(每个包含数据的包条目一个)。这导致在验证过程中用O(N)努力进行N个引用搜索，使得引用检查的复杂性在条目数量上有效地二次化。

这使得即使是最强大的计算机也很容易崩溃。当前的大小限制有效地将每个文件的条目数限制在大约25000个，而HAPI验证器需要几个小时的来仔细研究这个问题，即使是在当前可用的最强大的CPU上。如果没有引用，同一文件的验证时间将不到一分钟。

在我们的用例中，包含数据的条目在包含的包文件之外没有标识。实际上，它们既不需要entry.fullUrl也不需要entry.resource.id，因为它们的业务标识符包含在包含的base64 blobs中。但是，这些标识符的存在或不存在对验证所需的时间没有实际影响(即使是1GB文件也是1秒的分数)，所以谁在乎呢。是引用列表杀死了HAPI验证器。

也许有可能通过将所有条目都包括对构成的提及来满足参考文件的要求。HAPI验证器不管是哪种方式都不关心，所以我不知道这是否有效。但是，即使它是有效的FHIRly，这也是一个非常愚蠢的解决办法。

有什么办法可以摆脱引用要求吗？可能是通过将包类型更改为“集合”，还是使用contained资源？

P.S.：目前，我们正在使用一种解决办法，将验证时间从小时缩短到不到一分钟，但这是一次黑客攻击，我们目前没有资源来修复HAPI验证器。我最关心的是如何修改规范(概要文件)以避免我描述的问题。

Answer 1

(也就是说，即使那些碰巧与类型代码“文档”捆绑在一起，但仅仅是机器处理数据的集合，也没有任何表示FHIRy文档的愿望)

如果它不是文档，也不打算成为文档，请不要使用“文档”绑定类型。如果你这么做了，你会让我曲解这些数据，这也是FHIR试图避免的。似乎您希望发送一组不一定相关的资源，因此

有什么办法可以摆脱引用要求吗？也许可以将包类型更改为类似于“collection”的内容。

是的，我会使用“集合”，或者可能使用“批/事务”，这取决于我想告诉接收方对数据做什么。