1、金華市中心醫院金華市中心醫院 醫院管理數據分析與決策支持系統醫院管理數據分析與決策支持系統（二期）招標需求（二期）招標需求目目 錄錄第第 1 章章項目背景項目背景.4第第 2 章章需求分析需求分析.52.1項目總體需求描述 .52.1.1需求范圍.52.1.2普遍性需求.62.1.3部門重點需求.72.1.4數據來源分析.92.2業務需求 .102.2.1總體業務架構.102.2.2實現方式.102.2.3功能性需求.112.2.4非功能性需求.15第第 3 章章項目目標及內容項目目標及內容.173.1項目目標 .173.1.1總體建設目標.173.1.2原則.193.1.3重點目標.213.

2、2項目內容 .223.2.1一期項目拓展維護.223.2.2新增指標管理.233.2.3系統管理.29第第 4 章章技術方案技術方案.314.1總體架構概覽 .314.2架構要求 .314.3邏輯運營架構 .324.4物理運營架構 .374.5移動端支持 .374.6系統備份與恢復 .38第第 5 章章工期及實施計劃工期及實施計劃.39第第 1 章章項目背景項目背景我院在 IBM 承建的 BI 一期系統上線后，對數據分析的需求越來越多，在質量控制，臨床業務分析等需求也提出了更高的要求，BI 項目對醫院后期的決策支持也越來越重要，因此，我院需要在一期項目基礎上，逐步將 BI 系統建設成為我院核心

3、的決策支持中心。項目一期在數據采集和分析方面已經打下了一定的基礎，但還不足以支撐全院的數據分析，部分新系統的投入使用，也沒有將數據整合到一期的系統中，同時，在數據分析層面，目前也比較單一，提供了報表和簡單的 OLAP 分析，沒有針對移動端的應用，不方便使用者隨時隨地地獲取必要的數據。因此，我院將投入 BI 二期建設，以便將 BI 項目更進一步，使醫院的決策分析能夠獲取實時有效的數據，從而可以進行全方位的分析，讓醫院的發展能夠借助信息化的力量穩步前進。第第 2 章章需求分析需求分析2.1 項目總體項目總體需求描述需求描述本項目將充分利用金華中心醫院現有數據源的信息和數據，建立統一的決策分析管理平

4、臺；實現對醫院總體運營按財務、門診、住院、藥品、耗材、設備、人力等不同主題，多維度進行分析；本著規范化與靈活性相結合的原則，設定不同的使用權限（組織和人員） ，靈活查詢和分析，實現對醫療服務、研究、教學全方位的整合監控，提供決策支持。.1 需求范圍需求范圍BI 數據倉庫系統的建設是一個系統工程，不能一蹴而就，應該循序漸進，借鑒業界數據倉庫建設的實踐經驗，采用“大處著眼、小處入手、快速擴展”的策略，該項目的實施將循序漸進、分期實施。從所有采集的報表及數據，借鑒行業的項目經驗，結合訪談需求，歸納出BI 的總體需求，根據業務需求，并結合一期已經實施的部分，本期核心的地項目范圍主要有以

5、下部分：OLAP 分析增加對醫院運營信息的整合和綜合查詢KPI 展現增加對院領導及各部門關注的關鍵運營指標，提供直觀可視化展現固定報表增加部分業務需要的報表，能夠匯總醫院不同的數據 儀表盤 增加對管理層所關注的關鍵指標做定制展示移動應用 增加對移動端的應用支持.2 普遍性需求普遍性需求1. 需要對數據不同粒度的分析各部門已經不滿足于匯總性的數據， “不僅知其然，還知其所以然” ，強烈地需要了解更詳細的數據，特別是在需要了解具體的業務原因時尤為強烈。例如：醫務處需要對門診掛號量細化到小時粒度。2. 需要對數據不同維度的分析目前的報表基本上是二維報表，不能提供對一個業務問題不同角度

6、的觀察，現在各部門都希望深入地了解業務，從不同的維度對業務進行交叉分析。目前在業務系統中提供維度的信息不全，如診斷。3. 報表的時效性需要提高由于許多報表的數據來源于不同部門和不同的系統，在收集來數據后還需要進行手工的整理和計算，往往過了 1-2 個月，才能到達領導手中。有的部門只能看到季報，對了解業務狀況和決策產生很大影響。4. 報表的準確性需要提高許多部門的報表數據來源于各部門，統計口徑不一致，手工處理較多，由于處理人員的技能不同或疏漏，很可能造成數據錯誤。發現錯誤后，再返工修改，又帶來時效性問題。5. 靈活方便地分析功能分管領導、衛生部、統計局和各部門等要求提供的數據往往不一樣的，而且時

7、間要求高，需要時就去提取。并且，需要分析的指標也是動態變化的，希望能提供靈活地分析手段。6. 數據共享目前有部分數據仍然分散在各個部門，數據就像在一個個孤島中，部門間獲取對方信息也很麻煩，甚至無法獲取。希望數據倉庫建成，可方便獲取分析所需的基礎數據。7. 數據質量目前數據質量還達不到要求。質量問題主要是分部門本身錄入的問題如人為理解不同、誤操作，受各因素影響等原因造成的?；A數據的正確性、真實性直接影響到分析結果的可信度。.3 部門重點需求部門重點需求部門部門業務要點業務要點分析重點分析重點項目階段項目階段院領導目前最迫切的是完善醫療服務財務運營分析門診業務分析住院業務分析病人

8、病種費用分析藥品庫存進出量分析（含血庫）科室設備使用情況分析設備報廢情況分析耗材使用情況分析（含高值耗材）人力成本分析人力效率分析財務處特需住院難區分資產負債分析收入支出分析人力成本分析醫療機構基本數字及財務分析（門診、住院、藥品、設備、耗材、人力相關財務數據）科研經費分析教學經費分析財務核算分析醫務處節假日無法標識門診量分析住院工作量分析門診住院效率分析手術情況分析病房床位分析輔助檢查工作量統計控感辦數據均需手工輸入，跨系統無法綜合性分析 院感情況分析感染費用分析手術感染情況分析耐藥性情況分析器械不良事件監控藥劑科所需數據系統中都有，難以應對臨時性統計需求藥品庫存財務分析 藥品價格變動分析藥

9、品庫存業務分析藥品使用模式分析用藥量變化因素分析設備處數據是動態變化，時點數據統計較為困難設備庫存分析設備使用狀況分析設備預算管理分析設備采購流程分析設備報廢管理分析高值耗材分析設備維修情況分析設備經濟效益分析供應科耗材成本分攤規則較難定位耗材財務分析耗材管理情況分析耗材使用排名分析基數調研分析供應商付款情況分析固定資產使用情況分析放射科與臨床數據的關聯不夠設備費用分析設備使用量分析工作效率分析護理部基礎數據無系統支持，靠手工記錄護理人員配置分析護理人員工作量分析護理人員工作質量考核物品消耗管理薪酬獎金管理教學科研管理病人相關管理人事處所有報表均為手工制作人力成本分析人員構成分析崗位設置分析績

10、效考核分析職稱評價體系分析運營處單病種費用分析住院業務質量分析全成本核算分析改革辦原始數據質量存在問題病房收入分析門診收入分析消耗相關分析手術費用分析住院日費用趨勢分析.4 數據來源分析數據來源分析根據對項目業務需求范圍的建議，結合醫院現有數據情況，一期系統本身已經對部分系統進行了數據抽取和清洗，但由于醫院業務在不斷改進，部分業務系統進行了重新建設，部分業務系統進行了改造，因此本期涉及的源系統 將涵蓋一期源系統，同時也將增加部分系統，初步統計將設計如下系統：門急診 HIS住院 HISHRP電子病歷（部分）病案首頁人事系統藥物不良反應記錄電子病歷檢驗信息系統捷達圖文報告系統手術排

11、程系統手術麻醉信息系統病理信息系統PACS/RIS內窺鏡/超聲/心電血庫預約中心2.2 業務需求業務需求.1 總體業務架構總體業務架構系統架構組成如圖所示，按照目前數據基礎狀況及業務需求的緊迫性要求分階段實現。.2 實現方式實現方式根據業務需求中提出的操作、展示等要求，目標系統需要通過以下幾種方式加以實現：1、多維分析2、固定報表3、KPI 展現4、儀表盤5、移動端OLAP 是 On-Line Analytical Process（在線分析處理）一種即時分析工具。利用 OLAP 分析，分析人員、管理人員能夠針對同一個主題，根據已經設計好的分析維度與分析內容做任意

12、組合的交叉分析，選取需要的分析維度與分析內容產生特定的分析，從多個角度對數據進行分析，從而快速、交互地得出經營管理所需的分析結論。它的技術核心是“維”的概念，因此，OLAP 也被稱為多維數據分析。OLAP 分析模塊是醫院 BI 系統的主要數據展現和分析手段，用戶通過瀏覽器，快速訪問各種可能的信息視圖，很容易地由不同的分析指標測量值，做非?？焖倥c互動的摘要整理分析，洞察數據深處蘊涵的規律，掌握隱于其中的規律。OLAP 多維分析包括分析維度和分析指標兩個重要要素。對各項分析主題進行分析時，要針對某些分析的角度或視點去進行觀察，這些分析的角度或是視點，即分析維度需要在二期實現中多方位實現，項目需要的

13、維度如下：員工維度：如年齡層、性別、職稱、學歷等時間維度：如年、季、月、日、時段等 組織維度：如總院、學科、部門、科室、病房.等藥品維度：如藥品大類、單種藥品等 項目本期大部分的多維分析主題都共享這些分析維度，在系統上線穩定運轉一段時間后，可以根據業務需要進行調整。.3 功能性需求功能性需求根據醫院數據倉庫的總體需求，結合數據倉庫分析技術能力，可以將重心醫院數據倉庫的實現分為關鍵業務指標展示和多維分析兩種方式。關鍵業務指標展示采用圖表結合的方式，主要面向管理層和決策支持人員，對業務關注的關鍵業務指標進行綜合分析，包括文字方式、占比分析、預警分析、歷史趨勢分析等。多維分析主要面向

14、決策和運行管理人員，采用面向業務主題的方式組織，方便業務人員根據實際業務要求靈活的組織分析指標、分析維度，能夠動態生成分析圖表，并可以對圖表的樣式進行調整。除了展示關鍵業務指標和多維分析以外，系統還提供全面的系統管理接口，包括，用戶管理、權限管理、用戶日志管理以及系統幫助等。 KPI 展示實現展示實現關鍵業務指標分析主要為管理層提供當前業務運行情況的總體分析和概覽，對關鍵業務指標的當前數據進行展示，并計算累計量，與計劃量進行比較、與上期量進行比較。如下圖所示，可以直接選擇關注的關鍵業務指標查看具體的數據及比較分析情況，采用圖形和表格方式進行展示。 多維分析實現多維分析實現業務主題多維分析主要面

