Defective medical data generation method

Abstract

The invention relates to the field of medical data processing, and discloses an imaginary medical data generation method, which comprises the following steps: S1, constructing a dynamic medical knowledge graph containing rare disease knowledge; s2, constructing a virtual patient model, and carrying out probability modeling on a disease development process; s3, using a deep learning algorithm to generate virtual patient data under the guidance of the virtual patient model, and synchronously recording associated knowledge path metadata; s4, performing post-processing on the generated data; s5, providing the data to a medical diagnosis platform; s6, establishing a performance feedback module, and collecting and evaluating performance indexes of the downstream medical diagnosis model; and S7, executing attribution analysis and adaptive optimization. According to the method, the medical logicality of the data is ensured through the strong constraint of the knowledge graph, and the continuous iterative improvement of the data quality according to the application effect is realized through a closed-loop feedback mechanism.

Description

Technical Field

[0001] This invention relates to the field of medical data processing technology, and in particular to a method for generating fictitious medical data. Background Technology

[0002] The development and validation of medical diagnostic models heavily rely on large-scale, high-quality medical data. However, real-world medical data is often insufficient for model training due to privacy restrictions, high annotation costs, and the scarcity of rare case samples. Therefore, using deep learning techniques, particularly generative adversarial networks (GANs), to generate fictional patient data has become a research hotspot.

[0003] These technologies have shown potential in improving the statistical realism and diversity of generated data. However, existing deep learning generation methods often lack effective medical logical constraints. Models may generate data that appears statistically reasonable but is medically illogical or contradictory, such as combining mutually exclusive symptoms or violating known disease progression patterns. This logical flaw limits the usability of the generated virtual data and may even mislead the training of downstream diagnostic models.

[0004] At the same time, these generative models also face challenges in simulating rare cases because the real data on which they are trained suffers from severe class imbalance, making it difficult for the models to accurately capture and generate the unique features of rare diseases.

[0005] Furthermore, existing generative models are typically static. Medical knowledge and clinical guidelines are constantly being updated, while once a data generation model is trained, its internal knowledge becomes fixed. When new treatment options or disease insights emerge, the model cannot automatically update synchronously, and the virtual data it generates quickly becomes outdated.

[0006] Furthermore, existing methods generally lack a closed-loop mechanism for back-optimization based on application results. The quality assessment of generated data typically remains at the statistical level, while the actual performance of the data on downstream medical diagnostic platforms—such as whether it effectively improves the performance of diagnostic models in specific blind spots—cannot be fed back to the data generator. This disconnect between generation and application prevents models from undergoing targeted iterative improvements based on actual needs. Summary of the Invention

[0007] The purpose of this invention is to provide a method for generating virtual medical data, which solves the problems that existing virtual medical data generation methods generally lack medical logic constraints, have poor timeliness, and cannot adaptively optimize based on feedback from downstream applications.

[0008] To achieve the above objectives, the present invention provides the following technical solution: A method for generating fictitious medical data includes the following steps: S1. Collect and analyze medical data to establish a medical knowledge graph, which includes disease characteristics, symptoms, treatment plans and prognosis. S2. Based on the medical knowledge graph, construct a virtual patient model, which takes into account demographic characteristics and disease progression. S3. Using deep learning algorithms, generate virtual patient data based on the virtual patient model; S4. Post-process the generated virtual patient data, including data quality checks and the implementation of privacy protection mechanisms; S5. Provide the processed virtual patient data to the medical diagnostic platform. Preferably, in step S1, establishing the medical knowledge graph further includes: Entities and relationships specific to rare diseases are extracted from the rare disease database and incorporated into the entity set and relationship set of the medical knowledge graph.

[0009] Preferably, step S1 further includes: Establish a dynamic update mechanism to regularly collect the latest medical research findings and case data to update the medical knowledge graph. The updated medical knowledge graph is used to adjust the probability matrix structure and probability parameters of the virtual patient model.

[0010] Preferably, in step S3, while generating the virtual patient data, the following further steps are included: The associated knowledge paths of the medical knowledge graph on which its generation is based are synchronously generated and recorded as metadata; The deep learning algorithm is a generative adversarial network; The S3 step specifically includes: Condition vectors are sampled from the virtual patient model and used as condition inputs to the generator and discriminator of the generative adversarial network.

[0011] Preferably, in step S2, the virtual patient model includes: Static characteristics, including demographic characteristics; Dynamic characteristics, including clinical status that changes over time; The virtual patient model models the disease progression using state transition probabilities and observation emission probabilities constrained by the medical knowledge graph.

