Medical data circulation and storage method based on block chain

Abstract

The invention relates to the technical field of medical data circulation and storage, in particular to a block chain-based medical data circulation and storage method, which comprises the following steps of data storage, data circulation and data auditing. The medical data storage security is remarkably improved, the blockchain storage performance bottleneck is avoided, the non-tampering property of the blockchain ensures that the data operation record is traceable in the whole process, the malicious tampering risk of internal personnel is completely eradicated, a mixed encryption mechanism is adopted, a session key is chained after being encrypted by a public key of a patient, a private key is only held by the patient, the cracking difficulty is extremely high, and the safety is high. According to the method, high-efficiency and de-intermediary data circulation is achieved, patient privacy control and compliance are enhanced, fragmented PBFT consensus is adopted, the medical transaction throughput can reach 2000 + TPS, clinical real-time requirements are met, breakthrough is achieved in the aspects of safety, efficiency and privacy protection, and a trusted infrastructure is provided for medical data value circulation.

Description

Technical Field

[0001] The present invention relates to the technical field of medical data circulation and storage, and specifically to a medical data circulation and storage method based on blockchain. Background Art

[0002] In current medical information systems, medical data (such as electronic medical records, medical images, and test results) are typically stored in a centralized manner in hospital databases or regional medical cloud platforms. This model presents the following key issues:

[0003] (1) Insufficient data storage security

[0004] Single point of failure risk: Once a centralized database is attacked (such as ransomware) or suffers a hardware failure, it may lead to large-scale data loss or service interruption.

[0005] Data tampering risks: The integrity of medical data depends on the database administrator's authority, and there is a risk of malicious modification or operational errors by internal personnel (such as tampering with test results).

[0006] (2) Low data flow efficiency

[0007] Reliance on third-party intermediaries: Cross-institutional data sharing must go through regional health information platforms or third-party data exchange centers, which is a cumbersome and time-consuming process.

[0008] Privacy leakage risk: Intermediaries may retain copies of data, increasing the possibility of unauthorized access (such as the 2019 US medical data leak involving 20 million records).

[0009] (3) Lack of control over patient data

[0010] The authorization mechanism is not transparent: patients are usually unable to trace who accesses their data and for what purpose. The current "blanket authorization" model violates privacy regulations such as GDPR.

[0011] Data silo phenomenon: Data formats between different medical institutions are incompatible (such as mixing HL7 and FHIR standards), resulting in complex data cleaning and conversion required for sharing.

[0012] To address the above issues, existing technologies have attempted the following improvements, but they still have significant drawbacks:

[0013] (1) Encrypted database technology

[0014] Insider risk is not addressed: Even with transparent encryption (TDE) or field-level encryption (such as MySQL AES encryption), database administrators can still bypass auditing and directly access plaintext data.

[0015] Complex key management: Traditional PKI systems require a centralized CA organization, making key rotation difficult and unable to support fine-grained dynamic authorization.

[0016] (2) Initial application of blockchain

[0017] Storage performance bottleneck: Directly uploading medical data to the chain results in insufficient throughput (for example, Ethereum has only 15 TPS), making it difficult to support high-frequency medical scenarios.

[0018] Insufficient privacy protection: The transparency of public chains conflicts with the anonymization requirements of medical data. Existing solutions (such as zero-knowledge proofs) have high computational overhead and low practicality.

[0019] (3) Cross-institutional sharing agreements

[0020] Lack of standardization: Existing interoperability frameworks (such as IHE XDS.b) require customized interface development, which is costly to implement (deployment costs for a single hospital exceed US$500,000).

[0021] Data consistency challenges: When multiple parties maintain independent copies, real-time synchronization cannot be guaranteed (e.g., delayed updates of patient allergy information leading to medication errors).

[0022] No solutions have been proposed for the relevant technical issues. Summary of the Invention

[0023] In response to the problems in related technologies, the present invention proposes a blockchain-based medical data circulation and storage method to overcome the above-mentioned technical problems existing in existing related technologies. The purpose of the present invention is to significantly improve the security of medical data storage, realize efficient and decentralized data circulation, strengthen patient privacy control and compliance, support secure collaborative computing and federated learning, and only need to deploy light nodes and API gateways. Using sharded PBFT consensus, the medical transaction throughput can reach 2000+TPS, meeting clinical real-time needs.

