省級衛(wèi)生信息化平臺項目方案建議書

1、省級衛(wèi)生信息化平臺項目方案建議書目 錄 TOC o 1-3 h z u HYPERLINK l _Toc47002681 第一節(jié)、項目概述 PAGEREF _Toc47002681 h 5 HYPERLINK l _Toc47002682 1.1 政策背景 PAGEREF _Toc47002682 h 5 HYPERLINK l _Toc47002683 1.2 項目目標 PAGEREF _Toc47002683 h 7 HYPERLINK l _Toc47002684 1.3 項目難點、重點 PAGEREF _Toc47002684 h 9 HYPERLINK l _Toc47002685

2、第二節(jié)、項目總體設計 PAGEREF _Toc47002685 h 10 HYPERLINK l _Toc47002686 2.1 總體架構 PAGEREF _Toc47002686 h 10 HYPERLINK l _Toc47002687 2.2 技術架構 PAGEREF _Toc47002687 h 16 HYPERLINK l _Toc47002688 2.3 技術路線 PAGEREF _Toc47002688 h 17 HYPERLINK l _Toc47002689 第三節(jié)、前置交換系統(tǒng)實施服務 PAGEREF _Toc47002689 h 25 HYPERLINK l _Toc4

3、7002690 3.1 交換前置系統(tǒng)功能描述 PAGEREF _Toc47002690 h 26 HYPERLINK l _Toc47002691 3.2 數(shù)據(jù)交換結(jié)構設計 PAGEREF _Toc47002691 h 28 HYPERLINK l _Toc47002692 3.3 數(shù)據(jù)交換共享模式分析 PAGEREF _Toc47002692 h 33 HYPERLINK l _Toc47002693 3.4 數(shù)據(jù)交換難點分析 PAGEREF _Toc47002693 h 36 HYPERLINK l _Toc47002694 3.5 數(shù)據(jù)交換內(nèi)容分析 PAGEREF _Toc4700269

4、4 h 39 HYPERLINK l _Toc47002695 3.6 數(shù)據(jù)交換過程設計 PAGEREF _Toc47002695 h 66 HYPERLINK l _Toc47002696 3.7 數(shù)據(jù)交換技術實現(xiàn) PAGEREF _Toc47002696 h 69 HYPERLINK l _Toc47002697 3.8 數(shù)據(jù)質(zhì)量管理 PAGEREF _Toc47002697 h 135 HYPERLINK l _Toc47002698 3.9 現(xiàn)有地市級平臺與省級人口健康信息平臺的對接 PAGEREF _Toc47002698 h 139 HYPERLINK l _Toc47002699

5、 第四節(jié)、消息中間件 PAGEREF _Toc47002699 h 140 HYPERLINK l _Toc47002700 4.1 支持的規(guī)范和技術 PAGEREF _Toc47002700 h 140 HYPERLINK l _Toc47002701 4.2 消息傳輸 PAGEREF _Toc47002701 h 141 HYPERLINK l _Toc47002702 4.3 應用管理 PAGEREF _Toc47002702 h 146 HYPERLINK l _Toc47002703 4.4 系統(tǒng)配置 PAGEREF _Toc47002703 h 146 HYPERLINK l _T

6、oc47002704 4.5 安全與可靠性保障 PAGEREF _Toc47002704 h 149 HYPERLINK l _Toc47002705 第五節(jié)、軟硬件基礎設施 PAGEREF _Toc47002705 h 150 HYPERLINK l _Toc47002706 5.1 前置機服務器 PAGEREF _Toc47002706 h 150 HYPERLINK l _Toc47002707 5.2 安全隔離與信息交換系統(tǒng) PAGEREF _Toc47002707 h 151 HYPERLINK l _Toc47002708 第六節(jié)、標準規(guī)范體系建設 PAGEREF _Toc4700

7、2708 h 181 HYPERLINK l _Toc47002709 6.1 建設目標 PAGEREF _Toc47002709 h 182 HYPERLINK l _Toc47002710 6.2 標準規(guī)范建設原則 PAGEREF _Toc47002710 h 182 HYPERLINK l _Toc47002711 6.3 總體建設要求 PAGEREF _Toc47002711 h 183 HYPERLINK l _Toc47002712 6.4 應用規(guī)范 PAGEREF _Toc47002712 h 183 HYPERLINK l _Toc47002713 6.5 信息基礎設施規(guī)范 P

8、AGEREF _Toc47002713 h 186 HYPERLINK l _Toc47002714 6.6 管理規(guī)范 PAGEREF _Toc47002714 h 187 HYPERLINK l _Toc47002715 6.7 安全規(guī)范 PAGEREF _Toc47002715 h 188 HYPERLINK l _Toc47002716 6.8 本期標準規(guī)范制定要求 PAGEREF _Toc47002716 h 188 HYPERLINK l _Toc47002717 6.9 標準規(guī)范體系管理 PAGEREF _Toc47002717 h 189 HYPERLINK l _Toc4700

9、2718 6.10 遵循和參考的標準與規(guī)范 PAGEREF _Toc47002718 h 191 HYPERLINK l _Toc47002719 6.11 標準規(guī)范的制定 PAGEREF _Toc47002719 h 193 HYPERLINK l _Toc47002720 6.12 動態(tài)標準管理系統(tǒng) PAGEREF _Toc47002720 h 199 HYPERLINK l _Toc47002721 第七節(jié)、項目實施方案 PAGEREF _Toc47002721 h 208 HYPERLINK l _Toc47002722 7.1 實施服務承諾 PAGEREF _Toc47002722

10、h 209 HYPERLINK l _Toc47002723 7.2 項目實施管理 PAGEREF _Toc47002723 h 212 HYPERLINK l _Toc47002724 7.3 項目實施進度安排 PAGEREF _Toc47002724 h 216 HYPERLINK l _Toc47002725 7.4 項目管理和質(zhì)量保證 PAGEREF _Toc47002725 h 216 HYPERLINK l _Toc47002726 7.5 文檔管理 PAGEREF _Toc47002726 h 220 HYPERLINK l _Toc47002727 7.6 二次開發(fā)方案 PAG

11、EREF _Toc47002727 h 221 HYPERLINK l _Toc47002728 7.7 系統(tǒng)測試方案 PAGEREF _Toc47002728 h 226 HYPERLINK l _Toc47002729 7.8 系統(tǒng)試運行方案 PAGEREF _Toc47002729 h 249 HYPERLINK l _Toc47002730 7.9 項目評審驗收 PAGEREF _Toc47002730 h 254 HYPERLINK l _Toc47002731 7.10 質(zhì)量保障體系設計 PAGEREF _Toc47002731 h 264 HYPERLINK l _Toc4700

12、2732 第八節(jié)、運行維護系統(tǒng)建設方案 PAGEREF _Toc47002732 h 272 HYPERLINK l _Toc47002733 8.1 管理制度規(guī)范 PAGEREF _Toc47002733 h 272 HYPERLINK l _Toc47002734 8.2 運維服務流程 PAGEREF _Toc47002734 h 275 HYPERLINK l _Toc47002735 8.3 質(zhì)量管理 PAGEREF _Toc47002735 h 276 HYPERLINK l _Toc47002736 8.4 風險管理 PAGEREF _Toc47002736 h 277 HYPER

