省級衛(wèi)生信息化平臺總體設計

1、省級衛(wèi)生信息化平臺總體設計目 錄 TOC o 1-3 h z u HYPERLINK l _Toc47002995 第一節(jié)、項目概述 PAGEREF _Toc47002995 h 3 HYPERLINK l _Toc47002996 1.1 政策背景 PAGEREF _Toc47002996 h 3 HYPERLINK l _Toc47002997 1.2 項目目標 PAGEREF _Toc47002997 h 5 HYPERLINK l _Toc47002998 1.3 項目難點、重點 PAGEREF _Toc47002998 h 7 HYPERLINK l _Toc47002999 第二節(jié)

2、、項目總體設計 PAGEREF _Toc47002999 h 8 HYPERLINK l _Toc47003000 2.1 總體架構(gòu) PAGEREF _Toc47003000 h 8 HYPERLINK l _Toc47003001 2.2 技術(shù)架構(gòu) PAGEREF _Toc47003001 h 14 HYPERLINK l _Toc47003002 2.3 技術(shù)路線 PAGEREF _Toc47003002 h 15項目概述1.1 政策背景衛(wèi)生信息化工作是醫(yī)改整體工作的重要一環(huán)。中共中央、國務院于2009年發(fā)布的關(guān)于深化醫(yī)藥衛(wèi)生體制改革的意見和國務院關(guān)于印發(fā)醫(yī)藥衛(wèi)生體制改革近期重點實施方案（

3、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)生信息化工作。2009年3月17日中共中央、國務院發(fā)布的關(guān)于深化醫(yī)藥衛(wèi)生體制改革的意見中提出“建立實用共享的醫(yī)藥衛(wèi)生信息系統(tǒng)”，要求“以醫(yī)院管理和電子病歷為重點，推進醫(yī)院信息化建設；利用網(wǎng)絡信息技術(shù)，促進城市醫(yī)院與社區(qū)衛(wèi)生服務機構(gòu)的合作”。2010年2月11日由衛(wèi)生計生委等五部委聯(lián)合發(fā)布的關(guān)于公立醫(yī)

4、院改革試點的指導意見進一步要求“以醫(yī)院管理和電子病歷為重點推進公立醫(yī)院信息化建設，充分利用現(xiàn)有資源，逐步建立醫(yī)院之間、上級醫(yī)院和基層醫(yī)療衛(wèi)生服務機構(gòu)之間、醫(yī)院和公共衛(wèi)生機構(gòu)、醫(yī)保經(jīng)辦機構(gòu)之間的互聯(lián)互通機制，構(gòu)建便捷、高效的醫(yī)院信息平臺”。 “十二五”期間是全面落實國家醫(yī)藥衛(wèi)生體制改革任務，實現(xiàn)國家醫(yī)藥衛(wèi)生體制改革目標的關(guān)鍵時期。衛(wèi)生信息化（含中醫(yī)藥，下同）建設是深化醫(yī)藥衛(wèi)生體制改革的重要內(nèi)容，也是其開展工作、服務民眾、發(fā)展壯大的重要支撐和保障條件。加強衛(wèi)生信息化建設，對于方便群眾就醫(yī)，規(guī)范醫(yī)療服務行為，提高醫(yī)療衛(wèi)生服務質(zhì)量和效率，降低醫(yī)藥費用，緩解看病難、看病貴問題，促進人人享有基本醫(yī)療衛(wèi)生服

5、務具有非常重要的現(xiàn)實意義和社會影響。為配合新醫(yī)改形勢下的衛(wèi)生信息化建設，衛(wèi)生計生委相續(xù)發(fā)布了健康檔案基本架構(gòu)與數(shù)據(jù)標準（試行）、電子病歷基本架構(gòu)與數(shù)據(jù)標準（試行）、基于健康檔案的區(qū)域衛(wèi)生信息平臺建設指南（試行）、基于健康檔案的區(qū)域衛(wèi)生信息平臺建設技術(shù)解決方案（試行）、基于區(qū)域衛(wèi)生信息平臺的婦幼保健信息系統(tǒng)建設技術(shù)解決方案（試行）、基于電子病歷的醫(yī)院信息平臺建設技術(shù)解決方案（試行）、電子病歷系統(tǒng)基本功能規(guī)范、基于電子病歷的醫(yī)院信息平臺建設技術(shù)解決方案在內(nèi)的一系列重要成果，為衛(wèi)生信息化建設奠定了良好的基礎。隨著計生體系的融入，過去的五項業(yè)務將增加計劃生育這一新業(yè)務變成六項業(yè)務，兩大基礎數(shù)據(jù)庫要增加

