Synthetic Medical Data: Utility Without Identifiability

Key takeaways

• Synthetic data is not automatically anonymous. Anonymity is a documented conclusion about specific data and specific recipients, not something the word “synthetic” provides.
• It differs from anonymized, pseudonymized and masked data. Synthetic data is newly generated records, while the other three are transformed real records, and each has different privacy and legal consequences.
• Utility means fitness for a purpose. Set thresholds first, then test distributions, clinical relationships, rare subgroups and missingness. Train on synthetic data and test on held-out real data to see whether the dataset can do the job you need.
• Risks remain after generation. These include memorization of unusual records, membership and attribute inference, and linkage with external data. Rare diseases and small populations are the highest-risk cases.
• Differential privacy helps but is not a guarantee. It gives a formal, parameter-dependent bound and works best alongside empirical attack testing against a defined attacker.
• The law still applies to the source data. Training a generator is processing of health data. The EDPB’s 2026 draft guidelines, still in consultation, apply the same anonymity test to synthetic data as to any other candidate.
• Before sharing, validate and document. Work through the checklist and involve legal and data protection review. Passing it does not by itself prove compliance or anonymity.

Consider a hospital group that wants a model to flag patients likely to develop chronic kidney disease within three years. The raw material exists: a decade of lab results, prescriptions and admissions. But it sits in a clinical data warehouse, the external team that would build the model cannot be given access, a research partner in another country needs a data-sharing agreement that will take months to negotiate, and the most informative records, the unusual ones, are exactly the hardest to release. The data that can be shared is often too heavily redacted, or too small, to train anything reliable.

What it does not do is remove privacy security risk by default. A generator trained on real patients can reproduce unusual records or let someone infer facts about people in its training data, and whether a synthetic dataset counts as anonymous under GDPR depends on a documented assessment of the specific data and its recipients, not on the word "synthetic." This guide explains how synthetic medical data is generated, how it differs from anonymized, pseudonymized and masked data, how to test whether it is useful and whether it is safe to share, and where the law draws its lines.

What is synthetic medical data?

Synthetic data generation comes in two broad families. Data-driven methods fit a model to real patient records and then sample new records from it. Process-driven methods build records from clinical rules and published statistics. The open-source Synthea generator, for example, simulates patient life histories from encoded care pathways. Goncalves and colleagues describe this split, and it matters for privacy: a process-driven generator may use little or no individual-level patient data, while a data-driven one is, by construction, shaped by the people in its training set. Process-driven data has its own weakness, which is realism. A validation study of Synthea that compared its output with publicly reported clinical quality measures concluded that the generator did not model deviations from standard care and the outcomes that follow from them.

Synthetic records are not real records with the names changed. Take a 58-year-old woman with type 2 diabetes, two admissions and a particular medication history. Pseudonymization swaps her name for a code and leaves everything else untouched; it is still her record. Masking might generalize her postcode and replace her age with a band; it is still her record, with some fields blurred. A data-driven synthetic dataset instead contains new rows sampled from a model that learned how age, region, HbA1c, medications and admissions tend to go together. No row is supposed to correspond to her. Whether any row is nonetheless too close to hers, or whether the dataset reveals that she was in the source data at all, is an empirical question, and we return to it in the privacy section.

A note on terminology: "synthetic" is also used in drug development for synthetic control arms, which are comparator groups assembled from real historical-trial or real-world patient data. That is not the same thing as AI-generated patients, and a recent review of regulatory frameworks points out how inconsistently the term is used. We come back to the distinction under clinical research.

How synthetic medical data is generated

Most projects follow the same sequence: prepare and govern the source data, choose and train a generator, produce records, validate utility, test privacy, then release under controlled conditions. The order matters because the later checks often send you back to earlier choices.

Step 1: Prepare and govern the source data

Start with the purpose. The use case determines which variables, time span and cohort you need, and what "good enough" will mean later. Clean and harmonize the data (consistent coding systems, units, date logic, duplicate handling), because a generator will faithfully learn your data-quality problems. Before training, split off a real evaluation set that the generator never sees. You will need it for both utility and privacy tests, and a test set that leaked into training makes both meaningless.