13、LINK l _Toc47002737 8.5 突發(fā)事件處置方案 PAGEREF _Toc47002737 h 280項目概述1.1 政策背景衛(wèi)生信息化工作是醫(yī)改整體工作的重要一環(huán)。中共中央、國務院于2009年發(fā)布的關于深化醫(yī)藥衛(wèi)生體制改革的意見和國務院關于印發(fā)醫(yī)藥衛(wèi)生體制改革近期重點實施方案（2009-2011）的通知中，都把衛(wèi)生信息化建設作為深化醫(yī)改的八大支撐之一，要求建立實用共享的醫(yī)藥衛(wèi)生信息系統(tǒng)，大力推進醫(yī)藥衛(wèi)生信息化建設，以推進公共衛(wèi)生、醫(yī)療、醫(yī)保、藥品、財務監(jiān)管信息化建設為著力點，整合資源，加強信息標準化和公共服務信息平臺建設，逐步實現(xiàn)統(tǒng)一高效、互聯(lián)互通。黨和政府高度重視醫(yī)藥衛(wèi)生信

14、息化工作。2009年3月17日中共中央、國務院發(fā)布的關于深化醫(yī)藥衛(wèi)生體制改革的意見中提出“建立實用共享的醫(yī)藥衛(wèi)生信息系統(tǒng)”，要求“以醫(yī)院管理和電子病歷為重點，推進醫(yī)院信息化建設；利用網(wǎng)絡信息技術，促進城市醫(yī)院與社區(qū)衛(wèi)生服務機構的合作”。2010年2月11日由衛(wèi)生計生委等五部委聯(lián)合發(fā)布的關于公立醫(yī)院改革試點的指導意見進一步要求“以醫(yī)院管理和電子病歷為重點推進公立醫(yī)院信息化建設，充分利用現(xiàn)有資源，逐步建立醫(yī)院之間、上級醫(yī)院和基層醫(yī)療衛(wèi)生服務機構之間、醫(yī)院和公共衛(wèi)生機構、醫(yī)保經(jīng)辦機構之間的互聯(lián)互通機制，構建便捷、高效的醫(yī)院信息平臺”。 “十二五”期間是全面落實國家醫(yī)藥衛(wèi)生體制改革任務，實現(xiàn)國家醫(yī)藥衛(wèi)

15、生體制改革目標的關鍵時期。衛(wèi)生信息化（含中醫(yī)藥，下同）建設是深化醫(yī)藥衛(wèi)生體制改革的重要內(nèi)容，也是其開展工作、服務民眾、發(fā)展壯大的重要支撐和保障條件。加強衛(wèi)生信息化建設，對于方便群眾就醫(yī)，規(guī)范醫(yī)療服務行為，提高醫(yī)療衛(wèi)生服務質(zhì)量和效率，降低醫(yī)藥費用，緩解看病難、看病貴問題，促進人人享有基本醫(yī)療衛(wèi)生服務具有非常重要的現(xiàn)實意義和社會影響。為配合新醫(yī)改形勢下的衛(wèi)生信息化建設，衛(wèi)生計生委相續(xù)發(fā)布了健康檔案基本架構與數(shù)據(jù)標準（試行）、電子病歷基本架構與數(shù)據(jù)標準（試行）、基于健康檔案的區(qū)域衛(wèi)生信息平臺建設指南（試行）、基于健康檔案的區(qū)域衛(wèi)生信息平臺建設技術解決方案（試行）、基于區(qū)域衛(wèi)生信息平臺的婦幼保健信息系

16、統(tǒng)建設技術解決方案（試行）、基于電子病歷的醫(yī)院信息平臺建設技術解決方案（試行）、電子病歷系統(tǒng)基本功能規(guī)范、基于電子病歷的醫(yī)院信息平臺建設技術解決方案在內(nèi)的一系列重要成果，為衛(wèi)生信息化建設奠定了良好的基礎。隨著計生體系的融入，過去的五項業(yè)務將增加計劃生育這一新業(yè)務變成六項業(yè)務，兩大基礎數(shù)據(jù)庫要增加全國人口數(shù)據(jù)資源庫變成三大基礎數(shù)據(jù)庫，也就是說，目前，國家衛(wèi)生信息化“十二五”規(guī)劃從“35212”變成“46312”，新的規(guī)劃具體如下：“十二五”期間，我國將重點建設國家級、省級和（州）市級三級衛(wèi)生信息平臺；加強信息化在公共衛(wèi)生、醫(yī)療服務、計劃生育、新農(nóng)合、基本藥物制度、綜合管理六項業(yè)務中的深入應用；建

17、設電子健康檔案、電子病歷和全國人口數(shù)據(jù)資源庫三個基礎數(shù)據(jù)庫；建設一個醫(yī)療衛(wèi)生信息專用網(wǎng)絡；逐步建設信息安全體系和信息標準體系。1.2 項目目標1.2.1 項目整體目標基層醫(yī)療衛(wèi)生機構管理信息系統(tǒng)建設項目的總體建設目標是以業(yè)務和管理需求為導向，全面建成實用、共享、安全的人口健康信息網(wǎng)絡體系，為深化醫(yī)藥衛(wèi)生體制改革，有效落實計劃生育基本國策，促進中醫(yī)藥事業(yè)發(fā)展，提高衛(wèi)生計生服務與管理水平，為實現(xiàn)人人享有基本醫(yī)療衛(wèi)生服務目標提供有力的信息技術支撐和保障?；鶎俞t(yī)療衛(wèi)生機構管理信息系統(tǒng)建設項目的本期建設需要實現(xiàn)的目標包括：根據(jù)國家“46312”建設總體框架，結(jié)合人口健康信息化建設實際，以實施基層醫(yī)療衛(wèi)生

18、機構管理信息系統(tǒng)建設項目為契機，統(tǒng)籌設計全省信息化建設總體規(guī)劃，統(tǒng)一數(shù)據(jù)標準，完善管理制度，整合現(xiàn)有衛(wèi)生計生已有信息系統(tǒng)，統(tǒng)籌建設全省統(tǒng)一的全員人口信息、居民電子健康檔案和電子病歷三大數(shù)據(jù)庫，重點推動建設省市兩級人口健康信息平臺，逐步實現(xiàn)個應用系統(tǒng)的數(shù)據(jù)交換、資源共享、互聯(lián)互通、業(yè)務協(xié)同，打造全省統(tǒng)一高效的人口健康信息體系。以省為單位統(tǒng)一規(guī)劃、統(tǒng)一設計，建設涵蓋以居民健康檔案管理為基礎的公共衛(wèi)生、診療規(guī)范、基本藥物制度執(zhí)行、績效考核等基本功能的管理信息系統(tǒng)，同時實現(xiàn)與新農(nóng)合、村衛(wèi)生室管理等信息系統(tǒng)的有效銜接，為提升基層醫(yī)療衛(wèi)生機構服務質(zhì)量、提高鄉(xiāng)村一體化管理水平，提供信息化技術支撐。采用云計算

19、、云存儲的先進理念，建設全省統(tǒng)一的醫(yī)療數(shù)據(jù)中心和云服務平臺，為基層醫(yī)療衛(wèi)生、新農(nóng)合、村衛(wèi)生室信息系統(tǒng)，以及未來開展的其它健康信息服務，提供一個安全、穩(wěn)定、可擴展、易管理的云服務運行環(huán)境。建設全省電子病歷數(shù)據(jù)庫、居民健康檔案數(shù)據(jù)庫與全員人口數(shù)據(jù)庫，為衛(wèi)生綜合管理、區(qū)域衛(wèi)生管理、居民健康服務提供強有力的數(shù)據(jù)支撐，也為未來建設其它醫(yī)療衛(wèi)生信息系統(tǒng)及業(yè)務應用提供數(shù)據(jù)來源。完成全省村衛(wèi)生室管理信息系統(tǒng)和新農(nóng)合信息系統(tǒng)數(shù)據(jù)中心遷移工作，有效解決目前數(shù)據(jù)上報不及時、業(yè)務流程不規(guī)范、醫(yī)療服務不到位的關鍵問題。建設省級人口健康信息平臺，通過數(shù)據(jù)采集、數(shù)據(jù)清洗和數(shù)據(jù)分析與挖掘，基于信息資源分類目錄管理和共享需求，

