內容導讀

近年來，在電子病歷應用水平評級要求以及醫院在不同業務間實現協同等多種因素的推動下，整合平臺成為各大型醫院資訊化建設中重點的專案。

本文將圍繞醫院整合平臺的資源需求以及其對 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 轉型方案等多個維度進行了詳盡闡述。38頁醫院超融合方案白皮書下載請點選：

醫院整合平臺 IT 基礎架構解決方案