A method and system for collaborative processing of multi-center clinical research data

Abstract

This invention discloses a collaborative processing method and system for multi-center clinical research data. The collaborative processing method includes: S1. A coordinator node receives a predefined research task and converts it into a standardized task package; S2. The coordinator node distributes the standardized task package to multiple participating nodes, each of which calculates intermediate results locally and then encrypts the intermediate results; S3. The coordinator node receives the encrypted intermediate results returned by each participating node and performs secure aggregation on the encrypted intermediate results to obtain an aggregated result; S4. The coordinator node updates the model parameters corresponding to the machine learning model based on the aggregated result; S5. The coordinator node repeats steps S2-S4 until the convergence condition is met; S6. The coordinator node outputs the updated model parameters of the machine learning model and stores the task execution record.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and system for collaborative processing of multi-center clinical research data. Background Technology

[0002] In the field of clinical research, multi-center studies require the integration of clinical data from multiple medical institutions to achieve sufficient sample size and data diversity. Currently, the mainstream multi-center clinical research data processing methods mainly include centralized data warehouse models and distributed query models. The centralized data warehouse model uploads anonymized data from each center to a central server for unified storage and analysis; the distributed query model distributes query tasks from the central server, with each center returning statistical results.

[0003] However, existing technologies have the following problems: In a centralized model, data is detached from the hospital's internal environment, and even after anonymization, there is still a risk of re-identification, making it difficult to meet increasingly stringent medical data regulations; different hospitals have different field definitions, coding standards, units, and granularities in their HIS, LIS, RIS, and other systems, resulting in strong data heterogeneity. Traditional ETL processes require a large amount of manual mapping, leading to high standardization costs; in multi-center studies, researchers need to repeatedly coordinate the export of data from each center, making it impossible to know the number of cases that meet the inclusion and exclusion criteria in real time, resulting in long research iteration cycles; issues such as missing data, outliers, and inconsistent recording logic among centers are difficult to control uniformly, leading to biased final analysis results; existing distributed queries cannot support the complex algorithm requirements such as training machine learning models.

[0004] To address the aforementioned technical issues, patent CN113704555A discloses a feature management method based on federated learning in the medical field, including the following steps: mapping international and local value domains to establish a transformation mapping relationship; converting medical data input according to the local value domain into standardized data according to the international value domain based on the transformation mapping relationship; setting a standard feature template based on the disease name targeted by the machine learning model, the standard feature template containing multiple retrieval entries corresponding to the international values ​​of the standardized data; retrieving the required data index based on the retrieval entries of the standard feature template; and initiating a request to other training nodes to train the machine learning model through federated learning based on the selection operation of the data index. While the aforementioned patent discloses a technical concept combining federated learning and semantic mapping, it primarily focuses on feature management and model training scenarios, without addressing the entire collaborative processing process in multi-center clinical research, from ingress and exclusion criteria parsing to multiple types of analysis tasks (including survival analysis, statistical queries, etc.), nor does it cover technical features such as local data quality pre-checking and blockchain-based operation auditing. Therefore, how to achieve efficient collaborative processing of multi-center clinical research data while ensuring data privacy and compliance remains a pressing technical problem to be solved in this field.

[0005] Therefore, in view of the above-mentioned technical problems, the present invention proposes a method and system for collaborative processing of multi-center clinical research data. Summary of the Invention

[0006] The purpose of this invention is to address the shortcomings of existing technologies by providing a multi-center clinical research data collaborative processing method and system. This method involves deploying front-end data processing nodes within each medical center and employing federated learning, trusted execution environments, and standardized semantic mapping technologies.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] A method for collaborative processing of multi-center clinical research data includes:

[0009] S1. The coordinator node receives predefined research tasks, which include screening rules, machine learning model types, and sets of data fields to be extracted. It converts the screening rules into executable query conditions and packages the executable query conditions, machine learning model types, and sets of data fields to be extracted into standardized task packages.

[0010] S2. The coordinator node distributes the standardized task package to multiple participating nodes. Each participating node extracts data from its local regional database based on the set of data fields to be extracted, filters the extracted data according to the executable query conditions, performs local calculations on the filtered data based on the machine learning model to obtain intermediate results, and then encrypts the obtained intermediate results.

