Queueing basics for capacity planning

A ward that runs at 90% occupancy on average is not 10% empty. Some days it is 80% full and some days it is full, with patients waiting in the emergency department for a bed. Average demand sets how many beds you need on average. Variation sets how many more you need to avoid a queue, and queueing theory is the arithmetic for that second part.

Four ideas cover most capacity questions an analyst gets asked: Little’s law, the utilisation curve, the cost of variability, and the Erlang C formula for pools of servers. None of them needs more than a few lines of Python.

Little’s law

For any stable system, the average number of items in it equals the arrival rate times the average time each item spends there:

L = λ × W

It holds whatever the distributions look like, as long as you measure over a long enough period. For beds, L is the average number of occupied beds, λ is admissions per day and W is the mean length of stay in days. Twenty admissions a day with a mean stay of 5.45 days gives 109 occupied beds on average.

Little’s law is the right tool for three everyday jobs:

• Sanity-checking a plan. If a business case says admissions will grow 5% and length of stay will stay flat, occupied beds grow 5%. No model needed.
• Converting between measures. The average number of patients waiting in the emergency department (ED) for a bed = decisions to admit per hour × mean wait in hours. If you know two, you know the third.
• Checking a simulation or a data pipeline. In the bed occupancy simulation, the mean number of patients in a bed was 109.03, and admissions per hour times mean hours in a bed gave 109.06. If those two numbers disagree in your own data, something is being counted twice or dropped.

What Little’s law can’t tell you is how often the system is full. It is about averages. For that you need the rest of this article.

Utilisation against waiting

Take the simplest queue: one server, customers arriving at random (a Poisson process), service times that vary exponentially. This is the M/M/1 queue. Its mean wait before service, in multiples of the mean service time, is:

wait ÷ service time = ρ ÷ (1 − ρ)

where ρ is utilisation, the share of time the server is busy. At 80% utilisation, the average wait is 4 service times. At 90% it is 9. At 95% it is 19. The last five points of utilisation double the wait, and the curve heads to infinity at 100%.

Data table

Number of servers (M/M/c)

Utilisation	1 server	2 servers	5 servers	20 servers
0.5	1.0	0.3	0.1	0.0
0.51	1.0	0.3	0.1	0.0
0.52	1.1	0.4	0.1	0.0
0.53	1.1	0.4	0.1	0.0
0.54	1.2	0.4	0.1	0.0
0.55	1.2	0.4	0.1	0.0
0.56	1.3	0.5	0.1	0.0
0.57	1.3	0.5	0.1	0.0
0.58	1.4	0.5	0.1	0.0
0.59	1.4	0.5	0.1	0.0
0.6	1.5	0.6	0.1	0.0
0.61	1.6	0.6	0.1	0.0
0.62	1.6	0.6	0.1	0.0
0.63	1.7	0.7	0.1	0.0
0.64	1.8	0.7	0.2	0.0
0.65	1.9	0.7	0.2	0.0
0.66	1.9	0.8	0.2	0.0
0.67	2.0	0.8	0.2	0.0
0.68	2.1	0.9	0.2	0.0
0.69	2.2	0.9	0.2	0.0
0.7	2.3	1.0	0.2	0.0
0.71	2.5	1.0	0.3	0.0
0.72	2.6	1.1	0.3	0.0
0.73	2.7	1.1	0.3	0.0
0.74	2.9	1.2	0.3	0.0
0.75	3.0	1.3	0.4	0.0
0.76	3.2	1.4	0.4	0.0
0.77	3.4	1.5	0.4	0.0
0.78	3.5	1.6	0.5	0.1
0.79	3.8	1.7	0.5	0.1
0.8	4.0	1.8	0.6	0.1
0.81	4.3	1.9	0.6	0.1
0.82	4.6	2.0	0.7	0.1
0.83	4.9	2.2	0.7	0.1
0.84	5.2	2.4	0.8	0.1
0.85	5.7	2.6	0.9	0.1
0.86	6.1	2.8	1.0	0.1
0.87	6.7	3.1	1.1	0.2
0.88	7.3	3.4	1.2	0.2
0.89	8.1	3.8	1.4	0.2
0.9	9.0	4.3	1.5	0.3
0.91	10.1	4.8	1.7	0.3
0.92	11.5	5.5	2.0	0.4
0.93	13.3	6.4	2.4	0.5
0.94	15.7	7.6	2.9	0.6
0.95	19.0	9.3	3.5	0.8

Service-time variability, one server (M/G/1)

