醫(yī)院信息集成平臺(tái)建設(shè)方案

1、信息集成平臺(tái)建設(shè)方案1 建設(shè)需求一個(gè)完善的醫(yī)院信息系統(tǒng)通常由上百個(gè)子系統(tǒng)組成，牽涉眾多的專業(yè)領(lǐng)域。 這么龐大的系統(tǒng)需要非常專業(yè)化的軟件開(kāi)發(fā)分工， 整合不同廠商有特色的專業(yè)系 統(tǒng)是醫(yī)院信息系統(tǒng)的發(fā)展趨勢(shì)， 醫(yī)院信息化能夠取得成功必須保證各個(gè)系統(tǒng)的有 效集成和數(shù)據(jù)的高度共享。然而這些系統(tǒng)通常是隨著醫(yī)院的發(fā)展需求逐步建設(shè) 的，它們來(lái)源于不同的廠家，基于不同的技術(shù)，缺乏統(tǒng)一的信息交換標(biāo)準(zhǔn)，這些 系統(tǒng)的集成整合已經(jīng)逐漸成為醫(yī)院數(shù)字化發(fā)展亟待解決的主要問(wèn)題。系統(tǒng)集成平臺(tái)的構(gòu)建主要面向兩個(gè)核心問(wèn)題： 一個(gè)是為各種醫(yī)療應(yīng)用提供統(tǒng) 一的醫(yī)療數(shù)據(jù)訪問(wèn)服務(wù)， 從而消除各種醫(yī)療應(yīng)用系統(tǒng)與醫(yī)療數(shù)據(jù)中心的直接耦合 性；另

2、一個(gè)是為各種臨床信息系統(tǒng)提供系統(tǒng)集成服務(wù)， 系統(tǒng)集成服務(wù)基于系統(tǒng)集 成模型，通過(guò) HL7 和 DICOM 等標(biāo)準(zhǔn)通訊協(xié)議為各種醫(yī)療應(yīng)用系統(tǒng)提供集成服 務(wù)，確保各個(gè)臨床信息系統(tǒng)在工作流整合的基礎(chǔ)上實(shí)現(xiàn)交互協(xié)作， 從而以數(shù)字化 的形式完成各項(xiàng)醫(yī)療業(yè)務(wù)。2 建設(shè)目標(biāo)系統(tǒng)間的整合、 集成和擴(kuò)展一直都是制約醫(yī)院數(shù)字化發(fā)展的主要障礙， 由于 不同廠商之間的產(chǎn)品不兼容， 使得醫(yī)院整體信息化步履維艱。 通過(guò)建設(shè)一個(gè)規(guī)范 的系統(tǒng)集成平臺(tái)，在 IHE 、DICOM 、HL7 等國(guó)際標(biāo)準(zhǔn)的基礎(chǔ)上，制定覆蓋醫(yī)療 所有業(yè)務(wù)流程的系統(tǒng)集成規(guī)范， 開(kāi)發(fā)基于規(guī)范的系統(tǒng)集成平臺(tái)， 為遺留的、 當(dāng)前 的以及將來(lái)的系統(tǒng)提供了一個(gè)統(tǒng)

3、一且標(biāo)準(zhǔn)的數(shù)據(jù)交換和工作流協(xié)同的平臺(tái)。3 信息集成方法信息集成方法有三，即應(yīng)用集成、數(shù)據(jù)集成、界面集成，這三種集成方式各 解決不同方面的問(wèn)題。 應(yīng)用集成指應(yīng)用程序之間實(shí)時(shí)或異步交換信息和相互調(diào)用 功能，可以采用 HL7 消息， Web Service ，CORBA ，EJB ，DCOM ， RPC 等標(biāo)準(zhǔn)，采用消息中間件， BPM 等中間件實(shí)現(xiàn)；數(shù)據(jù)集成是指應(yīng)用系統(tǒng)的數(shù)據(jù) 庫(kù)系統(tǒng)之間的數(shù)據(jù)交換和共享，以及數(shù)據(jù)之間的映射變換，常采用 ETL ( Extract-Transform-Load )工具實(shí)現(xiàn)；界面集成含義是應(yīng)用程序界面之間相 互關(guān)聯(lián)引用合成，采用技術(shù)包括 ActiveX 插件、 Por