15、向業務人員的數據分析要求而提供的一種數據分析工具，業務人員可靈活地選擇和顯示數據，支持數據的下鉆、上鉆等操作和動態變更表、圖、曲線的顯示形式。其中，業務主題是指面向業務的一組業務指標的集合，比如人員構成分析就是從編制、職級、工作性質、部門等不同維度，對醫院的人員構成，如在職員工數、平均年齡以及離職率進行多維分析；多維分析是指按照預先設定的分析角度，對指標進行分析，比如機構、時間、職稱、學歷、年齡段等。所謂數據上鉆、下鉆，是指可以在不同的層次上對數據進行查看分析，比如可以查看某個科室、在某個崗位上人員的學歷構成是怎樣的。 權限管理權限管理角色管理模塊是門戶系統的核心模塊，通過為角色分配權限和維度

16、限制了扮演這個角色的用戶所能夠涉及的系統內容和用戶動作的應用范圍，如圖. 角色權限管理示例。它有以下的幾個功能：角色信息管理、角色權限管理、新增角色和刪除角色。圖 角色權限管理示例 角色信息管理角色信息管理角色的信息管理包括，對于角色層級的管理以及對于角色的基本信息的管理，如名稱、描述、上級管理單位以及是否為管理員，如下圖： 角色權限管理角色權限管理角色的權限管理涉及到 2 個主要的方面：模塊權限管理、維度授權管理。模塊授權管理對于用戶能夠訪問的系統內容進行限制，既當用戶登陸后能訪問的模塊功能。維度的限制控制了用戶可以訪問的內容的寬度，比如地域、機構等等。為角色分配權限的過程如下圖示例：圖 用

17、戶維度管理 新增角色新增角色新增角色的過程包括，為角色設定基本信息，為角色分配相關權限，以及為角色分配維度，在新增一個角色時數據庫會將角色的基本信息、權限以及維度記錄在不同的表中，如下圖示例：圖 新增角色 刪除角色刪除角色刪除角色時，如果數據庫中存在使用這個角色的用戶，那么系統將不允許刪除操作，需要將相關用戶的角色重置為其他的角色，之后，數據庫才會先將這個角色的權限以及維度從相關表中刪除，之后才從角色表中刪除這個角色。.4 非功能性需求非功能性需求 用戶界面需求用戶界面需求方便操作，提供友好界面，特別是在移動端，要能夠及時便利地操作。 產品質量需求產品質量需求主要質量屬性主要質

18、量屬性詳細要求詳細要求正確性正確性系統能保證業務數據處理正確，并保持與其他系統的數據一致可靠性可靠性系統保證在運行期間安全可靠。對重要數據具有備份和恢復機制。對系統異常情況處理具有容錯功能。具有全套的異常情況應急處理方案和措施。性能，效率性能，效率在滿足系統運行的軟、硬件以及網絡性能要求的前提下：KPI 展示部分：查詢命令提交后結果返回平均不超過 20秒鐘。統計分析部分：不超過 120 秒。易用性易用性操作界面優化，業務處理邏輯合理安全性安全性 確保本系統不被非法入侵; 確保系統內信息通過網絡傳輸時不會被竊取和修改; 確保系統使用者的身份不被盜用，只有認證用戶才能登錄本系統; 由權限機制保證的

19、訪問控制能保證不同級用戶對不同資源的使用; 確保系統敏感數據的安全?？蓴U展性可擴展性數據庫的設計應考慮可擴充性，以適應今后業務發展的需要。系統設計中對數據采集的設計應考慮對新增數據源的支持。兼容性兼容性基于 JAVA 平臺和 J2EE 體系結構，但可以運行在各種操作系統。能適應多種機型。系統封裝性系統封裝性本系統自成體系。對外提供與其他系統聯網的接口。盡量減少對其他業務系統的依賴。可維護性可維護性在程序的開發過程中，應遵循結構化的程序設計原則，設立運行日志，加強系統的可維護性 系統安全設計需求系統安全設計需求本期系統設計必須符合行內計算機安全管理規范。保證以下安全點：主機系統安全：確保本系統不

20、被非法入侵；網絡安全：確保系統內信息通過網絡傳輸時不會被竊取和修改；用戶身份合法性：確保系統使用者的身份不被盜用，只有認證用戶才能登錄本系統；用戶權限控制：由權限機制保證的訪問控制能保證不同級用戶對不同資源的使用；關鍵數據安全：確保系統敏感數據的安全。第第 3 章章項目目標及內容項目目標及內容3.1 項目目標項目目標在完成了大量基礎業務應用系統的建設后，金華市中心醫院的業務發展戰略已從建設省內高水平的市級醫院，發展至以項目建設帶動學科發展和人才培養、以學科建設促進醫院發展；提高醫院管理效率和效益，增強醫院競爭實力；注重規劃與建設，堅持可持續發展；創新醫療模式，整合區域社區醫療，實現共同發展；最

21、終打造浙中一流醫院，因此金華市中心醫院的信息化建設也面臨著轉型和升級，才能更好地為醫院戰略提供支持。因此，根據我醫院運營管理、績效考核與業務流程優化的需求，提出了如下項目建設目標。.1 總體建設目標總體建設目標在醫院已有應用軟件基礎之上，建立面向醫院管理的數據分析和決策支持平臺則成為金華市中心醫院數字化醫院建設中不可缺少、也是亟待加強的一環，其主要目的是以計劃、組織、監測、控制、評價、預測和決策等各類管理活動中對信息的需求為出發點，通過對醫院的門診、住院流程以及物流、財務方面的運營數據等進行綜合分析，通過商業智能的技術手段從高速增長數據中獲取有價值的信息，對其進行歸納、梳理和設

