Question

目前（02-12-2013），在从业者资源0..1名称可以与从业者相关联。相反，0 .. *名称可以与患者相关联。例如，这允许指定人的婚前姓名。为什么会出现这种差异？

在我正在开展的项目中，我们使用FHIR消息从我们的数据库中导出有关从业者的现有数据。在数据库中，所有人都以相同的方式存储。由于可以存储一个人的婚前姓名（这也是我们数据中的从业者所做的），我们必须在医生信息中建立姓名部分，这与患者信息中的姓名部分不同。此外，在解析从业者消息时，我们需要不同的代码来提取患者和从业者的姓名。

因此，我认为不同类型的人具有不同的通用属性有两个缺点：

它阻止我们在不诉诸分机的情况下发送从业者的完整姓名信息。
它使构建和解析FHIR消息的代码变得复杂，这也使得代码的可维护性降低。

据我所知，在大多数情况下，能够发送从业者的婚前姓名并不是非常重要，但它确实为实施增加了额外的复杂性。此外，我没有看到将基数设置为0 .. *会导致什么问题。如果有人只想发送一个名字，那么这仍然是可能的。

同样，限制只允许0到1地址的从业者（也讨论here）也似乎是一个不必要的限制。

Answer 1

管理基数是一个棘手的问题。如果资源可以有多个名称，那么处理这个问题的每个人都必须处理多个名称的可能性。相关委员会认为，拥有多个名字对于从业者记录来说是一种不寻常的做法（这当然是我的经验），但对于患者来说却是一种常见的做法。

也许您想解释一下您的完整用例，以便委员会可以考虑？另一方面，您可以使用扩展名：

<Practitioner>
  <extension url="http://myurl.com/fhir/profiles/extensions#maiden">
    <valueHumanName>
      <!-- details for human name -->
    </valueHumanName>
  </extension>
</Practitioner>

Answer 2

因此，我认为有两个缺点不同类型人的不同通用属性：

在设计Patient，Pracitioner和RelatedPerson时，我们尝试了几种不同的解决方案：

拥有Person资源，与Patient / Pracitioner分开。这被证明是繁重的，因为许多系统（不像你的！）不会单独捕获患者和人，并且当看到REST使用模式时，结果发现它们总是需要时间，导致客户端和服务器的不必要负担
具有包含所有共享属性的特殊Demographics数据类型。这符合抵抗，因为它意味着在没有意义的实践者身上具有属性，例如婚姻状况和死者日期。这违背了我们的意图，即保持资源集中于其范围和每个资源的属性数量可管理。

这就是我们现在所处的位置：或多或少地“复制”这三种资源的属性（如果适用）。

同样地，限制只允许0到1地址的从业者（也在这里讨论）也似乎是一个不必要的限制。

从业者资源代表组织雇用提供护理的人员。我们假设对于一个这样的约定，该人有一个“官方”（邮寄）地址。然而，从业者可以在多个位置（每个位置都可以有一个地址）执行服务。

从业者的多个名字

2 个答案: