Modeling Patient Flow in an Emergency Department under ...

Citation: Terning, G.; Brun, E.C.;

El-Thalji, I. Modeling Patient Flow in

an Emergency Department under

COVID-19 Pandemic Conditions: A

Hybrid Modeling Approach.

Healthcare 2022, 10, 840. https://

doi.org/10.3390/healthcare10050840

Academic Editor: Marco P. Soares

dos Santos

Received: 29 September 2021

Accepted: 25 April 2022

Published: 2 May 2022

Publisher’s Note: MDPI stays neutral

with regard to jurisdictional claims in

published maps and institutional affil-

iations.

Copyright: © 2022 by the authors.

Licensee MDPI, Basel, Switzerland.

This article is an open access article

distributed under the terms and

conditions of the Creative Commons

Attribution (CC BY) license (https://

creativecommons.org/licenses/by/

4.0/).

healthcare

Article

Modeling Patient Flow in an Emergency Department underCOVID-19 Pandemic Conditions: A Hybrid Modeling ApproachGaute Terning 1,*, Eric Christian Brun 1 and Idriss El-Thalji 2

1 Department of Safety, Economics, and Planning, University of Stavanger, 4036 Stavanger, Norway;[email protected]

2 Department of Mechanical and Structural Engineering and Materials Science, University of Stavanger,4036 Stavanger, Norway; [email protected]

* Correspondence: [email protected]

Abstract: Emergency departments (EDs) had to considerably change their patient flow policies inthe wake of the COVID-19 pandemic. Such changes affect patient crowding, waiting time, and otherqualities related to patient care and experience. Field experiments, surveys, and simulation modelscan generally offer insights into patient flow under pandemic conditions. This paper provides athorough and transparent account of the development of a multi-method simulation model thatemulates actual patient flow in the emergency department under COVID-19 pandemic conditions.Additionally, a number of performance measures useful to practitioners are introduced. A conceptualmodel was extracted from the main stakeholders at the case hospital through incremental elaborationand turned into a computational model. Two agent types were mainly modeled: patient and rooms.The simulated behavior of patient flow was validated with real-world data (Smart Crowding) andwas able to replicate actual behavior in terms of patient occupancy. In order to further the validity, thestudy recommends several phenomena to be studied and included in future simulation models suchas more agents (medical doctors, nurses, beds), delays due to interactions with other departments inthe hospital and treatment time changes at higher occupancies.

Keywords: healthcare; emergency department; patient flow; simulation modeling; agent-basedmodeling; pandemic decision support

1. Introduction

Emergency departments (EDs) are complex and crucial systems for accommodatingpatients in urgent and responsive need of health care [1]. Lately, there has been a partic-ular focus on the ED under COVID-19 pandemic conditions [2], forcing us to rethink itsorganization [3]. Due to the pandemic conditions, EDs have had to adjust their operationsaccording to regulations while cost-effectively managing their resources.

In order to comply with restrictions and guidelines, several management policieshave been imposed simultaneously, e.g., changes in patient arrival handling, priorities ofpatients with suspected virus contamination, structural changes in patient flow, and theuse of available space. Although such measures have put unprecedented strain on thedepartment and its vital resources, they aim to ensure less overcrowding and treatmenttime while keeping the risk of contamination as low as possible.

In the past, ED crowding has been shown to have adverse effects on patient responsetime [4–8]. Overcrowding and treatment time can be regarded as systemic effects ofseveral agent behaviors and multiple operating scenarios, which might be hard to explainby medical staff or revealed by field experiments or surveys. Computer modeling andsimulation, in particular agent-based modeling, can thus be useful, as it allows to modelorganizational participants with their collective behavior [1,9–12]. It can further be usedfor decision support and to evaluate interventions, scenarios, operational risks, and cost-effectiveness of policies.

Healthcare 2022, 10, 840. https://doi.org/10.3390/healthcare10050840 https://www.mdpi.com/journal/healthcare

https://doi.org/10.3390/healthcare10050840


https://creativecommons.org/

https://creativecommons.org/licenses/by/4.0/

https://creativecommons.org/licenses/by/4.0/

https://www.mdpi.com/journal/healthcare

https://www.mdpi.com


https://www.mdpi.com/journal/healthcare

https://www.mdpi.com/article/10.3390/healthcare10050840?type=check_update&version=2

Healthcare 2022, 10, 840 2 of 28

Overall, there is an increasing body of literature on modeling and simulation of EDpatient flow [13,14]. There are several simulation models where the discrete event orsystem dynamics approaches mimic ED patient flow during normal conditions [13]. Suchmodeling and simulation approaches have also been used to model COVID-19 spread andtransmission [4] and mass-vaccination facilities [15]. However, there is an unmet needfor simulation models that mimic, explain, and predict ED patient flow under pandemicconditions while considering multiple agent behaviors [11], a feature not available inthe discrete event or system dynamics approaches. Moreover, there is a lack of studiesdemonstrating rigorous and transparent construction of a conceptual model of an ED,which leads to difficulties for readers to understand, assess and build trust in such models.Furthermore, from a practitioner’s point of view, there are several performance measuresthat ED managers use (such as time to treatment, the average length of stay, % full of triageroom, etc.) that are not yet considered in existing simulation models.

This paper thus aims to answer the following research question:

How can we build a simulation model of the emergency department patient flow duringCOVID-19 pandemic conditions while considering multiple agent behaviors?

In this paper, we present a thorough description of how we developed such a simula-tion model. We first detail how we developed a conceptual model building on systemknowledge and expertise from a case organization. Following that, we show how thisconceptual model was incorporated into a hybrid computational model, where agent-basedmodeling was used to model patient behavior, and discrete event modeling was used tomodel resources (e.g., treatment rooms, triage beds, extra treatment rooms, pre-triage). Themodeling approach we used consisted of (1) case study and systems analysis, (2) concep-tual modeling, (3) computational modeling, and (4) verification and validation. Moreover,the main key performance indicators (KPIs) for patient flow used by practitioners wereintegrated and visualized.

The remainder of this article is organized as follows: the following Materials andMethods section will briefly illustrate the applied four-step simulation modeling process,fundamentals of the main methods used, description of the case study (process, facility),and input data (patient arrival data). Next, the Results section will provide rigorousdocumentation of the conceptual model, including the purpose, KPIs, interfaces, processflows, and sequential interactions between agents. Additionally, the computational modeland a comparison between the simulated and real-world data will be presented. Finally, theDiscussion section will go through the implications and possibilities drawn from the results,and the Conclusions section will state the final, conclusive remarks of the research findings.

2. Materials and Methods

This section will present the modeling methodology and empirical case. First, thesimulation modeling methodology and methods to collect and analyze the model inputsand structure will be presented for both conceptual and computational models. Next,we will present our case organization—the ED of the Stavanger University Hospital inNorway—and the case data that were used to build, validate, and verify the models.

2.1. Simulation Modeling Methodology: Randers’ Model

In the original literature on modeling and simulation, there are several formalizedways of carrying out simulation studies [16]. In this study, we followed the processdefined by Randers’ [17], which divides the process of modeling into four main phases:(1) conceptualization, (2) formulation, (3) testing, and (4) implementation (see Figure 1).

Healthcare 2022, 10, 840 3 of 28

Figure 1. Randers’ modeling methodology.

Randers’ structure was chosen because it focuses on model purpose rather than asingular and finite problem as a starting predicate for the model. More importantly, Ran-ders’ approach is perhaps the most paradigm-independent among the available modelingprotocols from the research literature. Therefore, in the context of a hybrid model whichcombines two or more paradigms (discrete-event and agent-based modeling) into one sim-ulation study, Randers’ protocol was considered the most appropriate. The methodologicalaspects that will be given primary focus hereunder are those of the “conceptualization”and “formulation” steps. The last two steps were out of scope for this paper but will bepursued by the authors in a subsequent paper.

2.1.1. Conceptual Modeling

In a previous paper [18], we developed and presented a general model for an ED,mimicking the patient flow process before the pandemic situation. In this study, the modelhas been expanded and presented in further detail to cover patient regimens during apandemic situation. Like the general model, this model expansion was carried out incollaboration with the case organization through several meetings. As recommended inthe literature, this stage was started before any computational modeling was made [19].

The conceptual modeling followed the four steps of Albin’s [20] process for construct-ing rigid conceptual models, shown in Figure 2. The four steps are: “Step 1–Define thepurpose of the model”, “Step 2–Define the boundary and key variables”, “Step 3–Describethe system behavior”, and “Step 4–Describe the basic mechanisms of the system”. Althoughthe steps here are numbered from 1 to 4, it does not imply a necessity for a strict chronologi-cal enactment. The overall simulation modeling process is a recursive and iterative processthat will be developed in a back-and-forth manner, an issue we will revert to in Section 2.3.4.

Healthcare 2022, 10, x 3 of 29

Figure 1. Randers’ modeling methodology.

Randers’ structure was chosen because it focuses on model purpose rather than a singular and finite problem as a starting predicate for the model. More importantly, Rand-ers’ approach is perhaps the most paradigm-independent among the available modeling protocols from the research literature. Therefore, in the context of a hybrid model which combines two or more paradigms (discrete-event and agent-based modeling) into one simulation study, Randers’ protocol was considered the most appropriate. The methodo-logical aspects that will be given primary focus hereunder are those of the “conceptual-ization” and “formulation” steps. The last two steps were out of scope for this paper but will be pursued by the authors in a subsequent paper.

2.1.1. Conceptual Modeling In a previous paper [18], we developed and presented a general model for an ED,

mimicking the patient flow process before the pandemic situation. In this study, the model has been expanded and presented in further detail to cover patient regimens during a pandemic situation. Like the general model, this model expansion was carried out in col-laboration with the case organization through several meetings. As recommended in the literature, this stage was started before any computational modeling was made [19].

The conceptual modeling followed the four steps of Albin’s [20] process for con-structing rigid conceptual models, shown in Figure 2. The four steps are: “Step 1–Define the purpose of the model”, “Step 2–Define the boundary and key variables”, “Step 3–De-scribe the system behavior”, and “Step 4–Describe the basic mechanisms of the system”. Although the steps here are numbered from 1 to 4, it does not imply a necessity for a strict chronological enactment. The overall simulation modeling process is a recursive and iter-ative process that will be developed in a back-and-forth manner, an issue we will revert to in Section 2.3.4.

For each step we used a system engineering tool to aid communication with the case organization and to help analyze and understand the processes together with the stake-holders. The steps and their corresponding tools are shown in Figure 2.

Figure 2. Model conceptualization process defined by Albin [20] and the associated systems engi-neering tools.

The following subsections describe these four systems engineering tools.

2.1.2. Purpose Tree A purpose tree, shown in Figure 3, is an illustrative tool representing the purpose

behind the simulation model of interest and its measurable key performance indicators

Figure 2. Model conceptualization process defined by Albin [20] and the associated systems engi-neering tools.

For each step we used a system engineering tool to aid communication with thecase organization and to help analyze and understand the processes together with thestakeholders. The steps and their corresponding tools are shown in Figure 2.

The following subsections describe these four systems engineering tools.

2.1.2. Purpose Tree

A purpose tree, shown in Figure 3, is an illustrative tool representing the purposebehind the simulation model of interest and its measurable key performance indicators(KPIs). Different versions of tree structures are commonly used in management disciplines,e.g., work breakdown structure in the project management discipline, and organization

Healthcare 2022, 10, 840 4 of 28

charts. The purpose tree is used similarly to elaborate the fundamental aim of the modeland decompose it to achieve an overview of the model purpose and what system elementsthe model purpose builds upon.


(KPIs). Different versions of tree structures are commonly used in management disci-plines, e.g., work breakdown structure in the project management discipline, and organi-zation charts. The purpose tree is used similarly to elaborate the fundamental aim of the model and decompose it to achieve an overview of the model purpose and what system elements the model purpose builds upon.

Figure 3. A generic purpose tree and its KPIs decomposition.

2.1.3. Interface Diagram The interface diagram, shown in Figure 4, also known under the name “N2-matrix”,

visually illustrates the interfaces between involved entities or agents, as well as external inputs. The principal diagonal (Principal diagonal: the diagonal going from the upper-most left corner, ‘Subssytem 1′ in Figure 4, to the lowermost right corner, ‘Subssystem 3′ in Figure 4.) in the matrix constitutes different subsystems. The remaining squares in the matrix constitute interfaces between the various subsystems. The blocks above the princi-pal diagonal constitute downstream interfaces, and the blocks below the principal diago-nal constitute interface feedback upstream in the system. The top row of the matrix con-tains descriptions of subsystem input from external parts. The rightmost column of the matrix illustrates the output from the subsystems.

The principal diagonal of the N2-matrix may be procedural steps of a process, or a distinct group of assets used by system agents. Figure 4 shows a generic interface diagram where subsystems 1–3 are considered. Like the purpose tree, this tool is flexible as it can be used at several different units (e.g., health, patient, medicine, information) and levels (e.g., health trust, hospital, department, ward, treatment room) of analysis. For multi-pur-pose models, one can construct one diagram for each purpose and analyze them sepa-rately.

Figure 4. Generic interface diagram.


2.1.3. Interface Diagram

The interface diagram, shown in Figure 4, also known under the name “N2-matrix”,visually illustrates the interfaces between involved entities or agents, as well as externalinputs. The principal diagonal (Principal diagonal: the diagonal going from the uppermostleft corner, “Subssytem 1” in Figure 4, to the lowermost right corner, “Subssystem 3” inFigure 4.) in the matrix constitutes different subsystems. The remaining squares in thematrix constitute interfaces between the various subsystems. The blocks above the principaldiagonal constitute downstream interfaces, and the blocks below the principal diagonalconstitute interface feedback upstream in the system. The top row of the matrix containsdescriptions of subsystem input from external parts. The rightmost column of the matrixillustrates the output from the subsystems.


(KPIs). Different versions of tree structures are commonly used in management disci-plines, e.g., work breakdown structure in the project management discipline, and organi-zation charts. The purpose tree is used similarly to elaborate the fundamental aim of the model and decompose it to achieve an overview of the model purpose and what system elements the model purpose builds upon.


2.1.3. Interface Diagram The interface diagram, shown in Figure 4, also known under the name “N2-matrix”,

visually illustrates the interfaces between involved entities or agents, as well as external inputs. The principal diagonal (Principal diagonal: the diagonal going from the upper-most left corner, ‘Subssytem 1′ in Figure 4, to the lowermost right corner, ‘Subssystem 3′ in Figure 4.) in the matrix constitutes different subsystems. The remaining squares in the matrix constitute interfaces between the various subsystems. The blocks above the princi-pal diagonal constitute downstream interfaces, and the blocks below the principal diago-nal constitute interface feedback upstream in the system. The top row of the matrix con-tains descriptions of subsystem input from external parts. The rightmost column of the matrix illustrates the output from the subsystems.

The principal diagonal of the N2-matrix may be procedural steps of a process, or a distinct group of assets used by system agents. Figure 4 shows a generic interface diagram where subsystems 1–3 are considered. Like the purpose tree, this tool is flexible as it can be used at several different units (e.g., health, patient, medicine, information) and levels (e.g., health trust, hospital, department, ward, treatment room) of analysis. For multi-pur-pose models, one can construct one diagram for each purpose and analyze them sepa-rately.



The principal diagonal of the N2-matrix may be procedural steps of a process, or adistinct group of assets used by system agents. Figure 4 shows a generic interface diagramwhere subsystems 1–3 are considered. Like the purpose tree, this tool is flexible as it can beused at several different units (e.g., health, patient, medicine, information) and levels (e.g.,health trust, hospital, department, ward, treatment room) of analysis. For multi-purposemodels, one can construct one diagram for each purpose and analyze them separately.

2.1.4. Flow Chart

A flow chart, shown in Figure 5, is a high-level description of the system’s behavior. Itdescribes the process in terms of connected steps necessary to accomplish a task. In ourstudy, the flow chart representation was divided into states that coincide with the mostimportant and distinct processes the patient goes through in the ED.

Healthcare 2022, 10, 840 5 of 28


2.1.4. Flow Chart A flow chart, shown in Figure 5, is a high-level description of the system’s behavior.

It describes the process in terms of connected steps necessary to accomplish a task. In our study, the flow chart representation was divided into states that coincide with the most important and distinct processes the patient goes through in the ED.

Figure 5. A generic flow chart of a process containing three linearly connected subprocesses.

2.1.5. Sequence Diagram The sequence diagram, shown in Figure 6, is a detailed-level description that shows

the entity/agent interactions arranged in a time sequence. Complex social systems, e.g., EDs, rarely have a linear progression through the system’s different subprocesses. The system may have several feedback loops, resulting in a plethora of different system reali-zations, depending on specific details of the agent traveling through the system.

Figure 6. Simple illustration of a sequence diagram progressing through three subprocesses.

The sequence diagram provides a systemic way to capture, analyze, and discuss how different system agents progress throughout the various subprocesses of the system. A fully detailed sequence diagram thus visualizes all the unique passages an agent can take through the system in a more detailed manner than a flow chart can illustrate.

2.2. Computational Modeling–Hybrid Simulation Modeling Following the conceptualization step, the next step in the overall modeling was to

perform the Formulation step, as shown in Figure 7. The formulation is about structuring the conceptual model into software by using a computer programming language. A com-putational model will thus be another layer of codification on the conceptual model and be significantly contingent on the software’s codification abilities (i.e., a meta-model).

Figure 7. In the process of modeling, the next step after the conceptual modeling is formulation.

In order to carry out the modeling, it was found necessary to use an agent-based simulation in order to be able to adequately implement the complex patient flow logic of the case organization. However, a pure agent-based modeling approach was found to be insufficient when we were to model the resources and their use by the patient agents. Some agents would behave dominantly in a discrete-event manner, e.g., room seizing and releasing.


2.1.5. Sequence Diagram

The sequence diagram, shown in Figure 6, is a detailed-level description that shows theentity/agent interactions arranged in a time sequence. Complex social systems, e.g., EDs,rarely have a linear progression through the system’s different subprocesses. The systemmay have several feedback loops, resulting in a plethora of different system realizations,depending on specific details of the agent traveling through the system.














The sequence diagram provides a systemic way to capture, analyze, and discuss howdifferent system agents progress throughout the various subprocesses of the system. Afully detailed sequence diagram thus visualizes all the unique passages an agent can takethrough the system in a more detailed manner than a flow chart can illustrate.

2.2. Computational Modeling–Hybrid Simulation Modeling

Following the conceptualization step, the next step in the overall modeling was toperform the Formulation step, as shown in Figure 7. The formulation is about structuringthe conceptual model into software by using a computer programming language. Acomputational model will thus be another layer of codification on the conceptual modeland be significantly contingent on the software’s codification abilities (i.e., a meta-model).














In order to carry out the modeling, it was found necessary to use an agent-basedsimulation in order to be able to adequately implement the complex patient flow logicof the case organization. However, a pure agent-based modeling approach was found tobe insufficient when we were to model the resources and their use by the patient agents.Some agents would behave dominantly in a discrete-event manner, e.g., room seizingand releasing.

This required us to expand from strictly agent-based modeling (ABM) to a hybridcombination by including discrete event simulation (DES) model elements. To implementthis type of hybrid model that allowed for the utilization of both ABM and DES, we usedAnyLogic 8 Personal Learning Edition 8.7.2.

Agent behavior was defined using the statechart, which is an integrated feature inAnyLogic describing agent behavior. A statechart is a blueprint for the behavior of eachagent. The statechart is common for every agent (of the same type) that becomes initiatedinto the model. However, every patient will each have their individual realization of

Healthcare 2022, 10, 840 6 of 28

the statechart. The resource allocation logic, which included elements of discrete-eventmodeling, was codified by using the “process modeling” flow chart in AnyLogic.

In making the model, we collected data about how the emergency department in ourcase study normally works in a pre-pandemic situation. This model served as a basis forthe model development. We then added the complexities introduced by the pandemicrestrictions, e.g., a waiting zone, extra treatment rooms, and the associated procedures.

We then validated the model in two manners: Firstly, we set the patient contaminationrate (PCR) to 0% to simulate a pre-pandemic situation, ran the model with real-life pre-pandemic patient arrival data and compared the output of the run with real-life pre-pandemic patient crowding data.

Secondly, we ran the model with peri-pandemic patient arrival data, using a PCR setto 30%, since this was the actual patient contamination rate in the real peri-pandemic data,and again compared to the real-life peri-pandemic patient crowding data.

2.3. Case Study: ED of Stavanger University Hospital

In order to obtain a good understanding of the studied ED, three aspects will bepresented in this section:

(1). The facility and layout to understand the capacity, routes, and waiting zones.(2). The data management systems that store and visualize the patient arrival and crowd-

ing rates, (in this case, two systems called Meona and Smart Crowding, respectively).(3). The involved experts who provided descriptions of operations, policies, and expected

performance measures.

2.3.1. Facility and Layout

The case subject of this study is the ED of the public hospital Stavanger UniversityHospital, located in the city of Stavanger in the south-western part of Norway. The hospitalis a large hospital with more than 500 beds, over 7800 employees, and 33 wards serving369,000 city inhabitants. The case ED serves approximately 35,000 patients each year,averaging around a hundred patients daily. During normal circumstances, the case ED isequipped with 13 treatment rooms, 11 triage beds, and seven medical doctors (1 foundationhouse officer, three surgeons, two neurologists, and one orthopedist) [21–24].

2.3.2. Case Data

Three categories of data were utilized in this study, displayed in Figure 8; (1) data usedas inputs to run the simulation model, (2) data used to construct the simulation model, and(3) data used to validate the simulation output. Figure 8 shows a schematic overview of thecase data categories.


Figure 8. The data categories used in constructing, running, and validating the simulation model.

The first category—data used for simulation input—consisted of anonymized patient arrival time registrations for patients in the ED. These data were pre-existing data rec-orded independently of this study and were thus secondary data. The dataset we utilized was collected from a local database in an information and communication technology (ICT) system called Meona at the case hospital. Each record of data in Meona represented the time of arrival to the ED of one new patient. The number of data entries on a particular day in Meona thus represented the number of patients arriving at the ED that day.

The second category—data used for simulation model developments—was mainly obtained through interviews with knowledgeable stakeholders from the case organiza-tion. This category of data represented information about the patent flow process in the ED. These data were thus primary qualitative data. The steps in the patient flow process, and the criteria for the choice of alternative routes through the system, were explained to us by a group of key stakeholders at the case hospital.

Furthermore, we were given a blueprint of the layout of the ED, shown in Figure 9, which served as an outset for the construction of the computational model.

Figure 9. Blueprint of the studied ED before the pandemic measures was put in place.


The first category—data used for simulation input—consisted of anonymized patientarrival time registrations for patients in the ED. These data were pre-existing data recorded

Healthcare 2022, 10, 840 7 of 28

independently of this study and were thus secondary data. The dataset we utilized wascollected from a local database in an information and communication technology (ICT)system called Meona at the case hospital. Each record of data in Meona represented thetime of arrival to the ED of one new patient. The number of data entries on a particular dayin Meona thus represented the number of patients arriving at the ED that day.

The second category—data used for simulation model developments—was mainlyobtained through interviews with knowledgeable stakeholders from the case organization.This category of data represented information about the patent flow process in the ED.These data were thus primary qualitative data. The steps in the patient flow process, andthe criteria for the choice of alternative routes through the system, were explained to us bya group of key stakeholders at the case hospital.

Furthermore, we were given a blueprint of the layout of the ED, shown in Figure 9,which served as an outset for the construction of the computational model.



The first category—data used for simulation input—consisted of anonymized patient arrival time registrations for patients in the ED. These data were pre-existing data rec-orded independently of this study and were thus secondary data. The dataset we utilized was collected from a local database in an information and communication technology (ICT) system called Meona at the case hospital. Each record of data in Meona represented the time of arrival to the ED of one new patient. The number of data entries on a particular day in Meona thus represented the number of patients arriving at the ED that day.