[0012] Preferably, in step S4, the data quality check includes: Using metadata, the associated knowledge paths are compared with the latest medical knowledge graph to perform a medical logic consistency check; The implementation of the privacy protection mechanism includes: Differential privacy processing is applied to the virtual patient data.

[0013] Preferably, after step S5, the method further includes: S6: Establish a performance feedback module to collect and evaluate the performance indicators of the medical diagnostic model after the virtual patient data is used to train the downstream medical diagnostic model.

[0014] Preferably, after step S6, the method further includes: S7: Perform attribution analysis and adaptive optimization, using the performance indicators of the medical diagnostic model as feedback signals to input in reverse to locate the root cause of the poor performance of the medical diagnostic model, and make targeted adjustments to the medical knowledge graph, the virtual patient model, or the deep learning algorithm based on the attribution results.

[0015] Preferably, in step S7, the attribution analysis specifically includes: The diagnostic weaknesses of the medical diagnostic model were analyzed, and the root cause was identified as follows: The knowledge deficiencies of the aforementioned medical knowledge graph; Representational bias of the virtual patient model; The deep learning algorithm has insufficient generative capabilities.

[0016] Preferably, in step S7, the adaptive optimization specifically includes at least one of the following: If the root cause is attributed to a knowledge deficiency in the medical knowledge graph, then the dynamic update mechanism is activated to target and mine medical research results related to diagnostic weaknesses. If the root cause is attributed to a representational bias in the virtual patient model, then the model parameters of the virtual patient model are relearned or fine-tuned. If the root cause is attributed to the insufficient generation capability of the deep learning algorithm, then during the adversarial training of the deep learning algorithm, the conditional vector corresponding to the diagnostic weakness feature is oversampled.

[0017] In summary, the present invention has at least one of the following beneficial technical effects: 1. This invention constructs a medical knowledge graph and establishes a virtual patient model strictly constrained by this graph, thereby guiding deep learning algorithms to generate data under this constraint. This solves the technical problem that existing deep learning methods only focus on statistical distribution and ignore medical logic, which may lead to self-contradictory data generated. This ensures that the generated virtual data conforms to real medical laws in terms of disease development and symptom manifestation.

[0018] 2. This invention addresses the technical problems of insufficient model training due to the scarcity of rare case samples in real medical data and the poor timeliness of generated data due to the inability of static models to reflect the latest clinical guidelines by introducing a rare disease database to expand the coverage when constructing the knowledge graph and establishing a dynamic update mechanism to synchronize with the latest medical achievements. In this way, it can generate sufficient and diverse rare case data and ensure the timeliness and accuracy of the data.

[0019] 3. This invention establishes a performance feedback module to collect the application effects after the data is delivered to the downstream platform, and uses the attribution analysis results to back-optimize the data generation model, thereby constructing a closed-loop system for data generation. This solves the technical problem that existing data generation methods are disconnected from downstream applications and cannot iteratively optimize the model based on the actual application effects of the data on the diagnostic platform. This enables the virtual data quality to be continuously improved according to the needs of downstream applications, enhancing the practicality and relevance of the method. Attached Figure Description

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

[0021] The following is in conjunction with the appendix Figure 1 The present invention will be further described in detail below.

[0022] See attached document Figure 1 This invention provides a method for generating fictitious medical data, comprising: Step S1 aims to construct a structured, dynamic, and comprehensive medical knowledge base as the foundation for subsequent virtual patient model construction and data generation. Step S1 can be further broken down into the following sub-steps: S101: Collect and analyze heterogeneous medical data from multiple sources.

[0023] To construct a comprehensive knowledge graph, data needs to be acquired from multiple sources. Medical data can include: anonymized electronic medical record (EMR) data, medical imaging data (such as CT and MRI scans) and their corresponding imaging reports, laboratory test reports, publicly available medical literature (such as journal articles and conference reports), industry-recognized clinical practice guidelines, and standard medical dictionaries (such as ICDs). During the analysis phase, these unstructured (such as literature and report texts) and semi-structured (such as EMR) data undergo preprocessing.

[0024] S102: Perform knowledge extraction and graph construction.

[0025] Natural Language Processing (NLP) techniques, particularly Named Entity Recognition (NER) and Relationship Extraction (RE) models, are used to identify and extract key medical entities and their relationships from the data processed by S101.

[0026] In this embodiment, a medical knowledge graph Defined as a directed multi-relation graph, its mathematical representation is as follows: .

