閆冠辰, 姜順榮, 李勝利,2, 張啟亮, 周 勇

1. 中國(guó)礦業(yè)大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院, 徐州 221116

2. 徐州醫(yī)科大學(xué)附屬醫(yī)院 病案統(tǒng)計(jì)科, 徐州 221006

3. 徐工漢云技術(shù)股份有限公司, 徐州 221001

1 引言

電子醫(yī)療病歷(electronic health record, EHR) 是一種利用數(shù)字化手段存儲(chǔ)、管理和使用患者資料的醫(yī)療系統(tǒng), 該系統(tǒng)可以記錄患者完整的就診醫(yī)療信息. 對(duì)于某些疾病的患者, 醫(yī)生在后續(xù)的就診過(guò)程中, 可以通過(guò)對(duì)EHR 的查詢, 對(duì)病情有更加全面的了解, 從而能夠進(jìn)行更加高效而全面的治療[1].

近年來(lái), EHR 系統(tǒng)在全球范圍內(nèi)快速發(fā)展, 預(yù)計(jì)2022 年將產(chǎn)生超過(guò)397 億美元的價(jià)值[2]. 在我國(guó), EHR 系統(tǒng)同樣發(fā)展迅速. 以江蘇省為例, 截至2019 年, 75.6% 的基層醫(yī)療機(jī)構(gòu)已經(jīng)建立EHR 系統(tǒng),78.5% 的醫(yī)療機(jī)構(gòu)的信息系統(tǒng)已實(shí)現(xiàn)公共衛(wèi)生服務(wù)功能[3]. 然而, Xing[3]指出, EHR 普及的背后, 依然存在著“信息孤島” 現(xiàn)象, 具體原因有: (1) 數(shù)據(jù)標(biāo)準(zhǔn)不統(tǒng)一; (2) 沒(méi)有開(kāi)通數(shù)據(jù)互通的接口; (3) 缺少信息安全的保障[4]. “信息孤島” 的存在消耗了大量存儲(chǔ)資源, 同時(shí)也存在著數(shù)據(jù)共享上的困難[5]. 這對(duì)于患者轉(zhuǎn)診、轉(zhuǎn)院極為不利, 患者新就診的醫(yī)院可能由于無(wú)法獲得患者之前完整的診療數(shù)據(jù)而耽誤治療時(shí)機(jī).

針對(duì)“信息孤島” 帶來(lái)的EHR 數(shù)據(jù)共享問(wèn)題, 區(qū)塊鏈提供了一種可行的解決思路. 區(qū)塊鏈伴隨著“比特幣[6]” 誕生, 其作為數(shù)字貨幣的底層技術(shù), 可以看作是一個(gè)去中心化的數(shù)據(jù)庫(kù), 適用于需要全局性、歷史性地記錄數(shù)據(jù)的場(chǎng)景[7], 此特點(diǎn)與醫(yī)療領(lǐng)域中共享病歷的需求不謀而合. 區(qū)塊鏈采用密碼技術(shù)和共識(shí)機(jī)制, 將數(shù)據(jù)存儲(chǔ)在一個(gè)個(gè)區(qū)塊中, 再按照時(shí)間順序?qū)^(qū)塊鏈接起來(lái), 具有可追溯、難篡改等特點(diǎn)[8]. 通過(guò)區(qū)塊鏈, 可以保證存儲(chǔ)在鏈上的不被篡改, 即使區(qū)塊鏈上的一小部分節(jié)點(diǎn)被破壞, 整個(gè)區(qū)塊鏈系統(tǒng)仍可以正常運(yùn)行[9].

然而, 區(qū)塊鏈上的數(shù)據(jù)公開(kāi)透明[10], 這無(wú)疑存在著數(shù)據(jù)安全的風(fēng)險(xiǎn). 為了實(shí)現(xiàn)鏈上數(shù)據(jù)的安全共享,Niu 等人[5]結(jié)合代理重加密和可搜索加密技術(shù),實(shí)現(xiàn)了關(guān)鍵字的安全搜索以及數(shù)據(jù)的安全共享. Zhang 等人[11]設(shè)計(jì)了基于實(shí)用拜占庭(PBFT) 算法的聯(lián)盟區(qū)塊鏈系統(tǒng), 降低了算力消耗, 防止了數(shù)據(jù)泄露. Wang等人[12]基于環(huán)簽名技術(shù)構(gòu)建了存儲(chǔ)數(shù)據(jù)協(xié)議, 并使用了智能合約進(jìn)行訪問(wèn)控制. Jiang 等人[13]構(gòu)建了隱匿授權(quán)方案以實(shí)現(xiàn)患者對(duì)數(shù)據(jù)的控制權(quán), 并根據(jù)類(lèi)型打包交易以實(shí)現(xiàn)數(shù)據(jù)的高效刪除. Xu 等人[14]使用同態(tài)加密技術(shù)對(duì)數(shù)據(jù)進(jìn)行隱私保護(hù), 并使用智能合約對(duì)密文進(jìn)行操作, 實(shí)現(xiàn)了自動(dòng)理賠功能, 避免了隱私數(shù)據(jù)的泄露. Ren 等人[15]提出了一種指定驗(yàn)證者序列聚合簽名方案(DVSSA), 以實(shí)現(xiàn)訪問(wèn)控制與隱私保護(hù). 現(xiàn)有方案對(duì)比如表1 所示.

表1 現(xiàn)有方案對(duì)比Table 1 Comparison of existing schemes

上述方案解決了數(shù)據(jù)安全分享的難點(diǎn), 但是模糊查詢的需求沒(méi)有完全實(shí)現(xiàn). 關(guān)于模糊查詢的必要性,Zhang 等人[16]指出, 一種疾病可能由另一種疾病引起或與之相關(guān), 在這種情況下, 診斷的準(zhǔn)確性受到醫(yī)生獲得的病人其他健康信息的數(shù)量和準(zhǔn)確性的影響. 通過(guò)詢問(wèn)病人, 醫(yī)生可以得到有關(guān)疾病的一些信息.然而, 這種方法不足以有效地輔助診斷, 原因有下: (1) 若兩次就診間隔過(guò)久, 病人可能會(huì)忘記一些細(xì)節(jié),例如所服用的藥物或醫(yī)療檢查, 這將影響醫(yī)生的診斷或治療的精確性; (2) 由于病人的醫(yī)學(xué)知識(shí)有限, 不能專(zhuān)業(yè)地描述診斷或治療, 這也會(huì)影響醫(yī)生的判斷. 因此, 高效的模糊查詢算法在診療中是必要的, 其可以快速調(diào)取出患者既往的診療記錄, 幫助醫(yī)生更全面了解患者的身體狀況. 但目前有關(guān)這方面的工作較少, 為此需要設(shè)計(jì)合理的方案, 以實(shí)現(xiàn)醫(yī)療數(shù)據(jù)安全分享與高效模糊查詢的雙目標(biāo).

1.1 本文貢獻(xiàn)

(1) 設(shè)計(jì)、采用統(tǒng)一的EHR 格式生成醫(yī)療數(shù)據(jù), 并采用Fabric 聯(lián)盟鏈平臺(tái)存儲(chǔ)數(shù)據(jù), 方便數(shù)據(jù)共享;

(2) 基于SHVE 算法的特性實(shí)現(xiàn)高效的模糊查詢, 醫(yī)生可以通過(guò)此算法跨科室查詢患者的診療信息;

(3) 改進(jìn)SHVE 算法, 使之與基于密文策略屬性加密(cipertext policy attribute-based encrypption,CP-ABE) 算法相結(jié)合, 并在智能合約上部署CP-ABE 算法, 實(shí)現(xiàn)了細(xì)粒度的訪問(wèn)控制;

(4) 在Fabric 聯(lián)盟鏈平臺(tái)進(jìn)行了模擬測(cè)試, 實(shí)驗(yàn)結(jié)果表明了本方案具有可行性.

2 背景知識(shí)

2.1 SHVE

對(duì)稱(chēng)密鑰隱藏矢量加密(SHVE)[17]是一種謂詞加密方案,并且支持在加密數(shù)據(jù)上進(jìn)行查詢匹配操作.假設(shè)?！蕒0,1}是一個(gè)有限的屬性集,* 為通配符, Γ*∈{0,1,*}, 則SHVE 包含下列算法:

SHVE.Setup(λ)→(msk,M): 輸入安全參數(shù)λ, 返回主密鑰msk, 并生成信息空間M;

SHVE.keyGen(msk,ν ∈Γ*)→sk: 輸入主密鑰msk 和包含通配符*的謂詞向量ν, 返回查詢令牌sk;

SHVE.enc(msk,μ ∈M,x ∈Γ)→c: 輸入主密鑰msk, 待加密信息μ和屬性向量x, 返回密文c;

SHVE.evaluate(sk,c)→message/⊥: 輸入查詢令牌sk 和密文c, 此算法查詢向量ν是否在密文c中. 若PSHVEν(x)=1, 則返回信息message, 否則返回⊥. 其中,PSHVEν(x) 的計(jì)算方法為:

鑒于SHVE 算法的特性, 若給定謂詞向量{1,*,0,*}, 則可以查詢到包含屬性向量為{1, 0, 0, 0}, {1,0, 0, 1}, {1, 1, 0, 0}, {1, 1, 0, 1} 的密文. 因此, 只要合理設(shè)置謂詞向量中的通配符, 就可以快速、全面地篩選出需要的數(shù)據(jù), 達(dá)到模糊選擇的目標(biāo). 又因?yàn)镾HVE 算法支持在加密數(shù)據(jù)上操作, 符合醫(yī)療場(chǎng)景中對(duì)數(shù)據(jù)安全、隱私的需求, 故本文選取此算法用于數(shù)據(jù)的加解密與查詢.

2.2 區(qū)塊鏈

區(qū)塊鏈?zhǔn)且粋€(gè)分布式的共享賬本和數(shù)據(jù)庫(kù), 具有去中心化、不可篡改、全程留痕、可以追溯、集體維護(hù)、公開(kāi)透明等特點(diǎn). 其結(jié)構(gòu)如圖1 所示.

圖1 區(qū)塊鏈結(jié)構(gòu)Figure 1 Structure of blockchain

區(qū)塊鏈可劃分為公有鏈、私有鏈和聯(lián)盟鏈[18], 其中聯(lián)盟鏈由多個(gè)機(jī)構(gòu)共同參與管理, 其中每個(gè)機(jī)構(gòu)運(yùn)行著一個(gè)或多個(gè)節(jié)點(diǎn). 節(jié)點(diǎn)間的權(quán)限完全對(duì)等, 它們不需要完全互信(有一定的信任基礎(chǔ)) 就可以直接進(jìn)行交互, 并由對(duì)等節(jié)點(diǎn)共同記錄交互信息. Hyperledger Fabric 是目前比較成熟的聯(lián)盟鏈, 它是一個(gè)開(kāi)源的企業(yè)級(jí)許可分布式賬本技術(shù)(distributed ledger technology, DLT) 平臺(tái). Fabric 是私密且權(quán)限化的, 相對(duì)于允許未知身份參與網(wǎng)絡(luò)的開(kāi)放式權(quán)限系統(tǒng), 它可以提供更好的數(shù)據(jù)安全性與隱私性. 由于醫(yī)療行業(yè)的數(shù)據(jù)屬于敏感數(shù)據(jù), 包含著患者的隱私, 在處理、存儲(chǔ)過(guò)程中存在著隱私泄露的風(fēng)險(xiǎn), 因而對(duì)平臺(tái)環(huán)境的信任度需求較高. 相較于無(wú)需審核的公有鏈, 需要授權(quán)才可加入或退出的聯(lián)盟鏈更加契合醫(yī)療行業(yè), “授權(quán)”這一操作緩解了信任缺失的情況, 奠定了信任基礎(chǔ). 因此, 本文的方案便基于Fabric 聯(lián)盟鏈設(shè)計(jì).

2.3 雙線性配對(duì)

一個(gè)雙線性配對(duì)(bilinear pairing) 定義為e: G×G→GT, 其表示將階為p的乘法循環(huán)群G 中的兩個(gè)元素映射到同階的乘法循環(huán)群GT中. 定義g為群G 的生成元, 此配對(duì)e具有如下性質(zhì):

(1) 雙線性: 對(duì)于任意a,b ∈G 和隨機(jī)數(shù)m,n ∈Z*q,e(am,bn)=e(a,b)mn始終成立;

(2) 非退化性: 存在g1,g2∈G, 使得e(g1,g2)/=1 成立;

(3) 可計(jì)算性: 對(duì)于任意a,b ∈G,e(a,b) 是可以被計(jì)算出來(lái)的.

2.4 基于密文策略屬性加密

基于屬性加密是為了解決外部存儲(chǔ)環(huán)境中, 數(shù)據(jù)的粒度訪問(wèn)控制問(wèn)題以及大規(guī)模用戶的動(dòng)態(tài)擴(kuò)展問(wèn)題[19], 可分為基于密鑰策略屬性加密(key policy attribute-based encryption, KP-ABE)[20]和基于密文策略屬性加密(CP-ABE)[21].

在CP-ABE 算法中, 用戶通過(guò)密鑰生成算法得到包含自己屬性的屬性密鑰, 而密文數(shù)據(jù)中包含著解密所需要的解密策略, 用戶只有在自己的屬性密鑰與密文中的解密策略完全匹配時(shí), 才能成功解密該數(shù)據(jù).因此, CP-ABE 算法可以用作訪問(wèn)控制算法, 控制密文數(shù)據(jù)的訪問(wèn)權(quán)限, 保護(hù)數(shù)據(jù)安全. CP-ABE 通常包含以下算法:

CP-ABE.Setup(λ)→(PK,MSK): 輸入安全參數(shù)λ, 該算法進(jìn)行初始化, 并生成公開(kāi)參數(shù)PK 和主密鑰MSK;

CP-ABE.keyGen(MSK, Att_S)→USK: 輸入主密鑰和屬性集Att_S, 返回用戶屬性密鑰USK;

CP-ABE.enc(PK, Msg,P)→c: 輸入公開(kāi)參數(shù)、需要加密的數(shù)據(jù)Msg、解密策略P, 返回加密后的密文c;

CP-ABE.dec(PK,c,USK)→Msg: 輸入公開(kāi)參數(shù)、密文、用戶屬性密鑰, 若是用戶屬性匹配c中的解密策略, 則可以成功解密, 返回明文Msg.

3 系統(tǒng)模型

3.1 系統(tǒng)設(shè)計(jì)目標(biāo)

(1) 數(shù)據(jù)安全. 病歷信息、就診記錄等醫(yī)療數(shù)據(jù)屬于隱私信息, 此信息的泄露會(huì)對(duì)患者的正常生活造成嚴(yán)重且不必要的影響[22]. 同時(shí), 醫(yī)療信息的篡改會(huì)誤導(dǎo)后續(xù)醫(yī)生的診斷, 耽誤患者的病情. 因此, 本系統(tǒng)需要將密碼學(xué)與區(qū)塊鏈技術(shù)相結(jié)合, 在保護(hù)患者隱私信息安全的同時(shí), 保證信息的不可篡改性.

(2) 高效的模糊查詢. 對(duì)于醫(yī)生來(lái)說(shuō), 患者的病史是診療過(guò)程中的一大利器, 醫(yī)生可以通過(guò)查閱診療記錄對(duì)患者的身體狀況有更加全面的了解, 以便于快速定位病因[23]. 因此, 本系統(tǒng)需要設(shè)計(jì)一種支持高效模糊查詢的算法, 通過(guò)此算法可以快速查詢到患者在不同科室的診療記錄.

(3) 細(xì)粒度的訪問(wèn)控制. 需要在隱私數(shù)據(jù)流轉(zhuǎn)的關(guān)鍵流程處設(shè)置密碼學(xué)保護(hù), 確保數(shù)據(jù)的正確流向,實(shí)現(xiàn)細(xì)粒度的訪問(wèn)控制.

3.2 系統(tǒng)模型

本文提出了一種基于區(qū)塊鏈的EHR 共享方案. 醫(yī)生會(huì)基于患者的密鑰對(duì)其相關(guān)的診療數(shù)據(jù)進(jìn)行SHVE 算法的加密操作, 并采用CP-ABE 算法設(shè)置訪問(wèn)控制, 隨后上傳密文至醫(yī)院數(shù)據(jù)中心, 同時(shí)上傳存儲(chǔ)憑證與訪問(wèn)控制信息至Fabric 聯(lián)盟鏈網(wǎng)絡(luò). 在需要查閱病歷的時(shí)候, 醫(yī)生會(huì)向Fabric 聯(lián)盟鏈網(wǎng)絡(luò)發(fā)送訪問(wèn)控制申請(qǐng), 待CP-ABE 的算法驗(yàn)證成功后便會(huì)生成并發(fā)送查詢令牌至醫(yī)院數(shù)據(jù)中心, 數(shù)據(jù)中心負(fù)責(zé)完成密文的查詢匹配, 最終返回相應(yīng)的結(jié)果. 系統(tǒng)架構(gòu)如圖2—3 所示, 圖2 展示的是患者在同一家醫(yī)院轉(zhuǎn)診的架構(gòu)圖, 圖3 展示的是患者進(jìn)行跨院轉(zhuǎn)診的架構(gòu)圖, 時(shí)序如圖4 所示. 系統(tǒng)中包含5 種主要角色, 分別為:

圖2 院內(nèi)Figure 2 In-hospital

圖3 跨院Figure 3 Cross-hospital

圖4 系統(tǒng)時(shí)序圖Figure 4 System timing diagram

(1) 患者: 負(fù)責(zé)提供加密、解密過(guò)程中的密鑰.

(2) 密鑰管理中心(key management center, KMC): 負(fù)責(zé)全局參數(shù)的生成, 負(fù)責(zé)流程中全部密鑰的生成與分發(fā).

(3) 醫(yī)生: 負(fù)責(zé)診療數(shù)據(jù)的生成、加解密, 負(fù)責(zé)查詢令牌的生成, 負(fù)責(zé)CP-ABE 的加密操作.

(4) 區(qū)塊鏈: 負(fù)責(zé)診療數(shù)據(jù)摘要的存儲(chǔ), 負(fù)責(zé)CP-ABE 的驗(yàn)證與解密.

(5) 醫(yī)院數(shù)據(jù)中心: 負(fù)責(zé)診療數(shù)據(jù)密文的存儲(chǔ)與查詢匹配.

3.3 攻擊模型

在本文的框架中, 患者被認(rèn)為是完全誠(chéng)實(shí)的, 其行為均不會(huì)對(duì)整個(gè)系統(tǒng)產(chǎn)生危害. 區(qū)塊鏈上的信息是經(jīng)共識(shí)節(jié)點(diǎn)驗(yàn)證的, 因此也完全可信. 醫(yī)生被認(rèn)為是半誠(chéng)實(shí)的, 這意味著他們?cè)趯?duì)患者的診療過(guò)程期間會(huì)嚴(yán)格保持誠(chéng)實(shí), 而在診療結(jié)束后, 其可能會(huì)對(duì)患者的診療數(shù)據(jù)感興趣, 并利用自己的屬性生成屬性密鑰以通過(guò)CP-ABE 的驗(yàn)證, 獲得區(qū)塊鏈上的存儲(chǔ)憑證, 以及存儲(chǔ)在醫(yī)院數(shù)據(jù)中心的完整診療記錄密文, 對(duì)于密文診療記錄, 其可能會(huì)采用暴力破解等方式破譯密碼. 醫(yī)院數(shù)據(jù)中心與公共網(wǎng)絡(luò)環(huán)境被認(rèn)為是完全不誠(chéng)實(shí)的, 醫(yī)院數(shù)據(jù)中心有可能擅自對(duì)加密的診療信息進(jìn)行修改. 此外, 由于本方案涉及到跨院的流程, 此流程中查詢令牌、診療數(shù)據(jù)等信息需要經(jīng)過(guò)公網(wǎng)進(jìn)行院際傳輸, 而公網(wǎng)環(huán)境對(duì)于數(shù)據(jù)傳輸有著較高的泄露風(fēng)險(xiǎn).

