The critical caveat across all approaches:
None of these approaches guarantee that the generator is private — only that the individual synthetic records don't contain real patient identifiers. If the generator itself can be queried to reveal real patient information, the privacy guarantee breaks down at the system level even when the synthetic records appear clean.
The Membership Inference Attack — Why Standard Synthetic Data Isn't Enough
This is the most important technical finding in synthetic health data research and the one most synthetic data guides don't cover.
What a membership inference attack does:
An adversary with access to the synthetic data generator — or repeated access to its outputs — can submit queries designed to determine whether specific real individuals were in the original training dataset. The attack exploits the fact that a generator trained on a real dataset will produce slightly different outputs for records close to training data than for records far from it.
The practical implication:
- Your synthetic dataset: private (no real patient records)
- Your generator: potentially a privacy leak (can be queried to reveal membership of real patients)
For healthcare organizations sharing synthetic datasets publicly or with research partners, the synthetic data itself may be safe. But if the generator is accessible (via API, shared model weights, or repeated query access), the generator is the attack surface.
What peer-reviewed research shows:
Research published in Nature Medicine (2023) demonstrated membership inference attacks on synthetic patient data generated by GANs — an adversary with 50 queries could determine real patient membership with accuracy significantly above random. For high-dimensional health data (genomics, rare disease records), the attack succeeds with fewer queries.
The architectural fix:
Differential privacy (DP) during synthetic data generation adds calibrated mathematical noise to the generator in a way that provides provable bounds on membership inference leakage. A DP-synthetic dataset comes with a formal privacy guarantee: even with unlimited queries to the generator, the adversary's advantage in identifying real training members is bounded by ε (epsilon), the privacy budget.
The trade-off: stronger privacy (smaller ε) reduces data utility. For clinical AI training, ε values between 1 and 10 typically preserve sufficient statistical properties for model training while providing meaningful membership inference protection.
HIPAA De-Identification for Synthetic Health Data
HIPAA provides two pathways to de-identified status: Safe Harbor and Expert Determination. Synthetic data must meet one of these to be treated as outside HIPAA's scope.
Safe Harbor
Safe Harbor requires removal of 18 specified identifier categories. For synthetic data, Safe Harbor is generally achievable — a properly configured synthetic data generator produces records with no real patient identifiers.
The catch: Safe Harbor also requires that the covered entity "does not have actual knowledge that the information could be used alone or in combination with other information to identify an individual." If membership inference attacks can identify real patients via the generator, this condition may not be met — even if the synthetic records themselves don't contain explicit identifiers.
Expert Determination
Expert Determination requires a qualified statistician to certify that the risk of identifying any individual in the synthetic dataset is "very small." This is where differential privacy becomes directly relevant: a DP-generated synthetic dataset with a formal privacy budget provides the statistical basis for an Expert Determination certification in a way that standard GAN-generated synthetic data may not.
What HIPAA does NOT address:
HIPAA applies to covered entities and business associates handling PHI. It does not regulate:
- Research institutions using synthetic data generated from de-identified real data
- International use of synthetic data generated under HIPAA
- The generator itself, only the synthetic dataset output
For healthcare organizations generating synthetic data for research partnerships or commercial AI development, HIPAA compliance at the dataset level may not be sufficient if the generator is shared or accessible.
GDPR and the Stricter Anonymization Standard
GDPR applies a stricter anonymization standard than HIPAA — and the 2025 EDPB guidance on anonymization made it stricter still.
The GDPR anonymization test:
For data to be outside GDPR's scope, re-identification must be "reasonably impossible" — taking into account all the means reasonably likely to be used by a third party. The EDPB's 2025 guidance explicitly stated that the "all means" test must account for adversarial attacks, including membership inference.
The practical consequence:
Standard GAN-generated or VAE-generated synthetic health data may not meet GDPR's anonymization standard if:
- The generator was trained on personal data (EU patient records)
- The generator is accessible or its outputs can be queried repeatedly
- Membership inference attacks could determine real patient membership
If the synthetic data is not truly anonymous under GDPR, it remains personal data and GDPR's full framework applies — lawful basis, data minimization, cross-border transfer restrictions, and data subject rights including erasure.
What "GDPR-safe synthetic data" actually requires:
- Differential privacy during generation (mathematical bound on membership inference)
- The generator trained only on properly de-identified or pseudonymized source data (not raw patient records)
- No access to the generator by third parties receiving the synthetic data
- Documentation of the privacy budget (ε) and the statistical basis for the anonymization claim
The European Health Data Space — The 2026 Framework
The EU's European Health Data Space regulation creates the first EU-level framework for secondary use of health data — including synthetic data. As of 2026, EHDS is in implementation phase with Member State adoption ongoing.
What EHDS does for synthetic data:
EHDS creates a regulated pathway for researchers to access health data for secondary purposes. Synthetic data occupies a specific position in this framework:
- Synthetic data generated from real patient data that meets GDPR's anonymization standard can be provided to researchers without triggering GDPR data subject rights
- EHDS does not create a separate anonymization standard — it defers to GDPR's "reasonably impossible" test
- Health Data Access Bodies (HDABs) established under EHDS may generate synthetic datasets from national health data for researcher access — this is the most significant development for medical AI training data availability in Europe
What EHDS does NOT do:
EHDS does not lower GDPR's anonymization standard for synthetic data. "EHDS-compliant synthetic data" is not a separate compliance category — the data must still meet GDPR anonymization requirements.
For organizations generating synthetic health data for EU researcher access or cross-border sharing under EHDS, differential privacy and the EDPB's 2025 anonymization guidance both apply.
The Architecture That Satisfies All Three Frameworks
Step 1: Pseudonymize before generating
Before synthetic data generation begins, pseudonymize the source dataset. Replace patient identifiers with stable tokens; hold the entity mapping separately. Generate synthetic data from the pseudonymized source, not from raw patient records.
Why this matters: If the generator is trained on pseudonymized data, membership inference attacks against the generator reveal pseudonym membership, not real patient membership. The entity mapping held separately is never exposed to the generator or to third parties receiving synthetic data.
Step 2: Apply differential privacy during generation
Configure the synthetic data generator with a formal privacy budget (ε). For clinical AI training datasets, ε values between 3 and 10 typically preserve sufficient statistical properties while providing meaningful membership inference protection.
Document the ε value and generation methodology — this is the basis for HIPAA Expert Determination certification and GDPR anonymization documentation.
Step 3: Validate utility before distribution
Run utility validation against the synthetic dataset:
- Statistical similarity to source distribution (Wasserstein distance, KL divergence)
- Machine learning efficacy — model trained on synthetic data should perform comparably to model trained on real data for the target task
- Privacy audit — run membership inference attack tools against the generator to verify that the DP guarantees hold in practice
Step 4: Document for compliance
For HIPAA: engage a qualified statistician for Expert Determination certification, citing the ε value and membership inference audit results.
For GDPR: document the pseudonymization step, the DP configuration, the ε value, and the membership inference audit — providing the "all means" analysis the EDPB 2025 guidance requires.
For EHDS: confirm the GDPR anonymization documentation satisfies the HDAB requirements in the relevant Member State.
Frequently Asked Questions
What is HIPAA-compliant synthetic data?
Synthetic health data that meets HIPAA's de-identification standard under either Safe Harbor (no real patient identifiers in the synthetic records) or Expert Determination (a qualified statistician certifies the re-identification risk is very small). For Expert Determination, differential privacy during generation provides the statistical basis for the certification. Safe Harbor alone may not be sufficient if membership inference attacks against the generator can reveal real patient membership.
What is GDPR-safe synthetic data?
Synthetic health data that meets GDPR's anonymization standard — re-identification must be "reasonably impossible" accounting for all means including adversarial attacks. Standard GAN-generated synthetic data may not meet this bar. Differential privacy during generation, applied to pseudonymized source data, provides the strongest currently available technical basis for a GDPR anonymization claim.
What is a membership inference attack on synthetic data?
An adversary queries a synthetic data generator repeatedly to determine whether specific real individuals were in the original training dataset. Research has demonstrated this attack succeeds on GAN-generated health data with as few as 50 queries for certain record types. The attack breaks the privacy guarantee at the generator level even when individual synthetic records don't contain real patient identifiers.
Does synthetic data satisfy GDPR by definition?
No. The EDPB's 2025 guidance on anonymization requires that re-identification be "reasonably impossible" accounting for all means including adversarial attacks. If a synthetic dataset was generated from real patient data and the generator is accessible, membership inference attacks may make the anonymization claim unsupportable. Only synthetic data generated with differential privacy from pseudonymized source data, with the generator not accessible to third parties, provides a strong GDPR anonymization basis.
What is the European Health Data Space (EHDS) and how does it affect synthetic health data?
EHDS creates the first EU-level framework for secondary use of health data, including a regulated pathway for researcher access to national health data. Synthetic data plays a specific role: datasets meeting GDPR's anonymization standard can be provided to researchers without triggering data subject rights. EHDS does not create a separate anonymization standard — it defers to GDPR's "reasonably impossible" test, meaning DP-generated synthetic data is necessary to satisfy EHDS access pathways reliably.
What is differential privacy and why does it matter for synthetic health data?
Differential privacy (DP) is a mathematical framework that adds calibrated noise to a data release mechanism — in this case, a synthetic data generator — such that the adversary's ability to determine real individual membership in the training set is bounded by a formal privacy parameter (ε). Smaller ε means stronger privacy but lower utility. DP provides the only currently available mathematical guarantee against membership inference attacks, making it the basis for the strongest HIPAA Expert Determination and GDPR anonymization claims.
What is the FDA's position on synthetic data in clinical submissions?
The FDA's 2023 guidance on using AI/ML in drug development acknowledged synthetic data as a tool for augmenting clinical datasets with limited real patient data — particularly for rare diseases. The FDA does not endorse specific generation methods but expects documentation of the statistical properties of synthetic data, validation against real data distributions, and transparency about generation methodology in any submission that incorporates synthetic datasets.
What should I look for when choosing a synthetic health data provider or dataset?
Four criteria: (1) generation methodology — DP-generated data with documented ε value provides the strongest privacy guarantee; (2) source data handling — the generator should have been trained on pseudonymized, not raw, patient records; (3) utility validation documentation — Wasserstein distance, ML efficacy comparisons, and population representation metrics should be available; (4) compliance documentation — HIPAA Expert Determination certification or GDPR anonymization documentation signed by a qualified expert.
Conclusion
The path forward is not competing with Syntegra or Gretel.ai for "buy synthetic health datasets" — those are product category queries that vendor pages will always dominate. The path forward is owning the compliance angle: HIPAA Expert Determination, GDPR's membership inference standard, and EHDS secondary-use requirements. This is content that compliance teams, healthcare researchers, and institutional review boards need — and that synthetic data vendors rarely provide in regulatory depth.
Questa AI's pseudonymization-before-generation architecture directly addresses the membership inference gap: by training synthetic data generators on pseudonymized source data, membership inference attacks against the generator reveal pseudonym membership rather than real patient membership. Combined with differential privacy at the generation layer, this provides the strongest currently available technical basis for HIPAA Expert Determination and GDPR anonymization claims simultaneously.
