Catalog / Healthcare & Clinical / HLTH-008

Hospital capacity: bed, OR & staff planning

Forecast admissions, length of stay and discharges, then optimise bed allocation, operating-room schedules and staff rosters for hospital operations teams.

Hospitals run close to capacity while demand is volatile: emergency arrivals, cancelled operations, delayed discharges and staff absences all collide. Forecasting models predict occupancy, length of stay and OR demand, and optimisation solvers turn these predictions into bed assignments, OR schedules and rosters. Typical benefits are fewer cancelled operations, less boarding in the emergency department and fairer, more predictable shifts. Humans keep all decisions; the tools propose.

Problem & value

  • Today: bed managers work with whiteboards, phone calls and morning huddles. OR schedules are built from surgeon-estimated durations in block plans; rosters are built in Excel or rule-based workforce software. Planning is reactive.
  • Pain points: emergency boarding when wards are full, idle OR time next to overruns and late cancellations, discharge waiting for transport or paperwork, and nursing shortages that make every absence a crisis. In Germany the Pflegepersonaluntergrenzen (minimum nurse staffing levels) and the Krankenhausreform add compliance pressure on staffing data.
  • AI value: earlier warning of surges (hours to days), better case-duration estimates than surgeon guesses, discharge-readiness prediction to unblock beds, and roster optimisation that respects rules and preferences. Vendors publish customer-reported results (for example increased OR utilisation or reduced boarding), but these are self-reported, depend strongly on the baseline and should be validated in your own pilot [1][2].

Variants

  • Bed and patient flow management: ward and ICU census forecasts, discharge prediction, transfer coordination, command-centre dashboards.
  • Emergency department demand: arrival forecasting and triage-queue load; combines with PRED-011.
  • OR and surgical scheduling: case-duration prediction, block-time release, sequencing, turnover reduction, PACU and ICU bed downstream constraints.
  • Staff rostering and float-pool planning: demand-driven shift planning, self-scheduling, short-notice gap filling.

How it works

  1. HIS/EHR + ADT feed (HL7 v2 / FHIR) + OR system + roster system
  2. data pipeline (cleaning, pseudonymisation, feature store)
  3. forecasting (census, arrivals, LOS, case duration, absences)
  4. optimisation / simulation (bed assignment, OR schedule, roster)
  5. planner UI with explanations, what-if and alerts
  6. human decision (bed manager, OR coordinator, ward lead, works council rules)
  7. feedback: actual vs. predicted, overrides logged
  • Forecasting: gradient-boosted trees and classical time-series models (ETS, ARIMA) are the strong baselines; pretrained time-series foundation models are increasingly used for zero-shot census and arrival forecasts. LOS and discharge models are tabular classifiers/regressors.
  • Optimisation: constraint programming and mixed-integer solvers handle rosters and OR sequencing (hard rules: labour law, qualifications; soft rules: preferences, fairness). Discrete-event simulation tests policies such as bed buffers before rollout.
  • LLMs: summarise the morning situation, extract discharge barriers from free-text notes, answer planners' questions in natural language over the dashboard, and translate shift-swap requests into structured constraints. They do not make the allocation decision.
  • Human-in-the-loop: every schedule or roster is a proposal; planners can override, and overrides are logged. Rosters require works-council (Betriebsrat/Personalrat) co-determination in Germany.

Data preparation

Planning needs admissions, discharges and transfers, bed occupancy, OR schedules and actual times, staff rosters, absences and seasonal patterns. These live in the HIS, the OR planning system, the roster tool and often in Excel sheets kept by wards.

Typical gaps: inconsistent ward and bed codes after reorganisations, missing actual start and end times for operations, planning data kept in spreadsheets, rosters in a different system than patient data, and undocumented rules (isolation, specialty restrictions).

Preparation steps: 1. Map the data sources and gaps to the planning questions (PREP-002). 2. Find the Excel shadow systems wards use (PREP-003). 3. Export history of at least two years through interfaces (PREP-005, DATA-003). 4. Restructure the spreadsheets into tidy tables (PREP-011). 5. Define the KPIs and terms (occupancy, turnover time) once (PREP-012). 6. Aggregate or pseudonymise to unit level; staff-level data needs separate approval (PREP-022).

