CN111599425B - Hierarchical electronic medical record storage method and device based on block chain oriented node dynamics - Google Patents

Abstract

The invention discloses a node-dynamic hierarchical electronic medical record storage method and device based on blockchain, which can read relevant data through data consensus processing, data synchronization processing, and data dissemination processing according to the retrieval request sent by the patient. ; According to the authorization and key sent by the patient, the aforementioned read relevant data is sent to the corresponding department doctor; according to the aforementioned patient authorization, the doctor is allowed to write and manage the data of the corresponding medical record; the aforementioned doctor's management operation of the medical record is fed back to Data pool; this invention ensures the real-time correctness of data reading and the integrity of the node's local database through two verification mechanisms, ensuring that the data in the blockchain will not be tampered with, and even if it is modified, there will be traces. Follow-up, leaving evidence of tampering; in addition, for the setting of the key, the patient can divide the key into secret shares and distribute it to his relatives, friends or third-party organizations to prepare for the activation of registration when unexpected situations occur.

Description

Hierarchical electronic medical record storage method and device based on blockchain for node dynamics

Technical field

The present invention relates to the field of computer technology, and specifically relates to a node dynamic oriented hierarchical electronic medical record storage method and device based on blockchain.

Background technique

Electronic medical records have been developed for nearly sixty years, and it has been more than twenty years since hospitals in my country began to digitize medical records. Compared with traditional paper medical records, electronic medical records have the advantages of sufficient content, medical record standards and specifications, quality of medical record management, easy storage and convenient access, and conducive to the sharing of medical records. Electronic medical records and HIS systems complement each other and can improve medical work efficiency, enhance medication safety, and provide data mining for electronic medical records. With the rapid development of big data and machine learning, current electronic medical records are integrated with systems such as EMR, LIS, and PACS to realize data sharing between systems and break down information silos.

However, the current electronic medical records that have been applied mainly focus on work efficiency and management standards. The current newer electronic medical record designs only add discussion and support for the latest hot topics such as data sharing and data mining, and are still centralized. The storage mechanism is deployed inside the hospital. Medical records are completely controlled by the hospital system administrator and are very easy to be tampered with. However, it is very difficult to prove the authenticity of electronic medical records at present, because the current evidence of tamper-proof electronic medical records mainly includes: claiming that electronic medical records have secure anti-intrusion facilities, strict access control, and cryptographic technology to prevent tampering. But these claims are not technically sufficient to prove that electronic medical records have not been tampered with. The current method of proving the authenticity of electronic medical records still has shortcomings.

In recent years, with the rise of blockchain technology, many scholars and companies have begun to turn their hopes for the security of electronic medical records to blockchain technology, hoping to use the anti-tampering characteristics of blockchain technology to solve the problem that electronic medical records may be tampered with and the tampering cannot be detected. current situation. There are currently many electronic medical records and electronic certificate storage systems designed based on blockchain, but most of them use the PBFT algorithm. At present, these systems or products have more or less problems that cannot be solved or adapted to this system. requirements of application scenarios. The first is the consensus algorithm: quite a few systems use their own consensus algorithm or a newly proposed consensus algorithm, but there are always certain problems. The security and practicality of the algorithm do not guarantee continuity and integrity; secondly, In terms of framework design, some frameworks are not suitable for direct application in existing medical systems and are difficult to implement. And some systems adopt existing consensus protocol algorithms or frameworks, taking into account the design and functions at the application level, but lack consensus algorithm adaptation for situations where blockchain nodes may not be online. There are also some consensus protocols based on the PBFT algorithm that do not take into account network partitions, are relatively static, and lack processing for dynamic joining and leaving of nodes. There are also some studies that consider introducing tokens into the medical system to convert medical record data into value. They mainly consider data sharing and transactions, but there is insufficient consideration for data tamper resistance.

To this end, in view of the above-mentioned disadvantages, a method/device is designed for the deployment of blockchain-based distributed electronic medical record storage between hospitals, especially when there are a large number of lightweight medical institutions such as small medical institutions such as clinics and private hospitals. There may be blockchain application methods in the environment of offline or maintenance operations, and can solve the above existing problems at the same time, which has become an innovative design concept for current technicians.

Contents of the invention

In order to overcome the shortcomings of the existing technology, the purpose of the present invention is to provide a node dynamic hierarchical electronic medical record storage method and device based on blockchain, which solves the problem of network reasons and possible offline nodes in the existing technology. There may be situations where most nodes have the same values, and the PBFT algorithm cannot reach consensus. The relatively static PBFT algorithm is difficult to apply in this scenario. In addition, although the blockchain can ensure that the data is not tampered with, it cannot guarantee that the data will not be tampered with. Whether the data is correct at the time, when the data in the local blockchain is modified, it is impossible to detect the modification of the data in real time, and then the tampered data is read when reading, and it is impossible to rely on the tamper resistance of the blockchain to detect it in real time. Changes and other issues mentioned above.

In view of the above problems, the present invention provides a node dynamic oriented hierarchical electronic medical record storage method and device based on blockchain.

In a first aspect, the present invention provides a node-dynamic hierarchical electronic medical record storage method based on blockchain. The specific steps of the method include:

Step 1: According to the retrieval request sent by the patient, read relevant data through data consensus processing, data synchronization processing, and data dissemination processing;

Step 2: Based on the authorization and key sent by the patient, send the relevant data read in step 1 to the doctor in the corresponding department;

Step 3: Based on the patient authorization in Step 2, allow doctors to write and manage data on the corresponding medical records;

Step 4: Feed back the doctor’s medical record management operations in Step 3 to the data pool;

Blockchain layering scheme: Set large hospitals with sufficient computing power and higher credibility as main nodes, and set private hospitals and health clinic nodes with insufficient computing power and which may often go offline and online as edge nodes. Edge nodes Only the block header is stored, while the main node stores the complete data;

The specific steps of the data consensus processing include:

Step 1.0: All major nodes write timestamps on the received medical records and transition to a state ready for broadcast;

Step 1.1: If this node is the main node, x = Merkel tree calculated by the node based on the received medical record information in the time period from t to t+m;

Step 1.2: If this node is an edge node, leave x blank;

Step: 1.3: The order node sends a message to all major nodes, notifying them to package the medical records within the time period from t to t+m;

Step 1.4: The number of stages is less than f+1, continue to step 1.6;

Step 1.5: The algorithm ends;

Step 1.6: This node broadcasts its own input value value(x) and changes to a state ready to receive proposals;

Step 1.7: If this node receives value(y) broadcast by other nodes at least n-f times, then this node broadcasts propose(y);

Step 1.8: If this node receives proposal(z) at least f times, then this node modifies x to z;

Step 1.9: The RSA random number generator generates the master node vi of the i-th stage, and the master node does not repeat in each stage;

Step 1.10: The master node vi broadcasts its value value(w);

Step 1.11: If the number of times this node receives propose(x) is strictly less than n-f, then this node modifies x to w;

Step 1.12: Add 1 to the number of stages and return to step 1.4. .

1. Preferably, the data synchronization processing includes:

Step 2.0: If node u calls this algorithm when it is disconnected from the network, it will stop broadcasting the medical record block, the new medical record will be kept locally, and the system will continue to run in the network partition, waiting for the network to recover.

Step 2.1: If node u calls this algorithm in the propagation algorithm or is disconnected from the network at a certain moment, enter step 2;

Step 2.2: Query the latest status of the blockchain through the arbitration system;

Step 2.3: Synchronize to the latest correct node determined by the arbitration algorithm, apply the read server to obtain the data, and restart the execution of the algorithm after the synchronization is completed.

Step 2.4: If synchronization fails, go to step 2.2.

2. Preferably, the specific steps of the data dissemination process include:

Step 3.0: When consensus is not started, edge node v uploads medical records to its own master node.

Step 3.1: Master node u saves v’s medical records and the medical records broadcast by other master nodes in the local medical record pool;

Step 3.2: Whenever the data consensus processing proceeds to step 1.6, broadcast its own input value value(xi), value(xi) is the value(x) in step 1.6 of the data consensus processing, and xi is used here to refer to the ith time. x when reaching data consensus processing step 1.6;

