市场上有太多的技术体系和应用开发架构,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生态未来产生更多的、更灵活的应用架构。