醫療信息系統私有云建設方案探討

劉芳，管新，袁飛，楊繼奎

南通市通州區人民醫院 信息科,江蘇 南通 226300

隨著公眾對自己健康越來越關注，人們希望醫療機構能夠提供更加優質的服務，健康信息服務是醫療服務的重要組成部分，大眾希望得到高效、快捷、安全的健康信息服務，同時能方便地獲取全面的個性化健康信息，例如個人健康檔案信息、個人電子病歷信息。這對當前的醫療信息系統提出了更高的要求，甚至可以說是挑戰。

醫療信息系統本身也積累了海量數據。如何利用好現有的數據為大眾提供更好的信息服務，也是一項艱巨的任務。

近年來IT業興起的云計算模式為應對這樣的挑戰提供了一個很好的解決方案。

1 云計算興起的背景

1.1 谷歌、亞馬遜等大型網站對于海量數據存儲和高計算性能研發成就了云計算

對于用戶來說，遠端的數據存儲和軟件服務可以看作是云端，用戶不用關心數據和服務從哪里來，就像享受隨用隨到的電力和水力服務一樣享受著來自云端的軟件服務和各種各樣的數據。云計算的關鍵是建立好數據中心和計算中心[1]。

海量數據存儲可以理解為數據中心，高性能計算可以理解為計算中心，數據中心和計算中心并不是割裂的，而是合二為一的。實現方法主要是將多臺計算機通過高速網絡連接起來，提供近乎無限的數據存儲、計算能力和完美的可靠性。

數據中心最關鍵的是管理軟件，通過管理軟件來管理好加入數據中心的每一臺計算機，管理好計算任務和數據存儲的負載均衡。

據微軟網站的介紹，微軟云計算中心每月都要加入上千臺服務器來提高服務能力以滿足不斷增長的用戶需要。微軟云計算中心為全世界的數十億用戶永不間斷地提供著HotMail、SkyDrive、Office365 等在線應用服務。

醫療機構的健康信息中心同樣面對著海量數據存儲和高性能計算能力的擴展需求。健康信息中心也應該橫向擴展，即通過增加計算節點來擴展計算能力。當中心感到在業務高峰計算能力不足，要通過加入低成本計算機或者啟動虛擬機加入服務器集群來提高計算能力[2]。

1.2 軟件即服務

大型醫院集團化管理對醫療軟件的部署也提出了新要求，小型醫療機構加盟集團后，最好不需要重新部署信息系統，而是通過互聯網免安裝下載和使用信息系統的各模塊。信息中心只要在后端服務器進行配置后，就能使新加盟的醫療機構融入到集團整個信息系統中，不再像過去通過購買盒裝軟件，省去軟件購買、安裝、升級等繁雜手續。

普通大眾也希望通過互聯網享受到信息中心的各種服務，要求軟件終端本身就基于Web。用戶的終端也不僅限于PC，越來越多的智能手機和平板電腦也擁有了類似PC的計算能力，并且在不遠的未來，智能手機和平板電腦的數量將遠遠多于現有的PC數量。未來公眾很可能通過智能手機終端軟件去查詢自己的電子病歷和健康檔案信息，或者通過智能手機做一些互動的健康咨詢類似需求，醫療機構提供海量健康信息數據存儲和計算中心，并通過電信網絡和互聯網為廣大公眾提供健康信息服務。

這些需求總結起來就是軟件即服務，要求醫療信息系統要提供適應更多終端的客戶端。

1.3 大中型醫院的私有云建設和應用

健康信息屬于個人信息，對于安全性要求很高，因此不能把健康信息存儲到公共的云端，醫療機構必須建設自己的云計算中心，即私有云[3]。

私有云的另一個特點是云計算的特征，提供海量數據存儲能力和強大的計算能力，并且提供方便快捷的軟件服務。這個特點也可以使醫院管理集團共享IT資源[4]。

建設私有云計算的核心在于建設和管理服務器集群[5-6]。

（1）要做到服務器集群的橫向擴展。即通過增加計算機或虛擬機來近乎線性地提高計算能力和數據存儲能力。

（2）新增加計算機或虛擬機時，不需要修改軟件，只需要做服務器集群的配置操作。

