Synthetic Health Data: What It Is, Uses and Limits
Synthetic health data is artificially generated data that mimics the statistical properties of real patient data without corresponding to real individuals. It is produced by algorithms — from simple rule-based simulators to generative machine-learning models — trained on or configured from real datasets. Synthetic data is genuinely useful for software testing, training and education, method development, and exploratory analysis, but it is not a substitute for real data in regulated evidence generation, and it does not automatically eliminate privacy risk.
Why synthetic health data matters now
Two forces have pushed synthetic data up the agenda. The first is the rise of generative artificial intelligence (AI): the same model families that generate text and images — generative adversarial networks (GANs), variational autoencoders (VAEs), diffusion models, and large language models — can generate patient-shaped records, and healthcare AI infrastructure teams are being asked whether that removes the need for hard-won access to real data. The second is regulatory pressure on data movement. The European Health Data Space (EHDS), in force since March 2025, mandates that secondary use of personal electronic health data happens inside secure processing environments; the May 2026 UK Biobank incident, in which approved researchers removed participant-level data through a centralised platform’s normal workflow, hardened attitudes further. When real data becomes harder to move, organisations look for something they can move freely — and synthetic data appears to be it.
That appearance deserves scrutiny. Synthetic data solves a real set of problems and quietly fails at others, and the difference matters enormously for anyone building healthcare AI infrastructure on top of it.
How synthetic health data is generated
Three generations of method
Rule-based simulators encode clinical knowledge directly. Synthea, the open-source patient generator maintained by MITRE, simulates entire synthetic lifetimes — conditions, encounters, medications — from published clinical care pathways and population statistics. Because no real patient data enters the process, the privacy risk is zero; because no real data enters the process, the output reflects the rules, not reality, and cannot contain patterns the authors did not encode.
Statistical methods fit distributions and correlations from a real dataset and sample new records from them. This preserves the broad shape of the data — marginal distributions, pairwise correlations — while breaking the link to individuals, though complex interactions and rare combinations are typically flattened.
Deep generative models — GANs, VAEs, and more recently diffusion models — learn the joint distribution of real data and can capture far richer structure, including longitudinal patterns in records and pixel-level structure in imaging. Their fidelity is their risk: a model expressive enough to reproduce subtle real-world structure is expressive enough to memorise its training examples, which is where privacy leakage begins.
The fidelity–privacy trade-off
Every synthetic data project sits on a single axis. At one end, low-fidelity data is safe but useless for anything beyond schema testing. At the other, high-fidelity data is analytically valuable but increasingly disclosive — membership-inference attacks, demonstrated against machine-learning models by Shokri and colleagues in 2017 and since extended to generative models, can determine whether a specific person’s record was in the training set, and outlier patients with rare condition combinations are the most likely to be reproduced nearly verbatim. The uncomfortable conclusion is that synthetic data generated from real patient data is a derived product of that data, not an unrelated artefact. It requires disclosure assessment before release, exactly like any other research output, and privacy-preserving training techniques such as differential privacy reduce the risk at a measurable cost to fidelity.
How to evaluate a synthetic dataset before trusting it
Because “synthetic” describes a method, not a quality level, any dataset offered to a healthcare AI infrastructure team should be evaluated on three axes before it enters a workflow. Fidelity asks whether the statistical properties survive generation: compare marginal distributions, correlation structures, and clinically meaningful relationships — such as age–comorbidity gradients — between synthetic and real data. Utility asks the question that actually matters downstream: does an analysis or model built on the synthetic data behave like one built on the real data? The standard test is train-on-synthetic, test-on-real (TSTR) — train a model on the synthetic set, evaluate it against held-out real records, and measure the performance gap against a real-data baseline. Privacy asks what the dataset remembers: run nearest-neighbour distance checks to find synthetic records suspiciously close to real ones, and membership-inference tests to estimate whether training records can be detected. A generator that scores well on fidelity and poorly on privacy has not solved the problem; it has moved it — and a dataset with no published evaluation on any of the three axes should be treated as untested, whatever its documentation claims.
When to use synthetic data — and when to use federated access to real data
The practical question for a healthcare AI infrastructure team is rarely “synthetic or real?” in the abstract; it is “which tool for which stage of the pipeline?”. Synthetic data excels where realism matters less than availability: developing and testing analysis code before a data-access application is approved, teaching, demonstrating platforms, benchmarking pipeline performance, and prototyping. Real data, accessed under governance, is non-negotiable where the conclusion will be acted on: regulatory submissions, clinical validation, epidemiology, and training models whose outputs affect care.
The modern answer to “we can’t move the real data” is not to fabricate it but to stop moving it. In a federated Trusted Research Environment (TRE), analysis travels to the data custodian, runs inside a secure environment, and returns only checked aggregate results — the data never leaves the source. Federation delivers what synthetic data promises — analysis without data movement — while preserving what synthetic data cannot: the rare variants, the outliers, the true correlational structure, and the regulatory standing of real-world evidence. The two are complementary: many programmes publish a synthetic twin of their dataset so researchers can write and debug code freely, then execute the finished analysis against the real data inside the federated environment.
Synthetic data versus federated access to real data
| Dimension | Synthetic health data | Federated access to real data |
|---|---|---|
| What the researcher analyses | Artificial records mimicking real distributions | Real patient records, in place, under governance |
| Privacy model | Depends on generation method; residual re-identification and membership-inference risk | Data stays with the custodian; only checked aggregates leave |
| Rare diseases and outliers | Poorly represented, or dangerously memorised | Fully represented |
| Regulatory evidence value | Not accepted as primary evidence | Real-world evidence, accepted with appropriate methods |
| Speed of first access | Immediate — often openly downloadable | Gated by access approval |
| Best use | Code development, testing, training, demos | Production analysis, validation, publication |
Real-world examples
The pattern of pairing synthetic and real data is already standard among mature programmes. The Simulacrum, produced by Health Data Insight from the English national cancer registry, gives researchers a freely usable synthetic dataset that mirrors the structure of the real registry, so analysis code arrives at the secure environment already written and tested. In the United States, the Centers for Medicare and Medicaid Services published the DE-SynPUF synthetic claims files for exactly the same reason, and Synthea’s fully simulated populations underpin health-IT testing worldwide. National genomics programmes follow the same logic at larger scale: Genomics England provides researchers with governed access to real genomic and clinical data inside its research environment — with federated analysis capability delivered with Lifebit — rather than releasing derived copies, while test and training environments use synthetic or dummy data. The division of labour is consistent everywhere: synthetic data for the parts of healthcare AI infrastructure that need availability, federated real data for the parts that need truth.
Common pitfalls
Four failure modes account for most synthetic-data disappointment. First, treating synthetic data as automatically anonymous: if it was generated from real records, it inherits disclosure risk and needs assessment before release. Second, validating a model on synthetic data alone — the model learns the generator’s simplifications, and performance claims evaporate on real patients, a problem sharpest for under-represented groups whose statistical signal the generator smoothed away. Third, using synthetic data to dodge governance: a generator trained on patient data without a lawful basis does not launder the data it memorised. Fourth, over-engineering: teams spend months tuning a generative model to answer a question that a federated analytics query against the real data could have answered in an afternoon, with an exact rather than approximate result.
What to do next
Treat synthetic data as one component of healthcare AI infrastructure, not the foundation. A workable evaluation sequence: classify each intended use as development-grade or evidence-grade; adopt or generate synthetic data for the development-grade uses, preferring published synthetic twins where they exist; subject any synthetic dataset you generate from real data to formal disclosure assessment before sharing it; and route every evidence-grade use through governed access to real data — ideally a federated TRE, so the analysis code developed against the synthetic twin runs unchanged where the real data lives. Teams that draw this line early get the speed of synthetic data and the credibility of real data, without discovering the gap between them at publication time.
Frequently asked questions
What is synthetic health data?
Synthetic health data is artificially generated data that reproduces the statistical properties of real patient data without describing real individuals, created by rule-based simulators, statistical models, or deep generative models such as GANs and diffusion models.
Is synthetic health data anonymous?
Not automatically. Synthetic data generated from real records can leak information about the people in the training data — particularly outliers — through memorisation and membership-inference attacks, so it should be disclosure-assessed before release like any other derived output.
Can synthetic data replace real patient data in research?
No. It substitutes well for real data in code development, testing, education, and demonstration, but regulatory submissions, clinical validation, and any conclusion that will affect care require real data accessed under governance.
What is synthetic data best used for?
Writing and debugging analysis code before data access is granted, testing software and pipelines, teaching, benchmarking, and letting researchers explore a dataset’s structure — so that time inside the secure environment is spent on the real analysis.
How does federated analysis compare with synthetic data?
Federated analysis sends the computation to where the real data is held and returns only checked aggregate results, so researchers get exact answers from real data while the data never moves; synthetic data gives approximate answers from artificial data that moves freely. Mature programmes use both, in that order of trust.
Do generative AI models make synthetic health data safe by default?
The opposite is closer to true: the more expressive the generative model, the more faithfully it can reproduce — and therefore memorise — its training records. High-fidelity generative synthetic data needs stronger privacy testing, not less.