🏥 Synthea Synthetic Patient Data Generator

Generate realistic synthetic patient healthcare data using Synthea. Create FHIR bundles, CSV files, and metadata for synthetic patients with demographics, conditions, medications, procedures, and more. Perfect for healthcare research, EHR testing, medical training, and healthcare application development.

💡 What is Synthea Synthetic Patient Data Generator?

Synthea Synthetic Patient Data Generator is a powerful Apify Actor that generates realistic, synthetic patient healthcare data using the open-source Synthea™ synthetic patient population simulator. This Actor transforms complex healthcare data generation into a simple, scalable API that produces comprehensive patient records in industry-standard formats.

Whether you're building healthcare applications, testing EHR systems, conducting medical research, training machine learning models, or developing healthcare analytics tools, you'll get realistic, privacy-compliant patient data without the legal and ethical concerns of using real patient information ⚡.

✅ FHIR-Compliant: Generates data in FHIR (Fast Healthcare Interoperability Resources) format, the industry standard for healthcare data exchange

✅ Comprehensive Data: Includes patient demographics, conditions, medications, procedures, observations, encounters, and more

✅ Privacy-Safe: Synthetic data eliminates HIPAA concerns and privacy risks associated with real patient data

✅ Reproducible: Use seeds to generate the same patient populations for consistent testing and development

---

📋 What This API Returns

Each run returns one structured JSON record per synthetic patient population, so you know exactly what lands in your dataset:

• patient_count: how many synthetic patients were generated, which is also what you are billed for
• FHIR R4 bundles: one complete bundle per patient (Patient, Condition, MedicationRequest, Procedure, Observation, Encounter, and more), stored in the Key-Value Store with a key_value_store_key reference in the dataset row
• CSV exports: flat tables (patients, conditions, medications, procedures, observations, encounters) referenced the same way, ready for spreadsheets and dataframes
• execution_metadata: every parameter used for the run, so results stay reproducible
• summary: file counts and the final patient total for a quick sanity check

Everything here is synthetic and privacy-safe, so nothing is real protected health information. Every bundle is produced by the open-source Synthea engine, not derived from any real patient.

---

📦 What Data Can You Extract?

🏷️ Data Type	📋 Description
👤 Patient Demographics	Age, gender, race, ethnicity, address, and other demographic information
🏥 FHIR Bundles	Complete FHIR R4 bundles containing all patient healthcare data in standardized format
💊 Medications	Prescribed medications with dosages, frequencies, and administration details
🩺 Conditions	Diagnosed medical conditions with onset dates, severity, and clinical status
🔬 Procedures	Medical procedures performed with dates, codes, and outcomes
📊 Observations	Lab results, vital signs, and other clinical observations
🏥 Encounters	Healthcare encounters including hospitalizations, office visits, and emergency visits
📋 CSV Files	Tabular data exports for easy analysis in spreadsheet applications
📄 Metadata	Generation metadata including patient counts, execution parameters, and file listings
🔗 US Core IG Support	Optional US Core R4 Implementation Guide profiles for enhanced interoperability

This structured synthetic patient dataset can be exported for EHR testing, healthcare application development, medical research, machine learning training, and healthcare analytics workflows.

---

⚙️ Key Features

✨ Realistic Synthetic Data - Generates medically accurate patient records with realistic relationships between conditions, medications, and procedures

🔬 FHIR R4 Compliant - Produces industry-standard FHIR bundles ready for integration with FHIR-compliant systems

🎯 Advanced Filtering - Filter patients by gender, age range, location (state/city), and other demographic characteristics

🌍 Location-Based Generation - Generate patients from specific US states and cities for geographic analysis

📊 Multiple Output Formats - Get data in FHIR JSON bundles, CSV files, and structured metadata

🔄 Reproducible Results - Use seeds to generate identical patient populations for consistent testing

💰 Pay-Per-Patient Pricing - Transparent pricing: setup fee + per-patient charge (only pay for patients you generate)

🛡️ Production-Ready - Built-in error handling, validation, and graceful failure modes

📦 Structured Output - Clean JSON output with complete metadata and file organization

🇺🇸 US Core IG Support - Optional US Core R4 Implementation Guide profiles for enhanced FHIR compliance

💾 Key-Value Store Storage - All FHIR bundles and CSV data are stored in Key-Value Store with references in the dataset, ensuring compliance with size limits while preserving all data

---

📖 Usage Examples

Example 1: Basic Patient Generation

Generate a single synthetic patient with default settings.

{
  "population_size": 1
}

Output: One patient record with complete FHIR bundle, CSV files, and metadata.

---

Example 2: Generate Multiple Patients with Location

Generate 10 patients from Massachusetts.

{
  "population_size": 10,
  "state": "Massachusetts"
}

Output: 10 patient records from Massachusetts with location-specific healthcare data.

---

Example 3: Filter by Gender and Age Range

Generate 5 female patients aged 30-40 years.

{
  "population_size": 5,
  "gender": "F",
  "age_range": "30-40"
}

Output: 5 female patients between 30-40 years old with age and gender-appropriate conditions and medications.

---

Example 4: Reproducible Generation with Seed

Generate the same 3 patients every time using a seed for reproducibility.

{
  "population_size": 3,
  "seed": 12345
}

Output: Identical 3 patient records every time this seed is used, perfect for testing and development.

---

Example 5: Location-Specific Generation (State and City)

Generate patients from a specific city in California.

{
  "population_size": 5,
  "state": "California",
  "city": "San Francisco"
}

Output: 5 patient records from San Francisco, California with location-specific healthcare encounters.

---

Example 6: Custom Reference Date

Generate patients with a specific reference date for historical scenarios.

{
  "population_size": 10,
  "reference_date": "20200101",
  "state": "New York"
}

Output: 10 patients from New York with healthcare data generated relative to January 1, 2020.

---

Example 7: US Core Implementation Guide

Generate FHIR bundles using US Core R4 Implementation Guide profiles.

{
  "population_size": 5,
  "exporter_fhir_use_us_core_ig": true,
  "state": "Texas"
}

Output: 5 patients from Texas with FHIR bundles conforming to US Core R4 Implementation Guide profiles.

---

Example 8: Comprehensive Configuration

Use multiple filters and options together for precise patient generation.

{
  "population_size": 20,
  "seed": 67890,
  "gender": "M",
  "age_range": "25-50",
  "state": "Florida",
  "city": "Miami",
  "exporter_fhir_use_us_core_ig": true
}

Output: 20 male patients aged 25-50 from Miami, Florida with US Core IG-compliant FHIR bundles.

---

Example 9: Large Population Generation (Recommended Approach)

The Actor enforces population_size <= 100 per run to keep memory and disk usage predictable. For larger populations, run multiple times with different seeds.

Batch 1:

{
  "population_size": 100,
  "seed": 1000,
  "state": "California"
}

Batch 2:

{
  "population_size": 100,
  "seed": 2000,
  "state": "California"
}

Output: 200 total patients from California, generated in two batches. Each run's files are automatically cleaned up after storage in the Key-Value Store, so disk usage stays bounded.

💡 Tip: Use different seeds for each batch to ensure unique patients, or use sequential seeds to maintain reproducibility.

---

🔍 Input Parameters

Parameter	Type	Required	Default	Description
population_size	integer	✅ Yes	1	Number of synthetic patients to generate. Must be at least 1. Each patient record is charged separately. ⚠️ For large populations (>100 patients): Consider generating in smaller batches (200-300 patients per run) to avoid disk space limitations. Files are automatically cleaned up after storage in Key-Value Store.
seed	integer	❌ No	-	Random seed for reproducible patient generation. If provided, the same seed will generate the same patients. Useful for testing and consistent data generation.
reference_date	string	❌ No	Today's date	Reference date for patient generation in YYYYMMDD format (e.g., "20240101"). If not provided, uses today's date. All patient timelines are generated relative to this date.
clinician_seed	integer	❌ No	-	Seed for clinician assignment to patients. If provided, ensures consistent clinician assignments across runs. Useful for maintaining consistent provider-patient relationships.
gender	string	❌ No	-	Filter patients by gender. Only patients of the specified gender will be generated. See Gender Options below.
age_range	string	❌ No	-	Filter patients by age range in format "minAge-maxAge" (e.g., "30-40"). Only patients within this age range will be generated. Ages must be integers.
state	string	❌ No	-	US state name for patient location (e.g., "Massachusetts", "California"). If specified, only patients from this state will be generated. Use full state names, not abbreviations.
city	string	❌ No	-	City name for patient location. Requires state to be specified. If provided, only patients from this city will be generated.
exporter_fhir_use_us_core_ig	boolean	❌ No	false	If enabled (true), generates FHIR bundles using US Core R4 Implementation Guide profiles. Enhances FHIR compliance for US healthcare systems. See US Core IG Options below.

---

⚠️ Limitations & Important Notes

Disk Space Considerations

Large Population Generation: When generating large populations (>100 patients), disk space may become a limiting factor. Each patient generates FHIR JSON files that can be 0.5-1 MB in size. For 1000 patients, this can require 100+ MB of temporary disk space during generation.

Solutions:

• Generate in batches: For large populations, split into multiple runs of 200-300 patients each
• Automatic cleanup: All output files are automatically deleted from disk after being stored in Apify's Key-Value Store, preventing accumulation
• Monitor space: If you encounter "No space left on device" errors, reduce the population_size and run multiple smaller batches

Note: Files are temporarily stored on disk during generation, then automatically cleaned up after successful storage in Key-Value Store. This ensures all data is preserved while managing disk space efficiently.

---

📊 Enumerated Value Options

Gender Options

The gender parameter accepts the following values:

Value	Description	When to Use
"M"	Male	Generate only male patients. Useful for gender-specific research, testing, or analysis.
"F"	Female	Generate only female patients. Useful for gender-specific research, testing, or analysis.

Note: If gender is not specified, patients of all genders will be generated according to natural distribution.

---

US Core Implementation Guide Options

The exporter_fhir_use_us_core_ig parameter accepts the following values:

Value	Description	When to Use
true	Enable US Core R4 IG	Use when you need FHIR bundles that conform to US Core R4 Implementation Guide profiles. Required for integration with many US healthcare systems and EHR platforms.
false	Standard FHIR R4	Use standard FHIR R4 format (default). Suitable for most use cases and international healthcare systems.

Note: US Core IG profiles provide additional constraints and extensions specific to US healthcare data standards, enhancing interoperability with US-based systems.

---

📤 Output Format

Dataset Structure

Each generation run returns a structured JSON object with the following structure:

{
  "generation_timestamp": "2025-01-15T14:30:00.123456",
  "patient_count": 5,
  "execution_metadata": {
    "population_size": 5,
    "seed": 12345,
    "reference_date": "20240101",
    "clinician_seed": null,
    "gender": "F",
    "age_range": "30-40",
    "state": "Massachusetts",
    "city": null,
    "base_directory": "/path/to/output",
    "output_directory": "/path/to/output/output",
    "execution_timestamp": "2025-01-15T14:25:00.000000",
    "command": "java -jar synthea-with-dependencies.jar -s 12345 -p 5 -g F -a 30-40 Massachusetts"
  },
  "generated_files": {
    "fhir": [
      "/path/to/output/output/fhir/Patient_12345.json",
      "/path/to/output/output/fhir/Patient_67890.json"
    ],
    "csv": [
      "/path/to/output/output/csv/patients.csv",
      "/path/to/output/output/csv/conditions.csv",
      "/path/to/output/output/csv/medications.csv"
    ],
    "metadata": [
      "/path/to/output/output/metadata/metadata.json"
    ]
  },
  "data": {
    "fhir_bundles": [
      {
        "file": "Patient_12345.json",
        "path": "/path/to/output/output/fhir/Patient_12345.json",
        "key_value_store_key": "fhir-bundle-Patient_12345.json",
        "size_mb": 5.2,
        "stored_in_kv_store": true,
        "format": "json"
      },
      {
        "file": "Patient_67890.json",
        "path": "/path/to/output/output/fhir/Patient_67890.json",
        "key_value_store_key": "fhir-bundle-Patient_67890.json",
        "size_mb": 12.5,
        "stored_in_kv_store": true,
        "format": "json"
      }
    ],
    "csv_data": {
      "patients.csv": {
        "file": "patients.csv",
        "path": "/path/to/output/output/csv/patients.csv",
        "key_value_store_key": "csv-patients",
        "size_mb": 2.1,
        "stored_in_kv_store": true,
        "row_count": 100
      }
    },
    "metadata": {
      "metadata.json": {
        "file": "metadata.json",
        "path": "/path/to/output/output/metadata/metadata.json",
        "data": {
          "patientCount": 5
        }
      }
    }
  },
  "summary": {
    "total_fhir_files": 5,
    "total_csv_files": 10,
    "total_metadata_files": 1,
    "patient_count": 5
  }
}

