Cell therapy and negative oxygen ion conditioning based exercise system perception prediction method

Abstract

The application is specifically a sports system sensing prediction method based on cell therapy and negative oxygen ion conditioning, relates to the technical field of medical health and artificial intelligence, and comprises: homomorphic encryption is performed on local node pair federal learning model updating and uploading, a central server completes safe aggregation according to a contract to generate a new global model, and a blockchain stores evidence consensus of an aggregation process, a model version and node credit scoring. In the application, a full-link hash evidence storage system from data collection to follow-up iteration is constructed relying on an alliance chain and three types of intelligent contracts; the hash value of each link is bound with the block height of the blockchain to form a hash chain that cannot be tampered with, and in the referral scene, a new node can trace historical data through patient authorization, and it is ensured that follow-up decisions are based on credible information.

Description

Technical Field

[0001] This invention relates to the field of medical health and artificial intelligence interdisciplinary technology, and in particular to a method for predicting motor system perception based on cell therapy and negative oxygen ion conditioning. Background Technology

[0002] Musculoskeletal disorders (such as knee osteoarthritis) are common among middle-aged and elderly people, and their treatment outcomes depend heavily on accurate prediction of motor function recovery and the development of personalized intervention plans.

[0003] Currently, multi-center medical collaboration is a key path to improve the generalization ability of predictive models, but traditional centralized data training requires uploading the private data of each institution to a central server, which is prone to violating relevant laws and regulations, making it difficult to promote multi-center data sharing.

[0004] Meanwhile, existing prediction models are mostly based on single interventions (such as drug therapy or physical rehabilitation only), without integrating the synergistic effect of cell therapy (such as mesenchymal stem cell infusion) and negative oxygen ion conditioning. They also only use clinical scores (such as VAS and ESR) as input, ignoring dynamic motion perception data such as joint angles and EMG electromyography signals collected by IMU sensors, resulting in prediction errors that are often too large and difficult to support precise intervention.

[0005] Therefore, a motion system perception prediction method based on cell therapy and negative oxygen ion conditioning is proposed to address the aforementioned problems. Summary of the Invention

[0006] The purpose of this invention is to propose a motion system perception prediction method based on cell therapy and negative oxygen ion conditioning in order to solve the above-mentioned problems.

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

[0008] Motor system perception prediction methods based on cell therapy and negative oxygen ion conditioning include:

[0009] Step 1: Complete the initialization of the federated learning consortium, the deployment of the blockchain smart contract, and the privacy collection and preprocessing of the local multimodal motion system and dual-intervention data;

[0010] Step 2: Implement multimodal feature fusion and initial model training of federated learning locally, and hash the training metadata to the blockchain to ensure traceability;

[0011] Step 3: Local nodes perform homomorphic encryption on the updated federated learning model and upload it. The central server completes secure aggregation according to the contract to generate a new global model. The blockchain stores and agrees on the aggregation process, model version and node credit score.

[0012] Step 4: Deploy the federated learning global model locally and verify its performance. Based on real-time data, realize personalized prediction of the state of the motion system. At the same time, hash the prediction results and personalized dual intervention scheme to the blockchain to build a trust chain.

[0013] Preferably, the specific content of step one includes:

[0014] Federated learning consortium initialization includes consortium initiation and member admission, as well as initial global model design and distribution:

[0015] Alliance Initiation and Membership Admission:

[0016] Initiate a dual-intervention prediction alliance for musculoskeletal diseases, clarify collaborative goals, and establish membership eligibility criteria:

[0017] Initial global model design and distribution: The central coordination server, in conjunction with the algorithm team, designed a predictive model architecture adapted to multimodal data;

[0018] Based on the smart contract deployed by the consortium blockchain, the rules for multi-center collaboration are defined. The smart contract includes the consortium management contract, the FL collaboration contract, and the data storage contract.

[0019] All participating nodes vote to confirm the smart contract through a practical Byzantine fault-tolerant consensus mechanism to ensure that the contract is immutable, and at the same time configure the corresponding permissions.

[0020] Local multimodal data privacy collection and preprocessing includes data collection and format adaptation, privacy preprocessing, and local encrypted storage.

[0021] Preferably, the specific content of step two includes:

[0022] Multimodal feature fusion and input adaptation include time series alignment and feature association, feature standardization and model input generation;

[0023] Time series alignment and feature association include time axis construction and feature engineering.

[0024] Feature standardization and model input generation involve performing Z-score standardization on the fused features to generate FL model input data that combines feature matrices and labels;

[0025] The local node loads the initial model downloaded from the central server into the training engine, configuring the parameters according to the FL contract:

[0026] After training is complete, the local engine calculates the model weights, i.e., the gradients. Update and perform differential privacy enhancements;

[0027] The local node generates a training metadata report and calculates the SHA-384 hash value of the report;

[0028] It then invokes the data storage contract to submit the hash value, timestamp, and node digital signature to the consortium blockchain; verifies the signature's legality; and after successful verification, packages the hash value into a new block and returns a successful storage receipt.

[0029] Preferably, step three includes the following:

[0030] The local node calls the CKKS homomorphic encryption algorithm to process the gradient after DP. Encryption, including:

[0031] A public and private key pair is generated locally using KMS. The public key is uploaded to the BC contract, and the private key is stored locally.

[0032] Use public key pair Each parameter is encrypted to generate a ciphertext gradient;

[0033] Calculate the MD5 hash value of the ciphertext gradient and upload it along with the ciphertext;

[0034] Local nodes upload the encrypted gradient, MD5 hash value, and proof receipt to the central coordination server, which then performs verification of proof, integrity verification, and timeout handling.

[0035] Preferably, the method further includes:

[0036] The central server counts the number of upload nodes in real time. When the upload rate of active nodes reaches the preset standard and the ciphertext gradient of each node passes the verification, the security aggregation process is triggered.

[0037] The central server calls the FL collaboration contract to obtain the data volume weights of each node, and performs a weighted summation on the ciphertext gradient to obtain the global ciphertext gradient. Then remove through gradient smoothing. outliers;

[0038] The central server generates a decryption request and sends it to all participating nodes. After verifying the validity of the request, each node uses its local private key to decrypt different fragments of the ciphertext global gradient. The decrypted fragments are then aggregated to obtain the plaintext global gradient. ;

[0039] Central server Update the weights of the initial model V0, generate a new global model V1, and calculate the SHA-256 hash value of V1.

[0040] Preferably, the above includes:

[0041] The central server generates an aggregated report, calculates the SHA-384 hash value of the report, and submits it to BC by calling the FL collaboration contract.

[0042] The BC network verifies the aggregate report signature through a practical Byzantine fault-tolerant consensus mechanism. After successful verification, the hash value is packaged into a block, and the model version mapping is updated in the FL collaboration contract. A model V1 download notification is pushed to all local nodes.

[0043] Preferably, step four includes the following:

[0044] The local node downloads the model V1 file from the central server; after the download is complete, it calculates the SHA-256 hash value of V1 and compares it with the V1 hash value stored in the BC contract. If they match, it confirms that the model has not been tampered with; otherwise, it downloads it again.

[0045] The local node deploys model V1 to the clinical prediction engine and tests V1 performance using the latest local test set, including prediction accuracy verification and inference speed verification.

[0046] In clinical settings, local nodes collect real-time motion perception data of patients and extract real-time feature matrices from historical dual intervention records;

[0047] The local prediction engine inputs the real-time feature matrix into model V1, performs inference calculations, and outputs short-term and long-term prediction results.

[0048] Preferably, the method further includes:

[0049] The local node generates a SHA-384 hash value from the patient's anonymity identifier, the prediction result text, the input data hash, and the model V1 hash, and submits it to BC by calling the data storage contract.

[0050] After the BC verification node signs the document, it is uploaded to the blockchain, generating a predictive proof receipt.

[0051] Doctors develop a dual intervention plan based on the prediction results, associate the plan with the prediction evidence receipt ID, and generate a plan hash value for on-chain evidence storage.

[0052] Preferably, step five involves verifying the correlation between follow-up data and historical records using blockchain to achieve full-process traceability, iteratively optimizing the federated learning model based on error case data, and supporting regulatory agencies to conduct multi-center compliance audits through blockchain.

[0053] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0054] 1. This invention constructs a hash-based evidence storage system covering the entire process from data collection to follow-up iteration by relying on consortium blockchains and three types of smart contracts. The hash value of each step is highly bound to the blockchain block, forming an immutable hash chain. In referral scenarios, new nodes can trace historical data through patient authorization, ensuring that follow-up decisions are based on credible information.

[0055] 2. This invention uses a federated learning architecture that ensures data does not leave the local machine as its core, combined with a triple privacy protection mechanism of AES-256-GCM local hardware encryption, differential privacy, and CKKS homomorphic encryption. This avoids the privacy leakage risks of traditional centralized training. At the same time, it adopts a CNN-LSTM-Transformer hybrid model to integrate IMU / EMG dynamic motion perception data with cell therapy and negative oxygen ion dual intervention data, which solves the prediction limitations of single data or intervention and provides a highly reliable decision-making basis for precise clinical intervention. Attached Figure Description

[0056] Further details, features, and advantages of this application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which:

[0057] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0058] Several embodiments of this application will now be described in more detail with reference to the accompanying drawings to enable those skilled in the art to implement this application. This application may be embodied in many different forms and for various purposes and should not be limited to the embodiments set forth herein. These embodiments are provided to make this application thorough and complete, and to fully convey the scope of this application to those skilled in the art. The embodiments described do not limit this application.

[0059] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It will be further understood that terms such as those defined in commonly used dictionaries shall be interpreted as having a meaning consistent with their meaning in the relevant field and / or the context of this specification, and shall not be interpreted in an idealized or overly formal sense unless expressly defined herein.

[0060] Example 1

[0061] Its specific implementation method is combined with the appendix Figure 1 Please provide a detailed explanation.

[0062] Appendix Figure 1 The flowchart of the motor system perception prediction method based on cell therapy and negative oxygen ion conditioning provided in the embodiments of the present invention shows the complete steps from completing the initialization of the federated learning alliance to verifying the correlation between follow-up data and historical evidence through blockchain to achieve full-process traceability.

[0063] In this embodiment, it includes:

[0064] Step 1: Complete the initialization of the federated learning alliance (including member admission, initial model design and distribution), deployment of blockchain smart contracts (defining collaboration rules and permissions), and privacy collection and preprocessing of local multimodal motion system and dual intervention data, laying the foundation for multi-center collaboration;

[0065] The specific content includes:

[0066] Federated learning consortium initialization includes consortium initiation and member admission, as well as initial global model design and distribution:

[0067] Alliance Initiation and Membership Admission:

[0068] A joint intervention prediction alliance for musculoskeletal diseases, initiated by a lead hospital (such as a top-tier orthopedic hospital), should be established, clearly defining collaborative goals (such as predicting the effect of combined mesenchymal stem cell and negative oxygen ion intervention on the recovery of motor function in knee osteoarthritis) and setting membership admission criteria.

[0069] It is necessary to have cell therapy qualifications (such as GCP certification) and a calibration report for negative ion conditioning equipment;

[0070] The local database must support AES-256 encryption and have the necessary conditions for deploying the FL local training engine;

[0071] Submit your organization's qualification documents (such as a medical institution license), and the hash value of these documents must be pre-verified by BC (to ensure that the qualifications are authentic and cannot be tampered with).

[0072] Initial global model design and distribution: The central coordination server (FL core node), together with the algorithm team, designed a predictive model architecture adapted to multimodal data, including the following:

[0073] Model type: A hybrid CNN-LSTM-Transformer model is adopted (CNN extracts spatial features of motion-sensing data, LSTM captures time series patterns, and Transformer enhances the feature attention of dual interventions).

[0074] Initial weight generation: Initial weights are pre-trained based on public datasets (such as the OAInitiative public database) to avoid cold start;

[0075] Model distribution: The model architecture file (.pb format), initial weights (.h5 format), and training configuration (learning rate 0.001, batch size 32) are pushed to all admitted local medical nodes via a TLS1.3 encrypted channel. After receiving the data, the nodes need to return a model reception confirmation hash to BC for evidence storage (to prevent model transmission tampering).

[0076] Based on a consortium blockchain (such as Hyperledger Fabric, adapted for private collaboration scenarios in medical institutions), three types of smart contracts are deployed to define the rules for multi-center collaboration, including:

[0077] Alliance management contract: Stores the list of participating nodes (node ​​ID, public key), admission / exit mechanism (exit requires 30 days' advance notice on the blockchain and completion of historical data hash handover), and node credit scoring rules (credit score will be deducted if model updates are not uploaded on time).

[0078] FL Collaboration Contract: Defines key FL parameters, aggregation algorithm (weighted FedAvg, weight = local data volume of node / total data volume of alliance), update upload time limit (once a week, exceeding the time limit is considered abandoning this round), safe aggregation trigger conditions (≥90% of active nodes must upload updates), and model version management (a new version number is generated for each round of aggregation, which is highly bound to the BC block).

[0079] Data storage contract: Defines hash storage format (e.g., data type-node ID-timestamp-hash value), storage trigger events (local data collection completion, model update upload, intervention execution, prediction result generation), and hash verification interface (supports third-party auditing institutions to call).

[0080] All participating nodes vote to confirm the smart contract through the Practical Byzantine Fault Tolerance (PBFT) consensus mechanism (requiring at least 2 / 3 of the nodes to sign for it), ensuring the contract is immutable; and the following permissions are configured:

[0081] Central server: Only has permissions for model aggregation and version distribution, but no data viewing permissions;

[0082] Local nodes: Only have permissions for local data read / write, model update upload, and hash-based evidence submission;

[0083] Regulatory agencies (such as the National Health Commission) only have the authority to view contracts, verify hashes, and query node credit scores.

[0084] Local multimodal data privacy collection and preprocessing includes data collection and format adaptation, privacy preprocessing, and local encrypted storage;

[0085] The specific details of data collection and format adaptation are as follows:

[0086] Each local node collects motion sensing and dual-intervention data according to the input requirements of the FL model, ensuring a consistent format:

[0087] Motor system sensory data: Knee flexion angle and angular velocity were acquired by IMU sensor (sampling rate 100Hz), and quadriceps electromyography signal (root mean square value RMS) was acquired by EMG sensor. Pain VAS score (0-10 points) and erythrocyte sedimentation rate (ESR) were recorded by clinical system.

[0088] Dual intervention data: Cell therapy (mesenchymal stem cell batch number, viability, infusion dose 1×) / time, infusion time), negative oxygen ion conditioning (concentration 30,000 ions / (Duration of treatment: 40 minutes / session; Target area: knee joint; Stiffness relief score after treatment)

[0089] Data format: Convert to JSON format uniformly, and name the fields according to the FL contract (e.g., joint_angle_knee, stem_cell_batch) to avoid errors in subsequent feature fusion.

[0090] The details of privacy preprocessing and local encrypted storage are as follows:

[0091] The local node implements the following privacy protection measures to ensure that data does not leave the local area and is untraceable:

[0092] Identity de-identification: Patient ID and national ID number are encrypted using the SHA-256 hash algorithm to generate anonymous identifiers (such as PID_8a3f2d...). The hash mapping table is stored locally only and is not transmitted externally.

[0093] Data anonymization: k-anonymization was performed on continuous data (e.g., EMG RMS value of 0.256mV) (grouped by 0.1mV and labeled as 0.2-0.3mV), and generalization was performed on discrete data (e.g., cell batches) (only the batch prefix was retained, such as MSC-202405XX).

[0094] Local encrypted storage: Preprocessed data is stored in a hardware encrypted hard disk (SED) using the AES-256-GCM encryption algorithm. The key is generated by the local node key management system (KMS) and can only be accessed by the local training engine (the key is never shared).

[0095] Step 2: Locally implement multimodal feature fusion (associate motion perception and dual intervention data and standardize them), federated learning initial model training (including gradient difference privacy protection), and simultaneously hash the training metadata to the blockchain to ensure traceability;

[0096] The specific content includes:

[0097] Multimodal feature fusion and input adaptation include time series alignment and feature association, feature standardization and model input generation;

[0098] Time series alignment and feature association include time axis construction and feature engineering.

[0099] Feature standardization and model input generation involve performing Z-score standardization (mean = 0, standard deviation = 1) on the fused features to avoid the magnitude difference between muscle strength (10-50N) and negative oxygen ion concentration affecting model training; finally, FL model input data is generated by combining the feature matrix (number of samples × number of features × time step) and the label (motor function recovery score in the next 14 days);

[0100] Local model loading and training parameter configuration include:

[0101] The local node loads the initial model (version V0) downloaded from the central server into the training engine, configuring the parameters according to the FL contract:

[0102] Optimizer: Adam (learning rate 0.001, weight decay 1e-5);

[0103] Loss function: Mean Squared Error (MSE, adapted to regression-type prediction targets, such as motor function scores);

[0104] Training rounds: 10 rounds of local pre-training (to avoid overfitting, an early stopping mechanism is used, stopping when the validation set MSE does not decrease for 3 consecutive rounds).

[0105] After training is complete, the local engine calculates the model weights, i.e., the gradients. Update and perform differential privacy (DP) enhancements to prevent gradient privacy leaks, specifically including:

[0106] Noise addition: The Laplace noise mechanism is used to calculate the noise intensity based on the local data volume N. ( =0.1, the larger N is The smaller the value, the better the balance between privacy protection and model accuracy. The formula is... ( (for gradient global sensitivity);

[0107] Gradient clipping: For noise-added... Perform L2 pruning (pruning threshold = 1.0) to prevent extreme gradient values ​​from affecting subsequent global aggregation;

[0108] Local validation: Use a local test set to validate the performance of the model after adding noise (e.g., MSE≤0.8 is considered acceptable). If it fails, retrain (adjust the noise intensity). Only after passing the test can the model proceed to the upload stage.

[0109] The local node generates a training metadata report, including: node ID, model version V0, training data volume (e.g., 500 patients), training epochs (10 epochs), local test set MSE (0.75), and gradient noise intensity (…). =0.1), calculate the SHA-384 hash value for this report (the hash value is longer and more secure);

[0110] The data storage contract is invoked through the BC client to submit the hash value, timestamp (accurate to milliseconds), and node digital signature (generated using the local private key) to the consortium blockchain. The BC network verifies the signature's legality (matching the node's public key stored in the contract) through PBFT consensus (3 rounds of voting). After successful verification, the hash value is packaged into a new block (the block contains the hash of the previous block, forming a chain structure), and a successful storage receipt (including block height and transaction ID) is returned. The local node stores the receipt for subsequent auditing.

[0111] Step 3: Local nodes perform homomorphic encryption on the federated learning model update (gradient) and upload it. The central server completes secure aggregation according to the contract to generate a new global model. The blockchain stores and agrees on the aggregation process, model version and node credit score.

[0112] The specific content includes:

[0113] FL model update encryption and upload:

[0114] The local node calls the CKKS homomorphic encryption algorithm (supports floating-point operations and adapts to gradient data types) to process the gradient after DP. Encryption, including:

[0115] Key generation: A public key and private key pair are generated locally using KMS. The public key is uploaded to the BC contract (for use by the central server during aggregation), and the private key is stored locally (only for subsequent decryption of the aggregation results).

[0116] Encryption process: using the public key to... Each parameter (such as the weights of the fully connected layers of the model) is encrypted to generate ciphertext gradients (the length of the ciphertext is 3-5 times that of the plaintext, and it needs to be compressed for transmission).

[0117] Integrity verification: Calculate the MD5 hash value of the ciphertext gradient and upload it along with the ciphertext to prevent tampering during transmission.

[0118] The local node uploads the ciphertext gradient, MD5 hash value, and proof receipt (generated in step two) to the central coordination server via HTTPS and QUIC protocol (fast transmission speed, resistant to packet loss). The central server then performs the following operations:

[0119] Verify the certificate: Call the BC contract to query the training metadata hash of the node to confirm the authenticity of the certificate (to avoid uploading gradients without training);

[0120] Integrity verification: Calculate the MD5 hash value of the received ciphertext gradient and compare it with the uploaded hash value. If they match, the data is accepted; otherwise, a retransmission is requested.

[0121] Timeout handling: If a node fails to upload within the time limit agreed upon in the FL contract (e.g., 24 hours), the central server will call the alliance management contract to deduct the node's credit score and record the timeout in the BC notarization record.

[0122] FL Global Model Secure Aggregation:

[0123] The central server counts the number of upload nodes in real time. When the upload rate of active nodes reaches the preset standard (e.g., ≥90%, such as 18 out of 20 nodes in the alliance completing the upload), and the ciphertext gradient of each node passes the verification, the secure aggregation process is triggered (strictly following the FL contract agreement).

[0124] The central server calls the FL collaboration contract to obtain the data volume weights of each node (e.g., node A has 500 data points, the total data volume of the consortium is 5000, weight = 0.1; node B has 1000 data points, weight = 0.2), and performs a weighted summation on the ciphertext gradient to obtain the global ciphertext gradient. Then remove through gradient smoothing. outliers;

[0125] Weighted summation: After multiplying the ciphertext gradient of each node by its weight, the weighted ciphertext gradients of all nodes are summed to obtain the global ciphertext gradient. (Because HE supports homomorphic addition, it can be calculated without decryption);

[0126] Gradient smoothing: for Perform outlier removal (if the gradient of a node's encrypted text deviates from the mean by more than 3 times the standard deviation, it is considered an outlier, removed, and recalculated) to ensure the robustness of the aggregation results.

[0127] The central server generates a decryption request, including the aggregation completion time, a list of participating nodes, and the ciphertext global gradient hash, and sends it to all participating nodes. After verifying the validity of the request, each node uses its local private key to decrypt different fragments of the ciphertext global gradient (distributed decryption is used, as a single node cannot decrypt independently). The decrypted fragments are then aggregated to obtain the plaintext global gradient. ;

[0128] Central server Update the weights of the initial model V0, generate a new global model V1, and calculate the SHA-256 hash value of V1 (for subsequent distribution verification).

[0129] BC aggregation process and model version verification:

[0130] The central server generates an aggregation report, which includes a list of participating node IDs, the weight of each node, the model V0 hash before aggregation, the model V1 hash after aggregation, the global aggregation MSE (calculated using the decrypted gradient, such as 0.68), the list of decrypted node signatures, calculates the SHA-384 hash value of the report, and calls the FL collaboration contract to submit it to BC.

[0131] The BC network verifies the aggregate report signature using Practical Byzantine Fault Tolerance (PBFT) consensus (all decryption node signatures must match the contract public key). After successful verification, the hash value is packaged into a block, and the model version mapping is updated in the FL collaboration contract (e.g., the block height is mapped to the model V1 hash). At the same time, the contract automatically triggers the model distribution notification, pushing the model V1 download notification (including the download address and V1 hash) to all local nodes.

[0132] The central server calls the alliance management contract to increase credit scores (e.g., +5 points) for nodes that upload on time and meet the gradient requirements, and deduct credit scores (e.g., -3 points) for nodes that time out or are abnormal. The updated results are stored on the blockchain (credit scores are bound to node IDs and affect subsequent alliance permissions; for example, nodes with high scores can participate in model architecture design first).

[0133] Step 4: Deploy the federated learning global model locally and verify its performance. Based on real-time data, realize personalized prediction of the state of the motion system. At the same time, hash the prediction results and personalized dual intervention scheme to the blockchain to build a trust chain.

[0134] The specific content includes:

[0135] The local node receives the model V1 download notification pushed by the BC contract and downloads the model V1 file (.pb format) from the central server through an encrypted channel. After the download is complete, the SHA-256 hash value of V1 is calculated and compared with the V1 hash value stored in the BC contract. If they match, it is confirmed that the model has not been tampered with; if they do not match, the download is restarted (to prevent attacks during the distribution process).

[0136] The local node deploys model V1 to the clinical prediction engine (isolated from the training engine to avoid data confusion) and tests V1 performance using the latest local test set (such as data from 50 patients who did not participate in training), including prediction accuracy verification and inference speed verification.

[0137] Prediction accuracy verification: Calculate the test set MSE (e.g., 0.65, which should be lower than 0.75 for model V0 to prove that the collaborative optimization is effective).

[0138] Inference speed verification: Ensure that the prediction time for a single patient is ≤10 seconds (meeting real-time clinical needs);

[0139] If the performance is not up to standard (e.g., MSE > 0.7), the local node can send a model redistribution request to the central server and record the performance anomaly in BC (for the consortium to investigate the problem, such as whether the gradient is abnormal during aggregation).

[0140] In clinical settings, local nodes collect real-time motion perception data from patients (such as the maximum knee flexion angle of 110°, electromyography RMS of 0.32mV, and VAS score of 5 on the same day) and historical dual intervention records (such as receiving one stem cell infusion and five negative oxygen ion therapy sessions in the past two weeks). Real-time feature matrices (such as motion features and intervention features from the time window T-24h to T0) are extracted according to the feature fusion logic in step two.

[0141] The local prediction engine inputs the real-time feature matrix into model V1, performs inference calculations, and outputs short-term and long-term prediction results (both with confidence levels, such as 95%):

[0142] Short-term prediction (7 days): After 72 hours, the knee joint VAS score will decrease to 3 points, and the range of motion will increase to 125°. Negative oxygen ion therapy needs to be maintained at 30,000 ions / day. concentration;

[0143] Long-term prediction (28 days): 21 days after the completion of the second stem cell infusion, the Lysholm score for motor function can reach 80 points (excellent standard). Be alert to the possibility of a slight increase in ESR on day 14 (it is recommended to add one negative oxygen ion conditioning session in advance).

[0144] The prediction results also include the input data hash, model version V1, and inference timestamp to ensure traceability.

[0145] The local node generates a SHA-384 hash value from the patient's anonymity identifier, the prediction result text, the input data hash, and the model V1 hash, and submits it to BC by calling the data storage contract.

[0146] After the BC verification node signs the data and uploads it to the blockchain, a prediction evidence receipt (including transaction ID and block height) is generated. Doctors can use the receipt to check the authenticity of the prediction results (to prevent human tampering with the prediction report).

[0147] Based on the predicted results, the doctor formulated a dual intervention plan (e.g., administering the second stem cell infusion on June 10, 2024, at a dose of 1.2 × 10⁻⁶). One; negative oxygen ion therapy once daily from June 11th to 17th, concentration 35,000 ions / day. The scheme is associated with the predicted evidence receipt ID, and the scheme hash value is generated and stored on the blockchain.

[0148] Meanwhile, the stem cell batch number and the hash value of the negative oxygen ion device calibration report involved in the plan also need to be linked to the blockchain.

[0149] Step 5: Verify the correlation between follow-up data and historical records using blockchain to achieve full-process traceability. Iterate and optimize the federated learning model based on erroneous case data. Simultaneously, support regulatory agencies in conducting multi-center compliance audits via blockchain, specifically including:

[0150] After the patient follows the intervention protocol, at follow-up time points (e.g., 7 days and 28 days after prediction), the local node collects actual musculoskeletal status data (e.g., actual VAS score of 3 points, joint range of motion of 123°), and performs the following processing:

[0151] Calculate the SHA-256 hash value of the actual data;

[0152] Call the BC data storage contract to query the historical predicted input data hash of the patient and compare the time correlation between the actual data and the predicted input data (to ensure that the follow-up data belongs to the same patient).

[0153] Generate a comparison report of prediction vs. actual activity (e.g., predicted activity 125°, actual 123°, error 1.6%), and calculate the report hash value and upload it to the blockchain.

[0154] If a patient needs follow-up visits at another consortium node due to referral, the new node can query the patient's anonymous identifier and historical evidence records via BC (patient authorization is required, and authorization information is also recorded on the blockchain) to obtain:

[0155] Original data collection and storage (Step 1), local training and storage (Step 2), model update and storage (Step 3), prediction and storage (Step 4);

[0156] By comparing the hash chains of all stages (the hash of the previous stage is associated with the hash of the next stage), it is confirmed that the entire process has not been tampered with, ensuring that follow-up decisions are based on reliable historical data.

[0157] For cases where the prediction error exceeds a threshold (e.g., 10%) at the local node (e.g., predicted activity 125°, actual 110°, error 12%), analyze the reasons for the error (e.g., not considering the impact of the patient's comorbid diabetes), and use the error case data and actual follow-up data as new training samples to supplement the local database; following the process in step two, use the global model V1 as the initial model to perform local training (10 rounds) and calculate the new gradient. And add DP noise ( =0.1).

[0158] The local node follows the process in step three to... Homomorphic encryption is performed and uploaded to the central server; the central server completes secure aggregation according to the FL contract, generates global model V2, and its hash value is stored on the blockchain; through multiple iterations (usually 5-8 rounds), the model MSE can be reduced to below 0.5, and the prediction accuracy continues to improve; the model version, aggregation report, and error analysis of each iteration are stored through BC, forming an iteration optimization log.

[0159] Regulatory agencies such as the National Health Commission can access smart contracts through the BC regulatory interface to query the following information (without needing to view the raw data):

[0160] Alliance node qualification verification (step one), credit score of each node (step three);

[0161] The list of participating nodes, gradient upload rate, and aggregated MSE for each round of FL aggregation (Step 3);

[0162] Randomly select patient prediction, intervention, and follow-up hash chains (steps four and five) to verify the compliance of the process.

[0163] If an audit finds an anomaly (such as a node uploading abnormal gradients multiple times), the regulatory agency can query all the node's evidence records (such as training metadata and upload timestamps) through BC to trace the cause of the anomaly. If the node is confirmed to have violated regulations (such as falsifying training data), the alliance management contract can be invoked to remove it from the alliance, and the violation record can be stored in BC to prohibit the node from being re-admitted in the future.

[0164] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0165] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

[0166] It should be noted that, in this document, the use of relational terms such as "first" and "second" is merely for distinguishing one entity or operation from another, and does not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0167] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0168] Those skilled in the art will 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, or a combination of computer software and electronic hardware. 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.

