Healthcare application development has a chicken-and-egg problem: you cannot test an EHR integration without patient records, and you cannot touch real patient records without a compliance program. The standard answer is Synthea, the open-source synthetic patient simulator, and it is excellent, but it is a local Java program, not an API. I wanted synthetic patients on demand without babysitting a toolchain, which is what the Synthea Medical Record Generator API on Apify does: send a population size, get FHIR R4 bundles and CSVs back.
Disclosure: the Apify links in this post are affiliate links. If you run the Actor, I may earn a referral commission at no extra cost to you.
One thing to be clear about up front: everything this Actor produces is synthetic. No record describes a real person, so there is no protected health information anywhere in the output.
Does Synthea have an API?
Not a hosted one. Synthea is a program you clone, configure through properties files, and run on your own machine, with a Java toolchain and enough disk for the output it generates. That is fine for a one-off dataset and a drag for a CI pipeline or an agent that needs fresh test patients on demand. This Actor wraps the same open-source engine as a pay-per-patient API: JSON input in, patient bundles out, nothing installed.
What the synthetic patient generator returns
The Synthea generator API returns one structured JSON record per generated population: a patient count, FHIR R4 bundles, CSV exports, and the metadata to reproduce the run.
| Field | Example | Notes |
|---|---|---|
patient_count |
10 |
What was generated, and what you are billed for |
| FHIR R4 bundles | Patient, Condition, MedicationRequest, Procedure, Observation, Encounter | One complete bundle per patient, in the Key-Value Store |
| CSV exports | patients, conditions, medications, procedures, observations, encounters | Flat tables for spreadsheets and dataframes |
key_value_store_key |
reference in the dataset row | Points to the stored bundles and CSVs |
execution_metadata |
every parameter used | Makes runs reproducible |
summary |
file counts and final patient total | Quick sanity check |
Demographics, conditions, medications, and procedures hang together medically per patient, which is what makes Synthea output better test data than random fakes.
Who this is for
Developers building or testing healthcare applications against FHIR interfaces, machine-learning teams that need patient-shaped training data without privacy review, and instructors or researchers who need a classroom-safe EHR dataset.
The manual way, and where it drags
Running Synthea locally means cloning the repo, getting the Java version right, learning the properties files, and managing gigabytes of output directories per large run. It all works, and I have done it, but every batch is a small ops project: tweak config, rerun, clean up disk, zip results for whoever asked. The Actor removes exactly that layer. Same engine, same output formats, no local footprint, and each run's files are cleaned up automatically after storage.
The faster way: run the Synthea generator
Apify Console
- Open the Synthea Medical Record Generator API and click Try for free.
- Set
population_size, optionally withstate,gender,age_range, or aseed. - Run it and collect FHIR bundles and CSVs from the run's storage.
REST
curl -X POST "https://api.apify.com/v2/acts/johnvc~Synthea-Medical-Record-Generator-API/runs?token=YOUR_APIFY_TOKEN" \
-H "Content-Type: application/json" \
-d '{ "population_size": 10, "state": "Massachusetts" }'
Run endpoint reference: the Apify API docs.
Generate synthetic patients in Python
from apify_client import ApifyClient
client = ApifyClient("YOUR_APIFY_TOKEN")
run = client.actor("johnvc/Synthea-Medical-Record-Generator-API").call(
run_input={
"population_size": 5,
"gender": "F",
"age_range": "30-40",
"seed": 12345,
}
)
for item in client.dataset(run["defaultDatasetId"]).iterate_items():
print(item["patient_count"], item.get("key_value_store_key"), item.get("summary"))
The seed matters more than it looks: the same seed regenerates the same patients, so your test fixtures stay stable across runs.
FHIR test data for healthcare app development
The task Create FHIR test data for healthcare app development is the standard starting point: a small population with complete R4 bundles to throw at your FHIR endpoints.
Dummy patient data as FHIR plus CSV
Generate dummy patient data FHIR CSV shows the two-format output side by side, bundles for systems and flat tables for humans.
A synthetic EHR dataset for research
Generate synthetic EHR dataset for research leans on the demographic filters (state, city, age_range) to shape a population instead of taking whatever comes.
Patient records for EHR testing
Synthetic FHIR patient records for EHR testing targets integration testing, where the win is US Core IG support via exporter_fhir_use_us_core_ig for interoperability checks.
Training data for machine learning
Synthetic patient data for machine learning generates the CSV side at volume, patient-shaped rows a model can train on with zero privacy review, because no row describes a real person.
Use it from Claude and other MCP clients
Add the Apify MCP server (https://mcp.apify.com/?tools=actors,docs,johnvc/Synthea-Medical-Record-Generator-API) and Claude, Claude Code, or Cursor can generate test patients mid-conversation: "give me five synthetic patients from Texas with US Core bundles" becomes a tool call. If you have not tried Claude with tools, start at claude.ai.
FAQ about the synthetic medical record generator
Is this a scraper or a generator?
A generator, full stop. Nothing is scraped from anywhere: every record is produced by the open-source Synthea engine, so the output is synthetic by construction rather than anonymized after the fact. That distinction is the whole point for compliance conversations.
How much does the synthetic patient generator cost?
A $0.02 setup fee per run plus $0.01 per patient record generated. A 10-patient test batch is $0.12, and population_size is the spend control. New Apify accounts include free platform credit, which covers plenty of experiments.
Is the generated data real patient data in disguise?
No. It is not derived from real patients, so there is no re-identification risk and no protected health information in the output. The records are medically plausible because Synthea models disease progressions, not because they borrow from anyone's chart.
Can Claude run the generator through MCP?
Yes. Through the Apify MCP server the generator appears as a callable tool, so an agent can produce fixtures on demand while it builds or tests a healthcare feature.
Can I schedule the generator the way I would schedule a scraper?
Yes, the platform mechanics are identical: save a task with your input, attach an Apify Schedule, and fresh synthetic batches arrive on cadence, handy for CI runs that want new-but-reproducible data. Start from the Synthea Medical Record Generator API.
What are the generator's limits?
population_size is capped at 100 per run to keep memory and disk predictable; generate larger cohorts in batches with different seeds. Locations are US states and cities, so geographic modeling is US-centric. And the data is for building and testing systems, not for drawing clinical conclusions.
More from Truffle Pig Data
If your healthcare work extends into research and IP, these Actors pair well: the Google Scholar API for medical literature and citations, the Google Patents API for device and method prior art, and the Google News API for industry monitoring.
Wrapping up
Test data should be the easiest part of healthcare application development, not a compliance meeting. Point the Synthea Medical Record Generator API at a population size and start building.
Top comments (0)