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

Question

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

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. in the bundle
3. 在其他地方的服务器上

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