分布式家庭醫生服務系統與區塊鏈電子病歷*

吳 飛 張 莉 夏倫騰

(1中南民族大學生物醫學工程學院 武漢 430074 2中南民族大學檢測與儀器校級工程中心 武漢430074)

1 引言

隨著“互聯網+醫療健康”發展提速，家庭醫生簽約成為重要一環。政府大力推行家庭醫生制以實現基層首診、分級治療目的，可有效緩解大型醫院看病難、看病貴問題[1-2]。現在大多數家庭醫生服務系統為傳統集中式系統，即由1臺或多臺主計算機組成中心節點集中存儲數據，且整個系統所有業務單元集中部署于該中心節點上。集中式系統具較明顯缺點：一是中央計算機需要執行所有運算，當終端較多時會導致響應速度變慢。二是如果終端用戶有不同需求，需針對每個用戶程序和資源進行單獨配置，在集中式系統中進行該操作較困難且效率較低、靈活性差[3]。分布式系統是一個硬件或軟件組件分布在不同網絡計算機上，通過消息傳遞進行通信和協調的系統。本研究結合區塊鏈和傳統關系型數據庫開發新型電子病歷獨立部署在家庭醫生服務系統中。經測試成功部署分布式系統，區塊鏈電子病歷核心模塊成功通過黑盒測試。

2 系統設計

2.1 功能需求

本系統分為用戶端、醫生端和管理員端，見圖1。用戶端具有用戶注冊登錄、我的醫生、體檢預約、查看體檢報告、健康咨詢、查看健康檔案和區塊鏈跳轉等模塊；醫生端具有我的病人、醫生登錄、病人咨詢、查看病人檔案、預約設置和區塊鏈跳轉等模塊；管理端具有用戶管理、醫生管理、體檢設置、統計分析和區塊鏈瀏覽等模塊。

圖1 系統需求

2.2 體系架構

2.2.1 概述 本系統由區塊鏈網絡、后端客戶端和獨立前端3部分組成。采用瀏覽器/服務器(Browser/Server，B/S)架構[4]，整體架構為3層設計，主要由Web客戶端、Web服務端和數據庫3部分組成，見圖2。

圖2 系統架構

2.2.2 Web客戶端 以HTML5頁面形式展示在微信公眾號上。基于手機瀏覽器開發，相當于采用傳統B/S開發模式，將編寫的HTML5頁面根據手機尺寸進行調節，然后將頁面內嵌到應用程序中，例如通過微信公眾號訪問HTML5頁面。這種開發方式不需要針對不同手機系統分別進行開發，只需要開發一個版本就能在不同手機上正常訪問。

2.2.3 Web服務端 采用模型、視圖、控制器(Model View Controller,MVC)框架模式進行編寫[5]。第1層的模型層主要負責與數據庫交互，用來為視圖層和數據持久層準備數據并處理從視圖層以及數據持久層接收到的數據。第2層的視圖層負責顯示數據處理結果與狀態，從模型層獲得數據并展示給用戶，相當于提供頁面供用戶進行人機交互。第3層的控制器層用來控制應用程序和處理視圖所發出請求。當控制器接收到用戶請求后，將用戶數據和模型相映射，然后控制器會選擇用于響應的視圖把模型更新后的數據展示給用戶，即所謂的接、調、存、轉。

2.2.4 數據庫層 分為Mysql數據庫和區塊鏈兩部分。使用Fabric搭建區塊鏈網絡用來存儲用戶隱私數據。框架依靠實用拜占庭容錯算法(Practical Byzantine Fault Tolerance，PBFT)保證各節點數據的一致性，開發人員在使用框架進行開發的過程中可不必關注區塊鏈底層模塊構建，提高開發效率。

2.3 功能架構(圖3)

圖3 系統功能架構

Dubbo是Alibaba開源的分布式服務框架，其最大特點是按照分層方式進行架構，使各層之間解耦合。使用Dubbo抽取核心業務作為獨立服務，逐漸形成穩定服務中心，可用于提高業務復用靈活性，使前端應用更快速響應多變的市場需求。前后端開發人員協議規定交互數據字段，通過Ajax和JSON則可以實現。前后端分離設計模式可使系統實現高內聚低耦合，提高系統維護性。服務器端采用SSM框架設計，為用戶端提供健康評估服務、預約服務等接口，用戶端通過POST方式向服務器端發送請求。

3 分布式系統

3.1 優勢

3.1.1 高度可靠性 數據分散存儲在網絡中不同主機上，系統中存在數據冗余，當一臺機器發生故障時可使用另一臺主機的備份。