6、全國人口數(shù)據(jù)資源庫變成三大基礎數(shù)據(jù)庫，也就是說，目前，國家衛(wèi)生信息化“十二五”規(guī)劃從“35212”變成“46312”，新的規(guī)劃具體如下：“十二五”期間，我國將重點建設國家級、省級和（州）市級三級衛(wèi)生信息平臺；加強信息化在公共衛(wèi)生、醫(yī)療服務、計劃生育、新農(nóng)合、基本藥物制度、綜合管理六項業(yè)務中的深入應用；建設電子健康檔案、電子病歷和全國人口數(shù)據(jù)資源庫三個基礎數(shù)據(jù)庫；建設一個醫(yī)療衛(wèi)生信息專用網(wǎng)絡；逐步建設信息安全體系和信息標準體系。1.2 項目目標1.2.1 項目整體目標基層醫(yī)療衛(wèi)生機構(gòu)管理信息系統(tǒng)建設項目的總體建設目標是以業(yè)務和管理需求為導向，全面建成實用、共享、安全的人口健康信息網(wǎng)絡體系，為深化

7、醫(yī)藥衛(wèi)生體制改革，有效落實計劃生育基本國策，促進中醫(yī)藥事業(yè)發(fā)展，提高衛(wèi)生計生服務與管理水平，為實現(xiàn)人人享有基本醫(yī)療衛(wèi)生服務目標提供有力的信息技術(shù)支撐和保障?；鶎俞t(yī)療衛(wèi)生機構(gòu)管理信息系統(tǒng)建設項目的本期建設需要實現(xiàn)的目標包括：根據(jù)國家“46312”建設總體框架，結(jié)合人口健康信息化建設實際，以實施基層醫(yī)療衛(wèi)生機構(gòu)管理信息系統(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é)同，打造全

8、省統(tǒng)一高效的人口健康信息體系。以省為單位統(tǒng)一規(guī)劃、統(tǒng)一設計，建設涵蓋以居民健康檔案管理為基礎的公共衛(wèi)生、診療規(guī)范、基本藥物制度執(zhí)行、績效考核等基本功能的管理信息系統(tǒng)，同時實現(xiàn)與新農(nóng)合、村衛(wèi)生室管理等信息系統(tǒng)的有效銜接，為提升基層醫(yī)療衛(wèi)生機構(gòu)服務質(zhì)量、提高鄉(xiāng)村一體化管理水平，提供信息化技術(shù)支撐。采用云計算、云存儲的先進理念，建設全省統(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)生管理、居民健康服務提供強有

9、力的數(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ī)療服務不到位的關(guān)鍵問題。建設省級人口健康信息平臺，通過數(shù)據(jù)采集、數(shù)據(jù)清洗和數(shù)據(jù)分析與挖掘，基于信息資源分類目錄管理和共享需求，構(gòu)建綜合管理信息平臺訪問服務，輔助衛(wèi)生管理與決策。建設二級及以上醫(yī)療機構(gòu)前置交換系統(tǒng)，為全省二級及以上醫(yī)院配置前置機，相關(guān)醫(yī)院也應按照省衛(wèi)計委的具體要求，進行HIS、LIS、電子病歷等系統(tǒng)的接口升級改造，與前置交換系統(tǒng)進行集成，及時、準確、完整地實現(xiàn)人口健康數(shù)據(jù)交換與業(yè)務協(xié)同。1.2.2 本包建

