1、區域衛生信息平臺數據交換技術方案設計目 錄 TOC o 1-3 u 第一章區域衛生信息平臺系統架構 PAGEREF _Toc83370236 h 4第一節平臺架構分析 PAGEREF _Toc83370237 h 4一、平臺系統功能 PAGEREF _Toc83370238 h 4二、數據來源模式 PAGEREF _Toc83370239 h 7三、數據存儲類型 PAGEREF _Toc83370240 h 9四、系統架構類型 PAGEREF _Toc83370241 h 9五、隱私保護與信息安全 PAGEREF _Toc83370242 h 10第二章區域衛生信息平臺技術架構 PAGEREF

2、 _Toc83370243 h 11第一節總體技術架構 PAGEREF _Toc83370244 h 11第二節數據交換技術方案 PAGEREF _Toc83370245 h 12一、企業服務總線 PAGEREF _Toc83370246 h 12二、數據接口方式 PAGEREF _Toc83370247 h 16三、業務組件服務 PAGEREF _Toc83370248 h 18四、運行監控管理 PAGEREF _Toc83370249 h 29五、平臺配置管理 PAGEREF _Toc83370250 h 31六、技術方案選型 PAGEREF _Toc83370251 h 32第三章區域衛

3、生信息平臺部署模式 PAGEREF _Toc83370252 h 34第一節平臺應用架構 PAGEREF _Toc83370253 h 34第二節縱向分級部署模式 PAGEREF _Toc83370254 h 35第三節橫向擴展布署模式 PAGEREF _Toc83370255 h 37第四節其他應用模式 PAGEREF _Toc83370256 h 38第四章附錄 PAGEREF _Toc83370257 h 39第一節縮寫 PAGEREF _Toc83370258 h 39第二節主要參考文獻 PAGEREF _Toc83370259 h 39區域衛生信息平臺系統架構平臺架構分析平臺系統功能

4、基礎功能基于健康檔案的區域衛生信息平臺的使用對象主要是醫療衛生人員，最終的服務對象是居民和患者。醫療衛生人員為了更好的為居民和患者提供可靠的、可及的、連續的醫療衛生服務，需要依賴平臺提供的眾多服務。在平臺提供的這些服務中有些是很基礎但又很關鍵的服務，比如：個人的身份識別、健康檔案索引服務、以人為中心的存儲服務、數據交換服務以及數據調閱服務，下面將分別對這些基礎服務進行描述。1. 個人身份識別服務為了建立對區域范圍內各醫療機構業務聯動，實現數據共享或業務協同，對各醫療機構在個人身份上必須具有統一的身份機制，此項工作是作為區域衛生信息平臺建設的最為基本性的任務。人群分類情況從人群的整體來看，主要可

5、分為兩大類：參保人群：即參與了基本醫療保障的本地居民，目前主要是城鎮職工基本醫療保險、城鎮居民基本醫療保險、新型農村合作醫療的參保人。非參保人群：由于我國的國情決定了還有相當一部分人群（特別是在農村及經濟欠發達地區）未納入國家社會保障體系，或者是外來就醫人員，這里歸納為非參保人群。電子憑證分類情況電子憑證是指能識別個人身份的電子依據，在這里大多是指卡，卡的種類主要有醫療保障就醫憑證、醫院自費就醫憑證、市民卡或者其他電子憑證。居民身份識別需求由于發卡機構的多樣性，個人手中可能會有多張與醫療衛生相關的電子憑證，如個人可能同時擁有醫保卡、社保卡、婦保卡、健康卡等。在區域醫療衛生系統中，則需要將各業務

6、條線的健康檔案進行整合，因此會出現這樣的問題：區域范圍內持多張卡的同一患者，在系統里會被認為是多個人，即多張卡沒有對同一人進行關聯，這樣就可能造成無法調閱某個人完整的健康檔案。個人身份識別是區域醫療衛生系統所要解決的基本問題，對于本系統的建設起著至關重要的作用。2. 健康檔案索引服務健康檔案索引服務全面掌握區域衛生信息平臺所有關于個人的健康信息事件，包括居民何時、何地、接受過何種醫療服務，并產生了哪些文檔。健康檔案索引服務中主要記錄兩大類的信息：健康事件信息：包括時間、地點、健康事件名稱等；文檔目錄信息：包括臨床文檔、預防保健文檔等。3. 以個人為中心的存儲服務在區域衛生信息平臺中，針對個人的

7、數據包括：個人注冊信息庫、臨床診療信息庫、公共衛生信息庫、時序檔案信息庫。個人注冊信息主要是指個人身份信息，可供系統唯一標識個體身份，以便使相關業務數據與所記錄的對象建立對應關系。臨床就診信息主要包括就診患者基本信息、實驗室檢驗報告、醫學影像圖像檢查報告、醫學影像圖像文件、住院相關病案、就診患者的就診日志信息等。公共衛生信息是指與居民相關的疾病預防控制、精神衛生、婦幼保健等業務數據。時序檔案信息是指對與患者相關信息（包括臨床就診數據、疾病控制與管理數據等）建立的索引信息，此外還根據業務流程或預定義的規范對業務信息進行相關處理。4. 數據交換服務在區域衛生信息平臺中，數據交換服務是一個非常重要的

8、基礎功能。平臺需要從醫療機構獲取各種基礎的業務數據，這些數據的獲取都是通過平臺提供的數據交換服務來完成的。數據交換服務至少要提供如下的一些功能：適配器管理功能、數據封裝功能、數據傳輸功能、數據轉換功能、數據路由功能、數據推送功能、數據訂閱發布功能和傳輸監控等。5. 數據調閱服務區域衛生信息平臺從醫療機構中采集數據，并經過一系列的處理后存入數據中心，這些過程只解決了數據怎么來、怎么存的問題，還沒有解決怎么用的問題，這就要求平臺提供相應的數據利用方式來為醫療衛生人員提供服務。這些數據利用的方式包括：數據調閱、業務協同、輔助決策等，其中業務協同和輔助決策可以被看成是在平臺加載的應用系統，而數據調閱因

