Distributed medical data storage method based on blockchain technology

Abstract

The present invention discloses a distributed medical data storage method based on blockchain technology, and its model architecture is sequentially composed of a storage layer, a verification layer and a blockchain layer from bottom to top; the method includes two stages of relay data storage and relay data verification: in the relay data storage stage, the verification node NV function includes collecting the doctor's signature information and relay data information, verifying the doctor's signature information, constructing a relay data block, and recording a new block; in the relay data verification stage, the verification node NV function includes accepting the doctor's verification request, checking the local blockchain copy status, synchronizing the local blockchain copy status, retrieving the relay data of a given signature and returning the result. The doctor's signature information and relay data are saved in the relay data block of medical data to ensure data traceability, improve the credibility of the relay data storage of medical data, and ensure the integrity of the relay data of medical data.

Description

Technical Field

[0001] The present invention relates to the field of medical data storage, and in particular to a distributed medical data storage method based on blockchain technology. Background Art

[0002] In recent years, with the development of information technology and the promotion of digital hospital construction, medical data has exploded, and the data volume has gradually developed from the initial GB and TB to PB (1024TB) or EB (1000000TB) or even higher. The type of medical data has also gradually developed from simple text types to complex, high-dimensional data, such as semi-structured data, image data, video data, sensor data, and streaming data. How to achieve effective management and storage of massive medical data has become a problem that needs to be solved urgently. Obviously, the use of stand-alone storage systems or network storage systems cannot effectively store these massive medical data. Therefore, distributed storage systems play a very important role in storing these massive data. In the field of distributed storage of medical data, relay data is usually stored in the central node, which may lead to an increase in the risk of single point failure and face security challenges of malicious tampering. Although the introduction of backup nodes can alleviate these problems to a certain extent, the synchronization and switching efficiency between nodes is limited. In addition, the nodes storing relay data can reach a consensus to modify the relay data, which lacks credibility. In the process of distributed data storage, relay data usually includes the physical node information of the data copy, etc., which is stored in the central node. When storing and reading data, it is necessary to access the central node to obtain the relay data information. This way of storing relay data is prone to single point failure problems, that is, if the central node fails or crashes, the relay data cannot be read. Although this problem can be avoided to a certain extent by introducing backup nodes, the switching efficiency between nodes is low; and the relay data stored in the central node has low security, that is, the relay data may be maliciously tampered with before reading the original data. Summary of the invention

[0003] In view of the defects in the existing technology, we embed the relay data into the block for storage, and introduce redundant blockchain storage and collaborative verification mechanism to ensure the integrity and security of the relay data of medical data. The model is mainly divided into two key stages: the relay data storage stage of medical data and the verification stage. In the storage stage, the doctor's signature and the relevant copy location data will be sent to multiple verification nodes, and then the relay data block of medical data will be generated and written into the blockchain. In the verification stage, the verification node first checks whether the local relay data blockchain state is consistent with the global state. If it is inconsistent, the state synchronization operation will be performed. Next, the verification node will retrieve the local relay data blockchain to verify the integrity of the medical data relay data. It can ensure the traceability and integrity of the relay data of medical data, and has good concurrent processing performance, while having little impact on the efficiency of medical data storage.

[0004] This paper proposes a distributed medical data storage method based on blockchain technology, named DDS (Decentralized Distributed Storage). Its model architecture is composed of storage layer, verification layer and blockchain layer from bottom to top:

[0005] ① Storage layer: It is a traditional distributed storage system responsible for storing traditional medical data. During the storage process, it generates relay data of medical data, which includes the location information and number of data copies.

[0006] ②Verification layer: It consists of several verification nodes NodeforVerification, NV. Each verification node NV saves a copy of the blockchain in local storage and maintains the local blockchain state LocalState;

[0007] ③ Blockchain layer: Save the global state of the relay data blockchain GlobalState. All verification nodes NV can query this layer to synchronize the local blockchain state to achieve blockchain state consistency; at the same time, when a single point failure or downtime occurs in the storage layer, the distributed storage system can restore key data by reading the relay data blockchain of this layer; the relay data blockchain saved in the blockchain layer is read-only;

[0008] The distributed medical data storage method based on blockchain technology includes two stages: storage of relay data and verification of relay data: in the relay data storage stage, the verification node NV function includes collecting the doctor's signature information and relay data information, verifying the doctor's signature information, constructing relay data blocks, and recording new blocks;

[0009] During the relay data verification phase, the verification node NV functions include accepting the doctor's verification request, checking the status of the local blockchain copy, synchronizing the status of the local blockchain copy, retrieving the relay data of the given signature and returning the result.

[0010] Preferably, the NV is a physical node, or a virtual node implemented using multi-threading technology.

[0011] Preferably, the relay data block consists of two parts, including a block header BlockHeader and a block body BlockBody; wherein the block header includes the Hash value, MerkleRoot and timestamp of the previous block; the block body is a Merkle tree, and the leaf nodes are composed of relay data.

[0012] Preferably, the relay data blockchain is composed of a number of relay data blocks RB linked together, wherein the relay data block RB i+1 It is relayed by its predecessor data block RB i The result of Hash calculation is RB i+1 =Hash(RB i ), where RB0 is the initial block.

[0013] Preferably, the relay data storage stage: ① Each doctor signs the data and saves it to the storage node; ② The doctor's signature set and copy location information are sent to all verification nodes, where the copy location information can be obtained by the central node of the distributed storage system; ③ Each verification node verifies the signature information of all doctors. If all the signature information is verified, the doctor's signature and the corresponding user data copy location information are used to construct the relay data, and the relay data block is constructed; ④ The relay data blockchain is updated.

[0014] Preferably, in the relay data verification stage: ① the doctor sends the signature information to all verification nodes; ② each verification node checks whether the status of the local relay data blockchain is consistent with the global status. The verification nodes with inconsistent status need to synchronize the status of the blockchain by reading the blockchain layer; ③ the verification node retrieves the data location information corresponding to the doctor's signature in the local relay data blockchain copy; ④ the verification result is returned to the doctor.

[0015] Compared with the prior art, the present invention has the following beneficial effects:

[0016] 1) A storage model of relay data blockchain based on medical data is proposed, a blockchain model for relay data storage of medical data is designed, and the relay data storage algorithm and verification algorithm of medical data are given.

[0017] 2) The doctor's signature information and relay data are stored in the relay data block of medical data to ensure data traceability; the credibility of the relay data storage of medical data is improved by introducing multiple nodes to participate in the recording; the integrity of the relay data of medical data is ensured by using the characteristics of the blockchain itself.

[0018] 3) The DDS model has better efficiency in storing and verifying the relay data of medical data, improves the security of the relay data of medical data, and has little impact on the efficiency of storing data. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 Medium / slave distributed storage system architecture

[0020] Figure 2 DDS model

[0021] Figure 3 Relay data chunk model

[0022] Figure 4 For: Relay data blockchain model

[0023] Figure 5 To: Relay the data storage and validation process DETAILED DESCRIPTION

[0024] The present invention is further described in detail below in conjunction with specific implementation modes.

[0025] The distributed medical data storage method based on blockchain technology described in the present invention is named DDS (Decentralized Distributed Storage). Its model architecture is composed of storage layer, verification layer and blockchain layer from bottom to top:

[0026] ① Storage layer. This layer is a traditional distributed storage system, such as GFS or HDFS, which is responsible for storing traditional medical data and generates relay data of medical data during the storage process. These relay data include data copy location information, number of copies, etc.

[0027] ②Verification layer. This layer consists of several verification nodes (Node for Verification, NV). NV can be a physical node or implemented using multi-threading technology. Each verification node NV saves a copy of the blockchain in local storage and maintains the local blockchain state (Local State). The DDS model includes two parts: storage of relay data and verification of relay data. In the relay data storage stage, the functions of the verification node NV include collecting the doctor's signature information and relay data information, verifying the doctor's signature information, constructing relay data blocks, and recording new blocks; in the relay data verification stage, the functions of the verification node NV include accepting the doctor's verification request, checking the status of the local blockchain copy, synchronizing the status of the local blockchain copy, retrieving the relay data of a given signature and returning the result.

