Intelligent medical data integration display system based on block chain

Abstract

The invention discloses an intelligent medical data integrated display system based on a block chain, and relates to the technical field of medical block chains, decentralized data management and dynamic access control are realized through a block chain technology, and a patient can define and update an access strategy by using a trusted terminal to ensure data privacy. Attribute-based encryption and zero-knowledge proof technologies are adopted, data encryption storage and anonymous permission verification are achieved, and safe sharing of data is guaranteed. Meanwhile, an emergency access authorization mechanism is introduced, and timeliness and safety in an emergency treatment scene are both considered. In addition, dynamic audit tracking is realized through homomorphic encryption, risks are monitored in real time, emergency response is triggered, and the safety of the data life cycle is ensured. According to the invention, the efficiency, security and privacy protection level of medical data sharing are significantly improved, and the method is suitable for a cross-institution medical cooperation scene.

Description

Technical Field

[0001] This invention relates to the field of medical blockchain technology, specifically to a blockchain-based intelligent medical data integration and display system. Background Technology

[0002] Currently, medical data is scattered across independent systems in various medical institutions, with heterogeneous data formats (such as HL7, DICOM, and FHIR) and a lack of unified integration standards, resulting in low efficiency in cross-institutional data sharing. Traditional centralized integration solutions rely on third-party intermediaries, which pose single points of failure risks and cannot guarantee real-time data synchronization. Clinical diagnosis and research collaboration require frequent access to patient data throughout their entire lifecycle, but the data silos severely hinder the efficiency of cross-hospital collaboration, especially causing critical delays in multidisciplinary consultations for critically ill patients.

[0003] Existing systems rely on role-based access control (RBAC) or attribute-based access control (ABAC), resulting in delayed and coarse-grained permission updates, preventing patients from managing sensitive data (such as genetic and mental health records) in real time. Centralized permission verification requires transmitting doctors' plaintext identities, making them vulnerable to hacking or internal leaks; in 2023, 87% of medical data breaches stemmed from permissions system vulnerabilities. Furthermore, emergency treatment scenarios (such as patients in a coma) lack authorization mechanisms that balance timeliness and security, and traditional all-or-nothing open models can easily lead to excessive privacy exposure.

[0004] Auditing of medical data operations typically relies on plaintext logs, posing a risk of secondary privacy breaches (such as inferring patient diseases from access records). Existing auditing systems cannot detect abnormal behavior in real time (such as frequent access to genetic data), and the process from risk identification to response takes several hours, failing to meet the GDPR / HIPAA's mandatory 72-hour notification requirement for data breaches. Rigid key management means that even if accounts are frozen, historical data can still be decrypted using leaked keys, and the lack of cryptographically-level self-destruct capabilities leads to a loss of control over the security of medical data throughout its lifecycle.

[0005] To address the aforementioned shortcomings, a technical solution is provided. Summary of the Invention

[0006] The purpose of this invention is to solve the problems of low efficiency in existing medical data sharing, insufficient privacy protection, and lagging access control, and to propose a blockchain-based intelligent medical data integration and display system.

[0007] The objective of this invention can be achieved through the following technical solutions: A blockchain-based intelligent medical data integration and display system includes: The access control module allows patients to define dynamic access policies through trusted terminals. The policy summary is stored on the blockchain via a smart contract. Medical data is monitored in real time, encrypted according to the policy, and then distributed for storage, with an on-chain anchoring relationship established. Patients can update or revoke the policy, triggering an automatic re-encryption process to ensure that invalid permissions are blocked immediately. The authorization verification and data request module allows doctors to generate zero-knowledge proofs based on attribute credentials to verify authorization compliance without revealing their identity. Through a multinomial commitment batch processing mechanism, a single proof can cover multiple data requests, reducing verification complexity. After successful verification, the key fragment is encrypted with a temporary public key and returned. Finally, the data is decrypted and destroyed in a secure sandbox. The audit and emergency response module records a minimal privacy audit log and monitors preset risk modes in real time through smart contracts. When an alarm is triggered, it initiates a physical key destruction and data cryptographic self-destruction mechanism to make the ciphertext permanently undecipherable. Patients can perform emergency recovery, including key reset and reencryption of historical data.