10、設目標與內(nèi)容本包名稱：基層醫(yī)療衛(wèi)生機構(gòu)管理信息系統(tǒng)建設一二級及以上醫(yī)療機構(gòu)數(shù)據(jù)交換系統(tǒng)實施服務。本包建設目標是：按照省級人口健康信息平臺中的交換體系要求，安裝部署二級及以上醫(yī)療機構(gòu)前置交換系統(tǒng)建設，為全省二級及以上醫(yī)療機構(gòu)配置前置機、安全隔離與消息交換系統(tǒng)、消息中間件等軟硬件設備，相關(guān)醫(yī)院按照省衛(wèi)生計生委的具體要求，進行HIS、LIS、電子病歷等系統(tǒng)的升級改造，及時、準確、完整地實現(xiàn)人口健康數(shù)據(jù)交換與業(yè)務協(xié)同。具體建設內(nèi)容是：使用E包“基層醫(yī)療衛(wèi)生機構(gòu)管理信息系統(tǒng)建設項目省級人口健康信息平臺”中提供的統(tǒng)一數(shù)據(jù)交換平臺軟件，為全省二級及以上醫(yī)院配置前置機，并部署前置交換系統(tǒng)，467家醫(yī)院應該按照

11、省衛(wèi)生計生委的具體要求，進行HIS、LIS、電子病歷等系統(tǒng)的面向接口的升級改造，與前置交換系統(tǒng)進行集成，實現(xiàn)醫(yī)院與市級平臺及虛擬平臺的對接，并完成現(xiàn)有地市平臺與升級人口健康信息平臺的對接，及時、準確、完整地實現(xiàn)人口健康數(shù)據(jù)交換與業(yè)務協(xié)同。1.3 項目難點、重點根據(jù)對醫(yī)療機構(gòu)信息化現(xiàn)狀、特點、本項目招標要求的分析，以及本公司在醫(yī)院數(shù)據(jù)采集方面的經(jīng)驗，歸納本項目的主要難點、重點如下：結(jié)構(gòu)復雜的數(shù)據(jù)采集系統(tǒng)建設是難點因醫(yī)療機構(gòu)多、類型多、規(guī)模差別大、數(shù)據(jù)量大、異構(gòu)系統(tǒng)多，且醫(yī)院信息化建設發(fā)展不平衡，為確保項目可控、方案可行，必須考慮到不同醫(yī)院的異構(gòu)系統(tǒng)，異構(gòu)系統(tǒng)數(shù)據(jù)采集是其中的主要難點、重點。數(shù)據(jù)清

12、洗轉(zhuǎn)換是難點多數(shù)醫(yī)院現(xiàn)有的信息系統(tǒng)達不到國家衛(wèi)計委相關(guān)標準規(guī)范要求，為減少醫(yī)院系統(tǒng)改造及接口改造的工作量，前置交換系統(tǒng)實施時應考慮面向提供接口改造、主動式數(shù)據(jù)采集、清洗、數(shù)據(jù)項映射、后結(jié)構(gòu)化轉(zhuǎn)換、標準化處理等功能。數(shù)據(jù)質(zhì)量控制管理是重點根據(jù)我們的經(jīng)驗數(shù)據(jù)采集過程中最突出的問題的數(shù)據(jù)質(zhì)量達不到平臺要求，由此造成數(shù)據(jù)利用的結(jié)果不正確、不可用。因此，在前置交換系統(tǒng)實施中進行數(shù)據(jù)質(zhì)量審計、結(jié)果驗證、質(zhì)量記錄、問題通報、數(shù)據(jù)修訂、檢查監(jiān)督等一系列的數(shù)據(jù)質(zhì)量監(jiān)控和管理，建立數(shù)據(jù)質(zhì)量控制管理體系，是本項目建設的重點。項目實施管理是重點鑒于本項目的建設規(guī)模大、周期短、涉眾度、結(jié)構(gòu)復雜、難度大的特點，有效的項目

13、實施管理是本項目成功的保證。項目總體設計2.1 總體架構(gòu)整個區(qū)域衛(wèi)生信息交換平臺包括了兩大部分建設內(nèi)容，分別是信息交換平臺的中心端和前置接入端。中心端服務于區(qū)域醫(yī)療信息共享與協(xié)同服務，它的基礎是分布在各個醫(yī)療機構(gòu)的前置交換系統(tǒng)。前置交換端主要的功能是適配各個醫(yī)療機構(gòu)的異構(gòu)的信息系統(tǒng)，負責采集醫(yī)療機構(gòu)各業(yè)務系統(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ù)的安全性，以標準的方式與