[0028] ③ Blockchain layer. This layer saves the global state (GlobalState) of the relay data blockchain. All verification nodes NV can query this layer to synchronize the local blockchain state to achieve blockchain state consistency. At the same time, when a single point failure or downtime occurs in the storage layer, the distributed storage system can restore key data by reading the relay data blockchain of this layer. In addition, the relay data blockchain saved in this layer is read-only, that is, if the location information of the data stored by the doctor changes, then only new relay data information can be regenerated, a new relay data block can be constructed, and recorded in the relay data blockchain.

[0029] Relay data blockchain

[0030] The data in the blockchain is stored in several blocks. Each block is linked to the previous block through a specific method, forming a complete chain data storage structure. Each block consists of two parts: a block header (BlockHeader) and a block body (BlockBody). The block header stores the hash value of the block, which is calculated by hashing the block header of the previous block. In this way, all blocks can be combined into a chain that depends on its previous block. The block body is responsible for storing data. The blockchain in the DDS model stores the relay data generated by patients during hospital treatment. This chapter first introduces relay data, then relay data blocks, and finally, relay data blockchains.

[0031] Relaydata: Let doctor c, data to be stored fc, tuple <sig c ,loc fc >Represents the relay data of the data, where sig c Indicates the signature of user c, loc fc Indicates the location information of data fc saved by doctor c.

[0032] Relay data block (RB): The relay data block consists of two parts, including a block header and a block body. The block header includes the Hash value of the previous block, the Merkle Root, and the timestamp. The block body is a Merkle tree, and the leaf nodes are composed of relay data. The relay data block model is as shown in Figure 3 shown below.

[0033] Given a set of relay data R = {<sig1, loc f1 >, <sig2, loc f2 >, …, <sig m , loc fm >}, the Merkle

[0034] root (Merkle Root) generated by R is unique. According to the definition of the Merkle tree, all nodes except the leaf nodes are composed of the Hash values of their child nodes. In the Merkle tree shown in Figure 3 , all nodes from the penultimate layer to the root node are obtained by performing a Hash operation on their child nodes. For example, Hash(1, 2) = Hash(Hash(1) U Hash(2)). And so on, finally obtaining the root node of this Merkle tree. According to the uniqueness of the hash algorithm, if any information in the leaf nodes changes, the finally calculated root node will also change.

[0035] Relay data blockchain (RBC): The relay data blockchain is composed of several linked relay data blocks RB, as shown in Figure 4 , where the relay data block RB i+1 is obtained by performing a Hash calculation on its predecessor relay data block RB i , that is, RB i+1 = Hash(RB i ). Among them, RB0 is the initial block.

[0036] Given the relay data blockchain RBC = {RB0, RB1, …, RB m}, if a certain relay data block RB i (0 < i < m) in RBC is modified, then all blocks before RB i must be modified. Since a block is obtained by performing a Hash calculation on its previous block, and due to the uniqueness of the hash algorithm, if a certain block RB i in RBC is modified, then all its predecessor blocks need to be recalculated. i

[0037] Given a relay data blockchain RBC1 = {RB 11 ,RB 12 ,…,RB 1m} and RBC2 = {RB 21 ,RB 22 ,…,RB 2m}, if RBC1.RB 1i ->Header=RBC2.RB 2i ->Header, where 0≤i≤m, then RBC1 and RBC2 are said to have the same status. Suppose in time period t, there is a set of doctors S C ={c1,c2,c3,c4} stores data in a distributed storage system, and the corresponding signature information is S Sig ={sig1,sig2,sig3,sig4},S Loc ={loc f1 ,loc f2 ,loc f3 ,loc f4} represents the location information of the doctor's data copy storage, then the corresponding relay data S R ={ <sig1,loc f1 >, <sig2,loc f2 >, <sig3,loc f3 >, <sig4,loc f4 >}, through

[0038] The relay data block constructed by SR is as follows Figure 3 As shown, where MerkleRoot represents the relay data tuple S R The root of the constructed Merkle tree is unique. If you modify Figure 4 RB i+1 , you need to recalculate RB i+1 If there are two nodes v1 and v2 that save the relay data blockchain copies, denoted as v1.RBC and v2.RBC, at this time, if the block header information of the relay data blockchain copies saved by nodes v1 and v2 is the same, that is, v1RBC->Header=v2.RBC->Header, then it is determined that the states of the relay data blockchain copies saved by nodes v1 and v2 are consistent.

