面向臨床數據中心的信息檢索研究與應用

武學鴻，朱建平，李建華

（1.中南大學計算機學院，湖南 長沙 410083；2.湖南科醫云健康科技有限公司，湖南 長沙 410012；3.湖南科創信息技術股份有限公司，湖南 長沙 410012）

臨床數據中心（clinical data centers，CDR）隨著電子病歷應用的不斷豐富而持續發展[1-3]，其包含了患者所有重要的臨床數據，可集成院內各科室級臨床信息系統（醫囑、病歷、檢驗、手術、心電、超聲、病理等），實現所有臨床診療數據的整合與集中展現，并為醫療診斷決策提供支持信息。臨床數據中心具有數據量大、增長快、關聯關系復雜、價值高等特點[4-6]。面對如此龐大的數據規模，傳統的關系型數據庫在存儲能力、檢索效率，尤其是多表關聯檢索等方面，往往無法有效滿足臨床醫生、科研人員等對信息獲取的需求[7-9]。本文提出了應用Elasticsearch分布式搜索引擎技術實現面向臨床數據中心的信息檢索方法[10-13]，結合數據本身及搜索引擎技術特性[14]，制定相應的優化策略，并通過實際檢索場景驗證本方法的效果，現總結如下。

1 數據模型梳理及索引構建

1.1 數據模型梳理 臨床數據主要是以患者為中心，本次圍繞患者住院信息選擇了具有代表性的八類數據來進行相關分析，八類數據信息分別是：病案首頁、檢驗信息、病歷文書、醫囑信息、費用信息、手術信息、診斷信息、檢查信息，其描述見表1。將表1 中八類數據以面向主題的方式進行整合，以病案首頁為核心，其他數據與之形成關聯，見圖1。

圖1 以病案首頁為核心的關聯關系模型

病案首頁中包含了患者的基本信息，以病案首頁信息為中心，其他數據表信息與其構成了父子關聯模型，即病案首頁信息為父表，檢驗信息、病歷文書、醫囑信息等都為子表。通過該模型，在檢索的業務需求中可以根據1個或者多個子表中的1個或者多個字段來查詢病案首頁信息或者根據病案首頁信息來查詢任意1個子表的信息。上述模型結構在面向極端場景時，即根據7個子表同時關聯來查詢病案首頁信息，尤其是表的數據規模達到億級別以上時，傳統關系型數據庫往往難以支撐。Elasticsearch不僅支持分布式索引數據存儲還原生的支持父子關聯索引模型，同時在父子關聯模型查詢接口上提供了很好的支撐，可實現由父查子以及由子查父的關聯檢索場景[15-17]。

1.2 索引模型的構建 結合數據模型間的復雜關聯關系[18，19]，基于Elasticsearch 創建索引并配置各索引類型之間的關聯關系映射，形成父子索引模型，索引映射文件配置部分信息見圖2。

索引模型定義了8 種類型分別對應的8個信息表，各類型包含了一系列屬性對象的定義。其中子表與父表之間的關聯關系是通過表中_parent 屬性定義實現，如：病歷文書（docc）表指定其_parent 屬性值為病案首頁（page），即父表是病案首頁（page），子表是病歷文書（docc）；其他數據表，如檢驗信息、費用信息、診斷信息、醫囑信息等與病歷文書的定義方式一致。定義完索引模型后，通過Elasticsearch 所提供的索引創建API 實現索引的建立。

1.3 數據索引及分詞 Elasticsearch 提供了bulk 接口支持數據索引，即將數據從關系型數據庫或者其他數據源導入到索引庫中，數據索引也有多種工具可選擇，如Elasticsearch river 插件、Logstash 工具等。這些工具都可以解決數據從關系型數據庫索引到Elasticsearch 集群的過程，并支持增量索引。Elasticsearch 默認支持英文單詞的分詞方式，通過安裝配置分詞插件可實現中文分詞，本文中采用的是ik 分詞器[13，20]，該分詞器目前應用較廣泛，無論是原生的分詞效果還是其擴展性都能夠滿足業務檢索的需求。

2 索引的優化方法

2.1 數據索引優化 數據索引即把數據導入到Elasticsearch 的過程，如果數據體量較大，那么在不做優化方案的情況下往往會導致數據索引過慢，而且數據的索引過程并不是一次性的工作，當索引字段變更，索引映射文件變更的時候就需要將所有數據進行重新索引，每次索引過程都比較耗時。為此，本研究對索引過程進行了優化：①在數據索引階段禁用數據的副本：數據副本能夠有效保障數據安全性，但是在數據索引過程中啟用副本會消耗一定時間在數據的復制過程中，通過禁用副本可以提升數據索引的效率，當所有數據索引完成后即可打開副本；②設置數據提交刷新時間為手動刷新：數據索引過程會利用數據緩沖策略，數據緩沖默認實時刷新緩存到持久化層，通過禁用自動刷新，可以有效利用緩存策略，提升數據索引的吞吐量和效率；③設置增大數據索引提交批量：與上一點同原理，通過提升數據索引的提交量，可提升數據索引的吞吐量；④按需調整增加分片數：Elasticsearch 原生支持分布式能力，索引分片是其基礎的分布式單元，通過增加分片數，可以提升其并發處理能力，從而提升數據索引的吞吐量；⑤增大Elasticsearch 服務節點內存：與第③點同原理，啟用緩存，增大提交量就會占用更多服務節點內存，通過增大內存保障吞吐量；⑥原始數據不存儲：Elasticsearch 主要是實現倒排索引的構建與存儲，其本身默認存儲原始數據，但是原始數據過多會導致無論是內存、IO，還是在磁盤空間占用方面都會對索引數據形成一定的影響，因此通過禁用原始數據存儲可以有效釋放資源，保障數據索引效率；⑦提升服務器硬件配置：從硬件層面來提升數據的處理性能，從而保障數據索引效率。

2.2 檢索效率優化 采用Elasticsearch 分布式搜索引擎的默認配置信息即可提供有效的數據檢索性能，然而在實際應用過程中隨著數據量的劇增，默認的配置信息往往無法滿足業務檢索的需求，在硬件配置環境一定情況下可以通過以下方式進行優化配置：①采用分索引方案：按時間維度對索引進行分區劃分，如對臨床數據的檢索一般都會有檢索時間段條件，當數據體量大時可以將索引數據按時間維度劃分索引，2002-2015年共14個索引，其中索引命名方式為index_2002，index_2003....，當業務查詢需要查詢2014-2015年的病案首頁信息時，后端執行API 只需要查詢index_2014，index_2015 這兩個索引即可，這樣有效縮小了數據的檢索范圍，提升了數據的檢索效率；②合理設置索引分片：分片數越多會帶來越高的并發度，但并不是分片數越多越有效，分片數越多也會帶來檢索過程中數據的合并與IO 的消耗，因此需按實際應用情況合理調整分片的數量；③根據實際情況可考慮去除_all 字段：_all 字段是默認啟用，主要用于全文檢索，如果實際場景中只需要實現精確檢索功能，可以去除_all 字段帶來的索引負載；④采用Elasticsearch warmer 實現數據熱加載：基于緩存技術提升檢索效率。

2.3 檢索準確率優化 數據檢索的準確率主要是體現在分詞的準確率上，而分詞的準確率需要有業務相關的專有名詞庫支撐。如“門脈高壓”一詞，在ik分詞器默認分詞配置下，ik 分詞器無法識別“門脈高壓”一詞會將其進一步切分，而如果將“門脈高壓”作為專有名詞庫配置到ik 分詞中，其就能準確識別出“門脈高壓”，在檢索時可以準確檢索出該詞所對應的信息。另一類場景是同義詞庫的應用，在實際檢索過程中，檢索的信息不僅要精確出現，與檢索信息意思相同或相近的結果也需要能夠檢索出來，如同樣檢索“門脈高壓”一詞，需要能夠把包含“肝硬化”記錄信息也能夠檢索出來，而通過配置同義詞庫可以實現該效果。

3 實際檢索場景驗證

3.1 實驗數據與環境 實驗數據采用某醫院2009年的臨床電子病歷數據信息，所有數據已經過脫敏處理，數據總記錄數為12 696 458 條，其中各個表記錄數見表2。

測試所用的Elasticsearch 集群服務包含3個節點，其中每個節點服務器配置信息為：Centos7 64位操作系統、64 GB 內存，CPU 雙路24 核[Intel(R)Xeon (R) CPU E5-2620 v3 @ 2.40GHz]，磁盤空間600 GB。

3.2 數據索引性能分析 以記錄數最多的檢驗信息（lab）數據為例，在保證數據導入源端一致的情況下，通過優化Elasticsearch 集群及索引的配置，分析優化操作對數據導入性能的影響，形成對比結果見圖3。圖中A 是采用Elasticsearch 集群默認的服務節點及索引配置，其中默認服務節點為1 G 內存，默認索引配置為啟用1個副本，5個分片，自動索引刷新；B 在A 的基礎上去除分片副本；C 在A 的基礎上取消索引自動刷新并增大索引數據提交批量；D在A 的基礎上增大分片數，10個分片；E 在A 基礎上增大各個Elasticsearch 節點內存；F 為所有優化集成。可以看出，通過對服務節點及索引的配置優化，B～F 條件下的數據導入性能相較于A 都有明顯提升，F 配置下的數據索引性能最優。

圖3 數據索引性能分析

3.3 關聯檢索結果分析 關聯檢索主要是針對臨床數據中心部分復雜的關聯查詢需求，通過父查子/子查父兩類檢索場景驗證Elasticsearch 檢索服務的有效性。其中“子查父”指根據檢驗信息、病歷文書、醫囑信息、費用信息、手術信息等子表信息，以及病案首頁本身查詢條件來檢索病案首頁信息；“父查子”指根據病案首頁信息，以及任意子表本身的查詢條件來檢索相應的子表信息。實驗結果見圖4。

圖4A 是1個子查父的關聯檢索場景，其具體檢索需求為：患者診斷結果為“慢性腎炎”且手術中采用了“全身麻醉”的所有病案首頁信息，即根據診斷信息以及手術信息來關聯檢索病案首頁信息。圖4B 是1個父查子的關聯檢索場景，其具體檢索需求為：患者性別為男性，且入院日期為2009年3 月18日至2009年4 月19 日之間的所有診斷記錄信息，即根據病案首頁信息來檢索診斷信息。兩種檢索場景都準確的檢索出了相關結果，并且在千萬級數據規模場景下檢索效率分別為42 ms 以及104 ms。

圖4 關聯檢索分析

3.4 數據檢索效率分析 影響檢索效率的因素有很多，包括硬件設施配置、集群中節點內存配置等[21]。本次主要從索引角度出發，在保證硬件配置一致，集群環境配置一致的前提下，通過調整索引分片的數量來分析檢索效率。實驗過程中，基于同一份測試數據創建了10個索引，其中每個索引依次是1個分片到10個分片。通過模擬客戶端發起100 次ES 檢索請求，求取所有請求的平均值，分析不同分片索引下的檢索效率，統計結果見圖5。可以看出，從1 分片到4 分片，分片數越多檢索效率越高，而從4 分片到10 分片，分片數越多檢索效率反而有所下降，主要原因是分片增多，數據并發處理能力雖然提升了，但是數據IO 以及數據的合并所消耗的時間增加了。

圖5 不同分片下檢索效率分析

3.5 檢索準確率分析 IK 分詞器支持自定義詞典庫的配置，在臨床檢索需求中，專有名詞的準確識別對于檢索準確率十分重要。使用IK 默認詞典庫，無法達到準確分詞的效果。為了進一步驗證查詢的準確率，本次建立了3個對比測試索引：ik_all，ik_none_all 和ik_zymc_all，其中3個索引的詞庫配置信息見表3。

表3 索引配置對比

按照是否配置專有名詞、同義詞庫組合劃分，本應還有1個索引，即只配置了同義詞庫，而沒有配置專有名詞庫的，然而當沒有專有名詞庫時，專有名詞無法劃分，那么僅配置同義詞庫將失去意義，因此用于實驗的索引僅有3個。表中3個索引庫中索引的數據一致，分別從3個索引庫中檢索“肝硬化”或“門脈高壓”一詞，查詢統計結果見表4。

表4 檢索結果對比

可以看出，配置了專有名詞庫和同義詞庫，無論是搜索“肝硬化”，還是“門脈高壓”都可以準確搜索出所有的記錄；而僅使用專有名詞的情況下，檢索結果的查全率不足；若沒有配置專有名詞庫、以及同義詞庫，那么在檢索時將無法檢索出任何信息。因此，專有名詞庫提升了檢索的準確率，而配合上同義詞庫后進一步提升了檢索結果的查全率。

4 總結

臨床數據中心的建設為臨床分析、業務優化、決策支持等提供了良好的數據支撐。然而，數據持續增長及業務場景的復雜性都使得傳統關系型數據庫無法有效滿足臨床醫生及科研人員對海量數據信息的檢索與分析需求。本研究提出的基于Elasticsearch分布式搜索引擎的臨床信息檢索方法，可實現復雜業務關聯信息的檢索，同時結合一系列的優化策略進一步提升了臨床信息的索引效率、檢索效率，以及檢索準確率，可快速為臨床醫生、科研人員等提供準確的臨床信息。