20、構建綜合管理信息平臺訪問服務，輔助衛(wèi)生管理與決策。建設二級及以上醫(yī)療機構前置交換系統(tǒng)，為全省二級及以上醫(yī)院配置前置機，相關醫(yī)院也應按照省衛(wèi)計委的具體要求，進行HIS、LIS、電子病歷等系統(tǒng)的接口升級改造，與前置交換系統(tǒng)進行集成，及時、準確、完整地實現(xiàn)人口健康數(shù)據(jù)交換與業(yè)務協(xié)同。1.2.2 本包建設目標與內(nèi)容本包名稱：基層醫(yī)療衛(wèi)生機構管理信息系統(tǒng)建設一二級及以上醫(yī)療機構數(shù)據(jù)交換系統(tǒng)實施服務。本包建設目標是：按照省級人口健康信息平臺中的交換體系要求，安裝部署二級及以上醫(yī)療機構前置交換系統(tǒng)建設，為全省二級及以上醫(yī)療機構配置前置機、安全隔離與消息交換系統(tǒng)、消息中間件等軟硬件設備，相關醫(yī)院按照省衛(wèi)生計生

21、委的具體要求，進行HIS、LIS、電子病歷等系統(tǒng)的升級改造，及時、準確、完整地實現(xiàn)人口健康數(shù)據(jù)交換與業(yè)務協(xié)同。具體建設內(nèi)容是：使用E包“基層醫(yī)療衛(wèi)生機構管理信息系統(tǒng)建設項目省級人口健康信息平臺”中提供的統(tǒng)一數(shù)據(jù)交換平臺軟件，為全省二級及以上醫(yī)院配置前置機，并部署前置交換系統(tǒng)，467家醫(yī)院應該按照省衛(wèi)生計生委的具體要求，進行HIS、LIS、電子病歷等系統(tǒng)的面向接口的升級改造，與前置交換系統(tǒng)進行集成，實現(xiàn)醫(yī)院與市級平臺及虛擬平臺的對接，并完成現(xiàn)有地市平臺與升級人口健康信息平臺的對接，及時、準確、完整地實現(xiàn)人口健康數(shù)據(jù)交換與業(yè)務協(xié)同。1.3 項目難點、重點根據(jù)對醫(yī)療機構信息化現(xiàn)狀、特點、本項目招標要

22、求的分析，以及本公司在醫(yī)院數(shù)據(jù)采集方面的經(jīng)驗，歸納本項目的主要難點、重點如下：結(jié)構復雜的數(shù)據(jù)采集系統(tǒng)建設是難點因醫(yī)療機構多、類型多、規(guī)模差別大、數(shù)據(jù)量大、異構系統(tǒng)多，且醫(yī)院信息化建設發(fā)展不平衡，為確保項目可控、方案可行，必須考慮到不同醫(yī)院的異構系統(tǒng)，異構系統(tǒng)數(shù)據(jù)采集是其中的主要難點、重點。數(shù)據(jù)清洗轉(zhuǎn)換是難點多數(shù)醫(yī)院現(xiàn)有的信息系統(tǒng)達不到國家衛(wèi)計委相關標準規(guī)范要求，為減少醫(yī)院系統(tǒng)改造及接口改造的工作量，前置交換系統(tǒng)實施時應考慮面向提供接口改造、主動式數(shù)據(jù)采集、清洗、數(shù)據(jù)項映射、后結(jié)構化轉(zhuǎn)換、標準化處理等功能。數(shù)據(jù)質(zhì)量控制管理是重點根據(jù)我們的經(jīng)驗數(shù)據(jù)采集過程中最突出的問題的數(shù)據(jù)質(zhì)量達不到平臺要求，由

23、此造成數(shù)據(jù)利用的結(jié)果不正確、不可用。因此，在前置交換系統(tǒng)實施中進行數(shù)據(jù)質(zhì)量審計、結(jié)果驗證、質(zhì)量記錄、問題通報、數(shù)據(jù)修訂、檢查監(jiān)督等一系列的數(shù)據(jù)質(zhì)量監(jiān)控和管理，建立數(shù)據(jù)質(zhì)量控制管理體系，是本項目建設的重點。項目實施管理是重點鑒于本項目的建設規(guī)模大、周期短、涉眾度、結(jié)構復雜、難度大的特點，有效的項目實施管理是本項目成功的保證。項目總體設計2.1 總體架構整個區(qū)域衛(wèi)生信息交換平臺包括了兩大部分建設內(nèi)容，分別是信息交換平臺的中心端和前置接入端。中心端服務于區(qū)域醫(yī)療信息共享與協(xié)同服務，它的基礎是分布在各個醫(yī)療機構的前置交換系統(tǒng)。前置交換端主要的功能是適配各個醫(yī)療機構的異構的信息系統(tǒng)，負責采集醫(yī)療機構各業(yè)

24、務系統(tǒng)數(shù)據(jù)并按照平臺規(guī)定的標準進行清洗，并根據(jù)路由機制將數(shù)據(jù)安全傳輸?shù)侥康牡?。為保證數(shù)據(jù)的安全性及有效性，在信息資源交換前置端在向中心端數(shù)據(jù)傳輸之前，先對業(yè)務數(shù)據(jù)進行各類檢驗，如數(shù)據(jù)完整性檢驗、數(shù)據(jù)有效性檢驗、數(shù)據(jù)準確性檢驗等，此外在數(shù)據(jù)傳輸過程中實行加密傳輸，以保證數(shù)據(jù)的安全性，以標準的方式與中心端協(xié)作。圖 SEQ 圖 * ARABIC 1 總體架構整個區(qū)域衛(wèi)生信息交換平臺通過中心端和前置端的合作，提供數(shù)據(jù)傳輸服務、數(shù)據(jù)轉(zhuǎn)換服務、數(shù)據(jù)處理服務、運營管理服務等基礎信息交換功能，數(shù)據(jù)傳輸包括數(shù)據(jù)源管理、數(shù)據(jù)訪問管理、智能路由控制、隊列管理等內(nèi)容，為用戶提供安全、可靠、高效的傳輸服務；數(shù)據(jù)轉(zhuǎn)換包括

25、消息轉(zhuǎn)換、出錯控制、轉(zhuǎn)換效率監(jiān)控、轉(zhuǎn)換可視化等內(nèi)容，提供可靠、可測試、可視化、可建模的轉(zhuǎn)換服務；數(shù)據(jù)處理包括智能建庫、數(shù)據(jù)備份、數(shù)據(jù)映射、數(shù)據(jù)比對等內(nèi)容，為用戶提供科學智能的處理服務；運營管理包括遠程監(jiān)控、事件管理、工作流定義、負載均衡等內(nèi)容，提供數(shù)據(jù)運行整個過程管理服務。系統(tǒng)間通過消息集成、數(shù)據(jù)集成和服務集成的方式，以各類協(xié)議為基礎進行互聯(lián)。系統(tǒng)在設計和開發(fā)中遵循各類標準規(guī)范，保持系統(tǒng)具有足夠的開放性。這些標準規(guī)范涵蓋了系統(tǒng)互聯(lián)、管理、安全、數(shù)據(jù)等方面。基礎數(shù)據(jù)交換平臺所提供的是各應用系統(tǒng)的底層服務，主要服務組件包括：2.1.1 數(shù)據(jù)傳輸服務數(shù)據(jù)傳輸服務為系統(tǒng)間特別是異構的系統(tǒng)間的應用整合提

