大型醫(yī)院多院區(qū)一體化基礎(chǔ)信息平臺建設(shè)方案

1、大型醫(yī)院多院區(qū)一體化基礎(chǔ)信息平臺建設(shè)方案第1頁1IT面臨困擾第2頁多院區(qū)割裂信息系統(tǒng)服務(wù)器和數(shù)據(jù)庫加劇膨脹 信息系統(tǒng)碎片化數(shù)據(jù)一致性和完整性服務(wù)器、機(jī)房以及信息接口開發(fā)等成本攀升第3頁 三套HIS電子病歷 患者在多個院區(qū)就診時，診療資料分開建立，不能同時共享 兩套信息系統(tǒng)，版本一致性差，運維成本，服務(wù)器成本 患者就醫(yī)體驗不佳1.1 IT面臨困擾:多院區(qū)割裂信息系統(tǒng)第4頁三個院區(qū)共有110臺PC服務(wù)器各類信息系統(tǒng)共計 96 各數(shù)據(jù)庫假如全部實現(xiàn)高可用（HA），服務(wù)器數(shù)量最少要膨脹到1.5倍除了主力服務(wù)器，其它邊緣服務(wù)器難以得到高質(zhì)量均衡運維伴隨信息化連續(xù)推進(jìn)，這個趨勢依然在繼續(xù)1.2 IT面臨困

2、擾:服務(wù)器和數(shù)據(jù)庫加劇膨脹第5頁1.3 IT面臨困擾: 信息系統(tǒng)孤島全院共有107臺服務(wù)器，92個數(shù)據(jù)庫。數(shù)據(jù)一致性、運轉(zhuǎn)效率、成本效率不佳。比如：主任診療時患者病歷張冠李戴。月初做報表時一線應(yīng)用 時常運行遲緩或卡頓?；颊邔掖巫≡簳r身份ID不整合，既往病歷調(diào) 閱困難，處方查詢速度慢。國內(nèi)醫(yī)院信息系統(tǒng)孤島現(xiàn)象嚴(yán)重，缺乏標(biāo)準(zhǔn)和互聯(lián)互通系統(tǒng)缺乏頂層設(shè)計與規(guī)范整合第6頁 系統(tǒng)被院區(qū)、服務(wù)器、數(shù)據(jù)庫分割成碎片 分散應(yīng)用系統(tǒng)難以形成理想狀態(tài)下協(xié)力，雪崩時每 一片雪花都以為自己是無辜。 應(yīng)用廠商不會為醫(yī)院信息化整體架構(gòu)、數(shù)據(jù)流最優(yōu) 化出發(fā)，而是以自己系統(tǒng)和企業(yè)利益最大化思索 局部亮點代替不了整體質(zhì)量1.4

3、IT面臨困擾：信息碎片化第7頁 近百個數(shù)據(jù)庫之間以數(shù)據(jù)庫同時、表間訪問等實現(xiàn)數(shù)據(jù)流動 醫(yī)療應(yīng)用軟件要求系統(tǒng)間數(shù)據(jù)高度一致性和完整性 當(dāng)前同時機(jī)制對數(shù)據(jù)實時性、完整性和一致性存在不利影響1.5 IT面臨困擾：數(shù)據(jù)一致性和完整性第8頁 比如，開一條抗菌藥品醫(yī)囑，需要在1秒鐘內(nèi)，獲取藥品信息、醫(yī)生信息、患者體征信息、檢驗 匯報、PACS匯報、手術(shù)出血量、手術(shù)切口、藥品配伍禁忌以及既往抗菌藥品醫(yī)囑等信息，要包括EMRLISHISPACSHIS系統(tǒng)、電子病歷、醫(yī)囑系統(tǒng)、LIS系統(tǒng)、手術(shù)麻醉系統(tǒng)、合理用藥系統(tǒng)、PACS系統(tǒng)等7個系統(tǒng)醫(yī)生下達(dá)抗菌藥品醫(yī)囑互聯(lián)網(wǎng)用戶路由數(shù)據(jù)庫1數(shù)據(jù)庫2數(shù)據(jù)庫3數(shù)據(jù)庫4數(shù)據(jù)庫5

