云計(jì)算技術(shù)在海量電子病歷數(shù)據(jù)分析中的應(yīng)用研究

張東林

(山西中醫(yī)學(xué)院附屬醫(yī)院,山西 太原 030024)

引言

信息化的電子病歷與傳統(tǒng)手抄病歷相比,所包含的信息內(nèi)容更加廣泛,除記錄病狀、檢驗(yàn)結(jié)果和診療記錄等靜態(tài)信息外,還記錄了各類與診療相關(guān)的動(dòng)態(tài)服務(wù)信息。例如病人的歷年健康體檢記錄、轉(zhuǎn)院記錄、具有法律效力的醫(yī)學(xué)證明等。此外,電子病歷的作用也不僅被用于輔助醫(yī)生診療,還可以用于病歷信息的快速共享和數(shù)據(jù)挖掘應(yīng)用。但是現(xiàn)有的電子病歷管理系統(tǒng)大部分只能對(duì)規(guī)范化的文本信息進(jìn)行有效的分析與處理,而對(duì)于一些不能明確顯示其含義的非結(jié)構(gòu)化文本信息,例如醫(yī)生用自然語言表達(dá)和記錄下來的醫(yī)囑、病人的臨床癥狀等,還無法進(jìn)行準(zhǔn)確的識(shí)別與檢索[1]。隨著醫(yī)療信息化技術(shù)的不斷發(fā)展,電子病歷的數(shù)據(jù)規(guī)模也呈現(xiàn)出高速增長(zhǎng)態(tài)勢(shì),實(shí)現(xiàn)對(duì)海量電子病歷數(shù)據(jù)的高效檢索與分析,是未來醫(yī)療信息化發(fā)展中面臨的重要問題。而實(shí)現(xiàn)海量數(shù)據(jù)檢索的關(guān)鍵在于對(duì)信息內(nèi)容進(jìn)行準(zhǔn)確的識(shí)別,并在此基礎(chǔ)上建立相應(yīng)的關(guān)鍵詞標(biāo)注與檢索機(jī)制,本文基于云計(jì)算技術(shù)與UIMA框架構(gòu)建了一種電子病例文本數(shù)據(jù)管理與分析模型,為有效提升電子病歷數(shù)據(jù)的檢索與處理效率提供了新的解決方案。

1 云計(jì)算技術(shù)與UIMA框架

云計(jì)算技術(shù)是一項(xiàng)新興的、共享式的信息化數(shù)據(jù)處理技術(shù)。它集合了計(jì)算機(jī)網(wǎng)絡(luò)分布技術(shù)、服務(wù)器集群技術(shù)、信息通信、網(wǎng)格計(jì)算、虛擬化存儲(chǔ)等一系列技術(shù),其核心思路就是通過計(jì)算機(jī)網(wǎng)絡(luò)將各類不同配置的數(shù)據(jù)處理設(shè)備高效整合后通過統(tǒng)一的接口為網(wǎng)絡(luò)用戶提供共享式的數(shù)據(jù)處理服務(wù)[2]。本文中所選用的Hadoop是一款開源的云服務(wù)平臺(tái),為基于云服務(wù)的第三方應(yīng)用服務(wù)開發(fā)人員提供了性能優(yōu)異的研究和實(shí)驗(yàn)環(huán)境。Hadoop平臺(tái)主要包含兩大核心模塊:Map/Reduce并行處理模塊,用于實(shí)現(xiàn)對(duì)復(fù)雜任務(wù)的分布式控制。HDFS分布式文件管理模塊,實(shí)現(xiàn)數(shù)據(jù)的分布式存儲(chǔ)與統(tǒng)一管理。HDFS能夠有效屏蔽底層硬件的特性差異,可部署在廉價(jià)硬件設(shè)備集群之上,大幅度降低了資金成本的投入。