4、tlet 、 IFrame 等。協(xié)同應(yīng)用從早期單純的點(diǎn)對(duì)點(diǎn)接口方式， 發(fā)展到現(xiàn)如今的集成平臺(tái)方式。 各 種方式中：? 點(diǎn)對(duì)點(diǎn)接口方式的復(fù)雜性在于要和不同的系統(tǒng)建立1 ：N 的接口，假定有N個(gè)系統(tǒng)相互之間需要建立接口，則接口數(shù)為 N*(N-1)/2 。? 集成平臺(tái)方式中，在 N 個(gè)系統(tǒng)需要進(jìn)行應(yīng)用協(xié)同的情況下，只需要開(kāi)發(fā)N 個(gè)適配器接口即可，減少了集成平臺(tái)的系統(tǒng)負(fù)荷。由于醫(yī)院信息系統(tǒng)復(fù)雜性， 我們根據(jù)不同的需求和應(yīng)用場(chǎng)景， 設(shè)計(jì)分別采用 上述三種不同集成方法和手段進(jìn)行信息集成。4應(yīng)用集成和醫(yī)技輔診科室信息系統(tǒng)（如 PACS/RIS、LIS、MUSE等）的信息集成， 這種場(chǎng)景，信息交互的數(shù)據(jù)量不大

5、，實(shí)時(shí)性要求不高，且各信息系統(tǒng)各專業(yè)廠商 實(shí)現(xiàn)方式相差較大，采用基于集成平臺(tái)的應(yīng)用集成方式是最優(yōu)選擇。集成平臺(tái)體系結(jié)構(gòu)如下圖所示，集成平臺(tái)對(duì)外提供支持多種方式的集成服務(wù)：包括 WebService服務(wù)、TCP監(jiān)聽(tīng)服務(wù)、文件監(jiān)測(cè)服務(wù)、FTP服務(wù)、SQL監(jiān)控服務(wù)等方式柬護(hù)fit:廠WCF醫(yī)院信息系統(tǒng)在國(guó)際、國(guó)內(nèi)廣泛采用的有一套集成規(guī)范，即：醫(yī)療健康信息集成規(guī)范（IHE）規(guī)范。IHE規(guī)范未定義新的集成標(biāo)準(zhǔn)，而是采用了 “標(biāo)準(zhǔn)協(xié)調(diào)” 過(guò)程推動(dòng)基于工業(yè)標(biāo)準(zhǔn)的醫(yī)療IT系統(tǒng)互操作性。在IHE中，消息傳遞采用的是 HL7 （2.x版本）標(biāo)準(zhǔn)，影像傳遞采用 DICOM標(biāo)準(zhǔn)。本集成平臺(tái)的集成嚴(yán)格參 照該規(guī)范進(jìn)行：

6、信息集成平臺(tái)在進(jìn)行消息時(shí)采用 HL7 2.4標(biāo)準(zhǔn)進(jìn)行消息傳遞、 在消息內(nèi)部傳遞 DICOM StudyUID ，以滿足后續(xù) DICOM 圖像應(yīng)用時(shí)的需要臨床信息集成用于對(duì)各臨床信息系統(tǒng)進(jìn)行信息層面的集成事務(wù)處理。 事務(wù)的 定義參照 IHE 規(guī)范執(zhí)行，消息的交互標(biāo)準(zhǔn)參照 HL7 2.4 標(biāo)準(zhǔn)執(zhí)行。集成平臺(tái)內(nèi)部引擎本身由 Ensemble 集成平臺(tái)基礎(chǔ)之上進(jìn)行二次開(kāi)發(fā)而來(lái)， 依托 Ensemble 本身對(duì)各種適配器的支持，集成平臺(tái)對(duì)外能夠提供多種接入服 務(wù)方式：TCP、文件夾監(jiān)聽(tīng)、FTP文件監(jiān)聽(tīng)、自定義 WebService、SQL監(jiān)聽(tīng) 等形式。以更多接入方式進(jìn)行各種不同方式集成各業(yè)務(wù)系統(tǒng)。集成流

7、程以業(yè)務(wù)流程可視化、 可編輯化對(duì)外提供工作流程的制定與使用。 集 成引擎 基于標(biāo) 準(zhǔn)的業(yè)務(wù) 流程 執(zhí)行語(yǔ) 言( Business Process Execution Language )進(jìn)行擴(kuò)展應(yīng)用，以描述交互應(yīng)用。4.1 信息集成模塊與示例信息集成組件主要由以下幾部分組成 Business Service 業(yè)務(wù)服務(wù)、 Business Process 業(yè)務(wù)處理、 Business Operation 業(yè)務(wù)操作，這幾部分共同 作用下，將集成事務(wù)與消息傳遞進(jìn)行完成。其中， Business Service 主要負(fù)責(zé) 進(jìn)行消息的監(jiān)聽(tīng)與接收； Business Process 負(fù)責(zé)全局的消息路由轉(zhuǎn)發(fā)

