某三甲医院HIS系统升级改造项目实战分享【架构洞察力】.pdf

某三甲医院HIS系统升级改造项目实战分享【架构洞察力】

【摘要】在当前医院的数据中心里，HIS系统是最主要的信息系统之一，与医院的日

常运行息息相关、存储了大量的关键数据，需要在保障高可用的同时构建弹性的基

础架构应对业务灵活变化，建设稳健的核心业务云。本文通过对某三甲医院HIS系统

背景、存在问题及改造需求进行系统分析基础上，针对性提出HIS系统升级改造的架

构设计，并总结分析了HIS系统升级改造过程中硬件软件的难点以及升级改造项目的

经验，旨在为医疗行业同行分享提供该类HIS系统升级改造的建设经验。

【作者】曾宇平，某三甲医院工程师，硕士研究生，2010年至今从事医院信息化基

础架构设计、实施与运维工作，熟悉各类基础架构信息化产品、技术与方案。

前言

医院管理信息系统(HospitalInformationSystem,HIS)有广义和狭义之分。广义的医院HIS是医院

管理和医疗活动中进行信息管理和联机操作的计算机应用系统的统称；狭义的医院HIS单指医院

门诊及住院信息管理业务系统。而本文所述HIS系统通指其狭义概念。

医院HIS作为医院最重要的信息系统，其稳定、可靠、高效运行以支持医院业务发展需要是医疗

信息化研究的重要方向。随着信息技术日新月异的发展及医院业务需求的不断扩展，如何采用

新技术和新架构促成医院HIS系统的软硬件升级与改造已然成为国内众多医院亟待解决的重要课

题。

本文根据某三甲医院HIS系统升级改造的案例，详细进行阐述分析，以期提供相应的经验分享。

一、背景介绍

该院HIS系统采用的是C/S架构，数据库服务器为两台2010年采购的P570服务器，所用存储为

IBMDS4800。服务器上所采用的操作系统平台为AIX5.3，数据库为Oracle9i，版本为9.2.0.8。

服务器采用AIX的双机集群HACMP以及OracleRAC，将两台服务器做成了一个群集，底层

DS4800存储通过RemoteMirrorFlashCopy实现两个机房间的两台存储之间的远程物理层面的容

灾。容灾环境由一台P550服务器接管，该服务器通过OracleDataGurad方式实现Oracle数据库

的逻辑容灾，HIS架构如图1所示。

图1HIS架构

二、存在问题及升级改造的需求分析

1、架构需优化

HIS系统作为最重要的业务系统，系统的建设目标是追求RTO和RPO均等于0。由上述架构可

知，由于当时的技术限制，虽然架构上考虑到物理层及数据逻辑层的容灾，但是无法实现RTO

和RPO均等于0。物理层面上，两台DS4800之间通过RemoteMirrorFlashCopy实现同步容灾，

可实现RPO等于0，但是因为容灾存储及服务器的启用仍需要进行相应的切换操作才可使容灾环

境支持业务系统，理论RTO时间为5-10分钟；而逻辑层面上，因为OracleDataGuard的配置因

素，生产及容灾环境之间的数据一致性依赖于生产数据库的在线及离线日志是否正常传输至容

灾服务器，而突发的意外宕机极有可能损失一部分日志文件，并且容灾环境的启用也需要比较

复杂及专业的环境切换操作，故RPO及RTO均不可能等于0。

除此之外，容灾体系也不够全面完善。虽然Oracle9i的DataGurad可支持对Oracle数据逻辑层

的回退操作，但是其前提是相应的离线日志尚未被recover恢复。如果已执行recover恢复，则无

法实现相应的回退目标，致使无法实现业务的回退容灾，存在相当的风险隐患，需要引入诸如

全量备份、增量备份及持续数据保护CDP等方式加强数据的逻辑层保护。

2、性能需优化

主机性能方面，通过AIXnmon工具对医院HIS的两台服务器进行监控分析发现，单台服务器

Power6CPU的总核数为16核，平均使用率在80%以上，高峰达到90%，64G内存使用也在90%

左右。如果两台服务器中的其中一台出故障，另外一台在如此压力之下无法胜任支撑业务系统

的要求，相对配置更低的容灾服务器P550更加无法满足业务系统容灾的需要。网络吞吐方面，

数据库的两个实例间的心跳网络为千兆网络，HIS高峰业务期心跳网络的吞吐量长期维持在80-

100M/S，已经达到了千兆网络的瓶颈速度。磁盘IO方面，DS4800的存储配备的是10k的SAS

盘，总共32块