Synthetic Patient Data — What It Is, Who Uses It, and Where to Get It

Synthetic patient data is AI-generated medical record data that is statistically and clinically realistic but not derived from any real individual. It contains no Protected Health Information (PHI) and is produced entirely from model training on published clinical literature, drug labeling, and population health distributions — not from real patient charts.

Synthetic patient data looks and behaves like real EHR data for the purposes of software development, ML model training, coding practice, and workflow testing, but carries zero HIPAA risk. Every field — demographics, diagnoses, medications, labs, vitals, clinical narratives — is generated by the model, not extracted or transformed from a real chart.

HIPAA does not apply to truly synthetic data because HIPAA governs Protected Health Information (PHI) — individually identifiable health information about a real person. Synthetic patient data generated from AI models (not from real patient records) contains no PHI by definition. There is no real individual to identify.

This means: no Business Associate Agreement (BAA) required, no Safe Harbor de-identification analysis, no Minimum Necessary standard, no breach notification risk, and no covered entity or business associate relationship created by sharing the data. You can store synthetic records on AWS S3, share them in a public GitHub repository, or include them in a published paper without any HIPAA compliance review.

Synthea is a rule-based patient simulator developed by MITRE. It generates plausible demographic timelines and encounter sequences using probabilistic state machines — useful for populating test databases, but clinically shallow for NLP and coding use cases.

PatientDatasets.com records are generated by a language model grounded in 9.9 million PubMedBERT embeddings. Each record contains a complete clinical narrative: chief complaint, HPI (OLDCARTS framework), review of systems, physical examination with objective findings, assessment with differential reasoning, and an evidence-based plan. These are the fields that clinical NLP models, medical coders, and EHR documentation teams actually need. Synthea does not produce these narratives.

Additionally, PatientDatasets.com records include 7 production-ready formats (FHIR R4, HL7 v2, C-CDA, Parquet, SQLite, JSON, CSV) generated natively, not converted from a single internal schema. Synthea's primary outputs are CSV and OMOP CDM, with FHIR output requiring additional tooling.

De-identified data starts as real patient records and has 18 HIPAA-specified identifiers removed (name, geographic data smaller than state, all date elements except year, phone numbers, fax numbers, email addresses, SSN, medical record numbers, health plan beneficiary numbers, account numbers, certificate/license numbers, VINs, device identifiers, URLs, IP addresses, biometric identifiers, full-face photographs, and any other unique identifying number).

Even after de-identification, residual re-identification risk remains. Academic studies have demonstrated that de-identified records can be re-linked to individuals using auxiliary data sources. This is why de-identified datasets like MIMIC-IV still require Data Use Agreements, credentialing, and research-only licensing.

Synthetic data bypasses this entirely. Because no real patient is represented in the dataset, there is no re-identification risk — there is no real individual to re-identify. No DUA, no IRB, no compliance overhead. This is a fundamentally different legal and technical category, not just a stronger form of de-identification.

Yes — ML training and benchmarking is the primary use case for PatientDatasets.com. Records include 36+ structured fields (demographics, ICD-10-CM codes, CPT/HCPCS codes, LOINC-coded labs, RxNorm medications, vitals, SDOH screening) plus full clinical narrative text — HPI, ROS, physical exam, assessment, and plan.

Because the data is 100% synthetic, you can train models, publish accuracy metrics, share the dataset with co-authors, and include it in a Methods section without any HIPAA restriction, IRB approval, or data governance review. Parquet format is optimized for pandas DataFrames, Apache Spark, scikit-learn, PyTorch Datasets, and cloud data warehouse ingestion (BigQuery, Snowflake, Redshift).

Common ML use cases include: ICD-10 code prediction from clinical notes, clinical NER (named entity recognition) for diagnosis, medication, and lab extraction, readmission risk prediction, LLM fine-tuning for clinical text generation, and embedding model training for medical semantic search.

