Degree project
Simulation of Assistive Systems for Elderly People Author: David Garcia Perez Supervisor: Sabri Pllana
Date: 20141108
Course Code: 4DV01E, 15 credits Level: Master
Department of Computer Science
Faculty of Technology SE391 82 Kalmar | SE351 95 Växjö Phone +46 (0)77228 80 00
[email protected] Lnu.se/facultyoftechnology?l=en
Abstract Aging population is becoming a problem in a lot of countries, being Sweden one of them, and that is leading society to a lack of the necessary people to take care of all the elderly people. The CareIP device, an alarm system for the elderly people, with which they are able to ask for assistive help in case they need it, has been used all over Sweden for a while now. In this thesis, a simulation model has been built in order to study how this care giving system works in the specific case of V¨axj¨o. This model can be used to simulate real situations and prevent certain problems as it could be the lack or excess of resources, long waiting times or unexpected increase on the number of alarms, which could lead to critical situations on a emergency healthcare system. Keywords: Emergency healthcare systems, healthcare modeling, discrete event simulation, Arena Simulation Software
i
Acknowledgements I would like to thank to my supervisor Sabri Pllana, who guided me during all the process with great support and advice. I also wish to thank P¨ar Kingstrad, who kindly and quickly provided me with all the information I needed, and my family for their great support. Without them, this project would not have been possible.
ii
Contents 1 Introduction 1.1 Background and Previous Research 1.2 Problem Definition . . . . . . . . . 1.3 Purpose and Research Questions . . 1.4 Outline of the Report . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
1 1 2 2 3
2 General System Description
4
3 Background Study 3.1 Discrete Event Simulation . . . . . . . . . . . . . . . . . . . . 3.2 Overview of Simulation Applied to Health Care Systems . . . 3.3 Experimental Background . . . . . . . . . . . . . . . . . . . .
7 7 7 8
4 Methodology 4.1 Data Collection . . . . . . . . . . . . . . . . . . . . 4.2 Discrete Event Simulation . . . . . . . . . . . . . . 4.3 Arena Simulation Software Overview . . . . . . . . 4.4 Development of Simulation Model for Elderly Care 4.4.1 Basic Features for the Simulation . . . . . . 4.4.2 Arena Simulation Software Modules . . . . . 4.4.3 The Model Explanation . . . . . . . . . . . 4.5 Verification and Validation of the Model . . . . . . 4.6 Experimentation . . . . . . . . . . . . . . . . . . . 4.7 Model Animation . . . . . . . . . . . . . . . . . . . 4.8 Social and Ethical Considerations . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
11 11 11 14 15 15 17 23 29 30 31 31
5 Results and Analysis 34 5.1 Entities Results and Analysis . . . . . . . . . . . . . . . . . . 34 5.2 Resources Results and Analysis . . . . . . . . . . . . . . . . . 34 5.3 Queues Results and Analysis . . . . . . . . . . . . . . . . . . . 36 6 Conclusions 38 6.1 Advantages and Disadvantages . . . . . . . . . . . . . . . . . . 39 6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 References
41
iii
Appendices Appendix A: Validation Results . . Appendix B: Arrival Experiment . Appendix C: Resources Experiment Appendix D: Arrival Real Data . . Appendix E: Queues Experiment .
iv
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
1 . 1 . 5 . 9 . 11 . 14
List of Figures 1.1 2.1 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 5.1 5.2
Population pyramid (1991-2011) . . . . . . . . . . . . . . CareIP device flowchart in V¨axj¨o. . . . . . . . . . . . . . Diagram representing the steps for a Simulation study. . Some of the resources defined in the model. . . . . . . . The Create Module and its Properties. . . . . . . . . . . The Decide Module and its Properties. . . . . . . . . . . The Assign Module and its Properties. . . . . . . . . . . The Process Module and its Properties. . . . . . . . . . . The Record Module and its Properties. . . . . . . . . . . The Route Module and its Properties. . . . . . . . . . . The Submodel Module and its Properties. . . . . . . . . The Dispose Module and its Properties. . . . . . . . . . . Call Center part logic. . . . . . . . . . . . . . . . . . . . The Schedule used for entities (calls) generation. . . . . . Submodel for Zone assignment of the entities. . . . . . . The assisntance part of the model. . . . . . . . . . . . . Expression to decide if it is weekend or not in the model. Submodel corresponding to days on not weekends. . . . . The Call Center part of the animation. . . . . . . . . . . The assistance part of the animation. . . . . . . . . . . . Result of the simulation increasing the arrivals. . . . . . Rate of arrivals from different months of 2013. . . . . . .
v
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
1 4 13 16 17 18 19 20 20 21 22 22 23 24 25 26 27 28 32 33 35 37
List of Tables 2.1 2.2 4.1 4.2 4.3 4.4 5.1 5.2
Personnel available on the care groups. . . . . . . . . . . Zones assigned to each Night Patrol. . . . . . . . . . . . Relation of model zone numbers and real zones. . . . . . Call Statistics of V¨axj¨o kommun in november 2013. . . . Zones assigned to each Night Patrol. . . . . . . . . . . . Real Data compared to the confidence intervals obtained. Experimental results obtained. . . . . . . . . . . . . . . . Resources usage on night patrols. . . . . . . . . . . . . .
vi
. . . . . . . .
. . . . . . . .
. . . . . . . .
5 5 16 16 28 29 34 35
1
Introduction
In this section we present a background of the problem, the problem definition, and the outline of the sections of the thesis. 1.1
Background and Previous Research
Nowadays society is facing a problem of aging population in the developed countries. Due to improvement in living standards and health systems, population life expectancy is increasing a median of 1.7 years for women and 2.1 years for men, being 82.6 and 76.7 years respectively in 2009 in Europe [4]. At the same time, fertility has been decreasing from the 1960s, dropping from 7.5 million live births to 5.4 million in 2008 [3]. So basically population above 60 years old is increasing, and population under that age is decreasing, as we can see in Figure 1.1.
Figure 1.1: Population pyramid of Europe comparing 1991 and 2011. Reached the point where the top of the pyramid is much wider than the bottom, the working-age population is smaller than the population older than 60. Having in mind that all that elderly people will eventually get to the point where they will need healthcare assistance, there will not be enough people to take care of them. 1
Sweden, our case of study, is one of the more affected countries by this phenomenon in Europe, with only 9% of the population older than 65 in 1905, this population increased to 17% in 2005, and it is expected to be 24% in 2050 [11, Pg. 10]. On the other side, though, Sweden is the country that offers more publicly financed care for the elderly people, actually 2.8% of the GDP of the country is spent in those matters, followed by Norway with 1.8% [11, Pg. 5]. Elderly people in Sweden are provided with different kind of support, like home adaptations, technical devices, human care, and even meals on wheels. Obviously, there exist special housing for elderly people, but due to growth on elderly population, that is not the optimal thing to think about, either because of the elderly people do not usually want to leave their own home, or because of the economic expense involved for the government, the own person, or even his or her relatives. 1.2
Problem Definition
The problem of aging population will generate different problems as it worsens: health care expenses will increase, since elderly people require a higher health care assistance; the number of specialized health care people like nurses will decrease, specially if it is compared to the number of elderly people that need their assistance; special housing for elderly people end up collapsing; the number of occupationally active people will decrease, which will generate problems related to the pension systems; etc. There is not a general solution for all those problems. What can be done, though, is try to help them with solutions for some of the mentioned problems. 1.3
Purpose and Research Questions
In this thesis some of those problems will be addressed with an study, simulation and optimization on the health care for elderly people in V¨axj¨o, which might reduce health care expenses, and help the future lack of nurses and room in special housing for elderly people. The purpose and goals of this thesis were to develop a simulation model to be able to analyze the system and its optimality, and detect the possible changes that could be made in order to make the V¨axj¨o health care more optimal and better distributed regarding the resources, and hence, less expensive, helping some of the problems mentioned in the last section.
2
1.4
Outline of the Report
The rest of the thesis is organized as follows. In Section 2 we present a general description of the care-giving system that is addressed in this thesis. In Section 3 the background reviewed in order to write the thesis will be presented. In Section 4, we describe the methodology used to build the model. That includes data collection, design of the model, verification and validation of the model, experimentation done with it, and also a description of the animated part of the model. In Section 5 the results are described and analyzed. In Section 6 the conclusions obtained from the study are presented, as well as advantages, disadvantages and future work.
3
2
General System Description
The CareIP device is a phone system that will put in contact a user and an assistant of a call center when the button is pushed, and will provide him or her with assistive help if needed. This device was developed by Jan-Erik Larsson in 1975. It has been used in Sweden for a while now, and has been exported to other EU countries like Denmark and the UK. Whenever the user push the button in the device, it will contact with the Call Center. There are two Call Centers in Sweden, so depending on the user location, he will be put in contact with one of them depending on his proximity to it. In V¨axj¨o’s case, the user will be put in contact with the Call ¨ Center in Orebro. In the Call Center, an assistant will decide if the call needs to be taken care of by a nurse or not. That is because some of the calls are just made to check if the device is working, or even when the elderly user feels alone and just needs to talk to someone, so in those cases, no further step will be taken by the assistant in the Call Center. Otherwise, the assistant will contact the closest nurse in the V¨axj¨o area. This flowchart can bee seen in Figure 2.1.
Figure 2.1: CareIP device flowchart in V¨axj¨o. During the day, the care assistants, are divided in care groups , each group taking care of one of the 18 zones in V¨axj¨o. Those groups will have a number of personnel depending on the extension and the population of their zone. The zones are the following, sorted by relevance: Anna Trolle, ¨ Dalbo, Teleborg, Rottne, Centrum, S¨oder, Lammhult, Lassaskog, Ojaby, ¨ ¨ ˚ Sandsbro, Hovslund, Borgm¨astaren, Oster, Oster Aryd, Kinnevald, Gemla, Kvarng˚ arden and Sj¨oliden. The number of personnel of each care group will slightly reduce on week ends. 4
During the night, though, each of the 18 zones will be associated to one of the 4 night patrols. The night patrols are named after the zone they work in, so there is the east night patrol, the west night patrol, the north night patrol and the south night patrol. We can see the staff available on each care group in the Tables 2.1 and 2.2. Anna Trolle Dalbo Teleborg Rottne Centrum S¨oder Lammhult Lassaskog ¨ Ojaby Sandsbro Hovslund Borgm¨astaren ¨ Oster ¨ ˚ Oster Aryd Kinnevald Gemla Kvarng˚ arden Sj¨oliden
Personnel Week Days 19 12 13 9 16 10 15 12 10 10 7 9 10 5 9 5 10 9
Personnel Weekends 11 7 9 9 8 7 6 7 6 6 6 5 6 3 5 4 5 4
Table 2.1: Personnel available on the care groups.
Night Night Night Night
Patrol Patrol Patrol Patrol
1 2 3 4
Personnel Available 6 6 6 6
Table 2.2: Zones assigned to each Night Patrol. So once the call is approved by the call center assistant, he will contact the closest nurse available in the patient’s zone according to the current time or day of the week. The nurse will spend from 4 to 10 minutes depending on his current location to get to the patient’s location. 5
Finally, the nurse will arrive to the patient’s place and will help him as needed. The calls can be done due to bathroom or daily matters, or can also be health emergencies, so the nurse might spend from 10 to 60 minutes to assist the patient.
6
3
Background Study
In this section, some background in Discrete Event Simulation and the reason why the simulation applied to health care systems has gained so much importance in the last decade will be discussed. Plus, a few experimental healthcare simulation related works will be mentioned and described. 3.1
Discrete Event Simulation
For a basic understanding of this thesis, first thing we have to know is what is a discrete event simulation. We can understand DES(discrete event simulation), as a modeling of a system which behavior is changed during time by a discrete sequence of events. There is a lot of literature describing the important aspects for simulation analysis, such as data collecting and analysis, modeling, verification and validation of the model, such as [6] and [7]. In Banks’ articles about DES, we can find a defined list of steps for the modeling of a system [6, 1], which is the steps followed in this thesis (with a little modification of the flowchart). Other interpretations can be found in different articles about DES [7]. 3.2
Overview of Simulation Applied to Health Care Systems
World’s population has been aging (percentage of older people is rising over total population) since the mid-twentieth century, specially in the more developed regions [10, 4, 3]. In addition, cost of health care in countries like USA is increasing due to the need of more equipment for the hospitals [14], since elderly population require more medical attention in general. Due to all of that reasons, there has been an increasing interest in healthcare systems simulations in order to use more efficiently the resources available. That includes optimizing the staff scheduling, improving the schedules and patient flow, and reducing at the same time the waiting time (which is a critical matter in health care systems, specially in emergency situations). That will reduce the cost and will improve the patient’s satisfaction towards the service. Additional information about the importance that simulation is taking in health care matters can be found in [8, 9, 12], where the current situation of simulation applied to the health care systems is described widely. Those papers explain the barriers on the use of simulations on health care systems, like the lack of personal experienced resources in companies able to model the systems, or the lack of confidence on simulation systems by the managers and administrators, who believe in simpler, deterministic analytic techniques 7
for decision-making, and do not like the dehumanizing nature of simulation. It is for that reason that most of the modeling and research applied to health care systems is made in universities and colleges now a days. Other matters are analyzed in the articles, such as the domain of heath care simulations and the different aspects that can be improved, the more common tools used for modeling (where Arena Simulation Software is mentioned), and the more common issues on modeling a health care system, like the unpredictability of the arrivals on emergency systems, or the difficulty of validating the model and design proper experiments. Most of the papers [1, 8, 12, 13] agree about the complexity of the models. A simple model is more suitable than a complex model at the beginning, where the important matter is to verify that the model accomplishes the requirements for the simulation, and then the model can become more complex. 3.3
Experimental Background
Due to that aging population problem and by consequence, the increasing demand for healthcare services, researchers have taken advantage of simulation technology to develop models that are useful for analyzing the situation on the health care systems. Because of that, we can see that most of the problem formulations in the background literature are related to those matters. Since it is a very widespread problem all over the world, even though the problem formulation of most of the related literature is very similar (increase the efficiency, optimize the waiting time of the patient and reduce cost), the health care systems analyzed are distributed all over the world. For instance, we can find articles like [14] and [5] analyzing systems located in the USA, being a concrete hospital for the first article (with the target of generalizing the model to any hospital), and the US Army emergency health system for the second paper. On the other hand, in [15] Pedro Marinho and Luis Ricardo analyze the Brazil emergency medical system known as SAMU (portuguese acronym for Urgency Medical Assistance Service), in [17] Shao Jen analyzes the Emergency Department of a Taiwanese Hospital, and in [2] Christine Duguay analyzes the emergency department at Dr. Georges-L. Dumont Hospital in Moncton in Canada. Once the problem is formulated, according to [1], it is time for Setting the objectives and the project planning in order to build the model. Since we had a limited amount of time to interview the V¨axj¨o kommun health care system, we did not have the possibility to do the Setting the objectives and project planning and the data collection stages in different times, but that problem is common in the literature review [15, 17], where those two stages 8
are also done at the same time. Since we are working with emergency systems, where despite of the data collection, the system is unpredictable and the lack of data is inevitable sometimes, it is also common to make assumptions about data [15] and some of the overview literature encourage the modeler to ”make it (the data) up!” [9]. Of course, those assumptions have to be confirmed in the verification stage. When it comes to build the model, as said before, most of the background literature recommends to begin with a not too complex model [1, 9]. There is even [13] fully dedicated to why a simulation should be simple, explaining concepts like even though real-world model are usually very complex, making complex models too is not as important as identifying the important aspects for the analysis of the simulation and abstract the rest of aspects that are not necessary, or in other words, simplify it. So at the end, the real challenge is not building an exact replica of the real-world model, but build a simple model that represents a close enough approach to the real-world model, and with results that are close to it. The models in the papers are usually represented by a flowchart, and they are not commonly complex. Next step in Banks [1] flowchart is verification. This step can be considered as a way of verifying if the simulation behavior is the expected or if it needs changes in the model, or as a way of checking if the client agrees with the result of the model, and it fits to the real-world model in terms of functionality and behavior. In [14] they used the first method, and the model was verified by the administration of the hospital that the model was based on. On the other hand, on [15], what they did to verify the model was to build the model in a modular structure, such that each module could run separately, and they analyzed the behavior of each module, and in unlikely events, to check if there was any anomaly. In the end, verifying the model is to check from different perspectives if the it represents properly the real-world model and if its behavior is as expected. In some cases that procedure is not considered relevant enough to be mentioned in the documentation. After the verification, we need to validate the model. To validate the model we have to check if it is an accurate representation of the real-world model and if it can be used for the purposes of experimentation [1]. To do that, the real-world model data and the simulated data are statistically compared to check if there are significant differences between them. In [14], for example, they use a two-sample t-test with α = 0.5 to check if the data obtained with the simulation (5 days with 100 replications each) was significantly different from the real data collected at the hospital. In other experimental papers [5, 15, 2], confidence intervals were built 9
to compare the obtained simulation data and the collected data. These intervals were built based on different attributes of the simulation, like time between arrivals, waiting time, time spent by the patients on the Care Unit and number of dispatched patients. After the model has been validated, we will finally do the experimental design and the experimentation with the model. In the related studies, what has been done is define some control variables that change the simulation in some way, and give them different values that are thought to improve the simulation in some way. In brief, they create different variations of the simulation, for example one variation for each type of surgery [14], or change number of physicians, nurses and rooms for each variation [2], or just try to improve concrete bottle necks of the simulation, as it could be a patient assistance interrupted by the nurses or medics lunch break [5].
10
4
Methodology
The methodology used in this thesis is collect certain data in order to be able to build an accurate enough model that represents how the elderly care system works in the real world. In this section we will explain how the data was collected, what a discrete event simulation is, how we built the model, how we validated it, the results obtained and the discussion of them. 4.1
Data Collection
For the data collection, we contacted a current developer and former nurse for the healthcare system in V¨axj¨o. He explained us how the entire system works, including care groups and its zones, time schedules for each group, times spent by the patients contacting the call center, as well as by the assistants receiving the calls, attending them, and sending them back to V¨axj¨o in case it is necessary, and by nurses moving to the patient’s place and taking care of them. He also provided us with data about the name and personnel available of each care group, and statistics of some 2013 months about the number of calls done by the patients at different time intervals during the day. 4.2
Discrete Event Simulation
A Simulation is a representation of a real-world process over time using a model. The state of the system will be changed by events. When those events happen at discrete points in time, which is our case, it is called Discrete Event Simulation. Additional information on this topic is available in [1]. The simulation is used to analyze the behavior of a real-world system, and have a realistic idea of what would happen in special conditions. In our case, the real-world system is the care phone system used in Sweden for elderly care matters. In a Discrete Event Simulation, the model has to be realistic enough to have a realistic approach of the problem, but still, some of the things of the real-world system will always be abstracted. Building a simulation is an iterative process. Again, in [1], we can find an interesting way of representing the building process as steps guide: 1. Problem formulation. First thing needed for a simulation is the problem that needs to be analyzed. In our case, there is no problem itself. What we did, though, is analyze the system and study how the it would react to special situations (fast growing of number of patients, staff reduction, etc.) 11
2. Setting of objectives and overall project plan. This include the things that will be included in the model, such as staff, resources, etc., and the questions that have to be answered by the simulation analysis. 3. Model conceptualization. This is the kind of abstraction used to build the model, the components of it, the mathematical relations, attributes and variables. The model should be simple at the beginning, and grow over time until its complexity is appropriate. 4. Data Collection. This is the step when, once we know the data needed to build the model, we collect it from the appropriate sources. 5. Model Translation. Once we have all the information needed to build the model, it is time to translate it into something that a computer can recognize. In our case, we used Arena Simulation Software for this matter. 6. Verified? In this step we have to verify if the model is working as expected, and if we can analyze what we wanted with the data obtained from it. 7. Validated? To validate a model, we have to determine if the model is a close enough representation of the real-world system. 8. Experimental Design. In this stage, we have to define the experimental details, like the simulation time, the number of times we will run it, etc. 9. Production runs and analysis. We will study the results of the simulation here, and determine if they are what we needed. 10. More Runs? In case the results of the step before are not what we needed, we will determine if we need to run it again, or simulate additional scenarios. 11. Documentation and Reporting. We will document the model for the possible people interested in used it again, or even modify it. The results need to be reported clearly too. 12. Implementation. The simulation has to be judged by the client. As we mentioned previously, some of these steps are iterative. We can see the flow chart of the process in Figure 4.1. The diagram is based on the the one in Jerry Banks paper with slight modifications. 12
Figure 4.1: Diagram representing the steps for a Simulation study, based on a diagram presented in Jerry Banks paper. [1]
13
4.3
Arena Simulation Software Overview
Arena is one of the most widely used simulation software, distinguished by its ease of use and high utility. Plus, Arena provides a free version able to build simple models, so the client is able to try it out and see if the software fits his requirements. It is a discrete event simulation software developed by Rockwell Automation. With this software, the user can use different modules and connect them together in order to build the model. Once the model is built, the user can run and monitor the simulation to see if it behaves as expected, and analyze the statistics obtained from it. According to [16], the basic pieces in Arena software are the following: Entity. These are the ”players” of the simulation. The entities will be created during the simulation, they will interact with the modules of the model following their path, and finally they will be disposed. Attributes. Every entity will have a number of attributes that will make it different from the rest of the entities. These attributes can store any kind of information about the entity, and they can be numerical and alphanumerical. Variables. Variables in arena can store data about the system or the simulation. They can be used to store some information that will be reflected in the statistics at the end of the simulation. Resources. The entities mentioned above will use these resources during the simulation. In case the resources are limited, the entities will have to wait until they are able to use them. Queues. As said above, sometimes the entities will have to wait because a resource is being used by some other entity or it is just not available. In that case, the entities will have to wait in queues. Statistical Accumulators. These are built-in variables that will measure the performance of the simulation. For instance, the median waiting time in queues, number of products produced, etc. Simulation Clock. This clock will store the hypothetical time during the simulation. To build the model, besides from defining the attributes, variables, entities and resources, Arena provides us different modules to represent the behavior of the model in a flow chart way. We will see a further explanation of all the modules used to build our simulation in the next section, where the process of building the model will be described. 14
4.4
Development of Simulation Model for Elderly Care
In this section, now that we know the basics of the Discrete Event Simulation, and how Arena Simulation Software works, the process of building our model will be explained step by step. First, the basic definitions for the model to work will be explained. Those are the entities used, the resources available, the attributes defined for the entities, and the schedules used for the arrivals income. Then, all the modules used for the model building will be explained, both its function and the properties available for each module and do those properties change. Finally, the two parts of the model will be presented, and its function will be explained in relation to the real-world model. 4.4.1
Basic Features for the Simulation
Entities. The only entity type defined in our model is the Patient entity. This entity will represent the real world-model patient call, therefore, this entity will roam through the model seizing and releasing resources that represent the people that take care of them (nurses, call assistants) in the real-world model. Resources. As explained above, the resources are seized by the entities in the simulation, so in the real-world model, the resources are everything the patients take advantage of. So in our model, all the nurses groups are defined, and also the Call Center staff, and while all the Call Center staff are defined in the same group, we need to separate nurses available by their schedule (if they work during the day or the evening, or during the week or during the weekend) and by the zone they work. In Figure 4.2 we can see the resources of Dalbo, Anna Trolle, Teleborg, and Rottne during week days (WD), and week ends (WE) and the number of nurses who work in those groups in the Capacity column. Those are only a few of the resources defined, we can see all the resources available in Tables 2.1 and 2.2. Attributes The only attribute available in the simulation is the attribute nZone, which defines the zone where the patient belongs to. This attribute will be a natural number from 1 to 18, each number corresponding to one of the 18 different zones. We can see the relation of those numbers with the real-world model zones in Table 4.1. Schedules Schedules allow to define entities arrival using a graphical interface. In our case, we use the schedule to insert the statistics about the calls 15
Figure 4.2: Some of the resources defined in the model. Zone Zone Zone Zone Zone Zone Zone Zone Zone
1 2 3 4 5 6 7 8 9
Anna Trolle Dalbo Teleborg Rottne Centrum S¨oder Lammhult Lassaskog ¨ Ojaby
Zone Zone Zone Zone Zone Zone Zone Zone Zone
10 11 12 13 14 15 16 17 18
Sandsbro Hovslund Borgm¨astaren ¨ Oster ¨ ˚ryd Oster A Kinnevald Gemla Kvarng˚ arden Sj¨oliden
Table 4.1: Relation of model zone numbers and real zones. made in V¨axj¨o during November 2013, which can be seen in Table 4.2. Since the statistics are about the number of calls made during the entire month, we need the number of calls made during one hour, and there is no way of obtain closer statistics, the most realistic approach is divide the number of calls of each hour interval by the number of hours in that interval, and then scale the obtained number of calls from a month number to a day number, dividing it by the number of days of the month (November in our case) . The resulting numbers were introduced into the Arena Schedule. Calls Statistics Nr. of Calls Staying at the C.C. Submitted to V¨axj¨o
7:00 - 10:00 1193 739 (61,9%) 454
10:00 -14:00 1776 1050 (59,1%) 726
14:00 - 16:00 860 481 (55,9%) 379
16:00 - 21:00 1750 971 (55,5%) 779
21:00 - 7:00 2284 1003 (42,1%) 1381
Sum 7863 4244 (53,3%) 3719
Table 4.2: Call Statistics of V¨axj¨o kommun in november 2013.
16
4.4.2
Arena Simulation Software Modules
In this section, each module that has been used to build the model will be described. We will explain the function of that module, as well as the properties it has and what they change in the simulation. This is useful for a better understanding of how the model works, and how it is related to the real world, which will be explained later. The Create Module. As said before, one of the main parts of the model are the entities that interact with the modules, but those entities need to be created at some point. The Create module is the module that generate a stream of entities, depending on the values defined on the module’s properties. In this module properties, we can specify the type of the entities that will be generated, we can set the number of entities that will be created each time, a limit of entities that will be in the simulation simultaneously, and the time between each of the entities is generated. This can be seen in Figure 4.3
Figure 4.3: The Create module and its properties. The time between of each entity generation, also called arrival, can be set in four different ways: - Random. We can use an exponential distribution for the probabilities of the time between arrivals. In this case only the time between each arrival is needed, and the exponential distribution will be generated based on that, generating random values around the specified time. - Schedule. A schedule can be used too to define time between arrivals. With the schedule, the number of arrivals per hour can be specified each day of the simulation. 17
- Constant. A constant arrival stream can be used too. In this case only the exact time between the arrivals will be specified, and it will be a constant value during all simulation. - Expression. Finally, a mathematical expression can be used to specify the time in case we want it to be based on any of the Arena’s variables or attributes. We can use the Arena’s Expression builder to generate those expressions. The Decide Module. The Decide Module is used every time a decision has to be made in the model. The conditions for the decision can be set in two different ways in the module properties, as we can see in Figure 4.4:
Figure 4.4: The Decide module and its properties. - Decision by chance. In this case, the decision will be decided using a probability system defined by percentage values. - Decision by condition. Otherwise, we can use a condition to make the decision. That condition can be based on variables or attributes, the type of the entity going through the decision module, or an expression, that can combine all the things (variables, attributes and type of entity) in one. The Assign Module. This Module is used to modify any entity or model property, such as simulation variables, entity types, entity attributes, the entity picture, etc. As we can see Figure 4.5, we can create a list of all the things that will be modified in the module properties, and we can specify what will be changed. For instance, in Figure 4.5, the attribute nZone will be set to 1 for each entity going through the module, and we can add a variable, attribute, entity type and entity picture modification to the module. 18
Figure 4.5: The Assign module and its properties. The Process Module. The Process Module is used to process the entities in a simulation. In this module, we will be able to sieze and release the resources available on the entities, as well as delay or queue them. As we can see in Figure 4.6, the actions that can be applied to the entities are: - Delay. In this case only the delay will be applied to the entity. - Seize Delay. This option will seize resources on the entity, but will not release them, so we won’t be able to use them again until they are released. The specified delay will be applied too. - Seize Delay Release. Some of the resources will be seized in this case, and they will be released after the delay specified. - Delay Release. In this case seized resources will be released after the delay. In the Process Module, the delay for the process being modeled can be specified with a Normal, Triangular or Uniform statistical distribution, with a constant value, or with an Arena Expression. The Record Module. The Record Module is used to record statistics that will be shown at the end of the simulation. Using the record module we can record statistics such as a recount of the number of entities, statistics about 19
Figure 4.6: The Process module and its properties. the entities, time lapses or even specify what needs to be recorded using an Arena Expression. The module and its properties can be seen in Figure 4.7.
Figure 4.7: The Record module and its properties.
The Route and Station Modules. The Route and Station Modules are used to send entities from a point of the simulation to some other, modeling the time spent by an entity moving from a place to another in the real world model. So the Route Module will be used to send the entities, and the Station Module to receive them. Again, we can specify the delay of the route module with a Normal, Triangular or Uniform statistical distribution, with a constant value, or with 20
Figure 4.8: The Route module and its properties. an Arena Expression, and we can choose if the entity is going to be sent to a specific Station by name, by attribute or by Arena expression, or just to the next Station by sequence. We can see the module and its properties in Figure 4.8. Regarding the Station Module, we can set its name in the properties window in case we need it to set the destination Station in the Route Module properties, or just leave it as default in case we selected the sequence mode. The Submodel Module. The Submodel Module is basically a part of the model abstracted inside a module. It is useful to make the model less visually complex in case, for instance, that we are working with a lot of different types of entities and we need to make an assignation for each type. It would not be a complex task, but it could be very complex to understand it by looking at it. As we can see in Figure 4.9, we can change the number of inputs and outputs of the module in its properties, as well as add a description of the submodel, and obviously change its name. The Dispose Module. As much as we need a Create Module to generate a stream of entities for the simulation, we need some way of dispose them once their function is done in the simulation. That is the Dispose Module function. As we can see in the properties box in Figure 4.10, the only property we can change for this module is the name, and if we want it to register statistics or not, as we can see in the module properties box in Figure 4.10.
21
Figure 4.9: The Submodel module and its properties.
Figure 4.10: The Dispose module and its properties.
22
4.4.3
The Model Explanation
In this section, the two main parts of the model will be explained. When it comes to taking care of the patients that pushed the button, the process is divided in two parts. In the first part, the patient will contact to the care assistants at the call center, and then, in the second part, the assistants will take care of the situation. The Call Center part In this part of the model, everything related to the Call Center is modeled. For a better understanding of the model, the real situation is going to be explained before explaining each module of the model.
Figure 4.11: The logic of the Call Center part of the model. Basically first thing happening when someone push the alarm button is that they get contact with an assistant from the Call Center. Since they have to handle calls from all over Sweden, there are 57 assistants working there, so it is unlikely to have waiting time when trying to reach an assistant. What could happen, though, is that there were some connection problems, but they would last a minute as maximum. After the patient has reached the Call Center, the assistant will decide if the call needs to be sent to V¨axj¨o or not. That is because sometimes test or mistake calls are made, and they need to be disposed. Finally, if the user needs to be taken care by one of the V¨axj¨o’s nurses, the Call Center Assistant will call one of the nurses available working in the zone where the patient is located.
23
Figure 4.12: The Schedule used for entities (calls) generation. So to begin with, since the calls made by the users are represented by the entities of the model, we will need to generate those calls with a Create Module. The amount of calls generated each hour will be defined by the statistics in Table 4.2. Using an Arena Schedule we can introduce them to the model, as we can see in Figure 4.12. Once the entities are generated, we will use a record module called Patients Recount to record the total of calls made in order to include them into the final statistics, having in mind that the rejected calls are included in these statistics too. After that, we will assign a zone to all generated entities. That will be done in the Assign Zone Submodel. As we can see in the Figure 4.13, first module used in this submodel is a Decide Module, which based on percentages (based the population and extension of the zone), will send each entity to one of the outputs available. In each output, an Assign Module will assign a number from 1 to 18 to 24
Figure 4.13: Submodel for Zone assignment of the entities. the nZone attribute of the entity, each number corresponding to a different zone. The relation of numbers and zones is available in Table 4.1. After assigning the zone number to the entity, a Record Module will save the statistics about how many calls from that zone are generated in total. Again, those statistics still include the calls that will be rejected later. After assigning the zone, the call will be assisted by one of the Call Center Assistants. To represent that in the model, we will use a Process Module that will use a resource (the call center assistant in this case), and that will produce a delay of time corresponding to the time spent in the real-world model call. The number of available resources is 57, which are the different ¨ people working at the Orebro Call Center. Then a Decide Module will decide, as we can see in Figure 4.13, the calls that will be rejected and the ones that will be not. The decision will be made according to a probability percentage based on the call statistics, being the percentage of the call not being rejected 53.3 %. If the entity turns out to be one of the rejected calls, it will be sent directly to a Dispose Module, and that entity function will be done in the simulation. Otherwise, the entity will go through a Process Module, that represents the time spent by the Call Center Assistant reaching one of the nurses available in the patient’s area. Finally, the entity will be sent to the other part of the simulation by a Route Module, and a little delay will be run, according to the time spent by the nurse going to the patient’s house. That could take 4 minutes if she is in the same building, up to 10 minutes if the nurse has to move to a far place in the same zone. 25
The Assistance part In this part of the model, the rest of the process of the patient caring will be modeled. What basically happens in this part is that the nurse will go to the patient’s place and take care of him, spending the required time which will be between 10 and 60 minutes, being 20 minutes the most common. The process, though, is more complex when it has to be modeled, since different resources will be used depending on the time of the simulation. To do that, Decide models will be used. We can see the whole Assistance part of the model in Figure 4.14.
Figure 4.14: The assisntance part of the model. First Decide Module we see will check if the entity arrives during week days or weekends. As we can see in Figure 4.15, we do that using the Arena Variable TNOW, that stores the time during all simulation. Since the time is stored in hours, only thing we have to do is use the Module function with the variable TNOW and the total hours of the week, which are 168. If the result number is greater than 120, it will be weekend in the time of the simulation, and otherwise, it won’t be weekend. The expression can be seen too in Figure 4.15. Either it is weekend or not, another Decide Module will be used to check if the call has been made during the day or during the evening/night. In that case, a similar Arena Expression will be used, but now we will use the TNOW variable and the number 24 (total hours of the day) as input for the Module function. If the result is greater than 21 and less than 7, then the 26
call arrived during the evening, otherwise, it will be during the day.
Figure 4.15: Expression to decide if it is weekend or not in the model. For each case, there is a corresponding submodel that will use the resources dedicated for that time of the day and week, depending on the zone from where the call was made. In case the call is made during the evening, when only 4 night patrols are working, each zone will be assigned to one of them. In Figure 4.16 we can see one of the cases, which are very similar to each other. As we can see, there is a Decide Module that will decide the corresponding output for the entity based on the number of its nZone attribute. Then the entity will go through the Process Module of that zone, seizing the resources available. Finally, a Record Module will record the number of patients attended by the that concrete care group. So the main difference between the During Day and Evenings submodels, is the number of outputs of the Decides Modules at the beginning of each. In case of During Day Submodels will have 18 outputs, since there is 18 care groups working during the day. In the Evening Submodel, though, we know that only 4 night patrols are working, so the Decide Module will only have 4 outputs. The distribution of the zones to the night patrols can be seen in Table 4.3. The expression used in the Decide Module of the Evenings Submodels will basically send the entity through the input depending on the nZone attribute value, following the distribution of zones for each Night Patrol. For instance, the patients from zones 4, 7, and 18 are to Night Patrol 27
Figure 4.16: Submodel corresponding to days on not weekends. 1, so the expression for the first output of the Decide Module will be: (nZone == 4)||(nZone == 7)||(nZone == 18) So we are basically telling Arena, ’if the nZone value is 4 OR 7 OR 18, then send the entity through the input 1’. Night Night Night Night Night
Patrols Patrol 1 Patrol 2 Patrol 3 Patrol 4
Zones Assigned Sj¨oliden, Rottne and Lammhult ¨ ¨ ˚ Sandsbro, Hovslund, Oster, Oster Aryd and Anna Trolle Dalbo, S¨oder, Kvarng˚ arden and Teleborg ¨ Centrum, Lassaskog, Borgm¨astaren, Ojaby, Gemla and Kinnevald
Table 4.3: Zones assigned to each Night Patrol.
28
4.5
Verification and Validation of the Model
In this section how we verified and validated the model will be explained. Following Banks [1] flowchart, the verification and validation is useful to know if the model is an accurate replica of the real-world model, and must be done before any experimentation with it. To verify and validate the model, firstly the whole phone care system was examined. We had different meetings with a former assistance nurse for the phone care users and current system administrator to collect as much information as possible about how the system works (number of calls, number of nurses, number of staff assisting the calls, etc.). We kept contact with him while the model was being built to keep it as accurate as possible, and finally a flowchart of the model was reviewed and confirmed by him. The model logic can be checked by the software itself whereas building the model, and it is always checked before any simulation takes place, so it is impossible for the model to have errors before running any simulation. Finally, after running some test simulations and check that the results made sense, the same validation system used in [5, 15, 2] was used to completely validate the model. That is, running 100 replicas of a whole month simulation, and building a confidence interval with a confidence level of 95% with all the data collected from that simulation. That way, we obtained six different confidence intervals, one of those intervals is from the total number of patients helped that month, and the rest of them corresponding to each time interval shown in Table 4.2. After that, we checked that the real values are inside those intervals successfully. So as we can see in Table 4.4, where the real values from November 2013 (that we used to build the simulation), and the upper and lower boundaries of the confidence interval are shown, the value from each time interval of the real data is between the confidence interval built from the simulation results. 7:00 to 10:00 10:00 to 14:00 14:00 to 16:00 16:00 to 21:00 21:00 to 7:00 Total
November 2013 1193 1776 860 1750 2284 7863
Upper Bound 1200 1780 862 1769 2287 7881
Lower Bound 1187 1764 851 1750 2269 7841
Table 4.4: Real Data compared to the confidence intervals obtained. Further results of the validation process and also the confidence interval 29
data can be seen in Appendix A. 4.6
Experimentation
This section exhibits the experiments we did with the model, observing the behaviour of the entities, queues and resources. To study the entities we can study the number of entities generated (which we already did to validate the simulation), and we can study the waiting time for the entities, which is a subject of importance on an emergency system as it is our model. To study the waiting time, the same strategy followed by [14] was used. So what we did was to push the model to the limits, increasing 5% the number of arrivals at a time until the waiting time for the entities was not suitable for an emergency care system, bearing in mind that we always observed the worst case scenario (maximum waiting time), since the patient life may be in danger in some cases, so it would be irresponsible to work with the average waiting time. The maximum waiting time for the patient was considered to be 25 minutes as top. That time, in the model, includes the time that the patient spends talking to the call center assistant, the time spent by the call center assistant to reach the V¨axj¨o nurse, the time spent waiting for an available resource (the nurse, in this case), and the time spent by the nurse on its way to where the patient is located. From all the times considered, Arena will distinguish two different types of time: the transfer time, and the waiting time. The transfer time is the time spent for the entity going from one module to another. In this our case, the biggest transfer time is the ’Route 6’ module (the time spent by the nurse going to the patient’s place). That time is set with a triangular distribution, which will be from 4 to 10 minutes, being 7 the most common value. That is the reason why, as we will see now, the transfer time is always very close to 10 minutes in the worst case scenario, in every experiment simulated. The waiting time, on the other hand, is the time spent by the entities waiting in a process module delay. We have two kinds of process modules in our simulation, the ones that have a maximum waiting time, as in the case of the ’Call CC’ and ’Call CG’, which is the time spent for the patient calling to the Call Center, and the time spent by the Call assistant connecting with the nurse. In both cases the time spent will be a triangular distribution from 1 to 3 minutes, being 2 the most common value. Then we have the modules that do not have any maximum waiting time, those are the modules that are actually using any of the resources available. 30
Therefore, the entities that need to seize those resources will have to wait in a queue for an unlimited time until one of the entities using the resources stops. This will be the critical time for the experimentation, since it will be the variable time during the arrival increase. 4.7
Model Animation
For a better understanding of the model, Arena allows us to build an animation based on the model, in order for us to be able to observe what is happening at any moment during the simulation of the model. The animation is divided into the call center part, and the assistance part as we can see in Figures 4.17 and 4.18 respectively. Each time there is an arrival in the simulation, we will observe that a phone icon is generated from the corresponding zone in direction to the call center. Once it reaches the call center, the call can be sent to V¨axj¨o or not. In case it is sent to V¨axj¨o, the phone icon will keep moving down and then to the right until the V¨axj¨o Kommun label. When the call icon reaches that label, it would mean that a nurse in V¨axj¨o has been informed that a patient needs assistance, so the phone icon will switch to a person icon, and it will move to the corresponding area and time. For instance, if the call is made at 13:00 during the weekend from zone 5, the icon will move to the bottom part of the animation, which is the ’Weekend’ zone, to the zone labeled ’Care Groups’ (since it has been made during the day), and to the label ’zone 5’. During the simulation, we can also check at any moment the total number of calls made so far. 4.8
Social and Ethical Considerations
In healthcare projects, ethical and social considerations are important to consider. For instance, a system of webcam control has been in development to watch elderly people anytime wanted in order to see if he is in trouble. That can be considered as a violation of the person’s privacy, but would increase the quality of life for those people. In those cases we have to balance the advantages and disadvantages. All the collected data is totally anonymous, so nobody’s privacy has been infringed. In case this project would go further and needed to collect more specific data about the time required by nurses to help a patient, then new ethical and social considerations should be reviewed.
31
Figure 4.17: The Call Center part of the animation.
32
Figure 4.18: The assistance part of the animation.
33
5
Results and Analysis
In this section, the results obtained from the simulations done in the last section will be described from three different points of view: the entities, the queues and the resources. 5.1
Entities Results and Analysis
In order to push the system to the limits, what we did was to increase the arrival rate with 5% and run a 50 replica simulation each time we increased them, obtaining the results displayed in the Table 5.1.
Transfer Time Waiting Time Total Time
Real Arrivals 9.6 5.4 15
+5% Arrivals 9.6 7.2 16.8
+10% Arrivals 9.6 9.6 19.2
+15% Arrivals 9.6 18 27.6
Table 5.1: Experimental results obtained.
As we can see in both Table 5.1 and Figure 5.1, the waiting time with the real arrivals is a total of 15 minutes, and if we subtract the time spent by the patient calling, which is inevitable for him, it would not be more than 12 minutes, which is pretty acceptable time for an emergency system assuming that this is the worst case scenario. What we can also see in the results shown in Table 5.1, though, is that even the time still being under the limit in the first and second increase, it gets out of the limit on the third iteration, and increasing with a high slope. So what we can deduce is that once the arrivals do not meet the resources available, the waiting time will increase very fast to a very unacceptable level for an emergency system, and that could be very dangerous. Further results can be seen in Appendix B, where the full Arena Results form can be reviewed. 5.2
Resources Results and Analysis
In this section the resources results will be studied. To do that, we observed the level of utilization of each resource to see which resource would be the most susceptible to collapse in case the arrivals increase.
34
Figure 5.1: Result of the simulation increasing the arrivals. The first thing we observed on the entities usage percentage is that, while it is rare to see a higher than 80% value in the resources used during the week days and the week ends, the usage percentage on the night patrols, as we can see in table 5.2 are very high. East West North South
Night Night Night Night
Patrol Patrol Patrol Patrol
Usage Percentage 100% 100% 83% 100%
Table 5.2: Resources usage on night patrols. The reason of that is that, even though during the night the number of arrivals decrease to almost half of the arrivals during the day, each night patrol has to take care of the arrivals of 3, 4, 5 or even 6 different zones with a very reduced number of personnel compared to the personnel each zone have during the day. Regarding the rest of the zones, none of the bigger ones have higher than 80% utilization, with an utilization of 71% on Dalbo and S¨oder during the weekends as top values, which means it would be difficult to collapse them 35
even with new arrivals. As we move to the smaller zones where the number of arrivals is lower, but the personnel is a very little group of people compared ¨ ˚ to the bigger zones, the utilization even reaches 100% levels as in Oster Aryd on weekends, or Sj¨oliden with 75% on weekends. Another important observation is that the utilization is higher during the weekends than during the week days. So having in mind everything explained before, the number of resources are appropiate for the number of arrivals obtained in November 2013, since there are no bottlenecks or queues on the resources. What can be mentioned, though, is that a redistribution of the staff, moving some of the personnel from the week days care groups to other of the more needed groups we mentioned above, like night patrols or some of the minor zones where the utilization is higher, would be a good way of preventing long queues in case the arrivals increased. On the other hand, as the utilization is not generally high, and only one nurse at a time is needed to take care of a patient, increasing the number of nurses with the current arrivals would not increase the quality of the service. So assuming that the resources are appropriate for the number of arrivals registered in November 2013 (the most recent statistics we obtained), if we take a look to all the statistics we obtained from different months of 2013 in Figure 5.2, we can see that during 2013 the rate of arrivals was pretty similar in all months, being even higher in older months, which means that the number of arrivals is not growing very fast. All the utilization results and real arrival statistics from January, February, March and November 2013 can be seen in Appendix B and C. 5.3
Queues Results and Analysis
Regarding the queues, since our model is an emergency system model, it is very important not to have any kind of queues. Being assistance times a triangular distribution from 10 to 60 minutes, with 30 minutes as the most common value, a single patient in the queue could mean several minutes waiting in the worst case scenario in a situation where time is crucial. Due to that reason, most of queue waiting time results are 0, except from East night patrol during weekend and week days, and West night patrol during the week days, which had a 1 patient long queue during the simulation in each case and, if we check the waiting time for that patient, we will see that it was 3,6 minutes in the case of the west night patrol, and 4,8 and 5,4 in the case of the East night patrol during week days and weekend respectively. Bearing in mind that that time is spent on waiting for the resource only, and that we have to add the calling time, and the time spent by the nurse 36
Figure 5.2: Rate of arrivals from different months of 2013. going to the patients place, we realize that 5 minutes can be critical in some situations. Full Arena results form can be seen in Appendix E.
37
6
Conclusions
In this project, we contacted a current member of the elderly care system being used in the community of V¨axj¨o, and collected all the possible data related to the system. The system was described in Section 2 and a model was developed using Arena Simulation Software. After that, we validated and verified the model by running a series of simulations, collecting the resulting data and building a confidence interval to verify it with the real data collected, to observe that the model was an accurate replica of the real system. A series of experiments were run also to observe the behavior of different elements of the system: 1. We ran an 50 replica simulation to observe the behavior of the system as the arrivals increase, to observe how that increase affected the assistance time, concluding that a 15% increase in the arrivals rate would end as an unacceptable waiting and transfer time to the patients risking their lives. Due to that, it would be very important and useful to the V¨axj¨o elderly care system to know what resources would be needed and enough in case an arrival rate increase happen. 2. Another 50 replica simulation was ran to observe the resources utilization in order to prove that there are no bottleneck in the system, and the resources are enough to handle the current (November 2013) arrival rate. Plus, we studied the arrival rate during different 2013 months observing that it has not suffered from relevant changes. 3. Finally, another 50 replica simulation was ran to observe the queue behavior. Since it is an emergency system, no queues are expected to use the resources. In the results, though, we observed that in the worst case scenario, some resources do generate a short queue (which is only 1 patient long for all the cases), and even being as short as it is, it generates waiting times of even 5 minutes in one case. Those 5 minutes could be critical, and make us have an idea of how much the waiting time could increase in case that the resources would not meet the arrival rate. After obtaining the results, we observed that the system is efficient now, with a low number of exceptions in the night patrols and minor care groups where the utilization is very close to 100% in the worst case scenario, and yet it is less than 50% in some of the day care groups. So according to the results, some staff redistribution could make the system more optimal. 38
The simulation can be used to redistribute the personnel in order to reduce the higher utilization for some of the care groups and night patrols mentioned in the previous paragraph, and anticipate an optimal resources distribution in case the arrivals increase. An optimal use of the resources and the system provided by this simulation would reduce health care expenses, solve the lack of specialized nurses, and also solve a future lack of room in special housing for elderly people. 6.1
Advantages and Disadvantages
The model was successfully validated and it is an accurate replica of the real world model. We were able to study the system with the simulations, being able to make some observations about the resources usage, and how to make the system more optimal. As we observed with the entities arrival experiment, the system resources could not handle a large increase on the number of calls, but good thing about the model is that it can be used to predict and prevent events that could negatively affect the system and give an accurate idea of how to redistribute the personnel in an accurate and optimal way, preventing high or low utilization on some of the resources. However, even though the data collected from the real-world system is enough to have a general idea of the system and resources usage, if more data was collected for an internal person, as it could be a very nurse, we could have very precise data about the transportation times and times spent taking care of the patient, increasing the accuracy of the simulation. That disadvantage, as read in [12], is a very common problem on healthcare simulation. Healthcare organizations do not usually have the resources to make a simulation, so most of the simulations are done in a research or consulting framework usually by universities and colleges, even though it is expected to be normalized in the future. 6.2
Future Work
As said in the previous section, future work could include increasing the amount of real data about different aspects of the model, as it is the time spent on reaching the patient’s home and the time spent taking care of him. The model could be extended to other areas too. For instance, in critical cases where the patient needs further assistance than a nurse can provide, an ambulance will be called and the patient might be hospitalized. The model could be extended with the corresponding part, with a number of ambulances and hospital rooms as resources. 39
References [1] Jerry Banks. Discrete Event Simulation. 1999. [2] Christine Duguay and Fatah Chetouane. Modeling and improving emergency department systems using discrete event simulation. 2007. [3] European Commission Eurostat. Fertility statistics. http: //epp.eurostat.ec.europa.eu/statistics_explained/index. php/Fertility_statistics, October 2012. [4] European Commission Eurostat. Mortality and life expectancy statistics. http://epp.eurostat.ec.europa.eu/statistics_explained/ index.php/mortality_and_life_expectancy_statistics, October 2012. [5] Michael Findlay and Hank Grant. An application of des to an outpatient healthcare clinic with batch arrivals. 2011. [6] B.L. Nelson J. Banks, J.S. Carson and D.M. Nicol. Discrete Event Simulation, 4th Ed. Upper Saddle River, N.J. : Prentice-Hall, 2005, 2005. [7] A.M. Law and W.D. Kelton. Simulation Modeling and Analysis, 3rd Ed. McGraw-Hill, 2000. [8] Julie C. Lowery. Introduction to simulation in health care. 1996. [9] Julie C. Lowery. Getting started in simulation in healthcare. 1998. [10] United Nations. World population ageing 2013. 2013. [11] Swedish Association of Local Authorities and Regions. Care of the Elderly in Sweden Today. Jan 2007. [12] Stephen D. Roberts. Tutorial on the simulation of healthcare systems. 2011. [13] John D. Salt. Keynote address: Simulation should be easy and fun! 1993. [14] Michael E. Kuhl Sarah M. Ballard. The use of simulation to determine maximum capacity in the surgical suite operating room. 2006.
40
[15] Pedro Marinho Sizenando Silva and Luiz Ricardo Pinto. Emergency medical systems analysis by simulation and optimization. 2010. [16] Randall P. Sadowski W. David Kelton and Nancy B. Zupick. Simulation with Arena. McGraw-Hill Higher Education, 2009. [17] Shao-Jen Weng, Bo-Shiang Tsai, Lee-Min Wang, Chun-Yueh Chang, and Donald Gotcher. Using simulation and data envelopment analysis in optimal healthcare efficiency allocations. 2011.
41
Appendices Appendix A: Validation Results Results of a 100 replica simulation used to build the 95% confidence interval for the validation of the model.
1
2
3
4
Appendix B: Arrival Experiment Results of a 50 replica simulation analyzed from the arrivals point of view. The first set of results is for the real-world number of arrivals.
5
Results obtained from the arrivals point of view with the real-world number of arrivals increased a 5%.
6
Results obtained from the arrivals point of view with the real-world number of arrivals increased a 10%.
7
Results obtained from the arrivals point of view with the real-world number of arrivals increased a 15%.
8
Appendix C: Resources Experiment Results of a 50 replica simulation analyzed from the resources point of view.
9
10
Appendix D: Arrival Real Data Data collected of the real-world number of arrivals during some of the months of 2013.
11
12
13
Appendix E: Queues Experiment Results of a 50 replica simulation analyzed from the queues point of view.
14
15
Faculty of Technology SE391 82 Kalmar | SE351 95 Växjö Phone +46 (0)77228 80 00
[email protected] Lnu.se/facultyoftechnology?l=en
