Application of a Discrete Event Simulator for Healthcare Processes
Gregory Casier, Koen Casier, Jan Van Ooteghem and Sofie Verbrugge
Internet Based Communication Networks and Services research group IBCN, Ghent University, Belgium
Keywords:
Discrete Event Simulator, eHealth, Process Simulation, KPI, Multi-objective optimization.
Abstract:
Hospitals are currently catching up with other industries to utilize IT tools for optimizing their patient, data
and supply flows. The complexity of the processes and the amount of different resources and specialized
personnel make a good view on the costs and effects of changes hard to understand. In light of this growing
interest in healthcare towards leaner processes and better performance analytics, a process simulator was being
developed. A Discrete Event Simulator (DES) allows the monitoring of Key Performance Indicators (KPIs)
over existing processes and reveals opportunities for optimization. Opportunities to improve existing processes
can easily be tested to verify possible gains before an actual implementation. Harmful side effects caused by
changing the existing process can thus be measured on beforehand. The context in which the DES was being
developed and an overview of the tool by explaining its different phases is provided, as well as an indication
on potential further research topics and next developments.
1 INTRODUCTION
Hospitals consist of a complex set of clinical, mate-
rial and information flows, which must come together
in a point-of-care where the patient and the healthcare
professional interact. These patient care processes are
complex in nature (Mans et al., 2009) and often very
isolated over the different disciplines that are present
in a hospital (Lenz et al., 2002). While lean meth-
ods have been applied thoroughly in other sectors like
car manufacturing, hospitals are lagging behind. The
healthcare sector is currently in a lean learning phase
to reduce inefficient operations and increase quality of
service, but the synchronization of the different flows
in an efficient manner is still a huge challenge. (Kim
et al., 2006) A more patient oriented workflow, at the
same time enabling efficient hospital operation, calls
for innovative IT systems.
Several new methodologies are required to sup-
port this. One clearly identifiable need is to develop
novel solutions for identifying, installing and moni-
toring an appropriate set of KPIs over the current pro-
cesses. Process modeling methodologies will allow
studying and optimizing process flows. By adding
resource consumption information we can simulate,
analyze and evaluate the impact of the proposed pro-
cess optimizations for the chosen operational indica-
tors (e.g. patient safety, quality, cost efficiency). Sim-
ulating the proposal before implementing actual pro-
cesses can avoid a lot of unnecessary costs, especially
regarding the complex nature of processes in health-
care. (Bohmer, 2009)
For these reasons, a full discrete event simula-
tor was constructed, capable of simulating a pro-
cess based on statistical information on patient num-
bers and inter-arrival time, task timing, choices, etc.
The simulator runs as realistically as possible a set
of events through the process in which thousands of
tasks can be simulated in less than a minute, and
gather information on personal, patient and equip-
ment timesheets (when in use or in treatment), waiting
times and queue lengths, probabilities of events, etc.
These simulations allow us to monitor predefined
KPIs and as such identify opportunities to improve
the actual processes. Defining and adopting KPIs in
a healthcare organization has proven useful by not
only allowing the introduction of modern manage-
ment approaches, but also by helping to revise the
strategy. (Grigoroudis et al., 2012) Consequently,
changes that might result in redesigned processes can
also be checked on possible side effects before imple-
mentation.
Literature indicates different usage possibilities of
simulation-based tools in a hospital environment. In
(Jacobson et al., 2006) an overview is given of such
implementations. A distinction is made between pa-
241
Casier G., Casier K., Van Ooteghem J. and Verbrugge S.
Application of a Discrete Event Simulator for Healthcare Processes.
DOI: 10.5220/0005887702410246
In Proceedings of the Fifth International Symposium on Business Modeling and Software Design (BMSD 2015), pages 241-246
ISBN: 978-989-758-111-3
Copyright
c
 2015 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