UIMA是由IBM研發(fā),后又移交至Apache維護(hù)的一個(gè)開源結(jié)構(gòu)框架。UIMA的主要作用就是將各類非結(jié)構(gòu)化的數(shù)據(jù)中的有效信息分析與提煉出來,并按照用戶的需求將分析結(jié)果呈現(xiàn)給用戶。UIMA包含有三個(gè)核心業(yè)務(wù)模塊,分別為控制讀取(CR)、分析引擎(AE)、結(jié)果提交(CAS)。UIMA為這些底層組件的部署都提供有統(tǒng)一的API接口,支持開發(fā)者在其框架上擴(kuò)展、部署和應(yīng)用,為非結(jié)構(gòu)化數(shù)據(jù)處理提供了非常有效的解決方案。

2 電子病歷的非結(jié)構(gòu)化數(shù)據(jù)處理需求

電子病歷中的非結(jié)構(gòu)化數(shù)據(jù)主要指的是無法通過固定格式對(duì)其內(nèi)容進(jìn)行表述和顯示的數(shù)據(jù)信息,比如用自然語言表述的臨床診斷記錄,計(jì)算機(jī)是無法通過直接的檢索操作獲取到其中的各項(xiàng)關(guān)鍵信息的,若要求采用固定格式完成診斷記錄的錄入,就需要改變醫(yī)生們長(zhǎng)期形成的表述習(xí)慣,會(huì)嚴(yán)重影響到醫(yī)生的工作效率,因此在短期內(nèi)無法實(shí)現(xiàn)。同時(shí),在涵蓋了多所醫(yī)院的區(qū)域級(jí)電子病歷共享數(shù)據(jù)中心里,歷年來積累的電子病歷數(shù)據(jù)的存儲(chǔ)量也極其龐大,醫(yī)生如果想在海量的完全非結(jié)構(gòu)化的電子病例數(shù)據(jù)資源中檢索出所需的信息,以作為臨床診療與學(xué)術(shù)研究的參考依據(jù),也需要計(jì)算機(jī)提前對(duì)這些信息進(jìn)行分析與預(yù)處理[3]。因此,該問題解決需要從技術(shù)層面來完成,即對(duì)非結(jié)構(gòu)化的數(shù)據(jù)進(jìn)行分析和處理,通過相應(yīng)的計(jì)算機(jī)技術(shù)將非結(jié)構(gòu)化的數(shù)據(jù)轉(zhuǎn)換為結(jié)構(gòu)化數(shù)據(jù),而成功轉(zhuǎn)化的關(guān)鍵在于對(duì)數(shù)據(jù)文件的整合以及對(duì)數(shù)據(jù)內(nèi)容的分析并最終建立能夠高效運(yùn)行的索引庫(kù)的過程。

3 云計(jì)算技術(shù)在海量電子病歷數(shù)據(jù)分析中的應(yīng)用

3.1 設(shè)計(jì)思路

系統(tǒng)通過在Hadoop平臺(tái)中部署基于UIMA框架設(shè)計(jì)的數(shù)據(jù)分析引擎來實(shí)現(xiàn)電子病歷中非結(jié)構(gòu)化數(shù)據(jù)的分析處理,系統(tǒng)的數(shù)據(jù)分析處理流程如圖1所示。

圖1 數(shù)據(jù)分析處理流程

Hadoop與UIMA的整合首先需要進(jìn)行小文件的預(yù)處理,由于電子病歷中存在很多K級(jí)的小文件,存儲(chǔ)時(shí)如不能進(jìn)行有效的整合,將浪費(fèi)大量的存儲(chǔ)空間并嚴(yán)重降低數(shù)據(jù)檢索速度。因此,電子病歷的數(shù)據(jù)信息在導(dǎo)入到Hadoop之前,先要采用整合類優(yōu)化算法對(duì)小文件進(jìn)行排序組合。

