A blockchain-based medical data management method, system, device and medium

Abstract

A blockchain-based medical data management method, system, device and medium are provided, and relate to the field of information management. In the method, medical data is acquired, the content attribute and context information of the medical data are analyzed by a first smart contract on a blockchain to generate a first sensitivity level identifier; based on the first sensitivity level identifier, the medical data is differentially encrypted by a second smart contract on the blockchain, and verification information is generated; the differentially encrypted medical data is blocked, and the verification information is stored in the blockchain after being jointly constructed into a data structure; in response to receiving an access request, the authority voucher in the access request and the type of the access request are verified by a third smart contract on the blockchain to generate an access authorization voucher; and based on the access authorization voucher, target medical data corresponding to the access request is output. The technical solution provided by the present application realizes the whole life cycle security control of medical data from collection, storage to sharing.

Description

Technical Field

[0001] This application relates to the technical field of information management, specifically to a blockchain-based medical data management method, system, device, and medium. Background Technology

[0002] As a core representative of distributed ledger technology, blockchain technology has undergone a leapfrog development in recent years, evolving from the underlying architecture of cryptocurrencies to an infrastructure for applications across multiple industries. Its decentralized, immutable, transparent, and traceable characteristics provide a new paradigm for solving data trust issues. In the medical field, blockchain technology is gradually being applied to scenarios such as electronic medical record sharing, drug traceability, and clinical trial data management. Through smart contracts, it enables automated rule execution, providing technical support for breaking down traditional medical data silos and improving the efficiency of cross-institutional collaboration.

[0003] Existing technologies often employ a combination of static encryption strategies and coarse-grained access control: medical data is typically stored in centralized databases or blockchain nodes with uniform encryption strength, and access control relies on preset role-based access control models. This lacks fine-grained adaptation to the dynamic sensitivity of data content and usage scenarios. Static encryption cannot match the dynamic risk characteristics of medical data (such as the need for upgraded protection of infectious disease data during an epidemic), leading to over-encryption affecting data availability or insufficient encryption causing leakage risks. Summary of the Invention

[0004] To achieve secure management of medical data throughout its entire lifecycle, from collection and storage to sharing, this application provides a blockchain-based medical data management method, system, device, and medium.

[0005] The first aspect of this application provides a blockchain-based method for managing medical data:

[0006] Acquire medical data, analyze the content attributes and contextual information of the medical data through the first smart contract on the blockchain, and generate a first sensitivity level identifier;

[0007] Based on the first sensitivity level identifier, the medical data is differentially encrypted through a second smart contract on the blockchain, and verification information is generated.

[0008] The differentiated encrypted medical data is divided into blocks, and after being combined with the verification information to construct a data structure, it is stored in the blockchain;

[0009] In response to receiving an access request, the third smart contract on the blockchain verifies the permission credentials in the access request and the type of the access request, and generates an access authorization credential.

[0010] Based on the access authorization credentials, the target medical data corresponding to the access request is output.

[0011] By adopting the above technical solution, firstly, based on a dynamic content-aware sensitivity grading mechanism, a first smart contract is used to perform multi-dimensional feature analysis on medical data and automatically label its sensitivity level, providing a precise decision-making basis for differentiated encryption strategies. Secondly, a second smart contract establishes an encryption granularity control system matched to the sensitivity level, optimizing the processing efficiency of non-sensitive data while ensuring strong protection of core privacy data and generating verifiable integrity credentials. A data structuring design combining block storage and chain-based evidence storage is adopted to achieve rapid retrieval and compliant access while ensuring atomic storage of medical data. Finally, a third smart contract constructs a multi-dimensional permission verification engine, combining requester identity authentication, operation type auditing, and dynamic authorization mechanisms to form a tamper-proof and traceable access control closed loop under the support of the blockchain's immutability. This technical solution, through dynamic sensitivity grading and scenario-based encryption adaptation mechanisms, effectively solves the binary dilemma of traditional static encryption schemes in medical data protection—either over-encryption sacrificing usability or insufficient encryption leading to leakage—achieving a precise balance between data security strength and business needs. Optionally, the acquisition of medical data, and the analysis of the content attributes and contextual information of the medical data through a first smart contract on the blockchain to generate a first sensitivity level identifier, includes:

[0012] The structured metadata tags of the medical data are parsed using the first smart contract to obtain the data type classification results;

[0013] The real-time contextual features associated with the medical data are obtained through the first smart contract to obtain dynamic scene evaluation results;

[0014] Based on the data type classification results and the dynamic scene evaluation results, the first sensitivity level identifier is generated through a preset sensitivity mapping rule.

[0015] By adopting the above technical solution, the structured metadata tags of medical data are first parsed to extract data type features, including patient information, diagnosis category, and image modality, and then classified and archived. Simultaneously, real-time contextual features associated with the medical data are obtained through blockchain nodes, such as data generation time, access terminal type, and institutional cooperation level, forming a multi-dimensional risk assessment matrix. Finally, based on a preset sensitivity mapping rule engine, the structured classification results and dynamic scenario assessment results are weighted and fused to generate a first sensitivity level identifier covering both the inherent attributes of the data and its usage scenario. This provides a quantifiable risk decision-making basis for subsequent differentiated encryption strategies, achieving refined management of medical data privacy protection.

[0016] Optionally, the step of differentially encrypting the medical data based on the first sensitivity level identifier through a second smart contract on the blockchain and generating verification information includes:

[0017] The target encryption policy is matched from a predefined encryption policy library based on the first sensitivity level identifier. The target encryption policy includes an encryption algorithm, key length, and access control policy.

[0018] The medical data is encrypted based on the target encryption strategy.

[0019] The verification information is generated based on the encrypted medical data.

[0020] By adopting the above technical solution, based on the first sensitivity level identifier, a differentiated combination of encryption algorithms, key strengths, and access rules is intelligently matched from a predefined encryption policy library. For example, AES-256 encryption combined with attribute-based access control (ABAC) is used for highly sensitive genetic data, while AES-128 encryption combined with role-based access control is used for routine medical record data. Through a dynamic policy adaptation mechanism, while ensuring strong protection of core privacy data, the processing efficiency of low-risk data is optimized. Finally, verification information containing encryption parameter fingerprints and policy version numbers is generated, forming a verifiable proof of encryption integrity. This ensures a balance of confidentiality, integrity, and availability throughout the entire lifecycle of medical data, and builds a flexible and controllable encryption protection system for cross-institutional data sharing.

