集成平臺(tái)建設(shè)方案.doc

集成平臺(tái)建設(shè)方案篇一：醫(yī)院信息集成平臺(tái)建設(shè)方案信息集成平臺(tái)建設(shè)方案1 建設(shè)需求一個(gè)完善的醫(yī)院信息系統(tǒng)通常由上百個(gè)子系統(tǒng)組成，牽涉眾多的專業(yè)領(lǐng)域。這么龐大的系統(tǒng)需要非常專業(yè)化的軟件開發(fā)分工，整合不同廠商有特色的專業(yè)系統(tǒng)是醫(yī)院信息系統(tǒng)的發(fā)展趨勢(shì)，醫(yī)院信息化能夠取得成功必須保證各個(gè)系統(tǒng)的有效集成和數(shù)據(jù)的高度共享。然而這些系統(tǒng)通常是隨著醫(yī)院的發(fā)展需求逐步建設(shè)的，它們來(lái)源于不同的廠家，基于不同的技術(shù)，缺乏統(tǒng)一的信息交換標(biāo)準(zhǔn)，這些系統(tǒng)的集成整合已經(jīng)逐漸成為醫(yī)院數(shù)字化發(fā)展亟待解決的主要問(wèn)題。系統(tǒng)集成平臺(tái)的構(gòu)建主要面向兩個(gè)核心問(wèn)題：一個(gè)是為各種醫(yī)療應(yīng)用提供統(tǒng)一的醫(yī)療數(shù)據(jù)訪問(wèn)服務(wù)，從而消除各種醫(yī)療應(yīng)用系統(tǒng)與醫(yī)療數(shù)據(jù)中心的直接耦合性；另一個(gè)是為各種臨床信息系統(tǒng)提供系統(tǒng)集成服務(wù)，系統(tǒng)集成服務(wù)基于系統(tǒng)集成模型，通過(guò)HL7和DICOM等標(biāo)準(zhǔn)通訊協(xié)議為各種醫(yī)療應(yīng)用系統(tǒng)提供集成服務(wù)，確保各個(gè)臨床信息系統(tǒng)在工作流整合的基礎(chǔ)上實(shí)現(xiàn)交互協(xié)作，從而以數(shù)字化的形式完成各項(xiàng)醫(yī)療業(yè)務(wù)。2 建設(shè)目標(biāo)系統(tǒng)間的整合、集成和擴(kuò)展一直都是制約醫(yī)院數(shù)字化發(fā)展的主要障礙，由于不同廠商之間的產(chǎn)品不兼容，使得醫(yī)院整體信息化步履維艱。通過(guò)建設(shè)一個(gè)規(guī)范的系統(tǒng)集成平臺(tái)，在IHE、DICOM、HL7等國(guó)際標(biāo)準(zhǔn)的基礎(chǔ)上，制定覆蓋醫(yī)療所有業(yè)務(wù)流程的系統(tǒng)集成規(guī)范，開發(fā)基于規(guī)范的系統(tǒng)集成平臺(tái)，為遺留的、當(dāng)前的以及將來(lái)的系統(tǒng)提供了一個(gè)統(tǒng)一且標(biāo)準(zhǔn)的數(shù)據(jù)交換和工作流協(xié)同的平臺(tái)。 3 信息集成方法信息集成方法有三，即應(yīng)用集成、數(shù)據(jù)集成、界面集成，這三種集成方式各解決不同方面的問(wèn)題。應(yīng)用集成指應(yīng)用程序之間實(shí)時(shí)或異步交換信息和相互調(diào)用功能，可以采用HL7消息，Web Service，CORBA，EJB，DCOM， RPC等標(biāo)準(zhǔn)，采用消息中間件，BPM等中間件實(shí)現(xiàn)；數(shù)據(jù)集成是指應(yīng)用系統(tǒng)的數(shù)據(jù)庫(kù)系統(tǒng)之間的數(shù)據(jù)交換和共享，以及數(shù)據(jù)之間的映射變換，常采用ETL（Extract-Transform-Load）工具實(shí)現(xiàn)；界面集成含義是應(yīng)用程序界面之間相互關(guān)聯(lián)引用合成，采用技術(shù)包括ActiveX插件、Portlet、IFrame等。協(xié)同應(yīng)用從早期單純的點(diǎn)對(duì)點(diǎn)接口方式，發(fā)展到現(xiàn)如今的集成平臺(tái)方式。各種方式中：? 點(diǎn)對(duì)點(diǎn)接口方式的復(fù)雜性在于要和不同的系統(tǒng)建立1：N的接口，假定有N個(gè)系統(tǒng)相互之間需要建立接口，則接口數(shù)為 N*(N-1)/2。? 集成平臺(tái)方式中，在N個(gè)系統(tǒng)需要進(jìn)行應(yīng)用協(xié)同的情況下，只需要開發(fā)N個(gè)適配器接口即可，減少了集成平臺(tái)的系統(tǒng)負(fù)荷。由于醫(yī)院信息系統(tǒng)復(fù)雜性，我們根據(jù)不同的需求和應(yīng)用場(chǎng)景，設(shè)計(jì)分別采用上述三種不同集成方法和手段進(jìn)行信息集成。4 應(yīng)用集成和醫(yī)技輔診科室信息系統(tǒng)（如PACS/RIS、LIS、MUSE等）的信息集成，這種場(chǎng)景，信息交互的數(shù)據(jù)量不大，實(shí)時(shí)性要求不高，且各信息系統(tǒng)各專業(yè)廠商實(shí)現(xiàn)方式相差較大，采用基于集成平臺(tái)的應(yīng)用集成方式是最優(yōu)選擇。集成平臺(tái)體系結(jié)構(gòu)如下圖所示，集成平臺(tái)對(duì)外提供支持多種方式的集成服務(wù)：包括WebService服務(wù)、TCP監(jiān)聽(tīng)服務(wù)、文件監(jiān)測(cè)服務(wù)、FTP服務(wù)、SQL監(jiān)控服務(wù)等方式。醫(yī)院信息系統(tǒng)在國(guó)際、國(guó)內(nèi)廣泛采用的有一套集成規(guī)范，即：醫(yī)療健康信息集成規(guī)范（IHE）規(guī)范。IHE規(guī)范未定義新的集成標(biāo)準(zhǔn)，而是采用了“標(biāo)準(zhǔn)協(xié)調(diào)”過(guò)程推動(dòng)基于工業(yè)標(biāo)準(zhǔn)的醫(yī)療IT系統(tǒng)互操作性。在IHE中，消息傳遞采用的是HL7（2.x版本)標(biāo)準(zhǔn)，影像傳遞采用DICOM標(biāo)準(zhǔn)。本集成平臺(tái)的集成嚴(yán)格參照該規(guī)范進(jìn)行：信息集成平臺(tái)在進(jìn)行消息時(shí)采用HL72.4標(biāo)準(zhǔn)進(jìn)行消息傳遞、在消息內(nèi)部傳遞DICOM StudyUID，以滿足后續(xù)DICOM圖像應(yīng)用時(shí)的需要。臨床信息集成用于對(duì)各臨床信息系統(tǒng)進(jìn)行信息層面的集成事務(wù)處理。事務(wù)的定義參照IHE規(guī)范執(zhí)行，消息的交互標(biāo)準(zhǔn)參照HL7 2.4標(biāo)準(zhǔn)執(zhí)行。集成平臺(tái)內(nèi)部引擎本身由Ensemble集成平臺(tái)基礎(chǔ)之上進(jìn)行二次開發(fā)而來(lái)，依托Ensemble本身對(duì)各種適配器的支持，集成平臺(tái)對(duì)外能夠提供多種接入服務(wù)方式：TCP、文件夾監(jiān)聽(tīng)、FTP文件監(jiān)聽(tīng)、自定義WebService、SQL監(jiān)聽(tīng)等形式。以更多接入方式進(jìn)行各種不同方式集成各業(yè)務(wù)系統(tǒng)。集成流程以業(yè)務(wù)流程可視化、可編輯化對(duì)外提供工作流程的制定與使用。集成引擎基于標(biāo)準(zhǔn)的業(yè)務(wù)流程執(zhí)行語(yǔ)言（Business Process Execution Language）進(jìn)行擴(kuò)展應(yīng)用，以描述交互應(yīng)用。4.1 信息集成模塊與示例信息集成組件主要由以下幾部分組成Business Service業(yè)務(wù)服務(wù)、Business Process業(yè)務(wù)處理、Business Operation業(yè)務(wù)操作，這幾部分共同作用下，將集成事務(wù)與消息傳遞進(jìn)行完成。其中，Business Service主要負(fù)責(zé)進(jìn)行消息的監(jiān)聽(tīng)與接收；Business Process負(fù)責(zé)全局的消息路由轉(zhuǎn)發(fā)、事務(wù)流程處理、消息匹配映射等工作職責(zé)；Business Operation負(fù)責(zé)將轉(zhuǎn)換完成、最原子化的一個(gè)操作，發(fā)送/調(diào)用信息集成的目標(biāo)端。同時(shí)在三者相互作用下，消息的反饋準(zhǔn)確的返回到Business Process，由Process來(lái)講反饋消息控制返回到消息發(fā)送方。示意圖如下（后續(xù)對(duì)該示例進(jìn)行說(shuō)明）：4.1.1 業(yè)務(wù)服務(wù)監(jiān)聽(tīng)與接收在當(dāng)今醫(yī)院中，存在各種各種的醫(yī)療業(yè)務(wù)系統(tǒng)，醫(yī)療業(yè)務(wù)系統(tǒng)的多樣性，就將導(dǎo)致與其集成時(shí)，接入方式的多樣性，如部分系統(tǒng)已實(shí)現(xiàn)TCP的發(fā)送傳遞；部分已實(shí)現(xiàn)文本輸出等。集成平臺(tái)作為醫(yī)院信息系統(tǒng)的中轉(zhuǎn)、適配角色，在接入方式的多樣性成為必要條件。如前所述，在這方面，集成平臺(tái)允許的接入方式有：TCP、FILE、FTP、SQL、SOAP(WebService)、HTTP、MAIL等多種方式與相應(yīng)的適配器。在多種方式的接入過(guò)程中，將不同來(lái)源的消息通過(guò)統(tǒng)一的出口轉(zhuǎn)交給業(yè)務(wù)處理部分，由其進(jìn)行路由住轉(zhuǎn)發(fā)、消息匹配映射、業(yè)務(wù)流程處理等相關(guān)的工作。 在本示例中，EMRS通過(guò)WebService的服務(wù)監(jiān)聽(tīng)（BS.WS.EMRWS）方式將消息內(nèi)容傳遞進(jìn)集成平臺(tái)，在通過(guò)驗(yàn)證后，將該消息轉(zhuǎn)發(fā)給了業(yè)務(wù)處理模塊中的路由模塊。4.1.2 消息路由轉(zhuǎn)發(fā)在一些應(yīng)用場(chǎng)景中，如電子病歷系統(tǒng)、重癥監(jiān)護(hù)系統(tǒng)、HIS系統(tǒng)三者進(jìn)行信息傳遞時(shí)，部分信息是需要三者之間交互的，而部分信息僅僅需要兩者之間交互，這在消息轉(zhuǎn)發(fā)路由時(shí)，需要有一定的控制，起到閘門的作用。如：HIS系統(tǒng)進(jìn)行入院登記時(shí)，需要將病人的信息發(fā)送到電子病歷系統(tǒng)與重癥監(jiān)護(hù)系統(tǒng)；而在重癥監(jiān)護(hù)系統(tǒng)采集到病人生命體征信息時(shí)，僅僅將此信息發(fā)送到電子病歷系統(tǒng)即可。因此，在集成平臺(tái)中，引入消息路由轉(zhuǎn)發(fā)的相關(guān)模塊就顯得比較重要。在本示例中，EMRCTLRouter這個(gè)消息路由者在接受到BS.WS.EMRWS的消息時(shí)，可能會(huì)轉(zhuǎn)發(fā)至EMRPlaceOrder、EMROrderCA、BadMessageHandle三個(gè)相關(guān)的處理模塊。而具體轉(zhuǎn)發(fā)至何模塊，由消息頭定義中的相關(guān)信息具體定義。消息路由者起到解析與轉(zhuǎn)發(fā)的作用。4.1.3 事務(wù)業(yè)務(wù)流程處理即時(shí)消息路由已經(jīng)正確路由轉(zhuǎn)發(fā)了消息到準(zhǔn)確的端點(diǎn)，但是在對(duì)應(yīng)的端點(diǎn)內(nèi)，還會(huì)有一些業(yè)務(wù)流程需要進(jìn)行處理。如在EMRS下達(dá)一個(gè)新的Order的時(shí)候，需要的一定的情況下產(chǎn)生不同的業(yè)務(wù)流程分支：如該病人為門診病人或者住院病人，則有必要產(chǎn)生HL7 消息中的住院病人登記信息與門診病人登記信息：ADTA01與ADTA04。在本示例中，BPEMRPlaceOrder的內(nèi)部業(yè)務(wù)流程如下，每一個(gè)結(jié)點(diǎn)代表著一次邏輯處理過(guò)程：篇二：醫(yī)院集成平臺(tái)建設(shè)方案醫(yī)院信息系統(tǒng)集成平臺(tái)建設(shè)方案目錄1.2. 背景 . 5 建設(shè)目標(biāo) . 62.1實(shí)現(xiàn)醫(yī)療信息資源整合與利用 . 62.2實(shí)現(xiàn)醫(yī)院數(shù)據(jù)中心建設(shè) . 62.3提供管理決策及臨床決策支持 . 73. 設(shè)計(jì)原則 . 7實(shí)用性和先進(jìn)性 . 8安全性和可靠性 . 8開放性、互連性和標(biāo)準(zhǔn)化 . 8靈活性與可擴(kuò)展性 . 8經(jīng)濟(jì)性與投資保護(hù) . 9易管理和易操作性 . 9整體設(shè)計(jì)和多種應(yīng)用相匹配 . 94. 建設(shè)方案 . 104.1醫(yī)院信息化建設(shè)面臨的問(wèn)題和難題 . 104.2醫(yī)院集成平臺(tái)總體框架 . 124.3標(biāo)準(zhǔn)化數(shù)據(jù)中心 . 144.3.1建立數(shù)據(jù)中心的意義 . 154.3.2基礎(chǔ)信息庫(kù) . 164.3.3業(yè)務(wù)信息庫(kù) . 174.4.4交換信息庫(kù) . 184.3.5臨床文檔庫(kù)(CDR) . 184.3.6臨床數(shù)據(jù)中心構(gòu)建方法 . 21操作數(shù)據(jù)存儲(chǔ)ODS . 22數(shù)據(jù)倉(cāng)庫(kù) . 23醫(yī)學(xué)知識(shí)庫(kù) . 244.4數(shù)據(jù)交換總線平臺(tái) . 274.1.1. 數(shù)據(jù)交換總線技術(shù)特點(diǎn) . 294.1.2. 數(shù)據(jù)交換總線功能特點(diǎn) . 304.1.3. 基于數(shù)據(jù)交換服務(wù)總線的業(yè)務(wù)數(shù)據(jù)交互 . 324.1.4. 業(yè)務(wù)規(guī)則引擎 . 錯(cuò)誤！未定義書簽。4.1.5. 事件驅(qū)動(dòng)引擎 . 錯(cuò)誤！未定義書簽。4.1.6. 集團(tuán)化醫(yī)院信息交換平臺(tái) . 334.5公共消息服務(wù)平臺(tái) . 344.1.7. 支持HL7引擎服務(wù)部件 . 354.1.8. 適配器服務(wù)部件 . 384.2. Ensemble集成平臺(tái)中間件 . 404.2.1. Ensemble HIE 構(gòu)成組件 . 404.2.2. Ensemble HIE 設(shè)計(jì)原則 . 434.2.3. Ensemble HIE 技術(shù)特點(diǎn) . 444.2.4. Ensemble HIE 功能介紹 . 49病人主索引（MPI） . 524.2.5. 病人主索引功能 . 534.3. 統(tǒng)一身份認(rèn)證授權(quán)平臺(tái) . 574.3.1. 統(tǒng)一身份認(rèn)證授權(quán)平臺(tái)主要功能 . 5. 單點(diǎn)登錄 . 5. 身份管理 . 5. 授權(quán)管理 . 5. 安全審計(jì) . 594.3.2. 統(tǒng)一身份認(rèn)證授權(quán)實(shí)現(xiàn)方法 . 60醫(yī)院決策分析平臺(tái) . 614.3.3. 決策支撐平臺(tái)技術(shù)架構(gòu) . 634.3.4. 決策支撐平臺(tái)數(shù)據(jù)架構(gòu) . 644.3.5. 指標(biāo)加工邏輯架構(gòu) . 654.3.6. 系統(tǒng)工作內(nèi)容及技術(shù)路線 . 6. 指標(biāo)庫(kù)構(gòu)建與管理的工作內(nèi)容要求 . 6. 指標(biāo)庫(kù)構(gòu)建與管理的設(shè)計(jì)原則 . 7. 指標(biāo)庫(kù)構(gòu)建與管理的技術(shù)路線 . 72短信服務(wù)平臺(tái) . 724.3.7. 短信平臺(tái)架構(gòu) . 734.3.8. 短信平臺(tái)功能模塊 . 7. 通知功能 . 7. 查詢功能 . 7. 信息管理 . 7. 語(yǔ)音信箱咨詢功能 . 7. 醫(yī)院信息查詢功能 . 7. 投訴/舉報(bào)/建議受理功能 . 7. 自動(dòng)服務(wù)功能 . 7. 導(dǎo)醫(yī)功能 . 75后臺(tái)運(yùn)維管理系統(tǒng) . 754.3.9. 信息資源統(tǒng)一監(jiān)控系統(tǒng)設(shè)計(jì)原則 . 784.3.10. 信息資源統(tǒng)一監(jiān)控系統(tǒng)架構(gòu)及技術(shù)實(shí)現(xiàn) . 794.3.11. 信息資源統(tǒng)一監(jiān)控系統(tǒng)管理模型 . 80安全保障體系 . 814.3.12. 隱私保護(hù)措施 . 814.3.13. 網(wǎng)絡(luò)安全保障 . 844.3.14. 數(shù)據(jù)保密性 . 854.3.15. 數(shù)據(jù)完整性 . 864.3.16. 惡意代碼防范 . 874.3.17. 性能保障措施 . 884.3.18. 運(yùn)行環(huán)境保障措施 . 894.3.19. 信息安全與審計(jì)保障措施 . 905.平臺(tái)擴(kuò)展 . 錯(cuò)誤！未定義書簽。1. 建設(shè)背景我國(guó)醫(yī)院信息系統(tǒng)建設(shè)已經(jīng)有三十年的發(fā)展歷史，早期有所謂的All in One的系統(tǒng)，所有的應(yīng)用都由一個(gè)供應(yīng)商提供，服務(wù)于不同目的的應(yīng)用模塊，包裝在一個(gè)軟件包中，所有的數(shù)據(jù)庫(kù)都是開放給所有的應(yīng)用的，不需要接口引擎的設(shè)計(jì)。然而，醫(yī)療衛(wèi)生信息的復(fù)雜性決定了醫(yī)院信息系統(tǒng)的應(yīng)用越來(lái)越復(fù)雜，醫(yī)院對(duì)信息的需求也不斷擴(kuò)展，任何一個(gè)HIT廠商不可能提供醫(yī)院所需要的全線產(chǎn)品（也包括國(guó)外的HIS廠商），要實(shí)現(xiàn)真正一體化的醫(yī)院信息系統(tǒng)，必須引進(jìn)不同廠商的信息系統(tǒng)產(chǎn)品。因此在同一醫(yī)院環(huán)境下，集成不同廠商的產(chǎn)品就成為醫(yī)院信息化建設(shè)過(guò)程中必然遇到的問(wèn)題。一開始幾個(gè)廠商的產(chǎn)品要達(dá)到互連互通，往往是采用點(diǎn)對(duì)點(diǎn)的接口方式，因?yàn)檫@種方式簡(jiǎn)單、易行且成本低，例如，將一個(gè)醫(yī)療保險(xiǎn)的結(jié)算系統(tǒng)與醫(yī)院的住院及門診病人的費(fèi)用管理系統(tǒng)集成。然而，當(dāng)醫(yī)院的應(yīng)用擴(kuò)展到十幾個(gè)乃至幾十個(gè)應(yīng)用系統(tǒng)時(shí)，問(wèn)題就變得困難起來(lái)。醫(yī)院信息化能夠取得成功必須保證各個(gè)系統(tǒng)的有效集成和數(shù)據(jù)的高度共享。然而這些系統(tǒng)通常是隨著醫(yī)院的發(fā)展需求逐步建設(shè)的，它們來(lái)源于不同的廠家，基于不同的技術(shù)，缺乏統(tǒng)一的信息交換標(biāo)準(zhǔn)，這些系統(tǒng)的集成整合已經(jīng)逐漸成為制約醫(yī)院數(shù)字化發(fā)展的主要障礙。而如何把這些系統(tǒng)連接實(shí)現(xiàn)各部門各專業(yè)信息共享就成了醫(yī)院信息化建設(shè)中面臨的一大難題。如果以傳統(tǒng)的方式在各系統(tǒng)之間做接口的話就將出現(xiàn)眾多的接口，這將給醫(yī)院信息系統(tǒng)的穩(wěn)定性、安全性、可靠性、效率等帶來(lái)巨大的隱患，同時(shí)以讓醫(yī)院的運(yùn)行維護(hù)成本成倍增長(zhǎng)，如果醫(yī)院要對(duì)其中一個(gè)應(yīng)用系統(tǒng)進(jìn)行升級(jí)或更換就必須再做眾多數(shù)據(jù)接口。隨著國(guó)家新醫(yī)改政策的實(shí)施落實(shí)，以醫(yī)院為單位的管理模式已不能滿足廣大人民群眾日益增長(zhǎng)的醫(yī)療衛(wèi)生需求，信息共享是實(shí)現(xiàn)信息價(jià)值最大化的重要途徑之一，區(qū)域醫(yī)療信息共享是信息化發(fā)展的必然趨勢(shì)，為了實(shí)現(xiàn)醫(yī)療信息的區(qū)域化共享，同樣需要在醫(yī)院內(nèi)部把不同數(shù)據(jù)資源進(jìn)行集成整合。在此背景下通過(guò)醫(yī)院信息集成平臺(tái)來(lái)代替原來(lái)數(shù)量眾多的點(diǎn)到點(diǎn)數(shù)據(jù)接口，為醫(yī)院信息化建設(shè)提供標(biāo)準(zhǔn)和規(guī)范，只要各應(yīng)用系統(tǒng)都支持這些標(biāo)準(zhǔn)和規(guī)范，原篇三：系統(tǒng)集成平臺(tái)項(xiàng)目詳細(xì)實(shí)施方案-v1.0系統(tǒng)實(shí)施方案xx軟件股份有限公司2013年11月目錄第一章需求總體分析 . 61.總體需求描述 . 61.1應(yīng)用服務(wù)器需求 . 61.2第三方軟件產(chǎn)品需求 . 71.3項(xiàng)目實(shí)施進(jìn)度要求 . 72.需求分析 . 7第二章系統(tǒng)詳細(xì)設(shè)計(jì)方案 . 91.系統(tǒng)總體設(shè)計(jì) . 92.設(shè)備配置表 . 10第三章系統(tǒng)實(shí)施方案 . 121.服務(wù)器安裝調(diào)試方案 . 121.