跳到主要内容

3.2 业务角度

大多数情况下，解决方案提供商在设计上都不会选择完全支持FHIR规范的全部内容。不过FHIR标准规范是支持增量的、渐进式的应用。一些解决方案，像通用的术语服务，只需要提供FHIR规范的一个子集就可以满足解决方案需要。最简单的术语服务仅需要提供ValueSet资源及其支持的操作就可以，不需要其他的FHIR资源。

项目采用FHIR标准规范的开始阶段，许多解决方案提供商仅支持最基本的资源读取操作，并不支持资源的写入功能。这种情况可能会随着时间而改变，解决方案提供商可能会逐步支持资源的写入功能。因为从业务流程上来讲，支持写入功能是一项复杂的工作，尤其是那些具有复杂业务逻辑的数据处理，因为这些数据写入事件可能会触发其它的数据写入事件。

FHIR标准规范的应用，从业务角度来说，主要有两个方面，首先是医院信息集成，其次是区域互联互通，包括医联体、医共体和区域平台。当然，这两类业务也有其共通的部分，这里称之为基础服务。医院信息集成体现在FHIR标准上有两部分组成：离散状态的资源，包括像诊疗活动（Encounter）、诊断（Condition）、手术操作（Procedure）、服务申请（ServiceRequest）这些常用的资源等，以及将这些资源关联起来的，表现为业务流程的工作流（Workflow）。而在区域互联互通领域主要的应用场景则是跨机构的业务协同。同时，FHIR标准规范在互联网和物联网领域也在飞速的发展。

3.2.1 基础服务​

在医院和区域卫生信息系统解决方案中典型的基础类服务包括居民、医师、卫生机构、位置这些主数据注册服务以及术语、审计、文档共享服务等。这些基础服务都是非常成熟和稳定的，在最新版本的IHE规范中也都加入了对FHIR标准规范的支持，像PDQm、PIXm、mACM、IUA、MHD等等。

现在以文档共享服务为例，文档共享服务包括文档存储和文档注册两个组成部分，通常情况下都是参考IHE XDS规范进行设计的。但是XDS规范并没有直接支持移动设备或现代REST接口，因此限制了对这些共享文档的移动访问。

IHE现在推出了IHE XDS规范与FHIR规范集成的第一步 —— 移动健康文档（MHD）规范，允许移动设备以及其他资源受限的系统使用MHD规范访问文档存储库中的共享文档。基于FHIR规范的DocumentManifest、DocumentReference和Binary资源，提供了共享文档的创建、存储和调用方法。FHIR规范除了共享传统的文档（如 PDF）之外，还提供结构化临床文档功能，其继承并兼容了目前非常成功的HL7 CDA规范。

在项目实践过程中，我们一般都把FHIR规范作为IHE XDS的补充，技术上采用边车模式。有关边车模式参见本章技术角度3.3.2的详细说明。在我国，HL7中国也在尝试将MHD规范本地化，在2021年的FHIR Connectathon互联互通测试大会上其中的XDS-on-FHIR场景就为XDS+MHD落地实现提供了方向指引。

3.2.2 工作流​

FHIR规范中针对每个资源的操作都是离散状态的，但是在医院信息化中业务都是流程化的，一个步骤接着一个步骤，还可以有分支，跟平时绘制的流程图一样。所以，在FHIR规范一个很重要的内容就是工作流（Workflow）。工作流的内容如下图所示：

图形用户界面, 应用程序 描述已自动生成

首先FHIR规范定义了涉及活动的三类资源，定义、请求和事件。定义可以定义请求和事件，请求可以触发事件，请求还可以触发另一个请求。图中的替换表示版本的更替，包含表示可以嵌套的父子关系。

下面以一个卫生领域常见的场景来介绍工作流 —— 双向转诊。医院医生根据患者意愿并综合患者病情、转入医院学科特长和床位占用情况等信息向社区医院发送转诊预约申请（请求资源），经社区医院转入医生审核同意后反馈转出医院，同步传送电子病历、检查检验结果信息和电子健康档案信息。患者到诊后，回传患者到诊消息通知。主要业务过程包括床位信息查询、转诊预约申请提交、申请审核与确认、审核应答、履约情况确认、上传患者病历等步骤。

上述场景中涉及的流程及流程的活动是通过如下两个FHIR资源来定义的：

  • 活动定义资源（ActivityDefinition）： 定义在业务流程中每一个活动步骤，描述其在流程中的作用。
  • 计划定义资源（PlanDefinition）： 可以对活动定义资源进行组装，并描述活动之间的先后关系，触发条件等信息，该资源可描述一个完整的业务流程。