22、計，開發建立一個能滿足醫院各級管理者和決策者對醫院經營、運作的監控和決策分析需求的綜合商業智能（Business Intelligence, BI）解決方案，為醫院運營管理、績效考核與業務流程優化提供數據分析和決策支持，并最終提升醫院自身的管理，提升醫院對政府與相關機構監管的合規性，加強醫院以病人為中心的服務理念，促進醫院各類病人的滿意度和管理信息的再利用。項目應用范圍：根據醫院運營管理、績效考核與業務流程優化的需求，本項目將逐步擴大其數據收集和決策支持所設計業務及職能部門的范圍，包括：門診、住院、醫技、檢查、檢驗、藥品、護理、質控、教學、科研、統計、物資、財務、后勤、病患等部門，并為其提供各

23、類動態運營監控、財務分析、績效考核、醫院信息報表、決策趨勢分析等決策支持情報?？傮w功能要求：該項目應用先進的數據倉庫、商業智能、數據分析與挖掘等信息技術，并應用成熟的項目設計及實施的方法論，將現有HIS、LIS、PACS、資產管理系統等多種業務和管理系統的數據進行數據的清洗轉換加載 (Extract，Transform，Load，ETL)、建立醫院綜合數據倉庫 (Data Warehouse，DW)、并應用聯機業務處理 (On-Line Transaction Processing，OLAP)技術提供多維數據立方體（Multi-Dimensional Cube）分析，以及采用大規模數據分析、數

24、理統計及數據挖掘等技術，以生動友好的界面形式展現數據分布特征，發現數據中的顯性或隱性的規律和知識，實現醫院對業務和管理狀態的監督、追蹤、評價、預測，為數字化醫院的科學管理和科學決策提供有價值的信息資源；軟件產品要求基于 Web 方式，不需要第三方授權，并支持 HL7/HL7 CDA、ICD-10 等相關醫學信息標準規范，能夠提供數據查詢、統計、匯總及分析等功能，并建立各種分析和決策數學模型，開展跟蹤預測，為醫院管理和決策提供可信度高的數據依據和數據分析結果。此外，作為該項目的解決方案提供商，我們將提供包括項目管理、風險控制、設計、開發、實施、維護等服務，以及相適應的基礎平臺軟件于一體化的綜合解

25、決方案，并能夠適應醫院現有環境和技術框架，提供二次定制化開發接口及知識技能轉移等服務，最終幫助醫院打造能夠提高醫院運營效率，改善治療效果和病人的滿意度的醫院管理商業智能綜合解決方案。通過前期需求調研和項目規劃，本項目將包含以下四大建設內容：(一)建立涵蓋醫院主要應用系統的數據抽取清洗整合方案，定義數據抽取及整合規則，通過定義完整、統一的數據標準，建立和完善標準的統計指標和統計口徑，促進醫院標準數據集建設，通過數據建模、數據治理、數據清洗等手段持續提高數據質量為綜合數據倉庫提供保障。(二)建立醫院綜合數據倉庫：通過數據抽取清洗整層，收集包括醫院運營管理和病人信息等方面的基礎數據，并根據運營監控、

26、績效考核、流程優化的決策支持分析需求，建立相應的企業級數據倉庫。(三)建立個性化可視化的商業智能展現層：根據各類決策支持分析需求，建立包含固定報表、多維分析、管理儀表盤和專題分析的多種商業智能展現。(四)建立面向運營監控、績效考核、流程優化的綜合商業智能分析目標體系：其中，運營監控將包含質量、效率、成本、收入等八大主題的數據分析中心：幫助醫院提高效率、質量，優化運營，精細化管理、降低成本，對醫院運營進行監測，幫助醫院最大限度地降低風險。包括數據與指標集標準化定義、流程改進、變革管理，最終改進商業智能的質量與效果。此外，本項目還將通過對項目整體架構擴展性的把控，做到不僅僅是讓用戶看到信息，事后分

27、析，還可以集成其它的統計軟件，如 SPSS，為未來實現基于預測分析和仿真的醫院運營優化決策提供數據基礎。預期效果：本項目希望通過以上四大目標的建設，實現以下金華市中心醫院管理模式的三大轉變：(一)實現醫院管理從洞察力到執行力的轉變，即通過商業發現一個問題，系統自動通知到某個負責人，有人進行修正，最終解決問題，實現完整的閉環管理，(二)實現醫院管理的持續加強和微觀管理，即通過對應用系統中的數據積累進行商業智能化，實現以下管理模式的轉變：1） 從經驗管理到數據支持下的流程管理；2） 從記錄交易數據到形成控制、分析、管理的決策支持3） 從業務數據分散不一致到集中和治理4） 從粗放手工化的管理手段到精

28、細化、微觀化、自動化的管理手段(三)幫助醫院信息部門初步實現從信息系統提供者到決策支持輔助者的轉變，稱為醫院經營決策產生的出發點和效果反饋點。.2 原則原則為滿足金華市中心醫院對數據分析和經營決策的需求，并構建一個一個可靠、標準、開放、可擴展的商業智能系統平臺，即滿足近期醫院強化管理和業務規模，也著眼于未來醫院戰略發展，同時為醫院打造性價比最優的面向醫院管理的數據分析和決策支持平臺，本項目將遵循以下的項目建設原則：(一)整體規劃：任何一個信息系統的建設都不可能是一蹴而就，商業智能系統不同于以往面向業務流程的應用系統，這樣一個面向分析的的系統，涉及到醫院從上至下方方面面的用戶，涉

