Introduction

Hospitals are one of the most important links in the healthcare service chain and their quality directly affects people's lives. Operational Research/Management Science (OR/MS) methods can assist many people in the health system who are required to plan and manage hospital resources. One such method is computer simulation. A simulation model is a replica of a real-world system on computer and can be used to evaluate ‘what-if?’ scenarios before actually implementing changes in the real system. For example, a simulation model of a hospital's radiology department could be used to better understand the impact that a new Magnetic Resonance Imaging scanner might have on the hospital's quality of service.

There are many examples of use of simulation in hospitals as cited in the several reviews of the academic literature, such as those by Lane et al (2000), Brailsford et al (2009), Gunal & Pidd (2010), and Katsaliaki & Mustafee (2010). Most of the papers in the hospital simulation modelling area open with a sentence indicating the financial size of the healthcare sector and the need for improved efficiency. The intention of this paper is to act as a guide to support researchers or practitioners building hospital simulation models. It is stressed that by the term hospital model, it isn’t necessarily a whole-hospital model of its entire operations and functionality, but could for example be a model for a single component or several integrated components within a hospital.

Although simulation is known to be a useful method for evaluating options for improvements in hospitals, there are some barriers to implementation of models (Harper & Pitt, 2004; Brailsford, 2005). These are often related to the importance of engagement by hospital management (Lane et al, 2003). A useful general discussion of modelling for example in the U.K. healthcare domain, and the resulting challenges for OR/MS, can be found in Proudlove et al (2007).

This paper is organised in two parts. The first part focuses on conceptual modelling and the issues related to model definition, conceptualisation and framing of hospital processes, and data requirements. In addition, some ideas about the level of detail and level of generality are presented. The second part of the paper is devoted to simulation methodologies. Three methods are evaluated in the hospital modelling context, namely: Discrete Event Simulation (DES), System Dynamics (SD), and Agent-Based Simulation (ABS). A hypothetical hospital system is defined and modelled using each of these methods.

Part 1: Conceptual modelling

Conceptual modelling is a blueprint of the model that is to be built and is ideally independent from simulation software. Robinson (2008) defines a conceptual model as ‘non-software specific description of the computer simulation model’. This definition suggests that once a conceptual model is built, a computer model can be developed using available simulation software. On the other hand, Pidd (2004) argues that, in most of today's simulation software, there is capability of constructing a conceptual model on the go, while the modeller builds the actual simulation. Users of simulation software can at least build a flow diagram or a process diagram with a drag and drop from already defined simulation building blocks. As indicated in these definitions, a conceptual model is independent from simulation software; however, although not mentioned in the literature, a conceptual model is dependent on the simulation methodology. An SD modeller, for example, is likely to build a conceptual model differently from a DES or ABS modeller. This is because modellers tend to think in terms of the simulation methodology. Each methodology sees the world differently, as will be discussed later in this paper; for example, a patient is an ‘entity’ in DES, but an ‘agent’ in ABS. It is therefore natural that the differences between the chosen simulation methodologies affect the conceptual model.

Regardless of the simulation methodology adopted, the process of conceptual modelling should come before the model building (Pidd, 2004). A conceptual model helps the modeller to develop an understanding of the problem situation, to determine the modelling objectives and to identify the system's boundaries, inputs, outputs, and constructing elements and their interactions. Once these specifications are on hand, a model is easier to build. However, these specifications may also change during the model building, because the modeller may realise that something is missing or misunderstood once they have started modelling. This suggests that conceptual model is an ongoing process throughout the entire simulation project.

Although it makes sense to build a conceptual model before building a simulation model, there is no consensus on how a model is built, what instruments are used for it, and how it is represented. Robinson (2004) suggests four methods of representation in common use: component list, process flow diagram, logic flow diagram, and activity cycle diagram. On the other hand, Onggo (2009) presents a methodology for unified conceptual model representation. When the focus is to model patient processes in a hospital, process flow diagrams are the best choice since they are easy to build, can be better understood, and a good way of communication between experts and non-experts.

Conceptual modelling for hospital simulations

