Kulcare Docs

Hospital OT Settings QA

Manual acceptance for opening hours, maintenance, surgeon conflicts, and concurrent settings.

Setup

Use an isolated synthetic facility with real HTTP mode, an active surgeon role, two active theatres, and two planned cases for that surgeon. Use approved QA accounts. Record deployed commit, facility timezone, actor/permissions, and results. Do not use real patient information in evidence. No new migration is required. Keep issue 2517 open for QA.

Policy

  • Open Settings as a permitted configuration manager. Change surgeon policy to blocking, save, and reload. Confirm the saved value persists.
  • Book overlapping cases for one surgeon in separate theatres. Blocking rejects the second write, including a request with warning confirmation and a reason.
  • Change to warning. Confirm the same overlap needs explicit confirmation and a reason. The saved booking and audit evidence retain that reason.
  • Save general facility settings, then change policy. The policy save uses the new version without an unnecessary stale error. A background refetch keeps an unsaved policy draft; stale drafts still need explicit reload before saving.
  • Use a view-only configuration actor. The policy control is disabled and a direct write is denied. A theatre manager without configuration authority cannot change the surgeon policy.

Opening Hours And Maintenance

  • Edit an active theatre. Add Monday 09:00-17:00, save, and reload.
  • Book a case inside Monday hours. Confirm its turnaround also fits.
  • Attempt a case before opening or with turnaround after closing. Both writes fail without partial booking or case/event updates.
  • Book across two adjacent opening windows. The combined opening permits it.
  • Test an unlisted weekday. It is closed. Remove all windows while restriction remains on: the whole week is closed. Turn restriction off: hours are unrestricted.
  • Add Friday 22:00-02:00. A Saturday 00:30 case uses Friday's opening. Test an exact closing boundary and end 24:00 for a full-day window.
  • Add maintenance from 23:00 to next-day 01:00. Test overlap, turnaround overlap, and both touching boundaries. Only true overlap is blocked.
  • Submit malformed clocks, reversed maintenance, absent offset, and missing reason through the API. They fail validation and leave saved rules/version intact.
  • In a DST test facility, check repeated and nonexistent weekly boundaries. Maintenance retains explicit instants; a nonexistent local input is not shifted.

Existing Care And Concurrent Edits

  • Create a booking, then change theatre hours or maintenance around it. Reload the OT Board: the slot remains and has a review label. No cancellation occurs.
  • Change current turnaround. An existing booking keeps its original buffer. A new booking snapshots the new buffer.
  • Mark a theatre inactive/maintenance. Existing pending bookings are reviewable; new/restored active bookings are rejected. Cancel/postpone still works.
  • Open policy and theatre editors in two tabs. Save in one, then save stale input in the other. Confirm STALE_WRITE, retained input, and explicit reload.
  • Race a policy/window edit with booking. The serialized order determines the result. Earlier bookings remain visible; later writes follow the committed rule.
  • Switch facilities/profiles while editing. Old inputs and protected caches do not become writes in the new scope. Foreign tenant/facility IDs are denied.
  • Confirm successful settings/theatre writes and booking events have audit evidence. Invalid/denied/stale writes do not appear as successful changes.

UI And Evidence

  • Test keyboard labels, add/remove rows, save, errors, and reload controls.
  • Check desktop and narrow mobile widths for clipping or horizontal overflow.
  • Confirm theatre name/code share one desktop row and stack on mobile. Settings uses the shared UI-kit selects, checkbox, calendar, and time controls.
  • Open a maintenance calendar or time picker inside the theatre form. It must not submit the form. A required date/time must have both parts before saving.
  • Open the OT booking editor. Check the shared case, theatre, and status selects, calendar, and clock. Partial time, 24:00, and invalid minutes must disable Save. Choosing a time must not submit the booking.
  • Enter exact minutes and end 24:00. Check keyboard selection and that 24:01 is invalid. A disabled editor must not allow changes through a picker popover.
  • Open a reviewable slot from the board. The conflict explanation matches the API and the booking remains editable when its lifecycle permits.
  • Attach synthetic evidence and actual results to the PR/issue. Record failures and owners. Do not infer clinical approval from operational scheduling tests.

Reference: developer contract.

Local UI Review Evidence

Chrome DevTools MCP checked the UI-control follow-up against 8918617c18 plus the scoped working changes. The app ran at 127.0.0.1:3006 in explicit mock mode. The checks used synthetic cases and made no staging or patient-data writes.

RouteResultEvidence
/hsp/settingsPass, mock modeTheatre name/code share a row at 1440px and stack at 390px. No editor overflow. Shared calendar, clock, checkbox, and select controls work. Maintenance saves and reopens with the selected local date/time. The policy select saves Blocking.
/hsp/ot-boardPass, mock modeSaved maintenance adds a review flag without removing the booking. Partial clock text disables Save. An out-of-hours edit is rejected. A valid edit saves and updates the board. Keyboard hour selection changes the clock without submitting. The 390px booking editor has no horizontal overflow or native pickers.
Live HTTP-mode acceptanceSkipThis run uses the standalone mock app. Deploy the candidate and run the authenticated checklist above to verify real API, RLS, stale-write races, and audit behavior.

The final browser console check found no warnings or errors. No XHR/fetch requests appeared in that mock run. These results do not prove API integration or replace the manual acceptance and clinical approval checkboxes.

The follow-up passes 206 Hospital tests in 28 files. Canonical frontend CI passes with no lint errors or test failures and 252 existing TypeScript diagnostics under the 254 ceiling. Hospital's standalone typecheck is clean. Existing shell diagnostics include imports through Hospital facilityOptions.ts; they are not new control errors. No baseline, dependency, lockfile, backend, or schema change is part of this UI follow-up.

On this page