跳到主要内容

2.1 设计路线

2.1.1 设计概述​

FHIR设计的初衷是充分利用Web技术和开放的互联网标准，更好地解决现有标准面临的挑战以及适应新的、未来的市场需求。FHIR解决方案由一组称为“资源”（Resources）的模块化组件构建而成。这些资源可以组装起来，高效地解决现实世界的临床和管理问题。FHIR亦可支持各种新的应用场景，比如手机应用程序、云应用、数据交换共享和大型医疗机构内的互联互通等。

FHIR的核心包含两个主要组件：资源和APIs

资源： 为医疗健康相关的“业务对象”定义的数据元素、约束和关系的信息模型集合。从模型驱动架构的角度来看，FHIR资源在概念上等同于以XML或 JSON 实现的物理模型。

APIs： 一组定义良好的接口，用于在两个应用程序之间进行互操作。虽然不是必需的，但FHIR规范定义了针对API实现的RESTful接口。

FHIR规范提供了一个框架，用于定义医疗健康业务对象（资源），以组合方式将资源关联在一起，以可计算的形式实现，并通过接口共享。该框架包含可验证和可测试的语法、规则和约束、APIs的方法和接口签名，以及用于实现能够请求和交付 FHIR业务对象的服务提供者的规范。

2.1.2 设计原则​

FHIR设计遵循以下架构原则：

可复用性和可组合性：FHIR资源的设计考虑了80/20原则。资源旨在满足用例的通用数据要求，避免造成大量重复、冗余。同时，允许根据用例要求增加定制化扩展，从而调整通用资源。此外，FHIR资源可进行组合，资源可以引用其它资源，原子资源可构建为复杂结构，从而进一步促进资源的可复用性。

可扩展性：FHIR APIs与REST架构风格一致，所有事务都是无状态的，从而减少了内存使用，消除了服务器场（群集）内对状态会话的需求，因此支持水平可扩展性。

高性能： FHIR资源结构比较轻巧，适合跨网络交换。高优化的格式能提高跨网络的多个系统之间处理复杂事务的性能，因此基于标准的XML/JSON,就足以实现FHIR资源交换。

可用性： 技术专家和非技术人员都能够快速了解FHIR资源的意义。非技术人员即使不了解 XML或JSON语法的细节,也同样可以在任意浏览器或文本阅读器中轻松看懂其中的内容。

数据保真度： FHIR资源是强类型的，并内置了临床术语链接和验证机制。此外，可以对XML和JSON文档进行语法验证，也可以根据定义的业务规则进行验证。多种措施确保了数据的真实性，并且有助于实现语义互操作性。

可实施性： FHIR的驱动力之一是创建一套在不同的开发人员社区中得到广泛应用的标准。FHIR使用行业标准、通用标记和数据交换技术，以便理解和实施。

2.1.3 FHIR分解​

如前文所述，FHIR的主要组件是资源和RESTful APIs，FHIR规范还包括下列组件：信息模型、约束、术语和使用。

图形用户界面, 图示描述已自动生成

  • 信息模型：与FHIR资源创建相关的FHIR组件，主要包括基类（Element和Resource）、基类的定义、数据类型；
  • 约束：FHIR解决约束和有效性的组成部分，主要包括一致性声明Conformance Statement和规程配置Profile；
  • 术语：FHIR中与临床术语和本体相关的组件，主要包括代码系统 Code System和值集Value Set；
  • 使用：FHIR的组件，在运行时如何使用FHIR，主要包括REST API。

2.1.4 资源框架​

资源是FHIR的核心组成部分，是医疗健康信息模型的载体。资源通过定义数据元素组件、数据约束和数据关系一起构成可交换的单元。资源是一个实体，具有以下特性：

  • 有一个已知的标识（一个 URL），可以通过它来寻址；
  • 包含资源类型定义所描述的一组结构化数据项；
  • 有一个确定的版本，随着资源的内容变更。

将医疗健康信息模型分解为更小的FHIR资源时，我们需要一个框架或指导方针，以便促进资源结构和资源相互引用方式的一致性和完整性。