14、中心端協(xié)作。圖 SEQ 圖 * ARABIC 1 總體架構(gòu)整個區(qū)域衛(wèi)生信息交換平臺通過中心端和前置端的合作，提供數(shù)據(jù)傳輸服務、數(shù)據(jù)轉(zhuǎn)換服務、數(shù)據(jù)處理服務、運營管理服務等基礎信息交換功能，數(shù)據(jù)傳輸包括數(shù)據(jù)源管理、數(shù)據(jù)訪問管理、智能路由控制、隊列管理等內(nèi)容，為用戶提供安全、可靠、高效的傳輸服務；數(shù)據(jù)轉(zhuǎn)換包括消息轉(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ù)

15、據(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)間特別是異構(gòu)的系統(tǒng)間的應用整合提供通訊基礎,其主要特征包括：支持點對點通訊。消息發(fā)送應用可以向定點的目標系統(tǒng)發(fā)送消息。支持點對多點通訊。消息發(fā)送應用可以同時向多個目標系統(tǒng)發(fā)送消息。支持同步發(fā)送模式。消息發(fā)送應用可以以同步的方式向目標系統(tǒng)發(fā)送消息，這種模式保證消息發(fā)送完成后才將應用控制權(quán)交給消息發(fā)送應用。支持異步發(fā)送模式。消息發(fā)

16、送應用以異步的方式向目標系統(tǒng)發(fā)送消息，這種模式下，消息發(fā)送指令執(zhí)行后立即將應用的控制權(quán)交給消息發(fā)送應用。支持請求/響應消息交互模式。請求響應模式是遠程服務調(diào)用中一種最基本的模式，消息收發(fā)功能提供了對這種模式的支持，消息發(fā)送者可以發(fā)送完請求消息后獲取目標系統(tǒng)對請求消息的處理結(jié)果消息。支持通知消息交互模式。通知消息交互模式是消息應用向目標系統(tǒng)執(zhí)行信息公告的交互模式，目標系統(tǒng)接收到通知類型的消息可以根據(jù)業(yè)務需求自行處理。支持回執(zhí)消息交互模式。回執(zhí)的交互模式要求消息的收到方在收到消息后給發(fā)送方一個收到確認消息,以保證數(shù)據(jù)傳輸?shù)目煽啃?。支持消息攜帶附件發(fā)送。一個消息可以攜帶任意數(shù)量和大小的附件進行發(fā)送，

17、對于大附件，消息收發(fā)會自動進行文件切割發(fā)送和收到數(shù)據(jù)組裝的工作，方便消息收發(fā)應用對大數(shù)據(jù)的交換處理。支持豐富的消息連接器類型。連接器是系統(tǒng)互聯(lián)部分的重要服務，通過它系統(tǒng)外界進行通訊的通道。連接器管理可以讓管理人員自定義各種類型的連接器，并且在系統(tǒng)中注冊這些連接器。對于已有的連接器也可以根據(jù)實際的環(huán)境變化進行動態(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ù)

18、不一致性問題：源數(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é)構(gòu)的不一致：有些數(shù)據(jù)源由于歷史的原因，導致同一個表在不同的時期數(shù)據(jù)結(jié)構(gòu)不一致；源數(shù)據(jù)定義不規(guī)范導致錯誤數(shù)據(jù)；對數(shù)據(jù)的約束不嚴格，導致無意義數(shù)據(jù)；存在重復記錄等。2.1.3 智能路由服務醫(yī)療信息從一個提供者到達一個或者多個消費者的過程中可能會遇到很多障礙，例如：沒有直達消費者的網(wǎng)絡、消費者的接收系統(tǒng)暫時不可用、消費者依據(jù)醫(yī)療信息的內(nèi)容選擇等。系統(tǒng)提供智能消息路由的技術(shù)，可以確保上述任何情況發(fā)生時都可以自動

19、將醫(yī)療信息送達目的地。本系統(tǒng)智能消息路由的智能性主要體現(xiàn)在以下幾個方面：傳輸通道選擇的智能化。我們知道醫(yī)療信息提供者和消費者間的網(wǎng)絡情況可能出現(xiàn)異常，另外提供的信息量可能大小差距非常大。如果某種傳輸通道，例如：http協(xié)議有故障，則消息可以自動嘗試采用其它通道進行傳遞，例如：smtp。另外，如果消息中攜帶的數(shù)據(jù)量非常大，系統(tǒng)會自動考慮輔助采用更高效的協(xié)議，例如：ftp完成對醫(yī)療數(shù)據(jù)的傳遞，而放棄采用常規(guī)的MQ、web service等技術(shù)。消息目的地選擇的智能化。消息發(fā)送通常有點對點、點對多點的方式，這兩種方式隱含的信息是發(fā)送時接收者是明確的。即便對于采用訂閱機制的，點對多點模式來說，中心系統(tǒng)