[0021] Optionally, the step of dividing the differentiated encrypted medical data into blocks and storing it in the blockchain after constructing a data structure together with the verification information includes:

[0022] The data block size is determined from the predefined fragmentation strategy library based on the first sensitivity level identifier;

[0023] The differentially encrypted medical data is divided into continuous data blocks based on the data block size;

[0024] Calculate the corresponding cryptographic hash value for each data block;

[0025] A hash tree is constructed based on all the data blocks and their corresponding cryptographic hash values, and the verification information is associated with non-leaf nodes.

[0026] The hash tree is stored in the transaction data field of the blockchain.

[0027] By adopting the above technical solution, firstly, a data sharding strategy is dynamically adapted based on sensitivity levels. High-risk data is sharded with fine-grained blocks to strengthen access control, while regular data is stored in large blocks to optimize efficiency. Secondly, a verifiable data structure is constructed through a cryptographic hash chain. Each data block generates a unique digital fingerprint, which is aggregated layer by layer to form a hash tree. Encrypted verification information is anchored to non-leaf nodes to achieve on-chain evidence storage for integrity proof. Finally, the entire hash tree is stored in the blockchain as transaction data. While ensuring the atomicity of medical data storage, a complete verification link from data fragments to the global state is established. This ensures traceability of single-point tampering and supports rapid verification of massive amounts of medical data, providing a storage architecture for blockchain medical data evidence storage that combines scalability and security.

[0028] Optionally, in response to receiving an access request, verifying the permission credentials in the access request and the type of the access request through a third smart contract on the blockchain, and generating an access authorization credential, includes:

[0029] Parse the access request to obtain the target medical data identifier, role level attribute, and data usage declaration;

[0030] Retrieve the second sensitivity level identifier bound to the target medical data identifier from the preset blockchain state database;

[0031] Determine whether the character level attribute meets the minimum permission threshold required by the second sensitivity level identifier;

[0032] If the role level attribute meets the minimum permission threshold, the operation type of the access request is matched with the data purpose declaration through a preset compliance rule base to obtain a matching result;

[0033] Based on the matching results, an access authorization credential is generated.

[0034] By employing the aforementioned technical solution to parse the data identifiers, role attributes, and purpose declarations in access requests, and dynamically matching them with the sensitivity levels of blockchain-based evidence storage, automatic attribute-based permission threshold verification is achieved. A policy engine performs semantic-level matching between operation types and data purposes, such as restricting the scope of access operations based on data type, ensuring data usage complies with industry standards. Finally, a digital authorization credential containing time limits, purpose constraints, and operation logs is generated, forming a closed-loop process of "request-verification-authorization-audit." This solution deeply integrates role-based access control, business rule execution, and the immutability of blockchain, ensuring secure sharing of medical data while achieving automated decision-making for fine-grained access control, significantly improving cross-institutional collaboration efficiency and data utilization standardization.

[0035] Optionally, the step of outputting the target medical data corresponding to the access request based on the access authorization credential includes:

[0036] Extract the target data index and decryption key identifier from the access authorization credential;

[0037] Based on the target data index, locate the corresponding set of encrypted data blocks from the blockchain;

[0038] The decryption key is obtained from the preset distributed key management database based on the decryption key identifier;

[0039] The encrypted data block set is decrypted and reassembled based on the decryption key to obtain the original medical data;

[0040] Based on the data type requirements in the access request, extract the target field from the original medical data;

[0041] The target medical data is obtained by de-identifying the target field using a preset privacy computing engine.

[0042] By adopting the above technical solution, the encrypted data blocks stored on the blockchain are accurately located based on the intelligent index in the access authorization credential. Combined with a distributed key management system, on-demand key access is achieved, reducing the risk of key leakage while ensuring data confidentiality. Through fine-grained data reconstruction technology, only necessary fields are decrypted and unauthorized content is filtered out, minimizing the data exposure surface. Finally, a privacy computing engine is used to dynamically de-identify target fields, such as implementing differential privacy protection for identifying information like names and ID numbers, eliminating individual identifiability while maintaining data usability. This solution constructs a full-process protection chain from data extraction to secure output, ensuring the accurate use of medical data within the authorized scope and significantly improving the privacy protection strength and utilization efficiency of cross-institutional data collaboration through a "data not stored on the ground, use and then destroyed" control mechanism.

[0043] Optionally, the method further includes:

[0044] Data access event streams are obtained through the fourth smart contract on the blockchain;

[0045] The data access event stream is analyzed based on a preset anomaly detection model;

[0046] When the data access event stream is in an abnormal access mode, a permission revocation instruction is generated;

[0047] Based on the permission revocation instruction, the corresponding access authorization certificate is frozen through the third smart contract.

[0048] By adopting the above technical solution, full access behavior logs are obtained based on real-time capture technology. Intelligent analysis algorithms are used to analyze dimensions such as operation frequency, data flow, and permission overreach in real time, accurately identifying risk patterns including high-frequency probing attacks, abnormal access outside working hours, and abnormal cross-domain data flow. When a potential threat is detected, the permission revocation process is automatically triggered, and the associated authorization certificate is frozen in real time through a third-party smart contract, forming a closed-loop control of "monitoring-identification-disposal". This mechanism upgrades static permission management to intelligent risk-driven proactive protection. Combined with the tamper-proof event storage capability of blockchain, it ensures that abnormal behavior is traceable and shortens the data leakage risk window to one-tenth of the traditional solution through minute-level response speed, significantly improving the real-time defense capability and system risk resistance level in the medical data sharing environment.

[0049] A second aspect of this application provides a blockchain-based medical data management system, specifically comprising:

[0050] The data classification module is used to acquire medical data, analyze the content attributes and context information of the medical data through the first smart contract on the blockchain, and generate a first sensitivity level identifier.

[0051] An encryption module is used to perform differentiated encryption on the medical data based on the first sensitivity level identifier through a second smart contract on the blockchain, and generate verification information;

[0052] The block storage module is used to divide the differentiated encrypted medical data into blocks, and then store them into the blockchain after constructing a data structure together with the verification information.

[0053] The authorization query module is used to respond to an access request by verifying the permission credentials in the access request and the type of the access request through a third smart contract on the blockchain, and to generate an access authorization credential.

[0054] The data output module is used to output the target medical data corresponding to the access request based on the access authorization credential.

[0055] A third aspect of this application provides an electronic device including a processor, a memory, a user interface, and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any of the foregoing.

[0056] A fourth aspect of this application provides a computer-readable storage medium storing instructions that, when executed, perform the method described in any of the preceding descriptions.

