醫(yī)療行業(yè)數(shù)據(jù)交換與共享技術方案

1、醫(yī)療行業(yè)數(shù)據(jù)交換與共享技術方案目錄1 方案概述 41.1 背景 41.2 參考規(guī)范 52 需求分析 72.1 交換內容 72.2 功能需求 73 總體建設方案 93.1 實現(xiàn)思路 93.1.1 交換方案比選 93.1.2 技術優(yōu)勢 103.2 總體架構 113.3 數(shù)據(jù)交換與共享基本模型 123.3.1 分布模式 123.3.2 混合模式 133.3.3 數(shù)據(jù)交換與共享平臺交換流程模型 133.4與內部業(yè)務系統(tǒng)的交換方式 153.4.1 被動交換方式 163.4.2 主動交換方式 163.4.3 交換方式建議 173.5與區(qū)域衛(wèi)生信息平臺的交換方式 183.5.1 邏輯架構 183.5.2 數(shù)

2、據(jù)上傳的內容和要求 183.5.3 醫(yī)療機構數(shù)據(jù)提交方式 193.5.4 數(shù)據(jù)上傳的時間點 204 產品概述 214.1 技術實現(xiàn)框架 214.2 中心交換子系統(tǒng) 224.3 前置交換子系統(tǒng) 234.3.1 交換流程管理 234.3.2 數(shù)據(jù)轉換 244.3.3 消息路由 254.3.4 插件系統(tǒng) 264.3.5 適配器集成 264.4共享信息庫 264.5 平臺特點 274.5.1支持行業(yè)標準 274.5.2 擴展性強 274.5.3 適應性強 274.5.4 易于使用 284.5.5 易于維護 284.5.6 可重用 285 實施步驟 291 方案概述1.1 背景隨著我國醫(yī)療衛(wèi)生事業(yè)的發(fā)展

3、，國內的醫(yī)療信息化建設已經取得顯著成果， 絕大部分三級醫(yī)院和部分先進的二級醫(yī)院信息化程度都已很高。 主要的醫(yī)療業(yè)務 信息化系統(tǒng)包括 HIS（Hospital in formation system，醫(yī)院信息系統(tǒng)）、EMR（Electronic medical records ，電子病歷系統(tǒng)） 、 PACS（Picture archiving and co mmunication system ，醫(yī)學影像存檔與通信系統(tǒng)） 、 LIS（Laboratory informati on system，檢驗信息系統(tǒng)）、UIS（Ultrasou nd in formation system，超聲信息系統(tǒng)）

4、、 ECGIS（ECG network information system ，心電網絡信息系統(tǒng)） 、 PEIS（P hysical examination information system ，體檢管理信息系統(tǒng)） 、其他業(yè)已建 設完成或在逐步建設中的各類信息化系統(tǒng)等。上述信息化系統(tǒng)的建設，完成了醫(yī)療信息化過程的第一個步驟，逐步實現(xiàn)醫(yī) 療業(yè)務數(shù)據(jù)的信息化采集與存儲。 醫(yī)療信息系統(tǒng)地不斷深入應用， 使得醫(yī)院對醫(yī) 療信息化的渴求已經從簡單的醫(yī)療業(yè)務數(shù)據(jù)采集與存儲發(fā)展到了對醫(yī)療業(yè)務數(shù) 據(jù)的共享與交換，并逐步向醫(yī)療業(yè)務數(shù)據(jù)的分析與挖掘方向延伸。由于醫(yī)療信息化過程是一個漫長的逐步發(fā)展逐步演變的過程，

5、所以造成了醫(yī) 療業(yè)務系統(tǒng)之間存在著種種的差異。 醫(yī)院的各個醫(yī)療業(yè)務信息化系統(tǒng)由不同的應 用程序開發(fā)商分別在不同的時間進行設計、 安裝部署，數(shù)據(jù)定義及存儲方式有著 各自的特點。 這些都給醫(yī)療業(yè)務數(shù)據(jù)的共享與交換帶來了一定阻礙。 這些醫(yī)療業(yè) 務系統(tǒng)存在著體積龐大、 內容繁雜、 業(yè)務規(guī)則復雜等特點。 從整體上來看這些醫(yī) 療業(yè)務系統(tǒng)間存在以下區(qū)別：1）系統(tǒng)開發(fā)商不一致；2）硬平臺不一致；3）開發(fā)語言不一致；4）數(shù)據(jù)格式不一致；5）通訊協(xié)議不一致。所以各個醫(yī)療業(yè)務子系統(tǒng)在開發(fā)部署時并未考慮到其他相關聯(lián)業(yè)務子系統(tǒng) 間的相關性， 并未考慮到為其他業(yè)務子系統(tǒng)提供適合的數(shù)據(jù)共享與交換方式。 從 而導致了在各個醫(yī)

6、療業(yè)務子系統(tǒng)間無法進行數(shù)據(jù)交換、 數(shù)據(jù)共享。 對于各個醫(yī)療 業(yè)務子系統(tǒng)來說， 從各自的角度出發(fā)， 維護管理了許多不該由自己來進行維護管 理的基礎性數(shù)據(jù)。 同時又由于沒有順暢的渠道去獲取需要的相關數(shù)據(jù)， 導致醫(yī)療 業(yè)務系統(tǒng)間無法進行聯(lián)動，共享醫(yī)療業(yè)務數(shù)據(jù)，存在的問題如下：1) 數(shù)據(jù)重復輸入；2) 數(shù)據(jù)重復存儲；3) 數(shù)據(jù)無法共享；4) 系統(tǒng)維護難度大；5) 醫(yī)務流程分散于各系統(tǒng)中；6) 整合各系統(tǒng)的難度很大。 隨著醫(yī)院的發(fā)展，信息化的需求在改變，業(yè)務處理流程也在隨著信息化的進 展而發(fā)生變化。 在原有的分散模式下， 各醫(yī)療業(yè)務子系統(tǒng)無法很好地適應業(yè)務處 理流程的變化而變化， 每次業(yè)務流程的變換均需

