Discrete Event Simulation

Discrete Event Simulation: How DES Models Work in Health Economic Evaluation

In health economic evaluation, discrete event simulation (DES) follows individual patients, or other entities such as organs and referral requests, from one event to the next, so that each patient's history and the availability of services can shape what happens later. It is used for disease pathways that a cohort Markov model handles awkwardly and for services where beds, clinicians or scanners are limited and patients wait. This page explains the building blocks of a DES (entities, attributes, events, resources and queues), how the simulation clock advances, how event times are sampled from parametric distributions, and how costs and QALYs accrue. It also shows how simulation error is separated from parameter uncertainty, works through an illustrative capacity example, and sets out verification and validation checks drawn from the ISPOR-SMDM good practice report on DES and the NICE Decision Support Unit's TSD 15.

What discrete event simulation represents

In a DES, each event can change a person's condition, resource use, queue position or pathway through care. Entities are the patients or items that move through the model, attributes are the characteristics they carry, events are the occurrences that change their state, resources are the services they need, and queues form when a needed resource is occupied.

DES is especially useful when individual histories, competition for resources and the timing of events affect outcomes. The ISPOR-SMDM task force recommends DES when the problem involves constrained resources, and regards it as an attractive option without such constraints when individuals interact, when time dependencies matter, when pathways depend on several patient characteristics, or when individual experience needs to be recorded. In health technology assessment, many DES models are non-constrained, following the usual health economic assumption that every required resource is available when needed; TSD 15 notes that patient interaction and constrained resources are not a common feature of NICE technology appraisals. DES is not automatically preferable to a cohort model or other individual-level simulation; the model structure should follow the decision problem.

Events change the system state

A DES moves from one event to the next rather than updating every person at fixed time intervals. Between events, the system state remains unchanged unless the model explicitly includes continuous processes. This next-event logic can represent irregular timing without introducing an arbitrary cycle length.

Core components include:

The event definition should state what changes, which future events are scheduled or cancelled, and which costs or outcomes accrue. Hidden event side effects make the model difficult to verify.

The clock advances to the next scheduled event

The event calendar contains future events and their scheduled times. The simulation selects the earliest event, moves the clock directly to that time and executes the associated logic. Ties require a documented priority rule because simultaneous events can have different consequences depending on processing order.

If the current clock is $t$ and the pending event times are $T_1,\ldots,T_K$, the next event time is:

$$ t_{\text{next}}=\min_{k=1,\ldots,K}T_k $$

The clock update is:

$$ t\leftarrow t_{\text{next}} $$

The selected event is removed from the event calendar, its state changes are applied, and any resulting events are added. An event that becomes impossible, such as a scheduled follow-up after death, must be cancelled or ignored through an explicit rule.

Individual histories determine future risks

DES can retain attributes and past events for each person. Future event times or choices can therefore depend on age, time since treatment, previous complications, accumulated resource use or other history. This memory makes DES suitable for non-Markovian processes in which current state alone does not capture all relevant information. A Markov model conditions transitions on the current state only, so history or time since an event has to be carried by replicate or tunnel states, and TSD 15 notes that a cohort model becomes unwieldy once many such states are needed.

A cause-specific event time may be generated from a hazard function $h_j(t\mid x_i,H_i)$, where $x_i$ contains fixed attributes and $H_i$ contains the individual's simulated history. For a constant hazard $\lambda_j$, an exponential waiting time can be generated from a uniform random number $U$:

$$ T_j=-\frac{\ln(U)}{\lambda_j}, \qquad U\sim\operatorname{Uniform}(0,1) $$

This is the inverse-transform method: the sampled time is the value at which the survival function $S(T_j)$ equals $U$, which is valid because one minus a uniform random number on the interval from 0 to 1 is itself uniform on that interval. For a Weibull distribution with shape $\gamma$, scale $\beta$ and survival function $S(t)=\exp[-(t/\beta)^{\gamma}]$, the same step gives $T=\beta(-\ln U)^{1/\gamma}$; a shape above 1 gives a rising hazard, a shape below 1 a falling hazard, and a shape of 1 reduces to the exponential case.

For time-varying hazards more generally, inverse cumulative-hazard methods, numerical inversion or other validated sampling algorithms may be required. The model should preserve the intended dependence between competing event times rather than sample every time independently by convenience.

Competing events determine which pathway occurs next

A person may be at risk of several events, such as progression, treatment discontinuation, adverse event and death. DES can schedule candidate times and execute the earliest event, after which the remaining event schedule is updated. This creates a competing-risks process at the individual level.

For candidate event times $T_{i1},\ldots,T_{iJ}$ for person $i$:

$$ T_i^{\text{next}}=\min_j T_{ij} $$