Depending on the scale of the hospital simulation project the modeller is engaged in, the most difficult problem is to tackle complexity. In fact, this is true for any simulation project, and conventional rules (Henriksen, 2008) can be applied to a hospital's context. More specifically, hospitals could be viewed as simple input–output systems whereby patients arrive from different sources, take different treatment routes, and are discharged. This extremely simple representation is, however, typically insufficient for understanding real-world hospital complexity. One of the ways to reduce the complexity is to model the system in question in a ‘divide and conquer’ manner (Pidd, 2004). One possible classification of hospital units could be a functional division of units. Modelling these units to form a hospital model is more manageable than considering the hospital as one whole unit. This still holds true if you are to build only one unit of a hospital given that there may still be functional divisions within that unit. For example, in an Emergency Department (ED) context, reception could be thought of as a sub-unit, medical test facilities as another etc.

Aggregation is another method that could be employed to reduce complexity. For example, operating rooms and anaesthetics services could be represented implicitly under specialist care services, since the use of operating room capacity is a function of specialist care that is constrained by the number of surgeon teams and number of beds.

A simple process flow of a hospital, with its component units, inputs, and outputs is illustrated in Figure 1. It must be emphasised that this is a very simple possible representation and is not sufficient for representing the full content of a simulation model, but it is an attempt to simplify the complexity involved. Simple diagrams such as these are useful starting points.

Figure 1
figure 1

A possible high-level representation of a hospital.

Full size image

Framing and level of detail

Hospitals are complex organisations, and therefore a simulation model that includes all services provided by a hospital is unlikely to be feasible to build. For a simulation modeller, the main task is to reduce the complexity to a level at which modelling objectives can be achieved.

Within a hospital, there is a range of services provided that is directly or indirectly related to patient care. The modeller's task is to choose which of these services and activities are to be modelled, based on the objectives of the simulation project. The frame drawn specifies the model boundaries. However, there are two important points regarding these services. First, although some of these services work independently, most interact with each other, and therefore they are dependent on other services. For example, an ED may interact with radiology and laboratory departments, and outpatient clinics with operating rooms (patients seen in clinic may subsequently need surgery). Second, some services are shared by specialist care provider units in hospital, and therefore the performance of one unit may affect another's performance. For example, an inefficient pharmacy may eventually affect the length of stay of patients on wards, which in turn may affect planned surgery patients’ waiting times and cancellations. Because of shared resources, shortfalls in one service may have knock-on effect to other services. One of the grand challenges of hospital modelling is the interactions between services and activities.

For a modeller, it is important to link the services provided with physical activities and units in hospital since a patient will be represented by an entity and flows of entities, or in other words patient flows will be the main emphasis in the simulation model. Some services have their own dedicated physical units, such as ED, pharmacy, and laboratory, but some take place elsewhere. For example, general surgery beds may be located in wards A and B, urology beds in ward D, and so on. It is also worth noting that these services require different types of resources, including humans, beds, and equipment.

It is recommended that from time to time the modeller remind themselves of what will be modelled. Of course, the answer to this question is that what is to be modelled is determined by the objectives of the study. This will be the most important point in the study since it will also determine the level of detail in the model. Include only what you need as this will save time and effort; more detail means more time to add to the model and more data to analyse. Draw a frame and concern yourself only with what is inside of the frame.

Data requirements

To build credible models, reasonable data are required. After conceptualisation of the hospital processes, the modeller must consider the inputs. A model's input is also associated with the level of detail of the model. The more detailed the structure of the model is, the more inputs the model requires, and, if data are unavailable, some required details may be compromised.

Although simulation is known to be a flexible tool, and hence it is used frequently in modelling in health care, one of its burdens in applications is the requirement for extensive data (Banks & Carson, 1984). Today's information technology helps modellers with this since extensive amount of data are collected routinely in hospitals, though mostly for financial purposes. However, there is a danger of having this much data; modellers may fall in love with the data (Pidd, 2004). Thoughtful and careful data analysis is an important phase in the development of most simulation models, and is therefore very important when dealing with a complex system such as a hospital.

Modelling a hospital requires information (and data) from various sources such as hospital's information system (sometimes called Patient Administration System), interviews with staff, and personal observations at the hospital. All of these sources help the modeller gain understanding of the important aspects that need to be simulated. Interviews and visits offer a qualitative view, whereas other data offer a quantitative view of the real system. Visits are useful if a general view of the hospital is required and can also fill some information gaps that cannot be explained only with numerical data, such as the outlook of rooms and wards.

Although huge amounts of data are available from today's information systems in health care (hence it may seem like a heaven for simulation modellers), it may be difficult to use these data to estimate system parameters that characterise a hospital. The modeller may use commercial off-the-shelf software to analyse hospital data, or sometimes may consider using specific software developed for this purpose.

Modelling objectives, generality, and level of detail

It seems plausible that there is a relationship between the modelling objectives, the level of detail, and the generality of a model. It also seems plausible that beyond a certain point, the greater the level of detail, the greater the likelihood that a model will cease to be generic. Modelling objectives in a simulation project focus on activities that affect the performance of a hospital as measured in waiting times and this, in turn, has a major influence on the level of detail and, in turn, generality. In Figure 2, these relationships are illustrated. Note that there are different types of generality as indicated in Fletcher & Worthington (2009) and also discussed in Robinson et al (2004); for example, a simulation model might be a reusable model that is properly parameterised to be transferable across different hospitals and then become ‘full model reuse’ and, as suggested, it is less frequently used since the complexity involved is higher than in other alternatives of model reuse.

Figure 2
figure 2

Modelling objectives, generality, and level of detail.

Full size image

Two examples to further explain the relationships in Figure 2 are now provided. First, suppose that a modeller is building an ED model to evaluate patients’ total time and utilisation of doctors in the department. Taking doctors’ travel times into account requires the knowledge of physical attributes of the ED department, such as its layout. Adding the layout detail increases the level of detail but decreases generality (or model reuse) since every ED may have a different physical layout. However, instead of taking physical dimensions into account, staff travel times can be included in staff service times. This decreases the level of detail, in terms of number of inputs required, and increases generality, in terms of less dependence on physical processes.

A second example arises from bed management. A number of ward rounds may occur in inpatient wards during the day and these may affect the length of stay of patients. Suppose that a modeller is simulating the length of stay for inpatient beds to evaluate bed occupancy in a number of wards. Considering the ward-round times in the model causes the level of detail to increase, which requires more inputs and more simulation code in the model. This detail, however, decreases generality since the ward-round procedures are different across the hospitals. However, if the objective is to only simulate the length of stay, the model need not necessarily include the ward-round processes. Instead, it may be reflected implicitly by using stationary distributions disregarding special procedures of ward-round processes. A change in ward-round frequency may require some revisions to the stationary distributions.

Part 2: Simulation methods

There are a number of simulation methods that can be used for building hospital models. In this section, three simulation methods are evaluated – DES, SD, and ABS – by modelling a fictional hospital system. In this system, there are emergency patients who are seen in ED, and then sent to one of three ward groups in the hospital. Electively admitted patients use operating room resources and are then sent to a ward.

Discrete Event Simulation (DES)

DES is the father of all simulation methods and has a long history. DES is used to model systems that change states dynamically, stochastically, in discrete intervals. DES is particularly a powerful method in systems that have a strong queueing structure since it is based on tracking entities that change state in a system. Queues are formed naturally by entities that compete for resources.

DES is attractive for modelling hospitals for the following reasons:

  • Flexibility in responding to scale changes and the level of detail: Most DES software offers great flexibility in supporting the level of detail needed by the modeller. A DES model can be either extremely detailed or less detailed, based on the needs of the modeller. Programming languages, embedded in simulation software, add to this flexibility.

  • Individual patient focus: Movements of individual patients in treatment processes through time can be tracked in a DES model. That is, instead of cohort behaviour of patients, individual patient behaviour can be modelled.

  • Stochastic factors affecting hospital system: There are variations and stochastic elements in most parts of hospitals, such as random emergency arrivals, length of stay of patients, and clinic appointments. These factors can be easily modelled in DES.

  • Ease of use in reusable components: To cope with the complexity in hospital processes, DES also offers modularity in model building, by reusable components ranging from function code or a whole component to represent, for example, a hospital ward.

  • Waiting time-related performance and existence of queues: Complex queueing mechanisms, such as networks of queues and priority queues, can be modelled easily using DES. Moreover, the system to be analysed need not be in steady state, since the snapshots at anytime may help gain insights of the system, although the same is true for SD.

  • Visual representation of patient flows: DES is also used as a communication tool for the users. DES offers visual features, such as animation, which ease understanding of the system.