[0057] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0058] Based on a dynamic sensitivity grading mechanism, this solution integrates data content characteristics and usage scenarios to generate quantitative risk identifiers, providing a basis for differentiated encryption decisions. It employs intelligent encryption strategy matching technology to optimize the processing efficiency of non-sensitive data while ensuring the security of core privacy data. Through block storage and chained evidence storage design, combined with a sensitivity-dynamically adapted sharding strategy, it constructs a traceable data structure, supporting rapid verification of massive amounts of medical data. A multi-dimensional permission verification system is created, combining identity authentication and semantic-level policy matching to form a closed loop of tamper-proof access control. A real-time risk prevention and control mechanism is introduced, automatically triggering permission revocation based on intelligent behavior analysis, improving response speed to the minute level. This solution significantly improves cross-institutional collaboration efficiency while ensuring the privacy and security of medical data, building a security system covering the entire data lifecycle for the healthcare field. Attached Figure Description

[0059] Figure 1 This is a schematic diagram of the system architecture of an embodiment of a blockchain-based medical data management method or system applying this application;

[0060] Figure 2 This is a flowchart illustrating a blockchain-based medical data management method disclosed in an embodiment of this application.

[0061] Figure 3 This is a schematic diagram of a blockchain-based medical data management system disclosed in an embodiment of this application;

[0062] Figure 4 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application.

[0063] Explanation of reference numerals in the attached diagram: 301, Data hierarchical module; 302, Encryption module; 303, Block storage module; 304, Query authorization module; 305, Data output module; 306, Risk control module; 401, Processor; 402, Communication bus; 403, User interface; 404, Network interface; 405, Memory. Detailed Implementation

[0064] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0065] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0066] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0067] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0068] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as model training applications, video recognition applications, web browser applications, social platform software, etc.

[0069] Terminal devices 101, 102, and 103 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP4 (Moving Picture Experts Group Audio Layer IV) players, laptops, and desktop computers, etc. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices. They can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services) or as a single software program or software module. No specific limitations are imposed here.

[0070] This embodiment discloses a blockchain-based medical data management method. Figure 2 This is a flowchart illustrating a blockchain-based medical data management method disclosed in an embodiment of this application, as shown below. Figure 2 As shown, the method includes the following steps:

[0071] S201. Obtain medical data, analyze the content attributes and context information of the medical data through the first smart contract on the blockchain, and generate a first sensitivity level identifier.

[0072] Specifically, the server acquires medical data in real time through the standardized API (Application Programming Interface) of the Hospital Information System (HIS). This data includes structured data (such as HL7 (Health Level Seven) electronic medical records and DICOM (Digital Imaging and Communications in Medicine) image metadata) and unstructured data (such as diagnostic report text converted by OCR (Optical Character Recognition) technology). The first smart contract on the blockchain then performs dynamic sensitivity grading: first, it calls the structured metadata parsing engine to extract HL7 FHIR (Fast Healthcare Interoperability Resources) standard tags, and matches the data type classification results according to a preset classification rule base; simultaneously, it collects real-time context information (including the IP address of the access device). The algorithm uses a combination of data type classification results and dynamic scoring inputs to a predefined sensitivity matrix based on sensitivity mapping rules. This matrix generates a first sensitivity level identifier containing a level value and a timestamp of validity (e.g., {level:3, expire_time:1730419200}). This first sensitivity level identifier is then written into the blockchain transaction record to provide a basis for subsequent differentiated encryption.

[0073] Optionally, the acquisition of medical data, and the analysis of the content attributes and contextual information of the medical data through a first smart contract on the blockchain to generate a first sensitivity level identifier, includes:

[0074] The structured metadata tags of the medical data are parsed using the first smart contract to obtain the data type classification results;

[0075] The real-time contextual features associated with the medical data are obtained through the first smart contract to obtain dynamic scene evaluation results;

[0076] Based on the data type classification results and the dynamic scene evaluation results, the first sensitivity level identifier is generated through a preset sensitivity mapping rule.

[0077] Specifically, after inputting medical data, the smart contract calls the built-in metadata parsing engine to perform tag extraction. First, the data stream undergoes syntax validation and standardization preprocessing (e.g., converting DICOM image header files into standard DICOM tag sets). Then, key structured fields (e.g., the / DiagnosticReport / code node) are located using XPath (XML path language) or regular expressions are used to match predefined HL7 data element delimiters. The extracted raw tags are semantically standardized using a mapping rule base (e.g., mapping DX_RPT to a diagnostic report). Finally, based on preset tree-like classification rules (the root node is "medical data type", and the child nodes contain 12 branches such as test results, medication records, and genetic data, with each branch having a sensitivity weight), a machine-readable data type classification result is output. This result, along with the digital fingerprint of the raw data, is written to the blockchain temporary storage area for subsequent analysis and retrieval.

[0078] Furthermore, when medical data is received, the smart contract triggers an event listener to capture associated real-time signals—including obtaining the IP physical location coordinates of the data access device (such as GPS location points in the emergency room) by calling the hospital's geofencing system via the SDK (Software Development Kit), and generating a location risk coefficient by comparing it with a preset sensitive area database (such as the coordinate range of the operating room / infectious disease area); connecting to the epidemic API interface released by authoritative institutions (such as real-time early warning data from the National Center for Disease Control and Prevention), and determining whether the current situation is a time-sensitive scenario such as an infectious disease outbreak based on the blockchain timestamp, generating a time risk factor; scanning the associated operation log chain (tracing abnormal behavior of the same patient's data being exported in batches within 10 minutes through transaction hashes), and generating a behavioral risk index by combining it with a preset rule base (such as a single user high-frequency access threshold of 5 times / minute); and then executing a dynamic weighted algorithm. S_base is the basic sensitivity (from the data type classification result, value range [1,5]), L is the location risk coefficient (obtained through the IP geofencing system, emergency room = 0.2, infectious disease area = 0.4, general ward = 0.1), T is the time risk factor (calling the CDC API, outbreak period = 0.3, normal period = 0), and B is the behavioral risk index (analyzing the operation log chain, batch export behavior = 0.25, single access = 0). The final output is a structured dynamic scenario evaluation result.

[0079] Furthermore, the input data is first standardized, followed by multi-dimensional matching—using the basic sensitivity level as the vertical benchmark, the comprehensive risk score as the horizontal variable, and specific medical data types as the depth condition, determined according to the following core rules: when the risk score is within the normal range, the basic level is directly adopted; if the risk score exceeds the threshold, an upgrade mechanism is triggered (adding a risk increment value to the basic level, up to a maximum of five levels); for special data types such as infectious diseases, when the risk score reaches the critical value, it is forcibly upgraded to the highest level; at the same time, the principle that the sensitivity of medical data cannot be downgraded is set to ensure security. The system dynamically sets the validity period according to the data type: ordinary data has a default validity period of 30 days, while infectious disease data is synchronized with the national disease control early warning period. Finally, a first sensitivity level identifier containing the final sensitivity level and the validity expiration time is generated, and the encrypted verification fingerprint of this identifier is written to the blockchain event log for full-chain auditing and tracing.

[0080] S202. Based on the first sensitivity level identifier, the medical data is differentially encrypted through the second smart contract on the blockchain, and verification information is generated;

[0081] Specifically, the second smart contract deployed on the blockchain node queries the pre-configured encryption policy matrix based on the first sensitivity level identifier. This matrix is ​​defined in the form of a level-policy mapping table (e.g., L5 corresponds to AES-256-GCM algorithm + 4096-bit RSA key + dynamic masking policy, and L1 corresponds to AES-128-CBC algorithm + 2048-bit key + hash on-chain policy). The contract selects the encryption algorithm, key specifications, and access control rule combination that matches the sensitivity level through a smart matching engine, and calls the encryption service interface to perform differentiated encryption on the medical data: fine-grained block encryption is used for high-sensitivity data (e.g., cutting DICOM image sequences according to patient dimensions), and whole-file encryption is used for low-sensitivity data; a meta-data packet containing algorithm identifier, key version, and policy hash value is generated simultaneously. After encryption, the contract uses the blockchain private key to jointly sign the original data fingerprint and encryption parameters, generating verification information containing policy compliance proof. Finally, the encrypted data is stored in a distributed storage system, and the storage address, signature digest, and verification information pointer are recorded in the blockchain transaction, forming a full-link evidence of the encryption operation.

[0082] Optionally, the step of differentially encrypting the medical data based on the first sensitivity level identifier through a second smart contract on the blockchain and generating verification information includes:

[0083] The target encryption policy is matched from a predefined encryption policy library based on the first sensitivity level identifier. The target encryption policy includes an encryption algorithm, key length, and access control policy.

[0084] The medical data is encrypted based on the target encryption strategy.

[0085] The verification information is generated based on the encrypted medical data.

[0086] Specifically, the second smart contract deployed on the blockchain node contains a pre-defined mapping table between sensitivity levels and encryption policies. This table is stored using a multi-dimensional decision tree structure. When a first sensitivity level identifier is received, the contract directly locates the corresponding policy entry using a hash index algorithm. For example, an L4-level policy is configured with the AES-256-GCM algorithm, a 3072-bit RSA key (asymmetric encryption algorithm key), and a combination of role-based access control and dynamic data masking. The second smart contract further parses the policy parameters, triggering a compliance check engine to verify the policy's compatibility with current regulatory requirements (such as GDPR and HIPAA), generating a policy matching credential containing the policy version number, effective timestamp, and compliance marker, providing a verifiable parameter benchmark for subsequent encryption operations.

[0087] Furthermore, the second smart contract automatically calls the encryption service interface according to the target encryption strategy, loads a pre-built encryption algorithm (such as AES-256-GCM) through a dynamic link library, and combines it with a temporary session key generated by the blockchain key management system. This key is generated using the HKDF key derivation function based on sensitivity identifiers, and the salt value includes data type hashes and scenario risk factors to ensure the independence and security of the key. For structured data (such as electronic medical records), the contract performs encryption at the field level and embeds access control lists; for unstructured data (such as medical images), it performs block encryption according to preset block division rules (such as DICOM files being cut by image sequence), and synchronously generates meta-data packets containing block indexes and encryption algorithm identifiers. During the encryption process, the contract monitors resource consumption (such as CPU utilization and encryption duration) in real time. If the threshold is exceeded, a degradation strategy is triggered (such as switching to a lightweight algorithm) to ensure that the encryption operation is completed efficiently under the resource constraints of the blockchain network.

[0088] Furthermore, after encryption, the second smart contract uses the node's private key to perform ED25519 signing on the original data fingerprint (SHA-3-512 hash) and the encryption parameter set (algorithm version, key ID, policy hash), generating verification information that includes a timestamp, compliance statement, and policy traceability chain. This verification information is encapsulated in JSON-LD (JSON for Linking Data) format and includes encryption operation audit logs (such as encryption start / end time, execution node ID), policy compliance proofs (such as mapping table version hash, regulatory clause references), and data integrity check values ​​(such as Merkle root hash). Finally, the second smart contract stores the encrypted data in a distributed storage system and records the storage address, signature digest, and verification information pointer in the blockchain transaction, forming a full-link evidence storage of "data-policy-operation," supporting subsequent third-party audits or dispute evidence collection.

[0089] S203. Divide the differentiated encrypted medical data into blocks, and store it in the blockchain after constructing a data structure together with the verification information;

[0090] Specifically, based on data type (e.g., DICOM images use sequence-level sharding, and electronic medical records use field-level sharding) and preset storage optimization strategies (e.g., a maximum of 256KB per block), a sharding algorithm is invoked to generate a set of data blocks with sequence identifiers. Each data block is appended with a metadata header (including block index, raw data hash, and encryption algorithm identifier). Subsequently, the node encapsulates the data block set and verification information (including encryption strategy hash, node signature, and timestamp) into a structured data packet, defines the data model using JSON-LD format, and calculates a unique identifier for the data packet using a CID (Content Identifier) ​​generation algorithm. Next, the node invokes the IPFS (InterPlanetary File System) distributed storage interface to upload data blocks in parallel to network nodes and obtain the CID list for each block. Simultaneously, it submits the CID of the structured data packet and the verification message digest (SHA-3-512 hash) to the blockchain smart contract. When the contract executes the notarization operation, it writes metadata (storage address mapping table, data packet CID, policy traceability pointer) into the distributed ledger in the form of transactions and establishes block-level integrity proofs using a Merkle tree (a type of hash binary tree) structure. Ultimately, the storage credentials recorded in the blockchain transaction (including the root CID and transaction hash) are logically bound to the block data stored in the IPFS network. This achieves fine-grained distributed storage of medical data while ensuring the data source is trustworthy and the operation is traceable through the immutability of the blockchain. It also supports authorized nodes in reconstructing data blocks using CIDs and verifying the verification information, completing an end-to-end data security notarization loop.