[0008] Furthermore, the execution process of the access control module is as follows: Step A: The patient defines a structured access policy through a trusted terminal. The structured access policy includes a target data identifier, attribute condition combinations, and unauthorized access clauses. The strategy content is encrypted and hashed to generate a strategy digest, and the binding relationship between the strategy digest and the patient's identity identifier and timestamp is stored through a strategy registration contract on the blockchain; Step B: The edge data proxy module deployed on the intranet of the medical institution continuously monitors the incremental data of the local medical database. When the target data associated with the policy is detected, the attribute-based encryption engine is called to encrypt the data with the policy as the encryption parameter, generate ciphertext and transmit it to the distributed storage network to obtain the content addressing identifier. Write the association between the content addressing identifier and the policy summary into the data anchoring contract of the blockchain; Step C: When a patient initiates a policy update or revocation instruction, a new policy summary is generated and submitted to the policy registration contract, and the contract marks the old policy summary as invalid. After the edge data proxy module detects a policy failure event, it triggers a data re-encryption process: The original encrypted data is retrieved from the distributed storage network, decrypted using a preset key, re-encrypted according to the new strategy, and the distributed storage and blockchain anchor records are updated. For access requests, the smart contract verifies the policy status; if the policy summary status is invalid, access is denied.

[0009] Furthermore, the access control module also includes an emergency access authorization mechanism, the specific operation steps of which are as follows: Step 1, Policy Pre-configuration: The patient pre-configures an emergency access policy via a trusted terminal, including: Specify the list of emergency authorized person public keys and their associated time lock parameters; define the subset of medical data that can only be accessed in an emergency; Step 2, Key Fragmentation and Encapsulation: Execute the secure key processing flow: Generate a unique emergency access key; split the key into multiple independent fragments using threshold secret sharing technology; encapsulate each fragment into a cryptographic puzzle with a forced time delay; Step 3, Joint Authorization Access: When the preset minimum number of authorized users for joint requests is reached: The smart contract verifies the legitimacy of the requester's public key; triggers parallel computation of cryptographic puzzles, and automatically releases the complete key after a specified waiting period; uses the key to decrypt a preset subset of emergency medical data and transmits it securely. Step 4: Security Audit Tracking The blockchain fully records the following audit information without containing sensitive identities: Requester anonymous identifier; operation timestamp; data type tag accessed; Step 5: Post-treatment patient management: Once the patient regains autonomy, the following procedures should be followed immediately: Review all emergency access operation logs; immediately terminate all emergency authorization policies.

[0010] Furthermore, the specific operation steps of the permission verification and data request module are as follows: Off-chain identity anonymity verification: Doctors' terminal devices collect digital attribute credentials, and zero-knowledge proof circuits are constructed based on access strategies for target medical data; Generate a mathematical proof that verifies the compliance of doctor attributes without containing plaintext identity information; On-chain anonymous key release: Submit the mathematical proof, the target data storage identifier, and the temporary public key for this session to the blockchain verification contract; Verify the validity of the contract verification certificate; if it passes, request the decryption of the key fragment from the key management contract. The temporary public key is used to encrypt the key fragment and return it to the doctor's terminal; Terminal security decryption shows: The doctor's terminal uses the corresponding temporary private key to decrypt and obtain the key fragment; Download encrypted medical data from a distributed storage network; Data decryption and rendering are completed in a hardware-level trusted execution environment, and plaintext data and keys are cleared from memory immediately after display.

[0011] Furthermore, the permission verification and data request module also includes a batch zero-knowledge proof optimization mechanism based on multinomial commitments, with the following specific steps: Step 1, Attribute Commitment Pre-registration: The doctor's terminal pre-collects its medical attribute set, constructs an attribute polynomial, and generates the corresponding cryptographic commitment; This commitment will be recorded on-chain once via a blockchain smart contract; Step 2, Batch Proof Construction: When multiple medical data items need to be accessed, a single zero-knowledge proof circuit is constructed. This circuit simultaneously verifies that the doctor's attributes meet the access policy requirements of all target data; Step 3, Efficient On-Chain Verification: Submit the batch proof and data identifier list to the blockchain verification contract; Contract execution verification in two steps: Step 1: Verify the consistency between the cryptographic commitment and the attribute polynomial; Step 2: Run a batch verification algorithm with constant complexity to complete the centralized verification of all data access permissions; Step 4: Release the key as needed: After successful verification, the contract returns an encrypted decryption key fragment to the doctor's terminal; The terminal restores the complete key and accesses the data in a secure environment.

[0012] Furthermore, the specific operation steps of the audit and emergency response module are as follows: Minimize privacy audit logs: An audit log containing only five types of metadata is recorded on the blockchain: Event type; Operator anonymous identifier; Target data content identifier; Block timestamp; Transaction status; It absolutely does not record patient identity, doctor identity, medical content, strategy details, or decryption keys; Smart contract risk monitoring: Predefined programmable risk rules in blockchain smart contracts include: The same anonymous operator accessed sensitive patient data from different patients at high frequency within a short period of time. The number of policy revocation events in a single day exceeded the system threshold; Blockchain nodes monitor on-chain events in real time, and automatically trigger an alarm contract when the event sequence matches the risk rules. Secure key erasure and data self-destruction: Executes in response to alarm contracts or patient manual commands: The key management contract marks the master key seed associated with the target data as obsolete; The off-chain hardware security module physically destroys the stored key components; Preserve encrypted data in distributed storage, but permanently disable its decryption capability; Emergency Recovery Channel: After the patient passes security verification, the following steps are executed: generate a new key seed; trigger the historical data re-encryption process; and deploy the updated risk monitoring strategy.

[0013] Furthermore, the auditing and emergency response module also includes homomorphically encrypted dynamic audit trails, the specific process of which is as follows: Ciphertext aggregation storage: Define the audit log metadata set as ,in Corresponding timestamp, event type, operator hash, data ID, and transaction status; Use an additive homomorphic encryption algorithm to encrypt numeric fields in the log, satisfying the following: ,in Here, k0 is the encryption function, a is a constant, and a and b are arbitrary plaintext values. On-chain ciphertext aggregation node: Deploys dedicated audit nodes to periodically perform aggregation operations on on-chain ciphertext logs, including: Calculate the number of encrypted accesses for the same type of event within a certain time period. or the average time interval of the ciphertext ; where C is the total number of encrypted accesses of the same type of event within a certain time period, q is the number of entries of this type of event in the audit log, and E(1) is the encrypted representation of 1 access, and the number of accesses is counted by homomorphic accumulation; The timestamps of adjacent audit logs; Homomorphic alert threshold setting: Regulatory agencies predefine encrypted alert thresholds through smart contracts, including: or ,in These are the maximum allowed access frequency and the minimum time interval threshold, respectively. Ciphertext matching algorithm: When the audit node calculates the ciphertext statistics S, it executes the algorithm through a homomorphic comparison protocol. The execution process does not require decryption of logs; anomaly detection is completed directly in encrypted form. The encrypted calculation method for the risk index R is defined as follows: ,in For the i-th type of risk factor; As risk weight, satisfying h represents the total number of risk factor types; when When the emergency response contract is automatically triggered, This is the critical value for ciphertext.

