Glossary

Quick definitions for the terms used throughout these docs.

Course of care. One birth as the registry models it: a single mother, the labor & delivery encounter, one or more children, and any transfers of care. It’s the unit you submit and the unit the API accepts or rejects.

Practice. Your tenant. Every API key is scoped to one practice, and all data you push or read is isolated to it.

BFDR. Birth and Fetal Death Reporting — the HL7 FHIR Implementation Guide whose profiles shape the Bundle you submit (the mother and child Patient profiles, the newborn Observations, and so on).

FHIR R4 Bundle. The submission payload: a FHIR Bundle carrying the resources for a course of care. A Bundle can hold one course of care or, in batch mode, many — a Bundle whose entries are themselves Bundles. The registry checks only that resourceType is "Bundle"; the Bundle type (document, transaction, batch, …) is not enforced, though the examples use document. A transaction/batch entry carrying "request": { "method": "DELETE" } is accepted as a retraction.

Canonical spine. The small, input-agnostic data model every course of care maps into — Submission, Mother, Encounter, Child, Transfer of care — whether it arrived by FHIR push, CSV import, or the web form. Downstream filing and benchmarking read from the spine. See the data dictionary.

Transfer of care. A move of the mother or newborn to another care setting (antepartum, intrapartum, postpartum, or neonatal) — the community-birth differentiator. Zero or more per course of care.

Ingestion. One submitted Bundle and its processing. You get an ingestion id back immediately and poll it for status; it ends completed or failed.

OperationOutcome. The FHIR resource the API returns for every error and for each rejected record — so you parse one error shape everywhere.

Partial-batch success. In a batch, each course of care is validated independently: the good records land (accepted) and the bad ones are reported (rejected) without failing the whole submission.

Suspected duplicate. A submitted course of care that matches one already on file (same mother and newborn date/time). It is accepted and stored, then flagged for review — never auto-merged. See Duplicate handling.

Chart number. Your own record id for a course of care, sent as Bundle.identifier.value and stored as external_record_id. Unique within your practice.

Scope. A permission carried by an API key — ingest:write to submit, ingest:read to poll status.

Safe Harbor. The HIPAA de-identification method behind the registry’s reduced fields — e.g. a mother’s residence is stored as the first three ZIP digits (residence_zip3), not a full address.

Amendment. A re-send under a chart number already on file. The correction is applied in place, the record’s version advances, and the previous values are kept as history — it is never a second record. The receipt marks it amended: true with the new version. See Amendments and retractions.

Retraction. A withdrawal of a record on file, sent by chart number with either a Composition whose status is entered-in-error or a transaction/batch entry with "request": { "method": "DELETE" }. The record is voided and leaves statistics and benchmarks immediately; re-sending it later revives it as a further version. The receipt marks it retracted: true.

Idempotency-Key. An optional request header that makes a network retry of a POST safe: the first request with a given key creates the ingestion, and any later request with the same key replays the original 202 receipt without re-ingesting. It is scoped to your practice and applies to the whole request — use a fresh key per distinct submission. Distinct from duplicate handling, which catches the same birth arriving again.

Partner feed. A partner’s per-practice ingest lane — one EHR vendor or integrator pushing births on behalf of a practice it serves, under a key bound to that practice. Partner feeds are de-identified at the door and monitored for feed health; a practice pushing its own births under its own key is the native identified lane, not a partner feed.

Correlation id. The support handle returned in the outcome of a failed ingestion (correlation_id). It keys the internal failure record so support can diagnose a failure without any submitted content in the ticket. See Failed ingestions.