【问题标题】:Retrieving main CarePlan + all sub CarePlans that are part-of the main plan检索主护理计划 + 作为主计划一部分的所有子护理计划
【发布时间】:2021-03-22 13:54:13
【问题描述】:

我们正在构建一个用于创建和管理护理计划的网络应用程序。

我们决定以这种方式构建我们的应用程序:

  • 主要计划(CarePlan)
    • 第 1 部分(护理计划)
    • 第 2 部分(护理计划)
    • ...
    • 第 n 部分(护理计划)

这种方法背后的原因是我们的任何部分(例如“饮食”部分)都可以有多个目标和多项活动来实现这些目标。也可以单独编辑每个部分。

在我们的应用程序中,我们知道主计划的 id,并且需要在其 partOf-reference 中检索指向该主计划的所有子计划。

我怎样才能做到这一点?

我们正在使用http://hapi.fhir.org/ -server 测试我们的应用程序。

以下是我们 FHIR 资源的一些示例

  1. 主要护理计划:http://hapi.fhir.org/baseR4/CarePlan/1958874
  2. 部分护理计划:http://hapi.fhir.org/baseR4/CarePlan/1955871

及相关搜索:

  1. http://hapi.fhir.org/baseR4/CarePlan?_id=1958874 工作。
  2. http://hapi.fhir.org/baseR4/CarePlan?_id=1958874&_include=CarePlan:subject 工作。
  3. http://hapi.fhir.org/baseR4/CarePlan?_id=1958874&_revinclude=* 有效但不是很有用。
  4. http://hapi.fhir.org/baseR4/CarePlan?_id=1958874&_revinclude=CarePlan:partOf 不起作用。为什么?

【问题讨论】:

  • 旁注:当我查看 1955871 示例时,似乎有很多“包含”资源似乎应该独立存在。提醒一下,“包含”仅适用于与包含资源没有独立存在的数据(无法搜索它,除了在容器的上下文中没有意义)。
  • 这是一个公平的观点。我们在团队中也在这个主题上反复讨论。包含目标和活动的原因是,我们没有想到如果脱离 CarePlan 的上下文(至少目前是这样),这些信息将需要或相关的情况。你会建议建立独立的目标和活动,以防万一我们最终在其他情况下需要它们?
  • 如果您确信发送者和接收者都会将它们视为内在包含的并且没有独立的存在/身份,那没关系。包含的目标比包含的活动更容易理解——活动几乎总是独立存在? CarePlan 可能会指向它们,但您通常需要能够在不查看 CarePlans 内部的情况下看到发生的操作?

标签: hl7-fhir hapi-fhir


【解决方案1】:

试试http://hapi.fhir.org/baseR4/CarePlan?_id=1958874&_revinclude=CarePlan:part-of

当您指定_revinclude 时,您必须指定搜索参数,而不是元素名称。 partOf 的搜索参数是 part-of(如下所示:https://build.fhir.org/careplan#search

【讨论】:

  • 我明白了,谢谢!我完全忽略了搜索参数部分。通过此更正,搜索正在按照我的需要进行。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2018-07-06
  • 1970-01-01
  • 1970-01-01
  • 2016-02-28
  • 2019-04-13
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多