醫(yī)院信息集成平臺建設(shè)方案-
《醫(yī)院信息集成平臺建設(shè)方案-》由會員分享,可在線閱讀,更多相關(guān)《醫(yī)院信息集成平臺建設(shè)方案-(16頁珍藏版)》請在裝配圖網(wǎng)上搜索。
1、信息集成平臺建設(shè)方案 1 建設(shè)需求 一個完善的醫(yī)院信息系統(tǒng)通常由上百個子系統(tǒng)組成,牽涉眾多的專業(yè)領(lǐng)域。這么龐大的系統(tǒng)需要非常專業(yè)化的軟件開發(fā)分工,整合不同廠商有特色的專業(yè)系統(tǒng)是醫(yī)院信息系統(tǒng)的發(fā)展趨勢,醫(yī)院信息化能夠取得成功必須保證各個系統(tǒng)的有效集成和數(shù)據(jù)的高度共享。然而這些系統(tǒng)通常是隨著醫(yī)院的發(fā)展需求逐步建設(shè)的,它們來源于不同的廠家,基于不同的技術(shù),缺乏統(tǒng)一的信息交換標(biāo)準(zhǔn),這些系統(tǒng)的集成整合已經(jīng)逐漸成為醫(yī)院數(shù)字化發(fā)展亟待解決的主要問題。 系統(tǒng)集成平臺的構(gòu)建主要面向兩個核心問題:一個是為各種醫(yī)療應(yīng)用提供統(tǒng)一的醫(yī)療數(shù)據(jù)訪問服務(wù),從而消除各種醫(yī)療應(yīng)用系統(tǒng)與醫(yī)療數(shù)據(jù)中心的直接耦合性;另一個是為各
2、種臨床信息系統(tǒng)提供系統(tǒng)集成服務(wù),系統(tǒng)集成服務(wù)基于系統(tǒng)集成模型,通過HL7和DICOM等標(biāo)準(zhǔn)通訊協(xié)議為各種醫(yī)療應(yīng)用系統(tǒng)提供集成服務(wù),確保各個臨床信息系統(tǒng)在工作流整合的基礎(chǔ)上實現(xiàn)交互協(xié)作,從而以數(shù)字化的形式完成各項醫(yī)療業(yè)務(wù)。 2 建設(shè)目標(biāo) 系統(tǒng)間的整合、集成和擴展一直都是制約醫(yī)院數(shù)字化發(fā)展的主要障礙,由于不同廠商之間的產(chǎn)品不兼容,使得醫(yī)院整體信息化步履維艱。通過建設(shè)一個規(guī)范的系統(tǒng)集成平臺,在IHE、DICOM、HL7等國際標(biāo)準(zhǔn)的基礎(chǔ)上,制定覆蓋醫(yī)療所有業(yè)務(wù)流程的系統(tǒng)集成規(guī)范,開發(fā)基于規(guī)范的系統(tǒng)集成平臺,為遺留的、當(dāng)前的以及將來的系統(tǒng)提供了一個統(tǒng)一且標(biāo)準(zhǔn)的數(shù)據(jù)交換和工作流協(xié)同的平臺。 3 信息
3、集成方法 信息集成方法有三,即應(yīng)用集成、數(shù)據(jù)集成、界面集成,這三種集成方式各解決不同方面的問題。應(yīng)用集成指應(yīng)用程序之間實時或異步交換信息和相互調(diào)用功能,可以采用HL7消息,Web Service,CORBA,EJB,DCOM, RPC等標(biāo)準(zhǔn),采用消息中間件,BPM等中間件實現(xiàn);數(shù)據(jù)集成是指應(yīng)用系統(tǒng)的數(shù)據(jù)庫系統(tǒng)之間的數(shù)據(jù)交換和共享,以及數(shù)據(jù)之間的映射變換,常采用ETL(Extract-Transform-Load)工具實現(xiàn);界面集成含義是應(yīng)用程序界面之間相互關(guān)聯(lián)引用合成,采用技術(shù)包括ActiveX插件、Portlet、IFrame等。 協(xié)同應(yīng)用從早期單純的點對點接口方式,發(fā)展到現(xiàn)如今的集成平
4、臺方式。各種方式中: 點對點接口方式的復(fù)雜性在于要和不同的系統(tǒng)建立1:N的接口,假定有N個系統(tǒng)相互之間需要建立接口,則接口數(shù)為 N*(N-1)/2。 集成平臺方式中,在N個系統(tǒng)需要進(jìn)行應(yīng)用協(xié)同的情況下,只需要開發(fā)N個適配器接口即可,減少了集成平臺的系統(tǒng)負(fù)荷。 由于醫(yī)院信息系統(tǒng)復(fù)雜性,我們根據(jù)不同的需求和應(yīng)用場景,設(shè)計分別采用上述三種不同集成方法和手段進(jìn)行信息集成。 4 應(yīng)用集成 和醫(yī)技輔診科室信息系統(tǒng)(如PACS/RIS、LIS、MUSE等)的信息集成,這種場景,信息交互的數(shù)據(jù)量不大,實時性要求不高,且各信息系統(tǒng)各專業(yè)廠商實現(xiàn)方式相差較大,采用基于集成平臺的應(yīng)用集成方式是最優(yōu)選擇
5、。 集成平臺體系結(jié)構(gòu)如下圖所示,集成平臺對外提供支持多種方式的集成服務(wù):包括WebService服務(wù)、TCP監(jiān)聽服務(wù)、文件監(jiān)測服務(wù)、FTP服務(wù)、SQL監(jiān)控服務(wù)等方式。 醫(yī)院信息系統(tǒng)在國際、國內(nèi)廣泛采用的有一套集成規(guī)范,即:醫(yī)療健康信息集成規(guī)范(IHE)規(guī)范。IHE規(guī)范未定義新的集成標(biāo)準(zhǔn),而是采用了“標(biāo)準(zhǔn)協(xié)調(diào)”過程推動基于工業(yè)標(biāo)準(zhǔn)的醫(yī)療IT系統(tǒng)互操作性。在IHE中,消息傳遞采用的是HL7(2.x版本)標(biāo)準(zhǔn),影像傳遞采用DICOM標(biāo)準(zhǔn)。本集成平臺的集成嚴(yán)格參照該規(guī)范進(jìn)行:信息集成平臺在進(jìn)行消息時采用HL7 2.4標(biāo)準(zhǔn)進(jìn)行消息傳遞、在消息內(nèi)部傳遞DICOM StudyUID,以滿足后續(xù)DIC
6、OM圖像應(yīng)用時的需要。 臨床信息集成用于對各臨床信息系統(tǒng)進(jìn)行信息層面的集成事務(wù)處理。事務(wù)的定義參照IHE規(guī)范執(zhí)行,消息的交互標(biāo)準(zhǔn)參照HL7 2.4標(biāo)準(zhǔn)執(zhí)行。 集成平臺內(nèi)部引擎本身由Ensemble集成平臺基礎(chǔ)之上進(jìn)行二次開發(fā)而來,依托Ensemble本身對各種適配器的支持,集成平臺對外能夠提供多種接入服務(wù)方式:TCP、文件夾監(jiān)聽、FTP文件監(jiān)聽、自定義WebService、SQL監(jiān)聽等形式。以更多接入方式進(jìn)行各種不同方式集成各業(yè)務(wù)系統(tǒng)。 集成流程以業(yè)務(wù)流程可視化、可編輯化對外提供工作流程的制定與使用。集成引擎基于標(biāo)準(zhǔn)的業(yè)務(wù)流程執(zhí)行語言(Business Process Execution
7、 Language)進(jìn)行擴展應(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)聽與接收;Business Process負(fù)責(zé)全局的消息路由轉(zhuǎn)發(fā)、事務(wù)流程處理、消息匹配映射等工作職責(zé);Business Operation負(fù)責(zé)將轉(zhuǎn)換完成、最原子化的一個操作,發(fā)送/調(diào)用信息集成的目標(biāo)端。同時在三者相互作用下,消息的反饋準(zhǔn)確的返回
8、到Business Process,由Process來講反饋消息控制返回到消息發(fā)送方。示意圖如下(后續(xù)對該示例進(jìn)行說明): 4.1.1 業(yè)務(wù)服務(wù)監(jiān)聽與接收 在當(dāng)今醫(yī)院中,存在各種各種的醫(yī)療業(yè)務(wù)系統(tǒng),醫(yī)療業(yè)務(wù)系統(tǒng)的多樣性,就將導(dǎo)致與其集成時,接入方式的多樣性,如部分系統(tǒng)已實現(xiàn)TCP的發(fā)送傳遞;部分已實現(xiàn)文本輸出等。集成平臺作為醫(yī)院信息系統(tǒng)的中轉(zhuǎn)、適配角色,在接入方式的多樣性成為必要條件。如前所述,在這方面,集成平臺允許的接入方式有:TCP、FILE、FTP、SQL、SOAP(WebService)、HTTP、MAIL等多種方式與相應(yīng)的適配器。 在多種方式的接入過程中,將不同來源的消息通
9、過統(tǒng)一的出口轉(zhuǎn)交給業(yè)務(wù)處理部分,由其進(jìn)行路由住轉(zhuǎn)發(fā)、消息匹配映射、業(yè)務(wù)流程處理等相關(guān)的工作。 在本示例中,EMRS通過WebService的服務(wù)監(jiān)聽(BS.WS.EMRWS)方式將消息內(nèi)容傳遞進(jìn)集成平臺,在通過驗證后,將該消息轉(zhuǎn)發(fā)給了業(yè)務(wù)處理模塊中的路由模塊。 4.1.2 消息路由轉(zhuǎn)發(fā) 在一些應(yīng)用場景中,如電子病歷系統(tǒng)、重癥監(jiān)護系統(tǒng)、HIS系統(tǒng)三者進(jìn)行信息傳遞時,部分信息是需要三者之間交互的,而部分信息僅僅需要兩者之間交互,這在消息轉(zhuǎn)發(fā)路由時,需要有一定的控制,起到閘門的作用。如:HIS系統(tǒng)進(jìn)行入院登記時,需要將病人的信息發(fā)送到電子病歷系統(tǒng)與重癥監(jiān)護系統(tǒng);而在重癥監(jiān)護系統(tǒng)采集到病人生命體
10、征信息時,僅僅將此信息發(fā)送到電子病歷系統(tǒng)即可。因此,在集成平臺中,引入消息路由轉(zhuǎn)發(fā)的相關(guān)模塊就顯得比較重要。 在本示例中,EMRCTLRouter這個消息路由者在接受到BS.WS.EMRWS的消息時,可能會轉(zhuǎn)發(fā)至EMRPlaceOrder、EMROrderCA、BadMessageHandle三個相關(guān)的處理模塊。而具體轉(zhuǎn)發(fā)至何模塊,由消息頭定義中的相關(guān)信息具體定義。消息路由者起到解析與轉(zhuǎn)發(fā)的作用。 4.1.3 事務(wù)業(yè)務(wù)流程處理 即時消息路由已經(jīng)正確路由轉(zhuǎn)發(fā)了消息到準(zhǔn)確的端點,但是在對應(yīng)的端點內(nèi),還會有一些業(yè)務(wù)流程需要進(jìn)行處理。如在EMRS下達(dá)一個新的Order的時候,需要的一定的情況下產(chǎn)
11、生不同的業(yè)務(wù)流程分支:如該病人為門診病人或者住院病人,則有必要產(chǎn)生HL7 消息中的住院病人登記信息與門診病人登記信息:ADTA01與ADTA04。 在本示例中,BPEMRPlaceOrder的內(nèi)部業(yè)務(wù)流程如下,每一個結(jié)點代表著一次邏輯處理過程: 4.1.4 消息匹配映射 在一些情況下,消息的傳遞方并無必要產(chǎn)生HL7標(biāo)準(zhǔn)格式消息的情況下,如EMRS與集成平臺為內(nèi)部互調(diào)時,雙方之間提供預(yù)定義的WebService的接口,以快速的開發(fā)與進(jìn)行集成。 此時便需要在WebService中定義的消息格式與標(biāo)準(zhǔn)HL7消息格式之間進(jìn)行著匹配轉(zhuǎn)換的工作。而該轉(zhuǎn)換工作的處理調(diào)用是由事務(wù)業(yè)務(wù)流程處理模塊來
12、發(fā)起調(diào)用的。 4.1.5 終端消息發(fā)送 在進(jìn)行正確的消息格式轉(zhuǎn)換與業(yè)務(wù)邏輯處理,此時的消息已經(jīng)成為一個符合終端系統(tǒng)需要的消息格式。在事務(wù)業(yè)務(wù)流程處理中,會將此消息投遞給相應(yīng)的終端系統(tǒng)。 在投遞消息完成工,事務(wù)業(yè)務(wù)流程處理模塊會進(jìn)入等待反饋的狀況,等待終端系統(tǒng)反饋一個應(yīng)答消息,以表示該消息在終端系統(tǒng)中被準(zhǔn)確的處理。事務(wù)處理模塊收到該應(yīng)答消息,并組織成發(fā)送端系統(tǒng)需要的消息格式,并作為應(yīng)答系統(tǒng),反饋至發(fā)送端系統(tǒng)。 4.2 集成事務(wù)處理流程規(guī)劃 上述主要針對集成平臺中各個模塊作用于應(yīng)用場景進(jìn)行了闡述,下面將以IHE規(guī)范中醫(yī)囑下達(dá)方醫(yī)囑執(zhí)行的完整業(yè)務(wù)流程為例,進(jìn)行完整的集成事務(wù)流程描述。該流程
13、反應(yīng)了普遍的醫(yī)囑流程,多數(shù)院內(nèi)的醫(yī)囑流程都可參照執(zhí)行,為醫(yī)院的信息系統(tǒng)集成方式提供良好的參考。本示例中,目標(biāo)系統(tǒng)以PACS為例。 另外,在院內(nèi)經(jīng)常出現(xiàn)的是在IHE規(guī)范中描述的:執(zhí)行者醫(yī)囑流程,即由醫(yī)囑執(zhí)行者(PACS系統(tǒng)中,為檢查科室)進(jìn)行醫(yī)囑下達(dá)的過程并執(zhí)行的流程。如下圖所示: 5 數(shù)據(jù)集成 在實際業(yè)務(wù)應(yīng)用中,日常醫(yī)院的HIS庫與ERMS庫之間存在較多需要高頻率、高性能要求的交互,如計價信息與藥品庫存等信息的實時共享等。針對這樣的應(yīng)用場景,我們采用了ETL工具(GoldenGate)在數(shù)據(jù)庫底層進(jìn)行的DB層同步方式。 目前,醫(yī)院已經(jīng)存在比較完整的醫(yī)療信息系統(tǒng),這些醫(yī)療信息是以
14、JW1H系統(tǒng)為基礎(chǔ),增加醫(yī)院自己的需求發(fā)展而來。ERMS電子病歷系統(tǒng)是一個完整的獨立產(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)很難共用一個數(shù)據(jù)庫??闪硗庖环矫?,EMRS電子病歷系統(tǒng)和醫(yī)院現(xiàn)有醫(yī)療信息系統(tǒng)都是醫(yī)院系統(tǒng)不可分割的一部分,他們即有自己工作的重點,又有相互聯(lián)系和配合,只有相互無間的結(jié)合,才能快速、高效和正確地完成日常工作。應(yīng)用EMRS電子病歷系統(tǒng)之后,醫(yī)院現(xiàn)有醫(yī)療信息系統(tǒng)的主要工作就會變成傳統(tǒng)意義上的HIS業(yè)務(wù)工作,如經(jīng)濟管理、人員管理和物資管理等,而E
15、MRS電子病歷系統(tǒng)主要完成以患者為中心的診療行為業(yè)務(wù)工作。 兩者之間存在著千絲萬縷的關(guān)系,以醫(yī)囑業(yè)務(wù)舉例,如EMRS電子病歷系統(tǒng)下達(dá)、轉(zhuǎn)抄和校對醫(yī)囑之后,醫(yī)院現(xiàn)有醫(yī)療信息系統(tǒng)需要完成對應(yīng)的業(yè)務(wù)操作,如醫(yī)囑擺藥和醫(yī)囑收費操作等,這就需要在這兩個系統(tǒng)之間同步數(shù)據(jù)信息,而涉及到同步的醫(yī)療業(yè)務(wù)往往涉及的醫(yī)療各個環(huán)節(jié),如診療、藥房、收費、人員管理等,因此需要信息同步的數(shù)據(jù)量會比較大,而同時為了不造成醫(yī)療業(yè)務(wù)的延遲和脫節(jié),也需要很高的實時性。 在這種應(yīng)用場景下已不適宜采用基于集成平臺的,通過消息交互的應(yīng)用集成方式。消息集成方式,往往需要一個發(fā)起方和接受方,而發(fā)起方和接受方往往需要一些額外的支持,如發(fā)起
16、方需要調(diào)用接受方提供的接口等,期間可能還涉及到一些負(fù)責(zé)的來回交互,最主要的是,消息集成在數(shù)據(jù)量很大的情況下,處理速度不是很快,因此,我們將通過數(shù)據(jù)集成的方式來實現(xiàn)數(shù)據(jù)同步,數(shù)據(jù)庫集成工具采用Oracle GoldenGate。 醫(yī)院涉及到需要數(shù)據(jù)同步的包括兩個部分:HIS數(shù)據(jù)庫和EMRS數(shù)據(jù)庫。我們將采用GoldenGate實現(xiàn)HIS數(shù)據(jù)庫數(shù)據(jù)和EMRS數(shù)據(jù)庫之間的數(shù)據(jù)雙向同步。其基本結(jié)構(gòu)圖如下圖所示: 從上圖我們可以看到發(fā)生在HIS數(shù)據(jù)庫上的相關(guān)數(shù)據(jù)變化通過GoldenGate實時同步到EMRS數(shù)據(jù)庫,而發(fā)生在EMRS數(shù)據(jù)庫上的相關(guān)數(shù)據(jù)變化通過GoldenGate也會實時同步到EMRS
17、數(shù)據(jù)庫。其中具體的實現(xiàn)過程如下圖所示: 從上圖我們可以看到數(shù)據(jù)同步的核心是GoldenGate,在HIS數(shù)據(jù)庫和EMRS數(shù)據(jù)庫上變化數(shù)據(jù)的捕獲、傳遞和復(fù)制都是通過他來完成的。當(dāng)EMRS數(shù)據(jù)庫發(fā)生數(shù)據(jù)變化的時候,如EMRS下達(dá)、校對醫(yī)囑之后,此時運行在EMRS數(shù)據(jù)庫服務(wù)器上的GoldenGate將捕獲該功能業(yè)務(wù)對應(yīng)的變化數(shù)據(jù),并通過網(wǎng)絡(luò)傳遞到HIS數(shù)據(jù)庫,HIS數(shù)據(jù)庫接收到這些變化數(shù)據(jù)之后,運行在HIS數(shù)據(jù)庫服務(wù)器上的GoldenGate解析這些變化數(shù)據(jù)并應(yīng)用到HIS數(shù)據(jù)庫,此時如擺藥程序就能看到相應(yīng)的醫(yī)囑記錄并進(jìn)行擺藥。反之HIS數(shù)據(jù)庫上的變化數(shù)據(jù)也是經(jīng)過上述過程應(yīng)用到EMRS數(shù)據(jù)庫。
18、 通過GoldenGate我們可以很好地實現(xiàn)了HIS數(shù)據(jù)庫和EMRS數(shù)據(jù)庫的之間的獨立和聯(lián)系,使他們各盡其職,分工明確,一起很好地共同支撐整個醫(yī)院的正常運營。 5.1 GoldenGate概述 Oracle GoldenGate軟件是一種基于日志的結(jié)構(gòu)化數(shù)據(jù)復(fù)制軟件,它議決剖析源數(shù)據(jù)庫在線日志或歸檔日志取得數(shù)據(jù)的增量改變,再將這些改變運用到目標(biāo)數(shù)據(jù)庫,從而完成源數(shù)據(jù)庫與目標(biāo)數(shù)據(jù)庫同步。GoldenGate 能夠在異構(gòu)的IT基本結(jié)構(gòu)(包括幾乎一切常用操作系統(tǒng)平臺和數(shù)據(jù)庫平臺)之間完成大量數(shù)據(jù)亞秒一級的及時復(fù)制,從而在能夠在應(yīng)急系統(tǒng)、在線報表、及時數(shù)據(jù)倉庫供應(yīng)、買賣跟蹤、數(shù)據(jù)同步、集中/分發(fā)、
19、容災(zāi)等多個場景下運用,而我們采用的場景是數(shù)據(jù)雙向復(fù)制,GoldenGate雙向復(fù)制的工作原理如下圖所示: 如上所示,GoldenGate在實現(xiàn)數(shù)據(jù)同步的時候,主要涉及到三個重要進(jìn)程:抽取進(jìn)程、投遞進(jìn)程和應(yīng)用進(jìn)程。 1. 抽取進(jìn)程:就是上圖Capture進(jìn)程,該進(jìn)程主要負(fù)責(zé)讀取數(shù)據(jù)庫對應(yīng)的日志文件,將數(shù)據(jù)變化保存到隊列文件中; 2. 投遞進(jìn)程:也叫傳輸進(jìn)程,該進(jìn)程主要負(fù)責(zé)將源數(shù)據(jù)庫中產(chǎn)生的變化的隊列文件進(jìn)過壓縮和加密等方式,通過網(wǎng)絡(luò)傳輸?shù)侥康臄?shù)據(jù)庫; 3. 應(yīng)用進(jìn)程:也叫接納進(jìn)程,該進(jìn)程主要負(fù)責(zé)將投遞進(jìn)程傳遞過來的源數(shù)據(jù)庫的數(shù)據(jù)變化隊列文件解析出來,并應(yīng)用到目的數(shù)據(jù)庫中。 上述三
20、個進(jìn)程完成了從源數(shù)據(jù)庫到目的數(shù)據(jù)庫的單項同步,如果再加上從目的數(shù)據(jù)庫到源數(shù)據(jù)庫的相似的三個進(jìn)程,就實現(xiàn)了源數(shù)據(jù)庫和目的數(shù)據(jù)庫之間的雙向同步。 5.2 GoldenGate的特性 1. 基于日志的實時數(shù)據(jù)復(fù)制:相比傳統(tǒng)依賴數(shù)據(jù)庫觸發(fā)器和規(guī)則的方法來捕獲數(shù)據(jù)變化,GoldenGate采用讀取日志方式對源數(shù)據(jù)庫影響小很多,速度也快很多。 如上圖所示,GoldenGate是通過數(shù)據(jù)日志挖掘的方式實現(xiàn)的。 2. 事務(wù)完整性:GoldenGate只復(fù)制成功提交的事務(wù),同時目標(biāo)數(shù)據(jù)庫按照源數(shù)據(jù)庫的操作順序,而且,可以中斷可以自動恢復(fù),這些保證了源和目標(biāo)之間的事務(wù)完整性。 3. 檢查點機制保障數(shù)
21、據(jù)無丟失:GoldenGate的抽取和復(fù)制進(jìn)程使用檢查點機制記錄完成復(fù)制的位置。對于抽取進(jìn)程,其檢查點記錄當(dāng)前已經(jīng)抽取日志的位置和寫隊列文件的位置;對于投遞進(jìn)程,其檢查點記錄當(dāng)前讀取隊列文件的位置。 上圖中,Capture、Pump和Devlivery將傳遞狀態(tài)存儲至checkpoint file確保其恢復(fù)性,檢查點機制可以保證在系統(tǒng)、網(wǎng)絡(luò)或GoldenGate進(jìn)程故障重啟后數(shù)據(jù)無丟失。 可靠的數(shù)據(jù)傳輸機制:GoldenGate用應(yīng)答機制傳輸交易數(shù)據(jù),只有在得到確認(rèn)消息后才認(rèn)為數(shù)據(jù)傳輸完成,否則將自動重新傳輸數(shù)據(jù),從而保證了抽取出的所有數(shù)據(jù)都能發(fā)送到目標(biāo)端。數(shù)據(jù)傳輸過程中支持128位加
22、密和數(shù)據(jù)壓縮功能。 6 界面集成 對于醫(yī)學(xué)影像、心電圖波形數(shù)據(jù),臨床醫(yī)生的需求是,不僅能瀏覽圖像和波形,還須有對其處理的要求,通常對應(yīng)系統(tǒng)供應(yīng)商提供了DICOM影像瀏覽器和心電圖瀏覽器,這些瀏覽器提供相應(yīng)的工具來處理、管理、傳輸和轉(zhuǎn)換圖像和波形。針對這種帶專業(yè)處理功能的人機交互界面的應(yīng)用程序,我們采用界面集成的方式,集成專業(yè)瀏覽器插件或應(yīng)用程序。 針對這種方式的場景,EMRS系統(tǒng)將采用界面集成應(yīng)用的方式集成數(shù)據(jù)綜合瀏覽視圖,在臨床數(shù)據(jù)中心一節(jié)中已提到,該視圖采用組件化方式進(jìn)行開發(fā),實質(zhì)是各類專業(yè)瀏覽插件的容器,支持對各種醫(yī)學(xué)影像(X-Ray、CT、MRI、超聲、胃腸鏡)、心電圖、監(jiān)護數(shù)據(jù)
23、和麻醉監(jiān)護數(shù)據(jù)等在內(nèi)的多種醫(yī)療數(shù)據(jù)的綜合閱覽分析。 至于各專業(yè)瀏覽器插件內(nèi)部的實現(xiàn),可能又會采用應(yīng)用集成的方式,但通常為了提高性能,和多媒體資料庫中心采用直連的方式獲取影像和波形。 以DICOM影像瀏覽器組件為例,其內(nèi)部采用DICOM標(biāo)準(zhǔn)進(jìn)行醫(yī)學(xué)影像格式定義與交互傳輸。該模塊以O(shè)CX控件的方式實現(xiàn),同時提供給集成事務(wù)處理模塊和醫(yī)護工作站使用。EMRS醫(yī)護工作站使用DICOM引擎主要實現(xiàn)從影像中心查詢和獲取影像等功能。 6.1 DICOM影像應(yīng)用流程規(guī)劃 DICOM影像的顯示流程如上圖所示,主要由以下幾步組成: 醫(yī)護工作站通過調(diào)用DICOM引擎,設(shè)置參數(shù)(Study UID或Stu
24、dy Type + Study ID,DICOM Server的IP、Port、AE)*,請求獲取一個檢查的影像; DICOM引擎啟動DICOM Query服務(wù),獲取檢查影像數(shù),事件通知醫(yī)護工作站,醫(yī)護工作站可以根據(jù)返回的影像數(shù)啟動初始化進(jìn)度條; DICOM引擎啟動DICOM Move服務(wù),向影像中心請求影像; 影像中心啟動DICOM Storage服務(wù),向DICOM引擎發(fā)送影像; DICOM引擎每接收到一個新文件,事件通知醫(yī)護工作站,醫(yī)護工作站可以在此事件的處理中打開并顯示此文件,同時改變進(jìn)度條位置; DICOM引擎接收到DICOM Move響應(yīng),表明文件獲取已經(jīng)結(jié)束,事件通知醫(yī)護
25、工作站。 7 核心價值 通過建立集成信息平臺,集成各類應(yīng)用系統(tǒng)以及日常運營的業(yè)務(wù),通過該平臺整合醫(yī)院內(nèi)部業(yè)務(wù)應(yīng)用系統(tǒng),形成一個互聯(lián)互通的醫(yī)院業(yè)務(wù)協(xié)作網(wǎng)絡(luò)。醫(yī)院信息集成平臺可以很好支持不同系統(tǒng)之間的醫(yī)療數(shù)據(jù)整合、業(yè)務(wù)整合與數(shù)據(jù)共享,快速實施應(yīng)用程序節(jié)點部署以及各醫(yī)療子系統(tǒng)之間的協(xié)同通訊。在醫(yī)院信息系統(tǒng)中的各子系統(tǒng)中,比如HIS,LIS,RIS,OA等,傳遞和展現(xiàn)整個醫(yī)療過程中的相關(guān)信息。同時,集成信息平臺為臨床數(shù)據(jù)中心的數(shù)據(jù)來源提供了技術(shù)基礎(chǔ)和保障,通過信息標(biāo)準(zhǔn)、交換原則的制定,對業(yè)務(wù)系統(tǒng)提供標(biāo)準(zhǔn)的信息交換服務(wù),確保數(shù)據(jù)交換過程的安全性、可靠性,實現(xiàn)數(shù)據(jù)在系統(tǒng)平臺范圍內(nèi)自由、可靠、可信的交換。 通過醫(yī)院信息平臺建設(shè),一方面可以規(guī)避“點對點”式的信息共享與交換,并使得醫(yī)院可以基于信息平臺整體上進(jìn)行業(yè)務(wù)流程優(yōu)化與管理,對內(nèi)提高管理水平,對外以統(tǒng)一的方式接入?yún)^(qū)域衛(wèi)生協(xié)同網(wǎng)絡(luò),更好地為人民健康服務(wù)。另一方面利于醫(yī)院信息系統(tǒng)建設(shè)的持續(xù)性發(fā)展,以適應(yīng)未來的需求變化,避免信息化建設(shè)的大范圍的推倒重來;另外,持續(xù)性發(fā)展還必須要有一套合適的實施和服務(wù)模式作支撐。
- 溫馨提示:
1: 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
2: 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
3.本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
5. 裝配圖網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 2023年六年級數(shù)學(xué)下冊6整理和復(fù)習(xí)2圖形與幾何第7課時圖形的位置練習(xí)課件新人教版
- 2023年六年級數(shù)學(xué)下冊6整理和復(fù)習(xí)2圖形與幾何第1課時圖形的認(rèn)識與測量1平面圖形的認(rèn)識練習(xí)課件新人教版
- 2023年六年級數(shù)學(xué)下冊6整理和復(fù)習(xí)1數(shù)與代數(shù)第10課時比和比例2作業(yè)課件新人教版
- 2023年六年級數(shù)學(xué)下冊4比例1比例的意義和基本性質(zhì)第3課時解比例練習(xí)課件新人教版
- 2023年六年級數(shù)學(xué)下冊3圓柱與圓錐1圓柱第7課時圓柱的體積3作業(yè)課件新人教版
- 2023年六年級數(shù)學(xué)下冊3圓柱與圓錐1圓柱第1節(jié)圓柱的認(rèn)識作業(yè)課件新人教版
- 2023年六年級數(shù)學(xué)下冊2百分?jǐn)?shù)(二)第1節(jié)折扣和成數(shù)作業(yè)課件新人教版
- 2023年六年級數(shù)學(xué)下冊1負(fù)數(shù)第1課時負(fù)數(shù)的初步認(rèn)識作業(yè)課件新人教版
- 2023年六年級數(shù)學(xué)上冊期末復(fù)習(xí)考前模擬期末模擬訓(xùn)練二作業(yè)課件蘇教版
- 2023年六年級數(shù)學(xué)上冊期末豐收園作業(yè)課件蘇教版
- 2023年六年級數(shù)學(xué)上冊易錯清單十二課件新人教版
- 標(biāo)準(zhǔn)工時講義
- 2021年一年級語文上冊第六單元知識要點習(xí)題課件新人教版
- 2022春一年級語文下冊課文5識字測評習(xí)題課件新人教版
- 2023年六年級數(shù)學(xué)下冊6整理和復(fù)習(xí)4數(shù)學(xué)思考第1課時數(shù)學(xué)思考1練習(xí)課件新人教版