A method, device and medium for processing data of hyperuricemia and gout

Abstract

The application discloses a hyperuricemia and gout data processing method, equipment and medium, and belongs to the technical field of gout data processing. The method comprises the following steps: acquiring original medical data of hyperuricemia and gout patients; processing the original medical data based on a preset gout special disease data model, performing structured data collection based on preset jump logic, and generating a structured data set; performing multi-level verification on the structured data set based on a preset data governance algorithm, and generating a governed data set; fusing the governed data set from multiple center sources based on a federated learning algorithm, performing data integration, and generating a fused data set; generating personalized follow-up suggestions according to the fused data set; storing the personalized follow-up suggestions in a preset scientific research data warehouse, and outputting the personalized follow-up suggestions to a user terminal.

Description

Technical Field

[0001] This application relates to the technical field of gout data processing, and more particularly to a method, device and medium for processing hyperuricemia and gout data. Background Technology

[0002] In the healthcare field, the efficient collection and governance of disease-specific research data is a core foundation for improving the quality of clinical research. Currently, mainstream medical data systems primarily rely on general-purpose electronic health record (EHR) platforms, collecting basic patient information, laboratory reports, and medication records through structured forms. These systems typically support multi-center data access, using standardized interfaces (such as HL7 and FHIR) to integrate data from hospital information systems (HIS) and laboratory information systems (LIS). At the data governance level, existing technologies generally employ basic verification rules (such as numerical range checks) and static encryption methods (such as AES-256) to ensure data security. For chronic disease management, some systems have introduced intelligent follow-up functions, collecting patient lifestyle data through preset questionnaire templates and generating basic health recommendations based on rule engines.

[0003] While existing technologies provide basic data management capabilities, they have significant shortcomings in specialized research scenarios such as hyperuricemia and gout. First, the data collection process lacks dynamic adaptability: general-purpose systems cannot dynamically adjust the collection path based on disease-specific characteristics such as uric acid level thresholds, leading to redundant and invalid data (e.g., repeatedly collecting gout attack forms from asymptomatic patients). Furthermore, they lack a built-in research field library compliant with CDISC standards, making it difficult to meet the structured needs of multidimensional data (e.g., drug-diet interactions). Second, data governance mechanisms have serious flaws: existing verification rules ignore disease-specific logic (e.g., the matching of medication time with symptoms), transmission encryption is not adapted to the diversity of medical data (e.g., biochemical indicators and text records use the same encryption strength), and storage lacks spatiotemporal standardization (e.g., chaotic timestamp formats across multiple centers), resulting in low data quality and difficulties in tracing its origin. Finally, multi-center data integration is inefficient: traditional centralized processing requires sharing raw data, violating the privacy requirements of the "Regulations on the Management of Human Genetic Resources"; while offline models result in data silos between centers, hindering secure aggregation driven by federated learning and impeding cross-institutional research collaboration. These shortcomings collectively lead to the core problems of low efficiency in disease-specific research, high patient dropout rates, and insufficient data reliability.

[0004] Therefore, how to achieve efficient collection, secure management, and cross-center integration of data on hyperuricemia and gout has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides a method, device, and medium for processing data on hyperuricemia and gout, in order to solve the following technical problem: how to achieve efficient collection, secure management, and cross-center fusion of data on hyperuricemia and gout.

[0006] In a first aspect, embodiments of this application provide a method for processing data on hyperuricemia and gout. The method includes: acquiring raw medical data of patients with hyperuricemia and gout; wherein the raw medical data includes biochemical indicator data, medication record data, and lifestyle data, wherein the biochemical indicator data includes uric acid level values, the medication record data includes drug type and medication time, and the lifestyle data includes dietary records and exercise habits; processing the raw medical data based on a preset gout-specific data model, performing structured data collection using preset jump logic, and generating a structured dataset; performing multi-level verification on the structured dataset based on a preset data governance algorithm, and generating a post-governance dataset; wherein the multi-level verification process includes logical verification at the acquisition end, encryption verification at the transmission end, and integrity verification at the storage end; fusing the post-governance dataset from multiple centers based on a federated learning algorithm to perform data integration and generate a fused dataset; generating personalized follow-up suggestions based on the fused dataset; wherein the personalized follow-up suggestions include dietary plan adjustments and medication optimization strategies; storing the personalized follow-up suggestions in a preset scientific research data warehouse, and outputting the personalized follow-up suggestions to the user terminal.

[0007] In one embodiment of this application, acquiring raw medical data of patients with hyperuricemia and gout specifically includes: accessing patient data sources based on a preset multi-center data acquisition architecture; wherein, the patient data sources include hospital information systems, laboratory information systems, and patient mobile terminals; extracting biochemical indicator data, medication record data, and lifestyle data based on the patient data sources; processing the biochemical indicator data based on a preset uric acid range threshold to perform preliminary filtering of the biochemical indicator data to remove invalid or outlier biochemical indicator data; and unifying the data format of the biochemical indicator data, medication record data, and lifestyle data to generate raw medical data; wherein, the raw medical data includes timestamps and geocoding.

[0008] In one embodiment of this application, raw medical data is processed based on a preset gout-specific disease data model, and structured data is collected using preset jump logic to generate a structured dataset. Specifically, this includes: configuring a dynamic form engine and loading a preset research field library based on the dynamic form engine; wherein the research field library includes multiple medical entities, and the medical entities include at least uric acid-related symptoms, complications, and drug interaction dimensions; processing the raw medical data based on jump logic, and dynamically adjusting the data collection path when the uric acid level in the raw medical data reaches a preset uric acid threshold; wherein the intelligent jump logic includes: automatically triggering the next stage of form jump when the uric acid level reaches the preset threshold; and / or calculating the optimal jump path using a decision tree algorithm based on the patient's historical data and current condition data; and mapping the raw medical data to the research field library to generate a structured dataset.