[0039] Relay data storage and verification

[0040] The DDS model consists of two parts: relay data storage and relay data verification. This section introduces the processes and pseudocodes of these two parts respectively, and gives examples to illustrate these two parts.

[0041] Relay data storage. First, each doctor signs the data and saves it to the storage node; then, the doctor's signature set and copy location information are sent to all verification nodes, where the copy location information can be obtained by the central node of the distributed storage system; next, each verification node verifies the signature information of all doctors. If all the signature information is verified, the doctor's signature and the corresponding user data copy location information are used to construct the relay data and the relay data block; finally, the relay data blockchain is updated.

[0042] Relay data verification. First, the doctor sends the signature information to all verification nodes; then, each verification node checks whether the status of the local relay data blockchain is consistent with the global status. The verification nodes with inconsistent status need to synchronize the blockchain status by reading the blockchain layer; next, the verification node retrieves the data location information corresponding to the doctor's signature in the local relay data blockchain copy; finally, the verification result is returned to the doctor. Figure 5 The detailed process of relay data storage and relay data verification is given.

[0043] (1) Relay Data Storage

[0044] Suppose there is a set of doctors S C ={c1,c2,…,c m}, the signature set S corresponding to each doctor Sig ={sig1, sig2, …, sig m},S F ={f1,f2,…,f m} is the data set to be stored for each doctor, S Loc ={loc sig1 ,loc sig2 ,…,loc sigm The location information of each signature data after it is stored in the distributed file system can be obtained through the central node. There are several verification nodes, which can be physical nodes or implemented through multi-threading technology. Relay data storage is divided into the following four steps:

[0045] 1) The doctor signs the data to be stored and obtains the signed number S F' ={ <f sig1 ,sig1>, <f sig2 ,sig2>,…, <f sigm ,sig m >} is saved to the distributed storage system, where f sigi Indicates doctor c i Signed data, where 0 <i≤m。

[0046] 2) S F' Sent to all verification nodes S NV , the verification node verifies the signature information of each doctor, and after verifying all the signature information, nv broadcasts the message message. After receiving the message, other verification nodes terminate the current verification process and wait for the next verification. At the same time, the verification node obtains the recording authority, which is recorded as n v '.

[0047] 3)n v 'Get S from the central node F' The location information of all data in S Loc , by relaying data S R ={ <sig1,loc sig1 >, <sig2,loc sig2 >,…, <sig m ,loc sigm >} Generate a Merkle tree and construct a relay data block RB, and finally write the relay data block into the local relay data blockchain n v 'RBC.

[0048] 4)n v 'Record RB to the global blockchain RBC G After the record is successful, n v 'Broadcast message message to notify other verification nodes to synchronize the local blockchain status.

[0049] It should be noted that, unlike traditional blockchain applications such as Ethereum, where computing nodes compete with each other, these applications introduce the POS (Ethereum) mechanism to achieve consistency. NV There is a collaborative relationship between them, and there is no competitive relationship, that is, all verification nodes S NV At the same time, collect the signature information S of all doctors in a given time period Sig and data copy information S Loc , during the signature verification process,

[0050] The nv that completes the verification of all doctors' signature information first can obtain the recording permission and broadcast a message to notify other nvs. The verification node that does not obtain the recording permission terminates the current operation and waits for the request in the next time period. The relay data storage process is shown in Algorithm 1. Algorithm 1 first signs all data to obtain the set S F' , then, S F' Save to the distributed storage system. Lines 3 to 6 indicate that for each verification node nv, all data and the corresponding signature information S are verified. Sig, if all verifications are passed, then the relay data is created. Lines 7 to 8 use all the relay data to generate a Merkle tree and construct a relay data block RB. Line 9 indicates that the first n v 'Broadcast message message to other nv and obtain recording permission. Line 10 indicates n v 'Write the block to the relay data blockchain RBC.

