目    录

摘    要 I

Abstract II

1  文献综述 4

1.1  研究背景和意义 4

1.2  国内外研究现状 5

1.2.1  区块链在存储系统研究现状 5

1.2.2  区块链在医疗系统研究现状 7

1.3  研究内容和工作 9

1.4  文章组织和结构 10

2  技术概述 12

2.1  区块链技术概述 12

2.1.1  技术特性 12

2.1.2  密码技术 14

2.1.3  共识机制 15

2.1.4  智能合约 16

2.2  Hyperledger Fabric框架 17

2.2.1  项目概述 17

2.2.2  技术架构 18

2.2.3  共识算法 19

2.3  web技术框架 21

2.3.1  SSM组合框架 21

2.3.2  前端技术框架 22

2.4  本章小结 22

3  需求分析 23

3.1  功能性需求 23

3.1.1  整体架构 24

3.1.2  系统管理 25

3.1.3  通用模块 26

3.1.4  医生模块 30

3.1.5  患者模块 32

3.2  非功能需求 34

3.2.1  可用性需求 34

3.2.2  安全性需求 35

3.2.3  可扩展需求 35

3.3  本章小结 35

4  详细设计 36

4.1  系统管理设计 37

4.1.1  搭建Fabric环境 37

4.1.2  审核医疗机构 40

4.1.3  查看运行状态 41

4.2  通用模块设计 41

4.2.1  用户注册 42

4.2.2  用户登录 45

4.2.3  密钥管理 45

4.3  医生功能设计 46

4.3.1  管理信息 47

4.3.2  处理病历 48

4.3.3  申请授权 49

4.4  患者功能设计 51

4.4.1  管理信息 51

4.4.2  管理病历 52

4.4.3  管理授权 54

4.5  本章小结 56

5  测试维护 57

5.1  系统运行环境 57

5.2  系统功能测试 57

5.2.1  管理功能测试 57

5.2.2  通用功能测试 58

5.2.3  用户功能测试 59

5.3  本章小结 59

结    论 60

参 考 文 献 62

修改记录 64

致    谢 65

1  文献综述

1.1  研究背景和意义

2008年，比特币[1]问世，作为比特币的基础技术框架，区块链技术开始进入人们的视野。随着比特币的快速发展和应用，其相关技术也逐渐成为学术界热门研究话题，基于区块链的研究和应用呈现出爆发式增长趋势，被认为是继大型计算机、个人电脑、移动互联网、社交网络之后计算范式的第五次颠覆性创新，是继血亲信用、贵金属信用、央行纸币信用之后的人类信用进化史上的第四个里程碑[2]。

区块链的本质是分布式存储账本，账本是由多个区块按照时间顺序排列组合形成的线性的链表，账本中存储着网络世界中的交易信息，可以看做是一种具备信任基础的实现网络价值传输的分布式数据库技术。由于其天然的去中心化特性，不仅支持自动执行的智能合约等可扩展性应用，还注重数据安全和隐私保护等关键技术，使得区块链技术不仅可以成功应用于数字加密货币领域，同时在经济金融、物联网供应链和社会公共服务领域中也存在广泛的应用场景[3]。

传统的医疗机构以纸质版的形式保存患者的医疗数据，形式单一且检索困难。随着互联网技术的飞速发展，医疗行业也呈现出信息化的发展趋势。EMR（Electronic Medical Record，电子病历）使用计算机存储病人的医疗数据，记录了患者在医院治疗过程中产生的原始数据。通过梳理和总结近些年政府相关部门发布的有关智慧医疗的政策标准，可以发现，以智慧服务、智慧医疗、智慧管理为核心的智慧医院概念的圈定已逐渐清晰，全国各地正逐步开展“智慧医院”的示范建设工作，我国医疗信息化建设已进入快速发展期[4]。

EMR的广泛应用推动了医疗领域的发展，无论是对医疗机构还是患者本人都带来了很大的便利。但这种系统大都采用中心化的存储方式，将电子病历存储到每个医疗机构指定的中心数据库中。这种中心化的存储模式存在着数据泄露的风险，一旦数据库遭到攻击，可能会导致数据流失，不能保证患者信息隐私安全；同时，数据由各个医疗机构单方面保管，很容易出现“信息孤岛”问题，患者不能随时查看和保管自己的病历数据，由于企业之间存在差异化，医疗数据存储规范不同，EMR也无法在不同的医疗机构之间合理使用和共享，这给病人跨医院就诊带来很大不便；再者，如果出现医疗纠纷，医疗记录中心的管理模式将使患者处于不利地位，无法保障患者的合法权益。

区块链技术的诞生，为解决传统电子医疗数据中心化存储面临的几个痛点问题带来了新的思路。区块链自身带有去中心化的特性，由网络中的所有参与节点共同维护一个分布式的账本记录，可以有效防止一些节点失效或恶意篡改记录，另外每个区块都加盖时间戳并以hash运算的方式连接到前一个区块，这也为完整医疗信息的CURD操作提供了可靠的追溯功能；区块中的患者医疗数据采用密码学加密技术，有效保障链上数据的可靠存储和安全共享，提高了医疗数据的可信度和完整性；除此之外，区块链网络中的参与者人人平等，支持智能合约，合约部署在区块中，不可篡改，自动执行，可以很大程度上避免由于人为因素造成的有意或无意的错误，保护用户隐私安全，减少医疗纠纷。

在基于区块链技术的电子医疗数据存储系统中，分布式存储模型将呈现出以病人为中心的发展态势，使患者尽可能拥有自己电子病历的所有权，病人的医疗记录归本人所有，属于私人数据，其他人（包括医疗机构和研究人员）必须经过授权才能访问用户医疗记录；区块链技术的应用可以联合不同医疗机构，将各个机构提交的医疗数据统一格式后存储到链上，方便实现跨机构数据共享，使得医生和研究人员在得到授权后能快速获取患者医疗记录，进一步帮助患者诊断或者进行远程治疗。将区块链技术应用在EMR系统中，可以构建医疗信息互通互联的医疗体系，进而提高医疗行业服务质量，推动医疗行业信息化发展，具有一定实际价值。

1.2  国内外研究现状

1.2.1  区块链在存储系统研究现状

随着人工智能、云计算的快速发展，数据存储规模呈指数级增长，对存储技术有更大容量、高可靠性与低时延的需求。将区块链技术应用到存储系统中，可以提高现有存储系统的安全性和可扩展性。当前区块链技术应用在存储系统中有以下三个方面[5]：基于区块链构建的去中心化存储系统，基于区块链优化已有存储系统，区块链系统自身的存储方法和优化，如图1.1

图1.1  区块链存储研究分类

将区块链技术应用到存储系统中主要引起两方面变化，一方面，区块链账本存储文件分片的元数据，另一方面使用区块链虚拟货币作为奖励，鼓励用户积极提供存储空间。这种模式的存储系统具有隐私保护能力强、安全性强、响应速度快、下载速度快、闲置存储资源利用率高，存储激励能力强、存储空间开销大的特点。国外科研机构已经有一些开源的基于区块链的去中心化存储项目，IPFS（InterPlanetary File System 星际文件系统）是一个点对点的分布式文件系统[6]，目的在于改变现有的 HTTP 协议，致力于构建一个去中心化的分散的存储网络，打造一个全新的去冗余的互联网世界，而Filecoin 作为IPFS 激励层实现，通过价值激励来鼓励更多的节点加入 IPFS 网络；但是 Filecoin 的服务方式是让服务商和用户相互选择，在很多情形下会降低存储空间的利用率。 Sia 由NebulousLabs公司创建，专注于为去中心化存储模式提供一个功能完备的平台，通过智能合约自动维护存储提供方与用户的协作关系，无需依赖第三方机构，已经发布了正式版本，能够提供更稳定、成熟的服务，但是目前Sia采用POW（Proof of  Work）达成共识，无法应用于高频实时交易场景。

随着区块链技术日趋完善，有人开始研究如何借助区块链技术优化已有系统的存储性能。针对DNS（域名系统）出现的单点故障以及数据泄露造成的信任问题，基于区块链的分布式互联网Blockstack[7]于2015年问世，Blockstack是一款集成了分散式数据、分散式应用程序、分散式用户数据的区块链浏览器应用，Blockstack 架构分为三层：区块链底层、对等网络、数据层，可以看做区块链世界里的“google”。数据库与区块链技术的结合，可以克服现有中心数据库存在的安全性低、数据易泄露等问题，具有代表性的区块链数据库有BigchainDB，ChainSQL，RecordsKeeper等项目，具有去中心化、不可篡改、可溯源以及吞吐量高的优势。ChainSQL[8]将区块链与传统数据库相结合，构建了一种基于区块链网络的日志式数据库应用平台，该技术兼备了两种系统的优点，能随时随地恢复数据库表，并简化了区块链应用的开发，具有历史记录不可篡改、提供审计服务、本地数据库插件式管理等多种特性。对于大文件存储的场景，区块链往往需要底层的文件系统做支撑，采用链上链下组合存储的方式，文献[9]将区块链技术和文件存储系统相结合，将真实文件存储在底层文件系统中，区块链上则保存文件摘要等公共属性信息，利用哈希函数的唯一性和不可逆性来实现对数据的验证，管理文件的访问权限，从而实现一个个人隐私信息的管理平台。区块链技术与分布式存储，需要去中心化的激励机制吸引网络边缘存储设备的加入，两者相互结合，相互促进。

区块链可以看做是一个分布式的数据库，其自身存储也存在着一些问题，在存储空间方面，网络中每个节点要保存整个区块链的全拷贝，以比特币为例，截止2020.5.20，比特币网络中总共有区块630950个，区块总量348GB，区块链膨胀问题造成了存储空间的庞大开销，基于此问题，比特币允许网络中存在轻节点，该类节点选择以轻量级方式运行，只存储区块头内容而不必存储完整的区块数据，因而减少了节点的区块存储；在轻节点与全节点之外，也有人提出基于纠删码的区块链，减轻全节点的负担。纠删码（erasure coding，EC）是一种数据保护方法，它将数据分割成片段，把冗余数据块扩展、编码，并将其存储在不同的位置（比如硬盘），当冗余级别为N+M时，能容忍任意M个硬盘故障。纠删码节点只需保存编码区块，就可以恢复出完整区块，因此能够减轻存储负担；文献[10]提出了一种 Fast 同步算法，该算法只保存最近区块的状态数据而忽略较旧区块的状态数据，不仅减少了同步区块的状态数据，还提高了新节点加入区块链的效率；江云超等针对文献[11]提出的分片方案中存在的问题进行进一步优化[12]，首先分析区块链恶意节点概率并计算每个分片中区块的数量，然后获取区块链节点数量以及分片中编号最大区块被恶意节点攻击的概率，计算出每个分片需要存储的副本数量，新方案在减少区块存储和提高新节点加入区块链效率方面有更明显的优势。除了存储容量方面的限制，在I/O性能方面，区块链的底层数据结构和架构设计在很大程度上影响着系统的存储和查询性能，为了优化查询性能，EtherQL[13]通过在区块链外部关联数据库，并在区块链上构建查询层，通过数据库接口进行数据查询；另一种是内置索引的方式，王千阁等[14]提出为主键建立辅助索引，主键指向数据的物理地址，索引指向数据主键。经过比较，两种方式都能提高区块链系统的查询性能。

1.2.2  区块链在医疗系统研究现状

