醫(yī)院集成平臺建設方案設計

./醫(yī)院信息系統(tǒng)集成平臺建設方案目錄1.背景52.建設目標52.1實現(xiàn)醫(yī)療信息資源整合與利用62.2實現(xiàn)醫(yī)院數(shù)據(jù)中心建設62.3提供管理決策及臨床決策支持73.設計原則7實用性和先進性8安全性和可靠性8開放性、互連性和標準化9靈活性與可擴展性9經濟性與投資保護9易管理和易操作性9整體設計和多種應用相匹配104.建設方案104.1醫(yī)院信息化建設面臨的問題和難題104.2醫(yī)院集成平臺總體框架144.3標準化數(shù)據(jù)中心16建立數(shù)據(jù)中心的意義17基礎信息庫20業(yè)務信息庫21交換信息庫21臨床文檔庫<CDR>22臨床數(shù)據(jù)中心構建方法25操作數(shù)據(jù)存儲ODS26數(shù)據(jù)倉庫28醫(yī)學知識庫294.4數(shù)據(jù)交換總線平臺324.1.1.數(shù)據(jù)交換總線技術特點354.1.2.數(shù)據(jù)交換總線功能特點364.1.3.基于數(shù)據(jù)交換服務總線的業(yè)務數(shù)據(jù)交互384.1.4.業(yè)務規(guī)則引擎444.1.5.事件驅動引擎454.1.6.集團化醫(yī)院信息交換平臺454.5公共消息服務平臺464.1.7.支持HL7引擎服務部件484.1.8.適配器服務部件514.2.Ensemble集成平臺中間件534.2.1.EnsembleHIE構成組件534.2.2.EnsembleHIE設計原則564.2.3.EnsembleHIE技術特點574.2.4.EnsembleHIE功能介紹62病人主索引〔MPI654.2.5.病人主索引功能664.3.統(tǒng)一身份認證授權平臺704.3.1.統(tǒng)一身份認證授權平臺主要功能71.單點登錄71.身份管理72.授權管理72.安全審計724.3.2.統(tǒng)一身份認證授權實現(xiàn)方法73醫(yī)院決策分析平臺744.3.3.決策支撐平臺技術架構764.3.4.決策支撐平臺數(shù)據(jù)架構774.3.5.指標加工邏輯架構784.3.6.系統(tǒng)工作內容及技術路線80.指標庫構建與管理的工作內容要求80.指標庫構建與管理的設計原則84.指標庫構建與管理的技術路線85短信服務平臺854.3.7.短信平臺架構864.3.8.短信平臺功能模塊86.通知功能86.查詢功能87.信息管理87.語音信箱咨詢功能87.醫(yī)院信息查詢功能87.投訴/舉報/建議受理功能87.自動服務功能88.導醫(yī)功能88后臺運維管理系統(tǒng)884.3.9.信息資源統(tǒng)一監(jiān)控系統(tǒng)設計原則914.3.10.信息資源統(tǒng)一監(jiān)控系統(tǒng)架構及技術實現(xiàn)924.3.11.信息資源統(tǒng)一監(jiān)控系統(tǒng)管理模型93安全保障體系944.3.12.隱私保護措施944.3.13.網絡安全保障974.3.14.數(shù)據(jù)保密性984.3.15.數(shù)據(jù)完整性994.3.16.惡意代碼防范1004.3.17.性能保障措施1014.3.18.運行環(huán)境保障措施1024.3.19.信息安全與審計保障措施1035.平臺擴展103建設背景我國醫(yī)院信息系統(tǒng)建設已經有三十年的發(fā)展歷史,早期有所謂的AllinOne的系統(tǒng),所有的應用都由一個供應商提供,服務于不同目的的應用模塊,包裝在一個軟件包中,所有的數(shù)據(jù)庫都是開放給所有的應用的,不需要接口引擎的設計。然而,醫(yī)療衛(wèi)生信息的復雜性決定了醫(yī)院信息系統(tǒng)的應用越來越復雜,醫(yī)院對信息的需求也不斷擴展,任何一個HIT廠商不可能提供醫(yī)院所需要的全線產品〔也包括國外的HIS廠商,要實現(xiàn)真正一體化的醫(yī)院信息系統(tǒng),必須引進不同廠商的信息系統(tǒng)產品。因此在同一醫(yī)院環(huán)境下,集成不同廠商的產品就成為醫(yī)院信息化建設過程中必然遇到的問題。一開始幾個廠商的產品要達到互連互通,往往是采用點對點的接口方式,因為這種方式簡單、易行且成本低,例如,將一個醫(yī)療保險的結算系統(tǒng)與醫(yī)院的住院及門診病人的費用管理系統(tǒng)集成。然而,當醫(yī)院的應用擴展到十幾個乃至幾十個應用系統(tǒng)時,問題就變得困難起來。醫(yī)院信息化能夠取得成功必須保證各個系統(tǒng)的有效集成和數(shù)據(jù)的高度共享。然而這些系統(tǒng)通常是隨著醫(yī)院的發(fā)展需求逐步建設的,它們來源于不同的廠家,基于不同的技術,缺乏統(tǒng)一的信息交換標準,這些系統(tǒng)的集成整合已經逐漸成為制約醫(yī)院數(shù)字化發(fā)展的主要障礙。而如何把這些系統(tǒng)連接實現(xiàn)各部門各專業(yè)信息共享就成了醫(yī)院信息化建設中面臨的一大難題。如果以傳統(tǒng)的方式在各系統(tǒng)之間做接口的話就將出現(xiàn)眾多的接口,這將給醫(yī)院信息系統(tǒng)的穩(wěn)定性、安全性、可靠性、效率等帶來巨大的隱患,同時以讓醫(yī)院的運行維護成本成倍增長,如果醫(yī)院要對其中一個應用系統(tǒng)進行升級或更換就必須再做眾多數(shù)據(jù)接口。隨著國家新醫(yī)改政策的實施落實,以醫(yī)院為單位的管理模式已不能滿足廣大人民群眾日益增長的醫(yī)療衛(wèi)生需求,信息共享是實現(xiàn)信息價值最大化的重要途徑之一,區(qū)域醫(yī)療信息共享是信息化發(fā)展的必然趨勢,為了實現(xiàn)醫(yī)療信息的區(qū)域化共享,同樣需要在醫(yī)院內部把不同數(shù)據(jù)資源進行集成整合。在此背景下通過醫(yī)院信息集成平臺來代替原來數(shù)量眾多的點到點數(shù)據(jù)接口,為醫(yī)院信息化建設提供標準和規(guī)范,只要各應用系統(tǒng)都支持這些標準和規(guī)范,原則上就能與應用信息平臺進行數(shù)據(jù)交換,并能同與平臺相連的應用系統(tǒng)進行數(shù)據(jù)交換。建設目標2.1實現(xiàn)醫(yī)療信息資源整合與利用為實現(xiàn)各業(yè)務系統(tǒng)信息互聯(lián)互通,如果采用推倒重建的方法,就有可能將浪費大量的資金,并引起業(yè)務震蕩。通過醫(yī)院信息平臺的建設盡量減少不必要的重復建設。醫(yī)院原有的各業(yè)務系統(tǒng)和信息系統(tǒng)通過醫(yī)院信息平臺提供的接口實現(xiàn)整合,繼承已有的數(shù)據(jù)資源和服務。通過建設醫(yī)院信息平臺,將原先分布在各業(yè)務系統(tǒng)中的信息交換整合到醫(yī)院信息平臺,實現(xiàn)醫(yī)院各個科室之間、醫(yī)院之間信息的互聯(lián)互通,最大限度地方便病人就醫(yī)、方便醫(yī)院一線醫(yī)護人員工作、方便各類管理人員分析決策。2.2實現(xiàn)醫(yī)院數(shù)據(jù)中心建設為了使醫(yī)療活動可以準確、快速地進行,醫(yī)療服務者不但要接收到清晰的醫(yī)療指令信息,還需要掌握服務對象相關各方面信息、記錄服務對象在醫(yī)療活動中的情況及結果；因此要保證數(shù)據(jù)信息的高效利用,達到一處采集多處利用；以病人為主線,將病人在醫(yī)療機構中的歷次就診時間、就診原因、針對性的醫(yī)療服務活動以及所記錄的相關信息有機地關聯(lián)起來,并對所記錄的海量信息進行科學分類和抽象描述,使之系統(tǒng)化、條理化和結構化。建設醫(yī)院數(shù)據(jù)中心,通過數(shù)據(jù)中心實現(xiàn)不同信息系統(tǒng)、組織機構間信息資源整合,實現(xiàn)業(yè)務數(shù)據(jù)實時更新,確保信息同步；滿足管理決策、臨床決策、科學研究、對外信息共享；實現(xiàn)統(tǒng)一的數(shù)據(jù)倉庫的設計及技術文檔、元數(shù)據(jù)管理等功能。建設醫(yī)院信息集成平臺需制定統(tǒng)一的信息交換標準,統(tǒng)一衛(wèi)生信息標準與數(shù)據(jù)字典。2.3提供管理決策及臨床決策支持憑借數(shù)字化醫(yī)療信息服務的先進技術作為強有力的支撐,利用更為先進的信息化手段,掌握工作的主動權,把傳統(tǒng)事后處理轉為實時監(jiān)控。建設醫(yī)院信息平臺,規(guī)劃醫(yī)療資源,實現(xiàn)診療流程再造,提高醫(yī)院運作效率,提升醫(yī)院的整體服務能力,有效解決就診"三長一短"現(xiàn)象；建立統(tǒng)一的門戶信息,為病人的全面醫(yī)療健康信息的保存、傳遞、查詢提供有效的數(shù)據(jù),對數(shù)據(jù)的快速實時查詢。通過對數(shù)據(jù)進行分析和處理,對信息進行有效利用,幫助管理者進行科學管理決策,幫助醫(yī)生進行基于循證的醫(yī)療決策和醫(yī)療計劃的制定,支持臨床應用科研的開展。設計原則目前,大部分醫(yī)院的醫(yī)療信息系統(tǒng)實現(xiàn)數(shù)據(jù)共享是采用了傳統(tǒng)點對點通信模式的方法,這樣的方式需要每兩個系統(tǒng)之間都有專用的接口,且當有新系統(tǒng)添加進來的時候,也必須要單獨為每個子系統(tǒng)開發(fā)與新系統(tǒng)相應的接口,工作量極大。這樣的專用接口也存在很大風險,容易導致系統(tǒng)崩潰,中斷醫(yī)院正常的醫(yī)療業(yè)務流程。因此,需要建設一個能與全院所有醫(yī)療信息系統(tǒng)直接溝通的數(shù)據(jù)集成平臺,以此為中介,實現(xiàn)各系統(tǒng)間的數(shù)據(jù)共享和交互。建立一個以現(xiàn)有信息系統(tǒng)和數(shù)據(jù)資源為基礎,符合標準的、高可靠的、開放式醫(yī)療衛(wèi)生信息共享平臺,實現(xiàn)區(qū)域衛(wèi)生協(xié)同和診療信息共享；在平臺上提供區(qū)域級的標準組件服務、診療知識服務,以及協(xié)同醫(yī)療、衛(wèi)生監(jiān)管和健康管理等應用服務,有效提升醫(yī)療衛(wèi)生服務水平和服務能力,支持創(chuàng)新具有區(qū)域特色的開放、實用、共享、持續(xù)的醫(yī)療衛(wèi)生服務模式。目前通常采用基于中間件模型和數(shù)據(jù)倉庫等方法來構造集成的系統(tǒng),這些技術在不同的著重點和應用上解決數(shù)據(jù)共享和為企業(yè)提供決策支持。在方案設計時遵循了以下原則：統(tǒng)一性統(tǒng)一設計原則統(tǒng)籌規(guī)劃和統(tǒng)一設計系統(tǒng)結構。應用系統(tǒng)建設結構、數(shù)據(jù)模型結構、數(shù)據(jù)存儲結構以及系統(tǒng)擴展規(guī)劃等內容,均需從全局出發(fā)、從長遠的角度考慮。實用性和先進性當今的計算機技術日新月異,因此要求選擇的方法、技術、工具、設備不僅要保證具有先進性,而且要保證技術方向的正確性。設計的方案要結合考慮實用和兼顧今后發(fā)展的目的,不論在服務器、軟件及中間件等軟硬件產品方面,還是在方法論、工具方面,都應選擇當今國際上成熟的、主流的并領先的產品和技術來適應更高的數(shù)據(jù)處理要求,以滿足醫(yī)療管理信息系統(tǒng)未來5-10年的需求發(fā)展,并應具有良好的擴展?jié)摿?以適應未來業(yè)務的發(fā)展和技術升級的需要。安全性和可靠性設計的整體方案要通過多種安全技術和防護手段,保證系統(tǒng)自身的安全性,保證服務不會中斷。在本項目方案中,最重要的設計出發(fā)點就是系統(tǒng)的安全,關鍵設備或設備核心部件應當采取冗余設計,能夠避免單點故障導致系統(tǒng)整體或重要功能的喪失,保證系統(tǒng)平穩(wěn)運行,最大限度減少停機時間而且包括便于故障排查、恢復和日常的運行維護的機制。在采用硬件備份、冗余、負載均衡等可靠性技術的基礎上,采用相關的軟件技術提供較強的管理機制和控制手段,以提高整個系統(tǒng)和數(shù)據(jù)的安全可靠性。開放性、互連性和標準化系統(tǒng)必須采用國際、國家標準、協(xié)議和接口,能與現(xiàn)有的和未來的系統(tǒng)互連與集成,支持HL7、IHE、DICOM、ICD10等標準。靈活性與可擴展性設計的方案應當考慮系統(tǒng)的靈活性和可擴展性。系統(tǒng)建成后要能夠滿足業(yè)務近期、中期甚至長期時間范圍數(shù)據(jù)和業(yè)務快速增長的需要。適應目前需求的基礎上,能夠滿足醫(yī)院以及相關醫(yī)療機構不斷發(fā)展的信息化需要,充分地為將來可預見和不可預見的性能擴充留有余地,并具備方便地擴展系統(tǒng)容量和處理能力和支持多種應用的能力,可以根據(jù)業(yè)務發(fā)展的需要進行靈活、快速的調整,實現(xiàn)信息應用的快速部署,而且新功能、新業(yè)務的增加能夠在不影響系統(tǒng)運行的情況下實現(xiàn)。系統(tǒng)要充分考慮到擴容和升級的需要,能靈活方便地適應未來系統(tǒng)可能的變化。選擇應用開放性標準的產品,確保設備的兼容性；通過系統(tǒng)結構的合理設計和適度資源冗余,為未來的系統(tǒng)擴充打下基礎,保證需求增加時系統(tǒng)的平滑擴充,保證前期的投資。經濟性與投資保護方案所選用的技術和產品應當全部遵循通用的國際或行業(yè)標準,各系統(tǒng)模塊之間有良好的兼容性和較高的性能價格比。從長遠來看,也便于系統(tǒng)的升級和移植或運行其他應用軟件,實現(xiàn)整體效益,而且能以較低的成本、較少的人員投入來維護系統(tǒng)運轉,提供高效能與高效益的醫(yī)療信息服務。易管理和易操作性設計方案支持全面、完善、便捷、統(tǒng)一的系統(tǒng)管理和應急處理預案,保證一旦發(fā)生問題能在最短的時間內處理解決。而且,系統(tǒng)應具有良好的用戶操作界面、完備的幫助信息。集成完備的運行監(jiān)視系統(tǒng)、良好的管理界面工具或遠程控制臺,易于管理人員對其進行管理和維護,系統(tǒng)參數(shù)的維護與管理通過操作界面實現(xiàn)。整體設計和多種應用相匹配集成平臺需要進行統(tǒng)一設計,但是考慮到應用的多樣性以及業(yè)務、部門等的差異,整體設計又不要過于制約具體的應用開發(fā),要為各種應用開發(fā)提供靈活的手段?？删S護、可管理性通過統(tǒng)一網管,對信息系統(tǒng)平臺進行統(tǒng)一管理,提供可視化的網絡拓撲、網絡狀態(tài)監(jiān)控、故障事件實時預警和告警、異常網絡流量統(tǒng)計等。建設方案4.1醫(yī)院信息化建設面臨的問題和難題難題1:系統(tǒng)集成度較低醫(yī)院信息工作以采集到的數(shù)據(jù)范圍與數(shù)量為主要工作目標,而這些數(shù)據(jù)采集后的共享與深度利用往往被忽略。目前,很多的醫(yī)院都建設有獨立的PACS、LIS、手術麻醉等系,這些系統(tǒng)很多是科室根據(jù)自身業(yè)務需要,由科室主導建立起來的。這些系統(tǒng)在建立時并未考慮與醫(yī)院信息系統(tǒng)的集成,或者當時醫(yī)院信息系統(tǒng)并不具備集成應用的條件,所以就成為孤立的系統(tǒng)。由于信息沒有利用好,往往使醫(yī)院無法看到信息化工作的真正回報,醫(yī)院信息化工作就無沒得到醫(yī)院領導者們足夠的重視。對于信息化工作來說,信息的采集基本上是投入性的工作,而信息的有效、及時利用才是信息化工作的收益。難題2：規(guī)范化、標準化程度低我國醫(yī)院信息化建設的過程中,采用的標準、規(guī)范很少,信息的共享與交換主要以"點對點"的方式進行,這種方式個性化極強,往往會因為系統(tǒng)升級、更換廠商而帶來嚴重后果。傳統(tǒng)點對點模式基于傳統(tǒng)"點對點"直連數(shù)據(jù)接口方式來集成系統(tǒng),如果另一個應用程序系統(tǒng)A〔第n+1個必須集成進來,將需要產生、文檔化、測試和維護2n個新的接口。而更糟的是,必須修改每個已有的應用程序中的代碼以包括進新的接口,因而將增加大量的成本和復雜度。:點對點集成方式存在以下問題：接口不規(guī)范接口間的調用方式各不相同,如有存儲過程、視圖、中間表、應用程序、動態(tài)庫等等,無法形成統(tǒng)一的接口規(guī)范。數(shù)據(jù)不共享雖然現(xiàn)在大多數(shù)系統(tǒng)間均有做接口進行數(shù)據(jù)交互,但往往只做到最基礎的數(shù)據(jù)采集上,信息間的共享并不充分,如急診、危重病人的報告、異常的報告無法做到第一時間提醒醫(yī)生。醫(yī)生也無法主動查詢病人的報告進行到哪一步。數(shù)據(jù)不一致由于數(shù)據(jù)共享不充分,導致多數(shù)接口在重復做,往往會出現(xiàn)數(shù)據(jù)在不同系統(tǒng)間不一致的情況,如同樣的檢驗報告,在LIS系統(tǒng)下看到的格式有可能與HIS看到的不一樣,甚至連數(shù)據(jù)都有可能不同,這就給醫(yī)生帶來不小的困擾。數(shù)據(jù)入口多由于點對點的接口方式,數(shù)據(jù)重復存在于各個系統(tǒng)中,無法形成統(tǒng)一的數(shù)據(jù)中心模式,造成同一數(shù)據(jù)多個采集入口。接口安全性差很顯然在不同供應商之間開放數(shù)據(jù)庫用戶進行連接視圖或讀寫中間表,這種接口方式的安全性較低,一旦出現(xiàn)數(shù)據(jù)異常責任往往無法追蹤。接口耦合度高點對點集成方式導致接口耦合度高,不利于后期的擴展及維護。各系統(tǒng)界面、用戶分散,無統(tǒng)一管理機制用戶必須來回切換登錄不同系統(tǒng)用戶必須記住不同系統(tǒng)的不同用戶及密碼系統(tǒng)維護成本高4.2醫(yī)院集成平臺總體框架醫(yī)院集成平臺總體架構圖如上圖所示,本平臺中醫(yī)院信息平臺信息交換層,主要用于實現(xiàn)全院級應用系統(tǒng)互聯(lián)互通的需求,主要任務以滿足臨床信息、醫(yī)療服務信息和醫(yī)院管理信息的共享和協(xié)同應用為目,標采集相關業(yè)務數(shù)據(jù),并對外部系統(tǒng)提供數(shù)據(jù)交換服務；提供支持HL7標準的消息傳輸機制,建立服務之間的通信、連接、組合和集成的服務動態(tài)松耦合機制,為集成遺留系統(tǒng)和新建基于SOA的應用系統(tǒng)的服務集成提供了支撐。并在此基礎上,開發(fā)面向應用的業(yè)務適配器組件,實現(xiàn)各集成應用之間可管理的接口透明,為醫(yī)療應用提供了便捷、一致、安全并符合標準的豐富接口,保證服務之間信息的可靠傳送,實現(xiàn)不同操作系統(tǒng),不同數(shù)據(jù)庫、中間件運行平臺及其基于這些平臺之上開發(fā)的應用軟件的服務集成。信息資源層是對于各個業(yè)務系統(tǒng)產生的醫(yī)療業(yè)務信息、臨床信息、醫(yī)院管理信息,通過業(yè)務信息庫進行整合,主要服務于建立全院級的病人主索引的需求、建立全院級電子病歷的需求,并為醫(yī)院信息二次利用、為患者提供公眾服務、與外部互聯(lián)奠定數(shù)據(jù)基礎；支持結構化數(shù)據(jù)存儲,以XML格式提供結果數(shù)據(jù),便于相關系統(tǒng)進行二次處理〔如科研或質控。4.3標準化數(shù)據(jù)中心依據(jù)衛(wèi)生部2011年8月2日發(fā)布的《城鄉(xiāng)居民健康檔案基本數(shù)據(jù)集》,該標準于2012年2月1日起正式實施。該標準規(guī)定了城鄉(xiāng)居民健康檔案基本數(shù)據(jù)集的數(shù)據(jù)集元數(shù)據(jù)屬性和數(shù)據(jù)元目錄。數(shù)據(jù)元目錄包括城鄉(xiāng)居民健康檔案個人基本信息、健康體檢信息、重點人群健康管理記錄和其他醫(yī)療衛(wèi)生服務記錄的相關數(shù)據(jù)元。適用于城鄉(xiāng)居民健康檔案的信息收集、存儲與共享,以及城鄉(xiāng)居民健康檔案管理信息系統(tǒng)建設。標準中規(guī)定了衛(wèi)生信息中標識類數(shù)據(jù)元的數(shù)據(jù)元標識符、數(shù)據(jù)元名稱、定義、數(shù)據(jù)元值的數(shù)據(jù)類型、表示格式和數(shù)據(jù)元允許值內容。數(shù)據(jù)元目錄包括標識信息相關數(shù)據(jù)元。按此標準建設的數(shù)據(jù)集內容涵蓋了人員、醫(yī)療機構、醫(yī)療衛(wèi)生術語、電子健康檔案的數(shù)據(jù)集、數(shù)據(jù)元和各種代碼標準的注冊管理,數(shù)據(jù)標準化則提供了在數(shù)據(jù)注冊過程中基于標準化轉換服務,其囊括了區(qū)域衛(wèi)生業(yè)務數(shù)據(jù)的所有數(shù)據(jù)標準規(guī)范,根據(jù)應用領域分為數(shù)據(jù)類標準、技術類標準、管理類標準和業(yè)務類標準,并通過數(shù)據(jù)校驗機制保障數(shù)據(jù)中心的數(shù)據(jù)進行標準化。標準數(shù)據(jù)完全匹配國家對全程健康檔案服務和注冊服務的要求。數(shù)據(jù)注冊涵蓋了人員、醫(yī)療機構、醫(yī)療衛(wèi)生術語、電子健康檔案的數(shù)據(jù)集、數(shù)據(jù)元和各種代碼標準的注冊管理,數(shù)據(jù)標準化提供了在數(shù)據(jù)注冊過程中基于標準化轉換服務,其囊括了區(qū)域衛(wèi)生業(yè)務數(shù)據(jù)的所有數(shù)據(jù)標準規(guī)范,根據(jù)應用領域分為數(shù)據(jù)類標準、技術類標準、管理類標準和業(yè)務類標準,并通過數(shù)據(jù)校驗機制保障數(shù)據(jù)中心的數(shù)據(jù)進行標準化。依據(jù)標準建設的中心數(shù)據(jù)庫數(shù)據(jù)集內容包括：基本數(shù)據(jù)字典：科室字典、員工字典、用戶字典等；患者注冊基本信息；門診業(yè)務數(shù)據(jù)結果集：掛號記錄、診斷記錄、處方記錄、結算記錄等；住院業(yè)務數(shù)據(jù)結果集：住院記錄、診斷記錄、醫(yī)囑記錄、結算記錄等；健康體檢數(shù)據(jù)結果集：體檢登記記錄、診斷記錄、體格檢查記錄、評估報告、費用記錄等；電子病歷結構化數(shù)據(jù)集；決策分析數(shù)據(jù)集；醫(yī)院管理指標數(shù)據(jù)集；上述部分結構主要是結果集的采集存儲,為了滿足不同平臺之間或系統(tǒng)之間數(shù)據(jù)交互,涉及的業(yè)務相關數(shù)據(jù)集：住院患者信息相關表：如在院患者記錄表、出入轉記錄表；臨床路徑相關表；單據(jù)記錄及狀態(tài)相關表：單據(jù)表、單據(jù)狀態(tài)事件表等；電子申請單記錄表及醫(yī)技預約反饋記錄表；檢驗、檢查報告記錄表；系統(tǒng)間消息交互數(shù)據(jù)集；建立數(shù)據(jù)中心的意義數(shù)據(jù)中心是醫(yī)院的業(yè)務系統(tǒng)與數(shù)據(jù)資源進行集中、集成、共享、分析的場地、工具、流程等的有機組合。它將不同業(yè)務系統(tǒng)之間需要共享的信息、綜合業(yè)務系統(tǒng)與區(qū)域共享需要的業(yè)務數(shù)據(jù),按行業(yè)標準轉換明文方式長期存貯在一個數(shù)據(jù)倉庫中。當前醫(yī)院各業(yè)務系統(tǒng)面臨的最大問題：系統(tǒng)業(yè)務無統(tǒng)一數(shù)據(jù)標準數(shù)據(jù)標準是指衛(wèi)生信息采集表的處理過程中涉及到的標準,主要是指數(shù)據(jù)采集里的標準,定義各類數(shù)據(jù)標志的含義,規(guī)范數(shù)據(jù)采集的數(shù)據(jù)集能在不同系統(tǒng)之間傳遞的電子報文或者是電子文檔。由于醫(yī)院各業(yè)務系統(tǒng)產生的數(shù)據(jù)需要長期保存,但建立在這些業(yè)務數(shù)據(jù)基礎之上的各種字典,由于醫(yī)改的需要在不斷地變化,系統(tǒng)中各類字典也不斷膨脹,為減少業(yè)務數(shù)據(jù)錯誤與系統(tǒng)維護工作,很多系統(tǒng)設計者只能將明文保存的基礎業(yè)務數(shù)據(jù)表,造成業(yè)務系統(tǒng)運行效率低下,維護困難。數(shù)據(jù)中心的建立,就是要將原各系統(tǒng)不能共享的孤島信息,轉換成符合國家或衛(wèi)生部相關標準的數(shù)據(jù)集。為全院系統(tǒng)打造一個共享平臺,統(tǒng)一字典維護,降低業(yè)務系統(tǒng)標準字典維護量,為區(qū)域共享提供可進行信息統(tǒng)計與挖掘的標準數(shù)據(jù)集。涉及到醫(yī)院系統(tǒng)的主要標準有：疾病代碼、科室分類、藥典、非藥品記費項目。業(yè)務系統(tǒng)數(shù)據(jù)接口由于醫(yī)院業(yè)務管理系統(tǒng),是一個長期運行,不斷完善的情況下壯大成長起來的,醫(yī)療信息技術標準沒有慣徹到整個業(yè)務中。由此造成上線系統(tǒng)越來越多,各系統(tǒng)之間數(shù)據(jù)的調用頻繁,數(shù)據(jù)接口也就越來越多,越來越復雜。經常出現(xiàn)某個業(yè)務系統(tǒng)升級無法到相關信息,或因某業(yè)務系統(tǒng)升級造成其它業(yè)務系統(tǒng)數(shù)據(jù)混亂的現(xiàn)象。醫(yī)院業(yè)務需求擴張各業(yè)務系統(tǒng)隨著用戶應用不斷深入產生新的業(yè)務需求：如質控、CA認證、閉環(huán)醫(yī)囑等。這些應用必須建立在多個系統(tǒng)之上,若將這些應用需求不斷加入到基礎業(yè)務系統(tǒng)中,勢必造成基礎業(yè)務系統(tǒng)數(shù)據(jù)量不斷膨脹,造成基礎業(yè)務系統(tǒng)的可維護性與運行效率越來越差。病人信息綜合處理目前醫(yī)院的系統(tǒng)是按功能進行劃分的,如：HIS系統(tǒng)保存病人費用與醫(yī)囑內容、LIS保存病人檢驗數(shù)據(jù)、PACS保存病人影像信息等。醫(yī)生對病人的診斷往往來源于醫(yī)院各業(yè)務系統(tǒng),對其數(shù)據(jù)進行綜合的結果。將這些來源不同系統(tǒng)并標準不統(tǒng)一信息,整合在一個界面中進行綜合處理,存在巨大的障礙與分析效率低下的問題。將基本業(yè)務產生的數(shù)據(jù),對其進行質量控制、清洗、轉換保存到綜合醫(yī)療業(yè)務數(shù)據(jù)倉庫,長期海量保存。使基本業(yè)務與綜合醫(yī)療業(yè)務的運行建立不同數(shù)據(jù)倉庫中,實現(xiàn)分布式并行運行,有效地解決了高效、穩(wěn)定的前臺業(yè)務與多變的綜合展示業(yè)務之間運行效率的矛盾,極大地提高了基礎業(yè)務系統(tǒng)的維護性與穩(wěn)定性。共享基礎信息庫基礎信息庫集中了整個醫(yī)院信息平臺的基礎信息和共享數(shù)據(jù),是為各個子系統(tǒng)提供基礎信息服務的?；A信息庫包括了患者的人口學信息、醫(yī)療衛(wèi)生人員的注冊信息、以及各種醫(yī)療衛(wèi)生、公共衛(wèi)生術語字典數(shù)據(jù)及流程模板數(shù)據(jù)等。病人基本信息是基礎信息數(shù)據(jù)庫中的核心內容之一。無論是電子病歷、醫(yī)療業(yè)務、臨床信息,還是疾病分析信息和公共衛(wèi)生條線數(shù)據(jù)都是以病人基本信息為基礎的。在此基礎上,實現(xiàn)電子病歷、醫(yī)療業(yè)務〔含臨床數(shù)據(jù)的關聯(lián)。醫(yī)護人員庫是基礎信息數(shù)據(jù)庫中的另一個核心內容,以醫(yī)護人員信息為基礎?？梢越⑨t(yī)院診療資源注冊庫,可以作為醫(yī)院管理以及績效考核的基礎。數(shù)據(jù)元字典是輔助各類醫(yī)院業(yè)務、臨床業(yè)務的基本數(shù)據(jù)元、代碼集以及數(shù)據(jù)字典；以及包含了醫(yī)院各種業(yè)務、流程說明模版的操作模型。流程模版庫是包含了醫(yī)療機構醫(yī)療業(yè)務、臨床路徑、管理流程、財務結算等所有信息系統(tǒng)正常運轉、分布協(xié)同的規(guī)則庫。通過流程模版庫的流程引擎指導,能夠明確患者在醫(yī)療機構內如何進行就醫(yī),臨床醫(yī)生如何對患者進行準確診斷,防保醫(yī)生如何對疾病進行控制和分析,管理及后勤人員如何對醫(yī)療資源進行合理分配或者補充采購、財務結算人員如何統(tǒng)計和控制醫(yī)院的收入和開支。流程模版庫是醫(yī)療機構保證正常運轉的核心,對各級醫(yī)療衛(wèi)生人員和患者的醫(yī)療行為起著規(guī)范和指導作用。原始業(yè)務信息庫業(yè)務信息庫是整個醫(yī)院信息平臺的數(shù)據(jù)基礎,主要存儲原始業(yè)務產生的數(shù)據(jù),以未經過進一步加工的數(shù)據(jù)為主。包括診療業(yè)務流程產生的結果數(shù)據(jù)、醫(yī)療服務管理數(shù)據(jù)以及醫(yī)院運營管理流程產生的結果數(shù)據(jù)。這些未經修改的數(shù)據(jù),作為電子病歷的備份存儲,在以后發(fā)生任何疑問時,可調閱業(yè)務信息庫中的數(shù)據(jù)進行核實。業(yè)務信息庫中的數(shù)據(jù)要求在存儲后不能被修改和刪除,將作為系統(tǒng)的原始憑證被永久保留。從時效性和實際業(yè)務需求出發(fā),業(yè)務信息庫至少也要保存50年之內在線業(yè)務操作及結果數(shù)據(jù)。醫(yī)療機構內部的業(yè)務數(shù)據(jù)分布于不同的信息系統(tǒng)自身的數(shù)據(jù)庫之中,因此需要接入到覆蓋整個醫(yī)療機構的信息平臺上,以提供對原有業(yè)務數(shù)據(jù)的整合、利用服務,并為機構之間以及業(yè)務系統(tǒng)之間的聯(lián)動提供支持。業(yè)務系統(tǒng)通過設置交換信息庫作為與信息平臺的接入端代理,來實現(xiàn)業(yè)務系統(tǒng)與信息平臺的互聯(lián)互通性。體現(xiàn)在數(shù)據(jù)結構層面,就是業(yè)務信息庫通過交換信息庫實現(xiàn)數(shù)據(jù)的接入。除了在信息平臺上保存即時產生的,符合臨床診療要求的各種業(yè)務原始數(shù)據(jù)以外,還需要以患者的基本信息為基礎,整合患者歷次就診的就診履歷,完善患者的醫(yī)院電子病歷?；颊叩幕拘畔⒈４嬖诨A信息庫中,電子病歷保存在臨床文檔信息庫中,也就是說,業(yè)務信息庫根據(jù)基礎信息庫中的患者信息進行整合,并最終形成存儲在臨床文檔信息庫中的電子病歷。交換信息庫交換信息庫是信息平臺的數(shù)據(jù)轉換樞紐,包括中心交換庫和對外交換庫。中心交換庫的作用主要是對醫(yī)療機構內部信息系統(tǒng)業(yè)務數(shù)據(jù)的采集、整合以及醫(yī)療機構內部信息系統(tǒng)之間業(yè)務聯(lián)動。對外交換庫的作用主要是實現(xiàn)醫(yī)院信息平臺與區(qū)域信息平臺的數(shù)據(jù)交互。中心交換庫考慮到醫(yī)療機構各個信息系統(tǒng)相對的獨立性以及數(shù)據(jù)之間的關聯(lián)性,我們在醫(yī)院信息平臺中設立中心信息交換數(shù)據(jù)庫。中心交換庫是采集醫(yī)院各個業(yè)務信息系統(tǒng)的信息,并整合程電子病歷信息的區(qū)域,也是各個業(yè)務信息系統(tǒng)基礎信息和專業(yè)信息交換的信息存儲區(qū)域。中心交換庫存放各個信息系統(tǒng)交互的信息,包括了電子病歷信息、基礎信息〔患者基本信息、醫(yī)療人員信息等、專業(yè)信息〔醫(yī)療業(yè)務、臨床數(shù)據(jù)、檢驗檢查報告以及影像數(shù)據(jù)等。對外交換庫對外信息交換庫是醫(yī)院信息系統(tǒng)與區(qū)域衛(wèi)生信息平臺進行數(shù)據(jù)交換的信息存儲區(qū)域。為保證系統(tǒng)的相對獨立,我們設立對外信息交換數(shù)據(jù)庫。對外交換庫存儲要推送到區(qū)域衛(wèi)生信息平臺的電子病歷,同時也存儲著從區(qū)域平臺推送來的健康檔案。在對外交換庫中完成電子病歷與健康檔案的相互轉換。臨床文檔庫<CDR>電子病歷存儲服務具體由臨床數(shù)據(jù)存儲庫CDR<ClinicalDataRepository>來實現(xiàn)。電子病歷主要由臨床文檔組成,臨床文檔是電子病歷中各類業(yè)務活動記錄的基本形式。臨床文檔中的數(shù)據(jù)存在著一定的層級結構關系,其中有包含與被包含的關系,也有按同類屬性相互嵌套的關系。臨床文檔的結構化和標準化,是電子病歷實現(xiàn)語義層數(shù)據(jù)交換與共享的基本要求。CDR是醫(yī)院為支持臨床診療和全部醫(yī)、教、研活動而以病人為中心重新構建的新的一層數(shù)據(jù)存儲結構。它應該是物理存在的,而不僅僅是概念存在或者是邏輯存在。它是醫(yī)院基于電子病歷的信息平臺的核心構件。它是否存在可以作為醫(yī)院是否擁有真正電子病歷系統(tǒng)的標志。它與直接支持醫(yī)療操作的前臺業(yè)務信息庫不同,其數(shù)據(jù)來自這些業(yè)務系統(tǒng),但與前臺業(yè)務流程無關。它也不是通常意義上的數(shù)據(jù)倉庫,因為它的內容是隨著醫(yī)院業(yè)務活動動態(tài)變化的,并且直接支持醫(yī)生/護士對病人臨床記錄的實時應用。CDR獨立存在主要用于實現(xiàn)：1、與復雜的業(yè)務處理流程分割病人的臨床信息來自醫(yī)院現(xiàn)已存在的多種多樣的應用系統(tǒng)。一般說來,它們是面向應用過程設計的,是由不同供應商提供的,具有不同的信息模型和軟硬件平臺,其功能必須滿足管理與臨床應用不同的過程要求,例如一個實驗室系統(tǒng)。從醫(yī)生開出醫(yī)囑,到條碼打印和取得樣本,樣本傳送與接受,上化驗設備,化驗過程的雙向控制,化驗結果的自動獲取,報告的產出與確認,報告的發(fā)出與接受確實是十分復雜的。應用系統(tǒng)的數(shù)據(jù)結構設計必須滿足這些要求,數(shù)據(jù)庫內的化驗結果表達必然是復雜多變的。而電子病歷僅僅關心化驗報告的最終結果。因此,如果CDR僅僅保存從檢驗系統(tǒng)傳遞來的化驗結果,那么電子病歷系統(tǒng)就可以和復雜的業(yè)務處理流程相分割。如果電子病歷系統(tǒng)中的化驗結果要從檢驗系統(tǒng)中直接獲取,就不得不關注上述的所有細節(jié)。2、透明、一致化的數(shù)據(jù)模型CDR的獨立存在使得一個統(tǒng)一的、透明的、一致化的電子病歷信息模型的設計與實現(xiàn)成為可能。這樣一個模型的存在對所有應用系統(tǒng)的開發(fā)商、對系統(tǒng)集成、對醫(yī)生護士對病人信息的進一步應用都十分重要。3、應用系統(tǒng)升級容易由于CDR和復雜的業(yè)務處理流程相分割,使得以后各應用系統(tǒng)〔POS的升級換代變得簡單易行。而這種變化隨著業(yè)務流程的變化和信息化水平的提高,是經常發(fā)生的,也是醫(yī)院信息化發(fā)展進程中最讓人頭痛的問題。4、對醫(yī)生/護士更友善,效率更高醫(yī)生/護士使用物理上保存的以病人為中心的電子病歷記錄比起使用分散在不同應用系統(tǒng)中的病人記錄來更得心應手、更符合他們的思維習慣,應答速度會更快。特別是簡單、統(tǒng)一、透明的信息模型的存在使得他們有可能根據(jù)自己臨床工作的需要從CDR中剪裁出自己的病人臨床記錄子集。5、有利于電子病歷深層次應用的開發(fā)推廣電子病歷的存在不僅僅是要滿足臨床信息查詢的需要,更重要的是要滿足臨床決策、教學、科研的深層次的要求,例如警告與提示系統(tǒng)、臨床路徑控制、循證醫(yī)學支持等等。這些應用的開發(fā),當面對一個數(shù)據(jù)相對穩(wěn)定、信息模型簡單清晰、與操作過程無關的存儲庫時,要簡單得多。特別的,當服務點應用系統(tǒng)<PointofService,PoS>發(fā)生變化時,也不會影響這些深層次的應用。臨床數(shù)據(jù)中心構建方法廣義的電子病歷覆蓋了患者過去、現(xiàn)在、未來所有的醫(yī)療健康相關的數(shù)據(jù),這些數(shù)據(jù)的生成和利用涉及到了整個醫(yī)療過程的各個環(huán)節(jié)。即使在一個醫(yī)療機構內部,電子病歷也是往往建立在各類臨床信息系統(tǒng)充分發(fā)展的基礎之上,臨床信息系統(tǒng)構成了電子病歷的信息源。顯然,一個共享的電子病歷邏輯信息模型對于構建臨床數(shù)據(jù)中心以及最終實現(xiàn)共享的電子病歷來說都具有十分重大的意義。目前,我國大多數(shù)醫(yī)療機構都已經在不同程度上實現(xiàn)了信息化,建成了各種不同規(guī)模的臨床信息系統(tǒng)。在這種情況下,不改變各個已有系統(tǒng)的底層信息模型,采用僅在邏輯上集中的方案構建臨床數(shù)據(jù)中心比較具有現(xiàn)實意義。按照這種方案,各種類型的電子病歷數(shù)據(jù)仍由相應的臨床信息系統(tǒng)負責管理和維護,保持原有的物理分布特性；在此之上,采用一定的技術手段將這些分散存儲的數(shù)據(jù)在邏輯上集中起來,為上層的各種電子病歷應用提供統(tǒng)一的數(shù)據(jù)訪問接口,使得在這些上層系統(tǒng)看來,它們所面對的就是一個集中式的臨床數(shù)據(jù)中心。為了實現(xiàn)對這些多模態(tài)電子病歷數(shù)據(jù)的邏輯上的集中,通常有兩種技術方案：基于面向服務架構〔SOA和基于集中索引。SOA是一種將應用程序的不同功能單元〔稱為服務通過定義一些接口和契約聯(lián)系起來的軟件系統(tǒng)架構,數(shù)據(jù)訪問服務是SOA架構中最常見、使用最廣泛的服務。基于SOA構建邏輯集中的臨床數(shù)據(jù)中心就是指面向各個異構臨的床信息系統(tǒng)開發(fā)一系列的數(shù)據(jù)訪問服務,上層應用通過這些服務訪問電子病歷數(shù)據(jù)。在這種技術方案中,所有對于服務接口的調用都會涉及到訪問一個或多個臨床信息系統(tǒng)數(shù)據(jù)庫,整體效率比較低。集中索引是指在各個臨床信息系統(tǒng)之上,根據(jù)上層應用的需求,為那些經常被訪問到的電子病歷數(shù)據(jù)建立一個集中的索引,基于索引實現(xiàn)對電子病歷數(shù)據(jù)的訪問。在這種技術方案中,由于大部分的數(shù)據(jù)訪問操作不需要直接連接具體的臨床信息系統(tǒng)數(shù)據(jù)庫,提高了數(shù)據(jù)訪問效率。但是,為了確保醫(yī)護人員能夠隨時獲取到患者最新的電子病歷數(shù)據(jù),索引必需與原始數(shù)據(jù)保持同步更新。采用這種邏輯集中的方案時,由于原始數(shù)據(jù)仍存在于各自臨床信息系統(tǒng)的服務器中,同樣的數(shù)據(jù)可能同時在不同系統(tǒng)中存在多個備份,因此,如何確保數(shù)據(jù)的一致性、以及在出現(xiàn)數(shù)據(jù)不一致時系統(tǒng)的容錯能力是在開發(fā)服務和建立索引過程中需要關注的問題。相對于基于共享信息模型的技術方案而言,邏輯集中的方式可以保持已經建立的各個臨床信息系統(tǒng)不變,或僅需要為了支持數(shù)據(jù)交換開發(fā)少量的基于標準的消息通訊接口,是一個比較適合我國當前階段醫(yī)院信息化需求的構建臨床數(shù)據(jù)中心的方法。ODS〔操作數(shù)據(jù)存儲CDR存儲庫的組織形式以患者電子病歷為核心展開,其存儲結構方式更多的以個人基本索引模式組織展開,以結果數(shù)據(jù)為主體,這樣的組織形式在以個人視角所見的電子病歷中能夠完整迅速的定位,但對縱向條線業(yè)務的支持卻明顯缺乏有力的索引組織,不能完全滿足業(yè)務的需求。所以很多業(yè)務數(shù)據(jù)并不都在CDR存儲庫中存儲,為了完成某些特定業(yè)務上的流程要求,可能產生很多中間數(shù)據(jù),而這些中間數(shù)據(jù)都有賴ODS數(shù)據(jù)庫實現(xiàn)其存儲方式。ODS數(shù)據(jù)庫主要涵蓋臨床和管理數(shù)據(jù),對數(shù)據(jù)即席查詢、數(shù)據(jù)倉庫、面向患者的公眾信息服務以及區(qū)域衛(wèi)生提供數(shù)據(jù)層支持。同時,ODS數(shù)據(jù)庫支持整個醫(yī)院范圍內各業(yè)務系統(tǒng)的協(xié)同,可以與CDR結合作為院內臨床及其他業(yè)務驅動的數(shù)據(jù),為醫(yī)院內平臺級別的應用〔非POS應用,如統(tǒng)一調閱等提供信息支撐。ODS數(shù)據(jù)庫主要是作為CDR存儲庫外的業(yè)務需求的補充。除了電子病歷外,醫(yī)院信息平臺還需要支持一些其他業(yè)務,比如說婦幼保健等具體醫(yī)療業(yè)務。這些業(yè)務所需的一些信息可以從電子病歷中抽取,但是同時另一部分信息可能和健康信息毫無關系只是為業(yè)務統(tǒng)計分析時使用,他們也有一定的業(yè)務流程,ODS就成為此類數(shù)據(jù)的存放場所。ODS數(shù)據(jù)庫還包含對這些業(yè)務數(shù)據(jù)的匯總、展現(xiàn)、統(tǒng)計查詢等功能的支持,他不僅僅是一個單純的存儲服務,他可以依賴LRS實現(xiàn)共享和使用CDR存儲庫中已經存儲信息的展示。ODS、數(shù)據(jù)倉庫和業(yè)務信息庫的區(qū)別在于：業(yè)務信息庫一般針對實時性非常強的事務性操作和這些操作所對應的業(yè)務數(shù)據(jù)。其特點是數(shù)據(jù)實時性很強,但數(shù)據(jù)規(guī)模不大。數(shù)據(jù)倉庫一般針對很大規(guī)模的數(shù)據(jù)量。但是其數(shù)據(jù)為歷史數(shù)據(jù),時效性不強。ODS則介于二者之間。ODS數(shù)據(jù)來源于在線業(yè)務系統(tǒng)的實時映像。映像數(shù)據(jù)保存周期為數(shù)據(jù)集市或數(shù)據(jù)倉庫的裝載周期。利用ODS系統(tǒng),我們即可以允許歷史數(shù)據(jù)在保存周期中進行更新,又可以隨時對現(xiàn)有監(jiān)測數(shù)據(jù)進行分析,滿足應急性分析需求。數(shù)據(jù)從業(yè)務庫抽取出來裝載到ODS后,從ODS系統(tǒng)中進行數(shù)據(jù)清洗和轉換從而完成在建立數(shù)據(jù)倉庫/數(shù)據(jù)集市之前的數(shù)據(jù)準備工作。為了不影響業(yè)務數(shù)據(jù)庫的性能,一般ODS的數(shù)據(jù)庫結構和業(yè)務數(shù)據(jù)庫是完全一致的,這樣數(shù)據(jù)可以高效的從業(yè)務數(shù)據(jù)庫中抽取出來。ODS和數(shù)據(jù)倉庫的數(shù)據(jù)庫結構則往往區(qū)別較大。ODS的數(shù)據(jù)需要進行數(shù)據(jù)轉換方可進入數(shù)據(jù)倉庫。數(shù)據(jù)倉庫數(shù)據(jù)倉庫是在臨床數(shù)據(jù)、醫(yī)院管理類數(shù)據(jù)以及財務類數(shù)據(jù)采集的基礎上對各類數(shù)據(jù)進行歸類整合并加以利用。按其數(shù)據(jù)的性質大致可分為三類：衛(wèi)生資源信息、臨床診療信息、衛(wèi)生業(yè)務信息。其中衛(wèi)生資源信息可作為衛(wèi)生資源分布的基礎數(shù)據(jù)；臨床診療中與費用相關的信息可作為衛(wèi)生資源消耗的基礎數(shù)據(jù)；臨床診療中的疾病數(shù)據(jù)和衛(wèi)生業(yè)務信息可作為衛(wèi)生資源需求的基礎數(shù)據(jù),醫(yī)院的管理與決策可利用這些數(shù)據(jù)所產生的信息為相關的衛(wèi)生決策進行支撐。為快速的展示各種業(yè)務統(tǒng)計分析的報表及結果,必須首先對不同來源的數(shù)據(jù)按照主題的方式來進行組織和處理,按照業(yè)務統(tǒng)計分析的需求搭建數(shù)據(jù)倉庫,實現(xiàn)對數(shù)據(jù)的多維管理。數(shù)據(jù)倉庫包括相應的事實表和維度表,基于上述業(yè)務統(tǒng)計分析的要求,可采用多個面向不同主題的事實表共享維度表的"星型"數(shù)據(jù)倉庫模型。數(shù)據(jù)倉庫的建立,有利于后期對數(shù)據(jù)的高效應用。ODS庫是醫(yī)院醫(yī)療信息原始業(yè)務數(shù)據(jù)庫的鏡像庫,定時與醫(yī)療信息業(yè)務數(shù)據(jù)庫進行同步,為后面的數(shù)據(jù)轉換、數(shù)據(jù)倉庫建立提供穩(wěn)定、可靠的數(shù)據(jù)源。ODS庫的設置,緩解了ETL過程中頻繁訪問生產數(shù)據(jù)服務器產生的大批量數(shù)據(jù)交換對醫(yī)院信息平臺及網絡造成的壓力,并最大限度降低數(shù)據(jù)數(shù)據(jù)倉庫對原有業(yè)務系統(tǒng)的影響。數(shù)據(jù)倉庫是數(shù)據(jù)整合匯總中心,以業(yè)務需求為基礎創(chuàng)建ODS庫數(shù)據(jù)的抽取整理規(guī)范及流程,抽象出滿足業(yè)務分析主題的度量和維度,區(qū)分事實表與維度表,按照"星型模型"、"雪花模型"的方式建立事實表與維度表之間的關聯(lián)關系,將原有的二維數(shù)據(jù)表轉換成以分析主題為中心的多維表。數(shù)據(jù)倉庫的建立,可以有效地管理業(yè)務數(shù)據(jù),為數(shù)據(jù)展示、挖掘利用奠定基礎。數(shù)據(jù)倉庫的數(shù)據(jù)主要供管理決策分析之用,所涉及的數(shù)據(jù)操作主要是數(shù)據(jù)查詢,一般情況下并不進行修改操作。數(shù)據(jù)倉庫的數(shù)據(jù)反映的是一段相當長的時間內歷史數(shù)據(jù)的內容,是不同時點的數(shù)據(jù)庫快照的集合,以及基于這些快照進行統(tǒng)計、綜合和重組的導出數(shù)據(jù),而不是聯(lián)機處理的數(shù)據(jù)。因為數(shù)據(jù)倉庫只進行數(shù)據(jù)查詢操作,所以數(shù)據(jù)倉庫管理系統(tǒng)相比數(shù)據(jù)庫管理系統(tǒng)而言要簡單得多。數(shù)據(jù)庫管理系統(tǒng)中許多技術難點,如完整性保護、并發(fā)控制等等,在數(shù)據(jù)倉庫的管理中幾乎可以省去。但是由于數(shù)據(jù)倉庫的查詢數(shù)據(jù)量往往很大,所以就對數(shù)據(jù)查詢提出了更高的要求,它要求采用各種復雜的索引技術；同時由于數(shù)據(jù)倉庫面向的是高層管理者,他們會對數(shù)據(jù)查詢的界面友好性和數(shù)據(jù)展示提出更高的要求。醫(yī)學知識庫醫(yī)學知識庫用來存放各種規(guī)劃、專家的經驗、有關知識和因果關系等,主要包括事實庫、規(guī)則庫和約束庫三部分。事實庫存放求解問題的說明性知識、構成信息實體的事實等；規(guī)則庫中的主要內容是特定領域構規(guī)則、定理、定律等過程性知識及說明模型庫中各個模型的使用范圍、方法及關系的規(guī)則信息。約束庫主要是說明知識的使用范圍和使用條件。知識庫管理系統(tǒng)的主要功能是在決策過程中,通過人機交互作用,使系統(tǒng)能夠模擬決策者的思維方法和思維過程,發(fā)揮專家的經驗、推測和判斷,從而使問題得到一個滿意而又具有一定可信度的解答,同時可以根據(jù)知識庫的知識和經驗生成建議以支持決策。由此可見,醫(yī)學知識庫是臨床決策支持系統(tǒng)中的另一個重要元素。知識庫應包含詞庫、術語字典、模型結構、知識倉庫四個部分。疾病數(shù)據(jù)庫疾病數(shù)據(jù)庫是一種將疾病按病種或術種進行分類,使數(shù)據(jù)標準化,存放在計算機數(shù)據(jù)庫中,以備研究使用的數(shù)據(jù)管理與分析系統(tǒng)。包括：疾病名、英文名、縮寫、別名、ICD疾病代碼、概述、流行病學、病因、發(fā)病機制、臨床表現(xiàn)、并發(fā)癥、實驗室檢查、其他輔助檢查、診斷、鑒別診斷、治療、預防、預后及循證醫(yī)學證據(jù)等項目。通過疾病分析統(tǒng)計數(shù)據(jù)庫,可以將科室多年積累的病例全部存入計算機,根據(jù)需要隨時調出,計算統(tǒng)計結果。只有利用數(shù)據(jù)庫技術,通過科學分類,歸納疾病知識體系,建立系統(tǒng)化?？萍膊〗y(tǒng)計數(shù)據(jù)庫,才能獲取高質、完整研究資源,進而取得廣泛研究成果。藥品數(shù)據(jù)庫提供藥品信息,包括藥名、英文名、別名、劑型、藥理作用、藥動學、適應證、禁忌證、注意事項、不良反應、用法用量、藥物相互作用、專家點評等項目。藥品相互作用審查提示兩種藥物給一個患者時可能出現(xiàn)的藥理學效應,這些相互作用可能導致毒性增強、藥效降低等,使藥物的實際使用效果發(fā)生改變,或導致不良反應。藥物過敏預警主要對藥品的禁忌癥、副作用、老年人用藥、兒童用藥、妊娠期、特殊藥物劑量的審查和預警。合理用藥監(jiān)控提供藥師在藥品調配時對患者處方或醫(yī)囑進行合理用藥自動和人工審查功能,將發(fā)現(xiàn)的問題進行記錄并反饋給責任醫(yī)師的功能。用藥研究用藥研究模塊是提供給醫(yī)生研究藥品資料的入口,在該模塊中醫(yī)生可以查詢和組合審查藥品知識庫中全部幾萬種藥品,也可將當前下達的用藥醫(yī)囑導入用藥研究中與另外的藥品組合測試,在用藥研究平臺中所有信息都不會被保存,也不會影響醫(yī)生工作站正常的醫(yī)囑。輔助檢查數(shù)據(jù)庫提供各類檢查項目信息,每一種檢查項目涉及名稱、縮寫、正常值、臨床意義等內容。循證醫(yī)學數(shù)據(jù)庫主要包括：臨床實踐指南、系統(tǒng)評價和臨床科學研究,其中臨床科學研究包括：隨機對照試驗、對照臨床試驗、非隨機對照臨床試驗、病例對照研究、隊列研究、病例報告、病例分析及橫斷面研究等研究證據(jù)。以統(tǒng)一的數(shù)據(jù)規(guī)范存儲成全文數(shù)據(jù)庫。循證醫(yī)學數(shù)據(jù)庫的建立,有利于提高醫(yī)療質量和臨床科研水平。實施循證醫(yī)學將會不斷淘汰現(xiàn)行無效的醫(yī)學干預措施,防止新無效的措施進入醫(yī)學實踐,從而不斷提高醫(yī)療衛(wèi)生服務質量和效率,充分利用有限醫(yī)學資源。通過對醫(yī)學信息的挖掘、整理,進行知識的重新組織,實現(xiàn)從信息服務向知識服務轉變。醫(yī)學資料參照庫提供具有代表性權威臨床研究論文、醫(yī)學期刊和臨床醫(yī)學學會的全文文獻。提供各科權威臨床醫(yī)學教科書全文。針對特定主題做導覽式查詢,并提供相關圖書、期刊文獻、藥物信息、臨床指引、衛(wèi)教信息等參考列表。臨床輔助診斷主要提供輔助診斷治療,根據(jù)病人的癥狀,通過分析決策引擎,推斷出患者的疾病,并提供合適的治療方案,供醫(yī)生參考。在醫(yī)生確診并開出處方或處置以后,對疾病、處方以及處置進行分析,與知識庫中的規(guī)則進行比對,確認處方、處置的安全可靠性,如果有異常,則發(fā)出警報,對醫(yī)生提醒,從而提升醫(yī)療服務質量,減少或避免醫(yī)療事故的發(fā)生。4.4數(shù)據(jù)交換層醫(yī)院集成平臺核心是數(shù)據(jù)交換總線,這解決當前大部分醫(yī)院最關注的電子病歷與移動醫(yī)療等業(yè)務系統(tǒng)接口交互共享及消息數(shù)據(jù)狀態(tài)同步〔消息一體化機制等問題。集成平臺主要包括業(yè)務數(shù)據(jù)集并提供相應的標準處理接口API〔含數(shù)據(jù)采集與數(shù)據(jù)發(fā)布查詢更新,同時提供相應的適配器服務來處理不同供應商系統(tǒng)與集成平臺標準接口的數(shù)據(jù)交互。通過數(shù)據(jù)交換平臺,使整個臨床業(yè)務活動能基于醫(yī)院集成平臺更為充分的實現(xiàn)信息的共享與交換。實現(xiàn)各項臨床業(yè)務活動在信息使用層面上最大程度的業(yè)務協(xié)同。使實際臨床業(yè)務工作在充分的信息利用條件下實現(xiàn)提高業(yè)務效率、減少臨床差錯、降低業(yè)務成本、提高臨床服務滿意度。通過開放平臺提供的標準化接口,幫助第三方供應商通過運用和組裝平臺接口及第三方服務接口產生新應用,允許第三方實現(xiàn)擴展應用功能,同時提供統(tǒng)一便捷的接入方式保證新應用基于平臺環(huán)境的統(tǒng)一管理和運行。ESB〔EnterpriseServiceBus,企業(yè)服務總線是傳統(tǒng)中間件技術與XML、Web服務等技術結合的產物。ESB提供了網絡中最基本的連接中樞,是構筑企業(yè)神經系統(tǒng)的必要元素。企業(yè)服務總線ESB就是一種可以提供可靠的、有保證的消息技術的最新方法。ESB中間件產品利用的是Web服務標準和與公認的可靠消息協(xié)議接口。ESB產品的共有特性包括:連接異構的MOM、利用Web服務描述語言接口封裝MOM協(xié)議,以及在MOM傳輸層上傳送簡單對象應用協(xié)議<SOAP>傳輸流的能力。大多數(shù)ESB產品支持在分布式應用之間通過中間層如集成代理實現(xiàn)直接對等溝通。ESB采用了"總線"這樣一種模式來管理和簡化應用之間的集成拓撲結構,以廣為接受的開放標準為基礎來支持應用之間在消息、事件和服務的級別上動態(tài)的互連互通。ESB是一種在松散耦合的服務和應用之間標準的集成方式。它可以作用于：面向服務的架構－分布式的應用由可重用的服務組成面向消息的架構－應用之間通過ESB發(fā)送和接受消息事件驅動的架構－應用之間異步地產生和接收消息應用集成管理服務用于對各種基本服務和應用程序進行統(tǒng)一的管理與監(jiān)控。通過開放平臺提供的標準化接口,幫助第三方開發(fā)者通過運用和組裝平臺接口及第三方服務接口產生新的應用,允許第三方實現(xiàn)擴展應用功能,同時提供統(tǒng)一、便捷的接入方式保證新應用基于平臺環(huán)境的統(tǒng)一管理和運行。應用集成管理服務通過開放的合作方式,利用共享資源相互交換形成平臺提供商及應用開發(fā)商的共贏,是實現(xiàn)平臺應用豐富多元的重要基礎,促進了平臺產業(yè)健康發(fā)展的良性循環(huán)。主要功能與特點：開放式基礎工作環(huán)境,通過可持續(xù)運營模式最大限度保護現(xiàn)有投資;提供實時預警方式確保平臺應用不間斷運行；支持電腦、手機、平板等多種終端設備,滿足服務提供方式的靈活性；通過集成統(tǒng)一視圖技術確保第三方應用的無縫快速集成；提供標準的開發(fā)支撐組件,有效支撐第三方應用供應商參與到醫(yī)療平臺應用開發(fā)與持續(xù)性建設。數(shù)據(jù)交換層總線技術特點醫(yī)院集成平臺的數(shù)據(jù)交換服務總線具有以下技術特點：SOA支持方面,遵循SOA設計原則和技術標準,能夠構建標準的企業(yè)服務總線平臺,提供松耦合模式,將業(yè)務邏輯和應用邏輯、數(shù)據(jù)邏輯等分離開,提供一個滿足企業(yè)的應用集成和信息調解需求的解決方案；Web服務支持方面,支持最新WebServices標準,包括SOAP1.1/1.2、WSDL1.1、MTOM/XOP、WS-IBasicProfile1.1等,支持WebServices自有的安全性WS-Security和尋址功能WS-Addressing,可以實現(xiàn)WebServices同步和異步不同形式的調用；智能路由方面,靈活的消息路由方式,支持基于消息內容的處理和路由；而且還可以執(zhí)行一系列方式的消息交互,包括了過濾、充實、監(jiān)視、分發(fā)、關聯(lián)、拆分〔一對多和合成〔多對一等；XML格式轉換方面,標準XML數(shù)據(jù)的格式轉換,并且可以通過圖形化映射組件、XSLT、等多種方式實現(xiàn)轉換功能；非XML格式轉換方面,非標準XML數(shù)據(jù)的格式轉換,實現(xiàn)XML消息格式和其他數(shù)據(jù)格式之間的映射,同時也要支持自定義數(shù)據(jù)格式；發(fā)布/訂閱方面,提供發(fā)布/訂閱功能,支持隊列和主題兩種訂閱模式,主題訂閱模式支持樹狀結構,即支持多級主題模式,支持主題模糊的匹配方式,同時支持跨越多節(jié)點的發(fā)布訂閱能力；圖形化開發(fā)工具方面,提供圖形化界面開發(fā)工具,實現(xiàn)簡單和復雜的數(shù)據(jù)流程設計,提供圖形化界面的數(shù)據(jù)映射和拖拽方式,以及配置功能的開發(fā)。提供多種內置功能組件和節(jié)點,功能涵蓋協(xié)議接入、路由、轉換、監(jiān)控、例外處理等,同時要支持自定義的處理節(jié)點,提供多種編程語言的實現(xiàn)接口；通訊協(xié)議支持方面,提供可靠的數(shù)據(jù)或消息傳輸,確保消息傳輸?shù)淖詈喕B接方式,支持靈活和開放的協(xié)議支持,包括HTTP/HTTPS、JMS、FTP/File、Socket、SMTP、SOAP/HTTP等；數(shù)據(jù)庫支持方面,實現(xiàn)與關系數(shù)據(jù)庫實現(xiàn)無縫的集成,同時支持JDBC和ODBC兩種數(shù)據(jù)庫連接方式,支持數(shù)據(jù)庫要涵蓋主流數(shù)據(jù)庫；在數(shù)據(jù)交換和流轉的過程中,支持業(yè)務邏輯中對不同數(shù)據(jù)庫的存儲操作,支持對不同數(shù)據(jù)庫實現(xiàn)不同的用戶和密碼支持。管理方面,提供圖形化性能監(jiān)控工具,支持統(tǒng)計和分析的功能；性能方面,具備高性能處理能力,尤其對于XML數(shù)據(jù)的校驗和解析、XSLT解析、非XML報文的處理、路由和過濾、數(shù)據(jù)庫操作、WebServices調用等都要滿足高性能要求,提供動態(tài)的緩存機制,保證數(shù)據(jù)能夠在內存中最快速的處理；可用性方面,提供高可用性,保證平臺7*24小時的運行；提供高穩(wěn)定性,保證在數(shù)據(jù)量或應用連接數(shù)高峰運行時的系統(tǒng)運行正常,保障持久化系統(tǒng)運行；安全性方面,提供多種安全機制,用戶級別的認證、授權,支持標準的LDAP服務器；訪問級別的SSL傳輸機制；數(shù)據(jù)內容級別的數(shù)字簽名等機制。數(shù)據(jù)交換總線功能特點醫(yī)院集成平臺的數(shù)據(jù)交換服務總線具有以下功能特點：數(shù)據(jù)匯總支持各個分支數(shù)據(jù)源匯總數(shù)據(jù)到數(shù)據(jù)中心。采集公共數(shù)據(jù)的過程可以看成是一個數(shù)據(jù)匯總的過程,通過信息共享交換平臺將各業(yè)務部門的公共數(shù)據(jù)采集回來,匯集到數(shù)據(jù)中心的緩存數(shù)據(jù)庫。經過數(shù)據(jù)管理系統(tǒng)的比對、校驗、轉換得到一致的數(shù)據(jù)。數(shù)據(jù)分發(fā)數(shù)據(jù)分發(fā)是從數(shù)據(jù)中心的角度,主動向各數(shù)據(jù)使用方提供數(shù)據(jù)的過程。通過公開數(shù)據(jù)服務,依照數(shù)據(jù)使用權限的規(guī)則,從數(shù)據(jù)中心把數(shù)據(jù)分發(fā)到各個數(shù)據(jù)使用部門,實現(xiàn)數(shù)據(jù)共享、信息聯(lián)動。數(shù)據(jù)存取訪問信息共享交換平臺提供實時按需的數(shù)據(jù)存取訪問服務,通過統(tǒng)一標準的數(shù)據(jù)接口,以XML作為標準數(shù)據(jù)格式,通過標準的Web服務對各種技術平臺提供訪問支持。優(yōu)化業(yè)務流程實現(xiàn)利用現(xiàn)有的軟件系統(tǒng),通過集成平臺產品,重新組織醫(yī)院的業(yè)務流程和工作流,配置業(yè)務規(guī)則,包括可能跨躍不同的軟件系統(tǒng)的業(yè)務流程整合。各個系統(tǒng)與平臺的平滑連接、各個子系統(tǒng)之間數(shù)據(jù)平滑流轉、各個系統(tǒng)工作站功能整合〔病人主索引、分布式資源索引、綜合統(tǒng)計報表編輯和發(fā)布平臺、數(shù)據(jù)倉庫和數(shù)據(jù)挖掘的、內部網絡查詢和管理綜合門戶、基于所有系統(tǒng)的人員及部門權限管理、安全管理等,業(yè)務流程定制提高了系統(tǒng)的靈活性和適應性,確保了整個業(yè)務系統(tǒng)能夠很快的適應實際業(yè)務流程的變化,為醫(yī)院未來業(yè)務發(fā)展提供支撐。數(shù)據(jù)轉換數(shù)據(jù)交換服務可以把某個數(shù)據(jù)庫的數(shù)據(jù)轉換成標準XML數(shù)據(jù)集。通過數(shù)據(jù)轉換模塊,實現(xiàn)對各種異構數(shù)據(jù)轉換到統(tǒng)一標準規(guī)范、具有一致性和完整性的公共數(shù)據(jù)。任務定制數(shù)據(jù)接口系統(tǒng)應該允許用戶自己配置和管理相關的服務,如：數(shù)據(jù)提取服務、數(shù)據(jù)發(fā)送服務、數(shù)據(jù)接收服務、數(shù)據(jù)存儲服務等。支持用戶自定義數(shù)據(jù)接口系統(tǒng)應該是一個開放的系統(tǒng),要提供一些可擴充的接口以及二次開發(fā)接口,支持用戶基于這些接口來定義自己的特色服務。支持業(yè)務行為監(jiān)控能實時掌控整體業(yè)務運行。能夠對關鍵的業(yè)務行為以及相關的事件做出實時反應,以及自動反饋并執(zhí)行分支業(yè)務流程。支持平臺監(jiān)控管理對數(shù)據(jù)服務進行監(jiān)控管理,用戶權限管理,運行日志查看,性能統(tǒng)計。通過數(shù)據(jù)服務日志可以記錄、跟蹤數(shù)據(jù)交換的細節(jié)。對數(shù)據(jù)交換節(jié)點進行管理,提供安全策略指南、服務器安全管理配置?；跀?shù)據(jù)交換服務總線的業(yè)務數(shù)據(jù)交互應用集成管理服務用于對各種基本服務和應用程序進行統(tǒng)一的管理與監(jiān)控。通過開放平臺提供的標準化接口,幫助第三方開發(fā)者通過運用和組裝平臺接口及第三方服務接口產生新的應用,允許第三方實現(xiàn)擴展應用功能,同時提供統(tǒng)一、便捷的接入方式保證新應用基于平臺環(huán)境的統(tǒng)一管理和運行。應用集成管理服務通過開放的合作方式,利用共享資源相互交換形成平臺提供商及應用開發(fā)商的共贏,是實現(xiàn)平臺應用豐富多元的重要基礎,促進了平臺產業(yè)健康發(fā)展的良性循環(huán)。通過統(tǒng)一的業(yè)務交換服務平臺標準,可以實現(xiàn)以下業(yè)務數(shù)據(jù)交互：支持集團化醫(yī)院業(yè)務,解決各成員醫(yī)院間的遠程數(shù)據(jù)交換,主要包括病人檔案信息共享、病人診療信息共享、跨院檢驗檢查、藥品、易耗品等物資一體化功能。HIS與檢驗系統(tǒng)信息交互,通過業(yè)務服務平臺獲取檢驗單據(jù)信息、患者住院信息、病歷信息,記錄完整的檢驗單據(jù)處理過程,標本送檢過程處理與單據(jù)費用自動處理,檢驗報告結構化存儲,實現(xiàn)多系統(tǒng)統(tǒng)一的報告調閱接口；HIS與醫(yī)技檢查系統(tǒng)信息交互,放射檢查、病理檢查、心電、B超、內鏡檢查業(yè)務通過業(yè)務服務平臺獲取檢查單據(jù)信息、患者住院信息、病歷信息,記錄完整的檢驗單據(jù)處理過程,檢查圖文報告結構化存儲,實現(xiàn)多系統(tǒng)統(tǒng)一的報告調閱接口；并支持統(tǒng)一影像瀏覽及處理。HIS與電子病歷系統(tǒng)信息一體化,完善以電子病歷為中心的臨床信息系統(tǒng),提供電子病歷分級評價標準實現(xiàn)。臨床路徑信息查詢,可通過數(shù)據(jù)交換服務總線,實現(xiàn)路徑表單、知情通知書、路徑評估單等信息查詢。建立多途徑的消息機制,實現(xiàn)各系統(tǒng)間關鍵醫(yī)療信息自動提醒〔如急診異常報告、預警功能；字典同步：同步各系統(tǒng)間的基礎字典〔如科室、員工字典,消滅重復數(shù)據(jù)。與區(qū)域市民健康檔案標準化無縫對接,實現(xiàn)區(qū)域市民健康一卡通、雙向轉診、遠程醫(yī)療、檢查檢驗結果互認、預約診療、區(qū)域衛(wèi)生健康門戶等區(qū)域衛(wèi)生信息共享與協(xié)同服務應用；跨醫(yī)院信息交換平臺伴隨著醫(yī)院集團的出現(xiàn),醫(yī)院信息系統(tǒng)的集團化成為新時期的醫(yī)院信息系統(tǒng)建設的重要方向,為了使龐大而又分散的經營體系內部的各類機構能步調一致,有效地運轉,集團總部及各成員醫(yī)院都需建立相應的信息系統(tǒng),并用遠程通訊網絡將整個集團構成一個有機的整體,大型的醫(yī)院集團如果沒有一個健壯的電腦化集團信息系統(tǒng),就難以實施有效的管理,也就難以獲得經營的效益。集團化醫(yī)院較之單體醫(yī)院的最大特征在于資源在一定程度上實現(xiàn)了共享,但目前大部分的集團化仍未達到充分的資源共享,比如：集團下屬各家醫(yī)院一般都有獨立使用自己的LIS系統(tǒng),LIS數(shù)據(jù)僅存在本醫(yī)院內部,當病人跨院就診時,往往需要重新檢驗,造成大量的人力、財力的浪費。因此,集團化醫(yī)院信息系統(tǒng)的一個基本任務在于解決各成員醫(yī)院間的遠程數(shù)據(jù)交換,主要包括病人檔案信息共享、病人診療信息共享、跨院檢驗檢查、藥品、易耗品等物資一體化功能。通過在總院建立中心數(shù)據(jù)共享平臺,中心數(shù)據(jù)共享平臺根據(jù)需要通過各醫(yī)院的子系統(tǒng)收集并存儲患者信息,所有授權和整合的醫(yī)院都可以訪問。這樣資源和患者能夠有效地在各個醫(yī)院之間流動,各家醫(yī)院之間的報告信息、設備、人才可以共享,報告結果互認,當病人跨院就診時就不再需要重新檢驗,避免了人力、財力的浪費,方便了患者,提高了服務質量,一定程度上緩解了"看病難、看病貴"的問題。4.5公共消息服務平臺醫(yī)療數(shù)據(jù)交換服務主要用于實現(xiàn)醫(yī)療信息系統(tǒng)之間的消息路由、過濾和轉換。通過該服務可以將異源異構系統(tǒng)的信息,按照"以病人為中心"的原則進行數(shù)據(jù)的交換與共享。醫(yī)療數(shù)據(jù)交換服務支持多種技術環(huán)境下的數(shù)據(jù)交換,支持多種傳輸協(xié)議和數(shù)據(jù)庫讀寫方式,并支持多種數(shù)據(jù)傳輸格式,同時,在系統(tǒng)數(shù)據(jù)未遵循相應傳輸格式的情況下,提供發(fā)送、接收、組裝和解析該格式消息的適配功能。集成平臺消息總線主要是為了連結HIS不同業(yè)務系統(tǒng),提供統(tǒng)一標準的數(shù)據(jù)接口來進行信息互聯(lián)互通,集成平臺外部系統(tǒng)都通過標準接口發(fā)布與接收消息,一般不允許直接讀取消息數(shù)據(jù)集。消息處理服務接口基于數(shù)據(jù)庫與.Net的內部實現(xiàn),內部核心組件引入業(yè)界通用的互聯(lián)互通消息交流產品,且支持HL7消息引擎?？蓴U展標記語言<ExtensibleMarkupLanguage,XML>目前正在成為各種數(shù)據(jù)特別是文檔傳輸?shù)氖走x格式。使用它,就可以容易定義一致的數(shù)據(jù)格式和傳送數(shù)據(jù),包括HL7V3,MML協(xié)議也都是以XML語言為基礎。醫(yī)院信息集成平臺的消息交換標準框架應具備以下特點：共享語義和內容結構兩個應用程序之間為了通信,必須共享數(shù)據(jù)結構。例如,如果一個應用用單個字符串處理一個病人的地址,另一個應用程序用街道、城市、州、國家來處理地址,這兩個應用程序很難進行通信。消息模型須提供規(guī)則化的方法,保證唯一的語義和內容結構,當兩個應用程序關于通信地址進行通信時,它們針對以下內容達成一致：含義、包含的數(shù)據(jù)、與其它概念的相關關系。結構可擴展XML是可擴展的。消息服務架構須保持這種可擴展性,用戶可以利用基本內容并且擴展、客戶化這些以使它支持它們的需求。 數(shù)據(jù)交換可監(jiān)控如果只是簡單地容納外部協(xié)議的數(shù)據(jù)格式進入總線進行數(shù)據(jù)交換,那么對中心監(jiān)控來說,由于協(xié)議之間的差異,對每一種數(shù)據(jù)交換協(xié)議產生的離散的數(shù)據(jù)內容,都要定制相應的監(jiān)控程序,這將大大增加數(shù)據(jù)中心的復雜度和維護成本,并由于多重監(jiān)控的系統(tǒng)資源消耗,將嚴重地影響中心數(shù)據(jù)交換吞吐量,在實際應用中是不可行的。只有基于統(tǒng)一的總線數(shù)據(jù)協(xié)議,才可能對日常交換的數(shù)據(jù)進行監(jiān)督與控制,才可在中心進行消息過濾,安全控制等復雜操作。集成平臺消息服務由以下兩個基礎功能部件組成：支持HL7引擎服務部件HL7是醫(yī)療領域不同系統(tǒng)之間電子數(shù)據(jù)傳輸?shù)膮f(xié)議,是由HL7組織制定并由ANSI批準實施的一個行業(yè)標準。它主要的目的是發(fā)展各種類型醫(yī)療信息系統(tǒng)〔如：臨床、保險、管理、行政及各項電子資料的標準。在HL7通訊協(xié)議中,消息〔message是數(shù)據(jù)交換的基本單位。HL7的消息是自動生成的,HL7標準是一個文本結構的文檔。HL7消息定義規(guī)則：〔1消息〔Message:HL7共歸納了八十多種信息類型,用于定義消息目的和用途,每條消息由若干消息段組成。〔2消息段〔Segment:HL7共有110個消息段,消息段由數(shù)據(jù)字段組成,消息段都有相應的名稱,用語界定其內容或功能。〔3字段〔Field:是一個字符串。需定義其位置、長度、數(shù)據(jù)類型、選擇類型、重復性?！?消息分隔符〔Delimiters:在消息的構成中,要用到一些特殊字符來分隔消息的組成元素。HL7消息接口實際是一組標準的API接口,這樣可以大大簡化不同廠家同類應用程序接口的復雜度和工作量。HL7采用消息傳遞方式實現(xiàn)不同模塊之間的互聯(lián),十分類似于網絡的信息包傳遞方式,可分別在發(fā)送和接收端設定發(fā)送和接收信息數(shù)據(jù)傳輸前自動檢測接收端的狀態(tài),接收端按約定內容和格式接收信息后自動判定接收信息的質量,并根據(jù)情況分別返回接收正確、錯誤和拒絕3種信息,后兩種情況下通知信息發(fā)送端重新發(fā)送。HL7接口引擎是一類通用信息轉換中間件,作為標準化的數(shù)據(jù)轉換工具,通過HL7接口引擎,把非HL7格式的數(shù)據(jù)轉換成符合HL7的標準數(shù)據(jù),然后在HL7網絡上進行通信傳輸,而只需在系統(tǒng)的邊界增加作為通訊處理模塊的HL7接口引擎,對系統(tǒng)間的數(shù)據(jù)進行轉換和通信,達到數(shù)據(jù)共享的目的。HIS廠商與PACS廠商分別開發(fā)各自系統(tǒng)接口引擎,并在雙方服務器各開兩個端口,分別發(fā)送和接收HL7消息。HL7引擎服務：一個企業(yè)服務總線在整個SOA架構中核心的部分,與原來的面向接口的架構設計不同,面向服務的體系結構〔SOA將各個服務之間的接口邏輯規(guī)范、簡化到與總線的一套接口邏輯上來,極大的簡化了集成的復雜程度,避免未來由于接口規(guī)范發(fā)生變化導致的系統(tǒng)建設風險。XML消息隊列：銜接被集成系統(tǒng)的XML消息隊列,接收和發(fā)送各個"服務"之間的XML；HL7解析：集成平臺的核心功能之一,實現(xiàn)非標準XML與標準HL7XML之間的自動解析,實現(xiàn)非標準于標準之間的自動轉換。業(yè)務流程定義〔路由：按照業(yè)務流程定義被集成"服務"之間的交互流程,定義非標準信息和HL7標準信息的交換路由,自動控制流程的流轉；并可通過出錯流程的定義實現(xiàn)異?？刂疲籋L7標準消息隊列：本項目中,被集成的應用系統(tǒng)可能均為非HL7標準的系統(tǒng),但考慮到未來的擴展,在集成平臺中預留了HL7標準的消息隊列,任何系統(tǒng)都可以從該隊列中獲取本項目中全部的標準HL7信息流。其對未來系統(tǒng)的集成擴展的意義非常重大；適配器服務部件接入服務部件：以Adapter的方式實現(xiàn)對被集成平臺的集成接入,按照SOA的設計理念,被集成系統(tǒng)需要與集成平臺交互的功能組件將被封裝成"服務",屏蔽被集成系統(tǒng)所采用的具體技術及其實現(xiàn)方式,以單一的接口方式與集成平臺銜接。平臺接入服務部件可以靈活部署,可以部署在被集成系統(tǒng)內,也可以部署在集成平臺上實現(xiàn)遠程接入。Adapter：可以提供多種Adpter供用戶選擇使用,可選擇最適合醫(yī)院的Adapter連接被集成系統(tǒng)封裝的"數(shù)據(jù)服務"；XML消息隊列："服務"之間的信息交互載體為XML,通過消息機制建立XML的交換通道。各個應用系統(tǒng)通過與消息交換中心實現(xiàn)消息交互。通過在業(yè)務系統(tǒng)端安裝相應的軟件適配器,實現(xiàn)與消息交換中心的信息交互。適配器由軟件模塊、軟件配置文件、應用編程接口等組成。消息交換的模型如下圖所示：消息交換模型在消息總線系統(tǒng)的整體設計架構中,各個具體的業(yè)務系統(tǒng)通過Adapter連接到消息消息交換平臺收發(fā)業(yè)務數(shù)據(jù)。Adapter起著耦合消息交換平臺與具體業(yè)務系統(tǒng)的作用。在我們的解決方案中有三種適配器：標準適配器、專用適配器和商用適配器。標準適配器是由標準的AdapterKernel和API組成。AdapterKernel實現(xiàn)和消息交換中心的消息交互和對消息的實時監(jiān)控,并提供將消息分發(fā)到應用系統(tǒng)的功能。API是為應用系統(tǒng)提供的一套標準的接口,具有足夠的擴展性,可以靈活地嵌入到業(yè)務流程中,同時將與業(yè)務無關的通訊配置定義與業(yè)務代碼隔離。具體地,Adapter實現(xiàn)以下的功能：實現(xiàn)消息的安全、可靠傳遞；實現(xiàn)消息的透明傳遞,Adapter的實施者不必關注傳遞技術細節(jié)；接口通用化,降低因開發(fā)架構不同導致的業(yè)務應用側編程復雜性；實現(xiàn)具有共同性的消息封裝、變換、接收功能。例如,加解密/校驗/字符集變換及HCN-XML標準協(xié)議；簡單的遠程安裝配置方法,適配器的函數(shù)調用庫可以平滑升級而不影響業(yè)務應用；可以與消息交換平臺交互管理信息,實現(xiàn)流量控制、報文蓄積、本地日志等功能。Ensemble集成平臺中間件EnsembleHIE〔健康信息交換是InterSystems公司一個新的產品,它采用了一種全新的解決方案,是一個強大的應用軟件整合平臺,它包括了為醫(yī)療信息交換預先開發(fā)好的組件,使用Ensemble可以快速地整合和開發(fā)復合應用程序。Ensemble在增強現(xiàn)有軟件功能、協(xié)調新的商業(yè)過程和集中企業(yè)數(shù)據(jù)等方面非常出色。為了滿足每一個交換系統(tǒng)的實際需要,它還提供了一個為客戶化和擴展這些組件功能的完整的開發(fā)環(huán)境。EnsembleHIE是為降低成本,縮短開發(fā)周期以及降低健康信息交換系統(tǒng)構建運營風險而設計的。EnsembleHIE是Ensemble集成系統(tǒng)的一個新的版本,專門為醫(yī)療信息組織和其它醫(yī)療信息交換應用設計。EnsembleHIE構成組件EnsembleHIE包括三個組件,它們共同來解決每一個跨機構的健康信息交換系統(tǒng)實施的端到端的需求。EnsembleHIEHub作為病人的中心索引,通過"指針"指向包括病人臨床數(shù)據(jù)的醫(yī)院和醫(yī)生的辦公系統(tǒng)。EnsembleHIE網關把參與醫(yī)療場所和用戶連接到交換平臺。EnsembleHIEViewer是一個成熟的基于瀏覽器的門戶,醫(yī)生和其它的臨床醫(yī)生可以通過它來訪問病人的人口統(tǒng)計學和臨床數(shù)據(jù)。如上圖所示,這三個組件的任務可以通過一個簡單的例子來展示。假設一名醫(yī)生想要得到一個病人的臨床數(shù)據(jù),這樣的處理過程便會開始：首先,醫(yī)生查詢Hub來"找到"病人。接著,在確認了病人之后,醫(yī)生需要從一個或者多個站點獲取數(shù)據(jù)。請求被發(fā)送到這些站點的網關,數(shù)據(jù)從每個站點的本地應用系統(tǒng)中被取出,之后網關再把這些回應匯集起來。這些回應被送回到最初的網關以供使用EnsembleHIEViewer的醫(yī)生使用。EnsembleHIEHubEnsembleHIEHub提供了一個中央病人索引,存儲了病人統(tǒng)計信息的摘要,這些信息和存儲在醫(yī)生辦公室、醫(yī)院或者其它護理和檢測場所的系統(tǒng)中的醫(yī)療記錄相連。當一個站點加入到信息交換系統(tǒng),病人的索引信息就會被成批導入。之后,如果在護理場所出現(xiàn)變化,也可以持續(xù)更新——例如,增加了一個新的病人,或者現(xiàn)有的病人信息被更新,或者兩個病人記錄被發(fā)現(xiàn)屬于同一個病人,需要現(xiàn)有的記錄合并。EnsembleHIE網關EnsembleHIE網關負責所有的在醫(yī)護場所和Hub之間或者醫(yī)護場所之間網關到網關的通信。網關同時也連接到每一個地點已有的應用,使之間的信息可以雙向流動。特別的,這些應用會通知網關一些需要反饋給Hub的病人索引的事務,例如,一個新的病人注冊或者更新一個現(xiàn)有病人的人口統(tǒng)計學信息。在另一方面,網關給醫(yī)護場所已有的應用系統(tǒng)發(fā)送需要臨床信息的請求。網關和每個醫(yī)護場所的應用系統(tǒng)之間的通信是通過Ensemble的適配器來進行的。每個網關包括一個同意管理架構,被用來記錄病人同意的聲明并加以執(zhí)行。網關也包含了一些成熟的工具來進行本地的集成。這些可以用來處理現(xiàn)有的臨床應用系統(tǒng)查詢社區(qū)病人索引或者向其它的機構獲取病人數(shù)據(jù)。EnsembleHIE瀏覽器EnsembleHIE瀏覽器和Hub聯(lián)接,使平臺范圍內的病人搜索成為可能,而且它使分布在多個機構和多個醫(yī)療事件中的數(shù)據(jù)統(tǒng)一到一個以病人為中心的綜合視圖。它為大范圍內的不同的信息提供了一個直觀的顯示,包括病人的人口統(tǒng)計學信息、過敏、用藥、診斷、實驗結果〔結果范圍,累計和圖形的格式、放射檢查結果〔文本和影像、家庭病史、臨床發(fā)現(xiàn)、病程記錄等等。作為一個純Web產品,瀏覽器可以非常容易地實施和支持,僅僅需要一個瀏覽器,在客戶端不需要安裝組件。讓我們看一個討論的示例以了解EnsembleHIE瀏覽器的強大。我們到社區(qū)醫(yī)療信息交換平臺的Web站點并登錄開始。EnsembleHIE設計原則EnsembleHIE是基于6種主要的設計原則構建：可用性：臨床醫(yī)生需要通過同一個應用系統(tǒng)來把臨床數(shù)據(jù)〔也就是除了他自己的系統(tǒng)或者工具中的數(shù)據(jù)當成本地數(shù)據(jù)來瀏覽。遺憾的是,現(xiàn)在大多數(shù)電子病歷系統(tǒng)缺乏這一功能,如果要增加這一功能需要非常多的時間,獲得這點的最好途徑就是在系統(tǒng)中增加一個臨床數(shù)據(jù)瀏覽器,成熟卻簡單易用,高度客戶化卻配置簡單,功能豐富卻非常直觀,可以在任何支持瀏覽器的機器上使用。安全和保密：系統(tǒng)必須嚴格符合隱私和安全標準。嚴格的授權,基于角色的訪問,細致的安全政策以及不可更改的所有用戶的活動記錄,都是實現(xiàn)這一目標的要素。性能、可伸縮性和可靠性：系統(tǒng)需要提供對臨床數(shù)據(jù)接近于實時的訪問：不管是用于幾十個用戶的測試系統(tǒng)或者幾千用戶的州或者國家范圍的系統(tǒng)。并且需要做到24*7的穩(wěn)定運行?；跇藴剩簶藴适腔ゲ僮餍缘年P鍵。通過在數(shù)據(jù)交換的每一個階段采用相關標準——HL7V2、HL7V33、WebServices以及CDA——系統(tǒng)可以確保不僅能夠和新的或現(xiàn)有的臨床系統(tǒng)互通而且和其它的醫(yī)療信息交換解決方案互通。靈活性和快速的客戶化：雖然信息交換系統(tǒng)的功能和標準在快速的發(fā)展,但是仍然屬于剛剛起步的階段。許多實施架構正在被考慮,例如：集中式,分散式以及混合式。所以系統(tǒng)需要能夠有非常高的靈活性并可以快速改變,以適應不斷發(fā)展的需要和用戶反饋。易管理：作為一個"系統(tǒng)的系統(tǒng)",一個健康信息交換系統(tǒng)對于系統(tǒng)管理和維持系統(tǒng)高可用性來說挑戰(zhàn)是非常大的。系統(tǒng)需要支持不同角色的管理員,易于維護,為管理所有的組件以及使用系統(tǒng)所有的管理功能提供端到端的基于Web的管理門戶。EnsembleHIE技術特點醫(yī)院集成平臺必須能夠以最小的成本可靠的與數(shù)量龐大的現(xiàn)存的臨床應用系統(tǒng)互聯(lián)。通過EnsembleHIE,這項工作可以由三項強大的技術來完成：適配器,數(shù)據(jù)轉換,業(yè)務流程。Ensemble的適配器是一種可以重復使用的軟件組件,用來提供與應用系統(tǒng)聯(lián)接,并隔離所有應用特有的邏輯。Ensemble包含了一個預置的適配器庫,能夠滿足許多醫(yī)療信息交換系統(tǒng)的需要。在原系統(tǒng)或者目標系統(tǒng)不支持標準的適配器的情況下,客戶化的適配器可以非?？焖俚拈_發(fā)出來。例如,通過繼承已有的Ensemble適配器,可以快速開發(fā),并保證Ensemble的可靠性、可管理性和性能得以實現(xiàn)。在大多數(shù)的情況下,HL7V3被用來聯(lián)接已有的臨床應用系統(tǒng)。由于內置了支持所有HL7V3.x圖表及其強大的虛擬文件架構,EnsembleHIE提供當今最豐富和最快速的基于HL7的消息引擎。Ensemble的轉換引擎用來處理消息的翻譯或者其它消息標準化以及修改的任務。這可能會重構一個消息里的字段或者可能包括和外部的系統(tǒng)或者其它復雜的流程交互以把和每個應用獨特的消息轉換成標準的格式。EnsembleHIE包括了一個可擴展的轉換類,可以把來自應用系統(tǒng)中的HL7V3的響應轉換成標準的CDA格式。不管是建立一個新的轉換還是繼承已有的轉換,這些轉換都能夠圖形化定義或通過一個基于XML的轉換"語言"定義。每個臨床應用系統(tǒng)之間的不同要求對單個處理請求給以不同的處理步驟。例如,一個對于病人臨床信息的請求可能通過發(fā)送一個單獨的請求給一個單個的應用實現(xiàn)或者通過發(fā)送多個請求給可能是在多個計算機上的多個應用系統(tǒng)實現(xiàn)。Ensemble對XML也有很強的支持,包括內置XML的解析器,DTD和XML之間的交互,通過XPATH和XSLT進行文件查詢和傳輸,使用SOAP傳輸消息?？傊?這些工具使Ensemble能夠為CDA和其它XML格式基于文件的標準提供高性能的支持。除了EnsembleHIE的許多功能能夠通過瀏覽器被調用,通過網關,其它集成的應用系統(tǒng)可以直接由程序調用這些功能。這可以用來處理一個已有的臨床應用系統(tǒng)向另外的站點請求臨床數(shù)據(jù)或者查詢社區(qū)病人的索引。由于網關提供不同的技術來訪問這些服務,包括SOA、.NET、Java、ODBC和JDBC,所以他們能夠兼容實際的任何開發(fā)技術。高可用性：為了保證高可用性,EnsembleHIE依賴InterSystems公司的自動持久化架構。在流程的每一階段,Ensemble自動把消息的狀態(tài)存儲在內置的數(shù)據(jù)庫當中。在系統(tǒng)崩潰或者其它失敗的情況下,這能夠使其快速可靠的恢復。Ensemble提供了一個非常豐富的高可用性的特點,包括：在應用系統(tǒng)正在運行、數(shù)據(jù)庫正在變化的同時做全備份和增量備份事務日志和回滾恢復保證事務的完整性保證數(shù)據(jù)庫的完整性數(shù)據(jù)在線或者離線恢復集群：延展性和快速的失效恢復安全性：為了保證安全性和隱私,EnsembleHIE實施了大量的先進技術,包括：加密技術,加強的認證,基于身份的權限和審計日志與報告。EnsembleHIE為靜態(tài)和動態(tài)的數(shù)據(jù)都提供了加強的加密技術。Ensemble內置的數(shù)據(jù)庫加密技術為數(shù)據(jù)庫中的所有內容進行加密,包括索引。對所有的在Hub和網關上的敏