一种面向分级诊疗的病历数据共享方法*

薛惠丹 李 峰 潘雨青

（江苏大学计算机科学与通信工程学院 镇江 212013）

1 引言

分级诊疗制度［1］作为我国重要的医疗卫生制度，是合理分配医疗资源、促进基本医疗卫生服务均等化的重要举措，是深化医药卫生体制改革，建立中国特色基本医疗卫生制度的重要内容［2］。随着国外分级诊疗模式，尤其“美国模式”、“英国模式”的普遍推广，以及“互联网分级诊疗”中“微医模式［3］”的出现，使得探索并落地国内特有的分级诊疗制度，构建“基层首诊、双向转诊、急慢分治、上下联动［4］”分级诊疗秩序显得尤为重要。

在“互联网+”技术和大数据时代的背景下，数据作为一种价值资源，尤其医疗数据方面，病历数据作为国家档案的重要组成部分，是对患者疾病发生、发展、诊断、治疗、护理、转归等情况的客观和系统的记录［5］，是反映患者整体医疗过程的完整性证明。

随着信息化的相对成熟，一些电子病历系统（EMRS）、医院信息系统（HIS）、基于医学数字成像和通信（DICOM）的相关医疗信息化系统相继出现。虽然解决了部分医疗数据泄漏的问题，但并没有真正实现病历数据的共享。其采用的是基于C/S或B/S 的电子医疗信息系统或者基于云存储的分布式电子医疗信息系统［6～7］，实现数据共享的主要途径是将大量病历数据于各个医疗机构中心化数据库存储及管理。这不可避免会带来一些问题，于患者来说，其一中心化服务器存储，在发生医疗纠纷时，数据易于被篡改、泄露且不留痕迹，使其无法追责；其二患者无法持有对数据的真正拥有权，数据的流向无法掌握，丧失了用户自主权。于医疗机构来说，因医疗机构等级不同、私立公有的影响，在不同医疗机构间的“医院-社区-患者”信息传导机制缺乏联动，造成“数据孤岛［8］”现象，使得医生无法获取完整的诊疗历史，导致无法对患者情况进行全面、准确的分析。所以，如何进行跨机构的数据共享以达到整个病历数据的全流程追溯是分级诊疗中“双向转诊”必须要解决的问题。

而区块链作为一种分布式存储机制，因其自身链式结构和P2P网络而具有的去中心化、不可篡改及可溯源特性，加上密码技术保证了数据完整性和可验证性，为解决数据共享、数据存证、不可篡改等问题提供了一种新的解决思路。

为此，引入区块链技术，针对分级诊疗制度下目前存在的病历数据集中存储、数据易篡改、不可追溯、共享难的问题，本文结合门限秘密共享［9］方案，提出一种面向分级诊疗的病历数据共享方法DP-MDSM（Medical Record Data Sharing Method Based on Data Privacy）。用户作为数据的分享者及拥有者，可以看到数据的整个流程路径；医疗机构作为数据的请求者，不可以直接获得数据，只有经过多个医院共同验证收集达到一定数量的分片才可以恢复出用户病历信息。其中针对数据共享首要存在的安全性问题，设计不同的交易格式，采用非对称密码方法使病历数据以密文在区块上链，以此达到数据的不可篡改以及可溯源性。同时，在保证数据共享的情况下，针对数据共享期间进行的身份验证以及访问量大可能造成的数据访问周期较长的问题，设置区块链验证节点以承担部分可验证计算，保障了信息访问和共享的高可控性和高可用性。

2 相关技术

在区块链技术提供的分布式环境中，存在单点故障或恶意攻击造成的不诚实节点，所以探讨在不可信环境中多节点如何协调工作是研究区块链中数据如何共享的关键性问题；同时由于大部分区块链平台上的数据是对外公开的，任何节点都可以访问区块链上的数据，容易造成区块链的隐私安全问题，所以如何在保证隐私安全的基础上进行验证是密码学研究热点问题。秘密分享与Pedersen 承诺是以上两个问题的可行性解决方案。

2.1 秘密分享

