关键字
集成平台、柔性化、多面化、场景覆盖度、自我进化力
导读
在集成平台能力持续进化的进程中，医院的“多面化”需求通过更柔性的集成架构得以实现，使得集成平台在医疗场景中呈现“百花齐放、各有特色”的应用新局面。
集成平台在医疗行业的建设逐步深入，新的问题也随之而来。
- 有的医院发现，现有集成平台具备的数据交换技术（如集成引擎、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的“柔性化”集成技术都做了什么工作？
项目管理。 “目前我们用集成平台主要做三类事情： 项目管理、对外交互，以及数据上报。 在项目管理中，我们在平台上监控各个项目的交互情况和交互量，这在技术上是很有意义的一件事情。 ”浙江省台州医院信息中心集成平台项目负责人刘祉呈如是说。
数据质控。 “集成平台在质量控制中能发挥很大的作用。 ”郑州人民医院信息化建设和研发部主任兼数据中心主任张司露认为，不能把集成平台局限在“数据的搬运工”这一角色上。 在建设集成平台时，郑州人民医院首抓的核心工作是“注入灵魂”，也即建立“主数据管理系统”，并交由各业务管理部门维护，信息中心的作用是提供好用的工具，帮助各部门通过集成平台控制数据的生产源头，并进行事中的闭环监控与事后分析，实现数据质控效果。
内控合规。 据中信泰富医疗信息化负责人介绍，由于中信泰富的央企背景，需要构建“强内控、防风险、促合规”三位一体的内部控制体系，他最为看重的集成平台功能是基于大规模的数据集成，让集团总部了解各医院的经营情况并进行战略调整，同时基于平台打通经营管理全过程，形成管理闭环，从而更好地满足内控要求。
类似的应用实践还有许多。 在集成平台能力持续进化的进程中，医院的“多面化”需求通过更柔性的集成架构得以实现，使得集成平台在医疗场景中呈现“百花齐放、各有特色”的应用新局面。
Odin文章评论：