7、要針對業(yè)務流程進行有針對性地 再次開發(fā)， 造成系統(tǒng)維護的困難。 雖然醫(yī)院已經針對各醫(yī)療業(yè)務部署實施了相應 的信息化系統(tǒng)， 實現(xiàn)了醫(yī)療業(yè)務的信息化處理。 但是總體來說這些醫(yī)療業(yè)務系統(tǒng) 的部署實施反而造成了一個個的“信息孤島” ，限制了醫(yī)療信息化的程度和醫(yī)療 信息化的效果。隨著醫(yī)院對醫(yī)療信息化需求的轉變， 要求在這些醫(yī)療業(yè)務子系統(tǒng)間進行數(shù)據(jù) 共享與交換，進一步整合各個醫(yī)療業(yè)務子系統(tǒng)，構建統(tǒng)一的醫(yī)療業(yè)務平臺。結合醫(yī)療行業(yè)信息化的特點， 提出了“醫(yī)療行業(yè)數(shù)據(jù)交換與共享” 解決方案， 打破存在于醫(yī)院中的各種 信息孤島 ，使得醫(yī)院信息化發(fā)展進一步邁入數(shù)據(jù)交換 與共享平臺，進一步挖掘醫(yī)療數(shù)據(jù)的作用。1.2

8、參考規(guī)范1) WS/T 303-2009衛(wèi)生信息數(shù)據(jù)元標準化規(guī)則2) WS/T 305-2009衛(wèi)生信息數(shù)據(jù)集元數(shù)據(jù)規(guī)范3) WS/T 306-2009衛(wèi)生信息數(shù)據(jù)集分類與編碼規(guī)則4) WS 365-2011 城鄉(xiāng)居民健康檔案基本數(shù)據(jù)集5) 基于健康檔案的區(qū)域衛(wèi)生信息平臺建設指南6) 基于健康檔案的區(qū)域衛(wèi)生信息平臺建設技術解決方案(試行)2 需求分析2.1 交換內容目前，醫(yī)院各信息系統(tǒng)中需要交換與共享的數(shù)據(jù)大致可以分為運營類信息和 醫(yī)院管理類信息。其中，運營類信息需要進行交換和共享的主要內容有： 主要來源于門診、 藥 房、醫(yī)技科室、醫(yī)生站、護士站等業(yè)務。內容包括門診業(yè)務信息 （ 門急診流量、

9、掛號、門診收費、科室及醫(yī)師工作量、 病人資料、處方用藥等 ） 、住院業(yè)務信息 （病 人費用、住院病人統(tǒng)計分析、死亡病人統(tǒng)計分析、床位使用狀況、用藥情況統(tǒng)計 等） 、病案首頁業(yè)務信息 （ 分科醫(yī)療費用、診斷質量、手術質量、登記統(tǒng)計表、疾 病分類、年齡分類、單病種質量控制、部分病種費用、死亡分類情況、產科情況 統(tǒng) 計，就診病人來源、病案質量情況等 ） 、藥品業(yè)務信息、醫(yī)技業(yè)務信息、醫(yī)療 保險信息、處方醫(yī)囑信息、科研教學信息、疾病發(fā)病信息、病人死亡信息、醫(yī)院 衛(wèi)生統(tǒng)計報表、醫(yī)療資源信息等。其中門診業(yè)務信息、住院業(yè)務信息、病案首頁 業(yè)務信息是醫(yī)院醫(yī)療業(yè)務共享信息的主要組成部分；醫(yī)院管理類信息需要交換和

10、共享的內容為： 醫(yī)療服務費用信息， 大型設備使 用信息和醫(yī)院財務、人事、后勤管理信息等。2.2 功能需求從服務的角度來看， 數(shù)據(jù)交換與共享平臺必須具備消息傳輸、 數(shù)據(jù)整合、 服 務集成和流程驅動的功能。 從管理的角度看， 數(shù)據(jù)交換與共享平臺必須具備一定 的管理功能，這些管理功能為客戶端的接入、 交換的數(shù)據(jù)標準、 各種業(yè)務規(guī)則等。1） 消息傳輸 以消息的機制建立接入業(yè)務系統(tǒng)和數(shù)據(jù)交換與共享平臺的數(shù)據(jù)傳輸通道可 以較好的滿足應用對于交換的各類需求， 例如：異步的數(shù)據(jù)交換需要、 可靠的數(shù) 據(jù)傳遞等，因此消息傳輸?shù)膶崿F(xiàn)目標必須在能夠實現(xiàn)各類的不同的系統(tǒng)間的信息 通訊。2) 數(shù)據(jù)整合醫(yī)療信息的管理和決策