秘密分享，一般也称为(t，n)-门限秘密分享［9］，简单来说，就是用户A向n个参与方分享一个秘密值s，s被分割为n份，任意t个参与方可以利用他们的分片恢复出秘密值（其中t≤n），但少于t个参与方无法得到与s有关的任何信息，t为门限值。

随着同态加密的出现，使得分片持有人在密文的情况下对不同分片执行同态计算的结果与不同分片在明文的情况下进行计算之后加密的结果一样，称为同态秘密分享［10］（HSS）。区块链上互不信任的参与方将区块链中发布的数据内容和交互数据、数据状态属性等进行加密，从而在保证数据安全的同时完成对数据的操作。

2018 年，Tsalolui G 等基于此提出了可验证同态秘密分享（VHSS）的概念［11］。也就是，秘密分发者A将一个联合计算外包给n个分片持有者，任何人都可以验证最终的结果是否正确。

以上都主要解决在不可信的环境下，不同群体间如何协同工作的问题，秘密分存的优点在于个别子秘密的泄露不至于引起秘密的泄露，而个别子秘密的损失也不至于影响秘密的恢复。由于其计算复杂性和安全性上的优势，在数据共享方面有很高的研究价值。

2.2 Pedersen承诺

定义Pedersen承诺［12］，如式（1）：

其中G和H是椭圆曲线上两个点（阶为大素数p的两个点），r是一个秘密值，v是盲化因子（即来自Fp的随机数）。

由于离散对数问题的困难性以及椭圆曲线加密体系的特性，只要秘密的分发者A不公布r和v，其他任何人都无法从已计算出的承诺C中得到正确的r和v，在数据的安全性验证方面有出色的表现。

门限秘密共享和Pedersen 承诺的出现，为分级诊疗体系的安全性共享及可靠性验证提供了一种很好的解决思路。

3 病历数据共享方法DP-MDSM

3.1 方法概述

病历数据作为一种敏感数据，针对集中存储、数据易篡改、数据追责难、安全共享难的问题，为患者和医院提供具有高保密性、高可信度和具有验证功能的数据共享，以此在区块链平台上提出了面向分级诊疗制度的病历数据共享方法DP-MDSM。为了更好地描述整个共享方案，在此以单个患者的病历数据共享作为一个基本案例，其主要包括一个患者、一定数量的医院、区块链上的标识节点、验证节点以及一个医疗机构联盟服务群组。本方案设计在联盟链基础上，医疗机构联盟服务群组主要提供医院节点加入网络的认证。而整个共享场景是由若干个基本案例构成。在这个基本案例中，患者作为数据（即秘密）的拥有者，具有对数据分享的自主权，同时作为数据的分发者。医院作为数据的分片持有者，多个医院组成的一个信息交流循环体，且每个医院各自锚定一个带有自身ID 的标识节点。同时医院作为数据的请求者，每个患者可以以保密的方式与每个医院分享自己在某个医院或多个医院生成的医疗病历相关数据，同时可以在不知道明文的情况下进行同态计算，提高了数据的安全性，减少了加解密过程中造成的计算资源浪费。在整个过程中，医院不可以直接获得患者的资料，患者拥有对自己信息的相对自主权。在不可信环境下，数据的发送者可能是不诚实的，为了保证数据的正确性和有效性，数据的接收者在接受数据之后，必须首先进行验证运算，判断数据是否被诚实计算。一些公开可验证的计算工作可以放在区块链上的验证节点进行，即每次交易发送到区块链，首先进行交易中携带数据的校验，只有校验通过的交易才可以上链，以此进行后续步骤的进行，减少医院和患者服务器计算资源的浪费，提高整个数据访问期间的时间消耗。

3.2 符号定义

其机制涉及的主要符号及其含义，如表1 所示。

表1 符号定义

3.3 方法具体实现

3.3.1 交易的构造

一个区块内交易信息会包含多种类型交易信息，主要由specific部分的交易详细信息来区分。交易的具体构造，如表2所示。

表2 交易的构造