4 系統(tǒng)詳細(xì)設(shè)計(jì)

?

4.1 系統(tǒng)初始化

(3) 訪問(wèn)控制初始化. KMC 使用給定的安全參數(shù)β通過(guò)ABE.Setup(β) 生成主密鑰A_msk 與公開(kāi)參數(shù)A_PK. 對(duì)于每一個(gè)醫(yī)生Di, KMC 根據(jù)其發(fā)來(lái)的屬性Att_Di(見(jiàn)表2), 通過(guò)ABE.keyGen(A_msk,Att_Di) 方法生成屬性私鑰在我國(guó)醫(yī)療體系中, 醫(yī)生職稱(chēng)分為住院醫(yī)師、主治醫(yī)師、副主任醫(yī)師以及主任醫(yī)師, 醫(yī)院等級(jí)分為一、二、三級(jí), 每級(jí)又分為甲、乙、丙三等, 其中三級(jí)醫(yī)院增設(shè)特等. 本方案對(duì)這兩個(gè)屬性均按照由低至高的順序(醫(yī)生為住院醫(yī)師至主任醫(yī)師, 醫(yī)院為一級(jí)丙等至三級(jí)特等) 分別編號(hào)為1 至4 和5 至14.

表2 屬性定義Table 2 Definition of attribution

4.2 患者就診

4.2.1 患者注冊(cè)、就診

患者Pi首次在醫(yī)院H1就診,H1會(huì)要求Pi辦理就診卡, 卡內(nèi)包含Pi的密鑰對(duì)(Pk1i ,Pk2i ,Pki)、身份證號(hào)ID_Pi等數(shù)據(jù). 隨后Pi掛號(hào)至相應(yīng)科室醫(yī)生D1處就診,D1通過(guò)刷就診卡就會(huì)得知Pi的相關(guān)信息.

診療結(jié)束后,D1生成診療記錄Msgi, 其內(nèi)容如表3 所示. 依照北京協(xié)和醫(yī)院(三級(jí)甲等醫(yī)院) 官網(wǎng),可供患者掛號(hào)就診的共計(jì)有37 個(gè)科室, 因此本方案將Tid設(shè)計(jì)為37 位的{0, 1} 序列, 每一位代表一個(gè)科室. 在某一科室就診時(shí), 序列里對(duì)應(yīng)的位置值就為1, 其余為0.

表3 Msgi 內(nèi)容Table 3 Contents of Msgi

4.2.2 數(shù)據(jù)處理

(2) 對(duì)ID_Pi進(jìn)行切分, 按照長(zhǎng)度分為“6-8-4” 三個(gè)部分. 例如患者Pi的ID_Pi為“32030119 900101999X”, 可切分為“320301”, “19900101”, “999X” 三部分. 前兩個(gè)部分依照十進(jìn)制轉(zhuǎn)換為二進(jìn)制生成20+25 位共計(jì)45 位的{0, 1} 序列, 最后一部分按照十六進(jìn)制(尾號(hào)X 視作A) 轉(zhuǎn)換為二進(jìn)制生成16 位{0, 1} 序列. 因此, 患者Pi的身份證號(hào)可轉(zhuǎn)換為61 位{0, 1} 序列:

(3) 將Tid連接在上步生成的{0, 1} 序列后, 可得到最終的就診信息序列PIDi. 假設(shè)Pi此次在眼科就診, 而此科室的序列位置是第2 位, 所以Pi的PIDi為:

4.2.3 數(shù)據(jù)加密

算法1 加密算法Input: kHid, PIDi, Pk2 i , Msgi Output: SHVE 加密的密文CPi 1 醫(yī)生端隨機(jī)生成空間為{0,1}λ 的密鑰K, 并隨機(jī)生成98 個(gè)長(zhǎng)度同于K 的串: K1 至K98, 使得K = K1 ⊕K2 ⊕···⊕K98;2 定義n ∈[1,98];3 計(jì)算c0n = F0(kHid,(PIDi)n||n)⊕Kn, c1n = F0(kHid,*||n)⊕Kn;4 選取隨機(jī)數(shù)Msgi_r ∈{0,1}λ, 計(jì)算EK_Pi = H0(Pk2 i ||Msgi_r), 以及c = AES.enc(K,AES.enc(EK_Pi,Msgi));5 得到密文CPi =({c0n,c1n},c).

算法1 中采用雙重對(duì)稱(chēng)加密的目的在于提高安全性, 這樣即使在后續(xù)的查詢操作中匹配成功, 沒(méi)有密鑰信息, 也無(wú)法查看明文數(shù)據(jù).

4.2.4 訪問(wèn)權(quán)限設(shè)置

從冰箱取出一支保存的黑曲霉試管斜面，在超凈工作臺(tái)中加入無(wú)菌水，使無(wú)菌水剛好沒(méi)過(guò)斜面上的全部黑曲霉，然后用接種環(huán)把黑曲霉從斜面上輕輕刮下來(lái)，制成黑曲霉孢子懸液。

就診結(jié)束后, 系統(tǒng)會(huì)采用CP-ABE 算法設(shè)置訪問(wèn)控制, 本方案的訪問(wèn)策略Pi_Policy 為:

(1) 對(duì)于D_Title, 若新就診醫(yī)院的H_Title 較原醫(yī)院的高, 則允許低一級(jí)編號(hào)的醫(yī)生查看之前存儲(chǔ)的信息, 例如13 級(jí)醫(yī)院(三級(jí)甲等) 3 級(jí)的醫(yī)生(副主任醫(yī)師) 可查看12 級(jí)醫(yī)院(三級(jí)乙等) 4 級(jí)的醫(yī)生(主任醫(yī)師) 存儲(chǔ)的信息. 其余情況下, 高編號(hào)等級(jí)可以查看低編號(hào)等級(jí)醫(yī)生存儲(chǔ)的信息,反之不可;