[0091] Optionally, the step of dividing the differentiated encrypted medical data into blocks and storing it in the blockchain after constructing a data structure together with the verification information includes:

[0092] The data block size is determined from the predefined fragmentation strategy library based on the first sensitivity level identifier;

[0093] The differentially encrypted medical data is divided into continuous data blocks based on the data block size;

[0094] Calculate the corresponding cryptographic hash value for each data block;

[0095] A hash tree is constructed based on all the data blocks and their corresponding cryptographic hash values, and the verification information is associated with non-leaf nodes.

[0096] The hash tree is stored in the transaction data field of the blockchain.

[0097] Specifically, during the data chunking stage, the system first retrieves the configuration parameters associated with the first sensitivity level identifier from a predefined chunking strategy library. This strategy library uses a key-value pair storage structure, with the sensitivity level (e.g., L1-L5) as the key and the corresponding value containing the recommended data block size (e.g., 256KB, 512KB, etc.) and the chunking algorithm identifier. For example, when the sensitivity level is L4, the strategy library returns a "dynamic chunking strategy," requiring structured data to be cut into fixed 256KB blocks, and unstructured data (e.g., medical images) to use intelligent chunking based on DICOM sequences, ensuring that no single data block crosses the image sequence boundary. The chunking engine calls the streaming processing interface according to the strategy parameters, achieving lossless data chunking through a circular buffer, automatically padding zero values ​​for data that is not a complete block at the end and recording the actual effective length, generating a set of continuous data blocks with sequence identifiers.

[0098] Furthermore, during the hash calculation phase, the system generates a unique cryptographic fingerprint for each block. A hierarchical hash architecture is employed: first, the SHA-3-512 algorithm is used to calculate the digest value of each original data block, generating a 256-bit basic hash; then, the basic hash is subjected to a BLAKE2b-256 secondary hash to obtain a composite hash value that combines collision resistance and computational efficiency. The hash calculation module integrates a salt obfuscation mechanism, appending a dynamic salt value containing a sensitivity identifier and block sequence number before the input data to ensure that the same content generates different hashes in different contexts. The calculation result is stored in the form of a triple of "hash value + salt value + original data length," providing the basic building blocks for subsequent hash tree construction.

[0099] Furthermore, the system employs a bottom-up binary tree construction algorithm when constructing the Merkle Tree. First, the data block hashes are used as leaf nodes, arranged in block order. Then, the parent node hash is calculated layer by layer; the value of each parent node is the result of concatenating the hashes of its two child nodes and calculating using SHA-3-512. When the number of data blocks is odd, the last node is copied and paired. During the construction of non-leaf nodes, the system serializes the verification information (including the encryption policy hash, node signature, and timestamp), encodes it using Base64, and embeds it into the parent node hash calculation process. Specifically, the verification information and child node hashes are concatenated and used as input parameters to the hash function, achieving a deep binding between the verification information and the data structure. The final generated Merkle tree root hash serves as a global identifier for data integrity.

[0100] Furthermore, during the blockchain notarization phase, the system serializes the Merkle tree structure into a JSON-formatted data packet, containing key metadata such as the root hash, tree height, and node path proof. A standard transaction body is generated using the blockchain transaction builder, and the data packet is stored in the transaction's input field. Simultaneously, the hexadecimal representation of the root hash is written into the transaction data's witness field for double anchoring. The notarization engine calls the smart contract interface; upon contract execution, after verifying the transaction signature's legality, the Merkle tree metadata is associated with the verification message digest and stored in the distributed state database, establishing a mapping between the transaction hash and the physical storage address. Finally, the blockchain network writes the transaction into the immutable ledger using a consensus algorithm, forming a complete evidence chain of "data block-hash tree-transaction notarization."

[0101] S204. In response to receiving an access request, verify the permission credentials in the access request and the type of the access request through a third smart contract on the blockchain, and generate an access authorization credential.

[0102] Specifically, when a data requester initiates an access request (including a digital signature certificate, role declaration, and operation type declaration), the third smart contract executes an on-chain verification process: First, it parses the permission credentials in the request—including verifying the authenticity of the requester's digital signature through Public Key Infrastructure (PKI) and decoding its attribute certificate (including institution code, role level, scope of practice, etc.); simultaneously, it extracts the request type (such as data reading, batch export, or scientific research analysis). The contract then performs a triple verification: 1) retrieving the second sensitivity level identifier (e.g., level 5) bound to the target medical data from the blockchain state database; 2) comparing whether the requester's role level meets the minimum permission threshold for that sensitivity requirement (e.g., genetic data requires chief physician permissions); 3) verifying the legality of the request type and declared purpose through a pre-set compliance rule base (e.g., the medical section of the Personal Information Protection Law) (e.g., requests for research purposes cannot be used for clinical diagnosis). If all verifications pass, an access authorization credential with an expiration time (default 2 hours) and operation scope restrictions is generated. This credential is signed by the contract and returned to the requester, and written to the blockchain event log for auditing and tracking.

[0103] Optionally, in response to receiving an access request, verifying the permission credentials in the access request and the type of the access request through a third smart contract on the blockchain, and generating an access authorization credential, includes:

[0104] Parse the access request to obtain the target medical data identifier, role level attribute, and data usage declaration;

[0105] Retrieve the second sensitivity level identifier bound to the target medical data identifier from the preset blockchain state database;

[0106] Determine whether the character level attribute meets the minimum permission threshold required by the second sensitivity level identifier;

[0107] If the role level attribute meets the minimum permission threshold, the operation type of the access request is matched with the data purpose declaration through a preset compliance rule base to obtain a matching result;

[0108] Based on the matching results, an access authorization credential is generated.

[0109] Specifically, in the implementation, the third smart contract first parses the original data of the access request: it extracts the target medical data identifier (such as "PatientID_2025X_DNA"), role level attributes (including institutional authentication code and professional title certificate hash value) and data purpose declaration (such as clinical diagnosis or medical research) through a structured parsing engine. At the same time, it uses PKI (Public Key Infrastructure) to verify the authenticity of the requester's digital signature certificate to ensure that the request source is legitimate and has not been tampered with.

[0110] Based on the target medical data identifier obtained through parsing, the contract accesses the blockchain's distributed state database (a global ledger storing all medical data metadata) to retrieve the second sensitivity level identifier permanently bound to that identifier (such as {level:5, valid_until:1730419200} in the original classification record). If the identifier is detected to have expired (the current block timestamp has exceeded its validity period), the first smart contract is automatically triggered to execute the real-time data reclassification process to obtain the updated sensitivity level.

