医院如何解决集成平台的“打补丁”难题

随着医院信息化建设不断深入，功能和需求越来越多，医院对集成平台的要求也越来越高，为了满足要求不得不采用“打补丁”的方式添加功能，改造接口等。 但是如果能更好地理解集成平台建设的不同阶段，提前做好准备，采用合适产品，则能很大程度上避免陷入“打补丁”的困局。 

医院集成平台的不同建设阶段 

阶段一： 满足院内的数据集成/业务集成等基本需求 

该阶段的大多数医院以院内需求或是互联互通测评作为契机，初步接触并开始使用集成平台。 在建设集成平台时,也以满足院内的数据集成/业务集成需求，升级点对点的系统架构为主，并结合互联互通测评要求，搭建起一个基本的集成框架。 

以门诊预约挂号业务场景的集成为例，其中包括了挂号、退号、信息注册、信息查询、注销等功能。 信息查询要求响应速度快，有同步处理要求，响应时间不能超过3秒。 对于查询的内容能够根据业务变更灵活调整； 而预约挂号业务对于响应要求不高，但是需要保证消息的传输以及传输时的顺序，因此在应用端的预约和取消预约通过异步进行处理，结果信息的接收可通过发短信或刷新实现查询。 

因此在这个场景中，查询类业务适合通过ESB实现，而预约挂号类业务适合通过集成引擎实现。 在处理一个外部入口的所有请求时，需要根据具体业务中数据的传输模式要求不断进行调整，满足集成的基本需求。 

阶段二： 从“润滑剂”到“主动脉”，针对集成需求实现便捷的自主开发，拓展集成平台功能边界 

该阶段医院对集成平台的使用已经有了一定的了解，在使用集成平台的过程中也有了自己的体会和想法。 医院会慢慢将主要系统迁移至集成平台上，业务系统与集成平台数据交互也越发紧密，消息吞吐量在百万量级，集成平台逐渐从“润滑剂”变为信息资源整合的“主动脉”。 

这个阶段医院也需要通过集成平台自主实现一些需求的开发和部署。 如果医院难以掌控集成平台，则不得不通过厂商添加功能或易用性模块这种“打补丁”的方式才能解决需求。 

以 “健康码”的开发为例，在传统接口模式下医院需要厂商进行协助，花费2-3天的时间进行“健康码”的开发工作。 而 在Odin引擎的助力下，某集团化三甲医院信息部门一位熟练的技术人员1小时内就自主完成了全部服务部署。 

同时，由于医院逐渐意识到了一体化对于医院信息化建设的重要性，各系统之间的边界也将越来越模糊，集成平台将不仅仅作为满足医院集成需求的工具，也会根据医院需求拓展出更多的功能。 

以API的管理为例，API网关服务应用，具有鉴权管理、流量控制、黑白名单、访问控制等API管理功能，能提升接口管理方面的用户体验，但也常常需要对集成平台进行二次开发等“打补丁”的手段才能实现该功能。 

阶段三： 支撑瞬时超高并发环境下的大规模集成建设 

5G的到来和医联体/医共体的建设加速了医疗信息互联互通的进程，更高速率、更低延时和更多设备的接入，以及部分系统和外网的直连意味着数据处理量存在瞬时激增的可能，这对于平台在短时间内的扩展能力提出了极高的要求，传统的集成引擎所具备的性能和稳定性由于难以支撑此类瞬时超高并发的环境而导致卡顿甚至宕机，则会导致“打补丁”现象不断发生。 

Odin明确的产品升级路线图破解医院集成平台不同阶段的“打补丁”难题 

Odin 针对医院不同的集成阶段，提供了从AlwaysOn企业版到集群版再到Odin NeXT云原生平台的三个产品解决方案，这条非常明确的升级路线图可以有效保护医院的基础投资，避免医院在集成平台建设中由于平台性能、稳定性、功能不如预期而陷入的“打补丁”困局。 

Odin引擎AlwaysOn企业版 

Odin引擎 AlwaysOn 企业版除了解决了国内用户对于联互通测评支持、产品容灾性、易用性等多个常见问题，满足院内的数据集成/业务集成等基本需求外，还额外具有强大的高可用功能和易用性，其中包括： 

• 产品内置的主备容灾环境，无需依托任何外部高可用技术，服务无感知切换（亚秒级别切换时间）； 
• 拖拽式、图形化的操作界面，做到了所见既所得，大大减少了操作人员的工作量； 
• 统一界面的多人协同开发，统一配置管理，统一监控管理，统一数据管理，医院在进行自主开发、日常运维时更加便捷易用。 

Odin引擎集群版 

当AlwaysOn企业版不能满足医院增长需求时，可平滑升级至集群版，无需 “打补丁”。 

Odin引擎集群版原生实现一体化集群架构（Controller+Worker），并非单机系统部署在多台虚拟机上形成的“集群”(其核心仍是单机架构)。 除支持业务集成和数据集成外，作为平台的核心中间件，Odin引擎集群版能助力医院集成平台实现“五个一体化”—— 数据集成技术一体化、界面一体化、组件一体化、功能一体化、管理一体化。 

• 数据集成交换技术一体化： 融合集成引擎、IE、ESB、MQ等多种技术 
• 界面一体化： 统一的开发、测试、管理、运维和监控界面 
• 组件一体化： 控制组件、运行组件、API网关、用户鉴权等融为一体 
• 功能一体化： DevOps、态势感知、服务熔断、事件驱动等功能 
• 管理一体化： 容器微服务、单点登录、流量控制、黑白名单、访问控制 

Odin引擎集群版还引入OpenApi，RAM等能力组件，具有统一运维监控、智能化部署、定向隔离负载计算、态势感知、熔断保护、跟踪埋点、DevOps发布机制等功能特点，为大型医疗卫生机构提供“功能完备、持续稳定、高能可靠”的大规模数据交换和业务集成能力。 

Odin NeXT云原生平台 

当集群 版不能满足医院增长需求时，可平滑升级至Odin NeXT云原生平台，仍然不需要 “ 打补丁 ” 。 

Odin NeXT云原生平台在具备集群版功能特点的基础上融入高并发、高可用的云原生技术架构，前瞻性地实现单场景微服务和基于Kubernetes的容器动态化分布式PaaS部署等特性，实现了最佳的系统高性能、高可用、高稳定； 具有高资源利用率，动态弹性扩展，随业务负载波动的资源适配和场景项目间隔离等特性，为超大规模云应用，实现APIs快速开发和接口化服务提供准开发平台和纯Web一体化运维工具。 

结语 

医院集成平台建设要有切实可行的长期发展路径，集成平台的核心中间件本身也要有成熟、前瞻性的升级路线图，为医院集成平台的建设规划提供可持续的技术支撑，帮助医院走出频繁“打补丁”的困局，为医院信息化的长期发展夯实“地基”。