Check permissions at this stage, not at release. Training a generator on patient data is itself processing of health data, so the legal basis and conditions that cover it must be settled before it starts (see the regulation section below). Look beyond the tidy tables, too. Free-text notes, imaging metadata and scanned documents can carry names, dates and facility details that structured pipelines never expect, and sensitive data tends to spread across the copies, exports and logs a project creates. Questa AI's guide to finding sensitive data across AI workflows covers how to inventory those places.

Step 2: Choose a generation approach

No method wins everywhere. The right choice depends on your data type, sample size and intended use.

Statistical and sequential models fit distributions and conditional relationships directly, for example by synthesizing one variable at a time conditional on those already generated, or by modeling dependence with copulas. They are transparent, quick to audit and often the right starting point for modest-sized tabular data. They struggle with complex longitudinal patterns and rely on you to specify the relationships you care about.

Bayesian networks learn a graph of dependencies between variables and sample from it. Because the learned structure can be inspected, a clinician can see which variables the model links, which helps catch nonsensical relationships. They suit categorical clinical data and have differentially private variants. Their limits are continuous variables (usually discretized), large numbers of variables and irregular longitudinal records.

Generative adversarial networks (GANs) train a generator against a discriminator and can model mixed numeric and categorical data with complex interactions. The practical risks are unstable training; mode collapse, where the model drops rare categories (precisely the rare diagnoses a clinical team may care most about); and memorization of training records when the dataset is small.

Variational autoencoders (VAEs) learn a compressed representation and decode samples from it. They are usually easier to train than GANs and can handle missing values more gracefully, but they tend to smooth over sharp relationships and tails, and nothing about the architecture makes them private.

Newer approaches, including diffusion models and large language models for clinical text, images and long patient trajectories, are developing quickly, but their validation methods are less settled than for tabular data. Goncalves and colleagues compared probabilistic models, classification-based imputation and GANs on cancer registry data and discuss the trade-offs among them. Stadler, Oprisanu and Troncoso found that the privacy–utility trade-off of synthetic data is hard to predict in advance. The practical lesson is the same in both: choose a method for your data, then measure the result rather than assuming it.

Step 3: Generate, validate, test privacy, release

Generate a dataset and judge it against the thresholds you set in Step 1: utility first, then privacy attacks. Tuning one moves the other. Stronger privacy settings usually cost fidelity, and rare subgroups are typically the first casualty. Then decide the form of release. A dataset can be shared openly, under a data-use agreement, or only inside a secure environment. Releasing the generator itself is a different and riskier choice than releasing a fixed dataset, because the recipient can query it without limit. Plan for monitoring as well: re-assess when the source data, the model or the external data available to an attacker changes.

These categories overlap in practice. Pseudonymization is often a first step toward anonymization. A synthetic dataset can be generated from pseudonymized data. Masking a free-text note is a de-identification step that may or may not reach anonymity. And a synthetic dataset whose generator was trained with differential privacy and tested against realistic attacks may support an anonymity conclusion for a given recipient, while an untested one may not. What matters is the exact transformation applied and the evidence behind the claim, not the label. The EDPB's draft guidelines make the same point: controllers should not describe data as "anonymous," "de-identified" or "de-personalised" if individuals are still identifiable. Questa AI's comparison of how anonymization and pseudonymization differ is a useful companion if your team uses these terms inconsistently.

How to measure whether synthetic healthcare data is useful

Utility is fitness for a purpose, not a single score. A dataset can match every marginal distribution and still fail the one research question you needed it for. So define the purpose and acceptable thresholds before you look at results; otherwise it is easy to rationalize whatever comes out. Different purposes set different bars: valid schemas and realistic ranges for software testing; a small gap in downstream model performance for prototyping; the right direction and rough size of associations for exploratory epidemiology. For confirmatory analyses that will drive clinical or regulatory decisions, synthetic data on its own is generally not a substitute for the real data.

Statistical fidelity versus usefulness

Fidelity asks how closely the synthetic data resembles the real data statistically. Usefulness asks whether the conclusions and models you would build from it are good enough for the task. High fidelity on easy-to-measure statistics can hide failure on the relationships that matter, so test both, and give usefulness more weight.

What to test

Distributions. Compare each variable's distribution between real and synthetic data using summary statistics and distance measures, such as the Kolmogorov–Smirnov statistic for continuous variables and total variation distance for categorical ones. Look at the tails, not just the means.