[0169] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

[0171] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0172] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0173] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

Claims

1. A method for predicting motor system perception based on cell therapy and negative oxygen ion conditioning, characterized in that, include: Step 1: Complete the initialization of the federated learning consortium, deployment of the blockchain smart contract, and privacy collection and preprocessing of local multimodal motion system and dual intervention data. The model type adopted is a CNN-LSTM-Transformer hybrid model. The motion system perception data is collected by IMU sensor to collect knee joint flexion angle and angular velocity, and EMG sensor to collect quadriceps electromyography signal. The dual intervention data is divided into cell therapy data and negative oxygen ion conditioning data. The cell therapy data includes the batch number, viability, infusion dose, and infusion time of mesenchymal stem cells; the negative oxygen ion conditioning data includes concentration, duration of action, treatment site (knee joint), and stiffness relief score after conditioning. Step 2: Implement multimodal feature fusion and initial model training of federated learning locally, and hash the training metadata to the blockchain to ensure traceability; The specific content includes: Multimodal feature fusion and input adaptation include time series alignment and feature association, feature standardization and model input generation; Time series alignment and feature association include time axis construction and feature engineering. Feature standardization and model input generation involve performing Z-score standardization on the fused features to generate FL model input data that combines feature matrices and labels; The local node loads the initial model downloaded from the central server into the training engine, configuring the parameters according to the FL contract: After training is complete, the local engine calculates the model weights, i.e., the gradients. Update and perform differential privacy enhancements; The local node generates a training metadata report and calculates the SHA-384 hash value of the report; It then invokes the data storage contract to submit the hash value, timestamp, and node digital signature to the consortium blockchain; verifies the signature's validity, and upon successful verification, packages the hash value into a new block and returns a successful storage receipt. Step 3: Local nodes perform homomorphic encryption on the updated federated learning model and upload it. The central server completes secure aggregation according to the contract to generate a new global model. The blockchain stores and agrees on the aggregation process, model version and node credit score. The specific content includes: The local node calls the CKKS homomorphic encryption algorithm to process the gradient after DP. Encryption, including: A public and private key pair is generated locally using KMS. The public key is uploaded to the BC contract, and the private key is stored locally. Use public key pair Each parameter is encrypted to generate a ciphertext gradient; Calculate the MD5 hash value of the ciphertext gradient and upload it along with the ciphertext; Local nodes upload the encrypted gradient, MD5 hash value, and proof receipt to the central coordination server, which then performs verification of proof, integrity verification, and timeout handling. Step 4: Deploy the federated learning global model locally and verify its performance. Based on real-time data, realize personalized prediction of the state of the motion system. At the same time, hash the prediction results and personalized dual intervention scheme to the blockchain to build a trust chain.