Step 3.3: In the i-th consensus, t2 is selected as the medical record from t to t+m to calculate the Merkel tree;

Step 3.4: After i consensus is completed, package the medical records uploaded by hospitals within the buffer in the buffer, and request verification from the node whose input value is the same as the system consensus value to verify whether it has been confirmed by the blockchain;

Step 3.5: Package the medical records uploaded by the hospitals within your own scope in the buffer, and request verification from the node whose input value is the same as the system consensus value whether it has been confirmed by the blockchain;

Step 3.6: The requested node verifies the medical record through the Merkel tree path and returns the verification result to the requesting node. The returned result is value(y), which contains unconfirmed medical records;

Step 3.7: In stages from t to t+m, if the medical record has a retention flag set, put value(y); if the medical record does not have a retention flag set, delete the medical record; when value(y) is not an empty set, end the algorithm. .

Preferably, the electronic medical record storage method also includes a verification algorithm that can confirm the integrity and accuracy of the data. The verification algorithm includes a real-time verification algorithm and a periodic verification algorithm.

3. Preferably, the specific steps of the real-time verification algorithm include:

Step 5.1: The data verification module receives the hash value Hash(M) of the medical record that needs to be verified;

Step 5.2: Calculate the node proof(leaves) required to prove Hash(M);

Step 5.3: Enter the Hash (M) and the node proof (leaves) required for proof into the proof algorithm. The proof algorithm searches in the Merkle tree and returns the verification result;

Step 5.4: Send the verification results to the node requesting verification.

4. Preferably, the periodic verification algorithm refers to local blockchain verification at regular intervals. Each server starts verification from the first block maintained by itself and continues to the latest block; specific steps include:

Step 6.1: p is used as the identifier to record the current block and is initialized to 0;

Step 6.2: Read the block header of the p-th block from the database and determine whether the specific data of this block is stored locally;

Step 6.3: If the specific data of this block is stored, read all medical records for verification. If no specific data is stored, only the block header is verified;

Step 6.4: If the verification is successful, continue to verify the next block. If the verification fails, request the data of block P from other backup nodes, restore block P, and continue to verify the next block after the verification is successful.

Preferably, the electronic medical record storage method also includes a key recovery management method. The specific method steps are:

Step 7.1: After the key is generated, use Shamir threshold secret sharing to fragment the key into k shares;

Step 7.2: When retrieving the password, n shard holders can provide the key to recover the key, where n≤k;

Step 7.3: After authorization, the key remains active for a medical session and is destroyed at the end of the session. A hierarchical electronic medical record storage device based on blockchain for node dynamics, which is characterized by: specifically including:

The first unit is used to read relevant data through data consensus processing, data synchronization processing, and data dissemination processing according to the retrieval request sent by the patient;

The second unit is used to send the relevant data read in step 1 to the doctor in the corresponding department based on the authorization and key sent by the patient;

The third unit is used to allow doctors to write data to the corresponding medical records based on the patient authorization in step two;

The fourth unit is used to feed back the doctor's medical record management operations in step three to the data pool.

The invention provides a node-dynamic hierarchical electronic medical record storage method and device based on blockchain, which can read relevant data through data consensus processing, data synchronization processing, and data dissemination processing according to the retrieval request sent by the patient. ; According to the authorization and key sent by the patient, the aforementioned read relevant data is sent to the corresponding department doctor; according to the aforementioned patient authorization, the doctor is allowed to write and manage the data of the corresponding medical record; the aforementioned doctor's management operation of the medical record is fed back to Data pool. It can ultimately solve the problem that due to network reasons and nodes that may be offline, there may be situations where most nodes have the same value; the PBFT algorithm cannot reach consensus, and the relatively static PBFT algorithm is difficult to apply in this scenario; in addition, blockchain Although it can be guaranteed that the data has not been tampered with, there is no guarantee that the data is correct when the data is taken out; when the data in the local blockchain is modified, the modification of the data cannot be sensed in real time, and then the modified data cannot be sensed when reading. For tampered data, it is impossible to rely on the tamper resistance of the blockchain to detect changes in real time and other problems mentioned above.