Clinically meaningful relationships. Go beyond pairwise correlations. Does insulin use rise with HbA1c the way it does in practice? Do the timing and sequence of diagnoses, prescriptions and admissions make clinical sense? Are impossible combinations absent (pregnancy in male patients, discharge before admission, a drug prescribed for a condition the patient does not have)? Ask a clinician to name a handful of relationships that must hold.

Rare conditions and subgroups. Check whether rare diagnoses appear at all, at about the right frequency, with realistic co-occurring conditions. Repeat the checks for subgroups defined by age, sex, site and, where recorded and lawful to use, ethnicity, and for their intersections. Generators optimize for the bulk of the data, so small groups are where they fail first.

Missingness and data quality. In clinical data, missing values carry information: a lab test is often absent because it was not clinically indicated. A synthetic dataset that fills everything in, or scatters gaps at random, looks tidy and misleads. Compare missing-data rates and what they depend on, along with value ranges, units and coding.

Downstream model performance. Train a model on synthetic data and test it on real held-out data the generator never saw (often called train-on-synthetic, test-on-real), then compare it with the same model trained on real data. Report the gap overall and by subgroup, and report calibration as well as discrimination. Test separately whether adding synthetic records to real training data helps, because that is a different question.

Analytical replication. If the dataset is meant to support research, run the planned analyses on both versions and compare effect estimates and confidence intervals. A validation study at one institution compared results from five observational studies on real data with results from synthetic data produced by a single commercial system. It reported that the synthetic results gave close estimates and were useful for shaping hypotheses, and it also stated that broader validation across clinical questions and data types was needed. Read that as evidence the approach can work, not as evidence that your dataset does.

Bias and unrealistic records. Synthetic data inherits the biases of its source and can amplify them, for instance by under-representing groups that were already sparse. Compare subgroup representation with the source and with the population you intend to serve. Have clinicians review a random sample plus the most extreme records for implausibility. A classifier trained to tell real from synthetic records can also help: if it separates them easily, something systematic is off, although failing to separate them is not proof of quality.

A worked example (illustrative figures)

Suppose a hospital wants to share a synthetic type 2 diabetes cohort so that an external team can prototype a model predicting progression to chronic kidney disease within three years. The source is a 40,000-patient extract with age, sex, HbA1c, eGFR, BMI, comorbidities (hypertension, heart failure), treatments (metformin, insulin, SGLT2 inhibitors) and the outcome. Before generating anything, the team sets its thresholds: a train-on-synthetic, test-on-real AUROC within 0.03 of the real-trained model overall and within 0.05 in any subgroup of at least 500 patients, and key clinical relationships preserved within a stated tolerance.

On marginal statistics alone, this dataset looks fine. Against the criteria the team set in advance, it fails: relationships among HbA1c, treatment and outcome are flattened, a clinically important subgroup has mostly disappeared, and a model trained on it underperforms by more than the team accepted. It may still be fine for pipeline testing and schema development, but not for the model-development purpose it was commissioned for. The sensible response is to revisit the generator (a different method, more training, conditional generation for the under-represented subgroup), re-run the utility tests, and repeat the privacy tests, since every change to the generator also changes its privacy behavior.

Privacy and re-identification risks in synthetic patient data

The intuition that no synthetic row belongs to a real person is only part of the story. Privacy risk in synthetic data is about what an attacker can learn about real individuals from the output, and there are several routes.

Memorization and copying. A generator, particularly one that is overfitted or trained on a small dataset, can reproduce training records or near-duplicates. Unusual records are the most exposed, because nothing else in the data resembles them and the model has little reason to generalize. A common heuristic compares how close synthetic records are to the training records versus to held-out real records. If synthetic records sit systematically closer to the training data, that suggests leakage.

Membership inference. Here an attacker holding a person's record tries to determine whether it was part of the data used to train the generator. Shokri and colleagues demonstrated this kind of attack against machine-learning models, including models trained on a hospital discharge dataset, and the same logic has been applied to synthetic data. Membership can be sensitive in itself: appearing in a cancer-clinic dataset reveals something.