29、及到流程的梳理、數據的治理、整合、平臺的搭建、軟硬件的規劃等等，更需要做一個整體的規劃， ，才能為后續的建設指明道路和打下基礎。(二)分步實施：面向管理的決策支持系統的建設是一個長期的過程，是隨著醫院信息化廣度、深度的發展以及需求的擴展，逐步建設的，需要分成多個階段來完成。因此我們要在總體規劃的指導下，將整個過程科學地劃分成多個實施階段，設立每個階段不同的里程碑，逐步完成醫院商業智能的全面建設。(三)前瞻性：醫院商業智能建設計劃將是一個分階段分重點持續完善的過程，因此在進行軟硬件規劃以及系統建設時應具有一定的前瞻性，要考慮到三四年后技術的發展水平和成熟程度。(四)先進性和超前性：緊跟國內、外先

30、進的相關軟件技術、信息技術，并結合醫院的實際情況，制定科學適用的技術方案，確保系統在較長時期內能夠滿足醫院數據分析、挖掘的需要，最大限度地保證醫院的投資回報率，避免造成不必要的浪費。(五)實用性：BI 系統的建設應以計劃、組織、監測、控制、評價、預測和決策等各類管理活動中對信息的需求為出發點，依托醫院在各項業務活動中產生的數據，對其進行梳理、歸納和整合，開發建立一個能真正滿足醫院決策者和各級管理者對醫院運營全面監控和分析的數據分析和決策支持系統。(六)可擴展性和開放性：BI 建設將一步步擴展數據分析的范圍和深度，包括面向、整合更多來源的數據，包括和其它第三方系統集成，比如企業門戶，包括跨平臺的

31、應用等等，且擴展將不影響原先的建設。系統在數據通信協議、數據標準、數據倉庫系統、數據挖掘模型導入、界面開發、接口設計等方面應采用開放性設計。(七)標準化和規范化：BI 系統的數據模型符合行業信息模型，并根據醫院的實際情況和國內外產品的優點進行必要的擴充，滿足醫院的需要，同時提供標準化的對外接口。(八)安全性和保密性：BI 系統的建設面對醫院各種數據，醫院信息系統數據的安全性和保密性必須嚴格遵循相關信息安全標準，切實保證在系統建設的各個環節均能最大限度保障信息安全。系統的設計也將重視信息的安全性和用戶的權限控制。.3 重點重點目標目標面向醫院管理的數據分析和決策支持平臺項目，其在

32、規劃、設計、實施過程中既面臨像其它行業建立商業智能系統一樣的項目重點與難點，也具有通過 BI 強化醫院管理時所面臨的獨特挑戰，具體包括：(一)醫院管理性需求的收集與歸納：在面向管理的商業智能解決方案建設過程中，很多時候業務部門不知道自己需要什么數據，提不出自己的分析目標，大都還停留在傳統的醫院管理模式中，關注門診量、住院量、手術量等表面數據，使得項目實施后與其理想化的預期存在較大差距，需要引導業務部門對需求進行思考，提出準確的數據及 BI 需求。(二)數據質量問題：醫院的基礎應用系統（如 HIS/LIS/PACS 等）是為了滿足醫院日常業務運轉的需要而設計的，因此，往往會忽略從運營管理的角度對

33、業務數據的真實與完整性提出一定的要求，也會忽略了很多面向管理決策支持時必需的原始數據；特別是針對金華市中心醫院目前已有的基礎應用較多的現狀，這些基礎應用未必能夠提供足夠細化力度、滿足各類維度模型的原始數據，因此如何通過數據治理（Data Governance）將醫院運維管控的管理模型和績效指標體系（KPIs） 與數據模型和數據質量問題的交叉分析，確立基礎應用數據的抽取規則與質量控制指標，建立涵蓋主要應用系統的數據抽取及整合規則，通過定義完整、統一的數據標準，建立和完善標準的統計指標和統計口徑，為未來豐富和完善醫院運行基礎應用提供需求和規劃就成為本項目的重點和難點。(三)如何通過項目規劃和業務場

34、景選擇，確立分階段分重點的系統建設目標：通過建立醫院商業智能解決方案可以實現從基礎應用中抽取和整合面向醫院經營決策分析的數據，并通過數據倉庫和多維分析等手段實現對這些數據的二次利用，為改善醫院的管理提供幫助，但面對醫院各級領導，如何從數據中獲得洞察力，把數據變成執行力，特別是確立那些商業智能的應用場景則稱為整體方案建設內容的關鍵點，例如針對門診的管理，如何通過對病人門診診療時間和步驟的分析，使入院登記/門急診掛號/收費的時候變得更加便捷? 又如面向科研與教學，如何利用臨床數據支持科研和教學，又如何把科研成果應用到臨床和教學，如何識別和總結最佳臨床實踐？ 如何提供預防和循癥治療? 能夠從病人的治

35、療過程學習到什么? 針對這些場景的選擇，本建設方案將在需求調研的過程中，通過場景假設和效果模擬方式與醫院各級領導細化和確立各類分析目標的明細及優先級別，最終建立確立分階段分重點的系統建設目標。(四)建立企業數據倉庫的邏輯模型和物理模型：金華市中心醫院的 BI 系統，是隨著醫院運營發展不斷完善和加強的，所以建立有擴展性的企業數據倉庫是必須的，所以，如何建立企業數據倉庫的邏輯模型和物理模型，使本次項目的重點和難點。(五)建立移動應用：金華市中心醫院的 BI 系統一期，已經完成了基礎的系統建設，但是隨著醫院運營發展不斷完善和加強，需要擴展應用得體系，在移動應用建設上要求能夠將展示與分析部分拓展到各類