The second category—data used for simulation model developments—was mainly obtained through interviews with knowledgeable stakeholders from the case organiza-tion. This category of data represented information about the patent flow process in the ED. These data were thus primary qualitative data. The steps in the patient flow process, and the criteria for the choice of alternative routes through the system, were explained to us by a group of key stakeholders at the case hospital.

Furthermore, we were given a blueprint of the layout of the ED, shown in Figure 9, which served as an outset for the construction of the computational model.

Figure 9. Blueprint of the studied ED before the pandemic measures was put in place. Figure 9. Blueprint of the studied ED before the pandemic measures was put in place.

Using the blueprint eased the process of mapping out the patient movement path andlaying out the resources. In addition to being informative in the model layout, this wasalso an important part of data collection to understand how the ED operates. For example,knowing the spatial positioning of the resources was necessary for ensuring that the modelrepresented the actual system. Additionally, it directly revealed how many resources therewere, e.g., number of treatment rooms which were limited to 13, and amount of triage bedslimited to 11.

Additionally, we were given a walkthrough inside the case ED to observe the dailyoperation and obtain an understanding the workings of the real system.

For the final category—data used for the simulation output—we used secondarydata retrieved from an ICT system at the hospital called SmartCrowding for verificationand validation. These data consisted of graphs showing the patient flow developmentthroughout the time of the days. Patient flow development was represented through anumber of measures, such as time of day when crowing reached a certain percentage ofroom capacity, peak crowding level, etc. Thus, while the data from Meona represented

Healthcare 2022, 10, 840 8 of 28

the actual arrival of patients to the ED on a particular day, the data from SmartCrowdingshowed the actual resulting patient flow development on the same day.

2.3.3. Arrival and Crowding

The set of real-life numerical data we were given, gathered from Meona, consisted ofregistration times for each patient’s arrival at the ED. The record of the data spanned overtwo full days, altogether 48 h. Our informants selected these two days as two representativedays. These two days of data collection were two regular separate working days at thehospital (i.e., not in sequence) in the pre-pandemic situation, i.e., prior to the COVID-19pandemic onset. The crowding data for the same two days, gathered from SmartCrowding,are shown in Table 1a.

Table 1. a. Patient crowding in the ED gathered from Smart Crowding for two regular days in apre-pandemic situation. b. Patient crowding in the ED gathered from Smart Crowding for twoseparate days in a peri-pandemic situation.

a

Day 1 Day 2 †

Rea

ldat

a


Real

dat

a

b

Day 1 Day 2 †

Real

dat

a

† Graph ‘Day 2′ is not immediately the following day after ‘Day 1′ as the naming may suggest.

We were also given a similar set of real-life numerical data gathered from Meona during the pandemic, i.e., in a peri-pandemic situation, which consisted of registration times for patients arriving at the ED in the case hospital. Data spanning over two separate full days were selected also from this dataset. The real-life crowding data for the same two days, gathered from SmartCrowding, are shown in Table 1b.

2.3.4. Operations and Experts’ Descriptions Dialog with a case organization is essential for a modeling process to succeed and

benefit the system stakeholders. Accordingly, a significant portion of the data for this study was the qualitative data gathered through talking with the organization’s stake-holders. These individuals are personnel that work closely with the ED on a day-to-day basis.

The communication occurred as a mix of meetings on both a scheduled basis and an on-need basis for clarification in the model development. Development of both the con-ceptual and the computational model required intensive gathering of qualitative data by direct communication with the case organization. Testing of the computational model would quickly reveal misunderstandings in the conceptual modeling, resulting in an iter-ative development process in dialog with the stakeholders, as we indicated in Section 2.1.1. The development process, shown in the overall modeling methodology in Figure 2, was, thus, in practice, a nonlinear process, where the steps had to be revisited continually and iteratively throughout the lifetime of the model’s development process.

3. Results Applying Randers’ model of simulation modeling [17] allowed us to obtain three

main results: (1) The conceptual model that represents the real-world structure and context of the ED

during both pre-pandemic and peri-pandemic status. (2) The computational model that mimics the patient flow behavior in the ED during both

the pre-pandemic and peri-pandemic situations.


Rea

l dat

a

b

Day 1 Day 2 †

Real

dat

a










b

Day 1 Day 2 †

Rea

ldat

a


Rea

l dat

a

b

Day 1 Day 2 †

Real

dat

a











Rea

l dat

a

b

Day 1 Day 2 †

Real

dat

a










† Graph “Day 2” is not immediately the following day after “Day 1” as the naming may suggest.

We were also given a similar set of real-life numerical data gathered from Meonaduring the pandemic, i.e., in a peri-pandemic situation, which consisted of registrationtimes for patients arriving at the ED in the case hospital. Data spanning over two separatefull days were selected also from this dataset. The real-life crowding data for the sametwo days, gathered from SmartCrowding, are shown in Table 1b.

2.3.4. Operations and Experts’ Descriptions

Dialog with a case organization is essential for a modeling process to succeed andbenefit the system stakeholders. Accordingly, a significant portion of the data for this studywas the qualitative data gathered through talking with the organization’s stakeholders.These individuals are personnel that work closely with the ED on a day-to-day basis.

The communication occurred as a mix of meetings on both a scheduled basis and an on-need basis for clarification in the model development. Development of both the conceptual

Healthcare 2022, 10, 840 9 of 28

and the computational model required intensive gathering of qualitative data by directcommunication with the case organization. Testing of the computational model wouldquickly reveal misunderstandings in the conceptual modeling, resulting in an iterativedevelopment process in dialog with the stakeholders, as we indicated in Section 2.1.1.The development process, shown in the overall modeling methodology in Figure 2, was,thus, in practice, a nonlinear process, where the steps had to be revisited continually anditeratively throughout the lifetime of the model’s development process.

3. Results

Applying Randers’ model of simulation modeling [17] allowed us to obtain threemain results:

(1) The conceptual model that represents the real-world structure and context of the EDduring both pre-pandemic and peri-pandemic status.

(2) The computational model that mimics the patient flow behavior in the ED duringboth the pre-pandemic and peri-pandemic situations.

(3) The output (the simulated behaviors) of the computational model, where both real(from the patient crowding data) and simulated behavior are compared.

3.1. Result from Conceptual Modeling of the Case

Performing the conceptual modeling process described in Section 2.1.1 and Figure 2,resulted in a model including the following elements:

(1) Definition of the model purpose and twelve performance measures that the simulationmodel should be able to perform.

(2) Definition of model boundary and key variables, including critical interfaces between thelayout agents of the ED (pre-treatment, triage, treatment rooms, waiting-zones, discharge).

(3) Description of the system behavior, including interactions between patient agents(ordinary and contaminated patient) and layout agents to describe the room seiz-ing/releasing process, and

(4) Description of the basic mechanisms of the system.

3.1.1. Step 1—Definition of the Purpose of the Model

The model’s primary purpose was to model the patient flow behavior in the ED totest several policies and interventions in a virtual and low-cost environment. From anoperational perspective, the patient flow could be divided into three main segments, asillustrated in Figure 10: patient inflow, patient throughput within the department, andpatient output.


(3) The output (the simulated behaviors) of the computational model, where both real (from the patient crowding data) and simulated behavior are compared.

3.1. Result from Conceptual Modeling of the Case Performing the conceptual modeling process described in Section 2.1.1 and Figure 2,

resulted in a model including the following elements: (1) Definition of the model purpose and twelve performance measures that the simula-

tion model should be able to perform. (2) Definition of model boundary and key variables, including critical interfaces between

the layout agents of the ED (pre-treatment, triage, treatment rooms, waiting-zones, dis-charge).

(3) Description of the system behavior, including interactions between patient agents (or-dinary and contaminated patient) and layout agents to describe the room seizing/re-leasing process, and

(4) Description of the basic mechanisms of the system.

3.1.1. Step 1—Definition of the Purpose of the Model The model’s primary purpose was to model the patient flow behavior in the ED to

test several policies and interventions in a virtual and low-cost environment. From an op-erational perspective, the patient flow could be divided into three main segments, as il-lustrated in Figure 10: patient inflow, patient throughput within the department, and pa-tient output.

Figure 10. Purpose tree breakdown structure and KPIs for ED operations.

Implementation of the patient flow key performance indicators Performance indicators were selected and constructed within the simulation soft-

ware to measure relevant aspects of patient flow within the ED. The following comprises a brief description of the KPI implementation as well as their mathematical equations (main contributor of this paper is the author of these equations), illustrating the calcula-tions programmed into the simulation model. 1. Time to treatment (TTT) [h/pt]: This KPI tracks the time spent on all the activities

prior to the treatment. Then, it is calculated as an average. TTT is calculated for all the patients (Tot.), the patients that are suspected to be pathogen contagious (Cont.), and the patients that are found likely not to be pathogen carrying (Ord.). a·b

TTT(t) = 1

Nout(t) ∙� �PTime entering TR(n) − PTime entering ED(n)�Nout(t)

n = 0

∀ P ∈ �P (0), … , P�Nout(t)��

𝑃𝑃(𝑛𝑛)–nth patient agent, 𝑃𝑃𝑥𝑥(𝑛𝑛)–parameter x of the nth patient agent, 𝑁𝑁𝑖𝑖𝑖𝑖(𝑡𝑡)–Number of patients who entered the ED at time t, 𝑁𝑁𝑜𝑜𝑜𝑜𝑜𝑜(𝑡𝑡)–Number of patients left the ED at time t, 𝑡𝑡–

Figure 10. Purpose tree breakdown structure and KPIs for ED operations.

Implementation of the Patient Flow Key Performance Indicators

Performance indicators were selected and constructed within the simulation softwareto measure relevant aspects of patient flow within the ED. The following comprises abrief description of the KPI implementation as well as their mathematical equations (main

Healthcare 2022, 10, 840 10 of 28

contributor of this paper is the author of these equations), illustrating the calculationsprogrammed into the simulation model.

1. Time to treatment (TTT) [h/pt]: This KPI tracks the time spent on all the activitiesprior to the treatment. Then, it is calculated as an average. TTT is calculated for allthe patients (Tot.), the patients that are suspected to be pathogen contagious (Cont.),and the patients that are found likely not to be pathogen carrying (Ord.).

TTT(t) = 1Nout(t)

·∑Nout(t)n =0

(PTime entering TR(n)− PTime entering ED(n)

)∀ P ∈ [P (0), . . . , P(Nout(t))]

P(n)–nth patient agent, Px(n)–parameter x of the nth patient agent, Nin(t)–Number ofpatients who entered the ED at time t, Nout(t)–Number of patients left the ED at time t,t–time; acting as the independent discrete-time variable going from 00:00:00 to 23:59:59,running in increments of seconds.

2. The average length of stay (ALOS) [h/pt]: This calculates the average time the patientsspend in the ED. This measure can also be calculated individually for the differentpatient populations.

ALOS(t) = 1Nout(t)

·∑Nout(t)n =0

(PTime leaving ED(n)− PTime entering ED(n)

)∀ P ∈ [P (0), . . . , P(Nout(t))]


3. Crowding [%]: Crowding is defined as the number of patients simultaneously stayingwithin the ED facility, i.e., prevalence. This measure tracks how long the crowding inthe ED is above certain predefined levels and divides it by the total amount of timepassed. The crowding levels are selected according to the case organization’s plan forhigh activity, 15, 20, and 30.

Crowding>15(t) =∑t

n =0 u(t)t

