《基于区块链的医疗记录存储系统设计》18000字（论文）

IV基于区块链的医疗记录存储系统设计摘要医疗记录是具有高度私密和有价值的数据，所以它的存储和共享面临着巨大的挑战。现有的医疗记录存储系统大都是将数据存储在中央数据库中，而这种中心化存储模式面临着信息安全、数据共享等问题。区块链技术的出现为解决现有医疗记录存储系统存在的问题提供了新的思路，因其具有去中心化、不可篡改、安全可信等特性，可用于解决现有医疗记录存储系统医疗面临的上述问题。本文介绍了一个基于区块链的电子医疗记录存储系统。该系统以web客户端的形式呈现，使用SSM框架与MySQL实现后端业务逻辑，区块链部分基于Hyperledgerfabric框架实现，使用java语言开发链码。该系统基于区块链技术的天然特性，结合Hyperledgerfabric框架的数据加密功能和自增的授权功能，使得患者拥有自己医疗记录的绝对控制权，其他人需获得患者授权才可访问其医疗记录，解决了传统医疗记录存储系统的安全存储和隐私保护问题。本系统结合了web客户端和区块链存储技术，借助区块链去中心化和不可篡改等特性实现了医疗记录的安全存储和共享，解决了采用中心化存储模式的医疗记录存储系统的存储共享安全和数据控制权错位问题，是区块链技术在医疗领域应用的一次尝试。关键词：区块链；医疗记录；安全存储；共享目录摘要 [17]。Fabric的共识机制主要包括背书、排序、校验三个阶段，具体如图2-3所示。图2-3Fabric交易过程/共识过程Figure2-3Fabrictransactionprocess/consensusprocess背书：客户端首先将交易提案提交到指定的背书节点，背书节点收到交易提案后对其进行验证签名，然后对交易提案进行模拟执行，执行完毕后将背书结果和证书签名一同发给客户端；不同的背书策略规定了客户端在收到一定数量的提案同意反馈后，才认为该交易是有效的。排序：排序节点将一个时间段内收到的所有交易按时间顺序进行排序，然后将排好序的交易打包成数据块，再将这些打包好的区块广播给通道中的所有成员。校验：提交节点在接收到由排序节点发送来的交易后，首先对交易进行验证，包括检查交易签名是否正确、交易数据是否完整以及是否满足背书策略等。区块链中只有通过校验的交易才被认为是合法的，才可以将其将其写入账本。2.3web技术框架本系统web开发采用SSM框架。SSM框架是以标准的MVC模式将springMVC，spring和mybatis框架进行了整合，它是一种适用于搭建大型应用系统的轻量级JavaEE开发框架。Spring是为了解决企业应用开发的复杂性而创建的一个开源框架。Spring使用基本的JavaBean来完成以前只可能由EJB完成的事情。

简单来说，Spring是一个轻量级的控制反转（IoC）和面向切面（AOP）的容器框架。SpringMVC是SpringFramework系列产品，MVC是一种由模型层（Model）、视觉层（View）、控制层（Controller）三部分组成的应用程序分层开发模型。MyBatis是一个基于Java的持久层框架，作为数据对象的持久化引擎，它对jdbc的封装让数据库底层操作变的透明。mybatis的操作都是围绕一个sqlSessionFactory实例展开的。

需求分析本章系统需求分析主要从功能性需求和非功能性需求两方面进行了分析。首先简要阐述了系统的整体需求，然后围绕系统的整体架构对各个模块进行了详细的需求分析，并结合用例分析图和功能描述表对各模块涉及的参与角色及其功能进行详细说明。最后从系统的安全性、可扩展性以及可用性等方面说明了系统的非功能性需求。3.1系统需求概述随着互联网的发展，医疗行业也趋于信息化。电子病历逐渐取代了传统的纸质医疗记录，解决了保存管理麻烦、检索不便的问题。但是现有的电子医疗记录存储系统大都采用中心化的数据存储模式，将医疗机构的医疗数据存储在某一中心数据库中，然而这种中心化的存储模式面临着数据安全和隐私安全的问题，一旦中央数据库遭到恶意攻击，患者的医疗记录将面临被盗取和篡改的威胁，而这将极有可能导致患者在医疗纠纷中处于不利地位，使得患者的合法权益无法得到充分保障。而且各医疗机构之间的数据存储格式可能有所差异，这将容易导致信息孤岛问题，使得各医疗机构之间无法共享患者医疗记录，对病人的跨院治疗带来一定的不便。本系统借助区块链技术，结合HyperledgerFabric框架和web客户端，针对现有的电子医疗记录存储系统的痛点问题，开发一个可以安全存储、数据共享的医疗记录存储系统。由于区块链技术天然的去中心化、不可篡改、信息可溯源等特性，保证了患者的医疗记录存储的安全性；同时区块链可以将不同机构之间的医疗数据通过同一格式存储在链上，解决了数据共享难的问题，为患者的跨院治疗带来了便利；系统的参与者有医生、患者、科研机构、疾控中心，它们只有获得授权才能查看患者的医疗记录，同时存储在区块链中的医疗记录无法被篡改，具有公信力，能够在医疗纠纷中协助定责，确保公平性。3.2系统功能性需求系统的参与者有系统管理员、患者、医生、科研机构、疾控中心，他们在系统中拥有平等的地位，彼此之间相互制约、相互合作，共同组成了一个区块链联盟。系统底层借助HyperledgerFabric框架完成，数据采用区块链和本地MySQL联合存储，区块链存储患者医疗记录，MySQL存储用户信息。系统管理员主要负责配置环境、用户注册管理、查看系统运行状态以及用户权限管理等业务，管理员可以审核系统参与者的资格，也可以查看区块链相关的信息，只有通过管理员审核的用户才可以加入该系统。但是在系统运行过程中不允许管理员干涉实际业务逻辑和访问用户隐私数据。医生和患者在系统中拥有平等地位，属于区块链网络中的对等节点，诊治医生根据患者的检查治疗结果为患者生成电子医疗记录，得到患者的确定后将其上链存储；患者本人对自己的医疗记录拥有绝对的控制权，可以通过溯源码或者自己的身份证号查询追溯自己的医疗记录，医生或其他科研人员须得到患者的授权才能访问医疗记录。系统主要从三个方面来保证数据存储的安全性。第一，医生为患者创建病历后，需得到或者的检查确定后才可将其上链存储，这从源头上确保了数据的准确性；第二，患者的医疗记录存储在区块链上，作为分布式的账本，区块链技术天然的不可篡改性保证数据的安全存储和不被篡改；第三，出患者之外的所有用户必须得到患者本人的授权才能访问其医疗记录，这保证了患者对自己医疗记录的绝对控制权和共享时的隐私性。而且系统使用非对称加密技术对系统中的数据进行安全加密，实现了数据的安全存储和安全共享。3.2.1系统整体架构系统的整体架构分为四个模块：系统管理模块、医生模块、患者模块、疾控中心模块。如图3-1所示，将在下文对各模块的具体功能进行详细叙述。图3-1系统整体架构Figure3-1Overallsystemarchitecture3.2.2系统管理在该系统中，系统管理员与传统管理员不同，它没有所谓的上帝视角，它只是负责系统的管理和正常运行，不得干涉系统的业务逻辑或者私自访问数据，这也与区块链的去中心化相呼应。管理员的工作主要包括：搭建系统运行环境，负责用户的注册登录，对加入的医疗机构进行资格审查，查看系统以及区块链部分的运行状态。系统管理员用例图如图3-2所示：图3-2管理员用例图Figure3-2Administratorusecasediagram搭建Fabric环境。本系统的区块链部分是借助HyperledgerFabric框架完成，所以需要先配置Fabric环境，搭建区块链网络。在HyperledgerFabric网络中，需要先利用联盟链思想进行组织划分，然后根据划分的组织来设置通道，由通道来控制数据访问。主要工作包括配置Order节点、peer节点，划分组织，加入通道，申请数字证书，编写智能合约并将其部署在通道中的peer节点上，客户端便可通过智能合约与区块链网络进行交互。审核医疗机构。医疗机构作为大家信任的机构，主要负责为患者进行病情诊治，然后根据诊疗结果将其生成医疗记录并存储至区块链。为了避免非法机构进入系统，医疗机构加入该系统前需要经过管理员的资格审核，只有通过资格审核的医疗机构才可以加入该系统。查看区块链状态。根据自己搭建的区块链网络，借助Fabric搭建一个区块链浏览器，管理员可以通过该浏览器实时查看区块链网络中所有的区块、交易以及通道等关键信息。3.2.3医生模块医生进行申请注册后可以加入该系统，登录进入系统后，可以进行个人密码修改，还包括以下工作：根据溯源码从区块链查询病历，为患者创建病历并在患者的授权下将病历上传至区块链，查看自己添加过的医疗记录列表。医生用例图如图3-3所示：图3-3医生用例图Figure3-3Doctorusecasediagram医生功能用例分析：建立病历。医生为患者进行治疗后，将治疗过程所涉及的数据进行分类汇总，生成电子病历，待患者对病历进行检查确定无误后由医生将其存储在区块链上。医疗记录包括患者身份证号、溯源码、患者基本信息、科室、病情、治疗时间等。医生为患者建立电子病历功能如表3.1。表3-1建立病历Table3-1Establishmentofmedicalrecords功能名称为患者建立病历功能涉及角色医生功能具体描述医生为患者治疗，将其诊疗结果建成电子病历输入医生对患者的治疗信息输出电子医疗记录查询病历。医生根据患者的溯源码可以直接查看存储在区块链上的患者医疗记录。医生查看患者的医疗记录的功能如表3-2。表3-2查看病历Table3-2Viewmedicalrecords功能名称查看病历功能涉及角色医生功能具体描述医生根据患者的溯源码从区块链上查询患者的医疗记录输入溯源码输出患者的医疗记录申请授权因为医疗记录的所有权归患者所有，所以医生在添加病历时应该向患者申请授权，允许哪些参与者可以查看这个医疗记录，没有得到授权的参与者则无法查看患者的医疗记录。医生申请患者授权的功能表如表3-3。表3-3申请授权Table3-3Applicationforauthorization功能名称申请授权功能涉及角色医生功能具体描述医生向患者申请哪些参与者可以查看其医疗记录输入参与者角色输出是否对其授权3.2.4患者模块医疗记录属于患者的私有数据，其控制权归患者所有，患者应该对自己的医疗记录拥有绝对的控制权，所以在医生创建病历时应申请患者的授权以允许哪些参与者可以查看其医疗记录，只有获得患者授权的用户才可以查看其医疗记录。患者也可以自己根据溯源码查看存储在区块链上的医疗记录。患者模块功能用例如图3-4所示：图3-4患者用例图Figure3-4Patientusecasediagram患者功能分析：查看病历。患者可以随时查看自己的医疗记录，包括用溯源码查看某一次医疗记录和用身份证号查看自己所有的医疗记录。患者查询医疗记录功能如表3-4。

表3-4查看病历Table3-4Viewmedicalrecords功能名称查看病历功能涉及角色患者功能具体描述根据溯源码查看某一次医疗记录；根据身份证号查看所有医疗记录输入溯源码或身份证号输出患者的医疗记录授权管理。因为患者对自己的医疗记录拥有绝对的控制权，所以医生在为患者新建病历时需要向患者申请授权哪些参与角色可以查看其医疗记录，只有获得授权的参与者才能查看其医疗记录。患者授权管理功能表如表3-5。表3-5授权管理Table3-5Authorizationmanagement功能名称查看病历功能涉及角色患者功能具体描述申请患者是否为用户赋予查看其医疗记录的权利输入用户角色输出是否授权3.3系统非功能性需求系统不但要实现功能性需求，也要满足非功能性需求，因为系统的非功能性需求往往是系统稳定运行的关键。系统非功能性需求主要包括安全性需求、可扩展性需求、可用性需求。3.3.1安全性保证数据存储安全是该系统最大的特征之一。医生提交患者的医疗记录时须得到患者的检查确认，从源头上确保了数据的真实性；存储数据时借助区块链天然的不可篡改性，且保存至区块链的数据均为加密后的密文，确保了数据的存储安全；共享数据时需要的得到患者的授权。从以上三个方面确保了该系统的数据安全性。3.3.2可扩展性系统开发各个模块组件应设计为可插拔式，为后续进行功能添加或更改提供便利，且修改某一模块时对其他模块没有影响。3.3.3可用性操作界面应当美观简洁，在输入输出时有明确的提示，为用户的操作提供便捷。

系统设计本章是系统设计，首先对区块链网络拓扑、智能合约、区块链存储进行了详细设计，然后根据系统功能性需求分析，针对各个功能模块分别给出详细设计，包括管理员功能模块、医生功能模块以及患者功能模块。4.1区块链网络设计本系统使用HyperledgerFabric1.4.4版本搭建区块链网络。该网络共包含四个组织，每个组织两个peer节点，另外有一个order节点和四个CA节点，一个通道mychannel。如图4-1为区块链网络拓扑图。图4-1区块链网络拓扑图Figure4-1Blockchainnetworktopologydiagram客户端节点。客户端代表用户最终的操作实体，所以它必须连接到某一个peer节点或者orderer节点上来完成与区块链网络之间的通信。首先客户端向背书节点提交交易提案，背书节点对交易进行模拟执行并对其附加背书，当客户端收集到足够背书后，向排序节点提交交易，排序节点对提交的交易按时间顺序进行排序，打包成区块，广播至所有节点。但是该节点出现故障后并不会影响区块链网络的正常运行。Peer节点。所有的peer节点都担任记账节点，有的peer节点也有可能担任背书节点、主节点以及锚节点的角色。主节点与排序节点进行连接，负责把接收到的区块转发给其他节点。背书节点是与具体的链码绑定的动态角色，它的故障对网络的影响取决于链码对应的背书策略。锚节点是在一个通道上可以被所有其他节点发现的节点。Order节点。orderer负责接收包含背书签名的交易，然后对这些交易按时间顺序进行打包，最后将打包好的区块广播给peer节点。CA节点。CA节点是区块链网络中的证书颁发机构，它是由服务器（fabric-ca-service）和客户端组件（fabric-ca-client）组成的，主要负责对网络中的用户以及交易进行身份验证。fabric网络搭建启动流程包括为各组织生成证书文件、生成创始区块、创建通道配置节点信息和部署合约等内容。最后网络部署成功如图4-2：图4-2网络部署Figure4-2Networkdeployment4.2智能合约设计智能合约是一段部署在区块链上的可以自动执行的计算机程序。在fabric中的智能合约也被称为chaincode或者链码，主要包含系统智能合约和用户自定义合约。Fabric智能合约支持java、go、nodejs三种开发语言，并提供多个API函数接口供开发者使用，其中最主要的是Init、Invoke、main三个接口函数，main函数是智能合约的入口，Init函数是合约初始化函数，在实例化智能合约的时候调用，Invoke函数是触发函数，对智能合约进行除初始化以后的所有操作时都在此函数调用。智能合约的具体部署流程如图4-3所示：图4-3链码部署流程Figure4-3Chaincodedeploymentprocess智能合约的部署流程具体如下：（1）将链码进行打包;（2）将链码安装到各个节点上;（3）组织成员对安装的合约进行审核批准;（4）检查提交的合约是否满足在通道配置中定义的提交策略，该系统定义的背书策略要求超过一半的组织批准即可;（5）合约满足定义的策略后将其提交;（6）调用Init（）方法测试合约。至此，智能合约部署完成。4.3区块链存储设计4.3.1区块结构设计众所周知，比特币系统是将交易信息保存在区块链上，因此大家通常习惯说区块记录的是交易信息，但是并非只有交易信息可以记录到区块链上。在HyperledgerFabric中，所有区块通过hash值进行前后连接，所以它也被称为超级账本，这些区块不止可以存储交易信息，也可以进行数据存储。在本系统中，链上存储的是医疗记录，并非传统的交易记录。病历区块的具体结构如图4-4所示：整个病历区块包含区块头和区块体两部分。图4-4病历区块结构Figure4-4Medicalrecordblockstructure病历区块头部具体结构如表4-1所示，其中大部分信息与传统区块链中的区块头信息相同，最大的区别在于MerkleRoot，这里的MerkleRoot是由医疗记录产生的，并非是传统的关于交易记录的。表4-1病历区块头Table4-1Medicalrecordblockheader字段字段说明Block_ID区块的编号Block_Size区块的大小PrevHash前一个区块的hash值This_Hash当前区块的hash值TimeStamp时间戳MerkleRoot医疗记录的Merkle根病历区块体包括代表病历记录数量的MRnum、表示病历记录的MR*以及MR*之间的hash值，其中病历记录的具体结构如表4-2所示：