tient flow optimization and analysis and health care
asset allocation. Within the patient flow optimization
there are several subtopics in which a DES has been
applied. These include Outpatient Scheduling, Inpa-
tient Scheduling and Admissions, Emergency Room
Simulation Models, Specialist Clinics and Physician
and Health Care Staff Scheduling. Also in (G
¨
unal
and Pidd, 2010) a literature overview of discrete event
simulators being applied in healthcare is being pro-
vided. The author indicates that the survey demon-
strates the specificity of the studies. The simulators
built have been found to be mostly unit or facility spe-
cific.
The remainder of this paper is organized as
follows: first an overview of the iMinds eHealth
project HIPS in which context the simulator was con-
structed is being provided. (HIPS, 2014) Secondly an
overview of the DES is given and its different phases
are being explained in more detail. Finally, we pro-
vide the reader with a general conclusion and make
recommendations on further possibilities to extend
the provided approach.
2 HIPS PROJECT
In this section a short overview of the project in which
this simulator was developed is being provided. The
HIPS project is an ongoing iMinds research project
with both academic and industrial stakeholders in
which the synchronization and optimization of differ-
ent hospital flows is a key goal.
2.1 Context
According to the analytics at Gartner (Shaffer, 2012),
”Healthcare is catching up with other industries in its
demand for more timely and robust performance an-
alytics and dashboarding”. Many of the technologi-
cal aspects are feasible today. But it has yet to be-
come a reality because the healthcare supply chain,
from manufacturer to patient, remains fragmented,
with limited visibility and interconnection (Ebel et al.,
2012).
Within a hospital environment a huge variety of
processes and resources can be identified (Figure 1).
These processes vary in nature. Processes can often
not be planned in advance, and may occur in sequen-
tial or iterative mode (Bohmer, 2009). Most impor-
tantly, not being able to execute a process in a timely
way may have a life threatening impact on the patient
whereby the liability of the staff is very high. This
makes a hospital environment an extremely complex
environment to manage, unlike manufacturing orga-
nizations.
The mere size of the hospital has only a minor im-
pact on the variety of processes. It is the number of
supported treatments and specializations within a sin-
gle hospital environment that has a high impact on
this diverseness.
Figure 1: Overview of processes involved (AS IS).
Within this large variety of processes 2 main types
of processes can be identified:
• The actual Treatment processes aiming to care,
cure or help the patient, whereby treatment in-
cludes all technical medical and clinical activi-
ties related to diagnosis and therapy of illnesses,
surgery, palliative care or other care; in a hospi-
talization mode or in a day treatment mode. This
is the fundamental production process and deter-
mines how the care is given, and is reflected in a
care path.
• The Supporting processes that target to serve or
to support the treatment of a patient. Supporting
processes basically include all non-treatment pro-
cesses; finance, logistics, human resources, pur-
chasing, etc.
One of the primary goals of the HIPS project is to
design a methodology in order to optimize the sup-
porting processes and align them with the treatment
processes of the patient. This results with a single,
integrated flow as depicted in Figure 2.
2.2 Discrete Event Simulator within
HIPS
There are several reasons for which a DES is the ap-
propriate tool for analyzing and optimizing processes
within a hospital context.
1. A first reason is that the simulator allows the test-
ing of different alternatives next to each other for
a broad range of performances based on key per-
formance indicators.
Fifth International Symposium on Business Modeling and Software Design
242

Figure 2: Overview of processes involved (TO BE).
2. Secondly, operational modeling is a trend of the
last years and more and more operational pro-
cesses are decently modeled and documented.
Simulating these operational processes is the next
step in discovering and visualizing problems such
as bottlenecks, deadlocks, inefficient use of mate-
rial and personal, increasing delays, etc.
3. A third reason we identify is that operational opti-
mization needs to be run while closely monitoring
the performance of these operational processes.
The performance of an operational process, espe-
cially in healthcare, is not simply equal to the cost
of executing the process. As such different KPIs
of the operational process should be kept in mind
while running an optimization, and keeping sev-
eral such KPIs in mind at the same time is possible
by using an operational simulation tool.
For these reasons, a discrete event simulator was
developed and applied within the HIPS project. The
simulator itself is being explained in the next para-
graph.
3 DISCRETE EVENT
SIMULATOR
3.1 Motivation
The key need that the simulator fulfills are summa-
rized below.
1. Finding key performance indicators of the process
2. Finding opportunities for optimization
3. Checking for side effects of an optimization pro-
posal
The identification and monitoring of KPIs over sev-
eral simulations of an existing process allows us to
identify opportunities to optimize this process even
further. These opportunities can than also be virtually
incorporated in the process and new simulations can
provide insight in possible side effects.
Not only the motivation for applying a DES in
a healthcare environment is of importance here, but
also the architectural choice needs some clarification.
There are plenty of DES software tools available, an
clear overview was given in (Demyttenaere, 2014).
From this list, the decision was made to implement a
DES based on the MASON library (Multi-Agent Sim-
ulator Of Neighborhoods). There are several reasons
for which this approach was chosen:
• A first major requirement was to narrow the list
down by removing all commercial software pack-
ages. We wanted to have complete control over
the code to have the freedom to expand it any way
we deem necessary.
• Another requirement that guided our decision pro-
cess was the preference to make use of the Ac-
tiviti BPM (Business Process Management) plat-
form (Rademakers, 2012). This requirement
implies that the preferred language of the li-
brary/framework that will be selected is Java.
Due to these requirements the initial list was heav-
ily reduced. From the remaining possibilities for a
DES, the MASON library was selected, which will
be further explained in the Simulation paragraph.
3.2 Simulator Overview
An overview of a simulated process can be found in
Figure 3. Four different stages have been identified
in the flow of simulator usage. These are being ex-
plained more into detail in the following paragraphs.
1. Input phase
2. Simulation phase
3. Output phase
4. Analysis phase
Figure 3: Overview of Simulator Steps.
Application of a Discrete Event Simulator for Healthcare Processes
243

4 INPUT
In a first stage, both the process we want to simulate
as well as the parameters that define this process are
being delivered as input. A visual representation of
possible inputs is given in Figure 4
Figure 4: Input Phase.
4.1 Process Flow
The process to be simulated has to be provided in
the Business Process Model and Notation (BPMN)
standard. BMPN is a well-known and widely ac-
knowledged process flow standard with serialization
in XML (Extensible Markup Language) format either
in a proprietary or XPDL (XML Process Definition
Language) format. Our tool works on both XPDL and
proprietary Activity serialization format. Drawing the
process outline in BPMN, serializing this scheme to
xml and loading the xml in the simulator form the first
steps in this process.
4.2 Process Parameters
Now that we have made the process outline known to
the simulator, we also have to provide it with the con-
text in which this process takes place. These context
parameters are being provided in an xml file as well.
Most of the Simulation Parameters are typically con-
cerning costs and availability of resources and timings
and probabilities of the different process steps (Tasks)
involved.
Several examples of relevant process parameters
in a hospital environmnent are provided below. A first
category of parameters are those concerning the re-
sources (employees, rooms, equipment, etc.)
• Concerning Employees (Nurses, Doctors, Sur-
geons, etc.)
– Availability (expressed in several blocks during
a day)
– Cost (both fixed and variable)
– Resource Pool (for example, the group nurses
can contain doctors, but not vice versa)
• Concerning Other Resources (Operating room,
Examination room, etc. )
– Availability (expressed in several blocks during
a day)
– Cost (both fixed and variable)
– Grouping (for example an Operating room
could be used as an Examination room but not
vice versa)
A second category of parameters for the process are
those related to the execution of tasks in the process.
• Mean Time of task duration
• Distribution of task duration
• Resources required for a task
5 SIMULATION
In the next stage in the simulation process, the input
from the previous step is being used to run the actual
simulation. This is done by means of a Discrete Event
Simulator, which models the operation of a system
as a discrete sequence of events in time. ”Discrete
event simulation, based on a library of event models,
is a way of simulating or characterizing cause-effect
events that can be described as occurring at one par-
ticular moment in time a discrete event. These events
are not continuous and have finite result outputs that
are selected from a group of available outputs or cal-
culated based on the inputs.” (Hoare et al., 2002) Dur-
ing the simulation, convergence parameters are being
monitored to check possible stop or convergence con-
ditions.
The simulator was written entirely in the Java
language and was built on top of several libraries,
among which MASON. MASON stands for Multi-
Agent Simulator Of Neighborhoods and contains a
fast discrete-event multi agent simulation library core.
(Luke et al., 2004)
Several parameters are being monitored during the
simulation to make sure the simulation gets halted
when reaching convergence. The predefined criteria
that make the simulator to stop running are listed be-
low:
• Convergence of Full Process (Total duration of the
process defined)
• Convergence of all Statistics (Every task’s dura-
tion)
Fifth International Symposium on Business Modeling and Software Design
244

• Maximum amount of Reports in which the data is
stored is being reached
6 OUTPUT
When the simulation has ended for one of the reasons
above, all detailed descriptions of the results are being
outputted in xml-files. These include the steps that
have been taken, the timings, the amount of resources
utilized over time, etc.
All of the raw data is being kept in stand-alone
xml files that are used to perform analyses on top of
it. This allows us to perform different kind of analyses
afterwards, without the necessity to rerun the simula-
tion itself.
7 ANALYSIS
To be able to gain insights from these raw data files,
there is a final Analysis phase. The custom GUI al-
lows to open and visualize the data graphically. Pre-
defined KPIs are being calculated from the output and
these are being plotted in several graphs.
In the hospital context it is very likely that multi-
ple, conflicting KPIs get defined. An overview of sev-
eral of some of the KPIs we ran into during the HIPS
project are the following (De Pourcq et al., 2015):
1. Patient related KPIs
(a) Number of new patient records, Number of fin-
ished patient records, etc.
(b) Mean lead time, maximum lead time, etc.
2. Process related KPIs
(a) Execution cost of the process, cost per patient,
etc.
(b) Idle Time
3. Recourse related KPIs
(a) Usage of each resource (on average, minimal,
etc.)
(b) Idle time of each resource
4. Bottlenecks encountered
(a) Tasks that cause bottlenecks
(b) Resources that cause bottlenecks
An optimal level for all of the KPIs is because of
the conflicting nature impossible to achieve. There-
fore there exist multiple equally rewarding possibil-
ities and the most desirable solution is very much
dependent on the preferences of the hospital gover-
nance. A multi-KPI overview of each process under
consideration can be gained from the simulator and
matching these values with the preferences might re-
sult in an optimal process design.
Figure 5: Analysis Phase.
8 NEXT STEPS AND FUTURE
WORK
The current context in which the simulation was de-
veloped is the hospital context. Both within and out-
side of this context can further research possibilities
be identified.
Within the hospital environment coexist complex
flows of patients, data and supplies. These processes
are often susceptible for further optimization. The
current simulator allows a lot of this setting to be
modeled, but not all of it. Expanding the software to
incorporate scheduling algorithms for example might
be a valuable next step. Modeling different stock poli-
cies might be another possibility. Current research is
ongoing concerning the matching of the KPIs with the
preferences of hospital governance and visualizing
the results. This way, hospital governance can steer
the process by adjusting preference parameters and
monitor results in a visually attractive way. Another
line of work in progress is applying more complex
resource selection methods in the simulator. More
specifically ontology-based resource allocation in the
simulation should more realistic resource selection in
future simulations.
Further research possibilities outside of the hos-
pital environment are ubiquitous. For this reason the
simulator was built as generically as possible, being
able to read in any type of process and resources. This
allows completely different processes to be simulated
without the need for imminent adjustments.
Application of a Discrete Event Simulator for Healthcare Processes
245

9 CONCLUSION
In this paper we presented the key concepts of a dis-
crete event simulator that can be applied for process
simulation within a hospital flow optimization con-
text. An overview of the simulator was being pro-
vided and the main steps (Input of process flow and
resources, Discrete Event Simulation, Output of raw
data and Analysis and visualization) have been ex-
plained. Simulating current processes has several ad-
vantages. It allows us to monitor key performance
indicators of a process, identify opportunities for pro-
cess improvement and check for possible side effects
of process optimization proposals.
Please note that ONLY the files required to compile
your paper should be submitted. Previous versions
or examples MUST be removed from the compilation
directory before submission.
We hope you find the information in this template
useful in the preparation of your submission.
ACKNOWLEDGEMENTS
This research was carried out as part of the iMinds
Health HIPS project. This project is co-funded by
iMinds Health, and Amaron, Aucxis, H.Essers, AZ
Maria Middelares and AZ Nikolaas.
REFERENCES
Bohmer, R. M. (2009). Designing care: aligning the nature
and management of health care. Harvard Business
Press.
De Pourcq, K., Gemmel, P., and Trybou, J. (2015). Mea-
suring process performance in hospitals. In Proceed-
ings 22th International Conference of European Op-
erations Management Association (EUROMA).
Demyttenaere, P. (2014). Techno-economische Evaluatie
Van Ehealth-diensten Met Behulp Van Ontologiege-
baseerde Operationele Procesoptimalisatie. Master’s
thesis, Universiteit Gent, Ghent, Belgium.
Ebel, T., George, K., Larsen, E., Neal, E., Shah, K., and
Shi, D. (2012). Strength in unity : The promise of
global standards in healthcare. Technical Report Oc-
tober, McKinsey.
Grigoroudis, E., Orfanoudaki, E., and Zopounidis, C.
(2012). Strategic performance measurement in a
healthcare organisation: A multiple criteria approach
based on balanced scorecard. Omega, 40(1):104–119.
G
¨
unal, M. M. and Pidd, M. (2010). Discrete event simu-
lation for performance modelling in health care: a re-
view of the literature. Journal of Simulation, 4(1):42–
51.
HIPS (2014). Hips, innovation by coordinating and opti-
mizing patient, material and information flows in hos-
pitals.
Hoare, R., Ahn, J., and Graves, J. (2002). Discrete event
simulator. US Patent App. 10/043,847.
Jacobson, S. H., Hall, S. N., and Swisher, J. R. (2006).
Discrete-event simulation of health care systems. In
Patient flow: Reducing delay in healthcare delivery,
pages 211–252. Springer.
Kim, C. S., Spahlinger, D. A., Kin, J. M., and Billi, J. E.
(2006). Lean health care: What can hospitals learn
from a world-class automaker? Journal of Hospital
Medicine, 1(3):191–199.
Lenz, R., Elstner, T., Siegele, H., and Kuhn, K. A. (2002).
A practical approach to process support in health in-
formation systems. Journal of the American Medical
Informatics Association, 9(6):571–585.
Luke, S., Cioffi-Revilla, C., Panait, L., and Sullivan, K.
(2004). Mason: A new multi-agent simulation toolkit.
In Proceedings of the 2004 swarmfest workshop, vol-
ume 8.
Mans, R., Schonenberg, M., Song, M., van der Aalst, W. M.,
and Bakker, P. J. (2009). Application of process min-
ing in healthcare–a case study in a dutch hospital.
In Biomedical Engineering Systems and Technologies,
pages 425–438. Springer.
Rademakers, T. (2012). Activiti in Action: Executable busi-
ness processes in BPMN 2.0. Manning Publications
Co.
Shaffer, V. (2012). Hype Cycle for Healthcare Provider Ap-
plications and Systems. Technical Report july, Gart-
ner.
Fifth International Symposium on Business Modeling and Software Design
246