[0111] The contract calls the on-chain permission verification module to compare the requester's role level attributes (such as title = associate chief physician, institution level = tertiary hospital) with the minimum permission threshold required by the second sensitivity level identifier: through a pre-set permission matrix table (for example, level 5 sensitive data must meet "title ≥ associate chief physician and institution level ≥ tertiary hospital"), when the role attribute weight value (associate chief physician = 80 points, tertiary hospital = 20 points) reaches the threshold (100 points), the verification is deemed successful; otherwise, the request is immediately rejected.

[0112] For requests that pass permission verification, the contract connects to an external compliance rule base (a smart database that synchronizes with the latest laws and regulations) through a blockchain oracle, strictly matching the request operation type with the data usage statement: for example, requests for scientific research purposes must be associated with an ethics review number (such as ethics approval number: 2025-Medical Research No. X), and requests for clinical diagnosis must be bound to the hash value of the patient's informed consent form; the matching engine outputs structured results (such as {match:true, constraint:only allow access to anonymized data}), which include specific operation restriction clauses.

[0113] Finally, an access authorization credential is generated based on the compliance matching results: the credential adopts the form of a dynamic token (such as ZKP_9A2F) and contains three core elements - 1) timeliness (default validity period = current time + 2 hours, bound to the latest block hash to prevent forgery); 2) scope of operation (such as readable fields: diagnostic conclusions, test indicators); 3) level of desensitization (such as strong desensitization: hiding the last 8 digits of the ID card). The credential is returned to the requester after being digitally signed by a smart contract, and the complete audit trail is written to the blockchain event log.

[0114] S205. Based on the access authorization credential, output the target medical data corresponding to the access request.