No. IRB (Institutional Review Board) oversight applies to research involving human subjects — specifically, research that involves obtaining information about living individuals by interacting with them, or by obtaining identifiable private information about them. Synthetic data involves no real individuals, so human subjects research regulations (45 CFR 46, the Common Rule, and FDA 21 CFR Part 50/56) do not apply.

You can publish results, share the dataset with collaborators worldwide, cite it in a peer-reviewed Methods section, and include it in grant applications without IRB protocol submission. Each PatientDatasets.com release is versioned with a DOI-style citation string that satisfies most journal data transparency and reproducibility requirements.

Yes. Every FHIR export is a conformant R4 Bundle (version 4.0.1) validated against the official FHIR R4 JSON schema. Each bundle contains: Patient (demographics, identifiers), Encounter (visit type, dates, provider), Condition (ICD-10-CM coded diagnoses with SNOMED-CT equivalents), Observation (LOINC-coded vitals and lab results with reference ranges), MedicationRequest (RxNorm-coded medications with dosage instructions), and AllergyIntolerance (substance and reaction) resources.

Resources use proper UUIDs and internal reference chaining (e.g., Encounter.subject references Patient, Condition.encounter references Encounter). Bundles are suitable for: loading into HAPI FHIR, Azure Health Data Services, or Google Cloud Healthcare API; testing SMART on FHIR app authorization flows; testing CDS Hooks services; validating FHIR server import/export; and testing bulk FHIR export ($export) implementations without connecting to a live EHR.

Yes — and this is one of the most popular use cases. Each record contains a complete clinical encounter note structured to support coding practice: chief complaint, HPI documenting up to 8 OLDCARTS elements, review of systems covering relevant body systems, physical examination with objective findings organized by body system, assessment with clinical reasoning, and a plan with ordered tests, treatments, and follow-up instructions.

Records do not have ICD-10-CM or CPT codes pre-populated in the narrative — you derive the codes from the note text, exactly as you would on a real encounter. The structured CSV/JSON fields do include coded data (ICD-10-CM problem list, CPT procedure list) as an answer key for self-checking after coding practice.

Records span inpatient and outpatient encounter types, supporting E/M level assignment (MDM or time-based under 2021 guidelines), ICD-10-CM principal and secondary diagnosis selection, ICD-10-PCS procedure coding for inpatient encounters, and HCC (Hierarchical Condition Category) assignment for risk adjustment practice.

Visit patientdatasets.com, select your tier, and complete checkout via Stripe. Download links for your selected formats are delivered instantly to your email. Typical delivery time from checkout to inbox: under 60 seconds.

For the Free tier (5 records, CSV), click "Download Free Sample" on the homepage — no credit card or account creation required. Simply enter your email and the download link is sent immediately.

Files are delivered as a ZIP archive containing one folder per format. Each CSV/JSON/Parquet/SQLite file is clearly labeled with record count and format version. FHIR R4 bundles are delivered as individual JSON files (one per patient encounter) plus a full Bundle JSON combining all records. HL7 v2 messages are delivered as a pipe-delimited .hl7 file. C-CDA documents are delivered as individual XML files.

PatientDatasets.com records span 60+ clinical specialties. Core specialties with the highest record volume include: internal medicine, family medicine, cardiology, pulmonology, gastroenterology, oncology (hematology/oncology, radiation oncology), neurology, psychiatry, psychology/behavioral health, orthopedic surgery, general surgery, obstetrics/gynecology, pediatrics, endocrinology, nephrology, rheumatology, dermatology, ophthalmology, otolaryngology, urology, and emergency medicine.

Ancillary and allied health specialties are also well represented: physical therapy, occupational therapy, speech-language pathology, medical social work, nutrition/dietetics, clinical pharmacy, and case management documentation. Surgical subspecialties include thoracic surgery, vascular surgery, colorectal surgery, and neurosurgery.

For Enterprise tier customers, cohorts can be filtered to specific specialty mixes — for example, a behavioral health software vendor may request a cohort of 10,000 psychiatry and psychology records spanning inpatient, partial hospitalization, intensive outpatient, and outpatient telehealth encounter types.