(2) 對(duì)于H_Title, 就診信息只可同等級(jí)或更高等級(jí)的醫(yī)院才可查看.

系統(tǒng)對(duì)算法1 中的隨機(jī)數(shù)Msgi_r在策略Pi_Policy 下, 使用CP-ABE 的公開(kāi)參數(shù)A_PK 進(jìn)行加密, 得到訪問(wèn)控制密文AC_Cipher←ABE.enc(A_PK,Msgi_r,Pi_Policy).

4.2.5 信息存儲(chǔ)、上鏈

(1) 將經(jīng)過(guò)SHVE 加密后的密文CPi存入數(shù)據(jù)中心中;

(2) 計(jì)算出H0(Hid||K) 以及H0(Msgi), 并將(Pk1i ,H0(Hid||K),H0(Msgi),AC_Cipher)存入到區(qū)塊鏈中用作憑證.

4.3 轉(zhuǎn)診/再就診

假設(shè)患者Pi重新到醫(yī)生D2處就診,D2為了獲取Pi之前的診療記錄, 會(huì)通過(guò)刷Pi的就診卡獲得相關(guān)數(shù)據(jù), 并進(jìn)行如下操作.

4.3.1 訪問(wèn)權(quán)限申請(qǐng)

(3)D2選擇想要查看的Pi之前就診過(guò)的科室, 不選擇的話默認(rèn)本科室, 并在科室序列中將對(duì)應(yīng)的位置設(shè)為“*”, 最后將科室序列連接在上述步驟(2) 的身份序列后. 假設(shè)D2想要查看眼科和內(nèi)科的就診記錄, 而這兩個(gè)科室的序列位置為第2 位和第5 位, 因此最后得到的查詢序列sPIDi如下. 使用此方法可以選擇多個(gè)科室進(jìn)行查詢, 從而實(shí)現(xiàn)了支持多選的模糊查詢功能.

4.3.3 查詢令牌生成

算法2 令牌生成算法Input: k′Hid, sPIDi Output: SHVE 生成的查詢令牌TKHid 1 定義n ∈[1,98];2 計(jì)算dn = F0(k′)Hid,(sPIDi)n||n;3 計(jì)算bn =■■ ■1, (sPIDi)n = *0, otherwise ;4 得到查詢令牌TKHid = ((d1,b1),··· ,(d98,b98)).

4.3.4 查詢匹配

D2將算法2 生成的查詢令牌TKHid發(fā)送至數(shù)據(jù)中心, 數(shù)據(jù)中心接收后進(jìn)行查詢匹配操作.

算法3 查詢匹配算法Input: CPi, TKHid Output: AES.enc(EK_Pi,Msgi)/⊥1 計(jì)算K* = (cb11 ⊕d1)⊕(cb22 ⊕d2)⊕···⊕(cb9898 ⊕d98);2 計(jì)算H0(Hid||K*), 并檢查H0(Hid||K*) = H0(Hid||K) 是否成立, 成立則進(jìn)行下一步, 否則返回⊥;3 使用K* 解密CPi 中c 的首層加密, 并返回AES.enc(EK_Pi,Msgi).

4.3.5 安全傳輸(跨院轉(zhuǎn)診附加流程)

假設(shè)D2與D1隸屬于不同的醫(yī)院, 上述4.3.3 與4.3.4 節(jié)的流程則需要在兩個(gè)醫(yī)院之間跨院進(jìn)行. 針對(duì)此情形, 本文提出的方案是在數(shù)據(jù)跨院發(fā)送前, 使用接收方的公鑰對(duì)數(shù)據(jù)進(jìn)行加密, 同時(shí)使用發(fā)送方的私鑰進(jìn)行簽名, 接收方在收到數(shù)據(jù)時(shí)可使用發(fā)送方的公鑰進(jìn)行簽名驗(yàn)證, 驗(yàn)簽無(wú)誤后便可使用自己的私鑰進(jìn)行解密.

4.3.6 數(shù)據(jù)解密

算法3 返回二重對(duì)稱(chēng)加密數(shù)據(jù)的第一層解密結(jié)果, 即AES.enc(EK_Pi,Msgi), 隨后便可使用患者的密鑰Pk2i以及4.3.1 節(jié)流程中得到的隨機(jī)數(shù)Msgi_r生成EK_Pi=H0(Pk2i||Msgi_r), 并進(jìn)行第二重解密, 恢復(fù)之前的診療記錄明文Msgi. 得到明文后計(jì)算H0(Msgi), 并與區(qū)塊鏈上存儲(chǔ)的H0(Msgi) 進(jìn)行比對(duì), 若成功, 則表明數(shù)據(jù)無(wú)誤, 即可開(kāi)始本次的診療.

5 安全性與隱私性分析

本系統(tǒng)在SHVE 算法與CP-ABE 算法的基礎(chǔ)上, 結(jié)合區(qū)塊鏈技術(shù)實(shí)現(xiàn)了電子病歷的模糊查詢、訪問(wèn)控制以及共享功能, SHVE 算法與CP-ABE 算法的安全性已分別在文獻(xiàn)[16] 與文獻(xiàn)[21] 中加以證明.

診療數(shù)據(jù)在上傳前會(huì)經(jīng)過(guò)SHVE 算法的加密處理(4.2.3 節(jié)流程), SHVE 對(duì)數(shù)據(jù)的加密算法本質(zhì)上為二重AES 對(duì)稱(chēng)加密算法, 內(nèi)外層的密鑰不相關(guān), 無(wú)法相互推導(dǎo), 其中內(nèi)層的密鑰與患者的私鑰、隨機(jī)生成數(shù)相關(guān)聯(lián), 只有同時(shí)擁有這兩種數(shù)據(jù)才能還原診療數(shù)據(jù)的明文. 隨機(jī)生成數(shù)會(huì)被CP-ABE 算法加密(4.2.4 節(jié)流程), 只有當(dāng)數(shù)據(jù)訪問(wèn)者的屬性符合系統(tǒng)設(shè)置的屬性時(shí), 才能解密得到隨機(jī)數(shù), 但是只有隨機(jī)數(shù),沒(méi)有患者的密鑰, 也無(wú)法解密內(nèi)層密文. 此外AES 算法多達(dá)上百位的密鑰也極大降低了密文被暴力破解的可能性. 上述舉措降低了數(shù)據(jù)泄露的風(fēng)險(xiǎn), 提高了數(shù)據(jù)的安全性.