（3）多個服務集群之間可以互相作為備份，提高整個系統的可靠性和安全性。

（4）服務器集群中應該有負載均衡管理功能，將業務高峰時的工作負擔均分到各個服務器中，提高整個系統的性能。

（5）監控軟件來監控服務器集群中各個節點的運行狀態。

私有云不但能為本醫療機構信息系統和客戶服務，還能作為一個重要的基礎設施為其他醫療機構服務。例如，一個醫院管理集團圍繞著一個或若干個大型骨干醫院以及其他加盟醫院具有緊密合作關系，在醫院管理集團內不但可以共享優質的醫療資源，也可以共享IT基礎設施。一個醫院管理集團可以集中優勢資源建立一個高質量的私有云，集團內部的小醫院不必再重復建設信息系統，可以直接使用集團私有云提供的各種信息服務和數據服務。小醫院不僅大大降低自己的運營成本，而且獲得和大型醫院一樣高質量高水平的信息服務。整個集團也可以做到信息的集中管理，大大降低運營成本。

1.4 私有云的安全問題

私有云的安全性也是一個焦點問題。

（1）確?；A平臺的安全性，基礎平臺包括操作系統、數據庫、Web服務器、網絡中間件等[7]。① 服務器OS應采用Linux或者 Windows Server 2008 R2等安全性好的系統，并及時更新安全補丁。② 在操作系統上實施嚴格的安全策略。③ 數據庫應采用 Oracle、DB2或者SQLServer2008等安全性好的DB，并規劃好用戶、角色和數據的存取設置。數據庫服務器必須有熱備。④ 數據庫數據和文檔化的非結構化半結構化數據必須冗余存儲[8]。⑤ 安裝和打開網絡防火墻，關閉不用的DNS域名、IP和端口。⑥ 安裝網絡殺毒軟件并及時更新。

（2）應用軟件本身應該具備嚴密、完備的安全性。① 充分利用操作系統和數據庫所提供的安全性功能，劃分不同賬戶、不同角色，各自能夠訪問的數據。② 應用軟件本身應該提供賬戶、角色和功能的使用權限設置。③ 應用軟件應提供完備的Log記錄功能，對于敏感操作和敏感數據的存取要做到留痕。④ 系統賬戶信息、用戶賬戶信息等核心數據應該加密存儲。

（3）規劃好內網和外網（可以訪問互聯網）的網絡拓撲結構，保證內網的安全。① 確保內網和外網物理隔離，確保內網數據不能被外網訪問。② 外網需要訪問內網數據的時候，必須通過代理服務器訪問，不能直接把內網服務器暴露出來。③ 外網的訪問請求和數據傳輸必須加密。應該為每位外網用戶提供軟數字證書或硬數字證書，以便對傳輸數據進行加密，對其身份進行認證。

2 私有云的實現方案探討

下面結合醫院的實際情況討論一個私有云建設具體實施方案。現有的HIS數據庫一般采用單臺服務器模式，如果需要擴展計算能力必須要縱向擴展，所謂縱向擴展就是增加單臺服務器的硬件配置，例如增加內存、增加CPU核心的數量等，縱向擴展的優點是軟件不需要修改，但是擴展成本很高，而且擴展能力十分有限，單臺機器上的硬盤IO和網絡IO是一個繞不開的瓶頸。

所以想要無限地并且接近線性擴展系統的數據處理能力，服務器必須做到橫向擴展，即通過增加廉價的計算機節點來擴展系統的數據處理能力，數據處理任務分發給不同的服務器，這就要求軟件要做大的改造[9-10]。

2.1 通過增加計算機，即橫向擴展來提高整個系統數據處理能力

現階段的HIS仍然建立在數據庫基礎上。數據的存儲一般都放在數據庫里。醫院的業務高峰時也是數據庫服務器訪問量的高峰，單個數據庫的IO吞吐量往往成為整個系統的處理瓶頸，要突破這個瓶頸，應該建立數據庫服務器集群，計算任務分發給群內的計算機，并且對集群進行完善的管理。

數據應該通過網絡廣播和復制功能分發到不同的數據庫服務器上，數據必須冗余保存到多個數據庫服務器[11]。服務器通過管理模塊有機組成一個完整的數據存儲和提供數據訪問的服務單元，我們稱之為數據庫服務器集群[12]。