Utilisation	Fixed length (CV 0)	Low variability (CV 0.5)	Exponential (CV 1)	High variability (CV 1.5)
0.5	0.5	0.6	1.0	1.6
0.51	0.5	0.7	1.0	1.7
0.52	0.5	0.7	1.1	1.8
0.53	0.6	0.7	1.1	1.8
0.54	0.6	0.7	1.2	1.9
0.55	0.6	0.8	1.2	2.0
0.56	0.6	0.8	1.3	2.1
0.57	0.7	0.8	1.3	2.1
0.58	0.7	0.9	1.4	2.2
0.59	0.7	0.9	1.4	2.3
0.6	0.8	0.9	1.5	2.4
0.61	0.8	1.0	1.6	2.5
0.62	0.8	1.0	1.6	2.6
0.63	0.8	1.1	1.7	2.8
0.64	0.9	1.1	1.8	2.9
0.65	0.9	1.2	1.9	3.0
0.66	1.0	1.2	1.9	3.1
0.67	1.0	1.3	2.0	3.3
0.68	1.1	1.3	2.1	3.5
0.69	1.1	1.4	2.2	3.6
0.7	1.2	1.5	2.3	3.8
0.71	1.2	1.5	2.5	4.0
0.72	1.3	1.6	2.6	4.2
0.73	1.4	1.7	2.7	4.4
0.74	1.4	1.8	2.9	4.6
0.75	1.5	1.9	3.0	4.9
0.76	1.6	2.0	3.2	5.2
0.77	1.7	2.1	3.4	5.4
0.78	1.8	2.2	3.5	5.8
0.79	1.9	2.4	3.8	6.1
0.8	2.0	2.5	4.0	6.5
0.81	2.1	2.7	4.3	6.9
0.82	2.3	2.9	4.6	7.4
0.83	2.4	3.0	4.9	7.9
0.84	2.6	3.3	5.2	8.5
0.85	2.8	3.5	5.7	9.2
0.86	3.1	3.8	6.1	10.0
0.87	3.4	4.2	6.7	10.9
0.88	3.7	4.6	7.3	11.9
0.89	4.0	5.1	8.1	13.2
0.9	4.5	5.6	9.0	14.6
0.91	5.1	6.3	10.1	16.4
0.92	5.8	7.2	11.5	18.7
0.93	6.6	8.3	13.3	21.6
0.94	7.8	9.8	15.7	25.5
0.95	9.5	11.9	19.0	30.9

Calculated from the formulas. Source: projects/bed-occupancy-simulation. Poisson arrivals throughout. Servers: Erlang C. Variability: Pollaczek-Khinchine.

This is why “we’re only at 90%” is not reassuring, and why a small rise in demand near capacity does so much damage. In the simulation, 5% more demand raised mean bed occupancy by 3.3 points but multiplied 12-hour waits for a bed by 2.5.

The first view of the chart also shows the effect of more servers. With 20 servers sharing one queue, the wait at 90% utilisation is 0.28 service times instead of 9. Pooling is powerful, and it is the reason big hospitals can safely run hotter than small ones. More on that below.

Variability is the enemy

Switch the chart to the second view. It holds one server and Poisson arrivals, and varies only how predictable the service time is, measured by its coefficient of variation (CV, the standard deviation divided by the mean). The Pollaczek–Khinchine formula gives the mean wait exactly:

wait ÷ service time = ρ ÷ (1 − ρ) × (1 + CV²) ÷ 2

At 90% utilisation:

Same utilisation, same average service time, and the wait more than triples from the most predictable service to the least. Kingman’s approximation extends this to arrivals that are not Poisson: the (1 + CV²) ÷ 2 term becomes (CV of arrivals² + CV of service²) ÷ 2. Variability in when work arrives and variability in how long it takes both cost waiting time, and they add.

For capacity planning, that means two levers besides adding capacity:

• Smooth what you control. Emergency demand is random, but elective admissions, clinic templates and discharge timing are scheduled by the organisation. Spreading them evenly across the week removes variability that nobody had to create.
• Reduce the spread of the work. A clinic where some appointments take 10 minutes and others 40 queues worse than one with the same mean and a narrower spread. Booking long and short appointments into separate slots is a variability fix, not an efficiency one.

Pools of servers: M/M/c and Erlang C

Beds, clinic rooms and call handlers are pools: c identical servers sharing one queue. The offered load, a, is the arrival rate times the mean service time, measured in servers. For beds, that is admissions per day times mean stay in days, the L from Little’s law. Utilisation is a ÷ c.

The Erlang C formula gives the probability that an arrival has to wait. The direct formula has factorials that overflow for large pools, so I compute it through the Erlang B recursion, which is stable for any size:

def erlang_b(servers: int, load: float) -> float:
    """Chance that all servers are busy in a loss system, by the stable recursion."""
    blocked = 1.0
    for k in range(1, servers + 1):
        blocked = load * blocked / (k + load * blocked)
    return blocked


def erlang_c(servers: int, load: float) -> float:
    """Chance that an arrival has to wait in an M/M/c queue.

    load is the offered load in servers: arrival rate x mean service time. For beds, that is
    admissions per day x mean length of stay in days.
    """
    utilisation = load / servers
    if utilisation >= 1:
        return 1.0
    blocked = erlang_b(servers, load)
    return blocked / (1 - utilisation * (1 - blocked))


def mean_wait(servers: int, load: float, mean_service: float) -> float:
    """Mean wait in the queue for an M/M/c system, in the units of mean_service."""
    return erlang_c(servers, load) * mean_service / (servers - load)

A worked example: 120 beds, 20 emergency admissions a day, a mean stay of 5.45 days. The offered load is 109.0 beds, and utilisation is 90.8%.

