Hospital and Surgery Center

Product overviewCopy Anchor Link

Kulcare Hospital is one facility-operations app for Surgery Centers and small hospitals. The app has two operating presets:

• Surgery Center: an OT-first workflow for facilities with one or more operating theatres and day-care or short-stay beds. It focuses on surgical cases, scheduling, readiness, recovery, and internal consumption.
• Hospital 50: a broader hospital workflow for facilities with up to 50 beds. It adds ward and bed operations to the shared surgical workflows.

These presets use one app and one facility-operations foundation. They are not separate MFA apps. A facility selects its operating model in Hospital settings. Product availability remains controlled by the Admin app's feature flags. Role and permission management remains in the shell app.

Who uses itCopy Anchor Link

Actual access depends on the user's effective permissions and the facility's enabled modules.

Core workflowsCopy Anchor Link

Private document APIs are being added as a foundation for PDF-first Lab and local insurance work. U4 connects the PDF-first Lab screen in the candidate. Local insurance remains future work. Uploads remain disabled until private storage, scanning, retention/deletion, and actor policies are approved and verified. A clean malware scan is not clinical review or readiness clearance. See the document foundation guide for delivery limits.

Surgical case and OT workflowCopy Anchor Link

1. Find a patient, procedure, and surgeon.
2. Create a surgical case for the selected facility.
3. Review the case on the case list or OT Board.
4. Book or change a theatre slot. The system checks theatre overlap, turnaround time, surgeon overlap, and stale versions.
5. Move the case through its allowed lifecycle and review its timeline.

Theatre administrationCopy Anchor Link

Open Settings and find Theatres. Users with OT management permission can add or edit a theatre. Set its name, unique facility code, status, turnaround minutes, and equipment tags. Users with OT view permission can see the list without edit controls. General configuration permission does not grant OT management permission.

New bookings use active theatres. Maintenance and inactive status keep existing bookings and history; staff must review those bookings. Changing turnaround does not change existing slots. If another user changes a theatre first, the app keeps your draft and asks you to reload before saving. Reload replaces your draft with the saved values.

The theatre editor merged through PR 2642. Release and manual QA are still pending.

OT opening hours and scheduling policyCopy Anchor Link

In Settings, permitted configuration managers can select warning or blocking for surgeon overlaps. Warning requires confirmation and a reason; blocking cannot be bypassed with that confirmation.

OT managers can edit weekly opening hours and dated maintenance blocks in each theatre. Times use the facility timezone. New and rescheduled bookings must fit their full duration and turnaround. Hours are unrestricted until configured; an enabled restriction with no windows means closed all week.

Changes do not cancel existing bookings. The OT Board flags affected pending slots for coordinator review. Old turnaround snapshots remain unchanged. Stale edits need a reload before saving. These U14 controls require deployment and manual QA before operational acceptance.

Recovery and nursingCopy Anchor Link

The recovery surface tracks post-operative stays. The MAR surface records medication administrations against orders. These surfaces are present in the app, but their workflows are not yet connected to real Hospital HTTP endpoints.

Hospital 50 bed operationsCopy Anchor Link

The Hospital 50 preset adds a ward bed board for occupancy and movement. It is separate from the Surgery Center recovery board. The current bed-board UI uses mock data; admission, transfer, and discharge workflow integration remains future work.

Inventory and readinessCopy Anchor Link

Inventory connects case-linked internal stock use through the merged reusable Inventory ledger. Open Inventory from a case to retain case context. Add a requirement, reserve stock with an expiry, issue it to OT or ward, record actual use, and return only unused material. An actual use with no confirmed stock posting stays visible for reconciliation. Corrections retain the original history. Used material is not an unused return. The case-stock QA guide covers acceptance and failure recovery. This local implementation still needs review, release checks, and pilot acceptance. The U4 candidate adds a PDF-first Lab workqueue. Pharmacy remains a separate unfinished integration. Neither replaces a Lab or pharmacy system. See PDF-first Lab.

The current local readiness batch adds approved policy versions, manual evidence, separate review, and reasoned overrides with expiry. Case detail and live case-list filters use current source state. Missing policy, missing required evidence, or expired clearance prevents OT start and discharge. An override needs explicit clinical authority; an owner role alone does not grant it. Replacement evidence invalidates old review and override. Concurrent edits require current versions.

This is a configurable framework, not an approved clinical checklist. Clinical approval and the active-case handoff must precede release. U4 adds Lab PDF intake and review in the candidate; pharmacy sources remain pending. U10 separately adds case-stock links. See the readiness QA guide for the exact acceptance scope.

In HTTP mode, the eight unfinished workbench pages show a not-connected state. They do not load mock operational records. The dashboard uses the selected facility's local date for OT activity and marks recovery, MAR, and inventory metrics as Not live rather than zero.

Insurance and billingCopy Anchor Link

The TPA / insurance workqueue supports the intended progression from lightweight insurance capture toward a full exchange workflow. Full ABDM/HCX claims exchange is not yet implemented. Billing is a package-aware charge-capture workbench, not a full accounting, invoicing, payments, claims adjudication, or settlement product. Current Hospital pages use mock workflows.

Product boundariesCopy Anchor Link

• One shared Hospital app serves both presets.
• RBAC configuration is managed in the shell app.
• Feature flags are managed in the Admin app.
• Pharmacy scope is internal consumption. Retail sale and dispensing are out of scope.
• Lab and pharmacy source systems remain authoritative for their detailed workflows.
• Hospital operations must not inherit IPD Lite product or lifecycle limits. Reuse canonical clinical data only where its meaning and ownership match.
• Hospital API access must enforce tenant and facility scope. A facility ID in a route does not grant access.

Current implementation statusCopy Anchor Link

In Settings, Enabled means that the module belongs to the facility's module set. The separate API integration badge shows Connected, Partial, or Not connected. Connected covers implemented operations, not every planned feature, current service health, or clinical approval. Inventory consumption is connected; the dashboard is partial. Unfinished workbenches remain not connected. Explicit development mock mode shows Sample data for every module.

Saved presets and module restrictions apply to navigation and direct routes. The live app does not use the temporary mock preset switch. Theatre records set actual OT capacity. Bed counts and Pharmacy/TPA modes remain planning metadata. U4 adds a versioned PDF-first Lab mode; it does not enable an external Lab connector. See the workflow and settings audit.

“UI exists” does not mean the workflow is persisted or ready for production. See the QA guide, the developer guide, and the implementation backlog for current status and remaining work.

PDF-First LabCopy Anchor Link

The pilot Lab can use a separate system and provide PDF reports. No LIS or PACS is required. Select a case requirement, upload the PDF, and wait for the security scan. Link the exact report with its confirmed report time and a reason. A clean scan is not clinical clearance. An authorized reviewer must accept or reject the current linked evidence. Replacement, invalidation, or approved expiry removes the old clearance and can block OT entry. Unrelated clinical requirements must also be ready.

Queue-only access does not grant report access. Review and private history need Lab management authority. Use the shell for permission grants. Use Hospital settings for PDF-first mode. An unavailable scanner or unsupported Lab mode must not appear as a connected external service. Keep the original retry key after an uncertain result. Check history before a new write. See Lab QA for setup and recovery checks. The candidate is not approved for deployment or clinical use until D2/D3 are accepted.