· 100%, u(t) ={

1 if (Nout(t)− Nin(t)) > 150 otherwise


4. Peak crowding: This measure is intended to present information on how manypatients are present at the peak of the day.

Peak crowding(t) = max[Nout (t)− Nin(t)]∀ t ∈ [0, t]


5. Time of peak [time]: This measure states records at which the previously mentionedpeak of crowding occurs.

6. Time start use [time]: This measure keeps track of when the different resources startbeing used within the ED. Measures were chosen to be tracking the use of the extratreatment rooms (E.Tr.), triage (Tri.), and the waiting zone (WZ).

Healthcare 2022, 10, 840 11 of 28

7. Time in use [%]. This estimates the amount of time the resources are used as aproportion of the total time simulated. Equation (5) shows the calculation for the extratreatment rooms (E.Tr.).

Time in useE.Tr.(t) =∑t

n=0 u(t)t

· 100%, u(t) ={

1 if [email protected].(t) > 00 otherwise


8. Time full [time]: Similar to the “time start use”, this measure keeps track of when theresource first reached its full capacity (i.e., there was no more left of the resource for anew patient for the first time).

9. Waiting time pr pts [h/pt]: This measure calculates the average waiting time in WRacross the different patient agent groups.

10. Times TR blocked for contaminated patients [#]: This measure keeps track of thenumber of times a patient with virus suspicion is blocked from going directly to atreatment room after undergoing the pre-triage screening. Such a blockage occursunder the following conditions: (1) all the ordinary and all the extra treatment roomsare fully utilized, and (2) no ordinary patients can leave their treatment room, eitherdue to the lack of a waiting zone available or because none of the patients currently inthe treatment rooms have stayed their minimum amount of time in their treatmentrooms. Therefore, this measure is critical, because if this condition occurs, it meansthat a potentially contaminated patient has to wait, which poses an increased riskof contamination.

11. Times TR (WZ) seized [#]: Similar to the previous, this one is a pure counter. Thismeasure counts the number of times a treatment room (or waiting zone) is seized by apatient agent. The main reason for keeping track of this is that seizing rooms is workintensive. Rooms need to be set up and sanitized and thus constitute an economicand resource burden both directly and indirectly. Additionally, besides the pure laboraspect, the management of seizing and releasing may cause an error and be costly. Inaddition, having patients leave their rooms might be a high cost for the individualpatients, as this might yield stress and other discomforts for the patient.

3.1.2. Step 2—Definition of Model Boundary and Key Variables

The organizational structures of EDs may vary across hospitals. In the case organiza-tion, the ED was organized as its own independent department, not as a subdivision ofanother department, which is typical in smaller Norwegian hospitals.

In this step, the overall purpose was to convey patient flow elements in the simulationmodel. Figure 11 illustrates the inputs and outputs of each process step, identified byapplying to our case the Interface (N2) diagram tool presented in Section 2.1.3.

Healthcare 2022, 10, 840 12 of 28Healthcare 2022, 10, x 13 of 29

Figure 11. N2 diagram for ED facilities under pre- and peri-pandemic conditions.

3.1.3. Step 3—Description of the System Behavior In this step, a simple flowchart depiction of the patient flow process was developed.

The result is shown in Figure 12. The following descriptions explain each element in the flowchart:

“Pre-treatment” The first stage in the flow chart was pre-treatment. This stage included everything

from when the patient arrived at the ED until the patient left registration to be admitted into either the triage or treatment room. Imposed by the pandemic situation, the ED had decided to install a pre-triage area outside the entrance of the ED, where all patients ar-riving at the ED needed to be pre-screened. From here, if it was found likely that the pa-tient was infected by the COVID-19 virus, the patient would immediately be directed to a prepared treatment room (TR) to ensure a reduction in intra-departmental contamination. This implied that a treatment room was de-sanitized whenever it had been used to treat a patient who was suspected to have COVID-19.

“Triage”Triage here refers to the physical location where admitted patients wait for treatment. It is used in situations where no treatment rooms are vacant. We will later address the distinction between action and physical location, as triage can refer to both the action of triaging a patient according to a specific triage system and the physical lo-cation within the ED where the triaging of patients is primarily taking place.

“Under treatment” This stage of the patient pathway is where the actual treatment takes place. Then,

according to the prescribed medical protocol, the patient receives medical treatment from doctors and nurses. The standard treatment rooms in use before the pandemic amounted to 13. Extra treatment rooms were introduced for expanded capacity to cope with the pan-demic situation. Once the standard treatment rooms were filled, the extra treatment rooms would be used to accommodate more patients.

To cope with the risk of transmission between the patients, patients suspected of be-ing contaminated would be expedited to a treatment room. After treatment, the treatment

Figure 11. N2 diagram for ED facilities under pre- and peri-pandemic conditions.

3.1.3. Step 3—Description of the System Behavior

In this step, a simple flowchart depiction of the patient flow process was developed.The result is shown in Figure 12. The following descriptions explain each element inthe flowchart:


room would be de-sanitized before accepting a new patient. If the regular treatment rooms were full and a new patient with suspected contamination arrived, then a patient that had stayed in the room for at least 1 h would have to leave their treatment room and move over to a waiting zone.

“Waiting Zone” As said in the previous stage, the waiting zone was for patients evaluated not to be

incumbents of the virus. Here, patients would wait until there was an available treatment room that they could return to for their treatment to continue. “Discharge”

The last stage in the flow chart was the discharge. This step is where the patient fi-nally has undergone the treatment and is ready to be discharged from the ED.

Figure 12. Flow chart for patient flow under the pre-and peri-pandemic situation.

3.1.4. Step 4—Description of the Basic Mechanisms of the System The fourth step in the development procedure was to capture the basic mechanisms

of the system at a more detailed level than the simple flowchart. Discussions with the stakeholders in the case organization revealed a variety of possible pathways through the ED. These are illustrated in the sequence diagram in Figure 13, where the conditions for each route are indicated. These will be further elaborated in Table 2 in our computational model.

Figure 12. Flow chart for patient flow under the pre-and peri-pandemic situation.

“Pre-Treatment”

The first stage in the flow chart was pre-treatment. This stage included everythingfrom when the patient arrived at the ED until the patient left registration to be admittedinto either the triage or treatment room. Imposed by the pandemic situation, the EDhad decided to install a pre-triage area outside the entrance of the ED, where all patientsarriving at the ED needed to be pre-screened. From here, if it was found likely that thepatient was infected by the COVID-19 virus, the patient would immediately be directed toa prepared treatment room (TR) to ensure a reduction in intra-departmental contamination.

Healthcare 2022, 10, 840 13 of 28

This implied that a treatment room was de-sanitized whenever it had been used to treat apatient who was suspected to have COVID-19.

“Triage”

Triage here refers to the physical location where admitted patients wait for treatment.It is used in situations where no treatment rooms are vacant. We will later address thedistinction between action and physical location, as triage can refer to both the action oftriaging a patient according to a specific triage system and the physical location within theED where the triaging of patients is primarily taking place.

“Under Treatment”

This stage of the patient pathway is where the actual treatment takes place. Then,according to the prescribed medical protocol, the patient receives medical treatment fromdoctors and nurses. The standard treatment rooms in use before the pandemic amountedto 13. Extra treatment rooms were introduced for expanded capacity to cope with thepandemic situation. Once the standard treatment rooms were filled, the extra treatmentrooms would be used to accommodate more patients.

To cope with the risk of transmission between the patients, patients suspected of beingcontaminated would be expedited to a treatment room. After treatment, the treatmentroom would be de-sanitized before accepting a new patient. If the regular treatment roomswere full and a new patient with suspected contamination arrived, then a patient that hadstayed in the room for at least 1 h would have to leave their treatment room and move overto a waiting zone.

“Waiting Zone”

As said in the previous stage, the waiting zone was for patients evaluated not to beincumbents of the virus. Here, patients would wait until there was an available treatmentroom that they could return to for their treatment to continue.

“Discharge”

The last stage in the flow chart was the discharge. This step is where the patient finallyhas undergone the treatment and is ready to be discharged from the ED.

3.1.4. Step 4—Description of the Basic Mechanisms of the System

The fourth step in the development procedure was to capture the basic mechanismsof the system at a more detailed level than the simple flowchart. Discussions with thestakeholders in the case organization revealed a variety of possible pathways through theED. These are illustrated in the sequence diagram in Figure 13, where the conditions for eachroute are indicated. These will be further elaborated in Table 2 in our computational model.


Figure 13. Effect on patient flow operation illustrated in sequence diagram pre- and peri-pandemic situation.

Table 2. Description of the elements (states, transitions and initial conditions) of the patient agent statechart.

Name Description Logic Code

Patient arrival will be arriving according to the numerical data attained from the case or-ganization. Arrivals can be programmed based on a probability distribution that will make for a stochastical model. Alternatively, arrivals can be programmed according to rec-orded arrival times; the model will then be deterministic.

‘Stay’

State-Stay: The sole purpose of this state-block is to calculate the length of stay of pa-tients throughout their lifetime, i.e., the entire statechart. Timer3 here does the counting. No other logic is contained within this state block.

Timeout for each second in simu-lation in order to increment the timer value within Timer3 ac-cording to criteria in the code. Variables: (integer) v_LOS

Action: v_LOS += inState(Stay) ? 1: 0;

‘S1′

State-Pre-treatment: First compound state in the overall patient flow. This state contains all the states for the pre-treatment activities a pa-tient is undergoing. Like the previous state, counting is performed. It is worth noting counter is placed here instead of the ‘Stay’ state block to reduce the calculation power needed for each discrete increment.

Timeout for each second in simu-lation in order to increment the timer value within Timer1 ac-cording to code. Variables: v_time_in_PreTriage, v_time_in_WR

Action: v_time_in_PreTriage += inState(PreTriage)? 1: 0; v_time_in_WR += inState(WaitingInWR) ? 1: 0;

‘s1-1′ State-Incidence: Patient agent takes place into the statechart after being transferred from the

- -

Figure 13. Effect on patient flow operation illustrated in sequence diagram pre- and peri-pandemic situation.

Table 2. Description of the elements (states, transitions and initial conditions) of the patient agent statechart.


Patient arrival will be arriving according tothe numerical data attained from the caseorganization. Arrivals can be programmedbased on a probability distribution that willmake for a stochastical model. Alternatively,arrivals can be programmed according torecorded arrival times; the model will thenbe deterministic.

‘Stay’

State-Stay: The sole purpose of thisstate-block is to calculate the length of stay ofpatients throughout their lifetime, i.e., theentire statechart. Timer3 here does thecounting. No other logic is contained withinthis state block.

Timeout for each second insimulation in order toincrement the timer valuewithin Timer3 according tocriteria in the code. Variables:(integer) v_LOS

Action: v_LOS += inState(Stay) ? 1: 0;

‘S1’

State-Pre-treatment: First compound state inthe overall patient flow. This state containsall the states for the pre-treatment activities apatient is undergoing. Like the previousstate, counting is performed. It is worthnoting counter is placed here instead of the‘Stay’ state block to reduce the calculationpower needed for each discrete increment.

Timeout for each second insimulation in order toincrement the timer valuewithin Timer1 according tocode. Variables:v_time_in_PreTriage,v_time_in_WR

Action: v_time_in_PreTriage +=inState(PreTriage)? 1: 0;v_time_in_WR +=inState(WaitingInWR) ? 1: 0;

Healthcare 2022, 10, 840 15 of 28

Table 2. Cont.


‘s1-1’

State-Incidence: Patient agent takes placeinto the statechart after being transferredfrom the ‘Exit’ block in DES (Figure 14). Thesole purpose of this state block is that t servesthe programmatic purpose of letting thepatient agent enter the statechart. Once thepatient agent is instantiated into this state, itis immediately passed onto the transition.

- -

‘t1-1’

Transition: Patient agent arrives from theDES. Transition is triggered on the stringmessage “occurrence,” which is sent from the‘Exit’-block in the DES model.

- -

‘s1-2’State–PreTriage: Patient agent is gettingmoved from the entry node to the Pre-triagenode, i.e., light green field in Figure 14.

The patient agent initiatesmovement from the Entrynode to the te pre triage node.

Action:moveTo(main.PreTriageNode);

‘t1-2’ Transition: Transition from the statePreTriage to branch B1.

Transition is executedperiodically for every fixedtime interval in order to ensure.Parameter used:main.p_RegistrationCheckInterval

‘B1’Branch: This branch carries out the selectionfor what path the patient agent shouldproceed in.

Three different outgoingtransitions: (1) If there is asuspicion that the patient iscontaminated, the patient willgo to S2. (2) If the patientagent is found not to becontaminated, the patient willgo to the waiting room after aspecified waiting time, i.e.,state s1-3. (3) T3: If the patientagent has virus suspicion andthere are no more treatmentrooms, the patient must waitin the Pre-triage.

(1) Condition: p_contaminated &&!f_is_TR_full()(1) Action:main.enter_SeizeTR.take(this);(2) Condition: !p_contaminated &&(v_time_in_PreTriage >main.p_minTimeInPreTriage)(3) Action:if (p_contaminated && f_is_TR_full()&& v_BlockFlag == false) {main.v_Virus_Patient_TR_Decline ++;v_BlockFlag = true;}

‘s1-3’ State–WalkingToWR: Patient agent walkingto the waiting room from the pre triage.

The patient agent walks alongthe path between thepre-triage and waiting roomshown in Figure 14.

Action: moveTo(main.waitingRoomNode);

‘t1-3’Transition: The patient agent is simplytransitioning between walking to the waitingroom and waiting in the waiting room.

This transition is triggeredonce the patient agent stopswalking and arrives at itsplace in the waiting room.

-

‘s1-4’State–WaitingInWR: This state for the patientagents when waiting in the waiting room(WR); see the node in Figure 14.

- -

‘t1-4’ Transition: Here, the patient agent willattempt to see if it is ready to proceed.

This transition will triggerperiodically. It will check if itcan fulfill any of thetransitions branch B4 for eachperiodic interval.

-

Healthcare 2022, 10, 840 16 of 28

Table 2. Cont.


‘B4’

Branch: This is the pathway forward after thePreTreatment state. Patient agents from hereeither have to go to the treatment room,triage or wait further if the above-mentionedis full.

Three outgoing transitions: (1)T1–Going to triage if there areno more treatment rooms left,(2) T2–Going to a treatmentroom, and(3) Stay in the waiting room ifthe above-mentionedtransitions do not fulfill theirexecution conditions. None ofthe transitions havedependencies on the patientvirus suspicious status, asthese are already sorted in theprevious branch B1.

(1) Conditions: f_is_TR_full() &&!f_is_Triage_full() &&(v_time_in_WR >main.p_minTimeInWR)(1) Action:main.enter_seize_Triage.take(this);(2) Action:main.enter_SeizeTR.take(this);(3) Conditions: !f_is_TR_full() &&f_is_WZ_empty() &&f_is_Triage_empty() &&(v_time_in_WR>main.p_minTimeInWR)

‘S2’

State–IntraTreatment: This is the secondmajor compound state of the overall patientflow. As the name suggests, this is where thepatient finally undergoes treatment. Thepatient agent is released from the treatmentroom seizing pathway shown in the DESblock diagram (Figure 14)

The treatment is simulated bythe patient agent waitinginside the treatment room.The treatment time differsaccording to whether thepatient has suspicion of viruscontamination. (1) Timervariable: v_time_in_TR. (2)Counter variable:main.p_number_room_exit

v_time_in_TR += inState(Treatment) ? 1: 0;main.p_number_room_exit++

‘s2-1’

State–WalkingToAndSeizingTR: This is thestate the patient agent is contained withinuntil it has been transferred from theseize-path, as mentioned earlier.

- -

‘t2-1’Transition–The patient agent is transitionedto the next state once the message is receivedfrom the

The patient agent istransitioned to the next stateonce the message is receivedfrom the

-

‘s2-2’ State–Treatment: This is the state in whichthe patient agent is under treatment.

The patient agent stays in thisstate while the counteris increasing.

-

‘t2-2’Transition–Transition out of treatment leadsto a branch where there are threeoptions possible.

This transition is cyclical andrepeats every second duringmodel runtime for patients’agents that stay within thetreatment state.

-

‘B2’Branch: This branch leads the patient agentto go to the waiting zone, leave the ED, orstay to continue the treatment.

The branch is leading to threeoutgoing transitions (1) T6:Patient agents pause thetreatment and makes thepatient go to the waiting zone.(2) T7: Patient agent hascompleted treatment and willhead to exit the ED. (3)Treatment is not carried out,and it will proceed until it iseither completed or has topause because the treatmentroom needs to be seized by apatient suspicious ofcontamination.

(1) Action:main.enter_seize_WZ.take(this);(1) Condition: !p_contaminated &&f_is_TR_full() &&!f_is_WZ_full() &&v_time_in_TR > main.p_minTimeTR &&f_is_this_longest_in_TR(this) &&f_is_any_contaminated_in_WR() &&main.b_is_WZ_in_use(2) Action: main.enter.take(this);(2) Condition:p_contaminated ? v_time_in_TR >main.p_TreatmentTime_VirusSuspicion:v_time_in_TR >main.p_TreatmentTime_OrdinaryPatient

Healthcare 2022, 10, 840 17 of 28

Table 2. Cont.


‘S3’

State–Triage: Compound state elementemulating the patient standing by in thetriage until there is room for the patient inthe treatment rooms.

Time is tracked. Variable:v_time_in_Triage v_time_in_Triage += inState(Triage) ? 1: 0;

‘s3-1’

State-WalkingToTriage: The patient agentwalks from the waiting room node to thetriage node. The patient agent is retrievedfrom the DES path shown in Figure 14,distributing the triage bed to the patient agent.

- -

‘t3-1’Transition–Transition is executed once thepatient agent is transferred from the DESflow chart.

- -

‘s3-2’ State–WaitingInTriage: This state emulates thewaiting time in the triage. -

‘t3-2’Transition: Transition for checking if it istime to leave the triage. Decision-makingthrough the branch (B5) in the next row.

Transition executedperiodically; every secondpatient stays state‘WaitingInTriage.’

-

‘B5’ Branch: Checking if the patient agent canleave the triage to go to a treatment room.

The branch is leading to twooutgoing transitions. (1)Transition for when there is atreatment room ready. (2) Notreatment room is available forthe patient agent, returning tothe previous state.

(1) Condition: !f_is_TR_full() &&f_is_WZ_empty() &&!f_is_any_contaminated_in_WR() &&(v_time_in_Triage >main.p_minTimeInTriage)(1) Action:main.enter_SeizeTR.take(this);

‘S4’State-WaitingZone: This is the compoundstate encompassing the states that emulatethe waiting zone for the patient agents.

This compound statement hasno time counters as the time isdirectly relevant for when apatient agent will leave thisstate. However, as seen in theoutgoing transition (T5), thepatient agent can leave oncethere is room again for thepatient agent to return to thetreatment room.

-

‘s4-1’

State–GoingToWZ: The patient is retrievedfrom the DES chart, it has been allocated to awaiting zone, and walking to the spot it hasbeen granted.

- main.enter_seize_WZ.take(this);

‘t4-1’Transition: Patient agent is finished walkingto the waiting zone and will proceed bywaiting in the waiting zone.

This transition is carried outonce the patient agent hasarrived at the granted waitingzone spot. This transition isexecuted by receiving amessage from the DES-chart

-

‘s4-2’ State-WaitingInWZ: The patient agent iswaiting in the waiting zone. - -

‘t4-2’ Transition: Transition going out from waitingin the waiting zone.

This transition is periodicallyexecuted every secondof runtime.

-

Healthcare 2022, 10, 840 18 of 28

Table 2. Cont.


‘B3’ Branch: Branch for going further to thetreatment room or keep on waiting.

This branch does have twooutgoing transitions for thepatient agents staying in thetriage (1) T4–Going to theIntraTreatment state. (2) Keepon waiting in the triage.

(1) Condition: !f_is_TR_full() &&f_is_WZ_empty() &&!f_is_any_contaminated_in_WR() &&(v_time_in_Triage >main.p_minTimeInTriage)(1) Action:main.enter_SeizeTR.take(this);

‘S5’

State–Discharge: Patient agent is here on itsway out of the model. The state does not doanything besides being a mediator betweenthe two states.

- -Healthcare 2022, 10, x 19 of 29

Figure 14. Process diagram programmatically carrying out the resource allocation. Patients are in-put in the source and output in the sink; resources will be seized and released depending on the individual patient agent’s situation.

3.2.3. Patient Flow Behavior Model The agents, depending on variable characteristics, will progress through the follow-

ing main groups of activities: • Pre-treatment; • Triage; • Intra treatment; • Waiting Zone; • Discharge.

In Figure 15, the patient flow sequence is described in a statechart, where the main states (physical locations, e.g., triage, treatment room, waiting zones) and the triggers to move from one state to another are illustrated. The statechart is the programmatic entity that orchestrates the behavior of the individual agents in the model [26].

Figure 14. Process diagram programmatically carrying out the resource allocation. Patients areinput in the source and output in the sink; resources will be seized and released depending on theindividual patient agent’s situation.

3.2. Computational Model

The following documentation of the computational model will be segmented intothe following subjects: Environment, Resources, Agents, and Interaction topology, whichare some of the elements STRESS guidelines suggested for documenting DES and ABSmodels [25].

The computational modeling process resulted in:

(1) Animated layout to visualize the patient flow behavior in a virtual ED environment.(2) A discrete-event model for facility resources (treatment rooms, waiting zones, triage)

and patient arrival rate.(3) An agent-based model for patient flow (for ordinary and COVID-19 contaminated

patients), where the sequence (state and transitions), policies (conditions, triggers),and service time (treatment time, waiting time) are modeled.

These will be presented in the following, and the modeling assumptions will be listed.

Healthcare 2022, 10, 840 19 of 28

3.2.1. Virtual ED Model

The computational model was modeled using AnyLogic 8.0 Learning Edition, and thepresent study was limited to considering the spatial resources of the ED. These resourceswere overlaid on top of the case organization’s blueprints for convenience and accuracy.

3.2.2. Resource Allocation Model

The resource allocation of this model was programmed through a process flow chartusing the discrete-event modeling approach.

3.2.3. Patient Flow Behavior Model

The agents, depending on variable characteristics, will progress through the followingmain groups of activities:

• Pre-treatment;• Triage;• Intra treatment;• Waiting Zone;• Discharge.

In Figure 15, the patient flow sequence is described in a statechart, where the mainstates (physical locations, e.g., triage, treatment room, waiting zones) and the triggers tomove from one state to another are illustrated. The statechart is the programmatic entitythat orchestrates the behavior of the individual agents in the model [26].

In our current model, the only agents acting are patients. Whether the patientsare ordinary, or COVID-19 contaminated, patients have a clear flow throughout severalfacilities (triage, treatment rooms, waiting zones). Specific conditions trigger the flow orpatient movement, e.g., if a treatment room is empty, a patient moves from triage intothat treatment room. Thus, there are several states and transitions that each patient hasto undergo within the ED. As there are specific transitions that are time-dependent andexecuted depending on how much time the patient agents have spent in different states, itwas necessary to implement timers to keep track of the duration patients stay in differentparts of the patient flow process.

As seen in the statechart (Figure 15), there is a correlation between the flowchart inthe conceptual model developed in the previous subsections (Figure 12) and the resultingstatechart. The main blocks in the flowchart and statechart are the same. However, thestatechart has one more level of granularity as some of the main blocks (“PreTreatment”,“Triage”, “IntraTreatment”, “WaitingZone”) have a flow chart of activities within them.

In Figure 15, there is a unique transition (T3) for COVID-19 contaminated patientsto move from the pre-triage room (S1-2) at B1 to treatment rooms (S2). This particulartransition represents the mentioned priority rule that our case organization implementedin the ED during the pandemic for channeling the patients directly to treatment rooms.


Figure 15. Statechart of patient flow behavior at the studied ED.

In our current model, the only agents acting are patients. Whether the patients are ordinary, or COVID-19 contaminated, patients have a clear flow throughout several facil-ities (triage, treatment rooms, waiting zones). Specific conditions trigger the flow or pa-tient movement, e.g., if a treatment room is empty, a patient moves from triage into that treatment room. Thus, there are several states and transitions that each patient has to un-dergo within the ED. As there are specific transitions that are time-dependent and exe-cuted depending on how much time the patient agents have spent in different states, it was necessary to implement timers to keep track of the duration patients stay in different parts of the patient flow process.

As seen in the statechart (Figure 15), there is a correlation between the flowchart in the conceptual model developed in the previous subsections (Figure 12) and the resulting statechart. The main blocks in the flowchart and statechart are the same. However, the statechart has one more level of granularity as some of the main blocks (“PreTreatment”, “Triage”, “IntraTreatment”, “WaitingZone”) have a flow chart of activities within them.

In Figure 15, there is a unique transition (T3) for COVID-19 contaminated patients to move from the pre-triage room (S1-2) at B1 to treatment rooms (S2). This particular tran-sition represents the mentioned priority rule that our case organization implemented in the ED during the pandemic for channeling the patients directly to treatment rooms.

In Table 2, the first three columns describe each state and transition and their logic in the following table. These were all discussed and verified by our stakeholders in the case organization. The rightmost column shows the code of each element implemented in the computational model.

Figure 15. Statechart of patient flow behavior at the studied ED.

In Table 2, the first three columns describe each state and transition and their logic inthe following table. These were all discussed and verified by our stakeholders in the caseorganization. The rightmost column shows the code of each element implemented in thecomputational model.

3.3. Model Outcome and Output Validation

There are two primary outcomes from the computational model:

(1) Patient crowding timeline in the ED;(2) Key performance indicators of patient flow, e.g., waiting time and time to treatment.

Table 3 show comparisons between simulation output and actual patient crowdingdata in a pre-pandemic and peri-pandemic setting, respectively. Figures 16 and 17 showsnapshots of simulated key performance indicators during the same pre-pandemic andperi-pandemic settings, respectively.

Healthcare 2022, 10, 840 21 of 28

Table 3. a. Model output validation comparing graphs of patient crowding in the ED in a pre-pandemic situation. (a) Actual patient crowding data gathered from SmartCrowding, (b) Simulatedpatient crowding. b. Model output validation comparing graphs of patient crowding in the EDin a peri-pandemic situation. (a) Actual patient crowding data gathered from SmartCrowding, (b)Simulated patient crowding.

a

Day 1 Day 2 †

(a)A

ctua

lpat

ient

crow

ding


3.3. Model Outcome and Output Validation There are two primary outcomes from the computational model:

(1) Patient crowding timeline in the ED; (2) Key performance indicators of patient flow, e.g., waiting time and time to treatment.

Table 3 show comparisons between simulation output and actual patient crowding data in a pre-pandemic and peri-pandemic setting, respectively. Figure 16, Figure 17 show snapshots of simulated key performance indicators during the same pre-pandemic and peri-pandemic settings, respectively.

Figure 16. Snapshot of simulated KPI of patient flow in a pre-pandemic setting.

Table 3. a. Model output validation comparing graphs of patient crowding in the ED in a pre-pan-demic situation. (a) Actual patient crowding data gathered from SmartCrowding, (b) Simulated pa-tient crowding. b. Model output validation comparing graphs of patient crowding in the ED in a peri-pandemic situation. (a) Actual patient crowding data gathered from SmartCrowding, (b) Sim-ulated patient crowding.

a Day 1 Day 2 †

(a) A

ctua

l pat

ient

cro

wdi

ng

(b) S

imul

ated

pat

ient

cr

owdi

ng

b Day 1 Day 2 †







a Day 1 Day 2 †

(a) A

ctua

l pat

ient

cro

wdi

ng

(b) S

imul

ated

pat

ient

cr

owdi

ng

b Day 1 Day 2 †

(b)S

imul

ated

pati

entc

row

ding







a Day 1 Day 2 †

(a) A

ctua

l pat

ient

cro

wdi

ng

(b) S

imul

ated

pat

ient

cr

owdi

ng

b Day 1 Day 2 †







a Day 1 Day 2 †

(a) A

ctua

l pat

ient

cro

wdi

ng

(b) S

imul

ated

pat

ient

cr

owdi

ng

b Day 1 Day 2 † b

Day 1 Day 2 †

(a)A

ctua

lpat

ient

crow

ding


(a) A

ctua

l pat

ient

cro

wd-

ing

(b) S

imul

ated

pat

ient

cr

owdi

ng

† Graph ‘Day 2′ is not the immediately following day after ‘Day 1′ as the naming may suggest.

As can be seen in Table 3, the curve shapes from the actual patient crowding data in the case organization system (SmartCrowding) in row (a) and our simulated patient crowding in row (b) show a reasonably close resemblance. There are, however, discrep-ancies of the primary two main types. Firstly, the curves from the actual data (row a) are more elevated than the simulation output curves (row b) and secondly, a slight time lag seems present between the actual curves and the simulated output curves. These discrep-ancies will be further discussed in Section 4.2.1 of this paper’s Discussion chapter.

In the conceptualization stage, we presented the key performance indicators of pa-tient flow to be implemented and estimated by the simulation model. Figure 16 shows how these measures were represented in a table within the simulation software. The val-ues will change dynamically throughout the simulation runtime.

As shown in Table 3, the curve shapes from the actual patient crowding data in row (a) and simulated patient crowding in row (b) also show reasonably close resemblance in a peri-pandemic setting. The same discrepancies between the curves for simulated and actual patient crowding (i.e., slight differences in elevation level and time lag) discussed above for Table 3 can also be observed here.

Figure 17 shows how key performance indicators were represented in the peri-pan-demic setting. As in the pre-pandemic setting, the values will change dynamically throughout the simulation runtime.

Figure 17. Snapshot of simulated KPIs of patient flow in a peri-pandemic setting.

4. Discussion


(a) A

ctua

l pat

ient

cro

wd-

ing

(b) S

imul

ated

pat

ient

cr

owdi

ng







4. Discussion

(b)S

imul

ated

pati

entc

row

ding


(a) A

ctua

l pat

ient

cro

wd-

ing

(b) S

imul

ated

pat

ient

cr

owdi

ng







4. Discussion


(a) A

ctua

l pat

ient

cro

wd-

ing

(b) S

imul

ated

pat

ient

cr

owdi

ng







4. Discussion

† Graph “Day 2” is not the immediately following day after “Day 1” as the naming may suggest.

Healthcare 2022, 10, 840 22 of 28


3.3. Model Outcome and Output Validation

There are two primary outcomes from the computational model:

(1) Patient crowding timeline in the ED;

(2) Key performance indicators of patient flow, e.g., waiting time and time to treatment.

Table 3 show comparisons between simulation output and actual patient crowding

data in a pre-pandemic and peri-pandemic setting, respectively. Figure 16, Figure 17 show

snapshots of simulated key performance indicators during the same pre-pandemic and

peri-pandemic settings, respectively.


As can be seen in Table 3, the curve shapes from the actual patient crowding data in

the case organization system (SmartCrowding) in row (a) and our simulated patient

crowding in row (b) show a reasonably close resemblance. There are, however,

discrepancies of the primary two main types. Firstly, the curves from the actual data (row

a) are more elevated than the simulation output curves (row b) and secondly, a slight time

lag seems present between the actual curves and the simulated output curves. These

discrepancies will be further discussed in Section 4.2.1 of this paper’s Discussion chapter.

In the conceptualization stage, we presented the key performance indicators of

patient flow to be implemented and estimated by the simulation model. Figure 16 shows

how these measures were represented in a table within the simulation software. The

values will change dynamically throughout the simulation runtime.

As shown in Table 3, the curve shapes from the actual patient crowding data in row

(a) and simulated patient crowding in row (b) also show reasonably close resemblance in

a peri-pandemic setting. The same discrepancies between the curves for simulated and

actual patient crowding (i.e., slight differences in elevation level and time lag) discussed

above for Table 3 can also be observed here.

Figure 17 shows how key performance indicators were represented in the peri-

pandemic setting. As in the pre-pandemic setting, the values will change dynamically

throughout the simulation runtime.




4. Discussion

In this section, the conceptual and computational modeling process is discussed,

followed by a discussion of the simulated results and their validity. Finally, some

implications and future work will be highlighted.

4.1. Discussion of the Conceptual Modeling

The conceptual model in this present paper is documented in a paradigm-

independent manner, providing freedom for modelers. Additionally, this approach

provides transparency of the fundamental logic of the model. It makes it accessible for

researchers determined to use a simulation paradigm or a mix of simulation paradigms

different from the one used in this study. Furthermore, using systems engineering

methods for conceptual modeling supports several purposes.

The purpose tree provided a direction for modeling by identifying and decomposing

the over-arching purpose of the model. It also helped establish what key variables were

essential to communicate in any output dashboard of the end product. The interface

diagram aided us in mapping out both downstream and upstream patient flow interfaces

between subcomponents of the system. Thereby one sets the model’s boundary by

determining the input and output, in addition to giving a systemic view of the process

interactions between subcomponents.

The flow chart offers a simple overview of the whole patient flow process and

provides valuable direct guidance on how to construct the statechart of the following

computational model.

Lastly, in the conceptual modeling process, the sequence diagram captured and

highlighted the feedback loops and the plethora of different realizations throughout the

patient flow system that the ED entails. In particular, the sequence diagram highlighted

how much the complexity of the patient flow increased when the ED had to perform the

prioritization of regular and contamination suspected patients.

In their unique way, each of these tools helped arrive at the necessary understanding

of the patient flow complexities to proceed to the computational modeling. We assert that

this understanding goes beyond the understanding one can gain by solely using a

flowchart as a conceptualizing tool, as commonly seen in many patient-flow simulation

studies.

Utilizing the conceptual modeling approach as demonstrated in this study is useful

as it demonstrates the use of a set of tools for data collection and communication with the

stakeholders. It can also be used to verify and validate if the conceptual model represents

a credible understanding of the real-world case and to validate if the computational model

is traceable to the conceptual model. It is important to emphasize the benefit of the tools

being software independent.

The synergic effect of the combination of the different tools is essential. The tools

represent four abstractions of the same patient flow process. They serve as four different

low-resolution lenses to perceive the actual process. We believe that the diversity within

these “lenses” forces the simulation modeler and the participating stakeholders to


As can be seen in Table 3, the curve shapes from the actual patient crowding data in thecase organization system (SmartCrowding) in row (a) and our simulated patient crowdingin row (b) show a reasonably close resemblance. There are, however, discrepancies of theprimary two main types. Firstly, the curves from the actual data (row a) are more elevatedthan the simulation output curves (row b) and secondly, a slight time lag seems presentbetween the actual curves and the simulated output curves. These discrepancies will befurther discussed in Section 4.2.1 of this paper’s Discussion chapter.

In the conceptualization stage, we presented the key performance indicators of patientflow to be implemented and estimated by the simulation model. Figure 16 shows howthese measures were represented in a table within the simulation software. The values willchange dynamically throughout the simulation runtime.

As shown in Table 3, the curve shapes from the actual patient crowding data in row (a)and simulated patient crowding in row (b) also show reasonably close resemblance in aperi-pandemic setting. The same discrepancies between the curves for simulated and actualpatient crowding (i.e., slight differences in elevation level and time lag) discussed above forTable 3 can also be observed here.

Figure 17 shows how key performance indicators were represented in the peri-pandemic setting. As in the pre-pandemic setting, the values will change dynamicallythroughout the simulation runtime.

4. Discussion

In this section, the conceptual and computational modeling process is discussed, fol-lowed by a discussion of the simulated results and their validity. Finally, some implicationsand future work will be highlighted.

Healthcare 2022, 10, 840 23 of 28

4.1. Discussion of the Conceptual Modeling

The conceptual model in this present paper is documented in a paradigm-independentmanner, providing freedom for modelers. Additionally, this approach provides trans-parency of the fundamental logic of the model. It makes it accessible for researchersdetermined to use a simulation paradigm or a mix of simulation paradigms different fromthe one used in this study. Furthermore, using systems engineering methods for conceptualmodeling supports several purposes.

The purpose tree provided a direction for modeling by identifying and decomposingthe over-arching purpose of the model. It also helped establish what key variables were es-sential to communicate in any output dashboard of the end product. The interface diagramaided us in mapping out both downstream and upstream patient flow interfaces betweensubcomponents of the system. Thereby one sets the model’s boundary by determining theinput and output, in addition to giving a systemic view of the process interactions betweensubcomponents.

The flow chart offers a simple overview of the whole patient flow process and providesvaluable direct guidance on how to construct the statechart of the following computational model.

Lastly, in the conceptual modeling process, the sequence diagram captured and high-lighted the feedback loops and the plethora of different realizations throughout the patientflow system that the ED entails. In particular, the sequence diagram highlighted how muchthe complexity of the patient flow increased when the ED had to perform the prioritizationof regular and contamination suspected patients.

In their unique way, each of these tools helped arrive at the necessary understandingof the patient flow complexities to proceed to the computational modeling. We assert thatthis understanding goes beyond the understanding one can gain by solely using a flowchartas a conceptualizing tool, as commonly seen in many patient-flow simulation studies.

Utilizing the conceptual modeling approach as demonstrated in this study is usefulas it demonstrates the use of a set of tools for data collection and communication with thestakeholders. It can also be used to verify and validate if the conceptual model represents acredible understanding of the real-world case and to validate if the computational modelis traceable to the conceptual model. It is important to emphasize the benefit of the toolsbeing software independent.

The synergic effect of the combination of the different tools is essential. The toolsrepresent four abstractions of the same patient flow process. They serve as four differentlow-resolution lenses to perceive the actual process. We believe that the diversity withinthese “lenses” forces the simulation modeler and the participating stakeholders to perceivethe system from different conceptual perspectives. This, in turn, helps extract as muchrelevant information as possible, in line with the stated purpose(s) of a conceptual model,thus increasing the chance of representing the actual system behavior. We believe theapproach we have followed helps the stakeholders articulate important elements theyotherwise might consider too obvious to mention or that they may have not reflectedthoroughly upon.

4.2. Computational Model

The computational model, represented by a discrete event process diagram and state-charts, has been structured based on the conceptual model diagrams. It is clear that anycomputational model has a structure, behavior (formulas, rules, etc.) and inputs. The rulesand conditions have been extracted from interviews with staff working and managing theED at SUS. The input data such as ‘time of arrival’ was extracted from a real-time database,i.e., Meona. The service time for treatment and waiting time are assumed based on expertexperience. Finally, the simulated results were validated in two manners: (1) comparedwith real-life patient flow data (2) dialogue with stakeholders in the ED to ensure that ourunderstanding has mimicked real-world structure and relationships.

The comparison between the actual real-life data provided by SmartCrowding and thesimulation results provided by our model, illustrated in Table 3, clearly shows similarities in

Healthcare 2022, 10, 840 24 of 28

the daily pattern (i.e., curve shape) of the patient prevalence in the ED. Producing a realisticoutput that reasonably replicates the system behavior, confirmed by the expert group inthe meetings as being credible, gained confidence from the group. We experienced that thisconfirmation was a sign of trustworthiness of the model and yielded our acceptance withthe system stakeholders as the model continued to develop.

One particular problem experienced during the model development, which had apractical solution, was the way to emulate the limited resources (i.e., emergency treatmentrooms). This was solved by making these model elements use discrete-event modelingrather than agent-based modeling. There were, thus, interfaces between the DES portion ofthe model and the ABM part of the model. Agents would be programmed to temporar-ily exit their statechart, seize their supposed resources, and return to progress throughthe statechart.

The resulting model ended up fairly complex. Data will be gathered and calculatedevery second, and the agents will check conditions for several transitions. However,a regular modern laptop can run this model, simulating 24 h of operation in less thanone minute.

The computational model provides reliable and consistent results in several runs.However, three assumptions have been taken regarding the model: (1) static patientinfection rate, (2) no intra-hospital contamination, and (3) perfect sorting of the patients inthe pre-screening. The patient rate is modeled as a variable that users of the model willhave the ability to vary. However, intra-hospital contamination and imperfect sorting mightrequire further development to model such complex phenomena. It is worth highlightingthat the developed simulation model is generalizable in two terms. First, it can be utilizedfor other EDs in Norway or hospitals with similar operating procedures. The process of EDpatient flow in our case organization widely coincides with the commonly used processdescribed in the ED report from the Norwegian Directorate of Health [27]. Second, it hasthe potential to be utilized for other pandemics with different types of diseases.

The resulting computational model constitutes perhaps the biggest contribution ofthis paper. Being a hybrid model, including two major simulation paradigms: agent-basedsimulation and discrete event simulation, it is a result consistent with the recommendationof other studies to use more advanced simulation methods to incorporate more of theunderlying complexities of the healthcare delivery system [10].

4.2.1. Simulation Model Validity

The conceptual model, represented by the purpose tree, N2-matrix flowchart, andsequence diagram, has been extracted from discussions with staff working at and managingthe ED at SUS. Through continual and incremental verification from the system experts,the model was developed and tailored to mimic the patient flow system of the entire ED inthe case hospital.

Confidence in the computational model was achieved by running the model andcomparing the simulation output with actual data, both in a pre-pandemic and a peri-pandemic setting. There were sufficient overall similarities between real-world data andsimulated data in both settings to gain confidence in the model’s accuracy.

Our simulation model does not yet provide point prediction [28] in the sense that thesimulation results yielded the same results at every time point as the empirical data fromthe same period. As mentioned, the simulation output from our computational model(Table 3, row b) showed some discrepancies in the empirical data (Table 3, row a) thatcovered the same periods (2 separate days) as our simulations. The discrepancies between(a) the real and (b) the simulation output data were subject to discussion with the caseorganization stakeholders and possible explanations were offered.

One explanation could be our simplified assumption of a 2,0-hour treatment timefor every patient. Although our participating stakeholders at the case hospital suggestedthis simplification, they did indicate that treatment times would vary in practice. Inparticular, they stated that under periods of high patient crowding, most procedures tend

Healthcare 2022, 10, 840 25 of 28

to take longer than average, thereby extending the treatment time. Under these conditions,patients will stay in the system longer than the current simulation model assumes, therebyelevating the empirical curves higher than the simulation curves, as shown in Table 3. Ourstakeholders based this perception (calling it the “syrup effect”) on their experience ratherthan any available empirical data. We intend to develop our simulation model to addressthis issue in our future simulation studies. However, given the underlying assumptionsand simplifications necessary in any simulation model, we assert that our model providesa reasonably good pattern prediction [28].

Another explanation offered by the stakeholder group was the subtle difference presentin reporting between the two datasets. The real data gathered from the SmartCrowdingsystem, plotted in row ‘a’ of Table 3, tracks the number of patients registered to the ED.This means that patients traveling to the hospital from their general practitioners or via anambulance are registered as prevalent patients. However, the data used in the simulationmodel has a registration based upon actual arrival in the physical ED space. This differenceresults in a delay between the curves, as observed in Table 3, where the simulation output isslightly lagging behind the real data. This discrepancy will also be taken into considerationin future model development.

The differences between our simulation output and the actual patient flow data mightalso be explained by other phenomena that take an active role in the ED, such as the latencyassociated with higher crowding, staff shifts, or higher variation in the treatment times.The differences might also highlight the implication of the model delimitations that wehave taken. For example, patients and rooms were the only two modeled agents; medicalstaff (doctors, nurses) and beds were excluded. Moreover, the interactions between the EDand other departments were excluded, such as blood test, and X-ray laboratories, wherepatients are usually sent to those departments between their stay at the ED.

The “syrup effect,” potential delays in availability of doctors, nurses, and beds, andtime spent at other departments all directly affect patient flow in the ED. In fact, such issuesshow the need and implication of using a multi-method simulation approach instead ofonly a discrete event or system dynamics approach. In future model development, moreagents shall be considered in order to mimic the real-world behavior of the ED.

4.3. Assumptions and Simplifications

In addition to the above, there are other assumptions and simplifications that weretaken at this stage of model development, as follows:

1. The percentage of COVID-19-contaminated patients out of total patients enteringthe ED, i.e., the patient contamination rate (PCR), was considered 30% in the peri-pandemic scenarios and 0% in the pre-pandemic scenarios. This percentage wasconstant throughout the entire day, while it may have varied throughout the day inreal life.

2. Treatment time for each patient agent was assumed to be constant. However, re-alistically, the treatment time will most likely vary throughout the day accordingto what types of patients arrive to the emergency department. In this model, thetreatment time was set static to a 2-hour average, based on an assessment by the casestakeholders.

3. No intra-hospital contamination was put into the model.4. Therefore, the model implicitly assumes that there is a perfect sorting, i.e., a sorting

error is not taken into consideration regarding the patients in the pre-triage.

4.4. Practical Implications

This work was carried out in the context of the COVID-19 pandemic. However, themodel we have developed can be applied to other pandemic contexts, provided they requiresimilar patient flow operation and intervention policies similar the ones used in this paper,i.e., that infected patients needs to go directly to their own treatment room and shouldavoid the waiting room and triage. On the other hand, the transparency of our account

Healthcare 2022, 10, 840 26 of 28

should facilitate other researchers to make necessary modifications to the model to suittheir particular contexts.

Although the interventions (i.e., pre-triage, waiting zone) might be unique for thisparticular ED in our study’s context, this paper shows how such interventions can bebrought into a computational model.

The interventions shown here are a snapshot of one particular time in the case organi-zation. Such policies will need to change in accordance with the best medical knowledgeat the time in order to maintain the required quality of treatment. Detailed modeling canbe quite time-consuming, and in the worst case, a model can be deemed obsolete by thetime it is ready to be used. Additionally, it might be difficult for researchers to gain accessto relevant stakeholders in such a high-paced and hands-on environment as an ED. Therewill likely be a need and demand from these to achieve fast-paced tangible outcomes tomaintain stakeholder interest.

4.5. Further Work

As the scope of this paper was only to show the model building itself, a naturalcontinuation from this is to carry out actual simulation tests. A natural expansion of thework presented in this paper is to progress further onto the next step in Randers’ overallsimulation modeling process, as illustrated in Figure 3. In subsequent work, we willdemonstrate how our simulation model can be used to study the effects of pandemic-related policies on patient flow. For example, introducing a waiting zone and/or an extratreatment room in the ED are some of these policies.

Although the model resulting from the study presented in this paper is relatively ad-vanced compared to previous studies, since multiple agents and multi-method simulationapproaches are considered, we believe this study is merely scratching the surface of whattruly is the potential of ABM in conveying patient flow problematics. The proposed modelcan be expanded in several different directions. In this regard, there are several avenues forfurther work in the modeling work presented in this study. Examples are:

• Replacing our assumption of a constant contamination rate with a dynamically chang-ing rate as a pandemic develops through time throughout a population.

• Replacing our assumption of no intra-hospital contamination with a probability ofsuch contamination.

• Replacing our assumption of perfect sorting of incoming patients with a probability ofclassification inaccuracies.

5. Conclusions

This study set out to model the patient flow behavior in the ED under pandemicconditions. We conclude, based on a comparison between actual and simulated behaviorof patients, that patient flow behavior under pandemic conditions with multiple agents(patients, department resources) and operational complexities (transitions, conditions,priorities, processing time, resource limitations) can be modeled with an acceptable degreeof accuracy. We found that the prioritization of COVID-19-contaminated patients hascomplicated the ED behavior and has significantly affected the studied key performancemeasures. Moreover, compared to the actual data, the simulated results highlight the needfor further study, including other vital agents (doctors, nurses, beds, other departments)and behavioral phenomena related to the studied patient flow regiment.

The final simulation model could emulate the patient flow behavior, as this researchset out to accomplish. This was confirmed with stakeholder informants who had extensiveknowledge and familiarity with the system itself. By this, the model was confirmed to posea valid re-representation of the patient flow process of the case organization.

We found and concluded that neither discrete-event nor agent-based modeling ontheir own was effectively able to encompass the resulting patient flow complexities stem-ming from the COVID-19 pandemic. However, combining the two in a hybrid simulationmodel capitalized on the strengths from both discrete-event and agent-based modeling.

Healthcare 2022, 10, 840 27 of 28

The strength utilized from discrete-event modeling was the ability to model the resource al-location between patient agents. Similarly, the strength utilized from agent-based modelingwas the ability to model the patient agent’s complex journey through the system.

In line with our stated research goals, this paper has provided:

• A conceptual and a computational model that mimics, explains, and predicts EDbehavior under pandemic conditions while considering multiple agent behaviors.

• An account demonstrating the rigorous and transparent implementation of conceptualmodeling of patient flow in the ED, to a greater extent than shown in previous researchliterature. By documenting the entire thought process behind each step of the modelingprocess and showing the resulting model, we believe that we contribute to modelingpractice by making these steps transparent and accessible to others. This will behelpful to other researchers to understand, assess and build trust in such models, andprovides an example than can be emulated by others to build their own thoroughlyvalidated models.

• The computational model we have provided includes several performance measuresthat will be useful for practitioners but have not been previously introduced in simula-tion studies of patient flow in the ED.

• Furthermore, we have discussed the broader applicability of our models and arecurrently undertaking further research using the presented model to study patientflow in the ED under pandemic conditions.

Author Contributions: Conceptualization, G.T., E.C.B. and I.E.-T.; data curation, G.T.; formal analysis,G.T.; investigation, G.T. and E.C.B.; methodology, G.T., E.C.B. and I.E.-T.; project administration,G.T. and E.C.B.; resources, G.T.; software, G.T.; supervision, G.T., E.C.B. and I.E.-T.; validation, G.T.,E.C.B. and I.E.-T.; visualization, G.T., E.C.B. and I.E.-T.; Writing—Original draft, G.T., E.C.B. andI.E.-T.; Writing—Review and editing, G.T., E.C.B. and I.E.-T. All authors have read and agreed to thepublished version of the manuscript.

Funding: This research received no external funding.

Institutional Review Board Statement: Not applicable.

Informed Consent Statement: Not applicable.

Data Availability Statement: The numerical data used in this study is not publicly available andthus is not for distribution.

Acknowledgments: The development, including Even Flørenæs, Linda Halle Nordahl, and MariaEndresen team at SUS, has been instrumental in the progression of this research.

Conflicts of Interest: The authors declare no conflict of interest.

Abbreviations

ABM—Agent-based modeling, ED—Emergency departments, PF—Patient flow, SUS—StavangerUniversitetssykehus (The University Hospital of Stavanger), WZ—Waiting zone, TR—Treatment room.

References1. Ahsan, K.B.; Alam, M.R.; Morel, D.G.; Karim, M.A. Emergency department resource optimisation for improved performance: A

review. J. Ind. Eng. Int. 2019, 15, 253–266. [CrossRef]2. Quah, L.J.J.; Tan, B.K.K.; Fua, T.-P.; Wee, C.P.J.; Lim, C.S.; Nadarajan, G.; Zakaria, N.D.; Chan, S.-E.J.; Wan, P.W.; Teo, L.T.; et al.

Reorganising the emergency department to manage the COVID-19 outbreak. Int. J. Emerg. Med. 2020, 13, 32. [CrossRef] [PubMed]3. Nadarajan, G.D.; Omar, E.; Abella, B.S.; Hoe, P.S.; Do Shin, S.; Ma, M.H.-M.; Ong, M.E.H. A conceptual framework for Emergency

department design in a pandemic. Scand. J. Trauma Resusc. Emerg. Med. 2020, 28, 118. [CrossRef] [PubMed]4. Ronen, B.; Pliskin, J.S.; Pass, S. The Hospital and Clinic Improvement Handbook: Using Lean and the Theory of Constraints for Better

Healthcare Delivery; Oxford University Press: Oxford, UK; New York, NY, USA, 2018; ISBN 978-0-19-084345-8.5. Hoot, N.R.; Aronsky, D. Systematic Review of Emergency Department Crowding: Causes, Effects, and Solutions. Ann. Emerg.

Med. 2008, 52, 126–136.e1. [CrossRef] [PubMed]

http://doi.org/10.1007/s40092-019-00335-x

http://doi.org/10.1186/s12245-020-00294-w

http://www.ncbi.nlm.nih.gov/pubmed/32552659

http://doi.org/10.1186/s13049-020-00809-7


http://doi.org/10.1016/j.annemergmed.2008.03.014


Healthcare 2022, 10, 840 28 of 28

6. Hwang, U.; McCarthy, M.L.; Aronsky, D.; Asplin, B.; Crane, P.W.; Craven, C.K.; Epstein, S.K.; Fee, C.; Handel, D.A.; Pines, J.M.;et al. Measures of Crowding in the Emergency Department: A Systematic Review: ED Crowding Measures. Acad. Emerg. Med.2011, 18, 527–538. [CrossRef] [PubMed]

7. Moskop, J.C.; Sklar, D.P.; Geiderman, J.M.; Schears, R.M.; Bookman, K.J. Emergency Department Crowding, Part 1—Concept,Causes, and Moral Consequences. Ann. Emerg. Med. 2009, 53, 605–611. [CrossRef] [PubMed]

8. Pitts, S.R.; Pines, J.M.; Handrigan, M.T.; Kellermann, A.L. National Trends in Emergency Department Occupancy, 2001 to2008: Effect of Inpatient Admissions Versus Emergency Department Practice Intensity. Ann. Emerg. Med. 2012, 60, 679–686.e3.[CrossRef] [PubMed]

9. Dooley, K. Simulation Research Methods. In The Blackwell Companion to Organizations; Baum, J.A.C., Ed.; Blackwell PublishingLtd: Oxford, UK, 2017; pp. 829–848, ISBN 978-1-4051-6406-1.

10. Currie, C.S.M.; Fowler, J.W.; Kotiadis, K.; Monks, T.; Onggo, B.S.; Robertson, D.A.; Tako, A.A. How simulation modelling can helpreduce the impact of COVID-19. J. Simul. 2020, 14, 83–97. [CrossRef]

11. Gul, M.; Guneri, A.F. A comprehensive review of emergency department simulation applications for normal and disasterconditions. Comput. Ind. Eng. 2015, 83, 327–344. [CrossRef]

12. Ostermann, T. Agent-based modelling for simulating patients flow in a community hospital. In Proceedings of the InternationalConference on Health Informatics (HEALTHINF-2015), Lisbon, Portugal, 12–15 January 2015; pp. 14–19.

13. Bhattacharjee, P.; Ray, P.K. Patient flow modelling and performance analysis of healthcare delivery processes in hospitals: Areview and reflections. Comput. Ind. Eng. 2014, 78, 299–312. [CrossRef]

14. Roberts, S.D. Tutorial on the simulation of healthcare systems. In Proceedings of the 2011 Winter Simulation Conference (WSC),Phoenix, AZ, USA, 11–14 December 2011; pp. 1403–1414.

15. Asgary, A.; Najafabadi, M.M.; Karsseboom, R.; Wu, J. A Drive-through Simulation Tool for Mass Vaccination during COVID-19Pandemic. Healthcare 2020, 8, 469. [CrossRef] [PubMed]

16. Luna, L.F.; Andersen, D.L. Using Qualitative Methods in the Conceptualization and Assessment of System Dynamics Models. InProceedings of the 20th International System Dynamics Conference, System Dynamics Society, Palermo, Italy, 28 July–1 August 2002.

17. Randers, J. Elements of the System Dynamics Method; MIT Press: Cambridge, MA, USA, 1980.18. Terning, G.; Brun, E. Systemic Conceptual Modeling of Patient Flow in a Hospital Emergency Department: A case example. In

Proceedings of the System Dynamics Society Record of the 38th International Conference of the System Dynamics Society 2020,Bergen, Norway, 19–24 July 2020; Volume 38.

19. Gunal, M.M. A guide for building hospital simulation models. Health Syst. 2012, 1, 17–25. [CrossRef]20. Albin, S.; Forrester, J.W.; Breierova, L. Building a System Dynamics Model: Part 1: Conceptualization; MIT: Cambridge, MA, USA, 2001.21. Suh, H. Key Figures. 2018. Available online: https://helse-stavanger.no/om-oss/nokkeltall-2018 (accessed on 14 February 2019).22. Suh, H. Om Oss. Available online: https://helse-stavanger.no/om-oss (accessed on 7 February 2019).23. Gallagher Healthcare. What Are the Different Types of Hospitals? Available online: https://www.gallaghermalpractice.com/

blog/post/what-are-the-different-types-of-hospitals (accessed on 14 February 2019).24. Minge, A. Hun skal hele tiden være orakelet og ta raske og rette avgjørelse. Denne dagen varte pausen i 30 sekunder. Stavanger

Aftenblad 2020. Available online: https://www.aftenbladet.no/magasin/i/EWgGxa/hun-skal-hele-tiden-vaere-orakelet-og-ta-raske-og-rette-avgjoerelse-denne-dagen-varte-pausen-i-30-sekunder (accessed on 14 February 2019).

25. Monks, T.; Currie, C.S.M.; Onggo, B.S.; Robinson, S.; Kunc, M.; Taylor, S.J.E. Strengthening the reporting of empirical simulationstudies: Introducing the STRESS guidelines. J. Simul. 2019, 13, 55–67. [CrossRef]

26. Borshchev, A. The Big Book of Simulation Modeling: Multimethod Modeling with AnyLogic 6; AnyLogic North America: Chicago, IL,USA, 2013; ISBN 978-0-9895731-7-7.

27. Helsedirektoratet—Avdeling sykehustjenester Faglige og organisatoriske kvalitetskrav for somatiske akuttmottak. Nas. FagligeRetningslinjer-2236 2014. Available online: https://www.helsedirektoratet.no/retningslinjer/kvalitetskrav-for-somatiske-akuttmottak/Faglige%20og%20organisatoriske%20kvalitetskrav%20for%20somatiske%20akuttmottak%20%E2%80%93%20Nasjonal%20faglig%20retningslinje.pdf/_/attachment/inline/aea8baff-94d2-44f5-b525-f6c1f518aed5:029310dc7ad46980ba0fe85bdd9887148d4206b1/Faglige%20og%20organisatoriske%20kvalitetskrav%20for%20somatiske%20akuttmottak%20%E2%80%93%20Nasjonal%20faglig%20retningslinje.pdf (accessed on 14 February 2019).

28. Senge, P.M.; Forrester, J.W. Tests for building confidence in system dynamics models. Syst. Dyn. TIMS Stud. Manag. Sci. 1980,14, 209228.

http://doi.org/10.1111/j.1553-2712.2011.01054.x






http://doi.org/10.1080/17477778.2020.1751570

http://doi.org/10.1016/j.cie.2015.02.018

http://doi.org/10.1016/j.cie.2014.04.016

http://doi.org/10.3390/healthcare8040469


http://doi.org/10.1057/hs.2012.8

https://helse-stavanger.no/om-oss/nokkeltall-2018

https://helse-stavanger.no/om-oss

https://www.gallaghermalpractice.com/blog/post/what-are-the-different-types-of-hospitals

https://www.gallaghermalpractice.com/blog/post/what-are-the-different-types-of-hospitals

https://www.aftenbladet.no/magasin/i/EWgGxa/hun-skal-hele-tiden-vaere-orakelet-og-ta-raske-og-rette-avgjoerelse-denne-dagen-varte-pausen-i-30-sekunder

https://www.aftenbladet.no/magasin/i/EWgGxa/hun-skal-hele-tiden-vaere-orakelet-og-ta-raske-og-rette-avgjoerelse-denne-dagen-varte-pausen-i-30-sekunder

http://doi.org/10.1080/17477778.2018.1442155

https://www.helsedirektoratet.no/retningslinjer/kvalitetskrav-for-somatiske-akuttmottak/Faglige%20og%20organisatoriske%20kvalitetskrav%20for%20somatiske%20akuttmottak%20%E2%80%93%20Nasjonal%20faglig%20retningslinje.pdf/_/attachment/inline/aea8baff-94d2-44f5-b525-f6c1f518aed5:029310dc7ad46980ba0fe85bdd9887148d4206b1/Faglige%20og%20organisatoriske%20kvalitetskrav%20for%20somatiske%20akuttmottak%20%E2%80%93%20Nasjonal%20faglig%20retningslinje.pdf





Modeling Patient Flow in an Emergency Department under ...

Documents

Transcript of Modeling Patient Flow in an Emergency Department under ...