资源框架依据健康信息模型子类别的共性，将它们组织成层。层可用于识别医疗保健信息的哪些部分最常见，因此需要进行一致的定义和严格的管理。顶层的类别是最常见的，包含支持最多常见医疗健康事务的FHIR资源。

表格描述已自动生成

框架中各层的说明：

基础资源：基础资源是最基本的资源。它们通常用于基础设施类任务。它们通常不被其它资源引用。

基本资源：第二层由基本资源组成。它们经常被其它资源引用，但通常不引用其它资源。基本资源比较常用，需要最高程度的一致性和架构严谨性。第一层和第二层的资源是治理最好的资源。

临床资源：第三层主要是临床性质的资源，但在许多用例中也很常见。临床资源包括用于临床概要、诊断、用药、治疗和护理提供等资源。这些资源可以独立使用，但通常建立在第二层的资源之上。例如，临床概要引用第二层的患者资源。当这些资源被第三层、第四层和第五层的资源引用时，它们也经常具有上下文属性。

财务资源：第四层专门用于财务资源。从逻辑上讲，财务资源建立在临床资源和基本资源之上。例如，计费资源将引用临床事件和活动以及患者这样的基本资源。

专业资源：在第五层，我们为不太常见的用例找到了更专业的资源。这些资源几乎总是引用较低层中的资源。鉴于FHIR优先考虑满足最常见的用例，这一层的资源较少。

资源上下文化：第六层实际上并不是资源，它扩展了由前五层资源组成的组合框架。这一层包括规程和图表。规程用于为给定目的扩展、约束或以其它方式将资源上下文化。图表是资源的组合或资源网络，包含它们自己的属性。

2.1.5 使用要点​

2.1.5.1 组合、扩展和创建资源​

组合资源

资源是指医疗信息互操作中的最小信息交换单位，资源往往代表单个信息模型。单独一种资源可能会有实用性，但是更常见的情况是借助资源引用关系，将若干资源组合起来，从而实现具体的业务场景应用。

扩展资源

较为常见的情况是现有资源通常能满足绝大部分需求，FHIR具有内部扩展机制，可对其进行适当的扩展来满足特定的业务需求，比如描述“患者”的资源，需要扩展定义新的元素来承载“户籍”和精确“出生时间”的这类业务表达。资源中的每个元素都可以具有扩展子元素，以表示不属于资源基本定义的附加信息，主要包含扩展元素和修饰符扩展两种形式。扩展资源应遵循主要几项原则：

扩展元素（Extension）

  • 资源或数据类型中的每个元素都包含一个可选的“扩展”子元素，该子元素可以出现任意多次；
  • 扩展应具有值或子扩展，但不能同时具有具有值或子扩展；
  • 如果处理资源内容的应用程序忽略扩展是不安全的，则应使用修饰符扩展而不是extension元素来表示；
  • 有一些资源不允许在根元素上进行扩展，但其他元素可以进行扩展。

示例：

对“患者”资源的元素进行扩展，定义新的元素“出生时间”（birthTime）来记录患者精确的出生时间，扩展元素定义如下：

<!-- birthTime -->
<extension xmlns="http://hl7.org/fhir"
     url="http://hl7.org/fhir/StructureDefinition/patient-birthTime" >
  <!-- from Element: extension -->
 <valueDateTime value="[dateTime]"/><!--  1..1 Value of extension -->
</extension>

精确出生时间北京时间 2003 年 1 月 12 日早上 9 时 12 分 35 秒可以表示为：

<!--出生日期，时间-->
<birthDate value="2003-01-12">
<extension url="http://hl7.org/fhir/StructureDefinition/patient-birthTime">
<valueDateTime value="2003-01-12T09:12:35+08:00"/>
</extension>
</birthDate>

修饰符扩展（ModifierExtension）

  • 有些修饰符扩展会修改包含它的元素的含义，比如：使用Condition资源来记录患者有家族病史而不是病情本身；
  • 修饰符扩展不得改变 Resource 或 DomainResource 上任何元素的含义（包括不能改变修饰符扩展本身的含义）。

示例：