20、總是知道訂閱者的信息。消息目的地選擇的智能化是特指不依賴于特定主題的訂閱機制，而是依賴對消息內(nèi)容的分析，從而動態(tài)的決定當前消息的下一個目的地，也就是基于消息內(nèi)容的路由技術(shù)。2.1.4 協(xié)議服務協(xié)議服務是指一些服務處理網(wǎng)絡、傳輸和應用層協(xié)議的組件，主要包括：應用協(xié)議服務，這些服務將支持使用應用層的通信協(xié)議，建立與系統(tǒng)應用程序的通信通道。這些協(xié)議重點放在處理消息或其它類型通信流的有效負載以及應用層外部封裝上。這樣的協(xié)議包括Web Services（WS-I）、EBXML、SOAP 以及其它等。網(wǎng)絡協(xié)議服務，這些服務處理那些在物理網(wǎng)絡上提供通信能力的網(wǎng)絡協(xié)議。首要支持的網(wǎng)絡協(xié)議是TCP/IP 協(xié)議和

21、HTTP 協(xié)議。2.1.5 其他服務 除上述服務組件外，基礎數(shù)據(jù)交換平臺還提供運行所必須的其他組件，主要包括：數(shù)據(jù)安全服務，通過數(shù)據(jù)在傳輸過程中進行加密、解密，以保證數(shù)據(jù)安全?？梢允褂眉用芩惴ǎㄊ褂眉用苊荑€）將明文轉(zhuǎn)換為密文，并使用相應的解密算法將密文轉(zhuǎn)換回明文。對稱加密算法使用相同的密鑰進行加密和解密，而非對稱算法則使用公鑰/私鑰對；數(shù)據(jù)完整性服務，通常是由消息身份驗證代碼或哈希值提供的。哈希值是從數(shù)據(jù)序列導出的固定長度的數(shù)值。哈希值用于驗證通過非安全通道傳送的數(shù)據(jù)的完整性?？梢詫⑹盏降臄?shù)據(jù)的哈希值與傳送時數(shù)據(jù)的哈希值進行比較，以確定數(shù)據(jù)是否被篡改；日志管理服務，這些服務用來管理應用、系統(tǒng)、

22、安全等日志。各種服務都將產(chǎn)生事件日志。這些事件將根據(jù)配置記錄在事件日志中。日志可以被保存在平面文件、關(guān)系型數(shù)據(jù)庫、系統(tǒng)事件日志庫等。其他服務，如警報/通知服務，可以結(jié)合日志管理服務，以提供其他增值能力；審計服務，這些服務提供配置信息審計的能力，并為其它服務提供審計支持的接口；錯誤處理服務，這些服務提供了一個接口，以拋出和管理錯誤及其他業(yè)務例外。例外包括系統(tǒng)/應用級例外到發(fā)現(xiàn)由損壞或臟數(shù)據(jù)等導致的例外。錯誤/例外處理服務將使用日志管理服務來記錄出錯信息。2.2 技術(shù)架構(gòu)基于消息中間件的數(shù)據(jù)交換技術(shù)架構(gòu)Service Requester(服務請求方)在本構(gòu)架中，服務請求方為發(fā)起請求的應用系統(tǒng)，通過

23、消息中間件提供的源適配器，將請求消息發(fā)送到入點的前置服務器的發(fā)送隊列Message-Oriented Middleware(消息中間件)消息隊列為構(gòu)造以同步或異步方式實現(xiàn)的分布式應用提供了松耦合方法。消息隊列的API調(diào)用被嵌入到新的或現(xiàn)存的應用中，通過消息發(fā)送到內(nèi)存或基于磁盤的隊列或從它讀出而提供信息交換。消息隊列可用在應用中以執(zhí)行多種功能，比如要求服務、交換信息或異步處理等。在消息隊列中，隊列分為很多種類型，其中包括：本地隊列、遠程隊列、事件隊列、死信隊列等。本地隊列又分為普通本地隊列和傳輸隊列，普通本地隊列是應用程序通過API對其進行讀寫操作的隊列；傳輸隊列可以理解為存儲-轉(zhuǎn)發(fā)隊列，比如：

