近年來在電子病歷應(yīng)用水平評(píng)級(jí)要求以及醫(yī)院在不同業(yè)務(wù)間實(shí)現(xiàn)協(xié)同等多種因素的推動(dòng)下集成平臺(tái)成為各大型醫(yī)院信息化建設(shè)中重點(diǎn)的項(xiàng)目。

本文將圍繞醫(yī)院集成平臺(tái)的資源需求以及其對(duì) IT 基礎(chǔ)架構(gòu)的要求展開討論并給出基于超融合架構(gòu)的方案配置參考與傳統(tǒng)架構(gòu)的對(duì)比分析。

超融合方案：http://m.51huadong.com/2023/crh.asp

集成平臺(tái)在醫(yī)院信息化中承擔(dān)的角色

隨著醫(yī)院信息化建設(shè)的不斷完善醫(yī)院逐步上線了 HIS、EMR、PACS、LIS 等多個(gè)業(yè)務(wù)系統(tǒng)。

由于這些業(yè)務(wù)系統(tǒng)由不同廠家開發(fā)各個(gè)系統(tǒng)擁有不同的操作系統(tǒng)、數(shù)據(jù)庫進(jìn)而導(dǎo)致不同業(yè)務(wù)系統(tǒng)之間需求調(diào)用復(fù)雜、接口數(shù)量多且無統(tǒng)一標(biāo)準(zhǔn)、數(shù)據(jù)交互效率低下、維護(hù)困難等問題。

集成平臺(tái)的重要性在于其不僅能夠在各個(gè)系統(tǒng)之間實(shí)現(xiàn)統(tǒng)一集成和交互同時(shí)為數(shù)據(jù)集成提供了可能。

通過將各個(gè)系統(tǒng)產(chǎn)生的數(shù)據(jù)集中存儲(chǔ)并重新組織形成醫(yī)院的數(shù)據(jù)倉庫集成平臺(tái)為下一步數(shù)據(jù)分析創(chuàng)造條件即充分挖掘數(shù)據(jù)價(jià)值進(jìn)而形成一系列數(shù)字化應(yīng)用支撐智能化決策幫助醫(yī)院實(shí)現(xiàn)真正數(shù)字化轉(zhuǎn)型�？梢哉f集成平臺(tái)是醫(yī)院數(shù)字化轉(zhuǎn)型的重要基礎(chǔ)。

在部署集成平臺(tái)時(shí)醫(yī)院需要清晰了解集成平臺(tái)的架構(gòu)從平臺(tái)的實(shí)際需求出發(fā)并結(jié)合醫(yī)院資源池建設(shè)的整體規(guī)劃為集成平臺(tái)選擇合適的基礎(chǔ)架構(gòu)。

集成平臺(tái)架構(gòu)簡介

醫(yī)院集成平臺(tái)的實(shí)現(xiàn)方案有很多種早期以接口調(diào)用集成方案為主但這種方案集成效率較低后期逐漸轉(zhuǎn)向企業(yè)服務(wù)總線ESB為主要框架。

ESB 優(yōu)勢

• 可根據(jù)客戶的請(qǐng)求和事件提供路由數(shù)據(jù)轉(zhuǎn)換、翻譯等服務(wù)。
• 具有快速、并行的消息處理能力。

ESB 劣勢

• 無法保證消息或服務(wù)請(qǐng)求的順序而醫(yī)院業(yè)務(wù)之間調(diào)用大多有嚴(yán)格處理順序要求。
• 不支持國際醫(yī)療標(biāo)準(zhǔn)不利于醫(yī)療數(shù)據(jù)上報(bào)、醫(yī)療機(jī)構(gòu)之間的數(shù)據(jù)交互。

ESB 引入消息隊(duì)列軟件處理服務(wù)請(qǐng)求順序的問題、改造 ESB 支持醫(yī)療標(biāo)準(zhǔn)協(xié)議等方案雖然在一定程度上實(shí)現(xiàn)了 ESB 的優(yōu)化但存在方案極其復(fù)雜開發(fā)難度過大成本過高等問題可見在集成平臺(tái)建設(shè)中單憑 ESB 軟件是無法完全滿足業(yè)務(wù)的需求。