根据工作流程中不同阶段的要求，本机制构造五种不同交易：患者产生验证密钥的交易TBvk，患者将秘密进行分割的交易TBscrt，患者对数据加密的交易TBenc，请求者发送请求的交易TBrequest，医院发送反馈值的交易TBresponse。

将除了specific部分的其余部分算作交易头，五种交易的结构设计如表3所示。

表3 TBvk，TBsert，TBenc，TBrequest，TBresponse 的构造

3.3.2 工作流程

本案例的主要参与者由一个患者、n个医院、n个标识节点、一个请求者、多个验证节点组成。本机制的及其它的复杂案例皆可由本基本案例组合而成。在此部分，患者以用户相称。该机制的具体工作流程如下步骤所示。

步骤一：前期准备阶段。

1）医院对节点的标识阶段。每一个医院对标一个区块链标识节点，获取IDhi以此参与后续秘密分享阶段，此过程即为医院注册阶段。

2）数据格式设置。本方法数据集为结构化数据形成的文书类病历数据，包括入院记录、病程记录、手术文书记录、出院记录。原始数据于星际文件系统（IPFS）中存储，存储格式为式（2）所示。本地数据库中存储原始数据的摘要Ddata及与IPFS的映射关系。针对医疗数据共享中缺乏统一的格式规范，在此设定之后所有的医疗数据以下式所示格式进行初步处理。

其中，D为原始数据，T为时间戳，以便后续数据归属权的确认。

用户注册。用户在初次登录时主动进行注册，或者在医院进行初次检测生成数据档案时自动进行注册，以此获取IDui。

步骤二：初始化阶段。也是用户注册阶段的详细过程。

1）验证密钥的生成。用户在256-bit的p阶大素数域Fp上随机的选取两个t-1 次多项式h(x)和f(x)，如式（4）和式（5）：

其中，α1，α2，…，αt-1，β1，β2，…，βt-1∈Fp。

在Fp中随机取α0，令α0=core，作为核心秘密，仅由用户知晓。则Fp上的t次多项式为式（6），作为生成核心分片的主要函数。

接着设计辅助分片相关函数s(x)，计算如下所示：

于此同时，生成下式所示的验证参数集合Gg：

此集合即为验证密钥集。其中g是256 位的椭圆曲线生成器。同时用户将此计算结果打包为交易TBvk，将此交易发送到区块链网络。

2）分片的生成。从医院列表中读取n个标识节点，所以用户生成的核心分片有n片，取1 ≤i≤n，用户计算每个标识节点的核心分片及辅助分片，如下式：

为了保证分片传输过程中信息被截取造成数据的篡改，涉及到用户与医院信息的数据以非对称加密方式进行数据传输。刚生成的分片进行下式所示加密：

并对选取得t次多项式中的核心秘密值core以同样方式加密进行传输。

因此对于上述两式只有专属i所对应的医院标识IDhi拥有的ski才可以将秘密解密。然后分别计算这n个分片的承诺：

将核心分片、辅助分片及其承诺打包，生成交易TBsert，并发送到区块链网络。

步骤三：对秘密数据的处理阶段。也就是医院对用户病历数据的处理阶段。用户病历数据为Ddata，假设其由j个不同数据组成，对各个数据进行相同的移位处理，得到加密后的数据enc(Ddataj)：

其中，core为标识节点验证阶段从用户处获取的核心秘密值。将打包进交易TBenc，并将交易发送到区块链网络。用户可以不断地生成秘密值，也就是可以生成交易若干次，以此来分享数据。

步骤四：请求者请求数据及获得数据阶段。至此前期工作基本完成，用户病历数据已经上链，用户也给不同医院分发了不同的分片，同时此过程在链上进行了记录。基于此基础上，医院请求访问用户数据的整个阶段的时序流程图如图1所示。

图1 请求者请求数据时序图

1）发送数据请求交易。假设一个医院请求者想要获取某用户的病历数据，使用用户IDui获取TBvk，即以此为输入值，创建一个交易TBrequest，发送到区块链网络。

2）标识节点生成反馈值。当n个标识节点在区块链上收到这个交易请求后，各个节点根据自身情况，进行反馈值的计算：