The event type is:

$$ J_i^{\text{next}}=\arg\min_j T_{ij} $$

After the selected event occurs, previously scheduled times may remain valid, be resampled conditionally or be cancelled. The correct rule depends on the underlying time-to-event model and treatment of residual waiting time.

Resources and queues make capacity explicit

DES can represent finite resources and the waiting that occurs when demand exceeds availability. An entity seizes a resource when capacity is available, uses it for a simulated duration and releases it afterward. If no unit is available, the entity joins a queue governed by a stated priority rule.

Common queue disciplines include:

• First in, first out serves entities in arrival order.
• Clinical priority serves higher-acuity patients before lower-acuity patients.
• Shortest expected processing time prioritises activities expected to finish sooner.
• Appointment priority reserves capacity for scheduled rather than unscheduled arrivals.
• Pre-emption allows a high-priority entity to interrupt another entity's resource use.

Resource logic can affect health as well as throughput. Waiting may delay treatment, worsen prognosis, increase emergency use or change costs, so queues should not be modelled as operational detail alone when they influence outcomes.

Queue measures connect operations to economic outcomes

DES records waiting times, queue lengths, utilisation and throughput over simulated time. These outputs help explain why a capacity change affects costs or health. Measures should be defined over a stable observation period and distinguish time averages from averages across entities.

Resource utilisation for a resource with $c$ identical units over horizon $T$ can be estimated as:

$$ Utilisation= \frac{\text{total busy resource time}}{cT} $$

The average waiting time among $N$ served entities is:

$$ \overline W=\frac{1}{N}\sum_{i=1}^{N}W_i $$

For a stable queueing system, Little's law relates the long-run average number in the system $L$, arrival rate $\lambda$ and average time in the system $W$:

$$ L=\lambda W $$

Little's law is a useful validation relationship, but it requires consistent definitions and a stable measurement period. It should not be applied mechanically to a transient system or to one whose arrival pattern or capacity shifts during the observation period.

Illustrative example: utilisation and Little's law at a diagnostic service

In this illustrative example, with hypothetical figures, patients arrive at a diagnostic service at an average rate of 18 per day. The service has three identical machines, and each machine is available for eight hours per day. Mean processing time is one hour per patient, so nominal daily capacity is 24 patients.

The nominal utilisation implied by average demand is:

$$ \rho=\frac{18\times1}{3\times8}=0.75 $$

Average demand uses 75% of nominal machine time. This does not imply that no queue will form because random clustering of arrivals, variable processing times, downtime and scheduling rules can create temporary congestion.

If simulation estimates an average time in the system of 0.30 days under stable demand, Little's law implies:

$$ L=18\times0.30=5.4 $$

An average of 5.4 patients should therefore be in the system, including both waiting and service, if the arrival-rate and time definitions match. A material discrepancy can reveal an incorrect observation window, missed entities or inconsistent units.

Costs and health outcomes accrue at events or over time

A DES can assign one-off consequences when events occur and continuous consequences while a person occupies a state or uses a resource. Separating these mechanisms reduces double counting. Every accrued value should retain its timing so that discounting can be applied correctly.

For individual $i$, total discounted cost may be written as:

$$ C_i= \sum_{e\in E_i}c_e d(t_e) +\int_0^{T_i}c_i(t)d(t),dt $$

where $c_e$ is a cost attached to event $e$, $c_i(t)$ is a continuous cost rate, and $d(t)$ is the discount factor. Discounted QALYs can be accumulated as:

$$ Q_i=\int_0^{T_i}u_i(t)d_Q(t),dt $$

where $u_i(t)$ is the individual's utility over time. The model should specify whether utility changes immediately at events, gradually, or only after a delay.

Initialisation depends on the decision context

A simulation can begin empty and build toward steady operation, or it can begin with an existing population, queue and resource state. An empty start may create an artificial low-congestion period, while an unrealistic full start may create an artificial backlog. Initialisation should reflect whether the question concerns a new service, an established service or a defined patient cohort.

Common approaches include:

• A terminating cohort simulation follows a defined set of patients until a time horizon or absorbing outcome.
• A steady-state simulation represents an ongoing service with continuing arrivals and no natural final patient.
• A warm-up period allows an ongoing system to move away from arbitrary starting conditions before outcome collection begins.
• A historical initial state populates the model from observed queues, patients and resources at a selected date.

Warm-up data should be excluded from steady-state performance estimates but may still incur model runtime. The warm-up duration should be justified through convergence diagnostics rather than selected solely for convenience.

Terminating and steady-state analyses use different estimands

A terminating simulation has a natural end, such as completion of a trial horizon or follow-up of a closed cohort. A steady-state simulation estimates long-run performance of an ongoing system. The replication design, initialisation and uncertainty analysis should match the chosen estimand.