[0014] Compared with the prior art, the beneficial effects of the present invention are: (1) This invention effectively solves the privacy protection problem in existing medical data sharing by using a blockchain-based intelligent medical data integration and display system. Traditional medical data sharing relies on centralized third-party intermediaries, which poses a single point of failure risk and cannot guarantee real-time data synchronization, resulting in low efficiency of cross-institutional data sharing. By utilizing the decentralized characteristics of blockchain and combining attribute-based encryption (ABE) and zero-knowledge proof (ZKP) technologies, secure sharing and access control of medical data can be achieved without disclosing patient privacy and doctor identity. Patients can dynamically define access policies through trusted terminals and manage access permissions for sensitive data in real time, ensuring the privacy and security of data during cross-institutional sharing. At the same time, the system supports an emergency access authorization mechanism, which can balance timeliness and security in emergency situations such as when a patient is unconscious, avoiding excessive exposure of privacy. (2) This invention significantly improves the efficiency of access control and verification of medical data. Existing systems rely on role-based access control (RBAC) or attribute-based access control (ABAC), resulting in delayed and coarse-grained access control updates, making it impossible for patients to manage sensitive data in real time. This invention implements a dynamic update and instant expiration mechanism for permissions through blockchain smart contracts, allowing patients to update or revoke policies within seconds, ensuring that expired permissions are intercepted immediately. Furthermore, a multinomial commitment batch processing mechanism is introduced, allowing doctors to cover multiple data requests with a single proof when accessing multiple data items, significantly reducing verification complexity and improving verification efficiency. This efficient access verification mechanism not only ensures data security but also enhances the convenience and real-time nature of medical data sharing. (3) This invention enhances the auditing and emergency response capabilities of medical data through homomorphic encryption and smart contract technology. Traditional medical data operation auditing generally uses plaintext log recording, which poses a risk of secondary privacy leakage and cannot detect abnormal behavior in real time. The invention adopts a minimal privacy audit log, recording only non-sensitive metadata to avoid leakage of sensitive information such as patient identity, doctor identity, and medical content. At the same time, the invention uses smart contracts to monitor preset risk modes in real time. Once abnormal behavior is detected, the invention immediately initiates a physical key destruction and data cryptographic self-destruction mechanism, making the ciphertext permanently undecipherable. Patients can perform emergency recovery through secure verification, including key reset and historical data re-encryption, ensuring the security and privacy of medical data throughout its entire lifecycle. Attached Figure Description

[0015] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings; Figure 1 This is the overall system block diagram of the present invention. Detailed Implementation

[0016] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] It should be understood that the terms “comprising” and “including” used in this disclosure and claims indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0018] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure. As used in this disclosure and claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this disclosure and claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations.

[0019] like Figure 1 As shown, a blockchain-based intelligent medical data integration and display system includes an access control module, an access verification and data request module, and an audit and emergency response module. In the access control module, patients define dynamic access policies (including target data identifiers, attribute conditions, and unauthorized access clauses) through trusted terminals. Policy summaries are stored on the blockchain via smart contracts. The system monitors medical data in real time, performs attribute-based encryption (ABE) according to the policies, and then stores the data in a distributed manner, establishing on-chain anchoring relationships. Patients can update or revoke their policies within seconds, triggering an automatic re-encryption process to ensure that expired permissions are immediately blocked. Phase 1: Patient-Driven Dynamic Strategy Definition and On-Chain Evidence Storage Patients define structured access policies through a trusted terminal (such as a mobile device application) for authentication. Policy elements include: Target data identifiers (such as a unique ID for a specific test report); combinations of attribute conditions (including medical institution name, department type, doctor's title, and validity period); unauthorized clauses (such as allowing emergency room doctors to circumvent policy restrictions under audit conditions); The terminal device generates a policy digest by performing a cryptographic hash operation on the policy content, stores the binding relationship between the digest and the patient's identity identifier through a blockchain smart contract (named the policy registration contract), and records the timestamp. It also includes an emergency access authorization mechanism: Pre-defined emergency access policy: Patients declare a list of emergency authorized person public keys in the policy. and time lock parameter T (e.g., T=24 hours); define the urgently accessible data subset D. emerg D (e.g., D) emerg =blood type, allergy history); Time-lock key encapsulation: Generate emergency access key Split into n partitions (Shamir threshold scheme): ,in k is the minimum number of authorized collaborators, and i is the shard index. For fragmentation, Let x be the value of the Lagrange basis function at point 0, and let i and j be indices representing the i-th and j-th points, respectively. These are the x-coordinates of the i-th and j-th points, respectively; each slice Encapsulate it into a time-lock puzzle and force a solution time of T0; Emergency access process: When k authorized users jointly request access: Smart contract verifies requester's public key The time-locked puzzle is computed in parallel and automatically released after time T0. ;use Decrypting D emerg And transmit it to the authorized terminal; End-to-end on-chain auditing: records the requester's anonymous ID, timestamp, and access data tags; Post-patient control: After recovery, patients can view emergency access records via mobile devices; and revoke all emergency authorization policies with one click.

