CN110602089A - 基于区块链的医疗数据存储方法、装置、设备及存储介质 - Google Patents
基于区块链的医疗数据存储方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN110602089A CN110602089A CN201910860312.2A CN201910860312A CN110602089A CN 110602089 A CN110602089 A CN 110602089A CN 201910860312 A CN201910860312 A CN 201910860312A CN 110602089 A CN110602089 A CN 110602089A
- Authority
- CN
- China
- Prior art keywords
- user
- medical data
- blockchain system
- target
- medical
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Bioethics (AREA)
- Medical Informatics (AREA)
- Computing Systems (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Epidemiology (AREA)
- Primary Health Care (AREA)
- Public Health (AREA)
- Databases & Information Systems (AREA)
- Medical Treatment And Welfare Office Work (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本申请公开了一种基于区块链的医疗数据存储方法、装置、设备及存储介质,属于区块链技术领域,该方法包括:接收第一存储指令;根据第一存储指令,生成第一授权信息,第一授权信息表示用户授权将医疗数据存储至目标区块链***;使用用户在目标区块链***的私钥,对第一授权信息进行签名,得到第一签名;根据第一授权信息以及第一签名,向医疗机构服务器发送第一存储请求。本申请实施例能够通过区块链技术,实现医疗数据的高效流通,并且可以保证将医疗数据存储至区块链的过程是在用户的授权下执行的,避免医疗数据随意入链而造成用户隐私泄露的情况,并且能够保证区块链上存储真实可信的医疗数据,避免医疗数据在存储过程中被篡改。
Description
技术领域
本申请涉及区块链技术领域,特别涉及一种基于区块链的医疗数据存储方法、装置、设备及存储介质。
背景技术
病人在医院就诊后,会产生各种医疗数据,比如就诊记录、收费清单、临床诊断结果、化验报告、处方等,需要将病人的医疗数据妥善地存储起来,以便病人以医疗数据为凭据进行报销,医生根据医疗数据进行复诊。
目前,医疗数据的存储方法为:医疗机构服务器构建信息***,在病人就诊的过程中,医生将医疗数据录入到信息***中,从而在信息***中存储每个病人的医疗数据。
由于医疗机构的信息***通常仅对医疗机构内部开放,造成了信息孤岛的问题,导致保险机构等第三方机构难以得到病人的医疗数据,使得医疗数据流通的效率低下。
发明内容
本申请实施例提供了一种基于区块链的医疗数据存储方法、装置、设备及存储介质,能够解决相关技术中医疗数据的流通效率低下的问题。所述技术方案如下:
一方面,提供了一种基于区块链的医疗数据存储方法,应用于终端,所述方法包括:
接收第一存储指令,所述第一存储指令用于指示将用户在医疗机构服务器中存储的医疗数据存储至目标区块链***;
根据所述第一存储指令,生成第一授权信息,所述第一授权信息表示所述用户授权将所述医疗数据存储至所述目标区块链***;
使用所述用户在所述目标区块链***的私钥,对所述第一授权信息进行签名,得到第一签名;
根据所述第一授权信息以及所述第一签名,向所述医疗机构服务器发送第一存储请求,所述第一存储请求用于请求将所述医疗数据存储至所述目标区块链***。
可选地,所述第一存储指令包括所述医疗数据的标识、所述用户在所述医疗机构服务器的身份标识、所述目标区块链***的标识、区块链类型、区块链的标识、所述目标加密算法的标识中的至少一项。
可选地,所述第一授权信息包括所述医疗数据的标识、所述用户在所述目标区块链***的公钥、所述用户在所述医疗机构服务器的身份标识、所述目标区块链***的标识、区块链类型、区块链的标识、所述目标加密算法的标识中的至少一项。
可选地,所述接收授权指令之前,所述方法还包括:
从所述保险机构的服务器接收授权请求,所述授权请求用于请求所述用户授权对所述医疗数据进行解密;
显示授权提示界面,所述授权提示界面用于提示所述用户授权所述保险机构服务器对所述医疗数据进行解密或者拒绝所述保险机构服务器对所述医疗数据进行解密。
可选地,所述获取目标密钥对之后,所述方法还包括:
向密钥管理信息写入所述医疗数据的标识与所述目标密钥对之间的对应关系,所述密钥管理信息用于记录所述用户的每个医疗数据对应的目标密钥对;
所述从所述保险机构的服务器接收授权请求之后,所述方法还包括:
解析所述授权请求,得到所述医疗数据的标识;
根据所述医疗数据的标识,查询所述密钥管理信息,得到所述医疗数据的标识对应的所述目标密钥对的私钥。
可选地,所述第二存储指令包括所述用户在所述医疗机构服务器的身份标识、所述目标区块链***的标识、区块链类型、区块链的标识、所述目标加密算法的标识中的至少一项。
可选地,所述第二授权信息包括所述用户在所述目标区块链***的公钥、所述用户在所述医疗机构服务器的身份标识、所述医疗机构服务器在所述目标区块链***的公钥、所述目标区块链***的写入接口的标识、所述目标区块链***的标识、区块链类型、区块链的标识中的至少一项。
另一方面,提供了一种基于区块链的医疗数据存储方法,应用于医疗机构服务器,所述方法包括:
从终端接收第一存储请求,所述第一存储请求用于请求将用户在医疗机构服务器中存储的医疗数据存储至目标区块链***;
使用所述用户在所述目标区块链***的公钥,对所述第一存储请求中的第一签名进行验证;
当所述第一签名验证通过时,根据所述第一存储请求中的第一授权信息,读取存储的所述用户的医疗数据,所述第一授权信息表示所述用户授权将所述医疗数据存储至所述目标区块链***;
向所述目标区块链***中的节点设备发送所述医疗数据。
可选地,所述根据所述第一存储请求中的第一授权信息,读取存储的所述用户的医疗数据,包括:
解析所述第一授权信息,得到所述第一授权信息携带的所述医疗数据的标识;
以所述医疗数据的标识为索引,查询信息***,得到所述医疗数据的标识对应的医疗数据。
可选地,所述根据所述第一存储请求中的第一授权信息,读取存储的所述用户的医疗数据,包括:
解析所述第一授权信息,得到所述第一授权信息携带的所述用户在所述医疗机构服务器的身份标识;
以所述用户在所述医疗机构服务器的身份标识为索引,查询信息***,得到所述用户的每个医疗数据。
可选地,所述向所述目标区块链***中的节点设备发送所述绑定关系,包括:
使用所述医疗机构服务器在所述目标区块链***的私钥,对所述绑定关系进行签名,得到第四签名;
根据所述医疗数据、所述第四签名以及所述医疗机构服务器在所述目标区块链***的公钥,生成第二交易;
向所述目标区块链***中的节点设备发送所述第二交易。
可选地,所述从终端接收第一存储请求之前,所述方法还包括:
根据所述医疗机构服务器在所述目标区块链***的公钥,生成第三交易;
向所述目标区块链***中的节点设备发送所述第三交易。
另一方面,提供了一种基于区块链的医疗数据存储方法,应用于目标区块链***的任一节点设备,所述方法包括:
从医疗机构服务器接收医疗数据、所述医疗机构服务器在所述目标区块链***的公钥以及第三签名;
使用所述医疗机构服务器在所述目标区块链***的公钥,对所述第三签名进行验证;
查询所述目标区块链***存储的每个医疗机构的公钥,得到公钥集合;
当所述公钥属于所述公钥集合且所述第三签名验证通过时,将所述医疗数据存储至所述目标区块链***。
另一方面,提供了一种基于区块链的医疗数据存储装置,应用于终端,所述装置包括:
接收模块,用于接收第一存储指令,所述第一存储指令用于指示将用户在医疗机构服务器中存储的医疗数据存储至目标区块链***;
生成模块,用于根据所述第一存储指令,生成第一授权信息,所述第一授权信息表示所述用户授权将所述医疗数据存储至所述目标区块链***;
签名模块,用于使用所述用户在所述目标区块链***的私钥,对所述第一授权信息进行签名,得到第一签名;
发送模块,用于根据所述第一授权信息以及所述第一签名,向所述医疗机构服务器发送第一存储请求,所述第一存储请求用于请求将所述医疗数据存储至所述目标区块链***。
可选地,所述生成模块,包括:
获取子模块,用于获取目标密钥对,所述目标密钥对的公钥用于供所述医疗机构服务器对所述医疗数据进行加密;
生成子模块,用于根据所述目标密钥对的公钥,生成所述第一授权信息,所述第一授权信息包括所述目标密钥对的公钥。
可选地,所述接收模块,还用于接收授权指令,所述授权指令表示所述用户授权对所述医疗数据进行解密;
所述发送模块,还用于将所述目标密钥对的私钥发送至保险机构服务器。
可选地,所述接收模块,还用于接收第二存储指令,所述第二存储指令用于指示将所述用户在所述目标区块链***的公钥与所述用户在所述医疗机构服务器的身份标识之间的绑定关系存储至所述目标区块链***;
所述生成模块,还用于根据所述第二存储指令,生成第二授权信息,所述第二授权信息表示所述用户授权将所述绑定关系存储至所述目标区块链***;
所述签名模块,还用于使用所述用户在所述目标区块链***的私钥,对所述第二授权信息进行签名,得到第二签名;
所述发送模块,还用于根据所述第二授权信息以及所述第二签名,向所述医疗机构服务器发送第二存储请求,所述第二存储请求用于请求将所述绑定关系存储至所述目标区块链***。
可选地,所述第一存储指令包括所述医疗数据的标识、所述用户在所述医疗机构服务器的身份标识、所述目标区块链***的标识、区块链类型、区块链的标识、所述目标加密算法的标识中的至少一项。
可选地,所述第一授权信息包括所述医疗数据的标识、所述用户在所述目标区块链***的公钥、所述用户在所述医疗机构服务器的身份标识、所述目标区块链***的标识、区块链类型、区块链的标识、所述目标加密算法的标识中的至少一项。
可选地,所述接收模块,还用于从所述保险机构的服务器接收授权请求,所述授权请求用于请求所述用户授权对所述医疗数据进行解密;
所述装置还包括:显示模块,用于显示授权提示界面,所述授权提示界面用于提示所述用户授权所述保险机构服务器对所述医疗数据进行解密或者拒绝所述保险机构服务器对所述医疗数据进行解密。
可选地,所述装置还包括:
写入模块,用于向密钥管理信息写入所述医疗数据的标识与所述目标密钥对之间的对应关系,所述密钥管理信息用于记录所述用户的每个医疗数据对应的目标密钥对;
解析模块,用于解析所述授权请求,得到所述医疗数据的标识;
查询模块,用于根据所述医疗数据的标识,查询所述密钥管理信息,得到所述医疗数据的标识对应的所述目标密钥对的私钥。
可选地,所述第二存储指令包括所述用户在所述医疗机构服务器的身份标识、所述目标区块链***的标识、区块链类型、区块链的标识、所述目标加密算法的标识中的至少一项。
可选地,所述第二授权信息包括所述用户在所述目标区块链***的公钥、所述用户在所述医疗机构服务器的身份标识、所述医疗机构服务器在所述目标区块链***的公钥、所述目标区块链***的写入接口的标识、所述目标区块链***的标识、区块链类型、区块链的标识中的至少一项。
另一方面,提供了一种基于区块链的医疗数据存储装置,应用于医疗机构服务器,所述装置包括:
接收模块,用于从终端接收第一存储请求,所述第一存储请求用于请求将用户在医疗机构服务器中存储的医疗数据存储至目标区块链***;
验证模块,用于使用所述用户在所述目标区块链***的公钥,对所述第一存储请求中的第一签名进行验证;
读取模块,用于当所述第一签名验证通过时,根据所述第一存储请求中的第一授权信息,读取存储的所述用户的医疗数据,所述第一授权信息表示所述用户授权将所述医疗数据存储至所述目标区块链***;
发送模块,用于向所述目标区块链***中的节点设备发送所述医疗数据。
可选地,所述发送模块,包括:
解析子模块,用于解析所述第一存储请求,得到目标密钥对的公钥;
加密子模块,用于使用所述目标密钥对的公钥,对所述医疗数据进行加密,得到密文形式的医疗数据;
发送子模块,用于向所述目标区块链***中的节点设备发送所述密文形式的医疗数据。
可选地,所述发送模块,包括:
签名子模块,用于使用所述医疗机构服务器在所述目标区块链***的私钥,对所述医疗数据进行签名,得到第三签名;
生成子模块,用于根据所述医疗数据、所述第三签名以及所述医疗机构服务器在所述目标区块链***的公钥,生成第一交易;
发送子模块,用于向所述目标区块链***中的节点设备发送所述第一交易。
可选地,所述读取模块,包括:
解析子模块,用于解析所述第一授权信息,得到所述用户在所述目标区块链***的公钥以及所述用户在所述医疗机构服务器的身份标识;
查询子模块,用于根据所述用户在所述目标区块链***的公钥以及所述用户在所述医疗机构服务器的身份标识,查询绑定记录,所述绑定记录用于记录所述医疗机构服务器的每个用户的身份标识绑定的在所述目标区块链***的公钥;
读取子模块,用于如果所述绑定记录包括所述用户在所述目标区块链***的公钥以及所述用户在所述医疗机构服务器的身份标识之间的绑定关系,且所述第一签名验证通过时,读取存储的所述用户的医疗数据。
可选地,所述接收模块,还用于从终端接收第二存储请求,所述第二存储请求用于请求将所述用户在所述目标区块链***的公钥与所述用户在所述医疗机构服务器的身份标识之间的绑定关系存储至所述目标区块链***;
所述验证模块,还用于使用所述用户在所述目标区块链***的公钥,对所述第二存储请求中的第二签名进行验证;
所述发送模块,还用于当所述第二签名验证通过时,根据所述第二存储请求中的第二授权信息,向所述目标区块链***中的节点设备发送所述绑定关系,所述第二授权信息表示所述用户授权将所述绑定关系存储至所述目标区块链***。
可选地,所述读取模块,包括:
解析子模块,用于解析所述第一授权信息,得到所述第一授权信息携带的所述医疗数据的标识;
查询子模块,用于以所述医疗数据的标识为索引,查询信息***,得到所述医疗数据的标识对应的医疗数据。
可选地,所述读取模块,包括:
解析子模块,用于解析所述第一授权信息,得到所述第一授权信息携带的所述用户在所述医疗机构服务器的身份标识;
查询子模块,用于以所述用户在所述医疗机构服务器的身份标识为索引,查询信息***,得到所述用户的每个医疗数据。
可选地,所述发送模块,包括:
签名子模块,用于使用所述医疗机构服务器在所述目标区块链***的私钥,对所述绑定关系进行签名,得到第四签名;
生成子模块,用于根据所述医疗数据、所述第四签名以及所述医疗机构服务器在所述目标区块链***的公钥,生成第二交易;
发送子模块,用于向所述目标区块链***中的节点设备发送所述第二交易。
可选地,所述装置还包括:生成模块,用于根据所述医疗机构服务器在所述目标区块链***的公钥,生成第三交易;
所述发送模块,还用于向所述目标区块链***中的节点设备发送所述第三交易。
另一方面,提供了一种基于区块链的医疗数据存储装置,应用于目标区块链***的任一节点设备,所述装置包括:
接收模块,用于从医疗机构服务器接收医疗数据、所述医疗机构服务器在所述目标区块链***的公钥以及第三签名;
验证模块,用于使用所述医疗机构服务器在所述目标区块链***的公钥,对所述第三签名进行验证;
查询模块,用于查询所述目标区块链***存储的每个医疗机构的公钥,得到公钥集合;
存储模块,用于当所述公钥属于所述公钥集合且所述第三签名验证通过时,将所述医疗数据存储至所述目标区块链***。
可选地,所述接收模块,还用于从所述医疗机构服务器接收绑定关系以及第四签名,所述绑定关系包括所述用户在所述目标区块链***的公钥与所述用户在所述医疗机构服务器的身份标识;
所述验证模块,还用于使用所述医疗机构服务器在所述目标区块链***的公钥,对所述第四签名进行验证;
所述存储模块,还用于当所述第四签名验证通过时,将所述绑定关系存储至所述目标区块链***。
另一方面,提供了一种电子设备,所述电子设备包括一个或多个处理器和一个或多个存储器,所述一个或多个存储器中存储有至少一条程序代码,所述至少一条程序代码由所述一个或多个处理器加载并执行以实现上述基于区块链的医疗数据存储方法所执行的操作。
另一方面,提供了一种非易失性计算机可读存储介质,所述存储介质中存储有至少一条程序代码,所述至少一条程序代码由处理器加载并执行以实现上述基于区块链的医疗数据存储方法所执行的操作。
本申请实施例提供的技术方案带来的有益效果至少包括:
本申请实施例提供了一种基于用户的授权和签名,将用户的医疗数据存储到区块链的方法,通过将医疗数据存储至目标区块链***中,各个机构和用户可以通过请求目标区块链***来查询到医疗数据,从而保证医疗数据能够高效流通,并且,由于医疗机构服务器要在终端发送了第一授权信息的条件下,根据第一授权信息来请求目标区块链***存储医疗数据,从而保证将医疗数据存储至区块链的过程是在用户的授权下执行的,避免医疗数据随意入链而造成用户隐私泄露的情况,提高医疗数据的安全性和隐私性。并且,终端通过使用用户在目标区块链***的私钥,对第一授权信息进行签名,由医疗机构服务器使用用户在目标区块链***的公钥,对签名进行验证,能够保证第一授权信息是用户本人操作终端签名并发送的,保证医疗数据的入链过程是出于用户的真实意愿,避免将用户不愿意泄露的隐私数据误存储至区块链,从而提高医疗数据的安全性和隐私性。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种目标区块链***的架构图;
图2是本申请实施例提供的一种区块链的结构示意图;
图3是本申请实施例提供的一种新区块产生的流程图;
图4是本申请实施例提供的一种目标区块链***中节点设备的功能架构图;
图5是本申请实施例提供的一种基于区块链的绑定关系存储方法的流程图;
图6是本申请实施例提供的一种区块链客户端以及区块链网络的示意图;
图7是本申请实施例提供的一种基于区块链的绑定关系存储方法的流程图;
图8是本申请实施例提供的一种基于区块链的医疗数据存储方法的流程图;
图9是本申请实施例提供的一种第一交易、第二交易和第三交易的示意图;
图10是本申请实施例提供的一种基于区块链的医疗数据存储***的架构图;
图11是本申请实施例提供的一种基于区块链的医疗数据查询方法的流程图;
图12是本申请实施例提供的一种基于区块链的医疗数据存储装置的结构示意图;
图13是本申请实施例提供的一种基于区块链的医疗数据存储装置的结构示意图;
图14是本申请实施例提供的一种基于区块链的医疗数据存储装置的结构示意图;
图15是本申请实施例提供的一种终端的结构示意图;
图16是本申请实施例提供的一种医疗机构服务器的结构示意图;
图17是本申请实施例提供的一种目标区块链***中节点设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本申请中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分,应理解,“第一”、“第二”、“第n”之间不具有逻辑或时序上的依赖关系,也不对数量和执行顺序进行限定。
本申请中术语“至少一个”是指一个或多个,“多个”的含义是指两个或两个以上,例如,多个节点设备是指两个或两个以上的节点设备。
以下,对本申请涉及的名词进行介绍:
区块链(英文:blockchain):是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链本质上是一个去中心化的数据库,是一串使用密码学方法相关联产生的数据块,每一个数据块中包含了一批次网络交易的信息,用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。
区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中,用户管理模块负责所有区块链参与者的身份信息管理,包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等,并且在授权的情况下,监管和审计某些真实身份的交易情况,提供风险控制的规则配置(风控审计);基础服务模块部署在所有区块链节点设备上,用来验证业务请求的有效性,并对有效请求完成共识后,记录到存储上,对于一个新的业务请求,基础服务先对接口适配解析和鉴权处理(接口适配),然后通过共识算法将业务信息加密(共识管理),在加密之后完整一致的传输至共享账本上(网络通信),并进行记录存储;智能合约模块负责合约的注册发行以及合约触发和合约执行,开发人员可以通过某种编程语言定义合约逻辑,发布到区块链上(合约注册),根据合约条款的逻辑,调用密钥或者其它的事件触发执行,完成合约逻辑,同时还提供对合约升级注销的功能;运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出,例如:告警、监控网络情况、监控节点设备健康状态等。
平台产品服务层提供典型应用的基本能力和实现框架,开发人员可以基于这些基本能力,叠加业务的特性,完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。
共识机制(英文:consensus mechanism):是区块链***中实现不同节点之间建立信任、获取权益的数学算法。在区块链***中,通过特殊节点的投票,可以在很短的时间内完成对交易的验证和确认,对一笔交易,如果利益不相干的若干个节点能够达成共识,就可以认为***中的全部节点对此也能够达成共识。
智能合约(英文:smart contract):是一种旨在以信息化方式传播、验证或执行合同的计算机协议。区块链***中的各个节点根据特定条件自动执行的合约程序,可以对链上存储的数据进行操作,是用户与区块链进行交互、利用区块链实现业务逻辑的重要途径。智能合约的目的是提供优于传统合约的安全方法,并减少与合约相关的其他交易成本,它允许在没有第三方的情况下进行可信交易,这些交易可追踪且不可逆转。
公钥(英文:public key)与私钥(英文:private key):是通过一种算法得到的一个密钥对(即一个公钥和一个私钥),公钥是密钥对中公开的部分,私钥则是非公开的部分。公钥通常用于加密数据、验证数字签名等。通过这种算法能够确保得到的密钥对是唯一的,使用这种密钥对的时候,如果用其中一个密钥加密一段数据,必须用另一个密钥解密,例如,用公钥加密数据就必须用私钥解密,如果用私钥加密也必须用公钥解密,否则解密将不会成功。
本申请实施例提供了基于上述区块链技术实现的目标区块链***,以下对该目标区块链***的***架构进行介绍。
参见图1,该目标区块链***中可以包括多个节点设备101,此外,目标区块链***还可以包括客户端。
节点设备101可以是网络中的任意形式的计算设备,如服务器、主机、用户终端等。节点设备101与节点设备101之间能够共享数据,例如,在下述方法实施例中,不同节点设备101可以共享用户在目标区块链***的公钥、医疗机构服务器在目标区块链***的公钥、用户的医疗数据、用户在目标区块链***的公钥与在医疗机构服务器的身份标识之间的绑定关系。其中,节点设备101之间可以基于点对点(Peer To Peer,P2P)协议,建立P2P网络。该P2P协议是一个运行在传输控制协议(Transmission Control Protocol,TCP)协议之上的应用层协议。
每个节点设备101在进行正常工作的过程中,可以接收到输入信息,并基于接收到的输入信息维护该目标区块链***内的共享数据,例如,在下述方法实施例中,节点设备101接收到的输入信息可以为用户的医疗数据、用户在目标区块链***的公钥与在医疗机构服务器的身份标识之间的绑定关系。为了保证目标区块链***内的信息互通,目标区块链***中的每个节点设备之间可以存在信息连接,节点设备之间可以通过上述信息连接进行信息传输。例如,当目标区块链***中的任意节点设备接收到输入信息时,目标区块链***中的其他节点设备便根据共识算法获取该输入信息,将该输入信息作为共享数据中的数据进行存储,使得目标区块链***中全部节点设备上存储的数据均一致。
对于目标区块链***中的每个节点设备,均具有与其对应的节点设备的标识,而且目标区块链***中的每个节点设备均可以存储有目标区块链***中其他节点设备的节点设备标识,以便后续根据其他节点设备的节点设备标识,将生成的区块广播至目标区块链***中的其他节点设备。每个节点设备中可维护一个如下表1所示的节点设备标识列表,将节点设备名称和节点设备标识对应存储至该节点设备标识列表中。其中,节点设备标识可为IP(Internet Protocol,网络之间互联的协议)地址以及其他任一种能够用于标识该节点设备的信息,表1中仅以IP地址为例进行说明。
表1
节点设备名称 | 节点设备标识 |
节点设备1 | 117.114.151.174 |
节点设备2 | 117.116.189.145 |
… | … |
节点设备N | 119.123.789.258 |
目标区块链***中的每个节点设备均存储一条相同的区块链。区块链由多个区块组成,参见图2,区块链由多个区块组成,创始块中包括区块头和区块主体,区块头中存储有输入信息特征值、版本号、时间戳和难度值,区块主体中存储有输入信息;创始块的下一区块以创始块为父区块,下一区块中同样包括区块头和区块主体,区块头中存储有当前区块的输入信息特征值、父区块的区块头特征值、版本号、时间戳和难度值,并以此类推,使得区块链中每个区块中存储的区块数据均与父区块中存储的区块数据存在关联,保证了区块中输入信息的安全性。
在生成区块链中的各个区块时,参见图3,区块链所在的节点设备在接收到输入信息时,对输入信息进行校验,完成校验后,将输入信息存储至内存池中,并更新其用于记录输入信息的哈希树;之后,将更新时间戳更新为接收到输入信息的时间,并尝试不同的随机数,多次进行特征值计算,使得计算得到的特征值可以满足下述公式:
SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x))<TARGET
其中,SHA256为计算特征值所用的特征值算法;version(版本号)为区块链中相关区块协议的版本信息;prev_hash为当前区块的父区块的区块头特征值;merkle_root为输入信息的特征值;ntime为更新时间戳的更新时间;nbits为当前难度,在一段时间内为定值,并在超出固定时间段后再次进行确定;x为随机数;TARGET为特征值阈值,该特征值阈值可以根据nbits确定得到。
这样,当计算得到满足上述公式的随机数时,便可将信息对应存储,生成区块头和区块主体,得到当前区块。随后,区块链所在节点设备根据目标区块链***中其他节点设备的节点设备标识,将新生成的区块分别发送给其所在的目标区块链***中的其他节点设备,由其他节点设备对新生成的区块进行校验,并在完成校验后将新生成的区块添加至其存储的区块链中。
以下,对节点设备101的功能架构进行介绍。
参见图4,节点设备101从功能上可以划分为硬件层、中间层、操作***层和应用层,涉及的具体功能可以如下:
1)路由,节点设备具有的基本功能,用于支持节点设备之间的通信。
节点设备除具有路由功能外,还可以具有以下功能:
2)应用,用于部署在区块链中,根据实际业务需求而实现特定业务,记录实现功能相关的数据形成记录数据,在记录数据中携带数字签名以表示任务数据的来源,将记录数据发送到区块链***中的其他节点设备,供其他节点设备在验证记录数据来源以及完整性成功时,将记录数据添加到临时区块中。
例如,应用实现的业务包括:
2.1)钱包,用于提供进行电子货币的交易的功能,包括发起交易(即,将当前交易的交易记录发送给区块链***中的其他节点设备,其他节点设备验证成功后,作为承认交易有效的响应,将交易的记录数据写入区块链的临时区块中;当然,钱包还支持查询电子货币地址中剩余的电子货币。
2.2)共享账本,用于提供账目数据的存储、查询和修改等操作的功能,将对账目数据的操作的记录数据发送到区块链***中的其他节点设备,其他节点设备验证有效后,作为承认账目数据有效的响应,将记录数据写入临时区块中,还可以向发起操作的节点设备发送确认。
2.3)智能合约,计算机化的协议,可以执行某个合约的条款,通过部署在共享账本上的用于在满足一定条件时而执行的代码实现,根据实际的业务需求代码用于完成自动化的交易,例如查询买家所购买商品的物流状态,在买家签收货物后将买家的电子货币转移到商户的地址;当然,智能合约不仅限于执行用于交易的合约,还可以执行对接收的信息进行处理的合约。
3)区块链,包括一系列按照产生的先后时间顺序相互接续的区块(Block),新区块一旦加入到区块链中就不会再被移除,区块中记录了区块链***中节点设备提交的记录数据。
本申请实施例中,用户的区块链身份可以通过用户在目标区块链***的公钥来表示,用户在医疗机构的身份可以通过用户在医疗机构服务器的身份标识来表示,通过在目标区块链***中,存储用户在目标区块链***的公钥与该用户在医疗机构服务器的身份标识之间的绑定关系,从而将用户的区块链身份与在医疗机构的身份绑定起来,具体参见以下图5实施例。
图5是本申请实施例提供的一种基于区块链的绑定关系存储方法的流程图,参见图5,该实施例以交互主体包括终端、医疗机构服务器以及目标区块链***中的任一节点设备为例进行说明,参见图5,该方法包括:
501、终端接收第二存储指令。
第二存储指令用于指示将用户在目标区块链***的公钥与用户在医疗机构服务器的身份标识之间的绑定关系存储至目标区块链***。第二存储指令可以由用户在终端的操作触发。第二存储指令可以包括用户在医疗机构服务器的身份标识,可选地,第二存储指令还可以包括目标区块链***的标识、区块链类型、区块链的标识中的至少一项。
用户在该医疗机构服务器的身份标识用于在医疗机构服务器中标识用户的身份,不同用户在医疗机构服务器的身份标识不同。示意性地,身份标识可以为用户的身份证号码、用户在医院中的身份编号、就诊卡的***、社保账号等。第二存储指令通过携带用户在该医疗机构服务器的身份标识,能够指明用户的身份,即用户是哪一位病人,以便医疗机构服务器通过身份标识来确定用户的身份。用户在该医疗机构服务器的身份标识可以由用户在终端上输入,也可以在终端上预先存储。
目标区块链***可以用于存储用户在目标区块链***的公钥与该用户在该医疗机构服务器的身份标识之间的绑定关系,目标区块链***的架构可以参见图1。目标区块链***的标识用于标识目标区块链***,例如,目标区块链***的标识可以为目标区块链***的身份标识号(Identity,ID)、名称或网络地址等。第二存储指令通过携带目标区块链***的标识,可以指明将绑定关系存储至哪个区块链***中,以便医疗机构服务器通过目标区块链***的标识来确定将绑定关系发送至哪个区块链***中的节点设备。
可选地,终端可以支持与一个或多个区块链***进行交互,目标区块链***可以为终端支持交互的一个或多个区块链***中的一个区块链***。例如,目标区块链***可以为该一个或多个区块链***中用户选择的区块链***,或者可以为一个或多个区块链***中默认配置的区块链***。在一些实施例中,终端可以显示区块链***选择界面,该区块链***选择界面用于提示用户从一个或多个区块链***中选择用于存储绑定关系的区块链***,该区块链***选择界面可以包括该一个或多个区块链***中每个区块链***对应的控件,用户可以从一个或多个区块链***中,选择目标区块链***,对目标区块链***对应的控件触发操作,则终端可以根据用户触发的操作,确定该目标区块链***。通过这种方式,用户能够指定将自己的绑定关系存入哪一个区块链***维护的区块链,从而提高了存储绑定关系的灵活性,保证存储绑定关系的区块链***满足用户的自定义需求。
区块链类型可以包括公有链、私有链或联盟链中的至少一种。第二存储指令通过携带区块链类型,可以指明将绑定关系存储至哪种类型的区块链。可选地,第二存储指令中的区块链类型可以为用户选择的区块链类型,或者可以为默认配置的区块链类型。在一些实施例中,终端可以显示区块链类型选择界面,该区块链类型选择界面用于提示用户从一个或多个区块链类型中选择用于存储绑定关系的区块链类型,该区块链类型选择界面可以包括该一个或多个区块链类型中每个区块链类型对应的控件,用户可以从一个或多个区块链类型中,选择区块链类型,对选择的区块链类型对应的控件触发操作,则用户选择的区块链类型会携带在第二存储指令中。通过这种方式,用户能够指定将自己的绑定关系存入哪一个区块链类型的区块链,从而提高了存储绑定关系的灵活性,保证存储绑定关系的区块链类型满足用户的自定义需求。
区块链的标识用于标识区块链,例如可以是区块链的ID、编号或名称等。第二存储指令通过携带区块链的标识,可以指明将绑定关系存储至目标区块链***的哪一个区块链中。可选地,第二存储指令中的区块链的标识可以对应于用户选择的区块链,或者对应于默认配置的区块链。在一些实施例中,终端可以显示区块链选择界面,该区块链选择界面用于提示用户从一个或多个区块链中选择用于存储绑定关系的区块链,该区块链选择界面可以包括该一个或多个区块链中每个区块链对应的控件,用户可以从一个或多个区块链中,选择区块链,对选择的区块链对应的控件触发操作,则用户选择的区块链的标识会携带在第二存储指令中。通过这种方式,用户能够指定将自己的绑定关系存入目标区块链***的哪一个区块链,从而提高了存储绑定关系的灵活性,保证存储绑定关系的区块链满足用户的自定义需求。
502、终端根据该第二存储指令,生成第二授权信息。
第二授权信息表示用户授权将绑定关系存储至该目标区块链***。第二授权信息包括用户在目标区块链***的公钥、用户在该医疗机构服务器的身份标识、目标区块链***的标识、区块链类型、区块链的标识、写入接口的标识中的至少一项。在一些实施例中,终端可以解析第二存储指令,得到第二存储指令携带的内容,对第二存储指令携带的内容进行封装,得到该第二授权信息。
用户在目标区块链***的公钥能够在目标区块链***中标识用户的身份,因此,公钥可以视为用户的区块链身份。用户在该目标区块链***的公钥可以预先存储在终端中,用户在该目标区块链***的公钥可以对目标区块链***中的每个节点设备公开。
写入接口用于向目标区块链***传入待存储的数据。具体而言,目标区块链***通过提供写入接口,目标区块链***之外的其他设备可以调用写入接口,将待存储的数据传入该写入接口,使得目标区块链***中的节点设备可以接收写入接口传入的数据,从而存储传入的数据。写入接口的标识用于标识对应的写入接口,例如可以是写入接口的接口名、接口ID等。可选地,写入接口的传入参数可以包括加密后的医疗数据、医疗机构服务器在目标区块链***的公钥以及医疗机构服务器的签名。在一些实施例中,终端可以存储一个或多个区块链***中每个区块链***的写入接口的标识,可以从这些写入接口的标识中,选择目标区块链***的写入接口的标识,将目标区块链***的写入接口的标识写入至第二授权信息中,以便医疗机构服务器根据第二授权信息中写入接口的标识,调用目标区块链***提供的写入接口。
503、终端使用用户在目标区块链***的私钥,对第二授权信息进行签名,得到第二签名。
用户在目标区块链***的私钥与用户在目标区块链***的公钥属于同一密钥对,用户在目标区块链***的私钥可以预先存储在终端中,用户在目标区块链***的私钥可以由终端生成。
第二签名为第二授权信息的数字签名,第二签名用于验证第二授权信息的真实性,即第二授权信息是否由用户本人操作终端发送,另外第二签名还可以用于验证第二授权信息的完整性,即第二授权信息是否在传输过程中被篡改或发生丢失。关于第二签名的生成过程,在一些实施例中,终端可以计算第二授权信息的哈希值,使用用户在目标区块链***的私钥,对第二授权信息的哈希值进行加密,得到密文形式的第二授权信息的哈希值,该密文形式的第二授权信息的哈希值即为第二签名。
504、终端根据第二授权信息以及第二签名,向医疗机构服务器发送第二存储请求。
第二存储请求用于请求医疗机构服务器将绑定关系存储至目标区块链***。第二存储请求可以包括第二授权信息以及第二签名。终端可以对第二授权信息以及第二签名进行封装,得到该第二存储请求。
需要说明的一点是,上述步骤501至步骤504可以由终端上的区块链客户端执行。具体而言,终端可以安装和运行区块链的客户端,该客户端用于与目标区块链***进行交互,用户可以在客户端上进行操作,触发第二存储指令,以使客户端执行步骤501至步骤504。参见图6,区块链的客户端可以为应用程序(英文:Application,简称:app),也可以为嵌入式程序,即小程序。区块链客户端可以在手机上运行,也可以在个人电脑上运行。区块链客户端可以存储用户在目标区块链***的公钥以及用户在目标区块链***的私钥,另外,区块链客户端还可以存储一个或多个区块链***中每个区块链***的标识、一个或多个区块链类型、一个或多个区块链中每个区块链的标识、每个区块链***的写入接口的标识。
505、医疗机构服务器从终端接收第二存储请求,使用用户在目标区块链***的公钥,对第二存储请求中的第二签名进行验证。
在一些实施例中,第二存储请求的传输过程可以通过扫码的方式实现。具体而言,终端可以根据第二存储请求,生成二维码,该二维码携带第二存储请求。终端可以显示二维码,从而将第二存储请求以二维码的形式进行展示。医疗机构的工作人员可以通过扫描设备,对二维码进行扫描,扫描设备可以接收二维码,对二维码进行解析,得到二维码携带的第二存储请求,向医疗机构服务器发送第二存储请求,医疗机构服务器可以从扫描设备接收到第二存储请求。其中,扫描设备可以为码枪、摄像头或者其他能够扫描二维码的设备。通过扫码的方式,可以快速地接收到第二存储请求,节省了接收第二存储请求的时间,提高了接收第二存储请求的效率。当然,扫码的方式为可选方式,在另一些实施例中,终端可以与医疗机构服务器建立网络连接,可以通过网络连接,向医疗机构服务器发送第二存储请求,医疗机构服务器可以通过网络连接,接收第二存储请求。
医疗机构服务器可以解析第二存储请求,得到第二存储请求携带的第二授权信息以及第二签名,解析第二授权信息,得到第二授权信息中的用户在该目标区块链***的公钥、用户在该医疗机构服务器的身份标识、目标区块链***的标识、区块链类型、区块链的标识、写入接口的标识中的至少一项。可选地,医疗机构服务器可以存储用户在医疗机构服务器的身份标识与写入接口的标识之间的对应关系,以便后续在存储医疗数据时,根据用户在医疗机构服务器的身份标识,从对应关系中查询到写入接口的标识,调用该写入接口的标识对应的写入接口,来请求目标区块链***存储医疗数据。
在另一些实施例中,对第二签名进行验证的过程可以包括下述步骤一至步骤五:
步骤一、医疗机构服务器可以使用用户在目标区块链***的公钥,对第二签名进行解密,得到哈希值。
步骤二、医疗机构服务器可以计算第二授权信息的哈希值。
步骤三、医疗机构服务器可以对解密得出的哈希值与计算的哈希值进行对比。
步骤四、如果两个哈希值一致,则第二签名验证通过。
如果第二签名验证通过,一方面,能够证明第二授权信息是由用户本人操作终端签名并发送的,第二授权信息并不是其他用户伪造的授权信息,从而验证了用户的身份的真实性,保证将绑定关系存储至目标区块链***的过程是在用户本人的授权下执行的,是出于用户本人的真实意愿,避免将用户不愿意公开的隐私医疗数据误存储至目标区块链***。另一方面,能够证明第二授权信息是完整的,在传输过程中没有被篡改过。
步骤五、如果两个哈希值不一致,则第二签名验证不通过。
506、当第二签名验证通过时,医疗机构服务器根据第二存储请求中的第二授权信息,向目标区块链***中的第一节点设备发送该绑定关系。
医疗机构服务器可以根据第二授权信息中的用户在该目标区块链***的公钥以及用户在该医疗机构服务器的身份标识,建立用户在目标区块链***的公钥与用户在医疗机构服务器的身份标识之间的绑定关系,向第一节点设备发送该绑定关系,该第一节点设备为目标区块链***中的任一节点设备。
其中,如果第二授权信息包括目标区块链***的标识,医疗机构服务器可以根据第二授权信息中的目标区块链***的标识,向目标区块链***的标识对应的目标区块链***中的第一节点设备发送绑定关系。如果第二授权信息包括区块链类型,医疗机构服务器可以向目标区块链***中的第一节点设备发送绑定关系以及区块链类型,以指明要在符合该区块链类型的区块链中存储绑定关系。如果第二授权信息包括区块链的标识,医疗机构服务器可以向目标区块链***中的第一节点设备发送区块链的标识,以指明要在区块链的标识对应的区块链中存储绑定关系。如果第二授权信息包括写入接口的标识,医疗机构服务器可以调用该写入接口的标识对应的写入接口,向该写入接口传入绑定关系,从而以调用接口的方式,将绑定关系发往提供该写入接口的目标区块链***。
此外,当第二签名验证不通过时,医疗机构服务器可以拒绝向该目标区块链***中的节点设备发送绑定关系,此外,医疗机构服务器还可以向终端返回失败消息,该失败消息用于通知终端第二签名验证不通过,以便终端重新对第二授权信息进行签名,向医疗机构服务器重传携带新签名的第二存储请求。
在一些实施例中,医疗机构服务器可以在对第二签名进行验证的基础上,还对用户在医疗机构服务器的身份标识进行验证,当第二签名验证通过且用户在医疗机构服务器的身份标识验证通过时,医疗机构服务器向第一节点设备发送该绑定关系;当该第二签名验证不通过或者用户在医疗机构服务器的身份标识验证不通过时,医疗机构服务器拒绝向第一节点设备发送该绑定关系。具体而言,医疗机构服务器可以查询医疗机构服务器中已注册的身份标识,得到身份标识集合,判断第二授权信息中用户在该医疗机构服务器的身份标识是否属于身份标识集合,当第二授权信息中用户在医疗机构服务器的身份标识属于身份标识集合,表明用户的身份标识已经预先注册,则对用户在医疗机构服务器的身份标识验证通过,当第二授权信息中用户在医疗机构服务器的身份标识不属于身份标识集合,表明用户的身份标识尚未注册,则对用户在医疗机构服务器的身份标识验证不通过。可选地,如果用户在医疗机构服务器的身份标识验证不通过,医疗机构服务器可以生成失败消息,向终端发送失败消息。该失败消息用于提示用户在医疗机构服务器的身份标识验证不通过,另外,该失败消息还可以引导用户进行注册,例如可以携带注册界面的链接地址。
在一些实施例中,医疗机构服务器可以将绑定关系打包为一笔交易,从而将绑定关系以交易的形式发送至目标区块链***,具体可以参见以下步骤一至步骤三:
步骤一、医疗机构服务器可以使用该医疗机构服务器在该目标区块链***的私钥,对该绑定关系进行签名,得到第四签名。
第四签名为绑定关系的数字签名,第四签名用于验证医疗机构服务器身份的真实性,还用于验证绑定关系的完整性,即绑定关系在传输过程中没有被篡改,也没有发生丢失。第四签名的生成过程可以包括:医疗机构服务器可以计算绑定关系的哈希值,使用医疗机构服务器在该目标区块链***的私钥,对绑定关系的哈希值进行加密,得到密文形式的绑定关系的哈希值,该密文形式的绑定关系的哈希值即为第四签名。
步骤二、医疗机构服务器可以根据该绑定关系、该第四签名以及该医疗机构服务器在该目标区块链***的公钥,生成第二交易。
具体地,医疗机构服务器可以对绑定关系、第四签名以及医疗机构服务器在目标区块链***的公钥进行封装,得到第二交易。其中,第二交易包括绑定关系、第四签名以及医疗机构服务器在该目标区块链***的公钥,另外,第二交易还可以包括第二交易的交易ID,该交易ID用于标识第二交易。
步骤三、医疗机构服务器向该目标区块链***中的第一节点设备发送该第二交易。
例如,医疗机构服务器可以调用目标区块链***提供的写入接口,向写入接口传入第二交易,从而以调用接口的方式将第二交易发往目标区块链***。
507、目标区块链***中的第一节点设备从医疗机构服务器接收绑定关系,将绑定关系存储至目标区块链***。
第一节点设备为目标区块链***中的任一节点设备。绑定关系的存储过程可以包括:第一节点设备可以根据绑定关系,生成第一区块,第一节点设备可以基于目标区块链***内的共识机制,将第一区块添加至区块链,从而将绑定关系存储在区块链中。其中,第一区块包括该绑定关系,第一区块还可以包括第四签名,以便病人或其他机构访问第一区块中的绑定关系时,能够得到第四签名,从而通过第四签名来验证绑定关系的真实性和完整性。生成第一区块以及添加至区块链的具体流程可以参见图1至图3的介绍,在此不做赘述。另外,如果医疗机构服务器以交易的形式发送了绑定关系,则第一节点设备可以接收到携带了绑定关系的第二交易,将第二交易通过上述方式存储在目标区块链***中,则目标区块链***的区块链会存储第二交易。
在一些实施例中,第一节点设备可以通过验证第四签名,来验证绑定关系的合法性和完整性。具体而言,第一节点设备还可以从医疗机构服务器接收该医疗机构服务器在该目标区块链***的公钥以及第四签名,使用该医疗机构服务器在该目标区块链***的公钥,对该第四签名进行验证。当第四签名验证通过时,第一节点设备将绑定关系存储至目标区块链***。当该第四签名验证不通过时,第一节点设备拒绝将绑定关系存储至目标区块链***。
通过对第四签名进行验证,能够保证绑定关系的真实性,即绑定关系确实是由医疗机构服务器发送的,而非用户或第三方伪造的数据,同时,能够保证绑定关系的完整性,即绑定关系在传输过程中没有被篡改,也没有发生丢失,从而保证区块链上存储的绑定关系是真实可信的。
另外,如果绑定关系以交易的形式发往目标区块链***,第一节点设备可以解析第二交易,得到第二交易中的医疗机构服务器在该目标区块链***的公钥以及第四签名。如果目标区块链***与医疗机构服务器以调用接口的方式交互,第一节点设备可以从写入接口,接收传入的第二交易。如果医疗机构服务器还发送了区块链类型,第一节点设备还会接收到区块链类型,将携带绑定关系的第一区块添加至该区块链类型对应的区块链,从而保证存储绑定关系的区块链类型满足用户的自定义需求。如果医疗机构服务器还发送了区块链的标识,则第一节点设备还会接收到区块链的标识,将携带绑定关系的第一区块添加至该区块链的标识对应的区块链,从而保证存储绑定关系的区块链满足用户的自定义需求。
在一些实施例中,对第四签名进行验证的过程可以包括下述步骤(1)至步骤(5):
步骤(1)第一节点设备可以使用该医疗机构服务器在该目标区块链***的公钥,对第四签名进行解密,得到哈希值。
医疗机构服务器在目标区块链***的公钥可以预先存储在目标区块链***配置的区块链上,第一节点设备可以从区块链上获取医疗机构服务器在目标区块链***的公钥。在一些实施例中,医疗机构服务器在目标区块链***的公钥的存储方式可以包括下述方式一至方式二中的任意一种:
方式一、医疗机构服务器可以向目标区块链***的第二节点设备发送公钥,第二节点设备可以接收医疗机构服务器的公钥,根据公钥生成第二区块,第二区块包括医疗机构服务器在该目标区块链***的公钥。第二节点设备可以基于目标区块链***内的共识机制,将第二区块添加至区块链,从而将医疗机构服务器的公钥存储在区块链中。
其中,第二节点设备为目标区块链***中的任一节点设备,第二节点设备和第一节点设备可以为不同的节点设备或相同的节点设备。
在一些实施例中,医疗机构服务器可以将公钥打包为一笔交易,从而以交易的形式来发送公钥。具体地,医疗机构服务器可以对公钥进行封装,得到第三交易,该第三交易至少包括公钥,另外还可以包括公钥之外的其他身份信息,例如医疗机构的名称、ID等,因此第三交易也可以称为身份信息交易。医疗机构服务器可以向目标区块链***的第二节点设备发送第三交易,第二节点设备可以接收第三交易,将第三交易存储至目标区块链***的区块链。
方式二、目标区块链***中的节点设备可以预先获取一个或多个合法的医疗机构中每个医疗机构的医疗机构服务器的公钥,将每个医疗机构的医疗机构服务器的公钥存储至目标区块链***。
步骤(2)第一节点设备可以计算绑定关系的哈希值。
步骤(3)第一节点设备可以对解密得出的哈希值与计算的哈希值进行对比。
步骤(4)如果两个哈希值一致,则第四签名验证通过。
如果两个哈希值一致,表明第四签名是正确的,确实是根据医疗机构服务器在目标区块链***的私钥产生的,从而证明绑定关系是由医疗机构服务器签名并发送的,而非第三方伪造的数据,从而验证了绑定关系的真实性以及可信性。另一方面,表明第一节点设备接收到的绑定关系与医疗机构服务器发送的绑定关系是一致的,从而证明绑定关系是完整的,在传输过程中没有被篡改过。
步骤(5)如果两个哈希值不一致,则第四签名验证不通过。
508、如果绑定关系存储成功,第一节点设备向医疗机构服务器发送成功消息。
成功消息表示绑定关系成功存储至目标区块链***。此外,如果绑定关系存储失败,或者由于第四签名验证不通过使得第一节点设备拒绝存储绑定关系,目标区块链***可以向医疗机构服务器发送失败消息,该失败消息表示绑定关系未存储至目标区块链***。
509、医疗机构服务器从第一节点设备接收成功消息,存储绑定关系。
在一些实施例中,医疗机构服务器可以记录每个用户的绑定关系。具体而言,医疗机构服务器可以生成绑定记录,该绑定记录用于记录该医疗机构服务器的每个用户的身份标识绑定的在该目标区块链***的公钥,绑定记录可以包括一个或多个绑定关系,绑定记录中的每个绑定关系可以对应一个用户,每个绑定关系包括对应用户的身份标识与该用户在目标区块链***的公钥。医疗机构服务器可以向绑定记录中添加已成功存储至目标区块链***的绑定关系,从而更新绑定记录。
在一些实施例中,医疗机构服务器可以存储用户信息库,该用户信息库用于存储用户的一种或多种信息,医疗机构服务器可以查询用户信息库中用户在该医疗机构服务器的身份标识对应的信息条目,向该信息条目写入用户在该目标区块链***的公钥,从而标记用户在该目标区块链***的公钥,将用户的已入库的其他信息和公钥绑定起来。
此外,如果医疗机构服务器从第一节点设备接收到失败消息,医疗机构服务器可以将失败消息发送至终端,终端可以接收失败消息,可以提示用户绑定关系存储失败,另外还可以向医疗机构服务器重传第二授权信息,以便医疗机构服务器向目标区块链***重传绑定关系。
参见图7,其示出了医疗机构服务器的公钥以及绑定关系入链的流程图,该流程包括下述步骤1至步骤8:
步骤1、医疗机构服务器获取公钥。
步骤2、医疗机构服务器根据公钥,生成第三交易。
步骤3、医疗机构服务器向目标区块链***中的节点设备发送第三交易,目标区块链***中的节点设备接收第三交易,根据第三交易生成区块,基于共识机制,将区块添加至区块链,从而将第三交易入链,那么由于第三交易携带了医疗机构服务器的公钥,能够将医疗机构服务器的公钥在目标区块链***的区块链上存储。
步骤4、终端生成第二授权信息,向医疗机构服务器发送第二授权信息。
步骤5、医疗机构服务器接收第二授权信息。
步骤6、医疗机构服务器根据第二授权信息,生成第二交易。
步骤7、医疗机构服务器向目标区块链***中的节点设备发送第二交易,目标区块链***中的节点设备接收第二交易,根据第二交易生成区块,基于共识机制,将区块添加至区块链,从而将第二交易入链,那么由于第二交易携带了绑定关系,能够将绑定关系在目标区块链***的区块链上存储。
步骤8、目标区块链***向医疗机构服务器发送成功消息,医疗机构服务器接收成功消息,存储绑定关系;或者,目标区块链***向医疗机构服务器发送失败消息。
本实施例提供了一种基于用户的授权和签名,将用户在目标区块链***的公钥与在医疗机构服务器的身份标识之间的绑定关系存储到区块链的方法。由于绑定关系是根据第二授权信息查询和存储的,使得在用户已经授权将绑定关系存储至目标区块链***的情况下,绑定关系才会存入区块链,从而避免绑定关系随意入链造成用户隐私泄露的情况。并且,终端通过使用用户在目标区块链***的私钥,对第二授权信息进行签名,由医疗机构服务器使用用户在目标区块链***的公钥,对签名进行验证,能够保证第二授权信息是用户本人通过终端签名并发送的,保证将绑定关系入链的过程出于用户的真实意愿,提高存储绑定关系的安全性。此外,通过将绑定关系存储在目标区块链***中,由于存储在区块链中的数据不可篡改,可以避免绑定关系在存储过程中被篡改。并且,第三方能够通过向区块链***的节点设备发送查询请求,来得到用户的绑定关系,打破了医疗机构仅对内部***息的限制,便于第三方查询绑定关系。
图5实施例介绍了基于区块链存储绑定关系的方法,在图5实施例的基础上,本申请实施例还提供了一种基于区块链存储医疗数据的方法,具体参见下述图8实施例。可选地,图8实施例可以在图5实施例之后执行。需要说明的是,图8实施例着重描述与图5实施例的区别之处,而与图5实施例同理的步骤还请参见图5实施例,在图8实施例中不做赘述。
图8是本申请实施例提供的一种基于区块链的医疗数据存储方法的流程图,本实施例以交互主体包括终端、医疗机构服务器以及目标区块链***中的任一节点设备为例进行说明,参见图8,该方法包括:
801、终端接收第一存储指令。
第一存储指令用于指示将用户在医疗机构服务器中存储的医疗数据存储至目标区块链***。第一存储指令可以由用户在终端运行的区块链客户端上的操作触发。第一存储指令可以包括医疗数据的标识、用户在该医疗机构服务器的身份标识、目标区块链***的标识、区块链类型、区块链的标识、该目标加密算法的标识中的至少一项。
医疗数据的标识用于标识对应的医疗数据,以医疗数据的标识为索引,能够在医疗机构服务器的信息***中查询到对应的医疗数据。示例性地,医疗数据的标识可以包括医疗数据的ID或医疗数据的时间戳中的至少一项。以医疗数据为就诊数据为例,就诊数据的标识可以包括就诊ID、就诊时间点或就诊时间点所属的时间范围中的至少一项。第一存储指令中的医疗数据的标识可以为一个或多个,对应着用户的一条或多条医疗数据。医疗数据的标识可以由用户在终端上输入。第一存储指令通过携带医疗数据的标识,能够指明要向目标区块链***存储哪一条或多条医疗数据,以便医疗机构服务器通过医疗数据的标识查询到对应的医疗数据,将其存储至目标区块链***。
目标区块链***的描述还请参见图5实施例,与图5实施例相区别的是,本实施例中,目标区块链***还用于存储用户的医疗数据,第一存储指令通过携带目标区块链***的标识,可以指明将医疗数据存储至哪个区块链***中,以便医疗机构服务器通过目标区块链***的标识来确定将医疗数据发送至哪个区块链***中的节点设备。在一些实施例中,终端可以显示区块链***选择界面,该区块链***选择界面用于提示用户从一个或多个区块链***中选择用于存储医疗数据的区块链***,该区块链***选择界面可以包括该一个或多个区块链***中每个区块链***对应的控件,用户可以从一个或多个区块链***中,选择目标区块链***,对目标区块链***对应的控件触发操作,则终端可以根据用户触发的操作,确定该目标区块链***。通过这种方式,用户能够指定将自己的医疗数据存入哪一个区块链***维护的区块链,从而提高了存储医疗数据的灵活性,保证存储医疗数据的区块链***满足用户的自定义需求。
区块链类型的描述还请参见图5实施例,第一存储指令通过携带区块链类型,可以指明将医疗数据存储至哪种类型的区块链。可选地,第一存储指令中的区块链类型可以为用户选择的区块链类型,或者可以为区块链客户端中默认配置的区块链类型。在一些实施例中,终端可以显示区块链类型选择界面,该区块链类型选择界面用于提示用户从一个或多个区块链类型中选择用于存储医疗数据的区块链类型,该区块链类型选择界面可以包括该一个或多个区块链类型中每个区块链类型对应的控件,用户可以从一个或多个区块链类型中,选择区块链类型,对选择的区块链类型对应的控件触发操作,则用户选择的区块链类型会携带在第一存储指令中。通过这种方式,用户能够指定将自己的医疗数据存入哪一个区块链类型的区块链,从而提高了存储医疗数据的灵活性,保证存储医疗数据的区块链类型满足用户的自定义需求。
区块链的标识的描述还请参见图5实施例。第一存储指令通过携带区块链的标识,可以指明将医疗数据存储至目标区块链***的哪一个区块链中。可选地,第一存储指令中的区块链的标识可以对应于用户选择的区块链,或者对应于区块链客户端中默认配置的区块链。在一些实施例中,终端可以显示区块链选择界面,该区块链选择界面用于提示用户从一个或多个区块链中选择用于存储医疗数据的区块链,该区块链选择界面可以包括该一个或多个区块链中每个区块链对应的控件,用户可以从一个或多个区块链中,选择区块链,对选择的区块链对应的控件触发操作,则用户选择的区块链会携带在第一存储指令中。通过这种方式,用户能够指定将自己的医疗数据存入目标区块链***的哪一个区块链,从而提高了存储医疗数据的灵活性,保证存储医疗数据的区块链满足用户的自定义需求。
目标加密算法为医疗机构对医疗数据进行加密采用的加密算法。目标加密算法的标识用于标识目标加密算法,例如可以是目标加密算法的ID、编号或名称等。可选地,目标加密算法可以为用户选择的加密算法,或者为终端默认配置的加密算法。在一些实施例中,终端可以显示加密算法选择界面,该加密算法选择界面用于提示用户从一个或多个加密算法中选择用于加密医疗数据的加密算法,该加密算法选择界面可以包括该一个或多个加密算法中每个加密算法对应的控件,用户可以从一个或多个加密算法中,选择目标加密算法,对选目标加密算法对应的控件触发操作,则目标加密算法会携带在第一存储指令中。通过这种方式,用户能够指定将自己的医疗数据使用哪一种加密算法加密,从而提高了存储医疗数据的灵活性和安全性,保证加密医疗数据的方式满足用户的自定义需求。
需要说明的一点是,第一存储指令携带目标加密算法的标识为可选方式,而非必选方式。在另一些实施例中,如果免去医疗机构服务器对医疗数据进行加密的步骤,或者医疗机构服务器固定采用默认配置的加密算法对医疗数据进行加密,则第一存储指令可以不携带目标加密算法的标识。
802、终端根据该第一存储指令,生成第一授权信息。
第一授权信息表示用户授权将医疗数据存储至该目标区块链***。第一授权信息包括医疗数据的标识、用户在该目标区块链***的公钥、用户在该医疗机构服务器的身份标识、目标区块链***的标识、区块链类型、区块链的标识、该目标加密算法的标识中的至少一项。在一些实施例中,终端可以解析第一存储指令,得到第一存储指令携带的内容,对第一存储指令携带的内容进行封装,得到第一授权信息。
在一些实施例中,可以实现将医疗数据加密存储至目标区块链***的功能,让目标区块链***存储密文形式的医疗数据。具体而言,生成第一授权信息的过程可以包括下述步骤一至步骤二:
步骤一、终端可以获取目标密钥对。
终端可以生成目标密钥对,也可以接收用户输入的目标密钥对,本实施例对获取目标密钥对的方式不做限定。其中,目标密钥对可以称为信息加密密钥,即用于加密医疗数据这种信息的密钥。目标密钥对包括公钥和私钥,目标密钥对的公钥用于供医疗机构服务器对医疗数据进行加密,目标密钥对的私钥用于对密文形式的医疗数据进行解密。
在一些实施例中,用户的每个医疗数据可以分别具有对应的目标密钥对,不同医疗数据的目标密钥对可以不同或相同。可选地,终端可以维护医疗数据与目标密钥对之间的对应关系,作为一种可能的实现,终端可以生成密钥管理信息,该密钥管理信息用于记录该用户的每个医疗数据对应的目标密钥对。终端可以存储密钥管理信息,终端获取目标密钥对后,可以向密钥管理信息写入该医疗数据的标识与该目标密钥对之间的对应关系。
在另一些实施例中,用户的每个医疗数据可以共用同一目标密钥对,则同一用户的不同医疗数据的目标密钥对可以均相同。可选地,终端第一次将用户的医疗数据存储至目标区块链***的过程中,可以对获取到的目标密钥对进行存储,后续将用户的其他医疗数据存储至目标区块链***的过程中,终端可以读取已存储的目标密钥对。
步骤二、终端可以根据该目标密钥对的公钥,生成该第一授权信息,该第一授权信息包括该目标密钥对的公钥。具体地,终端可以对第一存储指令携带的内容以及目标密钥对的公钥进行封装,得到第一授权信息。
803、终端使用用户在目标区块链***的私钥,对第一授权信息进行签名,得到第一签名。
第一签名为第一授权信息的数字签名,第一签名用于验证第一授权信息的真实性以及完整性。终端可以计算第一授权信息的哈希值,使用用户在目标区块链***的私钥,对第一授权信息的哈希值进行加密,得到密文形式的第一授权信息的哈希值,该密文形式的第一授权信息的哈希值即为第一签名。
804、终端根据第一授权信息以及第一签名,向医疗机构服务器发送第一存储请求。
第一存储请求用于请求将用户的医疗数据存储至目标区块链***,第一存储请求可以包括第一授权信息以及第一签名。终端可以对第一授权信息以及第一签名进行封装,得到第一存储请求。
805、医疗机构服务器从终端接收第一存储请求,使用该用户在该目标区块链***的公钥,对该第一存储请求中的第一签名进行验证。
在一些实施例中,第一存储请求的传输流程可以通过扫码的方式实现。具体而言,终端可以根据第一存储请求,生成二维码,该二维码携带第一存储请求。终端可以显示二维码,从而将第一存储请求以二维码的形式展示。医疗机构的工作人员可以通过扫描设备,对二维码进行扫描,扫描设备可以接收二维码,对二维码进行解析,得到第一存储请求,向医疗机构服务器发送第一存储请求,医疗机构服务器可以从扫描设备接收到第一存储请求。当然,通过扫码的方式传输第一存储请求仅是示例,在另一些实施例中,终端可以与医疗机构服务器建立网络连接,可以通过网络连接向医疗机构服务器发送第一存储请求,医疗机构服务器可以通过网络连接接收第一存储请求。
在一些实施例中,对第一签名进行验证的过程可以包括下述步骤一至步骤六:
步骤一、医疗机构服务器可以解析第一存储请求,得到第一存储请求携带的第一授权信息以及第一签名。
步骤二、医疗机构服务器可以使用该用户在该目标区块链***的公钥,对第一签名进行解密,得到哈希值。其中,关于医疗机构服务器获取用户在该目标区块链***的公钥的方式,在一些实施例中,如果第一授权信息包括用户在该目标区块链***的公钥,医疗机构服务器可以解析第一授权信息,得到第一授权信息中的用户在该目标区块链***的公钥。在另一些实施例中,如果第一授权信息包括用户在该目标区块链***的公钥,医疗机构服务器可以解析第一授权信息,得到第一授权信息携带的用户在该医疗机构服务器的身份标识,根据用户在该医疗机构服务器的身份标识,查询用户在该目标区块链***的公钥与该用户在该医疗机构服务器的身份标识之间的绑定关系,得到用户在该医疗机构服务器的身份标识绑定的公钥。
步骤三、医疗机构服务器可以计算第一授权信息的哈希值。
步骤四、医疗机构服务器可以对解密得出的哈希值与计算的哈希值进行对比。
步骤五、如果两个哈希值一致,则第一签名验证通过。
步骤六、如果两个哈希值不一致,则第一签名验证不通过。
806、当第一签名验证通过时,医疗机构服务器根据第一存储请求中的第一授权信息,读取存储的用户的医疗数据。
如果第一签名验证通过,表明第一签名是正确的,一方面,能够证明第一授权信息是由用户本人操作终端签名并发送的,而非其他用户伪造的授权信息,从而验证了用户的身份的真实性,保证将医疗数据存储至目标区块链***的过程是在用户本人的授权下执行的,是出于用户本人的真实意愿,避免将用户不愿意公开的隐私医疗数据误存储至目标区块链***。另一方面,能够证明第一授权信息是完整的,在传输过程中没有被篡改过,也没有发生丢失。在这种情况下,医疗机构服务器会读取用户的医疗数据,以便将读取的医疗数据存储至目标区块链***,而当第一签名验证不通过时,医疗机构服务器会拒绝读取医疗数据,也就不会将医疗数据存储至目标区块链***。
在一些实施例中,读取医疗数据的方式可以而不限于下述方式一至方式二中的任一项:
方式一、医疗机构服务器可以解析第一授权信息,得到第一授权信息携带的医疗数据的标识,以医疗数据的标识为索引,查询信息***,得到医疗数据的标识对应的医疗数据,以便将该医疗数据的标识对应的医疗数据发送至目标区块链***的节点设备。例如,如果第一授权信息携带的医疗数据的标识为就诊ID:0511011、就诊时间8019年9月10日09:30,则医疗机构服务器以就诊ID:0511011、就诊时间8019年9月10日09:30为索引,可以得到就诊ID为0511011且就诊时间8019年9月10日09:30的医疗数据。通过这种方式,能够从医疗机构服务器已注册的所有用户的所有医疗数据中,精确地找到某一用户的某一条或多条医疗数据,从而将用户指定要存储的医疗数据存储至目标区块链***。
方式二、医疗机构服务器可以解析第一授权信息,得到第一授权信息携带的用户在该医疗机构服务器的身份标识,以用户在该医疗机构服务器的身份标识为索引,查询信息***,得到用户的每个医疗数据,以便将用户的每个医疗数据发送至目标区块链***的节点设备。例如,如果第一授权信息携带的身份标识为病人编号1908299339,则医疗机构服务器以病人编号1908299339为索引,可以得到病人编号为1908299339的所有医疗数据。通过这种方式,能够从医疗机构服务器已注册的所有用户的医疗数据中,精确地找到某一用户的所有医疗数据,从而将用户的所有医疗数据批量化地存储至目标区块链***,节省存储用户的所有医疗数据的总时间。
在一些实施例中,医疗机构服务器可以在对第一签名进行验证的基础上,还根据用户在医疗机构服务器的身份标识,对该用户的身份进行验证。具体可以包括下述步骤一至步骤五:
步骤一、医疗机构服务器可以解析该第一授权信息,得到该用户在该目标区块链***的公钥以及该用户在该医疗机构服务器的身份标识。
步骤二、医疗机构服务器可以根据该用户在该目标区块链***的公钥以及该用户在该医疗机构服务器的身份标识,查询绑定记录。
步骤三、医疗机构服务器判断绑定记录是否包括该用户在该目标区块链***的公钥以及该用户在该医疗机构服务器的身份标识之间的绑定关系。
步骤四、如果该绑定记录包括该用户在该目标区块链***的公钥以及该用户在该医疗机构服务器的身份标识之间的绑定关系,且该第一签名验证通过时,医疗机构服务器读取存储的该用户的医疗数据。
如果该绑定记录包括该用户在该目标区块链***的公钥以及该用户在该医疗机构服务器的身份标识之间的绑定关系,表明用户的身份信息已经在医院注册,且用户的绑定关系已经成功存储至目标区块链***,从而进一步保证了请求存储医疗数据的用户的身份的合法性。
步骤五、如果绑定记录不包括该用户在该目标区块链***的公钥以及该用户在该医疗机构服务器的身份标识之间的绑定关系,或者该第一签名验证不通过时,医疗机构服务器拒绝读取存储的该用户的医疗数据。
807、医疗机构服务器向目标区块链***中的第三节点设备发送医疗数据。
第三节点设备为目标区块链***中的任一节点设备,第三节点设备与图5实施例中的第一节点设备以及第二节点设备可以为不同或相同的节点设备。
如果第一授权信息包括目标区块链***的标识,医疗机构服务器可以根据第一授权信息中的目标区块链***的标识,向目标区块链***的标识对应的目标区块链***中的第三节点设备发送医疗数据。如果第一授权信息包括区块链类型,医疗机构服务器可以向目标区块链***中的第三节点设备发送医疗数据以及区块链类型,以指明要在符合该区块链类型的区块链中存储医疗数据。如果第一授权信息包括区块链的标识,医疗机构服务器可以向目标区块链***中的第三节点设备发送区块链的标识,以指明要在区块链的标识对应的区块链中存储医疗数据。如果第一授权信息包括写入接口的标识,医疗机构服务器可以调用该写入接口的标识对应的写入接口,向该写入接口传入医疗数据,从而以调用接口的方式,将医疗数据发往提供该写入接口的目标区块链***。
在一些实施例中,医疗机构服务器可以解析该第一存储请求,得到目标密钥对的公钥;医疗机构服务器可以使用该目标密钥对的公钥,对该医疗数据进行加密,得到密文形式的医疗数据;医疗机构服务器可以向该目标区块链***中的第三节点设备发送该密文形式的医疗数据。通过这种方式,可以将医疗数据加密存储至目标区块链***中,那么由于目标区块链***上存储的是医疗数据的密文,未授权的设备即使从目标区块链***上获取到医疗数据的密文,由于未持有目标密钥对的私钥,无法对医疗数据的密文进行解密,也就无法得到医疗数据的明文,从而避免用户的医疗数据泄露,极大地提高了存储医疗数据的安全性。
对医疗数据加密所采用的加密算法可以由终端指定,也可以预先配置。具体而言,在一些实施例中,医疗机构服务器可以解析第一存储请求,得到目标加密算法的标识;医疗机构服务器可以基于该目标加密算法的标识对应的目标加密算法,对该医疗数据进行加密,得到密文形式的医疗数据。在另一些实施例中,医疗机构服务器可以预先配置目标加密算法;医疗机构服务器可以基于预先配置的目标加密算法,对该医疗数据进行加密,得到密文形式的医疗数据。
需要说明的一点是,对医疗数据进行加密仅是可选方式,医疗机构服务器也可以向该目标区块链***中的节点设备发送该明文形式的医疗数据,本实施例对是否对医疗数据进行加密不做限定。
在一些实施例中,医疗机构服务器可以将医疗数据打包为一笔交易,从而将医疗数据以交易的形式发送至目标区块链***中的节点设备,具体可以参见以下步骤一至步骤三:
步骤一、医疗机构服务器可以使用该医疗机构服务器在该目标区块链***的私钥,对该医疗数据进行签名,得到第三签名。
第三签名为医疗数据的签名。第三签名用于验证医疗机构服务器身份的真实性,还用于验证医疗数据的完整性,即医疗数据在传输过程中没有被篡改,也没有发生丢失。第三签名的生成过程可以包括:医疗机构服务器可以计算医疗数据的哈希值,使用医疗机构服务器在该目标区块链***的私钥,对医疗数据的哈希值进行加密,得到密文形式的医疗数据的哈希值,该密文形式的医疗数据的哈希值即为第三签名。
步骤二、医疗机构服务器可以根据该医疗数据、该第三签名以及该医疗机构服务器在该目标区块链***的公钥,生成第一交易。
具体地,医疗机构服务器可以对医疗数据、该第三签名以及该医疗机构服务器在该目标区块链***的公钥进行封装,得到第一交易。其中,第一交易也可以称为就诊交易,第一交易包括医疗数据、第三签名以及医疗机构服务器在该目标区块链***的公钥,另外,第一交易还可以包括第一交易的交易ID,该交易ID用于标识第一交易。
步骤三、医疗机构服务器向第三节点设备发送该第一交易。
在一些实施例中,医疗机构服务器可以调用目标区块链***提供的写入接口,向写入接口传入第一交易,从而以调用接口的方式将第一交易发往目标区块链***。可选地,医疗机构服务器还可以向写入接口传入生成第三签名所采用的加密算法的标识,以便第三节点设备确定医疗机构服务器采用哪一种加密算法生成了第三签名,从而采用该加密算法对第三签名进行验证。
808、目标区块链***中的第三节点设备从医疗机构服务器接收医疗数据,将医疗数据存储至目标区块链***。
医疗数据的存储过程可以包括:第三节点设备可以根据医疗数据,生成第三区块,第三节点设备可以基于目标区块链***内的共识机制,将第三区块添加至区块链,从而将医疗数据存储在区块链中。其中,第三区块包括该医疗数据,第三区块还可以包括第三签名,以便病人或其他机构后续访问第三区块中的医疗数据时,能够得到第三签名,从而通过第三签名来验证医疗数据的真实性,即,医疗数据确实是由医疗机构服务器发送的,而非用户或其他第三方伪造的。生成第三区块以及添加至区块链的具体流程可以参见图1至图3的介绍,在此不做赘述。另外,如果医疗机构服务器以交易的形式发送了医疗数据,则第三节点设备可以接收到携带了医疗数据的第一交易,将第一交易通过上述方式存储在目标区块链***中,则目标区块链***的区块链会存储第一交易。
在一些实施例中,第三节点设备可以使用该医疗机构服务器在该目标区块链***的公钥,对该第三签名进行验证,从而保证医疗数据的合法性和完整性。具体而言,验证第三签名的过程可以包括下述步骤一至步骤五。
步骤一、目标区块链***中的节点设备可以使用该医疗机构服务器在该目标区块链***的公钥,对第三签名进行解密,得到哈希值。
在一些实施例中,第三节点设备可以接收第一交易,解析第一交易,得到第一交易中的医疗数据、医疗机构服务器在该目标区块链***的公钥以及第三签名。其中,如果目标区块链***与医疗机构服务器通过调用接口的方式进行交互,第三节点设备可以从写入接口,接收传入的第一交易。
可选地,如果生成第三签名的加密算法由医疗机构服务器指定,则医疗机构服务器还会向写入接口传入加密算法的标识,第三节点设备可以从写入接口接收加密算法的标识,基于该加密算法的标识对应的加密算法,对第三签名进行解密。
步骤二、目标区块链***中的节点设备可以计算医疗数据的哈希值。
步骤三、目标区块链***中的节点设备可以对解密得出的哈希值与计算的哈希值进行对比。
步骤四、如果两个哈希值一致,则第三签名验证通过。
如果两个哈希值一致,表明第三签名是正确的,那么一方面,能够证明医疗数据是由医疗机构服务器签名并发送的,而非第三方伪造的数据,从而验证了医疗数据的真实性以及可信性。另一方面,能够证明医疗数据是完整的,在传输过程中没有丢失,也没有被篡改过。
步骤五、如果两个哈希值不一致,则第三签名验证不通过。
在一些实施例中,第三节点设备可以使用该医疗机构服务器在该目标区块链***的公钥,对该医疗机构服务器在目标区块链***的身份进行验证,从而保证医疗机构服务器的身份的合法性。具体而言,第三节点设备可以查询该目标区块链***存储的每个医疗机构的公钥,得到公钥集合。第三节点设备可以判断医疗机构服务器的公钥是否属于该公钥集合,当医疗机构服务器的公钥属于该公钥集合,则医疗机构服务器在目标区块链***的身份验证通过,当医疗机构服务器的公钥不属于该公钥集合,则医疗机构服务器在目标区块链***的身份验证不通过。其中,目标区块链***可以预先将合法的一个或多个医疗机构的公钥存储至区块链中,公钥集合可以包括该合法的一个或多个医疗机构中每个医疗机构的公钥。
需要说明的一点是,对该医疗机构服务器在目标区块链***的身份进行验证的过程与对第三签名进行验证的过程可以均执行,当两种验证过程均通过,即当医疗机构服务器的公钥属于该公钥集合且第三签名验证通过时,第三节点设备将医疗数据存储至目标区块链***。当两种验证过程存在一种验证过程不通过,或者两种验证过程均不通过,即当该公钥不属于该公钥集合或者该第三签名验证不通过时,第三节点设备拒绝将该医疗数据写入该区块链。其中,本实施例对验证医疗机构服务器在目标区块链***的身份与验证第三签名的先后顺序不做限定。在一些实施例中,验证医疗机构服务器在目标区块链***的身份与验证第三签名可以顺序执行。例如,可以先验证医疗机构服务器在目标区块链***的身份,再验证第三签名;也可以先验证第三签名,再验证医疗机构服务器在目标区块链***的身份。在另一些实施例中,验证医疗机构服务器在目标区块链***的身份与验证第三签名也可以并行执行,即,可以同时验证医疗机构服务器在目标区块链***的身份以及第三签名。
示意性地,参见图9,本申请实施例中医疗数据、医疗机构的公钥以及绑定关系均可以采用交易的形式在区块链中存储,图9示出了本实施例涉及的几类交易的示意图,第一交易内至少封装了医疗数据,区块链中通过存储第一交易,即存储了医疗数据;第二交易内至少封装了用户在医疗机构服务器的身份标识与在目标区块链***的公钥之间的绑定关系,区块链中通过存储第二交易,即存储了绑定关系;第三交易内至少封装了医疗机构服务器的公钥,区块链中通过存储第三交易,即存储了医疗机构服务器的公钥。
示意性地,参见图10,图10是本申请实施例提供的一种基于区块链的医疗数据存储***的架构图,该医疗数据存储***包括终端、医疗机构服务器以及目标区块链***,该终端上运行了区块链客户端。区块链客户端、医疗机构服务器以及目标区块链***可以包括多个软件模块,通过运行各个软件模块来分别执行对应的步骤。具体地,区块链客户端可以包括密钥管理模块、二维码管理模块、签名与验证模块、交易封装模块以及区块链通信模块,目标区块链***中的节点设备可以包括区块链网络以及第一写入接口模块,该区块链网络包括交易执行模块、智能合约执行模块、区块打包模块、共识及提交模块、P2P通信模块。该第一写入接口模块用于在医疗机构服务器调用写入接口时提供对应的服务。医疗机构服务器可以包括第二写入接口模块以及医疗数据封装模块,该第二写入接口模块用于调用写入接口,来与第一写入接口模块进行交互。
本实施例提供了一种基于用户的授权和签名,将用户的医疗数据存储到区块链的方法,通过将医疗数据存储至目标区块链***中,各个机构和用户可以通过请求目标区块链***来查询到医疗数据,从而保证医疗数据能够高效流通,并且,由于医疗机构服务器要在终端发送了第一授权信息的条件下,根据第一授权信息来请求目标区块链***存储医疗数据,从而保证将医疗数据存储至区块链的过程是在用户的授权下执行的,避免医疗数据随意入链而造成用户隐私泄露的情况,提高医疗数据的安全性和隐私性。
并且,终端通过使用用户在目标区块链***的私钥,对第一授权信息进行签名,由医疗机构服务器使用用户在目标区块链***的公钥,对签名进行验证,能够保证第一授权信息是用户本人操作终端签名并发送的,保证医疗数据的入链过程是出于用户的真实意愿,避免将用户不愿意泄露的隐私数据误存储至区块链,从而提高医疗数据的安全性和隐私性。
并且,相对于通过中心化的第三方***存储医疗数据的方案来说,由于目标区块链***具有去中心化的特点,可以规避中心化节点故障而导致医疗数据泄露的风险,极大地提高存储医疗数据的安全性。
并且,由于区块链中存储的数据不可篡改,使得医疗数据存储至目标区块链***后,能够避免医疗数据在存储过程中被篡改,从而保证医疗数据的真实可靠性。
并且,相对于由终端主动地请求区块链***存储医疗数据的方案来说,通过由医疗数据服务器查询存储的用户的医疗数据,请求区块链***存储查询到的医疗数据,从而保证区块链上存储的医疗数据确实是医疗机构提供的,而非用户或第三方伪造的,实现区块链上存储真实可信的医疗数据。
图8实施例介绍了基于区块链的医疗数据存储方法,在图7实施例的基础上,本申请实施例还提供了一种基于区块链的医疗数据查询方法,可选地,该方法可以在图8实施例之后执行,参见图11,该实施例以交互主体包括终端、保险机构服务器以及目标区块链***中的任一节点设备为例进行说明,参见图11,该方法包括:
1101、保险机构服务器向目标区块链***的第四节点设备发送查询请求。
查询请求用于查询目标区块链***上存储的用户的医疗数据,查询请求可以包括医疗数据的标识。在一个示例性场景中,当用户要求保险公司报销某个医疗数据关联的医药费时,可以在终端上输入该医疗数据的标识,终端可以接收输入的医疗数据的标识,将该医疗数据的标识发送至保险机构服务器,从而触发保险机构服务器生成查询请求。
1102、第四节点设备接收查询请求,根据查询请求,从目标区块链***获取医疗数据。
第四节点设备为目标区块链***中的任一节点设备,第四节点设备与上述实施例中的第一节点设备、第二节点设备或第三节点设备可以为不同的节点设备,也可以为相同的节点设备。第四节点设备可以解析查询请求,得到查询请求携带的医疗数据的标识,根据医疗数据的标识,从存储的区块链的第三区块中,得到医疗数据。
1103、第四节点设备向保险机构服务器发送医疗数据。
1104、保险机构服务器从第四节点设备接收医疗数据。
另外,如果图8实施例中,医疗数据与医疗机构服务器的第三签名打包为一笔交易存储,则第四节点设备不仅可以从第三区块中得到医疗数据,还可以从第三区块,得到第三签名,向保险机构服务器发送第三签名,则保险机构服务器可以接收第三签名,使用医疗机构服务器在该目标区块链***的公钥,对该第三签名进行验证,当验证通过时,证明医疗数据是由医疗机构服务器签名并发送的,从而保证得到可信的医疗数据。另外,如果图8实施例中,医疗数据与医疗机构服务器在目标区块链***的公钥打包为一笔交易存储,则第四节点设备不仅可以从第三区块中得到医疗数据,还可以从第三区块,得到医疗机构服务器在目标区块链***的公钥,向保险机构服务器发送医疗机构服务器在目标区块链***的公钥,则保险机构服务器可以接收医疗机构服务器在目标区块链***的公钥,根据医疗机构服务器在目标区块链***的公钥,确定医疗机构服务器的身份,从而得知医疗数据是由哪家医疗机构提供的。
可选地,如果医疗机构服务器对医疗数据进行了加密,使得医疗数据以密文的形式在目标区块链***上存储,保险机构服务器接收到的医疗数据可以为密文形式的医疗数据,在这种情况下,图11实施例还可以包括下述步骤1105至步骤1109。
1105、保险机构服务器向终端发送授权请求。
授权请求用于请求该用户授权对该医疗数据进行解密,授权请求包括医疗数据的标识,还可以包括用户在该目标区块链***的公钥。
1106、终端接收授权请求,显示授权提示界面。
终端可以生成授权提示界面,在屏幕中显示该授权提示界面,该授权提示界面用于提示该用户授权保险机构对该医疗数据进行解密或者拒绝该保险机构对该医疗数据进行解密,授权提示界面可以包括保险机构服务器对应的保险机构的标识。示例性地,授权提示界面可以包括授权控件以及拒绝控件。当用户同意授权保险机构服务器对该医疗数据进行解密时,可以对授权控件进行操作,该授权控件用于触发授权指令,该授权指令表示该用户授权保险机构服务器对该医疗数据进行解密。当用户不同意授权保险机构服务器对该医疗数据进行解密时,可以对拒绝控件进行操作,拒绝控件用于触发拒绝指令,拒绝指令表示该用户拒绝保险机构服务器对该医疗数据进行解密。
可选地,终端与保险机构服务器之间可以通过目标区块链***来转发授权请求。具体而言,保险机构服务器可以向目标区块链***中的第三节点设备发送授权请求,目标区块链***中的第三节点设备可以接收授权请求,将授权请求存储至目标区块链***。终端可以监听目标区块链***存储的用户关联的请求,得到该授权请求。通过这种方式,能够在将保险机构服务器的授权请求传输至终端的基础上,通过将授权请求存储至目标区块链***,由目标区块链***自动地记录保险机构服务器将请求终端授权解密的事件。
1107、终端接收授权指令。
1108、终端将该目标密钥对的私钥发送至保险机构服务器。
在一些实施例中,如果用户的每个医疗数据分别具有对应的目标密钥对,终端可以解析授权请求,得到医疗数据的标识;终端可以根据医疗数据的标识,查询密钥管理信息,得到医疗数据的标识对应的目标密钥对的私钥。终端可以将医疗数据的标识对应的目标密钥对的私钥发送至保险机构服务器,则保险机构服务器根据该目标密钥对的私钥,可以对医疗数据的标识对应的医疗数据行解密,而对医疗数据的标识对应的医疗数据之外的其他医疗数据无法解密。
1109、保险机构服务器接收目标密钥对的私钥,使用该目标密钥对的私钥,对密文形式的医疗数据进行解密,得到医疗数据。
需要说明的一点是,步骤1105至步骤1109为可选步骤,而非必选步骤,如果医疗数据以明文的形式在目标区块链***上存储,则可以不执行步骤1105至步骤1109。
1110、保险机构服务器根据医疗数据,处理保险业务。
示例性地,保险机构服务器可以预先配置智能合约,可以基于智能合约,对医疗数据进行分析,从而进行核保和理赔。
需要说明的一点是,本实施例仅是以保险机构服务器查询医疗数据为例进行说明,在一些实施例中,用户的医疗数据能够通过目标区块链***进行共享,保险机构之外的其他第三方或者用户本人可以采用同理的方式,通过向区块链***的节点设备发送查询请求,来得到用户的医疗数据,从而打破了医疗机构仅对内部***息的限制,避免由于医疗机构与第三方之间的数据隔离而造成难以得到医疗数据的情况,便于第三方查询医疗数据。
并且,相对于每个医疗机构服务器分别构建各自的信息***的方式来说,可以避免由于不同医疗机构服务器的信息***的接口标准不同,要分别为每个医疗机构服务器配置对应的查询流程,而造成配置复杂、接入困难的情况,能够通过目标区块链***,实现医疗数据存储的标准化,基于同一种查询方法,即可从目标区块链***中,查询到各个医疗机构服务器存储的医疗数据,从而简化了查询流程。
此外,相对于流通纸质医疗数据的方式来说,由于纸质医疗数据容易伪造,难以验证纸质医疗数据的真实性,造成可验真性差,并且由于纸质医疗数据容易损坏,造成纸质医疗数据的可传递性差,难以二次使用。而基于本申请实施例提供的方法,由于医疗数据可以和医疗机构服务器的签名打包存储,通过验证医疗机构服务器的签名,能够保证医疗数据的真实性,从而提高医疗数据的可验真性。并且,医疗数据以电子数据的形式在区块链上存储,不仅不会在传输过程中损坏,而且能够避免被篡改,第三方通过接入目标区块链***,即可查询医疗数据,从而实现医疗数据的高效流通。
图12是本申请实施例提供的一种基于区块链的医疗数据存储装置的结构示意图。参见图12,该装置应用于终端,包括:接收模块1201、生成模块1202、签名模块1203、发送模块1204。
接收模块1201,用于接收第一存储指令,该第一存储指令用于指示将用户在医疗机构服务器中存储的医疗数据存储至目标区块链***;
生成模块1202,用于根据该第一存储指令,生成第一授权信息,该第一授权信息表示该用户授权将该医疗数据存储至该目标区块链***;
签名模块1203,用于使用该用户在该目标区块链***的私钥,对该第一授权信息进行签名,得到第一签名;
发送模块1204,用于根据该第一授权信息以及该第一签名,向该医疗机构服务器发送第一存储请求,该第一存储请求用于请求将该医疗数据存储至该目标区块链***。
可选地,该生成模块1202,包括:
获取子模块,用于获取目标密钥对,该目标密钥对的公钥用于供该医疗机构服务器对该医疗数据进行加密;
生成子模块,用于根据该目标密钥对的公钥,生成该第一授权信息,该第一授权信息包括该目标密钥对的公钥。
可选地,该接收模块1201,还用于接收授权指令,该授权指令表示该用户授权对该医疗数据进行解密;
该发送模块1204,还用于将该目标密钥对的私钥发送至保险机构服务器。
可选地,该接收模块1201,还用于接收第二存储指令,该第二存储指令用于指示将该用户在该目标区块链***的公钥与该用户在该医疗机构服务器的身份标识之间的绑定关系存储至该目标区块链***;
该生成模块1202,还用于根据该第二存储指令,生成第二授权信息,该第二授权信息表示该用户授权将该绑定关系存储至该目标区块链***;
该签名模块1203,还用于使用该用户在该目标区块链***的私钥,对该第二授权信息进行签名,得到第二签名;
该发送模块1204,还用于根据该第二授权信息以及该第二签名,向该医疗机构服务器发送第二存储请求,该第二存储请求用于请求将该绑定关系存储至该目标区块链***。
可选地,该第一存储指令包括该医疗数据的标识、该用户在该医疗机构服务器的身份标识、该目标区块链***的标识、区块链类型、区块链的标识、该目标加密算法的标识中的至少一项。
可选地,该第一授权信息包括该医疗数据的标识、该用户在该目标区块链***的公钥、该用户在该医疗机构服务器的身份标识、该目标区块链***的标识、区块链类型、区块链的标识、该目标加密算法的标识中的至少一项。
可选地,该接收模块1201,还用于从该保险机构的服务器接收授权请求,该授权请求用于请求该用户授权对该医疗数据进行解密;
该装置还包括:显示模块,用于显示授权提示界面,该授权提示界面用于提示该用户授权该保险机构服务器对该医疗数据进行解密或者拒绝该保险机构服务器对该医疗数据进行解密。
可选地,该装置还包括:
写入模块,用于向密钥管理信息写入该医疗数据的标识与该目标密钥对之间的对应关系,该密钥管理信息用于记录该用户的每个医疗数据对应的目标密钥对;
解析模块,用于解析该授权请求,得到该医疗数据的标识;
查询模块,用于根据该医疗数据的标识,查询该密钥管理信息,得到该医疗数据的标识对应的该目标密钥对的私钥。
可选地,该第二存储指令包括该用户在该医疗机构服务器的身份标识、该目标区块链***的标识、区块链类型、区块链的标识、该目标加密算法的标识中的至少一项。
可选地,该第二授权信息包括该用户在该目标区块链***的公钥、该用户在该医疗机构服务器的身份标识、该医疗机构服务器在该目标区块链***的公钥、该目标区块链***的写入接口的标识、该目标区块链***的标识、区块链类型、区块链的标识中的至少一项。
图13是本申请实施例提供的一种基于区块链的医疗数据存储装置的结构示意图。参见图13,该装置应用于医疗机构服务器,包括:接收模块1301、验证模块1302、读取模块1303、发送模块1304。
接收模块1301,用于从终端接收第一存储请求,该第一存储请求用于请求将用户在医疗机构服务器中存储的医疗数据存储至目标区块链***;
验证模块1302,用于使用该用户在该目标区块链***的公钥,对该第一存储请求中的第一签名进行验证;
读取模块1303,用于当该第一签名验证通过时,根据该第一存储请求中的第一授权信息,读取存储的该用户的医疗数据,该第一授权信息表示该用户授权将该医疗数据存储至该目标区块链***;
发送模块1304,用于向该目标区块链***中的节点设备发送该医疗数据。
可选地,该发送模块1304,包括:
解析子模块,用于解析该第一存储请求,得到目标密钥对的公钥;
加密子模块,用于使用该目标密钥对的公钥,对该医疗数据进行加密,得到密文形式的医疗数据;
发送子模块,用于向该目标区块链***中的节点设备发送该密文形式的医疗数据。
可选地,该发送模块1304,包括:
签名子模块,用于使用该医疗机构服务器在该目标区块链***的私钥,对该医疗数据进行签名,得到第三签名;
生成子模块,用于根据该医疗数据、该第三签名以及该医疗机构服务器在该目标区块链***的公钥,生成第一交易;
发送子模块,用于向该目标区块链***中的节点设备发送该第一交易。
可选地,该读取模块1303,包括:
解析子模块,用于解析该第一授权信息,得到该用户在该目标区块链***的公钥以及该用户在该医疗机构服务器的身份标识;
查询子模块,用于根据该用户在该目标区块链***的公钥以及该用户在该医疗机构服务器的身份标识,查询绑定记录,该绑定记录用于记录该医疗机构服务器的每个用户的身份标识绑定的在该目标区块链***的公钥;
读取子模块,用于如果该绑定记录包括该用户在该目标区块链***的公钥以及该用户在该医疗机构服务器的身份标识之间的绑定关系,且该第一签名验证通过时,读取存储的该用户的医疗数据。
可选地,该接收模块1301,还用于从终端接收第二存储请求,该第二存储请求用于请求将该用户在该目标区块链***的公钥与该用户在该医疗机构服务器的身份标识之间的绑定关系存储至该目标区块链***;
该验证模块1302,还用于使用该用户在该目标区块链***的公钥,对该第二存储请求中的第二签名进行验证;
该发送模块1304,还用于当该第二签名验证通过时,根据该第二存储请求中的第二授权信息,向该目标区块链***中的节点设备发送该该绑定关系,该第二授权信息表示该用户授权将该绑定关系存储至该目标区块链***。
可选地,该读取模块1303,包括:
解析子模块,用于解析该第一授权信息,得到该用户在该目标区块链***的公钥以及该用户在该医疗机构服务器的身份标识;
查询子模块,用于根据该用户在该目标区块链***的公钥以及该用户在该医疗机构服务器的身份标识,查询绑定记录,该绑定记录用于记录该医疗机构服务器的每个用户的身份标识绑定的在该目标区块链***的公钥;
读取子模块,用于如果该绑定记录包括该用户在该目标区块链***的公钥以及该用户在该医疗机构服务器的身份标识之间的绑定关系,且该第一签名验证通过时,读取存储的该用户的医疗数据。
可选地,该接收模块1301,还用于从终端接收第二存储请求,该第二存储请求用于请求将该用户在该目标区块链***的公钥与该用户在该医疗机构服务器的身份标识之间的绑定关系存储至该目标区块链***;
该验证模块1302,还用于使用该用户在该目标区块链***的公钥,对该第二存储请求中的第二签名进行验证;
该发送模块1304,还用于当该第二签名验证通过时,根据该第二存储请求中的第二授权信息,向该目标区块链***中的节点设备发送该绑定关系,该第二授权信息表示该用户授权将该绑定关系存储至该目标区块链***。
可选地,该读取模块1303,包括:
解析子模块,用于解析该第一授权信息,得到该第一授权信息携带的该医疗数据的标识;
查询子模块,用于以该医疗数据的标识为索引,查询信息***,得到该医疗数据的标识对应的医疗数据。
可选地,该读取模块1303,包括:
解析子模块,用于解析该第一授权信息,得到该第一授权信息携带的该用户在该医疗机构服务器的身份标识;
查询子模块,用于以该用户在该医疗机构服务器的身份标识为索引,查询信息***,得到该用户的每个医疗数据。
可选地,该发送模块1304,包括:
签名子模块,用于使用该医疗机构服务器在该目标区块链***的私钥,对该绑定关系进行签名,得到第四签名;
生成子模块,用于根据该医疗数据、该第四签名以及该医疗机构服务器在该目标区块链***的公钥,生成第二交易;
发送子模块,用于向该目标区块链***中的节点设备发送该第二交易。
可选地,该装置还包括:生成模块,用于根据该医疗机构服务器在该目标区块链***的公钥,生成第三交易;
该发送模块1304,还用于向该目标区块链***中的节点设备发送该第三交易。
图14是本申请实施例提供的一种基于区块链的医疗数据存储装置的结构示意图。参见图14,该装置应用于目标区块链***的任一节点设备,包括:接收模块1401、验证模块1402、查询模块1403以及存储模块1404。
接收模块1401,用于从医疗机构服务器接收医疗数据、该医疗机构服务器在该目标区块链***的公钥以及第三签名;
验证模块1402,用于使用该医疗机构服务器在该目标区块链***的公钥,对该第三签名进行验证;
查询模块1403,用于查询该目标区块链***存储的每个医疗机构的公钥,得到公钥集合;
存储模块1404,用于当该公钥属于该公钥集合且该第三签名验证通过时,将该医疗数据存储至该目标区块链***。
可选地,该接收模块1401,还用于从该医疗机构服务器接收绑定关系以及第四签名,该绑定关系包括该用户在该目标区块链***的公钥与该用户在该医疗机构服务器的身份标识;
该验证模块1402,还用于使用该医疗机构服务器在该目标区块链***的公钥,对该第四签名进行验证;
该存储模块1404,还用于当该第四签名验证通过时,将该绑定关系存储至该目标区块链***。
本申请实施例提供的各个装置,通过将医疗数据存储至目标区块链***中,各个机构和用户可以通过请求目标区块链***来查询到医疗数据,从而保证医疗数据能够高效流通,并且,由于医疗机构服务器要在终端发送了第一授权信息的条件下,根据第一授权信息来请求目标区块链***存储医疗数据,从而保证将医疗数据存储至区块链的过程是在用户的授权下执行的,避免医疗数据随意入链而造成用户隐私泄露的情况,提高医疗数据的安全性和隐私性。并且,终端通过使用用户在目标区块链***的私钥,对第一授权信息进行签名,由医疗机构服务器使用用户在目标区块链***的公钥,对签名进行验证,能够保证第一授权信息是用户本人操作终端签名并发送的,保证医疗数据的入链过程是出于用户的真实意愿,避免将用户不愿意泄露的隐私数据误存储至区块链,从而提高医疗数据的安全性和隐私性。
上述所有可选技术方案,可以采用任意结合形成本公开的可选实施例,在此不再一一赘述。
需要说明的是:图12实施例、图13实施例以及图14实施例提供的基于区块链的医疗数据存储装置在基于区块链存储医疗数据时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将基于区块链的医疗数据存储装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的基于区块链的医疗数据存储装置与基于区块链的医疗数据存储方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
本申请实施例提供了一种电子设备,该电子设备可以是上述各个方法实施例中的终端,也可以是上述各个方法实施例中的医疗机构服务器,也可以是上述各个方法实施例中的目标区块链***中的节点设备。该电子设备包括一个或多个处理器和一个或多个存储器,该一个或多个存储器中存储有至少一条程序代码,该至少一条程序代码由该一个或多个处理器加载并执行以实现上述基于区块链的医疗数据存储方法所执行的操作。
以电子设备为终端为例,图15是本申请实施例提供的一种终端的结构示意图。该终端1500可以是:智能手机、平板电脑、MP3(Moving Picture Experts Group Audio LayerIII,动态影像专家压缩标准音频层面3)播放器、MP4(Moving Picture Experts GroupAudio Layer IV,动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。终端1500还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。
通常,终端1500包括有:处理器1501和存储器1502。
处理器1501可以包括一个或多个处理核心,比如4核心处理器、8核心处理器等。处理器1501可以采用DSP(Digital Signal Processing,数字信号处理)、FPGA(Field-Programmable Gate Array,现场可编程门阵列)、PLA(Programmable Logic Array,可编程逻辑阵列)中的至少一种硬件形式来实现。处理器1501也可以包括主处理器和协处理器,主处理器是用于对在唤醒状态下的数据进行处理的处理器,也称CPU(Central ProcessingUnit,中央处理器);协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中,处理器1501可以在集成有GPU(Graphics Processing Unit,图像处理器),GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中,处理器1501还可以包括AI(Artificial Intelligence,人工智能)处理器,该AI处理器用于处理有关机器学习的计算操作。
存储器1502可以包括一个或多个计算机可读存储介质,该计算机可读存储介质可以是非暂态的。存储器1502还可包括高速随机存取存储器,以及非易失性存储器,比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中,存储器1502中的非暂态的计算机可读存储介质用于存储至少一条程序代码,该至少一条程序代码用于被处理器1501所执行以实现本申请中方法实施例提供的基于区块链的医疗数据存储方法。
在一些实施例中,终端1500还可选包括有:***设备接口1503和至少一个***设备。处理器1501、存储器1502和***设备接口1503之间可以通过总线或信号线相连。各个***设备可以通过总线、信号线或电路板与***设备接口1503相连。具体地,***设备包括:射频电路1504、触摸显示屏1505、摄像头组件1506、音频电路1507、定位组件1508和电源1509中的至少一种。
***设备接口1503可被用于将I/O(Input/Output,输入/输出)相关的至少一个***设备连接到处理器1501和存储器1502。在一些实施例中,处理器1501、存储器1502和***设备接口1503被集成在同一芯片或电路板上;在一些其他实施例中,处理器1501、存储器1502和***设备接口1503中的任意一个或两个可以在单独的芯片或电路板上实现,本实施例对此不加以限定。
射频电路1504用于接收和发射RF(Radio Frequency,射频)信号,也称电磁信号。射频电路1504通过电磁信号与通信网络以及其他通信设备进行通信。射频电路1504将电信号转换为电磁信号进行发送,或者,将接收到的电磁信号转换为电信号。可选地,射频电路1504包括:天线***、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路1504可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于:万维网、城域网、内联网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity,无线保真)网络。在一些实施例中,射频电路1504还可以包括NFC(Near Field Communication,近距离无线通信)有关的电路,本申请对此不加以限定。
显示屏1505用于显示UI(User Interface,用户界面)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏1505是触摸显示屏时,显示屏1505还具有采集在显示屏1505的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器1501进行处理。此时,显示屏1505还可以用于提供虚拟按钮和/或虚拟键盘,也称软按钮和/或软键盘。在一些实施例中,显示屏1505可以为一个,设置终端1500的前面板;在另一些实施例中,显示屏1505可以为至少两个,分别设置在终端1500的不同表面或呈折叠设计;在再一些实施例中,显示屏1505可以是柔性显示屏,设置在终端1500的弯曲表面上或折叠面上。甚至,显示屏1505还可以设置成非矩形的不规则图形,也即异形屏。显示屏1505可以采用LCD(Liquid Crystal Display,液晶显示屏)、OLED(Organic Light-Emitting Diode,有机发光二极管)等材质制备。
摄像头组件1506用于采集图像或视频。可选地,摄像头组件1506包括前置摄像头和后置摄像头。通常,前置摄像头设置在终端的前面板,后置摄像头设置在终端的背面。在一些实施例中,后置摄像头为至少两个,分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种,以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality,虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中,摄像头组件1506还可以包括闪光灯。闪光灯可以是单色温闪光灯,也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合,可以用于不同色温下的光线补偿。
音频电路1507可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波,并将声波转换为电信号输入至处理器1501进行处理,或者输入至射频电路1504以实现语音通信。出于立体声采集或降噪的目的,麦克风可以为多个,分别设置在终端1500的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器1501或射频电路1504的电信号转换为声波。扬声器可以是传统的薄膜扬声器,也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时,不仅可以将电信号转换为人类可听见的声波,也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中,音频电路1507还可以包括耳机插孔。
定位组件1508用于定位终端1500的当前地理位置,以实现导航或LBS(LocationBased Service,基于位置的服务)。定位组件1508可以是基于美国的GPS(GlobalPositioning System,全球定位***)、中国的北斗***或俄罗斯的伽利略***的定位组件。
电源1509用于为终端1500中的各个组件进行供电。电源1509可以是交流电、直流电、一次性电池或可充电电池。当电源1509包括可充电电池时,该可充电电池可以是有线充电电池或无线充电电池。有线充电电池是通过有线线路充电的电池,无线充电电池是通过无线线圈充电的电池。该可充电电池还可以用于支持快充技术。
在一些实施例中,终端1500还包括有一个或多个传感器1510。该一个或多个传感器1510包括但不限于:加速度传感器1511、陀螺仪传感器1512、压力传感器1513、指纹传感器1514、光学传感器1515以及接近传感器1516。
加速度传感器1511可以检测以终端1500建立的坐标系的三个坐标轴上的加速度大小。比如,加速度传感器1511可以用于检测重力加速度在三个坐标轴上的分量。处理器1501可以根据加速度传感器1511采集的重力加速度信号,控制触摸显示屏1505以横向视图或纵向视图进行用户界面的显示。加速度传感器1511还可以用于游戏或者用户的运动数据的采集。
陀螺仪传感器1512可以检测终端1500的机体方向及转动角度,陀螺仪传感器1512可以与加速度传感器1511协同采集用户对终端1500的3D动作。处理器1501根据陀螺仪传感器1512采集的数据,可以实现如下功能:动作感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。
压力传感器1513可以设置在终端1500的侧边框和/或触摸显示屏1505的下层。当压力传感器1513设置在终端1500的侧边框时,可以检测用户对终端1500的握持信号,由处理器1501根据压力传感器1513采集的握持信号进行左右手识别或快捷操作。当压力传感器1513设置在触摸显示屏1505的下层时,由处理器1501根据用户对触摸显示屏1505的压力操作,实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。
指纹传感器1514用于采集用户的指纹,由处理器1501根据指纹传感器1514采集到的指纹识别用户的身份,或者,由指纹传感器1514根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时,由处理器1501授权该用户执行相关的敏感操作,该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。指纹传感器1514可以被设置终端1500的正面、背面或侧面。当终端1500上设置有物理按键或厂商Logo时,指纹传感器1514可以与物理按键或厂商Logo集成在一起。
光学传感器1515用于采集环境光强度。在一个实施例中,处理器1501可以根据光学传感器1515采集的环境光强度,控制触摸显示屏1505的显示亮度。具体地,当环境光强度较高时,调高触摸显示屏1505的显示亮度;当环境光强度较低时,调低触摸显示屏1505的显示亮度。在另一个实施例中,处理器1501还可以根据光学传感器1515采集的环境光强度,动态调整摄像头组件1506的拍摄参数。
接近传感器1516,也称距离传感器,通常设置在终端1500的前面板。接近传感器1516用于采集用户与终端1500的正面之间的距离。在一个实施例中,当接近传感器1516检测到用户与终端1500的正面之间的距离逐渐变小时,由处理器1501控制触摸显示屏1505从亮屏状态切换为息屏状态;当接近传感器1516检测到用户与终端1500的正面之间的距离逐渐变大时,由处理器1501控制触摸显示屏1505从息屏状态切换为亮屏状态。
本领域技术人员可以理解,图15中示出的结构并不构成对终端1500的限定,可以包括比图示更多或更少的组件,或者组合某些组件,或者采用不同的组件布置。
以电子设备为医疗机构服务器为例,参见图16,图16是本申请实施例提供的一种医疗机构服务器的结构示意图,该医疗机构服务器1600可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上处理器(Central Processing Units,CPU)1601和一个或一个以上的存储器1602,其中,该存储器1602中存储有至少一条指令,该至少一条指令由该处理器1601加载并执行以实现上述各个方法实施例提供的的基于区块链的医疗数据存储方法。当然,该医疗机构服务器还可以具有有线或无线网络接口以及输入输出接口等部件,以便进行输入输出,该医疗机构服务器还可以包括其他用于实现设备功能的部件,在此不做赘述。
以电子设备为目标区块链***中的节点设备为例,参见图17,图17是本申请实施例提供的一种目标区块链***中的节点设备的结构示意图,该节点设备1700可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上处理器(central processingunits,CPU)1701和一个或一个以上的存储器1702,其中,该存储器1702中存储有至少一条程序代码,该至少一条程序代码由该处理器1701加载并执行以实现上述各个方法实施例提供的的基于区块链的医疗数据存储方法。当然,该节点设备还可以具有有线或无线网络接口以及输入输出接口等部件,以便进行输入输出,该节点设备还可以包括其他用于实现设备功能的部件,在此不做赘述。
在示例性实施例中,还提供了一种非易失性计算机可读存储介质,例如包括程序代码的存储器,该存储介质中存储有至少一条程序代码,该至少一条程序代码由处理器加载并执行以实现上述基于区块链的医疗数据存储方法方法所执行的操作。例如,计算机可读存储介质可以是只读存储器(Read-Only Memory,简称:ROM)、随机存取存储器(RandomAccess Memory,简称:RAM)、只读光盘(Compact Disc Read-Only Memory,简称:CD-ROM)、磁带、软盘和光数据存储设备等。
应理解,在本申请的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
应理解,根据A确定B并不意味着仅仅根据A确定B,还可以根据A和/或其它信息确定B。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,该程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上所述仅为本申请的较佳实施例,并不用以限制本申请,凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。
Claims (15)
1.一种基于区块链的医疗数据存储方法,其特征在于,应用于终端,所述方法包括:
接收第一存储指令,所述第一存储指令用于指示将用户在医疗机构服务器中存储的医疗数据存储至目标区块链***;
根据所述第一存储指令,生成第一授权信息,所述第一授权信息表示所述用户授权将所述医疗数据存储至所述目标区块链***;
使用所述用户在所述目标区块链***的私钥,对所述第一授权信息进行签名,得到第一签名;
根据所述第一授权信息以及所述第一签名,向所述医疗机构服务器发送第一存储请求,所述第一存储请求用于请求将所述医疗数据存储至所述目标区块链***。
2.根据权利要求1所述的方法,其特征在于,所述根据所述第一存储指令,生成第一授权信息,包括:
获取目标密钥对,所述目标密钥对的公钥用于供所述医疗机构服务器对所述医疗数据进行加密;
根据所述目标密钥对的公钥,生成所述第一授权信息,所述第一授权信息包括所述目标密钥对的公钥。
3.根据权利要求2所述的方法,其特征在于,所述根据所述第一授权信息以及所述第一签名,向所述医疗机构服务器发送第一存储请求之后,所述方法还包括:
接收授权指令,所述授权指令表示所述用户授权对所述医疗数据进行解密;
将所述目标密钥对的私钥发送至保险机构服务器。
4.根据权利要求1所述的方法,其特征在于,所述接收第一存储指令之前,所述方法还包括:
接收第二存储指令,所述第二存储指令用于指示将所述用户在所述目标区块链***的公钥与所述用户在所述医疗机构服务器的身份标识之间的绑定关系存储至所述目标区块链***;
根据所述第二存储指令,生成第二授权信息,所述第二授权信息表示所述用户授权将所述绑定关系存储至所述目标区块链***;
使用所述用户在所述目标区块链***的私钥,对所述第二授权信息进行签名,得到第二签名;
根据所述第二授权信息以及所述第二签名,向所述医疗机构服务器发送第二存储请求,所述第二存储请求用于请求将所述绑定关系存储至所述目标区块链***。
5.一种基于区块链的医疗数据存储方法,其特征在于,应用于医疗机构服务器,所述方法包括:
从终端接收第一存储请求,所述第一存储请求用于请求将用户在医疗机构服务器中存储的医疗数据存储至目标区块链***;
使用所述用户在所述目标区块链***的公钥,对所述第一存储请求中的第一签名进行验证;
当所述第一签名验证通过时,根据所述第一存储请求中的第一授权信息,读取存储的所述用户的医疗数据,所述第一授权信息表示所述用户授权将所述医疗数据存储至所述目标区块链***;
向所述目标区块链***中的节点设备发送所述医疗数据。
6.根据权利要求5所述的方法,其特征在于,所述向所述目标区块链***中的节点设备发送所述医疗数据,包括:
解析所述第一存储请求,得到目标密钥对的公钥;
使用所述目标密钥对的公钥,对所述医疗数据进行加密,得到密文形式的医疗数据;
向所述目标区块链***中的节点设备发送所述密文形式的医疗数据。
7.根据权利要求5所述的方法,其特征在于,所述向所述目标区块链***中的节点设备发送所述医疗数据,包括:
使用所述医疗机构服务器在所述目标区块链***的私钥,对所述医疗数据进行签名,得到第三签名;
根据所述医疗数据、所述第三签名以及所述医疗机构服务器在所述目标区块链***的公钥,生成第一交易;
向所述目标区块链***中的节点设备发送所述第一交易。
8.根据权利要求5所述的方法,其特征在于,所述当所述第一签名验证通过时,根据所述第一存储请求中的第一授权信息,读取存储的所述用户的医疗数据,包括:
解析所述第一授权信息,得到所述用户在所述目标区块链***的公钥以及所述用户在所述医疗机构服务器的身份标识;
根据所述用户在所述目标区块链***的公钥以及所述用户在所述医疗机构服务器的身份标识,查询绑定记录,所述绑定记录用于记录所述医疗机构服务器的每个用户的身份标识绑定的在所述目标区块链***的公钥;
如果所述绑定记录包括所述用户在所述目标区块链***的公钥以及所述用户在所述医疗机构服务器的身份标识之间的绑定关系,且所述第一签名验证通过时,读取存储的所述用户的医疗数据。
9.根据权利要求5所述的方法,其特征在于,所述从终端接收第一存储请求之前,所述方法还包括:
从终端接收第二存储请求,所述第二存储请求用于请求将所述用户在所述目标区块链***的公钥与所述用户在所述医疗机构服务器的身份标识之间的绑定关系存储至所述目标区块链***;
使用所述用户在所述目标区块链***的公钥,对所述第二存储请求中的第二签名进行验证;
当所述第二签名验证通过时,根据所述第二存储请求中的第二授权信息,向所述目标区块链***中的节点设备发送所述绑定关系,所述第二授权信息表示所述用户授权将所述绑定关系存储至所述目标区块链***。
10.一种基于区块链的医疗数据存储方法,其特征在于,应用于目标区块链***的任一节点设备,所述方法包括:
从医疗机构服务器接收医疗数据、所述医疗机构服务器在所述目标区块链***的公钥以及第三签名;
使用所述医疗机构服务器在所述目标区块链***的公钥,对所述第三签名进行验证;
查询所述目标区块链***存储的每个医疗机构的公钥,得到公钥集合;
当所述公钥属于所述公钥集合且所述第三签名验证通过时,将所述医疗数据存储至所述目标区块链***。
11.根据权利要求10所述的方法,其特征在于,所述从医疗机构服务器接收医疗数据、所述医疗机构服务器在所述目标区块链***的公钥以及第三签名之前,所述方法还包括:
从所述医疗机构服务器接收绑定关系以及第四签名,所述绑定关系包括所述用户在所述目标区块链***的公钥与所述用户在所述医疗机构服务器的身份标识;
使用所述医疗机构服务器在所述目标区块链***的公钥,对所述第四签名进行验证;
当所述第四签名验证通过时,将所述绑定关系存储至所述目标区块链***。
12.一种基于区块链的医疗数据存储装置,其特征在于,应用于终端,所述装置包括:
接收模块,用于接收第一存储指令,所述第一存储指令用于指示将用户在医疗机构服务器中存储的医疗数据存储至目标区块链***;
生成模块,用于根据所述第一存储指令,生成第一授权信息,所述第一授权信息表示所述用户授权将所述医疗数据存储至所述目标区块链***;
签名模块,用于使用所述用户在所述目标区块链***的私钥,对所述第一授权信息进行签名,得到第一签名;
发送模块,用于根据所述第一授权信息以及所述第一签名,向所述医疗机构服务器发送第一存储请求,所述第一存储请求用于请求将所述医疗数据存储至所述目标区块链***。
13.一种基于区块链的医疗数据存储装置,其特征在于,应用于医疗机构服务器,所述装置包括:
接收模块,用于从终端接收第一存储请求,所述第一存储请求用于请求将用户在医疗机构服务器中存储的医疗数据存储至目标区块链***;
验证模块,用于使用所述用户在所述目标区块链***的公钥,对所述第一存储请求中的第一签名进行验证;
读取模块,用于当所述第一签名验证通过时,根据所述第一存储请求中的第一授权信息,读取存储的所述用户的医疗数据,所述第一授权信息表示所述用户授权将所述医疗数据存储至所述目标区块链***;
发送模块,用于向所述目标区块链***中的节点设备发送所述医疗数据。
14.一种电子设备,其特征在于,所述电子设备包括一个或多个处理器和一个或多个存储器,所述一个或多个存储器中存储有至少一条程序代码,所述至少一条程序代码由所述一个或多个处理器加载并执行以实现如权利要求1至权利要求11任一项所述的基于区块链的医疗数据存储方法所执行的操作。
15.一种非易失性计算机可读存储介质,其特征在于,所述存储介质中存储有至少一条程序代码,所述至少一条程序代码由处理器加载并执行以实现如权利要求1至权利要求11任一项所述的基于区块链的医疗数据存储方法所执行的操作。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910860312.2A CN110602089B (zh) | 2019-09-11 | 2019-09-11 | 基于区块链的医疗数据存储方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910860312.2A CN110602089B (zh) | 2019-09-11 | 2019-09-11 | 基于区块链的医疗数据存储方法、装置、设备及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110602089A true CN110602089A (zh) | 2019-12-20 |
CN110602089B CN110602089B (zh) | 2021-08-10 |
Family
ID=68858884
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910860312.2A Active CN110602089B (zh) | 2019-09-11 | 2019-09-11 | 基于区块链的医疗数据存储方法、装置、设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110602089B (zh) |
Cited By (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110826026A (zh) * | 2020-01-13 | 2020-02-21 | 江苏万链区块链技术研究院有限公司 | 基于区块链技术的出版物及其关联版权保护的方法和*** |
CN111145850A (zh) * | 2019-12-23 | 2020-05-12 | 支付宝(杭州)信息技术有限公司 | 基于区块链的医疗数据查询方法以及装置 |
CN111180031A (zh) * | 2019-12-31 | 2020-05-19 | 贵州精准健康数据有限公司 | 数据管理***及方法 |
CN111222118A (zh) * | 2020-01-16 | 2020-06-02 | 王江盼 | 基于联盟链的证明信息生成和查询方法 |
CN111291420A (zh) * | 2020-01-21 | 2020-06-16 | 国家市场监督管理总局信息中心 | 一种基于区块链的分布式离链数据存储方法 |
CN111448565A (zh) * | 2020-02-14 | 2020-07-24 | 支付宝(杭州)信息技术有限公司 | 基于去中心化标识的数据授权 |
CN111506901A (zh) * | 2020-04-16 | 2020-08-07 | 腾讯科技(深圳)有限公司 | 基于区块链的数据处理方法、终端及存储介质 |
CN111681723A (zh) * | 2020-04-27 | 2020-09-18 | 山东浪潮通软信息科技有限公司 | 一种基于区块链的健康信息管理方法及设备、介质 |
CN111783070A (zh) * | 2020-06-29 | 2020-10-16 | 平安科技(深圳)有限公司 | 基于区块链的档案信息获取方法、装置、设备及存储介质 |
CN111881481A (zh) * | 2020-08-05 | 2020-11-03 | 杭州翔毅科技有限公司 | 基于区块链的医疗数据处理方法、装置、设备及存储介质 |
CN111899826A (zh) * | 2020-07-27 | 2020-11-06 | 深圳微控科技有限公司 | 健康数据管理方法、装置、计算机设备和存储介质 |
CN111914029A (zh) * | 2020-08-06 | 2020-11-10 | 平安科技(深圳)有限公司 | 基于区块链的医疗数据调用方法、装置、电子设备及介质 |
CN112163171A (zh) * | 2020-09-21 | 2021-01-01 | 中国电子科技网络信息安全有限公司 | 一种基于终端签名的数据记链方法 |
CN112260996A (zh) * | 2020-09-22 | 2021-01-22 | 广州思达信息科技有限公司 | 基于区块链的医药管理方法 |
CN112398837A (zh) * | 2020-11-05 | 2021-02-23 | 中国联合网络通信集团有限公司 | 数据授权方法、确权平台、运营商平台和*** |
CN112614586A (zh) * | 2020-12-15 | 2021-04-06 | 广东德澳智慧医疗科技有限公司 | 一种基于医学影像和区块链的远程疾病智能诊断*** |
CN112768022A (zh) * | 2021-01-26 | 2021-05-07 | 杭州卓健信息科技有限公司 | 一种医疗数据流转用的***及方法 |
CN112804218A (zh) * | 2020-12-31 | 2021-05-14 | 平安国际智慧城市科技股份有限公司 | 基于区块链的数据处理方法、装置、设备及储存介质 |
CN112908442A (zh) * | 2021-03-05 | 2021-06-04 | 京东数科海益信息科技有限公司 | 医疗数据共享方法、装置、设备及计算机可读介质 |
CN112948874A (zh) * | 2021-02-10 | 2021-06-11 | 上海凯馨信息科技有限公司 | 一种密态数据访问方法 |
CN112991045A (zh) * | 2021-03-22 | 2021-06-18 | 湖南大学 | 基于区块链的医疗健康消费融资方法、装置、设备及介质 |
CN113535854A (zh) * | 2021-07-28 | 2021-10-22 | 深圳创维-Rgb电子有限公司 | 基于区块链的用户数据处理方法、装置和可读存储介质 |
CN114189526A (zh) * | 2021-11-01 | 2022-03-15 | 北京中合谷投资有限公司 | 一种分布式网络的中心化调度算法 |
CN116344013A (zh) * | 2023-05-30 | 2023-06-27 | 浙江云针信息科技有限公司 | 一种医疗数据管理方法和*** |
CN116757857A (zh) * | 2023-08-17 | 2023-09-15 | 北方健康医疗大数据科技有限公司 | 基于区块链的商保数据管理方法、***、终端及存储介质 |
CN116910828A (zh) * | 2023-09-13 | 2023-10-20 | 合肥工业大学 | 一种智慧医疗图片信息安全处理方法及*** |
CN117809827A (zh) * | 2024-03-01 | 2024-04-02 | 吉林大学 | 一种基于物联网的护理信息管理*** |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108063752A (zh) * | 2017-11-02 | 2018-05-22 | 暨南大学 | 一种基于区块链与代理重加密技术的可信基因检测及数据共享方法 |
CN108632284A (zh) * | 2018-05-10 | 2018-10-09 | 网易(杭州)网络有限公司 | 基于区块链的用户数据授权方法、介质、装置和计算设备 |
CN108683630A (zh) * | 2018-04-03 | 2018-10-19 | 阿里巴巴集团控股有限公司 | 跨区块链的认证方法及装置、电子设备 |
CN108923925A (zh) * | 2018-06-22 | 2018-11-30 | 北京京东尚科信息技术有限公司 | 应用于区块链的数据存储方法和装置 |
CN109326337A (zh) * | 2018-09-06 | 2019-02-12 | 西安电子科技大学 | 基于区块链的电子医疗记录存储和共享的模型及方法 |
CN109493952A (zh) * | 2018-11-12 | 2019-03-19 | 湘潭大学 | 一种基于信用机制的智能合约医学影像安全共享的方法 |
CN109660485A (zh) * | 2017-10-10 | 2019-04-19 | 中兴通讯股份有限公司 | 一种基于区块链交易的权限控制方法及*** |
CN109948367A (zh) * | 2019-03-27 | 2019-06-28 | 南京星链高科技发展有限公司 | 一种基于区块链技术的医疗数据授权方法 |
CN109949882A (zh) * | 2018-11-15 | 2019-06-28 | 陕西医链区块链集团有限公司 | 一种医疗区块链数据存储*** |
CN109995737A (zh) * | 2018-01-02 | 2019-07-09 | ***通信有限公司研究院 | 去中心化的数字证书管理方法及装置、节点、*** |
CN110148475A (zh) * | 2019-04-03 | 2019-08-20 | 平安科技(深圳)有限公司 | 一种医疗信息共享方法、装置、可读存储介质及服务器 |
CN110224984A (zh) * | 2019-05-07 | 2019-09-10 | 平安科技(深圳)有限公司 | 一种基于区块链技术的多方授权方法及装置 |
-
2019
- 2019-09-11 CN CN201910860312.2A patent/CN110602089B/zh active Active
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109660485A (zh) * | 2017-10-10 | 2019-04-19 | 中兴通讯股份有限公司 | 一种基于区块链交易的权限控制方法及*** |
CN108063752A (zh) * | 2017-11-02 | 2018-05-22 | 暨南大学 | 一种基于区块链与代理重加密技术的可信基因检测及数据共享方法 |
CN109995737A (zh) * | 2018-01-02 | 2019-07-09 | ***通信有限公司研究院 | 去中心化的数字证书管理方法及装置、节点、*** |
CN108683630A (zh) * | 2018-04-03 | 2018-10-19 | 阿里巴巴集团控股有限公司 | 跨区块链的认证方法及装置、电子设备 |
CN108632284A (zh) * | 2018-05-10 | 2018-10-09 | 网易(杭州)网络有限公司 | 基于区块链的用户数据授权方法、介质、装置和计算设备 |
CN108923925A (zh) * | 2018-06-22 | 2018-11-30 | 北京京东尚科信息技术有限公司 | 应用于区块链的数据存储方法和装置 |
CN109326337A (zh) * | 2018-09-06 | 2019-02-12 | 西安电子科技大学 | 基于区块链的电子医疗记录存储和共享的模型及方法 |
CN109493952A (zh) * | 2018-11-12 | 2019-03-19 | 湘潭大学 | 一种基于信用机制的智能合约医学影像安全共享的方法 |
CN109949882A (zh) * | 2018-11-15 | 2019-06-28 | 陕西医链区块链集团有限公司 | 一种医疗区块链数据存储*** |
CN109948367A (zh) * | 2019-03-27 | 2019-06-28 | 南京星链高科技发展有限公司 | 一种基于区块链技术的医疗数据授权方法 |
CN110148475A (zh) * | 2019-04-03 | 2019-08-20 | 平安科技(深圳)有限公司 | 一种医疗信息共享方法、装置、可读存储介质及服务器 |
CN110224984A (zh) * | 2019-05-07 | 2019-09-10 | 平安科技(深圳)有限公司 | 一种基于区块链技术的多方授权方法及装置 |
Cited By (42)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111145850A (zh) * | 2019-12-23 | 2020-05-12 | 支付宝(杭州)信息技术有限公司 | 基于区块链的医疗数据查询方法以及装置 |
CN111180031A (zh) * | 2019-12-31 | 2020-05-19 | 贵州精准健康数据有限公司 | 数据管理***及方法 |
CN111180031B (zh) * | 2019-12-31 | 2023-07-28 | 贵州精准健康数据有限公司 | 数据管理***及方法 |
CN110826026A (zh) * | 2020-01-13 | 2020-02-21 | 江苏万链区块链技术研究院有限公司 | 基于区块链技术的出版物及其关联版权保护的方法和*** |
CN110826026B (zh) * | 2020-01-13 | 2020-04-24 | 江苏万链区块链技术研究院有限公司 | 基于区块链技术的出版物及其关联版权保护的方法和*** |
CN111222118A (zh) * | 2020-01-16 | 2020-06-02 | 王江盼 | 基于联盟链的证明信息生成和查询方法 |
CN111222118B (zh) * | 2020-01-16 | 2022-09-30 | 王江盼 | 基于联盟链的证明信息生成和查询方法 |
CN111291420A (zh) * | 2020-01-21 | 2020-06-16 | 国家市场监督管理总局信息中心 | 一种基于区块链的分布式离链数据存储方法 |
CN111291420B (zh) * | 2020-01-21 | 2022-11-11 | 国家市场监督管理总局信息中心 | 一种基于区块链的分布式离链数据存储方法 |
CN111448565B (zh) * | 2020-02-14 | 2024-04-05 | 支付宝(杭州)信息技术有限公司 | 基于去中心化标识的数据授权 |
CN111448565A (zh) * | 2020-02-14 | 2020-07-24 | 支付宝(杭州)信息技术有限公司 | 基于去中心化标识的数据授权 |
CN111506901B (zh) * | 2020-04-16 | 2023-09-05 | 腾讯科技(深圳)有限公司 | 基于区块链的数据处理方法、终端及存储介质 |
CN111506901A (zh) * | 2020-04-16 | 2020-08-07 | 腾讯科技(深圳)有限公司 | 基于区块链的数据处理方法、终端及存储介质 |
CN111681723A (zh) * | 2020-04-27 | 2020-09-18 | 山东浪潮通软信息科技有限公司 | 一种基于区块链的健康信息管理方法及设备、介质 |
CN111783070A (zh) * | 2020-06-29 | 2020-10-16 | 平安科技(深圳)有限公司 | 基于区块链的档案信息获取方法、装置、设备及存储介质 |
CN111899826A (zh) * | 2020-07-27 | 2020-11-06 | 深圳微控科技有限公司 | 健康数据管理方法、装置、计算机设备和存储介质 |
CN111881481A (zh) * | 2020-08-05 | 2020-11-03 | 杭州翔毅科技有限公司 | 基于区块链的医疗数据处理方法、装置、设备及存储介质 |
CN111881481B (zh) * | 2020-08-05 | 2024-04-09 | 杭州翔毅科技有限公司 | 基于区块链的医疗数据处理方法、装置、设备及存储介质 |
CN111914029A (zh) * | 2020-08-06 | 2020-11-10 | 平安科技(深圳)有限公司 | 基于区块链的医疗数据调用方法、装置、电子设备及介质 |
CN112163171A (zh) * | 2020-09-21 | 2021-01-01 | 中国电子科技网络信息安全有限公司 | 一种基于终端签名的数据记链方法 |
CN112163171B (zh) * | 2020-09-21 | 2022-03-18 | 中国电子科技网络信息安全有限公司 | 一种基于终端签名的数据记链方法 |
CN112260996A (zh) * | 2020-09-22 | 2021-01-22 | 广州思达信息科技有限公司 | 基于区块链的医药管理方法 |
CN112398837B (zh) * | 2020-11-05 | 2023-04-18 | 中国联合网络通信集团有限公司 | 数据授权方法、确权平台、运营商平台和*** |
CN112398837A (zh) * | 2020-11-05 | 2021-02-23 | 中国联合网络通信集团有限公司 | 数据授权方法、确权平台、运营商平台和*** |
CN112614586B (zh) * | 2020-12-15 | 2022-04-22 | 广东德澳智慧医疗科技有限公司 | 一种基于医学影像和区块链的远程疾病智能诊断*** |
CN112614586A (zh) * | 2020-12-15 | 2021-04-06 | 广东德澳智慧医疗科技有限公司 | 一种基于医学影像和区块链的远程疾病智能诊断*** |
CN112804218A (zh) * | 2020-12-31 | 2021-05-14 | 平安国际智慧城市科技股份有限公司 | 基于区块链的数据处理方法、装置、设备及储存介质 |
CN112804218B (zh) * | 2020-12-31 | 2024-04-12 | 深圳平安智慧医健科技有限公司 | 基于区块链的数据处理方法、装置、设备及储存介质 |
CN112768022A (zh) * | 2021-01-26 | 2021-05-07 | 杭州卓健信息科技有限公司 | 一种医疗数据流转用的***及方法 |
CN112768022B (zh) * | 2021-01-26 | 2024-06-11 | 杭州卓健信息科技有限公司 | 一种医疗数据流转用的***及方法 |
CN112948874A (zh) * | 2021-02-10 | 2021-06-11 | 上海凯馨信息科技有限公司 | 一种密态数据访问方法 |
CN112908442A (zh) * | 2021-03-05 | 2021-06-04 | 京东数科海益信息科技有限公司 | 医疗数据共享方法、装置、设备及计算机可读介质 |
CN112991045B (zh) * | 2021-03-22 | 2024-03-01 | 湖南大学 | 基于区块链的医疗健康消费融资方法、装置、设备及介质 |
CN112991045A (zh) * | 2021-03-22 | 2021-06-18 | 湖南大学 | 基于区块链的医疗健康消费融资方法、装置、设备及介质 |
CN113535854A (zh) * | 2021-07-28 | 2021-10-22 | 深圳创维-Rgb电子有限公司 | 基于区块链的用户数据处理方法、装置和可读存储介质 |
CN114189526A (zh) * | 2021-11-01 | 2022-03-15 | 北京中合谷投资有限公司 | 一种分布式网络的中心化调度算法 |
CN116344013A (zh) * | 2023-05-30 | 2023-06-27 | 浙江云针信息科技有限公司 | 一种医疗数据管理方法和*** |
CN116757857B (zh) * | 2023-08-17 | 2023-11-10 | 北方健康医疗大数据科技有限公司 | 基于区块链的商保数据管理方法、***、终端及存储介质 |
CN116757857A (zh) * | 2023-08-17 | 2023-09-15 | 北方健康医疗大数据科技有限公司 | 基于区块链的商保数据管理方法、***、终端及存储介质 |
CN116910828B (zh) * | 2023-09-13 | 2023-12-19 | 合肥工业大学 | 一种智慧医疗图片信息安全处理方法及*** |
CN116910828A (zh) * | 2023-09-13 | 2023-10-20 | 合肥工业大学 | 一种智慧医疗图片信息安全处理方法及*** |
CN117809827A (zh) * | 2024-03-01 | 2024-04-02 | 吉林大学 | 一种基于物联网的护理信息管理*** |
Also Published As
Publication number | Publication date |
---|---|
CN110602089B (zh) | 2021-08-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110602089B (zh) | 基于区块链的医疗数据存储方法、装置、设备及存储介质 | |
CN110245144B (zh) | 协议数据管理方法、装置、存储介质及*** | |
CN111245745B (zh) | 消息发送方法、装置、节点设备及存储介质 | |
CN110889772B (zh) | 保单处理方法、装置、计算机设备及存储介质 | |
CN110401715B (zh) | 资源收集任务管理方法、装置、存储介质及*** | |
CN110687821B (zh) | 基于区块链的智能家居控制***及方法 | |
CN111340482B (zh) | 冲突检测方法、装置、节点设备及存储介质 | |
CN110689460A (zh) | 基于区块链的交通事故数据处理方法、装置、设备及介质 | |
CN111355732B (zh) | 链接检测方法、装置、电子设备及存储介质 | |
CN110597924B (zh) | 基于区块链的用户标识处理方法、装置、设备及存储介质 | |
CN111159474B (zh) | 基于区块链的多线取证方法、装置、设备及存储介质 | |
CN110826103B (zh) | 基于区块链的文档权限处理方法、装置、设备及存储介质 | |
CN110555780B (zh) | 基于区块链的保险数据处理方法、装置、设备及存储介质 | |
CN111339086A (zh) | 区块处理方法、基于区块链的数据查询方法及装置 | |
CN110598386B (zh) | 基于区块链的数据处理方法、装置、设备及存储介质 | |
CN110598879A (zh) | 基于区块链的垃圾回收方法、装置、设备及存储介质 | |
CN111667371B (zh) | 基于区块链的资源聚合方法、***、设备及存储介质 | |
CN111212074B (zh) | 基于区块链的资格认定方法、装置、设备及存储介质 | |
CN111145034A (zh) | 基于区块链的社保管理方法、装置及***、存储介质 | |
CN110597906A (zh) | 基于区块链的入学积分生成方法、装置、设备及存储介质 | |
CN110599328A (zh) | 基于区块链的风险用户确定方法、装置、设备及存储介质 | |
CN110597840A (zh) | 基于区块链的伴侣关系建立方法、装置、设备及存储介质 | |
CN110597868A (zh) | 基于区块链的信息查询方法、装置、终端及存储介质 | |
CN111327427B (zh) | 提交备选区块的方法、装置、节点设备、***及存储介质 | |
CN111277608B (zh) | 基于区块链的安全风险信息管理方法、装置、设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40015638 Country of ref document: HK |
|
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |