Synthetic Medicare claims data is artificially generated beneficiary, enrollment, and claims records that look and behave like real Medicare data, with the same tables, code systems and utilisation patterns, without containing any actual beneficiary's information. It exists in two generations. The first is CMS's own static public files, built a decade ago to prove the concept. The second is on-demand, certified synthesis with a formal privacy guarantee attached. Understanding the gap between the two is the fastest way to understand where health-data infrastructure is heading.
Why CMS built SynPUF, and what it proved
CMS released the Data Entrepreneurs' Synthetic Public Use File (DE-SynPUF), built from 2008–2010 Medicare claims. It holds synthetic versions of those claims for roughly 2.3 million synthetic beneficiaries, spanning beneficiary summaries, inpatient, outpatient, carrier, and prescription-drug claims. The stated purpose was exactly the use case analytics teams still have today: let developers build and test software against claims-shaped data "without the risk of violating beneficiary privacy," with programs designed so that code written against the SynPUF would run on CMS's real Limited Data Sets.
SynPUF's real achievement was proving demand. It has been downloaded, converted (including into the OMOP Common Data Model, mirrored on the AWS Open Data registry), and built against for over a decade. That is evidence an entire industry needs realistic, linkable claims data it is allowed to touch.
Where SynPUF falls short today
| Limitation | Consequence |
|---|---|
| Frozen in 2008–2010 | ICD-9 era: no ICD-10, no modern therapies, pre-ACA utilisation patterns |
| Fidelity deliberately limited | CMS intentionally distorted inter-variable relationships for privacy, and documents that analytic inferences from SynPUF should not be trusted |
| One schema, one population | Medicare FFS only; cannot be shaped to a customer's tables, vocabularies, or volumes |
| No formal privacy guarantee | Protection rests on the distortion process, not on a stated, verifiable bound |
| Never refreshed | The file is the file; there is no pipeline behind it |
None of this is criticism. SynPUF was built as a proof of concept and says so. But teams still standardising test environments on a 2010 snapshot are solving a 2026 problem with decade-old infrastructure.
The successor: certified synthesis
Modern synthesis inverts the model. Instead of one static file, a generation pipeline runs against whatever claims source the data holder has, and every output ships with evidence.
- A formal privacy guarantee. Generation under ε-differential privacy gives a provable ceiling on what the output reveals about any individual in the source. It is a stated (ε, δ), not an unstated distortion process.
- Preserved relational structure. Claims data is only useful if every claim resolves to a member and a visit. Referential integrity can be guaranteed by construction and then independently verified.
- Measured fidelity. Distribution comparisons against the source, reported rather than asserted, including where privacy protection deliberately costs accuracy.
- Provenance and audit. A tamper-evident record of how the dataset was produced, which is what a compliance team actually files.
A worked example, with real numbers
To make this concrete: in October 2026 we ran the SX-Engine against the public 100,000-person OMOP conversion of DE-SynPUF itself (a deliberately safe seed, already synthetic and public domain, so the demonstration involves no PHI at any point). The output is release SX-SAMPLE-SYNPUF-001. It holds 5,000 synthetic persons across five OMOP CDM v5.3-format tables (person, visit, condition, drug, procedure, core fields), totalling 1.85 million event rows, generated with person-level privacy at ε = 1.0, δ = 10−5 and Rényi-DP accounting.
- Referential integrity: 7 of 7 referential-integrity checks pass, 0 orphan rows. Every claim resolves to a person and a visit.
- Marginal fidelity, reported as concordance (1 − Jensen–Shannon distance against the seed, distance in brackets): visit type mix 0.999 (0.001), sex 0.996 (0.004), age 0.941 (0.059), procedure codes 0.908 (0.092), diagnosis codes 0.842 (0.158), drug codes (NDC) 0.797 (0.203). Composite concordance 0.91.
- Disclosed costs: long-tail drug codes diverge most (distance 0.203) under per-person contribution capping. That is the privacy protection working, stated on the report rather than tuned away.
That is the generational difference in one paragraph: not "trust us, it's synthetic," but a dataset that arrives holding its own evidence.
What claims synthesis is honestly for
The same discipline applies as for synthetic health data generally. Release SX-SAMPLE-SYNPUF-001 is fit for OMOP pipeline and software validation, multi-table linkage testing and cohort-query prototyping. It is not fit for pharmacovigilance, rare-disease cohorts or primary regulatory evidence. It is also not fit for temporal sequence analysis, because in this release event dates are sampled uniformly within 2008–2010, so visit intervals and sequences are not preserved. Put plainly, this public sample demonstrates schema fidelity, linkage and privacy accounting. It is not a basis for clinical-outcome research. A claims dataset with a certificate should print its contraindications on the certificate, and this one does.
Frequently asked questions
Is CMS DE-SynPUF still available?
Yes. The 2008–2010 files remain downloadable from CMS, and OMOP CDM conversions are mirrored on the AWS Open Data registry. CMS has also published newer Synthea-based synthetic Medicare claims files. All remain static snapshots rather than generation pipelines.
Can I still use SynPUF for software testing?
For basic pipeline bring-up, yes. Its limits arrive quickly: ICD-9-era coding, deliberately distorted relationships that CMS itself warns against analysing, and a single fixed schema. Teams needing current vocabularies, their own table shapes, or defensible privacy documentation outgrow it.
Does synthetic Medicare data involve real beneficiaries?
DE-SynPUF was derived by CMS from real claims through a disclosure-limitation process. Certified synthesis states the relationship formally: under ε-differential privacy, the influence of any single individual in the source data on the entire output is mathematically bounded, whatever the source.
Can synthesis produce ICD-10-era or payer-specific claims?
Yes. A synthesis pipeline preserves whatever coding and schema the source uses, so ICD-10/current-vocabulary output comes from current source data, shaped to the tables and volumes an engagement defines. That is the structural difference from any static public file.
What should a buyer ask for with any synthetic claims dataset?
Four artifacts: the stated privacy parameters (ε, δ, adjacency, accounting method), a referential-integrity report, a fidelity report against the source, and provenance/audit documentation. If a provider can't produce them, the word 'synthetic' is doing all the work.
Continue reading in Research:
Inspect a real certificate and OMOP cohort
Request release SX-SAMPLE-SYNPUF-001. It holds 5,000 synthetic persons across five OMOP CDM v5.3-format tables at (ε = 1.0, δ = 10⁻⁵), with its Clinical Privacy Index certificate, fidelity snapshot and linkage report. Requests are reviewed individually.
Request the sample release Talk to us