9、其通用性和安全性要求則被視為平臺的基礎功能給予提供。數據調閱服務是為醫療衛生人員提供的一種基于Web方式安全的訪問健康檔案的功能。互聯互通性目前醫療衛生機構中存在大量處理業務的信息系統，例如：醫院內的HIS、CIS、LIS、RIS、PACS等系統，社區服務中心內的HIS、LIS、CHIS等系統，公共衛生條線的疾控、婦幼等系統，這些業務系統被統稱為基本業務信息系統（Point Of Service，POS）。在現有條件下，要實現醫療機構內部信息系統應用之間的互聯互通問題，有兩種方式，其一是為所有醫療衛生機構新建業務系統，其二是建設區域衛生信息平臺來與醫療機構內部信息系統應用交互。平臺與醫療機構內

10、部信息系統應用的交互能力就是所謂的互聯互通性（Interoperbility）。平臺需要從醫療機構內部信息系統應用中獲取數據，平臺也向醫療機構內部信息系統應用提供信息共享、協同服務等功能。平臺與醫療機構內部信息系統應用之間的交互被視為互聯互通性一個應用場景。平臺從醫療機構內部信息系統應用獲取數據后需要內部各構件協同工作來提供對外服務，例如：注冊服務構件與全程健康檔案服務構件之間交互，這些平臺內部構件之間的交互也是互聯互通性的一個應用場景。概括而言，互聯互通性是系統與系統之間進行協作的技術規范，它包含兩個層面的含義，第一個層面是指系統與系統之間能夠進行數據交換，即消息層互聯；第二個層面是指系統能

11、夠認識并準確理解被交換數據的含義并且按照預期操作進行，即語義層互通。互聯互通規范主要包含兩大類內容，其一為描述醫療機構內部信息系統應用與區域衛生信息平臺之間的交互接口，被稱為健康檔案互聯互通規范；其二為描述區域衛生信息平臺內部各構件之間的協作行為，被稱為平臺互聯互通規范。數據來源模式孤島數據孤島數據是指那些不能相互共享利用、孤立的、分散的業務數據。根據當前我國醫療衛生信息化的現狀，可以看出多數的醫院內部信息系統存在“信息孤島”的現象，從而也就產生了相應的孤島數據。典型的孤島數據有：1. 社區健康檔案系統數據社區衛生服務中心所使用的健康檔案管理系統，大多數是為該社區的居民建立個人基本健康檔案，一

12、旦建檔完成后就保存在本地的服務器上，絕大多數的建檔檔案數據獨立存在于本社區內，既沒有被臨床診療相關的業務系統“激活”，也沒有被上級機構所采集共享以實現跨社區的聯動。該系統完全為建檔而建檔，建好的檔也就成為“死檔”，沒能體現應有的利用價值。2. 醫院信息系統（HIS）數據HIS系統一般是當前醫院首先建設的信息系統，主要是為實現以收費為中心的醫院內部信息管理，早期建設的HIS系統也是完全獨立于醫院內部，與醫院外的業務系統無任何聯動，有的甚至與醫院內部其他信息系統（如LIS、CIS等）也毫無關聯（因為往往同一家醫院HIS、LIS、CIS的開發分別由不同的開發商承擔，醫院難以協調開發商對多系統進行整合

13、）。3. LIS數據LIS是相對專業化程度較高的系統，每家醫院獨立使用這套系統，LIS數據僅存在于本醫院內部，當病人跨院就診時，往往需要重新檢驗，造成了大量的人力、財力的浪費，往往這也是造成老百姓看病難、看病貴的主要原因。4. PACS數據與LIS類似，PACS系統專業化程度高，由于產生的醫學影像數據也只存在于本醫院內，造成病人跨院就診時重復檢查，也是孤島數據的一個重要表現。5. 醫院體檢系統數據醫院建設的體檢系統也是完全獨立的，僅記錄來本院體檢人員的信息，與其他醫院內部業務系統無業務聯動。6. 其他除以上所涉及到的孤島數據外，其他醫療機構也存在類似的情況，如疾病預防控制中心的慢病管理系統等，

14、往往也是獨立存在的“孤島”。孤島數據的存在給醫療衛生從業人員帶來的很多的麻煩，如對于每個孤島系統都需要不斷錄入人員信息數據，極大地加重了醫療機構從業人員（特別是基層醫療機構，其中以社區衛生服務中心尤為突出）的工作量，導致工作效率低下等問題。煙囪數據煙囪數據是指以業務條線為主的業務數據。疾病預防控制業務系統、婦幼保健業務系統中的數據是典型的煙囪數據。目前我國廣大區域內疾控業務多以業務條線為主，如傳染病管理，每一個病重都是一個業務條線，從國家到省、地區、縣市、鄉鎮的縱向管理，與其他業務條線也是平行的，同樣也就造成了相關工作人員，特別是基層數據錄入人員的工作負擔。從管理上來看，煙囪數據的存在也造成了

15、相關業務條強塊弱的局面，為管理層帶來了很大挑戰。無系統數據由于區域內各醫療機構信息化水平參差不齊，很多社區衛生服務中心、衛生服務站（特別是中西部偏遠欠發達地區），并沒有建成區域信息平臺所需要的醫療機構內部信息系統（POS），因此造成基礎數據無法采集。對于這類區域醫療機構，需要在新建信息系統時，基于本區域平臺來建設，平臺提供將提供相關業務的數據標準，以便新建的系統能良好地集成到區域衛生信息平臺。數據存儲類型業務數據的類型主要包括文檔數據、操作型數據、輔助決策型數據。文檔數據：以文檔形式存在于平臺中的臨床和預防保健業務數據，例如檢驗報告、處方，傳染病報告卡等。這些數據是結果數據。操作型數據：操作型

