用“柔性”应对“变化”：什么样的集成平台才具有“自我进化力”？

导读

在集成平台能力持续进化的进程中，医院的“多面化”需求通过更柔性的集成架构得以实现，使得集成平台在医疗场景中呈现“百花齐放、各有特色”的应用新局面。

集成平台在医疗行业的建设逐步深入，新的问题也随之而来。

• 有的医院发现，现有集成平台具备的数据交换技术（如集成引擎、ESB等）和功能比较单一，不能完全满足医院实际需求；
• 有的医院在进行平台选型时，遇到了各种新名词，如微服务架构、云原生、PaaS等，无所适从、难以抉择；
• 医院信息化建设“年年上台阶”，有的医院上线集成平台后心里也不踏实，担心平台缺乏前瞻性、短期内会被淘汰，投资打了“水漂”。

在这些困惑、犹豫、担忧的背后，实际隐藏的问题是：在医院数字化转型的行业背景中，在技术与应用的相互促进下，与几年前相比，无论是集成平台的自身能力，还是医院集成平台的应用场景已经发生了很大的变化。

技术与需求都并非一成不变。那么，什么样的医院集成平台才能具备“自我进化”的能力，更好地适应已发生和未来将发生的种种变化，从而帮助医院CIO们放下心中的疑虑与担忧？

Odin认为，这格外考验作为集成平台核心的集成中间件的能力。集成中间件必须具备“柔性化”的能力，不断实现功能架构的演进，从而更好地适应医院“多面化”的建设需求。

集成平台架构为何需要“柔性化”？

在医院数字化转型进程中，更加多样化、复杂化业务场景的出现，使得单纯技术导向型、能力“刚性”的传统集成平台渐显力不从心。“柔性化”成为新型集成技术架构演进的新趋势。

所谓“刚性”，是指以单一的集成技术解决某一类型的集成问题，让需求实现被动地去适应技术，能为用户发挥的作用和价值有限，也限制了医院信息化水平的提升。

比如，当下医院集成平台建设需要兼顾可用性、性能、效率、同步性、数据互操作等多方面问题，但受到IE（集成引擎）、ESB等数据交换技术自身特性的制约，传统的集成平台有些只能满足高可用和数据互操作需求（如基于IE技术实现的双活架构），有些只能满足性能和数据同步性需求（如基于ESB技术实现的多机多活架构），难以同时满足上述所有需求。

而“柔性”，则是指以集成场景和业务需求为导向，以业务价值输出为目标，通过多种集成技术的高效有机协作，从而实现全场景的覆盖。集成平台的柔性化能力不仅能很好地满足基础的互联互通需求，也能为不同场景下的数据利用打下扎实基础，成为支撑医院数字化转型的新“地基”。

在医院数字化转型进程中，技术实现的“柔性化”是非常重要的。比如，在保证院内以及跨机构协同时的数据互联互通方面，要实现这一点不难，但要做好做精，将数据互联互通从面上的数据标准融入实际业务场景却不容易。若是集成平台过于“刚性”，难以应对大量的复杂场景，导致数字化转型的“地基”不稳，后续在实现数据驱动业务、借助数据辅助决策的过程将举步维艰，这也是目前大部分医院数字化转型中的难点。

集成平台的“柔性化”架构，主要体现在以下几个方面：

首先，具备多种集成技术，功能可扩展。医疗场景越发复杂，即使是同一场景下，根据业务需求的不同，需要用到不同的集成技术或平台功能。因此，医院集成平台需要灵活运用多种集成技术，协同解决当前问题。同时还需具备可扩展的功能，以应对未来更加多元化的场景需求。

其次，以面向场景的微服务技术架构为核心。新版互联互通标准化成熟度测评方案在“3.1.2信息整合技术”条目的备注中提到：在总线技术基础上，可进一步探索基于微服务架构的环境搭建。

第三，平台负载和性能可延展，稳定高可用。集成平台的能力越强大，承载的业务类型越多，隐含条件之一就是负载、容灾的性能需要足够支撑,需要通过合理的功能和架构设计保证平台的高性能和高可用。

最后，产品具备平滑升级能力，伴随医院共同成长。想要实现投资复用，集成平台需要具备和医院共同成长的能力，从架构、管理、功能等多方面，根据医院成长不断进行升级调整，避免医院在集成平台建设中由于平台性能、稳定性、功能不如预期而陷入“打补丁”困局。

Odin认为，“柔性化”使得医院可以把更多的精力投入到业务目标的实现（以业务场景为导向），而无需过多考虑集成平台到底能做什么（被局限在技术实现手段上）。提高平台的设计规划能力和业务价值体现，降低底层技术实现的感知，是“柔性化”架构的重要目标。

那么，Odin是如何打造集成平台的“柔性化”能力？

功能上，Odin集成平台中间件具备IE、ESB、ETL、MQ、APIs等多种集成技术，并能合理依据业务场景进行灵活使用，还能根据医院的本土化需求预置功能；开放式、模块化的平台架构也能根据用户需求便捷地增加新功能、新工具，实现医疗业务全场景覆盖。