接着用请求者公钥pkh0加密反馈值，并用自身私钥skhi进行签名，在此假设请求者为IDh0：

只有请求者拥有的私钥才可以将秘密解密。接着，计算反馈值的承诺：

将以上计算结果及IDTBvk打包进交易TXresponse，并发送到区块链。

3）对秘密数据的恢复。当请求者收到t个反馈值交易，t为门限值，t≤n且t≥f+1，其中f为恶意节点的数量，以此保证恶意节点无法影响最后的结果的生成。请求者首先使用自己私钥利用数据对反馈值的完整性进行校验，接着分别从交易TXresponsei中获取enc(rspsi)，使用IDhi的私钥skhi对其解密，得到反馈值rspsi。首先对反馈值进行简单运算：

如果与交易中携带的Crspsi相等，说明收到的反馈值rspsi是有效的。如果至少t个反馈值有效，则利用拉格朗日插值公式重构初始化阶段提出的t-1次多项式，该计算如下所示：

接着把x=0 代入F(x)，计算F(0)，求得的结果即为用户的病历数据摘要，根据摘要在本地数据库中获取与IPFS 的映射关系来获取用户的原始病历数据。

3.3.3 验证流程

在不可信环境下，每个数据的发送者都很难保证其诚实性，所以在每次接受数据后，首先要进行数据的校验。校验过程分为验证节点的校验、医院标识节点的校验。

1）验证节点的校验

针对数据共享期间进行的数据验证以及访问量大可能造成的数据访问周期较长的问题，设置区块链验证节点以承担部分可验证计算。整个验证流程中验证节点要进行的验证主要分为以下几个部分。

（1）对TBvk的验证。用户发送TBvk到区块链网络中时，为了保证数据分享者没有进行错误计算以及对数据完整性的校验，进行如下所示验证。

验证节点从TBvk中的specific中得到密钥验证集Gg，从Fp中选取一个随机值x0，带入式（21）中进行初始化阶段的重新计算：

以此进行判断是否满足三个函数的关系如下式s(x)=h2(x)-f(x)。如果满足，则证实数据计算正确，该交易TBvk可以上链。如果不满足拒绝上链，并反馈一个错误位标志给IDui。

（2）对TBsert的验证。同理用从TBvk中取出的Gg集进行3.3.2节中分片承诺生成的重复运算：

如果=CCserti，=CAserti，则证明用户进行了诚实计算，可以上链。

（3）对TBresponse的校验。

当接收到从各个节点发送的TXresponsei，验证节点为保证各个标识节点的诚实性，要进行数据的重新计算。在计算出式（21）的基础上，利用加密的数据和双线性映射e，继续计算：

如果式（22）成立，则说明反馈值是有效的。所以TBresponse可以成功记录在区块链上。

2）医院标识节点对分片的校验。当节点在区块链上看到发送给自己的交易TBsert时，取得specific中的数据，用自己的私钥skhi解密Ecserti，Ecore得到Cserti，Aserti，core，进行如下计算：

以此判断与CCserti，与CAserti是否相等。如果相等，说明拿到正确的分片，为后期秘密数据的恢复做准备。n个标识节点分别进行同样的计算以校验拿到正确分片。

4 实验与分析

4.1 测试环境搭建

该套共享机制部署于笔记本电脑和阿里云服务器ECS 上的Hyperledger Fabric［13］平台上进行测试，并于ECS上利用Docker［14］虚拟化技术搭建节点接入测试的区块链网络。

电脑配置为Win10 OS，Intel i7-8750H CPU，2.20GHz，16GB memory。测试云服务器硬件环境为4 vCPU，8GB 内存，40GB 硬盘；系统环境为CentOS 8.1 64 位。代码运行的软件环境为Docker，版本号型号为17.09。采用Hyperledger Caliper［15］作为性能测试工具。对每个交易的签名算法使用基于secp256k1 曲线［16］的ECDSA 签名算法，非对称加解密采用基于secp256k1 曲线的ECIES 加密算法［17］。方法中承诺和双线性映射涉及的椭圆曲线点乘运算采用Pairing-Based Cryptography（PBC）Library［18］来计算。

