ABDM platform operations

Read-only deployment status

Mode and environment are stamped during deployment. The console reports their effective state and blockers but cannot switch mock, sandbox, or production traffic at runtime.

Central facility registry

Super administrators maintain each tenant's HFR, HIP, and HIU identifiers and control registry verification. Tenants cannot enable modules, change stop controls, or edit ABDM-specific configuration.

Evidence-backed release authority

Protected compliance evidence is bound to one exact build and environment. Release approval requires creator separation and two independent approvers. Expiry, revocation, or build drift fails closed.

Safe operations view

Queues and ledgers expose identifiers, states, attempts, page coordinates, and failure codes only. Callback envelopes, ABHA identifiers, consent artefacts, keys, and clinical content remain protected.

Controlled recovery and terminology

Only eligible failed asynchronous callbacks can be replayed. Terminology releases are staged, validated, and activated as immutable versions.

Onboard a facility

1. Choose the exact clinic or hospital and enter only its approved HFR, HIP, and HIU identifiers.
2. Save the revision, then run server-side registry verification.
3. Resolve deployment, registry, evidence, credential, and release blockers before testing user workflows.
4. Suspend routing immediately when registry authority is withdrawn or under investigation.

Authorize a release

1. Upload reviewed non-PHI evidence for the deployment's fixed environment.
2. Create an immutable manifest for the exact build, adapter, callback profile, modules, HI types, NRCeS target, and Fidelius profile.
3. Submit the draft and collect two independent approvals from administrators other than the creator.
4. Deploy the intended mode through infrastructure. Do not use application data as an environment switch.