Attribute inference and linkage. An attacker who knows a few facts about a person (an age band, sex, region, perhaps that they attended a given clinic) and that they were in the source data can use the synthetic data to estimate unknown attributes such as a diagnosis. Where the synthetic data preserves rare combinations of quasi-identifiers, matching against external datasets, such as registries, other releases or public records, gets easier. Not every inference is a privacy failure, though. Learning population-level patterns is the point of the exercise. The EDPB draft distinguishes inferences that depend on a person's own record from those that could be drawn from general knowledge or population data, and describes comparing results with and without that person's record as one way to tell them apart.

Rare diseases, small populations and distinctive histories. This is where all of the above is worst. Imagine a rare condition with a few dozen known patients in a country. A generator has to stay close to those few records to preserve the condition at all, and a synthetic patient with that diagnosis, a plausible age of onset and a region may well be recognizable to anyone who knows that community. Rich longitudinal histories, with particular sequences of admissions and procedures, are similarly distinctive. The more detail the data keeps, the greater the exposure: the EDPB draft notes that re-identification techniques tend to be more effective against record-level data with high dimensionality and high resolution.

What the research shows. Stadler and colleagues evaluated a range of generative models and concluded that synthetic data either did not prevent inference attacks or did not retain utility, and that it did not offer a better privacy–utility trade-off than traditional anonymization techniques. They also found the trade-off hard to predict. That does not make synthetic data unsafe. It means the privacy gain is variable, must be measured for each dataset, and that an untested claim of safety is the real problem.

Differential privacy: what it does and does not do

Differential privacy (DP) is a mathematical framework that limits how much any one person's record can change the output of a computation (Dwork and Roth, 2014). Applied to training a generator, it gives a formal bound, governed by a privacy parameter usually written epsilon, on what an attacker can learn about whether any individual was in the data. That is a real property that heuristic testing cannot provide. It is not a promise of zero risk. The guarantee depends on the parameters chosen and on correct implementation. Tighter settings reduce utility, and rare subgroups usually pay first. Repeated releases consume privacy budget. Correlated records, such as relatives or repeat admissions, complicate what per-record protection means. And choosing epsilon is a risk decision, not a technical default. Treat DP as one strong control inside a program that also includes empirical attack testing.

Test against a defined attacker

Privacy testing means little without an attacker model. Specify who receives the data (a named research partner under contract, a public download, a vendor), what auxiliary information they could have (other releases, registries, local knowledge of patients), what access they have (a fixed dataset, or a generator they can query) and what they would gain. The EDPB draft says anonymity should be assessed from the perspective of those who will have access to the data after transfer, lists potentially relevant actors from receiving entities and rogue employees to investigative journalists, neighbours and cybercriminals, and says contractual restrictions can complement technical measures but are not a substitute for them. A dataset released to a few vetted researchers inside a secure environment and one posted publicly face different attackers, and need different evidence.

Where regulation fits

The legal status of a synthetic dataset depends on its facts, its recipients and its jurisdiction, so what follows is a map of the main ideas rather than legal advice.

Anonymous versus personal data. GDPR does not apply to anonymous information, which Recital 26 describes as information that does not relate to an identified or identifiable person, or personal data rendered anonymous so that the person is no longer identifiable. Identifiability is judged by the means reasonably likely to be used. Pseudonymized data that can be attributed to a person with additional information remains personal data (Article 4(5) and Recital 26). Anonymity is a conclusion you reach and document, not a label you apply.

The EDPB's 2026 draft guidelines. On 7 July 2026 the EDPB adopted draft Guidelines 02/2026 on Anonymisation for public consultation, open until 30 October 2026, to update the Article 29 Working Party's 2014 opinion. They set out three criteria: no record isolation, no linkage and no inference. If all three are met, data can be regarded as anonymous; if any is not, further analysis is needed. The draft states that the likelihood of identification need not be zero but must be insignificant in reality, and that anonymity can differ between entities. It also says that inferences can be drawn from data that captures correlations in the original information, naming AI models and synthetic data, and that a specific and meaningful inference of that kind would violate the no-inference criterion. In short, the draft subjects synthetic data to the same test as any other candidate for anonymity. Because it is a draft, check the final text before relying on specifics.

Training the generator is processing. The same draft says that anonymisation is itself processing of personal data. It needs an Article 6 legal basis, plus an Article 9(2) condition where special-category data such as health data is involved, and the draft presumes these coincide with those of the preceding processing when it is part of the same activity and purposes. Generating synthetic data therefore does not erase the obligations attached to the source data, and the hospital remains a controller of that source data. Questa AI's hospital guide explains the legal basis and Article 9 conditions that apply to health data. The draft also expects the anonymisation process and its testing to be documented.

