Development of an AI System for Hospital Occupancy Forecasting

Hospital load forecasting: where the current calculation breaks down

An admission plan is most often built on average values from past periods: bed occupancy for a month or quarter is taken and carried over to the next interval. Such a calculation holds as long as the flow is homogeneous.

As soon as the structure of admissions changes — planned admissions shift, a wave of emergency cases arrives — the average stops describing reality, and the gap between plan and actual grows.

The second failure point is delayed data extracts. Data comes from different subsystems at different frequencies: the admission department records an admission at the moment of registration, while bed movements and discharges appear in reporting later, sometimes once a day.

A calculation built on such a snapshot sees yesterday’s picture and does not react to today’s surge.

Seasonality of admissions is usually not taken into account at all. Respiratory waves, the vacation decline in planned admissions, holiday periods produce a recurring profile by weeks and months, but within the period average it is blurred.

A separate problem is planned flows: known in advance volumes of surgeries and admissions are not fed into the input as a separate signal, although they determine how many beds will remain for emergency admissions.

Overall, the result is a forecast that diverges from actuals the more the load rises — that is, exactly when the decision to redistribute beds is critical.

We break down how this is addressed: where data comes from, what goes into the calculation input, and how hospital load forecasting is built that can be trusted during a peak-load shift.

Regular patient flow forecasting: measurable effect

Regular calculation changes the very logic of work: the forecast for each department is recalculated nightly, and when new data arrives — off-cycle, so decisions are made not based on actual bed occupancy, but several days before the peak.

Data is pulled from the records system according to the industry exchange standard HL7 FHIR, without manual extracts and “coordination in messengers.”

• Denials of planned admissions. A 7–14 day forecast shows overload in advance — the admission date is moved before the patient arrives, not on the day of registration. The most expensive class of denials leaves the flow: those that damage reputation and require rebooking.
• Department occupancy. An imbalance between departments is visible 3–5 days before the peak, and there is time to transfer profile-specific patients and redistribute bed capacity. The spread in occupancy between departments shrinks, and emergency “shifts at the limit” become the exception.
• Shift reallocation. A flow forecast by day of week and admission department hours gives grounds to add reinforcement for a specific interval rather than keep full staffing “just in case.” Shifts are planned for expected load, and overtime moves into a controlled mode.
• Planning horizon. Three rhythms: daily — operational response, weekly — shifts, monthly — consumables, medications, and planned volumes. Each horizon is covered by its own forecast slice, not one shared number.
• Denial class. We separately count how many denials were converted into a planned reschedule. That is the measurable effect: a shift from an uncontrollable class to a controllable one, not just “things got calmer.”

The effect holds only with accuracy control: we calculate the deviation of actuals from the forecast for each department; when it sustainably exceeds the threshold, the model is retrained on fresh data. A one-off forecast solves nothing — a regular feedback loop works.

Approaches to the calculation model: rules, statistics, learning from data

A calculation model is not only an algorithm, but also what data goes into it, with what horizon it is updated, and how it is validated.

We maintain several interchangeable options of the same tier and choose for the task: in some cases rules and seasonal coefficients are enough, in others a statistical model is needed, and in others — learning from data with validation on retrospective slices.

There is one criterion: the option must outperform a simple rule on your history, not on demonstration data. If there is no gain, the rule goes into the calculation; it is more transparent.

Options and their applicability boundaries

In practice, a hybrid most often works: rules set the boundaries and cut off impossible values, learning from data refines the forecast within those boundaries, and seasonal coefficients smooth known peaks.

Implementation stages: from data audit to model handover

The order of the stages is not accidental: until the completeness of data extracts is verified, any forecast quality metric means nothing. We work according to the industry project organization standard CRISP-DM — with fixed readiness criteria at each step.

1. Source audit. We analyze extracts from the admission department, planned admissions, and bed capacity: gaps, duplicates, changes in accounting rules. The output is a data map and a list of places where assumptions cannot be avoided.
2. Feature schema. From raw events we assemble what actually explains load: day of week and seasonality, department profile, share of emergency admissions, waiting lists, epidemic waves.
3. Calculation setup. We fix the horizon — daily, three days, weekly — and the definition of overflow. The model returns not a single number, but an interval and a threshold at which an alert triggers.
4. Validation on historical periods. We run the calculation over past intervals, including holidays and disease surges. We look at deviation in bed occupancy and the share of hits within the interval.
5. Model acceptance. We agree on criteria in advance: accuracy on control periods, robustness to outliers, a clear reason for rejecting the forecast. The previous version remains for rollback.
6. Solution handover. We deploy the calculation on your side, hand over documentation and the retraining procedure, and walk through the code with your team. After that, your engineers maintain the model.

Data schemas, retraining procedure, quality control

Load forecasting lives not inside the model, but in the documents that remain with the hospital team. Six months later, patient routing changes or a new analyst arrives — the system can be raised, checked, and retrained only from this set. That is why we hand over not a “black box” but a set of artifacts.

