Healthcare & Life Sciences
Hospital Capacity Forecasting API
Staffing decisions for next week are being made now, from last week's census and somebody's judgement. The data to do better is already in your systems.
- Hospital operations software
- Health system planning teams
- Workforce scheduling vendors
- Integrated care boards
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Bed and staffing planning in most hospitals runs on a short-horizon look at current occupancy plus the experience of whoever is in charge of the rota. It works, in the sense that the hospital functions, but it produces a predictable pattern: units that are over-staffed on quiet days, agency spend that spikes in response to shortfalls nobody saw coming, and elective lists cancelled on the morning because an emergency surge filled the beds.
The underlying series are unusually forecastable. Emergency attendances have strong weekly and annual seasonality, respond to weather and to public holidays, and move with respiratory season in ways that have been consistent for years. Length of stay distributions by unit and case type are stable enough to convert an admission forecast into a bed-day forecast. Discharge timing is the noisy part, and it is noisy for operational reasons that are themselves partly predictable.
The distinction that matters is between a forecast and a plan. A point estimate of ninety-two beds is useless for a decision about whether to open an escalation area; the decision needs the probability of exceeding capacity, and the cost asymmetry between being over-staffed and being short. Forecasts here are built to be consumed as distributions.
Who buys this
Hospital operations software, Health system planning teams, Workforce scheduling vendors, Integrated care boards
What the API returns
What comes back
- Occupancy forecasts by unit and bed type with prediction intervals
- Admission and emergency attendance forecasts by hour of day and day of week
- Discharge forecasts with the expected profile across the day
- Staffing requirement translated from forecast demand using your own skill-mix rules
- Probability of breaching a configured occupancy or escalation threshold
- Elective list risk: which scheduled procedures sit on days likely to be capacity constrained
- Scenario runs for respiratory surge, industrial action and planned closures
- Forecast accuracy history per unit, published so the forecast can be trusted or discounted on evidence
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/forecast/occupancy | Occupancy forecast by unit with intervals |
| GET | /v1/forecast/admissions | Admission and attendance forecast by hour |
| GET | /v1/forecast/staffing | Staffing requirement from forecast demand |
| GET | /v1/forecast/breach-probability | Probability of exceeding configured thresholds |
| POST | /v1/scenarios/run | Run a surge or closure scenario |
| GET | /v1/accuracy | Realised forecast accuracy by unit and horizon |
Request and response
illustrativeRequest
{
"units": ["acute_medicine", "respiratory", "general_surgery"],
"horizon_days": 14,
"interval": 0.9,
"include_staffing": true,
"skill_mix_ruleset": "trust_default_2026"
}Response
{
"generated_at": "2026-10-22T06:00:00Z",
"model_version": "capacity-2026.08",
"units": [
{
"unit": "acute_medicine",
"beds_available": 96,
"forecast": [
{ "date": "2026-10-23", "occupancy_mean": 88.4,
"interval_90": [79.1, 96.8], "breach_probability": 0.21 },
{ "date": "2026-10-24", "occupancy_mean": 91.7,
"interval_90": [82.0, 99.9], "breach_probability": 0.38 },
{ "date": "2026-10-25", "occupancy_mean": 94.2,
"interval_90": [84.6, 102.4], "breach_probability": 0.56 }
],
"staffing": [
{ "date": "2026-10-24", "registered_nurses_required": 31,
"support_staff_required": 14, "shortfall_vs_roster": 3 }
],
"drivers": ["respiratory_season_onset", "bank_holiday_discharge_lag"]
}
],
"accuracy_note": "Mean absolute error 4.2 beds at 7-day horizon over the last 90 days",
"caveat": "Forecast of aggregate demand. Not a clinical prioritisation tool."
}Where the data comes from
| Your admission, discharge and transfer records | The core series; several years of history is what makes seasonality estimable rather than guessed |
| Emergency department attendance logs | Arrival timing at hourly granularity, which drives the front-door forecast |
| Length of stay history by unit and case type | Needed to convert an admission forecast into bed-days; this is where most of the signal lives |
| Roster and skill-mix rules | Your own establishment and ratio rules, so staffing output reflects how you actually staff rather than a generic ratio |
| Weather and public health surveillance feeds | Published data; both respiratory surveillance and temperature have measurable, lagged effects on attendance |
| Local calendars and elective schedules | Holidays, school terms and planned theatre lists all shift demand in ways a univariate model cannot see |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Hierarchical forecasting with reconciliation, so unit-level forecasts sum coherently to division and site totals
- Separate models for arrivals and for length of stay, combined into occupancy, because the two have different drivers and different error structures
- Quantile forecasting rather than point estimates plus a symmetric error bar; occupancy error is not symmetric and treating it as such understates breach risk
- Explicit holiday and day-of-week effects, including the discharge lag that follows a bank holiday
- Respiratory season handled as a regressor from surveillance data rather than as a fixed annual shape, since onset timing moves year to year
- Backtesting on rolling origins with accuracy reported per unit and per horizon, published as an API output rather than a slide
- Cost-asymmetric evaluation, because being three nurses short is not the mirror image of being three over
- Drift monitoring on pathway changes — a new ambulatory unit or a changed admission policy breaks these models immediately and visibly
What it changes for the business
Rota decisions made earlier
Staffing requirement with intervals at a two-week horizon moves decisions out of the window where agency cover is the only option.
Fewer same-day elective cancellations
Scheduled lists sitting on high-breach-probability days are visible while there is still time to move them.
Escalation opened on evidence
Breach probability gives a defensible trigger for opening or closing escalation capacity.
Accuracy you can audit
Published per-unit error history means operational teams can calibrate how much weight to give the forecast.
How it fits into your product
How it embeds
- Deployed inside your own environment; patient-level admission data does not need to leave it
- Scheduled generation each morning, with on-demand regeneration after a material change
- Outputs sized for your existing operational dashboards and rostering tools, not a separate screen to check
- Webhooks on breach-probability threshold crossings for escalation workflows
- Scenario endpoints your planning team can drive directly for surge and closure planning
- Aggregate-only outputs by default, so nothing patient-identifiable appears in the forecast layer
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
How far ahead is the forecast actually useful?
Seven to fourteen days is where it earns its place, because that is the window where rota and elective decisions are still changeable. Beyond about four weeks the intervals widen to the point where the forecast adds little over seasonal averages, and we would rather say that than sell a six-month horizon that looks precise and is not.
Does this prioritise patients or ration care?
No. Every output is aggregate: beds, attendances, staffing requirement. There is no patient-level scoring and no clinical prioritisation in it, and we would not extend it in that direction. Decisions about individual patients belong with clinicians looking at those patients.
What happens when something unprecedented occurs?
The forecast degrades, and it should say so. A pandemic, a major incident or industrial action sits outside the historical distribution, and the honest response is widened intervals plus a flag that the model is operating outside its training range. Scenario runs exist for exactly these cases — they are assumption-driven planning tools, not predictions.
How much history do you need?
Three years is comfortable, two is workable, one is thin — with one year you cannot separate an annual seasonal effect from a trend. If your data only goes back as far as a recent system migration, we would say so during discovery and scope the horizon accordingly.
Will a pathway change break it?
Yes, and quickly. Opening an ambulatory unit or changing an admission policy alters the series the model learned. Drift monitoring is built in so the break is detected rather than silently degrading accuracy, and the retraining cadence is agreed as part of the support arrangement.
Related blueprints
Appointment No-Show Prediction API
Cancellation and no-show probabilities per appointment, built to add capacity through reminders and overbooking rather than to ration care.
Pharmaceutical Supply Risk API
Shortage signals, supplier concentration risk and disruption indicators for the medicines and consumables a formulary depends on.
Medical Document Extraction API
Structured fields pulled from clinical notes, lab reports and referral letters, returned with per-field confidence for review.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.