Effort share: about 30 percent, mostly in cleaning time stamps and harmonising codes across systems. See GUIDE-003.

Implementation paths

Which path for whom

  • enterprise (hospital groups): Path B, because capacity planning is core to operations, must integrate with the HIS, OR system and staff scheduling, and forecasting on own data via cloud APIs or managed ML is more flexible than a fixed product; buy a product if the HIS vendor already offers a fitting module.
  • developer: Path C, because forecasting and optimisation run well on small hardware with open libraries and keep operational data in-house.
  • public (municipal and university hospitals): Path B on a sovereign EU or German cloud, because of procurement rules and the integration with own systems.

Path A — Buy

  • Patient flow / command centre: GE HealthCare Command Center, Philips capacity and flow offerings, Epic and Oracle Health embedded capacity modules, Dedalus and CompuGroup Medical (EU) hospital information system extensions, Qventus (inpatient/ED/OR flow), LeanTaaS iQueue (OR, inpatient beds, infusion) [1][2].
  • Rostering / workforce: Atoss, Dienstplan specialists such as P&I and Soloplan-class tools, Kronos/UKG, Quinyx, Nursing-specific tools in HIS suites; Atoss and P&I are EU vendors.
  • Choose A when: you want a clinically accepted workflow, vendor support and an integrated HIS connector. Check EU hosting, data processing agreement, HL7/FHIR connectors, model transparency, and what happens to your data for vendor model training.
  • Forecasting: managed time-series services in EU regions (Azure Machine Learning, Google Vertex AI Forecasting, Amazon SageMaker) or foundation models such as Chronos (Amazon) and TimesFM (Google) invoked in your tenant.
  • Optimisation: Google OR-Tools CP-SAT as a service on your cloud, or Timefold (Belgian company, open-source core) for rostering and scheduling [3][4].
  • LLM layer: an EU-hosted frontier or EU-provider model (for example Mistral) for summaries and note extraction; send only pseudonymised or minimal data.
  • Choose B when: you have a data/analytics team and need custom constraints, but no on-premise requirement.

Path C — Self-host (open source)

  • Forecasting: statsforecast, Prophet, LightGBM/XGBoost, Chronos, with MLflow for tracking [5].
  • Optimisation and simulation: OR-Tools, Timefold Solver, SimPy for discrete-event simulation.
  • Integration: FHIR server (HAPI FHIR) and HL7 interface engine (for example Mirth/NextGen Connect forks, Open Integration Engine), OMOP for research-grade history.
  • Hardware: HW1; classical models and solvers run on CPU. A small open LLM for summaries fits HW2.

Path D — Custom training

Hospital-specific LOS, no-show and case-duration models trained on your own history usually beat generic models, because case mix, coding and processes differ. Needs two to five years of ADT and OR data with clean timestamps. Multi-site learning is possible via federated approaches, but is rare in practice.

State of the art (2026)

  • Forecasting: gradient boosting and hierarchical time-series methods remain hard to beat for census; foundation models (Chronos, TimesFM) give competitive zero-shot results on short series and are a cheap starting point. Probabilistic forecasts (intervals, not point values) are what planners need.
  • OR scheduling: ML duration prediction using procedure, surgeon and patient features outperforms booked durations in many published studies, but gains in utilisation depend on whether the block policy also changes.
  • Discharge prediction: models using vitals, orders and nursing notes support daily discharge huddles; precision is limited by non-clinical barriers (transport, social care, nursing-home beds) that are not in the data.
  • Limits and failure modes: distribution shift after reorganisations or pandemics, feedback loops (a prediction changes behaviour that changes the outcome), biased predictions if LOS correlates with socioeconomic factors, unrealistic rosters if soft rules are not captured, and alert fatigue. Dashboards without process change deliver little.

Shared resources & combinations

  • Same stack (tabular-ml, time-series, optimization-solver): PRED-011 workload and staffing demand forecasting, PRED-001 demand forecasting, and the logistics scheduling cases share solvers and MLOps.
  • Upstream/downstream: HLTH-012 (deterioration scores drive ICU transfers), HLTH-020 (readmission and population risk), HLTH-031 (epidemic surge signals), HLTH-005 (coding data for case-mix and LOS benchmarks).
  • Workflow: AGENT-002 back-office automation and AGENT-012 scheduling agents for shift-swap and notification handling.