[0051] The following example illustrates the relay data storage process. Suppose the doctor set S C ={c1,c2,c3,c4}, corresponding signature information S Sig ={sig1, sig2, sig3, sig4}, the data to be stored for each doctor S F ={f1,f2,f3,f4}, verification node set First, each doctor signs the data to be stored using his own signature and obtains the signed data S F' ={f sig1 ,f sig2 ,f sig3 ,f sig4}; Then, S F' Stored in the distributed storage system; Next, all NVs verify the doctor's signature, assuming that the verification node First complete the verification of all signature information, Send a message to other verification nodes. After receiving the message, other verification nodes terminate the unfinished verification process and enter the waiting state. Get all S through the central node F' The copy information of the data in S Loc ={loc fsig1 ,loc fsig2 ,…,loc fsigm}, and construct the relay data block RB, and record it to the relay data blockchain RBC.

[0052]

[0053] (2) Relay data verification

[0054] Based on the tamper-proof characteristics of the blockchain itself, after the relay data is stored in the blockchain, it is not allowed to be modified at will. Doctors can send verification requests to the verification node at any time to verify the integrity of the relay data. In addition, if the central node fails, the relay data can also be restored by reading the global blockchain.

[0055] There is a doctor set S C={c1,c2,…,c m}, the signature set S corresponding to each doctor Sig ={sig1, sig2, …, sig m}, several verification nodes The relay data verification process is divided into three steps to retrieve the relay data blockchain through the doctor's signature:

[0056] 1) Doctor c∈S C , the signature information sig c Sent to all verification nodes S NV .

[0057] 2) Each verification node Where i∈[1,s], first check whether the local relay data blockchain state is consistent with the global state. If consistent, retrieve the signature information sig in the local blockchain c Corresponding location information loc fsigc On the contrary, if the status is inconsistent, you need to update the local blockchain before searching.

[0058] 3) When more than half of the verification nodes retrieve the same result, the verification result is returned to the doctor and a message is broadcast at the same time. Other verification nodes that have not completed the retrieval terminate the current retrieval process after receiving the message.

[0059] Similar to the relay data storage phase, in the relay data verification phase, all verification nodes are also in a collaborative relationship, that is, the first to retrieve the location information loc fsigc Verification node n v ', and return the result to the doctor. The relay data verification is shown in Algorithm 2.

[0060] Algorithm 2 first converts the signature information sig c Sent to all verification nodes S NV , lines 2 to 4 first check whether the state of the local relay data is consistent with the global state. If it is consistent, continue; otherwise, it is necessary to synchronize the local RBC state with the state of the global blockchain. Line 6 indicates that the local blockchain copy is queried according to the signature information sig, and sig is obtained. c Corresponding relay data information loc fsigc Lines 7 to 11 represent the check node n of the retrieved result. v 'Broadcast the message to other verification nodes and return the result to the doctor.

[0061]

[0062]

[0063] The following is an example to illustrate the whole process. Let the doctor set S C ={c1, c2, c3}, the signature information S Sig ={sig1, sig2, sig3}, the verification nodes represent the local blockchain status of all verification nodes, RBC G represents the global blockchain status. First, send the doctor's signature information to all verification nodes; then, all verification nodes check the local blockchain status. Here, it is assumed that the verification node RBC≠RBC G , then a synchronization operation needs to be performed first. The verification nodes and retrieve the relay data location information corresponding to each signature and return the retrieval results to the doctor. Assume that the location information loc fsig1 corresponding to sig1 is first retrieved by the verification node , broadcast the message message to other verification nodes, after receiving message, skip sig1 and continue to retrieve other signature information.

[0064] (3) Security analysis

[0065] Given the relay data blockchain S RBC ={RB1, RB2, …, RB m}, where RB i (0 < i < m) represents the relay data block. Assume that sig c is the signature information of doctor c. At this time, after doctor c stores the data, the central node will return the location information loc fc of the corresponding copy, generate the relay data, and the verification node constructs the relay data block through the relay data. Therefore, given sig c the location information where the data is saved can be traced, that is, the data is traceable.

