甘臣權(quán),楊宏鵬,祝清意,賈家慶,李昆鴻

(1.重慶郵電大學(xué) 網(wǎng)絡(luò)空間安全與信息法學(xué)院,重慶 400065;2.重慶郵電大學(xué) 通信與信息工程學(xué)院,重慶 400065)

0 引 言

醫(yī)療健康對(duì)于人們生活來(lái)說(shuō)至關(guān)重要,對(duì)醫(yī)療數(shù)據(jù)的分析有助于各種疾病的診斷與預(yù)防[1-2]。電子健康系統(tǒng)和電子病歷的使用為醫(yī)療數(shù)據(jù)的存儲(chǔ)、共享、檢索和追蹤提供了便利。早期,醫(yī)療數(shù)據(jù)存儲(chǔ)在各醫(yī)療機(jī)構(gòu)本地服務(wù)器,造成了數(shù)據(jù)孤島,不利于數(shù)據(jù)共享[3]。隨著云計(jì)算的發(fā)展與應(yīng)用,云服務(wù)器作為一個(gè)大容量的存儲(chǔ)中心開始流行起來(lái)[4]。基于云的電子醫(yī)療系統(tǒng)既有利于數(shù)據(jù)共享,又有利于節(jié)省存儲(chǔ)成本。但是,以服務(wù)器為中心的云服務(wù)往往面臨單點(diǎn)故障和共謀攻擊的威脅,無(wú)法完全保障醫(yī)療數(shù)據(jù)的安全性。

自中本聰發(fā)明數(shù)字加密貨幣比特幣以來(lái),其底層區(qū)塊鏈技術(shù)[5]由于具有去中心化、不可篡改、透明等特點(diǎn)開始受到極大關(guān)注。以太坊Ethereum[6]和超級(jí)賬本Hyperledger[7]相繼誕生。區(qū)塊鏈技術(shù)已被廣泛應(yīng)用于能源[8]、金融[9]、供應(yīng)鏈[10]、醫(yī)療[11]等眾多領(lǐng)域。在醫(yī)療領(lǐng)域,許多研究工作嘗試構(gòu)建醫(yī)療區(qū)塊鏈存儲(chǔ)電子病歷(electronic medical records,EMR)[12],利用區(qū)塊鏈特性來(lái)解決基于云的電子健康系統(tǒng)存在的安全問(wèn)題。

現(xiàn)有基于區(qū)塊鏈的電子醫(yī)療系統(tǒng)研究大多關(guān)注數(shù)據(jù)訪問(wèn)和共享過(guò)程中的安全性[13-14]和隱私保護(hù)[15-16],但當(dāng)需要從醫(yī)療區(qū)塊鏈上搜索所需數(shù)據(jù)時(shí),往往需要按照順序依次逐個(gè)遍歷醫(yī)療區(qū)塊鏈上所有區(qū)塊。以Ethereum為例,由于醫(yī)療數(shù)據(jù)是通過(guò)智能合約調(diào)用相關(guān)函數(shù)上傳到區(qū)塊鏈中的一些額外數(shù)據(jù),并以十六進(jìn)制的形式存在交易中的“input”字段[17],在每次搜索時(shí)都需要遍歷整條區(qū)塊鏈,先獲取塊,再獲取交易,最后獲取交易中“input”字段進(jìn)行解碼獲取數(shù)據(jù)[18]。然而,隨著區(qū)塊鏈逐漸增長(zhǎng),搜索耗時(shí)也會(huì)越來(lái)越長(zhǎng),顯然搜索效率不高,也無(wú)法對(duì)醫(yī)療區(qū)塊鏈上的數(shù)據(jù)進(jìn)行分類,實(shí)現(xiàn)多條件查詢。

為了加快區(qū)塊鏈搜索效率,文獻(xiàn)[19]提出了一種基于圖形處理單元(graphics processing unit,GPU)的鍵值搜索查詢方法,但無(wú)法查詢存入鏈中的額外數(shù)據(jù)。文獻(xiàn)[20]提出了一種基于區(qū)塊鏈的EMR細(xì)粒度訪問(wèn)控制查詢方案,支持塊、不同塊的相同屬性以及兩者的混合查詢。由于授權(quán)、加解密無(wú)需醫(yī)療公鑰基礎(chǔ)設(shè)施,大大減少了查詢時(shí)間。在此基礎(chǔ)上,文獻(xiàn)[21]提出了一個(gè)在塊中構(gòu)造新Merkle樹來(lái)存儲(chǔ)EMR的存儲(chǔ)方法,支持所有參與者按照各自身份進(jìn)行多條件查詢,遺憾的是并沒(méi)有實(shí)驗(yàn)驗(yàn)證。為了提高在塊內(nèi)的查詢效率,文獻(xiàn)[22]將比特幣的挖掘能力轉(zhuǎn)化為查詢能力,結(jié)合布隆過(guò)濾器構(gòu)建了一個(gè)物聯(lián)網(wǎng)領(lǐng)域的查詢模型,但該模型存在一定的誤判率。類似地,文獻(xiàn)[23]提出了一種存儲(chǔ)容量可擴(kuò)展的高效查詢模型ElasticQM,從緩存、全局查詢算法以及基于B-M樹的區(qū)塊內(nèi)部結(jié)構(gòu)3方面出發(fā)提升查詢效率。雖然文獻(xiàn)[19-23]對(duì)區(qū)塊鏈內(nèi)部結(jié)構(gòu)進(jìn)行修改提高了在每個(gè)塊中的查詢效率,但是都需要遍歷整條鏈,故從整體上查詢效率提升并不明顯。

不同于上述研究,文獻(xiàn)[24]提出了一種支持快速空間查詢的時(shí)空數(shù)據(jù)處理方法,解決了塊中因順序遍歷而導(dǎo)致查詢速度低的問(wèn)題。文獻(xiàn)[25]提出了一種基于區(qū)塊鏈具有公平性的可搜索加密方案,但該方案只關(guān)注了查詢的準(zhǔn)確性,并沒(méi)有在時(shí)間上提高搜索效率。文獻(xiàn)[26-27]利用數(shù)據(jù)庫(kù)特性實(shí)現(xiàn)了低延遲和豐富的查詢,但沒(méi)有提供相應(yīng)的驗(yàn)證機(jī)制,無(wú)法保證數(shù)據(jù)的正確性和可靠性。文獻(xiàn)[28]的EtherQL假設(shè)服務(wù)器總是返回正確結(jié)果,但這假設(shè)明顯與現(xiàn)實(shí)不符,無(wú)法實(shí)際應(yīng)用。

為了彌補(bǔ)文獻(xiàn)[26-28]的缺點(diǎn),文獻(xiàn)[29]以Hyperledger Fabric為例,結(jié)合MySQL提出了一種FabricSQL關(guān)系查詢方案,并為存儲(chǔ)在數(shù)據(jù)庫(kù)中的交易數(shù)據(jù)設(shè)計(jì)了一種存儲(chǔ)驗(yàn)證機(jī)制,從而保證數(shù)據(jù)不被篡改。然而,MySQL這種關(guān)系數(shù)據(jù)庫(kù),無(wú)法應(yīng)對(duì)海量數(shù)據(jù),且擴(kuò)展性比較差。對(duì)此,文獻(xiàn)[30]引入了HBase非關(guān)系數(shù)據(jù)庫(kù),并提出了一種支持驗(yàn)證的具有高吞吐量的查詢方法。類似地,文獻(xiàn)[31]也提出了一種在區(qū)塊鏈系統(tǒng)中加入外聯(lián)數(shù)據(jù)庫(kù)的可驗(yàn)證查詢層的方法。此外,為了實(shí)現(xiàn)高準(zhǔn)確性和匹配性醫(yī)療數(shù)據(jù)搜索,文獻(xiàn)[32-34]研究了相關(guān)的激勵(lì)機(jī)制促使患者積極共享醫(yī)療數(shù)據(jù)。雖然利用數(shù)據(jù)庫(kù)可以豐富數(shù)據(jù)查詢功能和縮短數(shù)據(jù)搜索時(shí)間,但是文獻(xiàn)[29-34]只是加快了單個(gè)塊查詢、交易查詢以及用戶余額查詢,并沒(méi)有考慮額外數(shù)據(jù)的分類搜索,自然無(wú)法支持不同身份用戶對(duì)不同數(shù)據(jù)的查詢。

針對(duì)以上述問(wèn)題,本文提出了一種帶有訪問(wèn)控制的可驗(yàn)證醫(yī)療區(qū)塊鏈數(shù)據(jù)的搜索機(jī)制。首先,獲取醫(yī)療區(qū)塊鏈上的交易數(shù)據(jù)構(gòu)建相應(yīng)索引,并采用非關(guān)系數(shù)據(jù)庫(kù)進(jìn)行存儲(chǔ),借助數(shù)據(jù)庫(kù)強(qiáng)大的查詢功能加快數(shù)據(jù)搜索效率,實(shí)現(xiàn)多條件查詢;其次,采用訪問(wèn)控制策略保證用戶訪問(wèn)的合法性和數(shù)據(jù)的安全性,并設(shè)計(jì)了可驗(yàn)證機(jī)制防止數(shù)據(jù)庫(kù)中的數(shù)據(jù)發(fā)生錯(cuò)誤,確保訪問(wèn)數(shù)據(jù)的準(zhǔn)確性;最后,在以太坊Ethereum、非關(guān)系數(shù)據(jù)庫(kù)MongoDB和真實(shí)公開的醫(yī)療數(shù)據(jù)上進(jìn)行了實(shí)驗(yàn)分析,展示了所提可驗(yàn)證搜索機(jī)制的有效性。

1 問(wèn)題描述

在詳細(xì)介紹可驗(yàn)證搜索機(jī)制之前,有必要對(duì)以下問(wèn)題進(jìn)行描述說(shuō)明,以加強(qiáng)闡述。

問(wèn)題1醫(yī)療區(qū)塊鏈存儲(chǔ)原始電子醫(yī)療數(shù)據(jù)為何可行?

問(wèn)題2醫(yī)療區(qū)塊鏈為何需要數(shù)據(jù)搜索與訪問(wèn)控制?

問(wèn)題3醫(yī)療區(qū)塊鏈依序逐塊數(shù)據(jù)搜索為何效率不高?

問(wèn)題4采用數(shù)據(jù)庫(kù)輔助醫(yī)療區(qū)塊鏈數(shù)據(jù)搜索為何可行?

針對(duì)問(wèn)題1,當(dāng)前醫(yī)療區(qū)塊鏈處理電子醫(yī)療數(shù)據(jù)的方式可以分成2類:第1類是鏈上只存儲(chǔ)電子醫(yī)療數(shù)據(jù)對(duì)應(yīng)的哈希值,原始電子醫(yī)療數(shù)據(jù)存儲(chǔ)在云服務(wù)器中[29],這樣做的優(yōu)點(diǎn)是可以減少塊的存儲(chǔ)空間,缺點(diǎn)是無(wú)法完全保證原始電子醫(yī)療數(shù)據(jù)的安全性與正確性,因?yàn)樵拼鎯?chǔ)無(wú)法防止共謀攻擊,一旦發(fā)生刪除或篡改有可能無(wú)法恢復(fù);第2類是鏈上存儲(chǔ)原始電子醫(yī)療數(shù)據(jù)[12,20-21,34],優(yōu)勢(shì)是可以彌補(bǔ)第1類存儲(chǔ)的缺點(diǎn),不足是占用塊存儲(chǔ)空間較多,會(huì)影響醫(yī)療區(qū)塊鏈的整體性能。

本文充分考慮上述2類處理方式的優(yōu)缺點(diǎn),將占用空間較小的文本型原始電子醫(yī)療數(shù)據(jù)采用第2類存儲(chǔ),占用空間較大的(比如:CT圖像)仍然采用第1類存儲(chǔ)。實(shí)際上,第1類存儲(chǔ)可以轉(zhuǎn)化為第2類存儲(chǔ),因?yàn)榭梢圆捎媒y(tǒng)一的模式對(duì)所有原始電子醫(yī)療數(shù)據(jù)處理成占用空間較小的文本型數(shù)據(jù)。比如:將包括CT圖像在內(nèi)的原始電子醫(yī)療數(shù)據(jù)都采用文本型關(guān)鍵信息描述,然后采用數(shù)據(jù)壓縮技術(shù)進(jìn)一步減少空間占用。圖像型數(shù)據(jù),就算被篡改或刪除,鏈中的文本型描述也可以查看和校驗(yàn),實(shí)在不行可以對(duì)患者重新掃描生成最新的。為了描述方便,本文只研究第2類存儲(chǔ)。

針對(duì)問(wèn)題2,無(wú)論是電子醫(yī)療數(shù)據(jù)是否存儲(chǔ)在醫(yī)療區(qū)塊鏈上,日常的醫(yī)療診斷、第三方機(jī)構(gòu)(比如保險(xiǎn)公司)辦理業(yè)務(wù),都需要通過(guò)醫(yī)療區(qū)塊鏈查詢患者的電子醫(yī)療數(shù)據(jù),隨著醫(yī)療區(qū)塊鏈數(shù)據(jù)的不斷增多,要在海量數(shù)據(jù)里精準(zhǔn)快速地查找離不開搜索機(jī)制,就像在互聯(lián)網(wǎng)搜索過(guò)程中離不開搜索引擎一樣。醫(yī)療區(qū)塊鏈上存儲(chǔ)的醫(yī)療數(shù)據(jù)具有敏感性與隱私性,無(wú)法完全將互聯(lián)網(wǎng)搜索引擎照搬到區(qū)塊鏈中來(lái)。

醫(yī)療區(qū)塊鏈數(shù)據(jù)搜索不能像互聯(lián)網(wǎng)中搜索引擎一樣不區(qū)分內(nèi)容或用戶身份,不同用戶對(duì)醫(yī)療區(qū)塊鏈上的醫(yī)療數(shù)據(jù)搜索范圍肯定不一樣。醫(yī)療機(jī)構(gòu)每天需要對(duì)某種疾病進(jìn)行研究或?qū)Σ煌颊哌M(jìn)行治療,一般需要搜索全部醫(yī)療數(shù)據(jù);患者一般只能搜索自己的醫(yī)療數(shù)據(jù);第三方機(jī)構(gòu)一般只能搜索與之相關(guān)人員的醫(yī)療數(shù)據(jù)。為了保障醫(yī)療數(shù)據(jù)的安全性與隱私性,必須區(qū)分不同用戶的搜索權(quán)限,這就需要采用訪問(wèn)控制。

