文/胡紅雨 劉冬
(皖南醫(yī)學(xué)院弋磯山醫(yī)院信息中心 安徽省蕪湖市 241000)
隨著我國衛(wèi)生體制改革的不斷深入,如何在區(qū)域醫(yī)療下完成醫(yī)院信息系統(tǒng)的互聯(lián)互通,實(shí)現(xiàn)醫(yī)療信息資源共享已經(jīng)成為醫(yī)院信息化建設(shè)的重點(diǎn)內(nèi)容。近年來,基于電子病歷共享為核心的信息化建設(shè)與應(yīng)用已逐步深入。北京市的電子病歷共享工程建設(shè)通過搭建市級以電子病歷為核心的衛(wèi)生信息平臺,對醫(yī)療健康數(shù)據(jù)進(jìn)行有效分析處理,為衛(wèi)生行政管理部門、醫(yī)療衛(wèi)生機(jī)構(gòu)、相關(guān)科研機(jī)構(gòu)提供決策分析支持,提升了管理部門的信息監(jiān)管和決策服務(wù)能力。主要方法是在各試點(diǎn)醫(yī)院安裝前置機(jī),根據(jù)電子病歷信息采集的項(xiàng)目定義、分類和接口標(biāo)準(zhǔn)文檔要求,通過建立中間交換表結(jié)構(gòu),將清洗、轉(zhuǎn)換之后的數(shù)據(jù)寫入前置機(jī)接口,定時(shí)、批量上傳至衛(wèi)生平臺。胡正剛等按照醫(yī)院信息互聯(lián)互通標(biāo)準(zhǔn)化成熟度四級測評要求,基于Xpath 讀取路徑方法成功輸出53 本電子病歷共享文檔,主要分電子病歷系統(tǒng)打造、上傳集成平臺、轉(zhuǎn)換成標(biāo)準(zhǔn)共享文檔三個(gè)步驟。楊廠鋒等使用XML 標(biāo)準(zhǔn)轉(zhuǎn)換、Web Services 接口等技術(shù)設(shè)計(jì)了統(tǒng)一標(biāo)準(zhǔn)的云數(shù)據(jù)接口對接各個(gè)醫(yī)療機(jī)構(gòu)數(shù)據(jù)云,進(jìn)行數(shù)據(jù)轉(zhuǎn)換。[1-3]上述三種方法均必須依托完善的醫(yī)療信息平臺,需要對醫(yī)院信息系統(tǒng)進(jìn)行深度改造與聯(lián)合調(diào)試,中間環(huán)節(jié)多,數(shù)據(jù)交互在調(diào)用方法、響應(yīng)時(shí)間等方面存在限制。因此許多研究者開始關(guān)注獨(dú)立的第三方中間件并注重實(shí)時(shí)性的研究。王興強(qiáng)等設(shè)計(jì)了一種電子病歷共享文檔的自動生成方法,實(shí)現(xiàn)了患者在正常的就診過程自動觸發(fā)并生成相應(yīng)的電子病歷共享文檔,包括診療活動、事件、文檔調(diào)閱服務(wù)、數(shù)據(jù)服務(wù)、文檔合成服務(wù)、共享文檔數(shù)據(jù)庫6 個(gè)步驟。[4]
本文從上述實(shí)際情況處理,結(jié)合醫(yī)院信息化建設(shè)經(jīng)驗(yàn),設(shè)計(jì)了在區(qū)域醫(yī)療下電子病歷共享文檔中間件EMRSMW。通過獨(dú)立API 接口向現(xiàn)有醫(yī)院信息系統(tǒng)如HIS、EMR、PACS、LIS 等提供對接,提高了系統(tǒng)的獨(dú)立性、可擴(kuò)展性與互操作性。此外通過引入NoSQL 集群存儲機(jī)制,提升了系統(tǒng)的可靠性與性能。下面將首先介紹中間件的架構(gòu)設(shè)計(jì)及各組件的功能,然后對關(guān)鍵部分的技術(shù)實(shí)現(xiàn)做詳細(xì)闡述,再以真實(shí)的病歷概要數(shù)據(jù)進(jìn)行實(shí)例驗(yàn)證測試,最后總結(jié)優(yōu)缺點(diǎn)并展望下一步工作方向。
中間件應(yīng)當(dāng)具備很強(qiáng)的適應(yīng)性與可擴(kuò)展性。醫(yī)院信息系統(tǒng)具有多源異構(gòu)、數(shù)據(jù)格式、大小不同等特點(diǎn),使用統(tǒng)一框架或協(xié)議對接現(xiàn)有信息源難以實(shí)現(xiàn)。中間件應(yīng)具備適應(yīng)不同類型信息源的特點(diǎn),對各不同類型的信息系統(tǒng)提供對應(yīng)的接口類型和數(shù)據(jù)處理方式。且各系統(tǒng)會隨著醫(yī)院信息化進(jìn)程的推進(jìn),醫(yī)院信息系統(tǒng)的業(yè)務(wù)類型、功能、性能等均會發(fā)生變化,中間件應(yīng)當(dāng)保持靈活的擴(kuò)展性。
中間件應(yīng)當(dāng)具備高可靠性與高性能。中間件作為一項(xiàng)獨(dú)立于現(xiàn)有醫(yī)院信息系統(tǒng)的基礎(chǔ)服務(wù)存在,必須具備高可靠性。同時(shí)需要與醫(yī)院內(nèi)部信息系統(tǒng)甚至在區(qū)域內(nèi)醫(yī)療機(jī)構(gòu)之間的信息系統(tǒng)保持互操作能力,在網(wǎng)絡(luò)帶寬保證的前提下,盡可能降低服務(wù)響應(yīng)延時(shí),提升性能。
圖1:中間件架構(gòu)圖
圖2:正向傳輸?shù)墓ぷ鬟^程
本文設(shè)計(jì)的中間件總體架構(gòu)如圖1 所示。
中間件主要由存儲服務(wù)、事件驅(qū)動服務(wù)、數(shù)據(jù)服務(wù)、文檔服務(wù)、接口服務(wù)組成。
1.2.1 接口服務(wù)
接口服務(wù)提供事件監(jiān)測、數(shù)據(jù)采集、文檔調(diào)閱等功能接口。事件監(jiān)測用于接收在醫(yī)院信息系統(tǒng)中的患者掛號、檢查、檢驗(yàn)、用藥、出入庫等以及醫(yī)護(hù)人員處方、醫(yī)囑、手術(shù)、麻醉、護(hù)理等診療過程中的行為事件。將事件與數(shù)據(jù)分別發(fā)送給事件驅(qū)動服務(wù)與數(shù)據(jù)服務(wù)。數(shù)據(jù)采集接口用于接收電子病歷共享文檔規(guī)范所要求的數(shù)據(jù)。文檔調(diào)閱接口用于電子病歷共享文檔的調(diào)閱申請、審核與返回文檔結(jié)果。
表1:中間件性能測試數(shù)據(jù)
圖3:反向查詢的工作過程
圖4:數(shù)據(jù)轉(zhuǎn)換流程
1.2.2 事件驅(qū)動服務(wù)
完成事件消息的接收轉(zhuǎn)發(fā)。接收不同類型事件請求,存入事件隊(duì)列,根據(jù)事件處理配置轉(zhuǎn)發(fā)事件給數(shù)據(jù)服務(wù),將事件日志記錄轉(zhuǎn)發(fā)存儲服務(wù)作持久化存儲。
1.2.3 數(shù)據(jù)服務(wù)
圖5:數(shù)據(jù)轉(zhuǎn)換流程
完成事件消息處理與數(shù)據(jù)處理過程。接收事件驅(qū)動服務(wù)提供具體的事件處理過程,接收伴隨事件產(chǎn)生的相關(guān)數(shù)據(jù)傳入操作,或主動檢測和自動連接目標(biāo)數(shù)據(jù)庫獲取所需數(shù)據(jù),完成數(shù)據(jù)格式轉(zhuǎn)換。將提取到的數(shù)據(jù)發(fā)送到存儲服務(wù)完成持久存儲。
1.2.4 文檔服務(wù)
電子病歷共享文檔的調(diào)閱申請服務(wù)與合成轉(zhuǎn)換。調(diào)閱申請是指通過特定的查詢字段發(fā)起對電子病歷共享文檔的調(diào)閱申請,通過安全認(rèn)證后返回相應(yīng)的文檔內(nèi)容。合成轉(zhuǎn)換是從根據(jù)數(shù)據(jù)服務(wù)采集到的數(shù)據(jù),按照電子病歷共享文檔規(guī)范進(jìn)行合并與轉(zhuǎn)換。
1.2.5 存儲服務(wù)
事件監(jiān)測日志、從醫(yī)院信息系統(tǒng)中采集的數(shù)據(jù)與轉(zhuǎn)換生成的電子病歷共享文檔均通過存儲服務(wù)完成讀寫訪問操作。需要完成融合多源異構(gòu)數(shù)據(jù)的融合存儲,實(shí)現(xiàn)數(shù)據(jù)庫的控制、數(shù)據(jù)搜索查詢。
為屏蔽數(shù)據(jù)庫類型與數(shù)據(jù)格式差異,提供良好的兼容性,為更好的適應(yīng)現(xiàn)有醫(yī)院信息系統(tǒng),將數(shù)據(jù)采集方式設(shè)計(jì)為正向傳輸與反向查詢兩種方式。
正向傳輸是由醫(yī)院信息系統(tǒng)自主發(fā)起數(shù)據(jù)上傳,可結(jié)合各信息系統(tǒng)廠商標(biāo)準(zhǔn)與規(guī)范的實(shí)現(xiàn)程度、數(shù)據(jù)結(jié)構(gòu)特點(diǎn),部署獨(dú)立的程序來完成上傳功能,不需要對信息系統(tǒng)進(jìn)行深度改造。正向傳輸?shù)臄?shù)據(jù)采集設(shè)計(jì)提供批量處理接口、事件驅(qū)動采集、直接上傳接口3 種類型接口批量處理接口用于對醫(yī)院信息系統(tǒng)的歷史電子病歷數(shù)據(jù)進(jìn)行批量采集處理。事件驅(qū)動采集是針對監(jiān)測到事件進(jìn)行實(shí)時(shí)數(shù)據(jù)采集。直接上傳是按電子病歷共享文檔規(guī)范制定接口標(biāo)準(zhǔn),根據(jù)接口標(biāo)準(zhǔn)直接上傳所需數(shù)據(jù)。正向傳輸?shù)墓ぷ鬟^程如圖2 所示。
反向查詢是通過預(yù)先設(shè)定的數(shù)據(jù)庫連接參數(shù)、數(shù)據(jù)庫用戶信息、數(shù)據(jù)庫地址等數(shù)據(jù)訪問配置信息,從指定的數(shù)據(jù)庫中查詢所需要的數(shù)據(jù)。反向查詢的工作過程如圖3 所示。
數(shù)據(jù)轉(zhuǎn)換是根據(jù)電子病歷共享文檔規(guī)范要求,對采集的數(shù)據(jù)進(jìn)行格式轉(zhuǎn)換。電子病歷共享文檔采用可擴(kuò)展標(biāo)記語言XML 來實(shí)現(xiàn)文檔的描述、存儲與傳輸,借鑒ISO/HL7 CDA R2 文檔架構(gòu)標(biāo)準(zhǔn)作為基礎(chǔ)。雖然XML 與HL7 都是國際標(biāo)準(zhǔn),在不同的軟件廠商中具有廣泛的應(yīng)用與良好的兼容性,但是在技術(shù)實(shí)現(xiàn)方式與標(biāo)準(zhǔn)實(shí)現(xiàn)程度上卻存在巨大差異,為數(shù)據(jù)存儲與查詢調(diào)閱帶來了難度。為了實(shí)現(xiàn)一體化存儲服務(wù)與統(tǒng)一文檔生成服務(wù),需要對采集到的數(shù)據(jù)進(jìn)行轉(zhuǎn)換。數(shù)據(jù)轉(zhuǎn)換流程圖4 所示。
數(shù)據(jù)格式轉(zhuǎn)換完成XML 格式的電子病歷原始數(shù)據(jù)轉(zhuǎn)換成更輕量級的JSON 格式和對數(shù)據(jù)類型的支持更豐富的BSON 格式。BSON 格式是MongoDB 數(shù)據(jù)庫的文檔存儲格式。
電子病歷數(shù)據(jù)具有多源異構(gòu)、數(shù)據(jù)格式多樣化、結(jié)構(gòu)化數(shù)據(jù)比例較低、半結(jié)構(gòu)化數(shù)據(jù)多、數(shù)據(jù)大小相差懸殊、數(shù)據(jù)總量大等特點(diǎn)。解決多源異構(gòu)數(shù)據(jù)融合必須形成一體化存儲。MongoDB 是一種NoSQL 文檔型數(shù)據(jù)庫,非常適合于電子病歷、檢驗(yàn)檢查報(bào)告等具有固定格式的臨床數(shù)據(jù)存儲,同時(shí)通過存儲設(shè)計(jì),能夠?qū)崿F(xiàn)對圖片、聲音、影像等二進(jìn)制文件的高效存儲[6]。本文通過使用MongoDB的Shard 與Replset 機(jī)制,建立高可用的數(shù)據(jù)存儲集群設(shè)計(jì),實(shí)現(xiàn)讀寫分離,在提供高性能的同時(shí),具有良好的可擴(kuò)展性,可以應(yīng)對數(shù)據(jù)規(guī)模的快速增長。
數(shù)據(jù)存儲架構(gòu)如圖5 所示。
通過獨(dú)立程序?qū)υ簝?nèi)80 萬份半結(jié)構(gòu)化的電子病歷數(shù)據(jù)中的病歷概要部分進(jìn)行分析處理,經(jīng)批量上傳接口上傳到中間件平臺,經(jīng)格式化轉(zhuǎn)換后持久保存到數(shù)據(jù)存儲,再通過接口完成調(diào)閱申請,返回標(biāo)準(zhǔn)格式的電子病歷共享文檔。中間件在數(shù)據(jù)批量上傳、數(shù)據(jù)轉(zhuǎn)換服務(wù)和文檔查詢調(diào)閱等過程中均表現(xiàn)出較好的性能。各項(xiàng)測試數(shù)據(jù)如表1 所示。
本文設(shè)計(jì)的在區(qū)域醫(yī)療下電子病歷共享文檔中間件設(shè)計(jì),在數(shù)據(jù)采集、數(shù)據(jù)轉(zhuǎn)換和文檔查詢過程具有很高的性能。在實(shí)踐過程中,具有部署方便、可擴(kuò)展性好、穩(wěn)定性高的等特點(diǎn)。但是電子病歷中包含大量患者隱私信息,在下一步的工作中將在安全認(rèn)證與隱私保護(hù)方面進(jìn)行改進(jìn)。