The present invention adopts a layered architecture and divides the hospital into main nodes and edge nodes. The main nodes store specific data and the edge nodes store block headers. In this way, the threshold for participating in the system is lowered and the system stability and the credibility of data verification are improved. Spend.

This invention designs a new consensus algorithm, synchronization algorithm and propagation algorithm to reduce communication costs while ensuring consistency. At the same time, it achieves "effectiveness" that cannot be achieved by common algorithms such as PBFT, that is, it is assumed that the initial values of all nodes are not the same. Similarly, a consensus value can also be reached.

This invention aims at the problem that the blockchain can ensure that the overall data cannot be tampered with but cannot guarantee whether the read data is correct. Two verification mechanisms are designed, one is real-time verification and the other is periodic verification, to confirm the former verification. The integrity of the data being read, which checks the integrity of its own database.

The present invention designs a key scheme based on threshold secret sharing. Patients can divide the key into secret shares and distribute them to their relatives, friends or third-party organizations; thus in some unexpected emergencies, new keys can be kept or Recovery plan.

Description of drawings

Figure 1 is a schematic flow chart of the present invention's hierarchical electronic medical record storage method based on blockchain and oriented to node dynamics.

Figure 2 is a schematic diagram of the system architecture of the present invention's hierarchical electronic medical record storage method based on blockchain and oriented to node dynamics.

Figure 3 is a flow chart of the consensus algorithm in the present invention's blockchain-based hierarchical electronic medical record storage method oriented to node dynamics.

Detailed ways

Embodiments of the present invention provide a node-dynamic hierarchical electronic medical record storage method and device based on blockchain, which is used to solve the problem of inaccuracies in the PBFT algorithm in the existing technology and the inability to guarantee the information accuracy of the blockchain. Problem, the general idea of the technical solution provided by the present invention is as follows:

In order to better understand the above technical solutions, the technical solutions of the embodiments of this specification will be described in detail below through the accompanying drawings and specific examples. It should be understood that the embodiments of this specification and the specific features in the examples are the technical solutions of the embodiments of this specification. The detailed description is not intended to limit the technical solutions of this specification. The embodiments of this specification and the technical features in the embodiments can be combined with each other if there is no conflict.

Example 1:

Figure 1 is a schematic flow chart of a blockchain-based hierarchical electronic medical record storage method oriented to node dynamics in an embodiment of the present invention. As shown in Figure 1, the method includes:

Step 1: According to the retrieval request sent by the patient, read relevant data through data consensus processing, data synchronization processing, and data dissemination processing;

Step 2: Based on the authorization and key sent by the patient, send the relevant data read in step 1 to the doctor in the corresponding department;

Step 3: Based on the patient authorization in Step 2, allow doctors to write and manage data on the corresponding medical records;

Step 4: Feed back the doctor’s medical record management operations in Step 3 to the data pool.

Blockchain layering scheme: Set large hospitals with sufficient computing power and higher credibility as main nodes, and set private hospitals and health clinic nodes with insufficient computing power and which may often go offline and online as edge nodes. Edge nodes only store block headers, while primary nodes store the complete data.

Figure 3 is a flow chart of the data consensus processing. The specific steps include:

Step 0: All major nodes write timestamps on the received medical records and transition to a state ready for broadcast;

Step 1: If this node is the main node, x = Merkel tree calculated by the node based on the received medical record information in the time period from t to t+m; if this node is an edge node, x is left blank;

Step 2: The order node sends a message to all major nodes, notifying them to package the medical records from t to t+m;

Step 3: The number of stages is less than f+1, continue to step 4; otherwise, the algorithm ends;

Step 4: This node broadcasts its own input value value(x) and changes to a state ready to receive proposals;

Step 5: If this node receives value(y) broadcast by other nodes at least n-f times, then this node broadcasts propose(y);

Step 6: If this node receives proposal(z) at least f times, then this node modifies x to z;

Step 7: The RSA random number generator generates the master node vi of the i-th stage, and the master node does not repeat in each stage;

Step 8: The master node vi broadcasts its value value(w);

Step 9: If the number of times this node receives propose(x) is strictly less than n-f, then this node modifies x to w;

Step 10: Add 1 to the number of stages and return to step 3.

