9.2 全新的架构

---

医疗健康行业的数据来源越来越多、越来越分散：除了临床数据，还有患者院后数据、医保数据、基因测试数据、医疗物联网等，我们正面对着铺天盖地的数据洪流，不仅要能让这些数据互联互通，更要挖掘这些数据的价值。

FHIR标准是作为一个互操作能力基础平台设计的，也就是它的核心目标是提供好的、标准化的建筑材料，设计师用它来构建医疗健康的生态，就像乐高积木一样。因此，FHIR为如何应用它赋予了无限的想象力，它不仅解决HIT的现实业务需求，更有机会重塑HIT的架构。

FHIR标准开放、技术中立，它让FHIR开放生态不仅给传统医疗信息化厂商带来了新的机遇，也给行业外厂商一个进入医疗信息化行业的绝佳路径，例如基因工程、机器学习、互联网，它们以前缺乏接触医疗健康数据的渠道，如今我们已经看到众多的巨头开始基于FHIR开放生态构建自己的医疗信息化解决方案：苹果健康使用FHIR API链接到Epic的医院用户并向患者提供健康信息服务、亚马逊和谷歌等都提供云端的基于FHIR的医疗API和资源仓库解决方案、还有数据库巨头利用自己的技术优势开发了FHIR资源高效查询的方案。

FHIR或许会带给医疗健康信息化产业像TCP/IP带来的互联网那样的飞跃。

9.2.1 标准数据联邦

在FHIR目前被主要关注的4个互操作范式之外，另一个范式- FHIR存储 – 并未被广泛提及。FHIR存储的载体是FHIR资源仓库。

当前的医疗信息化建设中，数据通常都是作为业务的私有信息保存和处理的。造成我们的核心业务系统HIS、EMR一旦被更换，其大量的临床数据将随老业务系统下线而下线 – 原因是每个厂商对于业务数据的描述都不一样，很难在系统切换时做数据的转换和迁移。

而如火如荼的临床数据中心建设并没有解决这个问题，原因是没有一个数据中心是“标准”的，只是多建设了一个数据孤岛。这些封闭的数据孤岛和之前的孤岛没有什么本质差异，依然不具有开放性，只能使用建设厂商所提供的有限应用、应对我们建设前多设定的那些目标，很难支撑我们持续创新。而且数据同步、多级数据中心建设等更带来了数据时效差和建设维护成本高的问题。

FHIR资源仓库提供了一个新的、标准的“数据中心”架构，其兼具标准性和弹性的数据模型、完善的API和丰富的生态。同时，它并不限制任何底层的存储引擎 – 你可以用关系型数据库、面向对象数据库、文档数据库或任何其它数据平台技术实现。

同时，FHIR资源仓库是一个去中心化的架构：FHIR资源可以通过URL相互引用，并不需要物理保存在一起，从而形成一个联邦数据中心。这给数据编织在医疗行业的应用提供了强大的基础，可以将多个FHIR资源仓库组织在一起，提供统一的数据治理和通过统一的服务端口访问。例如医疗集团内的每家医疗机构都有自己的FHIR资源仓库，无需建设集团集中的数据中心，但集团FHIR应用完全畅行无阻。

谁可以扮演FHIR资源仓库角色，可能首先想到的是临床数据中心。但电子病历、电子健康档案和HIS系统都可以是绝佳的FHIR资源仓库，这让它们从一个业务系统成为平台 - 成为SMART on FHIR应用、CDS Hooks决策支持的运行平台和更多未来FHIR生态的支撑平台，并利用这些生态反馈回和增强业务！我们已经看到Epic等厂商开放了在其电子健康档案上的SMART on FHIR应用的支持，利用生态提高辅助决策能力。

数据在FHIR资源仓库里不仅被引用、查询和更新，还需要高效的检索。例如查询FHIR资源仓库中满足特定临床和健康条件的患者列表。FHIR的对象化资源模型和树形表达结构并不适合高效的分析检索，而目前FHIR也还没有这方便的标准发布，也没有项目或案例证明了大规模的FHIR资源检索的性能。

已经有很多厂商开始参与FHIR资源仓库查询检索能力的设计，并已经有一些成果，例如InterSystems和Google都提出了基于SQL的FHIR资源仓库高效查询的方案。虽然这些方案还未形成统一的标准，但为FHIR资源仓库的应用前景带来了无限的可能。

另外，FHIR在大规模部署和大规模业务压力整体性能如何？美国ONC FHIR At Scale Taskforce (FAST) 工作组的目标就是研究FHIR的大规模应用的性能，相信这类工作组很快会总结出最佳实践。

9.2.2 软件架构

市场上有太多的技术体系和应用开发架构，C/S、三层架构、面向服务架构… 以三层架构为例，展现层可能是网页或Java/.net客户端、应用层可能是java、.net、Python，数据层可能是SQL、NoSQL、NewSQL。但大多建立的是单体架构应用 – 为特定业务目标从底层数据模型到业务逻辑再到用户界面的一体化设计，也就是孤岛型应用。

