医院集成平台超融合基础架构转型方案

近年来在电子病历应用水平评级要求以及医院在不同业务间实现协同等多种因素的推动下集成平台成为各大型医院信息化建设中重点的项目。

本文将围绕医院集成平台的资源需求以及其对 IT 基础架构的要求展开讨论并给出基于超融合架构的方案配置参考与传统架构的对比分析。

超融合方案：https://www.idcbest.com/2023/crh.asp

集成平台在医院信息化中承担的角色

随着医院信息化建设的不断完善医院逐步上线了 HIS、EMR、PACS、LIS 等多个业务系统。

由于这些业务系统由不同厂家开发各个系统拥有不同的操作系统、数据库进而导致不同业务系统之间需求调用复杂、接口数量多且无统一标准、数据交互效率低下、维护困难等问题。

集成平台的重要性在于其不仅能够在各个系统之间实现统一集成和交互同时为数据集成提供了可能。

通过将各个系统产生的数据集中存储并重新组织形成医院的数据仓库集成平台为下一步数据分析创造条件即充分挖掘数据价值进而形成一系列数字化应用支撑智能化决策帮助医院实现真正数字化转型。可以说集成平台是医院数字化转型的重要基础。

在部署集成平台时医院需要清晰了解集成平台的架构从平台的实际需求出发并结合医院资源池建设的整体规划为集成平台选择合适的基础架构。

集成平台架构简介

医院集成平台的实现方案有很多种早期以接口调用集成方案为主但这种方案集成效率较低后期逐渐转向企业服务总线ESB为主要框架。

ESB 优势

• 可根据客户的请求和事件提供路由数据转换、翻译等服务。
• 具有快速、并行的消息处理能力。

ESB 劣势

• 无法保证消息或服务请求的顺序而医院业务之间调用大多有严格处理顺序要求。
• 不支持国际医疗标准不利于医疗数据上报、医疗机构之间的数据交互。

ESB 引入消息队列软件处理服务请求顺序的问题、改造 ESB 支持医疗标准协议等方案虽然在一定程度上实现了 ESB 的优化但存在方案极其复杂开发难度过大成本过高等问题可见在集成平台建设中单凭 ESB 软件是无法完全满足业务的需求。

经过多年的发展与试错医院集成平台逐步形成了以 ESB企业服务总线、IE集成引擎、ETL 工具三种技术组合而成的搭建方案。

如上图所示集成平台的集成工作主要包括两个部分：应用集成和数据集成。

应用集成

应用集成主要实现各个业务系统之间的请求和调用由 ESB 和 IE集成引擎两部分组成；其中 ESB 负责同步数据处理操作IE 集成引擎负责异步数据处理。

• ESB 充分发挥并行处理优势实时、高效地处理系统之间的请求。
• IE 集成引擎支持以 HL7、CDA 等国际医疗标准协议交互提供消息异步处理机制解决重视次序的服务调用需求。

国内集成平台常用的集成引擎方案如下表所示。可以看出国内的集成平台厂商大多采用国外成熟的 ESB 企业服务总线产品/集成引擎产品。

常见 ESB/集成引擎 产品的系统要求和数据库支持情况如下：

数据集成

数据集成主要任务是将医院各个系统所产生的数据集中清洗并以新的组织结构进行存储形成医院数据仓库以便后续对数据进行分析挖掘和利用。

ETL 工具

ETL 是 extract-transform-load 三个数据处理过程的缩写：

• 数据抽取Extract：连接各个业务系统数据库抽取数据库日志和事务数据。
• 数据转换Transform：抽取数据后对数据进行验证、清洗、根据规则执行转换。
• 数据加载Load：将处理好的数据加载到目标数据库。

理论上 ETL 工具可从生产业务系统的数据库直接抽取数据并转换数据但这种方式会对生产数据库带来较大压力直接影响业务系统响应速度。为了解决这个问题 ETL 过程会先将数据完封不动地抽取到中间数据库临时库数据转换、数据加载都会发生在临时库中以最大程度上降低对生产数据库的影响。

集成平台对基础架构带来的需求变化

集成平台的角色多资源需求量大

通常情况下建设集成平台大约涉及 40-80 个服务器角色其原因主要在于：

以 ESB 软件为例它包含应用和数据库两种角色；部分大型三甲医院甚至将集成平台接口服务器应用角色拆分成多台以避免过分集中带来的风险在这种情况下ESB 可能会涉及 4-10 个服务器角色。

ETL 相对更加复杂包含 ETL 工具服务器中间数据库服务器通常运行 mysql 数据库、目标库服务器等因此ETL 可能会涉及 6-12 个服务器角色。

同时集成平台生产环境的各个角色必需考虑冗余高可用设计而且需要有对应的开发和测试环境。

可靠性要求高

以往各个业务系统相对独立但引入集成平台后所有系统之间的调用都依赖集成平台；一旦发生宕机所有业务都有可能受到影响风险极大因此集成平台对于基础架构的可靠性要求非常高。

性能要求高

大型三甲医院集成平台平均每天需要处理 9000 万条消息要求峰值处理能力需达到 1000 TPS存储性能不足容易导致整个业务系统卡顿严重情况下甚至会宕机因此非常考验基础架构 IO 吞吐能力。

需求变化剧烈

以往医院其他业务上线后软件开发、调试工作量和频次较低；但集成平台以及数字化应用的引入则涉及大量、持续的开发、测试任务；传统基础架构的资源扩展动辄需要数月进行规划和部署无法满足平台的敏捷性要求。

为集成平台选择更合适的基础架构

传统架构部署问题凸显

采用物理服务器部署需要新购数十台甚至上百台服务器明显增加风险与压力。

• 服务器硬件采购成本压力大：80 台服务器采购成本需要数百万人民币同时硬件维保的费用也相应提高但每台服务器资源的实际利用率却非常低。
• 机房管理风险增大：很多医院机房空间非常有限新增大量的物理服务器可能会使得机房变得拥挤不堪制冷和 UPS 有可能无法满足需求进而为机房管理带来较大的风险。
• 集中式 SAN 存储扩展成本高：部分医院采用服务器虚拟化+集中式 SAN 存储的架构运行集成平台虽然可以解决物理服务器的一些问题但共享 SAN 存储的问题则愈发凸显。很多大型医院选择全闪 SAN 存储作为主存储并为了保证存储高可用配置了双活存储功能其使用成本超过 10万元/TB ；而集成平台对于存储资源需求较大完全依赖 SAN 存储则难以满足平台的持续扩展的需求。

超融合是更理想的基础架构

超融合是新型的“多合一”基础架构

超融合架构将服务虚拟化、服务器、存储多种设备和元素融为一体以软件为核心使用标准商用硬件替代昂贵的专用硬件解决了传统架构管理复杂、难以扩展等问题。

灵活可扩展的基础架构

超融合基础架构采用分布式技术资源扩展不受限于单台服务器的硬件配置可通过扩大服务器集群规模持续获得资源拓展和性能提升。

SmartX 超融合解决方案

方案架构

理论上超融合平台可承载集成平台所有角色但由于部分医院用户仍希望将核心系统的数据库部署传统架构如集成平台的 CDR 数据库为了满足用户的需求SmartX 提供两种架构综合部署的解决方案。

• 超融合软件基于 SmartX 分布式存储 ZBS并与大型医院客户熟悉的 VMware 虚拟化融合部署。
• 以两台物理服务器和 SAN 存储组建 Oracle RAC 数据库集群运行 CDR 数据库。
• SmartX 超融合平台运行集成平台其他所有角色包括 ESB、ETL、IE、中间库等角色。
• SmartX 超融合平台同时可承载多个核心业务系统数据库的备机Oracle DG 备库/MS SQL Server 备用库。

方案配置

超融合架构与传统架构实施对比

方案价值

优异的性价比打造集成平台基础架构

• 超融合架构极大提高部署密度只需不到传统方案 1/10 的物理服务器数量即可满足部署要求大幅减少机房空间浪费。
• SmartX Halo 一体机支持基于 NVMe 全闪超融合集群性能卓越单节点处理能力超过 10000+TPS 可满足大型三甲医院集成平台高峰消息处理能力要求。

全面提升平台可靠性

• 系统集群内提供数据副本冗余同时节点故障可自动迁移虚拟机到其他节点进行恢复提升了集成平台整体可用性水平。
• SMTX OS 支持双活集群、远程容灾全面满足电子病历5级容灾备份的RTO和RPO要求。

简单敏捷

• 方案架构简单无需维护复杂的存储硬件和存储网络。
• 平台扩展便利可按需投入持续扩展资源池。
• 大幅缩短业务交付时间提升业务敏捷性。

综上所述超融合架构承载集成平台相较传统架构具备高可靠、高性能、简单敏捷等多种优势将会成为医院集成平台基础架构选型的一个不可忽略的选项。

针对医疗行业信息化建设与 IT 转型SmartX《医疗行业超融合基础架构解决方案白皮书》围绕医院信息化建设国家政策要求、大中小型医院业务特点、以及其基于超融合基础架构的 IT 转型方案等多个维度进行了详尽阐述。

本文链接：https://www.idcbest.com/cloundnews/11008823.html