在預(yù)處理完成后即將數(shù)據(jù)提交至Hadoop平臺(tái),Hadoop接收到待處理的數(shù)據(jù)時(shí),會(huì)將數(shù)據(jù)同時(shí)交由主服務(wù)器和HDFS進(jìn)行分布式存儲(chǔ)與管理,Hadoop是典型的主從式服務(wù)架構(gòu),主服務(wù)器主要負(fù)責(zé)任務(wù)的分派與調(diào)度,主服務(wù)器主要實(shí)現(xiàn)與Map/Reduce的交互,創(chuàng)建Map任務(wù)列表,并將其按照先到先出的排列順序分配到若干從服務(wù)器上執(zhí)行[4]。UIMA的核心業(yè)務(wù)模塊CR、AE將部署在所有的從服務(wù)器上,專門用于實(shí)現(xiàn)Map任務(wù)中非結(jié)構(gòu)數(shù)據(jù)轉(zhuǎn)換分析;HDFS則負(fù)責(zé)對(duì)輸入的源數(shù)據(jù)進(jìn)行存儲(chǔ)。數(shù)據(jù)處理完成后的最終結(jié)果由UIMA的CAS模塊提交至用戶響應(yīng)服務(wù)模塊。

系統(tǒng)主要采用了分層的架構(gòu)模型設(shè)計(jì),主要包括數(shù)據(jù)維護(hù)、核心技術(shù)、業(yè)務(wù)邏輯三個(gè)層級(jí)如圖2所示。

圖2 系統(tǒng)分層架構(gòu)圖

其中數(shù)據(jù)維護(hù)層主要用于實(shí)現(xiàn)源數(shù)據(jù)、索引結(jié)果的存儲(chǔ)與維護(hù),主要包括HDFS、索引數(shù)據(jù)庫(kù)兩個(gè)功能模塊;核心技術(shù)層則集合了UIMA的所有功能模塊以及Hadoop的并行任務(wù)執(zhí)行模塊Map/Reduce,用于并行完成非結(jié)構(gòu)化數(shù)據(jù)的初始化、關(guān)鍵語義分析、創(chuàng)建標(biāo)注的核心業(yè)務(wù)處理;業(yè)務(wù)邏輯層主要包括服務(wù)類型分析、檢索服務(wù)響應(yīng)、索引創(chuàng)建三個(gè)模塊,面向核心技術(shù)層提供快速的業(yè)務(wù)類型預(yù)處理操作,面向用戶提供響應(yīng)結(jié)果的索引創(chuàng)建和檢索服務(wù)響應(yīng)功能。

系統(tǒng)的用戶訪問功能實(shí)現(xiàn)并不局限于特定的程序開發(fā)語言與框架,用戶可以通過WEB頁(yè)面、APP應(yīng)用等方式與系統(tǒng)進(jìn)行交互,并可以基于第三方數(shù)據(jù)庫(kù)創(chuàng)建用戶訪問權(quán)限驗(yàn)證機(jī)制,為系統(tǒng)的安全訪問提供保障,系統(tǒng)在為用戶提供快速檢索服務(wù)的流程如圖3所示。

圖3 系統(tǒng)快速檢索服務(wù)流程圖

3.2 關(guān)鍵技術(shù)的應(yīng)用分析

3.2.1小文件的預(yù)處理

在云存儲(chǔ)模型中,小文件是指體積在20M以下的文件,由于Hadoop的HDFS文件系統(tǒng)的存儲(chǔ)單位是64M,小文件長(zhǎng)度即使不足64M,也會(huì)占用一個(gè)64M的存儲(chǔ)單元,因此過多的小文件會(huì)增加系統(tǒng)的存儲(chǔ)開銷,降低存儲(chǔ)空間的有效利用率[5]。小文件的預(yù)處理實(shí)際上就是在將文件提交至HDFS子系統(tǒng)進(jìn)行存儲(chǔ)之前就利用二維裝箱算法對(duì)小文件進(jìn)行排序、整合優(yōu)化處理,以彌補(bǔ)HDFS文件系統(tǒng)在小文件存儲(chǔ)管理上的不足。

對(duì)于病歷數(shù)據(jù)中所包含的大量k級(jí)小文件,系統(tǒng)采用Hadoop API提供的SequenceFile機(jī)制,將多個(gè)小文件中包含數(shù)據(jù)記錄都以的格式進(jìn)行序列化并寫入到同一個(gè)SequenceFile文件中進(jìn)行存儲(chǔ),即將大量的小文件歸并為一個(gè)大文件。SequenceFile的文件結(jié)構(gòu)如圖4所示。