8、、事務(wù)流 程處理、消息匹配映射等工作職責(zé)； Business Operation 負(fù)責(zé)將轉(zhuǎn)換完成、最 原子化的一個(gè)操作，發(fā)送 / 調(diào)用信息集成的目標(biāo)端。同時(shí)在三者相互作用下，消 息的反饋準(zhǔn)確的返回到 Business Process ，由 Process 來(lái)講反饋消息控制返回 到消息發(fā)送方。示意圖如下(后續(xù)對(duì)該示例進(jìn)行說(shuō)明) ：Business ServicesSusiness Processesbusiness Operations.BS.WSE MW/SBPtMRPktcOrder Udd Mesqel ia nd lerMRCTLRterI EMRWSClientLMRPOrderO4.

9、1.1業(yè)務(wù)服務(wù)監(jiān)聽(tīng)與接收在當(dāng)今醫(yī)院中，存在各種各種的醫(yī)療業(yè)務(wù)系統(tǒng)，醫(yī)療業(yè)務(wù)系統(tǒng)的多樣性，就 將導(dǎo)致與其集成時(shí)，接入方式的多樣性，如部分系統(tǒng)已實(shí)現(xiàn)TCP的發(fā)送傳遞；部分已實(shí)現(xiàn)文本輸出等。集成平臺(tái)作為醫(yī)院信息系統(tǒng)的中轉(zhuǎn)、 適配角色，在接入 方式的多樣性成為必要條件。如前所述，在這方面，集成平臺(tái)允許的接入方式有： TCP、FILE、FTP、SQL、SOAP(WebService)、HTTP、MAIL 等多種方式與 相應(yīng)的適配器。在多種方式的接入過(guò)程中，將不同來(lái)源的消息通過(guò)統(tǒng)一的出口轉(zhuǎn)交給業(yè)務(wù)處 理部分，由其進(jìn)行路由住轉(zhuǎn)發(fā)、消息匹配映射、業(yè)務(wù)流程處理等相關(guān)的工作。在本示例中，EMRS通過(guò) WebSer

10、vice的服務(wù)監(jiān)聽(tīng)(BS.WS.EMRWS )方 式將消息內(nèi)容傳遞進(jìn)集成平臺(tái)，在通過(guò)驗(yàn)證后，將該消息轉(zhuǎn)發(fā)給了業(yè)務(wù)處理模塊 中的路由模塊。4.1.2消息路由轉(zhuǎn)發(fā)在一些應(yīng)用場(chǎng)景中，如電子病歷系統(tǒng)、重癥監(jiān)護(hù)系統(tǒng)、HIS系統(tǒng)二者進(jìn)行信息傳遞時(shí)，部分信息是需要三者之間交互的，而部分信息僅僅需要兩者之間交互,這在消息轉(zhuǎn)發(fā)路由時(shí)，需要有一定的控制，起到閘門(mén)的作用。如： HIS 系統(tǒng)進(jìn)行 入院登記時(shí)， 需要將病人的信息發(fā)送到電子病歷系統(tǒng)與重癥監(jiān)護(hù)系統(tǒng)； 而在重癥 監(jiān)護(hù)系統(tǒng)采集到病人生命體征信息時(shí)，僅僅將此信息發(fā)送到電子病歷系統(tǒng)即可。 因此，在集成平臺(tái)中，引入消息路由轉(zhuǎn)發(fā)的相關(guān)模塊就顯得比較重要。在本示例中，

11、EMRCTLRouter 這個(gè)消息路由者在接受到 BS.WS.EMRWS 的 消 息 時(shí) ， 可 能 會(huì) 轉(zhuǎn) 發(fā) 至 EMRPlaceOrder 、 EMROrderCA 、 BadMessageHandle 三個(gè)相關(guān)的處理模塊。而具體轉(zhuǎn)發(fā)至何模塊，由消息頭定 義中的相關(guān)信息具體定義。消息路由者起到解析與轉(zhuǎn)發(fā)的作用。4.1.3 事務(wù)業(yè)務(wù)流程處理即時(shí)消息路由已經(jīng)正確路由轉(zhuǎn)發(fā)了消息到準(zhǔn)確的端點(diǎn)，但是在對(duì)應(yīng)的端點(diǎn) 內(nèi)，還會(huì)有一些業(yè)務(wù)流程需要進(jìn)行處理。如在 EMRS 下達(dá)一個(gè)新的 Order 的時(shí) 候，需要的一定的情況下產(chǎn)生不同的業(yè)務(wù)流程分支： 如該病人為門(mén)診病人或者住 院病人，則有必要產(chǎn)生 HL7

12、消息中的住院病人登記信息與門(mén)診病人登記信息： ADTA01 與 ADTA04 。在本示例中， BPEMRPlaceOrder 的內(nèi)部業(yè)務(wù)流程如下，每一個(gè)結(jié)點(diǎn)代表 著一次邏輯處理過(guò)程：it ES*iUtitTd 泄冊(cè) m4.1.4消息匹配映射在一些情況下，消息的傳遞方并無(wú)必要產(chǎn)生HL7標(biāo)準(zhǔn)格式消息的情況下，如EMRS與集成平臺(tái)為內(nèi)部互調(diào)時(shí)，雙方之間提供預(yù)定義的WebService的接口，以快速的開(kāi)發(fā)與進(jìn)行集成。此時(shí)便需要在 WebService 中定義的消息格式與標(biāo)準(zhǔn) HL7 消息格式之間進(jìn) 行著匹配轉(zhuǎn)換的工作。 而該轉(zhuǎn)換工作的處理調(diào)用是由事務(wù)業(yè)務(wù)流程處理模塊來(lái)發(fā) 起調(diào)用的。4.1.5 終端消息

13、發(fā)送在進(jìn)行正確的消息格式轉(zhuǎn)換與業(yè)務(wù)邏輯處理， 此時(shí)的消息已經(jīng)成為一個(gè)符合 終端系統(tǒng)需要的消息格式。 在事務(wù)業(yè)務(wù)流程處理中， 會(huì)將此消息投遞給相應(yīng)的終 端系統(tǒng)。在投遞消息完成工， 事務(wù)業(yè)務(wù)流程處理模塊會(huì)進(jìn)入等待反饋的狀況， 等待終 端系統(tǒng)反饋一個(gè)應(yīng)答消息， 以表示該消息在終端系統(tǒng)中被準(zhǔn)確的處理。 事務(wù)處理 模塊收到該應(yīng)答消息，并組織成發(fā)送端系統(tǒng)需要的消息格式，并作為應(yīng)答系統(tǒng)， 反饋至發(fā)送端系統(tǒng)。4.2 集成事務(wù)處理流程規(guī)劃上述主要針對(duì)集成平臺(tái)中各個(gè)模塊作用于應(yīng)用場(chǎng)景進(jìn)行了闡述，下面將以IHE 規(guī)范中醫(yī)囑下達(dá)方醫(yī)囑執(zhí)行的完整業(yè)務(wù)流程為例，進(jìn)行完整的集成事務(wù)流 程描述。該流程反應(yīng)了普遍的醫(yī)囑流程，

14、多數(shù)院內(nèi)的醫(yī)囑流程都可參照?qǐng)?zhí)行， 為 醫(yī)院的信息系統(tǒng)集成方式提供良好的參考。本示例中，目標(biāo)系統(tǒng)以 PACS 為例。上層應(yīng)用程序集成平臺(tái)新開(kāi)申請(qǐng)單響應(yīng)ADTAA01消息/響應(yīng)ADPA04消息查詢申請(qǐng)安排情況響應(yīng)ORMAO01消息住院病人：發(fā)送 ADPA01消息/門(mén)診病人：發(fā)送 ADTAA04消息發(fā) 送PRMAoon -消息 (contror code=NW)-PACS對(duì)檢查申請(qǐng)進(jìn)行安排后，發(fā)送SIUAS12 消息1響應(yīng)SIUAS12消息|11開(kāi)始檢查時(shí)，發(fā)送 ORMAO01 消息(control code=SC Order Status=SC)|響應(yīng)ORMAO01消息檢查完成后，發(fā)送 ORMAO

15、01 消息(control code=SC Order Status=CM)響應(yīng)ORMAO01消息通知收費(fèi)系統(tǒng)進(jìn)行收費(fèi)I查詢申請(qǐng)檢查信息查詢申請(qǐng)檢查報(bào)告-有圖像數(shù)據(jù)（圖像匹配）后，發(fā)送EIORMAO01 消息(control code二SC Order Status=DA)響應(yīng)ORMAO01消息1發(fā)送DFTAP03消息11響應(yīng)DFTAP03消息報(bào)告完成后，發(fā)送 ORUAR01消息（OBX.11=P，初步報(bào)告）響應(yīng)ORMAO01消息ClI報(bào)告審核后，發(fā)送 ORUAR01消息（OBX.11=F，最終報(bào)告）響應(yīng)ORMAO01消息查詢申請(qǐng)檢查報(bào)告另外，在院內(nèi)經(jīng)常出現(xiàn)的是在IHE規(guī)范中描述的：執(zhí)行者醫(yī)囑

16、流程，即由 醫(yī)囑執(zhí)行者（PACS系統(tǒng)中，為檢查科室）進(jìn)行醫(yī)囑下達(dá)的過(guò)程并執(zhí)行的流程。 如下圖所示：可編輯范本PACS發(fā)送ORMAO01（control code=SN）消息時(shí)，消息中必須包含病人號(hào)（ PID.3 ），也就是說(shuō)病人已經(jīng)掛過(guò)號(hào)。上層應(yīng)用程序集成平臺(tái)PACS急診檢查登錄時(shí)，發(fā)送 ORMAOQ1消息（control code=SN）發(fā)送響應(yīng) ORRAOQ2 消息(control code=NA)開(kāi)始檢查時(shí)，發(fā)送 ORMAOQ1 消息(control code=SC Order Status=SC)響應(yīng)ORMOOI消息檢查完成后，發(fā)送 ORMOOI 消息(control code=SC

17、Order Status=CM)ORMAOQ1 消息發(fā)送DFTAPQ3消息通知收費(fèi)系統(tǒng)進(jìn)行收費(fèi)查詢檢查信息I查詢檢查報(bào)告查詢申請(qǐng)檢查報(bào)告更新或合并病人信息I ! o :響應(yīng)DFTAPQ3消息報(bào)告完成后，發(fā)送 ORUARQ1消息（OBX.11=P，初步報(bào)告）響應(yīng)ORUARQ1消息報(bào)告審核后，發(fā)送 ORUARQ1消息（OBX.11=F，最終報(bào)告）響應(yīng)ORUARQ1消息發(fā)送ADTAAQ8消息，更新病人信息/發(fā)送ADTAA4Q消息，合并病人號(hào)響應(yīng)ADTAAQ8消息/響應(yīng)ADTAA4Q消息5數(shù)據(jù)集成在實(shí)際業(yè)務(wù)應(yīng)用中，日常醫(yī)院的HIS庫(kù)與ERMS庫(kù)之間存在較多需要高頻率、高性能要求的交互,如計(jì)價(jià)信息與藥品

18、庫(kù)存等信息的實(shí)時(shí)共享等。 針對(duì)這樣的應(yīng)用場(chǎng)景，我們采用了 ETL工具(GoldenGate)在數(shù)據(jù)庫(kù)底層進(jìn)行的DB層同 步方式。目前，醫(yī)院已經(jīng)存在比較完整的醫(yī)療信息系統(tǒng)，這些醫(yī)療信息是以 JW1H 系統(tǒng)為基礎(chǔ)，增加醫(yī)院自己的需求發(fā)展而來(lái)。 ERMS 電子病歷系統(tǒng)是一個(gè)完整 的獨(dú)立產(chǎn)品， 他有他自己完整一套的系統(tǒng)架構(gòu)和數(shù)據(jù)中心結(jié)構(gòu)， 而在系統(tǒng)架構(gòu)和 數(shù)據(jù)中心結(jié)構(gòu)上醫(yī)院現(xiàn)有醫(yī)療信息系統(tǒng)和 EMRS 電子病歷系統(tǒng)都存在較大差 異，這就決定了現(xiàn)有系統(tǒng)和 EMRS 電子病歷系統(tǒng)很難共用一個(gè)數(shù)據(jù)庫(kù)?？闪硗?一方面， EMRS 電子病歷系統(tǒng)和醫(yī)院現(xiàn)有醫(yī)療信息系統(tǒng)都是醫(yī)院系統(tǒng)不可分割 的一部分， 他們即有自己

19、工作的重點(diǎn)， 又有相互聯(lián)系和配合， 只有相互無(wú)間的結(jié) 合，才能快速、高效和正確地完成日常工作。應(yīng)用 EMRS 電子病歷系統(tǒng)之后， 醫(yī)院現(xiàn)有醫(yī)療信息系統(tǒng)的主要工作就會(huì)變成傳統(tǒng)意義上的 HIS 業(yè)務(wù)工作，如經(jīng) 濟(jì)管理、人員管理和物資管理等，而 EMRS 電子病歷系統(tǒng)主要完成以患者為中 心的診療行為業(yè)務(wù)工作。兩者之間存在著千絲萬(wàn)縷的關(guān)系，以醫(yī)囑業(yè)務(wù)舉例，如 EMRS 電子病歷系 統(tǒng)下達(dá)、轉(zhuǎn)抄和校對(duì)醫(yī)囑之后， 醫(yī)院現(xiàn)有醫(yī)療信息系統(tǒng)需要完成對(duì)應(yīng)的業(yè)務(wù)操作， 如醫(yī)囑擺藥和醫(yī)囑收費(fèi)操作等， 這就需要在這兩個(gè)系統(tǒng)之間同步數(shù)據(jù)信息， 而涉 及到同步的醫(yī)療業(yè)務(wù)往往涉及的醫(yī)療各個(gè)環(huán)節(jié)，如診療、藥房、收費(fèi)、人員管理

20、等，因此需要信息同步的數(shù)據(jù)量會(huì)比較大， 而同時(shí)為了不造成醫(yī)療業(yè)務(wù)的延遲和 脫節(jié)，也需要很高的實(shí)時(shí)性。在這種應(yīng)用場(chǎng)景下已不適宜采用基于集成平臺(tái)的， 通過(guò)消息交互的應(yīng)用集成 方式。消息集成方式， 往往需要一個(gè)發(fā)起方和接受方， 而發(fā)起方和接受方往往需 要一些額外的支持， 如發(fā)起方需要調(diào)用接受方提供的接口等， 期間可能還涉及到一些負(fù)責(zé)的來(lái)回交互，最主要的是，消息集成在數(shù)據(jù)量很大的情況下， 處理速度不是很快，因此，我們將通過(guò)數(shù)據(jù)集成的方式來(lái)實(shí)現(xiàn)數(shù)據(jù)同步，數(shù)據(jù)庫(kù)集成工具采用 Oracle GoldenGate 。醫(yī)院涉及到需要數(shù)據(jù)同步的包括兩個(gè)部分：HIS數(shù)據(jù)庫(kù)和EMRS數(shù)據(jù)庫(kù)。我們將采用GoldenGa

21、te實(shí)現(xiàn)HIS數(shù)據(jù)庫(kù)數(shù)據(jù)和EMRS數(shù)據(jù)庫(kù)之間的數(shù)據(jù)雙向Golde nGate雙向復(fù)制PRIDE數(shù)據(jù)庫(kù)服務(wù)器從上圖我們可以看到發(fā)生在HIS數(shù)據(jù)庫(kù)上的相關(guān)數(shù)據(jù)變化通過(guò)GoldenGate實(shí)時(shí)同步到EMRS數(shù)據(jù)庫(kù)，而發(fā)生在EMRS數(shù)據(jù)庫(kù)上的相關(guān)數(shù)據(jù) 變化通過(guò)GoldenGate也會(huì)實(shí)時(shí)同步到EMRS數(shù)據(jù)庫(kù)。其中具體的實(shí)現(xiàn)過(guò)程如下圖所示:從上圖我們可以看到數(shù)據(jù)同步的核心是GoldenGate，在HIS數(shù)據(jù)庫(kù)和EMRSEMRS數(shù)據(jù)庫(kù)上變化數(shù)據(jù)的捕獲、傳遞和復(fù)制都是通過(guò)他來(lái)完成的。當(dāng)數(shù)據(jù)庫(kù)發(fā)生數(shù)據(jù)變化的時(shí)候， 如 EMRS 下達(dá)、校對(duì)醫(yī)囑之后， 此時(shí)運(yùn)行在 EMRS 數(shù)據(jù)庫(kù)服務(wù)器上的 GoldenGate

22、 將捕獲該功能業(yè)務(wù)對(duì)應(yīng)的變化數(shù)據(jù)，并通過(guò)網(wǎng) 絡(luò)傳遞到 HIS 數(shù)據(jù)庫(kù)， HIS 數(shù)據(jù)庫(kù)接收到這些變化數(shù)據(jù)之后，運(yùn)行在 HIS 數(shù)據(jù) 庫(kù)服務(wù)器上的 GoldenGate 解析這些變化數(shù)據(jù)并應(yīng)用到 HIS 數(shù)據(jù)庫(kù)，此時(shí)如擺 藥程序就能看到相應(yīng)的醫(yī)囑記錄并進(jìn)行擺藥。反之 HIS 數(shù)據(jù)庫(kù)上的變化數(shù)據(jù)也 是經(jīng)過(guò)上述過(guò)程應(yīng)用到 EMRS 數(shù)據(jù)庫(kù)。通過(guò) GoldenGate 我們可以很好地實(shí)現(xiàn)了 HIS 數(shù)據(jù)庫(kù)和 EMRS 數(shù)據(jù)庫(kù)的之 間的獨(dú)立和聯(lián)系， 使他們各盡其職， 分工明確， 一起很好地共同支撐整個(gè)醫(yī)院的 正常運(yùn)營(yíng)。5.1 GoldenGate 概述Oracle GoldenGate 軟件是一種基于日