[0011] S3. The coordinator node receives the encrypted intermediate results returned by each participating node and performs secure aggregation on the encrypted intermediate results to obtain the aggregated result;

[0012] S4. The coordinator node updates the model parameters corresponding to the machine learning model based on the aggregation results;

[0013] S5. The coordinator node repeats steps S2-S4 until the convergence condition is met;

[0014] S6. The coordinator node outputs the updated model parameters of the machine learning model and stores the task execution record.

[0015] Furthermore, in step S1, the conversion of the filtering rules into executable query conditions is performed using a medical rule engine.

[0016] Furthermore, in step S2, each participating node extracts data from its local regional database based on the set of data fields to be extracted using a semantic mapping module.

[0017] Furthermore, step S2, after filtering the extracted data, also includes performing a quality pre-check on the filtered data; wherein the quality pre-check includes missing rate detection, outlier detection, logical consistency detection, and time sequence detection.

[0018] Furthermore, the encryption process in step S2 employs at least one of homomorphic encryption, secret sharing, or secure multi-party computation techniques for encryption.

[0019] Furthermore, the secure aggregation in step S3 is implemented based on a trusted execution environment.

[0020] Furthermore, in step S5, steps S2-S4 are repeated. During the execution, the coordinator node monitors the quality of the intermediate results returned by each participating node and removes intermediate results with abnormal quality.

[0021] Furthermore, in step S1, the standardized task package is encapsulated using JSON Schema format.

[0022] Furthermore, the convergence condition in step S5 is that the rate of change of the loss function of the global model is lower than a preset threshold or the number of iterations reaches a preset maximum value.

[0023] Correspondingly, a multi-center clinical research data collaborative processing system is also provided, including:

[0024] The receiving module is used to receive predefined research tasks, which include screening rules, machine learning model types, and sets of data fields to be extracted. It converts the screening rules into executable query conditions and packages the executable query conditions, machine learning model types, and sets of data fields to be extracted into a standardized task package.

[0025] The distribution module is used to distribute standardized task packages to multiple participating nodes. Each participating node extracts data from its local regional database based on the set of data fields to be extracted, filters the extracted data according to executable query conditions, performs local calculations on the filtered data based on a machine learning model to obtain intermediate results, and then encrypts the obtained intermediate results.

[0026] The encrypted aggregation module is used to receive the encrypted intermediate results returned by each participating node, and to perform secure aggregation on the encrypted intermediate results to obtain the aggregated result;

[0027] The update module is used to update the model parameters corresponding to the machine learning model based on the aggregation results;

[0028] The loop module is used to repeatedly execute the distribution module, the encryption aggregation module, and the update module until the convergence condition is met.

[0029] The output module is used to output the updated model parameters of the machine learning model and store the task execution record.

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

[0031] 1. Solves the privacy compliance problem of medical data discharge: The original data always stays in the hospital, which complies with the regulatory requirements that data does not leave the country / discharge, greatly reducing the risks of ethical approval and data security.

[0032] 2. Significantly improves the efficiency of multi-center data governance: Based on deep semantic mapping, automatic standardization shortens the field alignment work that traditionally takes weeks or even months to a few days, and it can be reused.

[0033] 3. Supports more complex clinical research analysis tasks: It not only supports simple statistical aggregation, but also advanced modeling tasks such as multi-center machine learning, deep learning, and survival analysis, expanding the depth of multi-center research.

[0034] 4. Improve the reliability of analysis results: Local data quality pre-checks and center-level quality reports enable researchers to quantify the data quality of each center, avoiding the importation and exportation of substandard data.

[0035] 5. Enhance the transparency and auditability of cooperation: Blockchain-based operation logs ensure that all data usage behavior is immutable, facilitating auditing by regulatory agencies or ethics committees.

[0036] 6. Reduce communication bandwidth and central server pressure: Only model parameters or statistics are transmitted, instead of raw data, reducing the transmission volume by 2-3 orders of magnitude. Attached Figure Description

[0037] Figure 1 This is a flowchart of a multi-center clinical research data collaborative processing method provided in Example 1. Detailed Implementation

[0038] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.