36、移動載體。(六)對一期項目維護與加強：需要完全理解金華市中心醫院的 BI 系統一期的建設成果，同時能夠對一期項目進行深入維護，保障在項目正常運營的基礎上合理擴充和完善。3.2 項目內容項目內容.1 一期項目拓展維護一期項目拓展維護 醫院運營監控中心醫院運營監控中心 需要針對一期系統已經完成的業務收入、業務成本、行政運營收支等業務進行合理調整，并確保其正常運行；耗材財務與業務分析耗材財務與業務分析需要針對一期系統已經完成的耗材管理、耗材財務、耗材使用等業務進行合理調整，并確保其正常運行；藥品財務與

37、業務分析藥品財務與業務分析需要針對一期系統已經完成的藥品管理、藥品財務、藥品使用等業務進行合理調整，并確保其正常運行；領導決策支持領導決策支持需要針對一期系統已經完成的財務運營、全院收支、醫院管理損益、醫院資產負債、醫院現金流量等業務進行合理調整，并確保其正常運行；臨床運營指標分析臨床運營指標分析需要針對一期系統已經完成的臨床運營相關業務進行合理調整并擴充臨床分析，并確保其正常運行；人力資源分析人力資源分析 需要針對一期系統已經完成的人員構成、人力成本、人員配置、與醫院運營相關的人力資源資質等業務進行合理調整，

38、并確保其正常運行；科室統計分析科室統計分析需要針對一期系統已經完成的科室管理、費用、業務效率指標等業務進行合理調整，并確保其正常運行；績效管理支持績效管理支持需要針對一期系統已經完成的績效指標分析等業務進行合理調整，并確保其正常運行；.2 新增指標管理新增指標管理在本期項目中將對以下不同維度的指標進行整合并融入到系統中?？蛻艟S度 門急診病人分布（來源、身份、科室、年齡） 在院病人構成（地區、身份、科室、病種、年齡） 出院病人構成（地區、身份、科室、病種、年齡） 外地病人就診科室、病種 病人入院途徑分析門診總人次門診城鎮職工

39、基本醫療保險人次門診城鎮居民基本醫療保險人次門診新型農村合作醫療人次門診全自費人次年健康體檢人次急診總人次年急診人次年留觀人次初診、復診、出院復診專家號、普通號即日號、預約號各預約模式預約量醫保卡病人門診量退號量、退號率科室病種分析門急診處方量效率維度門急診服務人次醫生出診單元醫生出診單元平均門診量出院患者總人數出院患者城鎮職工基本醫療保險人數出院患者城鎮居民基本醫療保險人數出院患者新型農村合作醫療人數出院患者全自費人數年住院患者入院例數年住院患者出院例數住院服務人次出院患者平均住院日門診手術例數年門診手術例數總手術人次三類手術例數四類手術例數年住院手術例數各類手術平均時間住院手術手術每臺日平

40、均例數床位周轉次數平均每張床位工作日病床使用率（%）住院實際開放總床日數住院實際占用總床日數出院患者占用總床日數ICU 實際開放總床日數ICU 實際占用總床日數床位急診留觀實際開放床位數質量維度門急診不合格處方占全部處方比例（%）抗菌藥物在門診處方的比例（%）門急診使用抗菌藥物人次門急診靜脈用藥人次抗菌藥物處方數/每百張門診處方（%）注射劑處方數/每百張門診處方（%）急診科危重搶救例數急診科死亡例數電子和非電子方占比分析入出院診斷符合率（%）危重病人搶救成功率（%）出院病人治愈率（%）住院患者總死亡人數住院患者自動出院例數住院手術死亡例數住院危重搶救例數住院危重搶救死亡例數新生兒患者住院死亡率

41、出院患者使用抗菌藥物總例數出院患者使用抗菌藥物總品種數住院患者抗菌藥物使用強度（DDD）I 類切口手術抗菌藥物預防使用率（%）發生壓瘡的出院患者人次醫院內跌倒/墜床發生次數出院 31 日內再住院患者人次出院患者醫院感染發生例數住院非計劃再次手術例數手術相關醫院感染總例數惡性腫瘤手術前診斷與術后病理診斷符合例數手術冰凍與石蠟診斷符合例數術中自體輸血比例（%）ICU 中與中心靜脈置管相關血液感染例數ICU 中使用中心靜脈導管病人日數ICU 中與呼吸機相關肺部感染例數ICU 中使用呼吸機病人日數ICU 中與留置導尿管相關泌尿系統感染例數ICUICU 中使用留置導尿管病人日數中藥飲片帖均費用（膏方除外

42、）藥費收入占醫療總收入比重（%）抗菌藥物占西藥出庫總金額比重（%）常用抗菌藥物種類可與提供藥敏試驗種類比例（%）門診病種用藥分析門診毒麻藥品分析住院病種用藥分析住院毒麻藥品分析 單病種平均住院天數住院重點疾病總例數住院重點疾病死亡例數住院重點疾病、手術住院重點疾病 2 周與 1 月內再住院例數住院重點疾病平均住院日住院重點疾病平均住院費用住院重點手術總例數住院重點手術死亡例數住院重點手術術后非預期再手術例數住院重點手術平均住院日國內論文數 ISSN論文被引用次數（以中國科技核心期刊發布信息為準）SCI 收錄論文數/每百張開放床位承擔與完成國家科研課題數/每百張開放床位承擔與完成省級科研課題數/

43、每百張開放床位獲得國家科研基金額度/每百張開放床位學習科研科研成果（評審前五年）獲得省級科研基金額度/每百張開放床位醫院病房（區）總數優質護理開展優質護理病房（區）數全院員工總數衛生技術人員數醫師數護理人員數醫技人數其他維度資源配置醫院醫用建筑面積.3 系統管理系統管理重新構建分級的系統管理體系，要能夠細化到對數據的管控。權限管理權限管理1) 用戶種類a) 系統管理員b) 用戶組：總院用戶組，各分院的用戶組，各科室組的用戶組c) 個人用戶：隸屬于某個用戶組2) 用戶權限a) 系統管理員：該用戶具有所有權限，負責為每個分公司調度和運行報表等。b) 部門

