工作组: FHIR Infrastructure 成熟度: N/A标准状态: Informative

FHIR包括两部分核心内容:

  1. 资源(Resources):与卫生健康相关的信息模型集合,它为“业务对象”定义了数据元素、约束和关系。 从模型驱动架构的角度来看,FHIR资源在概念上等同于XML或JSON中实现的物理模型。请参见资源定义
  2. 接口(API):用于两个应用程序之间互操作的标准预定义接口集合。虽然没强制要求使用RESTful API, 但FHIR规范中的API是这样实现接口的。 详情请参阅 FHIR RESTful接口

在卫生健康领域,“业务对象”的集合没有一种统一定义。FHIR理论的形成是基于共识对包括“患者”、“手术”、“观测”、“医嘱”等在内的一些核心通用业务对象标准化持续改进的过程。 请参见(已经定义的资源列表)。 FHIR规范提供了一个的框架用来:

  1. 定义卫生健康领域的业务对象(“资源”);
  2. 以组合的方式关联资源;
  3. 以可计算的形式实现资源
  4. 在标准预定义接口之间共享资源。
此框架为“FHIR式”API提供了一组规则和约束、方法和接口签名,并且还内置了验证和测试语法,以及服务器请求和传输FHIR业务对象的能力说明。

从运营角度来看,资源的构成与去留是由HL7的内部标准研制和治理流程决定的。 但FHIR规范还提供了一种机制,用于在特定范围内针对特定需求对资源进行场景化配置,(请参阅资源的配置)。

FHIR资源完全适用于信息架构域,而用于数据交换的FHIR API则与应用程序架构的各方面相对应。

从TOGAF的角度来看,fhir处理与信息模型定义和数据交换相关的体系结构视图的各个方面,这些方面在TOGAF体系结构开发方法的信息系统体系结构部分中进行了描述。 从TOGAF(开放组体系结构框架)的角度看 ,FHIR的架构视图与TOGAF架构开发方法中的信息模型定义和数据交换一致, 这在其“信息系统架构”部分有所描述,见图一。

Zachman框架 的角度看, FHIR的设计与其架构视角、工程视角和技术视角中的数据与功能维度相对应,见图二。

HL7服务互操作框架(SAIF) 的角度 ,FHIR资源和RESTFUL API分别代表的平台规划层中信息模型的“物理模型”和行为模型的“接口实现”。

FHIR的主要目的是使用结构化、可视化的数据模型和简单高效的数据交换机制来解决互操作性问题。 此外,FHIR符合以下架构原则:

  1. 重用和可组合性:FHIR资源的设计遵循了二八定律——聚集20%重要的部分满足其他80%的互操作需求。 为此,资源被设计为满足多数用例的通用或常用数据需求,以避免大量重叠和冗余资源。 提供扩展和定制(参见配置FHIR),以允许根据特定用例需求采用和调整通用的资源。 此外,FHIR资源是高度可组合的,因为资源经常引用其他资源。这进一步促进了重用,并允许从更多的原子资源构建复杂的结构。
  2. 可伸缩性:FHIR API使用REST架构风格来确保所有事务都是无状态的,这就减少内存使用,服务器集群不再需要sessions会话,因此支持水平扩展。
  3. 性能:FHIR资源体积小、适合在网络上进行交换。 很多实施者认为在共享和限制网络中使用标准的JSON/XML格式可以保证在多个系统间跨系统执行复杂事务的性能,而FHIR高度优化的数据格式可能做得更好。
  4. 可用性:技术专家和非技术人员都能理解FHIR资源。非技术人员即使对XML或JSON语法的细节不太理解,他们仍可以在任何浏览器或文本阅读器中查看并理解其中的内容。
  5. 数据准确性:FHIR是强类型的,具有内置的临床术语链接和验证机制。此外, XML和JSON文档可以在语法上预定义的业务规则来进行验证。这促进了数据的高度准确性,但是使用FHIR来实现语义级互操作性还有很长的路要走。
  6. 可实现性:FHIR的驱动力之一是需要在不同的开发人员社区中创建一个高度统一的标准。使用行业标准、通用标记和数据交换技术很容易理解和实现FHIR。

还有一些与一致性、粒度、引用完整性以及其他尚未建立或验证的架构原则可请参阅下面“已知问题”小节。

如前所述,FHIR的主要构件是资源和RESTfulAPI。但是,FHIR规范还有很多其它构件,包括下:

注:上述“构件”这个术语仅用于粗略的表示某事物的一部分, 并不是为严格本体、建模框架或其他架构和组织结构表示特定含义的术语。 下面的构件以UML类图来说明,这仅仅是为了利用它使用符号解释语义的优点。 FHIR在建模时并没有采用面向对象法,在FHIR规范中那些形如UML类或对象的构件也和面向对象无关。 同样,下面显示的UML包是概念性的,仅用于组织目的。

如图四所示,可以简单地将FHIR规范视为下列构件:

  • 信息模型——此组件与创建FHIR资源相关
  • 约束——此FHIR构件处理约束和符合性问题
  • 术语——此FHIR构件与临床术语和本体相关
  • 使用——此FHIR构件负责在运行时中使用FHIR的能力

上述各构件的描述:

以下列表提供了定义FHIR资源时适用的一般准则,它们大多数不是以编程方式强制执行的,需要人们遵守以下规则达到规范的目的。

  • 资源应该有一个清晰的边界:与一个或多个逻辑事务范围相匹配的边界
  • 不同的资源的含义应不同,而不仅仅是在使用上不同(例如,使用实验室报告的每种不同方法不应该产生不同的资源)
  • 资源需要具有一个自然本体
  • 大多数资源应该很常见,并用于许多不同的业务事务中
  • 资源不应该过于具体或详细,否则将缩小其支持业务交易的范围
  • 资源应该是互斥的,这是一个非常重要的考虑因素,有助于减少冗余和避免歧义
  • 资源应该使用其他资源,但它们应该不仅仅是其他资源的组成部分;每个资源都应该引入新的内容
  • 资源应该基于共性及其所链接的内容,织成一个逻辑框架(见下面的资源框架)。
  • 资源应该要足够大才能提供有意义的上下文,仅包含少数属性的资源就可能太小以至于无法提供有意义的业务价值。
  • 资源应能反映通用使用场景:
    • 如果大多数系统将某个事物视为一个独立的概念,则建议用单个资源; 如果大多数系统将某个事物视为不同的概念,则建议用多个资源
    • 如果对“资源”的两种不同使用会导致对“核心”的解释完全不同,则建议用两种资源可能更合适。
  • 倾向于减少资源而不是增加资源

用单一的信息模型来模拟整个卫生健康数据是不现实的。 每次建模,从HL7第二版消息规范到FHIR资源,都将 卫生健康信息域分为更小、更易于管理的子域或信息模型片段。FHIR的每个资源本质上都是大型卫生健康信息领域的一小部分。

当将卫生健康信息模型分解成更小的块(或FHIR资源)时,用一个框架和一套指南以资源相互引用的方式来促进内部的一致性和完整性尤为重要。 下面所示的框架包含卫生信息模型各子类别,这些子类别根据其共性程度被组织成若干层。 用这些层级和类别来区分哪些是最常见的卫生健康信息非常有用,因此需要得到最一致的定义和严格的管理。 顶层的类别最常用,它包含的FHIR资源支持了大多数的卫生健康事务。

对此框架中每个层级的描述:

  1. 框架资源 - Foundation Resources: 框架资源是最基本、最基础的资源。它们通常用于承担基础架构相关任务。尽管没有禁止,但其他资源一般都不会引用它们。
  2. 基础资源 - Base Resources : 第2级由基础资源组成。这些通常是资源图的叶节点。换句话说,它们经常被其他资源引用,但通常不引用其他资源。这些资源是最常用的, 因此需要最高程度的一致性和最缜密的架构。对第1级和第2级中的资源管理是最严的。
  3. 临床资源 - Clinical Resources: 第3级包含属于临床范围的资源,它们在许多场景下都很常用。这些资源包括临床观测、临床治疗、护理和药物。 这些资源可以独立使用,但通常会以第2级的资源作为基础。 例如,观测资源将引用第2级的患者资源。当这些资源被第3、4、5级的资源引用时,它们经常在特定场景中被赋予特定的意义.
  4. 财务资源 - Financial Resources: 第4级专注财务相关的资源。从逻辑上讲,财务资源以临床资源和基础资源作为基础。 例如,账单资源会引用临床事件和活动以及像患者这样的基础资源。
  5. 专业资源 - Specialized Resources: 在第5级中,是一些不太常用的专业资源。这些资源几乎总会引用更低层级的资源。 由于FHIR优先满足常见用例,这一层级的资源相对较少。
  6. 资源上下文 - Resource Contextualization: 第6级不包含资源。但正是它扩展了由前五级资源组成的框架结构。 第6层包括配置和资源图。为达到特定目的,可利用配置对资源进行扩展、约束或让其在特定的上下文中使用。 资源图是包含自身属性的资源组合或资源网组合。

