“查询”资源中的多个资源参数，用于在消息传递范式中获取结果

Question

我想使用查询资源以二进制格式从存储库中获取文档列表。存储库维护文档参考资源和患者详细信息。我的参数是基于

1. DocumentReference.type
2. DocumentReference.subject.Patient.identifier.value@value
3. DocumentReference.subject.Patient.identifier.system@value

这就是我猜参数的样子 -

<parameter url="http://nhs.uk/fhir/query#_type">
  <valueString value="DocumentReference"/>
</parameter>
<parameter url="http://nhs.uk/fhir/query#type">
  <valueString value="EndofLifeCareRecord"/>
</parameter>
<parameter url="http://nhs.uk/fhir/query#subject:Patient.identifier.value">
  <valueString value="12345"/>
</parameter>
<parameter url="http://nhs.uk/fhir/query#subject:Patient.identifier.system">
  <valueString value="http://nhs.uk/fhir/nhs-number/"/>
</parameter>

我的问题 -

1. 考虑到我使用的是消息范式（不是 REST），上述参数构造是否正确？
2. 如何构建响应，即文档资源将填充主题（即患者）。它会是一个包含的资源吗？

Answer 1

如果您使用规范中定义的参数，那么它们的 URL 是http://hl7.org/fhir/query。如果您自己定义参数 - 其中 4 个中的 3 个似乎是这种情况（这就是您的意思吗？）然后您提供自己的命名空间，就像您一样。参数格式正确。

就响应而言，它是一个带有消息头资源的包，以及一个包含对构成查询结果集的资源的引用的查询资源，这些资源必须在包中。文档资源通过 URL 引用主题（患者），您有 3 个选择放置患者资源的位置：

1. 包含在文档参考资源中
2. 在捆绑包中
3. 在其他服务器上

我认为 #3 在您的情况下不起作用，因此您在 #1 和 #2 之间进行选择。包含的资源总是一个坏主意——它们通过取消标识来阻碍资源的后续使用。因此，您应该只在必要时使用包含的资源，因为您没有足够的信息来构建已识别的资源——这对您的患者资源来说是一个非常糟糕的主意。确实是个坏主意。