2. The method for predicting motor system perception based on cell therapy and negative oxygen ion conditioning according to claim 1, characterized in that, The specific content of step one includes: Federated learning consortium initialization includes consortium initiation and member admission, as well as initial global model design and distribution: Alliance Initiation and Membership Admission: Initiate a dual-intervention prediction alliance for musculoskeletal diseases, clarify collaborative goals, and establish membership admission criteria; Initial global model design and distribution: The central coordination server, in conjunction with the algorithm team, designed a predictive model architecture adapted to multimodal data; Based on the smart contract deployed by the consortium blockchain, the rules for multi-center collaboration are defined. The smart contract includes the consortium management contract, the FL collaboration contract, and the data storage contract. All participating nodes vote to confirm the smart contract through a practical Byzantine fault-tolerant consensus mechanism to ensure that the contract is immutable, and at the same time configure the corresponding permissions. Local multimodal data privacy collection and preprocessing includes data collection and format adaptation, privacy preprocessing, and local encrypted storage.

3. The method for predicting motor system perception based on cell therapy and negative oxygen ion conditioning according to claim 1, characterized in that, Also includes: The central server counts the number of upload nodes in real time. When the upload rate of active nodes reaches the preset standard and the ciphertext gradient of each node passes the verification, the security aggregation process is triggered. The central server calls the FL collaboration contract to obtain the data volume weights of each node, and performs a weighted summation on the ciphertext gradient to obtain the global ciphertext gradient. Then remove through gradient smoothing. outliers; The central server generates a decryption request and sends it to all participating nodes. After verifying the validity of the request, each node uses its local private key to decrypt different fragments of the ciphertext global gradient. The decrypted fragments are then aggregated to obtain the plaintext global gradient. ; Central server Update the weights of the initial model V0, generate a new global model V1, and calculate the SHA-256 hash value of V1.