3.1.2 均衡負載 每臺主機可緩存本地最常用數據，不需要頻繁訪問服務器，減輕服務器負擔，減少網絡流量。服務器也可對任務進行分配和優化，突破幾種系統中央計算機資源緊張的瓶頸。

3.1.3 滿足不同需要 用戶可根據需要安裝不同操作系統、應用軟件以使用不同服務，解決集中式計算機系統受限于中央計算機功能問題。基于以上分析，家庭醫生服務系統采用面向服務 (Service-Oriented Architecture, SOA)分布式架構可解決模塊之間耦合度高、開發效率低、擴展性差、不能靈活進行分布式部署等問題[4]。

3.2 分布式服務框架

3.2.1 概述 當項目規模較小時使用簡化增刪改查工作量的數據訪問框架——對象關系映射(Object Relational Mapping，ORM)，達到減少部署節點和縮減成本的目的，但性能擴展困難。當規模逐漸變大單一應用架構無法滿足項目需求時，使用Web框架MVC，將應用拆分成數個獨立應用，提升效率，但公用模塊無法重復利用。當垂直應用越來越多，應用之間交互困難，簡單、垂直的應用架構無法滿足需求時，可使用分布式服務框架遠程過程調用(Remote Procedure Call， RPC)[6]。

3.2.2 分布式應用架構 Dubbo將遠程方法調用透明化，只需簡單配置，沒有任何應用程序接口(Application Programming Interface，API)侵入。軟負載均衡及其容錯機制可在內網替代F5等硬件負載均衡器，減少成本和單點。本系統中Dubbo采用Spring配置方式，透明化接入應用，無API侵入，Dubbo基于Spring的Schema擴展進行加載[7]。服務提供方稱為生產者(Provider)，調用遠程服務的消費方稱為消費者(Consumer)。用戶Web、商品Web、訂單Web都是生產者部署在A服務器上，用戶服務、商品服務、訂單服務則是消費者部署在B服務器上，見圖4。消費者可遠程調用生產者提供的服務。當服務不斷增多時消費者對生產者的調用關系越來越復雜，消費者調用服務時需了解由哪臺服務器提供，也就是IP(Internet Protocol)地址與服務名稱對應關系，需要注冊中心實現。本系統使用 Zookeeper注冊中心。Dubbo服務生產者在Zookeepper上創建一個臨時節點，暴露自己的IP和端口，消費者調用服務時在Zookeepper上找到服務生產者，通過IP和端口對服務進行調用。如果生產者宕機，Zookeepper可通過心跳機制檢測到宕機機器，將其IP和服務名稱對應關系從服務提供列表中刪除，以免消費者誤調用。

圖4 分布式應用架構

3.3 服務調用流程(圖5)

圖5 服務調用流程

本系統中將用戶管理Web、醫生管理Web、病歷管理Web、預約管理Web、健康咨詢管理Web作為生產者。當服務運行容器啟動時服務生產者隨之啟動，生產者啟動后在注冊中心(Zookeepper)進行注冊。服務消費者啟動時向注冊中心訂閱所需服務，注冊中心為其返回服務生產者地址列表，消費者從中調用所需服務。內存中的調用次數和時間統計后定時發送至監控中心。

3.4 服務調用測試

Dubbo管控臺可對注冊到Zookeepper注冊中心的服務或者服務消費者進行管理。通過管理平臺可清晰看到服務生產者的機器IP和狀態、服務消費者的機器IP和應用名等。服務生產者部署在容器apache-tomcat-7.0，端口20880，進入Dubbo管控臺可看到提供者信息。啟動服務消費者，進入Dubbo管控臺可看到服務消費者信息。生產者成功提供服務，消費者成功調用服務，Dubbo服務框架搭建成功。

4 區塊鏈電子病歷設計

4.1 電子病歷數據存儲方式