Different recipients can see different data. In EDPS v SRB (C-413/23 P, 4 September 2025), the Court of Justice held that pseudonymized data is not necessarily personal data in all cases and for every person. For a recipient with no reasonable means of re-identification it may not be, while it remains personal data for the party that holds the key, and the original controller's duties toward data subjects are unaffected. The EDPB draft builds on this contextual approach. For a hospital, that means a dataset's status can differ between you and your recipient, and has to be assessed from each relevant perspective.

The EU AI Act and the European Health Data Space. The AI Act does not require any particular synthetic-data method. Article 10(5) lets providers of high-risk AI systems exceptionally process special-category data for bias detection and correction, but only if, among other conditions, that purpose cannot be effectively fulfilled with other data, including synthetic or anonymised data. Synthetic data is an option to consider there, not a mandate. Regulation (EU) 2025/327 on the European Health Data Space entered into force in March 2025 and sets up a framework for secondary use of health data through health data access bodies, with the secondary-use provisions applying from March 2029. It does not make synthetic data exempt from anything.

Outside the EU. Other regimes have their own tests. In the United States, HIPAA defines de-identification through the Safe Harbor and Expert Determination methods, and whether a given synthetic dataset falls under either depends on how it was produced and what it reveals. Confirm with counsel, using HHS guidance as a starting point.

Realistic use cases

Each use case sets a different bar for utility and for privacy. The notes below give the benefit, the main limitation and the validation each one needs. They are general patterns, not case studies.

Developing and testing medical AI models

Benefit: Teams can prototype pipelines, features and architectures before access to real data is approved, and can augment sparse classes. Limitation: A model that learns artifacts of the generator may not transfer to real patients. Validation: Train-on-synthetic, test-on-real with subgroup and calibration results, and final model validation on real data, since that is the evidence that matters clinically.

Software testing and clinical-system development

Benefit: Realistic volumes, formats and edge cases for EHR integrations, interfaces and dashboards, without placing production patient data in test environments. Process-driven generators suit this well. Limitation: Statistical realism may be modest, and the output will not reproduce the messiness of real coding practice. Validation: Schema and terminology conformance, plausible ranges and clinical logic, plus confirmation that no real records leaked in, which matters if the test data came from a data-driven generator or a masked production extract.

Research collaboration across institutions

Benefit: Partners can develop code and run feasibility checks on synthetic data, then send validated code to run against the real data inside the data holder's secure environment. Synthetic data works here as a rehearsal. Limitation: Results from the synthetic version are not findings, and differences in coding and practice across institutions can undermine realism. Validation: Analytical replication on a real sample where permitted, documented known limitations, and data-sharing agreements that cover the synthetic data as well as the source.

Rare-disease research

Benefit: Synthetic data can support method development and let collaborators rehearse analyses without access to a fragile small cohort. Limitation: This is the use case with the highest privacy risk and the weakest statistical basis. Generating more patients from a handful of real ones adds no new information; it reshuffles what is already there, and it can create false confidence. Validation: Clinical expert review, privacy testing against the strictest attacker model, and a frank comparison with the alternative, which is often controlled access to the real data under strong governance.

Evaluating analytics pipelines

Benefit: A generator with planted effects gives you known ground truth, so you can check whether a pipeline recovers a relationship you put there, benchmark changes and regression-test releases. Limitation: It tests only what was planted and says little about how the pipeline will cope with real-world mess. Validation: Make sure planted effect sizes and noise levels are realistic, and compare pipeline behavior on a real sample where you are allowed to.

Clinical trial planning and simulation

Benefit: Simulation can inform design decisions such as enrollment scenarios, power under stated assumptions and site feasibility, using historical data to explore options. Limitation: Keep exploratory work separate from evidence. Synthetic control arms in the regulatory literature are built from real patient-level data, such as earlier trials, registries and health records, which is how the FDA's draft guidance on externally controlled trials frames external controls (issued as non-binding draft guidance in February 2023; check the page for current status). That is not the same as AI-generated patients. An EMA document on external controls lists clarifying terminology, including synthetic data and digital twins, among its aims. We are not aware of guidance in the sources reviewed here that establishes AI-generated patients as an accepted substitute for real control patients. Validation: Label every output clearly as simulation, pre-specify analyses, and seek early dialogue with the relevant regulator before relying on any synthetic or external comparator.