11、支持的應用需要以格式規(guī)整和高質量的基礎數(shù)據(jù)作 為支撐。而這些數(shù)據(jù)通常是由接入的各個系統(tǒng)來提供的， 但各系統(tǒng)能夠提供的數(shù) 據(jù)在結構和質量方面存在較大的差異，通過采用數(shù)據(jù)整合可以收集、整理數(shù)據(jù)， 形成數(shù)據(jù)高度集中的數(shù)據(jù)中心，為決策支持提供數(shù)據(jù)服務。3) 服務集成就各個業(yè)務系統(tǒng)的整合而言，服務集成必須滿足：支持對于 webservice 的 集成，數(shù)據(jù)交換和共享平臺采用統(tǒng)一的服務調用接口完成對各個業(yè)務系統(tǒng)提供的 服務調用，支持對于服務請求和反饋的日志功能。4) 流程整合當數(shù)據(jù)校核和共享平臺連接了醫(yī)院的業(yè)務系統(tǒng)和其他外部系統(tǒng)后， 有些信息 的處理可能需要一個較為復雜的過程控制， 在這種過程中需要把多種

12、數(shù)據(jù)的處理 操作按照某些業(yè)務規(guī)則連接起來， 實現(xiàn)業(yè)務規(guī)則的可視化建模和業(yè)務過程的可視 化運行監(jiān)控。5) 管理功能 數(shù)據(jù)交換和共享平臺負責醫(yī)院各業(yè)務系統(tǒng)和外部系統(tǒng)之間大多數(shù)的數(shù)據(jù)交 換，接入節(jié)點的數(shù)量比較多， 而每一個系統(tǒng)能夠提供的醫(yī)療信息資源也存在不小 的差異，因此必須管理和組織好這些交換的節(jié)點， 使得交換可以有效、 可靠的運 行。3 總體建設方案3.1 實現(xiàn)思路3.1.1 交換方案比選實現(xiàn)醫(yī)療業(yè)務系統(tǒng)間的數(shù)據(jù)交換，有多種方案可供選擇：1) 修改各醫(yī)療業(yè)務子系統(tǒng) 在各醫(yī)療業(yè)務子系統(tǒng)間直接進行點對點信息共享交換。2) 建立醫(yī)療業(yè)務中間數(shù)據(jù)庫 各醫(yī)療業(yè)務子系統(tǒng)將數(shù)據(jù)存儲于中間數(shù)據(jù)庫，醫(yī)療業(yè)務子系統(tǒng)

13、通過中間 數(shù)據(jù)庫進行信息共享交換。3) 建立醫(yī)療數(shù)據(jù)交換平臺 整合醫(yī)務流程，構建統(tǒng)一的信息共享交換平臺。以上 3 種醫(yī)療數(shù)據(jù)交換方案分別采取 3 種不同的策略來實現(xiàn)醫(yī)療數(shù)據(jù)交 換。點對點的信息交換模式， 通過原有醫(yī)療業(yè)務信息系統(tǒng)， 按照各個系統(tǒng)間的數(shù) 據(jù)交換需求進行系統(tǒng)改造， 系統(tǒng)間耦合度過高， 每增加一個需要交換的系統(tǒng)， 都 需要對相關聯(lián)的所有系統(tǒng)均進行改造，工作量巨大。中間數(shù)據(jù)庫模式， 通過將數(shù)據(jù)集中存儲的方式進行數(shù)據(jù)交換， 要求各業(yè)務子 系統(tǒng)采取相同的中間數(shù)據(jù)庫， 將數(shù)據(jù)集中存儲于中間數(shù)據(jù)庫中； 各業(yè)務子系統(tǒng)直 接訪問中間數(shù)據(jù)庫來實現(xiàn)數(shù)據(jù)交換，無法對數(shù)據(jù)安全及業(yè)務流程進行控制。醫(yī)療數(shù)據(jù)交

14、換平臺的方式， 是通過建立獨立于各業(yè)務子系統(tǒng)之外的數(shù)據(jù)交換 平臺，實現(xiàn)數(shù)據(jù)交換服務，為各業(yè)務子系統(tǒng)提供數(shù)據(jù)共享和交換服務。醫(yī)療數(shù)據(jù)交換平臺建立了醫(yī)療業(yè)務子系統(tǒng)間的數(shù)據(jù)交換標準和平臺， 為醫(yī)療 業(yè)務子系統(tǒng)提供數(shù)據(jù)交換服務。 醫(yī)療數(shù)據(jù)交換平臺除了提供數(shù)據(jù)交換服務外， 還 提供公用的基本醫(yī)療信息服務， 將分散于各業(yè)務系統(tǒng)中、 被不斷重復實現(xiàn)的基本 醫(yī)療業(yè)務服務進行剝離整合， 提供公用的服務。 通過實施醫(yī)療數(shù)據(jù)交換平臺可實現(xiàn)：（1）醫(yī)療數(shù)據(jù)交換標準化，規(guī)范化業(yè)務系統(tǒng)間的數(shù)據(jù)定義，實現(xiàn)業(yè)務數(shù)據(jù) 標準化。（2）醫(yī)療業(yè)務基本服務組件化，將基本的公用服務進行剝離整合，形成基 本的公用服務。（3）醫(yī)療業(yè)務流程控