存儲(chǔ)數(shù)據(jù)時(shí)(4.2.5 節(jié)流程), 診療數(shù)據(jù)的密文會(huì)被存至醫(yī)院數(shù)據(jù)中心, 然而數(shù)據(jù)中心存在著被攻擊的風(fēng)險(xiǎn), 因此存入的密文數(shù)據(jù)不包含患者的隱私信息, 攻擊者無(wú)法從這些數(shù)據(jù)中挖掘、分析出患者的敏感信息, 數(shù)據(jù)的隱私性得到了保證. 診療數(shù)據(jù)的哈希摘要被上傳存儲(chǔ)在區(qū)塊鏈中, 區(qū)塊鏈自身的數(shù)據(jù)結(jié)構(gòu)保證了數(shù)據(jù)無(wú)法被篡改的同時(shí), 也保證了其不可抵賴性. 當(dāng)攻擊者攻擊存儲(chǔ)服務(wù)器, 企圖修改數(shù)據(jù)時(shí), 任何微小的改動(dòng)都會(huì)改變?cè)\療數(shù)據(jù)的哈希摘要, 這將會(huì)導(dǎo)致數(shù)據(jù)解密(4.3.6 節(jié)流程) 中的比對(duì)失敗. 如果攻擊者企圖修改區(qū)塊鏈中的數(shù)據(jù), 就必須獲得全網(wǎng)半數(shù)以上的算力(稱(chēng)為“51% 攻擊”[24]), 此舉代價(jià)極大, 且目前實(shí)現(xiàn)較難. 此外, Fabric 聯(lián)盟鏈的通道技術(shù)、隱私數(shù)據(jù)技術(shù)也提供了較好的隱私保護(hù), 攻擊者無(wú)法通過(guò)區(qū)塊鏈中的數(shù)據(jù)反推出患者的真實(shí)身份.

在查詢匹配數(shù)據(jù)時(shí)(4.3.2—4.3.4 節(jié)流程), 本系統(tǒng)會(huì)使用SHVE 算法加密查詢索引, 生成查詢令牌, 并進(jìn)行查詢匹配. 在此過(guò)程中, 患者本人的敏感數(shù)據(jù)不會(huì)暴露, 查詢成功后返回的均為加密數(shù)據(jù), 數(shù)據(jù)的安全、隱私得到了保障.

綜上, 本系統(tǒng)在每個(gè)可能出現(xiàn)數(shù)據(jù)泄露、數(shù)據(jù)隱私暴露的環(huán)節(jié)均進(jìn)行了相應(yīng)的防范, 并做出了對(duì)應(yīng)的保護(hù)措施, 因此本系統(tǒng)是兼具安全性與隱私性的.

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

本節(jié)對(duì)本文提出的方案進(jìn)行數(shù)值模擬實(shí)驗(yàn). 實(shí)驗(yàn)采用Visual Studio Code (1.57.1) 作為開(kāi)發(fā)平臺(tái), 使用Golang (1.15.5) 和Java (11.0.9) 進(jìn)行開(kāi)發(fā), 在個(gè)人主機(jī)中基于Hyperledger Fabric 2.0 搭建聯(lián)盟鏈.實(shí)驗(yàn)運(yùn)行于虛擬機(jī)中, 實(shí)驗(yàn)平臺(tái)信息如表4 所示. 依據(jù)某二線城市三甲醫(yī)院的真實(shí)數(shù)據(jù), 該院日均就診患者1 萬(wàn)人次, 日均生成診療數(shù)據(jù)量14 GB, 可得人均生成診療數(shù)據(jù)量1.4 MB. 考慮到城市以及醫(yī)院等級(jí)的差異, 本實(shí)驗(yàn)測(cè)試4000—16 000 人次患者的相關(guān)數(shù)據(jù), 測(cè)試源數(shù)據(jù)大小為1.4 MB.

表4 實(shí)驗(yàn)平臺(tái)信息Table 4 Information of experimental platform

6.1 模糊查詢

本節(jié)對(duì)方案內(nèi)SHVE 算法的模糊查詢性能進(jìn)行測(cè)試. 圖5 展示了不同的科室數(shù)對(duì)診療記錄命中耗時(shí)的影響, 圖中n表示診療記錄的總個(gè)數(shù). 可以看出, 在診療記錄數(shù)固定的情況下, 隨著所選科室數(shù)的增加,查詢命中的耗時(shí)雖然一直在5—10 毫秒內(nèi)小范圍波動(dòng), 但其變化的趨勢(shì)呈現(xiàn)水平狀, 無(wú)明顯上升趨勢(shì), 表明了模糊查詢的耗時(shí)與所選擇的科室數(shù)無(wú)關(guān)聯(lián); 而在所選科室數(shù)固定的情況下, 隨著診療記錄數(shù)的增加, 查詢命中的耗時(shí)線性增加, 且增長(zhǎng)幅度較緩, 在診療記錄數(shù)分別為4000、6000、14 000 和16 000 份時(shí), 查詢的平均耗時(shí)為52.3 ms、78.6 ms、174.7 ms 和218 ms, 因此可知增速大概為130 ms/萬(wàn)份診療記錄數(shù), 此耗時(shí)增速處于較低的水平, 對(duì)于醫(yī)療行業(yè)而言是可以接受的.

圖6 展示了文獻(xiàn)[5] 所提方案與本方案在搜索階段的耗時(shí)對(duì)比結(jié)果, 圖中結(jié)果是在診療記錄數(shù)固定為10 000 份的前提下得出的. 從圖中可以看出, 在查詢科室數(shù)較少的時(shí)候, 兩者的耗時(shí)接近, 但隨著查詢科室數(shù)的增多, 對(duì)比方案的耗時(shí)呈現(xiàn)大幅度線性增長(zhǎng), 在查詢科室數(shù)達(dá)到最大值37 的時(shí)候, 對(duì)比方案的耗時(shí)上探到4.7 s 左右, 遠(yuǎn)超同等狀態(tài)下本文方案的耗時(shí). 究其原因, 類(lèi)似的方案因?yàn)椴恢С帜：ヅ洳樵? 所以需要發(fā)送多個(gè)查詢請(qǐng)求, 每個(gè)查詢請(qǐng)求又需要完成一次完整查詢流程, 因此耗時(shí)較高, 而本文方案支持模糊查詢, 只需要發(fā)送一次查詢請(qǐng)求就可以獲得多個(gè)數(shù)據(jù), 從而降低了查詢階段的整體耗時(shí).

圖6 模糊查詢耗時(shí)對(duì)比Figure 6 Comparison of fuzzy query time consumption

綜上所述, 本文方案中的模糊查詢算法有著較好的性能.