24、我們將某個消息交給中間件系統(tǒng)發(fā)送到遠程主機，而此時網(wǎng)絡發(fā)生故障，消息中間件將把消息放在傳輸隊列中暫存，當網(wǎng)絡恢復時，再發(fā)往遠端目的地。遠程隊列是目的隊列在本地的定義，它類似一個地址指針，指向遠程主機上的某個目的隊列，它僅僅是個定義，不真正占用磁盤存儲空間。根據(jù)應用邏輯劃分，隊列主要劃分成發(fā)送和接收兩種隊列：Input Queue(發(fā)送隊列)Output Queue(接收隊列)Service Provider(服務提供方)SOA設計中，將應用系統(tǒng)對外提供的實現(xiàn)了特定的、可標識的一組（業(yè)務）功能稱為服務。2.3 技術(shù)路線系統(tǒng)將遵循國家衛(wèi)生計生委（原衛(wèi)生部）基于健康檔案的區(qū)域衛(wèi)生信息平臺建設技術(shù)解決

25、方案，采用當今先進成熟的技術(shù)架構(gòu)和路線設計，如SOA架構(gòu)、消息總線、XML、Web Service、數(shù)據(jù)集成交換引擎、工作流引擎技術(shù)、等技術(shù)，采用國家衛(wèi)生計生相關(guān)標準及HL7、IHE、 DICOM3、ICD10、CDA 等國際標準，以保障系統(tǒng)的先進性、高效性、可靠性、擴展性、互聯(lián)互通性和可持續(xù)性。2.3.1 面向?qū)ο蠓誗OA面向服務的體系結(jié)構(gòu)（Service-Oriented Architecture，SOA）是一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯(lián)系起來。接口是采用中立的方式進行定義的，它應該獨立于實現(xiàn)服務的硬件平臺、操作系統(tǒng)和編程語言。

26、這使得構(gòu)建在各種這樣的系統(tǒng)中的服務可以一種統(tǒng)一和通用的方式進行交互。SOA是一種粗粒度、松耦合的服務結(jié)構(gòu)，是服務的集合，服務是最核心的抽象手段，業(yè)務被劃分(組件化)為一系列粗粒度的業(yè)務服務和業(yè)務流程。服務通過基于標準、精確定義的接口通信，通信可能涉及簡單數(shù)據(jù)傳遞、兩個或更多的在一個活動中協(xié)作的服務。由此，SOA是一個其所有功能均被定義成精確定義的、可調(diào)用的、獨立的服務，且能被有序編排、構(gòu)建業(yè)務流程的應用架構(gòu)。SOA通過應用組件和傳輸協(xié)議的松散耦合，服務的即時綁定，從而實現(xiàn)業(yè)務組件的虛擬化，造就一個虛擬的集成架構(gòu)，這樣使得服務集成不受任何限制，可以同時集成NET組件和J2EE組件，以及集成其他遺

27、留系統(tǒng)的各種應用，同時也可以隨時更換這些服務組件。最終達到敏捷的、不受限制的服務集成目標，從而使IT能夠隨著業(yè)務需求的變化而自由調(diào)整，達到所謂的“隨需而變”的最高境界。建議本平臺的建設，基于SOA原理。該原理強調(diào)將不同的職責封裝成不同的服務。服務構(gòu)成了SOA的功能塊，能被發(fā)布并且被其他應用程序所使用。在一個SOA架構(gòu)下，客戶端應用程序使用業(yè)務功能的服務而不是直接調(diào)用業(yè)務對象的函數(shù)。服務層向客戶端提供封裝了業(yè)務邏輯的黑盒子。SOA的基本原則是某一層只能與相鄰的層次進行通信。這樣可以降低一些與客戶端應用程序請求響應需穿越復雜對象模型所導致的復雜性，同時分離組件的職責，為故障容錯、簡化修改維護工作、

