原文链接：Responsibilities of a FHIR client
FHIR 客户端的职责
当在我们Orion Health 公司开始进行实质性的FHIR开发工作的时候，我们就FHIR接口做了大量的限制和约束，这些决定无疑会影响客户端使用我们所提供的服务。 通常，我们使用Conformance资源来记录这些限制和约束的决策，这也让我不禁想起一个FHIR 客户端总体上应具备的职责。
尽管对FHIR是一种比其他标准更易于开发的观点不存在过多分歧，但它仍然是为了解决医疗信息的交换而生的，而问题本身是极其复杂的。 尽管设计人员已尽其所能将复杂度转移至服务器端而非客户端，实现同样的目的仍然存在多种方式，这也就意味着除了遵循spec中资源和接口的规定，FHIR 客户端仍然有很多额外的职责。
让我们逐一来看一看。
首先是扩展，FHIR的一大卖点就是扩展，有了它，基础的资源才能够足够简单，FHIR的内在扩展机制使得具体系统的开发可以按需添加额外的属性字段到资源中去，对于客户端而言，要能够理解它所不知道的扩展，也就是说，客户端在处理资源内容时需要特别地查找扩展，根据 客户端的了解程度来做出决策。
对于标化扩展(字段名称为extension)，其中包含的信息对客户端来讲可能是有用的，但忽略其中的内容从临床上来讲也是安全的。比如我们要在Patient中记录患者的宗教信仰，可能是很有意思的信息，但对于临床来讲不是很重要。
spec中并没有指明客户端该如何处理未知的扩展，其中强烈建议将扩展的含义包含在资源的文本描述之中(narrative)，这样至少可以将其展示给用户，但这取决于具体的开发实现。
同样需要注意的是，扩展可以出现在资源的任何未知：
对于Modifier类的扩展(字段名称为 modifierExtension)，则是另外一种情况。从临床安全的角度来讲，这类信息对于客户端来讲是必须理解的。比如，你如果想表达某个患者并没有某种病情，那么就新建一个negative的扩展。另一个例子是表达患者并没有得truncal rash。很显然，此类扩展完全改变了资源内容的含义，从临床上来讲，客户端忽略此类信息是不安全的。spec中明确指出：
Modifier类的扩展出现的位置相对受限，尤其是它不能更改包含数据的属性/字段，也就意味着着它只能作用于资源类型或类的层面上。
客户端必须查找扩展，尤其是modifierExtension
FHIR 中充满了资源间的链接，了解如何理解引用对于客户端是很重要的。大体上，也是有2类引用。
最常用的是对独立资源的引用，可以是同一个服务器上的本地资源，也可以是不同服务器上的资源。每个资源都有一个唯一id，但获取资源的具体 机制则大不相同。 可能是客户端中已经拥有的bundle中存在的资源内容的一个copy副本，或者是客户端需要直接从某个服务器中获取。
另一种则是内嵌资源，这种常用于被嵌入的资源不是独立存在的，比如服务器中只使用药品编码的话， MedicationPrescription中可能包含一个内嵌的Medication 资源，内嵌资源的ID是以#开头的，内嵌的资源除了不能有text字段之外，和其他资源都是一样的。 (内嵌的资源不能再内嵌资源)
客户端不需要过多操心的是Profile，由于profile基本上就是一个如何使用资源来满足某个特殊案例/场景需求的声明，在不知道资源遵循哪个profile的前提下， 客户端应该能处理任意的资源,如果资源中不存在某个值，客户端不能根据profile得到默认值。
也就是说客户端不能做预设，不管资源声称遵循哪个profile，客户端都要进行核对/校验。比如资源遵循某个profile(其中将一个可选字段改为必选) 客户端必须要核对，而且要能处理存在错误或省略的情况。可编码字段是另一种情况，不管profile有没有强制规定使用某个特殊字典或值集，不意味着资源中数据必须遵循这个约束。
综上所述，有3点：