23、志的結(jié)構(gòu)化數(shù)據(jù)復(fù)制軟件，它議決 剖析源數(shù)據(jù)庫(kù)在線日志或歸檔日志取得數(shù)據(jù)的增量改變， 再將這些改變運(yùn)用到目 標(biāo)數(shù)據(jù)庫(kù)，從而完成源數(shù)據(jù)庫(kù)與目標(biāo)數(shù)據(jù)庫(kù)同步。 GoldenGate 能夠在異構(gòu)的 IT 基本結(jié)構(gòu)（包括幾乎一切常用操作系統(tǒng)平臺(tái)和數(shù)據(jù)庫(kù)平臺(tái)）之間完成大量數(shù) 據(jù)亞秒一級(jí)的及時(shí)復(fù)制 ,從而在能夠在應(yīng)急系統(tǒng)、在線報(bào)表、及時(shí)數(shù)據(jù)倉(cāng)庫(kù)供應(yīng)、 買賣跟蹤、數(shù)據(jù)同步、集中 / 分發(fā)、容災(zāi)等多個(gè)場(chǎng)景下運(yùn)用，而我們采用的場(chǎng)景 是數(shù)據(jù)雙向復(fù)制， GoldenGate 雙向復(fù)制的工作原理如下圖所示：Capture：實(shí)時(shí)逮取交易日志捕捉蠹據(jù)更化并可實(shí)現(xiàn)過(guò)邈源數(shù)據(jù)庫(kù)戲向復(fù)制如上所示，GoldenGate在實(shí)現(xiàn)數(shù)據(jù)同步

24、的時(shí)候，主要涉及到三個(gè)重要 進(jìn)程：抽取進(jìn)程、投遞進(jìn)程和應(yīng)用進(jìn)程。1. 抽取進(jìn)程：就是上圖Capture進(jìn)程，該進(jìn)程主要負(fù)責(zé)讀取數(shù)據(jù)庫(kù)對(duì)應(yīng)的 日志文件，將數(shù)據(jù)變化保存到隊(duì)列文件中；2. 投遞進(jìn)程：也叫傳輸進(jìn)程，該進(jìn)程主要負(fù)責(zé)將源數(shù)據(jù)庫(kù)中產(chǎn)生的變化的 隊(duì)列文件進(jìn)過(guò)壓縮和加密等方式，通過(guò)網(wǎng)絡(luò)傳輸?shù)侥康臄?shù)據(jù)庫(kù)；3. 應(yīng)用進(jìn)程：也叫接納進(jìn)程，該進(jìn)程主要負(fù)責(zé)將投遞進(jìn)程傳遞過(guò)來(lái)的源數(shù) 據(jù)庫(kù)的數(shù)據(jù)變化隊(duì)列文件解析出來(lái)，并應(yīng)用到目的數(shù)據(jù)庫(kù)中。上述三個(gè)進(jìn)程完成了從源數(shù)據(jù)庫(kù)到目的數(shù)據(jù)庫(kù)的單項(xiàng)同步，如果再加上從目的數(shù)據(jù)庫(kù)到源數(shù)據(jù)庫(kù)的相似的三個(gè)進(jìn)程，就實(shí)現(xiàn)了源數(shù)據(jù)庫(kù)和目的數(shù)據(jù)庫(kù)之間的 雙向同步。5.2 GoldenGa