The specific steps of data synchronization include:

Step 0: If node u calls this algorithm in the propagation algorithm or is disconnected from the network at a certain moment, enter step 1;

Step 1: If it is disconnected from the network, stop broadcasting the medical record block, keep the newly added medical records locally, and the system continues to run in the network partition, waiting for the network to recover, otherwise go to step 2 directly;

Step 2: Query the latest status of the blockchain through the arbitration system;

Step 3: Synchronize to the latest correct node determined by the arbitration algorithm, and apply the read server to obtain the data. If the synchronization fails, enter step 2;

Step 4: Restart the algorithm after synchronization is completed.

The specific steps of the data dissemination processing include:

Step 0: When consensus is not started, edge node v uploads medical records to its master node, and master node u saves v's medical records and the medical records broadcast by other master nodes in the local medical record pool;

Step 1: Broadcast value(xi) when proceeding to step 2 of the algorithm;

Step 2: In the i-time consensus, t2 is selected as the medical record from t to t+m to calculate the Merkel tree. After the i-time consensus is completed;

Step 3: Package the medical records uploaded by hospitals within your own scope in the buffer, and request verification from the node whose input value is the same as the system consensus value whether it has been confirmed by the blockchain;

Step 4: The requested node verifies the medical record through the Merkel tree path and returns the verification result to the requesting node. The returned result is value(y), which contains unconfirmed medical records;

The electronic medical record storage method also includes a verification algorithm that can confirm the integrity and accuracy of the data. The verification algorithm includes a real-time verification algorithm and a periodic verification algorithm.

Among them, in the real-time verification algorithm, the data verification module verifies a certain medical record and returns the verification results. The principle of the data verification module is to use the characteristics of the Merkle tree to quickly query whether a node is in the tree based on the Merkle tree, thereby determining whether the medical record is the correct medical record. Merkle trees can provide a fast data verification method, which is much faster than traversing and searching for all data. The specific operation process of data verification is as follows:

Step 1: The data verification module receives the hash value Hash(M) of the medical record that needs to be verified;

Step 2: Calculate the node proof(leaves) required to prove Hash(M);

Step 3: Enter the Hash (M) and the node proof (leaves) required for proof into the proof algorithm. The proof algorithm searches in the Merkle tree and returns the verification result;

Step 4: Send the verification results to the node requesting verification.

Periodic verification method, the system performs local blockchain verification at regular intervals to ensure that the local server maintains data integrity. Each server starts verification from the first block maintained by itself and continues until the latest block is verified. The specific process of periodic verification is as follows:

Step 1: p is used as the identifier to record the current block and is initialized to 0;

Step 2: Read the block header of the p-th block from the database and determine whether the specific data of this block is stored locally;

Step 3: If the specific data of this block is stored, read all medical records for verification. If no specific data is stored, only the block header is verified;

Step 4: If the verification is successful, continue to verify the next block. If the verification fails, request the data of block P from other backup nodes, restore block P, and continue to verify the next block after the verification is successful.

The electronic medical record storage method also includes a key recovery management method. After the patient generates the key, he uses Shamir threshold secret sharing to fragment the key into m parts and share it with his trusted relatives and friends or a trusted third party institution participating in the system. , when retrieving the password, n (n ≤ m) shard holders can provide the key to recover the key. After a visit is made and the doctor is authorized, the key will be obtained by the medical institution, remain active during a visit session, and be destroyed after the session ends. Considering that the key may be leaked in the server of the medical institution, a key update method can be adopted, and the system reminds the user to update the key at regular intervals. Users can also choose to update their keys on their own, which can avoid future leaks of medical records. The key is uploaded to the key pool after being encrypted by the user's password. Since only the MD5 value of the password is stored in the server, even if the attacker obtains the key from the server's key pool, he cannot decrypt the key to avoid information leakage.