15、制，可根據(jù)業(yè)務流程變化動態(tài)調整業(yè)務子系統(tǒng)間的數(shù) 據(jù)流向。3.1.2 技術優(yōu)勢數(shù)據(jù)交換平臺提供了統(tǒng)一的方式來實現(xiàn)醫(yī)院信息系統(tǒng)的集成， 這種方式的優(yōu) 勢有：1） 連接標準化數(shù)據(jù)交換平臺支持 HL7。2） 降低了系統(tǒng)搞合度和集成的難度由于應用系統(tǒng)只需要與數(shù)據(jù)交換平臺集成， 從而減少集成應用系統(tǒng)之間的稠 合水平，可以將某一個應用系統(tǒng)的部分或全部進行替換而不影響其他應用系統(tǒng) - 數(shù)據(jù)交換平臺提供的配置工具，可以輕易配置好系統(tǒng)之間的集成 - 并且定義了多 種接口，多種通訊協(xié)議和消息協(xié)議， 使得各種異構系統(tǒng)之間的連接更加簡單， 降 低了開發(fā)的工作量，減少重復開發(fā)。3） 實現(xiàn)數(shù)據(jù)共享可以將分散建設的若干應用系

16、統(tǒng)內的部分數(shù)據(jù)進行整合， 綜合統(tǒng)一的數(shù)據(jù)存 儲應用服務，使多個應用系統(tǒng)進行信息 / 數(shù)據(jù)的傳輸及共享，提高信息資源利用 率，保證數(shù)據(jù)時效性、真實性，安全可靠性。4）提高系統(tǒng)的擴展性數(shù)據(jù)交換平臺的最大優(yōu)點體現(xiàn)在它的可擴展性上， 任何一個系統(tǒng)的下線或 者上線不會直接影響到其他系統(tǒng)，方便多個應用系統(tǒng)間的集成。從這一點上講， 對于醫(yī)院這樣需要不斷完善、新系統(tǒng)不斷增加的狀況來說無疑具有重要意義。5）提高了系統(tǒng)的可維護性 一方面由于接口數(shù)量減少了，維護起來相對容易 ; 另一方面由于數(shù)據(jù)交換平臺提供了監(jiān)控工具，可以追蹤系統(tǒng)里的每一個消息，可以及時發(fā)現(xiàn)問題并糾錯， 維護更加方便，這也提高了集成的質量。6）便于

17、管理由于所有系統(tǒng)都通過數(shù)據(jù)交換平臺來集成，醫(yī)院只要管理好集成平臺與應用 系統(tǒng)之間的關系，不用再協(xié)調各廠商之間的關系。3.2總體架構數(shù)據(jù)交換與共享平臺屬于系統(tǒng)服務軟件， 它連接不同的業(yè)務系統(tǒng)，為其提供 連接和協(xié)同工作的功能，簡化不同業(yè)務系統(tǒng)之間的通信，具備多元融合、一體化 和多業(yè)務，支持多種協(xié)議。以各類信息交換為核心的數(shù)據(jù)交換平臺，通過建立底 層結構來聯(lián)系橫貫整個醫(yī)院的異構系統(tǒng)、應用軟件、數(shù)據(jù)庫資源等，支持不同處 理業(yè)務、不同軟硬平臺對不同結構數(shù)據(jù)交互的要求，滿足各種醫(yī)療信息系統(tǒng)、辦公自動化、內外門戶網站的需求，以及其應用系統(tǒng)之間無縫地共享和交換數(shù)據(jù)的 需要，將不同系統(tǒng)各自獨立的數(shù)據(jù)源連接整合起

