最新醫(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)一且標(biāo)準(zhǔn)的數(shù)據(jù)交換和工作

3、流協(xié)同的平臺(tái)。3 信息集成方法信息集成方法有三，即應(yīng)用集成、數(shù)據(jù)集成、界面集成，這三種集成方式各精品文檔精品文檔解決不同方面的問(wèn)題。 應(yīng)用集成指應(yīng)用程序之間實(shí)時(shí)或異步交換信息和相互調(diào)用功能，可以采用 HL7消息， WebService ，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 插件、 Portlet 、IFrame 等。

4、協(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ù)量不大， 實(shí)時(shí)性要求不高， 且各信息系統(tǒng)各專業(yè)廠商實(shí)現(xiàn)方式

5、相差較大，采用基于集成平臺(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ù)等方式。精品文檔精品文檔醫(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)行：信息集成平臺(tái)在進(jìn)行消息時(shí)采用HL7

6、 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)。集成流程以業(yè)務(wù)流程可視化、可編輯化對(duì)外提供工作流程的制

7、定與使用。集成引擎基于標(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ù)、BusinessProcess 業(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ā)、事務(wù)流程處理、消息匹配映射等工作職責(zé)； Business Oper

8、ation負(fù)責(zé)將轉(zhuǎn)換完成、最原子化的一個(gè)操作，發(fā)送 / 調(diào)用信息集成的目標(biāo)端。同時(shí)在三者相互作用下，消息的反饋準(zhǔn)確的返回到 Business Process ，由 Process 來(lái)講反饋消息控制返回到消息發(fā)送方。示意圖如下（后續(xù)對(duì)該示例進(jìn)行說(shuō)明） ：業(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(

9、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ò) WebService 的服務(wù)監(jiān)聽(tīng)（）方式將消息內(nèi)容傳遞進(jìn)集成平臺(tái)， 在通過(guò)驗(yàn)證后， 將該消息轉(zhuǎn)發(fā)給了業(yè)務(wù)處理模塊中的路精品文檔精品文檔由模塊。消息路由轉(zhuǎn)發(fā)在一些應(yīng)用場(chǎng)景中，如電子病歷系統(tǒng)、重癥監(jiān)護(hù)系統(tǒng)、 HIS 系統(tǒng)三者進(jìn)行信息傳遞時(shí)，部分信息是需要三者之間交互的， 而部分信息僅僅需要兩者之間交互，這在消息轉(zhuǎn)發(fā)路由時(shí)，需要有一定的控制，起到閘門的作用。如： HI

10、S 系統(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)模塊就顯得比較重要。在本示例中， EMRCTLRouter這個(gè)消息路由者在接受到的消息時(shí)，可能會(huì)轉(zhuǎn)發(fā)至 EMRPlaceOrder、EMROrderCA、BadMessageHandle三個(gè)相關(guān)的處理模塊。而具體轉(zhuǎn)發(fā)至何模塊， 由消息頭定義中的相關(guān)信息具體定義。 消息路由者起到解析與轉(zhuǎn)發(fā)的作用。事務(wù)業(yè)務(wù)流程處理即時(shí)消息路由已經(jīng)正確路由轉(zhuǎn)發(fā)了消息到準(zhǔn)確的端點(diǎn)， 但是在對(duì)應(yīng)的端點(diǎn)內(nèi)，還會(huì)有一些業(yè)務(wù)流程需要

11、進(jìn)行處理。如在 EMRS下達(dá)一個(gè)新的 Order 的時(shí)候，需要的一定的情況下產(chǎn)生不同的業(yè)務(wù)流程分支：如該病人為門診病人或者住院病人，則有必要產(chǎn)生HL7 消息中的住院病人登記信息與門診病人登記信息：ADTA01與ADTA04。在本示例中， BPEMRPlaceOrder的內(nèi)部業(yè)務(wù)流程如下，每一個(gè)結(jié)點(diǎn)代表著一次邏輯處理過(guò)程：精品文檔精品文檔消息匹配映射在一些情況下， 消息的傳遞方并無(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)

12、準(zhǔn)HL7消息格式之間進(jìn)行著匹配轉(zhuǎn)換的工作。 而該轉(zhuǎn)換工作的處理調(diào)用是由事務(wù)業(yè)務(wù)流程處理模塊來(lái)發(fā)起調(diào)用的。終端消息發(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ī)

13、囑下達(dá)方醫(yī)囑執(zhí)行的完整業(yè)務(wù)流程為例，進(jìn)行完整的集成事務(wù)流程描述。該流程反應(yīng)了普遍的醫(yī)囑流程，多數(shù)院內(nèi)的醫(yī)囑流程都可參照?qǐng)?zhí)行，為醫(yī)院的信息系統(tǒng)集成方式提供良好的參考。本示例中，目標(biāo)系統(tǒng)以PACS為例。精品文檔精品文檔上層應(yīng)用程序集成平臺(tái)PACS新開(kāi)申請(qǐng)單住院病人：發(fā)送 ADTA01消息 /門診病人：發(fā)送ADTA04 消息響應(yīng) ADTA01消息 /響應(yīng) ADTA04消息發(fā)送 ORMO01 消息 (control code=NW)響應(yīng) ORMO01 消息對(duì)檢查申請(qǐng)進(jìn)行安排后，發(fā)送SIUS12 消息響應(yīng) SIUS12 消息查詢申請(qǐng)安排情況開(kāi)始檢查時(shí)，發(fā)送ORMO01 消息 (control code=

14、SC Order Status=SC)響應(yīng) ORMO01 消息檢查完成后，發(fā)送ORMO01 消息 (control code=SC Order Status=CM)響應(yīng) ORMO01 消息有圖像數(shù)據(jù)（圖像匹配）后，發(fā)送ORMO01 消息 (control code=SC Order Status=DA)響應(yīng) ORMO01 消息發(fā)送 DFTP03 消息響應(yīng) DFTP03 消息通知收費(fèi)系統(tǒng)進(jìn)行收費(fèi)查詢申請(qǐng)檢查信息報(bào)告完成后，發(fā)送ORUR01 消息 (OBX.11=P ，初步報(bào)告 )響應(yīng) ORMO01 消息查詢申請(qǐng)檢查報(bào)告報(bào)告審核后，發(fā)送ORUR01 消息 (OBX.11=F ，最終報(bào)告 )響應(yīng) O

