- Simulation-based generators like Synthea never touch real patient records and carry no privacy risk; model-based generators trained on real data do.
- Synthetic data shines where data only needs to be shaped like medicine — software testing, demos, education — not true about actual people.
- Fidelity and privacy pull in opposite directions: the more faithfully a model captures its training data, the more it can leak rare, distinctive patients.
- Training a generative model on patient records is processing those records; calling the output synthetic does not erase obligations attached at training time.
On this page
Open a demo of almost any piece of health software and you will meet someone like Margaret: 67 years old, hypertension diagnosed in 2009, metformin since 2014, a knee replacement, a flu shot every October. Margaret is detailed, internally consistent, and does not exist. She was generated — birth, illnesses, encounters, refills, and all — by software.
Synthetic health data has earned a real place in research infrastructure. It also has a marketing problem: the word "synthetic" is increasingly used to imply that the privacy questions have been engineered away. Some have. Most have not — and the difference depends entirely on where the data came from.
What synthetic health data actually is
Synthetic health data is artificially generated records designed to look and behave statistically like real patient data. Two families dominate, and the difference between them is the whole privacy story.
The first family is simulation. Synthea, an open-source patient generator, simulates entire lives — births, conditions, encounters, prescriptions — from public statistics and published clinical guidelines, then writes the results out as standard FHIR records. No real patient's record ever enters the pipeline, so no real patient's record can leak out of it. The data is fake all the way down, and that is its virtue.
The second family is model-based: a generative model is trained on real patient records and asked to emit new ones with the same statistical texture. This is where most of the commercial energy is — and all of the privacy tension. The model is a compression of real people's medical histories, and what is compressed can sometimes be decompressed.
Where synthetic data genuinely shines
Synthetic data is at its best when the question is "does the software work?" rather than "what is true about patients?" Four uses come up constantly, and all four are honest:
- Software testing and development. Engineers need realistic record volumes and shapes without ever exposing protected health information to a development database.
- Demos and sales. No real patient should ever appear on a conference screen.
- Education and training. Students can practice queries, terminologies, and analytics without an ethics review, because there is no one to harm.
- Interoperability and pipeline rehearsal. Synthea is widely used to exercise FHIR implementations precisely because its records are structurally realistic and legally inert.
These uses share one property: nobody will ever treat the outputs as facts about human beings. The data needs to be shaped like medicine, not true.
The fidelity-privacy trade-off
Here is the uncomfortable engineering fact: for model-generated synthetic data, utility and privacy pull in opposite directions. A generative model is useful exactly insofar as it captures the patterns of its training data — and the more tightly it captures them, the more it risks reproducing individual people rather than populations.
The failure modes have names. Memorization: rare, distinctive patients — the one-of-a-kind cases — are precisely the records a model most easily reproduces nearly verbatim. Membership inference: an attacker uses the model's outputs to test whether a particular person was in the training set, which for a disease-specific dataset discloses a diagnosis all by itself. These are cousins of the linkage attacks we catalog in re-identification attacks, and the people at highest risk are the same ones: outliers, rare-disease patients, small subgroups.
Defenses exist — training under differential privacy puts a provable bound on what any single record can contribute — but the bound costs fidelity, and it costs the most fidelity exactly where health research needs it most: in the tails, the rare conditions, the unusual trajectories. Average patients are easy to fake. Research is rarely about average patients.
What synthetic data cannot honestly do
| Use | Verdict | Why |
|---|---|---|
| Software testing, demos, education | Yes | The data needs to be shaped like medicine, not true |
| Method development and pipeline rehearsal | Mostly | Validate on real data before believing anything |
| Augmenting small datasets | Sometimes | Can amplify the generator's biases as easily as the signal |
| New scientific findings | No | A generator can only restate what it learned; it cannot witness |
| Regulatory evidence of safety or efficacy | No | Decisions about real bodies require evidence from real bodies |
The deepest limit is epistemic, not technical. A synthetic dataset contains no new information about the world; at absolute best it restates what its generator extracted from real records, minus noise, plus artifacts. Discovery — a new association, an unexpected safety signal — requires contact with reality. That is also why quality work on real data matters so much, a subject we take up in garbage in, garbage out. And evidence about drug safety and effectiveness still comes from real patients under real protocols, however the surrounding tooling evolves.
'Synthetic' is not a consent bypass
The quiet pitch behind some synthetic-data products runs: train on patient records you were never clearly permitted to use, generate "synthetic" output, and the consent problem evaporates. It does not.
Training a generative model on patient records is processing those records. The obligations attach at training time, not at output time — a lawful basis is needed for the training itself, whatever the outputs are later called. And whether those outputs are truly anonymous is a question of fact, judged by the same standard as any other release: GDPR's Recital 26 asks whether anyone is identifiable by all the means reasonably likely to be used, and regulators such as the UK's ICO treat synthetic data as a privacy-enhancing technology whose anonymity must be demonstrated case by case, not assumed from the label. A memorizing model fails that test no matter what its marketing says. The legal vocabulary here — anonymous, de-identified, pseudonymized — is its own minefield, mapped in what these words actually mean.
At Mithras Health the line runs where this essay draws it. Generated records are a fine way to build and show software; they are not a way around permission. Research on the platform runs only over records patients have explicitly provisioned — each study under a revocable, scope-limited consent, behind a k ≥ 5 release floor that is not configurable, with every event on an append-only audit trail. Where AI assists discovery, it is locally hosted, and deterministic engines make the decisions.
The honest summary of synthetic health data fits on an index card: it is a superb way to build software and a poor way to learn about people. Used inside that line, it removes real risk from development, demos, and teaching. Used to launder data nobody agreed to share, it is the oldest trick in a new vocabulary. The records can be synthetic. The permission cannot.
Appendix · questions
Questions, answered
What is synthetic health data?
Is synthetic health data anonymous?
Can synthetic data replace real data in clinical research?
Does using synthetic data avoid the need for patient consent?
The sun is rising on chronic-disease research.
One email when we launch — and nothing else. Patients, researchers, sponsors, and programs all start here.
Mithras