In Figure 3, a layout for the hospital system described above is given. This diagram is drawn using Arena simulation software (Rockwell Software, 2012) and Arena's diagramming concepts are adopted to represent the conceptual model. Most DES software has similar ‘building blocks’ for building flow-based models; for example, patients are created in an ‘entity creator’ module and passed to a ‘processor’ module. Although these general building blocks can be used to model hospitals, there is some DES software that has hospital-specific features (e.g., templates, objects) for modelling.

Figure 3
figure 3

Arena layout of a DES hospital simulation model.

Full size image

Regardless of DES software selected, a DES model includes the following:

  • entities and attributes,

  • resources,

  • a network of processes, and

  • variables (inputs and outputs).

Entities in a hospital model are generally patients. However, note that depending on the modelling objectives entities might be some other tangible or intangible things such as test samples, prescriptions, or porter requests. Entities flow through a network of processes and change state, as these changes are recorded with attributes. For example, a patient entity will have a date and time attribute to keep track of arrival, admission, and discharge times.

Doctors, nurses, beds, and equipment can be thought as resources that cause entities to change state. Most of the time, we assume that resources are identical and hence they are represented as variables, for example the number of doctors is three and when there is a patient to be seen, dynamically reduce the number of doctors by one. However, if tracking individual behaviours of resources is required, then we create individual objects for each resource, as we did for entities.

To represent the interaction between entities and resources in a DES hospital model, we create a network of processes. By doing this, we are able to tell what will happen when a patient is admitted, which paths will be followed, and what resources are used during patients’ journey. For example, in Figure 3, we say that emergency patients are first seen in ED and a decision is made to admit to a ward. Finally, input and output variables are complementary to the model's logic. Examples of DES hospital models include Harper (2002) and Gunal & Pidd (2011).

System Dynamics (SD)

SD is a popular method for modelling continuous systems and was founded by Forrester (1958). It works based on a set of differential equations that tracks instantaneous changes in a dynamic system. A typical dynamic system can be characterised by interdependence, mutual interaction, information feedback, non-linearity, and circular causality concepts. SD is known to be a method for strategic-level thinking since it looks at systems from higher levels to capture the whole system. It is for this reason that in SD we examine cohorts but not individuals. Aggregating individuals, as discussed in an earlier section, helps a model to be simpler and less detailed.

An SD model has two basic elements: stocks to keep track of levels of ‘things’, and flows for the rate of change of ‘things’. ‘Things’ are the entities in a system that change their states based on the feedback loops from other stocks. The entity concept in SD is different from that in DES since entities represent cohorts but not individuals. Feedback-loop concept resides at the heart of SD and is represented by casual relationships. A casual loop diagram is used to visualise feedback loops that exist in a system. There are two types of feedbacks: positive reinforcement, which represents behaviour of growth, and negative reinforcement, which represents behaviour of balancing (Sterman, 2000). For example, in Figure 4, we say that ‘specialty ward’ affects ‘Bed Occupancy’ positively. It is worth noting that SD not only looks at events but also patterns of behaviour since it evaluates the cause-and-effect relationship in a system. Levels are static and they only change when flows are in action.

Figure 4
figure 4

An example of an SD hospital model.

Full size image