[0009] In one embodiment of this application, a multi-level verification of a structured dataset is performed based on a preset data governance algorithm to generate a post-governance dataset. Specifically, this includes: implementing logical verification processing of the structured dataset at the acquisition end for real-time data verification; wherein the logical verification at the acquisition end includes: applying a rule engine to perform uric acid value range verification to ensure that uric acid levels are within a preset physiological range; performing medication time logical verification to verify whether the medication time interval conforms to gout treatment guidelines; performing symptom-medication matching verification to compare the consistency between symptom data and drug type data; performing encryption processing of verified data at the transmission end for secure data transmission; wherein the encryption at the transmission end includes: selecting encryption algorithms adapted to different data types, applying advanced encryption standard algorithms to biochemical indicator data, and applying RSA encryption algorithms to medication record data; generating dynamic keys by fusing data characteristics to ensure tamper-proof transmission; and implementing integrity verification processing of the encrypted data at the storage end to generate a post-governance dataset; wherein the integrity verification at the storage end includes: calculating data hash values ​​for integrity comparison; detecting data corruption based on a checksum mechanism; marking verified data and isolating abnormal data for manual review.

[0010] In one embodiment of this application, a fused dataset is generated by fusing governance datasets from multiple centers based on a federated learning algorithm. Specifically, this includes: preprocessing the governance dataset on an edge computing device for local data optimization; wherein the preprocessing includes data dimensionality reduction and feature extraction, removing low-relevance features; deploying a federated learning framework to coordinate multiple center devices for secure data aggregation; wherein the federated learning framework includes: initializing global model parameters; training local models on each local device to generate model gradient data; aggregating gradient data to update the global model without exchanging the original datasets; and integrating the governance dataset based on the updated global model to generate the fused dataset; wherein the integration includes data normalization and entity alignment to ensure consistency in the spatiotemporal dimensions of the multi-center data.

[0011] In one embodiment of this application, generating personalized follow-up recommendations based on a fused dataset specifically includes: parsing patient basic information data in the fused dataset to determine the patient's height, weight, and age; extracting disease characteristic data, including uric acid fluctuation pattern data, medication adherence score data, and symptom severity index data; processing the patient basic information data and disease characteristic data based on a preset collaborative filtering recommendation algorithm to match similar patient data features and generate dietary plan adjustment data; processing the fused dataset based on a preset clinical guideline rule base to generate medication optimization strategy data, including drug dosage adjustment parameters and medication time reminder parameters; and integrating the dietary plan adjustment data and medication optimization strategy data to generate personalized follow-up recommendations.

[0012] In one embodiment of this application, personalized follow-up suggestions are stored in a preset scientific research data warehouse and output to a user terminal. Specifically, this includes: processing personalized follow-up suggestions based on a version control protocol to generate versioned follow-up data; wherein the version control protocol includes: assigning version identifiers; recording data change trajectories; supporting version rollback operations; processing versioned follow-up data based on spatiotemporal standardization rules to generate standardized storage data; wherein the spatiotemporal standardization rules include: adding Coordinated Universal Time (UTC) timestamps; converting location information to geocoding; transmitting standardized storage data to the scientific research data warehouse; wherein the transmission includes calling a batch import interface and a real-time streaming channel; generating visual report data and outputting it to the user terminal via an application programming interface (API).

[0013] In one embodiment of this application, the method further includes: monitoring the data quality indicators of the data dataset after governance, including missing rate data, error rate data, and consistency score data; adjusting the parameters of the data governance algorithm based on the monitoring results; wherein the adjustment includes: updating the verification rule threshold through an anomaly detection model; dynamically optimizing the encryption algorithm key strength; and feeding back parameter adjustment instructions to the data acquisition step to trigger the data re-acquisition process; wherein the triggering includes: marking low-quality data sources; and iteratively executing structured data acquisition and multi-level verification steps.

[0014] Secondly, embodiments of this application also provide a hyperuricemia and gout data processing device, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a hyperuricemia and gout data processing method as described above.

[0015] Thirdly, embodiments of this application also provide a non-volatile computer storage medium storing computer-executable instructions, which, when executed, implement a hyperuricemia and gout data processing method as described above.

[0016] The data processing method, device, and medium for hyperuricemia and gout provided in this application have the following beneficial effects: Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 A flowchart of a data processing method for hyperuricemia and gout provided in this application embodiment;

[0019] Figure 2 This is a schematic diagram of the internal structure of a data processing device for hyperuricemia and gout provided in an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] This application provides a method, device, and medium for processing data on hyperuricemia and gout, in order to solve the following technical problem: how to achieve efficient collection, secure management, and cross-center fusion of data on hyperuricemia and gout.

[0022] The technical solutions proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0023] Figure 1 This document provides a flowchart for data processing of hyperuricemia and gout, as illustrated in an embodiment of this application. Figure 1 As shown in the embodiment of this application, a method for processing hyperuricemia and gout data specifically includes the following steps:

[0024] Step 1: Obtain the original medical data of patients with hyperuricemia and gout; wherein, the original medical data includes biochemical indicator data, medication record data and lifestyle data, the biochemical indicator data includes uric acid level, the medication record data includes drug type and medication time, and the lifestyle data includes diet record and exercise habits.

[0025] Step 1.1: Access patient data sources based on a preset multi-center data acquisition architecture; wherein, the patient data sources include hospital information systems, laboratory information systems, and patient mobile terminals.

[0026] The multi-center data acquisition architecture is a predefined software and hardware framework for connecting source data systems across multiple healthcare institutions. Patient data sources are a collection of these systems: Hospital Information Systems (HIS) manage patient admission and diagnostic records; Laboratory Information Systems (LIS) process biochemical test results; and patient mobile terminals, including smartphones or wearable devices, collect lifestyle data. The access process is implemented through standard APIs (Application Programming Interfaces) to ensure reliable data transmission.