[0066] During the relay data storage process, the verification node that first completes the verification of all signatures obtains the right to record, and at the same time broadcasts a message to "notify" other verification nodes to end the current verification process. This ensures that only one verification node can modify the global blockchain at a certain time, avoiding blockchain forks. After the relay data is successfully written into the blockchain, in order to prevent the verification node from tampering with the data in the local blockchain, all verification nodes will periodically synchronize the local blockchain. During the synchronization process, the verification node will read the block header information of the block to be synchronized in the global blockchain. If it is inconsistent with the block header of the local block, the corresponding local block will be replaced. Blockchain synchronization ensures that the relay data stored in all verification nodes is the same. At the same time, since the local blockchains of all verification nodes are the same, it can be guaranteed that the data of the corresponding signature is correct each time it is retrieved.

[0067] Since the data in the relay data block is composed of two tuples <sig c ,loc fsigc >Composed of a Merkle tree structure, where sig c Indicates the signature of doctor c, loc fsigc Indicates the location information of doctor data in the distributed storage system. At this time, if sig c or loc fc If there is a change, the Merkle tree will also change. This ensures the integrity of the data copy.

[0068] The above descriptions are only some specific implementation methods of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by any person familiar with the art within the technical scope disclosed in the present invention should be covered within the protection scope of the present invention.

Claims

1. A distributed medical data storage method based on blockchain technology, characterized by: The data storage model architecture is divided into the storage layer, verification layer and blockchain layer from bottom to top: ① Storage layer: It is a traditional distributed storage system responsible for storing traditional medical data. During the storage process, it generates relay data of medical data, which includes the location information and number of data copies. ②Verification layer: It consists of several verification nodes NodeforVerification, NV. Each verification node NV saves a copy of the blockchain in local storage and maintains the local blockchain state LocalState; ③ Blockchain layer: Save the global state GlobalState of the relay data blockchain. All verification nodes NV can query this layer to synchronize the local blockchain state to achieve blockchain state consistency; at the same time, when a single point failure or downtime occurs in the storage layer, the distributed storage system can restore key data by reading the relay data blockchain of this layer; The relay data blockchain stored in the blockchain layer is read-only; The verification layer includes two stages: storage of relay data and verification of relay data: in the relay data storage stage, the verification node NV collects the doctor's signature information and relay data information, verifies the doctor's signature information, constructs relay data blocks, and records new blocks; In the relay data verification phase, the verification node NV accepts the doctor's verification request, checks the status of the local blockchain copy, synchronizes the status of the local blockchain copy, retrieves the relay data of the given signature and returns the result; The relay data is defined as: Let doctor c, data to be stored fc, tuple <sig c ,loc fc >Represents the relay data of the data, where sig c Indicates the signature of user c, loc fc Indicates the location information of data fc saved by doctor c.

2. The distributed medical data storage method based on blockchain technology according to claim 1 is characterized by: The NV is a physical node, or a virtual node implemented using multi-threading technology.

3. The distributed medical data storage method based on blockchain technology according to claim 1 is characterized by: The relay data block consists of two parts, including a block header BlockHeader and a block body BlockBody; the block header includes the hash value, MerkleRoot and timestamp of the previous block; the block body is a Merkle tree, and the leaf nodes are composed of relay data.

4. The distributed medical data storage method based on blockchain technology according to claim 1 is characterized in that: The relay data blockchain is composed of a number of relay data blocks RB linked together, where the relay data block RB i+1 It is relayed by its predecessor data block RB i The result of Hash calculation is RB i+1 =Hash(RB i ), where RB0 is the initial block.

5. The distributed medical data storage method based on blockchain technology according to claim 1 is characterized in that: The relay data storage stage: ① Each doctor signs the data and saves it to the storage node; ② The doctor's signature set and copy location information are sent to all verification nodes, where the copy location information can be obtained by the central node of the distributed storage system; ③ Each verification node verifies the signature information of all doctors. If all the signature information is verified, the doctor's signature and the corresponding user data copy location information are used to construct the relay data, and the relay data block is constructed; ④ The relay data blockchain is updated.

6. The distributed medical data storage method based on blockchain technology according to claim 1 is characterized by: The relay data verification stage: ① The doctor sends the signature information to all verification nodes; ② Each verification node checks whether the status of the local relay data blockchain is consistent with the global status. The verification nodes with inconsistent status need to synchronize the status of the blockchain by reading the blockchain layer; ③ The verification node retrieves the data location information corresponding to the doctor's signature in the local relay data blockchain copy; ④ Return the verification result to the doctor.

Images