傳統在萬維網上運行的數據庫通常使用客戶端-服務器架構，權限用戶(客戶端)可更改存儲在中央服務器上的數據。依賴人為管理，如果訪問權限出現錯誤或管理員操作不當數據將有泄露風險。相對于傳統關系型數據庫，區塊鏈可視為一種去中心化分布式數據庫，區塊之間通過復雜的密碼學算法連接，數據記錄在每一個區塊上，每一個區塊通過計算前一區塊的哈希值、新交易區塊和隨機數得來，保證區塊唯一性[8]。當區塊足夠多時，如果想篡改其中一個區塊的數據，則需要對被篡改區塊之后的所有區塊重新進行密碼學證明，保證區塊鏈不可篡改性。每次數據改動都會通過數字簽名合法記錄在區塊鏈上[9]，即數據公開性和可溯源性。基上述優點區塊鏈成為醫療數據存儲的重要方式。傳統區塊鏈存儲方式是將患者所有數據存儲到區塊鏈上，將加大系統開支，吞吐量問題難以解決。同時猶豫區塊鏈性能對于患者隱私的保護，醫療數據分享成為難題[10]。為解決該問題，本系統將傳統關系性數據庫與區塊鏈結合，將患者個人信息與病歷詳細信息分開存儲[11]。

4.2 架構設計

4.2.1 電子病歷模塊 基于區塊鏈的電子病歷分為登錄、病歷生成、診治信息存儲以及查詢等模塊。電子病歷的區塊鏈網絡單獨存儲于整個家庭醫生服務系統中，設立單獨登錄模塊，患者通過就診卡ID(Identity document)登錄，沒有注冊模塊，見圖6。患者第1次登錄成功后會生成一對公私匙。

圖6 區塊鏈電子病歷模塊

4.2.2 病歷存儲 使用非對稱加密公匙加密用戶病歷上的個人隱私數據[12]，私匙加密病歷上的診療信息。將公匙保存到數據庫，私匙儲存在患者就診卡中，區塊鏈網絡根據患者公匙生成的地址創建患者數據，見圖7。由于已經將病歷上的個人信息和診治信息分離，且診治信息數據量大、操作頻繁，所以將診治信息數據存儲到Mysql數據庫中，解決數據所有權錯權問題并減小區塊鏈網絡吞吐量。患者病歷上的個人信息涉及個人隱私且操作不頻繁。患者的診治信息單獨擁有唯一主鍵ID，系統將患者的個人信息通過對稱加密后和數據庫中的診治信息主鍵ID加載到區塊鏈網絡中[13]，組成患者的電子病歷數據。區塊鏈中只有患者的診治信息主鍵ID而不包含個人信息，既保護了患者的隱私也減少了區塊鏈的吞吐量[14]。

圖7 區塊鏈網絡病歷存儲

4.2.3 病歷查詢 分為患者查詢和醫生查詢。由于診治信息數據保存在Mysql數據庫中，醫生查詢時可直接搜索公開的診治信息。患者就診時可使用就診卡ID進入查詢系統查詢病歷信息。系統使用私匙進行解密后通過診治信息的主鍵ID查詢數據庫中具體數據，整理后返回給患者，見圖8。

圖8 患者查詢病歷

4.2.4 病歷生成 醫生根據患者主訴請求填寫病歷信息，完成后提交給服務器，校驗成功后將數據上傳，提取患者信息同時創建診治信息數據摘要，使用患者私匙進行簽名，向區塊鏈發送更新患者病歷的請求，鏈代碼解析請求并且更新患者數據[15]，將病歷表上的診治信息主鍵ID和數據摘要信息更新到電子病歷中。

4.3 核心功能測試

對區塊鏈電子病歷的核心功能分成3部分進行測試，即用戶登錄、病歷生成和病歷查詢測試，每部分再分為數個測試單元，采用黑盒測試方法。測試結果，見表1。針對將病歷數據全部儲存到區塊鏈的傳統方式，通過區塊鏈與傳統關系型數據庫的有效結合，達到減小區塊鏈網絡吞吐量的目的，同時使診治信息數據與患者個人隱私分開，解決了所有權錯位問題，可更好地分享醫療數據。

表1 核心功能測試結果

5 結語

該分布式家庭醫生服務系統分別開發了用戶端、醫生端和管理端，既有傳統家庭醫生服務系統的簽約醫生、預約體檢、健康咨詢、健康檔案等功能，同時部署區塊鏈電子病歷。針對傳統集中式家庭醫生服務系統低耦合性、靈活性差等缺點，該系統采用分布式系統架構，將核心模塊分別部署在不同服務器上，解決應用耦合性高的問題，提高系統可靠性和開發效率，面對用戶需求變化系統后期更易擴展。區塊鏈與傳統數據庫的結合，一方面保護患者隱私，另一方面減少區塊鏈網絡壓力，同時解決醫療數據所有權錯權問題。經測試分布式系統被成功部署，區塊鏈電子病歷核心功能成功通過黑盒測試。該系統的開發為醫療機構、醫生和用戶提供聯系平臺，為“互聯網+醫療健康”增添動力，為家庭醫生制的推行奠定基礎。