針對(duì)問(wèn)題3,若依序逐塊進(jìn)行數(shù)據(jù)搜索,每一次都要從頭開始逐塊遍歷,雖然可以找到相應(yīng)結(jié)果,但是隨著醫(yī)療區(qū)塊鏈數(shù)據(jù)的不斷增多,這樣的“窮舉法”在海量數(shù)據(jù)里查找無(wú)疑會(huì)越來(lái)越耗時(shí)。此外,依序逐塊搜索提供的查詢功能比較單一,無(wú)法滿足醫(yī)療區(qū)塊鏈中不同用戶的多條件訪問(wèn)需求,這也會(huì)導(dǎo)致搜索效率不高。

針對(duì)問(wèn)題4,數(shù)據(jù)庫(kù)是按照數(shù)據(jù)結(jié)構(gòu)來(lái)組織、存儲(chǔ)和管理數(shù)據(jù)的倉(cāng)庫(kù),可以提供豐富的查詢功能,在各行各業(yè)得到了廣泛應(yīng)用。在醫(yī)療區(qū)塊鏈數(shù)據(jù)查詢方面,文獻(xiàn)[29-31]已經(jīng)嘗試采用關(guān)系數(shù)據(jù)庫(kù)或非關(guān)系數(shù)據(jù)庫(kù)進(jìn)行輔助查詢,這表明醫(yī)療區(qū)塊鏈數(shù)據(jù)搜索采用數(shù)據(jù)庫(kù)是可行的。

結(jié)合上述問(wèn)題,本文提出了一種帶有訪問(wèn)控制、可驗(yàn)證醫(yī)療區(qū)塊鏈數(shù)據(jù)的搜索機(jī)制。為了提高搜索效率、實(shí)現(xiàn)多條件查詢和防止數(shù)據(jù)篡改,本文采用鏈上存儲(chǔ)原始電子醫(yī)療數(shù)據(jù)和非關(guān)系數(shù)據(jù)庫(kù)進(jìn)行輔助搜索。

2 可驗(yàn)證搜索機(jī)制

本文假設(shè)各個(gè)醫(yī)療機(jī)構(gòu)通過(guò)協(xié)商組成一個(gè)聯(lián)盟鏈,其系統(tǒng)模型如圖1所示。模型共有5個(gè)實(shí)體:患者、醫(yī)療機(jī)構(gòu)、聯(lián)盟鏈、數(shù)據(jù)庫(kù)、其他訪問(wèn)用戶。搜索機(jī)制包含3個(gè)階段:電子醫(yī)療數(shù)據(jù)鏈上存儲(chǔ)、交易數(shù)據(jù)鏈下存儲(chǔ)以及可驗(yàn)證搜索。

圖1 系統(tǒng)模型Fig.1 System model

2.1 醫(yī)療數(shù)據(jù)鏈上存儲(chǔ)

當(dāng)患者前往醫(yī)療機(jī)構(gòu)就醫(yī)時(shí),醫(yī)生負(fù)責(zé)對(duì)患者進(jìn)行診斷治療,相應(yīng)生成的醫(yī)療數(shù)據(jù)將會(huì)上傳到醫(yī)療區(qū)塊鏈中,上傳規(guī)則可參照文獻(xiàn)[34]。存儲(chǔ)在區(qū)塊鏈上的醫(yī)療數(shù)據(jù)對(duì)加入醫(yī)療區(qū)塊鏈系統(tǒng)中的所有用戶都可見(jiàn),為保護(hù)患者隱私,在數(shù)據(jù)上鏈前需要判斷是否存在敏感數(shù)據(jù)需要進(jìn)行加密處理,加密細(xì)節(jié)可借鑒文獻(xiàn)[35-36]。

本文所涉及的電子醫(yī)療數(shù)據(jù)主要包含病歷id、患者姓名、年齡、性別、電話、地址、疾病類型、診斷信息、圖像對(duì)應(yīng)的哈希值、文本型關(guān)鍵信息及其在本地云中的存儲(chǔ)位置、醫(yī)院id、部門id、醫(yī)生id等信息。首先,將這些存入數(shù)據(jù)全部拼接并進(jìn)行哈希,生成一個(gè)哈希值,即

(1)

上傳醫(yī)療數(shù)據(jù)所用的智能合約為數(shù)據(jù)上傳合約(dataupload contract,DUC),電子醫(yī)療數(shù)據(jù)通過(guò)函數(shù)uploadEMR(string id_c_n,string name,uint age,…)進(jìn)行上傳。

交易發(fā)起者用這些十六進(jìn)制數(shù)據(jù)來(lái)告訴合約運(yùn)行的特定函數(shù)。生成的十六進(jìn)制數(shù)據(jù)由函數(shù)的標(biāo)識(shí)符以及12組參數(shù)組成。其中,函數(shù)標(biāo)識(shí)符是該函數(shù)簽名的前8個(gè)字符,它告訴智能合約找到具體的某個(gè)函數(shù)。緊接著是12組以32字節(jié)為一組的參數(shù),它告訴智能合約往函數(shù)中傳遞的值。

此外,針對(duì)一個(gè)塊中可能會(huì)出現(xiàn)無(wú)法存放一份完整電子醫(yī)療數(shù)據(jù)的情況,將其分組之后,生成多筆交易存儲(chǔ)在多個(gè)塊中,并使用id-count-num關(guān)聯(lián)將其分割成多條交易的電子醫(yī)療數(shù)據(jù)。id-count-num中,id表示病歷id,將分組的數(shù)據(jù)關(guān)聯(lián)起來(lái);count表示總共被分割成幾條交易;num表示第幾條交易,它用來(lái)拼接字段的先后順序。id-0-0表示數(shù)據(jù)沒(méi)有被分割。

本文以以太坊為例在圖2中描述了區(qū)塊交易結(jié)構(gòu)以及input字段的組成部分。為了簡(jiǎn)單起見(jiàn),圖2中只列出了函數(shù)的前3個(gè)參數(shù),同時(shí)在表1中對(duì)交易結(jié)構(gòu)的字段進(jìn)行了解釋。

表1 交易結(jié)構(gòu)中主要字段解釋Tab.1 Main fields in the transaction structure are explained

2.2 交易數(shù)據(jù)鏈下存儲(chǔ)

將醫(yī)療區(qū)塊鏈中的交易數(shù)據(jù)導(dǎo)入數(shù)據(jù)庫(kù)前需要考慮如何設(shè)計(jì)數(shù)據(jù)庫(kù)中的表來(lái)進(jìn)行存儲(chǔ)。非關(guān)系數(shù)據(jù)庫(kù)類型繁多,且不同類型數(shù)據(jù)庫(kù)設(shè)計(jì)方式也不同。由于每份電子醫(yī)療數(shù)據(jù)可以以文檔的形式出現(xiàn),故本文選取面向文檔類型的非關(guān)系數(shù)據(jù)庫(kù)MongoDB來(lái)進(jìn)行設(shè)計(jì),在MongoDB中的集合就相當(dāng)于關(guān)系數(shù)據(jù)庫(kù)中的表。由于本文關(guān)注的是如何搜索患者的電子醫(yī)療數(shù)據(jù),故只需往數(shù)據(jù)庫(kù)里存儲(chǔ)input字段中包含的醫(yī)療數(shù)據(jù)以及可以定位交易信息的N、H(具體含義見(jiàn)表1),定位交易信息主要用于后續(xù)的驗(yàn)證。

本文的電子醫(yī)療數(shù)據(jù)主要包含患者個(gè)人信息(patientInfo),醫(yī)院信息(hospitalInfo),患者病歷信息(EMRInfo)。將醫(yī)療區(qū)塊鏈中的醫(yī)療數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)后,為了后續(xù)驗(yàn)證醫(yī)療數(shù)據(jù)的正確性和完整性,還需要提取區(qū)塊信息(blockInfo),用于定位醫(yī)療數(shù)據(jù)存儲(chǔ)于哪筆交易。它們包含的主要字段如下。

patientInfo

{

"id" : 1,

"name" : Bob,

"age" : 20,

"sex" : Male,

"phone" : ***,

"address" : Chongqing

}

hospitalInfo

{

"id" : 1,

"hosId" : 2,

"depId" : 3,

"docId" : 4

}

EMRInfo

{

"id" : 1,

"type" : "Enterogastritis",

"info" : "Diarrhea, vomiting, and abdominal pain",

"phoHash" : "0x0dff12a2",

"phoLocation" : "/mnt/dbfs",

"phoDescription" : Nothing

}

blockInfo

{

"id" : 1,

"blockNumber" : 10,

"transactionIndex" : 1,

"hash" : "0xac12d5dd"

}

通常情況下,電子醫(yī)療數(shù)據(jù)中4部分?jǐn)?shù)據(jù)分別存儲(chǔ)在4個(gè)集合中,并通過(guò)綁定id關(guān)聯(lián)在一起。當(dāng)查詢一份滿足條件的電子醫(yī)療數(shù)據(jù)時(shí)需要通過(guò)關(guān)聯(lián)的id將4個(gè)集合中關(guān)聯(lián)的數(shù)據(jù)都顯示出來(lái)。在這種情況下,查詢性能會(huì)比較慢,且在更新或添加數(shù)據(jù)時(shí),4個(gè)集合都需要操作。本文使用一對(duì)一內(nèi)嵌文檔模型。所謂一對(duì)一就是一份電子醫(yī)療數(shù)據(jù)只對(duì)應(yīng)一個(gè)患者,通過(guò)內(nèi)嵌文檔模型將4種信息作為單個(gè)文檔內(nèi)嵌在主文檔中,添加、刪除、修改、查詢只需要操作一個(gè)集合即可。這樣更易于管理,消除了因關(guān)聯(lián)4個(gè)集合而帶來(lái)的性能影響。一對(duì)一內(nèi)嵌文檔模型的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)如下。

{

"id" : 1

"patientInfo" : {

"name" : "Bob",

"age" : 20,

"sex" : "male",

"Address" : "Chongqing",

"phone" : ***

}

"hospitalInfo" : {

"hosId" : 2,

"depId" : 3,

"docId" : 4

}

"EMRInfo" : {

"type" : "Enterogastritis",

"info" : "Diarrhea, vomiting, and abdominal pain",

"phoHash" : "0x0dff12a2",

"phoLocation" : "/mnt/dbfs"

}

"blockInfo" : {

"blockNumber" : 10,

"transactionIndex" : 1,

"hash" : "0xac12d5dd"

}

}

注意:這些字段只是作為一個(gè)例子便于講解,而實(shí)際應(yīng)用中可能是其他字段屬性。于是,可以將舉例的字段屬性抽象成一組字段屬性:屬性1,屬性2,…,屬性n,對(duì)應(yīng)值分別為1,2,…,n。具體的字段屬性和數(shù)量由實(shí)際情況確定。

下面將介紹如何處理區(qū)塊鏈中的醫(yī)療數(shù)據(jù),并將其存儲(chǔ)在數(shù)據(jù)庫(kù)中從而實(shí)現(xiàn)對(duì)醫(yī)療數(shù)據(jù)多條件搜索,具體處理過(guò)程見(jiàn)算法1。在這里,政府部門可以作為一個(gè)可信機(jī)構(gòu)充當(dāng)醫(yī)療區(qū)塊鏈系統(tǒng)中的搜索方,負(fù)責(zé)將區(qū)塊中的醫(yī)療數(shù)據(jù)處理入庫(kù)并對(duì)系統(tǒng)進(jìn)行維護(hù)。

利用數(shù)據(jù)庫(kù),可以根據(jù)搜索條件查詢對(duì)應(yīng)的所有數(shù)據(jù)。另外,本文對(duì)區(qū)塊鏈中醫(yī)療數(shù)據(jù)的入庫(kù)處理進(jìn)行持久化處理,當(dāng)發(fā)生故障或更新時(shí),需要暫停工作,在下次繼續(xù)工作時(shí),可以直接從上次同步的區(qū)塊高度開始繼續(xù)處理區(qū)塊中的醫(yī)療數(shù)據(jù),這樣可以避免每次都從頭處理區(qū)塊中的醫(yī)療數(shù)據(jù)。

算法1醫(yī)療區(qū)塊鏈中數(shù)據(jù)處理過(guò)程

輸入:區(qū)塊號(hào)

輸出:true or false

1.定義包含元素的result列表,key主要用于存儲(chǔ)電子醫(yī)療數(shù)據(jù)中的字段,value存儲(chǔ)字段對(duì)應(yīng)的值;

2.定義5個(gè)文檔document0,document1,document2,document3,document4;

3.定義3個(gè)字典,分別包含patientInfo,hospitalInfo,EMRInfo所對(duì)應(yīng)的字段;

4.定義兩個(gè)字典map_data和map_count;

5.for(訪問(wèn)第1個(gè)到最后一個(gè)區(qū)塊)