26、供通訊基礎,其主要特征包括：支持點對點通訊。消息發(fā)送應用可以向定點的目標系統(tǒng)發(fā)送消息。支持點對多點通訊。消息發(fā)送應用可以同時向多個目標系統(tǒng)發(fā)送消息。支持同步發(fā)送模式。消息發(fā)送應用可以以同步的方式向目標系統(tǒng)發(fā)送消息，這種模式保證消息發(fā)送完成后才將應用控制權交給消息發(fā)送應用。支持異步發(fā)送模式。消息發(fā)送應用以異步的方式向目標系統(tǒng)發(fā)送消息，這種模式下，消息發(fā)送指令執(zhí)行后立即將應用的控制權交給消息發(fā)送應用。支持請求/響應消息交互模式。請求響應模式是遠程服務調(diào)用中一種最基本的模式，消息收發(fā)功能提供了對這種模式的支持，消息發(fā)送者可以發(fā)送完請求消息后獲取目標系統(tǒng)對請求消息的處理結(jié)果消息。支持通知消息交互模式。

27、通知消息交互模式是消息應用向目標系統(tǒng)執(zhí)行信息公告的交互模式，目標系統(tǒng)接收到通知類型的消息可以根據(jù)業(yè)務需求自行處理。支持回執(zhí)消息交互模式?；貓?zhí)的交互模式要求消息的收到方在收到消息后給發(fā)送方一個收到確認消息,以保證數(shù)據(jù)傳輸?shù)目煽啃?。支持消息攜帶附件發(fā)送。一個消息可以攜帶任意數(shù)量和大小的附件進行發(fā)送，對于大附件，消息收發(fā)會自動進行文件切割發(fā)送和收到數(shù)據(jù)組裝的工作，方便消息收發(fā)應用對大數(shù)據(jù)的交換處理。支持豐富的消息連接器類型。連接器是系統(tǒng)互聯(lián)部分的重要服務，通過它系統(tǒng)外界進行通訊的通道。連接器管理可以讓管理人員自定義各種類型的連接器，并且在系統(tǒng)中注冊這些連接器。對于已有的連接器也可以根據(jù)實際的環(huán)境變化

28、進行動態(tài)的刪除和參數(shù)調(diào)整。2.1.2 數(shù)據(jù)轉(zhuǎn)換服務數(shù)據(jù)轉(zhuǎn)換是指交換前置端系統(tǒng)對從醫(yī)院業(yè)務系統(tǒng)中抽取的源數(shù)據(jù)根據(jù)數(shù)據(jù)交換中心確定的數(shù)據(jù)標準的要求，進行數(shù)據(jù)的檢查、合并、拆分、匯總等處理，保證來自不同系統(tǒng)、不同格式的數(shù)據(jù)的一致性和完整性，并按要求裝入目標數(shù)據(jù)庫。數(shù)據(jù)轉(zhuǎn)換主要完成由于以下原因造成的數(shù)據(jù)不一致性問題：源數(shù)據(jù)系統(tǒng)同中心數(shù)據(jù)庫在模型上的差異性；源數(shù)據(jù)系統(tǒng)平臺不一致：數(shù)據(jù)源可能包括基于不同平臺數(shù)據(jù)庫的數(shù)據(jù)；源數(shù)據(jù)系統(tǒng)中采用的代碼編碼方案與目標數(shù)據(jù)系統(tǒng)中的代碼編碼方案的差異性；源數(shù)據(jù)結(jié)構的不一致：有些數(shù)據(jù)源由于歷史的原因，導致同一個表在不同的時期數(shù)據(jù)結(jié)構不一致；源數(shù)據(jù)定義不規(guī)范導致錯誤數(shù)據(jù)；對

29、數(shù)據(jù)的約束不嚴格，導致無意義數(shù)據(jù)；存在重復記錄等。2.1.3 智能路由服務醫(yī)療信息從一個提供者到達一個或者多個消費者的過程中可能會遇到很多障礙，例如：沒有直達消費者的網(wǎng)絡、消費者的接收系統(tǒng)暫時不可用、消費者依據(jù)醫(yī)療信息的內(nèi)容選擇等。系統(tǒng)提供智能消息路由的技術，可以確保上述任何情況發(fā)生時都可以自動將醫(yī)療信息送達目的地。本系統(tǒng)智能消息路由的智能性主要體現(xiàn)在以下幾個方面：傳輸通道選擇的智能化。我們知道醫(yī)療信息提供者和消費者間的網(wǎng)絡情況可能出現(xiàn)異常，另外提供的信息量可能大小差距非常大。如果某種傳輸通道，例如：http協(xié)議有故障，則消息可以自動嘗試采用其它通道進行傳遞，例如：smtp。另外，如果消息中攜

30、帶的數(shù)據(jù)量非常大，系統(tǒng)會自動考慮輔助采用更高效的協(xié)議，例如：ftp完成對醫(yī)療數(shù)據(jù)的傳遞，而放棄采用常規(guī)的MQ、web service等技術。消息目的地選擇的智能化。消息發(fā)送通常有點對點、點對多點的方式，這兩種方式隱含的信息是發(fā)送時接收者是明確的。即便對于采用訂閱機制的，點對多點模式來說，中心系統(tǒng)總是知道訂閱者的信息。消息目的地選擇的智能化是特指不依賴于特定主題的訂閱機制，而是依賴對消息內(nèi)容的分析，從而動態(tài)的決定當前消息的下一個目的地，也就是基于消息內(nèi)容的路由技術。2.1.4 協(xié)議服務協(xié)議服務是指一些服務處理網(wǎng)絡、傳輸和應用層協(xié)議的組件，主要包括：應用協(xié)議服務，這些服務將支持使用應用層的通信協(xié)議

31、，建立與系統(tǒng)應用程序的通信通道。這些協(xié)議重點放在處理消息或其它類型通信流的有效負載以及應用層外部封裝上。這樣的協(xié)議包括Web Services（WS-I）、EBXML、SOAP 以及其它等。網(wǎng)絡協(xié)議服務，這些服務處理那些在物理網(wǎng)絡上提供通信能力的網(wǎng)絡協(xié)議。首要支持的網(wǎng)絡協(xié)議是TCP/IP 協(xié)議和HTTP 協(xié)議。2.1.5 其他服務 除上述服務組件外，基礎數(shù)據(jù)交換平臺還提供運行所必須的其他組件，主要包括：數(shù)據(jù)安全服務，通過數(shù)據(jù)在傳輸過程中進行加密、解密，以保證數(shù)據(jù)安全?？梢允褂眉用芩惴ǎㄊ褂眉用苊荑€）將明文轉(zhuǎn)換為密文，并使用相應的解密算法將密文轉(zhuǎn)換回明文。對稱加密算法使用相同的密鑰進行加密和解密

32、，而非對稱算法則使用公鑰/私鑰對；數(shù)據(jù)完整性服務，通常是由消息身份驗證代碼或哈希值提供的。哈希值是從數(shù)據(jù)序列導出的固定長度的數(shù)值。哈希值用于驗證通過非安全通道傳送的數(shù)據(jù)的完整性?？梢詫⑹盏降臄?shù)據(jù)的哈希值與傳送時數(shù)據(jù)的哈希值進行比較，以確定數(shù)據(jù)是否被篡改；日志管理服務，這些服務用來管理應用、系統(tǒng)、安全等日志。各種服務都將產(chǎn)生事件日志。這些事件將根據(jù)配置記錄在事件日志中。日志可以被保存在平面文件、關系型數(shù)據(jù)庫、系統(tǒng)事件日志庫等。其他服務，如警報/通知服務，可以結(jié)合日志管理服務，以提供其他增值能力；審計服務，這些服務提供配置信息審計的能力，并為其它服務提供審計支持的接口；錯誤處理服務，這些服務提供了