[0039] The purpose of this invention is to address the shortcomings of existing technologies by providing a method and system for collaborative processing of multi-center clinical research data.

[0040] Example 1

[0041] This embodiment provides a method for collaborative processing of multi-center clinical research data, such as... Figure 1 As shown, it includes:

[0042] S1. The coordinator node receives predefined research tasks, which include screening rules, machine learning model types, and sets of data fields to be extracted. It converts the screening rules into executable query conditions and packages the executable query conditions, machine learning model types, and sets of data fields to be extracted into standardized task packages.

[0043] S2. The coordinator node distributes the standardized task package to multiple participating nodes. Each participating node extracts data from its local regional database based on the set of data fields to be extracted, filters the extracted data according to the executable query conditions, performs local calculations on the filtered data based on the machine learning model to obtain intermediate results, and then encrypts the obtained intermediate results.

[0044] S3. The coordinator node receives the encrypted intermediate results returned by each participating node and performs secure aggregation on the encrypted intermediate results to obtain the aggregated result;

[0045] S4. The coordinator node updates the model parameters corresponding to the machine learning model based on the aggregation results;

[0046] S5. The coordinator node repeats steps S2-S4 until the convergence condition is met;

[0047] S6. The coordinator node outputs the updated model parameters of the machine learning model and stores the task execution record.

[0048] The method in this embodiment consists of a coordinator node and multiple participating node nodes.

[0049] The coordinator node is deployed at the research lead institution or a trusted third-party organization, and is responsible for defining, distributing, aggregating, and outputting research tasks. The coordinator node can be deployed on a cloud server or the research group's own server, and must be equipped with a central processing unit that supports a trusted execution environment.

[0050] Each participating node is deployed within the participating medical institutions, preferably on hospital servers equipped with at least an 8-core CPU, 32GB of memory, and a CPU supporting a trusted execution environment. For image data processing, an NVIDIA T4 or A10 graphics processor can be selected. Each participating node includes a clinical research data gateway, a front-end data processing engine, and a blockchain log client. The clinical research data gateway connects to the hospital's internal databases (HIS, LIS, EMR, etc.) and has read-only access. The front-end data processing engine includes a semantic mapping module, a data quality management module, and a local feature engineering module, responsible for local data processing and computation. The blockchain log client is responsible for storing operation records.

[0051] In step S1, the coordinator node receives predefined research tasks and converts them into standardized task packages.

[0052] The coordinator node receives research tasks input by researchers through a graphical interface or a DSL (domain-specific language). These research tasks include screening rules, machine learning model types (such as logistic regression, Cox regression, random forest, etc.), and a set of data fields to be extracted.

[0053] For example, in a multicenter study on predicting cardiovascular event risk in diabetic patients, the researchers used the following screening criteria: age ≥18 years, diagnosed with type 2 diabetes, and at least one recorded glycated hemoglobin (HbA1c) test. The input machine learning model was a logistic regression model used to predict whether patients would experience cardiovascular events. The set of data fields to be extracted included seven fields: age, gender, HbA1c level, systolic blood pressure, diastolic blood pressure, LDL cholesterol, and whether a cardiovascular event had occurred.

[0054] After receiving the research task, the coordinator node calls the built-in medical rule engine to convert the natural language filtering rules into executable query conditions. The medical rule engine is built based on the HL7 CQL standard and can convert the filtering rule of being 18 years of age or older, diagnosed with type 2 diabetes, and having at least one glycated hemoglobin record into a conditional statement in structured query language.

[0055] The coordinator node then encapsulates the transformed executable query conditions, machine learning model types, and the set of data fields to be extracted according to JSON Schema format, generating a standardized task package. The data structure of this standardized task package is as follows: the task package identifier field is used to uniquely identify this research task, the query condition field stores the above executable query conditions, the model type field stores data such as logistic regression, and the data field list field stores the names of the fields to be extracted.

[0056] In step S2, the coordinator node distributes the standardized task package to multiple participating nodes. Each participating node processes the standardized task package to obtain intermediate results, and then encrypts the intermediate results.

[0057] The coordinator node distributes the standardized task package generated in step S1, along with the current version of the machine learning model parameters, to all participating nodes in the research. On the first execution, the machine learning model parameters are the initial parameters, that is, all weight coefficients of the logistic regression model are set to 0, and the bias term is set to 0.