Evaluation checklist before sharing or using a synthetic dataset

Use this before a synthetic dataset leaves the team or informs a consequential decision. Passing it does not establish legal compliance or prove that a dataset is anonymous. Those are legal conclusions that depend on the facts, the recipients and the jurisdiction.

Purpose and thresholds

• The intended use and the intended recipients are written down.
• Utility thresholds were set before results were seen (for example, the maximum acceptable downstream performance gap, relationships that must be preserved, minimum subgroup performance).

Source data

• Provenance is documented: where the data came from, the time period, known gaps and biases, and how well it represents the population the output is meant to serve.
• The legal basis, the Article 9 condition (or local equivalent), purpose compatibility, ethics or institutional approvals and any contractual limits on the source data are confirmed for training the generator.
• A real hold-out set was reserved and never used in training.

Utility

• Distributions, clinically meaningful relationships and logical constraints were tested.
• Rare conditions and key subgroups were checked for presence, frequency and downstream performance.
• Missingness and data-quality patterns were compared with the source.
• Downstream tasks were tested train-on-synthetic, test-on-real, with subgroup and calibration results; analytical replication was done for research uses.
• Clinicians reviewed sampled and extreme records for plausibility.

Privacy

• An attacker model is defined: recipients, plausible auxiliary data, and whether anyone can query the generator.
• Closest-record analysis, membership and attribute inference tests, and a linkage assessment against plausible external data were run.
• Outliers and rare combinations were examined and handled.
• If differential privacy was used, the parameters, implementation and privacy accounting are documented.

Governance

• Limitations, residual risks and all test results (including failures and the fixes made) are documented.
• The data protection officer and legal counsel have reviewed the release, and any anonymity conclusion is a documented legal assessment made from the recipients' perspectives.
• The release form (dataset or generator), access controls, data-use agreement, ban on re-identification attempts and approval are recorded.
• Monitoring and re-assessment triggers are set: new releases, new external data, model changes and the final EDPB guidance.

Where sensitive-data detection and anonymization fit

Synthetic data generation is one tool in a privacy workflow, and it is not the same thing as anonymization. Sensitive-data detection and data anonymization do different jobs around it.

Before generation, they help find and handle direct identifiers and sensitive entities in the unstructured parts of a project (notes, scans, attachments, exports) so you decide deliberately what is removed, masked or pseudonymized. Around the project, they help keep real patient data out of the places it tends to leak: test environments, prompts, evaluation sets and logs. And they stand apart from synthetic generation. Data Masking or anonymizing real records produces a transformed version of real records, which needs its own assessment. A synthetic dataset needs its own as well. Where a tool keeps a local mapping that restores original values after processing, treat its output as pseudonymized from the holder's perspective rather than anonymous.

Questa AI's platform is built around that first and second job: detecting sensitive entities in documents, transcripts and files and masking them locally before data reaches a model. It is not a synthetic-data generator, and nothing in this article suggests it is.

If you are mapping where sensitive health data enters your AI and analytics pipelines, including the files and free text that feed a synthetic data project, see how Questa AI detects and anonymizes sensitive data locally before it reaches a model.

Frequently Asked Questions

Conclusion

Synthetic medical data can help healthcare teams build, test and collaborate faster, but only when it is treated as something you engineer and verify rather than a label that settles the privacy question. The useful questions are specific. Useful for what purpose, and measured against which thresholds? Safe against which attacker, and shared with whom, under what conditions? A dataset can match the source on summary statistics and still fail the task it was built for, and one with no copied row can still reveal who was in the source data.

In practice, that means setting the purpose and thresholds first, validating against real held-out data, testing privacy against a defined attacker, documenting results including failures, and bringing legal and data protection colleagues in before anyone calls a dataset anonymous. The EDPB's draft guidelines, still in consultation, point toward regulators expecting that kind of evidence rather than assertion. Synthetic data does not remove the obligations attached to the source data, and it works best as one control among several, alongside data minimization, access governance and sensitive-data detection. Used with that discipline, it is a practical way to rehearse, prototype and collaborate before real patient data is needed.