Most of the SD models in the healthcare domain are either used for persuasion purposes or for providing a framework for evaluation of tactical studies, as reported by Dangerfield's (1999) survey on SD applications in a European healthcare context. Dangerfield comments that SD models are more appropriate for studying the interrelationship between elements of healthcare systems. An influential paper by Lane et al (2000) supports this idea; their SD hospital model showed that the link between the ED and other units of a hospital is significant for the whole hospital performance. The model results were not terribly detailed but generated insights for decision makers. Brailsford et al (2010) also agree that SD models tend to look at strategic-level problems, whereas DES is used for operational-level problems.

The diagram in Figure 4 is drawn using PowerSim (PowerSim Software, 2012) SD simulation software and is typical for the hospital system defined above. In this model, emergency and elective patients arrive at hospitals (based on the defined rates) and they accumulate in the ED and Operating Rooms levels. Later, again based on some defined rates, patient levels change within the hospital. Eventually, bed occupancy changes and, in return, this change affects the elective admission rate. The existence of this simple feedback loop is useful for demonstrating this concept.

Agent-Based Simulation (ABS)

ABS is a simulation method for modelling dynamic, adaptive, and autonomous systems. It is employed to discover systems by using ‘deductive’ and ‘inductive’ reasoning. At the core of an ABS model, there are ‘autonomous’ and ‘interacting’ objects called agents. Agents are like entities in a DES model; however, agents are social and interact with others and they live in an environment and their next actions are based on the current state of the environment. In addition, an agent senses its environment and behaves accordingly based on simple rules defined. Agents may have explicit goals to maximise or minimise, may learn and adapt themselves based on experience (which needs memory, e.g., using dynamic attributes). The definition of agent behaviours ranges from simple ‘if-then’ statements to complex models, for example cognitive science or artificial intelligence.

Macal & North (2010) is a classical tutorial for ABS modelling in which the virtue of ABS is best described by a flock simulation model (Boids-Sim by Reynolds 2012). In this model, each agent, for example a bird, has three rules governing its movement: cohesion: move to the average position of its nearby ‘flockmates’, separation: avoid crowding local ‘flockmates’, and alignment: move towards average heading of local ‘flockmates’. By applying these rules to each agent, one might observe group behaviour of a flock. The generalisation of this observation is twofold: first, simple rules might explain complex behaviours and, second, local information is significant in a group's behaviour.

Is a hospital, or a part of it, a system of this kind? If yes, then we can think about ABS for modelling hospitals. The answer to this question is not yet entirely clear, but ABS surely has great potential and is an emerging method for hospital simulation modelling. So far, it has been used for epidemic modelling, for example by Laskowski et al (2011), who model the spread of influenza virus infection within an ED. Their model includes a collection of agents (patients and healthcare workers) and their individual characteristics, behaviours, and interactions on the ED layout. The results suggest that patient-oriented infection control policies tend to have a larger effect than policies that target healthcare workers. In addition, note that, as Siebers et al (2010) suggest, ABS is not yet well adopted by industry and is used primarily by academics.

An ABS model has three elements: agents, which have attributes (static or dynamic levels, e.g. variables) and behaviours (conditional or unconditional actions, e.g., methods); interactions, which define relationships between agents; and environment that are external factors that affect agents and interactions. On the representation of behaviour of an agent, state charts using Unified Modelling Language is one of the methods (Borshchev & Filippov, 2004; Sobolev et al, 2008).

In Figure 5, state charts for three types of agents in our fictional hospital problem are shown. This diagram is an attempt for building an ABS hospital model. A curved rectangle represents a simple state, whereas they may be grouped into composite states. Arrows indicate transition between states and circles with B in the centre show branching in states. For example, when an emergency patient arrives we set the patient to ‘arrived’ state, after being seen by a doctor we set the patient to ‘seen by DR’ state, and subsequently branching to either exit or ‘On Ward’ state.

Figure 5
figure 5

State charts for ABS hospital simulation modelling.

Full size image

A comparison of DES, SD, and ABS

Before concluding this guide, based on the definitions provided above, a comparison of the three simulation methods is given in Table 1. This comparison may be helpful to modellers when choosing the methodology for their particular study.

Table 1 Comparison of Discrete Event Simulation (DES), System Dynamics (SD), and Agent-Based Simulation (ABS)
Full size table

