Hospital and Surgery Center Implementation Backlog

PurposeCopy Anchor Link

This document tracks work needed to move the Hospital app from its current integrated foundation and surgical case workflow to production-ready facility operations. The master backend and API integration plan owns product scope and domain ownership. The workflow and settings gap-closure plan is the execution entry point for the remaining gaps, dependencies, and acceptance evidence. Its forward delivery sequence defines the approved journey-first order from the current merged foundation. The phase plans below retain their detailed workflow contracts and manual QA checklists.

The gap-closure plan has 20 local U-IDs, all 15 route mappings, and a settings-effect matrix. Its prerequisite register identifies the clinical, nursing, document-security, capacity, inventory, billing, and external-exchange decisions that block dependent implementation or release. Those U-IDs do not renumber master or phase units. Planning these gaps does not change the implementation states below.

Count a workflow as complete only when its backend contract and implementation, frontend HTTP adapter, authorization and facility isolation, audit behavior where required, automated tests, and manual QA are in place. A mock-backed screen is not an integrated workflow.

Delivery UpdateCopy Anchor Link

PR 2642 merged theatre administration, readiness commands/gates, the reusable Inventory source, case-stock integration, and truthful live-source states. Earlier "local/current worktree/not merged" descriptions in historical plans do not describe current merge status. Deployment and acceptance must use the release record, including its explicit Billing-only CI exception.

PR 2701 merged U14 effective OT scheduling settings into docs/new-schema-design as 3f6eca9ddb: versioned surgeon policy, weekly opening hours, maintenance blocks, backend enforcement, and review flags for existing bookings. See the developer contract and manual QA. This does not complete the missing clinical/source workbenches or grant pilot approval.

Approved Delivery OrderCopy Anchor Link

U3 private-document foundation is in PR 2746. It adds case-scoped private document APIs and typed transport, not the Lab/TPA workbenches. Uploads default off. Scanner-provider integration, approved retention/deletion behavior, D2 deployment verification, and manual acceptance remain open. Staging and production deployment remain blocked until the D2 storage/scanning gate is accepted. See Private Clinical Documents and its QA guide.

The next workflow has a focused U4 PDF-first Lab implementation plan. It covers the live workqueue, private report links, clinical review, replacement/freshness, readiness/OT enforcement, end-to-end tests, and manual QA at each unit boundary. U4 implementation and frontend API integration are complete locally in the same draft PR 2746. The candidate includes live queue/history APIs, immutable report links, source-safe clinical review and OT gates, PDF-first settings, typed UI, and retry recovery. See the developer contract and manual QA. Local API and authenticated Chrome journeys pass in both presets. The final scoped external follow-up completed with no findings. Do not mark U4 accepted until release QA is recorded. D2/D3 still govern deployment and clinical acceptance. See the release record for exact evidence, review limits, and remaining gates.

Build complete Surgery Center patient journeys before deeper Hospital 50 operations. Unit numbers below belong to the gap-closure plan; they are reference IDs, not a strict execution order. The existing unit contracts keep their file lists, tests, dependencies, and D1-D7 approval gates.

Three units progress with every applicable delivery, not as a final cleanup phase:

• U15 settings: connect each source mode to its actual capability, permissions, health, and backend behavior as that source ships.
• U18 dashboard: add a metric only when its source exists and its count, facility-local window, and access rules can be verified.
• U20 acceptance: add real-HTTP journey tests and manual QA at each delivery boundary. Final acceptance covers all 15 routes and all applicable settings.

The first combined clinical acceptance journey is case booking, reviewed Lab evidence, medication review, OT start, recovery, MAR, signed discharge, and stock reconciliation. MAR remains a day-one clinical release requirement, not a later enhancement. Clinical journey acceptance does not mean the whole product is complete: billing, reports, Hospital 50, external TPA, deployment, and owner approvals retain their own gates. Unsupported workflows must remain visibly unavailable; required missing sources must never become ready.

There are 14 remaining delivery units (U3-U8, U11-U13, U15-U19), plus U20 acceptance. U18 is already partial; U15/U18/U20 are delivered incrementally. The merged readiness framework, Inventory source/case-stock operations, and OT settings need release evidence, not replacement implementations.

Use the forward implementation plan and phase QA gates to select the next executable scope.

Current workflow statusCopy Anchor Link

See the workflow and settings audit for the full route/action inventory and the effect of each configuration setting. Capacity and integration planning fields do not activate live operations.

The completed case-and-OT plan is not completion of the full Hospital product. The master plan has ten implementation units. Its Units 1-3 cover the foundation, HTTP boundary, and case/OT workflow. Unit 10 isolates the remaining theatre administration UI; Units 4-9 cover the other workflows below. Unit numbers within individual phase plans are local to those documents. The phase plan documents are plans and QA contracts; their existence does not mean the work shipped.

The current QA seed creates four synthetic patients, procedures, cases, two theatres, and OT bookings. It does not create the other workflows. Seed visibility proves only that the case-and-OT records load; it does not prove that the Hospital workflow set is complete.

Screen auditCopy Anchor Link

This table covers every registered Hospital route. “Live” means that the route uses an implemented backend endpoint in non-mock mode. It does not mean that every panel on the route is integrated.

PR 2642 also prevents mock-only pages from calling unsupported live API operations. They show an explicit not-connected state instead of a mock permission or service error. The deployed commit and acceptance evidence must be checked separately.

ImplementedCopy Anchor Link

• Facility context, preset configuration, and the Hospital HTTP/query boundary.
• Surgical case create, read, lifecycle transitions, theatre schedule, and OT booking.
• Backend theatre list/create/update endpoints, merged Settings create/edit, an opaque version contract, and current theatre checks during booking writes.
• Hospital settings integration for supported context and configuration fields.
• Case and OT security, audit, and telemetry for the implemented case/OT resource group.