16、數據存儲，在本指南中一般是指平臺從業務系統中采集、匯總、供實時業務查詢和統計使用的數據：操作型數據是從醫療機構內部信息系統采集上來的，不是由操作型數據所在的平臺產生的；操作型數據是從多個醫療機構內部信息系統數據源采集上來，并加以匯總的數據，不是醫療機構內部信息系統數據的簡單采集和堆積；從邏輯上操作型的數據結構基本與原來醫療機構內部信息系統數據源的類似，但是在匯總時會使用統一的基礎數據（例如居民信息、機構信息、代碼等），也會消除一些冗余信息；操作型數據主要服務于統一的即時查詢和實時的統計。輔助決策數據：存儲在數據倉庫中，以主題方式組織，是經過二次加工的歷史數據。系統架構類型區域衛生信息平臺涉及到

17、與居民健康相關的所有業務，因此其業務數據具有類型多、容量大的特點。根據業務數據的特點，對數據存儲的要求也不盡相同。系統架構與數據存儲的模式分為集中式、分布式和混合式。集中式存儲方式：集中存儲的優點是效率高且方法簡單，但擴展性和靈活適應性受到一定局限。在本系統建設中，對于居民基本信息（包括姓名、性別、出生年月、身份證號、社會保險號等），由于其使用頻率高，數據容量相對較小，可采用數據中心集中式存儲的方式；對于公共衛生信息，如疾病預防數據、婦幼保健數據、精神衛生數據，則采用中心集中存儲的模式，這樣可以保證該類數據的安全性。分布式存儲方式：分布存儲一般說來效率較低，技術實現復雜，但其擴展性和靈活性有很

18、大優勢。在本系統建設中，對于醫學影像信息，其數據量大，可采用分布式的存儲模式，這類信息通過注冊到區域衛生信息平臺，當醫療機構需要調閱時，可通過平臺查詢獲取數據所存儲的地址（一般為某醫療機構），再從目的地獲取所需要的信息。這樣既減輕了平臺的負載，也提高了數據的調閱效率，但缺點是對醫療機構之間的網絡要求較高，區域范圍內各醫療機構之間必須是雙向網絡，而且需要保證一定的帶寬。混合存儲方式（聯邦式）：對于其他業務數據（如實驗室檢驗數據、就診記錄數據），則可以根據實際的業務需求，采用分布式存儲+集中式存儲的混合模式。總的說來，區域衛生信息平臺可以支持這三種架構來實現數據存儲。隱私保護與信息安全隱私保護及信

19、息安全是區域衛生信息平臺所要重點解決的問題。主要體現在如下幾個方面：隱私保護的需求居民同意；匿名化服務；根據病種、角色等多維度授權；關鍵信息（字段級、記錄級、文件級）加密存儲；數據調閱對安全的需求身份認證的需求；角色授權的需求；責任認定的需求；電子簽名；時間戳。應用系統對安全的需求單點登錄；統一授權；應用審計。區域衛生信息平臺技術架構總體技術架構從前面的需求分析我們知道，基于健康檔案的區域衛生信息平臺是為區域衛生信息化提供一個以健康檔案數據為核心的開發和運行平臺，可以使用此產品快速的的定制、開發和部署區域衛生信息平臺項目，來滿足日益增加的區域電子健康信息共享與管理需求。因此基于健康檔案的區域衛

20、生信息平臺構架設計的目標是建立一個能夠容納管理個人健康檔案的可擴充的、開放的、可持續發展的構架，其包括以下方面：管理業務的擴充：能夠圍繞電子健康信息建立擴展新的健康管理業務，從公共健康管理的角度來看可以建立不同的疾病監控系統，從醫療服務者的角度看，可以查詢、調用以不同組織方式呈現的個人電子醫療檔案。存儲健康信息的擴充：能夠在系統中增加新的健康信息種類的存儲，比如新的醫療影像或檢驗結果。能夠根據每種存儲信息的特點對信息內容進行優化，但通過統一的接口對新的健康信息可以和已有的健康信息進行查詢、調閱。接入方式的擴充：區域電子健康信息中心面對的數據源和用戶是各個醫療機構及個人用戶，所以能夠接納各種現有

21、的和未來的應用系統的數據上傳及使用相當重要。中心構架需要能夠擴充對各種接入方式的支持。系統容量的擴充：區域電子健康信息中心是一個數據量龐大的信息系統，在設計時需要考慮對數據存儲容量的橫向擴充。系統處理能力的擴充：隨著區域電子健康信息中心使用者的增加，系統將承受大量的服務請求壓力。系統將使用分布式服務和集群等方式實現系統處理能力的擴充。為了實現上述的要求，建立一個穩定核心適用全國各地的軟件平臺，滿足各地區域衛生信息化的基本需要，同時還要滿足區域衛生信息化持續性發展的需求，因此我們將基于健康檔案的區域衛生信息平臺的總體技術框架設計如下：圖5-1 總體技術架構圖如上圖所示，基于健康平臺的區域衛生信息

22、平臺主要包括硬件網絡基礎設施層、數據中心數據層、業務服務層、數據交換層四個層次，還包括貫穿四個層次的標準規范體系和安全保障體系兩大體系。硬件網絡層是指支撐區域衛生信息平臺的硬件設備和網絡平臺，其是區域衛生信息平臺的基礎設施。數據中心層主要是實現基于健康檔案的區域衛生信息平臺的數據存儲，需要解決數據存儲的結構、模型、內容、數據庫管理軟件的選型等。數據交換層和業務服務層主要實現基于健康檔案的區域衛生信息平臺的數據采集、交換與共享，數據交換層是直接與外部系統進行溝通的技術層，業務服務層是基于數據交換層根據數據結構設計各種業務服務組件來完成平臺數據的采集，存儲與共享。標準規范體系是區域衛生信息平臺中必