33、一個接口，以拋出和管理錯誤及其他業(yè)務例外。例外包括系統(tǒng)/應用級例外到發(fā)現(xiàn)由損壞或臟數(shù)據(jù)等導致的例外。錯誤/例外處理服務將使用日志管理服務來記錄出錯信息。2.2 技術架構基于消息中間件的數(shù)據(jù)交換技術架構Service Requester(服務請求方)在本構架中，服務請求方為發(fā)起請求的應用系統(tǒng)，通過消息中間件提供的源適配器，將請求消息發(fā)送到入點的前置服務器的發(fā)送隊列Message-Oriented Middleware(消息中間件)消息隊列為構造以同步或異步方式實現(xiàn)的分布式應用提供了松耦合方法。消息隊列的API調(diào)用被嵌入到新的或現(xiàn)存的應用中，通過消息發(fā)送到內(nèi)存或基于磁盤的隊列或從它讀出而提供信息交

34、換。消息隊列可用在應用中以執(zhí)行多種功能，比如要求服務、交換信息或異步處理等。在消息隊列中，隊列分為很多種類型，其中包括：本地隊列、遠程隊列、事件隊列、死信隊列等。本地隊列又分為普通本地隊列和傳輸隊列，普通本地隊列是應用程序通過API對其進行讀寫操作的隊列；傳輸隊列可以理解為存儲-轉(zhuǎn)發(fā)隊列，比如：我們將某個消息交給中間件系統(tǒng)發(fā)送到遠程主機，而此時網(wǎng)絡發(fā)生故障，消息中間件將把消息放在傳輸隊列中暫存，當網(wǎng)絡恢復時，再發(fā)往遠端目的地。遠程隊列是目的隊列在本地的定義，它類似一個地址指針，指向遠程主機上的某個目的隊列，它僅僅是個定義，不真正占用磁盤存儲空間。根據(jù)應用邏輯劃分，隊列主要劃分成發(fā)送和接收兩種隊

35、列：Input Queue(發(fā)送隊列)Output Queue(接收隊列)Service Provider(服務提供方)SOA設計中，將應用系統(tǒng)對外提供的實現(xiàn)了特定的、可標識的一組（業(yè)務）功能稱為服務。2.3 技術路線系統(tǒng)將遵循國家衛(wèi)生計生委（原衛(wèi)生部）基于健康檔案的區(qū)域衛(wèi)生信息平臺建設技術解決方案，采用當今先進成熟的技術架構和路線設計，如SOA架構、消息總線、XML、Web Service、數(shù)據(jù)集成交換引擎、工作流引擎技術、等技術，采用國家衛(wèi)生計生相關標準及HL7、IHE、 DICOM3、ICD10、CDA 等國際標準，以保障系統(tǒng)的先進性、高效性、可靠性、擴展性、互聯(lián)互通性和可持續(xù)性。2.3

36、.1 面向?qū)ο蠓誗OA面向服務的體系結(jié)構（Service-Oriented Architecture，SOA）是一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯(lián)系起來。接口是采用中立的方式進行定義的，它應該獨立于實現(xiàn)服務的硬件平臺、操作系統(tǒng)和編程語言。這使得構建在各種這樣的系統(tǒng)中的服務可以一種統(tǒng)一和通用的方式進行交互。SOA是一種粗粒度、松耦合的服務結(jié)構，是服務的集合，服務是最核心的抽象手段，業(yè)務被劃分(組件化)為一系列粗粒度的業(yè)務服務和業(yè)務流程。服務通過基于標準、精確定義的接口通信，通信可能涉及簡單數(shù)據(jù)傳遞、兩個或更多的在一個活動中協(xié)作的服務。由此

37、，SOA是一個其所有功能均被定義成精確定義的、可調(diào)用的、獨立的服務，且能被有序編排、構建業(yè)務流程的應用架構。SOA通過應用組件和傳輸協(xié)議的松散耦合，服務的即時綁定，從而實現(xiàn)業(yè)務組件的虛擬化，造就一個虛擬的集成架構，這樣使得服務集成不受任何限制，可以同時集成NET組件和J2EE組件，以及集成其他遺留系統(tǒng)的各種應用，同時也可以隨時更換這些服務組件。最終達到敏捷的、不受限制的服務集成目標，從而使IT能夠隨著業(yè)務需求的變化而自由調(diào)整，達到所謂的“隨需而變”的最高境界。建議本平臺的建設，基于SOA原理。該原理強調(diào)將不同的職責封裝成不同的服務。服務構成了SOA的功能塊，能被發(fā)布并且被其他應用程序所使用。在

38、一個SOA架構下，客戶端應用程序使用業(yè)務功能的服務而不是直接調(diào)用業(yè)務對象的函數(shù)。服務層向客戶端提供封裝了業(yè)務邏輯的黑盒子。SOA的基本原則是某一層只能與相鄰的層次進行通信。這樣可以降低一些與客戶端應用程序請求響應需穿越復雜對象模型所導致的復雜性，同時分離組件的職責，為故障容錯、簡化修改維護工作、有效管理錯誤提供了方便。在省級人口健康信息平臺中使用SOA時，SOA設計有兩個不同的層級。第一，區(qū)域衛(wèi)生信息共享平臺提供的服務是符合標準和規(guī)范的，這表示在區(qū)域范圍的任何一個終端系統(tǒng)都可以以規(guī)范的方式使用這些服務。另一個不同層級的SOA設計存在于平臺內(nèi)部，平臺在完成管理服務時要對業(yè)務邏輯進行封裝。面向服務

39、架構（SOA）被認為是異構應用系統(tǒng)之間互聯(lián)互通的最有發(fā)展前景的新技術架構，通過Web Service實現(xiàn)平臺無關性的遠程訪問和服務調(diào)用，可以在基本不改變原有應用系統(tǒng)的情況下實現(xiàn)系統(tǒng)之間的交互和資源共享。在面向服務的架構下，服務提供者（或數(shù)據(jù)提供者）提供的服務或數(shù)據(jù)源，只要設計一次，就可以被其他所有應用系統(tǒng)所利用，避免了對每個其他應用系統(tǒng)都要設計一次的麻煩。新的服務或數(shù)據(jù)源加入數(shù)據(jù)交換平臺時，對其他應用系統(tǒng)不產(chǎn)生任何影響，所以，隨著業(yè)務發(fā)展，政府用戶可以很方便地加入新的服務或數(shù)據(jù)源，構建新的數(shù)據(jù)倉庫或應用系統(tǒng)。WebService技術該方案涉及許多專業(yè)化應用，需要對多應用系統(tǒng)的進行集成，用一體化

40、的方案給予解決，形成一個相對完整而有效的體系。Webservice是一個可互操作的分布式應用程序的新平臺，它定義了應用程序如何在Web上實現(xiàn)互操作性。用任何的語言，在任何平臺上寫Webservice，只要通過Webservice標準就可以對這些服務進行查詢和訪問，形成一個開放的共享體系，使系統(tǒng)既有良好的可擴展性。基于SOA構建的交換信息平臺是一種由消息代理連接（適配器）在一起的獨立應用架構，每一個業(yè)務機構對外提供相應的接口服務群，服務在平臺配置和發(fā)布，以便其他業(yè)務機構進行調(diào)用。業(yè)務服務和發(fā)起調(diào)用的應用系統(tǒng)通過消息交換總線來執(zhí)行請求調(diào)用動作，對調(diào)用者來說，服務的提供方的具體位置以及系統(tǒng)平臺與之無