6. {

7. 訪問(wèn)區(qū)塊中的所有交易;

8. if(交易為空)

9. { 跳轉(zhuǎn)到步驟4; }

10. for(訪問(wèn)每筆交易)

11. {

12. 訪問(wèn)交易中的,input和;

13. result = input解碼,生成數(shù)據(jù)為形式的列表;

14. first = 獲取result第1個(gè)元素的value;

15. 分隔first,分別獲取id,count,num;

16. if(count != 0)

17. {

18. if(id不在map_data和map_count中)

19. {

20. 創(chuàng)建一個(gè)長(zhǎng)度為count的數(shù)組arr;

21. 將result存入arr的第num個(gè)位置;

22. 將存入map_data;

23. 將存入map_count;

24. }

25. else

26. {

27. 將result存入map_data中id對(duì)應(yīng)arr的第num個(gè)位置;

28. 將存入map_count;

29. if(map_count中id對(duì)應(yīng)的值

30. {跳出本次循環(huán)繼續(xù)下一次循環(huán); }

31. result = 按順序合并id對(duì)應(yīng)map_data的arr的所有元素,如果有重復(fù)字段,則將對(duì)應(yīng)的值按順序全部拼接,id-count-num變?yōu)閕d;

32. 清除map_data和map_count中的id;

33. }

34. }

35. for(訪問(wèn)result列表)

36. {

37. k=訪問(wèn)元素的key;

38. v=訪問(wèn)元素的value;

39. if(k在patientInfo中)

40. { 將k和v以key-value的形式存入到document1; }

41. else if(k在hospitalInfo中)

42. { 將k和v以key-value的形式存入到document2中;}

43. else

44. { 將k和v以key-value的形式存入到document3中; }

45. }

46. 將、、以key-value的形式存入到document4中;

47.將document1、document2、document3、document4合并到document0中;

48. 將document0插入到數(shù)據(jù)庫(kù)中; }

2.3 可驗(yàn)證搜索

雖然區(qū)塊鏈本身具有防篡改特性,但是當(dāng)把數(shù)據(jù)處理存儲(chǔ)到數(shù)據(jù)庫(kù)之后就無(wú)法保證返回結(jié)果與區(qū)塊鏈中的原始數(shù)據(jù)的一致性。本文提出了一種支持搜索的驗(yàn)證機(jī)制,根據(jù)用戶身份不同,加入了一個(gè)訪問(wèn)控制。本文工作框圖如圖3所示。

圖3 可驗(yàn)證搜索工作框圖Fig.3 Verifiable search work diagram

2.3.1 訪問(wèn)控制

本文訪問(wèn)控制是通過(guò)智能合約實(shí)現(xiàn)的,訪問(wèn)控制流程如圖4所示。方案中包含了5組智能合約:用戶合約(user contract,UC)、訪問(wèn)合約(access contract,AC)、搜索合約(search contract,SC)、行為合約(behavior contract,BC)以及撤銷合約(revoke contract,RC),詳情如下。

圖4 訪問(wèn)控制流程圖Fig.4 Flowchart of access control

UC:該合約主要的作用是用戶注冊(cè)和用戶身份驗(yàn)證,合約包含以下函數(shù)。

? register(string identify,string name)。在本文方案中,凡是加入醫(yī)療區(qū)塊鏈系統(tǒng)的用戶都需要調(diào)用此函數(shù)進(jìn)行身份注冊(cè)并進(jìn)行分類。其間,系統(tǒng)會(huì)為注冊(cè)用戶生成一個(gè)由數(shù)字和字母組成的地址作為假名與真實(shí)身份關(guān)聯(lián),用戶可以使用假名參與訪問(wèn)過(guò)程。注冊(cè)信息會(huì)存放到一個(gè)用戶列表,并由醫(yī)療區(qū)塊鏈系統(tǒng)進(jìn)行維護(hù)。方案中本文將用戶分為4類:未注冊(cè)人員、醫(yī)療機(jī)構(gòu)、患者和第三方(如銀行、保險(xiǎn)公司、個(gè)人),分別用0,1,2,3代替。

? isValidUser()。在用戶發(fā)送搜索請(qǐng)求之前,用戶調(diào)用此函數(shù)進(jìn)行身份驗(yàn)證。該函數(shù)會(huì)獲取用戶的假名并發(fā)送給醫(yī)療區(qū)塊鏈系統(tǒng),醫(yī)療區(qū)塊鏈系統(tǒng)會(huì)根據(jù)假名從用戶列表中進(jìn)行匹配,并驗(yàn)證其身份,最終返回身份驗(yàn)證結(jié)果。

AC:該合約主要用于定義用戶的訪問(wèn)控制策略。經(jīng)過(guò)醫(yī)療區(qū)塊鏈系統(tǒng)驗(yàn)證之后,決定訪問(wèn)用戶是否有權(quán)限訪問(wèn)電子醫(yī)療數(shù)據(jù)。如果用戶為醫(yī)療機(jī)構(gòu),則無(wú)需授權(quán),可以直接訪問(wèn)所有醫(yī)療數(shù)據(jù)。如果用戶為患者本身,只允許訪問(wèn)自己的醫(yī)療數(shù)據(jù)。如果用戶為第三方或者患者想要訪問(wèn)其他患者的醫(yī)療數(shù)據(jù),需要經(jīng)過(guò)授權(quán)之后才可以訪問(wèn),合約包括以下函數(shù)。

? grant()。用戶經(jīng)過(guò)身份驗(yàn)證之后,醫(yī)療區(qū)塊鏈系統(tǒng)調(diào)用此函數(shù)進(jìn)行授權(quán)。同時(shí),允許設(shè)置相應(yīng)的訪問(wèn)時(shí)間,它接受以秒為單位的值。

? getResult()。該函數(shù)用于返回請(qǐng)求之后的授權(quán)結(jié)果。

SC:當(dāng)用戶經(jīng)過(guò)授權(quán)之后,則可以通過(guò)此合約根據(jù)自己的查詢條件發(fā)送查詢語(yǔ)句到搜索方,合約包含以下函數(shù)。

? search(string s)。用戶調(diào)用此函數(shù),發(fā)送自己的搜索條件,可以發(fā)送多次。

BC:該合約主要用于判斷用戶在整個(gè)訪問(wèn)過(guò)程中的惡意行為。若用戶存在惡意行為(例如,頻繁請(qǐng)求、無(wú)效請(qǐng)求、無(wú)權(quán)限請(qǐng)求等),則需要記錄該行為,并進(jìn)行相應(yīng)的懲罰,合約包含以下函數(shù)。

? illegalActs(string depict)。當(dāng)用戶發(fā)生惡意行為時(shí),醫(yī)療區(qū)塊鏈系統(tǒng)調(diào)用該函數(shù),記錄用戶的非法行為。同時(shí),記錄該用戶的非法行為次數(shù)。

? setPunishTime()。當(dāng)用戶存在惡意行為時(shí),醫(yī)療區(qū)塊鏈系統(tǒng)記錄其行為之后會(huì)調(diào)用該函數(shù)設(shè)置懲罰時(shí)間,其間不允許用戶進(jìn)行訪問(wèn)操作,只有懲罰時(shí)間結(jié)束之后才可以繼續(xù)訪問(wèn)。

RC:該合約主要用于撤銷用戶的訪問(wèn)控制權(quán)限。在整個(gè)訪問(wèn)過(guò)程中,如果用戶泄漏了電子醫(yī)療數(shù)據(jù),醫(yī)療區(qū)塊鏈系統(tǒng)可以實(shí)時(shí)撤銷用戶的訪問(wèn)權(quán)限。此外,當(dāng)用戶訪問(wèn)時(shí)間結(jié)束或者用戶訪問(wèn)結(jié)束時(shí),醫(yī)療區(qū)塊鏈系統(tǒng)也會(huì)撤銷訪問(wèn)權(quán)限,合約包含以下函數(shù)。

? deleteAccessByTA()。當(dāng)發(fā)生上述任何一種情況時(shí),醫(yī)療區(qū)塊鏈系統(tǒng)會(huì)調(diào)用此函數(shù),撤銷用戶的訪問(wèn)權(quán)限。

2.3.2 搜索

經(jīng)過(guò)訪問(wèn)控制之后,用戶通過(guò)客戶端輸入搜索條件,然后生成一條查詢語(yǔ)句s,并通過(guò)SC中的search(string s)函數(shù)向搜索方發(fā)送搜索醫(yī)療數(shù)據(jù)請(qǐng)求。該函數(shù)主要涉及一筆帶有搜索請(qǐng)求數(shù)據(jù)的轉(zhuǎn)賬交易。由用戶向搜索方發(fā)送一筆轉(zhuǎn)賬交易,充當(dāng)搜索醫(yī)療數(shù)據(jù)的費(fèi)用,并通過(guò)search函數(shù)中傳遞的參數(shù)作為請(qǐng)求搜索的數(shù)據(jù)。

搜索階段除了從數(shù)據(jù)庫(kù)獲取醫(yī)療數(shù)據(jù)之外,還支持從區(qū)塊鏈以及客戶端緩存上搜索。最終,由搜索方返回搜索結(jié)果集resultSet為

resultSet={idi,{patientInfoi,hospitalInfoi,

EMRInfoi,blockInfoi}}

(2)

(2)式中,i∈1,2,…,n。

整個(gè)搜索過(guò)程可以分為3種情形。

情形1用戶都會(huì)有一個(gè)客戶端緩存,每成功完成一次搜索請(qǐng)求之后,都會(huì)將搜索結(jié)果緩存在本地。在下一次搜索相同數(shù)據(jù)的時(shí),就會(huì)先從本地緩存中進(jìn)行查找并獲取結(jié)果集resultSet。

情形2在本地緩存沒(méi)有滿足用戶的請(qǐng)求結(jié)果時(shí),就會(huì)請(qǐng)求搜索方,搜索方根據(jù)用戶發(fā)送的查詢條件通過(guò)數(shù)據(jù)庫(kù)進(jìn)行查詢,如果沒(méi)有對(duì)應(yīng)的結(jié)果就會(huì)返回未查詢到的信息,否則把查詢到的結(jié)果集resultSet返回給用戶。

情形3由于鏈下存儲(chǔ)存在無(wú)法及時(shí)將數(shù)據(jù)處理并存儲(chǔ)到數(shù)據(jù)庫(kù)的情況,本文考慮了以下兩個(gè)方面。

1)入庫(kù)操作由于故障等原因會(huì)暫停工作,區(qū)塊鏈上的數(shù)據(jù)會(huì)持續(xù)更新,從而導(dǎo)致更新后的區(qū)塊數(shù)據(jù)沒(méi)有處理。