[0027] In a specific example, patient A suffers from hyperuricemia, and their data is integrated. First, the system connects to the hospital information system in city B based on a pre-defined architecture (such as using the HL7 protocol) to obtain basic medical record information; simultaneously, it accesses the laboratory information system to retrieve recent uric acid level test reports; then, it collects daily dietary records (e.g., recording the frequency of high-purine food intake) and exercise habit data (e.g., weekly exercise duration) through patient A's mobile terminal app. The entire integration process is completed automatically without manual intervention, demonstrating the practicality and efficiency of the architecture.

[0028] Step 1.2: Extract the biochemical indicator data, medication record data, and lifestyle data based on the patient data source.

[0029] Extraction refers to selecting specific information from a data source. Biochemical data includes uric acid levels (e.g., serum uric acid concentration); medication records cover drug types (e.g., anti-uric acid drug names) and medication duration (e.g., dosing time and interval); lifestyle data focuses on dietary records (e.g., daily meal plans) and exercise habits (e.g., exercise type and frequency). Extraction utilizes data crawling or SQL query techniques, extracting only relevant fields to avoid excessive redundancy.

[0030] In a specific case, for patient B, the system extracts information from its data sources: biochemical indicators such as uric acid levels (e.g., a record of 420 μmol / L) from the laboratory information system; medication records including drug type (e.g., allopurinol) and dosage time (e.g., once daily at 8:00 AM) from the hospital information system; and lifestyle data such as dietary records (showing a high-purine diet) and exercise habits (30 minutes of walking daily) from the patient's mobile device. The extraction process ensures data integrity and privacy protection, facilitating subsequent processing.

[0031] Step 1.3: Process the biochemical indicator data based on a preset uric acid range threshold to perform preliminary filtering of the biochemical indicator data and remove invalid or outlier biochemical indicator data.

[0032] Uric acid range thresholds are predefined numerical limits (e.g., the normal range is 200-420 μmol / L) used to distinguish between valid and invalid data. Preliminary filtering involves applying these thresholds to clean the data, removing invalid values ​​(such as negative numbers or missing values) and outliers (such as values ​​exceeding the threshold range) to ensure data reliability. Filtering is performed based on a rule engine, improving the accuracy of subsequent analyses.

[0033] In a specific case, patient C's biochemical data were processed. The preset uric acid range threshold was 200-420 μmol / L (high uric acid was defined as >420 μmol / L). The system checked uric acid levels: if a value of 500 μmol / L was found (abnormal), it was automatically marked as an outlier; another value was "unknown" and removed as invalid. After processing, only data meeting the threshold (e.g., values ​​within the 350-410 μmol / L range) were retained, and other data were isolated for review. This step focused on key aspects of data quality control, ensuring that subsequent analyses were based on reliable input.

[0034] Step 1.4: Standardize the data format of the biochemical indicator data, medication record data, and lifestyle data to generate the raw medical data; wherein, the raw medical data includes timestamps and geocoding.

[0035] Data format standardization involves converting data from different sources into a standard structure to avoid compatibility issues. Raw medical data is the initial, integrated dataset, including timestamps (recording the time the data was generated) and geocoding (encoding based on location data, such as simplifying latitude and longitude to city codes). Standardization involves field mapping (e.g., unifying "uric acid level" to "UA_level") and unit conversion (e.g., from μmol / L to mg / dL).

[0036] In a specific example, the three types of extracted data were integrated: biochemical indicator data (such as uric acid levels) were converted from LIS format to JSON; medication record data (such as drug type and time) were standardized from Excel to a database table; and lifestyle data (such as dietary records) were standardized from mobile app CSV files. Timestamps (e.g., recording test time) and geocoding (e.g., patient location coded as region A) were added. This generated unified raw data for easy storage. The steps focused on standardization to improve data consistency.

[0037] Step 2: Process the raw medical data based on the preset gout disease data model, and perform structured data collection using preset jump logic to generate a structured dataset.

[0038] Step 2.1: Configure the dynamic form engine and load the preset scientific research field library based on the dynamic form engine; wherein, the scientific research field library includes multiple medical entities, and the medical entities include at least the dimensions of uric acid-related symptoms, complications and drug interaction;

[0039] The dynamic form engine is a programmable software component used to create adaptive data collection forms. The research field library is a predefined collection of fields containing medical entities: such as uric acid-related symptoms (e.g., joint pain), complications (e.g., kidney stones), and drug interaction dimensions (describing the effects between drugs). Configuration and loading ensure that fields match the disease-specific model.

[0040] In a specific example, the system is configured with a dynamic form engine (using an open-source framework such as Odoo) and loads a research field library (including fields such as "severity of joint symptoms" and "drug interaction risk"). When processing patient A's raw data, the engine automatically matches the fields and extracts relevant information. The application of this field library ensures the targeted nature of data collection.

[0041] Step 2.2: Process the original medical data based on the jump logic. When the uric acid level in the original medical data reaches a preset uric acid threshold, dynamically adjust the data collection path. The intelligent jump logic includes: automatically triggering the next stage form jump when the uric acid level reaches the preset threshold; calculating the optimal jump path based on the patient's historical data and current condition data using a decision tree algorithm.

[0042] The redirection logic is an adaptive rule: the uric acid threshold (e.g., ≥420 μmol / L) serves as a trigger point, dynamically adjusting the path and changing the data collection process. A decision tree algorithm is used to calculate the path from historical data (e.g., previous medical records) and current data to optimize efficiency. Automatic form redirection refers to switching the data collection interface.

[0043] In a specific case, patient B's uric acid level reached 450 μmol / L (preset threshold 430 μmol / L). The system triggered a redirect: using a decision tree (based on historical attack frequency) to calculate the optimal path, the system redirected from the basic form to the advanced symptom collection form. This avoids redundant data collection and improves efficiency.

[0044] Step 2.3: Map the original medical data to the research field library to generate the structured dataset; wherein, the mapping includes data field matching and redundant data removal to ensure that the dataset conforms to the clinical data exchange standard protocol.

[0045] Mapping refers to aligning data fields to a research field library, such as mapping "UA_value" to "uric acid level value". Redundant data is removed by discarding irrelevant information (such as duplicate records). Standard protocols such as FHIR ensure dataset interoperability.

[0046] In a specific example, the "uric acid" field in patient C's original data was matched to a field library, and redundant entries (such as invalid time records) were removed to generate a structured dataset conforming to FHIR. The steps emphasize the accuracy of the mapping.

[0047] Step 3: Perform multi-level verification on the structured dataset based on a preset data governance algorithm to generate a governed dataset; wherein, the multi-level verification process includes logical verification at the acquisition end, encryption verification at the transmission end, and integrity verification at the storage end.

[0048] Step 3.1: Implement the logic verification process at the data acquisition end to process the structured dataset for real-time data verification; wherein, the logic verification at the data acquisition end includes: applying a rule engine to perform uric acid value range verification to ensure that the uric acid value is within the preset physiological range; performing medication time logic verification to verify whether the medication time interval conforms to the gout treatment guidelines; and performing symptom and medication matching verification to compare the consistency between symptom data and drug type data.

[0049] The data acquisition logic validation applies rules at the data generation point: the rule engine checks the uric acid value range (e.g., 200-800 μmol / L), medication interval (e.g., minimum interval of 6 hours), and symptom-drug matching (e.g., joint pain corresponds to uric acid-lowering drugs). This ensures the data logic is correct.

[0050] In a specific example, patient A's uric acid level of 600 μmol / L (out of range) was labeled in the structured dataset; the validation failed due to a 3-hour medication interval (the standard requires at least 6 hours); however, the symptom "joint swelling" successfully matched the medication "painkiller." Validation was performed in real time, improving data quality.

[0051] Step 3.2: Perform the encryption process at the transmission end to verify the data for secure data transmission; wherein, the encryption at the transmission end includes: selecting encryption algorithms to adapt to different types of data, applying the Advanced Encryption Standard algorithm to biochemical indicator data, and applying the RSA encryption algorithm to medication record data; and generating a dynamic key by integrating data characteristics to ensure tamper-proof transmission.

[0052] Encryption at the transmission end uses algorithms to protect the transmission: Biochemical indicator data (sensitive detection values) uses the Advanced Encryption Standard (AES) algorithm; medication record data (private information) uses the RSA algorithm (public-key encryption). Dynamic keys are generated as temporary keys based on data characteristics to prevent tampering.

[0053] In a specific example, patient B's biochemical data is encrypted with AES, and medication records are encrypted with RSA. A dynamic key (e.g., based on data size) is generated to ensure that the data transmitted from the collection point to the data center is not tampered with. This focuses on key aspects of transmission security.

[0054] Step 3.3: Perform the storage-side integrity verification process on the encrypted data to generate the post-governance dataset; wherein, the storage-side integrity verification includes: calculating data hash values ​​for integrity comparison; detecting data corruption based on a checksum mechanism; marking data that has passed verification, and isolating abnormal data for manual review.

[0055] Storage integrity verification ensures data integrity after storage: hash value calculation (such as SHA-256 to generate signature) is used to compare new and old data; checksum mechanism detects bit-level errors; verified data is marked with status, and abnormal data is isolated to avoid impact.

[0056] In a specific example, patient C's encrypted data is hashed and stored; if no change is found, it is marked "verification passed"; if the hash value does not match, it is isolated for manual verification, forming a post-processing dataset. The steps emphasize the verification mechanism.

[0057] Step 4: Based on the federated learning algorithm, the governed datasets from multiple centers are fused to perform data integration and generate a fused dataset.

[0058] Step 4.1: Preprocess the governed dataset on an edge computing device to perform local data optimization; wherein, the preprocessing includes data dimensionality reduction and feature extraction, and removal of low-relevance features;

[0059] Preprocessing the governed dataset on edge computing devices aims to rapidly optimize the data near the data source, reducing transmission burden. An "edge computing device" is a hardware device (such as a server) deployed near the data source (e.g., a healthcare institution), capable of processing data locally without having to upload it to a central server. "Local data optimization" refers to simplifying the data format using algorithms to make the data more suitable for subsequent fusion. "Preprocessing" includes specific operations: dimensionality reduction (reducing the number of redundant fields in the dataset, lowering complexity), feature extraction (identifying and retaining high-value information, such as key metrics), and removal of low-relevance features (removing data fields that contribute little to the analysis, such as irrelevant secondary metrics). These operations improve data processing efficiency and subsequent fusion performance.