[0020] Phase 2: Real-time data encryption and encapsulation based on attribute-based encryption: The edge data proxy module deployed on the intranet of a medical institution performs the following operations: Continuously monitor incremental data in the local medical database; when target data associated with a policy is detected, invoke the attribute-based encryption engine, use the patient-defined policy as the encryption parameter to encrypt the data; transmit the generated ciphertext to a distributed storage network (such as IPFS) to obtain a unique content addressing identifier; write the association between this identifier and the policy digest into the data anchoring contract on the blockchain; Phase 3: Dynamic Permission Update and Instant Expiration Mechanism When a patient initiates a policy update or revocation command through a trusted terminal: The terminal generates a new policy summary and submits it to the policy registration contract. The contract automatically marks the old policy summary as invalid. After the edge data agent module detects the blockchain policy invalidation event, it automatically triggers the data re-encryption process: retrieve the original encrypted data from the distributed storage network; decrypt the data using a preset key; re-encrypt the data according to the new policy; update the distributed storage and blockchain anchor records; any access request must be verified for policy validity by the smart contract: if the policy summary status is "invalid", access is directly rejected.

[0021] In the authorization verification and data request module, the doctor's terminal generates zero-knowledge proofs (ZKP) based on attribute credentials to verify authorization compliance without revealing their identity. Through a multinomial commitment batch processing mechanism, a single proof can cover multiple data requests, significantly reducing verification complexity. After successful verification, the key fragment is encrypted with a temporary public key and returned. Finally, data decryption and destruction are performed within a hardware-level security sandbox. Phase 1: Off-chain zero-knowledge proof generation: The doctor's terminal device (such as a clinical workstation) has a built-in proof generation module that executes: Collect doctors' digital attribute credentials (including encrypted signatures of institutions, departments, titles, etc.); construct zero-knowledge proof circuits based on the access strategy of the target medical data (such as the strategy defined in Innovation Point 1); generate mathematical proofs that verify that "doctor attributes meet the strategy requirements" but do not contain any plaintext attribute values ​​or doctor identity information. It also includes a batch zero-knowledge proof optimization mechanism based on multinomial commitments, the process of which is as follows: Multinomial commitment preprocessing: Physician terminal pre-registration attribute set (e.g., professional title, department, etc.); Construct attribute polynomials ,in Let y be an attribute polynomial, and y be a polynomial variable. For the i-th attribute value; generate a pair of polynomials. promise And store this commitment on the blockchain (it only needs to be stored once); Batch proof generation: When u data points need to be accessed (u≥2), a batch verification circuit is constructed: , Let be the set of policy attributes for the i-th data; a single proof can cover access requests for u data, which reduces the complexity of the verification equation to O(1); On-chain verification: when submitting (Batch proof) and list of data identifiers At this time, verifying the contract only requires the following two steps: Verification commitment Consistency with P(x): Ensure that the submitted polynomial P(x) is consistent with the commitment previously generated and stored on the blockchain. The corresponding polynomials are consistent; running the batch verification algorithm once has a complexity of O(n log n). , The verification complexity is proportional to the logarithm of the number of data items u: We use zero-knowledge proof (ZK-SNARK) technology to verify the validity of submitted batch proofs. The verification complexity here is O(n log n). This means that the verification process is highly efficient, and even with a large amount of data, the computing resources required for verification will not increase linearly.

[0022] Phase 2: On-chain Anonymous Verification and Key Release The doctor's terminal submits the following data to the blockchain smart contract (named the verification contract): Zero-knowledge proof; distributed storage identifier for the target data (such as IPFS content ID); temporarily generated public key (for this session only); Verify contract execution logic: Call a pre-built zero-knowledge verification algorithm to verify the validity of the Proof; If the verification is successful: send a command to the key management contract to obtain the decryption key fragment of the target data; encrypt the key fragment using the temporary public key provided by the doctor; and return the encryption result to the doctor's terminal. If verification fails: the process terminates without returning any error details; The blockchain only records: anonymous transaction hash, verification result (pass / reject), and timestamp.

[0023] Phase 3: Terminal Security Decryption and Sandboxed Display The doctor's terminal uses the corresponding temporary private key to decrypt the received key fragment; and downloads the encrypted medical data from the distributed storage network. Data decryption and rendering are performed in a hardware-level secure environment (such as the Intel SGX Trusted Execution Environment); after display, plaintext data and keys are automatically cleared from memory.