Effort, cost & KPIs

  • Path A: months for integration and change management; licensing is typically per bed or per site and is not publicly listed.
  • Path B/C: 6–12 months for a first production use case (for example ED arrival and ward census forecasting), then incremental modules. Costs are dominated by data engineering, clinical-operations time and change management rather than compute.
  • KPIs: forecast error (MAPE/WAPE, interval coverage) per ward, ED boarding hours, OR utilisation and first-case on-time starts, same-day cancellation rate, overtime hours, unfilled shifts, discharge before noon, average LOS, staff satisfaction, share of AI proposals accepted vs. overridden.

People & change

Involve management and the nursing and medical directors, ward and OR managers as process owners, bed management and planners as daily users, IT for HIS and roster interfaces, the data owners of each system, HR for roster rules, and the data protection officer. Involve the works council from the start: planning staff and rosters is its core field.

Works council: yes. Roster optimisation and utilisation reports are suited to monitor staff behaviour or performance, which triggers co-determination under §87(1) no. 6 BetrVG, and working-time rules fall under §87(1) no. 2. §90(1) no. 3 requires early information, and an expert under §80(3) is considered necessary for AI. Public hospitals involve the staff council. A works agreement should limit use to capacity planning, exclude individual performance evaluation and define data deletion.

Data protection: patient data should be aggregated; if staff data is used, do a DPIA check (Art. 35 GDPR) with the DPO.

AI literacy (Art. 4 AI Act, supporting measures): explain forecasts and their uncertainty to planners. Start with one ward cluster or the OR schedule as a pilot, compare forecasts with reality for a quarter, and keep planners as the decision makers who can override any proposal. Typical concerns are loss of control over rosters and fairness; address them with transparent rules and the ability to correct.

See GUIDE-004, GUIDE-008 and GUIDE-009.

Risks, regulation & compliance

  • EU AI Act: depends. Pure capacity forecasting is typically minimal risk. However, Annex III point 4 (employment, workers management) covers AI that allocates tasks, monitors or evaluates workers based on individual behaviour or personal traits: a roster tool that assigns shifts by individual traits or monitors performance is likely high-risk. Annex III point 5 lists AI that evaluates eligibility for or prioritises access to essential public healthcare services and emergency patient triage: tools that prioritise patients for admission or surgery may fall under this. Medical-device software (MDR) is only relevant if the tool has a medical purpose. Assess each module separately [6].
  • GDPR: patient data is special-category data (Art. 9); staff data is employee data (in Germany §26 BDSG and works-council agreements). Use pseudonymisation, data minimisation (aggregates often suffice for census forecasts), a DPIA, and a processing agreement; check legal basis under national hospital laws (Landeskrankenhausgesetze, KHZG-funded projects). The European Health Data Space regulation shapes secondary use of health data [7][8].
  • Mitigations (Art. 5: no prohibited practice intended; avoid emotion inference on staff): human decision on every plan, audit log, drift monitoring, staff involvement in design.

Getting started

  1. Pick one measurable pain point (for example ED boarding or OR cancellations) and compute the baseline from ADT and OR timestamps.
  2. Audit data quality: timestamps for admission, discharge, incision and closure; define a pseudonymised extract and complete the DPIA.
  3. Build a simple baseline (seasonal naive plus gradient boosting) and compare with a pretrained time-series model; evaluate on a held-out year.
  4. Pilot a planner dashboard with one ward cluster and the bed managers; run it alongside the current process for a few weeks.
  5. Involve the works council early for any rostering function; define override logging and KPIs before go-live.

Sources

Note: live web search was unavailable when this file was written; sources are primary vendor, project and regulator pages from prior knowledge. Accessed 2026-10 (links to be re-verified). 1. LeanTaaS iQueue — https://leantaas.com 2. Qventus — https://qventus.com 3. Google OR-Tools — https://developers.google.com/optimization 4. Timefold — https://timefold.ai 5. Chronos time-series foundation models — https://github.com/amazon-science/chronos-forecasting 6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj 7. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj 8. Regulation (EU) 2025/327 (European Health Data Space) — https://eur-lex.europa.eu/eli/reg/2025/327/oj