2.2 利用數據庫的數據復制功能建立數據庫服務器集群

數據庫服務器集群的關鍵是對內可以做到橫向擴展，即通過增加機器來提供數據存儲能力和提高數據吞吐量，對外作為一個整體提供數據訪問服務。

在集群內應使用數據復制功能，將數據通過一定的策略廣播到不同的數據庫實例中。目前HIS采用SQLServer作為數據庫平臺有很多，可以利用SQLServer數據庫本身提供的事務數據復制功能，在服務器之間復制數據[13]。

集群管理模塊要有一個數據存取的路由算法對SQL語句進行分析并轉發到不同的服務器上存取數據[14]。

以下方案參考了某超大型電子商務網站的數據庫配置方案，該方案完全能高效處理每天增加1G數據的數據量，足以應對目前國內任何一家大型醫院的要求。

2.3 面向醫院信息私有云的數據庫服務器集群建設方案

2.3.1 方案綜述

該方案的軟件部分主要有以下幾個組成部分：見圖1

圖1 數據庫服務器集群建設方案的軟件組成

（1 ）各種客戶終端：PC、平板電腦、智能手機。

（2）WebServices 應用服務器，例如基于IIS的WebServices服務器。

（3）數據庫集群管理模塊，該管理模塊內置了負載均衡模塊。

（4）數據庫服務器集群，集群內根據服務器的功能角色還可以分為：① 原始數據存儲服務器；② 熱點數據處理服務器；③ 歷史數據處理服務器。

客戶端的服務請求通過HTTP WebServices提交給Application Server 后，由Application Server 轉發給數據庫集群管理模塊（Database Cluster Management Module，DCMM），DCMM會對客戶請求的數據進行分析，并將其分為三類：

（1）原始數據的存儲。 原始數據單獨存儲，是要保證最好的原始數據處理性能。

（2）熱點數據處理和查詢。所謂熱點數據就是近期常用的數據，它不是原始數據，而是原始數據的計算結果。

（3）歷史數據查詢和分析。所謂歷史數據是屬于以前并且不常用的數據。

如果配置了負載均衡功能的話，DCMM還需要調用負載均衡模塊來確定最終客戶請求要發送給哪臺服務器。

2.3.2 數據庫服務器功能角色分類介紹

數據庫集群內包含了三類不同功能的服務器節點：

（1）原始數據存儲服務器對HIS來說，原始數據是：掛號、處方、醫囑、電子病歷、明細賬目等信息。

該服務器接收來自DCMM的insert update 等SQL語句以及存儲過程，接收原始數據并保存，為了提升性能，它不做任何計算。

原始數據保存后再通過高速網絡通道復制分發給熱點數據處理服務器。

當單臺服務器IO處理成為瓶頸時，可以用相同功能的服務器組成集群，DCMM 相應地要增加負載均衡計算和路由功能。由負載均衡模塊來選擇相對輕負載的服務器，提高整個系統的性能。

若存在多臺原始數據存儲服務器時，單臺服務器所保存的數據也應該廣播給其他原始數據存儲服務器。

（2）熱點數據處理服務器它主要是訂閱和接收原始數據，并進行計算和緩存快照處理。例如，當接收到住院病人的醫囑數據后，計算住院病人的賬戶。

它接收來自DCMM的數據查詢請求并返回相應的數據。

當單臺服務器成為瓶頸時，要增加服務器并組成集群，同樣的，DCMM要相應增加負載均衡計算和路由功能。

若存在多臺熱點數據處理服務器時，單臺服務器所處理的數據也應該廣播給其他熱點數據處理服務器。

隨著時間的流逝，當熱點數據漸漸變成乏人問津的數據后，它通過復制功能將數據復制給歷史數據處理服務器。

（3）歷史數據查詢和分析服務器專門用來作為對于相應速度要求不高的歷史數據查詢和分析服務器。

例如，出院3個月以上的病人數據可以轉儲到歷史數據服務器里。一年前的部門報表也可以轉儲到歷史數據服務器里等。

還可以采用SQLServer的Analysis Services 數據倉庫服務器來構建數據倉庫存儲和查詢功能。