[0024] The audit and emergency response module records a minimal privacy audit log (containing only non-sensitive metadata such as event type and anonymous ID), and monitors preset risk patterns (such as high-frequency access to genetic data) in real time via smart contracts. Once an alarm is triggered, a physical key destruction and data cryptographic self-destruction mechanism is immediately initiated, making the ciphertext permanently undecipherable. Patients can perform emergency recovery, including key reset and reencryption of historical data; Component 1: Minimize privacy audit logs: Log content guidelines: Only five types of non-sensitive metadata are recorded to the blockchain: event type (data access request, permission change, unauthorized access alarm); anonymized operator identifier (temporary ID hash value generated by zero-knowledge proof); target data identifier (distributed storage content ID); block timestamp; transaction status (passed / rejected). Never record: patient identity, doctor identity, medical details, strategy details, or decryption key; Log storage architecture: Sharded on-chain storage is adopted: core event summaries are stored on the main chain, and complete logs are encrypted and distributed to multiple private sub-chains, which can only be accessed by authorized auditors through cross-chain protocols; Component 2: Smart contract-driven leakage risk monitoring; Programmable risk rule engine: Patients or regulatory agencies define risk patterns in a smart contract (named the risk monitoring contract), including: Rule 1: The same anonymous operator requests genetic data from more than 50 different patients within 10 minutes; Rule 2: The number of policy reversal events in a single day exceeds the system threshold (indicating the risk of large-scale data migration).

[0025] Real-time risk detection: Blockchain nodes monitor the on-chain event stream, and automatically trigger an alarm contract when a continuous sequence of events matches a preset risk pattern; Component 3: Key Secure Erasure and Data Self-Destruction Mechanism Multi-level key destruction command: When the risk monitoring contract or the patient manually triggers an emergency response: a cryptographic erasure command is sent to the key management contract; the contract immediately marks the master key seed associated with the target data as obsolete; Hardware Security Module (HSM) linkage: the off-chain HSM device listens to the on-chain command and physically destroys the stored key component (through firmware-level security erasure command); Irreversible locking of encrypted data: the encrypted data in the distributed storage remains stored (ensuring data persistence), but because the key seed is destroyed, the data permanently loses its decryption ability, equivalent to "cryptographic self-destruction"; Component 4: Emergency Recovery Channel Patients can reactivate their accounts in a secure environment and perform the following actions: generate a new key seed; trigger historical data re-encryption (using the re-encryption pipeline of Innovation Point 1); and deploy updated risk monitoring strategies.

[0026] It also includes dynamic audit trails with homomorphic encryption, achieving a two-way optimization of privacy protection and risk warning through statistical analysis in the ciphertext state. Specifically: Ciphertext aggregation storage: Define the audit log metadata set as ,in This corresponds to the timestamp, event type, operator hash, data ID, and transaction status. Numerical fields in the log (such as timestamp differences and access frequencies) are encrypted using an additive homomorphic encryption algorithm (such as Paillier) to satisfy the following conditions: ,in Let k be the encryption function, k0 be a constant, and a and b be arbitrary plaintext values.

[0027] On-chain encrypted aggregation node: Deploy dedicated audit nodes to periodically perform aggregation operations on on-chain encrypted logs. For example, calculate the number of encrypted accesses for similar events within a certain time period. or the average time interval of the ciphertext ; where C is the total number of encrypted accesses of the same type of event within a certain time period, q is the number of entries of this type of event in the audit log, and E(1) is the encrypted representation of "1 access", and the number of accesses is counted by homomorphic accumulation; The timestamps of adjacent audit logs; Homomorphic alert threshold setting: Regulatory agencies predefine ciphertext alert thresholds through smart contracts, such as: or ,in These are the maximum allowed access frequency and the minimum time interval threshold, respectively. Ciphertext matching algorithm: When the audit node calculates the ciphertext statistics S, it performs the following steps using a homomorphic comparison protocol (such as Paillier-based ciphertext comparison): This process does not require decrypting logs and completes anomaly detection directly in the encrypted state; The encrypted calculation method for the risk index R is defined as follows: ,in For risk factors of type i (such as the number of unauthorized attempts and the frequency of cross-institutional visits); As risk weight, satisfying h is the total number of risk factor types; when When the emergency response contract is automatically triggered, This is the critical value for ciphertext.