41、關，中心動態(tài)消息路由負責轉(zhuǎn)發(fā)請求到具體目的地；雙方進行數(shù)據(jù)交換的數(shù)據(jù)格式由交換前置系統(tǒng)負責包裝和解析。面向服務的設計屏蔽了不同平臺、編程語言、操作系統(tǒng)和硬件架構之間的差異，實現(xiàn)了應用系統(tǒng)之間的簡單集成。此外，應用系統(tǒng)的功能彼此獨立，功能可以按照用戶需求通過服務的方式自由組合。而這些都是通過與實施細節(jié)無關的數(shù)據(jù)中心服務配置來完成。2.3.2 消息中間件醫(yī)用消息中間件是是一個基于TCP/IP的醫(yī)用網(wǎng)絡通訊框架，為SOA提供可靠的消息服務，其核心是通過消息隊列來實現(xiàn)一種應用程序?qū)贸绦虻耐ㄐ欧椒ǎ撼绦蛑g通過在消息中間件發(fā)送數(shù)據(jù)進行通信，而不是通過直接調(diào)用彼此來通信，應用程序通過寫和檢索出入列隊的

42、針對應用程序的數(shù)據(jù)（消息）來通信，而無需專用連接來鏈接它們。我們把應用程序交由消息中間件傳輸?shù)臄?shù)據(jù)定義包裝為消息，我們定義消息的內(nèi)容主要包括消息的特征：消息發(fā)送時間、消息的優(yōu)先級、消息的接受者、數(shù)據(jù)地址、處理請求、消息ID、消息生命周期等等。消息隊列是消息的安全存放地,隊列為構造以同步或異步方式實現(xiàn)的分布式應用提供了松耦合方法，消息隊列的應用并不要求收和發(fā)送應用程序同時執(zhí)行，消息可駐留在隊列中，直到它們被應用程序讀走。通過消息隊列，應用程序可獨立地執(zhí)行-它們不需要知道彼此的位置、或在繼續(xù)執(zhí)行前不需要等待接收程序接收此消息。2.3.3 數(shù)據(jù)交換的傳輸模式按傳輸模式劃分，平臺提供以下兩種模式以適應

43、應用系統(tǒng)之間的業(yè)務調(diào)用需求1點到點消息傳輸在點到點通信模型中，本系統(tǒng)數(shù)據(jù)傳輸支持應用程序與有標識的其它應用程序點交換信息。在此情況下，消息從一個應用程序發(fā)送至另一個應用程序，稱為數(shù)據(jù)分發(fā)。在其它情況下，數(shù)據(jù)交換涉及請求和回答的消息對，稱為請求/響應消息傳遞點到點交換支持同步與異步調(diào)用：消息發(fā)出后，消息發(fā)送方進入等待狀態(tài)，等待接收消息的應用程序返回響應消息。從業(yè)務應用系統(tǒng)角度看，請求和響應的過程是同步的。消息發(fā)出后，消息發(fā)送方繼續(xù)其他處理流程。當接收消息的應用程序返回響應消息后，消息發(fā)送方再處理響應消息2發(fā)布訂閱消息傳輸有些應用程序不與特定應用程序關聯(lián)。它們對誰接收該消息或消息來自何處都沒特定要

44、求。數(shù)據(jù)在任何時候?qū)θ魏胃信d趣的應用程序都是可用的，發(fā)送方或接收方不必相互知道。HCN實現(xiàn)發(fā)布訂閱模式數(shù)據(jù)傳送，任何一個發(fā)布者發(fā)布的消息都可以由多個訂戶接收。訂戶還可以接收多個發(fā)布者的同一主題或不同主題的消息。在此通信模式下，通過訪問控制表的安全性措施來控制消息的訪問。消息路由在大多數(shù)情況下，僅僅移動數(shù)據(jù)是不夠的。確定衛(wèi)生部門其它系統(tǒng)各自需要什么樣的信息的能力是同等的重要。平臺交換中心端和前置段配合實現(xiàn)消息路由功能，將特定的數(shù)據(jù)集發(fā)送給選定的應用。路由規(guī)則定義在消息交換中心。消息交換中心通過消息頭中設定的參數(shù)進行數(shù)據(jù)路由處理?；镜穆酚烧埱笥幸粚σ?、一對多兩種，提供單向發(fā)送、請求/回復、發(fā)布/

45、訂閱等多種路由模式。消息交換中心還具有智能路由的功能，能夠根據(jù)消息的內(nèi)容來決定消息的路由。消息格式轉(zhuǎn)換該功能提供了實時的動態(tài)重新格式化信息的能力，從而使得信息能夠被異構環(huán)境中的多個應用所接受和讀取。它針對不同的協(xié)議、編程語言、應用和硬件平臺，進行信息格式化分析，并對信息重新格式化。發(fā)送信息的應用可以以單一的格式發(fā)出信息，而格式轉(zhuǎn)換器能夠自動地將信息重新格式化成一個被每一個接收信息的應用所要求的新格式。格式轉(zhuǎn)換器能夠理解應用程序間傳輸?shù)乃邢⒌母袷?，可以進行格式轉(zhuǎn)換：可以將某一消息中的數(shù)據(jù)重組為新的消息，因此它就可以為另一個應用程序所用。它相當于一本通用的辭典，可以理解應用程序的“語言”，并知

46、道應用程序信息的哪一部分是有用的。工作流管理通過它可以實現(xiàn)對工作流的有效控制。工作流管理器可以捕獲和應用業(yè)務過程的信息，從而為企業(yè)提供了更強大的業(yè)務活動控制功能，包括對涉及應用程序和職員的活動，由此可以更快速地實現(xiàn)、改進和更新工作流。中心管理管理平臺主要通過遠程連接方式提供平臺各子系統(tǒng)的配置、運行控制、業(yè)務流程配置。管理對象包括前置機，消息中心，監(jiān)控系統(tǒng)等。管理平臺包括以下功能：數(shù)據(jù)中心交換平臺各前置子系統(tǒng)的配置。系統(tǒng)管理員在系統(tǒng)初始化時通過管理平臺配置各前置交換子系統(tǒng)。數(shù)據(jù)中心交換平臺各前置子系統(tǒng)的業(yè)務運行控制。系統(tǒng)管理員在系統(tǒng)運行過程中，通過監(jiān)控系統(tǒng)的顯示信息調(diào)整各子系統(tǒng)的運行。業(yè)務流程配

47、置。平臺系統(tǒng)管理員對業(yè)務接入/調(diào)整時對業(yè)務流程進行配置管理。2.3.4 XML技術要實現(xiàn)醫(yī)療衛(wèi)生行業(yè)業(yè)務范圍內(nèi)的業(yè)務協(xié)同，數(shù)據(jù)的共享和交換是必不可少的手段之一。但各個業(yè)務部門的業(yè)務系統(tǒng)和數(shù)據(jù)格式不盡相同，因此各方會對同一數(shù)據(jù)的理解和定義出現(xiàn)誤差，因此無法達到數(shù)據(jù)交換的真實目的。為了避免這種情況的發(fā)生，在數(shù)據(jù)交換過程中引入XML技術，通過標準的數(shù)據(jù)定義和表現(xiàn)形式，使交換雙方可以在交換內(nèi)容上統(tǒng)一認識。可擴展的標記語言(XML)是Webservice平臺中表示數(shù)據(jù)的基本格式。除了易于建立和易于分析外，XML主要的優(yōu)點在于它既是平臺無關的，又是廠商無關的。無關性是比技術優(yōu)越性更重要的：軟件廠商是不會選

48、擇一個由競爭對手所發(fā)明的技術的。XML可以存取多種數(shù)據(jù)源，根據(jù)具體的應用，大致可以分為下面三種：一種是XML純文本文檔，第二種是關系型數(shù)據(jù)庫，第三種則來源于其他各種應用數(shù)據(jù)，如郵件、目錄清單、商務報告等。其中，第一種來源，即XML純文本文檔是最基本的也是最為簡單的，將數(shù)據(jù)存儲于文件中，其最大的優(yōu)點在于可以直接方便地讀取，或者加以樣式信息在瀏覽器中顯示，或者通過DOM接口編程同其他應用相連。第二種數(shù)據(jù)來源是對第一種來源的擴展，其目的是便于開發(fā)各種動態(tài)應用，其優(yōu)點則在于通過數(shù)據(jù)庫管理系統(tǒng)對數(shù)據(jù)進行管理，然后在利用服務器端應用進行動態(tài)存取。這種方式最適合于當前最為流行的基于三層結(jié)構的應用開發(fā)。第三種