单体架构应用最大问题是没有哪一部分是以复用为主要目的设计和建设的，而且和其开发技术体系绑定：

• 应用只能运行在其开发的技术体系下，无法跨技术体系复用
• 由于数据模型、术语、行业服务和API标准的缺失及应用范围不足，即便采用相同技术体系的应用和功能也没法为别的用户使用。以患者管理为例，每个业务系统都有患者管理，但没有一个系统将患者管理功能分享给别的业务系统使用，我们不得不在不同的业务系统间集成和同步患者信息
• 而应用一旦不满足需求了，新应用要重新建设所有三层，任何一层都没法复用、原来的数据也随之下线，造成宝贵的数据资产损失

我们的医疗信息化建设的现状就是在不断重复建设不能复用和分享的单体架构应用 - 架构很重、开发周期长、开发成本很高、后期集成难度大、数据被孤岛化、应用效果不佳。

在医疗健康行业日益激烈的竞争和数字化转型中，原来独立的业务逐步互联互通、更多的新业务不断涌现，例如临床由院内扩展到互联网医院、医联体/医共体打破了之前独立运营的医院边界、三医联动更是打破了医疗、医药、医保的行业边界。在此大背景下，单体应用的建设更加难以为继，我们需要新的软件架构帮助整合数字资产和实现快速的业务创新 – 无论是业务范围还是业务规模。

微服务架构识别和定义数字资产，将业务解耦并重新封装为可以复用的服务。当业务发生变化或引入新业务时，无需像单体架构应用那样从头开发，可以通过将服务重新组合来快速应对，就像搭积木那样。通过去中心化、对技术实现体系透明、更灵活的部署模式，它让业务进化更加便捷。因此所有行业，包括医疗健康行业都开始拥抱微服务架构。

但微服务架构并不能直接帮助到任何行业，一个封装了核心业务能力、建设具有弹性的服务和业务流程能力的、具有行业通用性和复用性的微服务架构才是真正的数字资产。也就是说我们需要的不是一个微服务IT架构，而是一个微服务行业标准架构。这需要行业专家和IT专家的经验、携手努力和不断优化。

FHIR的出现恰逢其时，它是建立在过时或因复杂性和灵活性而失败的行业互操作标准之上，由行业专家、IT专家和标准化组织共同设计的行业标准，封装了：

• 兼具标准化和扩展性的行业本体模型 – FHIR资源模型
• 具有弹性的资源操作API – 既有细颗粒度的增删改读操作（CRUD），也有查询（Query）和更复杂的操作（Operation）
• 行业用例和实施指南

并且FHIR日益蓬勃的生态让其迅速具有了可用性和适用性。FHIR是目前看到的医疗健康行业标准微服务架构的最佳载体，它或将颠覆医疗健康信息化的软件架构。

如何基于FHIR建设微服务架构？ SMART on FHIR帮我们提供了最佳实践：利用FHIR资源模型作为统一标准的数据模型、FHIR资源仓库作为统一标准的逻辑数据持久化层、FHIR服务器（API）作为统一标准的访问层和统一标准的应用认证与授权机制，而不限制任何技术栈。

这个架构下，应用的开发只需要关注在自身要实现的业务逻辑、知识和界面展现上，通过统一的OAuth认证获得对后台FHIR服务器和资源仓库特定资源的权限即可。它无需建设数据层 – 使用已经建设好的FHIR资源仓库，无需设计访问层 – 使用FHIR API。而数据层-FHIR资源仓库、访问层-FHIR服务器可以由任何厂商、基于任何技术栈单独实现，它们都可以被复用，彻底解决了“数据随应用共存亡”问题。因此SMART on FHIR是非常轻量化、快速开发、可以复用的，而且它既可以单独运行、也可以嵌入电子病历等其它应用中。

现在已经有大量的SMART on FHIR应用可供选择，我们可以像手机App一样，到应用市场去下载安装SMART on FHIR应用即可；不喜欢这个应用了？卸载并安装另一家的应用。

还有不少开源项目在优化这个架构，例如FHIRcast是一种在医疗应用中实时同步和切换上下文（如患者）的新方式。FHIRcast可以通知SMART应用，EHR中的背景（即病人）已经改变，SMART应用中也应该改变。FHIRcast还支持跨设备的场景和上下文共享，让业务随时在线。

当前SMART on FHIR应用主要是决策支持类应用，但SMART on FHIR应用、CDS Hooks决策支持等基于FHIR的行业微服务架构实践已经让我们看到了其强大的生命力，成为推动医疗健康数字化转型的支撑。我们有望看到其更大范围的应用，和基于FHIR生态未来产生更多的、更灵活的应用架构。

（撰写人： Intersystems、北京嘉和美康信息技术有限公司）