Model Card

Explicitly defines the use cases for which the synthetic data generator was designed and validated, alongside explicit prohibitions against unsafe applications.

• Intended use: Generating synthetic electronic health records for clinical trial simulation with differential privacy guarantees
• Out-of-scope: Using generated data for direct patient care decisions without human review
• User qualification: Specifies that only trained biostatisticians should interpret outputs
• Includes the regulatory context (e.g., FDA SaMD classification, HIPAA Safe Harbor compliance)

Presents quantitative benchmarks demonstrating the synthetic data's fidelity, utility, and privacy preservation using standardized metrics.

• Statistical fidelity: Reports Frechet Inception Distance (FID) and Wasserstein distance between real and synthetic distributions
• Downstream utility: Documents Train-Synthetic-Test-Real (TSTR) performance—models trained on synthetic data must match real-data performance within a 5% margin
• Privacy metrics: Includes Nearest Neighbor Adversarial Accuracy (NNAA) and membership inference attack success rates
• Clinical plausibility: Validates adherence to SNOMED CT ontologies and physiological constraints

Documents the source, composition, and preprocessing of the real data used to train the generative model, enabling reproducibility and bias auditing.

• Data sources: Specifies originating institutions (e.g., MIMIC-IV, UK Biobank) and collection timeframes
• Demographic breakdown: Reports age, sex, race, and comorbidity distributions to surface representation gaps
• Exclusion criteria: Lists removed subpopulations or outlier records with clinical justification
• Preprocessing steps: Details batch effect normalization, missing data imputation strategy, and feature engineering decisions
• Data valuation: Identifies high-value records using Data Shapley scores for targeted augmentation

Candidly discloses known failure modes, representation gaps, and fairness evaluations to prevent misuse and guide responsible deployment.

• Representation bias: Quantifies underrepresentation of rare disease cohorts or demographic minorities using statistical parity difference
• Mode collapse: Reports whether the generator fails to produce certain clinical scenarios (e.g., rare drug interactions)
• FairGAN constraints: Documents whether equalized odds or demographic parity constraints were enforced during training
• Temporal drift: Warns that clinical practice changes may render synthetic data obsolete; specifies the expiration date for validity
• Causal limitations: Clarifies that synthetic data preserves correlations but may not capture causal mechanisms without explicit causal generative modeling

Addresses the societal impact, consent frameworks, and oversight mechanisms governing the synthetic data generator's lifecycle.

• Consent lineage: Traces whether original patients consented to derivative data generation for secondary research
• Dual-use risk: Assesses potential for generating deepfake medical records for insurance fraud or research misconduct
• Synthetic data watermarking: Describes embedded digital fingerprints for provenance tracking and leak detection
• Audit trail: Specifies logging of all generation requests, including user identity, timestamp, and parameter configurations
• Review cadence: Mandates quarterly adversarial validation checks to detect distribution shift from evolving real-world data

Provides implementation details enabling independent replication, security auditing, and interoperability assessment.

• Architecture: Specifies whether the generator uses a CTGAN, TimeGAN, WGAN-GP, or denoising diffusion probabilistic model (DDPM)
• Differential privacy implementation: Documents the privacy accountant (e.g., Rényi DP), noise multiplier, and clipping norm
• Hardware and runtime: Reports GPU requirements, training duration, and inference latency per 1,000 synthetic records
• Software dependencies: Lists framework versions (e.g., Synthetic Data Vault (SDV) 1.0, PyTorch 2.0) and random seeds for reproducibility
• Input/output schema: Defines expected feature types, categorical encodings, and output data format (e.g., FHIR R4, OMOP CDM)