Synthetic Patient Records Generator with a Privacy Attack Report for Hospital Data Sharing

The problem: hospital data is locked away, and synthetic data is not automatically safe

Students, researchers and health startups in Pakistan and elsewhere struggle to get realistic hospital data. Hospitals are right to refuse: removing names and ID numbers is not enough, because age, postcode, admission date and a rare diagnosis together can identify a person. Synthetic data, where a model learns the patterns in the real table and generates new fake rows, is often presented as the answer.

The trouble is that a synthesiser can memorise. If a dataset has one 94 year old patient with a rare condition, a generator may reproduce that patient almost exactly. Data stewards rarely have a way to check. They need a tool that generates synthetic data and then tries hard to break it.

What already exists and the gap

• SDV (Synthetic Data Vault) is a mature open source library for generating synthetic tables, with a companion metrics library.
• SmartNoise Synth, from the OpenDP project, provides synthesisers with formal differential privacy guarantees.
• Commercial synthetic data platforms offer generation with privacy scores, usually as a hosted service, which many hospitals cannot use because data must not leave the premises.

The gap is an offline tool that puts generation and adversarial testing side by side, explains the result in plain language for a data steward, and focuses on the rare records where leaks happen.

Inspiration

Two papers frame the project. Patki, Wedge and Veeramachaneni introduced the Synthetic Data Vault at IEEE DSAA 2016, showing that synthetic data could stand in for real data in data science work. Stadler, Oprisanu and Troncoso's "Synthetic Data: Anonymisation Groundhog Day" at USENIX Security 2022 showed the other side: synthetic data without formal guarantees can leak information about outlier records, and privacy cannot be judged from average-case metrics. Your project builds the tool that the second paper says data stewards need.

What you build

• The data steward loads a table on a local machine, marks which columns are sensitive and which are identifiers, and picks synthesisers to try.
• The tool trains each synthesiser, generates a synthetic table and runs the full test battery.
• The report shows, for each synthetic table, how useful it is, how much it leaks, which real records are most at risk and a recommendation.
• A researcher receives only the synthetic table and the report that justified its release.

The technically interesting part

• Membership inference. Train shadow synthesisers with and without a target record, then train a classifier to tell from synthetic output whether the target was in the training data. Run it specifically on outliers, as Stadler and colleagues did.
• Attribute inference. Given a patient's known attributes (age, sex, district), can an attacker predict their diagnosis from the synthetic table better than from population statistics alone?
• Distance metrics, used carefully. Distance to closest record is easy to compute and easy to misread. Show why a good average distance can hide a few near-copies.
• Utility that matters. Beyond matching distributions, test whether a model trained on synthetic data predicts readmission on real held-out data nearly as well as one trained on real data.
• Differential privacy trade-offs. Vary the privacy budget and plot utility against attack success, so the steward sees the price of privacy.

How to evaluate it

• Attack strength: membership inference advantage over random guessing for each synthesiser, on average records and on outliers separately.
• Utility: correlation preservation and the gap in model accuracy between real-trained and synthetic-trained models.
• Validation of the report: plant known risky records (exact duplicates, rare combinations) and confirm the report flags them.
• Usability: ask two people with data protection or research ethics experience to read three reports and say whether they could make a decision.

Suggested plan

• Weeks 1 to 4: literature, choose datasets, run SDV and one DP synthesiser end to end.
• Weeks 5 to 9: utility metrics, distance metrics, attribute inference.
• Weeks 10 to 14: membership inference with shadow models, outlier analysis.
• Second semester: report design, offline packaging, privacy budget experiments, user review and write-up.

Path to a product

Hospitals, insurers and health ministries all hold data that researchers want. A tool that produces defensible release decisions, run on premises, fits data governance teams and research ethics committees. It is also strong research material: a careful evaluation on South Asian health data would be publishable, and privacy engineering skills are in demand.

Scope warning

Do not invent a new generative model; compare existing ones. Do not use real patient data until you have an ethics approval and a signed agreement; public datasets are enough for the core project. Never present a synthetic table as safe because one metric looked good, and keep the language of the report careful.

Learn what you need on Sefism

• Data science roadmap: modelling and evaluation skills for the utility tests.
• Machine learning cheat sheet: classifiers for the attack models and held-out evaluation.
• scikit-learn User Guide: building the shadow and attack classifiers.
• An Introduction to Statistical Learning: the statistics behind distributions and correlations.
• EU Data Protection Rules for Business and Organisations: why anonymisation is judged by re-identification risk.

Get help with this idea

This is a research-heavy idea, and the risk is a report that sounds certain when the evidence is thin. Tauseef can help you choose datasets, design the attack experiments and keep the scope realistic for two semesters. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session