[0060] In a specific example, this step revolves around the core aspects of local data optimization: feature extraction and dimensionality reduction. The post-treatment dataset for city A (containing patient B's uric acid levels and medication records) is preprocessed on an edge computing device in region C. Dimensionality reduction is achieved by reducing the number of fields (e.g., compressing 100 data fields into 30 core fields). Feature extraction focuses on key information related to hyperuricemia (e.g., extracting uric acid fluctuation trends) and removes low-relevance features (e.g., patient sleep duration records, as they are irrelevant to gout analysis). The optimized data is smaller in size while retaining 97% of the key information, facilitating rapid use in subsequent federated learning.

[0061] Step 4.2: Deploy a federated learning framework to coordinate multi-center devices for secure data aggregation; wherein the federated learning framework includes: initializing global model parameters; training local models on each local device to generate model gradient data; aggregating gradient data to update the global model without exchanging the original dataset;

[0062] Deploying a federated learning framework is to coordinate data processing in a multi-center environment and ensure data privacy. A "federated learning framework" is a software architecture (such as using an open-source framework like FATE) used to manage communication and computation processes between devices. "Coordinating multiple centers" refers to the framework's unified control over the operation of multiple edge devices. "Secure data aggregation" emphasizes that data is protected during transmission and aggregation, with no risk of privacy breaches. The framework's specific operations are as follows: First, it initializes global model parameters (setting the structure and initial values ​​of a basic machine learning model); then, each local device trains a local model based on its local post-governance dataset (e.g., fitting a model using patient data), generating model gradient data (representing the update direction after model training, not the original data); finally, it aggregates the gradient data (summarizing gradients from all centers) to update the global model without exchanging the original dataset (the original data is always retained locally). This ensures data security and compliance.

[0063] In a specific example, this step revolves around the core principle of secure data aggregation: gradient exchange without exposing the raw data. After framework deployment, three centers are coordinated: Center A (City D), Center B (City E), and Center C (City F). Global model parameters are initialized (e.g., a neural network model for predicting gout risk). Local devices train local models: for example, Center A's device trains the model using optimized data from patient B, generating gradient data (a numerical vector representing how the model parameters are adjusted). The gradient data is securely transferred and aggregated (e.g., averaging all gradients), and the global model is updated to learn multi-center patterns, but patient B's raw uric acid record never leaves the local device. This avoids privacy risks and is highly efficient in aggregation.

[0064] Step 4.3: Integrate the governed dataset based on the updated global model to generate the fused dataset; wherein, the integration includes data normalization and entity alignment to ensure consistency of spatiotemporal dimensions of multi-center data.

[0065] Integrating the governed dataset based on the updated global model involves applying the distributed training results to the final data fusion. The "updated global model" is the unified machine learning model optimized after gradient aggregation in step 4.2. "Integration" refers to applying this model to process the governed dataset, generating a structurally consistent fused dataset. Specific operations include: data normalization (scaling all values ​​to a uniform range, such as normalizing uric acid values ​​from 0-1000 μmol / L to 0-1) to ensure data comparability across different centers; entity alignment (matching identical entities in different systems, such as merging records of the same patient from different centers based on patient ID) to eliminate duplication or conflicts; and ensuring spatiotemporal consistency (standardizing time and location information, such as using Coordinated Universal Time (UTC) for all timestamps and converting all locations to geocoding). This ensures the consistency and reliability of the fused dataset in the analysis.

[0066] In a specific example, this step revolves around the core points of entity alignment and spatiotemporal consistency during integration. An updated global model (such as a gout-based predictive model) is applied to integrate the post-treatment datasets (including patient D's records) from centers A and C. Data is normalized and scaled for uric acid values ​​(e.g., 600 μmol / L is normalized to 0.6); entity alignment matches patient D's ID (e.g., unified as "PAT_D").

[0067] Add UTC timestamps and geocoding (e.g., convert the location "City G" to the code "G123"). Generate a merged dataset where all data are time-aligned (e.g., error less than 1 minute) and spatially consistent (e.g., geocoding covers the same area) to facilitate subsequent steps.

[0068] Step 5: Generate personalized follow-up recommendations based on the fused dataset; wherein, the personalized follow-up recommendations include dietary adjustments and medication optimization strategies.

[0069] Step 5.1: Parse the patient's basic information data in the fused dataset to determine the patient's height, weight, and age data;

[0070] Parsing the fusion dataset is used to extract fundamental patient attributes for building personal health profiles. "Parsing" refers to identifying and retrieving specific fields from the dataset. "Basic patient information data" includes demographic indicators: height data (patient vertical height, used to calculate body mass index), weight data (patient mass, used for health assessment), and age data (patient age, influencing treatment strategies). This data forms the basis for subsequent recommendations.

[0071] In a specific example, this step revolves around parsing height and weight to determine the core body type. Basic information about patient E in the fusion dataset is parsed: height (175cm), weight (80kg), and age (45 years). The system automatically reads these fields (e.g., height is "Height" and weight is "Weight") and verifies their validity (e.g., within preset ranges). This will be used for subsequent personalized calculations.

[0072] Step 5.2: Extract disease characteristic data; wherein, the disease characteristic data includes uric acid fluctuation pattern data, medication adherence score data, and symptom severity index data;

[0073] Extracting disease characteristic data involves obtaining key dynamic information about the disease from a fused dataset. "Disease characteristic data" refers to features reflecting a patient's gout status: uric acid fluctuation pattern data (describing trends in uric acid levels, such as peaks and troughs), medication adherence score data (assessing patient compliance with medication, calculated as a percentage based on medication records), and symptom severity index data (quantifying symptom intensity, such as joint pain level). These features form the core basis for customized recommendations.

[0074] In a specific case, this step revolves around extracting the core elements of uric acid fluctuation patterns and symptom severity. Disease characteristics of patient F in the fusion dataset were extracted: uric acid fluctuation pattern data (showing weekly peaks exceeding 500 μmol / L), medication adherence score data (85%, indicating good adherence), and symptom severity index data (moderate pain index). The feature extraction process identified time-series changes and scored symptom levels (e.g., using a 0-10 scale).

[0075] Step 5.3: Process the patient's basic information data and disease feature data based on a preset collaborative filtering recommendation algorithm to match similar patient data features and generate dietary plan adjustment data;

[0076] Dietary recommendations based on collaborative filtering algorithms are a personalized recommendation method. The collaborative filtering algorithm analyzes the similarity between patients to customize the plan: matching similar patient data features (such as comparing height, weight, and disease characteristics to identify groups); and outputting personalized diet parameters (such as low-purine diet recommendations). The algorithm learns from similar patient groups to improve the practicality of the recommendations.

[0077] In a specific example, this step revolves around the core point of the algorithm matching similar features. For patient G (height 170cm, weight 75kg, age 50, fluctuating high uric acid), the algorithm matches similar patient groups (other patients with similar features) and outputs personalized diet parameters (such as a daily purine intake limit of 500mg, menu example: low-fat dairy products and vegetables).

[0078] Step 5.4: Process the fused dataset based on a preset clinical guideline rule base to generate medication optimization strategy data; wherein, the medication optimization strategy data includes drug dosage adjustment parameters and medication time reminder parameters;

[0079] Medication strategies are generated based on a clinical guideline rule base to ensure that recommendations comply with medical standards. The "clinical guideline rule base" is a pre-defined knowledge base (containing gout treatment protocols, such as the ACR guidelines). "Medication optimization strategy data" includes: drug dosage adjustment parameters (such as increasing or decreasing the dosage) and medication timing reminder parameters (such as specific times for taking the medication). This ensures the safety and effectiveness of the recommendations.

[0080] In a specific example, this step revolves around the core point of generating dose adjustments from a rule base. The clinical guideline rule base (storing standard gout medication rules) is applied to patient H: based on fusion data (symptom severity), it generates medication dose adjustment parameters (allopurinol dose adjusted from 100mg to 200mg) and medication time reminder parameters (daily at 8 AM and 8 PM). It is understood that in this embodiment, the rule base ensures that the parameters are based on evidence.

[0081] Step 5.5 Integrate the dietary plan adjustment data and medication optimization strategy data to generate the personalized follow-up recommendations.

[0082] In this embodiment, "integration" refers to integrating dietary plan adjustment data and medication optimization strategy data into a structured output. "Personalized follow-up recommendations" is a complete health guidance document.

[0083] In one embodiment of this application, the integration method applies a priority ranking algorithm to mark high-priority recommendations during the acute phase. The "priority ranking algorithm" applies rules (such as based on symptom severity) to mark high-priority recommendations during the acute phase (such as reminders to prioritize medication during a gout attack) to ensure that key recommendations are highlighted.

[0084] In a specific example, this step revolves around the core elements of combination and acute-phase prioritization. Patient I's dietary regimen adjustment data (low-purine diet) is combined with medication optimization strategy data (dosage adjustments) into a single recommendation document. A prioritization algorithm marks acute-phase (uric acid peak) recommendations as high priority (e.g., "immediate medication adjustment"), generating the final follow-up recommendation.

[0085] Step 6: Store the personalized follow-up recommendations in a preset scientific research data warehouse, and output the personalized follow-up recommendations to the user terminal.

[0086] Step 6.1: Process the personalized follow-up suggestions based on the version control protocol to generate versioned follow-up data; wherein, the version control protocol includes: assigning version identifiers; recording data change trajectories; and supporting version rollback operations;

[0087] Version control protocols are used to manage recommendation history. A "version control protocol" is a set of data management rules: assigning version identifiers (e.g., V1.0, used to uniquely identify versions), recording data change paths (e.g., logging each modification in a log file), and supporting version rollback operations (e.g., restoring an older version). This generates versioned follow-up data for easy tracking and auditing.

[0088] In a specific example, this step revolves around version identification and backtracking. Patient J's follow-up recommendations include: assigning a version identifier "V2.1" (the current version), recording changes (such as noting dietary parameter adjustments in the log), and supporting backtracking (which can be done via an interface to revert to "V2.0"). Versioned follow-up data storage is then generated.

[0089] Step 6.2: Process the versioned follow-up data based on spatiotemporal standardization rules to generate standardized storage data; wherein, the spatiotemporal standardization rules include: adding Coordinated Universal Time timestamps; converting location information into geocoding;

[0090] Data format and location information are unified based on spatiotemporal standardization rules. The "spatiotemporal standardization rules" add Coordinated Universal Time (UTC) timestamps (e.g., "2025-07-16T06:00:00Z" to ensure global time consistency) and convert location information to geocoding (e.g., "City H" converted to "H456" code). Standardized storage data is generated to eliminate dimensional differences.

[0091] In a specific example, this step revolves around adding timestamps and geocoding. Versioned follow-up data is stamped with a UTC timestamp (record generation time), and locations (such as patient addresses "Region K") are converted to geocoding "K789". Standardized storage data is then generated for transmission.

[0092] Step 6.3: Transmit the standardized stored data to the scientific research data warehouse; wherein, the transmission includes calling the batch import interface and the real-time stream processing channel;

[0093] Data transfer to the warehouse utilizes efficient interfaces. "Transfer" includes calls to the bulk import interface (for large volumes of data, such as importing multiple patients' data at once) and a real-time streaming channel (for small, immediate data, such as new recommendations). This ensures complete and rapid data loading.

[0094] In a specific example, this step revolves around the core elements of batch interfaces and real-time streaming. Patient L's data in the standardized storage data is transferred to the research data warehouse via a batch import interface (loading 100 records at a time) and a real-time streaming channel (newly generated suggestions are sent in real time), with zero processing delay.

[0095] Step 6.4: Generate visual report data and output it to the user terminal via the application programming interface.

[0096] Generate and output reports to enhance readability. "Visualized report data" transforms recommendations into charts or text (such as uric acid trend graphs); "API-based output" uses an API (Application Programming Interface) to push reports to user terminals (such as doctor's desktop or patient's mobile phone).

[0097] In a specific example, this step revolves around the core point of visualizing report output. Report data (such as displaying uric acid changes using a bar chart) is generated and output to the user's terminal (such as patient M's mobile app) via API for easy understanding.

[0098] The method further includes: monitoring the data quality indicators of the post-governance dataset, including missing data, error rate data, and consistency score data; adjusting the parameters of the data governance algorithm based on the monitoring results; wherein the adjustment includes: updating the verification rule threshold through an anomaly detection model; dynamically optimizing the encryption algorithm key strength; and feeding back parameter adjustment instructions to the data acquisition step to trigger the data re-acquisition process; wherein the triggering includes: marking low-quality data sources; and iteratively executing structured data acquisition and multi-level verification steps.

[0099] Data quality metrics for the monitored dataset after governance include: missing rate (calculating the proportion of missing data), error rate (assessing the frequency of erroneous records), and consistency score (checking the logical consistency of the data). Data governance algorithm parameters are adjusted based on monitoring results: verification rule thresholds are updated using an anomaly detection model (a machine learning model to detect data anomalies) (e.g., adjusting the boundary values ​​of the uric acid range threshold); encryption algorithm key strength is dynamically optimized (e.g., increasing or decreasing the key length based on data sensitivity). Feedback parameter adjustment instructions are sent to the data acquisition steps (steps 1 and 2): triggering a data re-acquisition process, including marking low-quality data sources (e.g., identifying data sources from specific hospitals as problem sources) and iteratively executing structured data acquisition (step 2) and multi-level verification (step 3). This ensures system self-optimization and continuous improvement.

[0100] In a specific example, this section focuses on monitoring key data quality metrics. After treatment, records for patient N in the centralized dataset are monitored: the missing data rate is calculated at 15% (too high), the error rate at 5% (e.g., incorrect medication time records), and the consistency score at 80% (needs improvement). The anomaly detection model updates its validation rule thresholds (e.g., increasing the uric acid threshold from 420 to 430 μmol / L) and dynamically optimizes the encryption key strength (from 128 bits to 256 bits). Feedback instructions trigger re-collection: low-quality data sources (e.g., laboratories in region P) are flagged, and iterative processing begins from step 2 (restructuring data collection and multi-level validation) to ensure data quality meets standards.

[0101] The above are embodiments of the method proposed in this application. Based on the same inventive concept, embodiments of this application also provide a data processing device for hyperuricemia and gout, the structure of which is as follows: Figure 2 As shown.

[0102] Figure 2 This is a schematic diagram of the internal structure of a data processing device for hyperuricemia and gout, provided as an embodiment of this application. Figure 2 As shown, the device includes:

[0103] At least one processor 201;

[0104] And a memory 202 that is communicatively connected to at least one processor;

[0105] The memory 202 stores instructions executable by at least one processor, which are executed by at least one processor 201 to enable at least one processor 201 to:

[0106] Obtain raw medical data from patients with hyperuricemia and gout; the raw medical data includes biochemical indicators, medication records, and lifestyle data. Biochemical indicators include uric acid levels, medication records include drug types and duration of use, and lifestyle data includes dietary records and exercise habits.

[0107] The raw medical data is processed based on a pre-defined gout-specific data model, and structured data is collected using pre-defined jump logic to generate a structured dataset.

[0108] The structured dataset is validated at multiple levels based on a preset data governance algorithm to generate a regulated dataset. The multi-level validation process includes logical validation at the acquisition end, encryption validation at the transmission end, and integrity validation at the storage end.

[0109] Federated learning algorithms are used to fuse governed datasets from multiple centers to integrate the data and generate a fused dataset.

[0110] Personalized follow-up recommendations are generated based on the fused dataset; these recommendations include dietary adjustments and medication optimization strategies.

[0111] Store personalized follow-up recommendations to a pre-defined scientific research data warehouse and output personalized follow-up recommendations to the user terminal.

[0112] Some embodiments of this application provide corresponding to Figure 1 A non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as follows:

[0113] Obtain raw medical data from patients with hyperuricemia and gout; the raw medical data includes biochemical indicators, medication records, and lifestyle data. Biochemical indicators include uric acid levels, medication records include drug types and duration of use, and lifestyle data includes dietary records and exercise habits.

[0114] The raw medical data is processed based on a pre-defined gout-specific data model, and structured data is collected using pre-defined jump logic to generate a structured dataset.

[0115] The structured dataset is validated at multiple levels based on a preset data governance algorithm to generate a regulated dataset. The multi-level validation process includes logical validation at the acquisition end, encryption validation at the transmission end, and integrity validation at the storage end.

[0116] Federated learning algorithms are used to fuse governed datasets from multiple centers to integrate the data and generate a fused dataset.

[0117] Personalized follow-up recommendations are generated based on the fused dataset; these recommendations include dietary adjustments and medication optimization strategies.

[0118] Store personalized follow-up recommendations to a pre-defined scientific research data warehouse and output personalized follow-up recommendations to the user terminal.

[0119] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for IoT devices and media are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0120] The systems, media, and methods provided in this application are one-to-one correspondences. Therefore, the systems and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the systems and media will not be repeated here.

[0121] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0122] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0123] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0124] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0125] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0126] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0127] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0128] It should also be noted that 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 limitation, 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 said element.

