A method and system for secure fusion query governance of multimodal biomedical data

Abstract

This application discloses a method and system for secure fusion query governance of multimodal biomedical data. The method includes: receiving a fusion query request; verifying its legitimacy through a blockchain smart contract; decomposing it into sub-query tasks based on a multimodal metadata ontology model and distributing them; each data holder node generating intermediate results identified by a unified pseudonym in its local privacy-preserving computing environment; performing privacy-preserving data alignment and aggregation operations; returning the fusion result and recording key events in the blockchain smart contract. This application achieves integrated governance that ensures data is available but not visible, queries are flexible, processes are auditable, and contributions are incentivized. It is applicable to the secure collaborative analysis of multimodal biomedical data such as genomics, imaging, and electronic medical records.

Description

Technical Field

[0001] This application belongs to the field of interdisciplinary technology of biomedical big data and privacy computing, specifically involving a platform governance method, system, electronic device and storage medium that enables cross-source and fusion query of multimodal biomedical data such as genomes, images and electronic medical records while ensuring data privacy and security. Background Technology

[0002] Currently, biomedical research has fully entered the multimodal era. Single data dimensions (such as genomes or images alone) are insufficient to reveal the intrinsic mechanisms of complex diseases, necessitating joint analysis of heterogeneous data such as gene mutations, medical images (such as CT / MRI), electronic medical records, and pathology reports. However, this data is widely dispersed across various medical institutions and research units, forming serious "data silos" that hinder cross-domain collaborative research.

[0003] Existing data sharing methods mainly rely on data copying or building centralized data warehouses, but such methods pose significant privacy risks. Even after de-identification, patients can still be re-identified through cross-comparison, violating increasingly stringent laws and regulations such as GDPR (General Data Protection Regulation), HIPAA (Health Insurance Portability and Accountability Act), and my country's Personal Information Protection Law.

[0004] To address privacy challenges, the industry has explored various technical approaches, but significant limitations remain: First, simple encrypted query schemes typically require data decryption before computation, failing to fundamentally eliminate the risk of leakage; second, while privacy-preserving computation methods, such as federated learning, can achieve "data remains stationary while the model moves," their design focuses on collaborative model training, making it difficult to support flexible, ad-hoc, multi-dimensional fusion queries (e.g., "identify patients with a pathological diagnosis of diffuse large B-cell lymphoma, immunohistochemical results indicating dual expression of MYC and BCL2, and PET / CT evaluation showing hypermetabolic lesions").

[0005] More importantly, most current solutions "emphasize technology but neglect governance," lacking a unified, automated, and trustworthy technical governance framework for the entire data lifecycle (including authorization, access, computation, and auditing), and thus failing to achieve verifiable, traceable, and sustainable incentives for query behavior.

[0006] Therefore, there is an urgent need for an innovative governance method for large-scale vertical model platforms that can truly achieve data availability without visibility at the underlying technology level, while supporting complex and flexible multimodal fusion queries and embedding compliant, transparent, and automated governance mechanisms. Summary of the Invention

[0007] The purpose of this application is to provide a multimodal biomedical data security fusion query governance method and system to solve the problems of data silos, privacy leaks, insufficient query flexibility and lack of governance mechanisms in the existing technology, and to achieve the integrated governance goal of data not leaving the domain, being usable but not visible, having auditable processes and being incentivized for contributions.

[0008] The first objective of this application is to provide a method for the secure fusion query governance of multimodal biomedical data.

[0009] The aforementioned objective of this application is achieved through the following technical solution:

[0010] A method for secure fusion query governance of multimodal biomedical data, the method comprising:

[0011] Receive a fusion query request from the querying party, the fusion query request being associated with at least two heterogeneous biomedical data modalities;

[0012] The legality of the fusion query request is verified using a blockchain smart contract;

[0013] Based on the preset multimodal metadata ontology model, the fusion query request that has passed the legality verification is parsed and decomposed into multiple sub-query tasks, and distributed to the corresponding data holder nodes;

[0014] Each data holder node executes a corresponding subquery task based on the raw biomedical data stored locally in its local privacy-preserving computing environment, generating intermediate results identified by a Uniform pseudonym, and the raw biomedical data does not leave its local storage location.

[0015] Perform privacy-preserving data alignment and aggregation operations on the intermediate results to obtain the fused query results;

[0016] The fused query results are returned to the querying party, and key events of the query execution process are recorded in the blockchain smart contract to achieve verifiable compliance governance.

[0017] Preferably, the step of verifying the legitimacy of the fusion query request through a blockchain smart contract includes:

[0018] The blockchain smart contract reads a preset access control policy, which includes at least one of the following: the identity of the querying party, the data modality type, the research purpose, and the patient's informed consent status.

[0019] Verify whether the fusion query request satisfies the access control policy;

[0020] If the conditions are met, the query is deemed valid and allowed to proceed to the subsequent parsing process; otherwise, the query is rejected and recorded in the audit log.

[0021] Preferably, the pre-defined multimodal metadata ontology model parses and decomposes the fusion query request that has passed legality verification into multiple sub-query tasks, including:

[0022] Identify each data modality field involved in the fusion query request and determine the logical relationship between each data modality field;

[0023] Based on the multimodal metadata ontology model, each data modality field is mapped to the data resource descriptor registered by the corresponding data holder node.

[0024] Based on the logical relationship and mapping results, a structured subquery task is generated for each target node, along with a unified pseudonym generation rule.

[0025] Preferably, each data holder node, within its local privacy-preserving computing environment, executes a corresponding sub-query task based on its locally stored raw biomedical data, including:

[0026] Each data holder node loads a signed and verified subquery script in its local privacy-preserving computing environment, wherein the privacy-preserving computing environment is a hardware-based trusted execution environment or a cryptographic-based encrypted computing environment.

[0027] The corresponding raw biomedical data is read from the local database of each data holder node, and the query logic corresponding to the sub-query script is executed in the privacy-preserving computing environment;

[0028] A uniform deterministic hash function is applied to the patient identifiers in the query results to generate a uniform pseudonym identifier;

[0029] The output contains only intermediate results of the unified pseudonym identifier and query fields, and removes the original biomedical data in the privacy-preserving computing environment.

[0030] Preferably, the privacy-preserving data alignment and aggregation operation performed on the intermediate results includes:

[0031] Each data holder node extracts a Uniform Kana ID from the intermediate results it generates, forming its own set of Uniform Kana IDs.

[0032] Based on their respective unified pseudonym identifier sets, each data holder node collaboratively executes a privacy set intersection protocol to determine a subset of common pseudonym identifiers corresponding to cross-modal common patients. The privacy set intersection protocol is implemented through secure multi-party computation or homomorphic encryption.

[0033] Based on the common pseudonym subset, each data holder node extracts the query field value corresponding to the common pseudonym subset in its local privacy-preserving computing environment, and performs statistical aggregation or desensitization processing on the query field value through secure multi-party computation or homomorphic encryption to generate a fused query result.

[0034] The privacy set intersection protocol and aggregation process are completed without exposing the original biomedical data, the patient's real identity information, or other node private data to any participating party or third party in plaintext.

[0035] Preferably, recording key events of the query execution process in the blockchain smart contract includes:

[0036] After the fusion query is completed, each participating data holder node submits its operation log summary to the blockchain smart contract. The operation log summary includes the task reception time, the subquery execution time, and the hash value of the intermediate results.

[0037] The blockchain smart contract automatically generates a query audit record based on the received operation log summary and stores it on the blockchain. The query audit record includes the query ID, a list of participating nodes, the hash value of the fused query result, a timestamp, and the contribution score of each node.

[0038] The blockchain smart contract further executes the incentive distribution logic automatically according to the preset contribution model, and distributes platform digital rights rewards corresponding to the contribution of each data holder node. The platform digital rights rewards are used to represent the value of data contribution and can be used for resource exchange for subsequent query services or acquisition of governance rights.

[0039] Preferably, the method further includes:

[0040] If any data holder node fails to return an intermediate result within the preset time limit, the querying party or the blockchain smart contract will trigger a partial fusion process, performing privacy-preserving data alignment and aggregation operations only based on the returned intermediate results, and marking the missing data modality types and corresponding data coverage in the fusion query results;

[0041] or

[0042] When it is detected that the privacy-preserving computing environment or subquery task of any data holder node fails the security verification, the node automatically suspends the subquery task, clears the intermediate results generated in its local privacy-preserving computing environment, and submits the failure to pass the security verification as a critical event to the blockchain smart contract for recording.

[0043] The second objective of this application is to provide a multimodal biomedical data security fusion query and governance system.

[0044] The second objective of this application is achieved through the following technical solution:

[0045] A multimodal biomedical data security fusion query and governance system, the system comprising:

[0046] The query receiving module is used to receive a fusion query request from the querying party, wherein the fusion query request is associated with at least two heterogeneous biomedical data modalities;

[0047] The legitimacy verification module is used to verify the legitimacy of the fusion query request through a blockchain smart contract;

[0048] The task parsing and distribution module is used to parse and decompose the fusion query request that has passed the legality verification into multiple sub-query tasks based on the preset multimodal metadata ontology model, and distribute them to the corresponding data holder nodes.

[0049] The intermediate result generation module is deployed on each data holder node. It is used to execute corresponding sub-query tasks based on the raw biomedical data stored locally in its local privacy-preserving computing environment, and generate intermediate results identified by a unified pseudonym identifier. The raw biomedical data does not leave its local storage location.

[0050] The data fusion module is used to perform privacy-preserving data alignment and aggregation operations on the intermediate results to obtain fused query results;

[0051] The result return and on-chain module is used to return the fused query result to the querying party and record key events of the query execution process in the blockchain smart contract to achieve verifiable compliance governance.

[0052] Preferably, when the legitimacy verification module performs legitimacy verification on the fusion query request through a blockchain smart contract, it is specifically used for:

[0053] The blockchain smart contract reads a preset access control policy, which includes at least one of the following: the identity of the querying party, the data modality type, the research purpose, and the patient's informed consent status.

[0054] Verify whether the fusion query request satisfies the access control policy;

[0055] If the conditions are met, the query is deemed valid and allowed to proceed to the subsequent parsing process; otherwise, the query is rejected and recorded in the audit log.

[0056] Preferably, when the task parsing and distribution module executes a preset multimodal metadata ontology model to parse and decompose the fusion query request that has passed the validity verification into multiple sub-query tasks, it is specifically used for:

[0057] Identify each data modality field involved in the fusion query request and determine the logical relationship between each data modality field;

[0058] Based on the multimodal metadata ontology model, each data modality field is mapped to the data resource descriptor registered by the corresponding data holder node.

[0059] Based on the logical relationship and mapping results, a structured subquery task is generated for each target node, along with a unified pseudonym generation rule.

[0060] Preferably, the intermediate result generation module executes corresponding sub-query tasks based on the raw biomedical data stored locally by each data holder node in its local privacy-preserving computing environment.

[0061] When, specifically used for:

[0062] Load the signed and verified subquery script in the local privacy-preserving computing environment of each data holder node, wherein the privacy-preserving computing environment is a trusted execution environment or a homomorphic encrypted computing environment;

[0063] The corresponding raw biomedical data is read from the local database of each data holder node, and the query logic corresponding to the sub-query script is executed in the privacy-preserving computing environment;

[0064] A uniform deterministic hash function is applied to the patient identifiers in the query results to generate a uniform pseudonym identifier;

[0065] The output contains only intermediate results of the unified pseudonym identifier and query fields, and removes the original biomedical data in the privacy-preserving computing environment.

[0066] Preferably, when the data fusion module performs privacy-preserving data alignment and aggregation operations on the intermediate results, it is specifically used for:

[0067] Each data holder node extracts a Uniform Kana ID from the intermediate results it generates, forming its own set of Uniform Kana IDs.

[0068] Based on their respective unified pseudonym identifier sets, each data holder node collaboratively executes a privacy set intersection protocol to determine a subset of common pseudonym identifiers corresponding to cross-modal common patients. The privacy set intersection protocol is implemented through secure multi-party computation or homomorphic encryption.

[0069] Based on the common pseudonym subset, each data holder node extracts the query field value corresponding to the common pseudonym subset in its local privacy-preserving computing environment, and performs statistical aggregation or desensitization processing on the query field value through secure multi-party computation or homomorphic encryption to generate a fused query result.

[0070] The privacy set intersection protocol and aggregation process are completed without exposing the original biomedical data, the patient's real identity information, or other node private data to any participating party or third party in plaintext.

[0071] Preferably, the result return, when the on-chain module executes the recording of key events in the query execution process in the blockchain smart contract, is specifically used for:

[0072] After the fusion query is completed, the operation log summary submitted by each participating data holder node is received. The operation log summary includes the task reception time, the subquery execution time, and the hash value of the intermediate results.

[0073] The blockchain smart contract automatically generates a query audit record based on the received operation log summary and stores it on the blockchain. The query audit record includes the query ID, a list of participating nodes, the hash value of the fused query result, a timestamp, and the contribution score of each node.

[0074] The blockchain smart contract further executes the incentive distribution logic automatically according to the preset contribution model, and distributes platform digital rights rewards corresponding to the contribution of each data holder node. The platform digital rights rewards are used to represent the value of data contribution and can be used for resource exchange for subsequent query services or acquisition of governance rights.

[0075] Preferably, the system further includes:

[0076] The fault-tolerant module is used to trigger a partial fusion process by the querying party or the blockchain smart contract when any data holder node fails to return intermediate results within a preset time limit. It performs privacy-preserving data alignment and aggregation operations only based on the returned intermediate results and marks the missing data modality types and corresponding data coverage in the fusion query results.

[0077] and / or

[0078] The security response module is used to automatically suspend the subquery task, clear the intermediate results generated in its local privacy-preserving computing environment, and submit the failure to pass security verification as a critical event to the blockchain smart contract for recording when it detects that the privacy-preserving computing environment or subquery task of any data holder node fails security verification.

[0079] The third objective of this application is to provide an electronic device.

[0080] The aforementioned objective three of this application is achieved through the following technical solution:

[0081] An electronic device, comprising:

[0082] The method includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the multimodal biomedical data security fusion query governance method described in any one of the first objectives of this application.

[0083] The fourth objective of this application is to provide a computer-readable storage medium.

[0084] The fourth objective of this application is achieved through the following technical solution:

[0085] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the multimodal biomedical data security fusion query governance method described in any one of the first objectives of this application.

[0086] Compared with the prior art, this application has the following beneficial effects:

[0087] 1. The original data does not leave the domain. It is processed through a trusted execution environment or homomorphic encryption, and combined with privacy set intersection and security aggregation to achieve usability without visibility, effectively preventing patient re-identification and meeting the requirements of domestic and international privacy regulations;

[0088] 2. Based on a multimodal metadata ontology model, it supports ad-hoc fusion queries with arbitrary logical combinations, breaking through the limitation that federated learning is only applicable to fixed models and adapting to real scientific research scenarios.

[0089] 3. Embed access control, audit trails, and policy enforcement into blockchain smart contracts to achieve pre-authorization, in-process control, and post-event traceability throughout the entire lifecycle of queries;