6.2 鏈下部分

本小節(jié)對(duì)方案內(nèi)的鏈下部分進(jìn)行測(cè)試, 主要包括病歷的加、解密流程. 由于本文方案的加、解密流程主要基于AES 對(duì)稱(chēng)加密算法設(shè)計(jì), 常見(jiàn)的AES 算法包括AES-128、AES-192 與AES-256, 為了確定哪一種算法更加適合本文方案, 本部分測(cè)試分別使用這3 種方案進(jìn)行本文中的加、解密操作, 測(cè)試數(shù)據(jù)大小為1.4 MB, 結(jié)果如圖7 和圖8 所示. 圖7 展示了3 種不同的方案在本文中的20 次加、解密實(shí)驗(yàn)結(jié)果, 從圖中可以看出, 3 種方案的加密耗時(shí)均遠(yuǎn)高于解密耗時(shí). 在加密流程中, 3 種方案的耗時(shí)接近, 均在40—50 ms 的區(qū)間內(nèi); 在解密流程中, 3 種方案的耗時(shí)同樣相近, 均未超過(guò)10 ms. 圖8 展示的是20 次取樣實(shí)驗(yàn)的平均值比對(duì)結(jié)果, 可以看出, 在分別進(jìn)行加、解密操作時(shí), 3 種方案的平均耗時(shí)幾乎沒(méi)有差距, 3 者的平均加密耗時(shí)為45 ms, 平均解密耗時(shí)為3.8 ms, 平均耗時(shí)誤差在1 ms 以內(nèi). 通過(guò)上述實(shí)驗(yàn)可以看出, 3 種不同的AES 方案在本文中的時(shí)間開(kāi)銷(xiāo)相近, 因此, 為了更好的系統(tǒng)安全性, 本文選取密鑰長(zhǎng)度更長(zhǎng)、加密輪數(shù)更多的AES-256 用于本文的加、解密流程.

圖7 20 次AES 取樣測(cè)試Figure 7 20 times sampling test of AES

圖8 AES 取樣測(cè)試平均值Figure 8 Average of AES sampling tests

接著對(duì)本文方案的魯棒性進(jìn)行測(cè)驗(yàn), 上述實(shí)驗(yàn)的測(cè)試數(shù)據(jù)大小1.4 MB 是某真實(shí)醫(yī)院的日診療數(shù)據(jù)量平均到每個(gè)患者的數(shù)據(jù)量, 是理想化的, 而在真實(shí)情況中, 由于患者的病癥不同以及診療數(shù)據(jù)類(lèi)型的多樣性, 患者個(gè)人產(chǎn)生的診療數(shù)據(jù)量是不固定的. 若是診療的過(guò)程中出現(xiàn)了非結(jié)構(gòu)化的檢驗(yàn)結(jié)果, 例如CT 片、X 光片等, 那么此患者就會(huì)產(chǎn)生十幾兆甚至幾十兆的數(shù)據(jù)量. 本部分測(cè)試的目的就在于研究較大的數(shù)據(jù)量對(duì)本系統(tǒng)產(chǎn)生的影響. 測(cè)試從1.4 MB 的數(shù)據(jù)量開(kāi)始, 逐漸增長(zhǎng)數(shù)據(jù)量至35 MB, 每次增長(zhǎng)后進(jìn)行20 次的取樣測(cè)試, 最終的結(jié)果為20 次測(cè)試的平均值, 實(shí)驗(yàn)結(jié)果如圖9 所示. 從結(jié)果圖中可以看出, 隨著數(shù)據(jù)量的不斷增加, 加、解密的操作耗時(shí)也以線性的方式增加, 在數(shù)據(jù)量為1.4 MB 時(shí), 系統(tǒng)加密的平均耗時(shí)為45 ms, 解密的平均耗時(shí)為3.8 ms, 在數(shù)據(jù)量為35 MB 時(shí), 系統(tǒng)加密的平均耗時(shí)為129 ms, 解密的平均耗時(shí)為83.6 ms, 由此可得, 加、解密的增速大概為2.5 ms/MB. 因此, 本方案在數(shù)據(jù)量不固定的情況下有較好的魯棒性.

圖9 魯棒性測(cè)試Figure 9 Test of robustness

最后進(jìn)行對(duì)比測(cè)試, 選取文獻(xiàn)[5]、文獻(xiàn)[25] 中的方案作為對(duì)比. 與上述的測(cè)試流程相同, 進(jìn)行20 次取樣測(cè)試, 最終的結(jié)果為20 次測(cè)試的平均值, 相關(guān)的實(shí)驗(yàn)結(jié)果如圖10 所示. 從圖中可以看出, 無(wú)論是加密還是解密, 本文方案的耗時(shí)均略低于文獻(xiàn)[5] 的方案, 且遠(yuǎn)低于文獻(xiàn)[25] 的方案. 在加密階段, 本文方案的平均耗時(shí)為45 ms, 文獻(xiàn)[5] 的方案平均耗時(shí)為51.97 ms, 而文獻(xiàn)[25] 的方案平均耗時(shí)上探至213.74 ms;在解密階段, 本文方案的平均耗時(shí)為3.8 ms, 文獻(xiàn)[5] 的方案平均耗時(shí)為7.83 ms, 而文獻(xiàn)[25] 的方案平均耗時(shí)大幅增長(zhǎng)至50.06 ms. 經(jīng)過(guò)分析, 由于文獻(xiàn)[25] 所提方案較其余方案使用了更多的雙線性配對(duì)操作, 根據(jù)本實(shí)驗(yàn)使用的基于Java 配對(duì)的密碼學(xué)庫(kù)(JPBC) 的基準(zhǔn)測(cè)試網(wǎng)頁(yè)[26], 雙線性配對(duì)操作耗時(shí)較其余操作耗時(shí)更高, 因此總體耗時(shí)數(shù)倍高于文獻(xiàn)[5] 所提方案與本方案.

圖10 方案對(duì)比測(cè)試Figure 10 Comparison of different solutions

綜上, 本文方案在鏈下部分有較好的性能.

6.3 鏈上部分

本小節(jié)對(duì)方案內(nèi)的鏈上部分進(jìn)行測(cè)試, 包括數(shù)據(jù)上鏈、鏈上查詢等流程. 本文在單機(jī)中基于Hyperledger Fabric 2.0 搭建聯(lián)盟鏈, 鏈中有10 個(gè)組織(醫(yī)院) 參與, 每個(gè)組織包含了1 個(gè)peer 節(jié)點(diǎn), 另外還有1 個(gè)排序節(jié)點(diǎn), 共計(jì)11 個(gè)節(jié)點(diǎn).