23、須遵循和管理的數據標準，是平臺運行和應用的數據基礎。安全保障體系是從物理安全到應用安全保障整個平臺的正常運營。數據交換技術方案企業服務總線數據交換服務總線ESB是整個區域衛生信息平臺的技術核心，ESB通常采用面向服務的體系結構。該服務保證在一個異構的環境中實現信息穩定、可靠的傳輸，屏蔽掉用戶實際中的硬件層、操作系統層、網絡層等相對復雜、煩瑣的界面，為用戶提供一個統一、標準的信息通道，保證用戶的邏輯應用和這些底層平臺沒有任何關系，最大限度地提高用戶應用的可移植性、可擴充性和可靠性。提供一個基于應用總線的先進應用整合理念，最大限度地減少應用系統互聯所面臨的復雜性。系統的實現維護都相對簡單，保證每一

24、個應用系統的更新和修改都能夠實時地實現；同時當新的應用系統出現時能夠簡便的納入到整個IT環境當中，與其它的應用系統相互協作，共同為用戶提供服務。面向服務的體系結構（SOA）是一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行交互。這種具有中立的接口定義（沒有強制綁定到特定的實現上）的特征稱為服務之間的松耦合。松耦合系統的好處有兩點，一點是它的靈活性，另一點是，當組成整個應用程序的每個服務的內部結構和實

25、現逐漸地發生改變時，它能夠繼續存在。而另一方面，緊耦合意味著應用程序的不同組件之間的接口與其功能和結構是緊密相連的，因而當需要對部分或整個應用程序進行某種形式的更改時，它們就顯得非常脆弱。對松耦合系統的需要來源于業務應用程序需要，根據業務的需要變得更加靈活，以適應不斷變化的環境，比如經常改變的政策、業務級別、業務重點、合作伙伴關系、行業地位以及其他與業務有關的因素，這些因素甚至會影響業務的性質。我們稱能夠靈活地適應環境變化的業務為按需業務，在按需業務中，一旦需要，就可以對完成或執行任務的方式進行必要的更改。雖然面向服務的體系結構不是一個新鮮事物，但它卻是更傳統的面向對象的模型的替代模型，面向對

26、象的模型是緊耦合的，已經存在二十多年了。雖然基于 SOA 的系統并不排除使用面向對象的設計來構建單個服務，但是其整體設計卻是面向服務的。由于它考慮到了系統內的對象，所以雖然 SOA 是基于對象的，但是作為一個整體，它卻不是面向對象的。不同之處在于接口本身。SOA 系統原型的一個典型例子是通用對象請求代理體系結構，它已經出現很長時間了，其定義的概念與 SOA 相似。然而，現在的 SOA 已經有所不同了，因為它依賴于一些更新的進展，這些進展是以可擴展標記語言（eXML）為基礎的。Web 服務并不是實現 SOA 的唯一方式。但是為了建立體系結構模型，所需要的并不只是服務描述。您需要定義整個應用程序如

27、何在服務之間執行其工作流。尤其需要找到業務的操作和業務中所使用的軟件的操作之間的轉換點。因此，SOA 應該能夠將業務的商業流程與它們的技術流程聯系起來，并且映射這兩者之間的關系。例如，給供應商付款的操作是商業流程，而更新零件數據庫，以包括進新供應的貨物卻是技術流程。因而，工作流在 SOA 的設計中扮演重要的角色。此外，動態業務工作流不僅包括部門之間的操作，甚至還可以包括與外部合作伙伴進行的操作。因此，為了提高效率，需要定義應該如何獲取服務之間的關系的策略，這種策略常常采用服務協定和操作策略等形式。 所有這些都必須處于一個信任和可靠的環境之中，以同預期的一樣根據約定的條款來執行流程。因此，安全、

28、信任和可靠的消息傳遞應該在任何 SOA 中都起著重要的作用。消息交換技術最好具備如下特性：基于消息中間件技術，業務中心基于JAVA技術，J2EE標準。操作系統平臺、數據庫系統無關性，ESB應完全按跨平臺技術設計和實現，兼容目前所有常規操作系統和流行的數據庫系統。基于消息內容路由功能，集成工作流服務。消息交換符合XML標準，為專為國內衛生行業定制的總線消息協議，可通過協議轉換器與HL7等多種國際標準協議兼容。基于衛生行業各系統發展不平衡的現狀。整體EAI設計模式符合SOA(面向服務系統架構)。現有的體系結構模型和實踐往往是以程序為中心的。應用程序是以某個單一的醫療行業業務需要為出發點。通常，流程

29、信息在組件之間傳播。應用程序很像一個黑匣子，沒有粒度可用于外部。重用需要復制代碼、合并共享庫或繼承對象。在以流程為中心的體系結構中，應用程序是為過程開發的。流程可以分解成一系列的步驟，每一個步驟表示一個業務服務。實際上，每個過程服務或組件功能都相當于一個子應用程序。將這些子應用程序鏈接在一起可以創建能夠滿足業務需求的流程流。這種粒度允許利用和重用整個組織中的子應用程序。（1）服務請求方 在ESB構架中，服務請求方為發起請求的應用系統，通過ESB提供的源適配器，將請求消息發送到入點的前置服務器的發送隊列。源適配器為發送方應用系統與ESB數據中間交換總線的橋梁，適應目前醫療行業業務系統所采用的系統

30、平臺和開發語言有較大差異，各種平臺上都有對應的源適配器，支持C,COM,JAVA等不同開發環境。（2）消息中間件 消息隊列為構造以同步或異步方式實現的分布式應用提供了松耦合方法。消息隊列的API調用被嵌入到新的或現存的應用中，通過消息發送到內存或基于磁盤的隊列或從它讀出而提供信息交換。消息隊列可用在應用中以執行多種功能，比如要求服務、交換信息或異步處理等。在MQ中，隊列分為很多種類型，其中包括：本地隊列、遠程隊列、模板隊列、動態隊列、別名隊列等。本地隊列又分為普通本地隊列和傳輸隊列，普通本地隊列是應用程序通過API對其進行讀寫操作的隊列；傳輸隊列可以理解為存儲-轉發隊列，比如：我們將某個消息交