起源于比特币的区块链技术因其自身的特性引起了社会各界广泛的关注，为推动区块链技术和产业发展，国务院工业和信息化部软件服务业指导中国电子技术标准化研究院，联合蚂蚁金融去、万向控股、微众银行等骨千企业，开展区块链技术和应用发展趋势专题研究，发布了《中国区块链技术和应用发展白皮书（2016）》[15]。包括政府部门在内，许多企业和研究机构纷纷成立专门的区块链实验室，由此催生了许多区块链研究项目。目前区块链的应用主要有金融科技领域、数字版权、物流溯源领域以及供应链领域，在医疗方面的应用研究相对较少。

国外区块链医疗研究案例。通常，医疗记录的医疗信息由医院单独管理，对患者有访问权限，这样患者不能掌握自己医疗数据的第一手记录，失去了对医疗记录等私人数据的控制权力，此外，近年来，医疗中心机构被黑客攻击导致数据勒索的犯罪现象频频发生，医院和患者的信息变的越来越不安全。针对此类问题，麻省理工学院（MIT）研究生Azaria等[16]利用以太坊平台，开发了一个医疗区块链与大数据相结合的医疗信息共享系统 MedRec，用来维护和管理患者的电子病历，存储在这个系统上的所有日志都是全面且不可改变的，包含认证系统、安全系统和问责制系统，为用户提供强大的安全技术处理敏感信息，但以太坊采用的是POW共识算法，全网共识过程类似于比特币，MedRec鼓励医疗利益相关者，医疗机构、患者和研究人员等作为“矿工”参与到以太坊网络中，以竞争算力的方式保护和维护以太坊的认证日志，同时可以获取相应的代币作为报酬，这种共识机制造成了一定的算力浪费；Xhafa F 等[17]提出了一个基于云的医疗记录方案，采用对称加密算法，不泄漏医生和患者的个人信息以及病情的详细描述，对称秘钥采用基于属性的加密方案进行封装，但该系统有一个缺点是需要依赖一个称之为全局权威( Global Authority，GA) 的完全可信的第3方负责密钥管理，有违去中心化的理念；Shrier 等[18]借助MIT的 OPAL/Enigma 加密平台的安全特性，结合区块链，提出一个用于分析和存储医疗数据的解决方案，同时为医疗数据提供安全存储环境。

国内医疗区块链研究案例。相较于国外，国内的研究相对较少，且大部分停留在理论模型上。通过分析医疗行业信息化现状，可以看出，各医疗机构间存在数据共享困难的问题，审查和校验数据需要花费大量的时间和资源，导致医生和研究人员在访问共享医疗数据时存在严格的限制。薛腾飞等[19]设计一个基于区块链的医疗数据共享模型（Medical Data Share Model，MDSM），提出两个概念，医疗机构联盟服务器群（Medical Institution Federate Servers, MIFS）和审计联盟服务器群（Auditing Federate Servers, AFS），将医疗机构根据信用积分划分等级，高等级的节点机构加入MIFS成为代理，第二等级的机构加入AFS作为审计校验的节点，配合改进的股份授权机制 DPOS（Delegate Proof of State） 实现共识，将数据存储在分布式数据库系统中减轻区块链上数据存储和高频访问时的压力，并有完备级客户端和轻量级客户端为用户提供查询服务，MDSM适用于解决各医疗机构共享数据的难题；MDSM医疗区块链启动时需要101个节点的MIFS和20个节点的AFS，也就是说至少需要121 所医院或医疗机构同时参与到区块链维护，针对其启动代价大的缺点，张超等[20]使用实用拜占庭容错算法 (Practical Byzantine fault tolerance, PBFT), 构建了一种既能以较少节点来启动运行，又不需要大量算力来维护的联盟式医疗区块链系统，适合早期探索与后期扩展，具有一定的优越性和较好的适用性；梅颖等[21]结合区块链和云存储技术，提出了一个用于个人医疗记录安全存储和共享的健康链，链上保存医疗记录的公共信息、匿名身份和访问权限，而真正的医疗数据则加密保存在链下存储结构中，有效实现了患者对个人医疗数据的所有权和访问权限的控制以及对敏感医疗数据的安全存储。

区块链技术在电子医疗领域的未来发展前景在很大程度上取决于区块链自身的成熟与发展，区块链的去中心化、不可篡改等特性是非常好的创新点，但其在医疗领域的应用场景尚具有不确定性，在未知的情况下，只有不断的尝试与探索，才能持续推动技术的进步，改正缺点与不足，逐步完善，实现应用落地。

1.3  研究内容和工作

在网络攻击和数据泄露的时代，集中存储的数据就像是一颗定时炸弹。借助区块链开发性、去中心化、不可篡改、不可伪造等特点，本系统研究设计一个基于区块链的电子医疗记录存储系统，系统参与方为患者、医疗机构和研究人员，如图1.2

图1.2  系统参与方

区块链基于点对点网络（P2P），天然具有去中心化的特性，网络中的每个节点都是平等的，保证用户可以拥有自己医疗数据的控制权，不用依赖中心医疗机构，医疗人员或研究者在访问患者医疗数据之前需要经过患者本人授权，才能进行查询；区块链网络中，大多数诚实节点通过共识机制建立信任，共同维护一个分布式大账本，每个参与共识的节点在本地存储着这个账本的完全拷贝，因此，利用区块链与生俱来的不可篡改性，可以保证数据在链上的真实性与安全性；同时，为了提高对患者数据的隐私保护性，链上数据不能以明文形式存在，因此需要将适当的密码学技术引入系统中，病历数据上链前必须经过诊治医生签名及患者本人的公钥加密。

在本系统的设计方案中，患者作为个人病历的所有者，经过授权可以决定谁有访问记录的权利，有效防止病历数据被第三方机构恶意托管和出售，在保证隐私安全性的前提下，使得病人对于就诊记录有更灵活的调度。在跨医院就诊的场景下，医生可以方便的查询患者就医历史，从而对病人实施精细的诊治方案，提高治疗的精准度，减少医患矛盾，也可以为远程医疗提供一种参考方案、技术支持。

系统实现，本系统最终将以网页客户端形式测试。后端使用java语言开发，借助Spring+SpringMVC+Mybatis开源框架实现业务逻辑，框架成熟，运行稳定；区块链网络部分基于Hyperledger Fabric技术框架，Go语言开发链代码，数据存储采用区块链联合存储的方式，fabric网络中存储医疗数据公共信息，而治疗过程中产生的相关文件数据则保存在本地服务器上。本文所实现的系统特点如下所述：

（1） 系统中医疗机构与患者是平等节点，互相协作、互相制约，确保数据源头的真实性；

（2） 所有节点共同维护分布式账本，链上的医疗记录不可篡改，确保数据存储的安全性；

（3） 链上数据全部加密存储，且需经过授权才能访问，确保数据共享时的保密性；

1.4  文章组织和结构

本文共有五个章节，每章节的内容安排如下：

第一章文献综述，首先介绍论文的研究背景和意义，之后从区块链的应用方向角度，分别分析了区块链技术在存储系统与医疗系统的国内外研究现状，然后详细介绍本文的研究方向和主要工作内容，以及系统最终要实现的功能。

第二章技术概述，对电子医疗存储系统中涉及到的技术、框架和用到的软件进行了介绍，包括区块链技术概念、Hyperledger Fabric框架以及通用web开发后端架构。

第三章需求分析，是系统整体要实现的功能和目标，通过分析现有电子医疗系统中存在的问题，提出系统的功能需求与非功能需求。对于要实现的功能需求，从系统使用者的角度分为四个模块，分别为，系统管理配置模块，用户通用功能模块，患者专用操作模块和医疗机构相关功能模块，对每个模块的需求分别叙述；非功能性需求则从可用性、稳定性、安全性、低时延和可扩展性几个方面分别讨论。

第四章详细设计，是对电子医疗系统的详细设计与实现，对上一章中各个模块的功能需求仔细剖析，单独设计实现，内容包括整体操作流程、fabric链代码、后端业务逻辑、后端连接区块链、数据库设计以及数据存储方式等。

第五章测试维护，对各个模块中关键且必要的功能设计测试用例，分析测试结果以发现系统的不足并改进。

最后对论文进行了总结，将整个系统完成实现的情况与预期目标进行比较，分析实现的不足和可选解决方案。对电子医疗领域区块链应用痛点进行分析，讨论区块链价值并对未来前景进行了展望。

2  技术概述

2.1  区块链技术概述

比特币是迄今为止最为成功的区块链应用，随着比特币的成功应用及其在全球范围内引起的广泛关注，其底层的技术原理也在试图展示更大的价值和意义。

2.1.1  技术特性

去中心化。区块链底层采用的是对等计算机网络（peer to peer，P2P），点对点的技术，每个节点都是客户端，没有中心服务器，节点之间互相直连，一种半分布式网络拓扑如图2.1

图2.1  P2P半分布式网络拓扑

去中心化是区块链最显著的特征，网络参与者资格权限完全对等，正是由于P2P协议的存在，让区块链可以实现点对点之间的价值传输。以比特币这一典型区块链应用代表为例，在一个没有中央银行且仅由用户组成的网络中，在P2P技术的支持下，虚拟货币可以在任何联网的计算机上进行挖掘和交易。相对于以往中心化机构的限制，去中心化提供的是一个更自由、更透明、更公平的环境，为个体赋予更多选择的权利和机会。

不可篡改。区块链底层存储架构使其天然具有不可篡改性。区块链可以看做是一个分布式的账本，账本的每一页就是一个区块，区块中存储网络某一个记忆时间段内全部的状态改变和交易的最终结果，区块首尾相接，形成链状结构，如图2.2

图2.2  区块链通用存储结构

在区块链中，第一个区块叫创世区块，通常不包含交易信息，创世区块确定区块结构。区块由区块头和区块体组成，区块头中包含区块号，当前区块hash值，前一区块hash值，时间戳及其他公共信息。

根据不同平台功能需求，区块头存储不同的信息，在比特币区块链中，其他公共信息包含版本号、所有交易merkle树根、难度值和随机数；而在以太坊区块链中，则还要包含叔父区块hash值，汽油费（gas）等更多信息。区块体中存储的是之前一段时间内经过网络广播验证合法的交易信息。每一区块包含前一区块的hash值，通过哈希指针与前一区块首尾相连。新产生的区块加盖时间戳后只能追加到主链末尾，形成一条从创世区块到当前区块的最长合法链（账本）。每个参与网络维护的节点都能拥有一份账本的拷贝，所有节点遵循着相同的共识机制，依靠共识机制建立信任共同维护一条不断增长的链（账本）。

区块头中的hash值根据区块信息经过哈希函数计算得到，任何细微的修改都将引起hash值的巨大改变，造成“断链”现象，只有断链造成的数据变化得到全网大多数节点的同意，才算修改成功，这要求攻击节点的运算速度或公信力等综合能力超过全网一半以上的节点，以使得其伪链长度超过主链长度，而这在现实世界中基本上是不可能的，因此可以说，区块链上的数据是不可篡改的。

公开透明可溯源。区块链是一个信息高度透明、开放的系统，全网广播的数据可以被任何人通过开放的途径查询和使用。基于统一的协议，节点之间的数据交换可以在安全、自由的去信任环境中实现，并且系统会永久存储通过验证的合法信息。基于链式存储结构，区块依次首尾相连，链上任何数据都可以通过此结构追本溯源，因此区块链能够提供历史数据的溯源和定位功能。

2.1.2  密码技术

区块链数据层的安全性主要依赖密码学相关技术，主要包括，哈希算法、数字签名、加密算法。

哈希散列算法。使用哈希函数，输入一个任意长度的字符串，输出一个固定长度的哈希值。公式如下：

(2.1)

输入的x取值范围是无限的，而输出的y是有限的。

常见的hash算法有，MD5 [22]，Message Digest Algorithm，输出哈希是32位16进制数，MD5本来是用来做加密哈希的，但随着计算机的发展，出现碰撞的可能性大了，所以现在普遍当做普通哈希，用作数据校验；SHA[23]，Secure Hash Algorithm，SHA-256输出哈希是64位16进制数，由于地址空间特别大，所以被认为是不可能被破解的，比特币中采用的就是SHA-256。哈希函数应满足以下特点：

（1） 抗碰撞性，collision resistance，很难找到两个不同的输入，使他们的输出的哈希值相同；

（2） 不可逆性，输入隐藏，hiding，根据输出的哈希值，很难逆向计算出相应的输入值；

（3） 输入敏感，即使输入值发生微小变化，计算输出的哈希值也完全不同；

哈希函数被认为是puzzle friendly，对输入无记忆性，比特币挖矿就是通过改变输入值中的随机数，不断hash运算求得满足条件的目标值的过程。

加密算法。常见的数据加密算法有两种，对称加密与非对称加密。

加密算法被用于数据传输过程中保证数据的安全隐私性，发送方在发送数据之前要对发送的文件进行加密，网络中只传输密钥加密后的密文，减低被黑客盗取的风险，接受者收到密文后，用相应的密钥解密，即可获取原来的明文文件。

对称加密算法加密密钥与解密密钥相同，发送方使用密钥加密原始文件发送出去，接收方收到密文后需要使用与发送方相同的密钥才能解密出原文，这种方法要求接收方与发送方事先约定好，双方拿的是相同的钥匙，不能保证密钥拥有者的唯一性，而要每个需要进行数据传输的双方都拥有相同的一组密钥会增加密钥数量，当用户量增大时就会产生密钥管理的负担。常见的对称加密算法有 DES 算法、RC5 算法等。

非对称加密算法的参与个体拥有两个密钥，公开的密钥叫公钥，非公开的密钥叫私钥。在数据传输过程中，接受者需要公开自己的公钥给发送者，发送者将要发送的数据使用接受者的公钥进行加密，然后将密文发送给接受者，接受者收到密文后，使用自己的密钥解密，读取数据。整个过程中，一旦数据使用公钥加密后，只有对应接受者的密钥才能对数据进行解密操作，这样极大程度上保证了数据和持有密钥的安全性。常用的非对称加密算法包括 RSA和 ECC（椭圆曲线加密算法）[24]等。

对称加密与非对称加密数据传输过程对比如图2.3

图2.3  对称加密与非对称加密流程

2.1.3  共识机制

共识机制是区块链技术的关键，是规范区块链中节点行为的规则。

节点通过共识机制建立互联网上的信任，确保对区块数据的有效性达成一致，全网都支持的信任机制让区块链去中心化成为可能。

区块链的世界里，每隔一段时间，就要有矿工将网络中产生的交易数据打包成区块之后上链，这种行为称为记账。每当要产生一个区块时，全体矿工要根据共识算法选出记账节点，获得记账权的矿工在本地交易池中选择验证通过的合法交易打包成区块，将新区块向全网广播，随后，所有节点或代表节点对收到的区块信息进行验证，经过大多数节点认证通过后，记账节点将其添加到最长合法链后面。

区块上链流程如图2.4

图2.4  共识过程

区块链网络层的安全主要有共识机制来保证，这里介绍一种工作量证明机制（Proof of Work，POW）。

POW共识算法。目前区块链社区中两大比较成功的项目，比特币和以太坊现阶段均采用POW共识机制来保证分布式节点的一致性。矿工通过计算哈希难题来争夺记账权，解题过程就是不断在计算哈希函数，将区块头部和随机值nonce作为输入，通过不断改变输入的nonce值来计算得到输出值output，当output < target 时，解题完成，网络中所有的全节点均可以运算，最先完成解题的节点竞争到记账权。每个节点均有解题成功的概率，但通常情况下，解题成功的概率与矿工拥有的计算资源成正比，节点算力占全网比例越大，越有可能竞争到记账权，将区块上链的行为可以获得相应的区块链奖励，这种虚拟货币的激励机制能正向鼓励网络中更多的节点加入到挖矿中。大规模激励产生巨大权力，虽然POW这种比拼算力的方式造成了很多算力资源的浪费，但也因此维护了区块链生态圈的和平稳定运转。

2.1.4  智能合约

1997年，密码学家尼克·萨博（Nick Szabo）首次提出了智能合约的概念[25]，Szabo希望消除中间人，只要满足某些条件，合同就会自动生效。

区块链技术的出现，推动了智能合约的发展。无需第三方，合约是以代码形式存在的计算机协议。其本质是一段由程序员编写的存储在区块中的计算机程序，采用确定性的算法和确定的数据来源，并且满足可终止性。当网络状态变化满足设置的初始条件时，“矿工”将自动执行智能合约内容。以太坊中，智能合约被认为是可直接控制数字资产的程序[26]。Ethereum和Hyperledger Fabric是应用智能合约的两大代表性技术平台，表2.1 从执行环境和编程语言等角度对二者进行简单的对比[27]。

表2.1  智能合约不同平台对比

系统名称	执行环境	编程环境特点	编程语言	特点
Ethereum	虚拟机EVM	轻量级虚拟机， 执行效率低， 资源消耗小	Solidity, Serpent, LLL	应用范围广，特别是数字货币的支付应用场景， 图灵完备的编程语言，能实现复杂的逻辑功能
Fabric	Docker容器	执行效率高， 资源消耗大	Go, Java	企业级应用场景，可用作商业平台开发 Docker部署执行环境，资源消耗大，合约性能有影响

智能合约增强了区块链技术在实际业务场景中应用的灵活性。类似于传统合同，用代码实现法律条款，将人与人之间复杂的关系程序化，利用计算机程序建立威信和约束力。可以认为，代码即法律，一旦生效不可反悔。这就需要注意一点，由于智能合约是自动执行的并且不许第三方干预，合约内容的合理设计运行是整个系统稳定运行的关键，如果合约代码里的逻辑存在问题将严重影响区块链的安全。因此，需要提前对待上链的智能合约进行慎重的检查。

2.2  Hyperledger Fabric框架

2.2.1  项目概述

Hyperledger（超级账本）是 Linux 基金会于 2015 年带头发起的一个区块链技术平台，是一个企业级的开源许可区块链项目。由众多科技、金融行业的巨头公司的共同维护并提供技术支持，包含丰富的代码库。借助开源世界自由强大的便利性，Hyperledger已经由单一的项目逐渐发展成了一个庞大的项目组，包含八大顶级子项目，满足区块链在各种商业平台的应用需求。

Hyperledger Fabric是联盟链中的优秀代表[28]，是提供分布式分类账解决方案的平台。

Fabric采用模块化架构，支持不同组件的可插拔使用，将一些原本独立的工作集中起来，制定统一的开放式协议和标准，此外，Fabric还实现了完整的权限控制和授权管理保障安全，具有机密性、灵活性和可扩展性，适用于通过共享的数据构建商业联盟链应用中可能出现的错综复杂的各种场景。

2.2.2  技术架构

Fabric灵活的可插拔组件特性依赖于其高度模块化的结构。

Fabric整体功能架构如图2.5[29] ：

图2.5  Hyperledger Fabric 架构图

包含三个主要部分：成员管理服务（Membership Servers，MSP），区块链服务（Blockchain Severs），链码服务（Chaincode Servers）。

相关概念介绍。

成员管理服务提供商（Membership Service Provider，MSP）：

负责提供成员的注册（Registration）、身份管理（Identity Management）、身份验证（Auditability）等服务。Fabric联盟链通过MSP提供成员证书（Certificate）管理服务，决定链上哪些节点是可信任的，所有类型的节点和客户端必须通过MSP授权后才能加入网络。证书授权的前提是需要配置公钥基础设施（Public Key Infrastructure，PKI），PKI是一种利用标准公钥加密技术提供的一套安全基础平台的技术和规范。Fabric上的认证机构（Certificate Authority，CA）通过PKI为用户颁发数字证书（Digital Certificate），分配密钥，以实现联盟网络中节点身份权限认证和数据访问授权管理。CA证书分为两类，根证书（Root Certificate Authority，RCA）和中间证书（Intermediate Certificate Authority，ICA），构成一个证书信任链。

证书分类如表2.2 所示：

表2.2  证书分类

证书名称	颁发机构	描述
注册证书 ECert	注册证书颁发机构 ECA Enrollment CA	身份验证通过用户的实名证书 长期有效，用于身份审核
交易证书 TCert	交易证书颁发机构 TCA Transaction CA	Ecert用户发起交易时的匿名证书 短期有效，交易期间身份认证
通信证书 TLSCert	TLS证书颁发机构 TLSCA TLS CA	进行网络通信的身份信息证书 保证网络通信的安全

通道channel：

通道是一个逻辑概念，同一个通道内的节点可以相互通信，节点之间不能跨通道建立连接。每个通道有一个全局的MSP，管理节点的加入和退出。

区块链服务（BlockChain Service）：

包含P2P网络协议管理（P2P Protocol）、共识机制管理（Consensus Manager）、分布式账本管理（Distributed Ledger）、账本存储管理（Ledger Storage）等服务。

账本包含两部分：区块链（Blockchain）和状态（State），Blockchain就是通常所说的由区块连接成的链，用于记录历史交易；State是一个Key-Value形式的数据库，对应当前网络的最新世界状态（WorldState），对同一个key的每次交易，均需更新状态。

链码功能（ChainCode）：

Fabric中的链码是系统开发者编写的存储在账本中的计算机程序，就是通常所说的智能合约。链码中包含业务逻辑代码，可由Go、Java、Node.js等语言编写，运行在Docker容器上；不同语言的客户端通过安装相应的软件开发工具包（SDK）调用应用程序接口（API）触发链码，链码根据客户端传来的参数调用对应的函数执行业务逻辑，访问账本更新世界状态。

2.2.3  共识算法

Fabric区块链中的网络节点，需要维护全网相同的账本状态，节点间本质上可看作是互相复制的状态机。

Fabric通过共识过程实现分布式节点的一致性，共识过程可以看做是一次交易实现的过程，包括三个阶段，背书、排序、校验。

共识过程如图2.6：

图2.6  Fabric1.0交易过程/共识过程

背书（Endorsement）过程。

客户端提交交易到背书节点，节点对收到的交易提案验证签名，并模拟执行链码得到结果，之后将校验结果、背书结果和证书签名作为提案结果发回给客户端；根据背书策略，客户端在收到足够多的提案同意反馈后，才认为交易是有效的。

排序（Ordering）服务。

排序节点（Ordering Service Node，OSN）将一段时间收到的交易进行排序，并将排序后的交易打包成数据块后，把新区块广播给通道中的成员。

排序服务需要达成共识，保证所有成员收到的是一组顺序相同的交易，维护数据一致性。Fabric1.0 中的排序服务支持可插拔组件。

三种模式对比如表 2.3 ：

表2.3  排序服务

排序模式	特点
SOLO	单机模式，仅有一个排序节点，适合开发测试中使用 中心化服务，不支持拜占庭容错
Kafka	基于kafka分布式消息服务平台，具有高扩展性和容错能力，可用于生产环境 能容忍节点故障失效，不能容忍恶意节点
EtcdRaft	使用raft协议保持数据一致性，允许不同的组织贡献节点共同组成排序服务 要保证大多数节点正常运行

校验（Validation）阶段。

确认节点对排序后的交易进行一系列合法校验，包括交易签名正确、交易数据的完整性、是否满足背书策略等。数据块中所有交易通过校验后，区块被认为是合法的，写入账本，并改变Key-Value状态数据库。

2.3  web技术框架

2.3.1  SSM组合框架

简单介绍。SSM框架，是Spring + Spring MVC + MyBatis组合的缩写，是轻量级JavaEE开发框架，适用于搭建大型应用系统。

Spring是一个轻量级的支持控制反转（IOC）和面向切面编程（AOP）的容器框架。Spring依赖注入DI来管理各层的组件，利用工厂模式将对象交给容器管理，只需在配置文件中事先写好用到的bean，Spring容器启动时会自动初始化这些bean，用这种方式让Spring容器生成类的实例对象，而不需要在业务代码中手动new生成。AOP是一种面向切面的编程思想，将多业务流程中的通用功能单独抽取出来，封装得到独立的切面功能，程序执行时，自动把功能代码横向插入需要的位置。Spring利用AOP机制实现事务管理，日志生成、权限检查等非业务逻辑相关功能。

SpringMVC是Spring Framework系列产品，原生支持Spring特性，使开发变的简单规范。MVC是一种应用程序分层开发模型，三部分组成：

（1） 模型层（Model），存储实体类数据，实现业务逻辑；

（2） 视图层（View），数据可视化展示，可以理解为前端页面；

（3） 控制层（Controller），与前端交互，将消息分发给业务逻辑层处理；

Mybatis是Java操作数据库的持久层框架，封装了JDBC的很多细节，开发人员只需关注SQL语句本身，由mybatis管理与数据库创建连接，执行查询，封装结果集等操作。基于ORM（Object Relational Mapping）的思想，通过注解在实体层（Entity）将业务实体和数据表关联起来，操作实体类就可以实现操作底层数据库表。

2.3.2  前端技术框架

Vue.js 是一个JavaScript MVVM（Model-View-ViewModel）库，是一套构建用户界面的渐进式框架。是以数据驱动和组件化的思想构架起来的，采用自底向上增量开发的设计。Vue只关注视图层，为开发人员提供简洁、易用的API。很轻量很快，通过尽可能简单的 API 实现响应的数据绑定和组合的视图组件。

Vue的核心：数据驱动，数据改变驱动了视图的自动更新，开发者将 DOM 绑定至底层实例的数据，当数据变化时，会自动改变视图，不用通过手动改变DOM来改变视图；视图组件化，将网页看成是由多个组件拼接或者嵌套组成的。把整个页面拆分成一个个分区，每个分区可以看作成一个组件。

2.4  本章小结

本章介绍了论文中涉及到的通用技术概念。首先介绍了区块链技术，包括区块链的特性、区块链中用到的密码学技术、还有共识机制和智能合约的概念及作用。接着介绍了Hyperledger Fabric框架的特点和应用场景，fabric整体技术框架，及其使用的的共识算法。最后介绍本文中用到的通用web开发框架，ssm的特点，Vue.js的特点。

3  需求分析

本系统是真实电子医疗系统的缩影，不完全实现实际医疗系统中特别复杂的业务场景，只涉及患者医疗数据的存储和共享部分，旨在为区块链技术在电子医疗系统中的实际应用提供一种思路。

以Hyperledger Fabric技术框架为基础，使用通用web前后端技术框架开发一个医疗记录存储系统。借助区块链的去中心化、不可篡改、隐私安全等特性，保证患者在就诊过程中产生的医疗数据的存储安全性，解决传统使用中心数据库存储电子医疗记录存在的信息孤岛问题，使得医疗数据可以安全方便的实现跨机构共享，为患者跨医院就诊和医生远程治疗提供了便利，医生可根据完整的医疗记录，对病人的病情做出精准的判断，提供更优质的医疗服务。此外，当出现医疗纠纷或保险理赔纠纷时，区块链中保存的历史诊疗记录对医院、保险公司、患者三方都是公平的，且具有公信力，能够协助定责，尽快确认责任方，提高办事效率。

3.1  功能性需求

系统参与实体主要分为三类：系统管理员，患者，医生，以共同合作、相互制约的方式组成区块链联盟。如图3.1 所示：

图3.1  系统用户

系统底层运行在Hyperledger Fabric上，使用区块链存储患者的医疗记录，Level DB存储医疗记录的状态信息，提高检索效率。系统中，允许有管理员角色的存在，管理员是系统开发人员和维护人员，负责常规操作如配置环境，部署代码，发布软件更新等非业务功能，业务逻辑方面负责审核医疗机构加入联盟链，可以查看系统运行数据如用户总量、区块总量等非敏感信息。管理员没有上帝视角，在系统运行过程中不允许管理员干涉实际业务逻辑，也不允许其访问用户隐私数据。从区块链的角度看，医生和患者属于对等节点，功能上互相牵制、互相合作。在患者就医时，诊治医生根据患者的检查结果和治疗结果为患者产生电子记录，发送给用户，用户查验数据正确性，确认没问题就可以提交到Fabric网络中；患者是医疗记录所有者，患者本人拥有医疗数据的完全控制权，可以随时查询、追溯自己的医疗记录，医生或其他科研人员想要访问医疗记录，需要向患者申请权限，得到授权后才可以进行相应的查询功能。

系统从三个方面考虑隐私病历数据安全性。源头上，医生与患者相互制约，患者查看数据正确后才允许上传，保证数据上链前的正确性；存储中，区块链可以看做一个分布式的账本，每个节点都保留一份账本的完全拷贝，其天然的不可篡改性保证数据存储过程中的安全性；使用时，数据查询设置完备的权限管理机制，其他用户必须得到患者本人的授权才能访问对应的病历数据，保证共享时的隐私性。而且在数据的存储和传输过程中，均使用非对称加密技术进行安全加密，保证在不泄露病历内容的前提下实现共享。

3.1.1  整体架构

系统整体架构划分为四个模块：系统管理模块，用户通用模块，医疗机构医生功能模块，患者操作功能模块，如图3.2 所示，每个模块功能需求会在后面详细叙述。

图3.2  系统功能模块

3.1.2  系统管理

在本系统中，为了不与区块链的去中心化概念相违背，管理员作为系统的管理与维护人员，职责是保障系统正常运行，不得干涉用户在系统的正常业务操作。

主要工作包括：搭建系统运行环境，完成Fabric环境配置，审核医疗机构加入，查看系统运行状态。

系统管理员用例图如图3.3

图3.3  管理员用例图

（1） 搭建Fabric环境。

Hyperledger Fabric网络需要初始化，为了保证系统实现功能，需要利用联盟链的思想，事先设置好分组规则。根据规则划分组织，设置通道，通过通道控制数据的访问和共享；设置Order节点、Peer节点，配置节点主要是向Fabric申请数字证书，标识其网络中的身份和所属组织，将申请到合法证书的节点按照事先约定好的策略加入通道中；web客户端可以通过链代码访问账本，所以需要管理员编写智能合约并部署在通道中的peer节点上。

最终测试启动环境，完成Fabric网络的搭建。

（2） 审核医疗机构。

医院负责产生病人的诊疗数据，是我们信任的权威机构，为了避免非法机构进入系统破坏运行生态，医疗机构的加入须经过管理员的审核（这里只是简单审核营业执照），通过审核的机构才能得到用户的信任。

审核医疗机构功能描述见表3.1：

表3.1  审核医疗机构

功能名称	审核医疗机构
功能角色	管理员
功能描述	新医疗机构申请加入，需要提供营业执照，管理员进入系统，查看消息，判断为合法后允许加入，并分配机构代码
输入	医院营业执照
输出	是否合法

注：目前该功能在此模拟环境中是管理员审核。基于去中心化的思想，不应该有管理员这样的功能存在。在真实应用场景中，可以考虑已有医疗机构投票审核的方式，自动完成新医疗机构的加入，而不需要管理员参与。

（3） 查看运行情况。

管理员维护系统需要借助此模块中的方法。此接口用于为管理员维护系统提供接口服务，分类下可以提供很多子方法供管理员查看系统运行状态，协助保证系统正常运行。这里提供的一个方法是查询用户总数。

查询用户总数见表3.2

表3.2  查询用户数

功能名称	查询用户数
功能角色	管理员
功能描述	可以通过该方法监听系统总用户
输入	无
输出	系统总用户数

3.1.3  通用模块

通用功能模块包含的是系统用户的各种通用功能，这些功能实现功能过程相似，考虑到后期维护的便利以及程序可扩展性，可以将功能类似或实现过程相似的功能归到一个模块中。

这里的用户主要分为医生和患者，通用功能主要包括新用户注册、用户登录、个人信息管理以及密钥管理等方面。

用户通用功能用例图，如图3.4：

图3.4  通用模块用例图

用户通用功能用例分析：

（1） 用户注册。

新用户必须注册进入系统才能正常使用功能，分为医院注册、患者注册与医生注册。医院的注册因为需要管理员的审核，所以需要一个不同的界面，专门用于医疗机构注册与审核；用户注册时，需选择自己的身份，患者还是医生，输入自己的真实姓名、手机号和密码，其中医生还要填一项是所属医疗机构代码，表明自己就职医院。手机号是用户在系统中的唯一标识，不允许重复，用于注册之后的用户登录

完成注册后，系统利用RSA算法为用户生成一个公私密钥对，公钥全网公开，私钥用户自己保存。；RSA密钥对是用户签名、加解密数据的唯一工具，患者密钥是获取区块链账本中加密医疗数据的唯一方式，而且只有这一次查看私钥的机会，需提示用户保存好。

用户注册功能描述见表3.3

表3.3  用户注册

功能名称	用户注册
功能角色	患者、医生
功能描述	用户填写个人信息，系统分配密钥对，完成注册
输入	姓名、手机号、密码
输出	注册结果，密钥对

（2） 用户登录。

用户需要登录系统才能看到具体的操作界面，分为患者登录与医生登录。用户输入手机号和密码，选择身份，系统判断用户密码是否正确。登录成功后跳转到不同身份类型用户相应操作界面，登录失败则返回错误信息。登录功能见表3.4

表3.4  登录功能

功能名称	用户登录
功能角色	患者、医生
功能描述	用户输入个人信息，根据用户类型跳转到相应操作界面
输入	手机号、密码
输出	登录结果，跳转界面

（3） 查询个人信息。

已登录用户拥有查询个人信息的功能。此系统是简化系统，这里的用户信息只包含头像、姓名和手机号，医生包含所属医院信息，其他非必要信息系统管理方式类似，这里不做多余处理，查询个人信息功能见表3.5

表3.5  查询个人信息

功能名称	查询个人信息
功能角色	患者、用户
功能描述	用户进入个人中心选项卡，显示“我的”页面
输入	用户ID
输出	个人信息

（4） 设置个人信息。

这里的修改信息指的是web端修改，只是为了客户端管理用户的方便，不涉及区块链数据上的修改。用户根据已查询到的个人信息，可以选择性的进行修改。这里可修改项包括手机号和头像。设置个人信息功能见表3.6

表3.6  修改个人信息

功能名称	修改个人信息
功能角色	患者、医生
功能描述	用户修改网页端的个人信息
输入	要修改的内容
输出	修改结果

（5） 查询公钥。

系统中公钥是公开的，存储在web服务器端，任何人都可以获取其他人的公钥。医生与患者在通信过程中需要使用对方的公钥对消息进行加密和验证签名，在实际场景中会有更多获取公钥的需求。用户自己的公钥在个人密钥管理页面就可以查看，其他人公钥可以根据对方手机号查询。查询公钥功能见表3.7

表3.7  查询公钥

功能名称	查询公钥
功能角色	用户
功能描述	根据手机号查询公钥，进行后续操作
输入	对方手机号
输出	对方公钥

（6） 生成密钥。

用户在使用系统的过程中，由于疏忽或其他意外情况可能导致私钥丢失。私钥是患者访问区块链上加密医疗数据的唯一方式，一旦丢失，则当时对应公钥加密的数据将永远不能再获取，除非系统所用RSA算法被破解。为了使用户能够继续使用存储系统，客户端提供新生成密钥操作。用户密钥新生成功能见表3.8

表3.8  生成新密钥

功能名称	生成新密钥
功能角色	患者、医生
功能描述	用户在个人密钥管理页面，点击新生成按钮，为用户生成新的密钥对，公钥全网公开，私钥提示用户保存好
输入	用户ID
输出	新的密钥对

3.1.4  医生模块

医生作为系统中的用户实体，除了拥有上一节中描述的通用功能外，医生属于医疗机构，要代表医疗机构的行使职能。医生的职责是帮助病人检查身体，治疗病人，并根据治疗结果为病人生成电子病历，将病历交给用户查看，最终存储到区块链上。

医生模块功能用例图如图3.5

图3.5  医生模块用例图

医生模块功能用例分析：

（1） 建立病历。

医生在线下为患者提供治疗，依据治疗记录建立电子病历。现实世界中，根据不同的病症患者会在不同的科室接受治疗，产生的电子病历形式也不尽相同。本系统简化传统医疗系统模型，使用一种简单的方式记录电子病历，将其分为两部分，一部分以文字表格形式，记录病历基础信息，包括主治医师，治疗时间，病情描述等；另一部分以图片形式，代表检查过程中使用电子仪器产生的电子数据，如CT，X光片、核磁共振等，由于此系统是面向电子医疗的简易系统，在此并不真正存储这些专业数据，只是以图片的方式代替。

系统中患者是医疗记录所有者，医生建立电子病历后，要将病历发送给患者本人，由医疗记录所有者确认记录没问题，才将记录存储到区块链网络中。为保证数据传输过程中的隐私安全，需要用RSA算法对电子病历进行签名及加密操作，之后发送到网络上。医生为患者建立电子病历功能如表3.9。

表3.9  建立病历

功能名称	建立病历
功能角色	医生
功能描述	医生为患者会诊，根据治疗过程和治疗结果，为患者建立新的电子病历
输入	治疗信息
输出	加密电子病历

（2） 更新病历。

医生根据授权查看以往医疗记录，对患者进行二次治疗。由于区块链的不可篡改性，这里的更新病历并不是真正修改超级账本中的历史数据，而是根据本次治疗情况为用户新建立一份电子病历，流程与新建电子病历类似。新建的这份病历保存在区块链的状态数据库中，医生申请查看用户病历，得到授权后查询到的就是最新的病历。医生为患者更新病历功能见表3.10。

表3.10  更新病历

功能名称	更新病历
功能角色	医生
功能描述	医生为患者再次治疗，根据治疗情况更新电子病历
输入	治疗信息
输出	加密电子病历

（3） 申请授权。

医生在会诊时，通常需要了解患者的既往病史，这有助于医生提出更快更有效的治疗方案。区块链上的数据经病历所有者公钥加密，其他用户无法获取。当医生想查询患者病历时，需向患者提交授权申请，经患者授权的医生可以查看病历，这个病历指的是患者的最新病历，如果医生需要更多患者的病例历史数据，则需要线下协商，由患者主动发送给医生需要的历史病历记录。医生向患者申请授权查看病历功能见表3.11。

表3.11  申请授权

功能名称	申请授权
功能角色	医生
功能描述	医生向患者申请查询其病历，患者检查消息，决定是否授权
输入	医生ID，患者ID
输出	是否授权

3.1.5  患者模块

医疗数据是患者的私有数据，患者作为病历所有者，对病历拥有绝对控制权。除了作为病历创建者的医生外，其他人未经允许是不会看到患者医疗信息的。在本简化系统中，不涉及处理现实中复杂的诊疗过程，患者的功能主要围绕病历数据的管理，包括接收医生建立的病历，检查没问题提交病历存储到区块链网络，查询本人病历数据，接收医生更新的病历并提交，接收医生的授权请求，授予医生访问病历的权限及取消相关授权。患者模块功能用例如图3.6

图3.6  患者模块用例图

（1） 上传病历。

参见医生模块建立病历功能，医生为患者建立新的电子病历后，需要将病历数据发送给病历所有者审核，病历所有者确认数据没问题，可以将病历发送到区块链网络中。审核验证内容包括医生签名、医疗数据信息的正确性。医生新建病历与更新用户病历传递给患者处理的操作流程是类似的，所以患者上传病历的功能包含新建病历和更新病历。患者上传病历功能见表3.12

表3.12  上传病历

功能名称	上传病历
功能角色	患者
功能描述	患者确认提交病历数据，存储到区块链网络中
输入	加密签名病历
输出	存储到区块链的结果

（2） 查询病历。

患者能随时查看自己的病历数据，包括查看最新病历和历史病历数据。点到查询病历选项卡默认查看的是最新的，但是提供同样提供接口查看以往更多数据。患者的病历数据加密保存在区块链上，从链上取到的数据也是密文，需要用户提供私钥进行解密才能看到原始数据。如果用户忘记私钥，将不可能获知对应公钥加密过的原始数据，丢失密钥相当于丢失数据。患者查询病历功能如表3.13

表3.13  查询病历

功能名称	查询病历
功能角色	患者
功能描述	进行查询病历选项卡，查看本人既往病史
输入	患者ID、患者私钥
输出	病历数据

（3） 允许授权。

患者掌握自己病历的所有权，医生想要查询病历需要先向病历所有者申请。患者查看待授权消息，将允许授权的病历先从区块链上取出，本地解密，再用医生公钥加密之后发送给医生，医生使用本人私钥解密即可获取医疗数据的明文内容。这里存在两种情况，一种是医生通过平台主动请求病例所有者授权查看最新病历，患者通过平台允许医生授权查看；另一种情况是最新数据不能包含患者所有既往病史，或最新数据没有提供医生所需内容，医生需要访问患者更多历史数据，可以让医生与病历所有者协商后，病历所有者主动发送病历数据供医生查看。患者允许授权功能见表3.14

表3.14  允许授权

功能名称	允许授权
功能角色	患者
功能描述	患者在就诊时，与医生达成共识，允许其查看既往病史
输入	医生ID
输出	授权病历数据

（4） 取消授权。

患者在结束治疗后或者医生不再需要查看其病历时，患者可以主动登录平台查看授权记录，并取消之前的授权，将病历所有权再次掌握在自己手中，保证数据安全性。患者取消授权功能见表3.15

表3.15  取消授权

功能名称	取消授权
功能角色	患者
功能描述	病历所有者查看授权记录，取消不需要的授权
输入	患者ID
输出	取消授权结果

3.2  非功能需求

要制定一个完备的系统，在实现基本的功能需求前提下，还要考虑系统的非功能性需求，包括可用性需求、安全性需求、可扩展性需求等，这些都是必不可少的思考点。

3.2.1  可用性需求

实现基本功能的基础上，能够平稳的运行是系统的必要条件。

规范输入输出，用户发起数据请求后，系统能以较快的速度做出响应，给出返回结果，操作错误给出提示反馈。

涉及重要信息需做出额外提示，如为与用户新生成密钥对后，要告知用户密钥对作用，提示用户保存好私钥。

3.2.2  安全性需求

系统在运行时需要保障用户数据的安全性，保护隐私数据不被泄露。利用密码学技术，本系统数据安全保护从三方面考虑：提交数据的安全性，数据上链前由医生和患者层层把关，保证真实；数据存储过程中安全性，借助区块链天然的不可篡改性，而且链上存储数据都是经数据拥有者加密后的密文数据，其他人就算获取到密文也看不到实际内容；数据使用过程中安全性，数据在共享过程中使用非对称加密算法加密，防止传输过程中被盗取。

3.2.3  可扩展需求

整体结构设计要遵循软件工程设计流程，各个模块的功能设计应尽可能减低耦合度，可以根据需求随时增加新功能，在修改或者删除一个功能模块时，对其他模块造成尽量小的影响。开发过程中，后端与链代码解耦，各个部分功能划分明确，单独完成开发测试并留有接口，通过调用API互相通信。低耦合设计不仅能提高开发效率，也为之后的故障检测、运行维护等工作提供了便利。

系统要具有一定的容错能力，基于fabric框架的优势，某个节点出现故障时，内部共识机制能保证系统正常继续运行。故障节点修复后或有新节点生成，可以自动同步所需数据方便加入系统运行。

3.3  本章小结

本章主要是对系统进行需求分析，包括功能性需求和非功能性需求。首先给出系统整体架构图，将系统功能从用户角度划分为四个模块，分别是管理员模块，通用功能模块，医生模块和患者模块，然后对每个模块分别画出模块功能用例图，再对每个子模块的功能需求细致分析。功能分析之后，针对系统的非功能性需求，从可用性需求、安全性需求与可扩展性需求三个方面进行了讨论。

4  详细设计

根据需求分析中的功能性需求，针对各个模块分别给出详细设计。系统以web客户端的形式展现，后端java，使用SSM框架，区块链网络使用HyperLedger Fabric技术框架，链代码Go语言开发，底层数据存储在区块链和Mysql数据库中。

基于数据分层处理模型，将系统整体分为四个层次：视图层（View），控制层（Controller），业务逻辑层（Service），数据存储层（Storage）。每个层次负责单独的功能，视图层代表前端页面，响应用户操作请求，显示处理结果；控制层接收前端请求，根据要处理的业务逻辑将数据分发给逻辑层，封装业务处理后的数据返回给前端；业务逻辑层实现实际要处理的业务，根据需要对底层数据库发送CRUD请求，将处理结果返回给控制层；底层数据库存储的是数据实体，分为区块链存储和Mysql存储，为业务逻辑层提供增删改查接口。系统响应一次用户请求的数据流程如图4.1

图4.1  客户端接收请求数据流图

4.1  系统管理设计

此模块对应的是管理员功能设计，分为搭建Fabric环境，审核医疗机构，查看运行状态。管理员功能要单独开发，与用户功能区分开，操作页面也是相互独立的，不能直接跳转。

模块涉及的本地Mysql数据库表：

医疗机构表t_hospital，表4.1

表4.1  医疗机构表

字段	类型	描述
hospital_id	int	医院机构代码，主键，自增
hospital_name	varchar(32)	unique，医院全称
hospital_state	tinyint	医院状态： 0-正常 1-待审核 2-非法
business_license	varchar(32)	营业执照以图片形式展示， 这里存储的是图片地址
in_date	date	提交审核时间 审核通过后为加入时间

用户数量自增表t_usercount，表4.2

表4.2  用户数量自增表

字段	类型	描述
user_count	int	用户总数，主键，自增
last_time	datetime	更新时间

4.1.1  搭建Fabric环境

本次实验中，使用Hyperledger Fabric v2.1 官方提供的测试网络，test-network。包含两个组织org1与org2，两个peer节点分别属于两个组织，一个order节点，一个通道mychannel。查看系统日志，fabric网络启动流程包括为各组织生成证书文件、生成创始区块、创建通道和部署合约等内容。

最后网络部署成功如图4.2：

图4.2  网络部署

智能合约。fabric 从2.0版本开始，加强了对链码的管理和部署，多个组织可以在链码生命周期中，通过共识策略，完成链码的安装与升级，进而使用链码与分布式账本进行交互。fabric链码背书策略配置灵活，既支持集中式信任模型，又支持分散式管理模型。在分散式模型中，只有得到网络中足够数量的组织批准后，才允许改变链码（安装或升级）。而且允许参与组织在链码生命周期中更改认可策略，无需重新打包或重新安装。面向开发，fabric 2.1 使用 peer lifecycle chaincode 命令操作链码，具体部署流程如图4.3：

图4.3  链码部署流程

链码部署流程分析：

打包链码：

peer lifecycle chaincode package medical.tar.gz --path CC_SRC_PATH --lang golang --label medical_1

CC_SRC_PATH是智能合约源代码所在路径，label是合约标签，使用版本号。

各个节点上安装链码：

peer lifecycle chaincode install medical.tar.gz

组织成员批准合约：

peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls true --cafile ORDERER_CA --channelID mychannel --name medical --version 1 --init-required --package-id PACKAGE_ID --sequence 1

ORDERER_CA是order节点证书地址，version与sequence在第一次合约安装的时候是1，之后合约每次更新版本号都要有不同，例如下一次升级安装时要改为2。

检查合约是否满足提交策略，策略的定义在通道配置中给出，这里背书策略要求满足过半数组织批准，就是org1与org2都要同意，命令如下：

peer lifecycle chaincode checkcommitreadiness --channelID mychannel --name medical --version 1 --sequence 1 --output json --init-required

查询结果如图4.4，组织1同意而组织2不同意，不满足过半数策略，不允许提交合约，需要组织2节点批准合约：

图4.4  背书状态

满足合约定义的策略后，提交合约：

peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls true --cafile ORDERER_CA --channelID mychannel --name medical --peerAddresses localhost:7051 –tlsRootCertFiles CA1_FILE --peerAddresses localhost:9051 –tlsRootCertFiles CA2_FILE --version 4 --sequence 4 --init-required

CA_FILE，是节点ca的根证书路径。

测试合约，刚安装的合约要首先调用Init() 方法：

peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls true --cafile ORDERER_CA -C mychannel -n medical PEER_CONN_PARMS --isInit -c '{"Args":["Init"]}'

PEER_CONN_PARMS是节点地址和证书地址信息。之后执行查询与结果如图4.5，firstKey对应取出的值为firstValue。

至此，合约部署完成：

图4.5  合约测试查询结果

4.1.2  审核医疗机构

医疗机构信息存储在服务器本地mysql数据库中，存储结构见表4.1。

管理员登录系统后，进入审核医疗机构选项卡，显示待审核的医疗机构列表，点击医疗机构详情，这里是简单审核营业执照，如果合格则选择审核通过，失败选择不通过，系统判定医疗机构非法，不允许加入。

涉及到的主要后端功能函数：

获取待审核机构列表，输出参数是一个待审核机构list，如表4.3

表4.3  待审核机构列表

K	V
请求url	/admin/checkHospitalList
请求方式	Get
请求参数	无
返回参数	返回参数描述
hospitalID	医院ID
hospitalName	医院名称
businessLicense	医院营业执照url
inDate	申请时间

根据查询到的待审核结构信息，管理员可以给出审核结果，通过或者不通过，改变数据库中医疗机构的状态，如表4.4

表4.4  审核医疗机构

K	V
请求url	/admin/checkHospital
请求方式	Post
请求参数	请求参数描述
hospitalID	int，医院ID
hospitalState	int，审核结果 1-合法，2-非法
返回参数	返回参数描述
result	修改是否成功 0-成功，1-失败

4.1.3  查看运行状态

管理员查看系统运行状态模块可以提供很多非业务功能，辅助维护系统正常运行，例如区块链上的运行状态，区块总数、节点运行状态，链下状态如查看医疗机构列表、用户数、操作日志等。这里只简单给出查询用户总数的功能，此类查询功能的实现方式都是类似的，后续如果有更多需求，都可以方便的添加到此模块中。

用户总数记录在用户数量自增表中，结构如表4.2，每当有新用户注册，表中数据自动加1。获取用户总数功能函数如表4.5

表4.5  获取用户总数

K	V
请求url	/admin/getUserCount
请求方式	Get
请求参数	无
返回参数	返回参数描述
count	用户总数

4.2  通用模块设计

此模块包含系统中用户的一些通用功能，这些功能的具体实现在不同类型用户下相差不大，将这些功能统一到通用模块下方便于管理代码。此模块目前实现了用户注册、用户登录以及密钥管理功能，如果后续有新的需求属于通用功能范畴的，都可以添加到此模块中。

模块涉及的本地Mysql数据库表：

患者信息表t_patient，表4.6

表4.6  患者信息表

字段	类型	描述
patient_id	int	主键，患者id，唯一标识
patient_name	varchar(16)	患者姓名
patient_phone	varchar(11)	unique，患者手机号
patient_password	varchar(32)	密码
patient_picture	varchar(32)	头像
patient_state	tinyint	状态，0-正常，1-非法

医生信息表t_doctor，表4.7

表4.7  医生信息表

字段	类型	描述
doctor_id	int	主键，医生id，唯一标识
doctor_name	varchar(16)	医生姓名
doctor_phone	varchar(11)	unique，医生手机号
doctor_password	varchar(32)	密码
doctor_picture	varchar(32)	头像
doctor_hospital	int	所属医疗机构 外键，关联t_hospital的hospital_id
doctor_state	tinyint	状态，0-正常，1-非法

用户公钥信息表t_publickey，如表4.8

表4.8  公钥信息表

字段	类型	描述
user_id	int	主键
user_publickey	varchar	公钥

4.2.1  用户注册

用户想要使用系统，首先需要注册为系统合法用户。

注册功能是web端完成的功能，不涉及访问区块链。用户注册分为患者注册、医生注册以及医疗机构注册，患者和医生归为用户类注册，医疗机构注册要单独实现。用户注册时除了要选择自己的身份，还要填写真实姓名、手机号、密码信息，注意需要将密码经MD5取哈希后才能保存到数据库。注册后要为用户生成公私密钥对，私钥是患者获取区块链上加密病历的唯一方式，需提示患者保存好私钥。

患者个人信息见表4.6，医生个人信息见表4.7，公钥信息存储表见表4.8。

用户注册流程图如图4.6 ：

图4.6  用户注册流程图

用户注册涉及到的主要后端功能函数：

用户注册接口，如表4.9。

其中医疗机构代码可以通过机构名称搜索获得或者由医生自主填写，需要提供根据名称获取机构代码函数，方法简单，此处不做叙述。

表4.9  用户注册

K	V
请求url	/user/register
请求方式	Post
请求参数	请求参数描述
userType	int，用户身份， 1-患者，2-医生
userName	string，用户真实姓名
userPhone	string，手机号
password	string,密码
hospitalID	可选参数，医生要填 int，所属机构代码
返回参数	返回参数描述
result	注册结果 0-成功， 1-失败，手机号注册过 2-失败，未知错误
privateKey	用户私钥

医疗机构注册，需要新建专门的页面。用户注册页面上提供超链接，跳转到医疗机构注册页面。医疗机构注册接口，如表4.10

表4.10  医疗机构注册

K	V
请求url	/user/newHospital
请求方式	Post
请求参数	请求参数描述
hospitalName	string，医院全称
businessLicense	file，营业执照（图片形式）
返回参数	返回参数描述
result	发送结果 0-发送成功 1-已经通过审核 2-提交过申请，审核中 3-判断为非法

4.2.2  用户登录

用户需登录进网站才能看到对应的操作界面。登录需选择身份，填写手机号和密码完成登录操作，登录成功后跳转到对应身份操作界面。

用户登录功能接口如表4.11

表4.11  用户登录

K	V
请求url	/user/login
请求方式	Post
请求参数	请求参数描述
userType	int，用户类别 1-患者，2-医生
userPhone	string手机号
password	string密码
返回参数	返回参数描述
result	0-成功，1-密码错误，2-手机号尚未注册，3-用户失活
userID	用户唯一标识，用于后面用户操作

4.2.3  密钥管理

密钥管理属于用户通用功能，公钥是公开的，当用户之间需要相互通信时，要使用对方的公钥对数据加密；在个人中心界面有密钥管理选项卡，提供查询公钥和生成新密钥对的操作。密钥信息存储结构见表4.8。

查询公钥功能接口，见表4.12

表4.12  查询公钥

K	V
请求url	/user/myPublicKey
请求方式	Get
请求参数	请求参数描述
userID userPhone	两个字段选择一个即可 用户自己查询时，使用userid 其他人查询时，使用手机号
返回参数	返回参数描述
publicKey	用户公钥

用户忘记私钥时，可以选择重新生成密钥对。因为RSA加密算法密钥是成对使用的，公钥加密的数据只有使用对应的私钥才能解密，这就意味着，用之前公钥加密存储在链上的数据，使用新密钥将无法获取，所以选择该功能前要提示用户谨慎操作。

生成新密钥对功能接口描述如表4.13

表4.13  生成新密钥对

K	V
请求url	/user/generateNewKey
请求方式	Get
请求参数	请求参数描述
userID	int，用户id
返回参数	返回参数描述
publicKey	新生成公钥
privateKey	新生成私钥

4.3  医生功能设计

本系统是医疗存储系统的简易系统，并不涉及现实医疗就诊系统中复杂的看病治疗环节。以电子病历为中心，本系统设计实现的功能包括医生个人信息管理，查看与修改信息，电子病历管理，为患者建立和更新病历的功能，最后是请求授权查看患者的病历功能。如果后续有新的需求出现，属于医生特有的功能均可以方便的添加到此模块中。

模块涉及的本地Mysql数据库表：

授权信息表t_authorize，如表4.14

表4.14  授权信息表

字段	类型	描述
apply_id	int	授权序号，主键自增
user_id	int	授权人
to_user_id	int	被授权人
apply_state	tinyint	授权状态 0-未授权，1-已授权，2-已拒绝
apply_date	datetime	授权时间
description	varchar(255)	授权内容，这里指的是病历信息
sign_text	varchar(255)	签名信息

模块涉及的区块链数据存储结构：

病历信息表t_medical，如表4.15

表4.15  病历信息表

字段	类型	描述
patient_name	string	患者姓名
doctor_name	string	医生姓名
create_time	string	病历创建时间
medical_picture	string	医学影像图片
description	string	病情描述

4.3.1  管理信息

