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

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

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

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

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

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

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

7、要針對業(yè)務(wù)流程進行有針對性地 再次開發(fā)， 造成系統(tǒng)維護的困難。 雖然醫(yī)院已經(jīng)針對各醫(yī)療業(yè)務(wù)部署實施了相應(yīng) 的信息化系統(tǒng)， 實現(xiàn)了醫(yī)療業(yè)務(wù)的信息化處理。 但是總體來說這些醫(yī)療業(yè)務(wù)系統(tǒng) 的部署實施反而造成了一個個的“信息孤島” ，限制了醫(yī)療信息化的程度和醫(yī)療 信息化的效果。隨著醫(yī)院對醫(yī)療信息化需求的轉(zhuǎn)變， 要求在這些醫(yī)療業(yè)務(wù)子系統(tǒng)間進行數(shù)據(jù) 共享與交換，進一步整合各個醫(yī)療業(yè)務(wù)子系統(tǒng)，構(gòu)建統(tǒng)一的醫(yī)療業(yè)務(wù)平臺。結(jié)合醫(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ù)元標(biāo)準(zhǔn)化規(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)生信息平臺建設(shè)指南6) 基于健康檔案的區(qū)域衛(wèi)生信息平臺建設(shè)技術(shù)解決方案(試行)2 需求分析2.1 交換內(nèi)容目前，醫(yī)院各信息系統(tǒng)中需要交換與共享的數(shù)據(jù)大致可以分為運營類信息和 醫(yī)院管理類信息。其中，運營類信息需要進行交換和共享的主要內(nèi)容有： 主要來源于門診、 藥 房、醫(yī)技科室、醫(yī)生站、護士站等業(yè)務(wù)。內(nèi)容包括門診業(yè)務(wù)信息 （ 門急診流量、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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