首先測(cè)試數(shù)據(jù)上鏈與鏈上查詢的性能. 為了保證鏈上數(shù)據(jù)的真實(shí)性與可信性, 對(duì)鏈上數(shù)據(jù)的操作需要經(jīng)過(guò)區(qū)塊鏈節(jié)點(diǎn)的共識(shí)操作, 這是保證區(qū)塊鏈系統(tǒng)在分布式架構(gòu)下數(shù)據(jù)正確可信的重要步驟. 通常情況下,共識(shí)需要區(qū)塊鏈網(wǎng)絡(luò)中半數(shù)以上的節(jié)點(diǎn)完成, 因此, 此部分測(cè)試不同的共識(shí)節(jié)點(diǎn)數(shù)對(duì)于系統(tǒng)效率的影響.

測(cè)試從6 個(gè)共識(shí)節(jié)點(diǎn)開(kāi)始, 依次增加共識(shí)節(jié)點(diǎn)數(shù)至10, 假定在極限情況下, 10 個(gè)組織(醫(yī)院) 的37個(gè)科室均有5 名醫(yī)生向區(qū)塊鏈發(fā)送交易, 即共有1850 條交易, 使用TAPE 測(cè)試工具[27]將這1850 條交易發(fā)送至Fabric 聯(lián)盟鏈網(wǎng)絡(luò), 并循環(huán)測(cè)試20 次數(shù)據(jù)上鏈與鏈上查詢的TPS (transactions per second,每秒處理的事務(wù)數(shù)), 最終的結(jié)果為20 次測(cè)試的平均值. 實(shí)驗(yàn)結(jié)果如圖11 所示, 由于測(cè)試中每個(gè)節(jié)點(diǎn)均以Docker 容器的形式啟動(dòng), 受制于實(shí)驗(yàn)機(jī)器的硬件資源, 單機(jī)同時(shí)啟動(dòng)全部節(jié)點(diǎn)消耗了大量資源, 導(dǎo)致虛擬機(jī)的性能下降, 故測(cè)試結(jié)果中的TPS 數(shù)值偏低, 甚至在全共識(shí)節(jié)點(diǎn)時(shí)TPS 驟降至28, 因此將共識(shí)節(jié)點(diǎn)數(shù)為6—9 的實(shí)驗(yàn)結(jié)果放大至圖12. 從結(jié)果可以看出, 數(shù)據(jù)上鏈與鏈上查詢的TPS 是非常接近的, 從數(shù)值可知其兩者誤差不超過(guò)1. 在共識(shí)節(jié)點(diǎn)增加的情況下, 交易的TPS 也在以線性的方式下降, 當(dāng)6 個(gè)節(jié)點(diǎn)進(jìn)行共識(shí)時(shí), 兩者TPS 均為64, 而在9 個(gè)節(jié)點(diǎn)進(jìn)行共識(shí)的情況下, 兩者的TPS 均降至49, 降速大概為5/共識(shí)節(jié)點(diǎn). 經(jīng)過(guò)分析, 推測(cè)下降的原因可能為: 節(jié)點(diǎn)的共識(shí)驗(yàn)證運(yùn)算量會(huì)隨著共識(shí)節(jié)點(diǎn)的增加而增加, 因此系統(tǒng)的效率也就隨之下降, 不過(guò)相信若使用更高性能的機(jī)器, 或采用多機(jī)形式部署區(qū)塊鏈網(wǎng)絡(luò), 其系統(tǒng)效率的下降速率會(huì)遠(yuǎn)低于本次實(shí)驗(yàn).

圖11 TPS 測(cè)試結(jié)果Figure 11 Results of TPS tests

圖12 TPS 測(cè)試結(jié)果部分放大圖Figure 12 Partial enlargement of TPS tests

最后測(cè)試鏈上CP-ABE 訪問(wèn)控制的部分, 通過(guò)上面的TPS 測(cè)試可以發(fā)現(xiàn), 在超過(guò)半數(shù)的情況下, 共識(shí)節(jié)點(diǎn)數(shù)與系統(tǒng)效率成反比, 因此, 此部分測(cè)試選取6 個(gè)節(jié)點(diǎn)用作共識(shí). 測(cè)試方法依舊為20 次的取樣測(cè)試, 最終的結(jié)果為20 次測(cè)試的平均值. 經(jīng)過(guò)測(cè)試, CP-ABE 的平均加密耗時(shí)為44.19 ms, 平均解密耗時(shí)為17.33 ms.

7 功能評(píng)估

本節(jié)采用對(duì)照分析的方法來(lái)評(píng)估本文提出的方案, 通過(guò)與表1 中的現(xiàn)有方案進(jìn)行對(duì)比, 分析本文方案的特點(diǎn), 評(píng)估結(jié)果如表5 所示, 表中“?” 表示支持, “×” 表示不支持. 表中從3 個(gè)維度將本文方案與現(xiàn)有研究成果進(jìn)行了對(duì)比, 可以看出本文方案在整體上具有一定的優(yōu)勢(shì), 但是同樣有許多弱點(diǎn)與需要改進(jìn)的地方, 例如訪問(wèn)控制未支持屬性撤銷(xiāo)等, 這將是本文方案后續(xù)研究的方向.

表5 本文方案與現(xiàn)有方案對(duì)比Table 5 Comparison of our solution with existing solutions

8 總結(jié)

針對(duì)電子病歷的數(shù)據(jù)安全以及共享問(wèn)題, 本文設(shè)計(jì)了一個(gè)基于區(qū)塊鏈技術(shù)的電子病歷共享系統(tǒng). 在數(shù)據(jù)存儲(chǔ)方面, 鏈上鏈下雙存儲(chǔ)的方案減輕了區(qū)塊鏈的存儲(chǔ)壓力, 并且所存數(shù)據(jù)均經(jīng)過(guò)密碼學(xué)技術(shù)處理, 安全性得到了保障. 在數(shù)據(jù)查詢方面, 首先智能合約會(huì)進(jìn)行訪問(wèn)權(quán)限的篩選, 控制數(shù)據(jù)的流向; 其次基于查詢算法的特性, 實(shí)現(xiàn)了較為高效的模糊查詢功能. 在數(shù)據(jù)共享方面, 統(tǒng)一的數(shù)據(jù)格式以及區(qū)塊鏈技術(shù)的采用方便了電子病歷在醫(yī)院之間的流通. 綜合對(duì)原型系統(tǒng)的測(cè)試與分析, 本系統(tǒng)具備可行性與實(shí)用性.