表4-2医疗记录结构表Table4-2Thestructureofmedicalrecords字段类型描述Patient_nameString患者姓名Doctor_nameString医生姓名IDString患者身份证号SexString性别DeskString科室DescriptionString诊断详情Creat_timeString病历创建时间Discharge_timeString出院时间moneyint花费金额4.3.2数据库设计本系统数据存储分为区块链存储和本地MySQL数据库存储。MySQL主要存储用户以及医疗机构信息，区块链进行患者医疗记录的存储，本系统选用CouchDB作为状态数据库来存储医疗记录数据，CouchDB是一个完全局域RESTfulAPI的键值数据库，它可以通过HTTP请求直接操作数据库。本文搭建了一个区块链浏览器，通过该浏览器可直接查看区块链的数据存储情况以及交易的具体信息。CouchDB中的主要字段如表4-3所示：表4-3CouchBD数据库字段Table4-3CouchBDdatabasefields字段字段类型类型描述IDkeyString患者IDNamevalueString患者姓名AgevalueString患者年龄SexvalueString性别DeskvalueString科室DescriptionvalueString诊断详情Creat_timevalueString病历创建时间Discharge_timevalueString出院时间DoctorvalueString诊治医生在CouchDB数据库中，字段id作为key值存储，其他信息作为v值存储。系统可根据ID在区块中查询数据。4.4管理员功能模块设计此模块对应的是管理员功能设计，主要包括用户注册、医疗机构审核。4.1.1用户注册管理用户进入系统首先要进行注册，将用户的注册信息存储至本地MySQL数据库，管理员可以为用户分配角色。用户登录时从MySQL数据库中进行检索，若有该用户便允许登录，若不存在则进行注册方可登录。用户注册登录设计到MySQL数据库的用户信息表和用户数量自增表，具体如下：表4-4用户自增量表Table4-4Userself-incrementtable字段类型描述User_numInt用户数量，主键，自增Last_timedatatime更新时间表4-5用户信息表Table4-5Userinformationtable字段类型描述User_idint用户ID，主键Namevarchar(30)姓名Passwordvarchar(30)密码Rolevarchar(30)角色Sexvarchar(10)性别ageint年龄4.1.2医疗机构审核医疗机构具体信息存储在本地MySQL数据库中，具体存储结构见表4-6：表4-6医疗机构表Table4-6ListofMedicalInstitutions字段类型描述hospital_idint医院机构代码，主键hospital_namevarchar(32)医院名称hospital_stateint医院状态：1-正常0-待审核2-非法in_datedate提交审核时间审核通过即为审核时间管理员登录进入系统，可以查看待审核的医疗机构列表，根据医疗机构的具体信息进行资格审核，审核通过的医疗机构才可加入该系统，然后管理员为审核通过的医疗机构申请查看患者医疗记录的权限，只有获得查看权限的医疗机构才可查看患者的医疗记录。资格审核主要分为两个步骤：首先要获取待审核机构列表，该请求会输出一个待审核机构list，如表4-7：表4-7待审核机构列表Table4-7Listoforganizationstobereviewed请求参数无返回参数返回参数描述Hospital_ID医院IDHospital_Name医院名称inDate申请时间根据查询到的待审核结构信息，管理员可以给出审核结果，通过或者不通过，改变数据库中医疗机构的状态，如表4-8表4-8审核医疗机构Table4-8Reviewofmedicalinstitutions请求参数请求参数描述Hospital_ID医院IDHospital_State审核结果1-合法，2-非法返回参数返回参数描述result修改是否成功0-成功，1-失败4.5医生功能模块设计医生的主要功能包括个人信息管理、为患者建立病历以及申请授权查看患者的医疗记录。4.5.1建立病历医生为患者进行诊疗后，将患者的诊断结果生成电子医疗记录，在经过患者的检查确定无误后将其存储至区块链上，其中病历信息存储结构见表4-2：建立电子病历功能接口，见表4-9：表4-9建立病历Table4-9Establishingamedicalrecord请求参数请求参数描述Doctor_ID医生IDDoctor_Name医生姓名Patient_Name患者姓名description病情描述返回参数返回参数描述result建立结果，0-成功，1-失败4.5.2管理信息医生管理个人信息模块功能包括查询与修改。医生个人信息存储结构见表4-10：表4-10医生信息表Table4-10DoctorInformationTable字段类型描述IDstring医生身份证号，主键NameString姓名DaskString科室hospitalString医院医生需要修改个人信息时，直接在对应的框里输入新的信息，提交即可。涉及到的主要功能函数：医生查询个人信息接口，如表4-11所示：表4-11查询个人信息Table4-11Querypersonalinformation请求参数请求参数描述doctorIDint，医生id返回参数返回参数描述Doctor_Name姓名Hospital_Name所在医院名称Dask科室Phone联系方式4.6患者功能模块设计患者是医疗记录的所有者，其主要功能包括个人信息管理以及查看个人医疗记录。4.6.1管理个人信息与医生相似，患者的个人信息管理模块也包括信息查看与修改两部分，患者的信息存储结构见表4-12。因其数据流程与逻辑实现和医生大体相同，此处不再赘述。表4-12患者个人信息表Table4-12PatientPersonalInformationTable字段类型描述IDstring患者身份证号NameString姓名AgeString年龄sexString性别4.6.2查询病历患者可以根据溯源码查询某一次具体的病历，也可以根据身份证号查询自己所有的病历。患者查询病历功能接口如表4-13：表4-13查询病历Table4-13Querymedicalrecords请求参数请求参数描述type查询类型，溯源码-最新病历，ID-历史病历patientID患者id返回参数返回参数描述result0-成功，1-私钥错误，2-未知错误Patient_Name患者姓名Doctor_Name诊治医生姓名Create_Time创建时间description病情描述

系统测试系统测试是对系统正式使用前进行的功能检查，模拟系统实际使用中可能出现的各种场景。本章先介绍了系统开发使用的相关编程语言以及技术框架，然后就系统的管理员功能模块、医生功能模块和用户通用功能模块进行了测试。5.1系统运行环境系统开发过程中所使用的编程语言以及相关技术框架见表5-1：表5-1系统运行环境Table5-1Systemoperatingenvironment名称版本虚拟机VMware-workstation14.x操作系统Centos7.7Go1.17Docker19.04Docker-compose1.25Fabric1.4.4java1.8Spring4.xMybatis3.4Mysql5.85.2系统功能测试系统功能测试是以用户为单位，对系统实现的功能单元进行测试，主要包括管理员功能测试、医生功能测试和系统通用功能测试。5.2.1管理员功能测试管理员功能测试用例如表5-2所示：表5-2管理员功能测试用例Table5-2Testcasesforadministratorfunctions测试用例编号测试功能测试描述预期结果是否通过T-1用户注册管理管理员可以进行用户的注册管理进行用户的添加和删除YT-2用户角色审核管理员可以对系统参与的用户角色进行审核分配用户的角色以及是否可以进入系统Y用户注册管理：管理员可以查看目前系统所有的参与用户，如图5-1：图5-1查看用户信息界面Figure5-1Viewuserinformationinterface可以利用查询功能快速定位到某一具体用户，管理员也可以通过“添加”、“删除”按钮进行新用户的添加和原有用户的删除，添加用户功能如图5-2所示：图5-2添加用户界面Figure5-2Adduserinterface用户角色审核：管理员负责对用户进行审核，包括确定用户角色以及状态，只有通过管理员审核后显示为正常状态的用户才可以使用该系统，管理员也可以将用户的状态设置为禁用，这样该用户将无法使用该系统，具体如图5-3所示：图5-3用户状态管理界面Figure5-3Userstatusmanagementinterface5.2.2医生功能测试医生功能测试用例如表5-3所示：表5-3医生功能测试用例测试用例编号测试功能测试描述预期结果是否通过T-1新建病历医生为患者新建病历新增患者病历YT-2查看自己创建的病历列表医生查看自己为患者添加的所有病历医生查看添加的所有病历YT-3设置病历的查看权限医生进行授权的用户可以查看病历得到授权的用户能够查看病历Y新建病历：医生可以根据患者的就诊情况为患者新建电子病历，并将其提交至区块链保存，具体如图5-4所示：图5-4新建病历界面Figure5-4Newmedicalrecordinterface查看病历列表：医生可以查看自己创建过的所有病历，具体如图5-5所示：图5-5查看所有病历界面Figure5-5Viewallmedicalrecordsinterface设置病历查看权限：医生在为患者创建病历时可以采取患者的意愿，决定允许哪些用户可以查看该病历，只有被允许的用户才可以查看该病历，具体如图5-6所示：