[0058] After receiving the standardized task package and model parameters, each participating node executes the following processing flow:

[0059] Each participating node invokes its locally deployed semantic mapping module to map the set of data fields to be extracted from the standardized task package to specific fields in its local regional database. This semantic mapping module incorporates a pre-trained BERT-based medical field alignment model and loads the hospital's local data dictionary, including field names, table names, and value domain codes. The model automatically maps standard variable names to local database fields. For example, the glycated hemoglobin value field in the standardized task package might be named HbA1c in Hospital A's database, located in the laboratory test table; and named glycated hemoglobin in Hospital B's database, located in the test results table. The semantic mapping module automatically identifies these correspondences and maps the standard field names to the actual field names in each hospital's local database, such as lab_results.test_name='HbA1c' AND lab_results.value. For fields that cannot be automatically mapped, the system generates a confirmation list, which is manually confirmed by the hospital's data administrator and then added to the mapping cache for reuse in subsequent tasks.

[0060] Each participating node retrieves the corresponding data records from its local regional database through the clinical research data gateway, based on the mapped field names. Taking the diabetes study mentioned above as an example, patient records meeting the criteria are retrieved from Hospital A's database. Each record contains values ​​for seven fields: age, gender, glycated hemoglobin level, systolic blood pressure, diastolic blood pressure, low-density lipoprotein cholesterol, and whether a cardiovascular event has occurred.

[0061] Each participating node filters the extracted data records based on the executable query conditions in the standardized task package, retaining only those that meet the conditions. For example, if the filtering condition requires patients to be 18 years of age or older, and the database contains some records with empty age entries or records of patients under 18 years of age, these records are excluded.

[0062] This embodiment uses the aforementioned low-resource-dependent lightweight semantic mapping, which eliminates the need to send all data to the center and completes the mapping process within the institute.

[0063] Each participating node performs a quality pre-check on the filtered data records. This pre-check includes missing value detection, outlier detection, logical consistency detection, and chronological order detection. Missing value detection checks if the proportion of missing data in each field exceeds a preset threshold. Outlier detection checks if the values ​​of numerical fields exceed clinically reasonable ranges; for example, a systolic blood pressure exceeding 300 mmHg is considered an outlier. Logical consistency detection checks the logical relationships between fields; for example, a positive result for a pregnancy history field in a male patient's record is considered logically inconsistent. Chronological order detection checks the order of time-related fields; for example, a discharge date earlier than an admission date is considered an incorrect chronological order. For problematic records identified during the quality pre-check, the system generates a structured quality report (JSON format) and pushes it to the coordinator node for researchers to comprehensively assess the reliability of the data from each center. Simultaneously, automatic repair is performed according to preset rules; for example, multiple imputation or mean imputation is used for continuous variables with missing values ​​below a preset threshold (e.g., 10%). It should be noted that automatic repair is only for statistical purposes; the original data remains unchanged.

[0064] This embodiment can avoid low-quality data from contaminating the results of multi-center analysis and assist each center in improving its data acquisition process.

[0065] Each participating node performs local training on the data records that have passed the quality pre-screening, based on the received machine learning model parameters. Since the machine learning model type assumed in this embodiment is a logistic regression model, each participating node uses local data to calculate the gradient of the loss function relative to the model parameters. Specifically, Hospital A uses its stored patient records to obtain a gradient vector of several gradient values ​​according to the gradient calculation formula of logistic regression. This vector represents the direction and magnitude of the current model parameters that need to be adjusted.

[0066] Each participating node encrypts the calculated gradient using either secret sharing or homomorphic encryption. This embodiment uses homomorphic encryption as an example. Each participating node uses the public key pre-distributed by the coordinator node to encrypt the gradient vector, obtaining the encrypted gradient. The encrypted gradient cannot be decrypted by any third party; only the coordinator node, holding the private key, can perform the aggregation operation. After encryption, each participating node returns the encrypted gradient to the coordinator node.

[0067] For imagery or high-throughput omics data, local GPUs can be used for feature extraction.

[0068] In step S3, the coordinator node receives the encrypted intermediate results returned by each participating node and performs secure aggregation on the encrypted intermediate results to obtain the aggregated result.