节点部署过程中，首先准备好peer、memsrvc、fabric-ccenv 等相关镜像的tar 包，通过“docker load-i peer.tar”等命令将tar 包导入到本地docker镜像库中，之后进入到docker-compose.yaml所在目录，执行“docker-compose up-d”将peer 节点和memsrvc容器逐个启动起来即可。

基础网络中共有5个节点，分别为peer和memsrvc 节点。其中peer 节点共同完成区块生成过程中的通信、共识、区块生成和校验等功能。memsrvc为成员管理节点，主要负责节点加入联盟时提供注册、身份证书颁发、交易证书颁发等服务。

4.2 实验分析

为了分析在实际应用中DP-MDSM 方法在数据共享流程的时间消耗是否满足实际应用，在此，使用每一步骤处理的平均时间消耗（Average time consumption）这一指标来进行验证，采用（3，4）-秘密共享方法部署于测试环境进行实验。接着测试该方法的部署应用是否满足区块链网络性能，主要指标为交易上链成功率（Success rate）、节点访问区块链请求延迟（Request detention）。测试中，将发送率从50到300 TPS来观察指标的变化情况。

案例包括1个数据分发者，4个秘密共享者（即标识节点），1 个请求者。在DP-MDSM 方法中，交易的大小影响每一步骤处理的平均时间消耗这一性能指标。在此分析不同交易的具体规模。1 个TBvk包含1 个用户ID 和1 个验证密钥集；1 个TBenc包含4 个标识节点ID、4 个加密的核心分片、4 个核心分片承诺和4个辅助分片承诺；1 个TBrequest仅包含一个请求的用户ID；1 个TBresponse包含1 个请求的用户ID、1个加密的反馈值和1个反馈值的承诺；而TBscrt涉及到用户病历数据的具体大小，所以specific大小不定。不同交易包含的内容不同，造成交易specific的大小不同，如表4所示。

表4 每种交易specific 大小

本实验中，为了减少用户与服务器节点的验证负担和大量计算浪费，设置区块链验证节点以承担部分可验证计算。在交易被记录在区块链之前，验证节点负责验证该交易中的所有公开可验证的数据。

由此，针对不同的交易，用交易模拟器模拟产生和发送1000 次交易。在包含验证过程的情况下，对该机制的不同步骤，每一步骤处理的平均时间消耗如表5所示。

表5 每一步骤的平均处理时间消耗

有无验证节点存在对处理交易速度的对比图如图2 所示。根据图中数据可知，公开可验证的数据，如验证密钥、分片的承诺、反馈值的承诺，在前三个阶段，通过在验证节点进行验证确实减少了部分时间消耗。

图2 有无验证节点对处理交易速度的对比图

交易上链成功率也就是交易被成功记录在区块链上的概率。交易上链成功率随交易发送量变化的情况如图3 所示。根据图知，交易上链成功率随交易发送量的增多而降低。

节点访问区块链请求延迟如图4 所示。整体趋势上，平均区块链访问延迟随交易发送量的增加而增加。根据测试结果可知，平均的访问延迟设置在2.93s 左右，这个时间完全满足目前的区块链平台的处理速度。

图4 节点访问区块链请求延迟图

5 结语

针对病历数据中心化存储带来数据篡改问题及其在分级诊疗制度中产生的“数据孤岛”问题，本文采用区块链技术作为一种解决方案，基于秘密共享方案与区块链工作原理相契合的基础上，提出一种面向分级诊疗的病历数据共享方法。患者的病历数据可以以密文的形式存储在区块链上，且不会被医院直接查询可得，任何人可以验证该密文的正确性，请求者可以获得真实可验证的医疗数据。同时为了保证数据的安全性，设计不同的交易格式，采用非对称密码方法使病历数据以密文在区块上链，以此达到数据的不可篡改以及可溯源性。为了减少用户与服务器节点的验证负担，设置区块链验证节点以承担部分可验证计算，保障了信息访问和共享的高可用性。