31、給MQ系統發送到遠程主機，而此時網絡發生故障，MQ將把消息放在傳輸隊列中暫存，當網絡恢復時，再發往遠端目的地。遠程隊列是目的隊列在本地的定義，它類似一個地址指針，指向遠程主機上的某個目的隊列，它僅僅是個定義，不真正占用磁盤存儲空間。根據應用邏輯劃分，ESB主要劃分成發送和接收兩種隊列：發送隊列接收隊列（3）服務提供方SOA設計中，將應用系統對外提供的實現了特定的、可標識的一組（業務）功能稱為服務。除了業務功能，ESB內配置的服務還實現中心管理接口，以及參與環境的邊界配置、操作和監視。數據接口方式為了實現各醫療衛生業務數據能夠與區域衛生信息平臺實現聯動，需要在醫療衛生機構部署數據交換前置服務部件

32、：以數據交換適配器的方式實現各分區醫療衛生信息系統（HIS、LIS、PACS、社區衛生系統等）的集成接入，按照SOA的設計理念，被集成系統需要與數據交換平臺交互的功能組件、數據組件將被封裝成“服務”，屏蔽被集成系統所采用的具體技術及其實現方式，以標準的接口方式與數據交換平臺銜接。同時根據需要部署前置數據庫，進行交換數據的前置緩存。各個應用系統通過與服務總線ESB實現消息交互。通過在業務系統端安裝相應的軟件適配器，實現與消息交換中心的信息交互。適配器由軟件模塊、軟件配置文件、應用編程接口等組成。在消息總線系統的整體設計架構中，各個具體的業務系統通過Adapter連接到消息消息交換平臺收發業務數據

33、。適配器起著耦合消息交換平臺與具體業務系統的作用。在我們的方案中有三種適配器：標準適配器、專用適配器和商用適配器。標準適配器是由標準的Adapter Kernel和API組成。Adapter Kernel實現和消息交換中心的消息交互和對消息的實時監控，并提供將消息分發到應用系統的功能。API是為應用系統提供的一套標準的接口，具有足夠的擴展性，可以靈活地嵌入到業務流程中，同時將與業務無關的通訊配置定義與業務代碼隔離。具體地，Adapter實現以下的功能：（1）實現消息的安全、可靠傳遞；（2）實現消息的透明傳遞，Adapter的實施者不必關注傳遞技術細節；（3）接口通用化，降低因開發架構不同導致的

34、業務應用側編程復雜性；（4）實現具有共同性的消息封裝、變換、接收功能。例如，加解密/校驗/字符集變換及HCN-XML標準協議；（5）簡單的遠程安裝配置方法，適配器的函數調用庫可以平滑升級而不影響業務應用；（6）可以與消息交換平臺交互管理信息，實現流量控制、報文蓄積、本地日志等功能。有關適配器組件的有關功能說明如下：（1）總線連接器功能概述：連接MQ隊列管理器和隊列，發送和接收消息。在其內部封裝了MQ提供的連接、收發消息等接口。它與其他組件/子模塊通過內部調用機制傳遞控制信息，和消息處理器通過內部接口傳遞處理好的消息。總線連接器不對消息內容做任何處理。（2）日志管理器功能概述：記錄運行日志和錯誤

35、日志，提供不同內部函數對應不同日志記錄要求。（3）配置管理器功能概述：讀取配置文件和業務對象定義以供初始化使用；生成對應消息控制數據（如消息路由、應用程序標志、消息類型）。（4）異常處理器功能概述：負責異常處理。根據異常定義，提供異常處理函數；標準化異常處理流程；和日志管理器配合記錄錯誤日志。（5）消息處理器功能概述：負責消息的轉換、封裝、提取。主要功能如下： 總線消息的封裝、提取。提供出口函數接口以實現業務對象與集成消息之間的轉換。（6）專用適配器管理器功能概述：目標端的主控程序，負責協調各個模塊之間的運行關系。啟動之后，主控程序通過配置管理器提供的信息啟動一個或多個工作進程管理器。（7）消

36、息分發控制器功能概述：消息分發服務器的主控程序，負責協調消息分發服務器各個模塊之間的運行關系。（8）工作進程管理器功能概述：負責啟動和控制工作進程。主控程序根據配置信息啟動工作進程管理器，每個工作進程管理器對應一個MQ本地隊列（消息分發服務器將單一接收隊列中的消息根據不同的應用發送到指定的隊列）。工作進程管理器可以根據配置啟動一個或多個工作進程從而提高消息傳遞的效率。（9）工作進程功能概述：完成一系列的消息處理工作。主要工作任務是：從配置管理器中獲取信息（如MQ連接配置，該應用類型，消息控制信息等）。實例化消息處理器，封裝和轉換消息。實例化日志管理器，實時記錄各種日志。實例化異常管理器，在運行

37、時實時捕捉異常并處理異常。實例化消息總線連接器，用于與消息交換中心交互消息。實例化外殼，與應用系統交互消息。根據工作進程管理器的指令，實現對有關資源的控制。（10）消息分發器功能概述：負責將接收到的消息分發到本地隊列。消息分發器負責將該接收隊列的消息根據消息體里的應用標志分發到各個指定的本地隊列中。（11）接口功能概述：提供連接應用系統的接口，不同的應用系統對應不同的外部接口。（12）標準接口功能概述：提供連接應用系統的標準接口。（13）文件接口功能概述：提供文件傳輸接口。業務組件服務公共服務1監控日志服務監控日志服務用來記錄系統中所處理的業務和系統事件，用戶可以通過統一界面配置和瀏覽所記錄的

38、事件。平臺中將設計一系列事件體系，包括業務事件和系統事件。各個模塊都可以定義各自的所產生的事件，并且通過平臺統一的接口進行記錄。監控日志服務將根據用戶對監控日志服務的配置對事件進行記錄。系統同時將提供一個集中式監控日志瀏覽接口，此接口將分析所有事件記錄文件，用網頁界面方式供用戶查詢和瀏覽。2標準轉換服務標準轉換服務是用來將一種XML格式的文件通過XSLT轉換成另一種格式。一種典型的應用是當用戶調用某個病人的記錄時，系統將記錄從XML格式轉換為健康檔案瀏覽器可以顯示的HTML格式。標準轉換服務可以將原始醫療記錄轉換為系統標準醫療信息數據結構。標準轉換服務是保證數據長期有效的根本服務。在系統中隨著