[0024] To achieve the above objectives, the present invention provides the following technical solution: a blockchain-based medical data circulation and storage method, comprising the following steps:

[0025] S1. Data storage:

[0026] (1) Divide the medical data into several data fragments using a data fragmentation algorithm, with the size of each fragment not exceeding a preset threshold;

[0027] (2) Use the national secret SM4 or AES-256 algorithm to encrypt each fragment, generate encrypted data fragments, and add a timestamp and fragment serial number;

[0028] (3) Upload the encrypted data fragments to the distributed storage network and obtain the unique content identifier CID;

[0029] (4) Recording metadata on the blockchain;

[0030] S2. Data Flow:

[0031] (1) The data requester submits an access request by calling the requestAccess function of the smart contract and attaching the Ethereum EOA signature or Fabric CA certificate;

[0032] (2) The smart contract executes the following verification logic:

[0033] ① Check the institution qualifications in the digital certificate of the requesting party;

[0034] ② Check whether the on-chain permission policy matches;

[0035] ③ If patient authorization is required, trigger the OAuth2.0 authorization process of the patient-side APP;

[0036] (3) After verification, the smart contract:

[0037] ①Generate a one-time access token;

[0038] ②Transmit the encryption key to the requester through a secure channel;

[0039] The requester uses the token to download the encrypted shard from the IPFS gateway and decrypts it in the local SGX enclave.

[0040] S3. Data Audit:

[0041] (1) Recording structured logs on the blockchain, including access time, requester identity, operation type, and data usage;

[0042] (2) Provides a regulatory audit interface that supports queries based on the following conditions:

[0043] ① The patient's DID can be used to trace back all access records;

[0044] ② Implement privacy audit based on the group signature mechanism of FISCO BCOS.

[0045] Preferably, in S1, the metadata includes data hash value, data owner information, access permission policy and data classification label.

[0046] Preferably, in S1, the encrypted data fragments adopt a hybrid encryption method, including:

[0047] ①Symmetric encryption stage:

[0048] Generate an independent session key for each data shard;

[0049] Use AES-GCM mode encryption, add MAC check code to prevent tampering;

[0050] ②Asymmetric encryption stage:

[0051] Encrypt the session key using the patient's public key;

[0052] The encrypted key and shard CID are stored together in the blockchain Key-Value database.

[0053] Preferably, in S2, the permission verification of the smart contract further includes:

[0054] ① Dynamic permission scenario:

[0055] Automatically relax access to tertiary hospitals when a medical emergency is detected;

[0056] Obtain the National Health Commission's blacklist through the oracle and block access by illegal institutions in real time;

[0057] ②Multi-factor authentication: requires the requester to provide both: biometrics and physical keys.

[0058] Preferably, in S3, the blockchain adopts an improved consensus mechanism, including:

[0059] ① Medical institution nodes participate in consensus as verification nodes;

[0060] ② The regulatory agency node acts as an observation node, only recording data but not having the right to keep accounts;

[0061] ③ Use the optimized PBFT algorithm to improve the processing efficiency of medical data transactions.

[0062] Preferably, data desensitization is also included:

[0063] ① Homomorphic encryption scenario: Paillier semi-homomorphic encryption is used for laboratory numerical data, supporting direct calculation of statistical indicators on the cloud;

[0064] ② Differential privacy scenario:

[0065] Add Laplace noise to genetic data;

[0066] Automatically verify noise addition compliance via smart contracts.

[0067] Preferably, in S1, the distributed storage network adopts IPFS, and redundant coding is added when data is stored in shards to improve data availability and anti-loss capabilities.

[0068] Preferably, the data owner information includes the patient's public key or de-identified ID, and the patient signs the authorization operation using the private key to ensure that ownership cannot be denied.

[0069] Preferably, data lifecycle management is also included:

[0070] The data expiration time is set through smart contracts. After the expiration, the encrypted data shards in the distributed storage network are automatically deleted and the status records on the blockchain are updated.

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

