FHIR与微服务架构

原文在这里

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

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

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

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

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