Other modelling considerations

The performance of a hospital simulation model is affected by the number of entities (e.g., patients) processed concurrently. This might be an issue in DES and ABS where state changes of every individual entity are tracked (e.g., in Future Event List in DES and agents’ interactions in ABS). Prolonged run-time of a simulation model may result in having less time for experimentation and consequently being ‘less’ useful for practice. In fact, as Pidd (2004) argues, it is ideal to build simple models that can run fast, so that more time can be dedicated to experimentation and sensitivity analysis. In practice, sometimes this may not be the case. The modeller may end up with a complex model which an experiment may take hours or days. The practical use of such complex models is limited. The author's experience on complex models is that people do not tend to use them because they can hardly understand them, and even if they understand it, it takes a long time to run. The best advice is to find ways to reduce the complexity by using the methods discussed earlier. If this does not work and you have to build a complex model, then the modeller or the analyst may focus on reducing the size of experimentation.

Classical techniques for Verification and Validation (V&V) of simulation models (Sargent, 2007) can be applied to hospital simulation models. However, the V&V process is harder in complex hospital models, especially when such models cover multiple units of a hospital. It is difficult to find an expert who knows everything about the hospital. The consequence of such a case is that the modeller has to engage with multiple experts and viewpoints, for example a clinical manager for the ED unit model, a bed manager for the inpatient wards model etc. Engaging with multiple experts for V&V can help unit-level testing, but it does not necessarily help understand the whole picture. The challenge in terms of V&V is to find experts in hospitals who can see the whole picture. For simple models, though, for example single-unit models, the V&V process is simple since an expert can explain the relationship between inputs and outputs.

Reusing a hospital model in a different hospital requires some customisation. This is particularly a difficult task when someone other than the modeller does it. Why? Because the new user has to learn how the model works first, and then has to enter the input data. Regardless of who the user is, there is no guarantee that a valid model for hospital A will also be valid for hospital B. The new user for hospital B still has to do V&V to make sure that the model behaves plausibly.

Conclusions and final remarks

The purpose of this paper is to highlight the significant areas of interest in hospital simulation modelling. The reader is initially taken through conceptual modelling concepts, since creating a conceptual model can help modellers understand the problem in hand before building a simulation model. As indicated in the first part of this paper, a conceptual model is independent from the simulation software, and therefore once a conceptual model is built it makes building the simulation model that much more straightforward.

Hospitals are complex systems and modelling them requires simplification of their complexity. In this paper, three methods to reduce the complexity are discussed. First, framing hospital operations, to take the modeller's attention to an area where modelling objectives can be achieved; second, to divide the hospital operations into smaller and manageable parts for modelling; and third to aggregate some of the processes in hospitals. The complexity, or the level of detail, is linked with data requirements and the level of generality. As discussed in this paper, level of generality is a significant factor in determining a simulation model's reusability.

In the second part of this paper, three simulation methods are evaluated from hospital modelling perspective. DES is a well-established method in this domain since it is a powerful method for modelling details of systems with strong queueing structure. SD is useful forward strategic-level thinking since we look at the changes in cohorts but not individuals. ABS is an emerging method and a new research area in hospital modelling. In ABS, a model is driven by self-deciding agents and has great potential in this domain.

There is surely a place for hybrid simulation methods. For example, Chahal & Eldabi (2008) discuss the combinations of simulation methods in healthcare domain and propose three types of hybrids: (i) hierarchical mode, where there exist two distinct simulation models working off-line, for example, a DES model feeds an SD model; (ii) process environment, where there are again two distinct models but this time one includes the other, for example a DES model resides inside an SD model; and (iii) integrated mode, where there exists a single model in which multiple simulation methods work inline. Adopting this classification, we see examples of the first and the second types of hybrid modelling, such as for DES and SD, by Brailsford & Hilton (2001) and Brailsford et al (2010), and for DES and ABS by Vieira et al (2010), however, the last one is not yet achieved.

As a final remark, this paper is designed to be a quick-start guide for modellers who want to work in hospital simulation modelling, and does not claim to be a complete guide.