醫(yī)院信息集成平臺建設方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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