同时，Odin引擎集群版还内嵌智能熔断、自修复、定向隔离负载、精细化故障转移等技术，在出现某个项目对内存过度占用的情况时，能及时熔断并实现自修复，防止异常情况进一步扩散导致服务宕机，保证高可用。

架构上，Odin引擎集群版在产品设计之初，就根据医院集成平台的业务特点，原生实现了集群架构，而非单机系统部署在多台虚拟机上形成的“集群”（其核心仍是单机架构）。Odin引擎集群版分离了管理监控、生产服务、数据存储等功能，利用负载均衡构建集群体系，通过按需的横向扩展提升整体性能。

同时，Odin集成平台中间件以医院的场景化需求为核心，积极尝试各类功能与新技术、新架构的融合。比如，Odin引擎集群版借助容器技术和API网关，实现业务细粒度分割和独立的开发、部署，帮助外部系统构建微服务架构，达到业务级的微服务；而Odin云原生平台Odin NeXT更进一步，在设计时就将Odin的服务功能进行物理切割，实现了自身架构级的微服务。

医院的数字化转型是一个长期过程，针对医院不同阶段的实际需求，Odin提供从AO企业版到集群版再到Odin NeXT云原生平台的三个产品解决方案，平滑的升级能力可以为医院的长期建设规划持续提供技术支撑。

“柔性化”集成技术让医院集成平台应用实践百花齐放

从医院应用的角度来看，由于所处发展阶段不同、信息化建设基础不同，各家医院对于期望借助集成技术解决的场景需求也不尽相同，正呈现“多面化”的新特点。 

当作为“系统集成和互联互通应用”使用时，有的医院将其作为多院区同品质医疗、同质化管理的“数字基座”，借以支持跨院区、跨机构的业务协同，或是将需求量庞大的自助机业务、互联网医疗业务都纳入平台进行承载。例如，李惠利医院基于集成平台实现了跨系统、跨院区的互联互通，核心业务包括跨院区预约挂号、检查预约、会诊、预约住院、自助打印、治疗、转科、化验等深度协同服务，从而解决“两院融合”进程中的业务协同难点问题。

有的医院希望能将集成平台作为实现服务注册、订阅、发布、监管等面向服务的“业务中台”。例如，安徽某龙头三甲医院利用集成中间件打造财务中台，从不同系统集成财务运营相关数据，并与当地市局的财务平台进行对接，打通医院财政数据上报反馈、电子票据验证等财务服务的必要流程,加速推进了结算环节的无纸化与自动化。

更有医院希望能将集成平台作为跨系统的“低代码开发平台”。这类医院的信息部门通常具备较强的开发能力，日常工作中经常需要满足部分小型、微型信息化开发需求。在疫情期间，台州医院就利用集成平台的这种“低代码开发”能力，通过图形化拖拽式操作，结合丰富的数据处理组件，进行高效开发，实现了“健康码”应用1小时上线。

基于“多面化”的应用场景与需求，与集成平台中间件“柔性化”的能力支持，已经有越来越多的医院利用集成平台满足了多样化、差异化、个性化的信息化建设需求。

不妨看看走在行业前列的医院利用Odin的“柔性化”集成技术都做了什么工作？

项目管理。“目前我们用集成平台主要做三类事情：项目管理、对外交互，以及数据上报。在项目管理中，我们在平台上监控各个项目的交互情况和交互量，这在技术上是很有意义的一件事情。”浙江省台州医院信息中心集成平台项目负责人刘祉呈如是说。

数据质控。“集成平台在质量控制中能发挥很大的作用。”郑州人民医院信息化建设和研发部主任兼数据中心主任张司露认为，不能把集成平台局限在“数据的搬运工”这一角色上。在建设集成平台时，郑州人民医院首抓的核心工作是“注入灵魂”，也即建立“主数据管理系统”，并交由各业务管理部门维护，信息中心的作用是提供好用的工具，帮助各部门通过集成平台控制数据的生产源头，并进行事中的闭环监控与事后分析，实现数据质控效果。

内控合规。据中信泰富医疗信息化负责人介绍，由于中信泰富的央企背景，需要构建“强内控、防风险、促合规”三位一体的内部控制体系，他最为看重的集成平台功能是基于大规模的数据集成，让集团总部了解各医院的经营情况并进行战略调整，同时基于平台打通经营管理全过程，形成管理闭环，从而更好地满足内控要求。

类似的应用实践还有许多。在集成平台能力持续进化的进程中，医院的“多面化”需求通过更柔性的集成架构得以实现，使得集成平台在医疗场景中呈现“百花齐放、各有特色”的应用新局面。

近期热文

HIT专家网∣致力推进中国卫生信息化长按二维码可申请加入HIT专家网专业交流群

寻求“商务合作”，长按二维码可快速与我们取得联系

投稿：[e-mail]

商务合作：[phone]

本公众号原创文章，版权归HIT专家网和原作者所有。

未经许可，谢绝转载或以其他形式使用文章内容进行传播。