39、應用的升級，系統中會積累各種歷史格式的數據，只用通過變形在使用中轉換歷史數據，才可以保證數據的可用性和統一性。3權限驗證服務權限驗證服務用來根據已認證用戶的角色來決定是否用戶有權限執行指定的操作。權限驗證服務提供驗證和認證兩方面的功能。驗證功能有兩種方式：顯示認證和隱式認證。顯示認證需要用戶主動輸入用戶名和相應的用戶密碼或其他認證方式。在權限驗證服務通過密碼認證了此用戶后，用戶才可以用此認證用戶的身份來調用他能夠調用的服務。隱式認證是指用戶或其系統使用以配置好的非對稱密鑰等系統直接認證其身份，不需要主動輸入用戶名和密碼。系統可以根據其配置直接賦予其所對應的驗證用戶的身份。認證功能將基于用戶的角

40、色定義，賦予某種角色的用戶可以擁有與角色相應的權限。用戶的驗證和認證管理將被實現為Web Service的一種服務，具體的用戶信息和角色信息的存儲將被存入LDAP服務器。用戶信息將和個人, 醫師和機構綁定。每個服務被調用前，如果需要對調用者進行驗證和認證，會先調用驗證服務確定調用者的身份，然后調用認證服務確認調用者的權限是否能夠調用此服務。4隱私管理服務隱私管理服務用來制定從法律，制度和個人要求等幾個方面對個人醫療信息的訪問進行限制和授權。系統將會指定一個通用的授權制度，比如說允許急救室訪問所有病人的醫療信息，或者允許病人訪問過的醫院里的醫師訪問此病人的所有信息。系統也可以允許病人自定義授權條

41、件，允許某些醫師或某些醫療機構訪問自己的醫療信息記錄。隱私管理服務將被實現成Web Service服務。系統中將醫療信息記錄按照種類或者條目制定記錄ID，在實現時，將為每個用戶建立一個授權映射表，指出某些醫師或機構已經被授權訪問哪些信息。5數據加密服務數據加密服務實現對系統中的關鍵數據加密保護，其子功能包括密鑰管理功能、字段加密功能和WS-Security加密功能。可能加密的數據包括電子健康信息(使用個人、醫師或醫療機構密鑰)，傳輸信息包和密碼等信息。加密所用的非對稱密鑰由注冊服務保存，最終存放在LDAP服務器中。6數字簽名服務數字簽名服務實現對系統中的信息包進行數字簽名，保證數據的完整性和不

42、可抵賴性，其子功能包括針對字段的電子簽名和針對XML的電子簽名。可能加密的數據包括電子健康信息(使用個人、醫師或醫療機構密鑰)等信息。加密所用的非對稱密鑰由注冊服務保存，最終存放在LDAP服務器中。7目錄管理服務目錄管理服務是提供系統內外所用到的服務信息格式的注冊服務。在注冊信息格式的同時，目錄管理服務還保存與此服務相關的描述信息。通訊服務1數據緩存服務數據緩存服務提供一個醫療機構端原始醫療數據上傳過程中的緩存機制，在大批量原始數據的上傳過程中，保證了電子健康信息中心的其他服務的響應時間和穩定性。醫療機構端原始醫療數據上傳可以采用準實時和批量上傳的形式。當數據上傳至中心之后，中心將根據不同數據

43、來源來對原始數據進行變形、驗證、導入和注冊等工作。由于電子健康信息中心的龐大數據量，每條上傳數據的處理將會耗用大量系統資源，造成中心響應時間的下降。相對于中心的其他服務，比如醫療數據調閱等服務來說，數據上傳是一個低優先級的服務要求，對于實時性的要求相對較低。數據緩存服務就是實現這個功能，當原始數據上傳至中心后，數據緩存服務將數據立即存于可靠的數據緩存中。后續服務會在系統資源允許時從緩存中讀取原始記錄，調用后續服務將原始記錄轉換成中心標準格式，注入到信息中心存儲服務中。2通訊服務協議HTTP/SOAP 通訊服務協議提供標準Web Service接入服務。作為最為廣泛接受的Web Service接

44、入方式，各醫療衛生系統提供商都可以用最少的開發時間，根據各自的技術解決方案，用各種開發工具提供醫院原始健康信息的上傳功能。同時，HTTP/SOAP 通訊服務還提供了SOA服務的主要調用方式。整個平臺使用了基于Web Service的SOA設計理念，會提供大量Web Service服務來提供具體定制和擴充的要求。HTTP/SOAP是主要外部Web Service調用協議。3FTP通訊服務FTP通信方式提供了平臺直接從外部FTP服務器上查詢可用文件，下載數據文件，并將數據文件遞交給相關處理流程的功能。對于一些HIS廠商來說，使用FTP上傳原始醫療數據是一種簡單的上傳方式。此平臺提供的FTP模塊，可

45、以定時到目標FTP服務器中(可能在醫院端，也可能是建立在中心)，定時地查詢原始數據文件是否已經上載到指定目錄。如果已經上載，FTP將依次下載可用的數據文件，將每個文件單獨地送入處理流程處理。對于已經處理的文件，可以選擇在目標FTP服務器上刪除或者改名作為處理完的標記。注冊服務1個人注冊服務個人注冊服務是平臺中的最主要服務之一，其主要功能是維護和提供醫療服務的接受者，比如病人等的唯一標識信息，個人信息和與外部系統中的標識映射信息。對于電子健康檔案信息中心平臺來說，必須針對一個個人在系統中擁有一個唯一的標識，也就是個人唯一標識。個人唯一標識被廣泛地用于和系統中和個人相關的所有信息中，比如共享醫療檔

