摘 要： 針對醫院信息管理系統(HIS)對輔助決策支持不足，提出以HIS為基礎建設面向主題的數據倉庫，建立基于聯機分析處理(OLAP) 的醫院決策支持系統" title="決策支持系統">決策支持系統。該系統采用數據倉庫總線架構" title="總線架構">總線架構，通過共享一致維度集成各個相對獨立的數據集市。在客戶端" title="客戶端">客戶端針對不同的用戶環境分別使用數據透視表服務和基于ADO MD的Web系統,極大地提高了系統的靈活性。
關鍵詞： OLAP； 數據倉庫； HIS； 數據總線
?
醫院信息系統HIS（Hospital Information System）在醫療系統的廣泛應用，促進了醫療信息的電子化，使醫院數據庫的信息量不斷地膨脹。而這些寶貴的醫學信息資源對醫院的管理和醫療診斷都具有極高的價值。然而，許多醫院當初設計開發HIS時的主要目的僅在于滿足日常的業務處理，并沒有考慮到對數據的分析與數據的挖掘。HIS運行幾年以后，積累了大量的數據，數據項繁雜，收集的海量數據往往被沉淀，變成了難以利用的數據檔案[1]。
基于數據倉庫的聯機分析處理OLAP（Online Analytical Processing）是使分析和管理人員能夠從多種角度對從原始數據中轉化出來的、能夠真正為用戶所理解并能真實反映企業數據特性的信息進行快速、一致、交互地存取，從而獲得對數據更深入了解的一類軟件技術[1]。通過建立面向主題的數據倉庫，使用聯機分析處理，可對醫療數據進行多方面的綜合分析，從而提高數據庫的利用水平，滿足醫院管理的需要。
1 數據倉庫與OLAP建模分析
1.1 醫院多維" title="多維">多維數據分析的體系結構
多維數據分析的體系結構分成四個部分：數據源、數據中心、Web服務器(應用服務器) 和終端客戶應用。數據源是指醫院的各種業務系統的數據,如門診、住院、醫囑等費用(HIS) ,醫院影像信息(PACS) ,檢驗檢查信息(LIS、RIS) 等數據集。數據中心是根據醫院的需求確定的分析主題的集合，由各種數據集市集成的數據倉庫。Web服務器為多維數據分析提供兩種集成和發布方式,即B/S 結構的Web 集成方式和三層結構的應用集成方式。終端客戶應用是指多維數據分析的數據展現分析工具。整個體系結構如圖1所示。
?
1.2 醫院數據倉庫的結構
醫院數據倉庫建設中存在一個關鍵的爭論就是如何規劃數據倉庫的結構。一種觀點認為應該采用“自頂向下”的整體方法，一次性地創建整個數據倉庫。這種方法不適應中國的醫療界現狀。大多數醫院并沒有配置完整的IT系統，一般建設只有HIS，部分醫院可能會有PACS和LIS，這種現狀無法一次性完成整體創建。此外，這種方式也無法適應未來的業務調整。另一種是“自底向上”的觀點，認為可將各種無關的、迥異的數據集市裝配成企業級數據倉庫。這種方法比較適合醫院目前的現狀，這也是本文所采用的方法。但為避免最終數據的不兼容，使各個獨立數據集中的數據能集成為企業級的數據倉庫，需要共享一致性的維度。因此，本文采用了數據倉庫總線結構的形式。
在數據倉庫的建設當中，要避免對構建角色和作用的混淆。在開發數據倉庫環境時，有四個相互分離的獨特構件需要考慮：操作型源系統、數據聚集環節、數據展示環節與數據存取工具[1]。數據倉庫的組成結構[2]如圖2所示。操作型源系統即HIS、PACS等系統；數據聚集環節主要是清理建立一致維度，如病人維度、醫生維度、時間維度等；數據展示環節主要是確定面向主題的數據集市，如掛號業務和處方業務等，通過一致的維度集成各個數據集市；數據存取工具主要是各種分析報表和數據挖掘" title="數據挖掘">數據挖掘，如數據透視服務、Web查詢等。
?
1.3 維度建模技術的選擇策略
維度建模是指用于數據建模的特殊規范，與之對應的是實體-關系（E-R）模型，它是經常應用于數據倉庫的一種邏輯設計技術。該技術試圖采用某種直觀的標準框架結構來表現數據，并且允許進行高性能存取。而實體-關系模型的目標在于去除各種冗余，努力達到第三范式的要求，避免各種操作異常。也正是因為這個原因，實體-關系模型不便于分析，它只適合于各種操作數據的跟蹤。維度模型的主要部件是事實表和維度表。在醫院進行多維數據分析發現，醫院的各類人員正是從醫生、病人、藥品維度等理解業務的，這種模型充分反映了用戶眼里所認可的業務。
多維模型有兩種基本架構:星型模式和雪花模式。在星型模式中，事實表整個模式的中心。事實表的字段通常由一群主鍵與一些分析匯總數值字段所組成。而這一群主鍵的值往往又依靠其四周相關的維表的主鍵值構成星型模型。從主鍵與外表鍵的依存關系來看，星型模式適用于關系型數據庫的環境中。在雪花模式中，多數經過雪花處理的表使數據展示變得復雜，而且雪花模型所提倡的維護容易性事實上也沒有什么實際意義，因為數據加載到展示環節的維度方案發生之前尚有一段很長的轉儲環節[2]。此外，因使用雪花維度而節省下來的少量磁盤空間也是無關緊要的，用2字節的編碼取代不到12 000行藥品維度表320字節的產品名稱，能夠節省不到0.3兆字節（12 000×18字節）的磁盤空間。但事實表卻有幾百兆字節之大的磁盤空間，而且隨著事實表容量的增大，節省的磁盤空間實際上可以忽略不計。星型模式示意圖如圖3所示。
?
2 多維OLAP系統的設計與實現
根據前面介紹的數據倉庫理論以及多維建模技術，本文具體規劃和設計了基于HIS的醫院多維聯機分析系統，以門診為例概述實現過程(多維OLAP系統的實現目前沒有標準的過程方法)，本文只是探討了各個實現的標準步驟。
2.1 確定業務過程
業務處理過程是在機構中進行的，一般都由源數據收集系統提供支持的自然業務活動,如HIS中的掛號、處方、醫囑等。確定業務過程的關鍵在于分解和梳理。在醫院業務流程中，比如門診，應該將掛號和處方分離為兩個相關聯的業務過程，而不是作為一個整體。這種劃分一方面使業務的流程清晰，事實表的粒度更小，從而能夠應付未來各種層次上的分析；另一方面可以減少數據的冗余量。但分離也對維度的一致性提出了嚴格要求。為了以后能進行跨業務過程的分析，如分析醫生某個月所開單據的平均費用，共享維度必須滿足一致性條件才能進行集成。處方業務細化方案如圖4所示。
?
2.2 確立多維模型
針對業務過程，要創建多維模型來反映這種業務。可依次分為三個步驟：定義業務過程的粒度、選定多維模型的維度和確定多維模型的事實表。粒度定義意味著對各事實表行實際代表的內容給出明確的說明，這是建模的基準，它反映了事實表的實際意義。開發多維模型是一個迭代過程，可能要在業務用戶需求和選定的源文件細節之間反復切磋。要從用戶角度分析如何看待業務，應該用一組在每個度量上下文中取單一值而代表了所有可能情況的豐富描述，將事實表裝扮起來，用于形成每個事實表行的數字型事實。事實的確定可以通過回答“要對什么內容進行評測”這個問題來進行，明顯屬于不同粒度的事實必須放在單獨的事實表中。本系統選擇星型模式作為多維模型的架構。
2.3 多維模型的物理實現
維度建模的最終方案成為物理設計和實現的起點。首先要確定各個維度和事實表的數據源。為保證數據集市的質量，數據進入數據集市前應進行細致而具體的數據轉換工作，數據的驗證和清理都在這個環節完成。建設數據倉庫的一大挑戰就是在構建數據倉庫之后的數據裝入工作。它一般占整個系統60%～80%的建設時間。在數據進入數據倉庫之前需要經過提取、校驗、清理、轉換和遷移這五個階段。完成數據裝入工作后，需針對數據倉庫的增長和演變做準備，確定數據倉庫維護和增長的方案。
2.4 多維模型的客戶端實現
數據展示環節是進行數據組織、存儲并向用戶、報表撰寫和其他分析型應用提供查詢操作的場所。后臺數據聚集環節是用戶接觸不到的，這樣一來，展示環節就成為業務群體眼中的數據倉庫，它是業務群體通過數據存取工具所看到和接觸的一切[1]。
在客戶端分析工具的選取上，系統依據不同使用環境而有不同的選擇。針對內部局域網環境下，安全性要求較低，而分析能力要求更強的情況，系統選用數據透視表服務和Excel工具，它具有豐富的圖形化表示；在Internet環境下，安全和保密性要求較高，系統則采用基于ADO MD的Web 應用程序作為分析工具。實踐表明，這種選擇帶來了安全性和靈活性。圖5是分析結果示意圖。
?
本文針對醫院HIS系統的現狀，嘗試一種利用數據倉庫與OLAP技術對海量數據進行分析的新方案，以解決醫院管理的輔助決策問題。系統采用數據倉庫總線架構形式，保證了系統的可行性與可擴展性；在客戶端工具選擇上則根據應用環境的劃分策略，這是一種有益嘗試。為了更好地支持輔助決策，系統應該引進數據挖掘手段，這也是本系統下一步的目標之一。
參考文獻
[1] ?張文君,胡淑濤,張磊,等.OLAP技術在醫院決策支持系統中的應用. 醫院數字化, 2005，(12).
[2] ?KIMBALL R, ROSS M著.數據倉庫工具箱.譚明金譯.北京：電子工業出版社，2003.