15、RMO01 消息查詢申請(qǐng)檢查報(bào)告另外，在院內(nèi)經(jīng)常出現(xiàn)的是在IHE 規(guī)范中描述的：執(zhí)行者醫(yī)囑流程，即由醫(yī)囑執(zhí)行者（ PACS系統(tǒng)中，為檢查科室）進(jìn)行醫(yī)囑下達(dá)的過(guò)程并執(zhí)行的流程。如下圖所示：精品文檔精品文檔PACS 發(fā)送 ORMO01(control code=SN) 消息時(shí)，消息中必須包含病人號(hào)（PID.3 ），也就是說(shuō)病人已經(jīng)掛過(guò)號(hào)。上層應(yīng)用程序集成平臺(tái)PACS急診檢查登錄時(shí)，發(fā)送ORMO01 消息 (control code=SN)發(fā)送響應(yīng) ORRO02 消息 (control code=NA)開(kāi)始檢查時(shí)，發(fā)送ORMO01 消息 (control code=SC Order Status=S

16、C)響應(yīng) ORMO01 消息檢查完成后，發(fā)送ORMO01 消息 (control code=SC Order Status=CM)響應(yīng) ORMO01 消息發(fā)送 DFTP03 消息響應(yīng) DFTP03 消息通知收費(fèi)系統(tǒng)進(jìn)行收費(fèi)查詢檢查信息報(bào)告完成后，發(fā)送ORUR01 消息 (OBX.11=P ，初步報(bào)告 )響應(yīng) ORUR01 消息查詢檢查報(bào)告報(bào)告審核后，發(fā)送ORUR01 消息 (OBX.11=F ，最終報(bào)告 )響應(yīng) ORUR01 消息查詢申請(qǐng)檢查報(bào)告更新或合并病人信息發(fā)送 ADTA08 消息，更新病人信息/發(fā)送 ADTA40 消息，合并病人號(hào)響應(yīng) ADTA08 消息 / 響應(yīng) ADTA40 消息5

17、 數(shù)據(jù)集成在實(shí)際業(yè)務(wù)應(yīng)用中，日常醫(yī)院的 HIS 庫(kù)與 ERMS庫(kù)之間存在較多需要高頻率、高性能要求的交互， 如計(jì)價(jià)信息與藥品庫(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)很難

18、共用一個(gè)數(shù)據(jù)庫(kù)。 可另外一方面，EMRS電子病歷系統(tǒng)和醫(yī)院現(xiàn)有醫(yī)療信息系統(tǒng)都是醫(yī)院系統(tǒng)不可分割的一部分， 他們即有自己工作的重點(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)之間

19、同步數(shù)據(jù)信息， 而涉及到同步的醫(yī)療業(yè)務(wù)往往涉及的醫(yī)療各個(gè)環(huán)節(jié)，如診療、藥房、收費(fèi)、人員管理等，因此需要信息同步的數(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ī)院