經(jīng)過多年的發(fā)展與試錯(cuò)醫(yī)院集成平臺(tái)逐步形成了以 ESB企業(yè)服務(wù)總線、IE集成引擎、ETL 工具三種技術(shù)組合而成的搭建方案。

如上圖所示集成平臺(tái)的集成工作主要包括兩個(gè)部分：應(yīng)用集成和數(shù)據(jù)集成。

應(yīng)用集成

應(yīng)用集成主要實(shí)現(xiàn)各個(gè)業(yè)務(wù)系統(tǒng)之間的請(qǐng)求和調(diào)用由 ESB 和 IE集成引擎兩部分組成；其中 ESB 負(fù)責(zé)同步數(shù)據(jù)處理操作IE 集成引擎負(fù)責(zé)異步數(shù)據(jù)處理。

• ESB 充分發(fā)揮并行處理優(yōu)勢實(shí)時(shí)、高效地處理系統(tǒng)之間的請(qǐng)求。
• IE 集成引擎支持以 HL7、CDA 等國際醫(yī)療標(biāo)準(zhǔn)協(xié)議交互提供消息異步處理機(jī)制解決重視次序的服務(wù)調(diào)用需求。

國內(nèi)集成平臺(tái)常用的集成引擎方案如下表所示�？梢钥闯鰢鴥�(nèi)的集成平臺(tái)廠商大多采用國外成熟的 ESB 企業(yè)服務(wù)總線產(chǎn)品/集成引擎產(chǎn)品。

常見 ESB/集成引擎 產(chǎn)品的系統(tǒng)要求和數(shù)據(jù)庫支持情況如下：

數(shù)據(jù)集成

數(shù)據(jù)集成主要任務(wù)是將醫(yī)院各個(gè)系統(tǒng)所產(chǎn)生的數(shù)據(jù)集中清洗并以新的組織結(jié)構(gòu)進(jìn)行存儲(chǔ)形成醫(yī)院數(shù)據(jù)倉庫以便后續(xù)對(duì)數(shù)據(jù)進(jìn)行分析挖掘和利用。

ETL 工具

ETL 是 extract-transform-load 三個(gè)數(shù)據(jù)處理過程的縮寫：

• 數(shù)據(jù)抽取Extract：連接各個(gè)業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫抽取數(shù)據(jù)庫日志和事務(wù)數(shù)據(jù)。
• 數(shù)據(jù)轉(zhuǎn)換Transform：抽取數(shù)據(jù)后對(duì)數(shù)據(jù)進(jìn)行驗(yàn)證、清洗、根據(jù)規(guī)則執(zhí)行轉(zhuǎn)換。
• 數(shù)據(jù)加載Load：將處理好的數(shù)據(jù)加載到目標(biāo)數(shù)據(jù)庫。

理論上 ETL 工具可從生產(chǎn)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫直接抽取數(shù)據(jù)并轉(zhuǎn)換數(shù)據(jù)但這種方式會(huì)對(duì)生產(chǎn)數(shù)據(jù)庫帶來較大壓力直接影響業(yè)務(wù)系統(tǒng)響應(yīng)速度。為了解決這個(gè)問題 ETL 過程會(huì)先將數(shù)據(jù)完封不動(dòng)地抽取到中間數(shù)據(jù)庫臨時(shí)庫數(shù)據(jù)轉(zhuǎn)換、數(shù)據(jù)加載都會(huì)發(fā)生在臨時(shí)庫中以最大程度上降低對(duì)生產(chǎn)數(shù)據(jù)庫的影響。

集成平臺(tái)對(duì)基礎(chǔ)架構(gòu)帶來的需求變化

集成平臺(tái)的角色多資源需求量大

通常情況下建設(shè)集成平臺(tái)大約涉及 40-80 個(gè)服務(wù)器角色其原因主要在于：

以 ESB 軟件為例它包含應(yīng)用和數(shù)據(jù)庫兩種角色；部分大型三甲醫(yī)院甚至將集成平臺(tái)接口服務(wù)器應(yīng)用角色拆分成多臺(tái)以避免過分集中帶來的風(fēng)險(xiǎn)在這種情況下ESB 可能會(huì)涉及 4-10 個(gè)服務(wù)器角色。