Five more beds cut the chance of waiting from 21.6% to 8.9%. Five per cent more demand on the same 120 beds pushes it to 50.1% and the mean wait to almost 12 hours. To keep the chance of waiting at or below 10%, this unit needs 125 beds today and 131 with 5% more demand. Those are the numbers a business case for beds should contain, not “we need 92% occupancy”.

Size changes the safe occupancy

The same calculation shows why a single occupancy target can’t suit every unit. Here is the highest utilisation each pool size can run at while keeping the chance of waiting at or below 10%:

Data table

Average occupancy	10 beds	30 beds	120 beds	500 beds
0.6	10%	1%	0%	0%
0.61	11%	1%	0%	0%
0.62	12%	1%	0%	0%
0.63	13%	1%	0%	0%
0.64	14%	2%	0%	0%
0.65	15%	2%	0%	0%
0.66	17%	2%	0%	0%
0.67	18%	3%	0%	0%
0.68	19%	3%	0%	0%
0.69	21%	4%	0%	0%
0.7	22%	4%	0%	0%
0.71	24%	5%	0%	0%
0.72	25%	6%	0%	0%
0.73	27%	7%	0%	0%
0.74	29%	8%	0%	0%
0.75	31%	9%	0%	0%
0.76	33%	10%	0%	0%
0.77	34%	12%	0%	0%
0.78	37%	14%	0%	0%
0.79	39%	15%	1%	0%
0.8	41%	17%	1%	0%
0.81	43%	19%	2%	0%
0.82	46%	22%	2%	0%
0.83	48%	24%	3%	0%
0.84	50%	27%	4%	0%
0.85	53%	30%	5%	0%
0.86	56%	33%	7%	0%
0.87	58%	36%	9%	0%
0.88	61%	40%	12%	0%
0.89	64%	43%	14%	1%
0.9	67%	47%	18%	1%
0.91	70%	51%	22%	2%
0.92	73%	56%	27%	4%
0.93	76%	60%	33%	7%
0.94	79%	65%	40%	11%
0.95	83%	70%	47%	18%
0.96	86%	76%	56%	27%
0.97	89%	82%	65%	39%
0.98	93%	87%	76%	55%
0.99	96%	94%	87%	75%

Calculated from the formulas. Source: projects/bed-occupancy-simulation. Assumes steady Poisson arrivals and exponential stays, which flatters real wards.

A 10-bed unit at 85% occupancy is in far more trouble than a 500-bed hospital at 85%. The spare capacity needed grows roughly with the square root of the load, not in proportion to it, so small units need proportionally more slack. This is also the case for pooling: two 30-bed wards that can take each other’s patients behave more like one 60-bed pool. The catch is “can”: a pooled bed only helps if the patient can safely use it.

What this means for bed and clinic capacity

• Plan beds from the distribution, not the average. Little’s law gives the average. The spare capacity comes from queueing, and it depends on how much you are willing to let patients wait.
• Set occupancy expectations by pool size. A 92% target means something different for a 12-bed specialist ward and for a whole hospital. Bagust and colleagues’ 1999 BMJ simulation found risks becoming discernible above about 85% average occupancy, and regular bed shortages at 90% or more, for a whole acute hospital. The table above says smaller units hit trouble sooner.
• Expect non-linear responses near capacity. A 5% rise in demand is not a 5% rise in waits. Report both, so nobody is surprised.
• Remove the variability you create. Uneven elective scheduling, one daily ward round that releases every discharge at 16:00, and clinics booked without regard to appointment length all add waiting that capacity then has to absorb.
• For clinics and waiting lists, the same shape applies. A service whose weekly capacity only just exceeds average weekly demand will see its waiting list swing widely and recover slowly after every bad week. The closer to 100% utilisation, the longer each recovery takes.

Where the formulas stop

Erlang C assumes arrivals at a constant random rate, exponential service times, first-come-first-served, and nothing that depends on the clock. Real beds break all of that. Admissions follow daily and weekly cycles, discharges bunch in the afternoon, weekends discharge fewer patients, and a crowded hospital behaves differently from a quiet one.

So I use the formulas for orientation and simulation for decisions. With inputs that match the worked example (20 admissions a day, 5.45 days in a bed on average), the bed occupancy simulation, which adds hourly and weekly cycles, lognormal stays and weekend discharge delays, gave a chance of waiting of 21.0% against Erlang C’s 21.6%, but a mean wait of 1.86 hours against 2.57. With 5% more demand, the gap widened: 37.5% against 50.1%, and 4.03 hours against 11.81. Part of that gap is a choice in the simulation, where time waiting in the ED counts towards the stay, so a crowded unit gets some bed-days back. Erlang C has no such feedback. At today’s load, the formula was close on how often patients wait and too pessimistic on how long, and it drifted further off as the load rose.

That is the usual pattern. The formula tells you which way things move and roughly how fast. Questions about timing, such as discharging before noon, need a model with a clock in it. Simulation for what-if questions covers how to build and trust one.

Reproduce

The formulas are in projects/bed-occupancy-simulation/queueing.py. The charts and every number in this article come from:

uv run python projects/bed-occupancy-simulation/run.py