18、來，實現(xiàn)數(shù)據(jù)的交換和共享。數(shù)據(jù)交換與共享平臺主要由以下三個核心子系統(tǒng)組成：業(yè)務蔡垢ins扭一 EMR前置ta1(LlSRtSM:pros前置呵前豐機uisittHUESBJMSFTP權限評硏用戶營理幾享數(shù)據(jù)庫圖1.數(shù)據(jù)交換共享平臺架構圖中心交換子系統(tǒng) 采用面向服務的架構（SOA理念，通過基于內容的路由和方便的數(shù)據(jù)轉 換引擎，實現(xiàn)傳統(tǒng)消息和 Web服務調用的統(tǒng)一處理。中心交換子系統(tǒng)由 中心交換傳輸子系統(tǒng)和中心交換管理子系統(tǒng)組成。前置交換系統(tǒng)數(shù)據(jù)交換前置機擔負著從業(yè)務系統(tǒng)的數(shù)據(jù)抓取、數(shù)據(jù)轉換、數(shù)據(jù)封裝和從中心子平臺的消息監(jiān)聽、消息處理等功能。共享信息庫是存儲數(shù)據(jù)交換過程中經由數(shù)據(jù)交換與共享平臺的業(yè)

19、務數(shù)據(jù)的存儲介 質，其作用是積累交換過程中的業(yè)務數(shù)據(jù)，為以后建立在數(shù)據(jù)交換與共 享平臺基礎上的應用提供數(shù)據(jù)來源。3.3數(shù)據(jù)交換與共享基本模型數(shù)據(jù)交換與共享平臺主要是基于國際國內標準，結合XML J2EE、WebServices等技術，完成不同業(yè)務應用系統(tǒng)間的業(yè)務協(xié)同，建立起可供數(shù)據(jù)交換 與信息共享的中心系統(tǒng)，實現(xiàn)跨部門、跨地區(qū)、跨平臺、跨系統(tǒng)的信息交換與共 享。我們可以將數(shù)據(jù)交換與共享平臺的交換模式分為兩類，即分布模式和混合模式。3.3.1分布模式分布模式即各應用系統(tǒng)通過數(shù)據(jù)交換與信息共享平臺的前置機 （即標準中的 端交換節(jié)點）來交換數(shù)據(jù)，實現(xiàn)點到點的數(shù)據(jù)交換。應用系統(tǒng)將消息傳遞到自身 對應的

20、數(shù)據(jù)交換前置機，由前置機再將消息通過 Web Services調用的方式傳遞 到目標應用端的前置機，由目標應用端的前置機進行數(shù)據(jù)接收的具體操作， 如圖:應用系統(tǒng)1 交換節(jié)點1 交換書點上應用系統(tǒng)2圖2.分布交換示意圖332混合模式混合模式是指各應用系統(tǒng)既可以通過數(shù)據(jù)交換與共享平臺的前置機進行點 對點的數(shù)據(jù)交換，也可以經由數(shù)據(jù)交換與共享平臺進行數(shù)據(jù)信息交換。如圖：交換節(jié)點3應用系統(tǒng)1交換節(jié)點1 w”4交換節(jié)點2 應用系統(tǒng)2圖3. 混合交換示意圖如圖所示，我們可以看出：數(shù)據(jù)交換與共享平臺的交換的混合模式， 與標準 中的混合模式少有差別。在標準的描述中，各系統(tǒng)是通過共享信息庫交換數(shù)據(jù)， 這實際上是一

21、種類似數(shù)據(jù)大集中的模式；而數(shù)據(jù)交換與共享平臺的數(shù)據(jù)交換模 式，則是由數(shù)據(jù)交換與共享平臺來交換數(shù)據(jù)， 并將交換的數(shù)據(jù)按照業(yè)務規(guī)則“漏” 入共享數(shù)據(jù)庫。因此，共享數(shù)據(jù)庫也可以看作交換體系的一個接入系統(tǒng)，即一個交換節(jié)點。但是，我們認為這種方式是符合標準的，而且更增加系統(tǒng)靈活性。3.3.3數(shù)據(jù)交換與共享平臺交換流程模型數(shù)據(jù)交換與共享平臺具體工作流程如下圖所示:一,I” I* ”i 9 AW “啦；* 卜 _力一al1 JMSS” /圖4.數(shù)據(jù)信息共享與交換平臺交換體系示例圖說明：1. 數(shù)據(jù)交換與共享平臺源數(shù)據(jù)前置應用：數(shù)據(jù)交換與共享平臺源數(shù)據(jù)前置應用是通過前置適配引擎根據(jù)源數(shù)據(jù) MAPPE對應關系文件

22、和其他前置適配引擎配置文件提取、格式化數(shù)據(jù)信息， 并傳遞消息機制數(shù)據(jù)信息。源數(shù)據(jù)應用系統(tǒng)前置適配器掃描獲得所需交換共享的數(shù)據(jù)信息；將交換共享的數(shù)據(jù)信息格式化為標準的 XML1訊文件；將交換共享的數(shù)據(jù)信息XML通訊文件通過消息通道傳送至指定消息 隊列；前置應用取數(shù)據(jù)、格式化XMLS訊文件、通訊都是根據(jù)源數(shù)據(jù)MAPPER 對應關系文件和其他前置適配引擎配置文件關聯(lián)。2. 數(shù)據(jù)交換與共享平臺應用：數(shù)據(jù)交換與共享平臺的消息隊列在獲得 XML通訊文件后即需要對其進 行解析，根據(jù)數(shù)據(jù)交換與共享平臺目錄體系、交換體系規(guī)則進行數(shù)據(jù)處理。系統(tǒng)根據(jù)目錄體系規(guī)則，結合 XML通訊文件自身定義，將數(shù)據(jù)交換 與共享平臺

23、核心共享數(shù)據(jù)庫所需要的數(shù)據(jù)字段值“漏”到核心共享 數(shù)據(jù)庫內；系統(tǒng)根據(jù)交換體系規(guī)則，結合 XML通訊文件自身定義，根據(jù)目的地 數(shù)據(jù)應用系統(tǒng)的數(shù)據(jù)格式要求，將 XML通訊文件轉換格式，以符合 目的地數(shù)據(jù)應用系統(tǒng)需要；將符合目的地數(shù)據(jù)應用系統(tǒng)需要的新的格式的XML通訊文件傳送至另一指定消息隊列。3 數(shù)據(jù)交換與共享平臺數(shù)據(jù)交換格式模型由源數(shù)據(jù)應用系統(tǒng)的前置機引擎掃描或抽取源數(shù)據(jù)并轉換、封裝成標準的XML消息體，并通過前置機根據(jù)目標地址交換到目標地，在目標地的前置 機引擎將標準的XML消息體解包、解析并轉換成目標系統(tǒng)的所需數(shù)據(jù)格式， 這是數(shù)據(jù)交換與共享平臺系統(tǒng)的數(shù)據(jù)交換格式模型，如下圖所示：圖5. 數(shù)據(jù)

24、交換格式模型3.4與內部業(yè)務系統(tǒng)的交換方式在前面的章節(jié)中，我們已經提到了，數(shù)據(jù)交換與共享平臺對外提供了WebServices、JMS SMTP FTP文件、定時器等交換服務的方式，在這些方式中， 可以分為被動交換方式和主動交換方式兩種類型。3.4.1被動交換方式被動交換方式即交換平臺被動地接受外部業(yè)務應用系統(tǒng)的交換請求，其中WebServices、JMS SMTP FTP文件及中間庫是屬于被動交換方式。此方式中應用系統(tǒng)與交換平臺的交換機制如下圖所示：Haaden圖6.被動交換方式342主動交換方式主動交換方式即數(shù)據(jù)交換與共享平臺主動探測外部業(yè)務應用系統(tǒng)數(shù)據(jù)的變化，并主動發(fā)起數(shù)據(jù)交換的流程，如圖

25、：Head or:圖7.主動交換方式3.4.3交換方式建議343.1 Web Services 方式對于實時性要求很高的數(shù)據(jù)交換，建議對業(yè)務系統(tǒng)進行改造，當業(yè)務發(fā)生時,調用數(shù)據(jù)交換與共享平臺的 Web Services接口，實現(xiàn)數(shù)據(jù)的實時交換。343.2數(shù)據(jù)庫觸發(fā)方式對于實時性要求很高的數(shù)據(jù)交換，同時業(yè)務系統(tǒng)無法進行改造，可以通過在 數(shù)據(jù)庫中配置觸發(fā)器，編寫腳本的方式。當業(yè)務數(shù)據(jù)變化時，激活觸發(fā)器，并進 行數(shù)據(jù)的交換。定時方式對于數(shù)據(jù)交換實時性不高的業(yè)務，可以通過定時輪詢的方式，檢測業(yè)務數(shù)據(jù) 的變化，并啟動相關數(shù)據(jù)交換流程進行數(shù)據(jù)交換3.5與區(qū)域衛(wèi)生信息平臺的交換方式3.5.1邏

26、輯架構在醫(yī)療機構部署前置機，醫(yī)療機構將內部業(yè)務系統(tǒng)（HIS、CIS、LIS、PACSRIS等）相關業(yè)務數(shù)據(jù)進行標準化和規(guī)范化整理后，統(tǒng)一上傳到醫(yī)療機構前置機 數(shù)據(jù)庫；依托前置機數(shù)據(jù)交換系統(tǒng)，將醫(yī)療機構標準數(shù)據(jù)打包上傳至區(qū)域衛(wèi)生信 息平臺數(shù)據(jù)中心數(shù)據(jù)庫。醫(yī)療機構前置機邏輯架構如下圖所示：3.5.2數(shù)據(jù)上傳的內容和要求結合各醫(yī)療機構內部已經成熟應用的系統(tǒng)（HIS、CIS、LIS、PACS RIS 等）的情況，區(qū)域衛(wèi)生信息平臺要求各醫(yī)療機構提供的業(yè)務數(shù)據(jù)包含如下內容:序號表名1門急診診療服務基本表2門急診診療服務就診記錄表3門急診處方主表4門急診處方明細表5門急診收費明細表6門急診結算記錄表7住院登

27、記服務基本表8住院醫(yī)囑主表9住院醫(yī)囑明細表10住院費用明細表11住院費用結算記錄表12住院病案首頁13門急診/住院手術麻醉記錄表14門急診/住院放化療、介入、植入等治療記錄表15門急診住院用血記錄表16門急診住院轉診記錄表17實驗室檢驗報告表頭18實驗室檢驗結果指標表19實驗室檢驗細菌結果表20實驗室檢驗藥敏結果表21醫(yī)學影像檢查報告表22健康體檢主記錄表23健康體檢分科記錄明細表24健康體檢明細表上表描述的24張業(yè)務表，醫(yī)療機構根據(jù)每天實際業(yè)務數(shù)據(jù)的產生情況，定時把相關數(shù)據(jù)上傳到醫(yī)院前置機數(shù)據(jù)庫。醫(yī)療機構在上傳數(shù)據(jù)時，需要遵守以下要求：1）醫(yī)療機構只能上傳新增數(shù)據(jù)和已經上傳過但是經過修改的數(shù)

28、據(jù)，不允許 重復上傳的相同的記錄；2）數(shù)據(jù)上傳前必須經過醫(yī)療機構內部審核，已經上傳數(shù)據(jù)不允許刪除；3）上傳的數(shù)據(jù)，要求記錄每條數(shù)據(jù)的提交時間以及記錄的狀態(tài)（標識清楚 是新增的記錄和修改過的記錄）；本標準通過兩個數(shù)據(jù)項約束：提交時間 和記錄狀態(tài)（“i ”表示新增記錄，“u”表示修改過的記錄）。3.5.3醫(yī)療機構數(shù)據(jù)提交方式醫(yī)療機構提交數(shù)據(jù)的方式為定時批量式。定時批量式提交的采集數(shù)據(jù)包含兩部分內容：部分字典數(shù)據(jù)和醫(yī)療業(yè)務數(shù)據(jù)定時批量式提交采集數(shù)據(jù)，要求醫(yī)療機構內部信息系統(tǒng)自動生成數(shù)據(jù)并定時 批量提交到前置機中約定的庫數(shù)據(jù)表中。特別需要說明：醫(yī)療機構內部信息系統(tǒng) 在編制提交采集數(shù)據(jù)的程序邏輯時，不要

29、將提交采集數(shù)據(jù)的操作邏輯嵌入到醫(yī)療 機構內日常醫(yī)療業(yè)務流程中，即不要將提交采集數(shù)據(jù)成功與否作為日常醫(yī)療業(yè)務 流程是否可繼續(xù)流轉的必要條件，而作為一個單獨的處理程序邏輯予以定時單獨 運作。在前置機上建立數(shù)據(jù)庫，并預先創(chuàng)建數(shù)據(jù)表的表結構。所有的表根據(jù)功能的 不同向醫(yī)療機構內相關信息系統(tǒng)開放不同的權限。在提交數(shù)據(jù)時，醫(yī)療機構信息 系統(tǒng)需要按照數(shù)據(jù)采集時點要求，定時批量的將生成的采集數(shù)據(jù)填入對應的數(shù)據(jù) 表內。請注意要求：醫(yī)療數(shù)據(jù)明細項目內容需在醫(yī)療機構日對帳結束后上傳；明細 項目內容必須每天上傳，若需修正，則修正后以同樣方式再次上傳。3.5.4數(shù)據(jù)上傳的時間點如上文所述，醫(yī)療機構通過內部信息系統(tǒng)自動生

30、成數(shù)據(jù)并定時批量提交到前 置機數(shù)據(jù)庫。醫(yī)療機構信息系統(tǒng)應每天提交業(yè)務運營數(shù)據(jù)、患者基本信息、就診 履歷信息、檢驗報告信息、住院病案等當天的增量數(shù)據(jù)。醫(yī)療機構應按照全市統(tǒng)一的數(shù)據(jù)交換時間規(guī)劃，在每天固定時間準時將完成 業(yè)務運營數(shù)據(jù)和診療數(shù)據(jù)等提交到前置機數(shù)據(jù)庫，前置機也遵循全市統(tǒng)一的規(guī) 劃，每天定時進行數(shù)據(jù)整合、匹配的工作，在完成數(shù)據(jù)整合、匹配后，區(qū)域衛(wèi)生信息平臺數(shù)據(jù)中心將從醫(yī)療機構的前置機標準數(shù)據(jù)庫采集相關醫(yī)療業(yè)務數(shù)據(jù)。舉例說明如下表：序號整合名稱處理頻次、時間點1醫(yī)療機構數(shù)據(jù)上報過程每日處理；每日00:00時開始，并在01:00 結束2前置機端整合過程每日處理；01:30時開始，04:00時

31、結束3前置機到數(shù)據(jù)中心的數(shù)據(jù) 交換過程每日處理；04:00時開始，06:00時結束4產品概述針對電子政務、企業(yè)級應用集成中的數(shù)據(jù)交換和業(yè)務集成問題，結合 EAI/E TL領域的先進設計思想和業(yè)界知名產品的優(yōu)點， 分析EAI/ETL領域的發(fā)展趨勢， 設計開發(fā)了 “數(shù)據(jù)交換與共享平臺”產品，以滿足電子政務、醫(yī)療、教育、金融、 電信等應用集成領域數(shù)據(jù)交換和共享以及業(yè)務集成等方面的需要。本產品是企業(yè)級的信息交換與信息整合產品，可以應用在數(shù)據(jù)共享與交換、 數(shù)據(jù)抽取轉換（ETL）、數(shù)據(jù)倉庫建設、信息同步、信息合并、歷史數(shù)據(jù)遷移等領 域。4.1技術實現(xiàn)框架數(shù)據(jù)交換前置機和共享數(shù)據(jù)交換與共享平臺的交換體系由中

32、心交換子平臺、 信息庫組成，如下圖所示：敬據(jù)交技平臺圖8.數(shù)據(jù)交換與共享平臺系統(tǒng)框架中心交換子平臺是數(shù)據(jù)交換與信息共享平臺交換體系的核心，它承擔著數(shù)據(jù)交換過程中的主要處理工作，如消息監(jiān)聽、消息處理、異常處理、流程管理、監(jiān) 控管理、參數(shù)管理等功能。前置機系統(tǒng)是一個小型的交換中心子平臺，也稱作數(shù)據(jù)交換的節(jié)點。它的功 能主要是完成消息的處理、數(shù)據(jù)的轉換和封裝。在網絡環(huán)境暢通的條件下，前置 機是可變成虛擬的；但在存在物理隔離或者防火墻的環(huán)境下， 前置機將是物理的 實體，它為應用系統(tǒng)間的數(shù)據(jù)交換與信息共享的實施，提供了可行與可靠的實 現(xiàn)方案。共享數(shù)據(jù)庫是存儲數(shù)據(jù)交換過程中經由數(shù)據(jù)交換與共享平臺的業(yè)務數(shù)據(jù)

33、的 存儲介質，其作用是積累交換過程中的業(yè)務數(shù)據(jù)， 為以后建立在數(shù)據(jù)交換與共享 平臺基礎上的應用提供數(shù)據(jù)來源。在下面的章節(jié)中，我們將對數(shù)據(jù)交換與共享平臺各子部分別作詳細的描述。4.2中心交換子系統(tǒng)數(shù)據(jù)交換與共享平臺按照應用層次的要求，由接入層、內容處理層、數(shù)據(jù)處理層，如圖所示：圖9. 中心交換子系統(tǒng)結構從整體上來看，平臺主要是在JCA國際規(guī)范基礎之上，結合XML J2EE、Web Services和JMS等技術標準，汲取了國內外的建設經驗，采用集中式的交換應 用服務器和可定制的智能連接適配器(Adaptor )、面向服務的框架結構體系(SOA，實現(xiàn)對各業(yè)務應用系統(tǒng)的有機整合，建立起可使跨部門業(yè)務

34、應用系統(tǒng)之 間進行“溝通”的數(shù)據(jù)信息交換與共享平臺。4.3前置交換子系統(tǒng)前置機子系統(tǒng)主要由Mapper和Engine兩大部分組成，如下圖所示:甌|巫融頭百II圖10. 前置交換子系統(tǒng)結構其中，Map per是一個由Java開發(fā)的C/S模式的系統(tǒng)。主要用來實現(xiàn)數(shù)據(jù)轉 換過程中轉換關系的定制。通過讀取源數(shù)據(jù)和目標數(shù)據(jù)的數(shù)據(jù)結構，結合系統(tǒng)的 拖拽、內置函數(shù)等功能，實現(xiàn)從源數(shù)據(jù)到目標數(shù)據(jù)的轉換關系定制。Engine前置交換子系統(tǒng)的核心，系統(tǒng)中業(yè)務流程的集成、數(shù)據(jù)的轉換、消息的路由、插件的部署等功能都是在應用集成服務器中實現(xiàn)的。主要由企業(yè)服務器總線、數(shù)據(jù)交換處理部件（包括適配器和交換子系統(tǒng)）、運行支撐環(huán)

35、境、規(guī)則 庫、管理組件（包括管理服務器和管理工具）等組成。4.3.1交換流程管理系統(tǒng)具備可視化方式創(chuàng)建業(yè)務流程的能力，用戶可以通過簡單的拖拽來定制 業(yè)務流程，屏蔽了具體的實現(xiàn)細節(jié)，使用戶能集中有限的精力來關注于業(yè)務層面 上的應用。如圖：圖11. 數(shù)據(jù)交換流程定義同時，系統(tǒng)具備業(yè)務流程擴展的能力。在需要實現(xiàn)具有復雜邏輯功能的業(yè)務 流程時，只需要按照系統(tǒng)的接口編寫相關的代碼并發(fā)布到系統(tǒng)中，就可以使系統(tǒng)具備運行、維護復雜業(yè)務流程的能力。4.3.2數(shù)據(jù)轉換數(shù)據(jù)轉換使用戶能在XML非XML等數(shù)據(jù)格式之間進行相互轉換，從而可 快速集成異構應用，無需過多考慮數(shù)據(jù)采用的是何種格式， 因為系統(tǒng)已經內置了 對各種

36、數(shù)據(jù)格式的支持，通過系統(tǒng)的識別、解析功能，可以快速地將各種數(shù)據(jù)格 式描述成自身能夠識別的語言在系統(tǒng)中流轉。對于系統(tǒng)暫時不能識別的數(shù)據(jù)格式，可以通過插件的形式快速升級系統(tǒng)的數(shù) 據(jù)識別庫，不僅保證了當前數(shù)據(jù)格式的識別，也擴充了系統(tǒng)的識別能力。數(shù)據(jù)轉換的功能可以封裝成控件來使用，跨多個業(yè)務流程和應用重復使用。前置機系統(tǒng)具有功能強大的可視化數(shù)據(jù)映射工具，即Mapper轉換映射器。它使用戶不但能夠生成復雜的數(shù)據(jù)轉換， 而且具體操作非常簡單，只要執(zhí)行拖放 操作就行。下圖展現(xiàn)的就是 Mapper轉換映射器。前置機系統(tǒng)的映射器功能，實 現(xiàn)了不同類型數(shù)據(jù)之間的轉換。例如，可把符合某個 XML Schemas證類

37、型的XML文檔轉換為符合另外一個XML Schemas型驗證的XML文檔圖 12. Mapper4.3.3消息路由數(shù)據(jù)交換與共享平臺實現(xiàn)的消息代理，向業(yè)務流程提供了基于渠道的發(fā)布和 訂閱通信機制。它使業(yè)務流程能以松散耦合、異步的方式，使用業(yè)務命名范例進 行通信。例如，采購訂單路由流程可以訂閱新訂單輸入渠道，并且當每個新的訂單消息發(fā)布到該渠道時，就激活了該流程。每個業(yè)務流程都可以指定其發(fā)布和訂 閱的渠道。發(fā)布者無須知道誰將接收消息，就可以廣播消息。這些消息的用戶可以是任 意幾個不同類型的聽眾之一。諸如業(yè)務流程和其他后端資源之類的用戶， 可以訂 閱消息代理渠道。消息代理以這種方式提供了松散耦合的界

38、面。在運行時，您可以添加新的發(fā)布者和訂閱者。消息代理支持事件生成器，后者可以從外部資源向消息代理渠道發(fā)布事件。 數(shù)據(jù)交換與共享平臺支持文件、JMS FTP電子郵件和定時器事件生成器。駐留 在應用集成框架中的適配器，可以從封裝應用向渠道發(fā)布事件。434插件系統(tǒng)系統(tǒng)內置了數(shù)據(jù)庫操作（增加、修改、刪除、查詢）、文件處理（讀取、寫 入）消息處理（發(fā)送、接收）、Web Services調用、Email處理（發(fā)送、接收）、 日志記錄等插件，確保系統(tǒng)對業(yè)務系統(tǒng)有足夠的適應能力。同時，系統(tǒng)的插件機制確保了系統(tǒng)能夠像插拔 USB設備一樣實現(xiàn)系統(tǒng)功能的 插拔，只要按系統(tǒng)規(guī)定的接口進行構建，用戶可方便地實現(xiàn)系統(tǒng)功能的擴展。435適配器集成系統(tǒng)支持JCA技術規(guī)范，按照此規(guī)范的任何適配器可以裝配到系統(tǒng)中，簡化 了