图5-6设置查看权限界面Figure5-6Setviewauthorityinterface5.2.3通用功能测试通用功能模块包括用户修改个人密码和查看电子病历，其中查看电子病历时可以根据溯源码查看某一个具体病历，也可以根据患者身份证号查看该患者的所有病历记录，所有系统参与者都具有修改密码和查看医疗记录的功能，但是只能查看被授权的医疗记录，通用功能测试用例如表5-4所示：表5-4通用功能测试用例Table5-4Commonfunctionaltestcases测试用例编号测试功能测试描述预期结果是否通过T-1修改密码用户修改自己密码密码修改成功YT-2电子医疗记录溯源用户根据溯源码查看某一特定医疗记录查询到特定医疗记录YT-3患者医疗记录溯源用户根据身份证查看某人所有医疗记录查询到某人所有医疗记录Y修改密码：医生、患者、疾控中心、科研机构等所有系统参与者均可使用该功能进行个人密码修改，具体如图5-7所示：图5-7修改密码界面Figure5-7Changepasswordinterface电子医疗记录溯源：根据溯源码查询某一特定的病历，具体如图5-8所示：图5-8电子医疗记录溯源界面Figure5-8Traceabilityinterfaceofelectronicmedicalrecords患者医疗记录溯源：根据患者身份证号查询该患者的所有医疗记录，具体如图5-9所示：图5-9患者医疗记录溯源界面Figure5-9Traceabilityinterfaceofpatientmedicalrecords

结论与展望结论本论文开发了一个基于区块链的医疗记录存储系统。文章首先对现有的采用中心化存储模式的医疗记录存储系统所面临的痛点问题进行了分析，然后通过查阅文献了解了国内外区块链技术在医疗记录存储系统中的研究现状，对比各种方案的优缺点，并结合自身能力，设计出本文基于HyperledgerFabric的解决方案。本系统采用web客户端的形式完成测试，在centos系统中利用HyperledgerFabric技术框架搭建部署了区块链网络，在IDEA中用java进行智能合约以及后端业务逻辑的实现。本文在前人所做研究的基础上，将区块链技术与现有医疗记录存储系统结合起来，针对现有医疗记录存储系统存在的存储共享安全和数据控制权错位等痛点问题提出了自己的解决方案，也是区块链技术在医疗记录存储领域应用的一次尝试。传统的医疗记录存储系统采用的中心化存储模式，这种存储模式面临数据流失和被篡改的威胁，同时各医疗机构数据存储模式的差异造成了数据共享困难，为患者跨院就诊带来不便。利用区块链技术的去中心化、不可篡改等特性，能够解决现有医疗记录存储系统所面临的痛点问题，保证患者医疗数据的安全存储。系统用户分为管理员、医生、患者以及科研机构四类。这里的管理员主要负责维护系统正常运行、查看系统运行状态、进行用户注册管理以及用户权限审核；医生负责为患者创建病历并将之上链存储，同时也可以查看自己添加过的所有病历；科研机构只有获得患者授权才可以查看其医疗记录。系统在区块链技术的基础上，新增授权环节，除患者之外的所有角色需获得患者的授权才可访问其医疗记录，保证了患者对自己医疗记录数据的绝对控制权，解决了传统医疗记录存储系统数据控制权错位的问题。本文基于区块链技术的特性，构建了一个可以安全存储医疗记录的存储系统，实现了医疗数据跨机构、跨平台共享，保证了患者对自己医疗记录数据的绝对控制权，为解决现有医疗记录存储系统的数据共享难、存储安全性差以及数据控制权错位等问题提出了新的思路。展望本系统利用区块链技术的特性，与现有医疗记录存储系统结合起来，针对目前医疗记录存储系统的痛点问题初步提出了自己的解决思路，在区块链与医疗记录存储系统结合的后续研究中，计划从以下方面进行研究：使用IPFS文件系统尝试解决区块链数据存储不足问题；从共识算法、数据并发操作等方面改进区块链存储效率问题。

参考文献Nakamoto S. Bitcoin: A Peer-to-Peer Electronic Cash System[EB/OL]. (2009,02,08).