28、有效管理錯誤提供了方便。在省級人口健康信息平臺中使用SOA時，SOA設計有兩個不同的層級。第一，區(qū)域衛(wèi)生信息共享平臺提供的服務是符合標準和規(guī)范的，這表示在區(qū)域范圍的任何一個終端系統(tǒng)都可以以規(guī)范的方式使用這些服務。另一個不同層級的SOA設計存在于平臺內(nèi)部，平臺在完成管理服務時要對業(yè)務邏輯進行封裝。面向服務架構(gòu)（SOA）被認為是異構(gòu)應用系統(tǒng)之間互聯(lián)互通的最有發(fā)展前景的新技術(shù)架構(gòu)，通過Web Service實現(xiàn)平臺無關(guān)性的遠程訪問和服務調(diào)用，可以在基本不改變原有應用系統(tǒng)的情況下實現(xiàn)系統(tǒng)之間的交互和資源共享。在面向服務的架構(gòu)下，服務提供者（或數(shù)據(jù)提供者）提供的服務或數(shù)據(jù)源，只要設計一次，就可以被其他所

29、有應用系統(tǒng)所利用，避免了對每個其他應用系統(tǒng)都要設計一次的麻煩。新的服務或數(shù)據(jù)源加入數(shù)據(jù)交換平臺時，對其他應用系統(tǒng)不產(chǎn)生任何影響，所以，隨著業(yè)務發(fā)展，政府用戶可以很方便地加入新的服務或數(shù)據(jù)源，構(gòu)建新的數(shù)據(jù)倉庫或應用系統(tǒng)。WebService技術(shù)該方案涉及許多專業(yè)化應用，需要對多應用系統(tǒng)的進行集成，用一體化的方案給予解決，形成一個相對完整而有效的體系。Webservice是一個可互操作的分布式應用程序的新平臺，它定義了應用程序如何在Web上實現(xiàn)互操作性。用任何的語言，在任何平臺上寫Webservice，只要通過Webservice標準就可以對這些服務進行查詢和訪問，形成一個開放的共享體系，使系統(tǒng)既

30、有良好的可擴展性?；赟OA構(gòu)建的交換信息平臺是一種由消息代理連接（適配器）在一起的獨立應用架構(gòu)，每一個業(yè)務機構(gòu)對外提供相應的接口服務群，服務在平臺配置和發(fā)布，以便其他業(yè)務機構(gòu)進行調(diào)用。業(yè)務服務和發(fā)起調(diào)用的應用系統(tǒng)通過消息交換總線來執(zhí)行請求調(diào)用動作，對調(diào)用者來說，服務的提供方的具體位置以及系統(tǒng)平臺與之無關(guān)，中心動態(tài)消息路由負責轉(zhuǎn)發(fā)請求到具體目的地；雙方進行數(shù)據(jù)交換的數(shù)據(jù)格式由交換前置系統(tǒng)負責包裝和解析。面向服務的設計屏蔽了不同平臺、編程語言、操作系統(tǒng)和硬件架構(gòu)之間的差異，實現(xiàn)了應用系統(tǒng)之間的簡單集成。此外，應用系統(tǒng)的功能彼此獨立，功能可以按照用戶需求通過服務的方式自由組合。而這些都是通過與實施

31、細節(jié)無關(guān)的數(shù)據(jù)中心服務配置來完成。2.3.2 消息中間件醫(yī)用消息中間件是是一個基于TCP/IP的醫(yī)用網(wǎng)絡通訊框架，為SOA提供可靠的消息服務，其核心是通過消息隊列來實現(xiàn)一種應用程序?qū)贸绦虻耐ㄐ欧椒ǎ撼绦蛑g通過在消息中間件發(fā)送數(shù)據(jù)進行通信，而不是通過直接調(diào)用彼此來通信，應用程序通過寫和檢索出入列隊的針對應用程序的數(shù)據(jù)（消息）來通信，而無需專用連接來鏈接它們。我們把應用程序交由消息中間件傳輸?shù)臄?shù)據(jù)定義包裝為消息，我們定義消息的內(nèi)容主要包括消息的特征：消息發(fā)送時間、消息的優(yōu)先級、消息的接受者、數(shù)據(jù)地址、處理請求、消息ID、消息生命周期等等。消息隊列是消息的安全存放地,隊列為構(gòu)造以同步或異步方式