4、數(shù)據(jù)庫6事務(wù)規(guī)模小，相 互關(guān)系弱，數(shù)據(jù) 一致性要求相對 低，追求高可用 性第9頁 服務(wù)器購置運維成本 機(jī)房重復(fù)擴(kuò)建升級 系統(tǒng)接口開發(fā)成本是一個輕易忽略但累積金額可觀隱 形成本1.6 IT面臨困擾：服務(wù)器、機(jī)房及信息接口等成本攀升第10頁2多院區(qū)一體化信息平臺第11頁集團(tuán)醫(yī)院以及多院區(qū)一體化是醫(yī)院IT發(fā)展方向醫(yī)院信息化建設(shè)開始從追求應(yīng)用數(shù)量水平擴(kuò)張，轉(zhuǎn)為 深挖內(nèi)涵垂直建設(shè)階段，即從面積到厚度轉(zhuǎn)變。醫(yī)院內(nèi)部信息系統(tǒng)必須頂層設(shè)計下深度融合，實時 互聯(lián)互通，方能應(yīng)對臨床決議支持、HRP、大數(shù)據(jù)等新 一代應(yīng)用。2.1 多院區(qū)一體化信息平臺第12頁 院區(qū)一體化模式：定時上傳平臺OR 建單一系統(tǒng)？ 系統(tǒng)耦合

5、模式：傳統(tǒng)表訪問 、單體數(shù)據(jù)庫、ESB? 服務(wù)器模式：水平擴(kuò)展 OR 垂直擴(kuò)展？2.2 十三五IT架構(gòu)規(guī)劃思緒第13頁2.2.1 院區(qū)一體化模式：定時上傳平臺OR 建單一系統(tǒng)？ 唯有建立單一系統(tǒng)，才能一步到位，徹底改進(jìn)醫(yī)護(hù)和患者使用體驗。 定時同時數(shù)據(jù)依然存在實時性、數(shù)據(jù)一致性、版本不統(tǒng)一、服 務(wù)器資源利用率低等一系列問題。 當(dāng)前市區(qū)范圍裸光纖聯(lián)通成本大大降低，醫(yī)院完全能夠承受。 服務(wù)器存放性能今非昔比。第14頁2.2.2 系統(tǒng)耦合模式：傳統(tǒng)表訪問 、單體數(shù)據(jù)庫、ESB? 數(shù)據(jù)集成平臺愿景很好，效果平平。 數(shù)據(jù)集成平臺極難實現(xiàn)完全互操作，最終異化為數(shù)據(jù)倉庫， 產(chǎn)出一堆漂亮報表而已。 既要務(wù)實，

6、又要前瞻：ESB + 共享單體數(shù)據(jù)庫 單體數(shù)據(jù)庫HIS+EMR+LIS+移動醫(yī)療第15頁2.2.3 服務(wù)器模式：水平擴(kuò)展 OR 垂直擴(kuò)展？ 單體數(shù)據(jù)庫ESB混合模式，決定了支撐數(shù)據(jù)庫服務(wù)器需要足 夠垂直擴(kuò)展能力 X86 Server 硬件可靠性、數(shù)據(jù)處理能力和垂直擴(kuò)展不足，所以 主力生產(chǎn)系統(tǒng)不予考慮 X86 Server 私有云無法虛擬出大于單個物理服務(wù)器性能虛擬服務(wù)器，本質(zhì)上沒有改進(jìn)單機(jī)I/O瓶頸問題 小型機(jī)及更高性能機(jī)型是最正確選擇第16頁2.2.4 服務(wù)器模式：x86服務(wù)器不足CPU性能I/O性能穩(wěn)定性可用性安全性X86服務(wù)器不足x86服務(wù)器單機(jī)整體故障率高，平均每年 故障率2%（ ID

7、C統(tǒng)計）。x86 數(shù)據(jù)處理能力弱，業(yè)界CPU利用率 為10%左右（IDC統(tǒng)計），主要瓶頸在于I/O 短板，不適合做為關(guān)鍵數(shù)據(jù)處理平臺。x86服務(wù)器虛擬化從本質(zhì)上無法提升單機(jī) CPU和I/O處理能力。x86服務(wù)器生命周期短，每隔一年半左右 更新?lián)Q代，硬件廠家和虛擬化廠家產(chǎn)品公布 不一樣時，經(jīng)常造成兼容性問題。第17頁X86虛擬云不足物理server1物理server2物理server n虛擬 服務(wù) 器 1虛擬服務(wù)器3虛擬 服務(wù) 器 2第18頁HISLIS。107臺水平擴(kuò)展，成本低，但數(shù)據(jù)分散，每個 節(jié)點服務(wù)器穩(wěn)定性和可靠性都不高。HISLinuxONE（擴(kuò)展能力: 141顆CPU10TB內(nèi)存）X