The invention provides a node-dynamic hierarchical electronic medical record storage method and device based on blockchain, which can read relevant data through data consensus processing, data synchronization processing, and data dissemination processing according to the retrieval request sent by the patient. ; According to the authorization and key sent by the patient, the aforementioned read relevant data is sent to the corresponding department doctor; according to the aforementioned patient authorization, the doctor is allowed to write and manage the data of the corresponding medical record; the aforementioned doctor's management operation of the medical record is fed back to Data pool. In the end, even if there are network reasons and the node may be offline, the accuracy of data reading can still be guaranteed; through two verification mechanisms, the real-time correctness of data reading and the integrity of the node's local database are guaranteed. It can ensure that the data in the blockchain will not be tampered with, and even if it is changed, it will be traceable and leave evidence of tampering; in addition, for the setting of the key, the patient can divide the key into secret shares and distribute them to his relatives and friends. Friends or third-party organizations to prepare for the activation of registration when unexpected circumstances occur.

It is obvious to those skilled in the art that the present invention is not limited to the details of the above-described exemplary embodiments, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention. Therefore, the embodiments should be regarded as illustrative and non-restrictive from any point of view, and the scope of the present invention is defined by the appended claims rather than the above description, and it is therefore intended that all claims falling within the claims All changes within the meaning and scope of equivalent elements are included in the present invention. Any reference signs in the claims shall not be construed as limiting the claim in question.

In addition, it should be understood that although this specification is described in terms of implementations, not each implementation only contains an independent technical solution. This description of the specification is only for the sake of clarity, and those skilled in the art should take the specification as a whole. , the technical solutions in each embodiment can also be appropriately combined to form other implementations that can be understood by those skilled in the art.

Claims (9)