32、實現(xiàn)的分布式應用提供了松耦合方法，消息隊列的應用并不要求收和發(fā)送應用程序同時執(zhí)行，消息可駐留在隊列中，直到它們被應用程序讀走。通過消息隊列，應用程序可獨立地執(zhí)行-它們不需要知道彼此的位置、或在繼續(xù)執(zhí)行前不需要等待接收程序接收此消息。2.3.3 數(shù)據(jù)交換的傳輸模式按傳輸模式劃分，平臺提供以下兩種模式以適應應用系統(tǒng)之間的業(yè)務調(diào)用需求1點到點消息傳輸在點到點通信模型中，本系統(tǒng)數(shù)據(jù)傳輸支持應用程序與有標識的其它應用程序點交換信息。在此情況下，消息從一個應用程序發(fā)送至另一個應用程序，稱為數(shù)據(jù)分發(fā)。在其它情況下，數(shù)據(jù)交換涉及請求和回答的消息對，稱為請求/響應消息傳遞點到點交換支持同步與異步調(diào)用：消息發(fā)出后

33、，消息發(fā)送方進入等待狀態(tài)，等待接收消息的應用程序返回響應消息。從業(yè)務應用系統(tǒng)角度看，請求和響應的過程是同步的。消息發(fā)出后，消息發(fā)送方繼續(xù)其他處理流程。當接收消息的應用程序返回響應消息后，消息發(fā)送方再處理響應消息2發(fā)布訂閱消息傳輸有些應用程序不與特定應用程序關(guān)聯(lián)。它們對誰接收該消息或消息來自何處都沒特定要求。數(shù)據(jù)在任何時候?qū)θ魏胃信d趣的應用程序都是可用的，發(fā)送方或接收方不必相互知道。HCN實現(xiàn)發(fā)布訂閱模式數(shù)據(jù)傳送，任何一個發(fā)布者發(fā)布的消息都可以由多個訂戶接收。訂戶還可以接收多個發(fā)布者的同一主題或不同主題的消息。在此通信模式下，通過訪問控制表的安全性措施來控制消息的訪問。消息路由在大多數(shù)情況下，僅

34、僅移動數(shù)據(jù)是不夠的。確定衛(wèi)生部門其它系統(tǒng)各自需要什么樣的信息的能力是同等的重要。平臺交換中心端和前置段配合實現(xiàn)消息路由功能，將特定的數(shù)據(jù)集發(fā)送給選定的應用。路由規(guī)則定義在消息交換中心。消息交換中心通過消息頭中設定的參數(shù)進行數(shù)據(jù)路由處理。基本的路由請求有一對一、一對多兩種，提供單向發(fā)送、請求/回復、發(fā)布/訂閱等多種路由模式。消息交換中心還具有智能路由的功能，能夠根據(jù)消息的內(nèi)容來決定消息的路由。消息格式轉(zhuǎn)換該功能提供了實時的動態(tài)重新格式化信息的能力，從而使得信息能夠被異構(gòu)環(huán)境中的多個應用所接受和讀取。它針對不同的協(xié)議、編程語言、應用和硬件平臺，進行信息格式化分析，并對信息重新格式化。發(fā)送信息的應用

35、可以以單一的格式發(fā)出信息，而格式轉(zhuǎn)換器能夠自動地將信息重新格式化成一個被每一個接收信息的應用所要求的新格式。格式轉(zhuǎn)換器能夠理解應用程序間傳輸?shù)乃邢⒌母袷?，可以進行格式轉(zhuǎn)換：可以將某一消息中的數(shù)據(jù)重組為新的消息，因此它就可以為另一個應用程序所用。它相當于一本通用的辭典，可以理解應用程序的“語言”，并知道應用程序信息的哪一部分是有用的。工作流管理通過它可以實現(xiàn)對工作流的有效控制。工作流管理器可以捕獲和應用業(yè)務過程的信息，從而為企業(yè)提供了更強大的業(yè)務活動控制功能，包括對涉及應用程序和職員的活動，由此可以更快速地實現(xiàn)、改進和更新工作流。中心管理管理平臺主要通過遠程連接方式提供平臺各子系統(tǒng)的配置、運行控制、業(yè)務流程配置。管理對象包括前置機，