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 數據交換結構設計 PAGEREF _Toc47002691 h 28 HYPERLINK l _Toc47002692 3.3 數據交換共享模式分析 PAGEREF _Toc47002692 h 33 HYPERLINK l _Toc47002693 3.4 數據交換難點分析 PAGEREF _Toc47002693 h 36 HYPERLINK l _Toc47002694 3.5 數據交換內容分析 PAGEREF _Toc4700269

4、4 h 39 HYPERLINK l _Toc47002695 3.6 數據交換過程設計 PAGEREF _Toc47002695 h 66 HYPERLINK l _Toc47002696 3.7 數據交換技術實現 PAGEREF _Toc47002696 h 69 HYPERLINK l _Toc47002697 3.8 數據質量管理 PAGEREF _Toc47002697 h 135 HYPERLINK l _Toc47002698 3.9 現有地市級平臺與省級人口健康信息平臺的對接 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 項目管理和質量保證 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 質量保障體系設計 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 質量管理 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)管信息化建設為著力點，整合資源，加強信息標準化和公共服務信息平臺建設，逐步實現統(tǒng)一高效、互聯互通。黨和政府高度重視醫(yī)藥衛(wèi)生信

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

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

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

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

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

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

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

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

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

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

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

25、消息轉換、出錯控制、轉換效率監(jiān)控、轉換可視化等內容，提供可靠、可測試、可視化、可建模的轉換服務；數據處理包括智能建庫、數據備份、數據映射、數據比對等內容，為用戶提供科學智能的處理服務；運營管理包括遠程監(jiān)控、事件管理、工作流定義、負載均衡等內容，提供數據運行整個過程管理服務。系統(tǒng)間通過消息集成、數據集成和服務集成的方式，以各類協議為基礎進行互聯。系統(tǒng)在設計和開發(fā)中遵循各類標準規(guī)范，保持系統(tǒng)具有足夠的開放性。這些標準規(guī)范涵蓋了系統(tǒng)互聯、管理、安全、數據等方面。基礎數據交換平臺所提供的是各應用系統(tǒng)的底層服務，主要服務組件包括：2.1.1 數據傳輸服務數據傳輸服務為系統(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ā)送應用。支持請求/響應消息交互模式。請求響應模式是遠程服務調用中一種最基本的模式，消息收發(fā)功能提供了對這種模式的支持，消息發(fā)送者可以發(fā)送完請求消息后獲取目標系統(tǒng)對請求消息的處理結果消息。支持通知消息交互模式。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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