医生管理个人信息子模块功能包括查询与修改。这里医生个人信息存储结构见表4.7，包括姓名，手机号，头像，医疗机构，实际应用中需要的更多信息处理流程与此类似，此处不做过多处理。医生选择个人中心选项卡，直接显示个人信息，要修改时，直接在对应栏目输入最新的信息，点击提交按钮，更新个人信息。

涉及到的后端主要功能函数：

医生查询个人信息接口，如表4.16

表4.16  查询个人信息

K	V
请求url	/doctor/myInfo
请求方式	Get
请求参数	请求参数描述
doctorID	int，医生id
返回参数	返回参数描述
doctorName	名字
doctorPhone	手机号
doctorPicture	头像地址
hospitalName	所属医院名称

修改个人信息时，只提交修改的内容。修改个人信息功能接口，如表4.17

表4.17  修改个人信息

K	V
请求url	/doctor/alterInfo
请求方式	Post
请求参数	请求参数描述
doctorID	int，医生id
doctorName	string，姓名
doctorPhone	string，手机号
doctorPicture	file，头像
hospitalID	int，所属医疗机构代码
返回参数	返回参数描述
result	修改结果 0-成功，1-手机号已存在，2-未知错误

4.3.2  处理病历

医生处理病历的操作包括为患者新建病历与为患者更新病历，这两个操作都是在医生为患者治疗结束后根据治疗结果生成的新病历，而且存储到区块链上的数据具有可不篡改性，所以此处的更新病历操作仍然可以看做是新建病历。完整的新建病历操作流程如图4.7所示。

图4.7  建立病历

本模块给出医生建立电子病历功能，用户验证以及调用链代码上链过程4.4节说明。

医生新建电子病历x，使用本人私钥对x签名得到x’，再用患者公钥对x’进行加密得到密文x”，将x”发送给病例所有者。患者收到医生新建并处理后的电子病历x”，首先使用自己的私钥进行解密得到签名明文x’，再使用医生的公钥验证签名的正确性，签名正确则查看病历的正确性。

一旦上述验证操作中任何一个步骤出现问题，如病例所有者密钥不能解密x”，或者医生公钥验证x’签名出现错误，电子病历数据都将被丢弃。只有一切处理都正确，才认为病历是正确的。之后，病历所有者使用自己的公钥加密电子病历x得到密文(x)，之后将(x)作为参数发送给区块链智能合约（链代码），智能合约调用putstate()方法将数据存储到区块链中。

病历信息存储结构见表4.15。

建立电子病历功能接口，见表4.18

表4.18  建立病历

K	V
请求url	/doctor/createMedical
请求方式	Post
请求参数	请求参数描述
doctorID	int，医生ID
patientPhone	string，患者手机号
medical.doctorName	string，医生姓名
medical.patientName	string，患者姓名
medicalFile	multipartFile，医学影像图片
medical.description	string，病情描述
doctorPrivateKey	string，医生私钥
返回参数	返回参数描述
result	建立结果，0-成功，1-失败

4.3.3  申请授权

医生想要查看患者的病例记录，需要得到病例所有者的授权，授权方式可以分为两种，单个授权和批量授权，这里提供单个授权的申请，就是申请查看最新的病历。

医生申请授权的数据流程图如图4.8

图4.8  申请授权

医生向某个患者申请授权，需要填入相应患者的手机号，根据手机号可以获取病例所有者ID。因为区块链网络中的状态数据库是以key-value形式存储病历的，key就是病例所有者ID，智能合约中的getstate()方法可以通过患者id获取电子病历，将得到的密文存储到授权申请表中。患者登录系统查看待授权列表，同意授权后，使用本人私钥将对病历进行解密，再使用医生公钥进行重加密，这样医生就可以通过自己的私钥查看到患者病历明文。授权申请表结构见表4.14。

涉及到的后端主要功能函数：

医生申请授权功能函数接口，见表4.19

表4.19  申请授权

K	V
请求url	/doctor/applyAuthorize
请求方式	Get
请求参数	请求参数描述
doctorID	int，医生id
patientPhone	string，患者手机号
返回参数	返回参数描述
result	0-成功，1-患者不存在，2-患者无病例信息，3-未知错误

医生查看已通过授权列表功能函数，见表4.20。未授权与已拒绝功能处理逻辑类似，这里不再赘述。

表4.20  查看已授权列表

K	V
请求url	/doctor/authorizedList
请求方式	Get
请求参数	请求参数描述
doctorID	int，医生id
doctorPrivateKey	string，医生私钥
返回参数	返回参数描述
applyID	授权序号
userName	授权人
applyDate	授权日期
patientName	病历上患者名字
doctorName	病历上医生名字
createTime	病历创建时间
medicalPicture	病历影像图片
description	病历病情描述

4.4  患者功能设计

本系统主要想解决的是电子病历的存储与共享问题，患者作为病历所有者，其实现的功能主要也是以电子病历为中心，包括个人信息管理、病历管理以及授权管理三方面。下面就这三方面功能展开详细设计。

4.4.1  管理信息

与医生类似，患者的个人信息管理模块也包含查询个人信息与修改个人信息两部分，而且对可知，二者的功能在逻辑实现上大体相同，只是患者个人信息不包含医生的所属医疗机构这一属性。

患者信息存储结构见表4.6，患者个人信息管理功能具体实现可参考4.3.1小节，医生个人信息管理模块，因其数据流程与逻辑实现大体相同，此处不再赘述。

4.4.2  管理病历

患者管理病历的功能包括上传病历与查询病历。其中上传病历的功能属于医生为患者建立病历的功能的后续功能。患者验证电子病历的正确性，确认没问题，可以提交到区块链网络中。生成病历完整流程参考医生功能模块4.3.2小节：处理病历，完整流程图见图4.3：建立病历。此处不再过多叙述。

患者查看待确认病历，如表4.21

表4.21  待确认病历

K	V
请求url	/patient/needConformMedical
请求方式	Get
请求参数	请求参数描述
patientID	int，患者id
patientPrivateKey	string，患者私钥
返回参数	返回参数描述
applyID	确认序号
userName	建立病历医生
applyDate	提交确认时间
doctorName	病历诊治医生
createTime	病历创建时间
medicalPicture	病历影像图片
description	病历详细描述

患者上传病历功能接口，如表4.22

表4.22  上传病历

K	V
请求url	/patient/uploadMedical
请求方式	Post
请求参数	请求参数描述
applyID	int，确认序号
patientID	int，患者id
patientPrivateKey	string，患者私钥
返回参数	返回参数描述
result	0-成功，1-私钥错误，2-区块链网络错误，3-未知错误

链代码上传病历核心函数实现，uploadMedicalRecord()，如图4.9

图4.9  链代码上传病历

查询病历，查询病历是患者特有的功能，分为查询最新病历和历史病历，这里查询历史数据是指查询存储在账本上的所有的历史病历记录。

患者查询病历功能接口如表4.23：

表4.23  查询病历

K	V
请求url	/patient/inquireMedical
请求方式	Get
请求参数	请求参数描述
type	int，查询类型，1-最新病历，2-历史病历
patientID	int，患者id
patientPrivateKey	string，患者私钥
返回参数	返回参数描述
result	0-成功，1-私钥错误，2-未知错误
size	历史病历条数
patientName	患者姓名
doctorName	诊治医生姓名
createTime	创建时间
medicalPicture	医学影像图片
description	病情描述

链代码获取患者历史病历核心函数实现，getAllHistoryRecordbyID()，如图4.10

图4.10  链代码获取历史病历

4.4.3  管理授权

患者作为病历所有者，拥有对本人病历管理授权的能力，包括，查询授权、允许或拒绝授权和取消授权几个方面。

用户管理授权主要使用的是本人的私钥进行权限确认，如果用户更新过密钥对，并且存在以往病历，那么这些历史病历的授权需要患者提供历史私钥，如果提供的私钥与当时加密公钥不对称，那么将不被允许查看与授权。为了避免患者因丢失私钥造成的病历丢失现象，不建议患者频繁更换密钥，应该自始至终保存好一份密钥对，以维护自己的权益。

患者管理授权的功能属于医生申请授权功能的后续操作，授权处理完整流程参见医生功能模块4.3.3小节：申请授权。授权管理流程图，见图4.4 申请授权。

涉及到的主要功能函数：

病历所有者主动向医生发出授权查看某特定病历功能接口，见表4.24

表4.24  新建授权

K	V
请求url	/patient/newAuthorize
请求方式	Post
请求参数	请求参数描述
userID	int，病例所有者id
toUserPhone	string，被授权医生手机号
patientName	string，病历患者姓名
doctorName	string，病历诊治医生
createTime	string，病历创建时间
medicalPicture	string，病历医学图片
description	string，病历病情描述
返回参数	返回参数描述
result	0-投放成功，1-投放失败

病历所有者查询授权列表功能接口，见表4.25

表4.25  获取授权列表

K	V
请求url	/patient/authorizeList
请求方式	Get
请求参数	请求参数描述
patientID	int，患者id
patientPrivateKey	string，患者私钥
返回参数	返回参数描述
applyID	授权序号
toUserName	申请授权的医生
applyState	授权状态 0-未授权，1-已授权，2-已拒绝
applyDate	授权日期
patientName	病历患者信息
doctorName	病历诊治医生
createTime	病历建立时间
medicalPicture	病历医学图片
description	病历病情描述

病历所有者处理授权功能接口，见表4.26

表4.26  处理授权

K	V
请求url	/patient/dealAuhorize
请求方式	Post
请求参数	请求参数描述
applyID	int，授权序号
patientID	int，病历所有者id
patientPrivateKey	string，病历所有者私钥
dealType	int，处理类型 1-同意，2-拒绝，3-删除
返回参数	返回参数描述
result	结果 0-成功，1-失败

4.5  本章小结

本章是系统的核心设计与实现。结合系统功能性需求分析，对管理员功能、通用功能、医生功能与患者功能四个方向分模块进行详细设计与实现。以流程图的形式对建立病历与授权管理的操作步骤和数据传输进行详细说明。通过实现后端业务逻辑，编写链代码与区块链网络交互，构成了一个简易的基于区块链的医疗记录的存储系统。

5  测试维护

系统测试是十分必要的，是对软件正式使用前的进行的功能检查。模拟软件运行，模拟实际使用中可能出现的各种场景，包括正常请求响应，出现异常的处理等。测试过程要考虑全面，对照系统的功能需求和实际完成情况，设计详细的测试用例进行测试并分析结果，将可能出现的错误控制在可接受的范围内，以保证系统在实际运行中的正确性。

本系统的定位是基于区块链的医疗记录存储系统，重点在于患者的医疗数据存储与授权管理，可以看做是实际医疗系统中的一个子功能系统实现。本章首先给出系统运行环境，然后针对第四章详细设计中每个模块具体实现的功能，进行功能单元测试，对比预期结果和实际结果，得出测试结论。

5.1  系统运行环境

系统开发中使用的编程语言，相关技术框架，如表5.1

表5.1  系统环境

centos	7.8
go	1.14
docker	19.03
docker-compose	1.25
fabric	2.1
java	1.8
spring	4.x
mybatis	3.4
mysql	5.7
tomcat	9

5.2  系统功能测试

系统功能测试面向系统实现的功能单元进行测试，从开发模块的角度，主要分为管理员功能测试，通用功能测试与用户功能测试。

5.2.1  管理功能测试