ETL 相對(duì)更加復(fù)雜包含 ETL 工具服務(wù)器中間數(shù)據(jù)庫服務(wù)器通常運(yùn)行 mysql 數(shù)據(jù)庫、目標(biāo)庫服務(wù)器等因此ETL 可能會(huì)涉及 6-12 個(gè)服務(wù)器角色。

同時(shí)集成平臺(tái)生產(chǎn)環(huán)境的各個(gè)角色必需考慮冗余高可用設(shè)計(jì)而且需要有對(duì)應(yīng)的開發(fā)和測試環(huán)境。

可靠性要求高

以往各個(gè)業(yè)務(wù)系統(tǒng)相對(duì)獨(dú)立但引入集成平臺(tái)后所有系統(tǒng)之間的調(diào)用都依賴集成平臺(tái)；一旦發(fā)生宕機(jī)所有業(yè)務(wù)都有可能受到影響風(fēng)險(xiǎn)極大因此集成平臺(tái)對(duì)于基礎(chǔ)架構(gòu)的可靠性要求非常高。

性能要求高

大型三甲醫(yī)院集成平臺(tái)平均每天需要處理 9000 萬條消息要求峰值處理能力需達(dá)到 1000 TPS存儲(chǔ)性能不足容易導(dǎo)致整個(gè)業(yè)務(wù)系統(tǒng)卡頓嚴(yán)重情況下甚至?xí)�宕機(jī)因此非常考驗(yàn)基礎(chǔ)架構(gòu) IO 吞吐能力。

需求變化劇烈

以往醫(yī)院其他業(yè)務(wù)上線后軟件開發(fā)、調(diào)試工作量和頻次較低；但集成平臺(tái)以及數(shù)字化應(yīng)用的引入則涉及大量、持續(xù)的開發(fā)、測試任務(wù)；傳統(tǒng)基礎(chǔ)架構(gòu)的資源擴(kuò)展動(dòng)輒需要數(shù)月進(jìn)行規(guī)劃和部署無法滿足平臺(tái)的敏捷性要求。

為集成平臺(tái)選擇更合適的基礎(chǔ)架構(gòu)

傳統(tǒng)架構(gòu)部署問題凸顯

采用物理服務(wù)器部署需要新購數(shù)十臺(tái)甚至上百臺(tái)服務(wù)器明顯增加風(fēng)險(xiǎn)與壓力。

• 服務(wù)器硬件采購成本壓力大：80 臺(tái)服務(wù)器采購成本需要數(shù)百萬人民幣同時(shí)硬件維保的費(fèi)用也相應(yīng)提高但每臺(tái)服務(wù)器資源的實(shí)際利用率卻非常低。
• 機(jī)房管理風(fēng)險(xiǎn)增大：很多醫(yī)院機(jī)房空間非常有限新增大量的物理服務(wù)器可能會(huì)使得機(jī)房變得擁擠不堪制冷和 UPS 有可能無法滿足需求進(jìn)而為機(jī)房管理帶來較大的風(fēng)險(xiǎn)。
• 集中式 SAN 存儲(chǔ)擴(kuò)展成本高：部分醫(yī)院采用服務(wù)器虛擬化+集中式 SAN 存儲(chǔ)的架構(gòu)運(yùn)行集成平臺(tái)雖然可以解決物理服務(wù)器的一些問題但共享 SAN 存儲(chǔ)的問題則愈發(fā)凸顯。很多大型醫(yī)院選擇全閃 SAN 存儲(chǔ)作為主存儲(chǔ)并為了保證存儲(chǔ)高可用配置了雙活存儲(chǔ)功能其使用成本超過 10萬元/TB ；而集成平臺(tái)對(duì)于存儲(chǔ)資源需求較大完全依賴 SAN 存儲(chǔ)則難以滿足平臺(tái)的持續(xù)擴(kuò)展的需求。

超融合是更理想的基礎(chǔ)架構(gòu)

超融合是新型的“多合一”基礎(chǔ)架構(gòu)

超融合架構(gòu)將服務(wù)虛擬化、服務(wù)器、存儲(chǔ)多種設(shè)備和元素融為一體以軟件為核心使用標(biāo)準(zhǔn)商用硬件替代昂貴的專用硬件解決了傳統(tǒng)架構(gòu)管理復(fù)雜、難以擴(kuò)展等問題。