Output Fields

Top-Level Fields

• generation_timestamp: ISO 8601 timestamp when the patient generation was completed
• patient_count: Number of patient records generated (used for billing)
• execution_metadata: Complete metadata about the Synthea execution including all parameters used
• generated_files: Lists of generated files organized by type (FHIR, CSV, metadata)
• data: Parsed data from all generated files, ready for use
• summary: Summary statistics of the generation run

FHIR Bundle Structure

All FHIR bundles are stored in Key-Value Store with references in the dataset:

{
  "file": "Patient_12345.json",
  "path": "/path/to/output/output/fhir/Patient_12345.json",
  "key_value_store_key": "fhir-bundle-Patient_12345.json",
  "size_mb": 5.2,
  "stored_in_kv_store": true,
  "format": "json"
}

Each FHIR bundle (whether in dataset or Key-Value Store) contains:

• resourceType: Always "Bundle" for FHIR bundles
• type: Bundle type (typically "collection")
• entry: Array of FHIR resources including:
  • Patient: Demographics and basic information
  • Condition: Diagnosed medical conditions
  • MedicationRequest: Prescribed medications
  • Procedure: Medical procedures performed
  • Observation: Lab results and vital signs
  • Encounter: Healthcare encounters (visits, hospitalizations)
  • Organization: Healthcare organizations (hospitals, clinics)
  • Practitioner: Healthcare providers
  • And more healthcare resources

Retrieving FHIR Bundles from Key-Value Store

All FHIR bundles are stored in Key-Value Store. Retrieve the full data using the key_value_store_key:

Using Apify SDK (Python):

from apify import Actor

async with Actor:
    # Get dataset item
    dataset_item = await Actor.get_dataset_items()
    
    # For each FHIR bundle (all are stored in Key-Value Store)
    for bundle in dataset_item[0]['data']['fhir_bundles']:
        # Retrieve from Key-Value Store
        full_bundle_data = await Actor.get_value(bundle['key_value_store_key'])
        print(f"Retrieved bundle: {full_bundle_data}")
    
    # For each CSV file (all are stored in Key-Value Store)
    for filename, csv_ref in dataset_item[0]['data']['csv_data'].items():
        # Retrieve from Key-Value Store
        full_csv_data = await Actor.get_value(csv_ref['key_value_store_key'])
        print(f"Retrieved CSV {filename}: {full_csv_data}")

Using Apify API:

KEY="fhir-bundle-Patient_67890.json"   # the key_value_store_key from the dataset item
STORE_ID="your-store-id"

curl "https://api.apify.com/v2/key-value-stores/${STORE_ID}/records/${KEY}" \
  -H "Authorization: Bearer ${APIFY_TOKEN}"

Note: All FHIR bundles and CSV data are stored in Key-Value Store to ensure compliance with Apify's 9MB dataset item limit. The dataset contains only references and metadata, while the full data is accessible via Key-Value Store.

CSV Data Structure

All CSV files are stored in Key-Value Store with references in the dataset:

{
  "patients.csv": {
    "file": "patients.csv",
    "path": "/path/to/output/output/csv/patients.csv",
    "key_value_store_key": "csv-patients",
    "size_mb": 2.1,
    "stored_in_kv_store": true,
    "row_count": 100
  }
}

CSV files are organized by data type:

• patients.csv: Basic patient demographics
• conditions.csv: Patient conditions and diagnoses
• medications.csv: Prescribed medications
• procedures.csv: Medical procedures
• observations.csv: Lab results and observations
• encounters.csv: Healthcare encounters
• And more specialized CSV files

Each CSV file entry includes:

• file: Filename
• path: Full file path
• key_value_store_key: Key to retrieve full CSV data from Key-Value Store
• row_count: Number of rows in the file
• size_mb: Size of the CSV data in megabytes
• stored_in_kv_store: Always true

To retrieve CSV data, use the same method as FHIR bundles - get the key_value_store_key and fetch from Key-Value Store.

---

n8n integration

Available as an n8n community node, n8n-nodes-synthea-api. In n8n: Settings, Community Nodes, install n8n-nodes-synthea-api, then use it in any workflow (it also works as an AI Agent tool).

---

💰 Pricing

This Actor uses a pay-per-event pricing model with transparent pricing:

• Setup Fee: $0.02 per Actor run (one-time charge for instance setup and initialization)
• Patient Record: $0.01 per patient record generated (charged for each synthetic patient record returned in the results)

You only pay for patients you actually receive, making it cost-effective for both small-scale testing and large-scale data generation. The Actor performs a pre-run credit check to ensure you have sufficient funds. If insufficient funds are detected, the Actor will exit gracefully with an error message.

Note: System files (hospitals, practitioners) are included at no additional charge beyond the setup fee.

---

🎯 Use Cases

• EHR Testing & Development: Generate realistic patient data for testing Electronic Health Record systems without privacy concerns

• Healthcare Application Development: Create test datasets for healthcare applications, mobile health apps, and telemedicine platforms

• Medical Research: Use synthetic data for research when real patient data is unavailable or requires extensive IRB approval

• Machine Learning Training: Train healthcare AI models on realistic synthetic data without privacy restrictions

• Healthcare Analytics: Analyze patient populations, treatment patterns, and healthcare outcomes using synthetic data

• FHIR System Integration: Test FHIR-compliant systems and APIs with realistic patient bundles

• Medical Education: Create patient scenarios for medical training and education programs

• Healthcare Data Modeling: Model healthcare workflows, care pathways, and treatment protocols

• Compliance Testing: Test healthcare systems for HIPAA compliance and data privacy requirements

• Population Health Analysis: Study population health trends, disease prevalence, and healthcare utilization patterns

• Clinical Decision Support: Develop and test clinical decision support systems with realistic patient scenarios

• Healthcare Interoperability: Test healthcare data exchange and interoperability between systems

---

🚀 Getting Started

1. Open the API on Apify: View on Apify Store
2. Set population_size (and optionally state, gender, age_range, or a seed for reproducible runs), then click Start.
3. Read the run's dataset for the per-patient FHIR and CSV references, then fetch each full payload from the Key-Value Store using its key_value_store_key.

For a Python quick-start and a full MCP setup walkthrough, see the example repo on GitHub.

Synthea is the open-source synthetic patient generator from The MITRE Corporation. No API key is required to run this API on Apify.

---

🔌 Use this API from Claude (MCP)

Add this API as a tool in Claude Code (free trial), Claude Cowork (free trial), or any other MCP client, via the hosted Apify MCP server. Use this API-specific URL:

https://mcp.apify.com/?tools=actors,docs,johnvc/Synthea-Medical-Record-Generator-API

Apify MCP integration docs: https://docs.apify.com/platform/integrations/mcp

Your AI agent can then handle requests like "generate 50 synthetic FHIR patients from Texas for my EHR test suite" or "create a reproducible cohort of female patients aged 30 to 40" with live, structured output.

---

🔌 Integrations: Automate Healthcare Application Development Pipelines

A single run answers one question ("give me 10 synthetic patients from Massachusetts"). The real payoff in healthcare application development comes from regenerating fresh synthetic cohorts on a schedule, so your test suites, demos, and training sets never go stale. See the full list of Apify platform integrations.

Tasks and Schedules (the core recipe). Save one task per cohort you need (for example "100 California patients, seed 1000" or "female patients aged 30 to 40"), then attach a schedule from the API's Actions, then Schedule menu. Useful cron strings: 0 7 * * * (daily at 7 AM to refresh a CI test fixture), 0 */6 * * * (every 6 hours), 0 9 * * 1 (Mondays, a weekly training-data refresh). One schedule can trigger many tasks at once, so a whole battery of cohorts regenerates in a single pass. The Featured Tasks section below has ready-to-run examples.

n8n. This API ships an n8n community node (see the n8n integration section above). A four-step pipeline: Schedule Trigger, then the Synthea API node, then a Function node that pulls each bundle from the Key-Value Store, then a database or storage node.

Make and Zapier. The same pattern works no-code with Make and Zapier: trigger on a schedule, run the API, and route the generated records where you need them.

Store the history (Supabase). Send each run's summary rows into a table so a catalog of generated cohorts accumulates. No-code: the n8n Actor node, then a Supabase node. Or in Python, using the real output fields (patient_count, generation_timestamp, execution_metadata):

from apify_client import ApifyClient
from supabase import create_client

apify = ApifyClient("YOUR_APIFY_TOKEN")
supabase = create_client("YOUR_SUPABASE_URL", "YOUR_SUPABASE_KEY")

run = apify.actor("johnvc/Synthea-Medical-Record-Generator-API").call(run_input={
    "population_size": 100,
    "state": "California",
    "seed": 1000,
})
rows = list(apify.dataset(run["defaultDatasetId"]).iterate_items())
for r in rows:
    supabase.table("synthea_cohorts").insert({
        "generation_timestamp": r["generation_timestamp"],
        "patient_count": r["patient_count"],
        "state": r["execution_metadata"]["state"],
        "seed": r["execution_metadata"]["seed"],
    }).execute()

MCP and AI agents. Add this API as a tool in Claude or Cursor through the Apify MCP server so an agent can generate cohorts on demand (see the Use this API from Claude section above).

Webhooks. For anything custom, fire an Apify webhook on ACTOR.RUN.SUCCEEDED to push each run's dataset into your own service.

---

🔗 Related Tools

Building a healthcare research or development toolkit? These tools from the same catalog pair well with synthetic patient data:

• Google Scholar API: pull medical research papers, citations, and author profiles to pair with the synthetic datasets you generate here.
• Google Patents API: search medical device and pharmaceutical patents for healthcare R&D and prior-art review.
• Google Scholar Lite API: cheap bulk retrieval of academic papers when you need literature at volume.

General-purpose synthetic data generators exist too, such as Synthetic Dataset Generator, but they produce arbitrary tabular records from generic presets, do not model clinical relationships, and do not emit FHIR R4 bundles, and they show minimal adoption. This API is purpose-built for healthcare: it generates clinically coherent patients with linked conditions, medications, and procedures, and exports standards-compliant FHIR with optional US Core IG profiles.

---

❓ FAQ and Troubleshooting

Why did I get an "insufficient funds" error before any data was generated?

The Actor pre-checks your available balance against the projected cost (setup fee + population_size × per-patient fee) and exits gracefully if it falls short. Add funds to your Apify account and re-run.

Why did my run time out on a large population?

Synthea is CPU-intensive. Stay at or below population_size: 100 per run and split larger jobs into multiple runs with different seeds (see Example 9).

Why did I get a "No space left on device" error?

Synthea's intermediate output files can exceed the container's disk allowance for very large populations. Reduce population_size to 100 or fewer per run.

The dataset items reference key_value_store_key instead of inline FHIR data. Where is the actual data?

FHIR bundles and CSV files are stored in the run's Key-Value Store to stay under Apify's 9 MB dataset item limit. Fetch the full payload using the key_value_store_key and the Apify SDK or REST API - see "Retrieving FHIR Bundles from Key-Value Store" above.

Can I supply a custom Synthea config or modules directory?

Not directly from the Actor input - the cloud container has no path for user file uploads. The Actor ships with default Synthea modules, and the US Core R4 IG toggle covers the most common need. For custom modules, fork the repo and bake them into the Docker image.

Can I schedule this API to regenerate synthetic data automatically?