2)在區(qū)塊鏈網(wǎng)絡(luò)中,會(huì)涉及到網(wǎng)絡(luò)延遲,也會(huì)出現(xiàn)區(qū)塊數(shù)據(jù)沒(méi)有處理的情況。

基于此,搜索方會(huì)保留處理的最終區(qū)塊高度He,當(dāng)接收用戶的查詢請(qǐng)求時(shí),執(zhí)行完數(shù)據(jù)庫(kù)查詢之后,會(huì)從高度為He+1的區(qū)塊開始進(jìn)行鏈上搜索,由于此階段所得的數(shù)據(jù)來(lái)源于區(qū)塊鏈而不是數(shù)據(jù)庫(kù),故無(wú)需進(jìn)行額外驗(yàn)證。

2.3.3 驗(yàn)證

為了保證數(shù)據(jù)庫(kù)中的數(shù)據(jù)沒(méi)有被篡改過(guò),本文設(shè)計(jì)了一種驗(yàn)證機(jī)制。在該機(jī)制中,區(qū)塊鏈系統(tǒng)共涉及兩方面驗(yàn)證。一方面是定期對(duì)數(shù)據(jù)庫(kù)進(jìn)行驗(yàn)證。另一方面是對(duì)搜索結(jié)果進(jìn)行驗(yàn)證。

定期驗(yàn)證。在將鏈上的醫(yī)療數(shù)據(jù)經(jīng)過(guò)處理存儲(chǔ)到數(shù)據(jù)庫(kù)之后,醫(yī)療區(qū)塊鏈系統(tǒng)會(huì)定期(比如每隔1個(gè)月)對(duì)數(shù)據(jù)庫(kù)中的數(shù)據(jù)進(jìn)行驗(yàn)證,并可以對(duì)被篡改過(guò)的醫(yī)療數(shù)據(jù)進(jìn)行更正。驗(yàn)證步驟如下。

1)在將區(qū)塊鏈中的醫(yī)療數(shù)據(jù)處理到數(shù)據(jù)庫(kù)之后,MongoDB會(huì)按寫入的順序進(jìn)行存儲(chǔ),那么就會(huì)按區(qū)塊的順序從頭開始存儲(chǔ),只有發(fā)生更新的時(shí)候,數(shù)據(jù)就會(huì)跑到數(shù)據(jù)庫(kù)的最后面。因此,需要事先對(duì)blockInfo中的blockNumber字段建立索引,以提升查詢某個(gè)塊對(duì)應(yīng)數(shù)據(jù)的速度。

2)醫(yī)療區(qū)塊鏈系統(tǒng)從區(qū)塊鏈中的第1個(gè)塊開始,獲取N以及里面的交易在塊中的索引集合IN={1,2,…,k},k表示索引。首先,使用數(shù)據(jù)庫(kù)查詢區(qū)塊號(hào)為N的所有醫(yī)療數(shù)據(jù),并對(duì)索引值n升序排序,然后依次獲取這些醫(yī)療數(shù)據(jù)的交易n,并與IN中的索引值進(jìn)行匹配,確定兩邊醫(yī)療數(shù)據(jù)包含的索引值是否對(duì)應(yīng)。如果全都對(duì)應(yīng),則執(zhí)行步驟3);如果數(shù)據(jù)庫(kù)中少了對(duì)應(yīng)的索引,即有數(shù)據(jù)遭到刪除,則區(qū)塊鏈中對(duì)應(yīng)索引的交易數(shù)據(jù)進(jìn)入處理階段;如果數(shù)據(jù)庫(kù)中的索引相比于區(qū)塊鏈中的數(shù)據(jù)多出來(lái)了,即增加了額外的數(shù)據(jù),則執(zhí)行刪除操作,最后再執(zhí)行步驟3)。

4)醫(yī)療區(qū)塊鏈系統(tǒng)會(huì)從數(shù)據(jù)庫(kù)嘗試獲取比目前最高區(qū)塊高度還高或者區(qū)塊號(hào)為負(fù)數(shù)的數(shù)據(jù)。如果有,則全部刪除,否則不做任何處理。

搜索結(jié)果驗(yàn)證。在區(qū)塊鏈接收到用戶請(qǐng)求后,會(huì)通過(guò)數(shù)據(jù)庫(kù)查詢到所有滿足條件的醫(yī)療數(shù)據(jù)并進(jìn)行分頁(yè)供用戶瀏覽查看,用戶在瀏覽醫(yī)療數(shù)據(jù)的同時(shí),醫(yī)療區(qū)塊鏈系統(tǒng)對(duì)所有結(jié)果進(jìn)行分頁(yè)驗(yàn)證,這樣可以節(jié)省用戶等待時(shí)間。同時(shí),支持返回正確的驗(yàn)證結(jié)果并對(duì)數(shù)據(jù)庫(kù)中被篡改過(guò)的醫(yī)療數(shù)據(jù)進(jìn)行更正。驗(yàn)證步驟如下。

1)當(dāng)用戶瀏覽某一頁(yè)的醫(yī)療數(shù)據(jù)時(shí),醫(yī)療區(qū)塊鏈系統(tǒng)會(huì)計(jì)算該頁(yè)每條數(shù)據(jù)的哈希值,即H(m)=SHA-256(id‖患者姓名‖…‖醫(yī)生id)。

2)獲取每份醫(yī)療數(shù)據(jù)對(duì)應(yīng)的blockInfo部分,通過(guò)blockInfo中的N先定位區(qū)塊,接著根據(jù)n定位對(duì)應(yīng)的交易位置。

