Registry API overview

BirthTracks is the birth registry. This API is its import and interop surface — the way another EHR or an integrator feeds a birth record in as a FHIR R4 BFDR Bundle, so a provider enters each birth once instead of re-keying it here. You submit one course of care — mother, child, and the newborn observations — and the same canonical record powers both vital-records filing artifacts and outcome benchmarking. Capture once, emit both, programmatically.

What you can do

Submit a course of care — POST a FHIR R4 Bundle to the ingestion endpoint. Processing is asynchronous: you get an immediate receipt and poll for the result.
Check ingestion status — every submission returns an id you can poll until it reaches a terminal state, with per-record accept/reject detail.
Pre-fill from an EHR launch — the second import lane: a clinician launches BirthTracks from inside their EHR and the launched patient’s data pre-fills a course of care over SMART on FHIR, an interactive one-record path alongside the server-to-server Bundle push above.

What it deliberately does not do

Two limits are stated up front because both matter to the compliance conversation, and both are properties of the partner lane — an EHR vendor or integrator pushing on behalf of the practices it serves:

No filing lane by default. Vendors file vital records through their own EHR, so partner-submitted records are not given a filing spine. Filing through BirthTracks is not part of this integration and is not something a feed can turn on for itself.
No identified patient data is stored. Bundles arrive identified, but a masking step runs before anything is persisted, allow-listing a coarse spine for the mother and child — maternal age, a 3-digit ZIP prefix, race/ethnicity, and the newborn outcomes. No name, no date of birth, no address. Provider attribution (a provider’s name and credentials) is retained, because a provider is not a patient.

A practice pushing its own births under its own key is a different, identified lane and is not masked this way. The lane is set by the key, not the Bundle. The two lanes also differ on the beta gate, place of birth, and provider attribution; see Two lanes for the side-by-side contract and Partner onboarding for the partner path.

Scoped to your practice

A registry API key scopes everything you submit to your own practice, so you can exercise the full ingestion → validation → mapping path end to end. Mint a key, submit the Bundle in Getting started, and inspect the mapped result — all from these docs.

How records are shaped

A Bundle carries one course of care, or many — a Bundle whose entries are themselves Bundles holds one course of care per inner Bundle. Each course of care is:

Exactly one mother Patient (resolved from its BFDR meta.profile).
At least one child Patient.
The newborn Observations the registry lands — birth weight (LOINC 8339-4), gestational age (11884-4), and Apgar scores (9272-6, 9274-2).

See the data dictionary for the full canonical spine and the API reference for endpoint detail.

Authentication and errors

Every request carries a per-source bearer token (Authorization: Bearer rgk_...). Keys are minted per practice, scoped, and revocable; only a hash is stored, so a leaked database can never recover a usable credential.

Every error — auth, malformed request, and each rejected record in a partial batch — comes back as a FHIR OperationOutcome with the application/fhir+json content type, so you parse one error shape everywhere. The one exception is a 429 rate-limit response, which carries a Retry-After header instead (see Rate limits).