49、數(shù)據(jù)由于來源廣泛，因此需要具體情況具體對待。數(shù)據(jù)接口是連接業(yè)務部門內(nèi)部的MIS系統(tǒng)和數(shù)據(jù)交換平臺的“橋梁”，而各業(yè)務部門之間的數(shù)據(jù)交換主要是以文件形式存在的。因此，數(shù)據(jù)中心應用XML技術存取的數(shù)據(jù)源主要為前兩種，即XML純文本文檔和關系型數(shù)據(jù)庫。數(shù)據(jù)接口通過XML的數(shù)據(jù)解析，將各業(yè)務數(shù)據(jù)庫中的數(shù)據(jù)生成XML純文本文檔，再經(jīng)過數(shù)據(jù)交換平臺進行傳遞。2.3.5 面向?qū)ο笤O計運用面向?qū)ο蠹夹g的前提是對整體系統(tǒng)的高度和準確抽象，通過它可以保證系統(tǒng)良好的框架，進而帶來產(chǎn)品較強的穩(wěn)定性和運行效率。本平臺的設計和開發(fā)完全采用面向?qū)ο蠹夹g，系統(tǒng)分析和設計采用UML可視化建模技術，嚴格按照面向?qū)ο蠓治?OOA)

50、、面向?qū)ο笤O計（OOD）進行設計開發(fā)。2.3.6 ETL技術平臺采用“自上而下”的ETL技術來實現(xiàn)對全省二級以上醫(yī)院的診療數(shù)據(jù)采集，建設省級資源數(shù)據(jù)庫，由交換前置系統(tǒng)來完成提供數(shù)據(jù)標準化轉(zhuǎn)換，將來自各機構格式不一的數(shù)據(jù)轉(zhuǎn)換為標準數(shù)據(jù)，不需要各醫(yī)療機構業(yè)務信息系統(tǒng)改造數(shù)據(jù)格式。前置交換系統(tǒng)實施服務基層系統(tǒng)建設能否達到預期效果關鍵在于是否有高質(zhì)量的數(shù)據(jù)支撐，需要通過前置交換平臺采集全省467家二級以上醫(yī)療機構的門診、住院、體檢等診療數(shù)據(jù)，采集HIS、電子病歷、健康檔案、健康卡以及新農(nóng)合數(shù)據(jù)。根據(jù)目前二級醫(yī)療機構的信息化水平，全省數(shù)據(jù)交換平臺采用前置機的方式進行建設，具體建設方案是在每個二級醫(yī)療機構

51、建設前置機系統(tǒng)，每個前置機部署數(shù)據(jù)交換平臺。省級人口健康信息平臺整個數(shù)據(jù)交換平臺系統(tǒng)包括部署在省級數(shù)據(jù)中心的交換平臺系統(tǒng)，以及部署在每個二級醫(yī)療機構的前置機系統(tǒng)。，每個醫(yī)療機構前置機部署數(shù)據(jù)交換系統(tǒng)，通過適配器及服務接口等方式分別與醫(yī)療機構的HIS、LIS、電子病歷、新農(nóng)合、健康卡等系統(tǒng)進行對接，并通過實時/定時等方式上傳到省平臺；省級平臺需要下達的數(shù)據(jù)到各個醫(yī)療機構的前置庫，通過適配器及服務接口等方式分別到對應的醫(yī)療機構應用系統(tǒng)中；同時醫(yī)療機構應用系統(tǒng)也可調(diào)用前置系統(tǒng)中的服務接口，獲取省級平臺相關服務功能，例如電子病歷調(diào)閱、健康檔案調(diào)閱等。3.1 交換前置系統(tǒng)功能描述通過在醫(yī)療機構設置前置機

52、當作與省級人口健康信息平臺的接入端代理，前置機作為醫(yī)療機構與平臺之間的統(tǒng)一的通訊入口和出口，使前置機成為醫(yī)院信息系統(tǒng)與信息交換總線相連接的橋梁，同時也是部門內(nèi)部業(yè)務系統(tǒng)及業(yè)務信息庫相隔離的“堡壘”。在部門前置機上安裝前置交換數(shù)據(jù)庫（交換庫）、應用適配器和信息交換軟件，用于實現(xiàn)信息數(shù)據(jù)的發(fā)送和接收。交換前置系統(tǒng)用來實現(xiàn)要對接的業(yè)務信息系統(tǒng)或平臺系統(tǒng)或交換信息庫的雙向信息同步。前置交換系統(tǒng)提供便捷的基于web的配置工具，以方便快速部署實施，實現(xiàn)業(yè)務信息與交換信息之間的映射。同時，前置系統(tǒng)實現(xiàn)業(yè)務庫與交換中心之間的“緩沖”，存放從業(yè)務部門信息庫需要送給省級人口健康信息平臺交換中心的信息和存放從交換中

53、心收到的信息。前置系統(tǒng)可根據(jù)需求，對交換數(shù)據(jù)進行緩存、過濾、轉(zhuǎn)換等加工處理。從業(yè)務角度來說其主要功能包括如下三個方面：1）作為醫(yī)療機構與省級人口健康信息平臺之間信息交互的媒介，從而來實現(xiàn)轄區(qū)內(nèi)醫(yī)療機構與現(xiàn)有市級平臺或虛擬平臺的對接，從而實現(xiàn)與省級人口健康信息平臺、醫(yī)療機構之間的互聯(lián)互通和信息共享。2）通過前置機來實現(xiàn)醫(yī)院的醫(yī)療數(shù)據(jù)集成管理，醫(yī)療機構使用前置機上部署的前置交換共享系統(tǒng)來實現(xiàn)對本院HIS、EMR、LIS、RIS等相關業(yè)務數(shù)據(jù)的異構或同構抽取、清洗和裝載，采集數(shù)據(jù)放置在前置機數(shù)據(jù)庫中，根據(jù)省級交換平臺的ESB設置的數(shù)據(jù)路由分別放進各自的業(yè)務數(shù)據(jù)庫中。3）省級需要下達的數(shù)據(jù)到各個二級機

54、構的前置庫中，通過前置交換系統(tǒng)分別到各自的應用系統(tǒng)中。從技術角度來說其主要功能包括如下幾方面：構建醫(yī)院信息系統(tǒng)和省級人口健康信息平臺數(shù)據(jù)交換與業(yè)務集成的系統(tǒng)框架，實現(xiàn)對醫(yī)院醫(yī)療的集成,遵循統(tǒng)一的數(shù)據(jù)采集、交換、共享的技術規(guī)范和標準，基于平臺實現(xiàn)醫(yī)院信息資源的交換共享、信息集成管理。通過醫(yī)院前置系統(tǒng)數(shù)據(jù)交換與共享的分層架構，支持醫(yī)療機構業(yè)務系統(tǒng)與管理系統(tǒng)的接入。將不同的業(yè)務系統(tǒng)依據(jù)訪問頻度、性能要求、實時性要求、數(shù)據(jù)粒度等的要求進行傳輸和管理。為醫(yī)療機構內(nèi)部信息系統(tǒng)層提供文檔交換共享存儲庫和消息交換共享庫，該功能主要是按照互聯(lián)互通性規(guī)范的要求的對醫(yī)療機構內(nèi)部信息系統(tǒng)內(nèi)部系統(tǒng)中的文檔和數(shù)據(jù)進行采集