圖4 SequenceFile文件結(jié)構(gòu)

SequenceFile的結(jié)構(gòu)特征非常適用于海量電子病歷數(shù)據(jù)的優(yōu)化存儲(chǔ),在對(duì)病例文件進(jìn)行處理的過程中可以將每一條病例數(shù)據(jù)的唯一識(shí)別碼作為Key,文本內(nèi)容作為Value連續(xù)存儲(chǔ)至SequenceFile文件中,并通過Hadoop專為SequenceFile提供塊壓縮功能對(duì)記錄進(jìn)行批量壓縮,在有效整合大量小文件的同時(shí),獲得更高的存儲(chǔ)效率。

3.2.2數(shù)據(jù)的分布式存儲(chǔ)與管理

數(shù)據(jù)文件的存儲(chǔ)主要基于HDFS分布式文件管理模塊來完成,HDFS屬于M/S(主從模式)體系架構(gòu),HDFS 集群由1個(gè)(且每集群中僅1個(gè))NameNode節(jié)點(diǎn)與多個(gè)(集群中數(shù)量大于等于1)DataNode節(jié)點(diǎn)組成,各節(jié)點(diǎn)均由服務(wù)器構(gòu)成。其結(jié)構(gòu)如圖5所示。

圖5 HDFS體系架構(gòu)

在HDFS的數(shù)據(jù)架構(gòu)中,擴(kuò)展索引作為一個(gè)重要的組成部分對(duì)數(shù)據(jù)檢索的響應(yīng)速度起到了決定性的影響。擴(kuò)展索引由NataNode負(fù)責(zé)創(chuàng)建,在HDFS系統(tǒng)初始化的時(shí)候上傳至NameNode節(jié)點(diǎn)并加載至內(nèi)存中。在數(shù)據(jù)檢索時(shí),用戶的每一次檢索操作都會(huì)對(duì)該索引的內(nèi)容進(jìn)行擴(kuò)展，以便再進(jìn)行相同的檢索時(shí)能夠快速獲取到結(jié)果,該機(jī)制可以有效地降低節(jié)點(diǎn)之間的網(wǎng)絡(luò)通信頻率,大量節(jié)省系統(tǒng)資源、提高運(yùn)行效率。

在不同的應(yīng)用環(huán)境中,有針對(duì)性的設(shè)計(jì)合理高效的擴(kuò)展索引結(jié)構(gòu),不僅能夠優(yōu)惠數(shù)據(jù)檢索的速度,也能夠提升HDFS的文件存儲(chǔ)數(shù)量。因此,本文針對(duì)電子病歷的數(shù)據(jù)結(jié)構(gòu)特征設(shè)計(jì)了相應(yīng)的擴(kuò)展索引結(jié)構(gòu),如圖6所示。

RecodIDDataSourceFileTypeStoragePathStartPosition 記錄標(biāo)識(shí)數(shù)據(jù)來源文件類型存儲(chǔ)路徑起始位置

圖6擴(kuò)展索引結(jié)構(gòu)

RecodID為電子病例數(shù)據(jù)庫(kù)中記錄的唯一編碼,以bigint類型存儲(chǔ),長(zhǎng)度為8字節(jié);DataSource為創(chuàng)建該數(shù)據(jù)的醫(yī)療機(jī)構(gòu)編碼以Int類型存儲(chǔ),長(zhǎng)度為4字節(jié);FileType則用于標(biāo)識(shí)文本、圖片、影像等有限的類型信息,長(zhǎng)度僅2個(gè)字節(jié)標(biāo)識(shí);StoragePath是在完成小文件合并與記錄批量壓縮操作之后生成的SequenceFile 文件在HDFS系統(tǒng)中的存儲(chǔ)位置,由8個(gè)字符進(jìn)行表示。StartPosition用于標(biāo)識(shí)小文件在合并后的SequenceFile起始位置,長(zhǎng)度為6字節(jié)。將以上數(shù)據(jù)匯總后可知,每個(gè)電子病歷文件在HDFS系統(tǒng)中的擴(kuò)展索引的大小為8+4+2+8+6=28字節(jié)。從理論上來說，NameNode節(jié)點(diǎn)服務(wù)器上僅1GB的內(nèi)存空間中就可以緩存3234萬條文件索引數(shù)據(jù),可以為文件檢索操作提供良好的響應(yīng)速度。

