Skip to content

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.

  • 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/json now 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 outcome is encrypted at rest.
  • A terminal status of failed returns a small error object as its receipt body — distinct from the per-record accepted / rejected pair a completed ingestion carries. See Failed ingestions.
  • An unparseable birthDate or meta.lastUpdated is 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 Practitioner resource 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.
  • 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 OperationOutcome you 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 Practitioner and Encounter in the API reference and the data dictionary — including non-NPI provider ids as the identity key and the ATND attendant rule.
  • 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": true and the new version.
  • Retractions. A Composition with status: 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.

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-record accepted / rejected outcomes.
  • Per-practice API keys (rgk_) carrying ingest:write / ingest:read scopes.
  • 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.