首先是定义（这里进行了简化），使用活动定义资源分别定义双向转诊流程中预约申请、预约应答、到诊应答、上传病历四个步骤。使用计划定义资源定义了双向转诊业务流程，通过其action元素将以上四个步骤组装起来，每个action元素关联一个步骤。可以通过此流程定义资源实例实现流程自动化。转诊预约申请活动为该流程的第一步，转诊申请发起后，根据转诊预约应答来确定后续步骤，如果为不同意，结束流程，如果为同意，等待患者到诊应答，患者到诊应答结束后，上传完整病历信息。

活动定义资源中有一个kind元素，此元素描述了该活动具体使用哪种资源类型，即活动实例资源类型。例如：转诊预约申请使用的就是继承自Appointment资源的HospitalReferral资源结构定义。此场景中涉及的活动实例资源如下：

  • 转诊预约申请资源（HospitalReferral）： 该资源描述医院转诊的申请。包括上转、下转都使用该资源。
  • 转诊预约应答资源（HospitalReferralResponse）： 该资源描述在提交转诊申请后，由接收方给出是否同意的转诊应答。
  • 任务资源（Task）： 在该场景下描述上传病历的步骤任务。

上述流程定义、活动定义、活动实例资源的关系图如下所示：

3.2.3 医师助手​

业务协同指实现医疗机构之间的业务协同，医疗机构、社区及纵向业务联动等。在这里医疗机构之间（含医院与社区卫生服务机构之间）的协同，我们称之为医疗业务协同。如果协同的范围不仅是医院、社区，还有公共卫生机构，协同的内容包括临床和预防保健，我们称之为卫生业务联动。

卫生业务的联动主要体现在区域范围内各医院、社区卫生服务中心与疾控、妇幼保健等业务条线的业务联动。由于许多卫生服务的信息源头是二、三级医院，例如产妇在产科医院分娩，产妇出院后，社区可以开展后续的产妇保健工作。同样患者在二、三级医院手术，手术出院后，需要康复指导。以前由于信息不通，社区卫生服务人员不能及时获得二、三级医院的信息，无法开展高效的卫生服务。

医师助手这种工具在业务协同应用中非常普遍，可能各个解决方案供应商的叫法各不相同，但是作用基本都是大同小异，例如：重复检查、重复检验、重复用药、合理用药等等。一般来说，业务协同引擎都是由平台级应用来提供，像区域卫生信息平台和医院信息平台。部署在医生工作站上的医师助手在医生诊疗过程中，与位于平台端的业务协同引擎互动，为医生提供辅助诊疗决策信息。这些业务协同的目标就是有效利用医疗资源，降低医疗成本，提高医疗质量。

医生助手在应用过程中的触发方式主要有如下两类：

  • 主动触发：医生通过医生工作站进行业务活动时触发，如医生在编写电子病历时触发辅助诊断；开具检查检验单时，触发重复检验检查判定。
  • 被动触发：主要指卫生业务联动，患者在医院就诊时，诊断为慢病、传染病时，信息由医院端同步到社区，由社区医生负责为这些患者创建专档，并为这些患者安排随访计划。

3.2.4 互联网和物联网​

FHIR规范最初设计的目标之一就是：

促进传统医疗保健系统之间的互操作，使原本向医疗保健提供者和个人提供的在计算机或平板电脑的各种设备上的医疗保健信息，变得更容易到手机，并允许第三方应用程序开发人员提供可以轻松集成到现有系统中的医疗应用程序。

目前在互联网移动应用中，居民健康档案记录管理是最为常见的应用方式。FHIR规范是以资源为基础，为逻辑上分散的健康数据开发的技术规范，允许数据通过标准API方便快捷的调用和传输。与现行用来交换临床数据的数据格式编码相比，以FHIR规范进行数据编码则更加的简洁，易于在移动设备上使用。FHIR规范基于简单的XML或JSON结构，定义了一套可以独立管理的资源，以及基于RESTful的网络传输协议。而且FHIR规范提供了很多编程语言的支持，因此在移动设备上开发既简单又方便。移动设备通过RESTful接口传输数据，这些轻量级的请求只需占用很小的带宽，就能把目标数据发送到移动端，大量的工作都是由服务端完成的。

物联网技术已成为数字医疗领域里程碑式的进步。物联网医疗设备数量呈指数级增长，到2020年为止，全球已有超过1.61亿台联网设备。由于高速网络技术的发展，可穿戴设备、智能手机和其他移动平台在医疗保健领域的日益普及，以及现在存在大量的物联网医疗设备，导致连接到医疗物联网世界的无数异构设备的集成难题。基于FHIR规范的自描述定义模型（StructureDefinition、DeviceDefinition等）可以很好的解决物联网设备医疗健康数据映射的难题。