8.1 区域协同“双向转诊”场景中FHIR标准应用实践
8.1.1 背景
为贯彻落实国务院办公厅《关于印发深化医药卫生体制改革 2019年重点工作任务的通知》(国办发〔2019〕28号)精神和国家卫生健康委工作要求，加快推进四川省紧密型县域医疗卫生共同体建设试点工作，我们通过调研、论证后决定制定基于HL7 FHIR的本地化标准来推进区域内各成员单位信息系统融合，实现数据共享，推进区域内资源配置、业务协同、效率监测等数字化运行。
在诸如区域内等区域协同环境下的众多医疗业务场景中，我们从“双向转诊”业务场景开始进行业务流程分析，抽象归纳后，以四川省卫生信息学会全民健康信息标准专业委员会（简称标委会）的科研课题《基于FHIR标准实现医疗卫生术语和管理》为基础，建立统一的数据标准和交互标准，利用多年积累的科研技术成果集成交换服务网关——医易通作为技术支撑，探索构建基于FHIR标准的健康信息交换服务网络（HIE-Net），形成可推广复制的协同服务网络体系。
8.1.2 业务需求
8.1.2.1 概述
在区域协同医疗服务体系中，双向转诊是根据患者病情需要进行的本级医院与上下级/基层医疗机构之间的协同诊疗服务。 双向转诊系统以整合电子病历信息为基础，实现上下级医疗卫生机构间相互转诊及转诊过程中的电子病历数据的流动与共享。
电子病历信息共享是双向转诊的核心，也是提高医疗质量、降低医疗风险的关键。转入机构的医生能够通过计算机调阅到该患者在转出机构就诊时的电子病历信息，并且可以查阅该病人以前的病史信息，减少不必要的重复化验。
向上转诊。一般的常见病、慢性病应在基层医疗机构诊治， 受条件所限基层医疗机构难以诊治的轻度疑难复杂或急性期的常见病患者，由基层医疗机构通过双向转诊中心填写申请转诊单转往县级医院诊治，上转之前完善患者电子病历等转诊信息，将转诊电子病历信息上传至电子病历共享中心，并生成转诊标识。
向下转诊。上级医院审批通过后，患者转入上级医院进行救治，上级医院通过转诊标识及电子病历浏览器调阅共享中心的患者电子病历，查阅诊断进行进一步治疗，并更新完善电子病历信息，并将更新后的电子病历上传至电子病历共享中心， 病情平稳后转回基层医疗机构。基层医疗机构通过转诊标识及电子病历浏览器调阅共享中心的上级医院上传的患者电子病历，查看患者病情与诊疗情况，并将后续康复治疗信息更新并上传到电子病历中心，上级医院通过电子病历共享中心调阅患者医疗信息，跟踪病人的病情，指导基层医疗机构进行后续诊治工作。
基于FHIR制定的本地化标准目标是按照 “基层首诊、双向转诊、急慢分治、上下联动” 的基本思想，为提供分级诊疗（双向转诊）的服务和监管的相关信息系统提供互联互通的接入标准，促进基本医疗服务、基本公共卫生服务、远程医疗、家庭医生签约、健康档案浏览等其它应用系统（模块）深度融合，协同工作，高效完成双向转诊，以实现区域内各机构之间的门诊、住院、检查检验、日间手术等转诊类型。
8.1.2.2 场景描述
由于社区卫生服务机构在设备和技术条件方面的限制，对一些无法确诊及危重的病人转移到上一级的医疗机构进行治疗。上一级医院对诊断明确、经过治疗病情稳定转入恢复期的病人，确认适宜者，将重新让患者返回所在辖区社区卫生机构进行继续治疗和康复。
通过调研四川省某区县的医共体中双向转诊的现状，整理出实际业务流程是通过《社区卫生服务双向转诊单》（以下简称“转诊单”）进行转诊流转。转诊单分存根栏与转诊栏，病人转出时需持转诊栏（分为“上转”和“下转”）就诊，存根栏由转出机构留存。实际详细业务流程如下：
1、社区卫生服务机构（下级机构）上转病人时填写《转诊单》（上转）。转诊单中需注明初步诊断，由经治医师签字并加盖公章。通过电话向医院分管社区的工作人员（上级机构）申请转诊。
2、转入医院同意后，由病人携带《转诊单》转诊栏至转入医院。危急重症患者转诊时，转出机构需派专人护送，并向转入机构接诊医生说明病人病情，同时提供相关的检查、治疗资料。
3、医院（上级机构）根据自身医院情况和患者病情，确认是否接诊。接诊后，需填写《双向转诊登记表》，并及时安排转诊病人至相应病区，如果不能接诊需填写原因。
4、医院（上级机构）在接收社区卫生服务中心（下级机构）的转诊病人后，在诊断治疗期间，上级机构的责任医生有义务接受转出机构社区医生的咨询，并将病人的治疗情况反馈社区医生。
5、当病人诊断明确、病情稳定进入康复期时，上级机构的责任医生填写《转诊单》（下转），说明诊疗过程、继续治疗的建议和注意事项，及时将病人转回社区卫生服务机构，并根据需要指导治疗和康复，必要时接受再次转诊。
8.1.3 主要流程
- 场景：基层医院向上级医院转诊
- 角色：该场景总共有3个角色，分别为患者、患者责任医生、上级医院医生，其中患者责任医生、上级医院医生为参与流程的角色，患者为该流程的主体角色。
- 流程：所有流程操作都由患者责任医生和上级医院医生两个角色完成。见图1。
基层医院患者的责任医生咨询患者转诊意向后，向上级医院发起转诊申请，包括录入患者基本信息，申请信息（转诊日期、转诊事项、转诊医院和医生）、患者转诊病历（包括患者的病情描述和治疗情况简介）。
上级医院接收到转诊申请后，查看信息，并且根据实际情况和患者病情做出转诊审核，审核通过后向申请者提交同意转诊同意通知，审核不通过直接返回原因和意见。
转诊同意后，根据转诊申请的约定日期和约定地点，患者到达转诊医院，经过上级医院确认后，办理入院，并且向申请人发出患者到诊通知。
基层医院医生收到患者到诊通知后，上传患者的所有完整病例信息。
上级医院医生接收患者所有病历信息，并且进行查阅。
8.1.4 实现路径
我们基于FHIR R4版本的基础规范，通过“注册术语与字典”、“裁剪与扩展资源”、“约定数据报文”、“定义活动与流程”、“发布实施指南（IG）”，技术实现六个步骤制定的用于双向转诊的FHIR本地化标准。
注册术语：通过提交编码系统与值域集注册术语与字典，以供下一步裁剪资源时约束其元素的值域。
裁剪与扩展资源：使用最贴近实际需求的FHIR基础资源进行约束与扩展，以供在数据报文中使用。
约定数据报文：约定用于消息交换的数据消息体（报文）。
定义活动与流程：定义消息交换的时机与先后关系。
发布实施指南(IG)：将上述步骤的产出物按照FHIR规范组织成本地化在线标准文档。（由于实施指南拟包含区域协同中的所有场景，故暂未单独发布“双向转诊场景”的实施指南。）
构建技术支撑服务：基于支持FHIR的集成交换服务平台，定制基于FHIR标准的转诊交换服务，包括已经完成的本地化的资源创建、查询等标准服务，支撑复杂的转诊流程中需要的各种应用场景服务。
8.1.4.1 支持FHIR标准的交换服务平台
我们基于现有的科研成果：适用于数字化医院和区域医疗信息系统的多标准集成网关（医易通），通过插件扩展实现FHIR标准支持。医易通是在四川省科技厅、电子科技大学和相关医院共同协作和联合基础上，由省卫生健康信息中心、四川省卫生信息标委会组织相关技术厂商、志愿者在吸收开源成果的基础上（主要包括MirthConnect） 开源协同本地化研发的一个多标准兼容医疗卫生信息系统集成交换引擎；它可以是一个松耦合、可编程的互联互通软总线（应该是最早集成了容器的交换引擎——服务网关）；也可以是一个构建微服务+SOA架构的卫生信息平台的交换中间件。 使用医易通，可以快速建立一个标准化的、互联互通的医疗卫生信息集成平台和系统，快速集成现有的信息系统，高效、安全和可靠地实现系统间的互联互通。
基于医易通的FHIR标准支持扩展包括FHIR数据类型、FHIR服务监听器和发送者、FHIR标准转化可视化助手等子模块。通过扩展支持，用户可以快速可视化、交互式、模板化地构建支持多个FHIR标准版本的标准的FHIR服务和访问标准的FHIR服务，包括构建标准的FHIR应用服务器、快速的FHIR服务访问发送器定制、可复用的代码模板可视化定制助手等。
图8.1.4.1-1 基于医易通实现的FHIR标准监听器
图8.1.4.1-2 基于医易通实现的FHIR标准服务请求发送者（调用者）定制
图8.1.4.1-3 基于医易通实现的FHIR标准服务首页
图8.1.4.1-4 基于医易通实现的FHIR标准服务
我们利用支持Fhir等标准的医易通集成交换系统，构建跨区域、跨机构的多级多标准的HIE服务节点，构建一个统一标准的健康信息交换（HIE）和应用服务网络，支撑区域协同如双向转诊等应用场景需求。
图8.1.4.1-5 基于FHIR标准服务节点构建互联互通的卫生健康服务网络
8.1.4.2 编码系统与值域集
行业术语字典是最基础标准，我们一方面利用四川省卫生信息学会标委会的科研课题《基于FHIR标准实现医疗卫生术语和管理》收集整理的FHIR编码系统（自2011年起国家卫生健康委员会发布的包括《WS 363-2011 卫生信息元数据目录》和《WS 364-2011 卫生信息数据元值域代码》在内的相关标准所对应的CodeSystem），并基于HAPI FHIR建设实现了规范化的统一术服务。另一方面，添加了双向转诊场景中可能需要的本地值域集。所有相关术语资源管理及服务由四川省全民健康信息平台的基础资源管理及服务系统支撑，均发布到下列地址中：
https://fhir.scwjxx.cn/Sichuan/fhir/CodeSystem/（同时在基础资源管理服务平台：http://fw.scwjxx.cn:10106/brs/fhir/r4/cs/ 提供）
https://fhir.scwjxx.cn/Sichuan/fhir/ValueSet/
在后续的资源裁剪定义中主要使用的编码系统与值域集见表1。
表1
| 定义的术语 | 相关资源使用的节点 | 来源 |
|---|---|---|
| 参与者角色 | AppointmentResponse.participantType Appointment.participant | 自定义 |
| 事件类型 | Task.businessStatus MessageHeader.eventCoding | 自定义 |
| 服务类型 | Appointment.serviceCategory | 自定义 |
| 服务项目分类 | Appointment.serviceType | 自定义 |
| 文档类型 | DocumentReference.type | 自定义 |
| 文档密级 | DocumentReference.securityLabel | 自定义 |
| 任务类型 | Task.code | HL7原生 |
| 文档引用状态 | DocumentReference.status.extension[resource-status] | HL7原生 |
| 预约状态 | Appointment.status.extension[resource-status] | HL7原生 |
| 证件类型 | Patient.identifier.type | WS 364-2011 |
| 生理性别 | Patient.gender.extension[sexual-distinction-of-human] | GB/T2261.1-2003 |
| 联系人关系代码 | Patient.contact.relationship | GB/T-4761-2008 |
| 婚姻代码 | Patient.maritalStatus | GB/T 2261.2 |
| 民族代码 | Patient.extension[ChineseEthnicity] | GB 3304-91 |
| 文档类别 | DocumentReference.category | WS365-2011 |
8.1.4.3 资源的裁剪与扩展
- 资源的裁剪
为了实现双向转诊的具体流程中交互数据的标准化，我们对一系列的FHIR资源进行了进一步的裁剪，并将裁剪定义发布到 {fhir_url}/StructureDefinion/。
主要使用到相关资源见表2。在后续的实际使用中，可将这些资源分为三大类。一是解释说明类的裁剪，包括Task资源和List资源，它们本质上是使用的FHIR顶级规范中的原生资源类型，并未对进行其实质上的改变，对其裁剪的内容仅仅是添加了具体使用的相关描述。二是基础类的资源，包括医护人员（Practitioner）、医院（Hospital）、部门（Department）、病床（HospitalBed）等。
表2
| 病历提交任务（Task） | Task | 解释说明内部节点 |
| 病历集合（List） | List | |
| 医护人员（Practitioner） | Practitioner | 以引用方式，仅截取URL末尾ID用于交互 |
| 医院（Hospital） | Organization | |
| 部门（Department） | Organization | |
| 病床（HospitalBed） | Location | |
| 转诊预约申请（hospital-referral） | Appointment | 在不同的活动事件中放入对应的资源捆束（Bundle）中用于数据报文的交换 |
| 转诊预约应答（hospital-referral-response） | AppointmentResponse | |
| 患者到诊应答（patient-arrive-response） | AppointmentResponse | |
| 病历文档引用（medical-record-documentation） | DocumentReference | |
| 患者（Patient） | Patient |
- 扩展元素
在信息系统的交互中，对预约的状态进行应答需要一个应答预约状态字段进行标识，故我们定义一个扩展元素“应答预约状态”，用于描述预约参与人的应约状态，包括同意、拒绝、未知、未响应等。以下裁剪的资源都对其进行了引用：转诊预约应答, 转诊预约申请, 患者到诊应答，详见表3。
表3 |扩展名称| 使用资源| |:----|:----| |生理性别（sexual-distinction-of-human）| Patient| |行政区划代码（AdministrativeDivision）| Patient| |民族（ChineseEthnicity）| Patient| |应答状态(participation-status)| DocumentReference Appointment|
8.1.4.4 消息交换数据报文结构
从业务需求分析中不难看出《转诊单》在整个双向转诊的流程中承载着业务交换的核心数据。我们使用Bundle（资源捆束）来组装消息体（报文）数据。如果把Bundle看作是单个患者的“转诊单文件夹”，那么文件夹中存放了“消息头资源”、“活动实例资源”和“业务资源”三类文件。
我们在整个医共体的信息系统架构是拟采用基于集成平台的消息中间件作为数据传输的媒介，所以我们选择了FHIR消息交换框架（Messaging）作为数据传输标准，它支持大多数消息组件、ESB等消息引擎，支持异步消息和消息应答机制。根据FHIR规范，我们约定这些文件的具体存放位置遵循了以下规则：
1、为了声明数据传输使用的Bundle资源是用于消息机制的，按照FHIR规范的要求，资源捆束中的“Bundle.type”元素固定为“message”。
2、按照FHIR中使用Bundle作为消息报文的要求，Bundle内的第一个条目(entry)中的资源必须是MessageHeader（消息头），用于说明消息的发送者、接收者、请求或响应等交互信息，并对资源捆束内所引用的相关资源进行概要式描述。
3、为了明确消息体是用于流程中哪一个活动事件（步骤）中的，我们约定资源捆束内的第二个条目中的资源必须是描述关于业务流程活动步骤的“活动实例资源”。 再通过对“活动实例资源”中的元素进行引用的方式来关联具体的业务资源。
4、资源捆束内的其它条目用于包含相应业务流程活动步骤中所需的其它相关业务资源。
“转诊单文件夹”以资源捆束的形式传输，其各条目中包含资源的相互关系示意图见“消息交换数据报文结构图”，这就是我们用于数据交换的消息体（报文）框架结构。
对于电子化之后的转诊单具体的数据格式标准，我们再通过消息定义（MessageDefinition）对不同业务活动需要交互的具体数据内容进一步定义。也就是说在不同业务活动的数据交换时，资源捆束中第二个条目中的资源类型（裁剪后的资源）在不同的业务活动（步骤）中是不同的。在双向转诊的场景中，我们使用消息定义资源对每个活动数据交换的消息体结构分别进行定义，包括“转诊预约申请”、“转诊预约应答”、“患者到诊应答”、“上传完整病”四个消息定义：
一、转诊预约申请的消息定义（HospitalReferral）： 在转出医疗机构向转入医疗机构发起转诊预约申请时使用的消息体结构的定义。该消息要求作出消息应答：
1.转入机构收到转诊申请后，根据自身情况和患者病情，审核是否通过转诊，审批通过后，作出应答。
2.患者到达转入机构，办理手续后，发起患者到诊应答。
二、转诊预约应答的消息定义（HospitalReferralRespose）： 在转入医疗机构收到转出医疗机构发起的转诊申请后，回复转出机构是否审批通过时使用的消息体结构的定义。
三、患者到诊应答的消息定义（patient-arrive-response）： 当转诊患者到达转入医疗机构后，转入医疗机构向转出医疗机构发送的消息体结构的定义。该消息要求作出消息应答：上传完整病历。
四、上传完整病的消息定义（medical-records-submitted）： 在转出医疗机构收到患者到诊应答消息后，上传完整患者完整病历时使用的消息体结构的定义。
8.1.4.5 活动与流程
定义好了数据交互的消息体（报文）格式的标准后，如何在各个不同的系统交换转诊的数据、何时交换是各个服务系统需要统一的核心问题。为了让电子化的转诊单在正确的时间将正确的内容传递给正确的信息系统，我们使用FHIR中活动定义资源（ActivityDefinition）来描述双向转诊流程中可能会发生数据交换的活动事件，并使用计划定义资源（PlanDefinition）按流程串联各项活动，使每个活动成为整个流程的一个有序的步骤。
活动定义：通过使用ActivityDefinition，可以定义在业务流程中每一个活动步骤，描述其在流程中的作用。
计划定义：通过使用PlanDefinition，可以对活动定义资源进行组装，并描述活动之间的先后关系，触发条件等信息，该资源可描述一个完整的业务流程。
根据实际业务需求，我们定义了“预约申请”、“预约应答”、“到诊应答”、“上传病历”四个活动， 形成了四个ActivityDefinition资源的实例，由“转诊预约申请”、“转诊预约应答”、“患者到诊应答”、“上传完整病”四个消息定义（MessageDefinition）引用关联，使之一一对应。
通过消息定义与活动定义之间的关联，使标准明确了当某一个活动事件发生时使用哪一个消息定义中的消息体（报文）格式。但是，标准中并没有明确这些活动事件之间的关系，即，为双向转诊提供服务的各个信息系统并不知道应该先做什么活动再做什么活动，或者做完什么活动后才能做什么活动。因此，我们使用计划定义资源（PlanDefinition）将之前定义的四个活动资源串联在一起，形成双向转诊的数据交互流程。具体做法是通过其Action元素将以上四个活动按步骤组装起来。转诊预约申请活动为该流程的第一步，转诊申请发起后，根据转诊预约应答来确定后续步骤，如果为不同意，结束流程，如果为同意，等待患者到诊应答，患者到诊应答结束后，上传完整病历信息。由于每个Action代表了一个步骤，这样参与服务流程的信息系统则可以通过此PlanDefinition的资源实例实现流程自动化。
8.1.5 应用效果与不足
以FHIR R4版本规范为基础，我们统一了成都市某区的医共体的双向转诊数据交互标准，以区域慢病管理中心通过集成平台的推送转诊消息的方式进行交互。
目前系统之间交互平稳，区域慢病管理中心与医共体的区第一人民医院发生109次数据交互、区第二人民医院3次数据交互、区中医院634次数据交互，总计461次数据交互。
由于区域医共体成立了慢病管理中心，转诊流程在慢病管理中心中完成，而不需要在系统之间进行复杂的转诊申请/审批流程。从实际业务出发，目前简化了流程，但关于流程相关的标准还没及时更新。
由于历史原因，主数据相关的标准虽已建立，但没有实际运用起来。实际的运行方式是：医共体内三家牵头医院的HIS厂商按ID统一了基础类资源（医护人员、医院、部门、病区）的实例，所以，为了减少交互量，在实际交互的资源捆束中，没有传输具体的基础类资源，而是直接通过获取活动资源中对应业务资源所引用的URL，然后截取其末尾ID的方式，最后在各系统在自己内部查询基础资源。
8.1.6 小结及展望
通过3年多的努力，我们在实践中检验FHIR的可行性，将新的技术和架构应用到国内业务协同标准中，使标准与实际业务更加贴合，实现了基于此标准下的医共体及区域的医疗健康信息及数据在“双向转诊”场景下的共享交互。通过开放标准统一的业务能力，实现应用的无差异化集成， 实现基于医疗健康数据的数据互联共享和业务互通协同,构建基于FHIR标准的HIE应用服务网络。为FHIR标准在我国医疗信息化互联互通的中应用提供了参考。
但是，我们在实践中也发现了在实际执行层面的一些问题。目前存的问题主要有两个方面，一是跨机构主数据的统一问题，目前通过上述ID的方式实现跨机构主数据交互虽然能作为过渡时期的使用，但却不能为更多系统（如互联网app）提供主数据资源的服务，极大地局限了区域健康应用的场景，故我们计划通过四川省基础资源管理平台建立主数据资源服务器，并统一以FHIR资源的形式对外提供主数据服务；二是流程变化后标准的适时跟进问题，这是由于流程需求变化快，并要求各软件厂商及时修改接口，这导致了流程标准发布滞后。为解决此问题，一方面我们计划完善标准管理平台，降低标准发布的难度，加快标准发布的速度，并使标准管理在版本、流程等方面进一步满足标准管理的需要，另一方面，我们鼓励接入标准的软件厂商开发标准自适应接口程序，目标是让程序订阅标准平台动态发布的FHIR标准定义文档（profile）、活动定义资源（ActivityDefinition）和计划定义资源（PlanDefinition），以自适应流程的变化。
下一步我们将以更加开放协作的精神，进一步完善关于跨机构区域协同下各类场景的FHIR资源本地化标准，并形成完整的实施指南（IG），同时结合全民健康信息平台建设等项目推动跨地区、跨机构的卫生健康信息互联互通和共享。
为了对一些新特性的支持，在FHIR版本方面，基于开源项目HAPI-FHIR本身的同步升级，我们将同步升级支持R5等后续版本。期待更多的同仁参与，希望得到各方的帮助与支持。
（撰写人：林晓东 沈明辉 黄路非 徐驰 李宁 黄朝彬 雷德英，四川省卫生健康信息中心，成都市第三人民医院，新都区卫健局，新都区人民医院）