医院信息集成平台 IT 基础架构需求分析与方案选型

内容导读

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

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

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

随着医院信息化建设的不断完善，医院逐步上线了 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 转型方案等多个维度进行了详尽阐述。