[0069] The coordinator node receives the cryptographic gradients returned by each participating node. In this embodiment, the secure aggregation of the cryptographic gradients performed by the coordinator node is implemented using a federated averaging algorithm.

[0070] The basic principle of the federated average algorithm is: after the coordinator node collects the gradients uploaded by each participating node, it performs a weighted average of the gradients according to the proportion of the amount of data that each participating node participated in training to the total amount of data, and obtains the aggregated gradient.

[0071] Because this embodiment uses homomorphic encryption, the coordinator node performs addition on all received encryption gradients without decrypting each individual gradient, obtaining the aggregated encryption gradient. Therefore, the coordinator node cannot obtain the gradient information for any single hospital, but it can calculate the weighted sum of the gradients from all hospitals.

[0072] As another implementation, the coordinator node can add random noise that satisfies differential privacy constraints to the aggregated gradient after calculating the weighted average gradient, and then use the noisy aggregated gradient for model parameter updates. The differential privacy parameter ε can be configured according to privacy protection requirements; the smaller ε is, the stronger the privacy protection, but the model accuracy may decrease accordingly.

[0073] As another implementation, secure aggregation can be implemented based on a Trusted Execution Environment (TEE), where the coordinator node and all participating nodes are deployed with CPUs supporting Intel SGX or AMD SEV architectures. Within the TEE, the encrypted gradients uploaded by each participating node are decrypted and then aggregated. The entire decryption and aggregation process is completed within the TEE, and the operating system, virtual machine manager, and other privileged software cannot access the data within the TEE. Even if the coordinator node itself is controlled by an attacker, because the decryption and aggregation operations are performed within the TEE, and because the TEE provides hardware-level isolation for sensitive information such as private keys, the attacker still cannot obtain the original gradient information of each participating node. The TEE scheme can be combined with the aforementioned homomorphic encryption scheme to form a dual protection mechanism.

[0074] This embodiment ensures that the original data always remains within the hospital, and only statistics or gradients that cannot be backed up from the original records leave the hospital network.

[0075] In step S4, the coordinator node updates the model parameters corresponding to the machine learning model based on the aggregation results.

[0076] The coordinator node decrypts the aggregated gradient obtained in step S3 to obtain the plaintext aggregated gradient. Then, the coordinator node multiplies the aggregated gradient by the preset learning rate and adds it to the current version of the model parameters to obtain the updated model parameters.

[0077] In step S5, the coordinator node repeats steps S2-S4 until the convergence condition is met.

[0078] In each iteration, the coordinator node distributes the latest version of the model parameters to each participating node. Each participating node calculates the gradient using its local data based on the same model parameters and returns it encrypted. The coordinator node then aggregates the gradients and updates the model parameters.

[0079] During the iteration process, the coordinator node monitors the L2 norm of the gradients returned by each participating node. Gradients with excessively large L2 norms may indicate that the corresponding participating node has data quality problems or computational anomalies. The coordinator node removes these abnormal gradients and does not participate in safe aggregation.

[0080] After multiple iterations, when the rate of change of the loss function of the global model is lower than a preset threshold, or when the number of iterations reaches a preset maximum value, the model is determined to have converged.

[0081] In step S6, the coordinator node outputs the updated model parameters of the machine learning model and stores the task execution record.

[0082] The coordinator node outputs the model parameters of the finally trained machine learning model. In this embodiment, the final output is the weight coefficient vector and bias term of the logistic regression model. These parameters can be directly deployed into the clinical decision support systems of various hospitals for the prediction of cardiovascular event risk in new diabetic patients.

[0083] Simultaneously, the coordinator node writes key operation records throughout the entire task execution process to the blockchain. These key operation records include: the definition and timestamp of the research task in step S1; the semantic mapping confirmation records and timestamps of each participating node in step S2; the hash values ​​and timestamps of the aggregation results for each iteration in steps S3 to S5; and the hash values ​​and timestamps of the final model parameters in step S6. Each operation record is written to the consortium blockchain in hash form, and each participating node maintains a complete copy of the blockchain. Any party can verify the integrity and immutability of the operation records at any time.

