SpiceGrinder vs. Synthea
Short version: Synthea gives you excellent synthetic patients. SpiceGrinder gives you a way to model your own data. If you need realistic FHIR patient records and Synthea’s clinical model fits your use case, use Synthea — it’s free, it’s well-built, and we can’t match its clinical depth.
What Synthea is, and why it’s good
Synthea is an open-source synthetic patient generator maintained by The MITRE Corporation. It simulates complete medical histories — encounters, conditions, medications, allergies, social determinants — from birth to present day, and exports to HL7 FHIR (R4, STU3, DSTU2), C-CDA, and CSV.
Its Generic Module Framework models diseases as state machines built by clinicians and calibrated against published CDC and NIH statistics. That’s a serious, domain-expert-built clinical model, and it’s free. For testing a FHIR interface, populating an EHR demo, or research needing realistic longitudinal patient records, Synthea is very hard to beat and SpiceGrinder isn’t trying to.
If Synthea’s patients fit your problem, use Synthea. That’s not a courtesy. We’re not going to out-build MITRE on clinical simulation, and we’d rather say so than let you find out the hard way.
Where the fit breaks
Synthea models patients, according to Synthea’s clinical model. Its strength is that you don’t have to build that model. Its limit is the same fact from the other direction: you get Synthea’s view of a patient population, not yours.
That matters when:
You need more of it than the population produces. Synthea does export claims — claims.csv is right there in the CSV output, and if it fits your test you’re done. What it can’t do is decouple volume from population: we measured 45 patients producing 4,687 claims, and that ratio isn’t a setting. A million claims means simulating on the order of ten thousand-plus patient lifetimes, which took about three hours at the rate we measured. The schema is Synthea’s billing shape (DIAGNOSIS1–DIAGNOSIS8, STATUS1, OUTSTANDING1), and the cost distributions come from its care model rather than from you.
You need a specific distribution rather than an epidemiologically realistic one. Synthea’s prevalence rates reflect the real US population, which is exactly right for research and often wrong for testing. If you need 30% of records to hit an edge case so your alerting logic gets exercised, real-world prevalence is working against you.
The scenario hasn’t happened. A new benefit design, a regulation taking effect next year, a stress scenario outside historical experience. Synthea models what the clinical literature describes. It can’t describe something that isn’t in it yet.
You need exact reproducibility as a testing primitive. Committing a model file to your repo and having it produce byte-identical output in CI is a different workflow from generating a population once and checking in the artifacts.
What describing your own shape looks like
A claims model — frequency and severity, the two things an actuarial test actually needs, stated directly:
<dataset seed="42">
<root node="ClaimObservation"/>
<nodes>
<Append name="ClaimObservation">
<input name="Frequency"/>
<input name="Severity"/>
</Append>
<Poisson name="Frequency" lambda="3.5"/>
<Lognormal name="Severity" mu="8.0" sigma="1.2"/>
</nodes>
</dataset>Want a catastrophe year? Change mu. Want to test the reserving model against a book three times heavier than history? Change lambda. The model is the argument, and it’s four lines.
A clinical trial with control and treatment arms:
<dataset>
<root node="PatientOutcome"/>
<nodes>
<Mix name="PatientOutcome" synchronous="false">
<input name="ControlArm" weight="2"/>
<input name="TreatmentArm" weight="1"/>
</Mix>
<!-- Control response rate ~ 30% -->
<Binomial name="ControlArm" n="1" p="0.30"/>
<!-- Treatment response rate ~ 45% -->
<Binomial name="TreatmentArm" n="1" p="0.45"/>
</nodes>
</dataset>Both run under SpiceGrinder Free, and both produce identical output from the same seed on any machine — the property that makes them usable as committed test fixtures rather than one-time artifacts.
Using both is the actual recommendation
These aren’t mutually exclusive, and the combination is better than either alone. Generate a population with Synthea once, commit it, then use SpiceGrinder’s FlatFile to draw members from that pool and generate claims against them at whatever volume and distribution your tests need. Real clinical population shape, claim economics you control, and one million claim lines in 1.6 seconds instead of roughly three hours.
We built it end to end and wrote down the numbers, the model, and the gotchas — including the one where Synthea’s leading-zero ZIP codes silently turn into floats due to CSV handling:
Showcase: Claims at Volume, on a Synthea Population →
The showcase also covers a Free-tier version of the same pattern: Free can’t resolve the member, but it can emit the pool row index for you to join yourself, and the claims it produces are byte-identical to the Pro model’s.
Where Synthea wins outright
- Clinical realism. MITRE’s disease modules encode real clinical expertise. We have distributions and composition; we do not have a cardiology module.
- Standard health formats out of the box. FHIR and C-CDA export are built in. SpiceGrinder emits CSV and structured output — mapping to FHIR is work you’d do yourself.
- Free and open source, with no tier. Synthea has no paid edition. SpiceGrinder Free is numeric-only with a 20-node cap per model; real string-valued healthcare data means Pro at $199/month.
Try it
Synthea details per synthetichealth.github.io/synthea, checked 2026-09-13.