[0090] 4. Digital rights rewards will be automatically distributed on the platform based on contributions, which can be used for resource exchange or governance participation, thereby stimulating the long-term willingness of data holders to share data.

[0091] 5. Supports automatic termination of timeout partial fusion and security verification failures, ensuring that the system can still operate safely and provide interpretable results under abnormal conditions. Attached Figure Description

[0092] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0093] Figure 1 This is a flowchart illustrating the multimodal biomedical data security fusion query governance method in one embodiment of this application;

[0094] Figure 2 This is a schematic diagram of the structure of a multimodal biomedical data security fusion query governance system in one embodiment of this application;

[0095] Figure 3 This is a general framework diagram of a multimodal biomedical data security fusion query governance system according to one embodiment of this application;

[0096] Figure 4 This is a schematic diagram of the structure of the electronic device in the embodiments of this application. Detailed Implementation

[0097] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0098] In the embodiments provided in this application, it should be understood that the disclosed methods and systems can be implemented in other ways. The system embodiments described below are merely illustrative. For example, the division of units and modules is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or modules can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, and can be electrical, mechanical, or other forms.

[0099] In addition, each functional unit in the various embodiments of this application can be integrated into a single processor, or each unit can be a separate device, or two or more units can be integrated into a single device; each functional unit in the various embodiments of this application can be implemented in hardware or in the form of hardware plus software functional units.

[0100] Those skilled in the art will understand that all or part of the steps of the following method embodiments can be implemented by program instructions and related hardware. The aforementioned program instructions can be stored in a computer-readable storage medium. When the program instructions are executed, they perform the steps of the following method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0101] 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 number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "a plurality of" or "several" means two or more, unless otherwise explicitly specified.

[0102] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below. It should be noted that the core innovative ideas of this application can be implemented through a variety of specific technical means.

[0103] like Figure 1 As shown in the embodiments of this application, a method for the secure fusion query governance of multimodal biomedical data is provided, which may include the following steps:

[0104] S1, receive a fusion query request from the querying party, wherein the fusion query request is associated with at least two heterogeneous biomedical data modalities;

[0105] In real-world scientific or clinical research scenarios, researchers (i.e., the querying party) often need to analyze patient information across dimensions to reveal disease mechanisms.

[0106] For example, a doctor at a hematology treatment center might submit a fusion query request through a vertical big data model platform: 'Statistics on the median progression-free survival (PFS) of all patients pathologically diagnosed with diffuse large B-cell lymphoma, with immunohistochemical results indicating double expression of MYC and BCL2, and PET / CT scans showing hypermetabolic lesions, after receiving first-line immunotherapy within the past five years.' This request explicitly links three typical heterogeneous biomedical data modalities: pathological / immunohistochemical data (diagnosis of diffuse large B-cell lymphoma and double expression of MYC and BCL2), medical imaging data (PET / CT hypermetabolic lesions), and electronic medical record / treatment record data (first-line immunotherapy usage and PFS). The vertical big data model platform first receives and parses such complex fusion query requests as the starting point for subsequent processing.

[0107] S2 verifies the legitimacy of fusion query requests through blockchain smart contracts;

[0108] Upon receiving a fusion query request, the system does not immediately perform calculations. Instead, it first invokes a smart contract deployed on the blockchain for a rigorous legitimacy review. This smart contract incorporates access control policies agreed upon by the data providers. In this scenario, the contract automatically verifies: whether the researcher's identity has been verified by the platform (e.g., belonging to a collaborating research institution); whether the declared research objective (tumor targeted therapy research) is within the authorized scope; and whether all patients involved have signed broad informed consent forms covering this type of research. Only when all preset policies are satisfied is the request deemed legitimate and allowed to proceed to the next step of the parsing process; otherwise, the request is rejected, and the audit log of this illegal attempt is permanently recorded on the blockchain to ensure the transparency and credibility of the governance process. It should be noted that, to enable the aforementioned verification of patient informed consent status, each data holder node, when registering its data resources with the platform, must simultaneously pre-write a summary of the informed consent status of patients in its data set (e.g., the number of patients authorized for research sharing, or the Merkle root hash of all patient consent statuses) as part of the access control policy into the blockchain smart contract.

[0109] S3, based on a preset multimodal metadata ontology model, parses and decomposes the fusion query request that has passed the legality verification into multiple sub-query tasks, and distributes them to the corresponding data holder nodes;

[0110] For requests that have passed legitimacy verification, semantic parsing is performed using a pre-built multimodal metadata ontology model. This model, stored in a graph database, comprises three core layers: 1) a top-level concept layer defining common concepts such as 'patient', 'genomic variation', 'imaging discovery', and 'clinical event'; 2) a standard terminology layer referencing authoritative medical terminology standards (e.g., SNOMED CT for clinical concepts, LOINC for laboratory tests, and RadLex for imaging); and 3) a local field mapping layer storing the mapping relationships between local database field names registered by each data holder node and the standard terms. Based on this, key elements in the request can be identified, such as "BRCA1 mutation", "MRIBI-RADS≥4", "PARP inhibitor", and "PFS", and the logical relationships between them can be determined (i.e., finding patients who simultaneously meet all conditions). Subsequently, these elements are mapped to the registered data holder nodes: gene sequencing company A (holding genomic data), regional medical imaging center B (holding MRI reports), and collaborating hospital C (holding electronic medical records and treatment records). Ultimately, three structured subquery tasks are automatically generated, along with a unified pseudonymization rule (such as using the shared-key HMAC-SHA256 function), and accurately distributed to the three target nodes.

[0111] S4, each data holder node executes a corresponding subquery task based on the raw biomedical data stored locally in its local privacy-preserving computing environment, generating intermediate results identified by a unified pseudonym identifier, and the raw biomedical data does not leave its local storage location.

[0112] Upon receiving a subquery task, each data holder node executes it within its strictly isolated, privacy-preserving computing environment. For example, Hospital C loads a digitally signed subquery script into its Intel SGX Trusted Execution Environment (TEE) enclave. This subquery task can be generated by the vertical large-scale model platform by decomposing the initiated fusion query request, and then reading the original medical records of relevant hematological patients from its internal database. Inside the TEE, the script executes the query logic, filters out patient records that meet the criteria, and applies a pre-defined unified hash function to their real patient IDs to generate pseudonym identifiers in the form of 'GPID_xxxxxx'. Finally, Hospital C outputs only an intermediate result file containing the pseudonym ID and PFS value (e.g., [GPID_abc123,18]), and immediately clears all original data from the TEE memory after the task is completed, ensuring that sensitive information never leaves its physical boundaries.

[0113] S5 performs privacy-preserving data alignment and aggregation operations on the intermediate results to obtain the fused query results;

[0114] Once all nodes have returned their intermediate results, the privacy-preserving aggregation phase begins. First, each node extracts a unique pseudonym identifier from the intermediate results, forming its own pseudonym set. Next, these nodes collaboratively execute a Privacy Set Intersection (PSI) protocol (preferably using the KKRT protocol based on overt overt transfer (OT)) to accurately identify a subset of patient pseudonyms common to all modalities (e.g., {GPID_abc123, GPID_def456}) without revealing their complete sets. Finally, the statistical computation phase begins. For statistics such as summation, counts, and averages, which can be derived from addition, each node can extract the corresponding query field values ​​locally based on the common pseudonym subset and perform secure aggregation using Paillier additive homomorphic encryption. For ordinal statistics such as the median, the processing method depends on the sample size n: when n ≤ 2, the median is the average of two values, which can be securely calculated using the Paillier scheme described above; when n > 2, the platform will use a secure multi-party computation (MPC) protocol that supports secure ordering, or instead return a privacy-preserving de-identified histogram as the result. Throughout the alignment and aggregation process, no party has access to the other party's original data or any information about non-shared patients.

[0115] S6 returns the merged query results to the querying party and records key events in the query execution process in the blockchain smart contract to achieve verifiable compliance governance.

[0116] The final fusion query results (i.e., statistical conclusions) are securely returned to the original researchers for their research analysis. Simultaneously, key events throughout the query execution process—including operation log summaries submitted by each node (containing time, time consumption, and result hash), automatically generated audit records (containing query ID, participants, and contribution scores), and platform digital rights rewards automatically distributed based on the contribution model—are all written into the blockchain smart contract. This not only provides immutable evidence for the query and achieves full auditability, but also provides immediate and fair rewards to data holders for their contributions through an automated incentive mechanism, forming a closed-loop and sustainable digital governance ecosystem.

[0117] As described above, this embodiment provides a multimodal biomedical data security fusion query governance method. First, it receives a fusion query request from the querying party. Then, it verifies the legitimacy of the fusion query request through a blockchain smart contract. Next, based on a preset multimodal metadata ontology model, it parses and decomposes the legitimacy-verified fusion query request into multiple sub-query tasks and distributes them to the corresponding data holder nodes. Then, each data holder node executes the corresponding sub-query task in its local privacy-preserving computing environment based on its locally stored original biomedical data, generating intermediate results identified by a unified pseudonym, while the original biomedical data remains in its local storage location. Next, it performs privacy-preserving data alignment and aggregation operations on the intermediate results to obtain the fusion query result. Finally, it returns the fusion query result to the querying party and records key events of the query execution process in the blockchain smart contract to achieve verifiable compliance governance.

[0118] This embodiment of the multimodal biomedical data security fusion query governance method successfully resolves the fundamental contradiction between cross-institutional data silos and privacy protection through a collaborative architecture of on-chain smart contract governance and off-chain privacy computation execution. This method ensures that raw data does not leave its domain, achieving usability without visibility of data value; through flexible query decomposition and privacy aggregation, it meets the ad-hoc query needs of complex research scenarios; and through blockchain, it achieves fully verifiable, traceable, and incentivized automated compliance governance. This embodiment's solution, while ensuring the highest level of data security, significantly improves the efficiency, flexibility, and sustainability of multimodal biomedical data collaborative research.

[0119] In one embodiment, the legitimacy verification of a fusion query request is performed via a blockchain smart contract, including:

[0120] The blockchain smart contract reads the preset access control policy, which includes at least one of the following: the identity of the querying party, the data modality type, the research purpose, and the patient's informed consent status.

[0121] Verify whether the merged query request meets the access control policy;

[0122] If the conditions are met, the query is deemed valid and allowed to proceed to the subsequent parsing process; otherwise, the query is rejected and recorded in the audit log.

[0123] This application provides a mechanism for verifying the legitimacy of fused query requests based on blockchain smart contracts. The core of this mechanism lies in embedding the compliance judgment logic for data access into an immutable and automatically executed smart contract, thereby constructing a trustworthy security gate before query execution.

[0124] For example, in a typical multicenter clinical research scenario, a research team at a university-affiliated hospital wants to initiate a study on "early biomarkers for Alzheimer's disease." Their fusion query request needs to simultaneously access data from a collaborating gene sequencing company (providing APOE genotype data), a regional imaging center (providing brain MRI structural imaging data), and another tertiary hospital (providing cognitive scale assessments and electronic medical records). Once this request is submitted to the platform, a legitimacy verification smart contract deployed on the blockchain is immediately triggered.

[0125] The smart contract first reads the access control policy, which is jointly preset and agreed upon by all data holders, from the blockchain. In this scenario, the policy clearly stipulates: 1) the querying party must be a research institution registered with the National Health Commission; 2) the requested "genomic data" modality can only be used for research related to neurodegenerative diseases; 3) the research purpose must be clearly stated as "non-commercial basic research"; 4) all involved patients must have signed informed consent forms containing "cross-institutional research sharing" clauses. The contract then automatically parses the metadata in the fusion query request and verifies item by item whether it meets the above policy requirements.

[0126] If all verifications pass (e.g., the research team is qualified, the research objective matches, and all target patient records are associated with valid informed consent), the smart contract returns a "legitimate" signal to the platform, authorizing the request to proceed to the subsequent task parsing and distribution process. Conversely, if any condition is not met (e.g., some patients are found to have only signed in-hospital use consent and not authorized cross-institutional sharing), the contract will immediately reject the request and automatically generate a structured audit log containing a timestamp, queryer ID, failure reason code, and request hash value, which will be permanently written to the blockchain. This log is visible to all authorized regulatory parties but will not disclose any patient privacy information.

[0127] This embodiment encodes multi-dimensional compliance rules (identity, purpose, data type, patient authorization) into blockchain smart contracts, achieving automated, objective, and verifiable pre-emptive legality review of fusion query requests. On the one hand, it fundamentally eliminates unauthorized or excessive data access, ensuring that every query strictly adheres to ethical norms and laws and regulations. On the other hand, it transforms the traditional trust model relying on manual review or centralized permission management into a decentralized trust model based on cryptography and consensus mechanisms, significantly improving governance efficiency and transparency. Simultaneously, the generated immutable audit logs provide a solid basis for post-event supervision and accountability.

[0128] In one embodiment, based on a preset multimodal metadata ontology model, the fusion query request that has passed legality verification is parsed and decomposed into multiple sub-query tasks, including:

[0129] Identify the data modal fields involved in the fusion query request and determine the logical relationships between the data modal fields;

[0130] Based on the multimodal metadata ontology model, each data modality field is mapped to the data resource descriptor registered by the corresponding data holder node;

[0131] Based on logical relationships and mapping results, a structured subquery task is generated for each target node, along with a unified pseudonym generation rule.

[0132] This embodiment provides a mechanism for fusion query request parsing and task decomposition based on a pre-defined multimodal metadata ontology model. This mechanism aims to address the issues of semantic inconsistency and structural dispersion in heterogeneous biomedical data, automatically transforming high-level semantic queries proposed by users into standardized sub-tasks executable by each data holder, thus laying the foundation for subsequent cross-domain collaborative computing.

[0133] "For example: In a real scientific research scenario, a precision hematology diagnosis and treatment project team submitted a fusion query request through a vertical large model platform: 'Find all patients with a pathological diagnosis of diffuse large B-cell lymphoma, molecular testing reports showing MYC gene rearrangement, and a maximum standardized uptake value (SUVmax) greater than 10 in high-metabolic lesions on PET / CT images, and calculate their three-year progression-free survival (PFS) after first-line immunotherapy.' The natural language expression of this request implicitly contains three heterogeneous data modalities: pathology reports (text), molecular testing data (structured variation or rearrangement information), and medical imaging data (radiological description and quantitative indicators).

[0134] After receiving the legitimately validated request, the vertical-category large-scale model platform first performs deep semantic parsing using a pre-built multimodal metadata ontology model. This ontology model is a knowledge graph constructed by domain experts, explicitly defining standard terms, field structures, and their logical relationships across different modalities. For example, the model maps 'diffuse large B-cell lymphoma' to the corresponding lymphohematopoietic system tumor classification code, standardizes 'MYC gene rearrangement' as a normalized rearrangement event description in a molecular testing report, and associates 'SUVmax>10 in PET / CT images' with a quantitative metabolic activity index field or a predefined image feature label in a structured image report. Simultaneously, the model identifies a logical AND relationship between the three, meaning the target patient must simultaneously meet all three conditions.