[0084] The technical solution provided in this embodiment organically combines federated learning, semantic mapping, quality pre-screening, secure aggregation, and blockchain notarization to achieve collaborative processing of multi-center clinical research data without the original data leaving the medical institution. Each participating node only exchanges encrypted gradient information, making it impossible to deduce any patient's original data, thus meeting the requirements for medical data privacy protection and regulatory compliance. Through the semantic mapping module with a built-in BERT model, the field alignment work of heterogeneous databases across medical institutions is shortened from traditional manual weeks to automated hours. Local multi-dimensional quality pre-screening prevents low-quality data from contaminating the multi-center analysis results. Blockchain notarization ensures that all operation records are tamper-proof and traceable, meeting regulatory audit requirements.

[0085] Example 2

[0086] The difference between the multi-center clinical research data collaborative processing method provided in this embodiment and Embodiment 1 is as follows:

[0087] This method is also applicable to statistical query tasks. The following explanation uses the calculation of multicenter overall survival rate as an example.

[0088] When the research task defined by the researchers is a statistical query type, the machine learning model type included in the standardized task package generated by the coordinator node is "Kaplan-Meier survival analysis".

[0089] After receiving the standardized task package, each participating node executes the same semantic mapping, data extraction, filtering, and quality pre-screening processes as in step S2 above. During the local computation phase, each participating node calculates two statistics based on its local patient survival data using the Kaplan-Meier method: the number of events and the number of patients at risk. The number of events refers to the number of patients who experienced the target event (such as death) at a specific time point, while the number of patients at risk refers to the number of patients still under observation at a specific time point who have not yet experienced an event.

[0090] Each participating node encrypts the calculated number of events and the number of people at risk, using the same homomorphic encryption or secret sharing technology as the machine learning task, and returns the encrypted statistics to the coordinator node.

[0091] After receiving the encrypted statistics returned by each participating node, the coordinator node performs a secure aggregation operation, summing the event counts and risk numbers of all participating nodes to obtain the global event count and risk number.

[0092] After completing the aggregation, the coordinator node directly calculates and outputs the summary statistics (such as the multicenter KM curve and the combined effect size) based on the global number of events and the number of people at risk, and writes the task execution record to the blockchain.

[0093] Example 3

[0094] The difference between the multi-center clinical research data collaborative processing method provided in this embodiment and Embodiment 1 is as follows:

[0095] In environments that do not support trusted execution environments, differential privacy techniques can be used as an alternative. Specifically, each participating node adds noise that satisfies ε-differential privacy to the gradient before uploading it, providing privacy protection. This scheme requires no special hardware support, but the model accuracy will be slightly compromised.

[0096] If there is a high level of trust among the participating nodes, an unencrypted federated average aggregation scheme can be adopted. Each participating node directly uploads the plaintext gradient, and the coordinator node calculates the weighted average and updates the model parameters. However, each participating node needs to sign a data usage agreement in advance.

[0097] Zero-knowledge proof-based compliance verification can replace blockchain log solutions. Each participating node can generate zero-knowledge proofs to demonstrate that its data mapping operations conform to the task definition without exposing the specific mapping logic.

[0098] A fully decentralized blockchain federated learning scheme can eliminate the need for a coordinator node. Each participating node can automatically aggregate through a smart contract model, further reducing the dependence on a central node, but the communication complexity increases accordingly.

[0099] Example 4

[0100] This embodiment provides a multi-center clinical research data collaborative processing system, including:

[0101] The receiving module is used to receive predefined research tasks, which include screening rules, machine learning model types, and sets of data fields to be extracted. It converts the screening rules into executable query conditions and packages the executable query conditions, machine learning model types, and sets of data fields to be extracted into a standardized task package.

[0102] The distribution module is used to distribute standardized task packages to multiple participating nodes. Each participating node extracts data from its local regional database based on the set of data fields to be extracted, filters the extracted data according to executable query conditions, performs local calculations on the filtered data based on a machine learning model to obtain intermediate results, and then encrypts the obtained intermediate results.

[0103] The encrypted aggregation module is used to receive the encrypted intermediate results returned by each participating node, and to perform secure aggregation on the encrypted intermediate results to obtain the aggregated result;