靈活可擴(kuò)展的基礎(chǔ)架構(gòu)

超融合基礎(chǔ)架構(gòu)采用分布式技術(shù)資源擴(kuò)展不受限于單臺(tái)服務(wù)器的硬件配置可通過擴(kuò)大服務(wù)器集群規(guī)模持續(xù)獲得資源拓展和性能提升。

SmartX 超融合解決方案

方案架構(gòu)

理論上超融合平臺(tái)可承載集成平臺(tái)所有角色但由于部分醫(yī)院用戶仍希望將核心系統(tǒng)的數(shù)據(jù)庫部署傳統(tǒng)架構(gòu)如集成平臺(tái)的 CDR 數(shù)據(jù)庫為了滿足用戶的需求SmartX 提供兩種架構(gòu)綜合部署的解決方案。

• 超融合軟件基于 SmartX 分布式存儲(chǔ) ZBS并與大型醫(yī)院客戶熟悉的 VMware 虛擬化融合部署。
• 以兩臺(tái)物理服務(wù)器和 SAN 存儲(chǔ)組建 Oracle RAC 數(shù)據(jù)庫集群運(yùn)行 CDR 數(shù)據(jù)庫。
• SmartX 超融合平臺(tái)運(yùn)行集成平臺(tái)其他所有角色包括 ESB、ETL、IE、中間庫等角色。
• SmartX 超融合平臺(tái)同時(shí)可承載多個(gè)核心業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫的備機(jī)Oracle DG 備庫/MS SQL Server 備用庫。

方案配置

超融合架構(gòu)與傳統(tǒng)架構(gòu)實(shí)施對(duì)比

方案價(jià)值

優(yōu)異的性價(jià)比打造集成平臺(tái)基礎(chǔ)架構(gòu)

• 超融合架構(gòu)極大提高部署密度只需不到傳統(tǒng)方案 1/10 的物理服務(wù)器數(shù)量即可滿足部署要求大幅減少機(jī)房空間浪費(fèi)。
• SmartX Halo 一體機(jī)支持基于 NVMe 全閃超融合集群性能卓越單節(jié)點(diǎn)處理能力超過 10000+TPS 可滿足大型三甲醫(yī)院集成平臺(tái)高峰消息處理能力要求。

全面提升平臺(tái)可靠性

• 系統(tǒng)集群內(nèi)提供數(shù)據(jù)副本冗余同時(shí)節(jié)點(diǎn)故障可自動(dòng)遷移虛擬機(jī)到其他節(jié)點(diǎn)進(jìn)行恢復(fù)提升了集成平臺(tái)整體可用性水平。
• SMTX OS 支持雙活集群、遠(yuǎn)程容災(zāi)全面滿足電子病歷5級(jí)容災(zāi)備份的RTO和RPO要求。

簡單敏捷

• 方案架構(gòu)簡單無需維護(hù)復(fù)雜的存儲(chǔ)硬件和存儲(chǔ)網(wǎng)絡(luò)。
• 平臺(tái)擴(kuò)展便利可按需投入持續(xù)擴(kuò)展資源池。
• 大幅縮短業(yè)務(wù)交付時(shí)間提升業(yè)務(wù)敏捷性。

綜上所述超融合架構(gòu)承載集成平臺(tái)相較傳統(tǒng)架構(gòu)具備高可靠、高性能、簡單敏捷等多種優(yōu)勢將會(huì)成為醫(yī)院集成平臺(tái)基礎(chǔ)架構(gòu)選型的一個(gè)不可忽略的選項(xiàng)。

針對(duì)醫(yī)療行業(yè)信息化建設(shè)與 IT 轉(zhuǎn)型SmartX《醫(yī)療行業(yè)超融合基礎(chǔ)架構(gòu)解決方案白皮書》圍繞醫(yī)院信息化建設(shè)國家政策要求、大中小型醫(yī)院業(yè)務(wù)特點(diǎn)、以及其基于超融合基礎(chǔ)架構(gòu)的 IT 轉(zhuǎn)型方案等多個(gè)維度進(jìn)行了詳盡闡述。

本文鏈接：http://m.51huadong.com/cloundnews/11008823.html