Hospital and Surgery Center QA Guide

Use this checklist for a manual review of the Hospital app. Record the build or commit, environment, facility, preset, user role, and result for each run. Do not use real patient information in a development or test environment unless the environment is approved for it.

Test setupCopy Anchor Link

• Confirm the Hospital app is enabled for the test tenant through the Admin app.
• Confirm the test user has Hospital access and the needed operation permissions through shell RBAC.
• Select a test facility with multiple theatres for the Surgery Center checks.
• Select a test facility with wards and beds for Hospital 50 checks.
• Confirm the selected tenant, profile, and facility in the shell before testing.
• Confirm whether the app is in explicit development mock mode or connected to the backend. Record this in the test result.
• Use test cases, patients, and dates that can be safely changed.
• Open the browser console and network panel. Watch for failed requests and client errors.

App access and shell behaviorCopy Anchor Link

• Open the Hospital app from the platform dashboard after login.
• Confirm a user without Hospital access cannot open the app by entering /hsp directly.
• Confirm the current facility name is shown in the shell.
• Switch to another facility and confirm Hospital requests and data use the new facility scope.
• Switch profile or tenant, where available, and confirm old Hospital data does not remain visible.
• Confirm role and permission changes are made in the shell app, not in Hospital settings.
• Confirm feature flag changes are made in the Admin app, not in Hospital settings.

Facility settings and presetsCopy Anchor Link

• Open /hsp/settings and wait for the saved facility settings to load.
• With a user that has view-only access, confirm all capacity and integration controls are disabled and the page states that access is view-only.
• Confirm loading, error, and retry states behave correctly when the API is delayed or unavailable.
• Confirm the screen shows the saved preset, capacity, operating services, and enabled modules.
• Check each enabled module's separate availability and API integration badges. In HTTP mode, OT scheduling, cases, Inventory consumption, and Configuration show Connected. The dashboard shows Partial. Bed, Recovery, MAR, Lab, Pharmacy, TPA, Billing, and Reports show Not connected. No module shows Mock or Sample data.
• In explicit mock mode, every enabled module shows Sample data, including OT, Recovery, MAR, and Inventory. No badge claims a live connection.
• Check both presets and a restricted module set. Disabled modules do not appear in the list. Check labels and badges at desktop and mobile widths.
• Delay or fail the facility configuration read. The module list shows loading or unavailable, not preset defaults with Enabled badges. Retry restores the list.
• In HTTP mode, change the preset to Hospital. Confirm capacity and integration planning values do not reset. Confirm the full default module set follows the new preset, while a custom restricted set remains restricted.
• In HTTP mode, confirm capacity and Lab/Pharmacy/TPA planning controls are disabled. Confirm the OT count comes from real theatre records, not a stored planning count. An unavailable theatre list must not show zero.
• In explicit mock mode only, change capacity or integration fields and confirm the preview updates. Do not treat this as bed provisioning or integration activation.
• Save settings. Confirm the save state is visible and the Save button returns to its unchanged state.
• Reload the page. Confirm the saved settings are loaded from the facility configuration API.
• Confirm a user without manage_hospital_configuration cannot save changes.
• Confirm settings cannot enable an app or module that the Admin-owned feature flag disables.
• Confirm changing the preset updates the shell navigation and sends the user to a valid route.
• Save a custom enabled-module list through the configuration API. Confirm disabled modules disappear from navigation and direct routes do not fetch their data. Confirm direct case/OT API reads and writes reject disabled modules. Restore the test configuration after this check.
• Save an enabled canonical default route. Open /hsp and an unknown route; confirm both use it. Disable that module and confirm fallback to the first enabled module without a redirect loop.
• Confirm the HTTP layout has no temporary preset switch and ignores local mock preset storage. Switch facilities and confirm the new saved preset applies.
• Suspend the test practice. Confirm configuration, theatre, case and booking write controls are absent or disabled. Confirm direct writes remain denied by the backend.

Surgical casesCopy Anchor Link

• Open the case list. Confirm cases are limited to the selected facility.
• Search for a test patient and select a canonical patient result.
• Search for and select an active procedure and surgeon.
• Create a case with valid values. Confirm the server response appears in the case list and case detail.
• Try to submit without required fields. Confirm validation errors identify the fields.
• Open a case detail and confirm the case, status, schedule, and timeline match the server response.
• Move a case through valid lifecycle actions. Confirm each successful change refreshes affected views.
• Attempt an invalid transition or stale-version update. Confirm the app shows a recoverable error and does not discard relevant user context.
• Confirm PHI is not included in URLs, error messages, or operational telemetry.