[0072] (1) The present invention is a medical data circulation and storage method based on blockchain. The present invention significantly improves the security of medical data storage. Medical data is encrypted and stored in a distributed network, and only the hash value is uploaded to the chain, avoiding the bottleneck of blockchain storage performance. The immutability of the blockchain ensures that data operation records are traceable throughout the process, eliminating the risk of malicious tampering by internal personnel. A hybrid encryption mechanism is adopted, and the session key is encrypted by the patient's public key and uploaded to the chain. The private key is held only by the patient, making it extremely difficult to crack.

[0073] (2) The present invention is a blockchain-based medical data circulation and storage method that achieves efficient and decentralized data circulation. Data requesters verify permissions through smart contracts, and patients dynamically authorize through digital signatures. No third-party intermediaries are required, and circulation efficiency is improved by more than 60%. Zero-knowledge proof is supported to verify the qualifications of the requester, without exposing specific identity information, in line with the GDPR principle of minimizing disclosure. By standardizing data hash and metadata formats, it is compatible with medical protocols such as HL7 / FHIR, reducing the cost of connecting heterogeneous systems.

[0074] (3) The present invention is a blockchain-based medical data circulation and storage method that strengthens patient privacy control and compliance. Patients control data access rights through decentralized identities. All authorization records are on-chain and can be revoked at any time. Differential privacy technology adds noise to sensitive fields to ensure that personal identities cannot be reversely identified during scientific research and analysis. It automatically records the purpose of data use, access time, and operator, generates HIPAA / GDPR-compliant audit reports, and reduces institutional legal risks.

[0075] (4) The present invention is a blockchain-based medical data circulation and storage method that supports secure collaborative computing and federated learning. Medical institutions coordinate federated learning through smart contracts. Model training only interacts on encrypted gradient parameters. The original data is always retained locally. Homomorphic encryption is used to support cloud-based statistical analysis. The original data cannot be obtained before the results are decrypted. Data contributors are rewarded through blockchain tokens, and credit points are deducted from illegal nodes and announced publicly to promote ecological collaboration. Only light nodes and API gateways need to be deployed. Sharded PBFT consensus is used, and the medical transaction throughput can reach 2000+TPS, meeting clinical real-time needs. DETAILED DESCRIPTION

[0076] The technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the embodiments of the present invention.

[0077] Example

[0078] The present invention proposes a technical solution for a blockchain-based medical data circulation and storage method: A blockchain-based medical data circulation and storage method includes the following steps:

[0079] S1. Data storage:

[0080] (1) Split the medical data into several data fragments using a data fragmentation algorithm (based on file size or content sensitivity), with the size of each fragment not exceeding a preset threshold (e.g., 1MB);

[0081] (2) Use the national secret SM4 or AES-256 algorithm to encrypt each fragment, generate encrypted data fragments, and add a timestamp and fragment serial number;

[0082] (3) Upload the encrypted data shards to the distributed storage network (IPFS or HDFS) and obtain the unique content identifier CID;

[0083] (4) Recording metadata on the blockchain;

[0084] S2. Data Flow:

[0085] (1) The data requester submits an access request by calling the requestAccess function of the smart contract and attaching the Ethereum EOA signature or Fabric CA certificate;

[0086] (2) The smart contract executes the following verification logic:

[0087] ① Check the institution qualifications in the requester's digital certificate (embedded in the X.509 certificate extension field);

[0088] ② Check whether the on-chain permission policy matches (e.g., "allow tertiary hospitals to access imaging data after 2023");

[0089] ③ If patient authorization is required, trigger the OAuth2.0 authorization process of the patient-side APP;

[0090] (3) After verification, the smart contract:

[0091] ①Generate a one-time access token (JWT format, valid for 24 hours);

[0092] ②Transmit the encryption key (hosted in the off-chain TEE environment) to the requester through a secure channel;

[0093] The requester uses the token to download the encrypted shard from the IPFS gateway and decrypts it in the local SGX enclave.

[0094] S3. Data Audit:

[0095] (1) Recording structured logs on the blockchain, including: access time (UTC timestamp), requester identity (institution code issued by PCA), operation type (read / write / delete), and data usage (clinical / research / insurance);

[0096] (2) Provides a regulatory audit interface that supports queries based on the following conditions:

[0097] ① The patient's DID can be used to trace back all access records;

[0098] ② Implement privacy audit based on the group signature mechanism of FISCO BCOS.

[0099] Preferably, in S1, the metadata includes a data hash value (SHA-3 digest generated based on CID), data owner information (patient DID decentralized identifier), access permission policy (ABAC attribute-based access control rules based on JSON) and data classification labels (such as imaging data / genetic data / electronic medical records).

[0100] Furthermore, in S1, the encrypted data fragments adopt a hybrid encryption method, including:

[0101] ①Symmetric encryption stage:

[0102] Generate independent session keys for each data shard (via hardware true random number generator);

[0103] Use AES-GCM mode encryption, add MAC check code to prevent tampering;

[0104] ②Asymmetric encryption stage:

[0105] Encrypt the session key using the patient's public key (SM2 or RSA-2048);

[0106] The encrypted key and shard CID are stored together in the blockchain Key-Value database.

[0107] Furthermore, in S2, the permission verification of the smart contract further includes:

[0108] ① Dynamic permission scenario:

[0109] Automatically relax access to tertiary hospitals when a medical emergency is detected (e.g., triggered by an ambulance GPS signal);

[0110] Obtain the National Health Commission's blacklist through the oracle and block access by illegal institutions in real time;

[0111] ② Multi-factor authentication: The requesting party is required to provide both: biometrics (through FIDO2 authentication) and a physical key (YubiKey hardware signature).

[0112] Furthermore, in S3, the blockchain adopts an improved consensus mechanism, including:

[0113] ① Medical institution nodes participate in consensus as verification nodes;

[0114] ② The regulatory agency node acts as an observation node, only recording data but not having the right to keep accounts;

[0115] ③ Use the optimized PBFT algorithm to improve the processing efficiency of medical data transactions.

[0116] In this embodiment, nodes are layered: core consensus nodes (servers of tertiary hospitals, which must pass TLS two-way authentication) and light nodes (supervision terminals of the National Health Commission, which only synchronize block headers); batch processing optimization: medical data transactions are packaged by department (radiology department / laboratory department) and BLS signature aggregation is used to reduce network overhead.

[0117] Furthermore, data desensitization is also included:

[0118] ① Homomorphic encryption scenario: Paillier semi-homomorphic encryption is used for laboratory numerical data, supporting direct calculation of statistical indicators on the cloud;

[0119] ② Differential privacy scenario:

[0120] Add Laplace noise (ε=0.1) to the genetic data;

[0121] Automatically verify noise addition compliance via smart contracts.

[0122] Furthermore, in S1, the distributed storage network adopts IPFS, and redundant coding is added when data is stored in shards to improve data availability and anti-loss capabilities.

[0123] In this embodiment, the redundancy strategy is: (5,3) Reed-Solomon encoding and geographically distributed storage (three copies in Beijing / Shanghai / Guangzhou) are used for medical record data above level 3; hot data caching: a local IPFS gateway is configured for tertiary hospitals to automatically cache frequently accessed data.

[0124] Furthermore, the data owner information includes the patient's public key or de-identified ID, and the patient signs the authorization operation using the private key to ensure that ownership cannot be denied.

[0125] In this embodiment, during the model training phase, the contract automatically assigns training tasks to each participant (based on GPU computing power pledge proof) and ensures the credibility of gradient calculations through TEE remote authentication. Incentive mechanism: Data contributors are rewarded with ERC-20 tokens and malicious nodes are punished (by deducting on-chain reputation points).

[0126] Furthermore, it also includes data lifecycle management:

[0127] The data expiration time is set through smart contracts. After the expiration, the encrypted data shards in the distributed storage network are automatically deleted and the status records on the blockchain are updated.

[0128] In this embodiment, the smart contract automatically executes: periodically scanning the blockchain status (based on time locks), triggering the IPFS pinning service to delete expired data, and writing tombstone records to the blockchain (retaining hash evidence).

[0129] A medical data security gateway device, comprising:

[0130] Hardware module: National secret SM2 / SM3 / SM4 acceleration chip and TEE trusted execution environment (Intel SGX or Arm TrustZone);