Yes, and this is where most of the value is. Any run can be automated: save a task with your input (a cohort definition like "100 California patients, seed 1000"), then attach a schedule from the API's Actions, then Schedule menu. Concrete cron strings: 0 7 * * * for daily at 7 AM, 0 */6 * * * for every six hours, and 0 9 * * 1 for Mondays. One schedule can trigger many tasks at once, so a whole set of cohorts regenerates together. See the Integrations section above for the full Tasks-and-Schedules recipe, and Apify schedules for the docs.

Should I use an API or a web scraper for synthetic health data?

Neither approach scrapes real records, and that is the point. Real patient data carries privacy and legal constraints that make web scraping the wrong tool. This Actor is a generator you call like a clean API: you request a population and it computes brand-new, statistically realistic patients on the fly. You get reproducible, standards-compliant data with no quotas and no privacy exposure, which a scraper of live sources cannot offer.

Can I use this Synthea API programmatically?

Yes. The Apify API runs the Actor, schedules it, and fetches datasets, and the apify-client package exists for both Node.js and Python. See the "Retrieving FHIR Bundles from Key-Value Store" example above, or the Actor's API tab.

Can I use this API through an MCP server?

Yes. Add it as a tool in any MCP client (Claude, Cursor, and others) through the hosted Apify MCP server with the API-specific URL https://mcp.apify.com/?tools=actors,docs,johnvc/Synthea-Medical-Record-Generator-API. In Claude Code (free trial) or Claude Cowork (free trial) your agent can then generate patient cohorts on demand. See the Apify MCP docs.

Can I integrate this API with other apps?

Yes. It connects to almost any cloud service through Apify integrations: Make, Zapier, Slack, the n8n community node, and webhooks on ACTOR.RUN.SUCCEEDED for custom actions. See the Integrations section above for full recipes.

Is the data real, and is it HIPAA compliant?

The data is entirely synthetic. Patients are simulated by the open-source Synthea engine and are not derived from any real person, so the output contains no real protected health information. Because there is no real PHI, you avoid the HIPAA and consent constraints that come with using actual patient records, which is why synthetic data (what is synthetic data) is widely used for testing and development. Bundles follow the FHIR R4 standard.

What is healthcare analytics, and how does synthetic data help?

Healthcare analytics is the use of data to study patient populations, treatment patterns, and outcomes. Synthetic patient data lets analytics and data-science teams build and validate dashboards, models, and pipelines against realistic records before touching any sensitive real data, which shortens development cycles and removes privacy blockers.

How else can I build a synthetic healthcare data pipeline?

Pair this API with related tools in the same catalog: the Google Scholar API for medical research papers and citations, the Google Patents API for medical device and pharmaceutical prior art, and the Google Scholar Lite API for cheap bulk literature retrieval.

---

🚀 Ready to Generate Synthetic Patient Data?

Start using the Synthea Synthetic Patient Data Generator today and create realistic, privacy-compliant patient healthcare data in minutes! Whether you're building healthcare applications, testing EHR systems, conducting medical research, or training AI models, you'll have comprehensive FHIR-compliant patient data ready for immediate use.

Made with ❤️

Transform your healthcare development and research with reliable, production-ready synthetic patient data generation. Generate realistic patient records without privacy concerns or legal restrictions.

---

Featured Tasks

Ready-to-run examples that show this API solving a specific problem. Each opens its own setup so you can run it on your account in one click.

• Generate synthetic FHIR patient records for EHR testing - Generate FHIR R4 patient bundles with the US Core profile for testing EHR systems, returning patient count, generation time, and file totals.
• Create FHIR test data for healthcare app development - Generate a small batch of synthetic FHIR R4 patient records as ready-to-use test fixtures for building healthcare apps.
• Generate synthetic patient data for machine learning - FHIR R4 bundles with no real PHI; set population size, age range, state, and random seed.
• Generate a synthetic EHR dataset for research - seed-reproducible FHIR R4 bundles with no real PHI; control population size, gender, and state.
• Generate dummy patient data in FHIR format - FHIR R4 bundles for app testing and demos with no real PHI; choose size, age range, city, and state.

---

Last Updated: 2026.07.14