Hospital Readiness Manual QA

Setup And Release GatesCopy Anchor Link

• Record the commit, environment, facility, preset, testers, and evidence links.
• Apply both readiness migrations and verify ENABLE/FORCE RLS on policy and command tables.
• In a disposable database, verify empty rollback/reapply and populated rollback refusal. FORCE RLS remains on after refusal, including with no tenant context.
• Use synthetic data in local or staging. Do not use real patient records for a test fixture.
• Obtain clinical approval D3 before active clinical use: checklist, freshness, override authority, emergency rules, and representative cases.
• Record the real approval reference and approver. Never copy the automated test rule into production.
• Review active cases without policy bindings and approve a care handoff before deployment.
• Configure permissions in Shell and feature flags in Admin, not Hospital.

The developer guide explains the internal approved-policy services. The framework has no policy-publishing UI. An authorized operator must use the approved setup procedure.

Policy And Case LifecycleCopy Anchor Link

• With no approved procedure policy, create a case. Detail shows incomplete setup, not ready.
• Attempt OT start and discharge completion. Both fail with current readiness blockers and preserve case state.
• Publish an externally approved synthetic policy. A new case binds its version and starts without evidence.
• Publish a later version. Existing cases keep the earlier policy.
• Explicitly rebind a nonterminal case with a reason. Evidence resets and the clinical event retains both policy IDs.
• Attempt a downgrade or rebind of a completed case. It fails without changing care history.
• Confirm removed or mismatched requirement rows cannot clear a new policy.
• Remove a ready or blocked requirement in a later policy and rebind. It disappears from the current checklist; its earlier command history remains readable.

Evidence And OverridesCopy Anchor Link

• Record manual evidence with a reason. A review-required item does not clear yet.
• Review the current source with a reason. Required readiness updates in detail and the live list filter.
• Record blocked evidence and then a ready review. The item remains blocked.
• Replace reviewed evidence. Its earlier review no longer clears it.
• Open a review, replace evidence in another session, and refresh. The old form requires reopening or receives a version conflict.
• Cause a known version conflict without a page reload. Current evidence refetches, and reopening uses its new versions.
• Check exact freshness expiry. Detail, list filter, OT start, and completion agree on stale state.
• With explicit override and category authority, override an approved blocked state. Source remains blocked; the reason and lease are visible.
• Let the lease expire or replace the source. The override no longer clears readiness.
• Try override as an owner with no explicit grant. It is denied.
• Try missing, stale, unavailable, or unstarted evidence, or an Inventory requirement. Clinical override cannot clear it.
• Confirm optional missing items warn without clearing a required blocker.
• Confirm Lab, pharmacy, and stock are not ready from a manual claim. Their source integrations remain pending.

Retry, Audit, And IsolationCopy Anchor Link

• Submit twice with the same key and body. One command and clinical event exist; retry returns the original result.
• Change the body under the same key. It conflicts without a second effect.
• Simulate a lost response. Retry uses the same complete command and key; no extra effect occurs.
• Refresh after success. Historical retry evidence is not displayed as the current item state.
• Inspect the protected command-history GET route. It retains actor, reason, time, source revision, and original result.
• Rebind the case and read an earlier command. Its original policy ID and full rule snapshot have not changed.
• Inspect PHI access logs. A new command records an amendment; an unchanged retry records a view, not another amendment.
• Verify required activity-audit failure rolls back evidence, command history, and clinical event.
• Race evidence replacement and case completion. The case lock permits one coherent outcome, not stale clearance.
• Revoke membership or category permission. The next command fails without effects.
• Suspend the tenant. Authorized history remains readable; writes fail.
• Disable cases or the category module. Direct routes deny access as navigation does.
• Try another tenant, an unassigned facility, and a foreign case/item selector. No evidence or history is exposed.
• Run enforced-role RLS and concurrent-connection tests with zero skips.

UI And AcceptanceCopy Anchor Link

• Check desktop and narrow mobile widths. Fields, errors, buttons, and long reasons do not overlap.
• Confirm view-only users have no write actions and current server actions control available commands.
• Confirm reason is required and drafts remain after validation or version errors.
• Check case-context changes. A form from one case or facility cannot submit for another.
• Verify missing Lab, MAR, Inventory, TPA, and Billing workflows still show their true integration state.
• Attach whole-PR backend/frontend CI, review evidence, and staging QA results. Keep unrelated CI failures explicit.
• Keep the issue open with the QA label. QA closes it after acceptance.