在“歪評”區(qū)塊鏈之后，前IBM認知醫(yī)療研究總監(jiān)、平安科技首席醫(yī)療科學家謝國彤回歸本行，聚焦MIT基于區(qū)塊鏈的電子病歷共享系統(tǒng)MedRec，從Linked Data角度思考區(qū)塊鏈的醫(yī)療行業(yè)應用。

自從今年3月份寫完《最具娛樂精神的區(qū)塊鏈科普》以后，一直沒有寫下篇。最近看了MIT Media Lab做的MedRec，一個基于區(qū)塊鏈的電子病歷共享系統(tǒng)，有點兒感想，分享一下。

萬維網(wǎng)和Linked Data

每當聽到有人說要把醫(yī)療數(shù)據(jù)放到區(qū)塊鏈上的時候，我的第一個問題都是：什么信息應該放到鏈上？什么不應該放到鏈上？在區(qū)塊鏈誕生的“比特幣”場景下，鏈上記錄的是比特幣交易信息，這類金融信息的特點是交易頻次高，但結構簡單，每次交易的數(shù)據(jù)量小。

電子病歷數(shù)據(jù)卻不太一樣。相比金融交易系統(tǒng)，電子病歷的頻次要低很多。在這個“買買買”的時代，一個人可以在一天內(nèi)輕輕松松掃20次以上的支付寶或微信支付，但他/她一年也不見得會有20次電子病歷數(shù)據(jù)交易?？墒菃未坞娮硬v數(shù)據(jù)卻相當復雜度，一個患者一次就診就可以產(chǎn)生掛號信息、病歷信息、檢驗單、檢查結果、醫(yī)學影像、入院記錄、手術記錄、護理記錄和出院小結等結構復雜、模態(tài)多樣的電子病歷數(shù)據(jù)。

這時問題就來了：難道我們要把這些數(shù)據(jù)都放到鏈上嗎？把這些數(shù)據(jù)在區(qū)塊鏈的每個節(jié)點上都復制一遍？這看起來不像個好主意。

類似的跨系統(tǒng)、多模態(tài)復雜數(shù)據(jù)的共享平臺其實我們每天都在用，就是萬維網(wǎng)（World Wide Web）。當你刷著淘寶追著劇，同時不停在微信上積贊換購物紅包，或者在微博上點評劇中男/女主的時候，你已經(jīng)在多個復雜的異構系統(tǒng)中進行了信息訪問和共享。只不過這個信息共享系統(tǒng)的設計實在太優(yōu)美，簡潔直觀，以至于你都沒有意識到自己做了這么復雜的事情。

這個優(yōu)美系統(tǒng)的設計者就是Tim Berners-Lee（TBL），他在1990年圣誕節(jié)實現(xiàn)了第一次HTTP通訊，并于2016年因為這個偉大的設計獲得了圖靈獎。

Tim Berners-Lee因為發(fā)明了萬維網(wǎng)獲得了2016年的圖靈獎

在完成萬維網(wǎng)的設計后，TBL在2006年提出了Web 2.0的概念，Linked Data。顧名思義，就是把數(shù)據(jù)，而不是網(wǎng)頁，通過鏈接關聯(lián)起來；讓程序，而不是人，可以在數(shù)據(jù)的海洋中沖浪。

這個希望在Web之上構建一個分布式結構化數(shù)據(jù)共享平臺的想法遠遠沒有Web成功，但它的一些設計指導原則在基于區(qū)塊鏈的電子病歷共享系統(tǒng)方面其實很有借鑒意義。

Linked Data有四個設計原則：

用URI（Uniform Resource Identifier）標識所有的數(shù)據(jù)資源

用戶可以通過HTTP協(xié)議訪問URI

當URI被訪問時，返回一些基于標準的有用信息

在URI之間建立鏈接，這樣用戶可以發(fā)現(xiàn)更多的信息

基于區(qū)塊鏈的電子病歷共享系統(tǒng)設計

參考Linked Data的四大設計原則，會發(fā)現(xiàn)在基于區(qū)塊鏈的電子病歷共享系統(tǒng)設計中，有一些基本的問題要思考：

什么是數(shù)據(jù)資源？在Web時代，最基本的數(shù)據(jù)資源是一個網(wǎng)頁、一張圖片或者一段視頻。在電子病歷共享系統(tǒng)中的資源是什么？一個患者，一個醫(yī)療機構，一次就診，一次就診中產(chǎn)生的一個臨床文檔？

