Hospital Recovery

Delivery BoundaryCopy Anchor Link

Programme U7 is governed by the focused Recovery plan. Local U1-U7 implement source protection, named resources, stays, observations, escalation, current readiness, secured HTTP APIs and the live workbench in both presets. See U6 API evidence, U7 UI evidence and U8 acceptance. Development mock mode remains separate; live failures do not return mock care. Programme U8 signed discharge and full ward operations remain later work. The ABDM discharge contract is a hard requirement for that signed-discharge phase, not a claim that this work exports a report. Production policy approval, explicit nursing grants, D4/D5, deployed QA and pilot acceptance remain separate gates. An empty production policy registry must keep policy-controlled assessment/handoff unavailable.

Use the manual QA guide and U1 execution record for evidence, limits, and the next implementation boundary. No green characterization test grants clinical release approval.

Current Source EvidenceCopy Anchor Link

The tests are in backend/domains/clinical/test/services/hospital/recovery_characterization_test.rb. Tests named GAP capture a known unsafe source behavior, not a desired invariant. When the relevant local U2-U5 fix lands, replace that gap expectation with a rejection/preservation regression in the same delivery. Do not keep unsafe behavior to preserve a characterization assertion.

The isolated U1 source database reported, before the U2 forward repair:

This is metadata evidence from the isolated candidate database, not an audit of staging or production. The original bed migration declares protections that the SQL dump does not contain. U2 adds the forward repair. Actual-object checks, SQL/migration parity, enforced-role tests and facility acceptance remain required before Recovery intake.

Source And Writer InventoryCopy Anchor Link

All paths in this table are under backend/domains/clinical/.

Shared Occupancy And Lock ContractCopy Anchor Link

This is the target protocol for local U2-U5, not a claim that existing writers follow it. Use one transaction for state, receipt, immutable events and required mutation audit.

1. Resolve current membership, selected facility and action authority. Recheck current authorization before replaying a receipt.
2. Lock applicable case rows in stable ID order, then existing admission rows, then stay rows. Re-read the current care owner and references under those locks.
3. For operations that depend on parent activity or change structure, lock affected wards, then rooms, each in stable ID order. Lock all affected bed rows in stable ID order after the parents.
4. When the action requires current clinical evidence, follow existing case-first source order. Lock medication requests and occurrences in stable ID order. Acquire any required Inventory source lock through its owning service. No source command may acquire a case or capacity lock in reverse order.
5. Recheck expected versions, active resource chain, current owner, exact care identity and current source obligations. Commit one effect or return a conflict with no partial state.

A resource-only writer does not acquire a care-owner lock after a bed lock. It rejects an active-care mutation or enters the owner-first command path before taking bed locks. Database guards arbitrate on the same parent bed row and validate scope/owner agreement; they must not introduce bed-to-owner lock acquisition. U2/U4 must prove the full graph with independent connections. This protocol is not a runtime race-test receipt.

Required database invariants:

• One canonical physical identity per bed; purpose classification is separate from category.
• At most one active Recovery stay per case and one current physical owner across active admissions/stays.
• Bed, room, ward, case and registration references belong to the same tenant/facility.
• Bed pointers and active-owner references agree at transaction completion. A null encounter is valid for day care, not permission to omit the case/patient owner.
• Occupied resources and their parent chain cannot be deleted, deactivated, reclassified or moved out from under care.
• Immutable movement, observation-link, assessment and receipt history cannot be rewritten by generic CRUD.

Do not add a parallel physical-resource ledger. Do not infer a Recovery purpose or license count from a preset.

Proposed HTTP ContractCopy Anchor Link

The original anchor is retained for existing links. Local U6 now implements these routes and U7 uses them through the typed hospitalRecoveryApi. Paths are relative to /clinical/facilities/:facility_id. The facility ID is a selector, not authorization. A request does not supply a tenant as authority.