2.4 負載均衡的實現方法

當集群內出現了多臺相同功能的服務器時，就需要做負載均衡的計算將任務較為均衡地分發給單臺服務器。

下面討論一個簡單的負載均衡邏輯。

（1）負載均衡模塊應隨時記錄所有可用的服務器并記住它們的網絡位置，服務器可以通過向負載均衡模塊發送心跳消息來報告自己的位置。當負載均衡模塊在一定時間段內未能收到某臺服務器的心跳消息時，應將其從服務器列表中刪除。

（2）負載均衡模塊應隨時記錄每臺服務器的業務負載值。當負載均衡模塊分發任務給某臺服務器時，應該相應增加該服務器的業務負載值。當負載均衡模塊收到服務器處理完任務的通知后，應該相應減少該服務器的業務負載值[15]。任務本身可以帶權重值，這樣使得業務負載計算得更加準確。

（3）負載均衡模塊收到任務請求后，應該遍歷每一臺服務器并檢查其負載值，從中選擇一個業務負載最小的服務器執行任務。

（4）負載均衡模塊本身應具備較強的健壯性，例如可以增加崩潰后自動重啟功能等，保證該模塊7×24 h不間斷運行。

通過負載均衡模塊就可以做到服務器節點的橫向擴展。

3 對私有云計算發展的展望

私有云總是以數據處理為中心，現階段主要以提高數據處理能力和存儲能力為主，建設具有橫向擴展能力的數據庫服務器集群，并且不斷提高自動化管理能力，降低管理成本，同時注意加強數據的安全性和系統的可靠性。

近年來，隨著云計算規模不斷擴大，為了解決對海量數據進行高效處理的迫切需求，Hadoop以及一批開源的NoSQL數據庫系統異軍突起。

Hadoop 是一個能夠對大量數據進行分布式處理的軟件框架。它是以一種可靠、高效、可伸縮的方式進行處理的。Hadoop 有許多元素構成。其最底部是 Hadoop Distributed File System（HDFS），它存儲 Hadoop 集群中所有存儲節點上的文件。HDFS（對于本文）的上一層是 MapReduce 引擎。MapReduce 主要是對具有鍵值對數據特征的數據建立鍵值對映射關系并簡化映射關系，MapReduce能夠并行計算，充分利用集群內的CPU節點計算能力。MapReduce 對于網頁關鍵字索引、日志分析、結構化數據分析都非常有用[16]。

NoSQL即非關系型數據庫，云計算要求數據處理系統在海量數據存儲條件下還需要高性能的讀寫，關系型數據庫已經無法滿足這樣的需求了。例如，在擁有上億條記錄甚至數十億條記錄的數據表里進行SQL查詢，其性能之差是無法忍受的，傳統關系型數據庫是用分表分區的方法來解決大數據表的查詢讀寫問題，但是還是會出現針對整個數據表并且跨分區的統計查詢。

NoSQL就是為了解決這些問題而孕育產生的。

NoSQL的設計目標就是最大限度利用系統IO和系統內存，高性能處理海量數據。

NoSQL一般不支持事務處理，這極大提高了數據寫入的性能。

NoSQL不支持多表連接查詢，查詢只針對單表，極大提高了讀取速度。

NoSQL一般都原生支持數據存儲節點的橫向擴展。例如MongoDB的Auto Sharding功能會將數據分割、分片存儲到不同的機器上，并且這一過程在服務器內部自動完成，客戶端感覺不到這個過程[17]。

NoSQL充分利用內存做緩存，從而實現了超高性能的數據讀寫。例如Redis，它會把所有的數據全部加載到內存里。

目前，國內應用比較廣泛的NoSQL產品有：MongoDB、Redis，還有谷歌的HBase。

NoSQL的數據存儲主要分為兩種，第一種是Key-Value鍵值對，例如 Redis、Memcached等系統；第二種是面向文檔的數據庫，如MongoDB。

以MongoDB為例，保存的數據為json格式[18]，數據的增刪改很方便，但是無法做數據集合之間的關聯查詢，所以在MongoDB中建表的話，要建立很多冗余字段，這對于HIS系統有些不方便，因為HIS系統中的數據有大量的關聯特性。

目前在醫療行業，用NoSQL的還比較少，主要是因為主流成熟系統都是建立在關系數據庫之上，其次，醫療信息系統比較復雜，數據結構關聯性比較高，目前NoSQL提供的數據結構存儲過于簡單。NoSQL本身也需要進一步成熟和完善。

我們有理由相信，隨著NoSQL的不斷發展成熟，NoSQL憑借自身優良特性一定會應用到醫療信息系統私有云中。

4 結束語

本文對云計算興起的背景進行了簡單介紹，提出了大型醫院或醫院管理集團應建設自己的私有云計算中心。

結合現有HIS的實際情況，醫院私有云建設的核心應該是改造現有的信息系統，尤其是后臺數據庫系統，使數據庫服務器能做到橫向擴展，即增加較廉價的服務器節點以不斷提高整個系統的數據處理能力和數據存儲能力。

本方案首先對數據庫功能角色進行分類，不同角色的數據庫服務器通過數據復制功能廣播和分發數據，原始數據服務器將原始數據復制給熱點數據服務器，熱點數據服務器復制給歷史數據服務器。

方案中需要開發一個數據庫集群管理模塊DCMM來對數據庫服務器集群進行管理，DCMM對客戶端數據請求分類后，分發給不同角色的數據庫服務器，如果相同角色的服務器有多臺，還需要做負載均衡來分擔工作負載。

最后，本文對私有云的發展做了展望，NoSQL今后很可能會在醫院私有云中得到廣泛地應用。

本文方案所介紹的私有云實現方法，足以應對國內目前任何大型醫院的數據存儲和數據處理需求。

[1] 吳朱華.云計算核心技術剖析[M].北京:人民郵電出版社,2011.

[2] 尚可.私有云:不需新購硬件[J].軟件和信息服務,2011,(12):76-77.

[3] 網界.公有云VS私有云到底誰更安全?[J].中國數字電視,2011,(12):70-71.

[4] 雷萬云.云計算:企業信息化建設策略與實踐[M].北京:清華大學出版社,2010.

[5] 姚青嶺.區域醫療云計算服務中心模型[J].中國醫療設備,2011,(12):49-51.

[6] 劉娟.簡述三種私有數據庫云模型[J].信息安全與技術,2011,(12):50-51..

[7] Tim Mather, Subra Kumaraswamy, Shahed Latif. Cloud security and privacy: an enterprise perspective on risks and compliance中文版[M].劉戈舟,楊澤明,劉寶旭,譯.北京:機械工業出版社,2011.

[8] 李知杰,趙健飛.云計算數據中心網絡安全的實現原理[J].軟件導刊,2011,(12):35-36.

[9] 尹雪蓉,尹今揚.云計算模式的醫療信息管理平臺構想[J].中國醫療設備,2012(6):74-76,129.

[10] 曾劭清.私有云是企業架構的改變[J].中國信息化,2011,(21):66-67.

[11] 周游,劉鵬,楊盛祥,等.基于私有云的數據冗余技術研究[J].電腦知識與技術:學術交流,2011,(1):16-19.

[12] 劉字.企業私有云平臺構建技術研究[J].計算機時代,2011,(6):37-41.

[13] Brian Knight.Professional Microsoft SQL Server 2008 Administration中文版[M].騰靈靈,付勇,譯.北京:清華大學出版社,2010.

[14] 楊志豪,趙太銀,姚興苗,等.一種適應數據與計算密集型任務的私有云系統實現研究[J].計算機應用研究,2011,28(2):621-624.

[15] 李琦,朱慶華,華彥玲,等.私有云環境下的資源競價機制研究[J].情報雜志,2011,(4):10-12.

[16] 孫福權,張達偉,程勖,等.基于Hadoop企業私有云存儲平臺的構建[J].遼寧工程技術大學學報:自然科學版,2011,30(6):13-16.

[17] Kristina Chodorow, Michael Dirolf. MongoDB: the definitive guide中文版[M].程顯峰,譯.北京:人民郵電出版社,2011.

[18] 楊磊.基于NoSQL數據庫的結構化存儲設計與應用[J].科技風,2011,(18):99-100.