Changelog
Notable changes to the Registry API and these docs. The OpenAPI spec is the authoritative contract; this page is the human-readable history.
The API is unversioned today — changes are additive where possible, and any breaking change will be called out here.
2026-08-24 — Sandbox practices
Section titled “2026-08-24 — Sandbox practices”- A practice can be marked a sandbox (
practices.is_sandbox) for the beta / design-partner program: it holds synthetic data only and shows a persistent “Test practice — sample data” banner in the app. No real PHI lands in a sandbox practice. There is no separate host — sandbox practices live alongside real ones; see the note in Getting started.
2026-08-24 — Canonical spine: eight new columns
Section titled “2026-08-24 — Canonical spine: eight new columns”Records — and the fields the FHIR mapper can land — gained eight columns on the
canonical course-of-care spine: birth_position, induction_indication,
doula_present, delayed_cord_clamping, stat_cesarean, induction and
augmentation agents, prenatal_care_site, and a ten-minute Apgar
(apgar_ten_minute). See the
data dictionary for the full spine.
2026-08-21 — Practice-defined custom fields
Section titled “2026-08-21 — Practice-defined custom fields”- Practices can define their own fields — definitions and per-record values — outside the FHIR lane. These are practice-local: they are not part of the FHIR / USCDI mapping and do not appear in a submitted or pulled Bundle.
2026-08-19 — Scribe role and key minting
Section titled “2026-08-19 — Scribe role and key minting”- A write-only Scribe seat can capture births but read nothing. Minting and managing registry API keys stays with record-managing roles (practice admin or provider) — a Scribe (like a read-only Viewer) can see existing keys but cannot issue one.
2026-08-17 — Feed health returns 503 on a stale batch
Section titled “2026-08-17 — Feed health returns 503 on a stale batch”/health/jsonnow returns 503 when a batch has gone stale, so a monitor can detect a feed that has stopped advancing rather than reading a 200 while ingestion is stuck. See the feed-health expectations in Troubleshooting.
2026-08-14 — Source stamping and blank child dates
Section titled “2026-08-14 — Source stamping and blank child dates”- Provenance source stamping now coalesces to a single source per value, and a blank child birth date is handled at the mapper rather than failing the record.
2026-08-13 — Duplicate detection keys on child birth date
Section titled “2026-08-13 — Duplicate detection keys on child birth date”- Duplicate-detection keys now include the child’s
birthDate, so two births filed under the same chart identifiers but different birth dates are no longer treated as the same record.
2026-08-13 — Encrypted outcomes, failed-receipt shape, stricter date parsing
Section titled “2026-08-13 — Encrypted outcomes, failed-receipt shape, stricter date parsing”- The ingestion
outcomeis encrypted at rest. - A terminal
statusoffailedreturns a small error object as its receipt body — distinct from the per-recordaccepted/rejectedpair a completed ingestion carries. See Failed ingestions. - An unparseable
birthDateormeta.lastUpdatedis dropped at the mapper instead of rejecting the whole record.
2026-07-31 — Provider identity attribution
Section titled “2026-07-31 — Provider identity attribution”- Documented how a pushed
Practitionerresource resolves to a provider identity: a non-NPI provider id can be the identity key, a career log records the provider’s history, and merging two identities repoints attribution to the survivor. See Provider attribution.
2026-07-28 — partner integration docs
Section titled “2026-07-28 — partner integration docs”- New Partner onboarding guide — the end-to-end path for an EHR vendor or integrator: contract and BAA, contract status and beta access, practice and feed-key provisioning, first ingest, and the expected sync cadence (daily floor, event-driven push, bulk backfill at onboarding).
- New Troubleshooting page — every
request-level and per-record
OperationOutcomeyou can receive, what causes it and what to do, plus the feed-health expectations for a live feed. - Documented what the partner lane deliberately does not do — no filing lane by default, and nothing identified is stored (masking runs before persistence, as an allow-list).
- Documented
PractitionerandEncounterin the API reference and the data dictionary — including non-NPI provider ids as the identity key and theATNDattendant rule.
2026-07-28
Section titled “2026-07-28”- Amendments. Re-sending a Bundle under a chart number already on file now
amends that record — version advances, previous values are kept as history —
instead of being rejected as a duplicate. Accepted entries for a correction
carry
"amended": trueand the newversion. - Retractions. A
Compositionwithstatus: entered-in-error, or an entry with"request": { "method": "DELETE" }, voids the record it names; a later re-send revives it as a further amendment version. - Two guards apply to amendments only: a push older than the stored version is
rejected as a
conflict(“Stale update ignored”), and a correction that would duplicate a different record is rejected rather than merged.
See Amendments and retractions.
2026-06-08
Section titled “2026-06-08”The current API surface:
POST /api/registry/fhir/Bundle— submit a FHIR R4 BFDR Bundle (one course of care, or many in batch mode) for asynchronous ingestion.GET /api/registry/fhir/ingestions/{id}— poll an ingestion for its per-recordaccepted/rejectedoutcomes.- Per-practice API keys (
rgk_) carryingingest:write/ingest:readscopes. - Accept-and-flag duplicate detection (
suspected_duplicate) and per-practice chart-number uniqueness. - A consent decision captured per course of care from an optional FHIR
Consent. - A 120 request/minute rate limit per API key, shared across both endpoints.