當(dāng)用戶查看像CT這種占有較大空間的醫(yī)療數(shù)據(jù)時(shí),還需要根據(jù)EMRInfo中的圖像存儲(chǔ)位置,從相應(yīng)的云上進(jìn)行下載并生成哈希值,然后與EMRInfo中的圖像哈希值進(jìn)行對(duì)比,并判斷是否被修改過(guò)。

3 實(shí)驗(yàn)分析

本節(jié)將對(duì)所提可驗(yàn)證搜索機(jī)制進(jìn)行實(shí)驗(yàn)分析,以展示其優(yōu)越性。首先介紹用于實(shí)驗(yàn)的環(huán)境配置和數(shù)據(jù)集,然后進(jìn)行性能分析,包括與文獻(xiàn)[6,33]的對(duì)比分析。

3.1 環(huán)境配置

本文使用Java和MongoDB進(jìn)行環(huán)境部署,并模擬所提可驗(yàn)證搜索機(jī)制中涉及的多個(gè)功能部分,并在兩臺(tái)不同的設(shè)備上創(chuàng)建了多個(gè)虛擬以太坊節(jié)點(diǎn),設(shè)備配置如表2所示。

表2 設(shè)備配置Tab.2 Device configuration

在兩臺(tái)設(shè)備上分別安裝Ethereum的geth客戶端,并通過(guò)geth客戶端創(chuàng)建多個(gè)以太坊節(jié)點(diǎn)充當(dāng)不同角色,將所有節(jié)點(diǎn)組成一個(gè)醫(yī)療區(qū)塊鏈系統(tǒng)。在這里所有節(jié)點(diǎn)均可充當(dāng)?shù)V工,并隨機(jī)選取一個(gè)節(jié)點(diǎn)部署智能合約,用于醫(yī)療機(jī)構(gòu)上傳患者的EMR,使用web3.js與geth客戶端進(jìn)行交互。為了方便操作,使用Java調(diào)用web3.js API,通過(guò)HTTP請(qǐng)求私有以太坊網(wǎng)絡(luò)進(jìn)行通信,通過(guò)里面的封裝類實(shí)現(xiàn)獲取私有以太坊網(wǎng)絡(luò)上的相關(guān)數(shù)據(jù)。此外,在其中一臺(tái)設(shè)備上安裝MongoDB數(shù)據(jù)庫(kù),使用Java調(diào)用MongoDB API與本地?cái)?shù)據(jù)庫(kù)進(jìn)行通信。通過(guò)Java將區(qū)塊鏈與MongoDB建立聯(lián)系,將從區(qū)塊鏈提取的數(shù)據(jù)存入數(shù)據(jù)庫(kù)中。

3.2 數(shù)據(jù)集

由于沒(méi)有公開可用的電子醫(yī)療數(shù)據(jù)庫(kù),本文采用醫(yī)療保險(xiǎn)和醫(yī)療補(bǔ)助服務(wù)中心(centers for medicare &medicaid services CMS) 2019年第2組公開報(bào)告的臨床醫(yī)生使用數(shù)據(jù)[37]。該數(shù)據(jù)集包含10個(gè)屬性,1 479 394條數(shù)據(jù)。

3.3 性能分析

所提可驗(yàn)證搜索機(jī)制的性能主要依賴于區(qū)塊鏈平臺(tái)、智能合約以及數(shù)據(jù)庫(kù),接下來(lái)將詳細(xì)分析該機(jī)制的效率,展示其可行性。

