Auth guards vary by endpoint — Create, List, and Get accept app (JWT) users plus trusted-backend callers (admin, platform, benefit provider). Update and Delete are restricted to trusted-backend callers (admin or benefit provider — not app users). JWT ownership and provider-scope checks happen in core, not at the route level.

Overview

An MRN (Medical Record Number) links a dependant to a benefit provider with an external identifier. Each MRN is uniquely scoped to one (dependant_id, benefit_provider_id) pair — only one active MRN per dependant per provider is allowed. The external identifier is stored as a JSONB object (external_mrn) with two optional fields: temp_number (a temporary registration number) and mrn (the final medical record number). Both may be null initially and populated as the provider assigns them. Routes are flat at /mrns (no user nesting). The primary_user_id is derived server-side from the dependant row — callers never supply it.
MRN records are also auto-created during insurance policy creation — one per covered dependant at the benefit’s provider. See the Insurance Policy module for details.

Create Flow


Auth Guards by Endpoint


Endpoints

POST /mrns

Create an MRN linking a dependant to a benefit provider.

GET /mrns

List MRNs. Filter by dependant_id, benefit_provider_id, primary_user_id, statuses, or mrn.

GET /mrns/{id}

Fetch a single active MRN by its internal UUID.

PATCH /mrns/{id}

Replace the external_mrn JSONB. Admin or the owning benefit provider. Used to backfill mrn once the provider issues it.

DELETE /mrns/{id}

Soft-delete (status → INACTIVE). Trusted-backend caller (admin / platform / benefit provider).

Request / Response Examples

external_mrn Object

Both fields are optional. The external_mrn field itself is also optional on create — an MRN record can exist without external identifiers (e.g., when auto-created during policy purchase).

Error Codes