46、案，醫療影像庫等。同時，系統中還需要存放個人的相關信息，比如名字、性別、年齡、籍貫等等，這些信息將和個人唯一標識綁定，存放在個人注冊服務服務中。個人唯一標識和相關信息的使用可以有效地防止歧義，保障長期醫療信息的一致性，并可以用來提供個人搜索等服務。由于健康檔案采集于各個醫療服務機構，無法被強制統一的上傳的原始醫療記錄中的個人標識。當原始醫療記錄被規范成中心標準格式后，此記錄需要對應到中心的相關記錄中。個人注冊服務的個人標識映射功能就是用來將不同來源記錄中的個人標識映射為中心的個人唯一標識。此類映射可以分為自動映射和人工干預映射兩種。個人注冊服務提供的主要服務包括：搜索個人：從輸入的個人相關信息

47、搜索個人唯一標識；增加新個人：創建一個新個人唯一標識和相關個人信息；合并個人：合并兩個個人唯一標識和相關個人信息；搜索中心標識：根據輸入的來源信息和來源標識找出對應的個人唯一標識；模糊搜索中心標識：根據輸入的個人相關信息，自動匹配最相關的個人唯一標識；搜索外部標識：根據來源信息和個人唯一標識找出對應外部系統的個人標識；設置外部標識映射：設置外部標識，來源信息和個人唯一標識的映射關系。個人注冊服務是以Web Service的形式實現，各服務是直接提供給各模塊使用，使用隱式認證方式，但不允許非認證用戶使用。服務定義將借鑒IHE PIX的定義，實現相近的功能。對于模糊查詢可能考慮使用開源搜索引擎搜索

48、相關度最高的結果。模糊查詢的關鍵信息包括：姓名、性別、年齡、身份證號、社保號、住址、電話號碼。合并個人標識和設置外部標識映射功能需要人工干預，相應的用戶界面和邏輯將在應用服務器中實現。2醫師注冊服務醫師注冊服務主要功能是維護和提供醫療服務的提供者，比如醫師、護士等的唯一標識信息，醫師信息和與外部系統中的標識映射信息。由于醫師的注冊機制比較嚴密，醫師注冊服務比個人注冊服務少了模糊查詢和合并醫師等功能。除此之外，每個醫師都會映射到機構注冊服務維護的醫療機構中，在現實中就是該醫師注冊的醫院或診所。在醫師信息中，還增加了醫師的公鑰信息，用來在某些記錄中對醫療記錄進行加密或簽名，以滿足某些場合安全性的需

49、要。醫師注冊服務提供的主要服務包括：搜索醫師；增加新醫師；搜索中心標識；搜索外部標識；設置外部標識映射；設置醫師公鑰；設置醫師服務機構。醫師注冊服務是以Web Service的形式實現，各服務是直接提供給各模塊使用，使用隱式認證方式，但不允許非認證用戶使用。設置醫師公鑰、設置醫師服務機構和設置外部標識映射功能需要人工干預，相應的用戶界面和邏輯將在應用服務器中實現。3機構注冊服務機構注冊服務主要功能是維護和提供醫療機構，比如醫院等的唯一標識信息、機構信息。醫療機構所上傳的病人原始健康信息將帶有醫院的唯一標識以利于中心歸檔映射。在機構信息中，還增加了機構的公鑰信息，用來在某些記錄中對醫療記錄進行加

50、密或簽名，以滿足某些場合安全性的需要。機構注冊服務提供的主要服務包括：搜索機構；增加新機構；搜索機構標識；設置機構公鑰；機構注冊服務是以Web Service的形式實現，各服務是直接提供給各模塊使用，使用隱式認證方式，但不允許非認證用戶使用。設置機構公鑰、增加新機構功能需要人工干預，相應的用戶界面和邏輯將在應用服務器中實現。4醫學名詞注冊服務醫學名詞注冊服務主要功能是維護和提供中心醫療名詞定義和醫療機構的名詞定義之間的映射定義。在中心的醫療記錄中，所有的醫療名詞都會以標準的名詞定義以保證一致性和支持統計功能。醫學名詞注冊服務提供的主要服務包括：機構至中心名詞映射；中心至機構名詞映射；名詞映射定

51、義。醫學名詞注冊服務的映射功能是以Web Service的形式實現，各服務是直接提供給各模塊使用，使用隱式認證方式，但不允許非認證用戶使用。醫學名詞注冊服務的名詞映射定義可以使用文件注入和界面設置來實現。全程健康檔案服務1數據標準化服務標準化服務組件將各種非標準化的數據格式轉換為系統所認知的統一的標準數據格式，同時也負責對單次的收集數據完整性進行校驗。標準化服務組件的運轉需要依賴于數據標準管理服務組件。所有能夠被標準化以及標準化后的數據結構必須在數據標準管理服務上已經被注冊，標準化服務通過Metadata的定義對這些數據格式進行認知和校驗。標準化服務的校驗實現是通過Xslt和Metadata的

52、數據庫中的定義共同完成，原則上基于效率考慮只針對這些這些數據的完整性通過Xslt進行校驗，如果需要進一步的嚴格校驗，則需指定相應的校驗域，通過Metadata對這些域中的數據以及邏輯關系進行更進一步的校驗。數據庫格式的轉換是通過標準組件中的標準轉換服務組件實現的。標準轉換服務通過XSLT將一種XML格式的文件轉換成另一種格式。原則上此組件只完成相對較簡單且固定的轉換操作，復雜的轉換和具有特殊性要求的且和一定業務邏輯相關的操作將都交給業務規則服務組件完成。2業務規則服務業務規則服務是系統中對具體業務規則進行實現的一類服務組件，它們負責對業務中的邏輯進行處理，通過對數據裝載、主鍵管理、健康檔案索引