用什么做數(shù)據(jù)資源的URI？用什么協(xié)議訪問這個URI？這里應該用區(qū)塊鏈的程序訪問協(xié)議來代替HTTP。

當用戶訪問某個URI的時候，應該由誰返回信息？返回什么信息？是由區(qū)塊鏈的分布式賬本，還是每個醫(yī)療機構的本地服務器來返回信息？是返回患者的就診列表，還是患者的電子病歷數(shù)據(jù)集？返回的信息格式應該如何設計才能更好的支持互操作性（Interoperability）。

URI之間有什么樣的語義鏈接？如何讓程序可以在通過鏈接在數(shù)據(jù)的海洋中穿梭遨游？

看完MedRec的系統(tǒng)設計，雖然它并沒有提Linked Data，不過我覺得它無意中遵循了一些LInked Data的設計原則。想想也不奇怪，畢竟MedRec也是在解決分布式異構數(shù)據(jù)共享問題，只不過從Web平臺換到了區(qū)塊鏈平臺上。

MedRec的智能合約設計

MedRec采用智能合約（Smart Contract）來表示區(qū)塊鏈上的患者、醫(yī)療機構、病歷信息指針和患者-機構之間的就診關系，這屬于電子病歷的元數(shù)據(jù)（metadata），而真正的數(shù)據(jù)依然存儲在每個醫(yī)療機構本地的數(shù)據(jù)庫中。

從智能合約中可以找到醫(yī)療機構本地數(shù)據(jù)庫的指針，然后程序通過這個指針可以查詢到最終的數(shù)據(jù)。類似你從谷歌和百度的搜索結果頁面中找到Web鏈接，然后再通過鏈接訪問包含原始數(shù)據(jù)的網(wǎng)站，獲取鏈接內(nèi)容。它主要包含三個合約：

管理合約（Registrar Contract）：它承擔了資源定義的工作。目前MedRec里只有兩類資源：患者（Patient）和醫(yī)療機構（Provider）。每個資源定義了唯一的URI：Eth addr（Ethereum address），是這個資源在Ethereum區(qū)塊鏈平臺上唯一的地址，類似一個RDFResource的集合。

摘要合約（Summary Contract）：以每個資源（患者或醫(yī)療機構）為索引，把這個資源相關的所有數(shù)據(jù)（關系）都整合起來。這樣從一個資源的URI出發(fā)，就可以找到所有跟它有關的數(shù)據(jù)。類似一個RDFGraph，記錄了所有以某個RDFResource為subject的RDFStatement的集合。

醫(yī)患關系合約（Patient Provider Relationship）：它表示的是兩類URI（患者和醫(yī)生）之間的語義關系：就診，類似一個RDFStatement。但它還要表示很多其他信息，所以采用了類似屬性圖（Property Graph）的方法，在二元關系上附加了很多屬性，比如：

Access info：包含實際存儲了原始電子病歷數(shù)據(jù)的醫(yī)療機構的本地數(shù)據(jù)庫訪問信息，如IP地址，數(shù)據(jù)庫用戶名等；

EMR queries & hashes：在醫(yī)療機構本地數(shù)據(jù)庫中查詢某個患者電子病歷信息的SQL語句，還有電子病歷信息的哈希值。這樣如果數(shù)據(jù)上傳區(qū)塊鏈之后，醫(yī)療機構又對本地電子病歷數(shù)據(jù)進行了修改，通過哈希值是可以發(fā)現(xiàn)的，這體現(xiàn)了區(qū)塊鏈的不可篡改性和可溯源性；

Permission：它是個哈希表，記錄了第三方訪問者可以調(diào)用哪些額外的SQL查詢，類似rdfs:seeAlso的設計，告訴訪問者還有哪些有意思的信息可以“順便”看看；

Mining Bounties：非常區(qū)塊鏈風格的賞金設計，很有趣。為了激勵區(qū)塊鏈上的礦工們（Miner）參與平臺的計算，當包含這個電子病歷數(shù)據(jù)更新的block（塊）被挖到的時候，礦工自動會得到訪問這個賞金（bounty）查詢的權限。賞金查詢主要是針對人群的一些統(tǒng)計信息，比如“最近一個月來醫(yī)院A就診的糖尿病患者的血糖均值”，不會泄漏患者的個人信息，所以也不需要患者的授權。