根据以上框架组织的全套FHIR资源可以在资源页面上找到。

这个框架主要为以下三个目的服务:

  1. 为了方便的导航并找到资源而对它进行组织排列
  2. 根据常识分组将资源分类或描述同一类别资源之间预期结构和行为的模式。
  3. 跨层传播资源,以将相对公用的最常见的资源分到顶部层级

Purposes 2 and 3 set the foundation for future architectural rigor and resource governance to optimize consistency, integrity and predictability of new or refined resources in the future. The actual rules and patterns will be defined and refined in future FHIR releases. However, one general guideline to state now is that resources generally reference resources in the same layer or higher. In other words, a layer 4 resource will typically only reference resources in layers 4, 3, 2 or 1. There is nothing prohibiting a layer 4 resource from referencing a layer 5 resource, but this is not as common. Given this guideline, it is possible to identify the resources that are likely to be most common across use cases and therefore demand the highest degree of consistency and governance. Further, the framework helps identify the areas where creating new FHIR resources is the highest priority. It is generally a higher priority to create FHIR resources in the higher layers (layers 1, 2 and 3) than it is to create FHIR resources in the lower layers (layers 4 and 5) because the higher layer resources will provide the greatest value across the largest number of use cases and stakeholders. This is not to say that the business transactions needed for the higher layers are not important, it’s just that they are not as common across the whole healthcare space.

The 6th layer of the framework are not actually resources. Profiles and Graphs are extensions of resources or resource compositions that continue the progression through the FHIR Composition Framework. They provide additional contextualization required to satisfy certain use cases.

将FHIR资源的创建与该框架结合起来,会带来一些预期的好处:

  • Organization and manageability of health domains - the framework provides a basis for decomposition and modularity 健康领域的组织和可管理性——框架为分解和模块化提供了基础
  • Identifying commonality - the framework teases out the common areas from the less common areas 识别共性——框架从非共性领域中梳理出共性领域。
  • FHIR resources prioritization - the framework provides a structure for determining priorities and delegating work fhir resources优先级-框架提供了确定优先级和授权工作的结构
  • Tiered governance levels - the framework separates the areas needing the most stringent and universal governance from those that require more context-specific governance 分层治理级别-该框架将需要最严格和普遍治理的领域与需要更具体上下文治理的领域分开

The framework is further elaborated in the FHIR Resource Considerations page . 该框架在fhir resources注意事项页中进一步阐述

Another useful tool for visualizing how FHIR resources are organized relative to each other can be found using the Resource Reference Visualization tool on clinFHIR . 另外一种图形化FHIR resources,展示它们是如何联系的工具可以用clinFHIR

A FHIR REST server is any software that implements the FHIR APIs and uses FHIR resources to exchange data. The diagram below describes the FHIR interface definitions. The methods are classified as: fhir rest服务器是实现fhir API并使用fhir资源交换数据的软件。下图描述了fhir接口定义。方法分为:

  • iServeInstance – methods that perform Get, Put or Delete operations on a resource IServeInstance–对resource执行获取、放置或删除操作的方法
  • iServeType – methods that get type information or metadata about resources IServeType–获取有关resource的类型信息或元数据的方法
  • iServeSystem – methods that expose or enable system behaviors. IServerSystem–公开或启用系统行为的方法。

Additional details on the FHIR APIs can be found at the FHIR RESTful API and the Operations Framework. 有关fhir API的更多详细信息可以在fhir restful API和操作框架中找到

As mentioned, FHIR resources are optimized for stateless transactions with RESTful APIs. Although this is not the only way FHIR resources can be used, these types of transactions are the only ones with defined interfaces and behaviors in the FHIR specification. 如前所述,fhir resources针对使用RESTfulAPI的无状态事务进行了优化。尽管这不是fhir resources的唯一使用方式,但这些类型的事务是fhir规范中唯一具有定义的接口和行为的事务。

FHIR transactions follow a simple request and response transaction pattern. The request and response can be for a single payload or can operate as batch. The payload or a request and response consist of a header and the content of interest. See diagram below for details. fhir事务遵循简单的请求和响应事务模式。请求和响应可以针对单个负载,也可以作为批处理操作。有效负载或请求和响应由一个头部和感兴趣的内容组成。详见下图。

(section to be filled out) (but see Security in the meantime). (该部分待补充 ,目前可以参阅 安全 部分).