Use current Hospital response envelopes and structured errors. Use runtime validation and snake-case mapping in hospitalRecoveryApi/recoveryTypes, not component HTTP calls. Opaque versions are strings. Operation keys are UUIDs, scoped to tenant/facility and protected resource/action context. Command history must not disclose another case's receipt through a matching key.

Command MatrixCopy Anchor Link

Every command has action, operation_key, relevant expected versions and any required reason. Reject unrecognized fields and actor/tenant/patient overrides. Resolve resource and patient identities from authorized records, not text entered by the caller.

The accepting actor must have current authority for the target context and supply their own authenticated acknowledgement. The producer cannot submit another actor's identity as proof of acceptance. U1 does not assert that a supported receiving workflow exists for every facility. If there is no eligible target, handoff is unavailable. Bed moves and ongoing care remain distinct. The later U8 signed-discharge service calls the guarded release boundary inside its own transaction. No public discharged flag, arbitrary destination, home label or browser-supplied proof can invoke it.

Read And Error SemanticsCopy Anchor Link

Base view requires view_hospital and view_surgical_cases, current facility scope and the relevant module/capability. Clinical values require observation-source read authority. MAR data retains its own policy. Structural resource changes use manage_hospital_configuration. U1 did not seed manage_recovery. The U4 candidate pulls its migration and catalog/default/snapshot/key-behavior coverage forward from U6, with no default role grant. It checks real stay operations and current facility assignment. The shell remains the role/permission administration surface. Clinical writes additionally require canonical observation authority, current staff/practitioner assignment and the approved action policy. An admin role is not nursing authority.

An exact-key replay is authorized before lookup and returns the committed receipt before testing the old versions again. A replay does not assert that the present source state still equals the original result. Refetch current state. After a lost response, look up the same key; never silently generate a new mutation intent. For provisioning, use the facility-scoped /recovery_resource_commands/:operation_key lookup because the created ID may be unknown. Require current configuration authority and return the created resource ID in the committed receipt, or receipt: null for authorized absence. The instance-scoped lookup remains valid for commands against an already known resource. Keep only private identity-scoped retry metadata, not observation notes, patient search or clinical payloads in browser storage.

Board counts cover the authorized filtered population, not only the current page. Active overnight stays remain visible across the facility-local date boundary. An observation/MAR reader without source authority sees unavailable/forbidden source state, not fabricated normal values. Query keys include tenant, facility, profile, authenticated user and filters. Cancel or isolate old responses and clear drafts/selectors on identity changes; preserve initial deep links during first identity hydration.

Resource drafts retain the version captured when selected. A refetch cannot replace that token under unsent fields. A changed version blocks save until the user explicitly loads the current resource. Readiness review also starts unchecked. It records the evidence the user reviewed, not merely the evidence that loaded. Changed evidence requires another explicit review.

A direct RESOURCE_UNAVAILABLE rejection permits a new target only after fresh reads succeed. Failed refresh keeps the original key. Timeouts and 503 results remain uncertain. A case with a closed Recovery stay cannot start another stay through receive; exact-key replay still returns the original receipt.

Read-Only Capacity Audit SpecificationCopy Anchor Link

Run the future audit against the selected facility with current read authority. Local U1 supplies this specification, not an executable production repair tool. Use aggregated, non-PHI output in the release record. Keep any authorized row-level reconciliation material private.

The audit must be read-only and repeatable. Re-running it must not change rows, counters, classifications or migration state. Record selected facility, evaluated time, deployed commit, object-check outcome, aggregate counts and reviewer decision. An audit failure is not permission to reset or reseed a shared database.

Settings And ReleaseCopy Anchor Link

Planning capacity remains metadata. Real resource commands determine capacity. Disabling intake must preserve the authorized continuation/reconciliation path for active care and exact-key recovery. Code/schema delivery does not approve clinical policy or production resource classification. Use the release acceptance record for D4/D5 decisions and actual deployed QA.