0

目前 (02-12-2013)，在从业者资源 0..1 中，名称可以与从业者相关联。相反，0..* 名称可以与患者相关联。例如，这允许指定一个人的娘家姓。为什么会有这种差异？

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

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

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

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

类似地，从业者只允许 0..1 个地址的限制（如这里所讨论的）也似乎是不必要的限制。

4

2 回答 2

1

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

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

  1. 拥有 Person 资源，与 Patient/Pracitioner 分开。这被证明是繁重的，因为许多系统（与您的不同！）不会分别捕获患者和人员，并且在查看 REST 使用模式时发现它们总是需要一起使用，从而给客户端和服务器带来不必要的负担
  2. 具有包含所有共享属性的特殊 Demographics 数据类型。这遇到了阻力，因为这意味着在 Practitioner 上具有没有意义的属性，例如婚姻状况和 deceasedDate。这违背了我们保持资源专注于其范围和每个资源可管理的属性数量的意图。

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

类似地，只允许从业者使用 0..1 个地址的限制（也 > 在这里讨论过）似乎也是不必要的限制。

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

于 2013-12-19T13:39:14.240 回答
1

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

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

<Practitioner>
  <extension url="http://myurl.com/fhir/profiles/extensions#maiden">
    <valueHumanName>
      <!-- details for human name -->
    </valueHumanName>
  </extension>
</Practitioner>
于 2013-12-02T12:05:09.387 回答