See the API reference and QA guide for current details.

Remaining implementationCopy Anchor Link

1. Theatre administrationCopy Anchor Link

• Release the current Settings editor, HTTP adapter, and conditional-update contract together. Older clients that omit the theatre version can no longer PATCH.
• Run the theatre QA checklist against the deployed build. Confirm persistence, two-tab stale edits, permissions, facility scope, audit, and booking safety.
• Do not mark this workflow complete until manual QA passes. Automated tests alone are not product acceptance.

2. Readiness integrations, Lab, pharmacy, and lightweight TPACopy Anchor Link

• Verify the U2 framework and manual QA checklist. Complete clinical approval D3 and the active-care handoff before deployment. Add integrated source writes, workqueues, and reconciliation next.
• Integrate Lab and pharmacy readiness with their owning systems. Do not make Hospital the source of detailed Lab or pharmacy records.
• Add lightweight insurance/TPA capture and review to the case workflow.
• Define retry, idempotency, failure, and stale-status behavior for inbound integration updates.
• Verify the implemented bounded override with category authority, explicit override grant, reason, revision, and lease. Do not treat a frontend control or owner role as clinical authority.

Plan: Readiness, integrations, and lightweight TPA.

3. Recovery, MAR, and clinical documentationCopy Anchor Link

• Persist recovery stays, assignments, observations, and recovery lifecycle events.
• Connect MAR to canonical medication orders and record administration, omission, and exceptions with the required clinical audit trail.
• Define the source of medication orders and the integration boundary with pharmacy.
• Audit and connect canonical peri-operative notes and discharge documentation. Resolve day-care documents without a ward admission, preserve signed versions, and enforce documentation clearance before discharge.
• Add facility-scoped authorization, conflict handling, tests, and manual QA for nursing workflows.

Plan: Recovery and MAR.

4. Internal inventory consumptionCopy Anchor Link

The six-unit reusable Inventory source and U10 case-stock consumer merged through PR 2642. Source review, CI, deployment, approved pilot counts/expiry rules, and operator acceptance remain distinct gates. Use Inventory Pilot Operations and all six unit QA guides. The Hospital API handoff checklist records implementation and acceptance separately.

• The scoped U10 review loop is complete. Complete the case-stock QA checklist.
• Verify source pilot approvals, full PR CI, deployment, and acceptance.
• Keep MAR mapping, pharmacy readiness, charge posting, and dashboard metrics in their own units.

Plan: Recovery, MAR, and inventory.

5. Hospital 50 bed workflows and IPD Lite coexistenceCopy Anchor Link

• Implement admissions, bed assignment, transfers, discharge, and bed cleaning/availability transitions for the Hospital 50 preset.
• Keep general ward beds distinct from short-stay and post-operative recovery capacity.
• Define how existing IPD Lite records coexist or migrate. Reuse canonical clinical records only where the domain meaning matches; do not make Hospital operations depend on IPD Lite limits or deprecated backend modules.
• Validate capacity and concurrency behavior, including facilities configured for up to 50 beds.

Plan: Hospital 50 beds and IPD coexistence.

6. Package billing, charge capture, and full TPA exchangeCopy Anchor Link

• Implement package selection, case-linked charge capture, review, and posting through the billing domain, with duplicate and cancellation safeguards.
• Extend lightweight insurance capture into the agreed full TPA workflow. Define ABDM/HCX API ownership, exchange states, callbacks, retries, correlation, and failure handling before implementation.
• Keep accounting, payment settlement, and claims adjudication outside this scope unless separately approved.
• Test posting permissions, auditability, idempotency, and reconciliation with case and package state.

Plan: Package billing and ABDM/TPA.

7. Dashboards, reports, and pilot cutoverCopy Anchor Link

• Replace mock dashboard and report data with authorized, facility-scoped queries.
• Define report filters, time boundaries, export access, and protection of sensitive data.
• Add operational observability for integration failures, stale readiness, queue delays, and failed writes.
• Complete pilot/UAT workflows, support procedures, production configuration, and rollback/cutover checks.
• Verify that production has no silent mock fallback and that each enabled workflow has passed its manual QA checklist.

Plan: Reports and pilot cutover.

Cross-cutting release gatesCopy Anchor Link

• Every new read and write must enforce tenant and facility access on the backend. Route IDs and frontend query scopes are not authorization. Add enforced-role RLS tests for new data paths.
• Each protected action must use the effective RBAC permission catalog and a real backend policy. Add key-behavior tests so each seeded permission changes an actual policy decision.
• Add audit events for clinical, operational, inventory, configuration, and billing changes according to the owning domain's audit contract.
• Keep frontend calls behind hospitalApi; add typed DTOs, query keys, cache invalidation, and HTTP adapter tests for each integrated resource.
• Keep mock behavior explicit to development and tests. A missing production endpoint must fail visibly.
• Complete the phase manual QA checklist and record its result before marking that phase complete.

Not part of this backlogCopy Anchor Link

• Role and permission administration UI, which belongs to the shell app.
• Feature-flag administration UI, which belongs to the Admin app.
• Retail pharmacy, dispensing, or a second inventory ledger.
• General staff scheduling, payroll, or HR management.
• Full hospital accounting, payment settlement, or claims adjudication.

Plan indexCopy Anchor Link

• Workflow and settings gap-closure execution plan
• Master backend and frontend API integration plan
• Foundation, security, and API adapter
• Surgical case and OT
• Readiness, integrations, and lightweight TPA
• Recovery, MAR, and inventory
• Hospital 50 beds and IPD coexistence
• Package billing and ABDM/TPA
• Reports and pilot cutover