44、用戶：通過即時運行報表的方式查看本部門相關報表。c) 科室用戶：通過即時運行報表的方式查看本科室相關報表。3) 歷史報表用戶應該能夠查看過去生成的報表。例如對月報表，用戶應該不僅能夠查看本月的報表，也能查看過去的月生成的報表。4) 用戶的其他權限成功登錄的用戶都可以對他所查看或生成的報表進行數據（報表）下載、數據（報表）打印。系統監控系統監控監控系統運行狀況，如：CPU 使用率、內存使用狀況、IO 吞吐量、硬盤空間狀況。該項工作是每日定點檢查，當遇到性能問題時，需要重點監測這些數據。系統備份與恢復系統備份與恢復建立完備的數據備份策略。根據

45、所需要的災難恢復的級別，制定數據備份的時間、數據備份的版本數、數據備份的存放、數據備份的時效性等。制定周密的數據恢復方案也非常關鍵。確保在發生災難后，按照事先制定好的方案，快速、準確地恢復數據。日志管理日志管理建立完善的日志管理策略，能夠方便靈活的查詢日志，并根據日志對系統進行診斷。第第 4 章章技術方案技術方案4.1 總體架構概覽總體架構概覽 做為醫院數據整合服務平臺，BI 系統整合了多個應用系統的數據源，提供了一個對醫院操作性數據的整合的視圖。目前 BI 的數據實時性要求 T+1，即當天（工作日）在 BI 系統看到的數據是前一工作日在業務系統的數據。BI 系統的

46、總體架構如下圖所示：BI 總體架構圖BI 抽取各個業務系統的數據、然后轉換、裝載進入 BI 核心數據庫的基礎層各表，再經過數據整合處理，形成了 BI 的基礎數據平臺。在此之上，BI 對數據匯總，匯總之后生成多維數據集（PowerCube） 。BI 提供了各種應用，包括報表生成、綜合查詢分析、儀表盤，這些應用分成陽光用藥分析、醫保費用分析、日常運營監控及科室目標管理等主題。4.2 架構要求架構要求BI 系統架構需求描述如下：我院面向醫院管理的商業智能整體架構包含四大層次結構，以及跨越四大層次結構的三大共享域，其中四大層次包括：數據源層數據源層：在本項目中數據源系統主要包括門診、住院HIS，LIS

47、，PACS，EMR 系統等；數據抽取轉換層數據抽取轉換層：通過 Infosphere Data Stage 軟件與CognosTransfomer 軟件負責從數據源系統抽取數據和轉換數據，并將清洗整合好的數據導入到數據存儲層，在本系統中數據整合將包括近實時性（Near Real-Time）的數據采集需求和批量數據采集需求；數據存儲層數據存儲層：包括 DB2 數據倉庫、數據集市與 Cognos 多維立方體數據集市。商業智能展現層：商業智能展現層：包括 Cognos 多維分析（Analysis Studio）、即席查詢（Query Studio 或 DB2 Client）與報表（Report St

48、udio）、平衡計分卡等集成性應用通過統一整合的分析應用環境提供對外訪問服務以及元數據應用和數據挖掘類應用。此外，整個架構中跨越三大層次的共享域（管理型模塊）將包括：元數據管理元數據管理；針對整個系統各個環節中的元數據集中存儲，統一管理，提供給最終用戶/開發者等方便查詢；安全管理：安全管理：包括系統安全，網絡安全，應用安全，用戶認證與權限管理等；系統管理系統管理：包括系統監控，數據清理、備份與恢復，日志管理，數據庫管理等；4.3 邏輯運營架構邏輯運營架構我院的系統運營架構主要用于描述系統操作和運行層面的架構，該設計面向于實現非功能性需求，包括：邏輯層次的系統節點和節點之間的連接。節點將可能是未

49、來的硬件系統配置的基本單位，當然，多個節點可以合并到一個硬件系統中，一個節點也可以分布到多一個硬件系統。同時描述每個節點和作用和配置。運營架構的作用包括：審核系統設計，確認 IT 架構設計中已經包括了業務的需求； 劃分功能節點，使得每個節點可以獨立的配置，不同節點協同完成復雜的功能； 作為性能、可用性和擴展性等非功能性需求的分析基礎，確認系統的整體實施可行性和可發展性；確定系統所需的技術、中間件模塊和集成架構；支持應用設計人員在前期從實施和管理的角度考慮應用設計；支持初步進行系統基礎平臺的投資分析；作為設備選擇、采購、安裝、配置和維護的基礎藍圖。整體運營邏輯架構請參見下圖。 邏輯運營架構邏輯節

50、點描述如下表所述：節點名稱節點名稱層次層次節點描述節點描述Web 瀏覽器節點(Web-Client)接入中心醫院用戶可通過 Web 瀏覽器訪問業務應用的工作站平臺，基于 Web 瀏覽器，客戶可瀏覽所有的報表并完成全部操作的客戶端支持。移動設備端接入支持用戶以手機， iPone，iPad 方式接入 ,實現移動 BI。Web 應用訪問服務節點應用基于報表、門戶、應用等各方面的要求，選用標準的web 應用服務器，便于提高應用的開放性和可擴展性。Web 應用服務節點節點名稱節點名稱層次層次節點描述節點描述(WEB-APP) 是實現 Web 應用的基礎，不但支持用戶訪問靜態Web 頁面，同時，還通過 W