MedicationRequest中没有表示“反处方（在特定时期内不服药的医嘱）”的元素。典型的临床记录系统不会将其记录为处方，但一个特定的系统会记录，并且这些“反处方”记录需要在发生这种情况的机构内共享，因为它们是工作流程的重要组成部分。因此，允许应用程序使用如下数据扩展资源：

<MedicationRequest>
  <modifierExtension url="http://example.org/fhir/StructureDefinition/anti-prescription">
      <valueBoolean value="true"/>
  </modifierExtension>
  <!--…其他内容… -->
</MedicationRequest >

创建资源

FHIR标准一直在快速发展和持续完善中，每一个版本变更往往会引入新的资源，对已有资源进行调整、甚至停用。在实际业务中，应尽量采用现有资源或者通过对资源进行组合、扩展等方式满足应用需求。如果经过仔细分析研究，上述方法无法有效满足需求，可以考虑创建新的资源来应对。创建资源应遵循主要几项原则，包括：

  • 资源应该有明确的界限；一个资源匹配一个或多个逻辑事务范围。
  • 资源应该在含义上彼此不同，而不仅仅是在使用上（例如，使用实验室报告的每种不同方式不应创建不同的资源）。
  • 资源需要有一个自然的身份。
  • 大多数资源应该是常见的，并在许多不同的业务交易中使用。
  • 资源不应具体或详细到足以排除对广泛业务交易的支持。
  • 资源应该是互斥的。这是一个非常重要的考虑因素，有助于减少冗余和歧义。
  • 资源应该使用其它资源，但它们应该不仅仅是其他资源的组合；每个资源都应该引入新颖的内容。
  • 应根据资源的共性及其链接的内容将资源组织成一个逻辑框架。
  • 资源应该足够大，以提供有意义的上下文；仅包含少数属性的资源可能太小而无法提供有意义的业务价值。
  • 资源应反映一般用途：如果大多数系统将某物视为一个单一的概念，这意味着单一的资源；如果大多数系统将某些事物视为不同的概念，那么这表明存在多种资源。
  • 如果“资源”的两种不同用途会导致对构成“核心”的解释大相径庭，那么这表明两种资源可能是合适的。
  • 倾向于更少而不是更多的资源。

2.1.5.2 FHIR APIs​

FHIR符合“RESTful”规范，是基于REST标准的行业级使用。在实践中，虽然通过扩展可实现完整的“REST成熟度模型”第3级的一致性，但是FHIR仅支持将“REST成熟度模型”的第2级作为其核心规范的一部分。FHIR是一个标准，它依赖于资源结构和接口的标准化，即使可能被认为违反了REST原则，但却是保证跨系统一致互操作性的关键。

API将FHIR资源描述为对资源的一组操作（称为“交互”），其中各个资源实例按其类型在集合中进行管理。服务提供者应说明支持哪些交互和资源。

主要交互API如下：

实例级交互：

read读取资源的当前状态
vread读取资源特定版本的状态
update通过id更新现有资源（如果是新资源，则创建）
patch通过发布一组更改来更新现有资源
delete删除资源
history检索特定资源的更改历史记录

类型级交互：

create创建具有服务器分配ID的新资源
search根据某些过滤条件搜索资源类型
history检索特定资源类型的更改历史记录

全系统交互

capabilities获取系统的能力声明
batch/transaction在单个交互中更新、创建或删除一组资源
history检索所有资源的更改历史记录
search根据某些过滤条件搜索所有资源类型

2.1.5.3 交易事务​

FHIR资源针对使用RESTful API的无状态事务进行了优化。虽然这不是使用FHIR资源的唯一方式，但这些类型的事务是唯一具有FHIR规范中定义的接口和行为的事务。

FHIR事务遵循简单的请求和响应事务模式。请求和响应可以针对单个有效负载，也可以作为批处理操作。有效负载或请求和响应由标头和相关内容组成。

2.1.5.4 安全​

安全应当依照法律、行政法规的规定和国家标准的强制性要求，采取技术措施和其他必要措施，保障数据的完整性、保密性和可用性。FHIR相关安全规范请参见4.7 安全隐私模块部分。