[0129] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for processing data on hyperuricemia and gout, characterized in that, The method includes: Obtain raw medical data of patients with hyperuricemia and gout; wherein, the raw medical data includes biochemical index data, medication record data and lifestyle data, the biochemical index data includes uric acid level, the medication record data includes drug type and medication time, and the lifestyle data includes dietary records and exercise habits; The raw medical data is processed based on a pre-defined gout-specific data model, and structured data is collected using a pre-defined jump logic to generate a structured dataset. The structured dataset is subjected to multi-level verification based on a preset data governance algorithm to generate a governed dataset; wherein, the multi-level verification process includes logical verification at the acquisition end, encryption verification at the transmission end, and integrity verification at the storage end. The governed datasets from multiple centers are fused based on the federated learning algorithm to integrate the data and generate a fused dataset. Personalized follow-up recommendations are generated based on the fused dataset; wherein, the personalized follow-up recommendations include dietary adjustments and medication optimization strategies; The personalized follow-up recommendations are stored in a preset scientific research data warehouse and then output to the user terminal. The raw medical data is processed based on a pre-defined gout-specific data model, and structured data is collected using pre-defined jump logic to generate a structured dataset, specifically including: Configure a dynamic form engine and load a preset scientific research field library based on the dynamic form engine; wherein, the scientific research field library includes multiple medical entities, and the medical entities include at least the dimensions of uric acid-related symptoms, complications and drug interaction; The original medical data is processed based on the jump logic. When the uric acid level in the original medical data reaches a preset uric acid threshold, the data collection path is dynamically adjusted. The jump logic includes: automatically triggering the next stage form jump when the uric acid level reaches the uric acid threshold; and / or calculating the optimal jump path based on the patient's historical data and current condition data using a decision tree algorithm. The raw medical data is mapped to the scientific research field library to generate the structured dataset; The structured dataset is subjected to multi-level validation based on a preset data governance algorithm to generate a governed dataset, specifically including: The structured dataset is processed using the logic verification at the acquisition end to perform real-time data verification. This logic verification includes: applying a rule engine to perform uric acid value range verification to ensure that uric acid levels are within a preset physiological range; performing medication time logic verification to confirm whether the medication time interval conforms to gout treatment guidelines; and performing symptom-medication matching verification to compare the consistency between symptom data and medication type data. Data that passes the verification process after the transmission end encryption is used for secure data transmission; wherein, the transmission end encryption includes: selecting encryption algorithms to adapt to different types of data, applying Advanced Encryption Standard (AES) algorithms to biochemical indicator data, and applying RSA encryption algorithms to medication record data; and generating dynamic keys by integrating data characteristics to ensure tamper-proof transmission. The encrypted data is processed through the aforementioned storage-side integrity verification to generate the post-governance dataset. The storage-side integrity verification includes: calculating data hash values ​​for integrity comparison; detecting data corruption based on a checksum mechanism; marking verified data and isolating abnormal data for manual review.

2. The method for processing hyperuricemia and gout data according to claim 1, characterized in that, Obtain raw medical data from patients with hyperuricemia and gout, specifically including: Access to patient data sources is based on a pre-defined multi-center data acquisition architecture; wherein, the patient data sources include hospital information systems, laboratory information systems, and patient mobile terminals; Based on the patient data source, extract the biochemical indicator data, medication record data, and lifestyle data; The biochemical indicator data is processed based on a preset uric acid range threshold to perform preliminary filtering of the biochemical indicator data and remove invalid or outlier biochemical indicator data. The data format is standardized for the biochemical indicator data, medication record data, and lifestyle data to generate the raw medical data; wherein the raw medical data includes timestamps and geocoding.

3. The method for processing hyperuricemia and gout data according to claim 1, characterized in that, The governed datasets from multiple centers are fused using a federated learning algorithm to integrate the data and generate a fused dataset, specifically including: The governed dataset is preprocessed on an edge computing device for local data optimization; wherein the preprocessing includes data dimensionality reduction and feature extraction, and removal of low-relevance features; A federated learning framework is deployed to coordinate multiple data centers for secure data aggregation. The federated learning framework includes: initializing global model parameters; training local models on each local device to generate model gradient data; and aggregating the gradient data to update the global model without exchanging the original dataset. The fused dataset is generated by integrating the governed dataset based on the updated global model; wherein, the integration includes data normalization and entity alignment to ensure consistency of spatiotemporal dimensions of multi-center data.

