大型医院多院区一体化基础信息平台建设方案
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
X86 Server 私有云无法虚拟出大于单个物理服务器性能的虚拟 服务器，本质上没有改善单机I/O瓶颈的问题
小型机及更高性能的机型是最佳的选择
2.2.4 服务器模式：x86服务器的局限性
X86服务器的局限性
•x86服务器单机整体故障率高，平均每年 故障率2%（ IDC统计）。
•x86 的数据处理能力弱，业界CPU利用率 为10%左右（IDC统计），主要瓶颈在于I/O 短板，不适合做为核心的数据处理平台。
HIS
EMR
LIS
PACS
路由
数据库 1
数据库 2
数据库 3
数据库 4
数据库 5
数据库 6
事务规模小，相 互关系弱，数据 一致性要求相对 低，追求高可用 性
1.6 IT面临的困扰：服务器、机房及信息接口等成本攀 升
服务器购买运维成本 机房反复扩建升级 系统接口开发成本是一个容易忽视但累积金额可观的隐
•x86服务器虚拟化从本质上无法提高单机 的CPU和I/O处理能力。
•x86服务器生命周期短，每隔一年半左右 更新换代，硬件厂家和虚拟化厂家产品发布 不同步，经常导致兼容性问题。
CPU性能＋I/O性能＋稳定性＋可用性＋安全性
X86虚拟云的局限性
虚拟 服务 器1
虚拟 服务 器2
物理server1
物理server2
无需增加硬件，不停机升级，对业务透明。
同一代同机型可升级（2965-L20）
20 IFLs
4 TB
需增加额外硬件，可不停机升级，对业务透明
同一代不同机型可升级（2964）
141 IFLs
10 TB
需要2～4小时停机维护时间，在应用架构不变前提 下，为横向扩展与纵向扩展预留充足扩展空间。
未来跨1代升级（参照历代产品发布经验）
未发布
未发布
生命周期长、支持向下兼容、有效保护既有投资！
未来跨2代升级（参照历代产品发布经验）
未发布
未发布
生命周期长、支持向下兼容、有效保护既有投资！
2.6 一体化基础信息平台构建
医院基础信息平台升级与云架构建设
本地磁盘级别双活高可用建设 未来集中灾备架构规划 未来读写分离双活数据中心规划
医
互
互联网用户
院
联
爆发式增
应
网
长
用
应
医院员工相对恒定 患者发展相对稳定
用
数据库
数据库
数据库
1
2
3
水
平
数据库
数据库
数据库
扩
4
5
6
展
24cpu
垂
24cpu
直
扩
展
2.4 十三五IT架构的规划结果
三个院区买断裸光纤构建冗余环网，实现院区网络一体化 引进LinuxONE大机服务器支撑四系统单体数据库 构建多院区一体化基础信息平台：HIS、电子病历＋数据集成平台 三个院区共享一套HIS、电子病历、LIS、移动医疗改进医护和患者使用
虚 拟虚 机拟虚
机拟虚 机拟
机
虚 拟虚 机拟虚
机拟虚 机拟
机
LinuxONE
虚 拟虚 机拟虚
机拟虚 机拟
机
虚 拟虚 机拟虚
机拟虚 机拟
机
8 FC 交换机SAN48B
4 FC
4 FC
4 FC
服务器云化资源池
8 FC 4FC 4 FC
交换机SAN48B
存储云
4 FC
4 FC 4 FC
SVC存储网关
SVC存储网关
形成本
2 多院区一体化信息平台
2.1 多院区一体化信息平台
1. 集团医院以及多院区一体化是医院IT发展方向 2. 医院信息化建设开始从追求应用数量的水平扩张，转为
深挖内涵的垂直建设阶段，即从面积到厚度的转变。 3. 医院内部的信息系统必须顶层设计下的深度融合，实时
互联互通，方能应对临床决策支持、HRP、大数据等新 一代应用。
PACS
水平扩展(大规模整合、动态创建虚机)
LinuxONE（扩展能力: 141颗CPU＋10TB内存） 水平扩展＋垂直扩展，成本持平，架构更灵活，整个平台 更可靠，有利业于务连续性和多院区一体化和大数据整合。
2.3 对医院信息化发展的基本判断
软件使用者数量已趋于饱和，不会象互联网企业那样“爆发式”增长。因此通过服务器性能 垂直扩展（Scale up）完全可以满足医院的需求
生产磁盘读写策略设计，同时写 FlashSystem900和DS8884，优先从 FlashSystem900读。
本地磁盘高可用设计使得RPO＝0，RTO＝0 成为可能（ 不停机切换），可以做到单台 存储损坏 或离线维护，而业务不中断。
App App App
IO写
LinuxONE Virtual Disks
国内医院信息系统孤岛现象严重，缺乏标准和互联互通
系统缺乏顶层设计与规范整 合
全院共有107台服务器，92个数据库。数据一致性、运转效率、 成本效率不佳。
例如：主任诊疗时患者病历张冠李戴。月初做报表时一线应用 时常运行缓慢或卡顿。患者多次住院时身份ID不整合，既往病历调 阅困难，处方查询速度慢。
1.4 IT面临的困扰：信息碎片化
硬件部件做到了智能检测报警和 自动隔离，支持在线不停机更换。
23
2.5.2 LinuxONE主机扩展能力、生命周期与投资保护的考 虑
• IBM LinuxONE主机生命周期预计为10年左右并支持跨2代升级，可在不 改变应用架构的前提下，为 系统预留了充足的扩展空间，很好的保护
了医院对一体化基础信息平台的既有投资。
例如，开一条抗菌药物医嘱，需要在1秒钟内，获取药品信息、医生信息、患者体征信息、检验 报告、PACS报告、手术出血量、手术切口、药品配伍禁忌以及既往抗菌药物医嘱等信息，要涉及 HIS系统、电子病历、医嘱系统、LIS系统、手术麻醉系统、合理用药系统、PACS系统等7个系统
医生下达抗菌药物医嘱
互ห้องสมุดไป่ตู้网用户
闪存 FlashSystem 900
存储 DS8884
存储云化资源池
架构集中、资源共享、运维简化
2.6.2 本地磁盘级别双活高可用建设
LinuxONE主机系统带宽高达832GB/sec，最 高可配141颗处理器和10TB内存，单台可支 持8000个虚机。
全闪存阵列全面提升磁盘IO/ 性能，IOPS可 以达到百万 级别，时延小于0.5毫秒。
产出一堆漂亮的报表而已。 既要务实，又要前瞻：ESB + 共享单体数据库 单体数据库＝HIS + EMR + LIS + 移动医疗
2.2.3 服务器模式：水平扩展 OR 垂直扩展？
单体数据库＋ESB混合模式，决定了支撑数据库的服务器需要足 够的垂直扩展能力
X86 Server 硬件可靠性、数据处理能力和垂直扩展不足，因此 主力生产系统不予考虑
2.2 十三五IT架构的规划思路
院区一体化模式：定期上传平台 OR 建单一系统？ 系统耦合模式：传统表访问 、单体数据库、ESB? 服务器模式：水平扩展 OR 垂直扩展？
2.2.1 院区一体化模式：定期上传平台 OR 建单一系统？
唯有建立单一系统，才能一步到位，彻底改进医护和患者使用 体验。
系统被院区、服务器、数据库分割成碎片 分散的应用系统难以形成理想状态下的合力，雪崩时每
一片雪花都觉得自己是无辜的。 应用厂商不会为医院的信息化整体架构、数据流的最优
化出发，而是以自己系统和公司的利益最大化思考 局部亮点代替不了整体质量
1.5 IT面临的困扰：数据一致性和完整性
近百个数据库之间以数据库同步、表间访问等实现数据流动 医疗应用软件要求系统间数据高度一致性和完整性 当前同步机制对数据实时性、完整性和一致性存在不利影响
1.2 IT面临的困扰:服务器和数据库加剧膨胀
三个院区共有110台PC服务器 各类信息系统共计 96 各数据库 如果全部实现高可用（HA），服务器数量至少要膨胀到1.5倍 除了主力服务器，其他边缘服务器难以得到高质量均衡运维 随着信息化持续推进，这个趋势仍然在继续
1.3 IT面临的困扰: 信息系统孤岛
体验 外围系统严格按照ESB总线实现信息互操作性交互
2.5 选择LinuxONE的几点考虑
三个院区共享一套数据库 HIS、电子病历、LIS、移动医疗共享单体数据库 水平扩展能力（数据库整合）＋垂直扩展能力（弹性架构） 稳定可靠不宕机(内部全冗余设计，金融行业首选和久经市场验证) 最安全的服务器平台（获取国际安全认证最高级别） 强大的IO数据处理能力（系统I/O带宽高达832GB／sec） 最佳资源共享平台（多重虚拟化和虚拟化技术的鼻祖） 是国内医院首例。美国约翰霍普金斯医院EPIC电子病历基于传统
• 医院LinuxONE主机当前最大可升级到141 IFLs＋10TB内存；在不增加
硬件L的inux条ON件E 主下机，扩可展能以力升级至 1IFL0s IFLs＋4M7e2mGoBry内存；同一个价型值号和意从义L10
升不级加硬到件微L码2可0升，级（最2965-大L10）可扩展20 IF1L0sIF＋Ls 4TB内存472。GB
定期同步数据仍然存在实时性、数据一致性、版本不统一、服 务器资源利用率低等一系列问题。
当前市区范围裸光纤联通成本大大降低，医院完全可以承受。 服务器存储性能今非昔比。
2.2.2 系统耦合模式：传统表访问 、单体数据库、ESB?
数据集成平台愿景很好，效果平平。 数据集成平台很难实现完全的互操作，最终异化为数据仓库，
2.6.1 医院基础信息平台升级与云架构建设
新业务系统快速部署上线、服务器和存储资源云化共享、资源按需动态调 、 配架构可横可纵灵活多变、私有云平台稳定可靠、数据最高安全保障。
医院私有云平台建设
服务器云
硬件平台升级 数据集中运维
升级＋整合＋共享
服务器众多、资源竖井、运维复杂
资源完全共享 虚机动态分配
大型医院多院区一体化基础信息平 台建设方案
1 IT面临的困扰
多院区割裂信息系统 服务器和数据库加剧膨胀 信息系统碎片化
数据一致性和完整性 服务器、机房以及信息接口开发等成本攀升
1.1 IT面临的困扰:多院区割裂信息系统
三套HIS电子病历 患者在多个院区就诊时，诊疗资料分开建立，不能同步共享 两套信息系统，版本一致性差，运维成本，服务器成本 患者就医体验不佳
虚拟服务器 3
物理server n
2.2.5 服务器模式：水平扩展 OR 垂直扩展？
水平扩展，成本低，但数据分散，每个 节点服务器的稳定性和可靠性都不高。
HIS
LIS
X86 。。107台
垂
垂
垂
垂
直
直
直
直
扩
扩
扩
扩
展
展
展
展
—
—
—
—
应
应
应
应
用
用
用
。。。 用
架
架
架
架
构
构
构
构
不
不
不
不
变
变
变
变
HIS
LIS
EMR
Mirror1
Mirror2
SVC
FlashSystem 900
DS8884
汇报完毕 感谢聆听
大机
2.5.1 零宕机的全冗余架构设计—最高级别的RAS特 性
高度的可用性，接近于连续可用，硬件平均无故障时间（MTBF）>40年
核内指令双路校验，排除处理器故障
体系架构上做到了硬件部件全冗 余设计，避免单点故障。
备用CPU、内存冗余校验技术等 关键部件冗余设计确保不宕机。
CPU、内存、电源线、内置电池、 光纤通道卡、网卡等所有部件设 计都支持N＋1冗余。
小型机及更高性能的机型是最佳的选择
2.2.4 服务器模式：x86服务器的局限性
X86服务器的局限性
•x86服务器单机整体故障率高，平均每年 故障率2%（ IDC统计）。
•x86 的数据处理能力弱，业界CPU利用率 为10%左右（IDC统计），主要瓶颈在于I/O 短板，不适合做为核心的数据处理平台。
HIS
EMR
LIS
PACS
路由
数据库 1
数据库 2
数据库 3
数据库 4
数据库 5
数据库 6
事务规模小，相 互关系弱，数据 一致性要求相对 低，追求高可用 性
1.6 IT面临的困扰：服务器、机房及信息接口等成本攀 升
服务器购买运维成本 机房反复扩建升级 系统接口开发成本是一个容易忽视但累积金额可观的隐
•x86服务器虚拟化从本质上无法提高单机 的CPU和I/O处理能力。
•x86服务器生命周期短，每隔一年半左右 更新换代，硬件厂家和虚拟化厂家产品发布 不同步，经常导致兼容性问题。
CPU性能＋I/O性能＋稳定性＋可用性＋安全性
X86虚拟云的局限性
虚拟 服务 器1
虚拟 服务 器2
物理server1
物理server2
无需增加硬件，不停机升级，对业务透明。
同一代同机型可升级（2965-L20）
20 IFLs
4 TB
需增加额外硬件，可不停机升级，对业务透明
同一代不同机型可升级（2964）
141 IFLs
10 TB
需要2～4小时停机维护时间，在应用架构不变前提 下，为横向扩展与纵向扩展预留充足扩展空间。
未来跨1代升级（参照历代产品发布经验）
未发布
未发布
生命周期长、支持向下兼容、有效保护既有投资！
未来跨2代升级（参照历代产品发布经验）
未发布
未发布
生命周期长、支持向下兼容、有效保护既有投资！
2.6 一体化基础信息平台构建
医院基础信息平台升级与云架构建设
本地磁盘级别双活高可用建设 未来集中灾备架构规划 未来读写分离双活数据中心规划
医
互
互联网用户
院
联
爆发式增
应
网
长
用
应
医院员工相对恒定 患者发展相对稳定
用
数据库
数据库
数据库
1
2
3
水
平
数据库
数据库
数据库
扩
4
5
6
展
24cpu
垂
24cpu
直
扩
展
2.4 十三五IT架构的规划结果
三个院区买断裸光纤构建冗余环网，实现院区网络一体化 引进LinuxONE大机服务器支撑四系统单体数据库 构建多院区一体化基础信息平台：HIS、电子病历＋数据集成平台 三个院区共享一套HIS、电子病历、LIS、移动医疗改进医护和患者使用
虚 拟虚 机拟虚
机拟虚 机拟
机
虚 拟虚 机拟虚
机拟虚 机拟
机
LinuxONE
虚 拟虚 机拟虚
机拟虚 机拟
机
虚 拟虚 机拟虚
机拟虚 机拟
机
8 FC 交换机SAN48B
4 FC
4 FC
4 FC
服务器云化资源池
8 FC 4FC 4 FC
交换机SAN48B
存储云
4 FC
4 FC 4 FC
SVC存储网关
SVC存储网关
形成本
2 多院区一体化信息平台
2.1 多院区一体化信息平台
1. 集团医院以及多院区一体化是医院IT发展方向 2. 医院信息化建设开始从追求应用数量的水平扩张，转为
深挖内涵的垂直建设阶段，即从面积到厚度的转变。 3. 医院内部的信息系统必须顶层设计下的深度融合，实时
互联互通，方能应对临床决策支持、HRP、大数据等新 一代应用。
PACS
水平扩展(大规模整合、动态创建虚机)
LinuxONE（扩展能力: 141颗CPU＋10TB内存） 水平扩展＋垂直扩展，成本持平，架构更灵活，整个平台 更可靠，有利业于务连续性和多院区一体化和大数据整合。
2.3 对医院信息化发展的基本判断
软件使用者数量已趋于饱和，不会象互联网企业那样“爆发式”增长。因此通过服务器性能 垂直扩展（Scale up）完全可以满足医院的需求
生产磁盘读写策略设计，同时写 FlashSystem900和DS8884，优先从 FlashSystem900读。
本地磁盘高可用设计使得RPO＝0，RTO＝0 成为可能（ 不停机切换），可以做到单台 存储损坏 或离线维护，而业务不中断。
App App App
IO写
LinuxONE Virtual Disks
国内医院信息系统孤岛现象严重，缺乏标准和互联互通
系统缺乏顶层设计与规范整 合
全院共有107台服务器，92个数据库。数据一致性、运转效率、 成本效率不佳。
例如：主任诊疗时患者病历张冠李戴。月初做报表时一线应用 时常运行缓慢或卡顿。患者多次住院时身份ID不整合，既往病历调 阅困难，处方查询速度慢。
1.4 IT面临的困扰：信息碎片化
硬件部件做到了智能检测报警和 自动隔离，支持在线不停机更换。
23
2.5.2 LinuxONE主机扩展能力、生命周期与投资保护的考 虑
• IBM LinuxONE主机生命周期预计为10年左右并支持跨2代升级，可在不 改变应用架构的前提下，为 系统预留了充足的扩展空间，很好的保护
了医院对一体化基础信息平台的既有投资。
例如，开一条抗菌药物医嘱，需要在1秒钟内，获取药品信息、医生信息、患者体征信息、检验 报告、PACS报告、手术出血量、手术切口、药品配伍禁忌以及既往抗菌药物医嘱等信息，要涉及 HIS系统、电子病历、医嘱系统、LIS系统、手术麻醉系统、合理用药系统、PACS系统等7个系统
医生下达抗菌药物医嘱
互ห้องสมุดไป่ตู้网用户
闪存 FlashSystem 900
存储 DS8884
存储云化资源池
架构集中、资源共享、运维简化
2.6.2 本地磁盘级别双活高可用建设
LinuxONE主机系统带宽高达832GB/sec，最 高可配141颗处理器和10TB内存，单台可支 持8000个虚机。
全闪存阵列全面提升磁盘IO/ 性能，IOPS可 以达到百万 级别，时延小于0.5毫秒。
产出一堆漂亮的报表而已。 既要务实，又要前瞻：ESB + 共享单体数据库 单体数据库＝HIS + EMR + LIS + 移动医疗
2.2.3 服务器模式：水平扩展 OR 垂直扩展？
单体数据库＋ESB混合模式，决定了支撑数据库的服务器需要足 够的垂直扩展能力
X86 Server 硬件可靠性、数据处理能力和垂直扩展不足，因此 主力生产系统不予考虑
2.2 十三五IT架构的规划思路
院区一体化模式：定期上传平台 OR 建单一系统？ 系统耦合模式：传统表访问 、单体数据库、ESB? 服务器模式：水平扩展 OR 垂直扩展？
2.2.1 院区一体化模式：定期上传平台 OR 建单一系统？
唯有建立单一系统，才能一步到位，彻底改进医护和患者使用 体验。
系统被院区、服务器、数据库分割成碎片 分散的应用系统难以形成理想状态下的合力，雪崩时每
一片雪花都觉得自己是无辜的。 应用厂商不会为医院的信息化整体架构、数据流的最优
化出发，而是以自己系统和公司的利益最大化思考 局部亮点代替不了整体质量
1.5 IT面临的困扰：数据一致性和完整性
近百个数据库之间以数据库同步、表间访问等实现数据流动 医疗应用软件要求系统间数据高度一致性和完整性 当前同步机制对数据实时性、完整性和一致性存在不利影响
1.2 IT面临的困扰:服务器和数据库加剧膨胀
三个院区共有110台PC服务器 各类信息系统共计 96 各数据库 如果全部实现高可用（HA），服务器数量至少要膨胀到1.5倍 除了主力服务器，其他边缘服务器难以得到高质量均衡运维 随着信息化持续推进，这个趋势仍然在继续
1.3 IT面临的困扰: 信息系统孤岛
体验 外围系统严格按照ESB总线实现信息互操作性交互
2.5 选择LinuxONE的几点考虑
三个院区共享一套数据库 HIS、电子病历、LIS、移动医疗共享单体数据库 水平扩展能力（数据库整合）＋垂直扩展能力（弹性架构） 稳定可靠不宕机(内部全冗余设计，金融行业首选和久经市场验证) 最安全的服务器平台（获取国际安全认证最高级别） 强大的IO数据处理能力（系统I/O带宽高达832GB／sec） 最佳资源共享平台（多重虚拟化和虚拟化技术的鼻祖） 是国内医院首例。美国约翰霍普金斯医院EPIC电子病历基于传统
• 医院LinuxONE主机当前最大可升级到141 IFLs＋10TB内存；在不增加
硬件L的inux条ON件E 主下机，扩可展能以力升级至 1IFL0s IFLs＋4M7e2mGoBry内存；同一个价型值号和意从义L10
升不级加硬到件微L码2可0升，级（最2965-大L10）可扩展20 IF1L0sIF＋Ls 4TB内存472。GB
定期同步数据仍然存在实时性、数据一致性、版本不统一、服 务器资源利用率低等一系列问题。
当前市区范围裸光纤联通成本大大降低，医院完全可以承受。 服务器存储性能今非昔比。
2.2.2 系统耦合模式：传统表访问 、单体数据库、ESB?
数据集成平台愿景很好，效果平平。 数据集成平台很难实现完全的互操作，最终异化为数据仓库，
2.6.1 医院基础信息平台升级与云架构建设
新业务系统快速部署上线、服务器和存储资源云化共享、资源按需动态调 、 配架构可横可纵灵活多变、私有云平台稳定可靠、数据最高安全保障。
医院私有云平台建设
服务器云
硬件平台升级 数据集中运维
升级＋整合＋共享
服务器众多、资源竖井、运维复杂
资源完全共享 虚机动态分配
大型医院多院区一体化基础信息平 台建设方案
1 IT面临的困扰
多院区割裂信息系统 服务器和数据库加剧膨胀 信息系统碎片化
数据一致性和完整性 服务器、机房以及信息接口开发等成本攀升
1.1 IT面临的困扰:多院区割裂信息系统
三套HIS电子病历 患者在多个院区就诊时，诊疗资料分开建立，不能同步共享 两套信息系统，版本一致性差，运维成本，服务器成本 患者就医体验不佳
虚拟服务器 3
物理server n
2.2.5 服务器模式：水平扩展 OR 垂直扩展？
水平扩展，成本低，但数据分散，每个 节点服务器的稳定性和可靠性都不高。
HIS
LIS
X86 。。107台
垂
垂
垂
垂
直
直
直
直
扩
扩
扩
扩
展
展
展
展
—
—
—
—
应
应
应
应
用
用
用
。。。 用
架
架
架
架
构
构
构
构
不
不
不
不
变
变
变
变
HIS
LIS
EMR
Mirror1
Mirror2
SVC
FlashSystem 900
DS8884
汇报完毕 感谢聆听
大机
2.5.1 零宕机的全冗余架构设计—最高级别的RAS特 性
高度的可用性，接近于连续可用，硬件平均无故障时间（MTBF）>40年
核内指令双路校验，排除处理器故障
体系架构上做到了硬件部件全冗 余设计，避免单点故障。
备用CPU、内存冗余校验技术等 关键部件冗余设计确保不宕机。
CPU、内存、电源线、内置电池、 光纤通道卡、网卡等所有部件设 计都支持N＋1冗余。