文件在經(jīng)過預(yù)處理和擴(kuò)展索引之后,HDFS系統(tǒng)對(duì)文件讀寫的管理可簡(jiǎn)單概括為以下兩個(gè)方面:

文件的寫入。將預(yù)處理后的醫(yī)療文件序列信息添加至HDFS的命名空間,將整合后的數(shù)據(jù)塊信息寫入到數(shù)據(jù)節(jié)點(diǎn),同時(shí)將數(shù)據(jù)塊中整合的小文件與對(duì)應(yīng)序列文件生成索引記錄。

文件的讀取。讀取醫(yī)療小文件時(shí),首先由HDFS的命名空間檢索到文件所屬數(shù)據(jù)塊的存儲(chǔ)位置信息,然后通過擴(kuò)展索引列表獲取文件在整合數(shù)據(jù)塊中的序列信息,以鎖定最終的文件位置信息。

3.2.3非結(jié)構(gòu)化數(shù)據(jù)的分析

為用戶提供快速高效的數(shù)據(jù)檢索服務(wù)的基礎(chǔ)是構(gòu)造合理的索引數(shù)據(jù)庫(kù)結(jié)構(gòu),而索引數(shù)據(jù)庫(kù)是基于對(duì)病例中的非結(jié)構(gòu)化文本數(shù)據(jù)進(jìn)行合理的分詞處理之后來完成構(gòu)建的。在本文所設(shè)計(jì)的系統(tǒng)模型中,經(jīng)過預(yù)處理的待轉(zhuǎn)換數(shù)據(jù)在寫入到Hadoop的分布式文件系統(tǒng)當(dāng)中后,由核心技術(shù)層中的UIMA與Hadoop模塊合作完成數(shù)據(jù)的分析轉(zhuǎn)換,其處理流程主要包括以下三個(gè)步驟:

1)通過Hadoop的Map/Reduce模型為待處理數(shù)據(jù)創(chuàng)建Map任務(wù),Map任務(wù)創(chuàng)建同時(shí)也會(huì)對(duì)待處理數(shù)據(jù)進(jìn)行數(shù)據(jù)片段的分割,主要是依據(jù)預(yù)處理數(shù)據(jù)格式索引列表中的類型值進(jìn)行分割。

2)通過創(chuàng)建好的Map任務(wù)獲取到數(shù)據(jù)格式索引列表中的一組Key、Value值,依據(jù)Value值明確數(shù)據(jù)分析所要獲取的中間結(jié)果類型,然后調(diào)用相應(yīng)的UIMA組件進(jìn)行處理,最后將獲取到的制定類型的中間結(jié)果存儲(chǔ)至HDFS,同時(shí)對(duì)Value值完成標(biāo)注。

3)HDFS當(dāng)中的Reduce任務(wù)將獲取到的中間結(jié)果再依據(jù)Key值進(jìn)行合并簡(jiǎn)化,也就是將具有相同輸入路徑的數(shù)據(jù)結(jié)果進(jìn)行排序、整合、去重、過濾等一系列操作,并將最終結(jié)果存儲(chǔ)至索引數(shù)據(jù)庫(kù)當(dāng)中。

在具體實(shí)現(xiàn)過程中,用于對(duì)文本進(jìn)行分詞的分析引擎由AE模塊結(jié)合開源漢語分詞工具Stanford與CMV(受控醫(yī)學(xué)詞匯庫(kù))共同組成,下面通過一個(gè)簡(jiǎn)單的病例文件來說明分詞的過程?，F(xiàn)有2個(gè)病歷數(shù)據(jù)記錄,其中包含的病例描述內(nèi)容如下:

Datarecord1:性別女,微創(chuàng)手術(shù)。

Datarecord2:是擴(kuò)張性心臟病患者,伴有心臟衰竭

通過分詞工具處理后,獲得的中文數(shù)據(jù)為:

Datarecord1:性別女,微創(chuàng)手術(shù)。

DataRecord2:是擴(kuò)張性心臟病患者,伴有心臟衰竭

將“性別”、“是”等在醫(yī)療數(shù)據(jù)檢索中無具體含義的詞與標(biāo)點(diǎn)符號(hào)過濾掉。獲取到的數(shù)據(jù)為:

Datarecord1: [女] [微創(chuàng)] [手術(shù)]

DataRecord2:[擴(kuò)張性] [心臟病] [患者] [心臟] [衰竭]

在數(shù)據(jù)檢索中除記錄數(shù)據(jù)文件中包含的關(guān)鍵詞的內(nèi)容以外,還應(yīng)對(duì)各個(gè)關(guān)鍵詞在每個(gè)文件中的數(shù)量與位置進(jìn)行標(biāo)記。主要包括兩個(gè)方面,首先是關(guān)鍵詞在整篇文擋中的字符位置,便于在向用戶顯示數(shù)據(jù)檢索結(jié)果時(shí)提高對(duì)關(guān)鍵詞進(jìn)行突高亮顯示定位的執(zhí)行速度。其次是記錄它在關(guān)鍵詞序列中的位置,以提升在詞組查詢中的執(zhí)行效率。根據(jù)所獲取的關(guān)鍵詞及相關(guān)信息而建立的索引數(shù)據(jù)表如表1所示。

表1 索引結(jié)果表

3.2.4索引數(shù)據(jù)庫(kù)的構(gòu)建

根據(jù)以上分析結(jié)果,可以在索引數(shù)據(jù)庫(kù)創(chuàng)建數(shù)據(jù)表Index-Key-Table,該表格的字段結(jié)構(gòu)與數(shù)據(jù)類型(以常見的MySQL5.0數(shù)據(jù)庫(kù)中的類型格式進(jìn)行描述)如表2所示。

表2 Index-Key-Table表的數(shù)據(jù)結(jié)構(gòu)

其中RecordId字段用于對(duì)病例文件進(jìn)行快速查找,內(nèi)容為病例記錄在數(shù)據(jù)庫(kù)中的唯一編碼,Place字段用于實(shí)現(xiàn)檢索時(shí)關(guān)鍵詞在文本中的突出高亮顯示,內(nèi)容以“N1,N2…Nm”的格式進(jìn)行存儲(chǔ)。在具體使用時(shí),開發(fā)人員可以通過前端編程對(duì)字段內(nèi)容進(jìn)行預(yù)處理后再應(yīng)用在檢測(cè)結(jié)果的顯示頁(yè)面中。

4 結(jié)論

由于電子病歷中存在大量的非結(jié)構(gòu)化數(shù)據(jù)信息,這些數(shù)據(jù)信息增加了系統(tǒng)管理的難度,也影響了各個(gè)醫(yī)療機(jī)構(gòu)之間信息的有效共享,因此本文提出了一種基于Hadoop云計(jì)算平臺(tái)與UIMA框架的電子病歷非結(jié)構(gòu)化數(shù)據(jù)處理解決方案。在該方案中構(gòu)建了專門應(yīng)用于海量電子病例數(shù)據(jù)的分層模型,并根據(jù)電子病歷數(shù)據(jù)的非結(jié)構(gòu)化類型特點(diǎn)設(shè)計(jì)電子病歷數(shù)據(jù)的預(yù)處理機(jī)制和數(shù)據(jù)處理引擎的核心部分Map-Reduce編程模型與UIMA分析引擎。該方案針對(duì)醫(yī)療類非結(jié)構(gòu)化數(shù)據(jù)的檢索優(yōu)化可以顯著提升大規(guī)模電子病歷數(shù)據(jù)的處理速度,進(jìn)而有效改善基于此類數(shù)據(jù)庫(kù)運(yùn)行的各類數(shù)據(jù)挖掘應(yīng)用的運(yùn)行效率，為未來智慧醫(yī)療系統(tǒng)的建設(shè)與應(yīng)用提供可靠的基礎(chǔ)數(shù)據(jù)支持。