MedRec的智能合約基本還是從數(shù)據(jù)庫設計的角度出發(fā)，考慮的是如何簡潔高效地把數(shù)據(jù)的關系表示清楚，但它無意中遵循了一些Linked Data對數(shù)據(jù)建模的原則。如果一開始就從Linked Data的設計原則（而不是具體的RDF語法或者W3C標準）出發(fā)，這個智能合約的結構應該還可以優(yōu)化。

另外，請各位RDF（Resource Description Framework）大神不要追究我對RDFStatement，RDFResource，RDFGraph或者Reification等概念的語義內(nèi)涵或外延不嚴謹?shù)年愂?，這里只是示意而已。

MedRec的系統(tǒng)實現(xiàn)

我覺得MedRec最核心的是智能合約設計，至于系統(tǒng)的實現(xiàn)會因為底層區(qū)塊鏈平臺的不同選擇（Ethereum或HyperLedger或其它平臺），或者架構師對工程美學的不同理解而千差萬別。

出于完整性的角度，我也非常簡單地介紹一下MedRec的系統(tǒng)實現(xiàn)。

MedRec設計了4個模塊，通過9個步驟完成資源的注冊、病歷信息的上鏈更新、患者授權和病歷信息查詢等關鍵過程：

Backend API Library：主要是一些utility功能，簡化系統(tǒng)操作的AP;

Ethereum Client：參與和使用Ethereum區(qū)塊鏈平臺的客戶端模塊；

Database Gatekeeper：在區(qū)塊鏈下訪問醫(yī)療機構本地數(shù)據(jù)庫的模塊I；

EHR Manager：MedRec系統(tǒng)對終端用戶的前端用戶界面

MedRec可以改進的方面

MedRec比很多隨便在HyperLedger上搭的所謂區(qū)塊鏈電子病歷共享系統(tǒng)的質(zhì)量高很多，不愧是MIT Media Lab出品。不過它依然只是個原型系統(tǒng)，還有很多方面可以提高，我拋幾塊磚：

智能合約的設計：Web是目前最成功的異構多模態(tài)數(shù)據(jù)訪問和共享架構，Linked Data是Web向結構化數(shù)據(jù)共享邁進的一步，它的很多設計原則可以應用在基于區(qū)塊鏈的電子病歷共享系統(tǒng)中，讓資源的表示和訪問模式更加簡潔優(yōu)美，提高系統(tǒng)的可擴展性和魯棒性

避免單點失敗：目前真正的電子病歷數(shù)據(jù)還是存儲在醫(yī)療機構本地的數(shù)據(jù)庫中。Web系統(tǒng)設計的初衷就是為了支持大規(guī)模多用戶訪問的，而醫(yī)療機構的數(shù)據(jù)庫不是為這個目標設計的，它只是為了支持醫(yī)院自身的流程管理和分析應用而已。一旦醫(yī)療機構的數(shù)據(jù)庫不能被訪問，就像微博宕機一樣，什么數(shù)據(jù)都訪問不了。目前MedRec去中央數(shù)據(jù)庫的設計并不能避免單點失敗的尷尬，也許可以參考Hadoop的思想，在區(qū)塊鏈平臺的另外2-3個可信賴的節(jié)點中保存數(shù)據(jù)的備份，保證即使某個醫(yī)療機構的數(shù)據(jù)庫掛了，真?zhèn)€電子病歷共享系統(tǒng)依然不受影響

數(shù)據(jù)的互操作性：數(shù)據(jù)共享平臺輸出的數(shù)據(jù)格式要滿足互操作性的要求。簡單的說，就是要讓數(shù)據(jù)使用方能理解查詢到的數(shù)據(jù)，就像Web系統(tǒng)用HTML，Linked Data系統(tǒng)用RDF一樣。在醫(yī)療領域，除了數(shù)據(jù)格式的規(guī)范，還有醫(yī)療術語的語義互操作性。可以考慮目前比較流行的FHIR格式，加上SNOMED-CT這樣的醫(yī)療術語標準

分布式機器學習：目前MedRec只是個數(shù)據(jù)查詢系統(tǒng)，但并不支持跨醫(yī)療機構的數(shù)據(jù)分析，即使是最基本的統(tǒng)計?？梢钥紤]“加載”類似MapReduce的分布式計算框架，甚至是分布式機器學習框架，支持跨醫(yī)療機構的分布式數(shù)據(jù)分析。