[0115] Specifically, the process begins by extracting the target data index and decryption key identifier (e.g., KeyID: KMS_20250710_XT01) from the credential. The encrypted data block set is located using a blockchain distributed indexer—based on the data index, the associated Merkle tree storage structure is retrieved. After verifying the consistency between the leaf node hash and the data fingerprint in the credential, the encrypted data block is extracted from a specified block (e.g., the transaction field at block height #10245). Then, based on the key identifier, the secure interface of the key management system is called (using zero-knowledge proof technology to verify the requester's identity), obtaining a temporary decryption key and injecting it into a secure sandbox environment. In the isolated environment, the data block is sequentially decrypted and reassembled to restore the original medical data. Finally, based on the operation scope declaration and anonymization level requirements in the credential, the privacy computing engine dynamically processes the data: sensitive fields (e.g., ID card numbers) are partially masked according to preset rules (keeping the first four digits), the patient's name in the diagnosis text is replaced with a code, generating target medical data that conforms to the minimization principle. This data is then returned to the requester in real-time via an HTTPS (Hypertext Transfer Protocol Secure) encrypted channel, and the temporary key and memory cache are automatically destroyed after the operation is completed.

[0116] Optionally, the step of outputting the target medical data corresponding to the access request based on the access authorization credential includes:

[0117] Extract the target data index and decryption key identifier from the access authorization credential;

[0118] Based on the target data index, locate the corresponding set of encrypted data blocks from the blockchain;

[0119] The decryption key is obtained from the preset distributed key management database based on the decryption key identifier;

[0120] The encrypted data block set is decrypted and reassembled based on the decryption key to obtain the original medical data;

[0121] Based on the data type requirements in the access request, extract the target field from the original medical data;

[0122] The target medical data is obtained by de-identifying the target field using a preset privacy computing engine.

[0123] Specifically, the target data index (e.g., Merkle root hash value: 0x89a2f4, data block sequence number range [3-7]) and decryption key identifier (e.g., KMS index number: SEC_20250710_XT01) are extracted through a pre-built credential decoder. Simultaneously, the elliptic curve digital signature algorithm (ECDSA) is used to verify the digital signature of the credential issuer (the third-party smart contract), ensuring credential integrity and anti-counterfeiting capabilities. Based on the Merkle root hash value, the specific block storing the hash tree (e.g., block height #10245) is located, and the corresponding set of encrypted data blocks is extracted from the transaction data field. Subsequently, data integrity verification is performed—the SHA-256 hash value of each data block is recalculated and compared with the Merkle tree leaf nodes stored on the chain. If three consecutive data blocks fail verification, an abnormal termination process is triggered.

[0124] Furthermore, the key identifier and visitor identity certificate are submitted to KMS via a TLS 1.3 encrypted channel. After KMS verifies the legitimacy of the request based on zero-knowledge proof technology, it returns a segmented temporary key (such as SM4 algorithm key fragments). This key is valid for 5 minutes and can only be used in combination within the Secure Enclave. The system automatically records the key acquisition audit log. Decryption and reconstruction are performed within a hardware-isolated secure sandbox: the encrypted data blocks are sorted according to their original sequence numbers, and a complete temporary key is injected; highly sensitive fields (such as gene sequences) are decrypted using the national cryptographic SM9 algorithm, and ordinary fields (such as diagnostic text) are decrypted using AES-256-CBC mode; the original medical data structure is restored through a binary stream reconstruction engine, and the sandbox memory cache is cleared immediately after reconstruction.

[0125] According to the data type requirements declared in the access request (such as "required fields: image diagnosis conclusion, HIV antibody test value"), a medical data extraction engine is used: for DICOM format data, the DICOM tag path is used (such as (0008,1030) to extract the examination description), and for HL7 format data, the XPath path is used (such as / HL7 / OBX[5] / VALUE). Non-target fields are cleared from memory within 0.5 seconds after extraction. The target field input privacy calculation engine performs dynamic desensitization: the rule library is matched according to the desensitization level (such as level 3 desensitization) preset in the voucher - the first 6 digits of the ID number are retained and then masked, the disease name is replaced with the ICD-10 code (such as AIDS → B24), and the test value is generalized to the medical reference range (such as CD4 value 356 → 300-400 cells / μL). The final generated target medical data is encrypted in AES-256-GCM mode and transmitted through the HTTPS channel. After the transmission is completed, the key destruction command is automatically triggered.

[0126] Optionally, the method further includes:

[0127] Data access event streams are obtained through the fourth smart contract on the blockchain;

[0128] The data access event stream is analyzed based on a preset anomaly detection model;

[0129] When the data access event stream is in an abnormal access mode, a permission revocation instruction is generated;

[0130] Based on the permission revocation instruction, the corresponding access authorization certificate is frozen through the third smart contract.

[0131] Specifically, the fourth smart contract continuously monitors the data access event stream on the blockchain (including visitor identity, target data identifier, operation type, and timestamp), and captures the raw logs broadcast by the full node in real time through the event subscription interface. After the event stream undergoes structured transformation, it is input into a pre-set anomaly detection model for analysis in the form of streaming data packets. The anomaly detection model uses a pre-trained LSTM (Long Short-Term Memory) temporal analysis algorithm, loaded on an off-chain secure computing node: The model first extracts the spatiotemporal features of the event stream (such as the frequency of access by a single user per unit time and cross-institutional data association access patterns), and compares them with historical normal behavior baselines (such as doctors accessing patient data ≤20 times per day). When continuous abnormal signals are detected (such as a single user initiating 50 gene data export requests within 10 minutes, or cross-hospital batch access to psychiatric medical records at 3 am), the model outputs an anomaly probability value (≥0.95 is considered high risk), triggering the fourth smart contract to generate a permission revocation command.

[0132] Furthermore, the fourth smart contract transmits the permission revoke instruction to the third smart contract via a cross-contract call protocol. The instruction includes a unique identifier for the access authorization credential to be frozen (e.g., token_id: ZKP_9A2F) and an encrypted chain of abnormal evidence (including anomaly pattern fingerprint and timestamp hash). After verifying the validity of the instruction signature, the third smart contract immediately marks the credential's status as "frozen" in the on-chain state database and broadcasts it to all network nodes for synchronous updates. When the third smart contract executes the freeze operation, it activates a dual invalidation mechanism: 1) it writes a freeze timestamp into the credential metadata and sends a key revocation request to the key management system (immediately invalidating the associated decryption key); 2) it publishes a global notification in the blockchain event log, forcing all nodes to reject subsequent data access requests for the credential. After the freeze operation is completed, the system automatically sends an alarm report (including an abnormal access path graph and frozen credential audit trail) to the data supervisor.

[0133] This embodiment also discloses a blockchain-based patient data management system. Figure 3 This is a schematic diagram of a blockchain-based medical data management system disclosed in an embodiment of this application, as shown below. Figure 3As shown, the system includes:

[0134] The data classification module 301 is used to acquire medical data, analyze the content attributes and context information of the medical data through the first smart contract on the blockchain, and generate a first sensitivity level identifier.

[0135] The encryption module 302 is used to perform differentiated encryption on the medical data based on the first sensitivity level identifier through a second smart contract on the blockchain, and generate verification information.

[0136] Block storage module 303 is used to divide the differentiated encrypted medical data into blocks, and store them into the blockchain after constructing a data structure together with the verification information.

[0137] The query authorization module 304 is used to respond to the received access request by verifying the permission certificate in the access request and the type of the access request through a third smart contract on the blockchain, and generating an access authorization certificate.

[0138] The data output module 305 is used to output the target medical data corresponding to the access request based on the access authorization credential.

[0139] Optional, the data classification module 301 is specifically used for:

[0140] The structured metadata tags of the medical data are parsed using the first smart contract to obtain the data type classification results;

[0141] The real-time contextual features associated with the medical data are obtained through the first smart contract to obtain dynamic scene evaluation results;

[0142] Based on the data type classification results and the dynamic scene evaluation results, the first sensitivity level identifier is generated through a preset sensitivity mapping rule.

[0143] Optional, encryption module 302, specifically used for:

[0144] The target encryption policy is matched from a predefined encryption policy library based on the first sensitivity level identifier. The target encryption policy includes an encryption algorithm, key length, and access control policy.

[0145] The medical data is encrypted based on the target encryption strategy.

[0146] The verification information is generated based on the encrypted medical data.

[0147] Optional, the block storage module 303 is specifically used for:

[0148] The data block size is determined from the predefined fragmentation strategy library based on the first sensitivity level identifier;

[0149] The differentially encrypted medical data is divided into continuous data blocks based on the data block size;

[0150] Calculate the corresponding cryptographic hash value for each data block;

[0151] A hash tree is constructed based on all the data blocks and their corresponding cryptographic hash values, and the verification information is associated with non-leaf nodes.

[0152] The hash tree is stored in the transaction data field of the blockchain.

[0153] Optionally, query the authorization module for a 304 error, specifically used for:

[0154] Parse the access request to obtain the target medical data identifier, role level attribute, and data usage declaration;

[0155] Retrieve the second sensitivity level identifier bound to the target medical data identifier from the preset blockchain state database;

[0156] Determine whether the character level attribute meets the minimum permission threshold required by the second sensitivity level identifier;

[0157] If the role level attribute meets the minimum permission threshold, the operation type of the access request is matched with the data purpose declaration through a preset compliance rule base to obtain a matching result;

[0158] Based on the matching results, an access authorization credential is generated.

[0159] Optional, the data output module 305 is specifically used for:

[0160] Extract the target data index and decryption key identifier from the access authorization credential;

[0161] Based on the target data index, locate the corresponding set of encrypted data blocks from the blockchain;

[0162] The decryption key is obtained from the preset distributed key management database based on the decryption key identifier;

[0163] The encrypted data block set is decrypted and reassembled based on the decryption key to obtain the original medical data;

[0164] Based on the data type requirements in the access request, extract the target field from the original medical data;

[0165] The target medical data is obtained by de-identifying the target field using a preset privacy computing engine.

[0166] Optionally, the system further includes a risk control module 306, specifically used for:

[0167] Data access event streams are obtained through the fourth smart contract on the blockchain;

[0168] The data access event stream is analyzed based on a preset anomaly detection model;

[0169] When the data access event stream is in an abnormal access mode, a permission revocation instruction is generated;

[0170] Based on the permission revocation instruction, the corresponding access authorization certificate is frozen through the third smart contract.

[0171] It should be noted that the above embodiments of the apparatus are only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0172] This embodiment also discloses an electronic device, referring to... Figure 4 The electronic device may include: at least one processor 401, at least one communication bus 402, user interface 403, network interface 404, and at least one memory 405.

[0173] The communication bus 402 is used to enable communication between these components.

[0174] The user interface 403 may include a display screen and a camera. Optionally, the user interface 403 may also include a standard wired interface and a wireless interface.

[0175] The network interface 404 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0176] The processor 401 may include one or more processing cores. The processor 401 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 405, and by calling data stored in memory 405. Optionally, the processor 401 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 401 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the processor 401.

[0177] The memory 405 may include random access memory (RAM) or read-only memory. Optionally, the memory 405 may include a non-transitory computer-readable storage medium. The memory 405 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 405 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 405 may also be at least one storage device located remotely from the aforementioned processor 401. Figure 4 As shown, the memory 405, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application for a blockchain-based medical data management method.