51、eb 應用支撐架構，支持其他各種標準的Web 服務,如 J2EE、.Net 等，基于該平臺復雜的業務應用，同時，報表和查詢軟件也需要 Web 應用服務的支撐，實現其 BS 用戶訪問和管理界面。多維分析及報表應用節點 應用該節點是實現系統前端查詢、報表及多維分析功能的核心；該節點支持用戶通過 Web 瀏覽器進行報表查詢及多維分析，該節點提供方便易用的界面，以支持非技術用戶基于業務需求和業務元數據，構造出查詢語句，進行查詢；提供對查詢的計劃功能，并支持分析查詢語句；報表發送服務通過該節點，配置需要后臺自動生成的報表，調度報表生成作業；數據倉庫(DW)存儲數據倉庫是配置中央數據倉庫結構化數據倉儲的節

52、點數據庫存儲的系統節點，是數據倉庫系統中最核心的部分。保障數據倉庫應用的性能、可用性、可靠性和可擴展性很大程度上要依賴于該節點的合理配置。數據倉庫存儲將建立在關系型數據庫之上。其配置需要考慮以下要求：大數據量批量數據加載與和大數據量的訪問需求；數據加載過程中數據表持續可訪問的要求；決策支持數據集市存儲決策支持數據集市是為了滿足 醫院領導和各科室主任決策分析的需求，從數據倉庫中抽取數據重新組織和計算而產生的數據子集。該節點的配置需要考慮查詢性能、可用性、呈現能力、建立和刷新所需時間。運營分析數據集市存儲運營分析數據集市是為了滿足 醫院領導，科室主任，醫護人員和信息人員 的需求，從數據倉庫中抽取數

53、據重新組織和計算而產生的數據子集。基于第一醫院各科室的需求分類，也可以考慮進行細分，例如門診、住院、手術、醫技、物流和財務數據集市。該節點的配置需要考慮查詢性能、可用性、呈現能力、建立和刷新節點名稱節點名稱層次層次節點描述節點描述所需時間。臨床分析數據集市存儲臨床分析數據集市是為了滿足醫生和科研人員的需求，從數據倉庫中抽取數據重新組織和計算而產生的數據子集。該節點的配置需要考慮查詢性能、可用性、呈現能力、建立和刷新所需時間。數據集市 -準實時數據集市(NRDM)存儲準實時數據集市提供了準實時的數據統計和匯總。因此除了滿足集市正常的查詢和數據刷新以外，準實時的數據集市需要能夠將準實時抽取過來的數

54、據加載進入集市和刷新相應的匯總數據。ETL-DW 節點整合ETL-DW 是將數據從源系統傳送到數據倉庫（ DW）和在 DW 的各個數據層次之間進行數據處理的過程；對ETL 技術上很關鍵的要求是保證 ETL 性能能夠達到在有限時間窗口限制內完成數據加載和匯總統計，并且對源系統、網絡和數據倉庫環境的影響最小。數據模型、數據量、當前狀態、歷史數據需求都會影響ETL 的開發和實現模式；ETL-DM 節點整合ETL-DM 是將數據從源系統或數據倉庫（ DW）傳送到數據集市（DM）進行數據處理的過程。和ETL-DW 不同的是， ETL-DM 的過程不涉及到 DW 數據進行復雜的轉換和整合，而更多的是進行統

55、計，匯總，和聚合的計算過程。此外需要考慮的是如果DM 和DW 是位于一個數據庫實例的情況，對于ETL-DM 的過程更多的應當是在數據庫內部進行，避免將數據從數據庫抽出到ETL 服務器，再導入到數據庫的過程。元數據存儲和管理節點元數據該節點的目標是實現技術元數據的集中管理和同步，以及支持技術用戶對元數據應用；該節點應該能夠支持與ETL、數據建模、數據庫與報表軟件的元數據獲取，將各個系統中定義的元數據收節點名稱節點名稱層次層次節點描述節點描述集到元數據存儲中；該節點負責整個元數據的獲取和管理過程，同時支持元數據的相關應用；數據備份恢復節點 系統管理數據備份和恢復節點支持對DW，DM 以及原數據存儲

56、庫中的數據安裝備份策略進行數據備份，以保存重要的分析數據，對數據的歸檔也通過備份功能實現。在需要時，可以將數據恢復至DW 以保障系統可用性或修復數據錯誤。LDAP 目錄服務節點 應用該節點集中存儲了系統中用戶、系統、功能和業務邏輯等信息，使得應用或用戶可以以確定的方式從一個目錄系統獲取資源信息；該節點使得集中的資源管理成為可能。本項目中對目錄服務的使用包括：集中管理系統用戶、用戶口令；該部分的功能目前是由BI 工具自帶的功能組件來提供各源數據相關系統節點源系統中心醫院運營分析及決策支持（ BI）系統建設涉及的各種源系統范圍根據業務目標確定；源系統數據抽取的原則是不影響或盡可能少影響源系統生產；當多個源系統中存在邏輯定義相同數據時，以原始生成該數據的數據主系統為準。4.4 物理運營架構物理運營架構 物理運營架構物理運營架構說明如下：四臺服務器，包括一個 ETL 服務器，一個數據倉庫服務器，一個數據集市服務器和一個 HA 服務器；HA 服務器上使用不同的分區用于 ETL 服務器，數據倉庫服務器，數據集市服務器的 HA；平時各自使用服務，一旦服務器出現故障則可以托管；兩臺 PC Server 用于 BI 工具服務器，采用雙機備份，所以當一個節點失敗時，另外一個可以進行接管；若干臺移動終端，在安全架構方案下可以實施獲取