管理员功能测试用例如表5.2所示：

表5.2  管理员功能测试用例

测试用例编号	测试功能	测试描述	预期结果	是否通过
T-1	审核医疗机构	首先注册一个新的医疗机构 管理员查看待审核医疗机构列表，反馈审核结果	查看数据库医疗机构状态，为审核通过	Y
T-2	查看系统 总用户数	管理员查看系统总用户数	返回系统总用户数n	Y

5.2.2  通用功能测试

系统通用模块功能测试用例如表5.3所示：

表5.3  通用功能测试用例

测试用例编号	测试功能	测试描述	预期结果	是否通过
T-1	用户注册	输入用户名、手机号、密码信息，传入注册接口	产生新用户	Y
T-2	用户注册	输入与T-1相同手机号	注册失败 手机号已注册	Y
T-3	用户登录	用户输入正确手机号、密码	返回登录成功状态码	Y
T-4	用户登录	输入任意错误的手机号、密码	登录失败，显示手机号或密码错误状态码	Y
T-5	修改个人信息	依次触发一下接口 查看个人信息X1 修改个人信息X2 查看个人信息X3	X3 != X1 X3 == X2	Y
T-6	生成新密钥对	依次触发一下接口 查看密钥X1 生成新密钥对 查看密钥X2	X2 != X1	Y

5.2.3  用户功能测试

系统中设计的医生和患者的很多功能操作具有先后顺序性，所以这里将医生和患者的功能放到一起进行测试。医生与患者相关功能测试用例如表5.4所示

表5.4  医生和患者功能测试用例

测试用例编号	测试功能	测试描述	预期结果	是否通过
T-1	新建病历	医生新建病历X1 患者审核并提交 患者查询病历X2	X2 == X1	Y
T-2	申请授权	医生申请授权 患者允许授权	医生可以查看到病历	Y
T-3	申请授权不通过	医生申请 患者不通过	医生不能查看病历	Y
T-4	患者主动授权	患者查看个人病历 选择病历授权给指定医生 医生查看病历	医生能看到病历明文	Y
T-5	患者管理授权	患者查看已授权列表 取消X医生权限	X医生不能再访问	Y

5.3  本章小结

本章分别从管理员功能、用户通用功能和医生患者联合功能三方面对系统实现的功能编写测试用例。实际开发过程中是边开发边测试，边测试边修改，测试贯穿整个开发过程，这里是对主要功能测试的总结。测试结果表明，系统基本实现了既定的功能。单元测试保证了相关模块功能的可靠性和完整性，也使得程序的健壮性得到了保证。

结    论

本论文研究开发一个基于区块链的电子医疗记录系统。首先对现有中心化医疗存储系统存在的问题进行分析，通过参考文献查找国内外区块链在电子医疗系统的应用研究现状，通过对比现阶段各研究人员提出方案的优劣性，结合自身能力，设计出本文基于Hyperledger Fabric的解决方案。

系统用户分为三类，管理员、医生和患者。与传统中心化系统不同，这里的管理员并不具有所有的权限，其作为系统的开发人员与维护人员，主要工作是保证系统环境稳定运行，根据用户反馈不定期提供软件更新，保证软件功能的完整无误，类似于比特币基金会相对比特币的作用。系统中医生负责为患者看病治疗，并根据诊疗过程与结果为患者简历电子病历，但电子病历是患者的私人数据，其所有权归患者所有，医生虽为病历生产者，却也必须得到患者授权才能查看病历数据。有效实现了病历数据的安全存储与共享。

系统主要实现逻辑功能，通过postman测试软件向后端发送测试请求，后端接受请求处理业务逻辑，将电子医疗等隐私数据通过调用Fabric链代码存储到区块链网络中，而登录信息等通常数据存储在本地mysql数据库中。本系统使用区块链存储电子病历解决了存储中心化的问题，但网页客户端登录操作的方式还是依赖于后端中心服务器，没有实现完全的去中心化控制。一个可解决方案是使用独立的软件客户端代替网页客户端进行操作，由各大医疗机构维护fabric服务器，每个用户看做一个节点，分配一个唯一的密钥对标识身份，节点以点对点的方式进行通信。在P2P的网络中，各个节点可以通过独立的信道与fabric网络通信，进行数据发送、接收、响应和处理，不需要通过中心服务器，不需要登录，也不需要维护个人信息，只需要保存好一对密钥即可。

本系统可以看做是真实医疗系统的一个电子医疗存储子系统，不涉及处理现实治疗过程中复杂的场景，旨在为区块链在医疗记录存储领域的研究提出一种解决思路，证明其可行性。但使用区块链存储医疗数据这种模式不会一开始就得到社会的广泛支持，这是一个缓慢的积累过程。可以从以下三方面分析：

（1） 区块链技术本身。区块链技术在医疗领域的未来发展很大一部分取决于其自身的发展与成熟，若能够在基础技术上取得突破，相应的应用也能够得到推广。相较于区块链技术，电子医疗概念则更为成熟。在医疗服务领域中，可以将区块链视作为一种辅助手段，作为辅助手段的基础技术若不够完善，其对电子医疗的作用是不能保证的，这可能导致两者的互相试错和牵制。

（2） 用户接受程度。区块链技术是全新的技术，很多人并不熟悉其技术原理甚至不了解其概念本质，由人性中普遍的不愿改变心理造成了天然的对新技术的自动屏蔽。特别是对区块链网络的公开透明性，很多患者可能会对这种公共世界的中的匿名性产生抵制，不愿意在公开的互联网世界纰漏个人信息。导致大多数人并不愿意主动去接受其应用。

（3） 实际应用中的问题。虽然目前已经有人研究将区块链应用到医疗系统中证明其可行性，但大多数研究还停留在理论分析上，真正落实到现实中的应用很少。这是因为缺少标准协议与相关法律文件的支持。需要建立一个开放的医疗系统标准，各医疗机构遵循统一的多方协议，保证医疗记录在不同医疗机构间的数据兼容性和共享性。另外政府部门需要出台相关法律文件，将区块链应用涉及到的实际纠纷问题纳入法律范畴，提高公信力。

对于一种颠覆性的技术，用过去的知识体系来评价它显然有失公允，因为其诞生本身就是为了打破过去的框架，创造新的技术架构与商业模式。现在的互联网是信息传播网络，信息传播方便，但价值交换是不方便的，下一代互联网是价值交换网络（internet of value）。区块链技术在信息与价值互联网中的存储和共享应用领域的美好愿景是不可否认的，但在实现或者探索这个愿景的时候，需要不断的尝试，不断的尝试，才能对其有更好的把握。

基于区块链的医疗记录存储系统研究与开发相关推荐

1. 基于区块链的医疗数据共享系统

   #个人的想法形成文章,借鉴或参考请注明出处,谢谢合作 基于区块链的医疗数据共享系统 I. Abstract 随着大数据时代的到来,数据已经成为重要的资源,发挥数据价值的关键在于数据流通.但是,由于隐私 ...

2. 塞浦路斯债务危机_唯链在塞浦路斯医院引入了基于区块链的医疗数据管理平台...

   塞浦路斯债务危机 Blockchain possesses incredible potential, that's why blockchain systems are considered as ...

3. WDK学习笔记_基于区块链溯源系统的后端接口开发

   文章目录 摘要 一.fabric-go-sdk各个封装函数的功能介绍 1.1 查询指定节点通道是否已经存在(函数: QuerySavedChannel(...) ) 1.2 创建并加入通道(函数: C ...

4. 基于区块链构建的农产品溯源系统开发

   在农业产业中,产品的存储与管理一直是重中之重,而区块链能够创新地解决这些问题. 基于区块链构建的农产品溯源系统,将农产品从采购原材料.种植.加工.物流运输.零售商到消费者餐桌的整个流程中产生的相关信息 ...

5. 基于区块链的nft盲盒游戏开发

   盲盒原来是一种年轻人的新潮玩具,在盒子里面装一些特殊表情.稀有卡牌等玩具,这些玩具都具有一定的收藏价值.消费者在打开盒子之前,并不能知道盒子里装的究竟是哪一款玩具,也正是这种未知性让很多年轻人对盲盒欲 ...

6. 基于区块链技术的数据资产管理机制研究

   点击上方蓝字关注我们 基于区块链技术的数据资产管理机制研究 赵明1, 董大治2 1 海军装备部,北京 100841 2 中国人民解放军91001部队,北京 100841 摘要:使用区块链技术可以保证数 ...

7. 基于区块链的链上数据安全共享体系研究

   点击上方蓝字关注我们 基于分层注意力网络的方面情感分析 刘彦松1, 夏琦1, 李柱1, 夏虎1, 张小松1, 高建彬2 1 电子科技大学计算机科学与工程学院,四川 成都 611731 2 电子科技大学 ...

8. SSM基于区块链的物联网数据交易 计算机毕业设计源码46193

   摘  要 物联网技术作为继互联网技术后新一代的通信信息集成应用的典范,其巨大的应用前景受到了学术界和政商界的广泛关注.物联网技术在一些传统行业已经有了很深入的应用,例如,其在商品生产信息溯源.环境监测 ...

9. 深度分析|DEVITA：一个基于区块链技术和Web3生态打造的先进数字医疗平台

   数字化工具正在延展至医疗行业成为其服务的关键部分,且推动着整个社会的发展进程.越来越多的人们开始倾向于更低成本的数字解决方案,而非传统的电话咨询或预约.挂号或面诊.尤其是在 COVID-19 的影响下 ...

最新文章

1. html代码在线运行环境,ES5/可执行代码与执行环境
2. Python入门：正则表达式
3. （转）Maven之自定义archetype生成项目骨架
4. Android官方开发文档Training系列课程中文版：调用相机之简单摄像
5. 萌新学python(输入与输出)
6. chrono0.10插件离线版_梁宝川：这11条anki插件的使用常识分享给你
7. jQuery LigerUI API预览版发布
8. opencv4版本和3版本_Spring Boot 太狠了，一口气发布了 3 个版本！
9. python类方法为装饰器_类方法的python装饰器
10. 12-Solidity8.0-view和pure区别
11. z-index诡异事件之背锅侠
12. #读书笔记#《富爸爸窮爸爸》 | Rich Dad Poor Dad 罗伯特.清崎 Robert Kiyosaki
13. 最新软件云测试方法你知道多少？有什么好处
14. 【NA】函数最佳逼近(二)勒让德多项式
15. 中国服务器连通状态,ppp服务器连通状态显示失败怎么办？
16. magento添加sku_快速提示：如何将优惠券添加到Magento电子商务商店
17. Mangopi MQ-R：T113-s3编译Tina Linux系统（二）SDK目录
18. DSA签名简介及对其的攻击方式
19. 知衣科技：夫妻搭档，创业是件骨子里的事
20. IPGuard启动加密常用的策略

热门文章

1. elementui 计数器动态渲染无法点击
2. ISELED---氛围灯方案的新选择
3. 数字电网的定义、内涵和特征
4. 3D轮廓渲染中的几种轮廓边
5. 手机与linux ubuntu电脑互传图片文件的方法
6. 《比尔总动员》富丽场景流出，展示奥妙科幻国际
7. 数据中心 电力监控系统的设计与应用
8. simulink添加模型库的方法
9. 基于SSH的二手物品拍卖系统
10. android pulldown view,Android控件PullRefreshViewGroup实现下拉刷新和上拉加载