Real paediatric data is hard to get. Children are a protected population, consent is layered through parents and guardians, sample sizes for rare conditions are small, and the data that does exist is sensitive in ways adult data rarely is. So when a health-tech team needs test cases, training examples or a demo dataset, synthetic data looks like the answer: artificial records that behave like the real thing, without any real child behind them.
Sometimes it is the answer. Sometimes it is a convincing imitation that quietly carries every flaw of the original data — plus a few new ones of its own. The difference between the two is not the generator you used. It is what you checked, what you documented, and what you refused to claim.
Contents
- What synthetic data actually is
- Where it genuinely helps
- Where it misleads
- The “synthetic means anonymous” mistake
- A worked example: the rare-condition cohort that looked perfect
- What to document before you quote synthetic results
- Frequently asked questions
What synthetic data actually is
Synthetic data is artificial data generated to reproduce the patterns of a real dataset. There are two broad kinds, and confusing them is the first mistake.
Rule-based synthetic data is built from clinical knowledge: a clinician or a specification defines the ranges, relationships and edge cases, and a generator produces records that follow them. A synthetic growth chart, for example, can be built from published percentile curves. This kind is only as good as the rules that went into it — and its limits are usually visible, because somebody wrote them down.
Model-generated synthetic data is learned from a real dataset: a statistical model or generative model studies real records and produces new ones with similar distributions. This is the kind most teams mean when they say “synthetic data”, and it is the kind that carries the most risk. It can reproduce patterns nobody on the team knew were in the source data — including the biases, the gaps and the rare records that should never have been reproducible at all.
A third distinction matters for paediatrics specifically: synthetic data about children is not a scaled-down version of synthetic data about adults. Age changes nearly everything — physiology, language, dose, consent, risk — and a generator trained on mostly adult records will not invent correct paediatric behaviour on its own. If your source data is thin on children, your synthetic data will be thin on children too, however large the output file looks.
Where it genuinely helps
Used honestly, synthetic paediatric data solves real problems that real data cannot.
Rare presentations. Some conditions are so uncommon in children that a team may never see a real case during development. A handful of synthetic cases, built with a clinician from the published literature, lets the product be tested against a presentation it would otherwise meet for the first time in production. The point is coverage, not volume: ten carefully built cases are worth more than ten thousand generated ones.
Edge cases and failure modes. The cases that matter most for safety are often the ones real data hides: the vague history, the contradictory symptoms, the parent who answers in fragments, the dose at the boundary between two weight bands. Synthetic data lets a team build these deliberately, rather than waiting for a real child to present them. This is the same instinct behind planted-error testing: you design the hard case on purpose, because the easy cases will never teach you anything.
Privacy-preserving development. A synthetic dataset can stand in for real records during early development, in demos, and in testing environments where real patient data should never sit. Developers can build against realistic structure — fields, formats, relationships — without handling a single real record. That is a genuine privacy gain, as long as nobody mistakes it for a guarantee. More on that below.
Sharing across teams. A startup working with an external reviewer, a university partner or a prospective buyer often cannot share real paediatric records at all. A well-documented synthetic dataset can be shared instead, so the other side can see the shape of the product’s behaviour without touching patient data.
None of these uses requires the synthetic data to be a faithful copy of reality. They require it to be honest about what it is: a stand-in, built for a stated purpose, with known limits.
Where it misleads
The trouble starts when synthetic data is treated as evidence about real children, rather than as a tool for testing a product.
Inherited bias. A generator trained on real data inherits the real data’s biases — and then amplifies them. If the source records under-represent infants, or over-represent one setting, or encode a clinician’s habit as though it were a fact, the synthetic output will reproduce all of it, smoothly and confidently. Worse, the synthetic data looks clean: no missing fields, no messy notes, no awkward exceptions. A team reviewing it can easily conclude the data is better than the reality it came from. It is not. It is the same reality, tidied up.
Unrealistic age mixes. This is the paediatric-specific failure. A synthetic dataset labelled “children” often contains a plausible-looking spread of ages that, on inspection, clusters around the ages the source data had most of — typically school-age children — with infants and adolescents thinly represented or, worse, represented by records that are just school-age records with the age changed. A dosing rule that works for an eight-year-old does not work for an eight-month-old, and a synthetic dataset that blurs that distinction will flatter a product that has never been tested on babies at all. Age bands are not a formatting detail; they are a safety boundary. The same per-domain thinking applies here as everywhere else — see why one overall accuracy score hides paediatric failure.
Validation theatre. The most dangerous claim in this area is also the most common: “validated on synthetic data”. A model tested only on data generated by the same process that trained it has been tested on its own reflection. The test passes because the generator and the model agree with each other, not because either of them agrees with reality. Validation against synthetic data is a check that the pipeline runs. It is not evidence that the product is safe for children. Any vendor or founder who quotes synthetic-only results as clinical evidence is either confused or hoping you are.
Plausible nonsense. Generative models are good at producing records that look right. A synthetic record can combine a plausible age, a plausible symptom and a plausible dose into a combination no real child would ever present — and nobody notices, because each field looks fine on its own. These combinations are the synthetic-data equivalent of a hallucinated citation: individually credible, collectively false. They are caught only by clinical review of the generated records themselves, case by case, not by statistical checks on distributions.
The “synthetic means anonymous” mistake
The privacy claim is the one teams get wrong most often, and it has real consequences. Generating synthetic data from real patient records does not automatically make the output anonymous.
The UK Information Commissioner’s Office, in its guidance on anonymisation and pseudonymisation, is clear on this point: synthetic data generated from personal data is not automatically anonymous. Whether the output counts as personal data depends on whether individuals can still be identified from it, directly or indirectly — and rare or unusual records in the source data can make identification possible even when no direct identifiers survive. The ICO’s draft guidance on anonymisation for research purposes, consulted on in 2026, makes the same point: teams must assess identifiability and re-identification risk across the whole lifecycle, including whether the synthetic dataset could let someone infer something about a particular person.
The US National Institute of Standards and Technology takes a similar line in its March 2025 guidance, NIST SP 800-226: to provide robust privacy protection, including against novel privacy attacks, synthetic data should be generated using differentially private algorithms. Methods without that formal guarantee offer informal protection only, and can be vulnerable to attacks that were not imagined when the dataset was made.
Three practical consequences follow. First, generating synthetic data from real records is itself processing personal data, and needs the same lawful basis and governance as any other use of those records. Second, a synthetic dataset built from a small paediatric cohort — where a single rare condition can identify a child — carries more re-identification risk than one built from a large adult population. Third, “synthetic” is a description of how data was made, not a legal status. A team that shares a synthetic dataset as though it were anonymous, without an identifiability assessment, is taking a risk it has not measured.
This is principle-level guidance, not legal advice. If your product handles children’s health data, the identifiability assessment is work for your data-protection adviser, not a checkbox in a sprint.
A worked example: the rare-condition cohort that looked perfect
Consider a team building a parent-facing app that flags possible signs of a rare metabolic condition in infants. Real cases are scarce — the team has access to forty real records, all from one specialist centre. They generate ten thousand synthetic cases to train and test the product.
On paper, the results are excellent. The model scores 94% on the synthetic test set. The demo looks convincing. The team quotes the figure to a prospective buyer.
Three problems are hiding in that number. First, the forty source records all come from one centre, with one referral pattern and one demographic mix; the synthetic data reproduces that centre’s habits as though they were the disease. Second, the generator smoothed away the messy reality of infant presentations — the vague feeding histories, the symptoms that arrive over weeks rather than days — because those patterns were rare even in the source data, and rare patterns are the first thing a generator drops. Third, the test set was generated by the same process as the training set, so the 94% measures agreement between the model and its own generator, not accuracy on real infants.
The fix is not to abandon synthetic data. It is to use it for what it is good at, and to stop claiming what it cannot support. The team should keep the synthetic cases for pipeline testing and edge-case coverage, test the model on real cases held out from generation — however few there are — and quote the real-data result, with its honest uncertainty, instead of the synthetic one. A small, honestly reported result on forty real infants is worth more than a polished 94% on ten thousand invented ones.
This is an illustrative example, not a report of a real incident — but it is the shape real overclaims take. The synthetic number is always the flattering one. That is exactly why it needs the most scrutiny.
What to document before you quote synthetic results
Before any synthetic result is quoted to a buyer, a partner or a reviewer, the following should exist in writing. If it does not, the result is not ready to quote.
- Source. What real data, literature or clinical rules was the synthetic data generated from? How many real records, from where, and covering which ages?
- Method. How was it generated — rules, statistical model, or generative model? Was differential privacy applied, and with what guarantee? If not, say so.
- Age-band coverage. How many cases fall in each age band — infants, toddlers, school-age children, adolescents — and was each band checked separately?
- Clinical review. Who reviewed the generated records, case by case, and what did they reject? A generator’s output should be clinically reviewed like any other content. The paediatric app review framework applies to synthetic test content as much as to anything else a child might see.
- What was tested on real data. Which results come from synthetic data, and which from real data held out from generation? Never present the two as one number.
- Known limits. What does the synthetic data not cover — which presentations, which age bands, which settings? Write the limits down before someone asks.
- Identifiability assessment. Has the synthetic dataset been assessed for re-identification risk, and under what sharing conditions? “Synthetic” is not an answer to this question.
- Version. Which generator version, which source snapshot, which test-set version? Synthetic data drifts like any other artefact, and a result without a version is not reproducible.
A buyer who receives this documentation can judge the evidence for themselves. A buyer who receives only a headline number cannot — and a founder who cannot produce the documentation has not yet done the work the number implies.
One final distinction, because it matters for everything on this site: reviewing synthetic-data practice is clinical-content review, not regulatory approval. A well-documented synthetic-data process strengthens a product’s evidence file; it does not certify the product, and it does not replace the regulatory route a regulated product must follow. For the broader picture of what clinical review can and cannot do, see the seven paediatric risks adult-focused teams commonly miss.
Frequently asked questions
Can synthetic data replace real paediatric data entirely?
No. Synthetic data is useful for pipeline testing, edge-case coverage, demos and development, but it cannot stand in for real data when the question is whether a product behaves safely for real children. Any claim about clinical behaviour needs to be tested on real cases held out from generation — however few there are — and reported with honest uncertainty.
Is synthetic data anonymous?
Not automatically. Synthetic data generated from personal data can still allow individuals to be identified, especially from small paediatric cohorts where a rare condition can identify a child. The ICO’s guidance is that identifiability must be assessed for the specific dataset and sharing context, and NIST recommends differentially private generation for robust protection. “Synthetic” describes how data was made, not its legal status.
How much synthetic data do we need?
Less than teams usually generate. Ten carefully built, clinically reviewed cases for a rare presentation are worth more than ten thousand unreviewed ones. What matters is coverage across your risk domains and age bands, and clinical review of the generated records — not volume. Volume without review is how plausible nonsense gets into a test set.
What is the most common mistake teams make with synthetic data?
Quoting synthetic-only results as clinical evidence. A model tested on data from the same generator that trained it has been tested on its own reflection. Keep synthetic results and real-data results separate, and quote the real-data result — with its uncertainty — when anyone asks how the product performs for children.
Should we generate synthetic data from our own patient records?
Only with proper governance. Generating synthetic data from real records is itself processing personal data, so it needs a lawful basis, a documented purpose and an identifiability assessment — and particular care with children’s data. For many small teams, rule-based synthetic data built from published guidance, or a small set of clinician-written cases, is the safer starting point.
Building a healthcare-AI or pediatric digital-health product? DigitalProved provides an independent review of clinical content, patient-safety risks, escalation advice and user communication. Receive a prioritised written report and recorded walkthrough within five working days. Request a Product Review
