这是一篇开放获取的文章,根据创作共用署名许可协议(https://creativecommons.org/licenses/by/4.0/)发布,该协议允许在任何媒体上不受限制地使用、分发和复制,前提是必须正确引用最初发表在《JMIR医学信息学》上的原始作品。必须包括完整的书目信息,https://medinform.www.mybigtv.com/上的原始出版物链接,以及版权和许可信息。
在临床基因组学中,基因数据库和实验室之间共享罕见遗传病信息对于确定变异的致病意义,从而实现罕见遗传病的诊断至关重要。在实践中,对数据治理和安全性的严重关注减少了这种共享。区块链可以为相关各方之间共享基因组数据提供一种安全的方法,从而帮助克服其中一些问题。
本研究旨在通过描述基于区块链的动态同意架构来支持临床基因组数据共享,并提供名为ConsentChain的概念验证实现,以探索该架构的性能,从而促进对区块链技术在支持临床基因组数据共享方面的潜在作用的日益增长的认识。
从患者论坛捕获了ConsentChain需求,以确定安全性和同意性问题。consenentchain是在以太坊平台上开发的,在该平台上,智能合约被用于建模患者的行为,患者可以提供或撤回共享其数据的同意;数据创建者,负责收集和存储患者数据;以及需要查询和访问患者数据的数据请求者。详细分析了作为系统处理的事务数量的函数的consenentchain性能。
我们描述了ConsentChain,这是一个基于区块链的系统,提供了一个门户网站接口,以支持临床基因组共享。ConsentChain允许患者授予或撤回数据请求者的访问权,并允许数据请求者查询和提交对存储在安全链下数据库中的数据的访问权。我们还开发了一个本体模型,将患者同意元素表示为机器可读代码,以实现同意和数据访问过程的自动化。
区块链和智能合约可以提供有效和可扩展的机制,以支持动态同意功能,并解决一些阻碍基因组数据共享的障碍。但是,它们并不是一个完整的答案,在实际部署这种系统之前,还有许多问题需要解决,特别是与验证用户凭证有关的问题。
随着快速有效的下一代测序技术的出现,无关联和分散的基因组数据已成为罕见病诊断的主要挑战。罕见疾病的分子诊断包括将患者的基因变异数据与大人群中患有类似疾病的其他人的基因变异数据进行比较。因此,基因数据库和实验室之间的数据共享对于识别重叠结果和确定变异的致病意义以诊断罕见遗传疾病至关重要。
需要克服的最常见的挑战之一是,由于隐私和安全方面的考虑,基因组数据通常保存在集中的受限访问存储库中[
上述一些挑战是采用集中式架构存储、共享和访问基因组数据的结果。在这种体系结构中,数据存储在集中的数据库中,并通过受控的访问机制进行访问。尽管这种收集和管理基因组数据的方法在过去已被证明是成功的,但研究表明,这种集中式架构未能妥善解决访问基因组数据的日益增长的需求[
针对与基因组数据集中存储相关的挑战,已经提出了各种解决方案。例如,有人提出了联邦数据存储系统来支持基因组数据共享。GA4GH信标项目[
去中心化和分布式技术被认为是促进基因组数据共享的潜在解决方案[
区块链是一种协议,使称为节点的计算机网络能够维护一个称为分类帐的共享数据库,而不需要网络节点之间完全信任[
区块链由两个主要部分组成:点对点网络和分布式账本。
点对点网络:理解点对点网络对于理解区块链至关重要,因为区块链的核心是一个点对点网络。如前所述,点对点网络由许多称为节点的连接计算机组成。网络中的每个节点都与其他网络节点有直接或间接的连接。每个节点将其计算资源(即处理能力或存储容量)的一部分直接提供给其他节点,而不需要服务器进行集中协调[
集中式和点对点网络的体系结构。
分布式分类账:网络中的所有交易都存储在一个共享分类账中。它由一个区块链组成,每个区块包含一组事务。每个区块都有时间戳,并与紧挨着它的区块链接。每个节点维护共享分类帐的相同副本。要添加新事务,网络节点使用共识协议来评估和验证新事务。该协议保证只有当大多数节点验证该事务时,该事务才被追加到共享分类帐中。一旦事务被附加到共享分类帐中,它就不能被更改或还原,而且因为所有节点都有共享分类帐的相同副本,所以没有节点有能力更改数据。这确保了共享分类帐的完整性。然而,最近的研究已经证明,通过51%的攻击,改变共享账本是可行的,其中对手可以控制区块链网络中超过一半的总节点来改变共享账本[
简化区块链的概念。
根据对数据的访问和参与网络的节点的作用,区块链分为4种类型[
公众无许可。任何人都可以参与到网络中,并从区块链读取或写入数据。比特币和以太坊是不受公共许可的区块链的例子。
公共许可。任何人都可以参与到网络中并从区块链读取数据,但只有少数参与者可以在区块链中写入数据。纹波(
私人无许可。有限的参与者可以参与到一个网络中,其中所有参与者都可以从区块链或在区块链中读写数据。Holochain [
私人的许可。有限的参与者可以参与到网络中并从区块链读取数据,但其中的一个子集可以在区块链中写入数据。Hyperledger织物(
动态同意是一种双向沟通方法,通过设置和修改个人的同意首选项,个人可以指定他们愿意与各种医疗保健提供者共享哪些数据。它允许个人通过授予和撤销对其数据的访问、跟踪其数据以及更新其同意首选项来控制其数据。尽管有这些好处,但由于伦理、法律和数据安全方面的考虑,动态同意在临床遗传学中的实施受到限制。缺乏病人的信任[
确定区块链是否适用于特定场景并不是一件容易的事情。虽然对于区块链的适用性没有通用公式或规则,但已提出若干决策方案,以根据情景需求决定是否应使用区块链[
决策树确定区块链的使用情况[
您需要存储状态吗?这个问题的答案是肯定的。诊断罕见遗传疾病患者是一项复杂而耗时的工作,因为它涉及从多个来源收集数据[
数据是否有多个写入者?在临床基因组学中,患者治疗途径涉及多方,如临床医生、科学家和临床实验室技术人员[
你能使用基于web的可信第三方吗?信任和同意是基因组医学和研究成功推进的重要因素。患者应该相信,他们的数据是安全处理的,只有在征得他们同意的情况下才会使用。英国基因组协会最近的一份报告[
所有的作家都是知名的吗?为了产生、管理和存储患者数据,卫生保健提供者必须表明自己的身份。此外,患者需要确认自己的身份,以便与卫生保健提供者联系。因此,这个问题的明确答案是肯定的。
所有的作家都值得信任吗?尽管患者和卫生保健提供者之间需要最低程度的信任,但卫生保健提供者可在未经患者明确同意的情况下将患者数据用于研究目的[
是否需要公开验证?即使患者数据没有直接存储在区块链中(链下存储),对系统的访问也应该是私有的并被允许的。因此,这个问题的答案是否定的。
根据对这6个问题的回答,很明显,在提议的基因组数据共享场景中使用区块链是合理的。
为了确定同意链的设计要求,我们分析了最近一项针对国家卫生服务(NHS)基因组医学服务患者的审议性焦点小组研究,该研究涉及共享基因组数据的公众意见(国家研究伦理委员会伦理批准文献18/NW/0510) [
作为一名患者,我希望我的数据能够被共享,以促进我的诊断和治疗。
作为一名患者,我希望我的无法识别的数据能够被更广泛地分享,以帮助其他人的治疗,并促进广泛的研究。
作为一名患者,我希望我的数据可用于不同的医疗保健提供者,这样我就不必每次访问新的医疗保健提供者时都要重复自己的信息。
研究参与者允许共享他们的基因组数据,以支持在多个卫生保健提供者之间对他们的病情进行诊断和治疗。他们还同意使用他们的基因组数据来帮助其他有类似基因状况的患者,并用于未来的研究。
该系统应允许卫生保健专业人员和研究人员发现和访问有关存储在单个基因实验室中的基因组数据集的信息。
作为一名患者,我希望实施数据安全方面的最佳实践,以保护我的数据,使其免受黑客攻击和丢失。
作为一个病人,我希望有不同层次的目的来访问我的数据,这样它们就可以用于授权的目的。
与会者一致认为,基因组数据应被安全地存储和共享,不得进行未经授权的修改,同时将其用于授权的目的。
应该使用数据加密和访问控制等安全技术来保护敏感数据。由于区块链的开放和透明性质,敏感数据(无论是加密的还是未加密的)不应该存储在链中。
作为一名患者,我希望我的基因数据在没有我的身份信息(如我的名字)的情况下被分享,这样我的身份就不会被泄露。
与会者强调,在患者直接护理之外分享基因组数据应该匿名,以保护他们的身份。
该系统应允许患者数据在相关各方之间流动,同时将患者身份泄露的风险降至最低。
作为一名患者,我想同意为某些明确的目的分享我的数据,这样就不需要再为这些目的获得进一步的同意。
作为一名患者,我希望被告知分享我的数据的目的是否被改变了,这样我就可以选择明确允许新的改变。
作为一名患者,我希望能够以直接和简单的方式选择更新/撤回我的同意,这样我以后就可以改变主意了。
作为一名患者,我希望能够跟踪我的共享数据,这样我就能知道我的数据在何时和谁共享。
参与者认为,他们应该被允许分享他们的数据,并被告知他们的数据将如何使用以及用于什么目的。此外,有些代表团认为他们将行使不参加的权利。
该系统应使患者能够动态更新其权限,并跟踪与不同方共享的数据。
作为一名患者,我希望指定不同级别的角色请求者访问我的数据,这样只有授权方才能获得访问权限。
作为一名患者,我希望对我的共享数据有一个时间限制,这样它们就不能在未来用于其他目的。
一些与会者担心未经授权将他们的数据泄露给第三方,包括家庭成员、雇主和执法机构,而另一些与会者则担心限制商业实体访问他们的数据。
该系统的设计应该允许在给定的时间框架和特定目的下共享患者数据。
受全球基因组学和健康联盟(GA4GH)数据使用本体努力的启发,为基因组数据使用限制和数据访问请求建模[
表示同意元素中的数据类型的代码。
数据类型 | 代码 |
基因型 | 斯通 |
表型 | 板式换热器 |
元数据 | 意味着 |
表示同意元素中角色的代码。
目的 | 代码 |
治疗 | 泰爱泰党 |
研究 | 盐土 |
临床 | 慢性淋巴细胞白血病 |
表示同意要素中目的的代码。
角色 | 代码 |
临床医生 | CLN |
研究员 | 稀土元素 |
Bioinformatician | 箱子 |
访问策略树的示例,其中临床医生为治疗访问患者基因型数据。CLN:临床医师;GNE:患者基因型资料;泰爱泰党:治疗。
我们使用PRISMA(系统审查和元分析首选报告项目)指南进行了系统审查,以分析现有的文献,这些文献基于区块链的同意数据用于医疗保健管理系统。PRISMA系统评审流程图如下所示
未解释同意管理(n=13)
没有提供实现(n=2)
无法访问全文(n=2)
回顾和想法(n=6)
PRISMA(系统评审和荟萃分析首选报告项目)流程用于本次评审。
((区块链[标题/文摘])或(智能合约[标题/文摘])或(blockchain-based[标题/文摘])或(智能合同[标题/文摘]))和((同意*[标题/文摘])或(许可*[标题/文摘])或(访问控制[标题/文摘]))和((医疗[标题/文摘])或(EMR[标题/文摘])或(基因组[标题/文摘])或(基因[标题/文摘])或(电子健康记录(标题/文摘])或(EHR[标题/文摘])或(电子医疗记录(标题/文摘])(医学[标题/摘要])或(临床试验[标题/摘要])或(患者*[标题/摘要]))
其他相关研究论文通过被引数确定(n=3)。对剩余的研究论文和确定的相关研究论文(n=10)进行全面分析。最后的研究结果总结于
Chenthara等人[
克莱恩(
Tith等al [
拉杰普特等人[
与已有的相关文献相比,该系统具有动态特性,支持最小的数据公开。据我们所知,还没有相关的文献报道了这6个设计需求,并提供了系统性能的详细分析。
在本节中,我们描述了拟议的基于区块链的动态同意架构,以支持临床基因组数据共享。这种通用体系结构可以自定义,并在需要动态同意的不同用例中使用。见
用户
数据创建者(DC):组织实体,如基因检测实验室,患者数据在这里收集并存储在安全的数据库中。
病人:其数据被链外存储在数据中心管理的安全数据库中的个人;病人可以使用
同意元素
代码。
DR:希望为特定目的(包括研究和卫生保健)发现和请求访问患者数据的领域专家或组织实体。
智能合约,用于提供系统功能,如注册新用户、管理患者同意和处理对患者数据的访问请求。此外,智能合约创建事务日志和事件,支持跟踪和审计所有系统数据和操作。
链上的资源
日志和事件:智能契约为所有系统事务创建日志和事件。这些日志和事件存储在链上,它们是跟踪和审计所有系统操作的重要资源,从而使所有系统用户对其操作负责。
数据概要(DP):这是对存储在基因实验室数据库链下的特定患者先前存在的基因组数据的描述。患者DP包含患者数据的位置、患者病情和基因名称等信息,不透露任何敏感和可识别的信息。在链上存储患者DPs有助于DR发现和识别存储在几个遗传实验室数据库中的感兴趣的基因组数据集。
同意管理:用于处理患者同意操作,如添加、更新和删除同意。
访问数据管理:这用于处理对患者数据的访问过程,包括验证访问请求和提供对链下数据的安全访问。
Off-chain资源
安全数据库:由数据中心管理的私有数据库,所有与所需DP相关的信息都存储在其中。
Oracle服务:根据设计,区块链和智能合约不能访问和读取链下数据;因此使用oracle服务。oracle服务是向区块链提供链下数据的可信数据提要服务。在该系统中,使用oracle服务实现智能合约与安全数据库的通信。
IPFS:这是一种去中心化的文件存储系统,它永久地存储和共享各种类型的文件。每个存储的文件都根据其内容给出一个惟一的哈希值。然后使用这个散列值从系统中检索文件。在本研究中,我们利用IPFS作为密钥管理服务来存储用户的公钥(PU)。我们认为IPFS是用户PU的最佳候选,因为它的高可用性和低成本。
所提议的体系结构的组件。IPFS:星际文件系统。
我们在一个私人许可的区块链上实现了概念验证,以演示我们基于区块链的架构的可行性。在基础设施层面,超级账本Besu [
六种智能合约被用来管理链上交易:注册智能合约(RSC)、患者智能合约(PSC)、数据配置文件智能合约(DPSC)、数据创建者智能合约(DCSC)、数据请求者智能合约(DRSC)和oracle服务智能合约(OSSC)。这些智能合约提供了8个主要系统功能:
病人智能合约代码的一个说明性示例。
每个系统参与者通过他或她的智能合约与系统交互,其中包括与系统交互所需的所有信息。因此,参与者必须是在创建了智能合约的系统中注册的。在进行系统注册之前,所有用户的身份和专业注册都应该由系统管理员进行验证,该管理员负责设置系统并邀请当局加入系统,例如NHS。
算法1:createNewPatientContracter
输入:patientWalletAddress调用者
输出:smartContractAddress
如果调用者= admin∧patientWalletAddress≠null
创建newPatientSmartContract
设置newPatientSmartContract所有者为patientWalletAddress
输出newPatientSmartContract地址
其他的
恢复智能合约状态并显示错误消息
算法2:createNewDataCreatorContract
输入:dataCreatorWalletAddress调用者
输出:smartContractAddress
如果caller = admin∧dataCreatorWalletAddress≠null则
创建新的DataCreatorSmartContract
设置newDataCreatorSmartContract owner为
dataCreatorWalletAddress
输出newDataCreatorSmartContract地址
其他的
恢复智能合约状态并显示错误消息
算法3:createNewDataRequestorContract
输入:caller, dataRequesterWalletAddress, dataRequesterPUK
输出:smartContractAddress
如果调用者= admin∧dataCreatorWalletAddress≠零∧
dataRequesterPUK≠零然后
创建newDataRequesterSmartContract
设置newDataRequesterSmartContract owner为
dataRequesterWalletAddress
设置newDataRequesterSmartContract的公钥为dataRequesterPUK
输出newDataRequesterSmartContract地址
其他的
恢复智能合约状态并显示错误消息
算法4:setConsent
输入:调用者,数据类型,角色,目的
输出:状态
同意←映射
如果caller=contractOwner∧dataType≠null∧角色≠null∧目的≠null,则
h←散列(数据类型、作用、目的)
如果CONSENT.contain (h,真的)
恢复智能合约状态并显示错误消息
其他的
CONSENT.insert (h,真的)
输出正确的
其他的
恢复智能合约状态并显示错误消息
方法5:cancelConsent
输入:调用者,数据类型,角色,目的
输出:状态
同意←映射
如果caller=contractOwner∧dataType≠null∧角色≠null∧目的≠null,则
h←散列(数据类型、作用、目的)
如果CONSENT.contain (h,假)
恢复智能合约状态并显示错误消息
其他的
CONSENT.insert (h,假)
输出正确的
其他的
恢复智能合约状态并显示错误消息
方法6:checkConsent
输入:dataType, role, purpose
输出:状态
同意←映射
如果数据类型≠null∧角色≠null∧目的≠null,则
h←散列(数据类型、作用、目的)
r←CONSENT.return (h)
输出r
其他的
恢复智能合约状态并显示错误消息
算法7:setupDataProfile
输入:caller, patientSmartContract, dataHash, condition, dataType,gene
输出:id
DATAPROFILE←映射
我←柜台
如果caller = dataCreatorSmartContract∧患者smartcontract≠空∧datatHash≠空∧条件≠空∧dataType≠空∧∧基因≠空
然后
我+ +
DATAPROFILE。insert(i,[patientSmartContract, dataHash, condition, dataType, dataCreatorSmartContract])
输出我
其他的
恢复智能合约状态并显示错误消息
当DR需要访问患者数据时,需要获取ATi (access ticket)和ATo (access token)。ATi用于控制对患者数据的访问,而ATo用于将对所请求数据的访问最小化到最低级别。
算法8:requestAccessTicket
输入:调用者、dataProfileId、角色、目的
输出:ticketId
DATAPROFILE←映射
如果caller=contractOwner∧dataProfileId≠null∧role≠null∧purpose≠null,则
d←DATAPROFILE.return (dataProfileId)
病人←d.patientSmartContract
数据类型←d.dataType
h←散列(数据类型、作用、目的)
如果patient.CONSENT.return (h) = true
票←病人。CreateAccessTicket(caller, dataProfileId)
ticket.status = true
输出ticket.id
其他的
恢复智能合约状态并显示错误消息
其他的
恢复智能合约状态并显示错误消息
为了获得ATo,容灾需要向系统提交有效的ATi。
算法9:requestAccessToken
输入:调用者,dataProfileId ticketId
输出:tokenId
DATAPROFILE←映射
如果caller=contractOwner∧dataProfileId≠null∧ticketId≠null,则
d←DATAPROFILE.return (dataProfileId)
dataCreator←d.dataCreatorSmartContract
病人←d.patientSmartContract
如果patient.ticket [ticketId]。状态= true然后
令牌
←dataCreator。dataProfileId createAccessToken(调用者)
Token.status = true
输出token.id
其他的
恢复智能合约状态并显示错误消息
其他的
恢复智能合约状态并显示错误消息
本节介绍了ConsentChain(拟议架构的概念验证实现),以探索应用区块链技术支持临床基因组数据共享的有效性。consenentchain为患者、dc和dr提供了一个与系统交互的web门户。它允许患者提供或撤回对共享其数据的同意,允许dc收集和存储患者数据,允许dr查询和访问患者数据。
在注册过程中,DR生成一对密钥:PU和PR。DR将PU上传到IPFS,记录IPFS返回的位置信息。
DR发送一个区块链事务,将IPFS返回的PU位置存储在RSC中。
患者发送一个区块链事务将他们的同意元素(数据类型、角色和目的)存储在PSC中。
DC收集患者数据并将其存储在一个安全的离线数据库中。DC还记录数据库返回的患者数据参考(DRef)。
DC创建一个DP,其中包括DRef、PSC地址和与患者数据相关的其他信息,这些信息不透露任何敏感和可识别的信息。然后,DC发送一个区块链事务将DP存储在DPSC中。
DR查询DPSC以发现感兴趣的特定DP并读取与该DP相关的事务信息。
DR从DP获取PSC地址,并向PSC发送一个区块链事务,请求ATi访问存储在链下数据库中的患者数据。根据存储在PSC中的患者同意,自动接受或拒绝请求。在接受时,生成ATi并存储在PSC中,DR接收与ATi相关的事务ID。
DR向DCSC发送一个包含ATi的区块链事务,请求ATo检索存储在链下数据库中的患者数据。根据ATi验证自动接受或拒绝请求。在接受请求时,ATo存储在DCSC中,DR接收与ATo相关的事务ID。
DR向oracle服务智能合约发送包含ATo的区块链事务,以检索存储在链下数据库中的患者数据。根据ATo验证自动接受或拒绝请求。
在接受请求后,请求被转发到Oracle服务服务器(OSS)。
OSS从RSC获取DR在IPFS上的PU位置。
网管从IPFS中下载灾备端PU。
OSS从数据库中获取患者的数据,并创建一个包含患者数据的临时JSON文件。这个JSON文件可以通过HTTPS请求访问,并且可以一次性访问。
网管使用dr端的PU对JSON文件的URL进行加密,然后发送一个区块链事务将加密后的URL存储在DRSC中。
DR从DRSC检索加密的URL,并使用相应的PR对其进行解密,以访问JSON文件。
病人接口。
同意链的高级结构和工作流程。Ati:访问的机票;博士:数据请求者;星际文件系统;OSS: Oracle服务服务器;OSSC: oracle服务智能合约;P:病人;PSC:患者智能合约;注册智能合约。
在本节中,我们将讨论我们的概念验证(ConsentChain)如何满足从患者论坛获取的需求,并提供对其性能的详细分析。
在ConsentChain中,我们使用了一种混合数据存储模型,其中包括链上或链下存储。敏感的患者数据在链外安全存储,而患者数据的元数据则与指向数据源的引用指针一起存储在链上。这个引用指针受到短时间框架的限制,并且是加密的。只有经过授权的DR才能在给定的时间范围内解密它以访问患者数据。此外,在私有或联盟区块链上实现consistentchain增加了一个安全层,其中所有用户在加入网络之前都要经过验证。
智能合约作为自主参与者,其行为是可预测的[
通过利用区块链的真实性和可验证性功能,consenentchain通过使用许可的区块链和匿名账户来维护隐私。只有经过授权的用户才能通过他们的匿名账户访问区块链,使患者能够在不暴露真实身份的情况下提供他们的同意。
在医疗保健环境中,平衡数据发现的最大化与数据披露风险的最小化是一项具有挑战性的任务[
为了最大化数据发现,我们利用了区块链特性。其中之一是跨网络复制存储在链上的数据;共识机制确保每个节点获得数据的本地相同副本。使用链上数据的本地副本,DR可以识别潜在的患者数据,而不是单独查询每个链外存储。因此,在链上存储患者元数据将为dr提供更广泛的类似患者数据视野,这些数据存储在链下的不同实验室中。
通过利用区块链的不可变性,我们的系统维护了所有系统事务的不可变日志。由于共享患者数据的过程由智能合约管理,所有涉及的交易都永久记录在区块链上。这将使患者能够检查区块链,以获取与其数据相关的所有信息和交易,包括数据存储在链下的位置、谁可以访问它们以及用于什么目的。该功能是向以患者为中心的方法的重大升级,以推进数据共享。它还将使监管机构能够在相关各方发生纠纷时调查索赔,从而增加对consenentchain的信心。
本节从患者隐私保护、数据存储、数据共享和防篡改等方面对consenentchain进行安全性分析。
基因组数据是高度敏感的,未经适当许可不应披露。在ConsentChain中,基因组数据存储在链下私有安全存储中,具有访问控制机制,从而降低了患者数据泄漏的风险。此外,为了保证参与者的匿名性,为与某个PU关联的参与者生成一个随机生成的唯一帐户。此帐户用于将事务发送到区块链;这些交易是匿名的,无法与参与者的真实身份挂钩。此外,一个与会者可以创建多个帐号;因此,由同一参与者发送到区块链的事务不能被对手推断出来。
在ConsentChain中,基因组数据存储在链下私有安全存储系统中。该存储的安全性超出了本文的范围,我们假设它由其所有者(DC)保护。只有链下存储数据的元数据、散列和引用在区块链上共享。存储在区块链中的链下DRef是防篡改的。
只有经过授权的用户才能通过智能合约中预设的权限请求访问链下数据。在接收到有效的请求后,DC创建一个包含所请求数据的JSON文件,并将其存储在临时访问链外存储中,在那里可以通过HTTPS访问数据。对JSON文件的访问受到一次访问和短时间框架的限制。然后DC检索从IPFS请求数据的用户的PU,并加密允许访问JSON文件的URL,然后将其存储在区块链中。请求数据的用户可以从区块链获得URL,并使用他们的PR解密它并访问JSON文件。一旦JSON文件被访问,它将从临时访问链下存储中删除,使存储在区块链中的URL无用;因此,如果对手破坏了请求数据的用户的PR来解密URL, URL将不会导致任何结果。此外,如果JSON文件没有在指定的时间框架内被访问,它将从临时访问链外存储中删除,从而降低数据未经授权访问的风险。
在consistentchain中,数据访问活动被记录在区块链中,可以对其进行审计和跟踪。此外,由于区块链中使用的共识机制,存储在区块链中的数据是不可变的,不能任意修改,这保证了添加的块不能被修改,除非对手可以发起51%的攻击。值得注意的是,根据区块链中使用的共识机制的类型,发起51%攻击的机制不同。例如,公共区块链如以太坊和比特币使用工作量证明共识机制,这需要很高的计算能力来生成新的区块,而在私有许可的区块链中,可以使用授权证明共识机制来生成新的区块[
为了测试和验证consistentchain,我们为部署和托管consistentchain构建了一个真实的生产环境。中提供了对consistentchain的详细性能分析
基因组数据在临床基因组学社区内共享并与其他患者数据进行比较时非常有用,这表明临床医生可能需要共享数据来有效地治疗患者。然而,许多挑战阻碍了大规模基因组数据共享,例如基因组数据的可用性、可发现性和可访问性[
尽管如此,这项研究的一些局限性需要解决。由于区块链技术的开放性和分布式特性,验证用户身份具有挑战性。我们的系统是在这样的假设下运行的:系统是在私有区块链上实现的,所有用户都被邀请加入系统。在用户可以加入系统之前,将执行用户身份验证,并为每个用户提供一个假名标识符,以在系统中表示他们。克服这一问题的更可靠和实际的解决方案可能是将患者身份与外部可信的信息源连接起来,如GOV.UK Verify和NHS identity。此外,DR和DC的身份验证可以通过与其专业注册相关联来实现。
另一个问题是区块链的GDPR符合性,这需要考虑[
这项工作的目标不是设计一个可以在医疗保健环境中实际使用的系统,而是展示区块链技术有潜力解决几个基因组数据共享挑战。我们发现,通过区块链技术和智能合约促进基因组数据共享是有前途的。但是,它们并不是全部的答案,在实际部署这种系统之前,还有许多问题需要解决,特别是与验证用户凭据有关的问题。
医疗保健中现有区块链解决方案的系统设计要求。
提出的模型的详细性能分析。
访问的机票
访问令牌
数据的创造者
数据创建者智能合约
数据概要
数据配置文件智能合约
数据请求者
数据参考
数据请求者智能合约
一般资料保障规例
星际文件系统
国家卫生服务
Oracle服务服务器
私钥
系统回顾和荟萃分析的首选报告项目
患者智能的合同
公钥
没有宣布。