4. The method for processing hyperuricemia and gout data according to claim 1, characterized in that, Personalized follow-up recommendations are generated based on the fused dataset, specifically including: The patient's basic information data in the fused dataset is analyzed to determine the patient's height, weight, and age data. Extract disease characteristic data; wherein, the disease characteristic data includes uric acid fluctuation pattern data, medication adherence score data, and symptom severity index data; The patient's basic information data and disease feature data are processed based on a preset collaborative filtering recommendation algorithm to match similar patient data features and generate dietary plan adjustment data. The fused dataset is processed based on a pre-defined clinical guideline rule base to generate medication optimization strategy data; wherein, the medication optimization strategy data includes drug dosage adjustment parameters and medication time reminder parameters; The dietary plan adjustment data and medication optimization strategy data are integrated to generate the personalized follow-up recommendations.

5. The method for processing hyperuricemia and gout data according to claim 1, characterized in that, The personalized follow-up recommendations are stored in a preset scientific research data warehouse and then output to the user terminal, specifically including: The personalized follow-up recommendations are processed based on a version control protocol to generate versioned follow-up data; wherein, the version control protocol includes: assigning version identifiers; recording data change trajectories; and supporting version rollback operations; The versioned follow-up data is processed based on spatiotemporal standardization rules to generate standardized storage data; wherein, the spatiotemporal standardization rules include: adding Coordinated Universal Time timestamps; and converting location information into geocoding; The standardized stored data is transmitted to the scientific research data warehouse; wherein, the transmission includes calling the batch import interface and the real-time stream processing channel; Generate visual report data and output it to the user terminal via the application programming interface.

6. The method for processing hyperuricemia and gout data according to claim 1, characterized in that, The method further includes: Monitor the data quality metrics of the post-governance dataset, including missing data, error rate data, and consistency score data; The parameters of the data governance algorithm are adjusted based on the monitoring results; wherein, the adjustment includes: updating the verification rule threshold through the anomaly detection model; and dynamically optimizing the encryption algorithm key strength; Feedback parameter adjustment instructions are sent to the data acquisition step to trigger the data re-acquisition process; wherein, the triggering includes: marking low-quality data sources; iteratively executing structured data acquisition and multi-level verification steps.

7. A data processing device for hyperuricemia and gout, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform a data processing method for hyperuricemia and gout as described in any one of claims 1-6.

8. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, they implement a data processing method for hyperuricemia and gout as described in any one of claims 1-6.

Images