53、等服務的調用以及對數據中具體指標的判斷，執行不同的業務處理。比如說診斷信息的收集中，如果有一定業務要求，需要對某種傳染病進行監控，則就在業務規則服務中加載此項服務判斷，對此信息進行分段處理。業務規則服務可以通過兩種模型實現，一種是通過標準的過濾服務對其中的一些關鍵數據域進行抽取后重新啟動一個已經被定義業務流程進行處理，另外一種可以在遵循標準接口的前提下，通過硬編碼的方式將業務規則注入到系統中。過濾服務是一種通用的業務規則服務，可以通過配置實現一些簡單的數據分離過濾功能，僅僅適用于那些簡單的數據過程，對于復雜的邏輯處理都應放在硬編碼的業務規則實現上，不宜將過濾服務認為是一個萬能服務，通過非常復雜

54、的配置實現某一業務功能。使用硬編碼的方式可以實現所有復雜的業務邏輯，硬編碼過程中應將盡量通過調用數據裝載服務這樣的標準組件來實現通用功能，硬編碼只做一些邏輯運算為主的工作。3索引服務索引服務是健康檔案快速定位目錄，通過健康檔案索引，能夠迅速定位相關的健康信息所在的存儲位置，方便數據裝載服務能夠迅速讀取其健康信息。健康檔案索引的編目方式主要以時間為維度縱向展開，主要的索引方式為時間和唯一編號，他和健康檔案摘要服務共同構成主要查詢體系。健康檔案索引的方式是多樣的，它獨立于健康檔案存儲存在，在數據進入健康檔案存儲時即根據制定的一定規則去生成相關的索引。同樣的一個數據可能具備多種索引，比如診斷索引，藥

55、品索引，健康時間索引等。其不同的索引目的是針對不同的查詢能夠迅速去定位相關信息，被索引的字段一般為已經能夠被確定結構化的信息，如診斷編碼、藥品編碼、健康事件號、健康事件類型等。索引本身僅僅是原數據的關鍵信息抽取，不作為統計分析使用。也不會因為版本的升級而變化，即使系統建立后仍然可以添加索引，索引系統可以基于健康檔案存儲數據進行動態的增減。4摘要服務健康檔案摘要服務是針對個人健康檔案信息的一個概括性快照，它從健康檔案信息中抽取關鍵性指標，生成一個能夠描述個人當前健康狀況以及主要健康事件的信息文本，包含一定的關鍵域，客戶端能夠通過這些關鍵域同健康檔案索引服務關聯起來，去定位當前個人健康狀況中的關鍵

56、性問題。健康檔案摘要服務提供查找以及生成來兩個功能，健康檔案摘要的存儲是獨立健康檔案存儲的獨立系統，客戶系統中默認情況，將首先調用該服務去了解個人健康概況，然后再去進一步深入調閱其他信息。5健康檔案地址服務在一個區域醫療信息網絡中，并非所有的信息都被集中存放在平臺中，這些信息可能分布在區域中的一些醫療機構中，也可能分布在另外一個區域醫療信息中。為了解決上述情況的健康信息調運，健康檔案地址服務提供每條醫療信息記錄的真實存放地址，在數據讀取過程中，讀取服務會通過健康檔案地址服務查詢到真實存放地址，地址信息包括：存放服務器地址，存放服務名等信息。這些存放服務器都需要實現統一的基于Web Servic

57、es的數據存儲服務，同時使用非顯性認證機制來解決安全問題。數據讀取服務可以通過健康檔案地址服務直接到遠端系統中讀取相關數據。如果數據是存放在中心中，可以考慮使用本地服務，快速讀取數據。在存放數據時，存放服務根據上傳數據的情況，通過健康檔案地址服務插入每條記錄的地址信息，以提供將來讀取需要。 健康檔案地址服務中的地址數據是存放在獨立的數據表中，通過外鍵與健康檔案索引聯合。針對健康檔案索引中的每一條數據，都可以查詢到相應存放地址。由于健康檔案是通過數據調用服務來使用的，對于系統中的其他服務來說健康檔案地址服務是透明的，不需要針對健康檔案地址服務進行任何操作。數據存儲服務健康檔案的存儲主要分成三種類

58、型，健康檔案數據存儲（EHR Data Storage）、業務數據存儲（Business Data Storage）、數據倉庫存儲（Data Warehouse）。健康檔案的數據存儲并不和某一數據庫進行綁定，他的存儲模式有文件系統存儲和數據庫存儲兩種模式。1數據元管理服務數據元管理服務的功能是提供醫療數據的格式定義，管理和激活驗證等活動，保證中心中保存的電子健康信息的數據一致性和長期的可用性。為了保證醫療數據的統一完整，每個國家都在制定電子健康信息數據格式。在中國，各個醫療域的醫療數據格式標準正在制定完善中。基于此現狀，此平臺產品將提供以下功能：元數據定義工具來導入、創建中國醫療信息數據元數據

59、集標準；元數據定義的多版本定義功能，支持對數據元數據集的升級；元數據到XML Schema的映射定義，直接生成XML Schema文件；元數據定義和XML Schema在Metadata Repository Server上集中保存；元數據上載、卸載至全程健康檔案服務服務；元數據和電子醫療數據的映射和激活使用。2數據裝載服務數據裝載服務是從健康檔案數據存儲中攥取數據以及存儲數據的底層數據服務，它負責將業務服務分離出來的實際數據保存入最后的物理存儲（數據庫或者文件方式存儲）中，同時也負責從物理存儲中讀取數據為各業務提供所需的素材。它對實際讀取和存儲的內容并不敏感，只負責根據確定的指令進行讀取和存

60、儲，其作用是隔斷業務操作和實際存儲中的緊密耦合，使得存儲環境的變化不影響到原來的業務操作。ELs是一種邏輯接口服務，它有兩類實現組件，一種為File_ELs(文件系統EL服務)，一種為DB_ELs(數據庫EL服務)。File_ELs針對文件存儲類型的數據進行讀取和裝載操作，它根據操作的不同分別調用File_Extract Svc（文件攥取服務）和File_Loader Svc(文件裝載服務)。File_Extract Svc負責從文件系統中讀取已經指定位置的文件，同時將文件的二進制流分裝入一個帶有文件名稱、文件類型、長度等基本信息的XML回應包中，傳送回調用方；File_Loader Svc服