4. The method for predicting motor system perception based on cell therapy and negative oxygen ion conditioning according to claim 3, characterized in that, Also includes: The central server generates an aggregated report, calculates the SHA-384 hash value of the report, and submits it to BC by calling the FL collaboration contract. The BC network verifies the aggregate report signature through a practical Byzantine fault-tolerant consensus mechanism. After successful verification, the hash value is packaged into a block, and the model version mapping is updated in the FL collaboration contract. A model V1 download notification is pushed to all local nodes.

5. The method for predicting motor system perception based on cell therapy and negative oxygen ion conditioning according to claim 4, characterized in that, The specific content of step four includes: The local node downloads the model V1 file from the central server; after the download is complete, it calculates the SHA-256 hash value of V1 and compares it with the V1 hash value stored in the BC contract. If they match, it confirms that the model has not been tampered with; otherwise, it downloads it again. The local node deploys model V1 to the clinical prediction engine and tests V1 performance using the latest local test set, including prediction accuracy verification and inference speed verification. In clinical settings, local nodes collect real-time motion perception data of patients and extract real-time feature matrices from historical dual intervention records; The local prediction engine inputs the real-time feature matrix into model V1, performs inference calculations, and outputs short-term and long-term prediction results.

6. The method for predicting motor system perception based on cell therapy and negative oxygen ion conditioning according to claim 5, characterized in that, Also includes: The local node generates a SHA-384 hash value from the patient's anonymity identifier, the prediction result text, the input data hash, and the model V1 hash, and submits it to BC by calling the data storage contract. After the BC verification node signs the document, it is uploaded to the blockchain, generating a predictive proof receipt. Doctors develop a dual intervention plan based on the prediction results, associate the plan with the prediction evidence receipt ID, and generate a plan hash value for on-chain evidence storage.

7. The method for predicting motor system perception based on cell therapy and negative oxygen ion conditioning according to claim 1, characterized in that, Step 5: Verify the correlation between follow-up data and historical records through blockchain to achieve full-process traceability, iterate and optimize the federated learning model based on error case data, and support regulatory agencies to conduct multi-center compliance audits through blockchain.

Images