• Data schema: sources (admission department, planned scheduling, admission history, transfers between departments), extract frequency, typical arrival delays, and the person responsible for each flow.
• Feature description: what goes into the input — department profile and capacity, day of week and seasonality, age group, average length of stay, volume of planned admissions; for each feature, the source, type, and missing-value behavior are specified.
• Preparation rules: how cancellations, readmissions, and incomplete slices are handled so the forecast does not diverge at shift handovers and during holiday periods.
• Retraining procedure: triggers (change in patient flow, new department profile, scheduled frequency), control period length, who launches it and who confirms the result.
• Forecast quality control: metrics for each department and horizon, suitability thresholds, and alerts when the error exceeds them.
• Discrepancy review procedure: reconciliation of actuals with the forecast by intervals, classification of causes (routing change, quarantine, disease outbreak), logging to the journal.
• Version log and rollback: which version ran in which period and was trained on what data, how to return to the previous one without losing accumulated history.

Case study: the gap between plan and actual decreased threefold

A multidisciplinary hospital with a flow of planned and emergency admissions planned load using averages from the previous period: departments consolidated figures manually once a week.

On a seven-day horizon, the error reached a quarter of beds — some beds stood idle, some shifts were covered with overtime, and planned admissions were rescheduled on the day of admission.

The planning loop was rebuilt: the model receives several years of admission and surgery history, the calendar of planned interventions, ARVI seasonality, days of the week and holidays, and fresh emergency admissions.

We calculate the forecast for each department 1, 7, and 14 days ahead; the core is a tree ensemble Gradient boosting with confidence intervals, so the planner sees not a single number but a range and the probability of exceeding it. Recalculation runs daily and off-cycle when actuals deviate from the forecast.

After three months of operation, the bed load forecast error on a weekly horizon decreased from 23% to 7%, and the gap between plan and actual fell threefold.

The share of unplanned bed idle time dropped by about half, and denials of planned admissions due to lack of space almost disappeared from reporting. Medical staff shifts are scheduled against the forecast, not actuals: overtime decreased by a quarter.

The decision remains with the human: the model shows where there is a risk of exceeding the range, the head of the department adjusts the plan, and the system recalculates the forecast taking the adjustment into account.

What if data is collected manually and with a delay?

A forecast can also be built on delayed data — the question is not completeness but the predictability of the delay. If the extract arrives every morning at the same time, the model is trained on the “data as of forecast time” slice and does not mix in the future.

If the delay varies from an hour to two days, quality drops imperceptibly: fields look fresh but are in fact outdated.

Manual extracts from the records system cover the first case: data sources are collected in one place, the volume is small, and the field composition is stable. They are used when the report on beds, admissions, and transfers goes out on schedule.

The limitations are predictable — missed days, duplicates, and discrepancies in department reference lists.

We cover incomplete data with features, not guesses: the model receives the age of the last record, the share of empty fields, and the source label.

The forecast then returns an interval and honestly widens it on days when data arrived later than usual, instead of silently making an error.

Automatic exchange is connected as a second stage — when the manual loop provides a clear data schema and it is visible which fields affect the forecast.

Technical questions before project start

Before start, three things are usually checked: whether accumulated data is sufficient, how the system will behave during a mass admission, and who is responsible for forecast quality after handover. We examine each point concretely, without promises “on average across the hospital.”

We start with a pilot in one department: the model trains on its history, the forecast is compared with actuals daily — and only after stable deviation within acceptable boundaries is the solution rolled out to the remaining buildings.

The pilot provides a measurable baseline: accuracy in a specific department instead of a promise of accuracy in general.

What happens during a mass admission?

The model will not predict a surge — it comes from outside: an accident, an outbreak, a mass arrival.

Therefore we include manual event entry and a discrepancy threshold: if actuals deviate from the forecast beyond the set value, the duty officer receives an alert and sees which departments are at risk. The adjustment is entered with one action and taken into account in subsequent calculations.

Who is responsible for forecast quality after handover?

Without control, accuracy drops: profiles, flows, and admission procedures change. We fix the quality metric, hand over the retraining procedure and discrepancy dashboard, and teach your team to run the cycle independently. We go through the first updates together — this leaves a clear procedure instead of a “black box.”

Let’s discuss the task and come back with an estimate and plan

To start, we do not need access to the clinic’s entire IT environment — an initial data set and an understanding of which decisions will rely on the forecast are enough. This is sufficient to come back with an estimate of work and an implementation plan, not generic slides.

• Initial data set: history of admissions and transfers between departments, length of stay, admission denials, seasonal surges — over several full cycles together with the epidemic season.
• Integration points: where data is currently pulled from — medical statistics module, admission department, operating block — and in what form extracts are available: file, database view, or query service.
• Planning horizon and the decision for it: shift scheduling, bed reserve, or planned admission plan. A daily forecast and a two-week forecast are different models and different recalculation frequency.
• External context of the flow: calendar of planned surgeries, holidays and school breaks, physician vacation schedule, constraints by bed profiles.
• Decision-making rules: which thresholds are considered critical, who looks at the forecast and how often, and what happens when they are exceeded.
• Access and environment: test loop, procedure for de-identifying extracts, who on the clinic side confirms the correctness of historical data.

After discussing the task, we come back with an estimate of work and an implementation plan: the sequence of stages, what we validate on historical data, where the boundary lies between the pilot in one department and the full loop, and for which departments we consider the model operational.

If some data is not yet available, that is also part of the conversation: we will suggest what can be collected along the way and how this affects timelines.