刘晶炜讲述“我的医疗云心路历程”(2)

如果说云计算的商业模式顺应了基层医疗机构信息化发展的潮流，那么与之相适应的关键技术是什么？要回答这个问题，首先我们需要分析在医疗实践云计算的挑战。

中国的医疗体系目前正处在关键的转型期，虽然国家有统一的改革方向，但各地区在落实各项改革措施方面有很大的地方特色，从卫生局到各级医疗机构，内外的业务流程和管理模式都在一个摸索创新的过程中，存在相当程度的动态变化需求。如何让云平台所提供的相对标准的服务适应不同地区用户可能存在的差异性需求将是一个巨大的技术挑战。这样的差异性将体现在系统的外部接口及系统的内部流程及管理模式的方方面面。归根到底，云计算要求应用的软件化程度很高，灵敏性和适应性要很强。传统以工程项目实施为导向，通过大量实施人员在现场修补应用的模式将不能适应云计算的要求。

要解决上述问题，我们必须从应用系统的架构入手，分析可能的解决方法。首先需要建立的是应用平台的观念。

在过去40年中业务应用的敏捷度和适应性的发展大致经历了以下几个阶段，早期将数据访问管理从业务应用中分离，使数据的访问与业务应用代码相对独立，从而产生了数据库技术。然后发展到业务应用的参数化，将局部可变的业务内容定位为可调整的参数，实现应用的参数可配置，套装软件在这一时期应运而生，一定程度上缓解了业务灵活性的压力。随着业务灵活性要求的进一步提高，仅仅参数可配置也不能很好满足要求，又进一步抽象出业务流程的概念，产生了流程可配置的要求，从而导致业务流程引擎技术的出现。当业务的复杂性进一步发展，应用中的业务规则成为影响应用适应性的关键挑战时，业务规则的管理也逐渐从应用中独立出来，力求实现不同用户的业务规则动态可配置，从而导致业务规则引擎技术的出现。以下是一个应用演进发展的概要总结。在过去的应用演进过程中，如何平衡平台化的成本与其所提供应用敏捷度及适应性的价值，一直是众多应用提供商面临的矛盾选择。在云计算的商业模式下，每个用户可以拥有自己的数据，自己的业务流程和业务规则，但不必自己独立拥有数据库，流程引擎，规程引擎等中间件平台，而是使它们成为公共的设施。可实现平台化的部分在大多数用户间进行共享，而在配置后的个性化部分由不同的用户独享，从而达到成本与效益的最大化。

医疗云应用的演进

今天大多数的医疗软件采用的是简单的应用架构，由于大多数是以项目的模式进行部署实施，而每个项目的经费有限，所以几乎没有引入能提供应用灵活度的高端中间件技术。业务流程，业务管理报表及业务规则都是通过手工编程的方式进行实现。一旦用户的需求发生变化或不同地区用户的需求有较大的差异，应用软件就难以自动适应。在云的商业模式下，我们可考虑将应用软件中大多数可变的部分(业务流程，业务管理报表及业务规则等) 平台化，引入流程引擎，报表平台，业务规则引擎等高端中间件技术，通过多租户的模式，使这些高端的中间件能够在多个用户间进行可靠而又隔离的共享，降低每个用户使用高端中间件的成本。同时使用户可配置自己的流程，管理指标及业务规则，尽量较少代码的修改。不同用户的最佳实践经验可以流程库，指标库和规则库的形式沉淀下来，便于经验的分享。采用这种模式，将可大大提高医疗行业应用的敏捷度和适应性。

医疗行业应用的整合

如果我们从行业架构的角度来思考云计算模式对技术应用的影响，则更多地需要思考医疗领域所面临的另一个巨大挑战：医疗行业应用的整合。新医改要求各级医疗机构间进行深度的协作，实现双向转诊等多种跨机构业务的协同。这就涉及到不同医疗机构间应用的整合与互操作。从单个业务功能的角度看，任何具体的业务功能都是可实现的，关键的是如何实现才能够有业务的扩展性和灵活的适应性。点对点的集成实现比较简单，但架构可扩展性很差，业务变化的适应性也很低。随着整合集成深度的提升，逐步发展为基于总线架构的应用互操作，关注消息及接口的标准。当应用间相互协作的需求越来越多，各应用间需要共同访问的数据日益增多，支撑的业务流程日益紧密时，将各应用间需在业务运作层面共享的数据独立出来管理，成为开放的服务就是必然的趋势。这也将系统间的整合和互操作推到主数据管理的阶段，同时反向影响原有业务系统的深层次改造。