[0135] Subsequently, based on the registration information in the ontology model, the aforementioned standardized fields are mapped to the actual data holder nodes: a tertiary hospital A (whose registered data resource descriptor on the platform declares that its pathology database contains a lymphoma pathology diagnosis coding field), a molecular testing institution B (who declares that its testing report database contains a standardized description field of gene rearrangement events), and a medical imaging center C (who declares that its PET / CT structured reporting system outputs an SUVmax numerical field). Based on this mapping relationship and the established logical connection method, the system automatically generates three structured sub-query tasks:

[0136] The task sent to Hospital A is: 'Screen patient records with a pathological diagnosis of diffuse large B-cell lymphoma';

[0137] The task sent to Institution B is: 'Screen sample records that are positive for MYC gene rearrangement';

[0138] The task sent to Imaging Center C is: 'Filter PET / CT examination records with SUVmax>10'.

[0139] Each subtask comes with a unified pseudonym generation rule (e.g., GPID=HMAC-SHA256(original patient ID, globally shared key)) to ensure that different institutions generate the same pseudonym ID for the same patient, providing a key anchor for subsequent cross-modal alignment.

[0140] This embodiment introduces a multimodal metadata ontology model, achieving automated, standardized, and semantically lossless conversion from user natural language or semi-structured queries to machine-executable subtasks. On one hand, it shields the heterogeneity and privacy of the underlying data sources, eliminating the need for the querying party to understand the specific storage formats and field naming of data from various institutions. On the other hand, it ensures the accurate decomposition and distribution of cross-modal query logic, providing a reliable prerequisite for achieving high-precision multi-source data fusion analysis, and significantly improving the platform's usability, interoperability, and query accuracy.

[0141] In one embodiment, each data holder node, within its local privacy-preserving computing environment, executes a corresponding sub-query task based on its locally stored raw biomedical data, including:

[0142] Each data holder node loads a signed and verified subquery script in its local privacy-preserving computing environment, which is either a hardware-based trusted execution environment or a cryptographic-based encrypted computing environment.

[0143] Read the corresponding raw biomedical data from the local databases of each data holder node, and execute the query logic corresponding to the subquery script in a privacy-preserving computing environment;

[0144] A uniform deterministic hash function is applied to the patient identifiers in the query results to generate a uniform pseudonym identifier;

[0145] The output contains only intermediate results of the Unicode identifier and query fields, and removes raw biomedical data from the privacy-preserving computing environment.

[0146] This embodiment provides a mechanism for securely executing subquery tasks within the data holder's local privacy-preserving computing environment. This mechanism ensures that raw biomedical data is always processed within the security boundaries of its own institution, outputting only anonymized intermediate results, fundamentally achieving the privacy protection goal of "data remaining unchanged, value flowing."

[0147] In a cross-institutional research collaboration scenario, a regional hematology imaging and testing collaboration center (as the data holder node) receives a sub-query task distributed by the platform. This task originates from a fusion query request initiated by a vertical large-scale model platform, and its content is: "Filter patients with diffuse large B-cell lymphoma whose PET / CT reports show high metabolic lesions and a maximum standardized uptake value (SUVmax) greater than 10, and return their pseudonym ID and SUVmax value." This task is transmitted in encrypted form and includes a sub-query script signed by the platform's private key.

[0148] The data holder node first starts a hardware-based Trusted Execution Environment (TEE), such as an Intel SGX enclave, on its local server. Before loading the subquery script, its digital signature is verified to ensure the script has not been tampered with. After successful verification, the script is securely loaded into the TEE. Subsequently, the runtime environment in the TEE reads the raw examination reports and corresponding patient identification information from the local PET / CT structured report database and the associated patient master index system. All raw data read (including sensitive information such as patient name, ID number, complete image report, and examination number) exists only in the hardware-protected encrypted memory of the TEE and is completely invisible to the external operating system and network.

[0149] Within the TEE, the subquery script executes predefined logic: parsing each PET / CT report, extracting descriptions of high-metabolic lesions and the maximum standard uptake value (SUVmax) field, and determining whether it meets the screening condition of "SUVmax greater than 10". For records that meet the condition, a predefined unified deterministic hash function (such as HMAC-SHA256, with the key securely distributed by the platform) is applied to the original patient ID to generate a unified pseudonym identifier in the form of "GPID_a3f8e2...". Finally, the TEE outputs only a very simple intermediate result file, containing only key-value pairs such as [GPID_a3f8e2...,12.4] and [GPID_b7c1d9...,15.1], without containing any personally identifiable information.

[0150] Once the task is completed, TEE immediately executes a memory erase command to completely remove all cached raw biomedical data and temporary variables, ensuring no residual risk.

[0151] This embodiment achieves full lifecycle local protection of original sensitive data by deploying a hardware-level or cryptographic-level privacy-preserving computing environment at the data source end and strictly limiting the output content to uniform pseudonym identifiers and necessary query fields. On the one hand, it completely eliminates the possibility of leakage of original data during transmission or computation, meeting the most stringent medical data compliance requirements; on the other hand, through standardized pseudonymous output, it provides a secure and consistent identity anchor for subsequent cross-institutional data alignment, while maintaining the complete control of each participating party over its data, effectively resolving the core contradiction between data usability and privacy protection.

[0152] In one embodiment, performing privacy-preserving data alignment and aggregation operations on intermediate results includes:

[0153] Each data holder node extracts a Uniform Kana ID from the intermediate results it generates, forming its own set of Uniform Kana IDs.

[0154] Based on their respective unified pseudonym identifier sets, each data holder node collaboratively executes a privacy set intersection protocol to determine the common pseudonym identifier subset corresponding to the cross-modal common patient. The privacy set intersection protocol is implemented through secure multi-party computation or homomorphic encryption.

[0155] Based on a common pseudonym subset, each data holder node extracts the query field values ​​corresponding to the common pseudonym subset in its local privacy-preserving computing environment, and performs statistical aggregation or desensitization on the query field values ​​through secure multi-party computation or homomorphic encryption to generate fused query results.

[0156] The privacy set intersection protocol and aggregation process are completed without exposing raw biomedical data, patient identity information, or other node private data to any participating party or third party in plaintext.

[0157] This embodiment provides a method for privacy-preserving data alignment and aggregation operations on intermediate results from multiple data holders. The core of this method lies in accurately identifying patient groups shared across modalities and securely performing statistical calculations without exposing any original patient identities or private data, thereby achieving truly usable but invisible fusion analysis.

[0158] For example, in a multicenter study of non-small cell lung cancer (NSCLC), three institutions returned intermediate results: Hospital A provided a list of pseudonym IDs of patients carrying the "EGFR L858R mutation" and their corresponding gene test values; Imaging Center B provided pseudonym IDs of patients with "solid nodules ≥2cm in diameter shown on lung CT" and their nodule sizes; and the pharmaceutical company's partner hospital C provided pseudonym IDs of patients who "received osimertinib as first-line treatment" and their progression-free survival (PFS). In this case, the platform needs to identify a subset of patients who simultaneously meet all three criteria and calculate their average PFS.

[0159] First, each node extracts a unified pseudonym identifier (e.g., GPID_xxx) from its intermediate results, forming three independent pseudonym sets. Then, the three parties collaboratively execute a Privacy Set Intersection (PSI) protocol, such as a secure multi-party computation protocol based on unintentional transmission (OT). During this protocol's execution, no single party can know the complete contents of the other parties' sets; they only ultimately obtain a single intersection result: {GPID_001, GPID_045, GPID_112}. This represents the common patient subset across the genetic, imaging, and therapeutic modalities.