Example Use Cases Using FHIR FHIR的示例用法

For illustrative purposes, the following diagram depicts a simple use case of a patient accessing their personal health record (portal) enabled by an underlying electronic medical record (EMR) system. The EMR plays the role of the FHIR server in this example. 为了便于说明,下图描述了患者访问其个人健康记录的简单用例。 (门户)由基础电子病历(EMR)系统启用。在这个例子中,EMR扮演着fhir服务器的角色。

The pre-conditions for this use case are: 此用例的前提条件是:

  • the EMR implements the necessary FHIR APIs EMR实现了必要的fhir API
  • the EMR implements the necessary authentication and authorization mechanisms 电子病历实施必要的认证和授权机制
  • the patient is successfully authenticated and authorized to access FHIR resources 患者已成功通过身份验证并获得访问fhir资源的授权。

The basic flow of the use case is that the patient registers (if required), logs in, enters search criteria to identify a patient or patients of interest (the patient is most like themselves in this use case), retrieves clinical documents for the patient and retrieves clinical resources for the patient. The use cases utilize the GET methods on the iServeInstance interface and works with the following types of FHIR resources: 用例的基本流程是患者注册(如果需要)、登录、输入搜索条件以标识患者或 感兴趣的患者(在这个用例中,患者与自己最相似),为患者检索临床文档,以及 检索患者的clinical resources。用例使用IServeInstance接口上的get方法并工作 使用以下类型的fhir资源

  • The Patient resource 病人resource
  • One or more document resource(s) 一个或多个文档resource
  • One or more clinical resource(s) 一个或多个clinical resource