[0131] Software modules: blockchain light node client, IPFS sharding proxy service and access control policy engine.

[0132] A cross-institutional medical data sharing system, deploying any of the above methods, includes:

[0133] Patient-side APP: Digital identity wallet based on DID;

[0134] Hospital subsystem: HIS system blockchain adapter;

[0135] Regulatory dashboard: real-time visual audit tracking interface.

[0136] 1. Taking the cross-hospital data retrieval scenario of the emergency department as an example

[0137] 1. Data preparation stage:

[0138] Patient A completes a CT scan in the emergency department of XX Hospital, generating a DICOM file (size 256MB)

[0139] System execution:

[0140]

[0141]

[0142] 2. Emergency access process:

[0143] Patient A is transferred to YY Hospital, and the attending doctor initiates a review request:

[0144]

[0145] 3. Data decryption:

[0146] YY Hospital Terminal is completed within the SGX enclave:

[0147]

[0148] 4. Audit Trail:

[0149] The blockchain generation log contains:

[0150]

[0151] Multi-center scientific research data analysis as an example

[0152] 1. Data preparation: Five tertiary hospitals uploaded desensitized genetic data of cancer patients:

[0153] 2. Federated Learning Implementation:

[0154] Smart contract coordination process:

[0155]

[0156] Each hospital uses TEE remote authentication during local training:

[0157]

[0158] 3. Data lifecycle management:

[0159] Smart contracts automatically perform cleanup:

[0160]

[0161]

[0162] 3. Taking the National Health Commission’s Supervision and Audit as an Example

[0163] 1. Privacy protection query:

[0164] Supervisors investigate all data access records of Patient B:

[0165] --Blockchain audit SQL (pseudocode)

[0166] SELECT * FROM access_logs WHERE patient_did = 'did:ethr:0xpatientB' GROUP BY accessor HAVING COUNT (*) > 5 -- Abnormal high-frequency access detection 2. Group signature verification:

[0167] Using FISCO BCOS's group signature scheme:

[0168]

[0169] 3. Compliance Check:

[0170] Smart contracts automatically verify noise addition:

[0171]

[0172]

[0173] The effect data of the embodiment are shown in Table 1 below:

[0174]

[0175] Table 1

[0176] Note: During specific implementation, the encryption algorithm parameters (such as changing SM4 to AES-256) and the number of consensus nodes (it is recommended to have no less than 7 medical verification nodes) can be adjusted according to the IT infrastructure of the medical institution.

[0177] The present invention is a medical data circulation and storage method based on blockchain. The present invention significantly improves the security of medical data storage. Medical data is stored in a distributed network after being encrypted in fragments, and only the hash value is uploaded to the chain, avoiding the bottleneck of blockchain storage performance. The immutability of blockchain ensures that data operation records are traceable throughout the process, eliminating the risk of malicious tampering by internal personnel. A hybrid encryption mechanism is adopted, and the session key is encrypted by the patient's public key and uploaded to the chain. The private key is only held by the patient, and the cracking difficulty is extremely high; efficient and decentralized data circulation is achieved, the data requester verifies the authority through the smart contract, and the patient dynamically authorizes through digital signatures, without the need for a third-party intermediary, and the circulation efficiency is improved by more than 60%. Zero-knowledge proof is supported to verify the qualifications of the requester, without exposing specific identity information, in line with the GDPR principle of minimizing disclosure, and through standardized data hash and metadata formats, it is compatible with medical protocols such as HL7 / FHIR, reducing the cost of connecting heterogeneous systems; strengthening patient Patient privacy control and compliance: patients control data access rights through decentralized identities, all authorization records are on-chain and can be revoked at any time, differential privacy technology adds noise to sensitive fields to ensure that personal identities cannot be reversely identified during scientific research and analysis, automatically records the purpose of data use, access time and operator, generates HIPAA / GDPR-compliant audit reports, and reduces institutional legal risks; supports secure collaborative computing and federated learning: medical institutions coordinate federated learning through smart contracts, model training only interacts on encrypted gradient parameters, and the original data is always retained locally. Homomorphic encryption is used to support cloud-based statistical analysis, and the original data cannot be obtained before the results are decrypted. Data contributors are rewarded through blockchain tokens, and credit points are deducted from illegal nodes and announced publicly to promote ecological collaboration. Only light nodes and API gateways need to be deployed, and sharded PBFT consensus is used. The medical transaction throughput can reach 2000+TPS, meeting clinical real-time needs.

