Choose your language:
June 1, 2026
Learning objectives:
Acknowledgements: This page was written with reference to the excellent content on conceptual modelling in Robinson (2024).
A conceptual model is a description of the simulation to be developed. It sits between the real-world problem and the computer implementation, capturing what the model needs to do before how it will be coded (Robinson (2024)).
Developing a conceptual model involves:
This description serves as a reference point during model development, for verification, and for any future collaborators or users of the model.
Before designing your DES, it is worth asking whether it is the right approach.
The ISPOR Simulation Modeling Emerging Good Practices Task Force developed the SIMULATE checklist to assist in deciding whether simulation methods are appropriate to address specific health system problems (Marshall et al. (2015)):
| SIMULATE | Does your problem require: |
|---|---|
| System | Modeling multiple events, relationships, and stakeholders representing health care delivery processes? |
| Interactions | Including nonlinear or spatial relationships among stakeholders and their context that influence behaviors and make outcomes in the system difficult to anticipate? |
| Multilevel | Modeling a health care delivery problem from strategic, tactical, or operational perspectives? |
| Understanding | Modeling a complex problem to improve patient-centered care that cannot be solved analytically? |
| Loops | Modeling feedback loops that change the behavior of future interactions and the consequences for the delivery system? |
| Agents | Modeling multiple stakeholders with behavioral properties that interact and change the performance of the system? |
| Time | Time-dependent and dynamic transitions in a health care delivery system, either between or within health care system levels or in health status change? |
| Emergence | Considering the intended and unintended consequences of health system interventions to address policy resistance and achieve target outcomes? |
If you answer yes to several of these, some form of dynamic simulation is likely justified. The checklist doesn’t tell you which method to use. There are three main options, and the simplest way to distinguish them is to consider what the unit of interest is…
| Method | You are modelling… |
|---|---|
| Discrete-event simulation | Individual entities (e.g., patients, calls, vehicles) moving through a process and competing for resources |
| System dynamics | Aggregate quantities and how they influence each other over time through feedback loops |
| Agent-based simulation | Individuals whose behaviour adapts based on what others around them are doing |
For most healthcare operational problems (e.g., scheduling, capacity planning, pathway design), DES is the natural starting point. The others become relevant when feedback loops or adaptive behaviour are central to the question, rather than incidental features of it.
In practice, the boundaries between these methods are blurry. The goal at the conceptual modelling stage is not to pick the “correct” method with certainty, but to make a justified and reasonable choice given the question you are asking.
Robinson (2024) break a conceptual model down into five key components:
State clearly what question the model is being built to answer, and what constraints apply. If you cannot write a one-sentence answer to “what decision will this model inform?”, the objective is not ready yet.
There are two levels of objectives to consider:
| Level | Description |
|---|---|
| Modelling objectives | What do you hope to achieve by the end of the study? What targets are you aiming for? What scenarios are in scope? |
| Project objectives | Practical constraints that shape the model including timescale, required flexibility, run speed, visual display requirements, and ease of use for intended users. |
List the parameters you plan to vary, and the ranges you’ll vary them over.
Ideally, also decide how inputs will be supplied (e.g., within a script, read from a file, entered via a user interface) since this affect how the model code is designed. This will depend on the needs of the intended users.
List the statistics the model needs to produce (e.g. mean waiting time, resource utilisation, queue length) and decide how they will be reported.
Outputs should map directly onto the objectives: if a statistic does not help answer the question, it probably does not need to be there.
Model content has two dimensions (Robinson (2024)):
| Dimension | Description |
|---|---|
| Scope | Which parts of the system are included in the model. |
| Level of detail | How finely to represent each included component. |
Content can be represented using:
Document every place where you depart from the real system, distinguishing two types (Robinson (2024)):
| Concept | Definition |
|---|---|
| Assumption | Arise from incomplete knowledge - you do not know exactly how something works, so you use the best available information. |
| Simplification | Deliberate design choices - you could model something in more detail, but you opt for a simpler representation. |
Both need to be recorded. Assumptions may need revisiting if better data become available; simplifications should be justified against their impact on validity.
A good model (Robinson (2024)):
Overarching all four criteria is the requirement to build the simplest model possible to meet the objectives of the simulation study. Simpler models are faster to build and run, easier to understand and explain, and require less data.
Models can be simplified by removing components or by representing components more simply - for example (Robinson (2024)):
A simplification is good if it brings the benefits of faster model development and run speed (feasibility and utility) while maintaining sufficient accuracy (validity) and credibility (Robinson 2024).
A practical way to calibrate this is to prototype: build the simplest plausible model first, then add scope or detail incrementally and check whether outputs change meaningfully. Stop when they stop changing.