*Queueing theory* and modeling provide us with “closed-form” analytical solutions to problems involving, reasonably enough, queues. Indeed, this type of performance-focused modeling is central to properly planning and sizing infrastructure and facilities of many types, from a new hospital building with interconnected services to servers, bridges, and routers on a distributed communications network, checkout registers at a retailer, toll booths (and lanes) on an interstate, conveyor belts at an airport, or teller and drive-through windows at a bank. Complex models can be joined to form *queueing networks*.

## The power and applicability of queueing models

Because they lend themselves to modeling just about anything one can conceive of in terms of traffic at one or more points of service, these models can also help us analyze queues of patients waiting to be registered, examined, operated on, or discharged.

The *Kendall notation* is used to characterize a queueing model in terms of probability distributions of *interarrival times and service times*, as well as *number of servers, system capacity, population size, and queue discipline*. Typically, a new arrival enters the system by joining the queue, and leaves the queue when at the head of the same with at least one server being *idle*. If not in an idle state, a server is deemed *busy*. For the same server, a *busy period* occurs between two idle states. Together, the arrivals in the queue and those being served add up to the arrivals in the system. Once served, an arrival leaves the system. This is sometimes called a *birth-death* process. In IT, one talks about *jobs* in the system (ex. data packets going through a gateway.) In healthcare, one tends to think in terms of patient flow.

As a practical example, consider a simple M/M/1 model, with exponential distributions of arrival and service times, a single server, essentially infinite system capacity and population size, and a first come-first serve (FCFS) queue discipline. This model could be used to characterize patients arriving to be registered by a single staff member at a hospital facility or physician practice, who also are asked to take a number or sign in and fill out some paperwork before they are seen. Many statistics, including average queue length, wait time, the probability of having more than a specific number of patients in the queue, and server throughput can be calculated, and in turn be used to redesign the entire facility or aspects of the workflow. That the system has infinite capacity means it can accommodate an unlimited number of arrivals. This is often not true in practice, where waiting rooms are finite in size. This means a *buffer* needs to be part of the model. Related to this, when faced with too lengthy a wait, certain arrivals may *balk* of their own accord and leave without being seen (LWBS), a not uncommon occurrence in hospital ERs.

## Building a queueing model and developing operational insight

Consider the case when an operations manager is being asked to optimize her allocation of resources in the patient registration area. She may well be wondering how best to allocate her budget strike a balance between speedy service and waiting facilities that do not drive much needed potential revenue away. Having a few parameters in mind, she would like to try out her ideas without actually having to build out a whole area. Below I illustrate a few of the calculations for such an M/M/1 model of patient registration, assuming that on average 5 patients arrive hourly, the registrar can process 20 registrations per hour, and there is limited space in the registration area, say for no more than 15 patients. Parameters in *italics* are inputs to the model, whereas calculated results are shown in normal font.

Note that these models yield results that typically hold for *steady-state* conditions, i.e. when transients have stabilized. This is true of modeling in general. In practice, what it means is that the results may become increasingly useful once away from the “warm up” period of the facility or situation being studied (ex. avoid drawing unwarranted conclusions from the modeling of the opening minutes of an eight-hour shift at a physician practice, or the first few minutes of the afternoon shift after a single server/staffer in customer service is returning to her workstation after lunch break, or during the first few days after a significant change to the layout of a facility has occurred and staff are still coming to grips with it.)

*M/M/1 queueing model*

Parameter/Result Value Comment

*b **15 * buffer size

*lambda* *5 * rate of arrival, in patients per hour

*mu * *20 * service rate, in patients (being registered) per hour

rho lambda/mu = 0.25 traffic intensity (utilization)

stability condition rho < 1? yes, equal to 0.25, thus stable

p_n (1-rho) * rho^n probability of n patients in system

p_0 0.75 prob. of zero patients (n = 0) in system

p_3 0.32 prob. of 3 patients in system (1 registering, 2 in queue)

p_7 0.10 prob. of 7 patients in system (1 registering, 6 in queue)

p_11 0.03 prob. of 11 patients in system (1 registering, 10 in queue)

num_pt_avg rho/(1-rho) = 0.33 mean number of patients in system

reg_t_avg (1/mu)/(1-rho) = 0.067 mean time spent by patients in system, .067 hr = 3 min 36 sec approx.

num_pt_avg_q rho^2/(1-rho) = .08 mean number of patients in queue

resp _t_avg (1/mu)/(1-rho) = .067 mean response time, .067 hr = 3 min 36 sec approx.

resp_t_var (1/mu^2)/(1 – rho)^2 = 0.0044 variance of response time

wait_t_avg rho*(1/mu)/(1-rho) = 0.017 mean wait time, .017 hr = 1 min approx.

pt_serve_busy_avg 1/(1 – rho) = 1.3 mean numer of patients registered in a busy period

busy_period_t_avg 1/(mu(1 – rho)) = 0.067 mean duration of busy period, .067 hr = 3 min 36 sec

p_buf_overflow rho^b = 0.25^15 = 9.3 x 10^(-10) prob. of *15 or more* people showing and overflowing space

buf_size ( < 1% loss) rho^n < .01 –>

–> n > log(.01) / log(rho) = 3.3 a buffer of size 4 ensures less than 1 patient in 100 will be unable to register.

Other questions a manager may have include: given an expected average rate of arrivals of 5 patients/hr, what is the likelihood that *exactly* 10 patients will arrive in the next 2 hours, *up to* 10 patients in the same time frame, or *between* 8 and 15 patients in the same time frame. Using the Poisson distribution function in Excel yields .125 o 12.5% for the probability that exactly 10 patients will arrive in the next 2 hours, 0.583 or 58.3% probability that between 0 and 10 patients will arrive in the next 2 hours, and 0.731 or 73.1% that there will be between 8 and 15 patient arrivals (this goes up to .969 or 96.9% for between 5 and 20 arrivals.)

The low utilization of the server in the above example and consequently short queue make the M/M/1 approximation to a more complex M/M/1/B model viable and therefore the calculations for buffers can be said to apply. In summary, this exercise tells the planning manager that most of the time (75%) there will be no queue of patients to speak of, that the server will be idle most of the time (and could perhaps be assigned other tasks), that approximately one third (32%) of the time there will be 3 patients in the system and about 10% of the time there are likely to be 7 patients in the system, that a patient will spend just over 3 1/2 minutes in the system (of which 1 minute waiting), that a waiting room with space for 4 patients should suffice to ensure that fewer than 1 in 100 patients walk away (balk) due to excessive waiting, and that the chances of the waiting room being too small for the expected traffic are infinitesimal. This is all on average and for steady-state conditions, with parameters as initially established — these parameters can be varied many times and the new scenarios and results compared and ranked according to design criteria, budget, or preferences.

These are the some of the most basic calculations possible in trying to plan and gauge operations performance. While patient registration was used to illustrate key ideas, the latter apply easily to a variety of points of service, thus enabling healthcare managers to avoid waste in trying out approaches to staffing or facilities sizing that have a low likelihood of meeting requirements. Being able to assess demand and plan properly in “what-if?” fashion is even more important in a context where time pressures on staff are high — as in the OR or the ER — and where fatigue and serious mistakes can result in eventual harm to the patient.

Queueing models can get exceedingly non-intuitive and complex to develop explicitly, which is why the use of simulation and related tools with user-friendly graphical interfaces is often the preferred option. Note, however, that a clear grasp of the underpinnings of simulation is just as necessary — regardless of its convenience and apparent ease of use — if one wants to properly apply models to a broad spectrum of situations and interpret results correctly.