20、涉及到需要數(shù)據(jù)同步的包括兩個(gè)部分： HIS 數(shù)據(jù)庫(kù)和 EMRS數(shù)據(jù)庫(kù)。我們將采用 GoldenGate 實(shí)現(xiàn) HIS 數(shù)據(jù)庫(kù)數(shù)據(jù)和 EMRS數(shù)據(jù)庫(kù)之間的數(shù)據(jù)雙向同步。其基本結(jié)構(gòu)圖如下圖所示：精品文檔精品文檔HIS數(shù)據(jù)庫(kù)PRIDE數(shù)據(jù)庫(kù)服務(wù)器服務(wù)器GoldenGate雙向復(fù)制從上圖我們可以看到發(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ù)和 EMRS數(shù)據(jù)庫(kù)上變化

21、數(shù)據(jù)的捕獲、傳遞和復(fù)制都是通過(guò)他來(lái)完成的。當(dāng)EMRS數(shù)據(jù)庫(kù)發(fā)生數(shù)據(jù)變化的時(shí)候， 如 EMRS下達(dá)、校對(duì)醫(yī)囑之后， 此時(shí)運(yùn)行在 EMRS數(shù)據(jù)庫(kù)服務(wù)器上的 GoldenGate 將捕獲該功能業(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)系， 使他們各

22、盡其職， 分工明確， 一起很好地共同支撐整個(gè)醫(yī)院的正常運(yùn)營(yíng)。精品文檔精品文檔5.1 GoldenGate 概述Oracle GoldenGate 軟件是一種基于日志的結(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ù)制， GoldenG

23、ate 雙向復(fù)制的工作原理如下圖所示：如上所示， GoldenGate 在實(shí)現(xiàn)數(shù)據(jù)同步的時(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ù)

24、到源數(shù)據(jù)庫(kù)的相似的三個(gè)進(jìn)程，就實(shí)現(xiàn)了源數(shù)據(jù)庫(kù)和目的數(shù)據(jù)庫(kù)之間的雙向同步。5.2 GoldenGate 的特性1. 基于日志的實(shí)時(shí)數(shù)據(jù)復(fù)制：相比傳統(tǒng)依賴數(shù)據(jù)庫(kù)觸發(fā)器和規(guī)則的方法來(lái)捕獲數(shù)據(jù)變化， GoldenGate 采用讀取日志方式對(duì)源數(shù)據(jù)庫(kù)影響小很多，速度也快很多。如上圖所示， GoldenGate 是通過(guò)數(shù)據(jù)日志挖掘的方式實(shí)現(xiàn)的。2.3. 事務(wù)完整性： GoldenGate 只復(fù)制成功提交的事務(wù)，同時(shí)目標(biāo)數(shù)據(jù)庫(kù)按照源數(shù)據(jù)庫(kù)的操作順序，而且，可以中斷可以自動(dòng)恢復(fù)，這些保證了源和目標(biāo)之間的事務(wù)完整性。4. 檢查點(diǎn)機(jī)制保障數(shù)據(jù)無(wú)丟失： GoldenGate 的抽取和復(fù)制進(jìn)程使用檢查點(diǎn)機(jī)制記錄完成復(fù)

25、制的位置。對(duì)于抽取進(jìn)程，其檢查點(diǎn)記錄當(dāng)前已經(jīng)抽取日志的位置和寫(xiě)隊(duì)列文件的位置；對(duì)于投遞進(jìn)程，其檢查點(diǎn)記錄當(dāng)前讀取隊(duì)列文件的位置。精品文檔精品文檔上圖中，Capture 、Pump和 Devlivery 將傳遞狀態(tài)存儲(chǔ)至 checkpoint file 確保其恢復(fù)性， 檢查點(diǎn)機(jī)制可以保證在系統(tǒng)、 網(wǎng)絡(luò)或 GoldenGate 進(jìn)程故障重啟后數(shù)據(jù)無(wú)丟失?？煽康臄?shù)據(jù)傳輸機(jī)制：GoldenGate 用應(yīng)答機(jī)制傳輸交易數(shù)據(jù)，只有在得到確認(rèn)消息后才認(rèn)為數(shù)據(jù)傳輸完成，否則將自動(dòng)重新傳輸數(shù)據(jù)， 從而保證了抽取出的所有數(shù)據(jù)都能發(fā)送到目標(biāo)端。 數(shù)據(jù)傳輸過(guò)程中支持128 位加密和數(shù)據(jù)壓縮功能。67 界面集成對(duì)于醫(yī)學(xué)

26、影像、心電圖波形數(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é)影像格式定義與交互傳輸。 該模塊以 OCX控件的方式實(shí)現(xiàn)， 同時(shí)提供給集成事務(wù)處理模塊和醫(yī)護(hù)工作站使用。 EMRS醫(yī)護(hù)工作站使用 DICOM引擎主要實(shí)現(xiàn)從影像中心查詢和獲取影像