1. A hierarchical electronic medical record storage method oriented to node dynamics based on blockchain, which is characterized in that: the specific steps of the method include: Step 1: According to the retrieval request sent by the patient, read relevant data through data consensus processing, data synchronization processing, and data dissemination processing; Step 2: Based on the authorization and key sent by the patient, send the relevant data read in step 1 to the doctor in the corresponding department; Step 3: Based on the patient authorization in Step 2, allow doctors to write and manage data on the corresponding medical records; Step 4: Feed back the doctor’s medical record management operations in Step 3 to the data pool; Blockchain layering scheme: Set large hospitals with sufficient computing power and higher credibility as main nodes, and set private hospitals and health clinic nodes with insufficient computing power and which may often go offline and online as edge nodes. Edge nodes Only the block header is stored, while the main node stores the complete data; The specific steps of the data consensus processing include: Step 1.0: All major nodes write timestamps on the received medical records and transition to a state ready for broadcast; Step 1.1: If this node is the main node, x = Merkel tree calculated by the node based on the medical record information received in the time period from t to t+m; Step 1.2: If this node is an edge node, leave x blank; Step: 1.3: The order node sends a message to all major nodes, notifying them to package the medical records within the time period from t to t+m; Step 1.4: The number of stages is less than f+1, continue to step 1.6; Step 1.5: The algorithm ends; Step 1.6: This node broadcasts its own input value value(x) and changes to a state ready to receive proposals; Step 1.7: If this node receives value(y) broadcast by other nodes at least n-f times, then this node broadcasts propose(y); Step 1.8: If this node receives proposal(z) at least f times, then this node modifies x to z; Step 1.9: The RSA random number generator generates the master node vi of the i-th stage, and the master node does not repeat in each stage; Step 1.10: The master node vi broadcasts its value value(w); Step 1.11: If the number of times this node receives propose(x) is strictly less than n-f, then this node modifies x to w; Step 1.12: Add 1 to the number of stages and return to step 1.4. 2. The hierarchical electronic medical record storage method for node dynamics based on blockchain according to claim 1, characterized in that: the data synchronization processing, the specific steps include: Step 2.0: If node u calls this algorithm when it is disconnected from the network, it stops broadcasting the medical record block, the newly added medical records are kept locally, and the system continues to run in the network partition, waiting for the network to recover; Step 2.1: If node u calls this algorithm in the propagation algorithm or is disconnected from the network at a certain moment, enter step 2; Step 2.2: Query the latest status of the blockchain through the arbitration system; Step 2.3: Synchronize to the latest correct node determined by the arbitration algorithm, apply the read server to obtain the data, and restart the execution of the algorithm after the synchronization is completed; Step 2.4: If synchronization fails, go to step 2.2. 3. The hierarchical electronic medical record storage method for node dynamics based on blockchain according to claim 1, characterized in that: the data dissemination processing, the specific steps include: Step 3.0: When consensus is not started, edge node v uploads medical records to its own master node. Step 3.1: Master node u saves v’s medical records and the medical records broadcast by other master nodes in the local medical record pool; Step 3.2: Whenever the data consensus processing proceeds to step 1.6, broadcast its own input value value(xi), value(xi) is the value(x) in the data consensus processing step 1.6, here xi refers to the i-th time x when reaching data consensus processing step 1.6; Step 3.3: In the i-th consensus, t2 is selected as the medical record from t to t+m to calculate the Merkel tree; Step 3.4: After i consensus is completed, package the medical records uploaded by hospitals within the buffer in the buffer, and request verification from the node whose input value is the same as the system consensus value to verify whether it has been confirmed by the blockchain; Step 3.5: Package the medical records uploaded by the hospitals within your own scope in the buffer, and request verification from the node whose input value is the same as the system consensus value whether it has been confirmed by the blockchain; Step 3.6: The requested node verifies the medical record through the Merkle tree path and returns the verification result to the requesting node. The returned result is value(y), which contains unconfirmed medical records; Step 3.7: In stages from t to t+m, if the medical record has a retention flag set, put value(y); if the medical record does not have a retention flag set, delete the medical record; when value(y) is not an empty set, end the algorithm. . 4. The hierarchical electronic medical record storage method based on blockchain and oriented to node dynamics according to claim 1, characterized in that: the electronic medical record storage method also includes a verification algorithm that can confirm the integrity and accuracy of the data, so The verification algorithm includes real-time verification algorithm and periodic verification algorithm. 5. The hierarchical electronic medical record storage method for node dynamics based on blockchain according to claim 4, characterized in that: the real-time verification algorithm, the specific steps include: Step 5.1: The data verification module receives the hash value Hash(M) of the medical record that needs to be verified; Step 5.2: Calculate the node proof(leaves) required to prove Hash(M); Step 5.3: Enter the Hash (M) and the node proof (leaves) required for proof into the proof algorithm. The proof algorithm searches in the Merkle tree and returns the verification result; Step 5.4: Send the verification results to the node requesting verification. 6. The hierarchical electronic medical record storage method based on blockchain for node dynamics according to claim 4, characterized in that: the periodic verification algorithm refers to local blockchain verification at intervals, and each server Verification starts from the first block maintained by itself and continues until the latest block is verified; the specific steps include: Step 6.1: p is used as the identifier to record the current block and is initialized to 0; Step 6.2: Read the block header of the p-th block from the database and determine whether the specific data of this block is stored locally; Step 6.3: If the specific data of this block is stored, read all medical records for verification. If no specific data is stored, only the block header is verified; Step 6.4: If the verification is successful, continue to verify the next block. If the verification fails, request the data of block P from other backup nodes, restore block P, and continue to verify the next block after the verification is successful. 7. The hierarchical electronic medical record storage method based on blockchain and oriented to node dynamics according to claim 1, characterized in that: the electronic medical record storage method also includes a key recovery management method, and the specific method steps are: Step 7.1: After the key is generated, use Shamir threshold secret sharing to fragment the key into k shares. Step 7.2: When retrieving the password, n shard holders can provide the key to recover the key, where n≤k; Step 7.3: After authorization, the key remains active for a medical session and is destroyed at the end of the session. 8. Based on the hierarchical electronic medical record storage device oriented to node dynamics based on blockchain, the steps of implementing the method described in any one of claims 1 to 7 are characterized in that the specific steps are as follows: The first unit is used to read relevant data through data consensus processing, data synchronization processing, and data dissemination processing according to the retrieval request sent by the patient; The second unit is used to send the relevant data read in step 1 to the doctor in the corresponding department based on the authorization and key sent by the patient; The third unit is used to allow doctors to write data to the corresponding medical records based on the patient authorization in step two; The fourth unit is used to feed back the doctor's medical record management operations in step three to the data pool. 9. A computer-readable storage medium with a computer program stored thereon, characterized in that when the program is executed by a processor, the steps of the method described in any one of claims 1-7 are implemented.