[0104] The update module is used to update the model parameters corresponding to the machine learning model based on the aggregation results;

[0105] The loop module is used to repeatedly execute the distribution module, the encryption aggregation module, and the update module until the convergence condition is met.

[0106] The output module is used to output the updated model parameters of the machine learning model and store the task execution record.

[0107] It should be noted that the multi-center clinical research data collaborative processing system provided in this embodiment is similar to that in Embodiment 1, and will not be described in detail here.

[0108] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for collaborative processing of multi-center clinical research data, characterized in that, include: S1. The coordinator node receives predefined research tasks, which include screening rules, machine learning model types, and sets of data fields to be extracted. It converts the screening rules into executable query conditions and packages the executable query conditions, machine learning model types, and sets of data fields to be extracted into standardized task packages. S2. The coordinator node distributes the standardized task package to multiple participating nodes. Each participating node extracts data from its local regional database based on the set of data fields to be extracted, filters the extracted data according to the executable query conditions, performs local calculations on the filtered data based on the machine learning model to obtain intermediate results, and then encrypts the obtained intermediate results. S3. The coordinator node receives the encrypted intermediate results returned by each participating node and performs secure aggregation on the encrypted intermediate results to obtain the aggregated result; S4. The coordinator node updates the model parameters corresponding to the machine learning model based on the aggregation results; S5. The coordinator node repeats steps S2-S4 until the convergence condition is met; S6. The coordinator node outputs the updated model parameters of the machine learning model and stores the task execution record.

2. The method for collaborative processing of multi-center clinical research data according to claim 1, characterized in that, In step S1, the filtering rules are converted into executable query conditions through a medical rule engine.

3. The method for collaborative processing of multi-center clinical research data according to claim 1, characterized in that, In step S2, each participating node extracts data from its local regional database based on the set of data fields to be extracted using a semantic mapping module.

4. The method for collaborative processing of multi-center clinical research data according to claim 1, characterized in that, Step S2, after filtering the extracted data, also includes performing a quality pre-check on the filtered data; wherein the quality pre-check includes missing rate detection, outlier detection, logical consistency detection, and time sequence detection.

5. The method for collaborative processing of multi-center clinical research data according to claim 1, characterized in that, The encryption process in step S2 employs at least one of homomorphic encryption, secret sharing, or secure multi-party computation techniques.

6. The method for collaborative processing of multi-center clinical research data according to claim 1, characterized in that, In step S3, secure aggregation is implemented based on a trusted execution environment.

7. The method for collaborative processing of multi-center clinical research data according to claim 1, characterized in that, In step S5, steps S2-S4 are repeated. During the execution, the coordinator node monitors the quality of the intermediate results returned by each participating node and removes intermediate results with abnormal quality.

8. The method for collaborative processing of multi-center clinical research data according to claim 1, characterized in that, In step S1, the standardized task package is encapsulated in JSON Schema format.

9. The method for collaborative processing of multi-center clinical research data according to claim 1, characterized in that, The convergence condition in step S5 is that the rate of change of the loss function of the global model is lower than a preset threshold or the number of iterations reaches a preset maximum value.

10. A processing system based on the collaborative processing method for multi-center clinical research data according to any one of claims 1-9, characterized in that, include: The receiving module is used to receive predefined research tasks, which include screening rules, machine learning model types, and sets of data fields to be extracted. It converts the screening rules into executable query conditions and packages the executable query conditions, machine learning model types, and sets of data fields to be extracted into a standardized task package. The distribution module is used to distribute standardized task packages to multiple participating nodes. Each participating node extracts data from its local regional database based on the set of data fields to be extracted, filters the extracted data according to executable query conditions, performs local calculations on the filtered data based on a machine learning model to obtain intermediate results, and then encrypts the obtained intermediate results. The encrypted aggregation module is used to receive the encrypted intermediate results returned by each participating node, and to perform secure aggregation on the encrypted intermediate results to obtain the aggregated result; The update module is used to update the model parameters corresponding to the machine learning model based on the aggregation results; The loop module is used to repeatedly execute the distribution module, the encryption aggregation module, and the update module until the convergence condition is met. The output module is used to output the updated model parameters of the machine learning model and store the task execution record.

Images