[0027] For entity sets. It should include at least: disease entity (specific disease), symptom entity (clinical manifestation), drug entity, and examination or test entity.

[0028] This is a set of relations. The set of relations RR must include at least: those describing the association between the disease and its symptoms. (Symptoms) Relationships, descriptions of cause and effect (Causing) relationships, describing complications (Concurrent) relationships, descriptions of treatment plans (Therapeutic) relationship, and descriptions of disease development stages (Developed into) a relationship.

[0029] The set of fact triples has the following form: ; In the formula, For the head entity, For tail entities, To connect the head and tail entities. For example, a triplet (type II diabetes, Diabetic nephropathy is... One fact is that type 2 diabetes can lead to diabetic nephropathy complications.

[0030] S103: Introduce a rare disease database to expand the medical knowledge graph.

[0031] Connect to and integrate one or more public or proprietary rare disease databases (such as Orphanet). Extract disease-specific entities (such as rare disease names and rare symptoms) and relationships (such as genetic patterns and specific biomarkers) from these databases and incorporate them into a medical knowledge graph. In one example, an entity in a rare disease database is defined as... and as a set of entities A subset of this, to ensure the medical knowledge graph's coverage in the field of rare disease knowledge.

[0032] S104: Establish a dynamic update mechanism.

[0033] This step introduces timestamps to the fact triples. Each fact is expanded into a time-series quadruple. In the formula, This indicates the effective time interval of the fact triple or the point in time when it was first established.

[0034] This dynamic update mechanism establishes a continuous monitoring module to automatically collect the latest medical research findings and case data from S101 on a regular basis (e.g., monthly or quarterly) or based on event triggers (e.g., upon monitoring the release of a new version of clinical guidelines). The specific functions of this module are as follows: This module deploys web crawler scripts to monitor the websites of authoritative medical information publishers or calls the APIs of public databases (such as PubMed) to retrieve the latest published literature and guidelines. Simultaneously, the module can securely obtain the latest anonymized case data from the electronic medical record systems of partner hospitals through interfaces compliant with medical information exchange standards (such as HL7 FHIR).

[0035] The collection process can be triggered at a fixed period, such as through a server's scheduled task service (e.g., cron job in a Linux environment) to achieve automatic execution every month; in addition, to ensure timeliness, an event-driven triggering method can also be implemented. For example, when the crawler is monitoring authoritative websites, a non-periodic update process can be started immediately by comparing changes in the hash value of the target page content.

[0036] When dealing with conflicts between old and new knowledge, a multi-layered conflict resolution rule base is employed. First, it is based on the timestamps in the fact quadruple. The system prioritizes timestamps, giving higher priority to facts with more recent timestamps. Secondly, it assigns authority levels to different information sources (e.g., national clinical guidelines are considered higher than multicenter research papers), accepting facts from higher-authority sources when conflicts arise. Furthermore, the natural language processing module specifically identifies explicit obsolescence statements such as "replaces" and "no longer recommended" in newer literature to mark older facts as outdated. If the conflict cannot be automatically resolved according to these rules, the system will push the conflicting facts and their source links to an expert review interface for final human judgment.

[0037] The system extracts new sets of facts from the latest data (such as newly discovered drug targets or new complication relationships) and uses medical logic or expert rule bases to identify outdated or revised sets of facts (such as obsolete treatments).

[0038] exist Momentary Medical Knowledge Graph This can be updated through the following operations: ; In the formula, for A medical knowledge graph in real time; For the newly added set of valid fact quadruples; This is the set of outdated fact quadruples that need to be removed.

[0039] S105: Construct the graph storage and query interface. This will allow you to store and query the completed dynamic medical knowledge graph. The graph relationships are stored in a graph database (such as Neo4j) or a triplet library (RDFstore) for efficient storage and retrieval of complex graph relationships. A standardized query interface (such as an API) is provided, allowing subsequent S2 steps to access the graph's structure and content. This interface must support querying all relationships of a specific entity (such as a disease) (e.g., its corresponding symptoms, complications, development paths, and probabilities), thus providing medical logic constraints for the state transition probabilities and observational emission probabilities of the virtual patient model constructed in the S2 step.

[0040] For step S2, the core is to transform the relatively abstract medical knowledge graph constructed in step S1 into a probabilistic model that can be used to generate specific cases and is instantiable. This virtual patient model aims to simulate the complexity and dynamic evolution of patient states in the real world. Step S2 can be further decomposed into the following sub-steps: S201: Defines the components of the virtual patient model. The virtual patient model is defined as containing two core feature sets: Static characteristics: This set of characteristics includes the patient’s basic attributes that do not change or change slowly over time, such as age, sex, genetic factors, lifestyle (such as smoking history), etc.

[0041] Dynamic features: This feature set contains information about patients at different points in time. A range of observable clinical manifestations, such as symptoms, signs, and laboratory test results.

[0042] S202: Construct a probabilistic graphical model of the disease progression.

[0043] This embodiment uses a probabilistic graphical model, such as a Hidden Markov Model (HMM) or a Dynamic Bayesian Network (DBN), to describe the dynamic behavior of the virtual patient model.

[0044] In this model, a latent disease state is introduced to represent the patient's condition at a given time point. These are real disease stages that cannot be directly observed (e.g., the early stage, progression stage, or complication stage of a disease). These implicit states correspond to disease or disease stage entities within the medical knowledge graph in S1.

[0045] Simultaneously, observable clinical manifestations are introduced to represent specific clinical data within dynamic features (e.g., elevated symptom A, elevated test result B). These observable clinical manifestations correspond to symptoms or examination entities within the medical knowledge graph in S1.

[0046] S203: Define the probability distribution constrained by the medical knowledge graph.

[0047] The dynamic behavior of the virtual patient model is defined by two key conditional probability distributions: State transition probability : ; In the formula, for Implicit disease state at any given moment; for Implicit disease state at any given moment; This is a static feature. This probability describes the pattern of disease state evolution over time.

[0048] Observational launch probability : ; In the formula, for Observable clinical manifestations at any given time; for Implicit disease state at any given moment; It is a static feature; To observe the emission probability. This probability describes the likelihood that a patient will exhibit a specific clinical symptom or sign in a given disease state.

[0049] The probability distribution structure of the aforementioned state transitions and observation launches is strictly constrained by the medical knowledge graph constructed in S1. Specifically, that is, from arrive transition probability .

[0050] At once In terms of structure, emission probability Only in the set of fact triples of the medical knowledge graph A non-zero value is only allowed when there are corresponding symptoms or test results.

[0051] To determine the specific values ​​of these non-zero probabilities, this step employs a two-stage learning approach.

[0052] The first stage is initialization: The system first sets an initial probability for all allowed (non-zero) state transitions and observations based on statistical evidence or confidence scores in the knowledge graph. For example, the frequency with which a fact is mentioned in source literature or the authority of its source can be quantified and mapped to an initial probability value. Then, all outgoing probabilities for each state are normalized to form an initial probability matrix.

[0053] The second stage is iterative optimization: Next, a constrained Baum-Welch algorithm (an expectation-maximization EM algorithm) is employed to iteratively fine-tune these initial probabilities using available real patient time-series case data. When updating probabilities, this algorithm consistently enforces the zero-probability constraint set by the knowledge graph, ensuring that paths easily judged as unreasonable virtual data are not learned.

[0054] The algorithm's convergence condition is set as follows: the gain of the model's log-likelihood of the data between two iterations is less than a preset small threshold, or the preset maximum number of iterations is reached. This method can effectively address the data sparsity problem. For rare transitions or manifestations that are permitted by the knowledge graph but have never appeared in real data, their probabilities will retain the initial estimates, thus ensuring that the model can still generate effective rare case data based on medical prior knowledge even in the absence of direct training samples.

[0055] S204: Model parameter learning.

[0056] It was determined by the medical knowledge graph in S203. and After establishing a sparse structure (i.e., which transitions and emissions are zero), the system utilizes real medical data collected in S101 and employs machine learning algorithms (such as the Baum-Welch algorithm or variational inference) to... and The non-zero probability parameters in the model are estimated and learned.

[0057] S205: Model tuning and instantiation.

[0058] When the dynamic update mechanism in S104 leads to the medical knowledge graph Updated to At that time, step S2 is triggered for adjustment.

[0059] The adjustment includes: Structural adjustment: based on The paths added or deleted in the middle, for and The probability matrix structure was modified.

[0060] Parameter adjustment: The probability parameters corresponding to the introduced new structure are relearned or fine-tuned.

[0061] Before step S3 is executed, the completed virtual patient model can be used for instantiation. By sampling from the virtual patient model, one or a batch of specific patient profiles can be generated (e.g., a profile containing specific...). And a time sequence (Patient instances along the path), this profile will serve as the conditional input for the deep learning algorithm in step S3.

[0062] The purpose of step S3 is to generate realistic fictional data in terms of both statistical distribution and medical logic, under the strong constraints of the virtual patient model constructed in step S2.

[0063] S301: Select a deep learning algorithm model.

[0064] The deep learning algorithm in this embodiment employs a generative adversarial network (GAN) architecture, specifically a conditional generative adversarial network (cGAN). This architecture includes two core neural network modules: a generator and a discriminator.

[0065] S302: Constructing knowledge-guided conditional inputs.

[0066] The virtual patient model built in step S2 is not used to directly generate data in this step, but rather to generate the condition vector required in step S3.

[0067] Specifically, the system samples from the virtual patient model to obtain one or a batch of instantiated patient profiles. This profile (i.e., the conditional vector) contains the static features defined in S201, as well as the dynamic disease development path defined in S202 that conforms to medical logic (such as the logic of a temporal implicit disease state and its corresponding observable clinical manifestations).

[0068] The condition vector is used as the conditional input for both the generator and the discriminator.

[0069] S303: Conduct adversarial training.

[0070] The generator and discriminator are trained through adversarial game theory. The generator takes a vector of random noise and a conditional vector, and its goal is to generate fictional patient data. The discriminator takes real medical data or generated virtual patient data and combines it with the same conditional vector, and its goal is to accurately distinguish between real medical data and virtual patient data.

[0071] The objective function for this adversarial training is defined as: ; In the formula, For generator; For discriminators; For distribution of real medical data Real samples; For the prior distribution of noise A random noise vector; This is a conditional vector obtained from the virtual patient model; For the generated virtual patient data; As expected.

[0072] Through this training, Forced to learn medical logic defined by the S2 model Below, generate The inability to distinguish between genuine and fake data ensures the medical rationality and realism of the generated data.

[0073] S304: Generate virtual patient data.

[0074] After the adversarial training of S303 converged, The model is solidified. During the generation phase, the system samples a new conditional vector from the virtual patient model. Sample a random noise from the noise distribution ,pass This will generate a completely new one that conforms to... Virtual patient data defined by medical logic.

[0075] S305: Synchronously generate metadata for related knowledge paths.

[0076] This step is performed during S304 generation. Simultaneously, while defining the virtual patient data for medical logic, the associated metadata (MM) is generated and recorded.

[0077] Specifically, when S304 needs to sample condition vectors from the virtual patient model, this sampling process (as in S203, based on...) and The sampling itself involves traversing a specific path within the S1 medical knowledge graph. The system captures and records the key fact triples in S1 upon which this sampling is based. The set of these traversed triples constitutes the associated knowledge path, i.e., metadata.

[0078] Therefore, the final output of step S3 is a data pair. In the formula, It is generated virtual patient data. It is support Generates logical metadata about knowledge paths from a medical knowledge graph. This data is... It will be transferred to step S4 for post-processing.

[0079] Step S4 involves verifying and finalizing the data pairs output from step S3 (i.e., virtual patient data and its associated metadata) to ensure that the data delivered to S5 is of high quality, logically consistent, and compliant with privacy and security regulations. Step S4 can be further broken down into the following sub-steps: S401: Perform a data quality check.

[0080] Perform a series of automated checks on the virtual patient data generated by S3, specifically including: Integrity check: Verify that there are no unexpected missing values ​​in the data.

[0081] Format check: Verify that the data conforms to predefined field types and formats (e.g., date format, encoding standards).

[0082] Value range check: Verify whether key physiological parameters (such as heart rate, blood pressure, body temperature) or test values ​​fall within a reasonable physical or medical range, and remove obviously abnormal outliers.

[0083] S402: Perform medical logical consistency checks. This step is central to the data quality check; it uses generated metadata to perform a deep validation of the virtual patient data. This validation includes: Internal logical consistency check: This checks whether there are any logical contradictions in the virtual patient data itself. For example, it verifies whether a record contains both a male gender and a diagnosis of pregnancy, which could be logically conflicting.

[0084] External knowledge consistency verification: This is a critical verification step. The system compares the metadata (i.e., knowledge paths) corresponding to the virtual patient data with the latest medical knowledge graph constructed in step S1. It verifies whether each associated knowledge path recorded in the metadata corresponding to the virtual patient data is still valid in the latest medical knowledge graph.

[0085] Only data pairs that pass both internal logical consistency checks and external knowledge consistency checks can be valid. Only then is it considered valid data and proceeds to the next sub-step.

[0086] S403: Implement a privacy protection mechanism.

[0087] Although the virtual patient data generated by S3 is fictitious, generative adversarial networks are at risk of remembering and leaking specific individual information from the real training data they use during training.

[0088] To mitigate this risk, this step implements strict privacy protection measures for virtual patient data that passes the S402 verification. In one embodiment, this mechanism is... The system adds random noise conforming to a Laplace or Gaussian distribution to numerical features (such as test results and age) in virtual patient data, or randomizes the response to categorical features.

[0089] This mechanism ensures that the output distribution of the final dataset is statistically indistinguishable after adding or deleting any real training sample, thus mathematically guaranteeing that the generated data cannot be traced back to any real individual.

[0090] S404: Generate and store verified data. Data pairs that have passed all post-processing steps S401 (quality check), S402 (logic verification), and S403 (privacy protection) are aggregated to form a verified, trusted, and secure virtual patient dataset. This dataset is stored in a database for later retrieval in step S5.

[0091] Step S5 is the data output and application delivery stage of this method.

[0092] Step S4 produces qualified virtual patient data pairs that have passed all checks and processing; these pairs are then organized and ready for use. Step S5 can be further broken down into the following sub-steps: S501: Organization and storage of virtual patient data.

[0093] The qualified virtual patient data and its associated knowledge path metadata output from step S4 are structured and organized. In one example, this data is stored in a virtual case database or packaged into standard dataset files, such as JSON, CSV, or HDF5 formats, for use by downstream platforms.

[0094] S502: Data delivery.

[0095] This step provides a data access interface for the medical diagnostic platform. One delivery method is through an application programming interface (API), allowing the medical diagnostic platform to query and retrieve one or more virtual patient data sets in real time based on specific needs (e.g., specifying disease type, patient age group, or disease stage). Another delivery method is to provide the medical diagnostic platform with the organized dataset files in S501 in batches via secure file transfer or offline storage media.

[0096] S503: Data Application.

[0097] After receiving virtual patient data, the medical diagnostic platform can use it for various downstream application scenarios.

[0098] Application Scenario 1: Training and Validation of Medical Diagnostic Models. Virtual patient data and their corresponding labels (which can be extracted from metadata or conditional vectors in S302) are used as training data to train downstream (e.g., deep learning-based) medical diagnostic models. In particular, due to the introduction of a rare disease database in S103, this method can generate sufficient rare disease case data to address the problem of insufficient training of downstream diagnostic models in rare disease identification caused by data scarcity.

[0099] Application Scenario 2: Simulation training for medical students or clinicians. The medical diagnostic platform can present virtual patient data as a simulated case to learners. The platform can also selectively display knowledge path metadata associated with the virtual patient data, serving as a medical logical explanation and teaching reference for the case.

[0100] Application Scenario 3: Functional verification of medical information systems. Virtual patient data can be used for functional testing or stress testing of medical diagnostic platforms or related electronic medical record systems.

[0101] Step S5 is a prerequisite for establishing the performance feedback module in step S6. The process of training and using the diagnostic model in application scenario S503 of the medical diagnostic platform is the object of performance metric collection in step S6.

[0102] Regarding step S6, which is the entry point for implementing the closed-loop feedback system of this invention, its core lies in quantifying the training effect of the virtual patient data delivered in step S5 in practical applications and providing a decision basis for the adaptive optimization in step S7. Step S6 can be further decomposed into the following sub-steps: S601: Determine the evaluation object and validation set. The evaluation object is the downstream medical diagnostic model trained on the virtual patient dataset mentioned in S503. To objectively evaluate the performance of the downstream medical diagnostic model, an independent real validation set that was not involved in the GAN training in S3 is reserved from the collected real medical data. This real validation set contains real patient data and their corresponding real labels (e.g., real diagnostic results).

[0103] S602: Performance Evaluation. The system applies the downstream medical diagnostic model to the real validation set. That is, for each real sample in the real validation set, the predicted output of the medical diagnostic model is calculated.

[0104] S603: Collect and evaluate the performance metrics of medical diagnostic models.

[0105] Based on the predicted output and real labels of S602, calculate one or more preset performance indicators of the downstream medical diagnostic model on the real validation set.

[0106] In one embodiment, the performance metric is the overall loss of the medical diagnostic model on the real validation set: ; In the formula, These are samples from the real validation set; The model predicts the output; This is a real label; For example, a predefined loss function, such as the cross-entropy loss function; This represents the expectation of all samples on the true validation set. This represents the overall loss.

[0107] In other embodiments, performance metrics may include, but are not limited to, diagnostic accuracy, precision, recall, F1 score, or area under the receiver operating characteristic curve.

[0108] S604: Locating and diagnosing weak points.

[0109] This step will further examine the model in the real validation set. A subset of poorly performing samples is identified and labeled.

[0110] In one example, the system identifies a subset of difficult samples in the true validation set that results in high loss. : ; In the formula, Loss for a single sample; A preset loss threshold is used; Difficult sample subset.

[0111] In another example, the weak link is located by analyzing local performance metrics (such as recall on that subset) for a specific category or population.

[0112] S605: Generate feedback signals. The overall performance indicators collected in S603 and the diagnostic weaknesses identified in S604 (such as data characteristics of difficult sample subsets or specific categories of low performance indicators) are structured and summarized as feedback signals, and transferred to step S7 for attribution analysis.

[0113] Step S7 receives the feedback signal generated by S605, locates the problem through attribution analysis, and initiates targeted optimization of upstream steps (S1, S2, and S3). Step S7 can be further decomposed into the following sub-steps: S701: Perform attribution analysis.

[0114] The system receives performance metrics and diagnostic weakness information from step S6. It then performs in-depth analysis of the common characteristics of the difficult sample subsets or low-performance categories identified in step S604. For example, it analyzes whether these samples are concentrated on a specific rare disease introduced in step S103, or a specific static characteristic (such as a specific age group or gender) defined in step S201.

[0115] Based on the analysis results, the system attributes the poor performance of the medical diagnostic model to one or more of the following upstream steps: Attributable to S1 (knowledge deficit in medical knowledge graphs): If the analysis finds that the relevant knowledge (such as symptoms and complications) of the disease corresponding to the difficult sample subset (e.g., a rare disease) in the medical knowledge graph constructed in S1 is sparse, missing, or outdated (not updated in time by S104). This judgment is made through specific verification steps: the system automatically abstracts the key medical facts in the difficult sample (e.g., the association between disease A and rare complication B) into a fact query and retrieves the knowledge graph. If the query result is false or conflicts with known facts, the root cause is clearly attributed to the knowledge defects of the knowledge graph.

[0116] Attributable to S2 (representational bias in virtual patient models): If the medical knowledge graph is complete, but the prediction bias of the medical diagnostic model corresponding to the difficult sample subset exhibits statistical regularity. For example, the parameters of the state transition probability or observational emission probability in the prediction of complications based on static characteristics of a specific population in S203. It failed to accurately learn the distribution of real-world data, resulting in representational bias. This characterization bias is identified and confirmed in the following way: This step is based on the probability matrix of S2 ( We perform direct Monte Carlo sampling to generate a theoretically optimal data distribution. If this theoretical distribution differs significantly from the real-world data distribution in key features (e.g., as measured by KL divergence), it can be demonstrated that the root cause lies in the S2 model itself failing to accurately represent reality.

[0117] This is attributed to S3 (insufficient generative capability of deep learning algorithms): If both the medical knowledge graph and the virtual patient model are verified to be logically complete and accurately represented, but the performance of the medical diagnostic model is still poor, it is attributed to the generator in S303 failing to fully learn and fit the data distribution of a conditional vector related to a difficult subset of samples provided by the virtual patient model, resulting in insufficient realism of the generated virtual patient data in this specific scenario. The "verification" process here provides a clear distinguishing criterion: a three-way comparison is made between the data distribution generated by S3, the theoretical data distribution directly sampled from the S2 model, and the real data distribution. When the theoretical data distribution of S2 is consistent with the real data distribution, while the data distribution generated by S3 differs significantly from both, the root cause of the failure can be determined to be isolated in the generator of S3 (e.g., due to training instability or pattern collapse), because it failed to reproduce a model that has been proven to be accurate.

[0118] S702: Perform adaptive optimization.

[0119] Based on the attribution analysis results of S701, the overall parameters of this method are updated in a targeted manner.

[0120] Regarding the adjustment to S1: If S701 is attributed to a knowledge deficiency in S1, the system will activate the dynamic update mechanism of S104. This mechanism will be guided to selectively and with high priority mine the latest medical research findings related to the characteristics of the difficult sample subset (such as the name of the rare disease) from the S101 data source, in order to generate... And update This helps to fill knowledge gaps.

[0121] Adjustment for S2: If S701 is attributed to a representational bias in S2, the system will trigger a relearning or fine-tuning of the virtual patient model parameters in S204.

[0122] In one embodiment, the system can utilize the features of a difficult subset of samples to adjust the parameters of the simulated patient model through reinforcement learning or gradient ascent, thereby correcting the bias in the probability distribution.

[0123] Regarding the adjustment to S3: If S701 is attributed to insufficient generation capability of S3, the system will oversample the condition vectors corresponding to the difficult sample subset features obtained from the simulated patient model in the next round of adversarial training (S303). By increasing the frequency with which the generator and discriminator encounter these difficult sample conditions, the generator is forced to invest more computational resources to fit the data distribution of this weak link, thereby improving generation capability.

[0124] Through the performance feedback and adaptive optimization closed loop formed by S6 and S7, this method can start from the application effect and iteratively optimize the data generation model in reverse, ensuring the continuous improvement of virtual patient data in medical logic, statistical distribution and timeliness.

Claims

1. A method for generating fictitious medical data, characterized in that, Includes the following steps: S1. Collect and analyze medical data to establish a medical knowledge graph, which includes disease characteristics, symptoms, treatment plans and prognosis. S2. Based on the medical knowledge graph, construct a virtual patient model, which takes into account demographic characteristics and disease progression. S3. Using deep learning algorithms, generate virtual patient data based on the virtual patient model; S4. Post-process the generated virtual patient data, including data quality checks and the implementation of privacy protection mechanisms; S5. Provide the processed virtual patient data to the medical diagnostic platform.

2. The method for generating fictitious medical data according to claim 1, characterized in that, In step S1, establishing the medical knowledge graph further includes: Entities and relationships specific to rare diseases are extracted from the rare disease database and incorporated into the entity set and relationship set of the medical knowledge graph.

3. The method for generating fictitious medical data according to claim 1, characterized in that, Step S1 further includes: Establish a dynamic update mechanism to regularly collect the latest medical research findings and case data to update the medical knowledge graph. The updated medical knowledge graph is used to adjust the probability matrix structure and probability parameters of the virtual patient model.

4. The method for generating fictitious medical data according to claim 1, characterized in that, In step S3, while generating the virtual patient data, the following is further included: The associated knowledge paths of the medical knowledge graph on which its generation is based are synchronously generated and recorded as metadata; The deep learning algorithm is a generative adversarial network; The S3 step specifically includes: Condition vectors are sampled from the virtual patient model and used as condition inputs to the generator and discriminator of the generative adversarial network.

5. The method for generating fictitious medical data according to claim 1, characterized in that, In step S2, the virtual patient model includes: Static characteristics, including demographic characteristics; Dynamic characteristics, including clinical status that changes over time; The virtual patient model models the disease progression using state transition probabilities and observation emission probabilities constrained by the medical knowledge graph.

6. The method for generating fictitious medical data according to claim 1, characterized in that, In step S4, the data quality check includes: Using metadata, the associated knowledge paths are compared with the latest medical knowledge graph to perform a medical logic consistency check; The implementation of the privacy protection mechanism includes: Differential privacy processing is applied to the virtual patient data.

7. The method for generating fictitious medical data according to claim 1, characterized in that, Following step S5, the following further includes: S6: Establish a performance feedback module to collect and evaluate the performance indicators of the medical diagnostic model after the virtual patient data is used to train the downstream medical diagnostic model.

8. The method for generating fictitious medical data according to claim 1, characterized in that, Following step S6, the following further includes: S7: Perform attribution analysis and adaptive optimization, using the performance indicators of the medical diagnostic model as feedback signals to input in reverse to locate the root cause of the poor performance of the medical diagnostic model, and make targeted adjustments to the medical knowledge graph, the virtual patient model, or the deep learning algorithm based on the attribution results.

9. The method for generating fictitious medical data according to claim 1, characterized in that, In step S7, the attribution analysis specifically includes: The diagnostic weaknesses of the medical diagnostic model were analyzed, and the root cause was identified as follows: The knowledge deficiencies of the aforementioned medical knowledge graph; Representational bias of the virtual patient model; The deep learning algorithm has insufficient generative capabilities.

10. A method for generating fictitious medical data according to claim 1, characterized in that, In step S7, the adaptive optimization specifically includes at least one of the following: If the root cause is attributed to a knowledge deficiency in the medical knowledge graph, then the dynamic update mechanism is activated to target and mine medical research results related to diagnostic weaknesses. If the root cause is attributed to a representational bias in the virtual patient model, then the model parameters of the virtual patient model are relearned or fine-tuned. If the root cause is attributed to the insufficient generation capability of the deep learning algorithm, then during the adversarial training of the deep learning algorithm, the conditional vector corresponding to the diagnostic weakness feature is oversampled.

Images