Synthetic data has become the default solution for clinical AI teams that need training data, partner-shareable datasets, or test environments without exposing protected health information. Done right, it cuts time-to-AI-pilot from months to weeks and removes a major regulatory blocker. Done wrong, it produces a synthetic dataset that still leaks real patient information and a 2026 HHS OCR investigation that does not end well.
This article walks through generating synthetic clinical data, validating it, and defending it during an HHS Office for Civil Rights audit. It is written for the CIO, Privacy Officer, CTO, or VP Data Engineering who is already running or about to run a synthetic data program and needs to know whether what they have built will survive scrutiny.
What Synthetic Clinical Data Is and Why It Is Not the Same as Anonymized Data Under HIPAA
Synthetic clinical data is data generated by a model trained on real patient records that produces new records which statistically mirror the source population without containing any real patients. The output is used for AI training, software validation, partner sharing, clinical trial simulation, and analytics.
What it is not is anonymized data. Anonymization removes identifiers from real records. Synthetic data generates new records that never existed. The legal distinction is significant: anonymized data falls within the HIPAA Privacy Rule's Safe Harbor or Expert Determination pathways at 45 CFR § 164.514(b) and remains regulated as de-identified PHI. Properly generated synthetic data, when it can be demonstrated that no individual's information is retained or reconstructable, can fall outside HIPAA — but only if you can prove it.
Two other shifts matter for clinical AI teams. The third phase of HHS HIPAA compliance audits commenced in March 2025, covering 50 covered entities and business associates with a focus on Security Rule provisions most relevant to AI-era data handling. And on February 16, 2026, HHS commenced enforcement of Part 2 regulations under newly delegated responsibility, which expands the regulatory perimeter around substance use disorder data that often appears in clinical AI training sets.
For any team training AI on patient data — synthetic or otherwise — the binder that proves compliance is now the single highest-leverage artifact in the engineering stack.
How Synthetic Clinical Data Gets Generated: Five Generator Categories in 2026
Five generator categories are in production use across healthcare in 2026. Choosing among them is the first major engineering decision.
Generative Adversarial Networks (GANs)
Dominate tabular EHR generation. CTGAN remains the standard open-source baseline; commercial implementations include MOSTLY AI and Replica Analytics. GANs handle complex mixed-type tables well but are sensitive to training instability and can memorize rare records.
Variational Autoencoders (VAEs)
Well-suited to smaller datasets and lower-cardinality features. Faster to train than GANs, generally more stable, but produce lower fidelity on highly correlated clinical features.
Diffusion Models
Have moved from imaging into tabular data. TabDDPM is the open-source reference. They handle conditional generation well — useful when you need synthetic cohorts matched to specific clinical phenotypes.
Bayesian Networks and Rule-Based Generators
Synthea remains strong for use cases where statistical accuracy of population-level patterns matters more than record-level realism. Synthea generates clinically plausible longitudinal records using public health statistics, clinical guidelines, and demographic models.
Large Language Models (LLMs)
Emerging for narrative clinical text generation — discharge summaries, progress notes, radiology reports. The hallucination risk is non-trivial; LLM-generated clinical text needs additional validation that tabular generators do not.
The right choice depends on the data modality, the use case, and the privacy budget. Most production programs use two or three generators in combination — Synthea for skeleton longitudinal records, CTGAN or TabDDPM for high-fidelity tabular features, and selective LLM generation for free-text fields.
How to Validate Synthetic Healthcare Data: Privacy, Fidelity, and Utility Testing
A synthetic dataset that has not been validated across all three categories below should not be released. Validating only one is the most common failure mode that ends in an OCR finding.
Privacy Validation
The dataset must demonstrate that no real patient's information can be recovered.
- Membership inference attack testing. Run an attacker model that tries to determine whether a specific record was in the training set. Attacker advantage should be near zero (typically below 0.1).
- Attribute disclosure testing. Test whether quasi-identifiers in the synthetic data allow inference of sensitive attributes about real individuals.
- k-anonymity and l-diversity scores against the documented quasi-identifier set, with thresholds aligned to your Expert Determination.
- Differential privacy budget (ε) documented if used. Lower ε equals stronger privacy.
Fidelity Validation
The dataset must statistically resemble the real population.
- Column-wise distribution tests — Kolmogorov-Smirnov for continuous variables, chi-squared for categorical.
- Wasserstein distance for distribution similarity at the column level.
- Correlation preservation — pairwise and higher-order correlations between clinical features.
- Conditional distributions for clinically critical features (e.g., lab values conditional on diagnosis).
Utility Validation
The dataset must produce AI models that work on real-world data.
- Train-on-Synthetic, Test-on-Real (TSTR) accuracy for the downstream AI use case — does the model trained on synthetic data perform comparably to the model trained on real data when evaluated on a held-out real test set?
- Subgroup performance. Run TSTR on race, ethnicity, age band, sex, and rare clinical phenotypes. Models trained on synthetic data that have collapsed rare subgroups will fail in production and create their own enforcement exposure under emerging AI fairness frameworks.
The Seven Artifacts That Get a Synthetic Data Program Through an HHS OCR Audit
OCR investigators do not begin with model architecture. They begin with documentation. Across enforcement patterns through 2024–2026, seven artifacts decide whether the audit binder closes quickly or expands.
Expert Determination Report
A formal report from a qualified statistician documenting the methodology, risk thresholds, residual disclosure risk, and the conclusion that the synthetic data is not PHI. Refreshed when source data changes, the generator changes, or annually — whichever is sooner.
Generation Methodology Specification
Generator architecture (CTGAN, TabDDPM, Synthea, MOSTLY AI, MDClone, Replica Analytics, or custom), training data scope, hyperparameters, privacy mechanisms including any differential privacy budget, and rejection criteria for unstable runs.
Privacy Validation Report
Membership inference, attribute disclosure, and k-anonymity / l-diversity results — every release.
Fidelity and Utility Validation Report
Distribution tests, correlation preservation, and TSTR benchmarks for the downstream AI use case.
Bias and Subgroup Performance Report
Subgroup representation analysis with documented mitigation when collapse is detected — typically conditional sampling, weighted training, or augmentation from external sources.
Provenance and Lineage Trail
Every synthetic dataset linked to its generator version, training data snapshot, validation run IDs, approval signatures, and downstream consumer registry — built into the data platform via Unity Catalog, AWS Glue Data Catalog, or a dedicated governance layer. Not a spreadsheet.
Workforce and Access Controls Evidence
HIPAA training records, minimum-necessary access enforcement under 45 CFR § 164.502(b), Business Associate Agreements with every vendor in the pipeline, and access logs covering source PHI access during generator training. Most OCR findings against AI training data do not arise in the synthetic data itself — they arise in the access patterns that produced it.
Audit Readiness Review
Audit Your Synthetic Data Against HHS OCR Requirements
NonStop runs a 45-minute Synthetic Data Audit Readiness Review covering the seven artifacts. Find out which you can defend today.
Book Audit Readiness Review →Three Synthetic Data Failure Patterns That Trigger HIPAA Violations and OCR Findings
After running synthetic data engagements with clinical AI companies and health systems, three failure patterns recur.
Outsourced Generation, Retained Liability
Using a third-party synthetic data vendor does not transfer regulatory responsibility. If the vendor is a Business Associate, you are still accountable for their controls, their validation methodology, and their access patterns. OCR has been explicit in 2024–2026 enforcement actions that BA management is the covered entity's obligation.
Validation at Release Only
A team validates the generator at first release, then runs it for eighteen months without re-validation as source data drifts. The synthetic data produced fourteen months later no longer matches the population it claims to represent — and no one can prove it does, because no one ran the tests.
The Two-Page Expert Determination
A consultant sends a brief memo concluding the data is de-identified, with no documented methodology, no re-identification test results, no defined risk threshold. Under OCR's expanded Risk Management focus, that document does not survive scrutiny. Expert Determinations need to read like statistical reports, not legal opinions.
The Business Case for Building a HIPAA-Compliant Synthetic Data Program
Building a defensible synthetic data program typically takes 12–16 weeks of infrastructure work, then ongoing per-release validation that a small team can run in days. The cost of doing it improperly is asymmetric — over $2.19 million per violation category for willful neglect, plus state AG penalties, plus 18–24 months of corrective action plans and lost partnership deals.
Done well, the program also unlocks revenue. It lets clinical AI teams train models on internal data without 9-month IRB cycles, share datasets with academic partners under data-use agreements, run AI vendor evaluations without exposing PHI, and accelerate clinical trial simulation. Health systems and biopharma teams that have built this infrastructure consistently report time-to-AI-pilot reduced from months to weeks.
NonStop Clinical AI
How NonStop Builds HIPAA-Compliant Synthetic Data Platforms for Clinical AI Teams
NonStop builds end-to-end synthetic data programs for clinical AI companies, health systems, and biopharma teams operating under HIPAA, the EU AI Act, and US state AI laws. Engagements run 12–16 weeks and deliver all seven artifacts above, wired into the data platform — not stored in a SharePoint folder.
NonStop Clinical AI
Build a HIPAA-Compliant Synthetic Data Platform with NonStop
Tell us your data, your AI use case, and your compliance footprint. We deliver an audit-defensible synthetic data program in 12–16 weeks.
Get Started →