Although this example use case is very simple, more complex transactions using a combination of GETs, PUTs and DELETEs against resources and metadata can be envisioned. However, the exact details of these use cases including which methods are used, the orchestration of methods and the specific resources involved are outside the scope of the FHIR specification. 尽管这个示例用例非常简单,但是可以预见使用针对资源和元数据的GET、PUT和DELETE组合的更复杂的事务。但是,这些用例的确切细节,包括使用的方法、方法的编排以及所涉及的特定resource,都不在fhir规范的范围之内。

  • Resource Consistency and Granularity – there is nothing intrinsically prohibiting one resource from duplicating the same information as another resource. Further, there is nothing prohibiting resources with the same information from defining and modeling the data elements differently. HL7 has a number of processes to ensure that resources are consistently designed, but the question is when to be consistent within the specification, and when to be consistent with the real world practices of healthcare - these are sometimes in conflict with each other. Resource granularity is a related potential problem as there are variations in the size, complexity and comprehensiveness of the existing resources. Resource一致性和粒度——本质上没有什么禁止一个Resource复制与另一个Resource相同的信息。 此外,没有禁止具有相同信息的资源以不同的方式定义和建模数据元素。 HL7有许多过程来确保资源的设计是一致的,但问题是什么时候在规范内保持一致, 什么时候与现实世界中的医疗实践保持一致——这些过程有时会相互冲突。 资源粒度是一个相关的潜在问题,因为现有资源的大小、复杂性和综合性都存在差异。

    Further, the degree to which the FHIR specification can impose consistency is limited to how much agreement can be gained across various communities. While the Implementers Safety Check List and the Considerations for FHIR Resource Considerations provide guidance and promote consistency, rules for achieving complete consistency of both content and granularity amongst resources are neither completely defined nor completely enforced. Considering that FHIR is still a new and emerging standard, an over-abundance of constraint and rigor has been avoided to maximize initial adoption. Further, there is a natural tension between consistency and an architectural virtue and the practicalities of supporting the real practice of health care. Considering that FHIR ultimately is a reflection of the health business processes it supports, FHIR will always carry forward some of the data discrepancies, inconsistencies and gaps that are present in the practice of healthcare across different organizations and practitioners. Nonetheless, the issues of resource consistency and granularity is a topic that gets considerable ongoing discussion, and may change as FHIR approaches a final normative standard and as FHIR adoption approaches a level where more control is warranted, or more information/process consistency emerges in the existing healthcare systems. 此外,fhir规范对一致性的影响程度仅限于不同社区之间可以达成多少协议。 虽然实施者的安全检查清单和对fhir resource的考虑提供了指导和促进一致性, 但实现资源之间内容和粒度完全一致性的规则既没有完全定义,也没有完全执行。 考虑到fhir仍然是一个正在发展的标准,已经避免了过多的约束和严格,以最大限度地提高初始采用率。 此外,一致性与架构优势以及支持医疗实际做法的实用性之间存在着自然的张力。 考虑到fhir最终是它所支持的医疗业务流程的反映, fhir将始终在不同组织和从业者的医疗实践中结转一些数据差异、 不一致和差距。尽管如此,资源一致性和粒度问题是一个正在进行大量讨论的话题, 并且可能会随着fhir接近最终规范标准和fhir采用接近一个需要更多控制或现有医疗系统中出现更多信息/流程一致性的水平而改变
  • Resource References – there are currently a lack of strict rules for what resources should be referenced by other resources and under what circumstance. There is potential for ambiguity, duplication, inaccurate and/or conflicting information communicated by a resource graph (a collection of linked resources). Imagine the scenario where Resource Type A (e.g., procedure) references Resource Type B (e.g., encounter) and Resource Type C (e.g., patient), and Resource Type B (e.g., encounter) also references Resource Type C (e.g., patient). In this scenario, is a reference to Resource A to Resource C meant to provide the same information as the reference from Resource B to Resource C? If so, is this duplication of information problematic? Note that this is not unique to FHIR - it is an innate property of information systems. If an actual instance of A, and the B that it references, reference different instances of Resource C (e.g. the procedure references patient X and an encounter for patient Y), how does the system know that the references are intentionally different versus an error or data anomaly? The problem is that there is limited ability to describe the intent of the reference which leads to the possibility of ambiguity and error. The Linkage resource can be used to help with this problem, but additional capabilities may be considered in the future to allow systems to address referential integrity. Resource引用——目前缺乏对哪些Resource应该被其他Resource引用以及在什么情况下引用的严格规则。Resource图(链接Resource的集合)传达的信息可能存在歧义、 重复、不准确和/或冲突。想象一下这样的场景:Resource类型A(例如,程序)引用Resource类型B(例如,遭遇)和Resource类型C(例如,患者), Resource类型B(例如,遭遇)也引用Resource类型C(例如,患者)。在这种情况下,ResourceA到ResourceC的引用是否意味着提供与ResourceB到ResourceC的引用相同的信息? 如果是这样的话,这种信息复制有问题吗?请注意,这不是fhir独有的,它是信息系统的固有属性。如果A和B的实际实例引用了ResourceC的不同实例(例如, 程序引用了患者X,遇到了患者Y),那么系统如何知道这些引用相对于错误或数据异常有意不同? 问题是,描述参考意图的能力有限,这导致了模糊和错误的可能性。可以使用链接资源来帮助解决这个问题,但是将来可能会考虑使用其他功能来允许系统处理引用完整性。
  • Conditional Semantics – Currently, the constraints for element definitions including things like data types, value sets, optionality and cardinality are defined at design time with limited consideration for variable run-time semantics. Imagine the scenario where the value of Data Element Y (e.g., “intolerance type”) is constrained differently depending on the value of Data Element X (e.g., “causative agent”) in a given instance of a resource. For example, if the instance of an Intolerance Resource has the “intolerance type” data element populated with “food intolerance”, then “causative agent” should be constrained to only valid values for this value set (e.g., valid foods instead of medications or environmental agents). Tools for addressing deep semantic consistency in this regard are only gradually developing. 条件语义- 目前,元素定义的约束包括数据类型、值集、可选性和基数等。 在设计时定义,对可变运行时语义的考虑有限。假设数据元素y的值(例如,“不容忍类型”)是 根据给定resource实例中数据元素x的值(例如,“因果代理”)的不同约束。例如,如果 不耐受性resource具有“不耐受性类型”数据元素,填充有“食物不耐受性”,那么“致因”应仅限于有效的 此值集的值(例如,有效食品而不是药物或环境因素)。用于解决此问题的深层语义一致性的工具 尊重只是在逐渐发展。
  • Business Rule Enforcement and Validation – As governance increases and more resource rules are defined, it may be advantageous to have a resource validation tool that checks for things like resource consistency, duplication, referential integrity, circular or nonsensical references, and other defined and approved validation rules. Once rules are agreed to, this level of automation can help address the other issues outlined above. These kinds of facilities are planned for the future. 业务规则实施和验证- 随着治理的增加和更多的resource规则的定义,进行resource验证可能更为有利。 检查resource一致性、重复、引用完整性、循环或无意义引用以及其他已定义和已批准的内容的工具 验证规则。一旦规则达成一致,这一级别的自动化就可以帮助解决上面概述的其他问题。这些设施都是为未来规划好了的 。