[0160] Next, each node extracts the corresponding query field value in its local privacy-preserving computing environment (such as TEE or homomorphic encryption environment) based on the common pseudonym subset: Hospital A extracts mutation abundance, Imaging Center B extracts nodule diameter, and Hospital C extracts PFS (e.g., 14 months, 18 months, 12 months). To calculate the average PFS, the three parties use additive homomorphic encryption: Hospital C encrypts its PFS value using its public key and sends it; the other parties perform addition and counting operations on the ciphertext; finally, the authorized party decrypts the data to obtain the sum (44 months) and the number of samples (3), thus obtaining an average PFS ≈ 14.7 months. Throughout the aggregation process, the original PFS values, any information about non-shared patients, and private data from other institutions are not exposed in plaintext to any participating party or third party.

[0161] This embodiment achieves accurate alignment and secure statistics of cross-modal patient records by combining Privacy Set Intersection (PSI) with data sovereignty and patient privacy, while ensuring the data sovereignty of all parties and patient privacy. On the one hand, it completely avoids the re-identification risks and compliance hazards brought about by traditional data splicing or centralized aggregation; on the other hand, it supports flexible statistical aggregation (such as mean, count, distribution) and de-identified output, meeting the needs of scientific research analysis while ensuring the provable security of the calculation process. This mechanism is a key technical link in realizing the reliable fusion and secure data output of multi-source heterogeneous biomedical data, significantly improving the feasibility and security of cross-domain collaborative research.

[0162] In one embodiment, key events of the query execution process are recorded in a blockchain smart contract, including:

[0163] After the fusion query is completed, each participating data holder node submits its operation log summary to the blockchain smart contract. The operation log summary includes the task reception time, the subquery execution time, and the hash value of the intermediate results.

[0164] Based on the received operation log summary, the blockchain smart contract automatically generates a query audit record and stores it on the blockchain. The query audit record includes the query ID, the list of participating nodes, the hash value of the fused query result, the timestamp, and the contribution score of each node.

[0165] The blockchain smart contract further executes the incentive distribution logic automatically according to the preset contribution model, and distributes platform digital rights rewards to each data holder node corresponding to their contribution. The platform digital rights rewards are used to represent the value of data contribution and can be used for resource exchange for subsequent query services or acquisition of governance rights.

[0166] This embodiment provides a mechanism for recording key events in the query execution process on a blockchain smart contract. This mechanism, through on-chain notarization and automated incentives, constructs a transparent, verifiable, and sustainable digital governance closed loop, ensuring the credibility and fairness of multi-institutional collaboration processes.

[0167] For example, after the completion of a cross-institutional study on "prediction of diabetes complication risk," the three institutions participating in this fusion query—a top-tier hospital (providing electronic medical records), a gene testing company (providing SNP data), and a wearable device platform (providing continuous blood glucose monitoring data)—each submit a summary of their operation logs to a smart contract deployed on the consortium blockchain. This summary is not the raw log, but rather structured metadata processed locally, including: task reception time (e.g., 2026-03-20T14:30:00Z), subquery execution time (e.g., 8.2 seconds), and the SHA-256 hash values ​​(e.g., a1b2c3...) of the generated intermediate result files. This information is sufficient to verify whether each node completed the computation task on time and completely, without leaking any business or patient data.

[0168] After collecting log summaries from all participants, the blockchain smart contract automatically triggers the audit log generation logic. It integrates data from all parties to create an immutable query audit log, which includes: a globally unique query ID (e.g., QID-20260320-NSFC01), a list of participating nodes ([Hospital_A, GeneLab_B, Wearable_C]), the hash value of the final merged query result (used for integrity verification), a full-process timestamp, and a contribution score calculated based on preset rules. For example, the contribution model for calculating the contribution score might comprehensively consider factors such as data modality scarcity (gene data has higher weight), number of fields, and response time, resulting in Hospital A scoring 40 points, GeneLab B scoring 50 points, and Equipment Platform C scoring 30 points. The contribution model for calculating the contribution score is as follows: ,in, The scarcity weights of the data modal provided by node i; The number of valid fields in the response of node i; α represents the execution time of the subquery at node i; α, β, and γ are preset adjustment coefficients used to balance the contribution weights of different dimensions. The data modality scarcity weight of all participating nodes involved in this fusion query task. The maximum value of ). This refers to the number of valid fields in the responses of all participating nodes in this fusion query task. The sum of ) This refers to the execution time of subqueries across all participating nodes in this fusion query task. The maximum value of ).

[0169] Subsequently, the smart contract immediately executes the incentive distribution logic: based on the contribution ratio, it automatically distributes a corresponding amount of platform digital equity rewards to the wallet addresses of each node (e.g., a total of 120 points, distributed in a 40:50:30 ratio). These equity rewards are not financial tokens, but rather value certificates within the platform, which can be used to offset computing resource quotas when initiating highly complex queries in the future, or to gain additional weight in platform governance voting.

[0170] This embodiment achieves traceable, quantifiable, and feedback-based governance of the entire data collaboration process by recording key operational events on the blockchain and linking them with automated incentives. On the one hand, leveraging the immutability and transparency of blockchain provides strong evidentiary support for regulatory audits and dispute tracing; on the other hand, through real-time, objective, and procedural rights allocation, it effectively incentivizes data holders to continuously and effectively participate in the platform ecosystem, solving the core pain points of traditional data sharing, such as the difficulty in measuring contributions and the lack of timely returns, thereby promoting the formation of a healthy and sustainable biomedical data element market.

[0171] In one embodiment, the method further includes:

[0172] If any data holder node fails to return intermediate results within the preset time limit, the querying party or the blockchain smart contract will trigger a partial fusion process. This process will only perform privacy-preserving data alignment and aggregation operations based on the returned intermediate results, and will mark the missing data modality types and corresponding data coverage in the fusion query results.

[0173] When it is detected that the privacy-preserving computing environment or subquery task of any data holder node fails the security verification, the node automatically suspends the subquery task, clears the intermediate results generated in its local privacy-preserving computing environment, and submits the failure to pass the security verification as a critical event to the blockchain smart contract for recording.

[0174] This embodiment provides a fault-tolerance and security response mechanism for abnormal scenarios to ensure the robustness and security of multimodal fusion queries in complex real-world environments. The mechanism designs automated and privacy-preserving response strategies for two typical anomalies: node response timeout and security verification failure, ensuring the system can still operate securely and transparently under partial failures or security threats.

[0175] For example, in a "Rare Disease Multi-omics Joint Analysis" task involving four institutions, the pre-defined sub-query task required simultaneous data acquisition from a gene sequencing company, an imaging center, an electronic medical record database, and a biobank. However, during execution, the biobank node failed to return intermediate results within the pre-defined 30-second time limit due to internal system maintenance. At this point, the platform detected a timeout event, and a partial fusion process was automatically triggered by a blockchain smart contract. The system performed privacy-preserving data alignment and aggregation operations based only on the intermediate results already returned by the other three institutions (genes, images, and medical records), generating preliminary statistical results. Simultaneously, the final fusion query results returned to researchers explicitly indicated: "Missing modality: proteomics data; Current data coverage: 75% (3 / 4 modality)." This annotation allows researchers to accurately assess the completeness and potential bias of the results, avoiding misjudgments.

[0176] For example, in another query, when a regional hospital node loads a subquery script, the remote proof of its Local Trusted Execution Environment (TEE) fails platform verification (e.g., the enclave code metric is detected as inconsistent with expectations, potentially indicating tampering). In this case, the node immediately and automatically aborts the subquery task, forcibly clears the script already loaded in its TEE memory and any temporarily generated intermediate results, and submits the security verification failure event as a structured log (including timestamp, failure type, and node ID) to the blockchain smart contract. This event is recorded as a critical audit entry for platform administrators to trace and triggers temporary isolation of the node to prevent potential malicious behavior from affecting overall computational trustworthiness.