For a terminating model, replication $r$ may produce an outcome $Y_r$, and the simulation estimate is:

$$ \overline Y=\frac{1}{R}\sum_{r=1}^{R}Y_r $$

For a steady-state model, observations close in simulated time may be autocorrelated. Batch means, independent long runs or other methods are needed to estimate uncertainty without treating correlated observations as independent.

Replications quantify simulation uncertainty

Random event times and attributes make repeated DES runs produce different outputs even with unchanged input distributions. This Monte Carlo variation is numerical uncertainty created by finite simulation, not uncertainty about the true input parameters. Increasing the number of independent replications reduces the standard error of the estimated mean.

For outcomes $Y_1,\ldots,Y_R$ from independent replications:

$$ SE(\overline Y)=\frac{s_Y}{\sqrt{R}} $$

where $s_Y$ is the sample standard deviation of the replication outputs and $R$ is the number of replications. A confidence interval for the mean simulation output is:

$$ \overline Y\pm t_{1-\alpha/2,,R-1} \frac{s_Y}{\sqrt{R}} $$

where $t_{1-\alpha/2,,R-1}$ is the Student t quantile with $R-1$ degrees of freedom. The number of replications should be chosen to achieve a prespecified precision for decision-relevant outputs. A visually stable running mean is useful evidence but is not a substitute for a quantified Monte Carlo standard error.

In a patient-level cost-effectiveness DES the same kind of error comes from simulating a finite number of patients. TSD 15 calls this between-patient sampling error first-order uncertainty, which falls as more patients are simulated, and separates it from second-order uncertainty about parameter values, which probabilistic sensitivity analysis (PSA) characterises. PSA in a patient-level DES usually needs two nested loops: an outer loop samples one set of parameter values, and an inner loop simulates enough patients to estimate mean costs and QALYs for that set. Because run time grows with both loop sizes, the number of patients per parameter set and the number of parameter sets should be chosen together and justified; both the ISPOR-SMDM task force and TSD 15 point to an analysis-of-variance approach for balancing them.

Common random numbers improve comparison efficiency

When two strategies are compared, using aligned random-number streams can make corresponding simulated patients or events experience comparable random variation. This common random numbers design can reduce the variance of the incremental result when strategy outputs are positively correlated. Separate random-number streams for different events, for example one for an event's occurrence and another for length of stay, help keep the same patient's draws aligned across strategies. The design must be implemented consistently so that shared randomness does not accidentally impose unrealistic dependence.

For replication-level strategy outputs $Y_{1r}$ and $Y_{0r}$, the analysis uses the paired difference:

$$ \Delta Y_r=Y_{1r}-Y_{0r} $$

The standard error is calculated from the variation in $\Delta Y_r$, not by treating the two strategy means as independent. Seed management and stream assignment should be documented so results are reproducible without reusing random numbers in unintended places.

Input distributions must represent the underlying process

DES often requires distributions for arrivals, service times, event times, patient characteristics and costs. Distribution choice should be supported by data, process knowledge and diagnostics, and for time-to-event inputs TSD 15 advises checking both the fit to the data and the clinical plausibility of the hazard the distribution implies. Matching only the mean can produce incorrect queues and outcomes because variability and tail behaviour affect congestion and rare events.

Input modelling should address:

• The empirical data source and observation window.
• Censoring, truncation and competing risks in time-to-event data.
• Dependence between patient characteristics and event times.
• Correlation between repeated events for the same person.
• Time-varying arrivals, capacity and clinical practice.
• Structural breaks, seasonality and exceptional periods.
• Parameter uncertainty in the fitted input distributions.

Empirical resampling can preserve observed distributional shape, while parametric models can support extrapolation and covariate effects. Neither approach is automatically superior in every application.

DES differs from other health-economic model structures

DES shares features with individual-level simulation but is defined by its event-scheduling mechanism and explicit simulated time. The choice between structures depends on whether event timing, history and resources materially affect the decision. A more detailed model is not better if the additional mechanisms are unsupported or irrelevant.

DES can represent cohort-like disease progression without queues, but its distinctive value is strongest when timing, history, resource competition or operational pathways matter.

Verification checks whether the model was built correctly

Verification, also called internal validity or technical validity, tests whether the implementation follows the conceptual model and code specification. It should examine event ordering, state updates, cancellations, resource accounting and outcome accumulation. Traceable event logs for a small number of entities are especially valuable.

Useful verification tests include:

• A single patient with deterministic event times follows the expected pathway exactly.
• Event times never move backward and the simulation clock is non-decreasing.
• Dead or discharged entities cannot experience prohibited later events.
• Resource use never exceeds available capacity unless the model explicitly permits overtime.
• Queue membership and service counts reconcile after every event.
• Costs and outcomes accrue once at the intended time.
• Extreme parameter settings produce predictable limiting behaviour.
• Re-running the same seed reproduces the same result.

Code review, unit tests and comparison with independent calculations provide complementary evidence. Passing one aggregate output check is not enough to verify event logic.

Validation asks whether the model is credible for its purpose

Validation compares model behaviour with data, expert knowledge and expected relationships. A model can be free of coding errors but still omit important mechanisms or use invalid inputs. Validation should be proportionate to the decision consequences and recorded separately from verification.

Relevant validation includes:

• Face validity assesses whether pathways, constraints and outputs are clinically and operationally credible.
• Dependent validation compares simulated outcomes with the data used to build or calibrate the model, so it shows consistency with those sources rather than independent support.
• Independent external validation compares outputs with data from another period or setting that were not used to build the model.
• Cross validity compares results with another credible implementation or model structure.
• Predictive validity evaluates whether the model predicts later observations when such a test is feasible.

A capacity model should validate both clinical-economic outcomes and operational measures such as arrivals, waiting, utilisation and throughput. Matching total cost while producing implausible queues does not establish credibility.

Common errors in discrete event models

DES can hide complex logic behind plausible aggregate outputs. The most important errors involve event dependence, initial conditions, queues and the treatment of uncertainty. The following failures can materially affect a health-economic result.

• Scheduling incompatible events independently can create impossible sequences or incorrect competing-risk probabilities.
• Leaving obsolete events on the calendar can allow follow-up, progression or costs after an absorbing event.
• Blocking ongoing risks by accident, for example suspending stroke risk while a patient is in hospital for another event, removes events that should remain possible over the time horizon.
• Using an empty start without warm-up can understate congestion in an ongoing service.
• Matching only average arrival and service times can misrepresent queue behaviour when variability differs.
• Treating correlated observations as independent understates uncertainty in steady-state results.
• Reporting one stochastic run confuses a random realisation with the expected model output.
• Changing random seeds inconsistently across strategies can add avoidable noise to incremental comparisons.
• Using resource queues that do not affect health or cost when delays matter breaks the pathway from operations to outcomes.
• Double counting event and state costs can overstate total expenditure.
• Adding detail without evidence increases complexity without improving decision validity.

A step-by-step verification and validation sequence for a DES

Validation should proceed from a transparent conceptual model to entity-level traces and then to aggregate behaviour. Randomness should be added only after deterministic logic works correctly. The following sequence provides an auditable minimum.

1. Define the entities, attributes, states, events, resources and queues in a conceptual model before coding.
2. Specify every event's trigger, state changes, scheduled consequences and cancellation rules.
3. Run a deterministic one-entity trace and reconcile every event time, cost and health outcome by hand.
4. Test event ties and priorities using deliberately simultaneous events.
5. Reconcile arrivals, queue entries, service starts, completions and exits over a short run.
6. Verify resource conservation and capacity limits at every event.
7. Test absorbing events and obsolete-event cancellation so prohibited events cannot occur later.
8. Choose and justify initialisation, warm-up and termination rules for the intended estimand.
9. Run independent replications and quantify Monte Carlo error for each decision-relevant output.
10. Validate clinical, economic and operational outputs against appropriate observed or external evidence.
11. Propagate parameter and structural uncertainty separately from finite-replication simulation error.
12. Archive the model version, input set, seeds and software environment needed to reproduce the result.

Discrete event simulation is most useful when event timing and system interactions materially affect the decision. Its credibility depends on transparent event logic, defensible input processes and validation of both individual pathways and system-level outcomes.

Sources

• Karnon J, Stahl J, Brennan A, Caro JJ, Mar J, Möller J. Modeling using discrete event simulation: a report of the ISPOR-SMDM Modeling Good Research Practices Task Force-4. Value in Health. 2012;15(6):821-827.
• Davis S, Stevenson M, Tappenden P, Wailoo A. NICE DSU Technical Support Document 15: Cost-effectiveness modelling using patient-level simulation. Sheffield: Decision Support Unit, School of Health and Related Research, University of Sheffield; April 2014.
• Eddy DM, Hollingworth W, Caro JJ, Tsevat J, McDonald KM, Wong JB. Model transparency and validation: a report of the ISPOR-SMDM Modeling Good Research Practices Task Force-7. Value in Health. 2012;15(6):843-850.
• Little JDC. A proof for the queuing formula: L = λW. Operations Research. 1961;9(3):383-387.
• Law AM. Simulation Modeling and Analysis. 5th ed. New York: McGraw-Hill Education; 2015.