[0178] exist Figure 4In the electronic device shown, the user interface 403 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 401 can be used to call an application stored in the memory 405 that is a blockchain-based medical data management method. When executed by one or more processors 401, the electronic device executes one or more methods as described in the above embodiments.

[0179] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0180] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some service interfaces; indirect couplings or communication connections between apparatuses or units may be electrical or other forms.

[0181] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0182] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 405 and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned memory 405 includes various media capable of storing program code, such as a USB flash drive, portable hard drive, magnetic disk, or optical disk.

[0183] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Other embodiments of this disclosure will be readily apparent to those skilled in the art upon consideration of the disclosure in this specification. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A blockchain-based medical data management method, characterized in that, Applied to a server, the method includes: Medical data is acquired, and the content attributes and context information of the medical data are analyzed through the first smart contract on the blockchain to generate a first sensitivity level identifier. The context information includes the geographical location information of the data access device, the epidemic warning status based on the blockchain timestamp, and the access behavior characteristics in the operation log. Based on the first sensitivity level identifier, the medical data is differentially encrypted through a second smart contract on the blockchain, and verification information is generated. The differentiated encrypted medical data is divided into blocks, and after being combined with the verification information to construct a data structure, it is stored in the blockchain; In response to receiving an access request, the third smart contract on the blockchain verifies the permission credentials in the access request and the type of the access request, and generates an access authorization credential. Based on the access authorization credential, output the target medical data corresponding to the access request; The process of acquiring medical data and analyzing its content attributes and contextual information through a first smart contract on the blockchain to generate a first sensitivity level identifier includes: The structured metadata tags of the medical data are parsed using the first smart contract to obtain the data type classification results; The real-time contextual features associated with the medical data are obtained through the first smart contract to obtain dynamic scene evaluation results; Based on the data type classification results and the dynamic scene evaluation results, the first sensitivity level identifier is generated through a preset sensitivity mapping rule; The step of differentially encrypting the medical data based on the first sensitivity level identifier through a second smart contract on the blockchain and generating verification information includes: The target encryption policy is matched from a predefined encryption policy library based on the first sensitivity level identifier. The target encryption policy includes an encryption algorithm, key length, and access control policy. The medical data is encrypted based on the target encryption strategy. The verification information is generated based on the encrypted medical data; The step of dividing the differentiated encrypted medical data into blocks, constructing a data structure together with the verification information, and then storing it in the blockchain includes: The data block size is determined from the predefined fragmentation strategy library based on the first sensitivity level identifier; The differentially encrypted medical data is divided into continuous data blocks based on the data block size; Calculate the corresponding cryptographic hash value for each data block; A hash tree is constructed based on all the data blocks and their corresponding cryptographic hash values, and the verification information is associated with non-leaf nodes. The hash tree is stored in the transaction data field of the blockchain.

2. The method according to claim 1, characterized in that, The step of responding to an access request by verifying the permission credentials in the access request and the type of the access request through a third smart contract on the blockchain, and generating an access authorization credential, includes: Parse the access request to obtain the target medical data identifier, role level attribute, and data usage declaration; Retrieve the second sensitivity level identifier bound to the target medical data identifier from the preset blockchain state database; Determine whether the character level attribute meets the minimum permission threshold required by the second sensitivity level identifier; If the role level attribute meets the minimum permission threshold, the operation type of the access request is matched with the data purpose declaration through a preset compliance rule base to obtain a matching result; Based on the matching results, an access authorization credential is generated.

3. The method according to claim 1, characterized in that, The step of outputting the target medical data corresponding to the access request based on the access authorization credential includes: Extract the target data index and decryption key identifier from the access authorization credential; Based on the target data index, locate the corresponding set of encrypted data blocks from the blockchain; The decryption key is obtained from the preset distributed key management database based on the decryption key identifier; The encrypted data block set is decrypted and reassembled based on the decryption key to obtain the original medical data; Based on the data type requirements in the access request, extract the target field from the original medical data; The target medical data is obtained by de-identifying the target field using a preset privacy computing engine.

4. The method according to claim 1, characterized in that, The method further includes: Data access event streams are obtained through the fourth smart contract on the blockchain; The data access event stream is analyzed based on a preset anomaly detection model; When the data access event stream is in an abnormal access mode, a permission revocation instruction is generated; Based on the permission revocation instruction, the corresponding access authorization certificate is frozen through the third smart contract.

5. A blockchain-based medical data management system, characterized in that, Specifically, it includes: The data classification module is used to acquire medical data, analyze the content attributes and context information of the medical data through the first smart contract on the blockchain, and generate a first sensitivity level identifier. The context information includes the geographical location information of the data access device, the epidemic warning status based on the blockchain timestamp, and the access behavior characteristics in the operation log. An encryption module is used to perform differentiated encryption on the medical data based on the first sensitivity level identifier through a second smart contract on the blockchain, and generate verification information; The block storage module is used to divide the differentiated encrypted medical data into blocks, and then store them into the blockchain after constructing a data structure together with the verification information. The authorization query module is used to respond to an access request by verifying the permission credentials in the access request and the type of the access request through a third smart contract on the blockchain, and to generate an access authorization credential. The data output module is used to output the target medical data corresponding to the access request based on the access authorization credential. The data classification module is also used to parse the structured metadata tags of the medical data through the first smart contract to obtain the data type classification result; The real-time contextual features associated with the medical data are obtained through the first smart contract to obtain dynamic scene evaluation results; Based on the data type classification results and the dynamic scene evaluation results, the first sensitivity level identifier is generated through a preset sensitivity mapping rule; The encryption module is further configured to match a target encryption policy from a predefined encryption policy library based on the first sensitivity level identifier, wherein the target encryption policy includes an encryption algorithm, a key length, and an access control policy. The medical data is encrypted based on the target encryption strategy. The verification information is generated based on the encrypted medical data; The block storage module is further configured to determine the data block size from a predefined sharding strategy library based on the first sensitivity level identifier; The differentially encrypted medical data is divided into continuous data blocks based on the data block size; Calculate the corresponding cryptographic hash value for each data block; A hash tree is constructed based on all the data blocks and their corresponding cryptographic hash values, and the verification information is associated with non-leaf nodes. The hash tree is stored in the transaction data field of the blockchain.

6. An electronic device, characterized in that, The device includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions. Both the user interface and the network interface are used to communicate with other devices. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1-4.

Images