8、862.2.5 服務(wù)器模式：水平擴(kuò)展 OR 垂直擴(kuò)展？LISEMRPACS。水平擴(kuò)展(大規(guī)模整合、動態(tài)創(chuàng)建虛機(jī))垂 直 擴(kuò) 展應(yīng) 用 架 構(gòu) 不 變水平擴(kuò)展垂直擴(kuò)展，成本持平，架構(gòu)更靈活，整個平臺 更可靠，有利業(yè)于務(wù)連續(xù)性和多院區(qū)一體化和大數(shù)據(jù)整合。垂 直 擴(kuò) 展應(yīng) 用 架 構(gòu) 不 變垂 直 擴(kuò) 展應(yīng) 用 架 構(gòu) 不 變垂 直 擴(kuò) 展應(yīng) 用 架 構(gòu) 不 變第19頁2.3 對醫(yī)院信息化發(fā)展基本判斷軟件使用者數(shù)量已趨于飽和，不會象互聯(lián)網(wǎng)企業(yè)那樣“暴發(fā)式”增加。所以經(jīng)過服務(wù)器性能 垂直擴(kuò)展（Scale up）完全能夠滿足醫(yī)院需求互聯(lián)網(wǎng)用戶 暴發(fā)式增 長數(shù)據(jù)庫1數(shù)據(jù)庫2數(shù)據(jù)庫3數(shù)據(jù)庫4數(shù)據(jù)庫5數(shù)據(jù)庫6

9、水 平 擴(kuò) 展互 聯(lián) 網(wǎng) 應(yīng) 用醫(yī) 院 應(yīng) 用醫(yī)院員工相對恒定患者發(fā)展相對穩(wěn)定24cpu 24cpu垂 直 擴(kuò) 展第20頁2.4 十三五IT架構(gòu)規(guī)劃結(jié)果 三個院區(qū)買斷裸光纖構(gòu)建冗余環(huán)網(wǎng)，實現(xiàn)院區(qū)網(wǎng)絡(luò)一體化 引進(jìn)LinuxONE大機(jī)服務(wù)器支撐四系統(tǒng)單體數(shù)據(jù)庫 構(gòu)建多院區(qū)一體化基礎(chǔ)信息平臺：HIS、電子病歷數(shù)據(jù)集成平臺 三個院區(qū)共享一套HIS、電子病歷、LIS、移動醫(yī)療改進(jìn)醫(yī)護(hù)和患者使用 體驗 外圍系統(tǒng)嚴(yán)格按照ESB總線實現(xiàn)信息互操作性交互第21頁2.5 選擇LinuxONE幾點考慮三個院區(qū)共享一套數(shù)據(jù)庫 HIS、電子病歷、LIS、移動醫(yī)療共享單體數(shù)據(jù)庫 水平擴(kuò)展能力（數(shù)據(jù)庫整合）垂直擴(kuò)展能力（彈

10、性架構(gòu)） 穩(wěn)定可靠不宕機(jī)(內(nèi)部全冗余設(shè)計，金融行業(yè)首選和久經(jīng)市場驗證) 最安全服務(wù)器平臺（獲取國際安全認(rèn)證最高級別） 強(qiáng)大IO數(shù)據(jù)處理能力（系統(tǒng)I/O帶寬高達(dá)832GBsec） 最正確資源共享平臺（多重虛擬化和虛擬化技術(shù)鼻祖） 是國內(nèi)醫(yī)院首例。美國約翰霍普金斯醫(yī)院EPIC電子病歷基于傳統(tǒng) 大機(jī)第22頁2.5.1 零宕機(jī)全冗余架構(gòu)設(shè)計最高級別RAS特征高度可用性，靠近于連續(xù)可用，硬件平均無故障時間（MTBF）40年 體系架構(gòu)上做到了硬件部件全冗 余設(shè)計，防止單點故障。 備用CPU、內(nèi)存冗余校驗技術(shù)等 關(guān)鍵部件冗余設(shè)計確保不宕機(jī)。 CPU、內(nèi)存、電源線、內(nèi)置電池、 光纖通道卡、網(wǎng)卡等全部部件設(shè) 計