1)搜索時(shí)間成本。為測(cè)試所提可驗(yàn)證搜索機(jī)制在時(shí)間上的搜索效率,本文隨機(jī)對(duì)某一疾病進(jìn)行搜索。例如,搜索測(cè)試數(shù)據(jù)集中spec=“HYPERTENSION”的患者臨床數(shù)據(jù)。通過(guò)語(yǔ)句:db.medical.find({spec:"HYPERTENSION″})進(jìn)行查詢,其中,medical表示數(shù)據(jù)所在的集合。同時(shí)測(cè)試了在不同交易數(shù)量中的搜索時(shí)間(10000到100000筆交易數(shù)據(jù)),并與以太坊[6]、文獻(xiàn)[33]進(jìn)行了對(duì)比,其結(jié)果如圖5所示。

圖5 搜索時(shí)間比較Fig.5 Search time comparison

從圖5可以看出,雖然隨著數(shù)據(jù)量的增大,搜索時(shí)間也在不斷增加,但是本文搜索時(shí)間明顯比另外兩個(gè)增長(zhǎng)緩慢,且仍是毫秒級(jí)。文獻(xiàn)[33]是將整個(gè)區(qū)塊鏈結(jié)構(gòu)進(jìn)行同步,效率會(huì)比較慢,本文只是將交易中的醫(yī)療數(shù)據(jù)同步到數(shù)據(jù)庫(kù),其余不作處理,這樣提高了搜索醫(yī)療數(shù)據(jù)的效率。通過(guò)數(shù)據(jù)庫(kù)中存儲(chǔ)的每份醫(yī)療數(shù)據(jù)所在區(qū)塊鏈中的位置可以快速定位并進(jìn)行驗(yàn)證,這表明本文機(jī)制具有較高的搜索效率。

此外,在10萬(wàn)條數(shù)據(jù)中,本文還測(cè)試了所提可驗(yàn)證機(jī)制在單條件和多條件搜索下有無(wú)索引的搜索時(shí)間對(duì)比。這里單條件表示符合單個(gè)字段對(duì)應(yīng)的醫(yī)療數(shù)據(jù),比如spec=“HYPERTENSION” 患者的臨床數(shù)據(jù),用戶通過(guò)客戶端向醫(yī)療區(qū)塊鏈系統(tǒng)發(fā)送查詢語(yǔ)句db.medical.find({spec:"HYPERTENSION″})。多條件表示符合多個(gè)字段對(duì)應(yīng)的醫(yī)療數(shù)據(jù),這里我們只測(cè)試兩個(gè)條件的搜索時(shí)間。例如,要搜索{spec=“HYPERTENSION”,lst_nm=“LARSON”}的患者臨床數(shù)據(jù),則用戶通過(guò)客戶端向醫(yī)療區(qū)塊鏈系統(tǒng)發(fā)送查詢語(yǔ)句

db.medical.find({

spec:"HYPERTENSION",

lst_nm:"LARSON"

})

來(lái)實(shí)現(xiàn)。單條件與多條件在有無(wú)索引下的搜索時(shí)間對(duì)比如圖6所示。由圖6可知,多條件搜索比單條件搜索耗時(shí)要少,即搜索越精確,耗時(shí)越少;有索引比無(wú)索引耗時(shí)要少。

圖6 單條件與多條件在有無(wú)索引下的搜索時(shí)間對(duì)比Fig.6 Search time comparison between single criteria and multiple criteria with or without indexes

最后,以10萬(wàn)條數(shù)據(jù)為例,根據(jù)不同的用戶類型,并根據(jù)訪問(wèn)控制,測(cè)試了不同用戶搜索自己所在范圍時(shí)所消耗的時(shí)間,其結(jié)果如圖7所示。首先,醫(yī)療機(jī)構(gòu)會(huì)搜索患者臨床治療時(shí)所處的醫(yī)學(xué)專業(yè),本次測(cè)試搜索了spec=“PATHOLOGY”和spec=“ANESTHESIOLOGY”歷史臨床數(shù)據(jù),搜索時(shí)間根據(jù)數(shù)據(jù)量的不同而不同;其次,患者只可以搜索自己的臨床數(shù)據(jù),搜索時(shí)間大致在50 ms左右;而第三方被允許搜索一個(gè)至多個(gè)人的臨床數(shù)據(jù),根據(jù)搜索用戶的數(shù)量不同其搜索時(shí)間也不同。相比較,患者搜索自己的數(shù)據(jù)用的時(shí)間相對(duì)較少。

圖7 不同用戶搜索不同范圍數(shù)據(jù)的時(shí)間比較Fig.7 Timecomparison of different users searching different ranges of data

2)驗(yàn)證時(shí)間成本。本文使用塊定位數(shù)據(jù)以及所提機(jī)制的定位方法(根據(jù)塊和交易在塊中的序號(hào)定位)測(cè)試了平均每條數(shù)據(jù)驗(yàn)證所花費(fèi)的時(shí)間,包含驗(yàn)證正確數(shù)據(jù)和驗(yàn)證被篡改過(guò)的數(shù)據(jù),還對(duì)一次性驗(yàn)證與分頁(yè)驗(yàn)證進(jìn)行了對(duì)比。其中,圖8是通過(guò)將數(shù)據(jù)記錄到Excel中生成的,圖9是將所得的實(shí)驗(yàn)數(shù)據(jù)通過(guò)Matlab生成。圖8—圖9中每個(gè)值都是通過(guò)對(duì)數(shù)據(jù)驗(yàn)證時(shí)間平均取100個(gè)度量來(lái)計(jì)算的。

圖9 對(duì)比驗(yàn)證Fig.9 Validation comparison

由圖8可以看出,根據(jù)塊和交易在塊中的序號(hào)定位進(jìn)行驗(yàn)證所耗費(fèi)的時(shí)間明顯比根據(jù)塊定位進(jìn)行驗(yàn)證所消耗的時(shí)間短;有錯(cuò)誤數(shù)據(jù)消耗的驗(yàn)證時(shí)間比無(wú)錯(cuò)誤數(shù)據(jù)消耗的驗(yàn)證時(shí)間長(zhǎng)。這是因?yàn)橛绣e(cuò)誤數(shù)據(jù)的驗(yàn)證需要增加對(duì)錯(cuò)誤數(shù)據(jù)的替換步驟,增加了時(shí)間成本。由于搜索結(jié)果返回的數(shù)據(jù)量是不確定的,本文測(cè)試了返回1—100條結(jié)果時(shí),分頁(yè)驗(yàn)證與一次性驗(yàn)證所有結(jié)果所消耗的時(shí)間,其結(jié)果如圖9所示。從圖9可以看出,隨著搜索的數(shù)據(jù)越來(lái)越多,如果一次性對(duì)所有搜索結(jié)果驗(yàn)證,消耗的時(shí)間會(huì)越來(lái)越多,整個(gè)驗(yàn)證過(guò)程的時(shí)間就會(huì)隨之增加。

3)交易數(shù)據(jù)入庫(kù)處理的時(shí)間成本。首先,本文分析了在關(guān)系型數(shù)據(jù)庫(kù)MySQL與非關(guān)系型數(shù)據(jù)庫(kù)MongoDB下,單筆交易和單個(gè)塊中數(shù)據(jù)處理的時(shí)間開銷對(duì)比,將所得數(shù)據(jù)記錄到Excel表格中,并生成如圖10和圖11所示的柱狀圖,所得數(shù)值都是通過(guò)對(duì)每個(gè)過(guò)程的時(shí)間開銷取100個(gè)度量來(lái)計(jì)算其平均值。主要包括提取數(shù)據(jù)時(shí)對(duì)數(shù)據(jù)處理的平均時(shí)間以及處理完畢后插入數(shù)據(jù)庫(kù)的平均時(shí)間。從圖10—圖11中可以看出,使用MongoDB時(shí),每筆交易整個(gè)過(guò)程的處理時(shí)間僅在7 ms左右,平均每個(gè)區(qū)塊整個(gè)過(guò)程的處理時(shí)間僅在500 ms左右。而使用MySQL時(shí),每筆交易整個(gè)過(guò)程的處理時(shí)間僅在12 ms左右,平均每個(gè)區(qū)塊整個(gè)過(guò)程的處理時(shí)間在850 ms左右。通過(guò)對(duì)比,MongoDB處理的時(shí)間會(huì)更短一些。雖然處理整條鏈消耗時(shí)間可能會(huì)比較長(zhǎng),但是會(huì)大大縮短搜索的時(shí)間。

圖10 單筆交易中醫(yī)療數(shù)據(jù)入庫(kù)處理時(shí)間成本分析Fig.10 Time cost analysis of medical data entry and processing in a single transaction

圖11 單個(gè)塊中醫(yī)療數(shù)據(jù)入庫(kù)處理時(shí)間成本分析Fig.11 Time cost analysis of medical data entry processing in a single block

4)Gas成本開銷。在搜索機(jī)制的整個(gè)過(guò)程中,需要通過(guò)智能合約來(lái)執(zhí)行需要的操作,這會(huì)消耗一定的gas值,而這些gas只是用于測(cè)試,并不用于真正的交易。表3為方案中所涉及智能合約的部署成本,圖12為智能合約所包含函數(shù)的執(zhí)行成本。從測(cè)試結(jié)果來(lái)看,一方面,如果合約中的邏輯代碼比較多,則合約部署所消耗的gas會(huì)多一點(diǎn);另一方面,調(diào)用合約時(shí),輸入的數(shù)據(jù)量多,則消耗的gas也會(huì)變多。最后,也可以采用一些綠色節(jié)能的共識(shí)算法來(lái)進(jìn)一步降低gas成本的消耗。

表3 智能合約部署成本Tab.3 Gas cost of smart contract deployment

圖12 智能合約部署和執(zhí)行成本Fig.12 Costs of smart contract deployment and implementation

4 結(jié)束語(yǔ)

區(qū)塊鏈的搜索方式大都按照順序依次遍歷整條鏈,且用戶無(wú)法按照不同用戶類型搜索所屬范圍的醫(yī)療數(shù)據(jù)。為此,本文提出了一種帶有訪問(wèn)控制的可驗(yàn)證醫(yī)療區(qū)塊鏈數(shù)據(jù)搜索機(jī)制,借助于非關(guān)系數(shù)據(jù)庫(kù),不僅提高了數(shù)據(jù)搜索速度還豐富了查詢功能。訪問(wèn)控制的使用確保了不同用戶只能搜索自己權(quán)限范圍內(nèi)的醫(yī)療數(shù)據(jù)。為了保證搜索的數(shù)據(jù)不被篡改,本文設(shè)計(jì)了一種分頁(yè)驗(yàn)證機(jī)制,使用戶在查看所搜索結(jié)果的同時(shí)對(duì)搜索結(jié)果進(jìn)行驗(yàn)證。最后,在以太坊Ethereum、非關(guān)系數(shù)據(jù)庫(kù)MongoDB和真實(shí)公開的醫(yī)療數(shù)據(jù)上的實(shí)驗(yàn)結(jié)果證明了所提可驗(yàn)證搜索機(jī)制的有效性。