55、、抽取、轉(zhuǎn)換并存儲到交換共享庫中，以便為其它服務使用。支持ETL工具集。實現(xiàn)不同系統(tǒng)之間互聯(lián)互通的路由、交換、協(xié)同工作，包括在數(shù)據(jù)傳送過程中實現(xiàn)協(xié)議轉(zhuǎn)換，數(shù)據(jù)格式轉(zhuǎn)換等。具有完善的數(shù)據(jù)同步復制系統(tǒng)，實現(xiàn)不同應用系統(tǒng)之間，數(shù)據(jù)中心與業(yè)務系統(tǒng)之間，數(shù)據(jù)中心與區(qū)域平臺之間的數(shù)據(jù)的同步與更新，實現(xiàn)分布環(huán)境下數(shù)據(jù)邏輯集中應用。自動協(xié)議轉(zhuǎn)換，支持HL7數(shù)據(jù)集與衛(wèi)生計生委的電子病歷基本數(shù)據(jù)集以及其它標準之間的自動轉(zhuǎn)換，元數(shù)據(jù)維護、字段管理等功能。提供與異構系統(tǒng)的集成能力，全面支持Web Services，與包括 .NET、J2EE在內(nèi)的各種平臺進行最好的集成，支持包括 SOAP/HTTP 和 HTTP(S)

56、 通道在內(nèi)的標準協(xié)議，提供與第三方軟件和應用套件之間的連接能力。提供廣泛的操作系統(tǒng)和硬件平臺支持，全面支持64位CPU。實現(xiàn)異構系統(tǒng)數(shù)據(jù)采集和交換，支持非標準格式數(shù)據(jù)采集；支持標準文檔自動轉(zhuǎn)換，自定義文檔模板，可提供自定義數(shù)據(jù)文檔轉(zhuǎn)換、CDA文檔自動生成、XDS提交集自動生成、患者標識轉(zhuǎn)換、數(shù)據(jù)字典轉(zhuǎn)換服務，支持多種數(shù)據(jù)格式共享，符合IHE XDS規(guī)范和衛(wèi)生計生委健康檔案相關規(guī)范。3.2 數(shù)據(jù)交換結(jié)構設計數(shù)據(jù)交換是數(shù)據(jù)共享的基礎。數(shù)據(jù)交換有兩種典型的模式，一種是網(wǎng)狀結(jié)構，一種是星型結(jié)構。3.2.1 網(wǎng)狀的數(shù)據(jù)交換結(jié)構圖 SEQ 圖 * ARABIC 2網(wǎng)狀結(jié)構數(shù)據(jù)交換模式傳統(tǒng)的點對點的數(shù)據(jù)交換

57、模式一般為網(wǎng)狀結(jié)構，網(wǎng)狀的數(shù)據(jù)交換結(jié)果如上圖所示，即任意兩個結(jié)點間都可以自己建立鏈接和定義接口標準來進行數(shù)據(jù)交換，當然交換數(shù)據(jù)文件的標準是相聯(lián)兩部門之間互相制定。目前很多的業(yè)務系統(tǒng)間的大部分的數(shù)據(jù)交換就是采用的這種模式。這種數(shù)據(jù)交換模式有以下一些優(yōu)點：結(jié)構簡單，實施方便；兩點間直接通訊，數(shù)據(jù)交換效率比較高；一個結(jié)點出現(xiàn)故障，對其他結(jié)點間的交換不會產(chǎn)生影響；當然這種交換模式也有其致命的缺點：隨著結(jié)點數(shù)的增加，連接數(shù)將呈幾何基數(shù)級增長，整個系統(tǒng)將變得越來越復雜；只能支持點對點的傳輸，不能支持數(shù)據(jù)共享及數(shù)據(jù)的訂閱/發(fā)布；參與交換的雙方必須同時在線；維護工作量較大；如果沒有專門的部門來統(tǒng)一數(shù)據(jù)交換標準

58、，那么從整體上看，各業(yè)務系統(tǒng)間的數(shù)據(jù)交換將變得非常的雜亂無章，而且重復建設現(xiàn)象將極為嚴重；3.2.2 星型的數(shù)據(jù)交換結(jié)構圖 SEQ 圖 * ARABIC 3星型結(jié)構數(shù)據(jù)交換模式星型的數(shù)據(jù)交換結(jié)構如上圖所示，即建立統(tǒng)一的數(shù)據(jù)交換中心，所有結(jié)點間的數(shù)據(jù)交換都通過數(shù)據(jù)交換中心來完成。這種數(shù)據(jù)交換模式的優(yōu)點是非常的明顯的，具體如下：可以由數(shù)據(jù)交換中心來制定統(tǒng)一的數(shù)據(jù)交換標準以及數(shù)據(jù)交換文件的模版，從而保證了所有結(jié)點間數(shù)據(jù)交換實現(xiàn)方式的一致性，在各節(jié)點客戶端應用也統(tǒng)一的情況下，各業(yè)務系統(tǒng)間的數(shù)據(jù)交換將形成一個統(tǒng)一的數(shù)據(jù)交換系統(tǒng)；每個節(jié)點只需要同數(shù)據(jù)交換中心建立連接，連接數(shù)很少；支持點對點的數(shù)據(jù)交換方式同

59、時也支持訂閱/發(fā)布式的數(shù)據(jù)交換；可以在數(shù)據(jù)交換中心來對整個數(shù)據(jù)交換過程進行統(tǒng)一的管理與監(jiān)控；不過這種數(shù)據(jù)交換模式同樣也存在一些缺陷，具體如下：數(shù)據(jù)交換中心過于依賴，一旦數(shù)據(jù)中心出現(xiàn)故障，所有結(jié)點間都將不能夠進行數(shù)據(jù)交換；由于任意兩個結(jié)點間的數(shù)據(jù)交換都需要通過數(shù)據(jù)交換中心來中轉(zhuǎn)，因此數(shù)據(jù)交換的效率相對兩個結(jié)點間的直接交換來說也要低一些；缺陷的彌補：做好數(shù)據(jù)中心與各業(yè)務系統(tǒng)業(yè)務之間數(shù)據(jù)互為備份工作，有條件的話，做好數(shù)據(jù)中心遠程異地容災。提高硬件設備的各項性能。做好數(shù)據(jù)中心應急相關的法律法規(guī)制度。3.2.3 混合型數(shù)據(jù)交換結(jié)構圖 SEQ 圖 * ARABIC 4混合結(jié)構數(shù)據(jù)交換模式混合結(jié)構數(shù)據(jù)交換模

60、式如上圖所示，混合交換模式下系統(tǒng)以星型結(jié)構通信方式為主，在設計過程中同時又考慮了網(wǎng)狀結(jié)構的特點，在重要的系統(tǒng)之間除采用星型結(jié)構的中心交換模式外，還提供了信息的點對點通道。這種設計模式既保留了星型結(jié)構管理簡單、連接數(shù)少的特點，又具有網(wǎng)狀結(jié)構的安全性，本項目中數(shù)據(jù)交換平臺建議采用混合結(jié)構工作方式。3.2.4 問題數(shù)據(jù)的處理機制在數(shù)據(jù)交換的過程中，問題數(shù)據(jù)的出現(xiàn)是在所難免的，問題數(shù)據(jù)處理流程如下圖所示：Source端的業(yè)務庫中變化的數(shù)據(jù)被寫入source的交換表中。source端的交換表中的數(shù)據(jù)被交換平臺發(fā)送到dest端正常情況下接收端解析數(shù)據(jù)，數(shù)據(jù)被存儲到dest的交換表中，如果從交換表中將數(shù)據(jù)存