[0028] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1.A blockchain-based intelligent medical data integration display system, characterized in that, Comprise: A permission control module, through which a patient defines a dynamic access policy via a trusted terminal, and a policy digest is stored in a blockchain via a smart contract; Real-time monitoring of medical data, attribute-based encryption according to the policy, distributed storage, and establishment of an on-chain anchoring relationship; the patient can update or revoke the policy, triggering an automatic re-encryption process to ensure that invalid permissions are intercepted in real time; A permission verification and data request module, based on attribute credentials, a doctor terminal generates a zero-knowledge proof, verifies the compliance of the permission without revealing the identity, and through a polynomial commitment batch processing mechanism, a single proof can cover multiple data requests, reducing the verification complexity; after verification, the key fragments are encrypted via a temporary public key and returned, and finally, data decryption and destruction display are completed in a secure sandbox; An audit and emergency response module, which records a minimized privacy audit log and monitors preset risk patterns in real time via a smart contract; When an alarm is triggered, a key physical destruction and data cryptography self-destruction mechanism is started, making the ciphertext permanently intractable; The patient can perform emergency recovery, including key reset and historical data re-encryption. 2.The blockchain-based intelligent medical data integration display system according to claim 1, wherein, The execution process of the permission control module is as follows: Step A: The patient defines a structured access policy via a trusted terminal, and the structured access policy includes a target data identifier, an attribute condition combination, and an overreach clause; The policy content is subjected to an encrypted hash operation to generate a policy digest, and the binding relationship between the policy digest and the patient's identity and the timestamp are stored via a policy registration contract on the blockchain; Step B: The edge data agent module deployed in the medical institution intranet continuously monitors the incremental data of the local medical database, and when the target data associated with the policy is detected, an attribute-based encryption engine is called to encrypt the data according to the policy, generate ciphertext, and transmit it to a distributed storage network to obtain a content addressing identifier; The association between the content addressing identifier and the policy digest is written into the data anchoring contract of the blockchain; Step C: When the patient initiates a policy update or revocation instruction, a new policy digest is generated and submitted to the policy registration contract, and the contract marks the old policy digest as invalid; After the edge data agent module detects the policy invalidation event, the data re-encryption process is triggered: The original ciphertext data is obtained from the distributed storage network, decrypted using the preset key, re-encrypted according to the new policy, and the distributed storage and blockchain anchoring records are updated; For access requests, the smart contract verifies the policy status, and if the policy digest status is invalid, access is denied. 3.The blockchain-based intelligent medical data integration display system according to claim 2, characterized in that, The permission control module also includes an emergency access authorization mechanism, and the specific operation steps are as follows: Step one, policy pre-setting: the patient pre-sets an emergency access policy via a trusted terminal, including: Specifying a list of emergency authorized public keys and their associated time lock parameters; defining a subset of medical data that only allows emergency access; Step two, key fragment encapsulation: execute a secure key processing flow: Generate a unique emergency access key; use threshold secret sharing technology to split the key into multiple independent fragments; encapsulate each fragment into a forced time-delay cryptography puzzle; Step three, joint authorized access: when the preset minimum number of authorized persons jointly request: The smart contract verifies the legitimacy of the requester's public key, triggers the parallel computation of the cryptographic puzzle, and automatically releases the complete key after a specified waiting period. The key is used to decrypt a preset subset of emergency medical data and securely transmit it. Step four, security audit tracking: The blockchain records the following audit information and does not contain sensitive identities: Requester anonymous identifier; Operation timestamp; Data type label accessed; Step five, patient post-control: After the patient regains autonomy, the following operations are performed at any time: Review all emergency access operation records; Immediately terminate all emergency authorization strategies. 4.The blockchain-based intelligent medical data integration display system of claim 1, wherein, The specific operation steps of the permission verification and data request module are as follows: Off-chain identity concealment verification: The doctor's terminal device collects digital attribute credentials and constructs a zero-knowledge proof circuit based on the access strategy of the target medical data; Generate a mathematical proof of verifiable doctor attribute compliance without revealing the identity; On-chain anonymous key release: Submit the mathematical proof, target data storage identifier, and this session's temporary public key to the blockchain verification contract; The verification contract checks the validity of the proof, and if it passes, it requests the decryption key fragment from the key management contract; Encrypt the key fragment using the temporary public key and return it to the doctor's terminal; Terminal secure decryption display: The doctor's terminal uses the corresponding temporary private key to decrypt and obtain the key fragment; Download encrypted medical data from a distributed storage network; Complete data decryption and rendering in a hardware-level trusted execution environment, and immediately clear the plaintext data and keys in memory after display. 5.The blockchain-based intelligent medical data integration display system according to claim 4, wherein, The permission verification and data request module also includes a batch zero-knowledge proof optimization mechanism based on polynomial commitments, with the following specific steps: Step 1, attribute commitment pre-registration: The doctor's terminal pre-collects its medical attribute set, constructs an attribute polynomial, and generates a corresponding cryptographic commitment; This commitment is stored on the blockchain through a one-time smart contract; Step 2, batch proof construction: When accessing multiple medical data items, construct a single zero-knowledge proof circuit; This circuit simultaneously verifies that the doctor's attributes meet the access strategy requirements of all target data; Step 3, efficient on-chain verification: Submit the batch proof and data identifier list to the blockchain verification contract; The contract performs two-step verification: Step 1, verify the consistency of the cryptographic commitment and attribute polynomial; Step 2, run a constant-complexity batch verification algorithm to complete centralized verification of all data access permissions; Step 4, key release on demand: After verification, the contract returns the encrypted decryption key fragment to the doctor's terminal; The terminal restores the complete key in a secure environment and accesses the data. 6.The blockchain-based intelligent medical data integration display system according to claim 1, wherein, The specific operation steps of the audit and emergency response module are as follows: Minimize privacy audit logs: Record audit logs containing only five types of metadata on the blockchain: Event type; Anonymous identifier of the operator; Target data content identifier; Block timestamp; Transaction status; Where patient identity, doctor identity, medical content, strategy details, and decryption keys are absolutely not recorded; Smart contract risk monitoring: Predefine programmable risk rules in the blockchain smart contract, including: Same anonymous operator accessing different patient sensitive data with high frequency in a short time; Strategy revocation events exceeding the system threshold in a single day; Blockchain nodes listen to on-chain events in real-time, and automatically trigger alert contracts when event sequences match risk rules; Key security erasure and data self-destruction: Respond to alert contracts or patient manual instructions: Key management contracts mark the target data-associated master key seed as obsolete; Off-chain hardware security modules physically destroy stored key components; Keep encrypted data in distributed storage, but make it permanently lose decryption capabilities; Emergency recovery channel: Patients execute after security verification: generate a new key seed; trigger historical data re-encryption process; deploy updated risk monitoring strategy. 7.The blockchain-based intelligent medical data integrated display system according to claim 6, wherein, The audit and emergency response module also includes homomorphic encryption dynamic audit tracking, the specific process is as follows: Ciphertext aggregation store: define audit log metadata set as wherein corresponding timestamp, event type, operator hash, data ID, transaction status; The numerical fields in the log are encrypted using an additive homomorphic encryption algorithm, satisfying: wherein is an encryption function, k0 is a constant, and a, b are arbitrary plaintext numbers. On-chain ciphertext aggregation node: Deploy a dedicated audit node to perform aggregation operations on on-chain ciphertext logs regularly, including: counting the number of ciphertext accesses of the same event in a certain period of time , or the mean of ciphertext time intervals ; wherein C is the sum of the number of ciphertext accesses of the same event in a certain period of time, q is the number of entries of the event in the audit log, E(1) is the ciphertext representation of 1 access, and the number of times is counted by homomorphic accumulation; is the timestamp of the adjacent audit log; Homomorphic early warning threshold setting: the regulatory authority predefines the ciphertext early warning threshold through the smart contract, including: or wherein are the maximum allowed access frequency and minimum time interval threshold, respectively; Ciphertext matching algorithm: when the audit node calculates the ciphertext statistics S, execute through homomorphic comparison protocol: , the execution process does not need to decrypt the log, and the anomaly detection is completed directly in the ciphertext state; The ciphertext calculation method of defining the risk index R is as follows: , wherein is the ith risk factor of the first type; is a risk weight, satisfying , and h is the total number of risk factor types. When the emergency response contract is automatically triggered, is a ciphertext threshold value.

Images