[0178] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A medical data circulation and storage method based on blockchain, characterized in that: The following steps are involved: S1. Data storage: (1) Divide the medical data into several data fragments using a data fragmentation algorithm, with the size of each fragment not exceeding a preset threshold; (2) Use the national secret SM4 or AES-256 algorithm to encrypt each fragment, generate encrypted data fragments, and add a timestamp and fragment serial number; (3) Upload the encrypted data fragments to the distributed storage network and obtain the unique content identifier CID; (4) Recording metadata on the blockchain; S2. Data Flow: (1) The data requester submits an access request by calling the requestAccess function of the smart contract and attaching the Ethereum EOA signature or Fabric CA certificate; (2) The smart contract executes the following verification logic: ① Check the institution qualifications in the digital certificate of the requesting party; ② Check whether the on-chain permission policy matches; ③ If patient authorization is required, trigger the OAuth2.0 authorization process of the patient-side APP; (3) After verification, the smart contract: ①Generate a one-time access token; ②Transmit the encryption key to the requester through a secure channel; The requester uses the token to download the encrypted shard from the IPFS gateway and decrypts it in the local SGX enclave. S3. Data Audit: (1) Recording structured logs on the blockchain, including access time, requester identity, operation type, and data usage; (2) Provides a regulatory audit interface that supports queries based on the following conditions: ① The patient's DID can be used to trace back all access records; ② Implement privacy audit based on the group signature mechanism of FISCO BCOS.

2. The blockchain-based medical data circulation and storage method according to claim 1, characterized in that: In S1, the metadata includes data hash value, data owner information, access permission policy and data classification label.

3. The blockchain-based medical data circulation and storage method according to claim 1, characterized in that: In S1, the encrypted data fragments adopt a hybrid encryption method, including: ①Symmetric encryption stage: Generate an independent session key for each data shard; Use AES-GCM mode encryption, add MAC check code to prevent tampering; ②Asymmetric encryption stage: Encrypt the session key using the patient's public key; The encrypted key and shard CID are stored together in the blockchain Key-Value database.

4. The blockchain-based medical data circulation and storage method according to claim 1, characterized in that: In S2, the permission verification of the smart contract further includes: ① Dynamic permission scenario: Automatically relax access to tertiary hospitals when a medical emergency is detected; Obtain the National Health Commission's blacklist through the oracle and block access by illegal institutions in real time; ②Multi-factor authentication: requires the requester to provide both: biometrics and physical keys.

5. The blockchain-based medical data circulation and storage method according to claim 1, characterized in that: In S3, the blockchain adopts an improved consensus mechanism, including: ① Medical institution nodes participate in consensus as verification nodes; ② The regulatory agency node acts as an observation node, only recording data but not having the right to keep accounts; ③ Use the optimized PBFT algorithm to improve the processing efficiency of medical data transactions.

6. The blockchain-based medical data circulation and storage method according to claim 1, characterized in that: Also includes data desensitization: ① Homomorphic encryption scenario: Paillier semi-homomorphic encryption is used for laboratory numerical data, supporting direct calculation of statistical indicators on the cloud; ② Differential privacy scenario: Add Laplace noise to genetic data; Automatically verify noise addition compliance via smart contracts.

7. The blockchain-based medical data circulation and storage method according to claim 1, characterized in that: In S1, the distributed storage network adopts IPFS, and redundant coding is added when data is stored in shards to improve data availability and anti-loss capabilities.

8. The blockchain-based medical data circulation and storage method according to claim 2, characterized in that: The data owner information includes the patient's public key or de-identified ID, and the patient signs the authorization operation with the private key to ensure that ownership cannot be denied.

9. The blockchain-based medical data circulation and storage method according to claim 1, characterized in that: Also includes data lifecycle management: The data expiration time is set through smart contracts. After the expiration, the encrypted data shards in the distributed storage network are automatically deleted and the status records on the blockchain are updated.

Images