[0177] This embodiment significantly enhances the system's usability and defense capabilities by introducing a dual mechanism of partial fusion driven by timeout and automatic circuit breaking driven by security. On the one hand, it avoids total failure under common faults such as network latency and node downtime, providing usable results with clear confidence levels, thus enhancing user experience and research efficiency. On the other hand, when facing security risks such as compromised computing environments or script tampering, it achieves rapid local self-destruction and global event reporting, effectively curbing the spread of risks and ensuring the computational integrity and data security of the entire platform. This mechanism makes the system not only usable but also reliable, trustworthy, and interpretable.

[0178] like Figures 2-3 As shown in the embodiments of this application, a multimodal biomedical data security fusion query and governance system is provided, which may include:

[0179] The query receiving module 201 is used to receive a fusion query request from the querying party, the fusion query request being associated with at least two heterogeneous biomedical data modalities;

[0180] The legality verification module 202 is used to verify the legality of the fusion query request through a blockchain smart contract;

[0181] The task parsing and distribution module 203 is used to parse and decompose the fusion query request that has passed the legality verification into multiple sub-query tasks based on the preset multimodal metadata ontology model, and distribute them to the corresponding data holder nodes.

[0182] Intermediate result generation module 204 is deployed on each data holder node. It is used to execute corresponding subquery tasks based on the raw biomedical data stored locally in its local privacy-preserving computing environment, and generate intermediate results identified by a unified pseudonym identifier, without the raw biomedical data leaving its local storage location.

[0183] Data fusion module 205 is used to perform privacy-preserving data alignment and aggregation operations on intermediate results to obtain fused query results;

[0184] The result is returned to the on-chain module 206, which is used to return the fused query result to the querying party and record key events of the query execution process in the blockchain smart contract to achieve verifiable compliance governance.

[0185] In one embodiment, when the legitimacy verification module 202 performs legitimacy verification of the fusion query request through a blockchain smart contract, it is specifically used for:

[0186] The blockchain smart contract reads the preset access control policy, which includes at least one of the following: the identity of the querying party, the data modality type, the research purpose, and the patient's informed consent status.

[0187] Verify whether the merged query request meets the access control policy;

[0188] If the conditions are met, the query is deemed valid and allowed to proceed to the subsequent parsing process; otherwise, the query is rejected and recorded in the audit log.

[0189] In one embodiment, when the task parsing and distribution module 203 executes a fusion query request that has passed legality verification and decomposes it into multiple sub-query tasks based on a preset multimodal metadata ontology model, it is specifically used for:

[0190] Identify the data modal fields involved in the fusion query request and determine the logical relationships between the data modal fields;

[0191] Based on the multimodal metadata ontology model, each data modality field is mapped to the data resource descriptor registered by the corresponding data holder node;

[0192] Based on logical relationships and mapping results, a structured subquery task is generated for each target node, along with a unified pseudonym generation rule.

[0193] In one embodiment, when the intermediate result generation module 204 executes corresponding sub-query tasks based on the raw biomedical data stored locally by each data holder node in its local privacy-preserving computing environment, it is specifically used for:

[0194] Load the signed and verified subquery script in the local privacy-preserving computing environment of each data holder node, where the privacy-preserving computing environment is a trusted execution environment or a homomorphic encrypted computing environment;

[0195] Read the corresponding raw biomedical data from the local databases of each data holder node, and execute the query logic corresponding to the subquery script in a privacy-preserving computing environment;

[0196] A uniform deterministic hash function is applied to the patient identifiers in the query results to generate a uniform pseudonym identifier;

[0197] The output contains only intermediate results of the Unicode identifier and query fields, and removes raw biomedical data from the privacy-preserving computing environment.

[0198] In one embodiment, when the data fusion module 205 performs privacy-preserving data alignment and aggregation operations on intermediate results, it is specifically used for:

[0199] Each data holder node extracts a Uniform Kana ID from the intermediate results it generates, forming its own set of Uniform Kana IDs.

[0200] Based on their respective unified pseudonym identifier sets, each data holder node collaboratively executes a privacy set intersection protocol to determine the common pseudonym identifier subset corresponding to cross-modal common patients. The privacy set intersection protocol is implemented through secure multi-party computation or homomorphic encryption.

[0201] Based on a common pseudonym subset, each data holder node extracts the query field values ​​corresponding to the common pseudonym subset in its local privacy-preserving computing environment, and performs statistical aggregation or desensitization on the query field values ​​through secure multi-party computation or homomorphic encryption to generate fused query results.

[0202] The privacy set intersection protocol and aggregation process are completed without exposing raw biomedical data, patient identity information, or other node private data to any participating party or third party in plaintext.

[0203] In one embodiment, the result returned is used when the on-chain module 206 records key events of the query execution process in the blockchain smart contract, specifically for:

[0204] After the fusion query is completed, the operation log summary submitted by each participating data holder node is received. The operation log summary includes the task reception time, the subquery execution time, and the hash value of the intermediate results.

[0205] Based on the received operation log summary, the blockchain smart contract automatically generates a query audit record and stores it on the blockchain. The query audit record includes the query ID, the list of participating nodes, the hash value of the fused query result, the timestamp, and the contribution score of each node.

[0206] The blockchain smart contract further executes the incentive distribution logic automatically according to the preset contribution model, and distributes platform digital rights rewards to each data holder node corresponding to their contribution. The platform digital rights rewards are used to represent the value of data contribution and can be used for resource exchange for subsequent query services or acquisition of governance rights.

[0207] In one embodiment, the system may further include:

[0208] The fault-tolerant module is used to trigger part of the fusion process by the querying party or the blockchain smart contract when any data holder node fails to return intermediate results within a preset time limit. It performs privacy-preserving data alignment and aggregation operations only based on the returned intermediate results, and marks the missing data modality types and corresponding data coverage in the fusion query results.

[0209] In one embodiment, the system may further include:

[0210] The security response module is used to automatically suspend the subquery task, clear the intermediate results generated in its local privacy-preserving computing environment, and submit the failure to pass security verification as a critical event to the blockchain smart contract for recording when it detects that the privacy-preserving computing environment or subquery task of any data holder node fails security verification.

[0211] like Figure 4 As shown, this application provides an electronic device 3, which includes a memory 301, a processor 302, and a computer program 303 stored in the memory 301 and executable on the processor 302. The memory 301 and the processor 302 are connected via a bus 304. When the processor 302 executes the computer program 303, it implements the multimodal biomedical data security fusion query governance method as described in the above method embodiment of this application.

[0212] Specifically, the electronic device 3 can be an intelligent device with memory and processor, such as an industrial control computer, PC, or smart mobile terminal, or a computer component with memory and processor, such as a CPU or GPU.

[0213] In this embodiment, the electronic device 3 may specifically be a server or computing device on the data holder node side, a server of the platform coordinator or query scheduler, a consensus node or client node in the blockchain network, or a terminal device used by the querying party.

[0214] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the multimodal biomedical data security fusion query governance method as described in the above-described method embodiments of this application.

[0215] It should be noted that the multimodal biomedical data security fusion query governance system, electronic device and computer-readable storage medium in the above embodiments have the same working principle and technical effect as the multimodal biomedical data security fusion query governance method in the above embodiments, and will not be repeated here.