OT Board and bookingsCopy Anchor Link

• Open the OT Board and select a date in the facility timezone.
• Open the Surgery Center dashboard. Confirm it uses the current facility-local date and shows cases seeded for that date.
• Confirm the schedule shows theatres, bookings, and related cases for the selected facility.
• Create a booking for an unscheduled case and active theatre.
• Reschedule a booking and confirm the new time and theatre persist after refresh.
• Try a same-theatre overlap and confirm a blocking conflict is shown.
• Try a turnaround-buffer conflict and confirm the configured rule is applied.
• Try a surgeon overlap and confirm the facility policy is applied, including an explicit confirmation when the conflict is warning-only.
• Attempt to save a stale booking. Confirm the server conflict is shown and the UI does not silently overwrite newer data.
• Postpone or cancel a booking and confirm it no longer appears as an active scheduled case.
• Confirm an inactive theatre cannot receive a new or restored active booking.
• Confirm schedule state remains correct after switching facility and returning to the OT Board.

Theatre configurationCopy Anchor Link

• Record the commit and confirm the versioned theatre editor is deployed. Local mock checks do not prove staging persistence.
• Confirm the theatre list shows only theatres for the selected facility.
• With view_ot_schedule and manage_ot_schedule, add a theatre with a unique code, status, turnaround, and equipment tags. Confirm it appears in the list and active booking selectors.
• Reload the browser and confirm the theatre persists through the HTTP API.
• Edit the name, code, equipment, and turnaround. Confirm settings, the OT Board, and case booking selectors refresh.
• With OT view permission only, confirm Add and Edit are absent. Send direct POST and PATCH requests and confirm 403 with no mutation.
• Confirm manage_hospital_configuration alone does not grant theatre writes. Confirm OT editors do not need case management permission to edit theatres.
• Submit a duplicate code or invalid turnaround through the API. Confirm 422, a field error, no audit success, and unchanged values/version. In the UI, confirm failed input remains in the form.
• Open one theatre in two tabs. Save in the first tab, then save the older draft in the second. Confirm 409 STALE_WRITE and that the older draft remains visible. Select Reload theatre and confirm the new saved values replace the draft.
• Send PATCH without theatre.version. Confirm 409 and no change. Copy the opaque version from a fresh GET before retrying.
• Mark a booked theatre as Maintenance. Confirm existing slots and history remain, and that it is absent from eligible new-booking selectors. Confirm direct new/restored active bookings return 422.
• Confirm postponement and cancellation remain available for an unavailable theatre. Return it to Active and confirm eligibility returns.
• Change turnaround after a booking exists. Confirm the existing booking keeps its snapshot and a new booking uses the new value.
• Switch facility with an editor open. Confirm the editor closes and a delayed response does not populate the new facility. Attempt a cross-facility PATCH and confirm 404 or access denial without a mutation.
• Check successful create/update activity audit rows for actor, tenant, facility, resource type, and resource ID. Confirm stale and denied writes do not log successful changes.
• Test a failed theatre-list request and Retry. Test the editor at desktop and mobile widths with keyboard navigation and a long theatre name.

Copy these checkboxes to the tracked issue or PR for Unit 10. Record each result there. Automated coverage is in theatre-administration.test.tsx, theatre-permissions.test.tsx, theatre-mock-validation.test.ts, hospital-http-api.test.ts, and the Hospital theatre request/policy and OT booking service tests. The checklist is not a completed QA record.

Recovery, MAR, bed board, inventory, readiness, TPA, billing, and reportsCopy Anchor Link

Recovery, MAR, the Bed Board, TPA, Billing, and Reports use mock workflows. Test their presentation only in explicit mock mode. Readiness commands and the case-stock workbench use the backend in HTTP mode. Do not record a mock success as proof of backend persistence.

Case readiness is included in the backend case-detail response. Review, approved overrides, and transition gates are implemented locally. Lab and Pharmacy source operations are not connected. Use controlled test records and the readiness QA checklist for command acceptance.

• Confirm an empty readiness list shows Not started, not Ready.

• Confirm a fresh, ready source displays Ready.

• Confirm stale source data and expired fresh_until values do not display Ready.

• Confirm an unstarted source stays Not started even if its freshness date has passed.

• Confirm unavailable source data displays Blocked, not Ready.

• Confirm a blocked or warning source cannot become Ready from a conflicting stored effective state. Test supported overrides under the approved readiness policy. Inventory-derived readiness cannot use a manual override.

• Confirm readiness items belong to the selected case and facility. Verify another tenant cannot read them.