25、te 的特性1. 基于日志的實(shí)時(shí)數(shù)據(jù)復(fù)制：相比傳統(tǒng)依賴數(shù)據(jù)庫(kù)觸發(fā)器和規(guī)則的方法來(lái)捕獲數(shù)據(jù)變化，GoldenGate采用讀取日志方式對(duì)源數(shù)據(jù)庫(kù)影響小很多,速度也快很多。數(shù)據(jù)庫(kù)乩點(diǎn)如上圖所示，GoldenGate是通過(guò)數(shù)據(jù)日志挖掘的方式實(shí)現(xiàn)的。2. 事務(wù)完整性：Golde nGate只復(fù)制成功提交的事務(wù)，同時(shí)目標(biāo)數(shù)據(jù)庫(kù)按 照源數(shù)據(jù)庫(kù)的操作順序，而且，可以中斷可以自動(dòng)恢復(fù)，這些保證了源 和目標(biāo)之間的事務(wù)完整性。3. 檢查點(diǎn)機(jī)制保障數(shù)據(jù)無(wú)丟失：Golde nGate的抽取和復(fù)制進(jìn)程使用檢查點(diǎn)機(jī)制記錄完成復(fù)制的位置。對(duì)于抽取進(jìn)程，其檢查點(diǎn)記錄當(dāng)前已經(jīng)抽 取日志的位置和寫(xiě)隊(duì)列文件的位置；對(duì)于投遞進(jìn)程，其檢

26、查點(diǎn)記錄當(dāng)前 讀取隊(duì)列文件的位置。Ccwnmil. IX 2TK 2BQir. TX 3Hnatii, TK 3Begin. TX4CfiftimlE, TX 1CaptureCheckpoint為fif讀詢Y atComrpt OpenedQJDtlivjyPajlfipCarnrt OrderedTd-ge? Trd目標(biāo)數(shù)館庫(kù)上圖中，Capture、Pump和Devlivery 將傳遞狀態(tài)存儲(chǔ)至 checkpointfile確保其恢復(fù)性，檢查點(diǎn)機(jī)制可以保證在系統(tǒng)、網(wǎng)絡(luò)或GoldenGate進(jìn)程故障重啟后數(shù)據(jù)無(wú)丟失?？煽康臄?shù)據(jù)傳輸機(jī)制：Golde nGate用應(yīng)答機(jī)制傳輸交易數(shù)據(jù)，只有在得到

27、確認(rèn)消息后才認(rèn)為數(shù)據(jù)傳輸完成，否則將自動(dòng)重新傳輸數(shù)據(jù)，從而保證了抽取出 的所有數(shù)據(jù)都能發(fā)送到目標(biāo)端。數(shù)據(jù)傳輸過(guò)程中支持 128位加密和數(shù)據(jù)壓縮功6界面集成對(duì)于醫(yī)學(xué)影像、心電圖波形數(shù)據(jù)，臨床醫(yī)生的需求是，不僅能瀏覽圖像和波 形，還須有對(duì)其處理的要求，通常對(duì)應(yīng)系統(tǒng)供應(yīng)商提供了 DICOM影像瀏覽器和 心電圖瀏覽器，這些瀏覽器提供相應(yīng)的工具來(lái)處理、管理、傳輸和轉(zhuǎn)換圖像和波 形。針對(duì)這種帶專業(yè)處理功能的人機(jī)交互界面的應(yīng)用程序，我們采用界面集成的 方式，集成專業(yè)瀏覽器插件或應(yīng)用程序。針對(duì)這種方式的場(chǎng)景，EMRS系統(tǒng)將采用界面集成應(yīng)用的方式集成數(shù)據(jù)綜合瀏覽視圖，在臨床數(shù)據(jù)中心一節(jié)中已提到，該視圖采用組件化方式進(jìn)行開(kāi)發(fā)， 實(shí)質(zhì)是各類專業(yè)瀏覽插件的容器，支持對(duì)各種醫(yī)學(xué)影像（X-Ray、CT、MRI、超聲、胃腸鏡）、心電圖、監(jiān)護(hù)數(shù)據(jù)和麻醉監(jiān)護(hù)數(shù)據(jù)等在內(nèi)的多種醫(yī)療數(shù)據(jù)的綜 合閱覽分析。至于各專業(yè)瀏覽器插件內(nèi)部的實(shí)現(xiàn)， 可能又會(huì)采用應(yīng)用集成的方式，但通常 為了提高性能，和多媒體資料庫(kù)中心采用直連的方式獲取影像和波形。以DICOM影像瀏覽器組件為例，其內(nèi)部采用DICOM標(biāo)準(zhǔn)進(jìn)行醫(yī)學(xué)影像格 式定義與交互傳輸。該模塊以O(shè)CX控件的方式實(shí)現(xiàn)，同時(shí)提供給集成事務(wù)處理 模塊和醫(yī)護(hù)工作站使用。EMRS醫(yī)護(hù)工作站使用DICOM