[0216] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0217] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0218] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0219] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A multi-modal biomedical data secure fusion query governance method, characterized in that, The method includes: Receive a fusion query request from the querying party, the fusion query request being associated with at least two heterogeneous biomedical data modalities; The legality of the fusion query request is verified using a blockchain smart contract; Based on the preset multimodal metadata ontology model, the fusion query request that has passed the legality verification is parsed and decomposed into multiple sub-query tasks, and distributed to the corresponding data holder nodes; Each data holder node executes a corresponding subquery task based on the raw biomedical data stored locally in its local privacy-preserving computing environment, generating intermediate results identified by a Uniform pseudonym, and the raw biomedical data does not leave its local storage location. Perform privacy-preserving data alignment and aggregation operations on the intermediate results to obtain the fused query results; The fused query results are returned to the querying party, and key events of the query execution process are recorded in the blockchain smart contract to achieve verifiable compliance governance. in, The pre-defined multimodal metadata ontology model parses and decomposes the fusion query request that has passed legality verification into multiple sub-query tasks, including: Identify each data modality field involved in the fusion query request and determine the logical relationship between each data modality field; Based on the multimodal metadata ontology model, each data modality field is mapped to the data resource descriptor registered by the corresponding data holder node. Based on the logical relationship and mapping results, a structured subquery task is generated for each target node, along with a unified pseudonym generation rule; Each data holder node, within its local privacy-preserving computing environment, executes a corresponding sub-query task based on its locally stored raw biomedical data, including: Each data holder node loads a signed and verified subquery script in its local privacy-preserving computing environment, wherein the privacy-preserving computing environment is a hardware-based trusted execution environment or a cryptographic-based encrypted computing environment. The corresponding raw biomedical data is read from the local database of each data holder node, and the query logic corresponding to the sub-query script is executed in the privacy-preserving computing environment; A uniform deterministic hash function is applied to the patient identifiers in the query results to generate a uniform pseudonym identifier; The output contains only intermediate results of the Uniform Pseudo-identifier and the query fields, and removes the original biomedical data in the privacy-preserving computing environment; The privacy-preserving data alignment and aggregation operation performed on the intermediate results includes: Each data holder node extracts a Uniform Kana ID from the intermediate results it generates, forming its own set of Uniform Kana IDs. Based on their respective unified pseudonym identifier sets, each data holder node collaboratively executes a privacy set intersection protocol to determine a subset of common pseudonym identifiers corresponding to cross-modal common patients. The privacy set intersection protocol is implemented through secure multi-party computation or homomorphic encryption. Based on the common pseudonym subset, each data holder node extracts the query field value corresponding to the common pseudonym subset in its local privacy-preserving computing environment, and performs statistical aggregation or desensitization processing on the query field value through secure multi-party computation or homomorphic encryption to generate a fused query result. The privacy set intersection protocol and aggregation process are completed without exposing the original biomedical data, the patient's real identity information, or other node private data to any participating party or third party in plaintext.

2. The multimodal biomedical data secure fusion query governance method of claim 1, wherein, The process of verifying the legitimacy of the fusion query request through a blockchain smart contract includes: The blockchain smart contract reads a preset access control policy, which includes at least one of the following: the identity of the querying party, the data modality type, the research purpose, and the patient's informed consent status. Verify whether the fusion query request satisfies the access control policy; If the conditions are met, the query is deemed valid and allowed to proceed to the subsequent parsing process; otherwise, the query is rejected and recorded in the audit log.

3. The multimodal biomedical data security fusion query governance method according to claim 1, characterized in that, The process of recording key events in the query execution process in the blockchain smart contract includes: After the fusion query is completed, each participating data holder node submits its operation log summary to the blockchain smart contract. The operation log summary includes the task reception time, the subquery execution time, and the hash value of the intermediate results. The blockchain smart contract automatically generates a query audit record based on the received operation log summary and stores it on the blockchain. The query audit record includes the query ID, a list of participating nodes, the hash value of the fused query result, a timestamp, and the contribution score of each node. The blockchain smart contract further executes the incentive distribution logic automatically according to the preset contribution model, and distributes platform digital rights rewards corresponding to the contribution of each data holder node. The platform digital rights rewards are used to represent the value of data contribution and can be used for resource exchange for subsequent query services or acquisition of governance rights.

4. The multimodal biomedical data security fusion query governance method according to any one of claims 1-3, characterized in that, The method further includes: If any data holder node fails to return an intermediate result within the preset time limit, the querying party or the blockchain smart contract will trigger a partial fusion process, performing privacy-preserving data alignment and aggregation operations only based on the returned intermediate results, and marking the missing data modality types and corresponding data coverage in the fusion query results; and / or When it is detected that the privacy-preserving computing environment or subquery task of any data holder node fails the security verification, the node automatically suspends the subquery task, clears the intermediate results generated in its local privacy-preserving computing environment, and submits the failure to pass the security verification as a critical event to the blockchain smart contract for recording.

5. A multimodal biomedical data security fusion query and governance system, characterized in that, The system includes: The query receiving module is used to receive a fusion query request from the querying party, wherein the fusion query request is associated with at least two heterogeneous biomedical data modalities; The legitimacy verification module is used to verify the legitimacy of the fusion query request through a blockchain smart contract; The task parsing and distribution module is used to parse and decompose the fusion query request that has passed the legality verification into multiple sub-query tasks based on the preset multimodal metadata ontology model, and distribute them to the corresponding data holder nodes. The intermediate result generation module is deployed on each data holder node. It is used to execute corresponding sub-query tasks based on the raw biomedical data stored locally in its local privacy-preserving computing environment, and generate intermediate results identified by a unified pseudonym identifier. The raw biomedical data does not leave its local storage location. The data fusion module is used to perform privacy-preserving data alignment and aggregation operations on the intermediate results to obtain fused query results; The result return and on-chain module is used to return the fused query result to the querying party and record key events of the query execution process in the blockchain smart contract to achieve verifiable compliance governance. in, The pre-defined multimodal metadata ontology model parses and decomposes the fusion query request that has passed legality verification into multiple sub-query tasks, including: Identify each data modality field involved in the fusion query request and determine the logical relationship between each data modality field; Based on the multimodal metadata ontology model, each data modality field is mapped to the data resource descriptor registered by the corresponding data holder node. Based on the logical relationship and mapping results, a structured subquery task is generated for each target node, along with a unified pseudonym generation rule; Each data holder node, within its local privacy-preserving computing environment, executes a corresponding sub-query task based on its locally stored raw biomedical data, including: Each data holder node loads a signed and verified subquery script in its local privacy-preserving computing environment, wherein the privacy-preserving computing environment is a hardware-based trusted execution environment or a cryptographic-based encrypted computing environment. The corresponding raw biomedical data is read from the local database of each data holder node, and the query logic corresponding to the sub-query script is executed in the privacy-preserving computing environment; A uniform deterministic hash function is applied to the patient identifiers in the query results to generate a uniform pseudonym identifier; The output contains only intermediate results of the Uniform Pseudo-identifier and the query fields, and removes the original biomedical data in the privacy-preserving computing environment; The privacy-preserving data alignment and aggregation operation performed on the intermediate results includes: Each data holder node extracts a Uniform Kana ID from the intermediate results it generates, forming its own set of Uniform Kana IDs. Based on their respective unified pseudonym identifier sets, each data holder node collaboratively executes a privacy set intersection protocol to determine a subset of common pseudonym identifiers corresponding to cross-modal common patients. The privacy set intersection protocol is implemented through secure multi-party computation or homomorphic encryption. Based on the common pseudonym subset, each data holder node extracts the query field value corresponding to the common pseudonym subset in its local privacy-preserving computing environment, and performs statistical aggregation or desensitization processing on the query field value through secure multi-party computation or homomorphic encryption to generate a fused query result. The privacy set intersection protocol and aggregation process are completed without exposing the original biomedical data, the patient's real identity information, or other node private data to any participating party or third party in plaintext.

6. An electronic device, characterized in that, The method includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the multimodal biomedical data security fusion query governance method as described in any one of claims 1-4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the multimodal biomedical data security fusion query governance method as described in any one of claims 1-4.

Images