Parker · Apex Atlas

Synthetic FHIR patients that are
current, causal, and auditable.

Apex Atlas generates large-scale, fully synthetic patient populations in FHIR R4/R5, grounded in public epidemiological data. Cohorts mirror real US care patterns and map to production FHIR from QHINs, HIEs, payer APIs, and CMS Blue Button-style feeds — for AI training, end-to-end integration, demos, and quality-measure testing. No real patient is ever depicted.

FHIR R4 · R5 US Core 6.1 Bulk Data NDJSON DEQM MeasureReport Gravity SDOHCC Apache 2.0
101clinical modules · 14 domains
101modules with sourced fidelity expectations
99.6%metric strata within tolerance
R4 · R5US Core 6.1 conformant
0credentialed datasets used

Built by Parker Health, Inc. · Author: Vincent J. Lopez, Founder & CEO

Production mapping

Not just conformance — data that maps to what you ingest in the field

Atlas output uses the same FHIR resource graph as clinical and payer channels. Population statistics mirror public US epidemiology; individual records are fully synthetic.

ChannelAtlas mirrors
QHIN / TEFCAUS Core clinical summaries — problems, meds, encounters, vitals/labs
HIELongitudinal multi-condition charts, notes (DocumentReference), cross-org care patterns
Stedi / claims APIsCoverage, Claim, ExplanationOfBenefit (--with-coverage --with-claims)
CMS Blue Button 2.0Medicare-shaped Coverage + EOB, age-stratified chronic care
Bulk $exportNDJSON + Parquet at scale

Atlas does not ingest from these systems. It produces license-clean cohorts your pipelines can treat like production FHIR — without PHI.

Proof, not promises

Three things you can open right now

Most synthetic-data claims are unverifiable. Atlas ships the evidence.

📊

Fidelity scorecard

Every sourced module is generated as a focused cohort and checked against its cited public target (NHANES, CDC, SEER, AHA) by the cohort harness.

565 / 565metric strata within tolerance · 100/100 modules pass

Open the scorecard →

📉

SDoH is causal, not a tag

Social-risk burden reduces what actually gets generated — fewer ambulatory visits, fewer filled prescriptions. The relationship a model needs to learn.

−39% / −32%ambulatory encounters / medication fills at high burden

Open the benchmark →

🧬

A library that extends itself

atlas author turns a condition name into a citation-grounded draft module and its sourced fidelity expectation — gated by clinician sign-off.

dossier → moduleresearch · synthesize · validate · promote

How authoring works →

The differentiator, measured

Patients with barriers behave like patients with barriers

Generated with --with-sdoh over a chronic-disease cohort. As a patient's positive SDoH screens rise, utilization falls — a gradient a tag-only generator can't produce.

Positive SDoH screensMean ambulatory encountersvs. noneMean medication fillsvs. none
0 (none)1.240.45
11.04−16%0.38−17%
20.86−31%0.31−32%
3+0.76−39%0.31−32%

Rates calibrated to BRFSS care-avoidance and Urban Institute cost-related non-adherence figures.

What it looks like

FHIR-native, profile-conformant output

One transaction Bundle per patient. Every resource targets a named US Core 6.1 profile and carries the HL7 HTEST tag so synthetic data is never mistaken for real.

  • Resources: Patient, Condition, Observation, Encounter, MedicationRequest, Procedure, Immunization, DiagnosticReport, Coverage, Claim/EOB, MeasureReport, DocumentReference.
  • Formats: FHIR R4/R5 Bundles, $export-aligned NDJSON, and Parquet.
  • Identity: every patient gets a Parker GPX identifier under the synthetic namespace.
  • Grounded notes: template or LLM-authored progress notes grounded in structured data.
{
  "resourceType": "Patient",
  "id": "GPX-SYN-0000000042-7",
  "meta": {
    "profile": ["…/us-core-patient|6.1.0"],
    "tag": [{ "code": "HTEST",
      "display": "test health data" }]
  },
  "gender": "female",
  "birthDate": "1968-04-12"
}
{
  "resourceType": "Observation",
  "meta": { "profile": ["…/us-core-blood-pressure|6.1.0"] },
  "category": [{ "coding": [{ "code": "vital-signs" }]}],
  "code": { "text": "Blood pressure panel" },
  "component": [
    { "code": { "text": "Systolic" },
      "valueQuantity": { "value": 152, "unit": "mm[Hg]" }},
    { "code": { "text": "Diastolic" },
      "valueQuantity": { "value": 96, "unit": "mm[Hg]" }}
  ]
}
Quick start

From clone to cohort in a minute

Apex Atlas is a Python package. Generate a validated FHIR cohort locally, then check it against public norms.

git clone https://github.com/ParkerApex/apex-atlas.git && cd apex-atlas
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"

# Generate 1,000 synthetic FHIR R4 patients with SDoH causal modeling
atlas generate --patients 1000 --seed 42 --with-sdoh --out ./out

# Validate a cohort's prevalence against its cited public targets
atlas generate --patients 20000 --seed 42 --module hypertension --out ./cohort
atlas validate ./cohort --cohort --module hypertension

# Draft a brand-new, citation-grounded module from a research dossier
atlas author synthesize --dossier ./glaucoma.dossier.yaml --out ./atlas-drafts

Prefer to look before you install? Browse a ready-made 25-patient sample cohort → — FHIR R4 bundles with conditions, meds, grounded notes, SDOHCC screening, payer coverage, and HEDIS MeasureReports.

What Apex Atlas is not. It is not trained on, derived from, or informed by restricted datasets such as MIMIC or UK Biobank. It is built exclusively from public, license-clean statistical distributions published by the CDC, NIH, AHA, and ACOG. No synthetic patient corresponds to any real person.