FHIR 搜索槽请求答案

【问题标题】：FHIR Search Slots requestFHIR 搜索槽请求
【发布时间】：2016-07-25 15:51:04
【问题描述】：

我正在实施 FHIR 服务器，但由于某些不可避免的原因，我无法访问医生的日程安排，但是，我可以访问可用于预约的时段。

我可以使用 4 个参数获取插槽

医生身份证

组织 ID

位置 ID

广告位日期

以下将被视为使用 FHIR 的有效槽查询：

http://localhost:8080/context/fhir/Slot?practitioner=Practitioner/123456789&organization=Organization/1234&location=Location/2&start=2016-07-25

另外，在对上述查询的响应中，由于对 Schedule 的引用是绝对必要的（Slot 有 card=1..1 用于 Schedule 参考），我可以将参考值传递为类似的东西：

"schedule": {
    "reference": "Schedule/notrequired"
  }

在槽响应中？

【问题讨论】：

标签： dstu2-fhir hapi-fhir hl7-fhir

【解决方案1】：

不幸的是，现在，您确实必须公开时间表，但没有任何理由必须是“真实的”。我们目前实现 Slot 搜索的方式是公开一个虚拟 Schedule，其中唯一的数据元素是到 actor 的链接。例如：

<Schedule xmlns="http://hl7.org/fhir">
<id value="1234" />
<actor>
    <display value="Cooper Thompson, MD" />
    <reference value="http://host/api/FHIR/DSTU2/Practitioner/1234" />
</actor>

我们的插槽搜索最终看起来像这样（为了简洁明了，特别是围绕插槽类型进行了一些编辑）：

http://host/api/FHIR/DSTU2/Slot?Schedule.actor:Practitioner=1234&Schedule.actor:Patient=5678&slottype=urn:oid:1.2.3|Cardiology&start=2016-07-21

请注意，这技术上是无效的，因为一个 Slot 只能有一个 Schedule，并且我们为 Schedule 包含了多个链式搜索参数。由于 Slot.schedule 是 1:1，因此我们还使用扩展来发回与插槽关联的患者、从业者和位置。然而，这种“故意滥用”是我发现的最佳选择，而不是强制客户端成为调度系统并处理为每个资源排队的插槽。

FHIR gforge 中有一些跟踪器项目（9989、9208）关于更新 Slot 以对“简单客户”更友好。我们非常感谢您的意见 :)。

【讨论】：

Thant 提出了一个关于上述网址的问题，您如何在服务器端解析 Schedule.actor:Practitioner & Schedule.actor:Patient=5678 参数？他们不会翻译成像host/api/FHIR/DSTU2/… 这样的URL，即具有相同参数名称“actor”的URL？
stackoverflow.com/questions/38855829/…
这些搜索参数的上下文中并不真正涉及 URL。我们只是将值“1234”视为从业者 ID。病人也一样。我们假设/要求用于搜索的 ID 是我们的服务器 ID。我是否正确理解了您的问题？
知道了，还有一个查询，所以对于那个查询，您是只搜索“2016-07-21”还是“2016-07-21”之后的约会？
通常用于搜索您要执行 &start=ge2016-07-21 的日期“当天或之后”。见hl7.org/fhir/search.html#date。

【解决方案2】：

我可能在这里遗漏了一些东西，但不确定您如何定义时段和时间表之间的区别？

Schedule 资源只是定义了一个时间段，其中可能存在插槽，以及其他资源。它不定义或公开在此期间可能存在的约会。

slot search parameters 没有像您暗示的那样定义任何搜索参数。这些都在它链接的计划资源上。

从业者、位置和患者都可以有自己的时间表/时间段，因此它取决于定义复杂性的系统。一些系统决定他们只关心从业者（他们有自己的房间），其他系统只担心房间，稍后会分配从业者。

根据我对您的尝试的理解（在实践管理系统前创建 FHIR 外观），我认为您需要公开以下资源：

从业者：公开从业者的详细信息（如果您的从业者可以在多个地点工作，有兴趣）
时间表：为了简单地显示您接受约会的日期范围（并且将定义空位可用性）并且从业者链接到此资源，如果他们在多个地点工作，您将在每个地点都有一个从业者工作。（如果位置资源有自己的时间表，则需要进一步考虑，以及可用时隙的协商在哪里完成）
槽：定义可以安排约会的可用槽。（注意：这些不是约会）
约会：接收创建的约会（如果您无权访问日程，不知道您将如何处理此问题）
患者：假设您要将患者分配到预约中；）

如果这一切都有意义并且您澄清了您的环境，我将提出您可能需要处理的查询。

这是一个很好的问题，Patient Administration 正计划编写一些实施指南，以在各种环境（全科、住院、门诊、社区、实验室等）中实施此功能

【讨论】：

感谢Brian的详细回复，我会尽快把环境细节放在这里。在那之前只有一个问题 - 我们可以向任何 FHIR 请求引入额外的参数，对吗？ - 如果我们把它们放在服务器一致性声明中？
嗨，Brian，我假设日程只是医生的工作时间，对吗？假设一位医生从早上 8 点工作到下午 5 点，然后我将那个时间间隔视为时间表
在某种程度上是的，并且插槽定义了时间表上的实际特定实例。其中引用了该调度实例。
至于添加额外的参数，这样做会降低您的互操作性而无需更改。这是我们真正要寻找的点并用更好的选择代替。我仍然需要通过示例编写参考指南，很高兴收到关于您认为缺少的内容的反馈。
谢谢，想解释一下环境。在任何实践中，我们都为任何患者提供单一登录。因此患者可以前往example.com，选择组织并使用凭据登录以查看我们 EHR 中的记录。在同一网站上，我们根据用户的位置选择发布医生资料及其可用位置。当我们获取医生位置时，我们有 1 个用于所有实践 (example.com) 的 URL，因此我们需要医生 ID、实践 ID、位置 ID 和日期。这意味着，即使我们搜索医生日程，我们也需要组织 ID 和位置 ID。这能解释我们的环境吗？如果有任何问题，请告诉我。