11、都支持N1冗余。 硬件部件做到了智能檢測報警和 自動隔離，支持在線不停機(jī)更換。23核內(nèi)指令雙路校驗，排除處理器故障第23頁2.5.2 LinuxONE主機(jī)擴(kuò)展能力、生命周期與投資保護(hù)考慮IBM LinuxONE主機(jī)生命周期預(yù)計為左右并支持跨2代升級，可在不改變應(yīng)用架構(gòu)前提下，為 系統(tǒng)預(yù)留了充分?jǐn)U展空間，很好保護(hù)了醫(yī)院對一體化基礎(chǔ)信息平臺現(xiàn)有投資。醫(yī)院LinuxONE主機(jī)當(dāng)前最大可升級到141 IFLs10TB內(nèi)存；在不增加硬件條件下，能夠升級至 10 IFLs472GB內(nèi)存；同一個型號從L10升級到L20，最大可擴(kuò)展20 IFLs4TB內(nèi)存。LinuxONE 主機(jī)擴(kuò)展能力IFLsMemory價

12、值和意義不加硬件微碼可升級（2965-L10）10 IFLs472GB無需增加硬件，不停機(jī)升級，對業(yè)務(wù)透明。同一代同機(jī)型可升級（2965-L20）20 IFLs4 TB需增加額外硬件，可不停機(jī)升級，對業(yè)務(wù)透明同一代不一樣機(jī)型可升級（2964）141 IFLs10 TB需要24小時停機(jī)維護(hù)時間，在應(yīng)用架構(gòu)不變前提 下，為橫向擴(kuò)展與縱向擴(kuò)展預(yù)留充分?jǐn)U展空間。未來跨1代升級（參考?xì)v代產(chǎn)品公布經(jīng)驗）未公布未公布生命周期長、支持向下兼容、有效保護(hù)現(xiàn)有投資！未來跨2代升級（參考?xì)v代產(chǎn)品公布經(jīng)驗）未公布未公布生命周期長、支持向下兼容、有效保護(hù)現(xiàn)有投資！第24頁 醫(yī)院基礎(chǔ)信息平臺升級與云架構(gòu)建設(shè) 當(dāng)?shù)卮疟P級別

13、雙活高可用建設(shè) 未來集中災(zāi)備架構(gòu)規(guī)劃2.6 一體化基礎(chǔ)信息平臺構(gòu)建 未來讀寫分離雙活數(shù)據(jù)中心規(guī)劃第25頁2.6.1 醫(yī)院基礎(chǔ)信息平臺升級與云架構(gòu)建設(shè)LinuxONE8 FC8 FC4 FC4 FC閃存 FlashSystem 900存放 DS88844 FC4 FC交換機(jī)SAN48BSVC存放網(wǎng)關(guān)交換機(jī)SAN48BSVC存放網(wǎng)關(guān)4 FC4 FC4 FC4FC硬件平臺升級數(shù)據(jù)集中運維資源完全共享虛機(jī)動態(tài)分配升級整合共享服務(wù)器眾多、資源豎井、運維復(fù)雜架構(gòu)集中、資源共享、運維簡化虛擬虛機(jī)擬虛機(jī)擬虛機(jī)擬虛擬虛機(jī)擬虛機(jī)擬虛機(jī)擬虛擬虛機(jī)擬虛機(jī)擬虛機(jī)擬機(jī)虛擬虛機(jī)擬虛機(jī)擬虛機(jī)擬機(jī)機(jī)機(jī)服務(wù)器云化資源池存放云化資源池服務(wù)器云存放云、新業(yè)務(wù)系統(tǒng)快速布署上線、服務(wù)器和存放資源云化共享、資源按需動態(tài)調(diào) 配架構(gòu)可橫可縱靈活多變、私有云平臺穩(wěn)定可靠、數(shù)據(jù)最高安全保障。醫(yī)院私有云平臺建設(shè)第26頁2.6.2 當(dāng)?shù)卮疟P級別雙活高可用建設(shè)LinuxONESVCVirtual DisksAppAppAppFlashSystem 900DS8884IO寫Mirror1Mirror2 LinuxONE主機(jī)系統(tǒng)帶寬高達(dá)