• Confirm malformed readiness IDs, required flags, categories, and source types are ignored without breaking case detail. Unknown state values must fall back to Not started, not Ready.

• Confirm a role without view_surgical_cases cannot read case readiness. Verify the successful case PHI audit includes surgical_case_readiness without result content in metadata.

• Open Recovery and check its empty, occupied, and status presentation.

• Open MAR and inspect due, administered, and withheld states. Do not treat mock medication actions as clinical records.

• Open the Hospital 50 Bed Board and inspect occupancy and movement controls.

• In HTTP mode, confirm the Bed Board says live ward data is not connected. Do not treat a mock-only board as a live permission failure.

• Run the live case-stock QA checklist. Check source quantities, holds, actual use, unused returns, reconciliation, case context, and retry recovery. Do not substitute mock presentation checks.

• Open Lab Readiness and Pharmacy Readiness and inspect status and review controls.

• Open TPA / Insurance and inspect capture status and workqueue states. Do not claim ABDM/HCX exchange is exercised.

• Open Billing and Reports and inspect workbench states. Do not claim financial posting or report export is exercised.

• Confirm mock actions do not appear as persisted backend records after a fresh session.

Live-mode regression checksCopy Anchor Link

• Open each direct route: /hsp/bed-board, /hsp/recovery, /hsp/mar, /hsp/lab-readiness, /hsp/pharmacy-readiness, /hsp/tpa, /hsp/billing, and /hsp/reports. Confirm the not-connected state and no mock permissions/workqueue request. Navigation must remain available.
• Open /hsp/inventory in HTTP mode. Confirm protected case-stock requests, real empty/error states, and authorized stock actions. Do not expect a not-connected placeholder.
• Open the dashboard on the current facility-local day. Confirm its OT schedule matches the OT Board for that day.
• Fail the schedule request. Confirm the dashboard says Unavailable and does not claim zero cases or zero current OT activity.
• Confirm recovery and MAR show Not live in HTTP mode. Do not interpret these labels as empty operational records. The dashboard may report unavailable stock summary data even when the case-stock workbench is connected.
• Open case detail. Confirm ward, recovery, MAR, package and TPA panels say Not live. Confirm the inventory panel opens the live workbench with case context. Confirm no placeholder zero amount or invented insurance capture status appears.
• Confirm live workflow controls show case status and enforce the approved readiness gates. Do not infer Ready from absent mock blockers. Confirm no mock/UAT completion message appears.
• Deploy the readiness migration before the backend that reads it. In an isolated test database, verify rollback/reapply, scoped foreign keys, unique requirement keys, and enabled/forced RLS.

Automated route regression coverage is in live-workflow-states.test.tsx. Readiness model, request, and enforced-role RLS tests cover the backend read boundary. These checks do not prove that Lab, Pharmacy, or TPA source operations are implemented. Use the separate readiness and case-stock checklists for their live boundaries.

Permission and RLS checksCopy Anchor Link

• Use a read-only role. Confirm controls for restricted writes are hidden or disabled and direct API writes return forbidden.
• Use a role with case permission but without OT management. Confirm case access does not grant OT mutations.
• Use a role with configuration view but without configuration management. Confirm the page is read-only.
• Use a user without membership in the selected facility. Confirm no Hospital resource data is disclosed.
• Attempt to use another tenant's facility selector. Confirm access is denied without revealing resource existence.
• Confirm tenant and facility scope is enforced by the authenticated request context and backend RLS. A frontend filter alone is not sufficient evidence.
• Confirm denied actions do not create successful audit events or mutate data.

Responsive and error checksCopy Anchor Link

• Check the OT Board and case detail at desktop and mobile widths.
• Check settings, bed board, and workqueues at mobile width. Confirm controls do not overlap or require horizontal page scrolling.
• Simulate an API timeout, 403, 404, 409, 422, and 5xx response where the test environment allows it.
• Confirm errors use a clear message and a useful retry path where retry is safe.
• Confirm a failed write does not display a false success state.
• Confirm there are no uncaught console errors, duplicate route segments, or failed asset requests.

Exit recordCopy Anchor Link

• Attach screenshots for key desktop and mobile flows.
• List each failed check with the route, role, facility, request ID, and reproduction steps. Exclude patient-identifying data.
• Mark mock-only workflow checks as UI checks, not integration acceptance.
• Re-run focused Hospital frontend tests and backend Hospital tests for any fix.
• Get clinical and operations sign-off before using the app for live care.

Related: Product guide · Developer guide · Hospital API contract