Page 1
Laurens Van Poucke, Pieter Demyttenaere
procesoptimalisatiemet behulp van ontologiegebaseerde operationeleTechno-economische evaluatie van eHealth-diensten
Academiejaar 2013-2014Faculteit Ingenieurswetenschappen en ArchitectuurVoorzitter: prof. dr. ir. Daniël De ZutterVakgroep Informatietechnologie
Master of Science in Industrial Engineering and Operations ResearchMasterproef ingediend tot het behalen van de academische graad van
Frederic VannieuwenborgBegeleiders: Jan Van Ooteghem, dr. Stijn Verstichel, dr. Femke Ongenae, ir.
Promotoren: prof. dr. ir. Mario Pickavet, dr. ir. Sofie Verbrugge
Page 3
Laurens Van Poucke, Pieter Demyttenaere
procesoptimalisatiemet behulp van ontologiegebaseerde operationeleTechno-economische evaluatie van eHealth-diensten
Academiejaar 2013-2014Faculteit Ingenieurswetenschappen en ArchitectuurVoorzitter: prof. dr. ir. Daniël De ZutterVakgroep Informatietechnologie
Master of Science in Industrial Engineering and Operations ResearchMasterproef ingediend tot het behalen van de academische graad van
Frederic VannieuwenborgBegeleiders: Jan Van Ooteghem, dr. Stijn Verstichel, dr. Femke Ongenae, ir.
Promotoren: prof. dr. ir. Mario Pickavet, dr. ir. Sofie Verbrugge
Page 5
De auteurs geven de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.
Pieter Demyttenaere & Laurens Van Poucke, Gent, juni 2014
Page 7
Dankwoord
Na vier jaar van succesvolle samenwerking tijdens het instuderen van de meest uitdagende vakken in
de opleiding van burgerlijk ingenieur, was het samen schrijven van een thesis in het vijfde jaar voor
ons een mooie afsluiter. Een belangrijke vereiste bij de keuze van onze thesis was een directe link
met de realiteit. We wilden meewerken aan een project dat op een bepaald vlak het verschil maakte
of wou maken en daarbij de toepasbaarheid in de praktijk zeker niet uit het oog verloor. Neem
daarbij onze almaar groeiende interesse in de gezondheidszorg en al snel bleek dat deze thesis onze
voorkeur zou wegdragen. Al tijdens het inleidende gesprek met Jan in april vorig jaar waren we
gefascineerd door de sterke realisaties van het Accio project en de vele mogelijkheden tot verder
onderzoek. Nu achteraf gezien blijkt het nog steeds de beste keuze die we konden maken.
Vooreerst hartelijk dank aan onze promotoren, Prof. dr. ir. Mario Pickavet en dr. ir. Sofie Verbrugge,
om ons de kans te geven aan deze uiterst boeiende thesis te kunnen werken. Zonder jullie zou dit
uiteraard niet mogelijk geweest zijn.
Graag willen we hierbij zeker ook onze vier begeleiders oprecht bedanken. Met hun expertise in
beide vakgebieden waren ze een enorme hulp voor ons. Elke meeting stonden ze ons met raad en
daad bij en lieten ze ons door het stellen van kritische vragen nadenken over onze methodes en
resultaten. Bedankt Jan Van Ooteghem, dr. ir. Femke Ongenae, dr. ir. Stijn Verstichel en ir. Frederic
Vannieuwenborg.
Door onze eerder beperkte voorkennis op het gebied van simulatiesoftware, was het niet altijd even
gemakkelijk om snel genoeg de nodige vorderingen te maken in de opbouw van de simulatie.
Daarom willen we zeker Kurt De Cock van onze vakgroep Industrieel Beheer niet vergeten, die al
onze vragen betreffende de FlexSim software zo snel mogelijk probeerde te beantwoorden en
daarbij een enorme hulp was tijdens het ontwerp van het model. Bedankt Kurt!
Tenslotte willen we ook onze vrienden, vriendinnen en dichte familie bedanken, die ons het hele jaar
door gesteund hebben bij het werken aan deze uiterst boeiende thesis.
Page 9
vii
Overzicht
Techno-economische evaluatie van eHealth-diensten met behulp van ontologiegebaseerde operationele procesoptimalisatie
Pieter Demyttenaere & Laurens Van Poucke
Promotoren: prof. dr. ir. Mario Pickavet, dr. ir. Sofie Verbrugge
Begeleiders: Jan Van Ooteghem, dr. ir. Femke Ongenae, dr. ir. Stijn Verstichel, ir. Frederic Vannieuwenborg
Masterproef ingediend tot het behalen van de academische graad van
MASTER OF SCIENCE IN INDUSTRIAL ENGINEERING AND OPERATIONS RESEARCH
Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter
Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2013-2014
Samenvatting: Het verpleegoproepsysteem dat voortvloeide uit het Accio project wijst, met behulp van nieuwe technologieën, de meest optimale zorgverleners toe aan oproepen van patiënten. Hiermee willen de ontwikkelaars niet alleen een betere ervaring voor de patiënt realiseren, maar ook een betere werklastverdeling voor de zorgverleners creëren. Daarenboven is het de bedoeling dit alles zo kostenefficiënt mogelijk uit te voeren. Vooraleer men dit nieuwe systeem operationeel kan maken, moet men aan de hand van een techno-economische analyse kunnen aantonen dat er effectief betere resultaten kunnen bereikt worden.
In deze thesis zal er, aan de hand van een Discrete Event Simulator (DES), nagegaan worden wat de invloeden zijn van het nieuwe oproepsysteem ten opzichte van het huidige systeem. Daarnaast zal er geprobeerd worden om een tool te ontwerpen die automatisch de regels die gedefinieerd zijn in het oproepsysteem omzet naar de regels die gebruikt worden in de simulator. De software van het verpleegoproepsysteem is gebaseerd op ontologieën. Een ontologie wordt gebruikt om kennis of data over een bepaald interessedomein te verzamelen en om dat domein op een formele manier te beschrijven op basis van een overeengekomen terminologie door gebruik te maken van concepten, relaties en eigenschappen.
Vertrekkende van reële oproependata afkomstig van twee verschillende bestaande departementen zal input gegenereerde worden voor het model in de DES. Verschillende scenario’s zullen worden besproken. Gaande van voorstellen tot verbetering van het Accio verpleegoproepsysteem tot effectenanalyse in verschillende situaties. Vervolgens worden de resultaten gebruikt om de inzetbaarheid in kaart te brengen samen met de voor- en nadelen van het systeem om uiteindelijk te eindigen met enkele aanbevelingen betreffende het invoeren van het oproepsysteem in ziekenhuizen.
Keywords: Nurse Call System; Ontologies; Key Performance Indicators (KPIs); Simulation; Healthcare
Page 11
ix
Techno-economic evaluation of e-Health services by means of ontology-based operational process optimisation
Pieter Demyttenaere & Laurens Van Poucke Supervisors: prof. dr.ir. Mario Pickavet, dr.ir. Sofie Verbrugge, dr. ir. Femke Ongenae,
Jan Van Ooteghem, ir. Frederic Vannieuwenborg, dr. ir. Stijn Verstichel
Abstract – Current Nurse Call Systems hinder the efficiency of nurses as the systems are not aware of their surroundings. The Accio project developed a new system that solves these problems. For example, the status of a nurse, or the trust relationship with the patients are considered while allocating a call to caregivers. Focus is not only on creating a higher quality patient care, but also on dividing the workload more evenly over all caregivers, keeping a cost-efficient care environment in mind. However, potential users have to be persuaded by demonstrating that the new system truly achieves better results. This master thesis will examine the effects of the system on a cure setting by using a Discrete Event Simulator (DES). Furthermore, an automatic translation tool was designed to convert the rules from the Nurse Call Software to those used in the simulation. The software of the Nurse Call System is based on ontologies. Ontologies are used to collect data from a certain domain and describe that domain by making use of a uniform terminology of concepts, relations and characteristics. Real life call logs and reality-based hospital departments will form the founding of the analysis. Different effects and improvements on the ontology rule set were tested and discussed. Those results were used to map the operability and the (dis)advantages of the new system with respect to the current one. In conclusion, some recommendations were made regarding the improvement of the Nurse Call System in hospitals.
Keywords: Nurse Call System; Ontologies; Key Performance Indicators (KPIs); Simulation; Healthcare
I. INTRODUCTION Healthcare has, especially in Belgium and
Flanders, become very expensive. Many hospitals do not succeed in making profit, in fact about one fifth of the Flemish hospitals make a loss. [1] A great part of those losses are due to the nursing departments. [1] The workload and required competences of nurses continue to rise. The Nurse Call System of the Accio Project tries to lower the workload by
dividing it more evenly over all nurses. [2] It takes into account the competences of the nurses, their trust relationship with the patients and their status at the moment of the call.
II. RESEARCH QUESTIONS One of the objectives of this master thesis is
to evaluate the effects of the new nurse call system on caregivers and, most importantly, on the patients. This was tested in a Discrete Event Simulator. Besides that, a translation tool was developed so that executives can easily interchange allocation rules in between the Nurse Call System and the simulator.
III. TRANSLATION TOOL Executives, such as the head nurse or the
head of a department, should be able to make any adjustments to the rule-set of the nurse call system so that they are able to refine the new system to their particular department. However, before introducing the new rules or definitions into the department, they need to implement them in the simulator in order to justify the adjustments to themselves and their employees. Rules should be interchanged instantly in between the ontology and the simulation software.
Currently, the rules in the nurse call system are programmed in the Web Ontology Language (OWL). [3] The rules itself though are written in Jena rules. [3] As Jena is not frequently used anymore in new applications, such as OWL 2, [4] it is agreed to make a translation starting from the Rule Interchangeable Format (RIF), a recently developed rule standard that creates a link between all different rule dialects, [4] to the language of the discrete event simulator (FlexSim). The translation tool has been set up in Python and analyses the code as a list of strings. It recognizes labels and modifies them to the new programming language. It is not a generic tool as this was out of the scope of this master thesis.
Page 12
x
IV. METHODOLOGY A. Ontology
A definition of ontologies is given by Gruber T. [5]: “An ontology is a specification of a conceptualization in the context of knowledge description”. This means that ontologies describe concepts, relations between those concepts and characteristics in a certain domain of interest. [6] An example of a relationship in the Accio Nurse Call System is the degree of trust between patient and caregiver. On top of the ontology is the rule-set that ensures that functions or actions that influence the ontology can be made. The ‘reasoner’ uses these rules to define all the elements, for example defining the status of a caregiver in the domain, and makes decisions concerning the allocation of calls to the caregivers. Those rules work as a decision tree that is evaluated top-down. The complete tree can be found in the PhD of dr. Femke Ongenae. [3]
B. Effects and adjustments For the simulations it was examined which
software would be best for testing the nurse call system and eventually FlexSim was chosen. FlexSim is originally intended for simulating industrial settings [7] so it had to be modified to the needs of a healthcare simulation.
Eight different scenarios were investigated. Firstly, a setting with the traditional nurse call system, ‘Traditional’, and one with the Accio Nurse Call System, ‘Accio’, were analysed. Subsequently three scenarios are used to test the effects of a certain situation on the operability of the system. And at last, three adjustments to the rule-set were introduced to try to improve the performance of the Nurse Call System. The scenarios are illustrated in Figure 1.
Figure 1: Overview of the different scenarios
‘Effect 1’ is a care setting in which all nurses have medical competences. This scenario has exactly the same employees as ‘Traditional’. This scenario is used mainly to test the differences in work load distribution among nurses for the Accio- and the traditional system. In ‘Effect 2’ a caregiver will not perform an intervention if he does not have the required qualifications. This scenario is examined because these situations happen in real life, although they are not allowed. Lastly, the trust relationship between nurses and patients are not taken into account in ‘Effect 3’ as there were doubts during the developments to incorporate these trust relationships into the rule-set.
The first change to the rule-set is made in ‘Adjustment 1’. The definition of the status ‘Busy’ is altered from being ‘Logged Into Device’ to ‘Logged Into Device’ OR ‘have a call waiting’. Usually, when multiple caregivers are selected, the call is sent to all of them. In ‘Adjustment 2’, the one from the list of selected caregivers, that until then has been selected the least, gets the new call. Finally, in ‘Adjustment 3’ the branch of the decision tree in which caregivers are selected based on their trust relationship with the patient is swapped with the one in which they are selected based on their current status. This adjustment was implemented because simulation results showed that the decision tree was too selective on the trust relationship and could not differentiate on the status anymore.
C. Key Performance Indicators (KPIs) Nine different KPIs were considered during
the analysis. Firstly, the covered distance per shift. As the Accio nurse call system considers the location of the caregivers and the patients, it should be expected that the caregivers have to walk less to perform the same work. Secondly, as mentioned in the abstract, focus during development was on dividing the workload more evenly. In the simulations it will be inspected whether the system succeeds in doing so. Next, the average- and maximum time patients had to wait until a caregiver arrives to help them are both considered in the analysis. Subsequently, it is checked whether the selected caregivers have the required competences to fulfil the intervention, and also if they have a trust relationship with the
Page 13
xi
patient. Another aspect that is considered is how many caregivers are simultaneously selected per call. Lastly, the simulation keeps track of both the number of calls that disturbed a caregiver and the number of redirections per call.
D. Input data Input data is created in Microsoft Office Excel
using ‘Macro’s’ and consists of all calls, with their respective labels, that will be launched during the simulation. Every aspect of the created data is based on anonymous real-life data from Televic, [8] which is one of the actors in the Accio project. The data was analysed for patterns in the arrival times of calls. As a result, each day was divided in several time periods in which calls have a predefined chance to occur. The distribution of the call types was found in the literature. [9] The number of calls per week is kept constant
V. RESULTS All eight scenarios were tested in two
different departments. The first, referred to as department 1, represents a rather small department with a small number of caregivers and calls per week. The other, department 2, is bigger in size and has a rather average number of calls.
Firstly, a horizontal analysis on the Accio scenario was made for both departments. Increasing the number of calls per week had a deteriorating effect on all KPIs. For example the average- and maximum waiting times rose for both departments as illustrated for the average waiting time in department 1 in Figure 2.
Figure 2: Average waiting time in function of the number of calls per week ('Accio' on department 1)
The waiting times in function of the number of calls per week however showed the same pattern for increasing number of calls. This pattern can be seen in Figure 3 (black line).
Secondly, it was analysed what the influence of the Accio scenario was in comparison to the traditional scenario. Average waiting times were quite similar for both scenarios. The curve of the waiting times versus the number of calls per week did however show significant differences. For the traditional scenario, two peaks arose. One at about 20 seconds – immediate answer – and one at 140 seconds – answer after ignore. For the Accio scenario, these two peaks were scattered over a range of 20 and 120 seconds. These findings can be seen on Figure 3 and are a result of the possibility of redirecting a call to a colleague.
Figure 3: Percentage of calls in function of the waiting time (Accio vs Traditional on department 1)
Another important KPI that was discussed was the percentage of calls that disturbed a caregiver. In the literature it is found that disturbing a nurse significantly increases the risk on errors. [10] For this KPI, the two departments showed different results because of the different number of employees. In department 2 ‘Accio’ had a lower percentage disturbing calls than ‘Traditional’. This percentage was higher in department 1 since the smaller number of employees prevented the system from selecting a nurse that was not occupied. This was mainly on a cause of the system acting too differentiating on the trust relationship between caregivers and patients. This phenomenon was affirmed in ‘Effect 3’, where the system does not incorporate the trust relationship. The results are illustrated in Figure 4.
0
20
40
60
40 80 120 160 200 240 280
Wai
tin
g ti
me
[s]
Number of calls per week
0%
10%
20%
30%
40%
50%
0 100 200
per
cen
tage
of
the
calls
waiting time [s]
Accio
Traditional
Page 14
xii
Figure 4: Percentage disturbing calls ('Accio' vs 'Traditional' vs 'Effect 3' on department 1)
As ‘Effect 1’ is analysed mainly to evaluate the difference in work load distribution between the traditional- and the Accio nurse call system, the workload with ‘Traditional’ will be compared. Fixed nursing rounds such as check-up tours are, together with answering patient calls, an important asset of the work load of a nurse. Analysis showed that although these rounds are not distributed among the nurses by the nurse call system, the system does take them into account. Nurses that performed a lot of tasks in tours got less calls than those that did not. This suggests that the new nurse call system divides the work load better among the nurses. In comparison to ‘Accio’, there are not a lot of differences. This gives executives the opportunity to hire lower educated and thus less expensive employees without lowering the quality of care.
‘Effect 2’ was implemented to check what the results would be if caregivers handled a call without the required competences for that type of call. It was expected that maximum waiting times would increase as such situations only rarely occur when the nurse call system does not find anybody else to handle the call. In Table 1, the percentage of calls that had a waiting time of more than two minutes is shown. It illustrates that there are more calls with higher waiting times for ‘Effect 2’ then for ‘Accio’ as was expected.
‘Effect 3’ has, next to the lower percentage of disturbing calls, also a drawback. As the system differentiates less on the trust relationship, more caregivers are selected per call resulting in a larger average covered distance per shift. This is illustrated in Figure 5 for the average distance for all caregivers during the evening shift on department 2.
Table 1: Percentage of calls with a waiting time higher than two minutes (‘Accio’ vs ‘Effect 2’ on Department 1)
Number of calls per week
80 160 240
Accio 5,36 % 7,31 % 10,25 %
Effect 2 6,58 % 9,08 % 11,89 %
Figure 5: Total average covered distance of all caregivers in the evening shift ('Accio' vs 'Effect 3' on Department 2)
‘Adjustment 1’ was designed to prevent a caregiver from having a large ‘queue’ of calls waiting. On occasion it occurred, that a caregiver was on his way to a patient to answer his call and at that moment received a new call from another patient because he was ‘Free’ instead of ‘Busy’ as he was not logged into a device. With ‘Adjustment 1’ this situation can no longer present itself. As these situations do not happen very often, it was expected that maximum waiting times would drop. The decrease happened as expected, and is illustrated in Figure 6.
Figure 6: Maximum waiting time in function of the number of calls per week ('Accio' vs 'Adjustment 1' on Department 1)
The adjustment to the rules-et that gave the best results for both departments was ‘Adjustment 3’. This is the one in which the order of the decisive blocks in the decision tree was changed. Now, the system first checked the status of the nurses before checking their
0%
10%
20%
30%
40%
50%
80 160 240Per
cen
tage
dis
turb
ing
calls
Number of calls per week
Accio
Traditional
Effect 3
8
8,5
9
9,5
10
10,5
600 700 800To
tal t
rave
lled
dis
tan
ce [
km]
Number of calls per week
Accio
Effect 3
0
500
1000
1500
2000
80 160 240
Wai
tin
g ti
me
[s]
Number of calls per week
Accio
Adjustment 1
Page 15
xiii
personal relationship with the patient. The scenario strongly decreased the percentage disturbing calls as is illustrated in Figure 7.
Figure 7: Percentage disturbing calls ('Accio' vs 'Adjustment 3' on Department 2)
This has several positive effects such as lower average- and maximum waiting times and a lower number of redirected calls. However, as the system cannot take into account the trust relationship as well as for the Accio scenario, this new ruleset leads to a higher percentage of confidence breaks. The difference in percentages is illustrated in Figure 8. It is up to the executives to choose what is most important for them, the trust relationships, or the disturbing calls.
Figure 8: Percentage of calls for which there was no trust relationship between caregiver and patient ('Accio' vs 'Adjustment 3' on Department 1)
VI. CONCLUSION The results mainly showed that trade-offs will
have to be made when executives choose the best ruleset for their department. When one of the decisive blocks becomes too discriminating, the system will not be able to properly use one of the next. One example has been given with the ‘Trust Relationship’ and the ‘Status’ block. A lower percentage of breaks in the trust relationship will result in a higher percentage of disturbing calls and vice versa. Secondly, the
results made clear that the advantages of the system become more apparent for bigger departments than for smaller ones. This is because the work load is bigger and the system has a bigger set of nurses to divide the task upon.
Lastly, it is recommended that, when the Accio nurse call system is introduced, it should be easy for executives to make adjustments to the rule-set of the system. In this manner, they could impose their own accents on the system so that their department operates exactly the way they want it to. The translation tool could help in achieving this goal.
VII. REFERENCES [1] B. &. R. I. Haeck, „Waarom uw ziekenhuis vecht om
te overleven,” De Tijd, pp. 4-5, 19 Oktober 2013.
[2] iMinds, „Accio - Ambient aware provisioning of
continuous care for intra-muros organization,”
[Online]. Available:
http://www.iminds.be/nl/projecten/2014/03/04/a
ccio. [Geopend 3 Oktober 2013].
[3] F. Ongenae, Ontwerp en beheer van ontologieën
voor elektronische zorgdiensten, 2013.
[4] „W3C: World Wide Web Consortium,” [Online].
Available: http://www.w3.org.
[5] T. R. Gruber, „Toward principles for the design of
ontologies used for knowledge sharing,”
International Journal Human-Computer Studies,
vol. 43, nr. 5-6, pp. 907-928, 1995.
[6] S. Verstichel, „Semantiek als middel voor een
efficiëntere informatie-integratie,” Gent, 2012.
[7] FlexSim Software Products (FSP), „FlexSim,”
[Online]. Available: www.flexsim.com. [Geopend
16 Oktober 2013].
[8] Televic, „Anonymous logging data from the Televic
nurse call system installed at the Ghent University
hospital in 3 representative departments.,” Ghent,
2008.
[9] Ongenae, „An ontology-based nurse call
management system (oNCS) with probabilistic
priority assessment.,” BMC Health Services
Research 2011, p. 11:26.
[10] W. A. R. M. D. W. D. R. Westbrook JI, „Association
of Interruptions With an Increased Risk and
Severity of Medication Administration Errors.,”
Archives of Internal Medicine, pp. 170(8):683-690,
2010.
0%
5%
10%
15%
20%
25%
600 700 800
Per
cen
tage
dis
turb
ing
calls
Number of calls per week
Accio
Adjustment 3
0%
5%
10%
15%
80 160 240
Per
cen
tage
han
dle
d c
alls
Number of calls per week
Accio
Adjustment 3
Page 17
xv
Lijst van Tabellen Tabel 1: Lijst met verschillende Discrete Event Simulation Software 18 Tabel 2: Eigenschappen van oproepen 71 Tabel 3: Initiële verdeling van een dag in periodes in Departement 1 73 Tabel 4: Finale verdeling van een dag in periodes in Departement 1 74 Tabel 5: Initiële verdeling van een dag in periodes in Departement 2 77 Tabel 6: Finale verdeling van een dag in periodes in Departement 2 78 Tabel 7: Personeelsbestand ‘Traditioneel’ en ‘Effect 1’ op departement 1 81 Tabel 8: Personeelsbestand ‘Traditioneel’ en ‘Effect 1’ op departement 2 81 Tabel 9: Personeelsbestand ‘Accio’ op departement 1 82 Tabel 10: Personeelsbestand ‘Accio’ op departement 2 82 Tabel 11: Gemiddelde wachttijd [s] en zijn standaardafwijking [s]
(‘Accio’ vs ‘Traditioneel’ op Departement 1) 98 Tabel 12: Gemiddelde wachttijd [s] en zijn standaardafwijking [s]
(‘Accio’ vs ‘Traditioneel’ op Departement 2) 103 Tabel 13: Tijdsverdeling van zorgverleners over 'Direct' en 'Utilize' taken
bij 800 oproepen per week (‘Traditioneel’ vs ‘Effect 1’) 108 Tabel 14: Percentage oproepen met wachttijd langer dan twee minuten
(‘Accio’ vs ‘Effect 2’ op Departement 1) 110 Tabel 15: Percentage oproepen dat werd toegewezen aan een zorgverlener die de correcte
kwalificaties niet had (‘Effect 2’ op Departement 1) 111 Tabel 16: Gemiddelde wachttijd [s] en zijn standaardafwijking [s]
(‘Accio’ vs ‘Effect 3’ op Departement 1) 114 Tabel 17: Percentage oproepen met wachttijd langer dan twee minuten
(‘Accio’ vs ‘Effect 3’ op Departement 1) 114 Tabel 18:Tijdsverdeling van zorgverleners over 'Direct' en 'Utilize' taken
bij 800 oproepen per week (‘Accio' vs ‘Aanpassing 2’ op Departement 1) 118 Tabel 19: Percentage oproepen met wachttijd langer dan twee minuten
(‘Accio’ vs ‘Aanpassing 3’ op Departement 2) 122 Tabel 20:Tijdsverdeling van zorgverleners tijdens de vroege shift over 'Direct' en 'Utilize' taken
bij 800 oproepen per week (‘Accio' vs ‘Aanpassing 3’ op Departement 2) 123
Page 18
xvi
Lijst van Figuren Figuur 1: Overzicht van de thesis 3 Figuur 2: Verdeling van de patiënten per zorgverlener in de huidige situatie 9 Figuur 3: Illustratie van de zorgdriehoek in het Accio project 10 Figuur 4: Mobiele applicatie van de zorgverleners [18] 12 Figuur 5: Voorbeeld van een kleine ontologie [23] 14 Figuur 6: Voorbeeld van een Arena Flowchart [36] 19 Figuur 7: Voorbeeld van FlexSim Dashboard [37] 22 Figuur 8: Testdepartement op kleine schaal in FlexSim 38 Figuur 9: Voorstelling van een industrieel proces in FlexSim 38 Figuur 10: Voorstelling van een zorgproces in FlexSim 38 Figuur 11: Overzicht van de werking van het verpleegoproepsysteem 39 Figuur 12: Verschillende stappen in de huidige beslissingsboom van de ontologie 46 Figuur 13: Kamer met één bed als Basic Unit 47 Figuur 14: Kamer met twee bedden als Basic Unit 47 Figuur 15: Publieke sanitaire voorzieningen als Basic Unit 48 Figuur 16: Verplegerspost als Basic Unit 48 Figuur 17: Alle types zorgverleners als Basic Unit 49 Figuur 18: De 'Source' als Basic Unit 51 Figuur 19: De 'Dispatcher' als Basic Unit 51 Figuur 20: Verdeling van de tijd van een zorgverlener over een representatieve shift [61] 57 Figuur 21: Verschillende oorzaken van een oproep [8] 70 Figuur 22: Voorstelling van Departement 1 in FlexSim 71 Figuur 23: Verloop van het aantal ontvangen oproepen in Departement 1 72 Figuur 24: Histogram van het aantal oproepen in Departement 1 74 Figuur 25: Voorstelling van Departement 2 in FlexSim 75 Figuur 26: Verloop van het aantal ontvangen oproepen in Departement 2 76 Figuur 27: Histogram van het aantal oproepen in Departement 2 78 Figuur 28: Overzicht van de verschillende scenario's 80 Figuur 29: Beslissingsboom voor het toekennen van de status aan een 'Staff Member' (SM)
bij Accio scenario 84 Figuur 30: Beslissingsboom voor het toekennen van de status aan een 'Staff Member' (SM)
bij ‘Aanpassing 1’ 84 Figuur 31: Deel van de beslissingsboom uit Accio scenario dat een oproep toewijst aan een
zorgverlener (SM) op basis van status en locatie. 85 Figuur 32: Deel van de beslissingsboom met ‘Aanpassing 2’ dat een oproep toewijst aan een
zorgverlener (SM) op basis van status en locatie. 85 Figuur 33: Deel van de beslissingsboom uit Accio scenario waar eerst vertrouwensband
gecontroleerd wordt en dan pas status en locatie 86 Figuur 34: Deel van de beslissingsboom met 'Aanpassing 3' waar eerst status en locatie
gecontroleerd worden en dan pas vertrouwensband 86 Figuur 35: Gemiddelde wachttijd in functie van het aantal oproepen per week
(‘Accio’ op Departement 1) 88 Figuur 36: Maximale wachttijd in functie van het aantal oproepen per week
(‘Accio’ op Departement 1) 88 Figuur 37: Percentage oproepen in functie van de wachttijden (‘Accio’ op Departement 1) 88 Figuur 38: Percentage oproepen dat minstens eenmaal werd doorverwezen
(‘Accio’ op Departement 1) 90
Page 19
xvii
Figuur 39: Gemiddeld aantal zorgverleners dat geselecteerd werd per oproep (‘Accio’ op Departement 1) 90
Figuur 40: Percentage oproepen dat werd behandeld door een zorgverlener met de vereiste competentie als ervaring (‘Accio’ op Departement 1) 92
Figuur 41: Percentage oproepen dat storend was voor de geselecteerde zorgverlener (‘Accio’ op Departement 1) 92
Figuur 42: Gemiddeld afgelegde wandelafstand per shift per zorgverlener ('Accio' op Departement 1) 93
Figuur 43: Percentage oproepen in functie van de wachttijden (‘Accio’ op Departement 2) 95 Figuur 44: Gemiddeld aantal zorgverleners dat geselecteerd werd per oproep
(‘Accio’ op Departement 2) 96 Figuur 45: Percentage oproepen dat storend was voor de geselecteerde zorgverlener
(‘Accio’ op Departement 2) 96 Figuur 46: Gemiddelde wachttijd in functie van het aantal oproepen per week
(‘Accio’ vs ‘Traditioneel’ op Departement 1) 98 Figuur 47: Maximale wachttijd in functie van het aantal oproepen per week
(‘Accio’ vs ‘Traditioneel’ op Departement 1) 98 Figuur 48: Percentage oproepen in functie van de wachttijden
(‘Accio’ vs ‘Traditioneel’ op Departement 1) 99 Figuur 49: Gemiddeld afgelegde wandelafstand per shift per zorgverlener
('Traditioneel' op Departement 1) 100 Figuur 50: Percentage oproepen dat storend was voor de geselecteerde zorgverlener
(‘Accio’ vs ‘Traditioneel’ op Departement 1) 102 Figuur 51: Percentage oproepen in functie van de wachttijden
(‘Accio’ vs ‘Traditioneel’ op Departement 2) 103 Figuur 52: Percentage oproepen dat storend was voor de geselecteerde zorgverlener
(‘Accio’ vs ‘Traditioneel’ op Departement 2) 104 Figuur 53: Percentage oproepen dat niet werd behandeld door een zorgverlener met een sterke
persoonlijke vertrouwensband met de patiënt (‘Accio’ vs ‘Effect 1’ op Departement 1) 105 Figuur 54: Gemiddeld aantal zorgverleners dat geselecteerd werd per oproep
(‘Accio’ vs ‘Effect 1’ op Departement 2) 106 Figuur 55: Percentage oproepen dat minstens eenmaal werd doorverwezen
(‘Accio’ vs ‘Effect 1’ op Departement 2) 106 Figuur 56: Gemiddelde wachttijd in functie van het aantal oproepen per week
(‘Accio’ vs ‘Effect 1’ op Departement 2) 106 Figuur 57: Maximale wachttijd in functie van het aantal oproepen per week
(‘Accio’ vs ‘Effect 1’ op Departement 2) 106 Figuur 58: Gemiddeld afgelegde wandelafstand tijdens de vroege shift per zorgverlener
(‘Traditioneel’ op Departement 2) 1099 Figuur 59: Gemiddeld afgelegde wandelafstand tijdens de vroege shift per zorgverlener
(‘Effect 1’ op Departement 2) 1099 Figuur 60: Gemiddelde wandelafstand van alle zorgverleners tijdens de vroege shift
('Traditioneel' vs 'Effect 1' op Departement 2) 109 Figuur 61: Percentage oproepen dat storend was voor de geselecteerde zorgverlener
(Accio vs ‘Effect 2’ op Departement 1) 111 Figuur 62: Gemiddeld aantal zorgverleners dat geselecteerd werd per oproep
(‘Accio’ vs ‘Effect 3’ op Departement 1) 112 Figuur 63: Percentage oproepen dat storend was voor de geselecteerde zorgverlener
(‘Accio’ vs ‘Effect 3’ op Departement 1) 112 Figuur 64: Percentage oproepen dat minstens eenmaal werd doorverwezen
(‘Accio’ vs ‘Effect 3’ op Departement 1) 113
Page 20
xviii
Figuur 65: Gemiddelde wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Effect 3’ op Departement 1) 114
Figuur 66: Maximale wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Effect 3’ op Departement 1) 114
Figuur 67: Gemiddeld afgelegde afstand voor alle zorgverleners in de late shift (‘Accio’ vs ‘Effect 3’ op Departement 2) 115
Figuur 68: Maximale wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Aanpassing 1’ op Departement 1) 116
Figuur 69: Gemiddelde wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Aanpassing 2’ op Departement 1) 118
Figuur 70: Maximale wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Aanpassing 2’ op Departement 1) 118
Figuur 71: Percentage oproepen dat minstens eenmaal werd doorverwezen (‘Accio’ vs ‘Aanpassing 2’ op Departement 2) 119
Figuur 72: Gemiddelde wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Aanpassing 2’ op Departement 2) 119
Figuur 73: Maximale wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Aanpassing 2’ op Departement 2) 119
Figuur 74: Totaal gemiddeld afgelegde wandelafstand tijdens de vroege shift door alle zorgverleners (‘Accio’ vs ‘Aanpassing 2’ op Departement 2) 120
Figuur 75: Percentage oproepen dat storend was voor de geselecteerde zorgverlener (‘Accio’ vs ‘Aanpassing 3’ op Departement 1) 121
Figuur 76: Gemiddelde wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Aanpassing 3’ op Departement 1) 121
Figuur 77: Maximale wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Aanpassing 3’ op Departement 1) 121
Figuur 78: Percentage oproepen dat niet werd behandeld door een zorgverlener met een persoonlijke vertrouwensband met de patiënt (‘Accio’ vs ‘Aanpassing 3’ op Departement 1) 122
Figuur 79: Percentage oproepen dat niet werd behandeld door een zorgverlener met een sterke persoonlijke vertrouwensband met de patiënt (‘Accio’ vs ‘Aanpassing 3’ op Departement 1) 122
Page 21
xix
Inhoudstafel 1. Inleiding ............................................................................................................................................ 1
1.1. Probleemstelling ....................................................................................................................... 1
1.2. Doelstelling ............................................................................................................................... 1
1.3. Structuur ................................................................................................................................... 3
2. Literatuurstudie ............................................................................................................................... 5
2.1. Nood aan efficiëntie in de gezondheidszorg ............................................................................ 5
2.1.1. Studie van de Vlaamse krant ‘De Tijd’ ............................................................................. 5
2.1.2. Alarm Fatigue ................................................................................................................... 6
2.2. Verpleegoproepsystemen: de huidige situatie ........................................................................ 7
2.3. Accio project ........................................................................................................................... 10
2.3.1. Algemeen ....................................................................................................................... 10
2.3.2. Opbouw van het Accio verpleegoproepsysteem ........................................................... 13
2.4. Ontologieën in verscheidene sectoren ................................................................................... 14
2.5. Verschillende Discrete Event Simulation (DES) Software ....................................................... 15
2.5.1. Inleiding DES Software ................................................................................................... 15
2.5.2. Analyse van de verschillende DES Software .................................................................. 16
3. Vertaalmethodologie ..................................................................................................................... 25
3.1. Inleiding .................................................................................................................................. 25
3.2. Jena regels .............................................................................................................................. 25
3.3. FlexScript regels ...................................................................................................................... 28
3.4. FlexScript – C++ ...................................................................................................................... 29
3.5. Introductie van RIF ................................................................................................................. 30
3.6. Automatisering van de vertaling Jena – FlexScript ................................................................. 32
4. Modelopbouw ................................................................................................................................ 37
4.1. Inleiding van de werkwijze en inleiding op FlexSim ............................................................... 37
4.2. Gedetailleerde uitleg van de volledige huidige regelset + implementatie ............................ 40
4.2.1. Type oproep ................................................................................................................... 40
4.2.2. Oorzaak .......................................................................................................................... 41
4.2.3. Competenties ................................................................................................................. 42
4.2.4. Prioriteit ......................................................................................................................... 42
4.2.5. Vertrouwensband .......................................................................................................... 43
4.2.6. Status en locatie ............................................................................................................. 45
4.2.7. Conclusie ........................................................................................................................ 45
Page 22
xx
4.3. Basic Units, uitleg van de bibliotheek .................................................................................... 46
4.3.1. Kamers ........................................................................................................................... 47
4.3.2. Openbare plaatsen ........................................................................................................ 47
4.3.3. Verplegerspost ............................................................................................................... 48
4.3.4. Zorgverleners ................................................................................................................. 49
4.3.5. ‘Source’ .......................................................................................................................... 49
4.3.6. ‘Dispatcher’ .................................................................................................................... 49
4.4. Samenstelling van patiënten- en oproepenbestand .............................................................. 51
4.5. Samenstelling van het personeelsbestand ............................................................................. 52
4.6. Tijdsverdeling van de zorgverleners ....................................................................................... 53
4.6.1. Vaste verplegersrondes ................................................................................................. 54
4.6.2. Nastreven van een realistische tijdsverdeling over een shift ........................................ 56
4.6.3. Overleg tijdens de wissel van de shifts .......................................................................... 57
5. Key Performance Indicatoren ........................................................................................................ 58
5.1. Kostenfunctie ......................................................................................................................... 58
5.2. De verschillende KPIs ............................................................................................................. 59
5.2.1. De wandelafstand .......................................................................................................... 59
5.2.2. Gemiddelde tijd tot interventie ..................................................................................... 59
5.2.3. Maximale tijd tot interventie ......................................................................................... 59
5.2.4. Het respecteren van de competenties van de zorgverlener ......................................... 60
5.2.5. Het respecteren van de vertrouwensband tussen zorgverlener en patiënt ................. 61
5.2.6. Hoeveel zorgverleners worden tegelijk opgeroepen? ................................................... 61
5.2.7. Aantal onderbroken taken van de zorgverleners .......................................................... 62
5.2.8. Aantal keer dat een oproep wordt doorverwezen ........................................................ 63
5.2.9. De verdeling van de werklast ......................................................................................... 64
5.2.10. Conclusie ........................................................................................................................ 65
6. Het genereren van een realistische dataset .................................................................................. 66
6.1. Inleiding .................................................................................................................................. 66
6.2. Opstellen van een algemeen oproepenbestand op basis van Televic data [30]. ................... 67
6.2.1. Inleiding ......................................................................................................................... 67
6.2.2. Het samenstellen van een patiëntenbestand ................................................................ 67
6.2.3. Eigenschappen van een oproep ..................................................................................... 68
6.3. Het oproepenbestand voor Departement 1 .......................................................................... 71
6.4. Het oproepenbestand voor Departement 2 .......................................................................... 75
7. Simulaties ....................................................................................................................................... 79
Page 23
xxi
7.1. Inleiding .................................................................................................................................. 79
7.1.1. ‘Traditioneel’ .................................................................................................................. 80
7.1.2. ‘Accio’ ............................................................................................................................. 81
7.1.3. ‘Effect 1’: Personeelsbestand ......................................................................................... 82
7.1.4. ‘Effect 2’: Competentie .................................................................................................. 83
7.1.5. ‘Effect 3’: Vertrouwensband .......................................................................................... 83
7.1.6. ‘Aanpassing 1’: Status ‘Busy’ .......................................................................................... 84
7.1.7. ‘Aanpassing 2’: 1 zorgverlener ....................................................................................... 84
7.1.8. ‘Aanpassing 3’: Status vs Vertrouwensband .................................................................. 85
7.2. Resultaten van de scenario-analyse ....................................................................................... 87
7.2.1. Horizontale analyse van ‘Accio’ ..................................................................................... 87
7.2.2. ‘Accio’ vs ‘Traditioneel’ .................................................................................................. 97
7.2.3. ‘Accio’ vs ‘Effect 1’ ....................................................................................................... 104
7.2.4. ‘Accio’ vs ‘Effect 2’ ....................................................................................................... 110
7.2.5. ‘Accio’ vs ‘Effect 3’ ....................................................................................................... 111
7.2.6. ‘Accio’ vs ‘Aanpassing 1’ .............................................................................................. 115
7.2.7. ‘Accio’ vs ‘Aanpassing 2’ .............................................................................................. 117
7.2.8. ‘Accio’ vs ‘Aanpassing 3’ .............................................................................................. 120
8. Discussie & aanbevelingen ........................................................................................................... 124
8.1. Kritische analyse van het onderzoek .................................................................................... 124
8.2. Aanbevelingen betreffende het invoeren van het Nurse Call Systeem ............................... 126
8.3. Suggesties voor verder onderzoek ....................................................................................... 126
9. Conclusie ...................................................................................................................................... 128
10. Referenties ................................................................................................................................... 131
11. Bijlagen ......................................................................................................................................... 135
11.1. Verklarende FlexSim woordenlijst ........................................................................................ 135
11.2. Overzichtstabel van de personeelsleden ............................................................................. 137
11.3. Originele beslissingsboom Accio scenario ............................................................................ 138
11.4. Verplegersrondes in model .................................................................................................. 140
11.5. Inhoud van de bijgevoegde CD ............................................................................................. 141
Page 25
1
1. Inleiding
“Geef ruimte aan technologie. De overheid zal nooit voorop lopen in de technologische race. Het
enige wat ze kan doen is de ruimte geven aan mensen die wel voorop kunnen lopen. Dat is belangrijk.
Als de vergrijzing de grootste uitdaging voor de gezondheidszorg is, komt de grootste hoop om
kwaliteit en budget te verzoenen van nieuwe technologie.” [1]
1.1. Probleemstelling
In de gezondheidszorg is reeds heel wat onderzoek gedaan naar nieuwe verpleegoproepsystemen.
Deze systemen houden, in tegenstelling tot de huidige statische systemen, rekening met
verscheidene factoren zoals het weergeven van de naam van de patiënten [2] of het in rekening
houden van de wandelafstand van de zorgverleners [3]. Deze nieuwe systemen zorgen ook reeds
voor een meer directe communicatiemogelijkheid tussen patiënt en zorgverlener, in tegenstelling tot
de intercom voor de volledige kamer in de huidige systemen. [3] Door het invoeren van deze nieuwe
functionaliteiten wil men de werkdruk voor de zorgverleners onder controle houden zodat de patiënt
niet de dupe wordt van overwerkte zorgverleners. Deze werkdruk ligt in de zorgsector typisch hoog
en neemt almaar toe door onder andere de vergrijzing van de bevolking [4]. Indien het systeem er
effectief in zou slagen om de zorgprocessen te optimaliseren, zou dit niet positieve gevolgen hebben
voor de patiënten, maar zou dit ook een enorme besparing kunnen betekenen op het vlak van
resources. Niet alleen qua tijd, want uit onderzoek moet nog blijken wat de gevolgen zijn voor de
werkdruk van de zorgverleners, maar ook qua personeel. Aangezien het systeem het profiel van alle
personen in de setting kent en in rekening brengt, zou het ziekenhuizen toelaten om met
zorgverleners te werken die niet de volledige medische scholing gekregen hebben als de huidige
verplegers en dus minder duur zijn voor de ziekenhuizen.
1.2. Doelstelling
Een van die nieuwe systemen is recentelijk ontwikkeld in het Accio project. Dit project, dat tot stand
kwam door een samenwerking van onder andere Televic en iMinds, [5] werd in het leven geroepen
om een persoonsgeoriënteerd verpleegoproepsysteem te ontwikkelen. Televic verzorgt als bedrijf
reeds de huidige verpleegoproepsystemen in een groot deel van de Belgische zorginstellingen [6] en
bezit bijgevolg realistische data over het gebruik van deze systemen. [7] Het nieuwe systeem tracht
aan deze systemen een redenering toe te voegen en zo op slimme wijze de juiste verplegers toe te
wijzen aan een oproep. Het verpleegoproepsysteem maakt daarvoor gebruik van ontologieën. [8]
Page 26
2
Deze beschrijven een domein op een formele manier waarbij concepten, relaties en eigenschappen
via een overeenkomstige terminologie gedefinieerd worden. Daarboven staat een set van regels die
inwerkt op dat domein. Er zijn veel mogelijkheden om verder te bouwen op het Accio project, dat
ondertussen afgesloten is. Hoewel het verpleegoproepsysteem reeds ontwikkeld is, is het nog niet
getest, noch gesimuleerd geweest in een volledige en realistische ziekenhuisafdeling. De primaire
werking is wel reeds aangetoond aan de hand van tests in een twee-kamer omgeving. Deze kamers
waren volledig voorzien van alle technologische nieuwigheden. Deze setting wordt ook wel eens
‘Patient Room of the Future’ genoemd. [9]
Deze thesis is een vervolg op dat Accio project en beslaat twee aspecten. Ten eerste moet een
methodologie opgebouwd worden die toelaat om, vertrekkend vanuit operationele processen in een
ziekenhuissetting, een regelset verstaanbaar te kunnen voorstellen. Dit aspect is weergegeven op
Figuur 1 met de aanduiding ‘1’. De ontologie beslist aan de hand van een statische set kenmerken en
een vooraf gedefinieerde regelset hoe de operationele zorgprocessen worden verdeeld over de
zorgverleners. Op die manier wordt een hogere graad van efficiëntie beoogd zodat aan de patiënten
een zorgverlening met een betere kwaliteit kan aangeboden worden. Die regelset is echter niet op
een eenvoudige manier te beschrijven. De methodologie moet er dus voor zorgen dat
domeinexperten de regelset kunnen begrijpen en aanpassen aan hun noden en verlangens. In dit
deel van de thesis zal er dan ook gezocht worden naar een vertaaltool om de regelset vanuit de
ontologie automatisch te vertalen naar de taal die gebruikt wordt in de Discrete Event Simulator
(DES) waar het tweede deel van de thesis dan over verder gaat.
Dat tweede deel bestaat uit het ontwikkelen van een case simulator waarmee op basis van reële
input in een eerste fase de bruikbaarheid van het verpleegoproepsysteem getest zal worden en in
een tweede fase gepoogd zal worden om de regelset uit de ontologie te optimaliseren. Dit aspect is
eveneens aangeduid op Figuur 1 met de aanduiding ‘2’. Hiervoor moeten meetbare parameters en
Key Performance Indicatoren (KPIs) gedefinieerd worden waarmee het mogelijk moet zijn om
verschillende scenario’s met elkaar te vergelijken. Het kan hier bijvoorbeeld gaan om het vergelijken
van de werkdruk aan de hand van afgelegde wandelafstanden of de verdeling van de taken.
De combinatie van deze twee aspecten leidt tot de volgende onderzoeksvraag: ‘Is het mogelijk om de
schaalbaarheid van ontologieën en de daaraan gekoppelde operationele processen, alsook de
gerelateerde kosten te evalueren en deze verder te optimaliseren aan de hand van vooropgestelde
KPIs?’
Page 27
3
Scenario input: e.g.: - # patients
- kosten - handelingen
- aantal bedden-…
KPI- analaysis + PDCA
Act. 1 Act. 2 X
Act. 4
Start
Act. 5 X
Act. 3
Act. 6
End
Co
sts
Task
typ
e
Trans.Check room
Adm.(not) give
medsAdm.
1m 0s 5s 1m.
Bring medication to the patient room: IMPACT OF ONTOLOGY
Pro
cess
€ €€€
Static data sources
Ontology
Rule BOX
Ontology based decision platform2
1
Figuur 1: Overzicht van de thesis
1.3. Structuur
In deze thesis wordt begonnen met een literatuurstudie. Hierbij wordt er dieper ingegaan op de
noodzaak van de realisatie van deze thesis en van het Accio project. In hoeverre heeft de zorgsector
nood aan procesoptimalisatie en hoe kan de optimalisatie van de verpleegoproepsystemen hierbij
helpen? Daaropvolgend wordt er onderzocht hoe de oude oproepsystemen werken en waar de
zwakke punten van die systemen zich situeren. Vervolgens wordt het oproepsysteem van het Accio
project van naderbij bestudeerd waarbij er eerst dieper wordt ingegaan op de ontologie die het hart
vormt van het systeem. Tot slot worden verschillende DES-softwareprogramma’s bestudeerd en
vergeleken om te onderzoeken welke van deze het best geschikt is voor het opstellen van een
simulator voor het verpleegoproepsysteem. Na de literatuurstudie wordt stapsgewijs uitgelegd hoe
het eerste deel van de thesis, de vertaalmethodologie, tot stand gekomen is. Daarbij worden de
verschillende programmeertalen van dichterbij bekeken om te eindigen met de uiteindelijke
uitwerking van de vertaaltool. Dan wordt er gestart met de bespreking van het tweede deel van de
thesis met een gedetailleerde uitleg van de opbouw van de simulator. Hoe werkt de DES-software en
hoe werd deze aangewend om de operationele processen in een ziekenhuissetting te simuleren?
Vervolgens worden de KPIs, die zullen gebruikt worden om de verschillende scenario’s te vergelijken,
gedefinieerd en besproken. Vooraleer de verschillende scenario’s tegenover elkaar uiteengezet en
Page 28
4
geanalyseerd worden, wordt er uitgelegd hoe de realistische data input gegenereerd werd. Daarna
volgt een discussie van de resultaten om te eindigen met de conclusie. In de discussie wordt het
gevoerde onderzoek kritisch geanalyseerd, worden aanbevelingen gegeven bij het invoeren van dit
verpleegoproepsysteem en worden tenslotte suggesties voor verder onderzoek aangebracht. In de
conclusie wordt een samenvatting van de belangrijkste bemerkingen uit de vergelijking van de
scenario’s gegeven.
Page 29
5
2. Literatuurstudie
2.1. Nood aan efficiëntie in de gezondheidszorg
Er is een dringende nood aan efficiëntie in de gezondheidszorg. Verplegers kunnen niet meer genoeg
tijd besteden aan hun patiënten door een veel te hoge werkdruk. [10] Niet alleen het aantal taken
per verpleger stijgt, ook de vereiste intellectuele inhoud van deze taken vergroot. [10] Deze
werkdruk blijft groeien, enerzijds door het stijgende aantal hulpbehoevende patiënten en anderzijds
door de grotere gemiddelde werklast per patiënt. [10] Dit zijn twee belangrijke gevolgen van de
toenemende vergrijzing in ons land. Er komen inderdaad almaar meer ouderen die zorg nodig
hebben, maar ook het aantal zwaar hulpbehoevenden blijft stijgen door de steeds hoger wordende
levensverwachting. Een hogere werkdruk zorgt ook voor een grotere kans op fouten [11], onder
andere omdat er minder tijd vrij is om informatie over de patiënten uit te wisselen met andere
zorgverleners. [10]
2.1.1. Studie van de Vlaamse krant ‘De Tijd’
In 2012 leden dubbel zoveel Vlaamse algemene ziekenhuizen verlies als een jaar eerder. [12] Volgens
een onderzoek van De Tijd draaiden toen 12 van de 52 algemene ziekenhuizen in Vlaanderen verlies.
[4] Een groot aandeel hierin spelen de verlieslatende verpleegdiensten van deze ziekenhuizen. [12] In
elk van de zeven algemene ziekenhuizen in Vlaanderen die als VZW hun jaarrekening publiceren,
maken de diensten met veel verplegend personeel het meeste verlies. [4] Een verpleegkundige kost
een ziekenhuis gemiddeld 60.750 euro per jaar, waarvan het ziekenhuis 3.600 euro zelf moet halen
uit de opbrengsten van andere afdelingen. [4] Aangezien een gemiddeld Vlaams algemeen ziekenhuis
ongeveer 1000 personeelsleden telt, waarbij dokters niet meegeteld zijn, [4] loopt dit bedrag snel op.
De werkuren van elke zorgverlener die ze in dienst hebben, zijn dus zeer kostbaar voor het
ziekenhuis. De verlieslatende verpleegdiensten worden dan volgens het onderzoek [4]
gecompenseerd door de overconsumptie op het vlak van het gebruik van scanners en het
aanspreken van klinische laboratoria, wat niet altijd noodzakelijk is. [13] Ook de ziekenhuisapotheek
houdt het ziekenhuis nog licht overeind. [4] Een ander gevolg is dat alle ziekenhuizen de capaciteit
van elke afdeling maximaal trachten te benutten, [10] waarbij er weinig rekening gehouden met het
feit dat bijna één derde van de patiënten binnenkomt via de spoedafdeling. In de spoedafdeling is er
daarom een probleem bij de doorstroming naar de andere afdelingen, wat ook enorm tijdrovend is
voor de zorgverleners die een plaats moeten zoeken voor de patiënt. [10]
Page 30
6
Ziekenhuizen proberen ook te besparen door patiënten vroeger uit het ziekenhuis te ontslaan. [14]
Er is door de overheid een vooropgesteld aantal verantwoorde ligdagen vastgelegd voor iedere
afdeling en dit aantal wordt bijna nooit meer overschreden. [10] De reden hiervoor is dat een patiënt
vroeger vervangen door een nieuwe patiënt financieel interessanter is voor ziekenhuizen. [15] Dit
betekent dat het volledige proces van opname, zorg, tests en screenings steeds sneller uitgevoerd
moet worden. Daarnaast moeten ook de nazorg en het ontslag van de patiënt sneller geregeld
worden. Dat is één van de redenen waarom het werk dat aan een bed moet gebeuren veel intenser
wordt, iets waar in financiële modellen vaak geen rekening mee gehouden wordt. [10] Resistentie
van de ziekenhuisbacterie is daarbij een bijkomend recent probleem. [16] Er moet veel meer tijd
gespendeerd worden aan ontsmetting en er moet in alle gevallen heel voorzichtig omgesprongen
worden met materiaal. Wanneer een verpleger bezig is met het behandelen van een andere patiënt,
moet die er ook op letten om contaminatie van deze patiënt te vermijden wanneer hij/zij1 een
toestel aanraakt om het alarm te beantwoorden. [16]
Daarnaast wordt er ook bezuinigd op het aantal zorgverleners per patiënt, [10] waardoor de
patiënten langer moeten wachten vooraleer hun vraag naar assistentie beantwoord wordt. In ons
land heeft een verpleegkundige gemiddeld elf patiënten onder haar hoede, [10] terwijl dat in andere
Europese landen zoals Noorwegen soms maar vijf is. [10, 14] Een efficiënter verpleegoproepsysteem
kan er hier voor zorgen dat die bezuiniging op het aantal zorgverleners niet noodzakelijk ten koste
moet gaan van de geleverde zorg.
2.1.2. Alarm Fatigue
‘Alarm Fatigue’, vrij vertaald alarmresistentie, is een gekend fenomeen in de gezondheidsinstellingen
en wordt gezien als één van de meest negatieve gevolgen van de technologische evolutie. [16, 17]
Alle verschillende toestellen maken een eigen geluid, vaak bijna onderling strijdend om de aandacht
van een verpleger. Zorgverleners worden daarnaast ook meermaals opgeroepen door patiënten. Op
termijn worden ze ongevoelig voor alarmgeluiden en reageren ze bijgevolg niet altijd adequaat of
snel genoeg. Het dagelijkse aantal alarmen op één drukbezette intensieve zorgafdeling kan
gemakkelijk een duizendtal zijn [16], waarvan er naar schatting 90% als niet dringend beschouwd
kunnen worden. [17] Al deze alarmen zijn dus niet alleen afkomstig van de patiënten zelf, maar ook
van allerlei toestellen die de patiënt monitoren. [17] Elk van deze alarmen moet in principe door een
zorgverlener kunnen herkend worden, waarbij er automatisch en zo snel mogelijk een prioriteit en
1 In het vervolg van dit document zal er naar een zorgverlener altijd worden verwezen door middel van
‘hij’, waarmee beide geslachten bedoeld worden.
Page 31
7
een mogelijke actie aan moet gekoppeld worden. [16] Ongevoelig worden aan deze geluiden en op
termijn bij elke oproep denken dat het toch niet dringend zal zijn, is dan ook één van de gevaarlijkste
zaken die kan gebeuren in de gezondheidszorg. Om deze problemen te vermijden moet er genoeg
aandacht besteed worden aan ‘alarm management’. [17] Deze techniek zorgt ervoor dat het aantal
alarmen niet te groot wordt, door enkel het noodzakelijke bij elke patiënt te monitoren. [16] Uit
onderzoek bleek ook dat een geavanceerder oproepsysteem dat rekening houdt met het feit dat een
tweede oproep binnen de 10-60 seconden, afhankelijk van het type oproep, niet onmiddellijk
opnieuw een alarm moet genereren, hierbij kan helpen. [16] Alarm management houdt ook de
bijscholing van verplegers in, waarbij deze leren omgaan met het grote aantal alarmsignalen om
alarmresistentie te vermijden. [16]
Efficiëntie nastreven wordt toegejuicht [10], op voorwaarde dat er met alle factoren rekening
gehouden wordt, zowel werklast als werkverdeling. De deelstaten in België hebben onlangs de
bevoegdheid gekregen om de kwaliteit van hun ziekenhuizen te meten en te controleren. [14] Het is
dus duidelijk dat alle actoren uit de gezondheidssector leiden onder de druk die er heerst. De
ziekenhuizen hebben het moeilijk om rond te komen, de verplegers zitten op hun tandvlees en de
patiënten worden sneller ontslagen om de volgende al binnen te kunnen brengen. In deze thesis
wordt een geïntegreerd verpleegoproepsysteem getest dat ervoor moet zorgen dat ziekenhuizen
gemakkelijker minder geschoolde werkkrachten kunnen inzetten, de werkdruk van de zorgverleners
daalt en patiënten sneller geholpen worden door een verpleger.
2.2. Verpleegoproepsystemen: de huidige situatie
Traditionele verpleegoproepsystemen zijn statisch [18], oproepen worden gemaakt door het
indrukken van een vaste knop die zich in het bed of aan de muur bevindt. Daardoor wordt de patiënt
beperkt in zijn vrijheid om rond te bewegen aangezien hij geen oproepen kan lanceren op andere
locaties. Het algoritme om een verpleger op te roepen is beperkt, het stuurt het signaal enkel naar
één of meerdere zorgverleners die op dat moment verantwoordelijk zijn voor die bepaalde kamer. Ze
nemen dus geen enkele omgevingsfactor zoals de status van de zorgverlener of de relatie met de
patiënt in rekening bij het kiezen van de zorgverlener en kunnen bijgevolg ook geen extra informatie
over de aard van de oproep doorsturen naar de zorgverlener. Het automatisch versturen van
oproepen wanneer sensoren aan het bed bepaalde ongewenste situaties detecteren is hierbij nog
niet mogelijk. [18] Een zorgverlener kan een oproep ook niet afwijzen, hij kan enkel de oproep
mondeling doorgeven aan een collega, met het risico dat de patiënt zal vergeten worden. Deze
mondelinge doorverwijzingen kunnen ook niet geregistreerd worden.
Page 32
8
Zorgverleners krijgen dus bij het begin van hun shift een aantal kamers toegewezen waarvoor ze
verantwoordelijk zijn. [18] Wanneer ze assistentie nodig hebben bij het behandelen van een patiënt
kunnen ze wel geholpen worden door andere zorgverleners van de afdeling en zeer uitzonderlijk
door iemand van een andere afdeling. Bij het lanceren van een oproep uit een kamer, wordt de
oproep voor andere zorgverleners meestal ook zichtbaar door een lampje dat brandt boven de
kamer in de gang. Zo kan het voorvallen dat toevallig voorbijlopende zorgverleners deze oproep
beantwoorden terwijl er al een andere zorgverlener onderweg is naar deze kamer.
Vaak komt het in de huidige situatie ook voor dat meerdere zorgverleners verantwoordelijk zijn voor
dezelfde kamer, waardoor die allemaal worden aangesproken bij een oproep van een patiënt uit die
kamer. Op die manier is het opnieuw goed mogelijk dat een zorgverlener bij een kamer aankomt en
opmerkt dat er al iemand anders bezig is met het behandelen van de patiënt. Wanneer die
zorgverlener het behandelen van een andere patiënt moest onderbreken om deze oproep te
beantwoorden, is dit niet aangenaam voor die andere patiënt die alleen gelaten werd alvorens de
behandeling afgelopen was. Om assistentie te vragen bij een oproep moeten de zorgverleners
gebruik maken van het apparaat van de patiënt om een nieuwe oproep te lanceren. De
communicatie moet gebeuren via de intercom in de kamer. Er is dus in het huidige systeem een
gebrek aan communicatiemogelijkheden tussen zorgverleners onderling, [18] maar ook tussen
zorgverleners en de patiënt. In zorginstellingen komt het vaak voor dat patiënten bepaalde
voorkeuren hebben op vlak van bepaalde zorgnoden, zoals bijvoorbeeld de manier van wassen. Ook
kan het zijn dat bepaalde patiënten omwille van taalproblemen niet door een bepaalde zorgverlener
willen of kunnen behandeld worden. Al deze neveninformatie, waaronder ook de toestand van de
patiënt, is in het huidige systeem niet altijd ter beschikking van de zorgverlener.
De communicatie tussen patiënt en zorgverlener verloopt evenmin optimaal. [18] De zorgverlener
moet bij de patiënt ter plaatse gaan om de reden en de prioriteit van de oproep te achterhalen en
om na te gaan of er nog extra hulpmiddelen zullen nodig zijn om de patiënt te kunnen helpen.
Opnieuw kan het zijn dat de zorgverlener daarvoor de behandeling van een andere patiënt heeft
moeten onderbreken. Vaak gebeurt het dus dat die zorgverlener nog heen en weer naar de
verpleegbasis moet lopen vooraleer hij de patiënt van dienst kan zijn. In de meeste ziekenhuizen is er
wel een mogelijkheid tot communicatie tussen verpleegbasis en kamer via een intercomsysteem,
maar dit wordt zelden gebruikt door het gebrek aan privacy dat daarmee gepaard gaat. [19] Alle
andere personen in de kamer kunnen het volledige gesprek in dat geval gewoon mee volgen. Er is
eveneens een gebrek aan feedback voor de patiënt na het versturen van de oproep. Hij weet meestal
niet of de oproep opgepikt is door iemand en ook niet hoe lang hij ongeveer zal moeten wachten.
Page 33
9
Een patiënt kan de oproep ook opnieuw blijven versturen wanneer hij vindt dat hij al te lang aan het
wachten is, wat een grote invloed heeft op het eerder beschreven probleem van ‘Alarm Fatigue’
waarbij zorgverleners immuun worden voor het alarmgeluid. Door het veelvuldig weerklinken van
het vervelende geluid nemen zorgverleners hun toestel soms niet mee binnen in de kamer wanneer
ze een patiënt verzorgen, om het voor zichzelf en de patiënt zo aangenaam mogelijk te maken. [8]
Hoewel dit voornamelijk ’s nachts gebeurt om de patiënt niet te wekken, kan dit wel negatieve
gevolgen hebben voor de andere patiënten wanneer deze dringend hulp nodig hebben en niet
gehoord worden door de verpleger.
Op elk departement van een ziekenhuis zijn er altijd patiënten die meer oproepen versturen dan
andere. [18] Er zijn patiënten die bij het minste ongemak om hulp vragen en er zijn patiënten die
hevige pijn als onderdeel van het genezingsproces beschouwen en niemand tot last willen zijn. De
kamers worden gewoonlijk per aaneengesloten zone verdeeld over de verschillende zorgverleners,
waarbij enkel rekening gehouden wordt met de bezetting van de bedden. Zelfs los van het aantal
oproepen is deze verdeling niet optimaal aangezien meer hulpbehoevende patiënten ook meer hulp
vereisen. Deze arbitraire verdeling zorgt er dus vaak voor dat niet alle zorgverleners een even drukke
zone toebedeeld krijgen, wat een nadelig effect heeft op de verdeling van de werklast. [18] Zo een
oneerlijke verdeling zorgt er ook voor dat de drukst bezette zorgverleners op de toppen van hun
tenen lopen. Dit verdelingsprincipe is verduidelijkt in Figuur 2. Zorgverlener (ZV) 4 heeft vier
hulpbehoevende patiënten onder zijn hoede gekregen, terwijl zorgverlener 2 slechts één iemand
heeft die meer dan gemiddeld hulp zal nodig hebben. Bijgevolg zal zorgverlener 4 hier dus een
grotere werklast ervaren dan de andere zorgverleners.
Figuur 2: Verdeling van de patiënten per zorgverlener in de huidige situatie
Page 34
10
Huidige verpleegoproepsystemen blijken dus nog heel wat tekortkomingen te hebben om volledig
optimale zorgverlening voor de patiënten mogelijk te maken. Zo houden ze geen rekening met
omgevingsfactoren, waardoor de zorgverlener op voorhand niet weet waar hij aan toe zal zijn.
Daarnaast loopt niet alleen de communicatie tussen zorgverleners onderling stroef, maar ook tussen
zorgverlener en patiënt. Kostbare tijd en info gaat hierdoor gemakkelijker verloren. Tot slot zorgt de
arbitraire verdeling van de bedden onder de verschillende zorgverleners voor een oneerlijke
verdeling van de werklast waardoor er wrevel kan ontstaan onder het personeel.
2.3. Accio project
2.3.1. Algemeen
Het Accio project is een samenwerking tussen verschillende bedrijven, waaronder Boone, In-ham,
Televic en iMinds en enkele zorginstellingen. [5] Men ging op zoek naar hoe men, door het gebruik
van intelligente ICT, de continue werking van zorgprocessen in deze zorginstellingen kon
optimaliseren. De focus lag bij het zoeken naar ondersteunende oplossingen voor de zorgverleners
en patiënten vooral op de driehoek zorgverlener – patiënt – kamer zoals te zien is op Figuur 3. Het
uiteindelijke doel was om via dit project de uitwisseling van informatie binnen zorginstellingen te
optimaliseren.
Figuur 3: Illustratie van de zorgdriehoek in het Accio project
Onderzoek uitgevoerd door medewerkers van het Accio project in verscheidene zorginstellingen, [5]
waaronder het Dominiek Savio instituut voor mensen met een cognitieve beperking en het hospitaal
te Aalst, toonde aan dat er mogelijkheden waren voor de verbetering van het
verpleegoproepsysteem. Zoals hierboven reeds vermeld zijn de huidige oproepsystemen niet
efficiënt genoeg. Eén van de doelen van het Accio project was om een dynamisch, context- en
profielbewust verpleegoproepsysteem te ontwerpen dat, met behulp van een ontologie, alle
Page 35
11
beschikbare heterogene zorgdata mee in rekening neemt. De ontologie wordt gebruikt om alle
informatie van de volledige zorginstelling op een gestructureerde manier te verzamelen. Over het
gebruik van ontologieën wordt in paragraaf 2.4 meer uitleg gegeven. Door met deze informatie te
redeneren moet het voor het beslissingsalgoritme, dat werkt als een beslissingsboom die top-down
overlopen wordt, [18] mogelijk zijn om de meest geschikte zorgverleners te vinden om een oproep
van een patiënt te behandelen. De volledige beslissingsboom is weergegeven in bijlage 11.3. In het
verpleegoproepsysteem van Accio wordt er bijvoorbeeld rekening gehouden met de status van de
zorgverleners zodat de zorgverleners die bezig zijn met een patiënt minder kans hebben om
opgeroepen te worden. Op die manier zou het aantal storende oproepen kunnen dalen en de
werkverdeling onder zorgverleners meer gelijk maken. Het algoritme wordt volledig beschreven in
paragraaf 4.2.
Automatische oproepen moeten ook kunnen gelanceerd worden wanneer er door de sensoren een
ongewenste combinatie van bepaalde contextinformatie gedetecteerd wordt. Zo werd tijdens de
ontwikkeling van het systeem de detectie van ‘Systemic inflammatory response syndrome (SIRS)’ als
toepasselijk voorbeeld gebruikt. [18] SIRS is een reactie van het lichaam op een acute aandoening
zoals bijvoorbeeld pancreatitis. Enkele voorwaarden voor dit geval werden gesteld, waarna het
systeem dit met een hoge waarschijnlijkheid correct detecteerde.
Zowel zorgverleners als patiënten krijgen in het verpleegoproepsysteem van Accio een individuele
mobiele belknop. [18] Met deze knop kunnen patiënten dus ook oproepen lanceren wanneer ze niet
in hun kamer aanwezig zijn. Dit verlaagt het risico voor patiënten wanneer ze in de gang
rondwandelen aangezien ze nu iemand kunnen bellen bij eventuele moeilijkheden. Een ander
voordeel is dat niet alleen de patiënten, maar ook de zorgverleners steeds door het systeem kunnen
gelokaliseerd worden. Het grootste voordeel is echter dat zorgverleners vanuit iedere positie in het
departement contact kunnen opnemen met patiënten en collega’s om zo over betere info te
beschikken bij het afhandelen van oproepen.
Voor de zorgverleners werd een smartphone applicatie ontwikkeld waarmee ze op eenvoudige wijze
oproepen kunnen ontvangen, accepteren, in de wacht zetten of afwijzen. [18] Een screenshot van de
applicatie is gegeven in Figuur 4. Dit moet ertoe leiden dat patiënten niet alleen sneller geholpen
worden, maar ook efficiënter. De applicatie biedt zoals beschreven ook de mogelijkheid om
rechtstreeks contact op te nemen met de patiënt, waarbij de privacy wel degelijk in acht genomen
wordt door de communicatie te voorzien via het persoonlijke toestel van de patiënt. De bedoeling is
ook om het systeem op termijn volledig ‘zelflerend’ te maken, waardoor de ontologie uit ervaring
zelf bestaande interacties kan detecteren en meenemen in het algoritme. [8]
Page 36
12
Figuur 4: Mobiele applicatie van de zorgverleners [18]
Dit systeem werd ontwikkeld door een samenwerking van vele bedrijven die het systeem ook graag
op de markt willen brengen. Het gaat hier echter nog steeds om een geavanceerd prototype en nog
geen uitvoerbaar concept. Via een ‘Proof of Concept’, die geïnstalleerd werd in een ‘Patient Room of
the Future’ (Prof), [9] werd de werking van het systeem wel al getest, maar een echte test op een
volledige afdeling werd nog niet doorgevoerd. ProF ontstond uit een consortium van verschillende
organisaties uit de zorgsector en is een concept waarbij de patiënt centraal staat. Het gaat om een
prototype kamer waarin de patiënt de meeste omgevingsfactoren zelf kan regelen. Zo kan deze
automatisch de lichten doven of de gordijnen openen. Daarnaast is de infrastructuur ook aangepast
zodat bezoekers comfortabeler in de buurt van de patiënt kunnen blijven en verplegend personeel
efficiënter kunnen werken. [20]
Uit de vergelijking van paragraaf 2.3.1 en 2.2 komen verschillende voordelen van het Accio
oproepsysteem aan het licht. Zo zijn er veel meer mogelijkheden tot overleg tussen de zorgverleners
onderling en tussen de zorgverleners en de patiënten. Dit leidt enerzijds tot een betere zorgverlening
omdat zorgverleners sneller weten welke actie moet ondernomen worden en anderzijds tot een
betere samenwerking tussen de zorgverleners omdat ze gemakkelijk en overal info kunnen
uitwisselen. Ook bezit het systeem informatie over de profielen van alle actoren in de omgeving
waardoor het hiermee rekening kan houden bij het toewijzen van oproepen aan zorgverleners. Zoals
beschreven heeft het oproepsysteem zijn functionaliteit echter enkel in een ProF bewezen, en nog
niet op schaal van een volledig departement. Daarom wordt in deze thesis een simulator ontworpen
die moet nagaan of het systeem operationeel kan gemaakt worden en wat de voor- en nadelen ervan
Page 37
13
zijn. Hoe het algoritme precies werkt wordt in bijlage 11.3 geïllustreerd aan de hand van de volledige
beslissingsboom die zorgverleners toewijst aan oproepen.
2.3.2. Opbouw van het Accio verpleegoproepsysteem
Door de enorme technologische vooruitgang maken telkens meer en meer toestellen hun intrede in
de traditionele patiëntenkamer. [16] Het gaat om toestellen die alle omgevingsfactoren
interpreteren en zich aanpassen aan die factoren, toestellen die patiënten elke minuut van de dag in
de gaten houden en toestellen die een enorme ondersteuning (kunnen) zijn voor de zorgverleners.
Sensoren moeten op termijn zowel de taak van de zorgverlener als de huidige toestand van de
patiënt registreren, om zo onmiddellijk de omgeving volledig aan de noden van de gebruikers te
kunnen aanpassen. Maar de aanpassing van de gezondheidszorgsector naar het gebruik van deze
technologieën gaat niet zo vlot als zou verwacht worden. Één van de hoofdredenen hiervoor is dat ze
niet voldoende gericht zijn op de werkelijke vereisten van de gebruikers, waardoor die zich verzetten
tegen de opgang van deze technologieën omdat het hun efficiëntie in sommige gevallen verlaagt in
plaats van verhoogt. [21] De nieuwe services zijn ook te weinig gefocust op de directe interactie
tussen zorgverlener en patiënt. [21] Kortom, het grote probleem zit in het gebrek aan communicatie
tussen de ontwerpers en de gebruikers. [21]
Om te vermijden dat er bij het Accio project een kloof ontstond tussen technologie en praktijk
werden zowel de ontwikkelaars als de gebruikers vanaf het begin bij elke stap betrokken tijdens het
ontwerpen van het intelligent verpleegoproepsysteem, zijn ontologie en algoritmes. De gebruikers
waren in dit geval de dokters, de zorgverleners en de gezondheidszorgspecialisten. Het ontwerp
startte met de analyse van de dagelijkse noden en taken van de gebruikers aan de hand van
workshops en dergelijke om een ideaal prototype voor de applicatie te ontwerpen. Tijdens elke stap
van het proces werden de gebruikers door de ontwikkelaars aangesproken om mee te bepalen welke
contextinformatie er in betrekking moest genomen worden en welke algoritmes moesten gebruikt
worden om de oproepen toe te wijzen. Zo werd snel duidelijk welke elementen belangrijk waren
voor de keuze van een zorgverlener en welke niet. Uiteraard speelden de suggesties van de
gebruikers ook een belangrijke rol in het creëren van de interface voor de applicatie. Hierbij werd
ook gelet op gebruiksgemak en functionaliteit. Na elke stap werd een nieuwe versie van de applicatie
voorgelegd aan verschillende zorgverleners, waarop zij dan feedback mochten leveren. [21]
Op deze manier kwam een systeem tot stand dat de goedkeuring had van zowel de software-
ontwikkelaars als de gebruikers, waardoor de kans op een geslaagde integratie in de hedendaagse
zorginstellingen en –processen een stuk hoger zou moeten liggen. [21]
Page 38
14
2.4. Ontologieën in verscheidene sectoren
De software in het Accio project werkt zoals reeds aangehaald op basis van een ontologie. [18] Een
ontologie wordt gebruikt om kennis of data over een bepaald interessedomein te verzamelen en om
dat domein op een formele manier te beschrijven op basis van een overeengekomen terminologie
door gebruik te maken van concepten, relaties en eigenschappen. Een definitie van een ontologie
wordt gegeven door Gruber.T [22]: “Een ontologie is een specificatie van een conceptualisering van
een context van kennisbeschrijving”. Dit betekent dus dat een ontologie concepten, relaties tussen
deze concepten en eigenschappen beschrijft in dat bepaalde interessedomein. Een relatie kan hier
bijvoorbeeld de vertrouwensband tussen patiënt en zorgverlener zijn. In Figuur 5 is een voorbeeld
gegeven van een kleine ontologie waar de verschillende relaties (auteur) en concepten (Persoon) op
aangeduid zijn. [23] ‘Tekst.doc’ is een ‘Document’ met als titel ‘Ph.D.’ en als tekst ‘Welkom’, de
auteur is ‘Naam’ en ‘Naam is een ‘Persoon’.
Figuur 5: Voorbeeld van een kleine ontologie [23]
Boven deze ontologie staat een set van regels die inwerken op de informatie die in de ontologie
terug te vinden is. Op basis van die regels kunnen functies worden opgeroepen of acties worden
ondernomen die invloed hebben op de ontologie. Deze regels zorgen er dus voor dat de ontologie
kan redeneren in de reasoner waardoor nieuwe relaties en eigenschappen tussen klassen in de
ontologie tot stand kunnen komen. Eén van de meest recente ontwikkelingen in standaard
ontologietalen is Web Ontology Language (OWL) [24] van het World Wide Web Consortium (W3C).
[25] Hierop wordt dieper ingegaan in paragraaf 2.4. Een voordeel van ontologieën is het feit dat deze
meer en meer geïntegreerd worden in de hedendaagse industrie. [23] Zoals bijvoorbeeld ook in het
integreren van alle data van het spoornetwerk over Europa. [26] Er zijn al verschillende
handleidingen op de markt om zelf ontologieën te leren bouwen, zoals bijvoorbeeld de Pizza Tutorial
van Horridge M.. [27]
Wat een ontologie zo innovatief maakt is het feit dat alle heterogene data afkomstig uit totaal
verschillende systemen en in totaal verschillende formaten op een eenvoudige manier kan
geïntegreerd en gestructureerd worden. Een ontologie kan op zichzelf bestaan (‘Single ontology
approach’) [26] of kan opgedeeld worden in kleinere ontologieën waarbij iedere heterogene
Page 39
15
informatiebron zijn eigen ontologie heeft (‘Multiple ontology approach’). [26] In dit laatste geval
moeten dan mappings of vertalingen voorzien worden om de overgang te voorzien tussen de
verschillende ontologieën, wat niet altijd eenvoudig is. De meest efficiënte benadering is de
gecombineerde benadering (‘Hybrid ontology approach’) [26] waar iedere informatiebron zijn eigen
lokale ontologie heeft die onderdeel is van een grotere gedeelde ontologie. Die grotere ontologie
legt de basisstructuur voor alle lokale ontologieën vast en vergemakkelijkt de uitwisseling tussen
deze ontologieën. Elke lokale ontologie breidt de kennis die in de gedeelde ontologie vastgelegd is,
uit op zijn eigen manier om de toepasbaarheid op het eigen informatiesysteem groter te maken.
Er werden reeds ontologieën ontwikkeld voor toepassingen in de gezondheidszorg, waarbij reeds
aandacht besteed werd aan de omgevingsbewuste redeneringen die moeten gebeuren op deze
ontologie, maar deze redeneringen werden nog niet gebruikt voor het optimaliseren van
zorgprocessen. Op dat vlak verschilt de Accio ontologie van de reeds bestaande ontologieën. [21]
Deze ontologie zorgt enerzijds voor de data-integratie en anderzijds voor de regelset die met deze
data moet redeneren. Eerst moet de ontologie nagaan wat de toestand van het departement is op
elk moment door alle informatie over de patiënten, de werknemers en het departement te
modelleren. Wie zijn de werknemers, wie zijn de patiënten, wat is de taak van iedere werknemer,
waar bevinden de werknemers zich op dit moment enzovoort. Alle noodzakelijk contextinformatie is
terug te vinden in de ontologie. Ten tweede is er de regelset die bepaalt welke oproep aan welke
werknemer wordt toegewezen. Deze regelset legt ondubbelzinnig vast hoe het systeem in elke
situatie moet reageren.
2.5. Verschillende Discrete Event Simulation (DES) Software
2.5.1. Inleiding DES Software
Eén van de doelen van deze thesis is om door middel van een simulatiesoftware het
omgevingsbewuste verpleegoproepsysteem, dat tijdens het Accio project werd ontworpen, uitvoerig
te testen. Een simulatiesoftware wordt gebruikt om een abstracte representatie of abstract model te
maken van de werkelijke situatie. [28] Dit simulatiemodel wordt dan gebruikt om effecten van
aanpassingen of de werking van prototypes te testen in een risicoloze context. Dit kan onder andere
toegepast worden op het vlak van productieprocessen, gezondheidszorg, verkeer enzovoort. [28] Het
gebruik van simulatiesoftware levert vooral veel voordelen op voor systemen waar het te gevaarlijk
of te risicovol is om werkelijke tests uit te voeren, voor systemen waar de procesvariabiliteit te hoog
is om in werkelijkheid alle situaties te kunnen testen, systemen waarvoor een worst-case scenario
moet getest worden dat altijd tot vernietiging van het systeem leidt enzovoort. [28]
Page 40
16
Er zijn verschillende soorten simulatiesoftware bekend, maar die kunnen hoofdzakelijk opgedeeld
worden in twee categorieën: continue simulatiepakketten en discrete simulatiepakketten. Beide
maken elk op hun eigen manier een abstractie van de realiteit. Vooreerst zijn er dus de continue
simulatiesoftware, waarmee een fysiek systeem kan gesimuleerd worden dat continu de toestanden
van het systeem analyseert door gebruik te maken van vergelijkingen, en dan vooral
differentiaalvergelijkingen. [29] Het betreft dynamische simulaties die afhankelijk zijn van de tijd en
op elk moment aangepast worden. Ze zijn complexer dan de discrete simulatiepakketten en vragen
meestal meer rekentijd. [30]
Daarnaast zijn er ook de discrete simulatiepakketten, ook wel Discrete-Event Simulation (DES)
Software [30] genoemd, die de werking van een systeem modelleren als een discrete serie van
evenementen met elk een bijhorend tijdstip van voorkomen. Elke gebeurtenis of elk evenement
vindt plaats op een specifiek tijdstip en verandert de staat van het systeem. De staat wordt
gedefinieerd als de welbepaalde set van variabelen die de toestand van het systeem op dat moment
bepaalt. Tussen de gebeurtenissen blijft het systeem voortdurend in dezelfde staat, de set van
variabelen blijft dus constant, zodat de software onmiddellijk naar het tijdstip van het nieuwe
evenement kan voortgaan. Daardoor moet de situatie van het systeem in dit geval veel minder
gecontroleerd worden dan bij continue simulatiesoftware en kan er dus veel sneller gesimuleerd
worden. [30]
Om deze laatste redenen werd er voorkeur gegeven aan een DES Software omdat dit soort software,
door zijn structurele manier van werken, het best geschikt is om de beslissingsboom uit de ontologie
stap voor stap uit te voeren. De volledige simulatie kan op die manier aangevoerd worden door het
invoeren van de lijst met oproepen en hun respectievelijke tijdstip van lanceren. Deze zullen als de
belangrijkste evenementen gelden in de simulatie. Tijdens de simulaties zal de status van een
zorgverlener of oproep dus niet aangepast worden vooraleer er iets gebeurt in het departement,
zoals bijvoorbeeld het lanceren van een oproep of het toekomen van een verpleger in een kamer.
2.5.2. Analyse van de verschillende DES Software
In het begin van het academiejaar werd er op zoek gegaan naar een ideale DES om de werking van
het verpleegoproepsysteem mee te modelleren. Hierbij waren er enkele vereiste eigenschappen die
de software zeker moest bevatten. Deze vereisten zijn hieronder geformuleerd als de belangrijkste
vragen die gesteld werden bij het testen van iedere mogelijke software.
Page 41
17
Kan de regelset van het verpleegoproepsysteem er apart uit geëxtraheerd worden zonder daarbij
eerst nutteloze programmeercode te moeten verwijderen? In welk formaat kan deze regelset uit
de DES gehaald worden?
Welke KPIs worden standaard meegegeven in de output? Kunnen er op eenvoudige wijze zelf KPIs
gedefinieerd worden?
Is er een eenvoudige connectie met Excel beschikbaar voor zowel het inladen van input als het
uitschrijven van resultaten?
Is er voldoende grafische ondersteuning voor de gebruiker om op elk moment van de simulatie de
situatie eenvoudig te kunnen controleren? Of kan dit op een andere manier gecontroleerd
worden?
De link met Excel wordt als voordeel aanzien omdat de data van Televic [7] immers in Excel
bestanden werden verkregen, de analyses op deze data werden in Excel uitgevoerd en nieuwe data
werd gegenereerd met behulp van Macro’s in Excel. Over deze data wordt in Hoofdstuk 6 uitgebreid
uitleg gegeven. Met een uitgebreide grafische ondersteuning kan op elk moment gemakkelijk
nagegaan worden wat de toestand van het systeem is, bijvoorbeeld welke zorgverlener zich op welke
plaats bevindt, welke patiënten aan het wachten zijn, wie er bezig is met het uitvoeren van welke
taak enzovoort.
In Tabel 1 is een overzicht terug te vinden van alle DES software die onderzocht werden, het is een
bijgewerkte versie van een tabel die op het internet werd teruggevonden met de bekendste DES
software [31]. De software uit de originele tabel [31] waarover te weinig informatie beschikbaar was
op het internet werden niet meegenomen in Tabel 1. Enkele van deze software, zoals bijvoorbeeld
Galatea, Adevs en MASON, waren enkel een bibliotheek met bijhorende programmeertaal om een
DES te ontwerpen in een bestaande simulatiesoftware zoals bijvoorbeeld Eclipse. Bijgevolg hadden
ze zelf geen of een maar zeer beperkte interface om de simulaties uit te voeren. De voorkeur ging
naar een volledig op zichzelf werkende software waardoor over deze drie niet verder uitgeweken
wordt. Tortuga is een Java Framework [32] om een DES uit te voeren in een bestaande
simulatiesoftware die gebruik maakt van Java. Bij nader onderzoek was er toch te weinig informatie
beschikbaar over Tortuga, waardoor deze ook niet meer in beschouwing werd genomen. Na de
eerste selectie bleven er dus nog vier goede keuzes over die dan aan de hand van kleine oefensessies
en handleidingen grondiger bestudeerd werden. Deze vier zullen in wat volgt ook uitgebreider
besproken worden. Het gaat om Arena, FlexSim, FlexSim HealthCare en TIBCO BusinessEvents.
Page 42
18
Naam Taal Interface Library/ Software
Commercieel/ Open Source
Adevs [33] C++ niet grafisch Library Open Source
Arena [34, 35, 36] Flowchart 3D Software Commercieel
FlexSim [37] C++ / FlexScript 3D Software Commercieel
FlexSim HealthCare [38] C++ / FlexScript 3D Software Commercieel
Galatea [39] Galatea Language niet grafisch Library Open Source
MASON [40, 41] Java 3D (beperkt) Library Open Source
SimPy [42, 43] Python niet grafisch Software Open Source
TIBCO BusinessEvents [44, 45, 46] Java niet grafisch Software Commercieel
Tortuga [47] Java niet grafisch Framework Open Source
Tabel 1: Lijst met verschillende Discrete Event Simulation Software
Arena
De Arena simulatiesoftware is ontworpen om productieprocessen te modelleren. Het wordt gebruikt
om het huidige productieproces te definiëren en vervolgens om, na het doorvoeren van kleine
aanpassingen in het model, de toekomstige performantie van het systeem te simuleren. Op die
manier kunnen complexe verbanden in het proces in kaart gebracht worden en kunnen verdere
mogelijkheden tot verbeteringen ontdekt worden. Dit kunnen verbeteringen of herstructureringen
zijn op het vlak van supply chain, distributie, warehousing, processen, productie en logistiek. De
werking van het proces kan in Arena ook grafisch voorgesteld worden. Het visuele aspect van de
software is optioneel, standaard wordt er enkel gewerkt met de visualisatie van de flowchart die te
zien is op Figuur 6. Maar de werking van elk type bedrijfsproces kan in 3D visueel weergegeven
worden. De werking van een proces wordt in Arena gedefinieerd aan de hand van één of meerdere
flowcharts, zoals in Figuur 6 te zien is.
Arena zorgt voor een grote flexibiliteit waarbij het door de verschillende versies van de software
mogelijk is om op elk niveau van detail of complexiteit te modelleren naargelang de keuzes en
eventuele doelen van de gebruiker. Het wordt gebruikt door veel grote internationale bedrijven,
zoals General Motors, Nike en dergelijke [36], die mogelijke aanpassingen in hun business processen
veelvuldig simuleren en analyseren om continu verbeteringen na te streven. Deze simulaties
opbouwen neemt veel tijd in beslag bij het begin van het project, maar eens die drempel is genomen
kunnen de gevolgen van kleine aanpassingen in het business proces heel snel geanalyseerd worden.
De gevolgen van die aanpassingen kunnen zo voorspeld worden zonder ingrijpende acties te moeten
doorvoeren aan het echte productieproces. Ook verschillende ‘wat-als’ scenario’s kunnen met deze
software eenvoudig naast elkaar gezet en vergeleken worden. De eenvoudige connectie met Excel
rekenbladen voor zowel in- als output is daarbij één van de vereisten die gesteld werden voor de
Page 43
19
ideale software. Bij aankoop van een volledige licentie kan ook gebruik gemaakt worden van de
dienst technische ondersteuning die assistentie verleent bij problemen met de Arena software. Er
zijn op de website twee versies van de software beschikbaar, Arena Standard Edition en Arena
Professional Edition [36]. Deze laatste is een meer geavanceerde versie van de Standard Edition,
maar voor de toepassingen in deze thesis is de Standard Edition genoeg, waarvoor een licentie meer
dan 2000 euro per jaar kost [36].
De kennismaking met de Arena software gebeurde aan de hand van een uitgebreide handleiding [34]
met daarin enkele kleine zelfstudiemodellen waarbij de doorstroming aan een eenvoudig
controlepunt op een luchthaven moest gemodelleerd en geanalyseerd worden. Deze oefenmodellen
werden uitgevoerd in een voorlopige versie van de software [35], die de belangrijkste
functionaliteiten wel bevatte. De uiteindelijke flowchart die moet opgesteld worden is op Figuur 6 te
zien. De passagiers stellen de flow voor die door deze flowchart loopt en zij zullen dus één voor één
alle verschillende stappen doorlopen. In Arena worden deze elementen die de flow voorstellen
‘entities’ genoemd. Afhankelijk van hun identificatiegegevens wordt er door het proces beslist of ze
al dan niet doorgelaten worden. De eigenschappen van het volledige proces kunnen allemaal
individueel ingesteld worden in de Arena module. In dit geval zijn dat onder andere de verdeling van
de toekomende passagiers, de driehoeksverdeling waaraan de duur van de identiteitscontroles
voldoet, de kans dat een passagier de controlepost mag passeren enzovoort. Na het simuleren
worden de basisresultaten automatisch gegenereerd in de outputrapporten. Indien financiële
gegevens als input gegeven worden, zoals bijvoorbeeld het loon van de agent die de
identiteitscontroles uitvoert, wordt ook een financieel rapport gegenereerd. Op die manier kunnen
verschillende situaties vergeleken worden. In de volgende stappen van dit oefenmodel werden nog
een bagagecontrolepunt en een veiligheidscontrole, waarbij er willekeurig passagiers worden
gecontroleerd, ingevoerd.
Figuur 6: Voorbeeld van een Arena Flowchart [36]
Page 44
20
De Arena software voldoet aan enkele gestelde eigenschappen, maar toch zijn er enkele
bedenkingen. Bij het modelleren van het verpleegoproepsysteem zou het moeilijk zijn om de
‘entities’ van de flowchart eenduidig te definiëren. In deze software wordt de flowchart overlopen
voor elke persoon apart, terwijl de beslissingsboom in de ontologie doorlopen wordt door de
verzameling zorgverleners. In deze laatste boom is het immers zeer belangrijk dat de volledige lijst
met zorgverleners doorheen de volledige boom gaat en niet persoon per persoon, omdat sommige
beslissingen in de boom afhangen van hoeveel zorgverleners er op dat moment nog overschieten in
deze lijst. De regelset, die in de software gedefinieerd staat als een flowchart, omzetten naar een
regelset in een bepaald formaat blijkt niet zo vanzelfsprekend. De regelset kan wel geëxtraheerd
worden als flowchart, maar een uitdrukking in een bepaalde programmeertaal zou ook handig zijn.
Voorlopig wordt dus beslist om eerst de andere software te onderzoeken vooraleer een beslissing te
nemen over Arena.
TIBCO BusinessEvents
TIBCO BusinessEvents Software werd door de begeleiders aangereikt als een mogelijk
softwarepakket voor de simulatie van het model. Het is een product van het bedrijf TIBCO [44], dat
bekend staat voor hun softwarepakketten voor informatiebeheer en procesoptimalisatie voor
bedrijven. Het softwarepakket wordt al gebruikt door onder andere Citibank Asia en Union Pacific
Railroad [45]. TIBCO BusinessEvents is een complexe DES Software die alle zinvolle informatie uit de
gebeurtenissen en data van het bestaande informatiesysteem haalt. Eén van de sterke punten van
de software is onder andere het omgaan met big data. Er kunnen snel sterke analyses uitgevoerd
worden op zowel gebeurtenissen uit het verleden als op real-time informatie om op die manier
complexe verbanden binnen het systeem te ontdekken en om de waarschijnlijkheid dat bepaalde
risico’s en trends opnieuw voorkomen te voorspellen. [45]
De gebruiker kan bovenop de standaardregels van de software ook zelf regels definiëren en
implementeren, om de software te leren naar welke trends er moet gezocht worden. De werking van
de software moet niet stopgezet worden om extra regels te definiëren, wat de betrouwbaarheid
groot maakt. Op basis van deze regels kunnen ook automatisch real time waarschuwingen
gelanceerd worden of automatisch bepaalde procedures in gang gezet worden.
De software werd getest aan de hand van het oefenmodel dat meegegeven werd in de handleiding
op de website. [48, 49] Doorheen de opbouw van het oefenmodel wordt de werking van de
belangrijkste functionaliteiten aangeleerd. De opzet van het model is om een fraudedetectiesysteem
Page 45
21
te simuleren, dat op basis van de frequentie en grootte van de transacties in een bepaald tijdslot
beslist of het om een verdachte rekening gaat of niet.
Het belangrijkste voordeel van TIBCO Business Events ten opzichte van alle andere software is het
feit dat de software volledig gratis te verkrijgen is. Wanneer de mogelijkheden van deze sterke
business software getoetst worden aan de vooraf gestelde eisen, blijkt echter dat TIBCO
BusinessEvents niet helemaal gelijkaardig is aan Arena en FlexSim en voor deze toepassing minder
geschikt is. De software heeft geen grafische ondersteuning, waardoor de werking van het model van
een ziekenhuisafdeling op ieder moment moeilijk te controleren zou zijn. Na het voltooien van de
oefenmodellen was de werking van de software nog niet volledig duidelijk en ook over de
gegevensuitwisseling met Excel rekenbladen werd tijdens de opbouw van dit model niets vermeld.
Verder onderzoek leert dat gegevens inlezen en uitschrijven met behulp van Excel echter wel
mogelijk is [50]. Aangezien na het overlopen van de handleiding en het uitgebreide oefenmodel nog
niet duidelijk is hoe de software precies zou kunnen dienen voor het simuleren van een
verpleegoproepsysteem, wordt deze software voorlopig ook opzij geschoven en worden eerste de
andere software verder onderzocht.
FlexSim
FlexSim staat gekend als een sterke simulatiesoftware waarmee elk systeem uit elke soort industrie
kan geanalyseerd en geoptimaliseerd worden [51]. FlexSim wordt gebruikt op vlak van productie,
logistiek, transport en andere. Het is mogelijk om op verschillende niveaus van detail en complexiteit
te programmeren, enkel met de basisimplementaties of ook met het zelf definiëren van
programmeercode in C++ of FlexScript [51]. FlexScript stamt af van de C++ programmeertaal en bezit
standaard specifieke functies die in FlexSim veel gebruikt worden maar in de klassieke C++ taal niet
gedefinieerd zijn. Het betreft dus een aangepaste C++ taal speciaal ontworpen voor het
programmeren in FlexSim. Over de precieze verschillen tussen beide wordt in paragraaf 3.4. meer
uitleg gegeven. De regelset die volledig vastlegt hoe het systeem in een bepaalde situatie moet
reageren, kan volledig apart geprogrammeerd worden in de ‘User Commands’. Daardoor is deze
regelset ook volledig afzonderlijk uit de simulatie te halen in C++. C++ is een gekende
programmeertaal, wat de kans vergroot op een eenvoudigere automatische vertaling naar de
ontologie. Aangezien FlexSim al meermaals intensief gebruikt werd in andere vakken tijdens de
opleiding, was het bestuderen van de handleiding en het bouwen van oefenmodellen hier niet meer
noodzakelijk.
Page 46
22
De connectie met Excel voor zowel het inladen als uitschrijven wordt eenvoudig uitgelegd in de
handleiding. [52] Maar ook de ingebouwde statistische analysetools zijn reeds ver ontwikkeld
waardoor uitschrijven naar Excel niet altijd noodzakelijk is. Deze statistische gegevens worden ook
gebruikt in het ‘Dashboard’ waar na elke simulatie alle mogelijke KPIs als output kunnen gegenereerd
worden. Een voorbeeld van het ‘Dashboard’ met enkele KPIs is gegeven in Figuur 7. Naast de
standaard geïmplementeerde KPIs zoals totale wandelafstand en werkverdeling van een werknemer,
die eveneens terug te vinden zijn op Figuur 7, kunnen ook geavanceerde KPIs zelf gedefinieerd en
uitgeschreven worden. Aan de definitie en implementatie van deze KPIs wordt later in Hoofdstuk 5
meer aandacht besteed.
Figuur 7: Voorbeeld van FlexSim Dashboard [37]
Door de eerder vermelde brede toepassingsmogelijkheden kan met behulp van FlexSim ook de
volledige werking van een ziekenhuisafdeling gesimuleerd worden. Wanneer daarbij de grafische
elementen uit de standaardbibliotheek van FlexSim HealthCare (FlexSim HC) [38] toegevoegd
worden, kan ook visueel gemakkelijk een afdeling nagebouwd worden. Met deze software kan in
tegenstelling tot FlexSim HC, wel enkel nadruk gelegd worden op de werking en toewijzing van de
zorgverleners.
FlexSim voldoet dus ruimschoots aan alle vereisten die op voorhand gesteld werden, maar is wel
betalend. Universiteit Gent is in het bezit van een Student Licence voor FlexSim 6. De prijzen voor
een licentie zijn niet eenduidig en kunnen enkel via een offerte aangevraagd worden. Vooraleer een
definitieve beslissing genomen wordt, wordt eerst een variant van FlexSim bestudeerd, die specifiek
gericht is op de gezondheidszorg.
Page 47
23
FlexSim Healthcare
FlexSim HealthCare (FlexSim HC) is ontstaan uit de samenwerking tussen specialisten uit de
gezondheidszorg en ingenieurs van de commerciële simulatiesoftware FlexSim. [53] Het wordt
specifiek gebruikt om simulaties uit te voeren in complexe medische zorginstellingen en
ziekenhuizen. Met behulp van deze simulaties moet het mogelijk zijn om optimalisaties uit te voeren
op het vlak van personeelsgebruik, patiëntendoorstroming en het toewijzen van operatiezalen,
scanners en dergelijke. De grafische ondersteuning in 3D is heel sterk zodat elke gebeurtenis in het
model snel kan opgemerkt worden. Gebruikers kunnen kiezen tussen werken met de eenvoudige
standaard implementaties of het implementeren van zelf geschreven geavanceerde
programmeercodes.
De grafische ondersteuning is even sterk als bij FlexSim, waardoor hier ook elke gebeurtenis tot in
detail kan geanalyseerd worden zonder daarbij output als tekst te moeten genereren. De
communicatie met Excel verloopt op dezelfde manier als bij FlexSim HC, terwijl ook de ingebouwde
statistische analysemogelijkheden vergevorderd zijn. FlexSim HC biedt de mogelijkheid om de
performantie van een zorginstelling gedurende enkele weken te achterhalen in enkele minuten,
waarbij ook gedetailleerde analyses van elke minuut mogelijk zijn. De standaardbibliotheek van
FlexSim HC bevat de belangrijkste elementen om een standaardafdeling uit een ziekenhuis na te
bouwen, maar daarnaast kunnen ook zelf elementen zoals specifieke zorgverleners apart
gedefinieerd of aangepast worden. De volledige regelset kan in zowel FlexScript als C++ apart
geïmplementeerd worden en achteraf eenvoudig uit de simulatie gehaald worden. Op deze formaten
van de regelset wordt later dieper ingegaan.
Er werd kennis gemaakt met FlexSim HC aan de hand van enkele oefensessies waarbij hetzelfde
model telkens uitgebreid werd. [52] De oefenmodellen worden opgebouwd in een beperkte
kennismakingsversie van de software, die niet alle functionaliteiten bezit. Met deze weggelaten
functionaliteiten werd wel al kennisgemaakt tijdens vorige projecten in FlexSim, het betreft immers
functies die ook in FlexSim geïmplementeerd zijn. Het volledige model stelde een beperkte
ziekenhuisafdeling voor waar patiënten aankomen op de dienst, zich aanmelden aan de balie en
plaatsnemen in de wachtzaal. Wanneer een controlekamer vrij was, werden ze opgehaald door een
verpleger die hen naar één van beide controlekamers bracht. Na een kort onderzoek door een dokter
werd beslist of ze het ziekenhuis mochten verlaten of nog verder moesten behandeld worden. In het
eerste geval verliet de patiënt rechtstreeks het ziekenhuis. In het andere geval werd de patiënt door
diezelfde verpleger met een rolstoel vervoerd naar een bed waar hij langer kon verblijven. Bij dit
model moest gelet worden op een efficiënte doorstroming van de patiënt door rekening te houden
Page 48
24
met het beperkte aantal rolstoelen en controlekamers, de duur van registratie aan de balie, de duur
van een controle enzovoort.
Aangezien dit oefenmodel de typische werking van FlexSim HC voorstelt, werd opgemerkt dat de
software vooral gericht is op de flow van patiënten en zorgverleners doorheen een afdeling.
Wanneer een verpleegoproepsysteem moet gemodelleerd worden, gaat het om patiënten die
langdurig op de afdeling verblijven en is de doorstroming van die patiënten dus niet van toepassing.
De sterke punten van deze software liggen dus, ondanks de specialisatie in de medische sector, niet
volledig in lijn met de doelstellingen van deze thesis. Daarenboven bezit de Universiteit Gent op dit
moment geen licentie voor deze software, waardoor ook een aankoop van deze eerder dure
software vereist zou zijn. Opnieuw zijn geen eenduidige prijzen beschikbaar op de website [53] en
moet een offerte aangevraagd worden. FlexSim HC benadert de eisen voor de ideale software voor
dit model maar wordt dus om bovenvermelde redenen, waarbij vooral de noodzakelijke investering
zwaar doorweegt, niet gekozen.
Conclusie
De vier eisen die gesteld werden bij het begin van de zoektocht naar een DES Software, worden enkel
door FlexSim probleemloos ingevuld waardoor dit softwarepakket uiteindelijk uitgekozen wordt om
het model te simuleren. De belangrijkste redenen voor het kiezen van dit softwarepakket worden
hieronder nog eens vermeld.
Sterke grafische mogelijkheden.
Veel nuttige KPIs kunnen standaard uit elke simulatie gehaald worden.
Elk model is heel sterk te individualiseren.
Regelset kan volledig apart gedefinieerd en uit de software geëxtraheerd worden.
Ervaring met de software uit andere projecten, waardoor inwerken niet noodzakelijk is.
Page 49
25
3. Vertaalmethodologie
3.1. Inleiding
Een van de doelen van deze thesis is om het voor de leidinggevenden zo eenvoudig mogelijk te
maken om de simulatie volledig aan te passen naar hun wensen. De invloed van elke kleine
aanpassing in de regelset moet kunnen bestudeerd worden in elke mogelijke situatie in elk mogelijk
departement. De regelset bepaalt hoe het oproepsysteem reageert in de mogelijke situaties die zich
in een zorginstelling kunnen voordoen [8]. Die situaties zijn afhankelijk van de huidige status en
competenties van elke zorgverlener, de samenstelling van het patiëntenbestand, het takenpakket
van de zorgverlener tijdens die shift, het aantal openstaande oproepen op dat moment enzovoort.
Het moet voor de gebruikers dus mogelijk zijn om snel een departement naar keuze na te bouwen in
een simulator en de regelset in de ontologie aan te passen waar nodig. In deze thesis wordt zoals in
Hoofdstuk 2.5 besproken gekozen voor FlexSim [37], waardoor in wat volgt elke referentie naar een
simulator op FlexSim zal doelen. Aangezien de regelset moet aangepast worden in de ontologie, is
een automatische koppeling nodig tussen die regelset in de ontologie en de regelset in de FlexSim
simulatie. Het gaat hierbij om twee regelsets in twee verschillende programmeertalen, waardoor
deze koppeling kan geïnterpreteerd worden als een automatische vertaling. Op die manier moet de
gebruiker de geavanceerde programmeermethodes van FlexSim niet onder de knie hebben om snel
kleine of grote aanpassingen door te voeren in de regelset, maar moet hij enkel kennis hebben van
de domeinontologie. De opbouw van deze vertaling kan gezien worden als het tweede deel van de
thesis, dat volledig losstaat van het opbouwen van een betrouwbare simulatie.
In wat volgt zal meer uitleg gegeven worden over enerzijds de taal van de regels in de ontologie en
anderzijds de taal van de regels die gebruikt worden om in de FlexSim simulatie aan te sturen.
Vervolgens zal aangetoond worden hoe de overgang kan mogelijk gemaakt worden door middel van
een tussenstap naar een regelset in een ander generiek formaat. De drie besproken talen zullen elk
verduidelijkt worden door middel van eenzelfde regel die voor de drie formaten als voorbeeld zal
dienen.
3.2. Jena regels
In het doctoraat ‘Ontwerp en beheer van ontologieën voor elektronische zorgdiensten’ van dr. ir. F.
Ongenae [18] werd de volledige ontologie opgebouwd met de huidige regelset voor het
verpleegoproepsysteem. Deze regels zijn in de ontologie geprogrammeerd in de Web Ontology
Language (OWL), de meest gekende en gebruikte ontologietaal [25]. Naast OWL is er ook OWL 2 Web
Page 50
26
Ontology Language (OWL 2) [54]. OWL 2 is een vernieuwing op OWL waarbij er dus enkele nieuwe
features toegevoegd zijn, maar dezelfde syntaxis en relaties behouden zijn. Er is een directe
achterwaartse compatibiliteit tussen OWL en OWL 2, wat betekent dat ontologieën geschreven in
OWL automatisch ook kunnen gebruikt worden in OWL 2. [54] Beide talen worden aangeraden door
het World Wide Web Consortium [25] en hebben enkele bekende subtalen zoals bijvoorbeeld OWL-
Full, OWL-Lite en OWL-DL. [8] Deze laatste is gebaseerd op de ‘Description Logics’ (DL), een deel van
de eerste orde logica. De redeneringen in OWL-DL zijn altijd efficiënt en kunnen in eindige tijd
worden voltooid. Telkens wanneer een ‘event’ optreedt in de ontologie worden alle regels tegelijk
aangesproken door een redeneertool, de ‘Reasoner’. Die gaat volgens een bepaald algoritme na of
alle voorwaarden voor een regel voldaan zijn. Indien dit het geval is, wordt de bijhorende functie
(‘functor’) opgeroepen die een opdracht vervult en bepaalde relaties of concepten in de ontologie
aanpast. In deze ontologie kan deze functie bijvoorbeeld zorgen voor het aanpassen van de status
van een oproep of zorgverlener. Met behulp van deze ‘Reasoner’, die de regelset loslaat op de
ontologie, functioneert het volledige oproepsysteem zoals het hoort en wordt inherente kennis
expliciet gemaakt. [8]
Jena is een bibliotheek die gebruikt wordt in de ontologie en waarin ook regels kunnen gedefinieerd
worden. Met behulp van deze regels in Jena kunnen dus variabelen uit het contextmodel van de
ontologie aangesproken en gewijzigd worden. In de moderne toepassingen van ontologieën wordt
deze taal niet zo frequent meer gebruikt aangezien het om een verouderde programmeertaal gaat.
[18]
Voor dit deel van de thesis moest er dus gestart worden van een representatieve subset met Jena
regels uit de huidige regelset van de ontologie. Een regel in de Jena programmeertaal kan gezien
worden als een geneste ‘if-structuur’ zonder ‘else’ commando’s. Elke lijn van de Jena regel wordt
gecontroleerd en van zodra er aan één voorwaarde niet is voldaan, wordt de rest van deze regel niet
meer verder bekeken tot er een volgend evenement optreedt. Voor elke specifieke situatie die zich
kan voordoen in de zorginstelling en waarbij het systeem iets moet ondernemen, moet er een regel
vastgelegd worden. Dit zorgt ervoor dat er enorm veel Jena regels zijn voor één regelset zodat er
gekozen werd om de vertaaltool te ontwerpen op basis van slechts een representatieve subset van al
deze regels.
(?c upperaccio:hasStatus taskaccio:Redirected)
Bovenstaande lijn is afkomstig uit een regel van de ontologie en toont aan hoe de structuur van het
Jena formaat opgebouwd is. Elke variabele die gebruikt wordt in de regel, wordt aangesproken door
Page 51
27
middel van een vraagteken en de naam van die variabele. Elke entiteit in een ontologie, zoals
bijvoorbeeld een functie, concept, relatie of individual, die gecontroleerd wordt, moet eerst
aangesproken worden door middel van de locatie of klasse waar de functie kan gevonden worden,
gevolgd door een dubbele punt en de naam van de klasse of relatie zelf. In onderstaande lijn code
wordt er bijvoorbeeld nagegaan of de variabele c, die een oproep voorstelt, de status ‘Redirected’
heeft. De functie die kan controleren welke status een oproep heeft, is terug te vinden in de klasse
‘upperaccio’, terwijl de verschillende statussen die een oproep kan hebben gedefinieerd zijn in de
klasse ‘taskaccio’. Deze verwijzingen naar de correcte klasse zijn nodig om te garanderen dat de regel
ondubbelzinnig is. Alles wordt immers gedefinieerd aan de hand van Uniform Resource Identifiers
(URIs), die verder worden uitgelegd in paragraaf 3.5.
In Fragment 1 is een voorbeeldregel in Jena weergegeven, het gaat om regel 202 uit de bestaande
ontologie. In deze regel wordt een oproep die al eens doorverwezen is, toegewezen aan een andere
zorgverlener die op dat moment vrij is, de correcte competenties heeft en zich dichtbij de oproep
bevindt. Eerst wordt er gecontroleerd of de opgegeven variabele c effectief een oproep is en of de
status van deze oproep gelijk is aan ‘Redirected’, wat erop wijst dat de oproep eerder al is
doorgestuurd door een zorgverlener. Vervolgens wordt er nagegaan of de reden van de oproep
bekend is in de ontologie en of het om een medische reden gaat. In de volgende drie lijnen code
zoekt de reasoner of er een persoon bestaat die de rol ‘StaffMember’ heeft. Indien dit het geval is,
wordt de huidige rol van die persoon gezocht en wordt er nagegaan welke competentie een persoon
met die rol heeft en of die competentie gelijk is aan ‘AnswerMedicalCallCompetence’, wat wil zeggen
dat die persoon een oproep met medische reden mag beantwoorden. [18] Ook wordt er gekeken of
de oproep doorverwezen is door een ander personeelslid, waarbij het ‘notEqual’ commando
ervoor zorgt dat de huidige persoon niet diegene is die de oproep al eens afgewezen heeft. De
persoon moet ook de status ‘Free’ hebben en mag dus niet bezig zijn met het beantwoorden van een
andere oproep. [18] Tenslotte wordt de locatie van de oproep nog opgevraagd uit de ontologie en
wordt er gecontroleerd of de persoon zich dichtbij deze locatie bevindt. De definitie van dichtbij kan
afzonderlijk vastgelegd worden in de ontologie. Wanneer al deze voorwaarden vervuld zijn voor een
bepaalde persoon p en een bepaalde oproep c, wordt de functie ‘assignCall(?c, ?p)’
opgeroepen die ervoor zorgt dat deze oproep in de ontologie wordt toegewezen aan die bepaalde
persoon en de oproep dus kenbaar gemaakt wordt aan die persoon door het systeem. [18]
Page 52
28
Fragment 1: Jena regel 202
3.3. FlexScript regels
Als simulatiesoftware is zoals eerder beschreven FlexSim uitgekozen. Zowel voor het programmeren
van alle functionaliteiten als voor het neerschrijven van de volledige regelset wordt de
gespecialiseerde programmeertaal FlexScript gebruikt. FlexScript is eigen aan FlexSim en is gebaseerd
op de alom bekende C++ programmeertaal. [51] In deze talen wordt er in tegenstelling tot de regels
in Jena, wel veel gebruik gemaakt van ‘else’ en ‘else if’ commando’s, waardoor de volledige
regelset veel compacter kan neergeschreven worden.
Wanneer exact dezelfde functionaliteit van bovenstaande Jena regel uit Fragment 1 in FlexScript
moet geïmplementeerd worden, moet de regel uit Fragment 2 gedefinieerd worden. Er werd
getracht in de simulatie met dezelfde verwijzingen als in de ontologie te werken, zodat een
eventuele automatische vertaaltool gemakkelijk de link tussen overeenkomende functies en labels
kan leggen. De commando’s die in deze regel gebruikt worden, zijn niet altijd even duidelijk als bij
voorgaande Jena regel omdat voor het definiëren van sommige functies uit de ontologie meerdere
lijnen nodig zijn. Een voorbeeld van zo’n veelgebruikt commando is ‘comparetext’, dat nagaat of
twee teksten gelijk zijn. Hiermee wordt vaak de inhoud van een bepaald tekstlabel vergeleken met
een vooropgesteld stuk tekst. Zo wordt er op de derde lijn van de regel bijvoorbeeld gecontroleerd of
het label ‘CallType’ van het ‘item’ gelijk is aan ‘Medical’. Zoals later zal verduidelijkt worden, is het
‘item’ de functionele voorstelling van een oproep in de FlexSim simulatie. Hier wordt dus de vraag
gesteld of de gelanceerde oproep wel degelijk een medische reden heeft.
De for-lus op de vijfde lijn wordt in elke regel gebruikt net voor de zorgverleners aangesproken
worden. In de FlexScript programmeertaal is deze lus nodig aangezien er hier geen gebruik gemaakt
Page 53
29
wordt van een redeneertool die automatisch alle mogelijke combinaties overloopt zoals in de
ontologie. De for-structuur in deze regel zorgt er dus voor dat de software voor elke zorgverlener
afzonderlijk alle daaropvolgende commando’s controleert. Het stuk code uit fragment 2 voert de
functie ‘settablenum(“FSM”,i,COL,1);’ voor deze zorgverlener enkel uit wanneer er aan
alle voorwaarden, die uitgedrukt zijn in de if-commando’s, voldaan is. Deze functie zal ervoor zorgen
dat er in de tabel van de beschikbare zorgverleners het getal ‘1’ naast de naam van de
corresponderende zorgverlener komt te staan. Over het gebruik van deze tabel volgt later een
uitgebreidere uitleg in 4.2. Hier volstaat het te weten dat dit door de simulatie geïnterpreteerd wordt
als het beschikbaar maken van deze zorgverlener voor de desbetreffende oproep. Door het gebruik
van deze structuren wordt de functionaliteit voor het nagaan van de regels van de redeneertool uit
de ontologie het best nagebootst.
Fragment 2: FlexScript regel 202
3.4. FlexScript – C++
De gebruiker van FlexSim heeft de keuze tussen twee programmeertalen voor de implementatie,
namelijk FlexScript en C++. De volledige opbouw van het simulatiemodel gebeurde in FlexScript
omdat er in deze taal gebruik gemaakt wordt van bepaalde commando’s die zeer specifieke FlexSim
functies definiëren. [37] Deze functies bestaan niet standaard in elke C++ applicatie en moeten dus
eerst vooraf apart gedefinieerd worden indien er in een C++ editor zoals bijvoorbeeld Microsoft
Visual Studio [55] geprogrammeerd wordt. Op het vlak van syntax zijn er quasi geen verschillen
tussen beide talen, FlexScript kan dan ook gezien worden als een taal die rechtstreeks afstamt van
C++ en speciaal voor het gebruik van FlexSim uitgebreid werd. Dit kon makkelijk gecontroleerd
worden door een FlexScript regel uit de gebruikte regelset in het programma Visual Studio C++ 2008
uit te voeren. Alle gegenereerde foutmeldingen verwijzen naar uitdrukkingen die in een afzonderlijke
C++ applicatie niet herkend worden, maar in FlexScript wel standaard gedefinieerd zijn. De
Page 54
30
foutmelding is dus altijd in de aard van ‘identifier not found’. Een voorbeeld hiervan is
‘treenode’, een veelgebruikt datatype in FlexScript dat een nieuw element aanmaakt in het model.
Elk model wordt in FlexSim immers voorgesteld door middel van een boomstructuur, waarbij elk
element van het model geïmplementeerd is als een knoop van de boom, vandaar ‘treenode’. [52] Dit
datatype wordt in een standaard C++ applicatie niet herkend en moet dus vooraf gedefinieerd
worden. Hoewel het doorgeven van tekstparameters in C++ standaard wel mogelijk is, kunnen in
FlexSim enkel numerieke parameters doorgegeven worden wanneer er in C++ geprogrammeerd
wordt.
Aangezien de regelset vanuit de ontologie in FlexSim moet geïmplementeerd worden via een
automatische vertaling, zou een vertaling van Jena naar FlexScript dus voldoende moeten zijn voor
deze toepassing alleen. Wanneer er een correcte vertaling naar C++ zou kunnen verzorgd worden,
zou FlexSim nog steeds op exact dezelfde manier functioneren als bij FlexScript. De vertaling zou in
dat geval wel al een stuk nuttiger worden, aangezien ze ook voor andere toepassingen gebruikt kan
worden. In wat volgt wordt er verder op zoek gegaan naar de mogelijkheden voor een zo generiek
mogelijke vertalingsmethode.
3.5. Introductie van RIF
De oorspronkelijke regelset wordt uit de ontologie gehaald als een uitgebreide set van Jena regels.
Die Jena regels worden tegenwoordig niet meer zo frequent gebruikt omdat, hoewel Jena en
Resource Description Framework (RDF) nog steeds een goede combinatie vormen, Jena en OWL
minder goed samengaan omwille van een discrepantie tussen de RDF en OWL filosofie. Om die reden
is het zeer waarschijnlijk dat een vertaaltool startende van deze taal niet zo nuttig zal blijken in de
toekomst. Er werd dus gezocht naar een formaat dat veel uitgebreidere mogelijkheden heeft maar
toch een gelijkaardige structuur heeft als de Jena regels. Dit formaat zou dan als tussenstap kunnen
gebruikt worden in de vertaling, zodat de vertaling tussen dit formaat en FlexScript/C++ wel nog
nuttig kan zijn in de toekomst. Een formaat dat aan al deze eigenschappen voldoet en op zich ook
geconstrueerd is met als doel de interoperabiliteit tussen talen te verbeteren, bleek het Rule
Interchange Format (RIF) [54].
RIF is een standaard die recent werd ontwikkeld door het W3C [25] om de integratie van regelsets en
de synthese ervan te vergemakkelijken. Het bestaat uit een set van onderling verbonden dialecten
die op hun beurt elk een taal met verschillende functies voorstellen. Het is vooral gericht op de
uitwisseling van regels tussen die verschillende dialecten, die allemaal een groot deel van de
semantiek gemeenschappelijk hebben, net om die uitwisseling te vereenvoudigen. [56] De dialecten
Page 55
31
worden dan ontwikkeld door gebruikers die extra parameters definiëren om het formaat volledig aan
te passen aan de noden van hun specifieke toepassing. Het is dus mogelijk om van elk bestaand
dialect een extensie te maken met eigen functies en parameters naar keuze. Regels kunnen dan
gemakkelijk van het ene dialect naar het andere vertaald worden door de grote gelijkenissen in
structuur en functies. Het voordeel van dit formaat is dat de grote toepasbaarheid ervan ervoor zorgt
dat er al veel syntactische mappings bekend zijn naar andere programmeertalen. De syntax van RIF is
gelijkaardig aan de XML syntax en heeft ook structurele gelijkenissen met de Jena regels. [56]
Aangezien er vanuit W3C al veel onderzoek werd uitgevoerd naar de link met ontologieën en OWL
[24], werd beslist dat de vertaling van de Jena regels naar RIF als gekend mag beschouwd worden. De
automatische vertaaltool die moet ontworpen worden moet dus enkel voor de rechtstreekse
vertaling zorgen van de regels in RIF naar de regels in FlexScript/C++.
De subset met de Jena regels moest dus eerst volledig handmatig vertaald worden naar RIF,
vooraleer deze als startpunt van de vertaaltool kon dienen. Alle aanwijzingen omtrent het geldig
opstellen van regels in RIF zijn terug te vinden in de RIF Primer op de website van het W3C. [54] De
Jena regels werden één voor één vertaald naar RIF en telkens gecontroleerd door gebruik te maken
van een online RIF validator [57].
Opnieuw wordt dezelfde regel 202 uit de regelset van de ontologie gebruikt om de algemene
structuur van dit formaat aan te tonen. In Fragment 3 is te zien hoe deze functionaliteit wordt
uitgedrukt in RIF. Een RIF bestand wordt altijd gestart met ‘Document()’ en vervolgens de lijst met de
gebruikte Uniform Resource Identifiers (URIs). Alle functies en constanten die in het document
gebruikt worden, moeten kunnen teruggevonden worden via het bijhorende unieke webadres of
URI. Op die manier is elke functie en elke constante ondubbelzinnig vastgelegd. Dit is immers de
basisfilosofie van ontologieën. Door gebruik te maken van namespaces, moet er in de regel niet
telkens teruggegrepen worden naar de webpagina, maar kan een verkorte verwijzing naar de URI
gebruikt worden zoals bijvoorbeeld ‘upperAccio’, die, ter illustratie, verwijst naar de URI:
‘http://occs.intec.ugent.be/ontology/UpperAccio.owl’. Wanneer er gerefereerd
wordt aan de URI ‘rdf’, wil dat zeggen dat het om een algemene functie gaat die standaard in het RIF
dialect geïmplementeerd is. Een voorbeeld daarvan is het commando ‘rdf:notEqual()’, dat
simpelweg nagaat of de ingevoerde variabelen wel degelijk verschillend zijn. De functie ‘Group()’
zorgt ervoor dat alle regels van de regelset gegroepeerd worden binnen het RIF document. Dit is
vooral om het document zo georganiseerd en gestructureerd mogelijk te houden. Binnen een
document kunnen meerdere groepen regels gedefinieerd worden, binnen zo een groep regels begint
elke regel in deze regelset met de ‘ForAll()’ functie.
Page 56
32
Zoals eerder beschreven werkt RIF op een gelijkaardige manier als de redeneertool van de ontologie.
Na de functie ‘ForAll()’ worden alle variabelen die in de regel gebruikt worden, gedefinieerd door
middel van een vraagteken en een naam. Deze functie zorgt ervoor dat alle mogelijke combinaties
van deze variabelen gecontroleerd worden en er geen enkel geval over het hoofd gezien wordt. In de
syntax van RIF wordt B :- A gebruikt voor het definiëren van het commando ‘Als A dan B’. De
‘And()’ functie spreekt voor zich en eist dat alle voorwaarden die gesteld worden binnen deze
‘And()’ voldaan zijn vooraleer er een positief resultaat teruggegeven wordt.
De functie die moet uitgevoerd worden in deze regel is dus het toewijzen van een oproep aan een
zorgverlener door middel van ‘taskAccio:assignedTo(?Person ?Call)’. De voorwaarden
waaraan de oproep en de zorgverlener daarvoor moeten voldoen zijn terug te vinden binnen de
‘And()‘ functie. Het gaat hierbij uiteraard om dezelfde voorwaarden die reeds zijn uitgelegd voor de
regel in de andere formaten.
Fragment 3: RIF regel 202
3.6. Automatisering van de vertaling Jena – FlexScript
Zoals eerder aangehaald is het uiteindelijk doel van dit deel van het onderzoek om een automatische
vertaling te verzorgen tussen RIF en de programmeertaal van de simulatiesoftware. Het gaat hier om
een vertaling tussen twee totaal verschillende programmeertalen met elk hun eigen structuur en
commando’s. Het uiteindelijke opzet is het ontwerp van een programma dat met input van een
Page 57
33
regelset in RIF als output deze regelset in FlexScript genereert. Er wordt dus een tekstbestand met
één RIF regelset waarin alle regels samen gegroepeerd zijn, ingeladen in de vertaaltool, die op zijn
beurt een tekstbestand creëert met alle vertaalde regels. Ook de vaste hoofding van de regelset in
FlexScript moet in het tekstbestand erbij genomen worden zodat de output rechtstreeks in de
FlexSim software kan ingevoerd worden.
Regels uit de ontologie bestuderen elke mogelijke combinatie van opgegeven variabelen en voeren
de bijhorende functie pas uit als aan alle voorwaarden voldaan is; het kan zoals beschreven gezien
worden als een geneste if-structuur zonder de 'else' commando's. De redeneertool van de
ontologie is ook zo ontworpen dat er snel gezien wordt welke regels kunnen overgeslagen worden
omdat de voorwaarden niet voldaan zijn. In FlexScript wordt er slechts één structuur, één regelset
geprogrammeerd die per oproep eenmaal overlopen wordt en afhankelijk van de huidige situatie de
juiste actie onderneemt. Hier is een automatische redeneertool niet beschikbaar, maar wordt er
handmatig met behulp van for-lussen voor gezorgd dat alle mogelijke situaties geanalyseerd worden.
Een omzetting van RIF naar Flexscript zou dus in het ideale geval alle mogelijke regels moeten
combineren in één grote regel met ‘if’ en ‘else’ commando’s voor de simulatiesoftware. Aangezien
niet alle regels uit de ontologie beschikbaar zijn, maar slechts een beperkte subset, werd er beslist
om de vertaaltool zo te ontwerpen dat elke regel volledig apart wordt vertaald naar FlexScript. Op
deze manier zal de uiteindelijke regelset een totaal verschillende globale structuur hebben en niet zo
overzichtelijk zijn door de vele if-structuren. Maar zolang alle mogelijke gevallen in de regels uit de
ontologie beschreven zijn, zal deze regelset op exact dezelfde manier functioneren.
Door het grote verschil in structuur tussen beide programmeertalen ligt het ontwerp van een volledig
generieke vertaaltool buiten het bereik van deze thesis. Ook zijn er geen andere gelijkaardige
toepassingen voorhanden waarmee de vertaaltool zou kunnen getest worden. Er werd dus
afgesproken dat de tool in dit geval toepassingsgericht mocht zijn, elke mogelijke regel uit de
ontologie van het verplegersoproepsysteem moet kunnen vertaald worden, maar uitbreidingen naar
andere domeinen zijn niet vereist.
Er werd bij de start van het ontwerp dus van uitgegaan dat de koppeling tussen de Jena regels en RIF
gekend is en de regelset dus altijd automatisch in RIF beschikbaar zal zijn. Het startpunt was het
document met de handmatig vertaalde regels uit de ontologie in RIF. Daaruit werden eerst de regels
gefilterd die geen toepassing hebben in het model. Het betrof vooral de regels met betrekking tot de
automatische contextoproepen, waarbij het systeem in bepaalde situaties zelf een oproep lanceert,
bijvoorbeeld na registratie van ongewenste bloedwaarden bij de patiënt.
Page 58
34
In dat RIF document kunnen drie klassen van regels onderscheiden worden. Het gaat hier maar om
een kleine subset van alle RIF regels vanuit de ontologie, maar toch kan ook de rest van de regels in
één van de drie klassen onderverdeeld worden. Vooreerst zijn er de regels die de status van de
personeelsleden aanpassen in ‘Free’, ’Busy’ of ‘withPatient’ naargelang hun activiteit op dat
moment. [8] Vervolgens zijn er de regels die de status van een oproep kunnen wijzigen, zoals
‘acceptCall’ en ‘finishCall’. Deze zullen ervoor zorgen dat de ontologie registreert wanneer een
zorgverlener een oproep accepteert of beëindigt. Tenslotte is er dan nog de grootste categorie regels
waarbij de ontologie beslist wanneer ze een bepaalde oproep toewijst aan een bepaalde
zorgverlener. De structuren van deze drie categorieën verschillen onderling licht en uiteraard moet
de vertaaltool correct functioneren voor alle drie de soorten.
Op basis van deze drie klassen werd de tool dan ook opgebouwd en gecontroleerd. Eerst werden all
regels uit de gegeven subset van regels van de ontologie (‘rulesAllScenes.txt’) handmatig vertaald
naar FlexScript, om eenvoudig de output te kunnen controleren. Acht RIF regels werden gebruikt als
basis om de tool op te stellen, en de overige 63 regels uit de subset werden gebruikt om de werking
te verifiëren. Van de acht initiële regels waren er vier van de eerste klasse, die de status van een
zorgverlener wijzigen, en twee van elke andere klasse.
Er werd besloten om de vertaaltool te ontwerpen in de Python programmeertaal vanwege de
eenvoudige methode die voorhanden is om tekstbestanden in te lezen en op te stellen. Met behulp
van de ‘fileHandler’ wordt de regelset in RIF lijn per lijn ingelezen. Aan de hand van
herkenningspunten in de lijn wordt dan achterhaald om welke soort commando’s het gaat. Om de
vertaaltool zo generiek mogelijk te maken wordt er op elke lijn van de regel achterhaald om welk
label het gaat en wordt er aan de hand van dat label en nog andere herkenningspunten, zoals een
dubbele punt of een vraagteken, een vertaling gegenereerd voor de lijn. Die herkenningspunten
worden meestal gedefinieerd onder de vorm van leestekens of vaste termen zoals ‘Document’. In
een RIF regel uit de ontologie is een label altijd terug te vinden in een lijn waar maar één vraagteken
staat en op de tweede plaats binnen de functie van die lijn. De URI wordt niet bij het label
inbegrepen. Uit onderstaand voorbeeld kan achterhaald worden dat er een zorgverlener gezocht
wordt met status ‘withPatient’.
upperAccio:hasStatus(?Person profileAccio:withPatient)
Elke lijn van de regel wordt dus apart bestudeerd en door middel van een gevallenstudie wordt er
gezocht om welke regel het gaat. Wanneer het programma bijvoorbeeld de term ‘Document’ ontdekt
in de lijn, is er geweten dat het om de eerste lijn van een RIF regelset gaat, waardoor de
Page 59
35
noodzakelijke hoofding voor een FlexScript regel wordt uitgetypt in het outputbestand. Telkens er
‘ForAll’ wordt ingelezen, registreert de vertaaltool dat het om een nieuwe regel gaat binnen dezelfde
groep en dat de volgende lijn de opdracht van de functie zal inhouden. Door de drie verschillende
klassen van regels zijn er ook drie verschillende functies of opdrachten die kunnen voorkomen. In
Fragment 4 is te zien hoe de vertaaltool de lijn analyseert, bepaalt om welk soort regel het gaat en
tenslotte de correcte vertaling opslaat onder de variabele ‘action’. Die variabele wordt dan na het
neerschrijven van alle voorwaarden op het einde van de FlexScript output geplaatst.
Fragment 4: Paragraaf uit de automatische Python vertaaltool
Door het verschil in structuur tussen de formaten, zijn er ook delen van de regel die niet rechtstreeks
moeten vertaald worden naar FlexScript. Het gaat om het verschil in het aanspreken van de
variabelen. In RIF zijn bijvoorbeeld onderstaande twee regels nodig om na te gaan of die bepaalde
persoon de rol van zorgverlener heeft. Op de eerste lijn wordt de variabele ?Role opgevraagd door
na te gaan welke rol die bepaalde persoon heeft en pas daarna wordt nagegaan of die variabele gelijk
is aan de rol van zorgverlener.
profileAccio:hasRole(?Person ?Role)
rdf:type(?Role roleCompetenceAccio:StaffMember)
In FlexScript kan dezelfde functionaliteit in één lijn uitgeschreven worden, zoals hieronder te zien is.
Dit wordt in de vertaaltool opgelost door de eerste lijn hierboven buiten beschouwing te laten,
aangezien deze dus geen toegevoegde waarde levert in FlexScript.
comparetext(getlabelstr(TE,"Role"),"StaffMember").
Zoals eerder beschreven probeert de redeneertool automatisch alle mogelijke combinaties uit en is
dit in FlexScript niet het geval. In elke regel van de output is een for-lus over alle zorgverleners
Page 60
36
daarom zeker vereist. De vertaaltool registreert daarom op welke lijn er in de RIF regel voor de
eerste maal een zorgverlener wordt aangesproken en schrijft op dat moment de start van die for-lus
neer in het outputbestand, zodat al de volgende voorwaarden binnen deze lus zitten en dus
gecontroleerd worden voor alle zorgverleners. Het volledige Python script en een handleiding om het
te gebruiken zijn terug te vinden op de CD die aan deze thesis bijgevoegd werd. Een overzicht van
alle documenten op deze CD is gegeven in bijlage 11.5.
Page 61
37
4. Modelopbouw
4.1. Inleiding van de werkwijze en inleiding op FlexSim
Zoals eerder vermeld werd FlexSim uitgekozen als discrete event simulator om de simulaties van het
verpleegoproepsysteem uit te voeren. De bedoeling is om de werking van de simulatie zo nauw
mogelijk te laten aansluiten bij de realiteit, onder andere door het inplannen van verplegersrondes,
shiftwissels en het samenstellen van een realistisch patiënten- en personeelsbestand. Ook de lay-out
van de departementen die gesimuleerd worden zijn gebaseerd op plattegronden van bestaande
departementen.
Er werd begonnen met het bouwen van een simulatie op kleine schaal met vier kamers en drie
personeelsleden om de functionaliteiten van het systeem sneller te kunnen testen. De structuur van
dit klein testdepartement is weergegeven in Figuur 8. FlexSim wordt voornamelijk gebruikt voor het
simuleren van industriële processen waardoor de werking van een zorginstelling in dit model moest
benaderd worden door het gebruik van typische industriële elementen. Deze vergelijking is
voorgesteld op Figuur 9 en Figuur 10. Een patiënt in een bed wordt in het model gesimuleerd door
een machine, in FlexSim een ‘Processor’ genaamd, die op bepaalde tijdstippen pakketjes ontvangt
om te verwerken. Deze pakketjes stellen de oproepen (‘Calls’) voor en moeten door één of twee
werknemers (‘Operators’) verwerkt worden. Welke werknemer verantwoordelijk is voor de
behandeling van dat pakketje wordt beslist door de ‘Dispatcher’. De ‘Dispatcher’ in FlexSim stelt het
beslissingsorgaan voor van de ontologie met daarin de volledige regelset. Deze regelset is
gedefinieerd als een beslissingsboom die uiteindelijk één of meerdere werknemers toewijst aan een
oproep. Deze beslissingsboom is terug te vinden in bijlage 11.3. De oproepen zijn afkomstig van de
‘Source’, de ‘Event generator’ van FlexSim, die de willekeurigheid van de patiënt die op het knopje
drukt voorstelt. In deze ‘Source’ wordt voor de simulatie het Excel document ingeladen waarin alle
oproepen met alle bijhorende details op voorhand gedefinieerd zijn, waaronder ook het tijdstip van
versturen. Over de opbouw van dit Excel document wordt in Hoofdstuk 6 meer duidelijkheid
geschept. Wanneer twee werknemers of zorgverleners nodig zijn voor de verwerking, wordt dat
geklasseerd als een assistentieoproep, gelanceerd door de eerste zorgverlener die op dat moment al
aan het bed is toegekomen en merkt dat hij de oproep niet alleen kan behandelen. Wanneer de
oproep afgehandeld is, wordt het corresponderende pakketje verstuurd van de machine naar de
‘Sink’, waar alle afgehandelde oproepen van dat bed verzameld worden.
Page 62
38
Figuur 8: Testdepartement op kleine schaal in FlexSim
Figuur 9: Voorstelling van een industrieel proces in FlexSim
Figuur 10: Voorstelling van een zorgproces in FlexSim
Dit systeem om oproepen te simuleren wordt zowel toegepast in bezette kamers als in publieke
plaatsen zoals de cafetaria of de sanitaire voorzieningen. Voor de simulaties op kleine schaal werd er
op basis van realistische data van Televic [7] een Poissonverdeling opgesteld waaraan het toekomen
van de oproepen moet voldoen. De oorzaak van die oproepen en het type patiënt dat de oproep
lanceerde werd telkens random bepaald, om de diversiteit ondanks het kleine aantal bedden hoog
genoeg te houden. In latere simulaties op grotere schaal is het de bedoeling ervoor te zorgen dat
dezelfde patiënt gedurende de hele simulatieperiode in hetzelfde bed blijft liggen, omdat het
verpleegoproepsysteem vooral op het vlak van continue zorg verbeteringen moet bieden.
Page 63
39
De code die ervoor zorgt dat het model de werking van een realistisch ziekenhuisdepartement
benadert, staat verdeeld over alle belangrijke elementen in de simulatie. Elk element, waarmee
bijvoorbeeld een machine of een processor bedoeld wordt, moet immers als een puzzelstuk in het
volledige model passen en moet bijgevolg ook voor een deel apart aangestuurd worden. Het draait
hier vooral om wat er gebeurt als er een oproep gelanceerd wordt door een patiënt, hoe het systeem
reageert als een zorgverlener wordt uitgekozen enzovoort. Deze stukken code zijn inbegrepen in de
standaardelementen van de zelfopgebouwde bibliotheek die in paragraaf 4.3. volledig zal uitgelegd
worden. Het komt erop neer dat deze code bij de bouw van een nieuw model al standaard zal
geïmplementeerd zijn. Ze heeft ook geen invloed op de regelset van het algoritme maar zorgt dus
enkel voor de werking van het model.
Deze regelset is de belangrijkste code voor deze thesis en wordt apart geprogrammeerd in de
‘Dispatcher’. Dit beslissingsalgoritme is volledig losgekoppeld van de rest van de simulatie en kan dus
gemakkelijk apart gemanipuleerd worden, wat ook het doel is van dit onderzoek. Bij elke
(assistentie)oproep van een patiënt wordt een signaal naar de ‘Dispatcher’ gestuurd, die op zijn beurt
op basis van de geprogrammeerde regelset de juiste zorgverlener(s) uitkiest om de
(assistentie)oproep te beantwoorden. Dit is schematisch voorgesteld op Figuur 11. Deze zorgverlener
kan de oproep dan accepteren, afwijzen of negeren. De desbetreffende regelset is zoals beschreven
volledig gebaseerd op de beslissingsboom uit de ontologie. De volledige beslissingsboom is terug te
vinden in bijlage 11.3. In de simulatie op kleine schaal werd deze boom stap voor stap
geïmplementeerd, van boven naar onder, waarbij elke stap eerst afzonderlijk getest werd.
Figuur 11: Overzicht van de werking van het verpleegoproepsysteem
Page 64
40
4.2. Gedetailleerde uitleg van de volledige huidige regelset +
implementatie
Zoals eerder aangehaald wordt de regelset in de ontologie voorgesteld door een beslissingsboom.
Deze beslissingsboom bestaat uit enkele belangrijke onderdelen, die in de volgende paragrafen elk
apart verduidelijkt zullen worden, samen met hun specifieke implementatiewijze in FlexSim en ook
teruggevonden kunnen worden in de beslissingsboom in bijlage 11.3. Deze boom in bijlage bevat
enkel de delen die effectief geïmplementeerd zijn in het model, de volledige oorspronkelijke boom
kan teruggevonden worden in het eerder vermelde doctoraat van dr. ir. F. Ongenae. [18]
Een overzicht van hoe het systeem precies in zijn werk gaat is zoals beschreven terug te vinden op
Figuur 11. Wanneer de patiënt een zorgverlener nodig heeft, lanceert hij een oproep naar de
‘Dispatcher’ via een druk op het toestel in de kamer. Hierop stelt deze een lijst op van alle
personeelsleden met een verzorgende functie die op dat moment aan het werk zijn, de ‘Filtered Staff
Members’ genaamd. Deze lijst wordt na elke knoop in de boom aangepast tot er slechts één
zorgverlener in de lijst overblijft of tot de laatste knoop bereikt is. Indien er na het doorlopen van de
volledige beslissingsboom nog meerdere zorgverleners in de lijst overblijven, wordt de oproep naar
al deze zorgverleners verstuurd. Dit systeem is ook van kracht wanneer een zorgverlener assistentie
vraagt via zijn mobiele toestel.
4.2.1. Type oproep
De belangrijkste en eerste vraag die gesteld wordt in de beslissingsboom is of het om een
urgentieoproep gaat of niet. Indien dit het geval is, wordt de noodprocedure opgestart en worden
alle personeelsleden onmiddellijk opgeroepen via hun toestel met de mededeling dat het om een
urgentiegeval gaat en ze zich zo snel mogelijk naar die patiënt moeten begeven. Er is beslist om dit
geval niet in de simulatie te betrekken, aangezien het zelden voorkomt en er weinig aan kan
geoptimaliseerd worden.
In het volgende deel van de beslissingsboom wil de dispatcher achterhalen wie de oproep gelanceerd
heeft. Gaat het om een zorgverlener, een patiënt of geen van beide? Indien de oproep afkomstig is
van een patiënt, wordt deze geclassificeerd als normale oproep (‘Normal Call’). Werd ze verstuurd
door een zorgverlener, dan gaat het om een assistentieoproep (‘Assistance Call’) en wordt er
nagegaan of er op dit moment meer dan één zorgverlener in de lijst ‘Filtered Staff Members’ staat.
Als er slechts één zorgverlener aan het werk is, komt de assistentieoproep van deze ene persoon en
kan er niemand uitgekozen worden om assistentie te verlenen. Deze situatie is uitgesloten in de
Page 65
41
FlexSim simulatie, aangezien het huidige verpleegoproepsysteem hiervoor (nog) geen oplossing
heeft. Een mogelijke oplossing, die evenwel niet gesimuleerd werd, zou de automatische connectie
met andere departementen zijn, waarbij de zorgverlener die assistentie nodig heeft, rechtstreeks
contact kan opnemen met zorgverleners van deze naburige departementen. Bij het versturen van
een assistentieoproep bevat de lijst met ‘Filtered Staff Members’ dus altijd nog minimum twee
zorgverleners zodat de zorgverlener, die de assistentieoproep gelanceerd heeft, eruit verwijderd kan
worden. Indien de oproep noch van een patiënt noch van een zorgverlener afkomstig is, gaat het om
een contextoproep (‘Context Call’), een automatische oproep van het systeem omdat de
geregistreerde waarden van een sensor aan het bed van een patiënt afwijken van de normale
waarden. Het kan hier gaan om een te hoge bloeddruk, een te hoge of te lage hartslag, koorts of
andere onregelmatigheden. Er werd beslist om in de simulatie geen onderscheid te maken tussen
contextoproepen en normale oproepen en alle oproepen als normale oproep (‘Normal Call’) te
klasseren.
4.2.2. Oorzaak
Nu de oorsprong van de oproep achterhaald is, gaat men op zoek naar de oorzaak van de oproep.
Wanneer de oproep voor de eerste keer uitgestuurd wordt, is er geen verdere informatie
beschikbaar over de reden en wordt dit volledige deel van de beslissingsboom niet in beschouwing
genomen. Pas als een andere zorgverlener de oproep eerder al afgewezen heeft en daarbij de reden
van de oproep toegevoegd heeft, wordt dit deel van de boom aangesproken. Deze situatie doet zich
meestal voor wanneer de zorgverlener die de oproep als eerste kreeg een telefonisch of rechtstreeks
gesprek met de patiënt gevoerd heeft over de reden van de oproep. Het is ook mogelijk dat er na
rechtstreeks contact met de patiënt nog altijd geen duidelijke reden bekend is, dan wordt de oproep
geclassificeerd als ‘NoReason’ en kan elke zorgverlener uitgekozen worden om te assisteren.
‘NoReason’ betekent dus niet per se dat er geen reden aan de oproep gekoppeld is, maar deze term
wordt zo in de ontologie gebruikt en zal in dit verslag ook zo verder gebruikt worden.
De oorzaak kan onderverdeeld worden in één van de volgende vier categorieën: Hotel (‘Hotel’), Zorg
(‘Care’), Medisch (‘Medical’) en Geen reden (‘NoReason’). In de ontologie is nog een vijfde categorie
van oproepen gedefinieerd, namelijk de oproepen waarvoor de tussenkomst van een dokter
noodzakelijk is (‘Doctor needed’), maar aangezien over deze oproepen geen data beschikbaar is en
de belangrijkste optimalisatie op de verpleegkundigen en zorgverleners gericht is, werden dit soort
oproepen buiten beschouwing gelaten in het model. De eerste categorie, een hoteloproep, kan door
iedereen beantwoord worden en gaat om eenvoudige zaken zoals bijvoorbeeld de vraag naar een
fles water. Het is niet nodig om voor dit soort opdrachten gekwalificeerde verplegers op te roepen.
Page 66
42
Voor het beantwoorden van een zorgoproep, waarbij een patiënt bijvoorbeeld nood heeft aan
sanitaire assistentie, is er een zorgverlener met enige kwalificaties vereist maar geen
verpleger/verpleegster met een specifiek diploma zoals dat wel het geval is bij een medische oproep.
4.2.3. Competenties
Op dit moment is de oorzaak van de oproep bekend, zodat er kan gezocht worden naar aanwezige
zorgverleners met de vereiste competenties om deze oproep te beantwoorden. Elk personeelslid
krijgt een rol toegewezen, zo zijn er bijvoorbeeld: dokter, verpleger, logistiek medewerker, assistent,
hoofdverpleger enzovoort. Eerst wordt er nagegaan of er op de lijst zorgverleners aanwezig zijn met
een rol die de vereiste competentie als hoofdcompetentie heeft. Is dit niet het geval dan wordt er
vervolgens gekeken naar hun formele trainingscompetenties. Om deze te behalen moet de
zorgverlener een officiële opleiding gevolgd hebben. Uit noodzaak kan er eventueel nog gekozen
worden uit zorgverleners die de vereiste competentie uit ervaring hebben, maar dit wordt zoveel
mogelijk vermeden. In dit laatste geval heeft de zorgverlener niet de juiste opleiding gevolgd en is
bijgevolg niet in het bezit van het correcte diploma. In theorie mogen deze personen deze patiënt
dus niet assisteren, hoewel daar in de praktijk vaak geen rekening mee gehouden wordt.
De boom wordt verder gecontroleerd met de overblijvende zorgverleners met de correcte
competenties in de lijst met ‘Filtered Staff Members’. Als er na het overlopen van de tak met de
oorzaak van de oproep slechts één zorgverlener op de lijst overblijft, wordt de oproep altijd aan deze
zorgverlener toegewezen, onafhankelijk van zijn status op dat moment. Is er geen enkele
zorgverlener met de vereiste competenties aanwezig, dan wordt dit deel van de boom buiten
beschouwing gelaten en wordt er verder gegaan met de ‘Filtered Staff Members’ die nog beschikbaar
waren vooraleer dit deel van de beslissingsboom aangesproken werd.
4.2.4. Prioriteit
Voor het verdere verloop van de boom moet de huidige status van alle overblijvende zorgverleners
gekend zijn. In de ontologie zijn er drie verschillende statussen gedefinieerd: ‘Free’, ‘withPatient’ en
‘Busy’. Als de zorgverlener ingelogd is in een kamer en dus bezig is met een specifieke taak om de
patiënt te helpen, dan krijgt hij de status ‘Busy’ toegewezen. Als hij zich daarentegen bevindt in een
kamer waar een patiënt aanwezig is, maar niet ingelogd is in de kamer, krijgt hij de status
‘withPatient’. Dit is een status die eerder weinig zal voorkomen, aangezien de zorgverlener voor de
meeste opdrachten zal inloggen in de kamer. In alle andere gevallen wordt de status ‘Free’
toegewezen aan de zorgverlener.
Page 67
43
De volgende kleine stap in de boom betreft de prioriteit van de oproep. Elke oproep die niet
geclassificeerd wordt als urgentieoproep krijgt een normale prioriteit (‘Normal Priority’). Een oproep
die afgewezen wordt door een zorgverlener en opnieuw verstuurd wordt naar de ‘Dispatcher’ kan
wel uitzonderlijk de prioriteit dringend (‘Urgent’) krijgen als dat meegegeven wordt tijdens het
afwijzen. Dit laatste geval werd buiten beschouwing gelaten in de simulatie.
Indien de prioriteit bekend is en gelijk is aan de normale prioriteit wordt in de volgende stap
achterhaald van wie de oproep afkomstig is door middel van een aparte beslissingsboom. [18] Deze
boom wordt hier niet verder uitgediept aangezien er in het model altijd vanuit gegaan wordt dat
bekend is wie de oproep gelanceerd. Bij assistentieoproepen wordt er ook nagegaan welke patiënt
de originele oproep gelanceerd heeft, dat is de oproep waarmee de zorgverlener dus nu mee bezig
is. De contextoproepen, zoals eerder al verduidelijkt, worden ook niet in de simulatie opgenomen,
waardoor een deel van deze aparte beslissingsboom ook buiten beschouwing moet gelaten worden.
4.2.5. Vertrouwensband
Nu het systeem weet wie de patiënt is die assistentie nodig heeft, wordt er in de ‘Filtered Staff
Members’ geselecteerd op basis van de verschillende vertrouwensbanden tussen die patiënt en de
zorgverleners. Voor deze selectie is er eveneens een aparte beslissingsboom [18] opgesteld met als
input de patiënt en de ‘Filtered Staff Members’ en als output de lijst met ‘Filtered Trusted Staff
Members’. In de ontologie zijn twee verschillende vertrouwensrelaties gedefinieerd, zowel de
‘therapeutische vertrouwensband’ als de ‘persoonlijke vertrouwensband’ tussen een zorgverlener en
een patiënt worden in rekening gebracht. Elke zorgverlener die volgens zijn kwalificaties een patiënt
mag behandelen heeft een therapeutische vertrouwensband met alle patiënten. De therapeutische
vertrouwensband is in de simulatie dan ook opgenomen als een binaire variabele die de waarde 1
aanneemt als de zorgverlener een therapeutische band heeft met de patiënten. Op basis van deze
vertrouwensband zullen weinig zorgverleners uitgesloten worden, aangezien het overgrote deel van
de zorgverleners alle patiënten mag behandelen. De persoonlijke vertrouwensband wordt
gedefinieerd door middel van een numerieke waarde tussen 0 en 100 en vertelt iets meer over de
persoonlijke relatie tussen zorgverlener en patiënt. Alle patiënten en zorgverleners krijgen in de
simulatie een vertrouwensgetal van 0 tot 100, waarbij het verschil in deze numerieke waardes de
persoonlijke vertrouwensband tussen zorgverlener en patiënt bepaalt. Hoe kleiner het verschil, hoe
comfortabeler een patiënt zich voelt wanneer hij geholpen wordt door die bepaalde zorgverlener.
De eerste vraag die gesteld wordt in deze aparte beslissingsboom is of er een zorgverlener aanwezig
is die een therapeutische vertrouwensband heeft met de patiënt in kwestie. Is dit het geval, dan
Page 68
44
wordt er nagegaan of er in de lijst van de ‘Filtered Staff Members’ zorgverleners aanwezig zijn die
minstens een bepaalde graad van therapeutische vertrouwensband hebben met de patiënt. Deze
graad van therapeutische vertrouwenband is door het invoeren van de binaire variabele in de
simulatie buiten beschouwing gelaten. Is er niemand met een therapeutische vertrouwensband, dan
wordt er een lege lijst teruggegeven als output en wordt dit deel volledig buiten beschouwing
gelaten in de oorspronkelijke beslissingsboom. Vervolgens wordt er geselecteerd op basis van de
persoonlijke vertrouwensband: zijn er nog zorgverleners aanwezig die een persoonlijke
vertrouwensband hebben met de patiënt die hoger ligt dan de minimale vereiste vertrouwensband?
In de simulatie wordt deze vraag als volgt gesteld: Zijn er zorgverleners waarbij het verschil in
vertrouwensgetal tussen zorgverlener en patiënt kleiner is dan een bepaalde drempelwaarde? Deze
drempelwaarde wordt standaard op 60 genomen, zodat er gemiddeld 85% van de patiënten op een
afdeling een persoonlijke vertrouwensband hebben met een willekeurige zorgverlener. Dit
percentage hangt natuurlijk af van het vertrouwensgetal van de zorgverlener, een zorgverlener met
vertrouwensgetal 50 heeft een persoonlijke vertrouwensband met elke patiënt en kan dus gezien
worden als een ideale werknemer op dat vlak. Een zorgverlener met vertrouwensgetal 0 zal
daarentegen maar met 60% van de patiënten een persoonlijke vertrouwensband opgebouwd
hebben, waardoor deze kan voorgesteld worden als een minder geliefd persoon. Vervolgens wordt
er nog gekeken of er onder deze overblijvende zorgverleners nog zijn die een sterke persoonlijke
vertrouwensband hebben met de patiënt, waarbij een sterke vertrouwensband gedefinieerd wordt
door een lagere drempelwaarde voor het verschil. Standaard wordt deze op 35 genomen zodat
gemiddeld ongeveer 55% van de patiënten deze sterkere band heeft met een willekeurige
zorgverlener. Enkel als er door deze laatste vraag nog gedifferentieerd kan worden tussen de
overblijvende zorgverleners, wordt de ‘Filtered Staff Members’ nog aangepast, anders blijft de lijst
ongewijzigd.
De lijst met zorgverleners die overblijven na het voorbije deel worden de ‘Filtered Trusted Staff
Members’ genoemd. In alle volgende stappen van de boom wordt verder gegaan met deze
aangepaste lijst. Als de lijst uit slechts 1 zorgverlener bestaat, wordt die altijd toegewezen aan de
oproep, ongeacht zijn status op dat moment. Blijft er geen enkele zorgverlener meer over op de lijst,
dan wordt de boom verder overlopen met de lijst van ‘Filtered Staff Members’ die nog beschikbaar
waren voor het aanspreken van de beslissingsboom die gebaseerd is op de vertrouwensband.
Page 69
45
4.2.6. Status en locatie
De volgende stap betreft de locatie van de oproep. Op basis van die locatie gaat het systeem na
welke van de zorgverleners uit de lijst met ‘Filtered Trusted Staff Members’ er in de buurt zijn. Een
zorgverlener wordt zowel in de simulatie als in de ontologie als dichtbij (‘Close’) geclassificeerd als hij
zich binnen een vooraf gedefinieerde afstand van de plaats van de oproep bevindt. De locatie van de
zorgverlener wordt in de ontologie bepaald aan de hand van een persoonlijke zender die door de
detectoren in de afdeling wordt geregistreerd. In de realiteit kan het zijn dat er in het systeem geen
locatie toegekend is aan de oproep aangezien de patiënt zich buiten het bereik van detectoren
bevindt. In dat geval is de laatst waargenomen locatie van de patiënt wel nog altijd beschikbaar in de
ontologie. Om die reden werd er beslist om het geval waarin de locatie niet gekend is niet mee te
nemen in de simulatie. Er wordt in het model dan ook geen onderscheid gemaakt tussen het geval
waarin de huidige locatie bekend is en het geval waarin het om een ‘oude’ locatie gaat.
De laatste selectieprocedure van de beslissingsboom is gebaseerd op de status en de locatie van de
nog overblijvende zorgverleners. Er wordt begonnen met het stellen van de hoogste eis die telkens
wordt afgezwakt als er niemand uit de lijst aan blijkt te voldoen. Eerst wordt er gecontroleerd of er
zorgverleners op de lijst staan die zich dichtbij de oproep bevinden en vrij zijn (‘Close’ + ‘Free’),
vervolgens of er zorgverleners op ronde zijn in de buurt van de oproep (‘Close’ + ‘withPatient’). In de
volgende stappen wordt de eis van het dichtbij zijn weggelaten, om dan daarna in het slechtste geval
ook de ‘Busy’ zorgverleners in rekening te brengen.
4.2.7. Conclusie
Uiteindelijk wordt als output van de beslissingsboom een lijst weergegeven met in het beste geval
één zorgverlener die wordt uitgekozen voor de oproep. Zoals eerder beschreven wordt de oproep
verstuurd naar alle zorgverleners die nog op de lijst overblijven na het doorlopen van de volledige
beslissingsboom. De verschillende delen van de boom zijn ter herhaling op Figuur 12 weergegeven.
Page 70
46
Figuur 12: Verschillende stappen in de huidige beslissingsboom van de ontologie
4.3. Basic Units, uitleg van de bibliotheek
De opbouw van de simulatie bestaat grotendeels uit twee aspecten. Vooreerst de beslissingsboom,
die moet afgestemd worden op de regels uit de ontologie, en daarnaast de simulatie van de
werkelijkheid. De software moet weten wat er te gebeuren staat bij het ontvangen en afhandelen
van een oproep, het starten van een verplegersronde, het ingaan van een nieuwe shift enzovoort.
Voor leidinggevenden is het belangrijk dat ze onbeperkt controle hebben over de beslissingsboom
die bepaalt hoe de software omgaat met een binnenkomende oproep. Het eerste deel kan dus
gezien worden als de ‘Front Office’ van de software, en het tweede deel de ‘Back Office’. Bij het
bouwen van een departement zal de leidinggevende onvermijdelijk ook geconfronteerd worden met
deze ‘Back Office’. Om ervoor te zorgen dat deze persoon zich niet helemaal hoeft in te werken in de
werking van Flexsim, werd ervoor gekozen om ‘Basic Units’ te gebruiken. Dit zijn standaardeenheden
die in de opstelling van een departement kunnen gebruikt worden en waarin alle achterliggende
code reeds geïmplementeerd is. Het gaat hierbij onder andere om kamers, verplegerseenheden,
personeelsleden en uiteraard ook de reeds vermelde ‘Dispatcher’. Ook de vooraf geprogrammeerde
‘User Commands’, zoals bijvoorbeeld de volledige regelset, en andere simulatietools kunnen heel
eenvoudig in een nieuw departement ingeladen worden.
Page 71
47
4.3.1. Kamers
Ten eerste zijn er de één- of tweepersoonskamers die beide voorgesteld worden op Figuur 13Fout!
Verwijzingsbron niet gevonden. en Figuur 14. Deze bestaan uit bedden met elk een knoop
(‘NetworkNode’) aan vastgekoppeld. Die knopen zijn nodig in het model om het bed bereikbaar te
maken voor de personeelsleden en om te kunnen detecteren wanneer een zorgverlener zich aan het
bed bevindt. De knoop die hoort bij het bed is verbonden met de knoop ‘Room’ van die kamer die in
de gang geplaatst is en de toegang tot de kamer voorstelt. In het model zal een zorgverlener elke
keer wanneer hij vanuit een kamer in de gang komt en dus dit soort knoop passeert, nagaan welke
onvoltooide taken hij nog heeft en afhankelijk van de prioriteiten daarvan zijn volgende bestemming
kiezen. Het bed zelf bestaat zoals reeds vermeld uit een ‘Processor’ die visueel omgebouwd is tot een
bed. Die processor is verantwoordelijk voor de differentiatie tussen normale en assistentieoproepen,
voor het oproepen en wegsturen van personeelsleden en voor het opslaan van data, zoals het aantal
keer dat de oproep doorverwezen werd of de wachttijd voor de patiënt.
Figuur 13: Kamer met één bed als Basic Unit
Figuur 14: Kamer met twee bedden als Basic Unit
4.3.2. Openbare plaatsen
De openbare plaatsen, zoals bijvoorbeeld de sanitaire voorzieningen op Figuur 15 zijn zeer
gelijklopend met de kamers. Ze bestaan ook uit een ‘Processor’ met de twee bijhorende knopen (de
‘Network Node’ en de ‘Network Node’ ‘Room’). Het enige verschil zit in de visuele voorstelling van de
‘Processor’. Wanneer er geen oproep gelanceerd is, heeft de ‘Processor’ geen visuele representatie,
waardoor de publieke plaats niet bezet is. Slechts bij het versturen van een oproep vanuit deze plaats
wordt een patiënt weergegeven.
Page 72
48
Figuur 15: Publieke sanitaire voorzieningen als Basic Unit
4.3.3. Verplegerspost
De verplegerspost is de plaats waar verzorgers en verplegers zich bevinden wanneer ze niet bezig zijn
met een taak of bezig zijn met indirecte zorg voor de patiënten zoals bijvoorbeeld de
medicatievoorbereidingen. De ‘HeadNurse’ en de ‘LogisticsAssistant’ hebben een apart kantoor,
respectievelijk Hoofdverplegerspost en Dienstruimte genoemd, waarin dezelfde code ingewerkt is als
bij de verplegerspost. De verplegerspost bestaat ook uit twee afzonderlijke elementen. Ten eerste is
er het visuele gedeelte die ervoor zorgt dat de verplegerspost visueel herkenbaar gemaakt wordt en
ten tweede is er de ‘NetworkNode’ die de eigenlijke locatie van de verplegerspost vastlegt. Het is in
die ‘NetworkNode’ dat alle achterliggende code is neergeschreven. De code in de verplegerspost
betreft enkel het vastleggen van de status van de zorgverlener wanneer deze toekomt of vertrekt. Zo
wordt er bij het toekomen van een zorgverlener gecontroleerd of zijn shift al afgelopen is. Indien dit
het geval is krijgt de zorgverlener de status ‘scheduled down’ mee zodat hij niet meer kan
opgeroepen worden. In Figuur 16 is een visuele representatie gegeven van een verplegerspost.
Figuur 16: Verplegerspost als Basic Unit
Page 73
49
4.3.4. Zorgverleners
Verder zijn ook de zorgverleners als ‘Basic Units’ geïmplementeerd in de gedaante van FlexSim
‘TaskExecuters’. Er kan gekozen worden tussen verschillende profielen, gaande van een
verpleegkundige over een verzorger, tot een logistiek assistent. De meest gebruikte zorgverleners
zijn weergegeven op Figuur 17. Indien nodig kunnen nog steeds zelf personeelsprofielen aangemaakt
worden. Competentie, training en ervaring zijn per profiel aangepast naar de te verwachten
waarden, zoals ze ook in Bijlage 11.2. weergegeven zijn. In een ‘TaskExecuter’ is er geen grote
hoeveelheid code geïmplementeerd. Enkel het terug versturen van een genegeerde oproep naar de
‘Dispatcher’ gebeurt hier. Wel belangrijk zijn de labels van de ‘TaskExecuters’, deze worden
doorheen de code voortdurend aangepast zodat de beslissingsboom over de juiste informatie
beschikt om calls te kunnen toewijzen.
Figuur 17: Alle types zorgverleners als Basic Unit
4.3.5. ‘Source’
Oproepen worden als ‘Item’ verstuurd vanuit de ‘Source’, die te zien is op Figuur 18. Alle gegevens
omtrent locatie, vertrouwensband, assistentie en reden van de oproep worden hier als label
meegegeven met het ‘Item’. Het belangrijkste in de ‘Source’ is de logica die beslist naar welk bed het
‘Item’ moet verstuurd worden. Deze werkt aan de hand van een vooraf opgestelde tabel
(‘SourceOutput’) waarin de naam van ieder bed overeenkomt met de overeenkomstige
uitgangspoort van de ‘Source’.
4.3.6. ‘Dispatcher’
De ‘Dispatcher’ regelt het versturen van oproepen naar de zorgverleners en het opnieuw behandelen
van doorverwezen oproepen. In dit object, dat voorgesteld staat op Figuur 19, staat de belangrijkste
code. Het is dan ook voor de hand liggend dat deze als ‘Basic Unit’ wordt opgenomen in de standaard
bibliotheek. Bij het ontvangen van een oproep roept de ‘Dispatcher’ de beslissingsboom op die
Page 74
50
besproken werd in paragraaf 4.2. Vervolgens wordt de ‘User Command’ ‘Respons’ opgeroepen om te
beslissen hoe de zorgverleners zullen reageren wanneer ze die bepaalde oproep toegestuurd krijgen.
Om de verdere werking van de ‘Dispatcher’ uit te leggen, wordt eerst de werking van de functie
‘Respons’ verduidelijkt. Het eerste wat hier gebeurt, is nagaan hoeveel zorgverleners er na het
doorlopen van de beslissingsboom nog in de lijst ‘Filtered Staff Members’ overblijven. Als het meer
dan één persoon betreft, worden er twee van de gefilterde zorgverleners willekeurig uitgekozen en
wordt daarna beslist wat deze twee zullen doen. Deze implementatie volgt uit het feit dat de regelset
selectief genoeg zou moeten zijn om niet meer dan twee zorgverleners op te roepen. Indien er maar
één iemand is die de oproep krijgt, wordt er eerst nagegaan waar de zorgverlener op dit moment
mee bezig is. Op basis hiervan wordt een kans toegekend aan elk van de negen volgende reacties na
het krijgen van een oproep:
Bel Accepteer Loop (BAL): De zorgverlener belt met de patiënt, drukt daarna effectief op de
accept knop en vertrekt vervolgens naar de patiënt waarbij hij zijn huidige taak achterlaat.
Automatisch zorgt het systeem dat er een andere zorgverlener wordt opgeroepen om deze
patiënt verder te helpen.
Bel Accepteer (BA): Zelfde reactie als BAL, maar de zorgverlener vertrekt niet meteen en
handelt eerst zijn huidige taak af.
Accepteer Loop (AL): De zorgverlener accepteert de oproep op zijn mobiel toestel zonder
bellen en vertrekt meteen naar de patiënt.
Loop Accepteer (LA): Het systeem weet niet dat de zorgverlener onmiddellijk vertrekt naar
de patiënt. Het accepteren van de oproep gebeurt dan door in te loggen in de kamer.
Bel Redirect (BR): De oproep wordt na het bellen met de patiënt afgewezen en dus
teruggestuurd naar het systeem, hoogstwaarschijnlijk met meer informatie over de reden.
Accepteer Loop Redirect (ALR): De zorgverlener accepteert eerst zonder bellen en eens
aangekomen bij de patiënt wijst hij de oproep toch af zodat die teruggestuurd wordt naar
het systeem. De zorgverlener blijft wel wachten bij de patiënt tot de andere zorgverlener
toegekomen is. Dit geval komt zelden voor aangezien een zorgverlener die een oproep
accepteert zonder bellen, de patiënt meestal wel kent en dus op voorhand weet dat hij de
oproep zal kunnen beantwoorden.
Loop Redirect (LR): Deze reactie is gelijkaardig aan ALR, maar dan zonder het vooraf
accepteren. Hier is het eerder rechtstreeks gaan kijken wat de reden van de oproep is om
vervolgens te zien dat er best iemand anders wordt opgeroepen om de patiënt te
behandelen.
Page 75
51
Redirect (R): De zorgverlener wijst zonder andere acties te ondernemen de oproep
onmiddellijk af, waarop die teruggestuurd wordt naar het systeem zonder extra informatie.
Geen enkele zorgverlener zal dit zonder geldige reden doen, omdat dit als ongunstig wordt
beschouwd voor zowel de collega’s als de patiënten. Deze reactie komt dan ook niet vaak
voor.
Ignore (I): De zorgverlener merkt de oproep niet op of heeft op dit moment de mogelijkheid
niet om te reageren op de oproep. Hier zal er ook altijd een grondige reden voor zijn.
Accepteren en doorverwijzen gebeurt door de desbetreffende zorgverlener een bericht met binaire
waarde terug te laten sturen naar de ‘Dispatcher’. Wanneer de waarde ‘1’ teruggestuurd wordt,
accepteert de zorgverlener de oproep, bij de waarde ‘0’ wijst hij de oproep af. Bij het afwijzen wordt
er ook meegegeven of de zorgverlener erin geslaagd is meer informatie over de oproep te
verzamelen en wat deze extra informatie inhoudt.
Tot slot zijn er in de standaardbibliotheek ook enkele louter visuele elementen voorzien om de
plattegrond wat overzichtelijker te maken. Het gaat hierbij onder andere over een muur, een deur,
een berging, … In deze objecten is er geen enkele logica ingepland.
Figuur 18: De 'Source' als Basic Unit
Figuur 19: De 'Dispatcher' als Basic Unit
4.4. Samenstelling van patiënten- en oproepenbestand
De samenstelling van het patiënten- en oproepenbestand moet gegenereerd worden om in deze
thesis realistische simulaties te kunnen uitvoeren. Zoals eerder vermeld zorgt de ‘Source’ ervoor dat
de oproepen als ‘Item’ op het correcte moment naar het correcte bed verstuurd worden. Vanuit het
bed wordt dan de oproep verstuurd naar de ‘Dispatcher’. Om de ‘Source’ op deze manier te laten
werken moet er op voorhand een Excel document ingeladen worden met alle nodige info over de
oproepen:
Page 76
52
Tijdstip van lancering van de oproep in seconden vanaf maandag 00u00.
Reden van de oproep (‘Hotel’, ‘Care’, ‘Medical’ of ‘No Reason’)
Locatie van de oproep aan de hand van een getal
Vertrouwensgetal van de patiënt om persoonlijke vertrouwensband te kunnen bepalen
Graad van hulpbehoevendheid van de patiënt (1 tot 5)
Assistentieoproep of niet?
Er worden ook nog andere labels gecreëerd zoals ‘Redirected’ en ‘SecOp’ die voorlopig geen waarde
krijgen, omdat deze waarden tijdens de simulatie zelf toegekend worden. Deze labels worden dus
enkel gebruikt door FlexSim om informatie bij te houden tijdens het doorlopen van de
beslissingsboom. Uiteraard wordt ervoor gezorgd dat het vertrouwensgetal en de
hulpbehoevendheid van de patiënt gelijk zijn als de oproep uit hetzelfde bed komt, aangezien er
slechts één persoon per bed is doorheen de hele simulatie. Op basis van deze hulpbehoevendheid
wordt door FlexSim de behandelingstijd berekend volgens een exponentiële verdeling waarbij er
voor gezorgd is dat er bij patiënten waar meer voorzichtigheid geboden is, meer kans is op langere
behandelingstijden.
Door het gebruik van dit Excel bestand is het mogelijk om de werking van het
verpleegoproepsysteem in diverse situaties te testen. De wijze waarop de waarden voor al deze
labels berekend worden volgt in een later hoofdstuk over de simulaties. Het hele oproepenbestand
moet vooraf vastgelegd en ingeladen worden in de ‘Source’. Zowel volledig willekeurige data als
realistische data van Televic [7] kunnen gebruikt worden. Deze realistische data zijn afkomstig van
anonieme datalogs van het oproepsysteem in bestaande departementen gedurende een
referentieweek. [7] Het genereren van deze data is uiteraard enkel nodig om realistische simulaties
te kunnen uitvoeren en is geen onderdeel van het model.
4.5. Samenstelling van het personeelsbestand
De werking van het departement zal uiteraard ook afhangen van het personeelsbestand dat gebruikt
wordt. Over de samenstelling van dit personeelsbestand wordt aan de leidinggevende ook de
volledige beslissingsbevoegdheid gegeven. Het is de bedoeling dat alle personeelsleden die
werkzaam zijn in het departement hier aan de simulatie worden toegevoegd. Er werd getracht om in
de opgebouwde bibliotheek met basiselementen zoveel mogelijk types van zorgverleners te
definiëren, waardoor de gebruiker zelf zijn eigen personeelsbestand en bezetting per shift kan
bepalen. Het is ook mogelijk om zelf eigen types van personeelsleden in de simulatie in te voeren. De
regelset is zo gedefinieerd dat er enkel rekening gehouden wordt met de verschillende competenties
Page 77
53
die aan de zorgverlener zijn toegeschreven als rol, training of ervaring. Op die manier kan een
leidinggevende de op voorhand gedefinieerde competenties zelf verdelen over deze drie categorieën
en zo zelf een specifiek personeelslid aanmaken. Dit implementeren is evenwel niet vanzelfsprekend.
Het model werd opgebouwd in FlexSim, maar er kan niet geëist worden van elke zorgverlener om
met dit softwarepakket te kunnen werken. Een oplossing daarvoor zou het ontwerp van een
eenvoudig gebruikersplatform kunnen zijn, dat als gebruiksvriendelijke tussenstap dient om snel de
nodige input in te brengen in het systeem, zonder dat daarvoor enige kennis nodig is van FlexSim. Dit
viel buiten het bereik van deze thesis en kan aangehaald worden als suggestie voor toekomstig
onderzoek.
Voor de originele simulaties werd er gestart met het personeelsbestand van het departement
waarop de plattegrond in het model is gebaseerd en waar dan in de simulatie variaties op gemaakt
werden. Indien zelf een personeelsbestand moet opgesteld worden zonder enige informatie over
wat de gebruikelijke personeelsbezetting is per shift, kan er rekening gehouden worden met de
resultaten van een onderzoek [58] dat uitgevoerd werd door het Royal College of Nursing
betreffende de ideale verhouding tussen ‘Registered Nurses’ en andere zorgverleners in enkele
klassen van ziekenhuisafdelingen. Dit kan in termen van het huidige model gezien worden als de
verhouding tussen ‘Medical’ zorgverleners en ‘Care’ zorgverleners, waarbij de eerste over meer
kwalificaties beschikken. Deze verhouding verschilde onder andere opmerkelijk tussen een pediatrie
afdeling en een instelling voor ouderenzorg. Ook werd er onderzocht hoeveel patiënten er in het
ideale geval per zorgverlener worden toegewezen. Dit laatste is uiteraard minder van toepassing op
het huidige verpleegoproepsysteem, aangezien er op een hogere efficiëntie gemikt wordt, maar kan
wel als richtlijn dienen. In het algemene geval zou er genoeg verplegersexpertise moeten zijn
gedurende de hele dag wanneer 65 procent van alle zorgverleners ‘Medical’ zorgverleners zijn met
uitgebreide kwalificaties. Dit percentage kan in enkele specifieke afdelingen stijgen tot 85 of 90
procent, zoals bijvoorbeeld de intensieve hulpafdelingen.
4.6. Tijdsverdeling van de zorgverleners
Om de situaties die getest worden zo realistisch mogelijk te maken, moet er ook rekening gehouden
worden met de tijdsverdeling van alle personeelsleden. Eerst en vooral moeten de verplegersrondes
geïmplementeerd worden, een belangrijk onderdeel van de dagtaak van iedere zorgverlener. Een
overzicht met de details van alle geïmplementeerde rondes in detail is terug te vinden in Bijlage 11.4,
maar in wat volgt worden alle verschillende rondes kort uitgelegd. De verschillende duurtijden van
elke ronde volgen bepaalde statistische verdelingen die achteraan ook in Bijlage 11.4 terug te vinden
zijn.
Page 78
54
4.6.1. Vaste verplegersrondes
In de volgende paragrafen worden de verschillende vaste verplegerrondes die geïmplementeerd zijn
in het model verduidelijkt.
Medicatieronde
Vooreerst zijn er de medicatierondes, waarbij een verpleegkundige (‘Medical’) eerst gedurende
ongeveer 45 minuten alle medicatie voor de patiënten voorbereid en klaarzet in de uitvalsbasis van
de zorgverleners om deze vervolgens in alle kamers te gaan afgeven. Bij het afgeven blijft de
zorgverlener gemiddeld vijf minuten in de kamer om de medicatie nogmaals te controleren, klaar te
zetten en eventueel al toe te dienen. Tijdens de voorbereiding van de medicatieronde is er besloten
om ervoor te zorgen dat de zorgverlener niet kan onderbroken worden door oproepen. Ook wanneer
hij zich in een kamer bevindt om de medicatie af te geven, wordt deze beter niet onderbroken. Enkel
tijdens het wandelen tussen beide kamers kan er een onderbreking van de ronde toegelaten worden.
Deze beslissingen volgen uit een Australisch onderzoek [11] naar de gevolgen van die
onderbrekingen tijdens de medicatieronde. Het fout afleveren van medicatie aan een patiënt kan
heel zware gevolgen hebben en moet ten allen tijde vermeden worden. Er werden tijdens het
onderzoek twee soorten fouten ontdekt die kunnen optreden tijdens de medicatieronde. Enerzijds
waren er de procedurefouten met ondermeer het verkeerd lezen van de labels van de
geneesmiddelen of van de patiëntennamen en anderzijds de klinische fouten, waarbij er het
verkeerde geneesmiddel of de foute dosis wordt afgeleverd. Per onderbreking nam de kans op
procedurefouten met 12.1 procent toe en de kans op klinische fouten met 12.7 procent. Ook de
ernst van de fouten nam toe naargelang het aantal onderbrekingen steeg, na vier onderbrekingen
steeg de kans op een kapitale fout van 2.3 procent naar 4.7 procent. [11] In het model kan eenvoudig
geïmplementeerd worden dat de zorgverleners tijdens deze taak nooit mogen gestoord worden.
Controleronde
Vervolgens zijn ook de controlerondes geïmplementeerd. Telkens aan het begin van een nieuwe shift
gaat er één zorgverlener langs bij alle kamers om te vragen of alles in orde is en om het wisselen van
shift aan te kondigen. Bij het begin van de vroege shift wordt dit gecombineerd met de
medicatieronde. Ook op andere momenten van de dag en nacht zijn nog gelijkaardige check-up
rondes ingevoerd omdat uit de literatuur blijkt dat dit de zorgverlening significant verbetert. Zo werd
er een onderzoek [59] uitgevoerd naar hoe men het onnodig gebruik van een
verpleegoproepsysteem kon reduceren. Dit overmatig gebruik is immers zeer nadelig voor de
effectiviteit van de zorgverlening van de patiënten, die zoals in de literatuurstudie reeds vermeld al
Page 79
55
niet zo hoog ligt de laatste jaren. Uit het onderzoek bleek dat gekwalificeerde zorgverleners te vaak
bezig waren met taken waarvoor die kwalificaties niet vereist zijn. Er werden dus teveel oproepen
gelanceerd die konden vermeden worden door middel van een meer proactieve behandeling van de
patiënten. [59] Als oplossing werden in het onderzoek twee aanpassingen doorgevoerd, namelijk het
toevoegen van een logistiek assistent aan het personeelsbestand en het invoeren van regelmatige
proactieve rondes waarbij per kamer een bepaald stramien gevolgd wordt. Tijdens die rondes, die
om de één of twee uur gedaan werden afhankelijk van het soort afdeling, vraagt de zorgverlener ook
met wat hij de patiënt nog kan van dienst zijn om zo in te spelen op toekomstige oproepen. Ook de
aanwezigheid van de logistiek assistent had gunstige gevolgen op de zorgverlening, de
gekwalificeerde zorgverleners hadden een betere attitude tijdens het beantwoorden van oproepen
omdat ze meer tijd hadden voor taken die binnen hun kwalificaties vielen. [59] Globaal werd er een
significante daling van het aantal oproepen en stijging van de patiëntentevredenheid geregistreerd.
[59] Per kamer blijft de zorgverlener gemiddeld drie minuten, maar in tien procent van de gevallen
treedt er een probleem op, waardoor de zorgverlener gemiddeld tien minuten langer moet blijven.
Hygiënische ronde
Daarnaast zijn er ook nog de hygiënische rondes, waarbij een zorgverlener de patiënt assisteert bij
het wassen. Uitgebreide kwalificaties zijn hier niet voor vereist, maar het aanwijzen van een logistiek
assistent hiervoor wordt niet toegelaten. ’s Ochtends is een uitgebreide wasronde geïmplementeerd,
waar de patiënt grondig gewassen wordt, wat gemiddeld 23 minuten duurt, en ’s avonds een korte
wasronde waar de patiënt opgefrist wordt, wat gemiddeld slechts 12 minuten duurt. [60]. Een
zorgverlener kan tijdens deze wasbeurten niet onderbroken worden, om het comfort van de patiënt
te garanderen. Er werd besloten om hierin ook de eventuele sanitaire hulp te betrekken zodat aparte
sanitaire rondes voor hulpbehoevende patiënten niet nodig zijn. Patiënten kunnen zoals eerder
aangehaald wel assistentie vragen door een oproep te lanceren vanuit de openbare sanitaire ruimtes
op de gang.
Maaltijdrondes
Uiteraard moet er ook driemaal per dag eten rondgebracht worden en is er eenmaal per dag een
koffieronde. Even later moet er ook afgeruimd worden. Bij een bepaald percentage van de patiënten
moet er ook assistentie verleend worden bij het eten geven. Dit percentage staat ingesteld op 20
procent en kan makkelijk aangepast worden. De exacte tijdsverdelingen zijn zoals beschreven terug
te vinden in bijlage 11.4. Deze rondes kunnen allemaal uitgevoerd worden door alle personeelsleden
en dus ook door een logistiek assistent.
Page 80
56
4.6.2. Nastreven van een realistische tijdsverdeling over een shift
Om de werking van het departement van een zorginstelling zo realistisch mogelijk na te bootsen
wordt er ook gekeken naar de tijdsverdeling van de werkende zorgverleners. Dit topic is reeds
besproken in vele tijd- en methodestudies en andere onderzoeken. In dit model worden de
resultaten gebruikt van enkele specifiek uitgekozen onderzoeken betreffende standaardtijden van
verplegersactiviteiten en de verdeling van deze activiteiten over hun shift. Het gaat om een
proefschrift van dr. Dries Myny [61], die ook bijdroeg in het ontwerp van het
verpleegoproepsysteem, een uitgebreid onderzoek van BMC Health Services Research [62] en een
Work Sampling studie [63] in een specifiek neurologisch departement, die uitgegeven is in het
Journal of Advanced Nursing.
De verdeling van activiteiten over de shift die wordt nagestreefd is te vinden in Figuur 20. De
verschillende categorieën worden hieronder kort uitgelegd:
Administration: Omvat vooral het opstellen en aanpassen van patiëntendossiers.
Personal Time: Tijd die een zorgverlener nodig heeft voor de noodzakelijke pauzes tijdens
een volledige shift, onder meer voor sanitaire pauzes en lunch.
Indirect Patient Care: Tijd die een zorgverlener spendeert aan een patiënt zonder
rechtstreeks in contact te zijn met die patiënt, bijvoorbeeld het klaarzetten van medicatie en
dergelijke.
Direct Patient Care: Tijd die een zorgverlener spendeert aan een patiënt terwijl hij
rechtstreeks in contact is met die patiënt, zoals bijvoorbeeld tijdens het beantwoorden van
oproepen en de assistentie bij het wassen.
Communication: Omvat vooral de momenten waarop zorgverleners met elkaar
communiceren bij shiftwissels of tijdens shifts om informatie over de verschillende patiënten
uit te wisselen.
Movement: Tijd die een zorgverlener spendeert aan het rondwandelen tussen zijn
verschillende opdrachten door.
Other: Alle activiteiten die niet onder één van bovenstaande klassen in te delen zijn.
Page 81
57
Figuur 20: Verdeling van de tijd van een zorgverlener over een representatieve shift [61]
Om deze verdeling zo goed mogelijk na te streven zonder teveel aan de algemeenheid van de
simulatie te raken, worden aan de zorgverleners tijdens de shift takenpakketten meegegeven die
willekeurig samengesteld worden en een kansverdeling volgen die neigt naar deze op Figuur 20. Elke
taak van het takenpakket krijgt een locatie mee en één van bovenstaande redenen. De
implementatie in het model is bijna identiek hetzelfde als bij de standaard verplegersrondes, al
wordt er hier willekeurig gekozen tussen alle mogelijke locaties in het departement terwijl bij de
standaard verplegersrondes de meest logische volgorde wordt gehanteerd. Het betreft hier dus
naast het beantwoorden van de oproepen van de patiënten en het voltooien van de vaste
verplegerrondes de rest van de taken die uitgevoerd worden door de zorgverleners tijdens hun shift.
4.6.3. Overleg tijdens de wissel van de shifts
Om de simulatie zo dicht mogelijk bij de werkelijkheid te laten aanleunen, werd het overleg tussen
de zorgverleners die hun shift beëindigen en diegene die hun shift starten geïmplementeerd. In de
simulatie staat het overleg gepland iedere keer tien minuten voor het wisselen van de werkploegen.
Hierbij worden de respectievelijke zorgverleners naar de basisplaats van de hoofdverpleegkundige
opgeroepen waar ze elk een tiental minuten blijven. Daarna vertrekken ze naar de verplegerspost tot
ze taken of oproepen toegewezen krijgen. Indien een zorgverlener nog een taak of dringende oproep
moet afwerken zal hij dit nog doen na het overleg vooraleer hij stopt met werken.
Page 82
58
5. Key Performance Indicatoren
5.1. Kostenfunctie
Om de verschillende scenario’s op kwantitatieve wijze met elkaar te vergelijken is er nood aan het
definiëren van relevante Key Performance Indicatoren (KPIs). Het gaat hier om numerieke waarden
die snel de performantie van het verpleegoproepsysteem moeten verduidelijken, zoals bijvoorbeeld
de gemiddelde wachttijd vooraleer een oproep beantwoord wordt en het aantal afgelegde
kilometers per zorgverlener. Elke leidinggevende zal deze KPIs in een bepaalde volgorde van
belangrijkheid kunnen plaatsen afhankelijk van zijn type afdeling en voorkeuren. Naargelang die
volgorde kan hij dan gewichten toekennen aan de verschillende KPIs. Zo kan een gebruiker de
gemiddelde tijd tot interventie belangrijker vinden dan de maximale tijd tot interventie of
omgekeerd. Hoe zwaarder het gewicht, hoe liever de gebruiker deze KPI laag wilt houden. Om een
eerste richtlijn te hebben in het bepalen van de gewichten kan er gestart worden vanaf de
beslissingsboom. Hoe hoger in de boom iets gecontroleerd wordt, hoe zwaarder het doorweegt
wanneer de situatie afwijkt van het ideale geval. Wanneer er niemand gevonden wordt met de
correcte competenties, zal dat een negatiever effect hebben op de kostenfunctie dan wanneer er
niemand gevonden wordt met een sterke vertrouwensband. De competenties worden immers
vroeger in de boom gecontroleerd. Toch is het belangrijk hierbij nog eens te vermelden dat dit zeer
afhankelijk is van het departement.
Indien sommige situaties niet mogen voorkomen in het departement kunnen heel zware numerieke
gewichten toegekend worden aan de KPI die met deze situatie verband houdt. Op deze manier is het
gemakkelijker om onderscheid te maken tussen gewenste en ongewenste scenario’s. Na het
uitvoeren van de simulatie worden de numerieke KPIs (kpii) dan met hun corresponderende gewicht
(xi) vermenigvuldigd en wordt vervolgens alles opgeteld om zo de waarde van de kostenfunctie te
bekomen zoals in onderstaande vergelijking te zien is. Deze waarde moet uiteindelijk
geminimaliseerd worden door middel van het doorvoeren van aanpassingen aan de regelset. Het
doel van dit onderzoek is om zoals beschreven een optimale regelset te bepalen, algemeen of per
soort afdeling.
Men kan twee scenario’s vergelijken enkel en alleen op basis van deze ene waarde, maar er wordt
aangeraden om vooral alle afzonderlijke KPIs goed te bestuderen. Zo is het bijvoorbeeld mogelijk dat
Page 83
59
een ongewenste situatie in beide scenario’s is voorgevallen waardoor beide onaanvaardbaar zijn,
onafhankelijk van hun onderlinge rangschikking. De discussie of de waarde van een KPI al dan niet
onaanvaardbaar is, kan opgelost worden door het invoeren van minima en maxima voor deze KPI,
maar deze zijn echter ook heel departementsgebonden. Er wordt in dit verslag dan ook niet op
verdergegaan. Elke KPI en de bijhorende betekenis wordt in wat volgt uitgebreid besproken.
5.2. De verschillende KPIs
5.2.1. De wandelafstand
Als door een zorgverlener hetzelfde takenpakket kan uitgevoerd worden met een duidelijk kleinere
totale wandelafstand kan er normaal gezien gesproken worden van een efficiëntere zorgverlening in
het departement. Het is ook mogelijk dat de leidinggevende van een departement bepaalde redenen
heeft om de wandelafstand in zijn departement zo laag mogelijk te houden, tijd die gespendeerd
wordt om zich te verplaatsen is immers tijd die niet kan gebruikt worden om zorg te verlenen. Om
die redenen wordt de totale wandelafstand als KPI meegenomen in het model. Deze waarde wordt
door FlexSim weergegeven als de totale afstand die gemiddeld per dag door alle zorgverleners samen
wordt afgelegd. Indien de simulatieperiode dus vijf dagen bedraagt, wordt het gemiddelde over deze
vijf dagen genomen. Ook de gemiddelde wandelafstand per dag voor elke zorgverlener over de
volledige simulatieperiode wordt als output gegeven, om meer in detail te kunnen nagaan welke
zorgverleners er te grote afstanden moeten afleggen en waarom.
5.2.2. Gemiddelde tijd tot interventie
Een van de hoofddoelen van het verpleegoproepsysteem blijft om zo snel mogelijk de correcte
zorgverlener op de correcte plaats te krijgen. De gemiddelde tijd tot interventie kan aantonen in
hoeverre het systeem daarin slaagt. Het gaat hier om de tijd tussen het lanceren van de oproep en
het inchecken van de zorgverlener in de kamer. Bij een assistentieoproep gaat het om de tijd tussen
de oproep en het inchecken van de eerste zorgverlener. Het is de bedoeling om dit gemiddelde zo
laag mogelijk te houden, maar niet tegen elke kost.
5.2.3. Maximale tijd tot interventie
Zoals beschreven probeert de regelset gemiddeld een zo snel mogelijke reactietijd te realiseren,
maar in deze situatie is het ook belangrijk de uitschieters te onderzoeken. Als alle patiënten
gemiddeld minder dan twee minuten moesten wachten op hulp maar één patiënt moest 30 minuten
wachten, is er een onaanvaardbare situatie opgetreden en werkt het systeem niet naar behoren. Er
is bewust voor gekozen om beide KPIs die betrekking hebben tot de interventietijd apart te
Page 84
60
definiëren met elk een eigen gewicht, om aan leidinggevenden zelf de keuze te laten welke kost ze
geven aan een te hoge reactietijd.
5.2.4. Het respecteren van de competenties van de zorgverlener
Afhankelijk van de oorzaak van de oproep kunnen bepaalde zorgverleners in aanmerking komen om
opgeroepen te worden en andere niet. De ideale situatie is die waarin elke zorgverlener enkel
oproepen beantwoordt waarvan de oorzaak overeenkomt met zijn hoofdcompetentie. Het overzicht
van de verschillende categorieën competenties per zorgverlener is terug te vinden in Bijlage 11.2.
Het eerste ongewenste geval treedt op wanneer een zorgverlener een oproep moet beantwoorden
met als vereiste competentie een competentie die hij niet als hoofdcompetentie heeft maar
verworven heeft via training. Dit kan geïnterpreteerd worden als een inefficiënte werking van het
systeem aangezien deze zorgverlener een taak uitvoert waar hij niet rechtstreeks voor aangeworven
is. Hoger gekwalificeerde mensen kosten een zorginstelling meer geld, dus zijn hun werkuren
waardevoller. Het is dan ook de bedoeling om de hoger gekwalificeerde zorgverleners een
takenpakket te geven dat het best aansluit bij hun kwaliteiten. Logischerwijs kan dit rechtstreeks als
kost geïmplementeerd worden in de kostenfunctie, aangezien deze situatie zoveel mogelijk
vermeden moet worden.
Het tweede geval dat moet vermeden worden is wanneer een zorgverlener wordt uitgekozen met de
vereiste competenties die hij slechts uit ervaring verworven heeft. Volgens de wet mag deze
zorgverlener dan geen assistentie bieden aan de patiënt, hoewel hij daar waarschijnlijk wel toe in
staat zou zijn. De gebruiker kan zelf kiezen of hij deze situatie al dan niet wil toelaten door het
aanpassen van de gewichten in de kostenfunctie. Er kan met behulp van deze simulatie ook
nagegaan worden welk effect het toelaten hiervan heeft en of er daardoor voldoende argumenten
zijn voor de leidinggevenden om dit in sommige gevallen toe te laten. De ideale regelset kiest voor
elke oproep een zorgverlener uit met de vereiste competenties als hoofdcompetentie.
Aangezien de regelset ook rekening houdt met het geval waarin er geen zorgverleners beschikbaar
zijn met de correcte competenties, kan het ook zijn dat er ongewenste situaties optreden. Wanneer
er bijvoorbeeld een ‘Care’ zorgverlener (zonder de vereiste diploma’s voor het beantwoorden van
medische oproepen) naar een oproep met medische oorzaak wordt gestuurd, kan dat problemen
veroorzaken. Deze persoon heeft niet de correcte competenties en zal in theorie de patiënt niet
volledig kunnen helpen. In de praktijk zal dit uiteraard niet altijd het geval zijn, maar toch moet deze
situatie zoveel mogelijk proberen vermeden worden. Dit zou ook zwaarder moeten doorwegen in de
Page 85
61
kostenfunctie dan het eerste geval waarin de zorgverlener een taak afwerkt waarvoor hij eigenlijk
niet aangeworven is.
Om bij deze KPI een numerieke waarde te verkrijgen, wordt gebruik gemaakt van een gekend
principe in FlexSim, namelijk de ‘Tracked Variables’. Deze variabelen worden bijgehouden gedurende
de volledige simulatie en worden enkel aangepast indien er rechtstreeks naar gerefereerd wordt.
Zowel de nieuwe waarde als het tijdstip van aanpassen wordt bijgehouden. Er wordt een aparte
variabele aangemaakt voor elk van de drie voorafgaande ongewenste situaties en voor het ideale
geval. Telkens één van die situaties voorkomt wordt er bij de corresponderende variabele een
eenheid opgeteld. Na het doorlopen van de volledige simulatieperiode tonen de eindwaardes van de
drie variabelen aan hoe vaak elke situatie voorgekomen is. Enkel deze laatst geregistreerde waarde is
van belang voor de kostenfunctie, maar de grafiek toont ook bij welke oproep er één van de
voorgaande gevallen is opgetreden. Uit het verloop van de grafiek kan dus afgeleid worden of er
bepaalde periodes waren waarin dit geval meer voorkwam. Aan elk van deze situaties kan een apart
gewicht toegekend worden, naar voorkeur van de gebruiker.
5.2.5. Het respecteren van de vertrouwensband tussen zorgverlener en patiënt
Er zijn twee types vertrouwensbanden tussen patiënten en zorgverleners mogelijk. Vooreerst is er de
therapeutische vertrouwensband om aan te geven of de zorgverlener de patiënt mag verzorgen.
Daarnaast kan het in een zorginstelling ook voorvallen dat een patiënt liever niet door een bepaalde
zorgverlener geholpen wordt, bijvoorbeeld omwille van taalkwesties of persoonlijke redenen. Deze
relatie wordt beschreven in de persoonlijke vertrouwensband. Beide vertrouwensbanden kunnen
gebroken worden indien er geen enkele beschikbare zorgverlener gevonden wordt met de correcte
vertrouwensband. Er wordt met ‘Tracked variables’ op dezelfde wijze geregistreerd hoeveel keer elke
band gebroken moet worden tijdens het overlopen van de regelset.
Hier kan een leidinggevende opnieuw beslissen wat hij doet. Hoezeer worden de wensen van de
patiënt in beschouwing genomen? Afhankelijk daarvan kan men dan gewichten voor de totale
kostfunctie toekennen aan beide waarden. Daarbij wordt aangeraden om een zwaardere kost toe te
kennen aan het breken van de therapeutische vertrouwensband. Wordt er in dat departement geen
rekening mee gehouden dan kunnen de gewichten gelijkgesteld worden aan nul.
5.2.6. Hoeveel zorgverleners worden tegelijk opgeroepen?
De ultieme bedoeling van de regelset is om telkens die ene meest geschikte zorgverlener over te
houden na het doorlopen van de volledige beslissingsboom. Indien er na het uitvoeren van de
Page 86
62
volledige regelset meerdere zorgverleners op de lijst met ‘Filtered Staff Members’ overblijven, wordt
de oproep naar al deze zorgverleners gestuurd. Deze zijn niet op de hoogte dat er collega’s dezelfde
oproep hebben gekregen en redeneren dus alsof ze de enige zijn. Deze situatie neigt weer naar het
oude geval waarin er nog geen sprake was van een geavanceerd verpleegoproepsysteem en waar
verschillende zorgverleners tegelijk toekomen aan een kamer voor het beantwoorden van dezelfde
oproep. Op die manier worden er veel nutteloze afstanden afgelegd want er zal uiteindelijk slechts
één iemand de oproep beantwoorden. Door de regelset zo selectief mogelijk te maken, kan ervoor
gezorgd worden dat het aantal zorgverleners dat tegelijk wordt opgeroepen geminimaliseerd wordt.
Aan de andere kant moet men ook opletten dat men niet teveel discrimineert zodat bepaalde takken
van de boom niet meer aangesproken worden. Wanneer er bijvoorbeeld teveel gediscrimineerd
wordt op basis van de vertrouwensband, zal de lijst na deze tak vaak nog maar één zorgverlener
bevatten. Op die manier kan er in de tak die daaronder komt en rekening houdt met de status en de
locatie van de zorgverlener niet meer veel gedifferentieerd worden, waardoor het systeem te weinig
kan rekening houden met de KPIs die afhangen van deze tak.
Bij elke oproep wordt bijgehouden naar hoeveel zorgverleners de oproep uiteindelijk simultaan
verstuurd is. Ook als de oproep meerdere malen moest verstuurd worden omdat een zorgverlener
hem afgewezen had, wordt er bijgehouden naar hoeveel personen die oproep dan verstuurd wordt.
Als output wordt het gemiddelde aantal zorgverleners weergegeven dat opgeroepen werd. De
bedoeling is om dit gemiddelde zo dicht mogelijk bij de waarde 1 te krijgen. De kost van deze KPI
(Khoeveel) wordt in de kostenfunctie uitgedrukt door middel van de volgende formule.
5.2.7. Aantal onderbroken taken van de zorgverleners
Wanneer het systeem niemand vindt die op het moment van de oproep vrij is, wordt de oproep door
de ‘Dispatcher’ verstuurd naar een zorgverlener die ofwel bezig is met een verplegersronde ofwel
bezig is met het behandelen van een oproep verstuurd door een andere patiënt. Tijdens sommige
verplegersrondes kan een zorgverlener zijn huidige taak gemakkelijk onderbreken voor een
dringende oproep, waardoor deze onderbreking niet als KPI geïntegreerd wordt. Dit is niet het geval
voor een sanitaire ronde, waar de patiënt tijdens een wasbeurt moeilijk even alleen kan gelaten
worden. De taken van zo een sanitaire ronde zijn dan ook niet te onderbreken in het model.
Er worden, met het gekende systeem van de ‘Tracked Variables’, twee verschillende zaken
bijgehouden. Enerzijds wordt er met de variabele ‘Disturbed’ geregistreerd wanneer een
zorgverlener gestoord wordt, dus op het moment dat hij opgeroepen wordt tijdens het behandelen
Page 87
63
van een oproep of tijdens het uitvoeren van een taak waarvoor hij bij voorkeur niet mag
onderbroken worden. Anderzijds wordt de variabele ‘Interrupted’ aangepast wanneer hij zijn taak
effectief onderbreekt om de oproep te beantwoorden. Bij het binnenkomen van een oproep kan het
voorkomen dat de zorgverlener even verstrooid geraakt en twijfelt wat hij moet doen, zelfs als hij
daarna beslist om de oproep te negeren. Het kan in elk geval nadelig zijn dat hij op dat moment niet
de volle concentratie op zijn taak heeft door het ontvangen van de oproep en de eventuele
bijkomende handelingen die nodig zijn om de oproep op het toestel af te wijzen. Vanuit dat
standpunt wordt dus de variabele ‘Disturbed’ toegevoegd als KPI aan de kostenfunctie. In deze twee
bovenstaande gevallen wordt voor alle duidelijkheid de variabele ‘Interrupted’ niet aangepast.
De variabele ‘Interrupted’ wordt enkel aangepast wanneer de zorgverlener de huidige taak stillegt
om te bellen met de oproepende patiënt. In dat geval ondervindt de patiënt effectief ongemakken
omdat zijn behandeling tijdelijk wordt stopgezet. Of hij al dan niet vertrekt naar de andere oproep
wordt in dit model niet in rekening genomen aangezien dat hier gekozen wordt volgens een zelf
vooropgestelde kansverdeling. Dit geval ook apart onderzoeken zou dus weinig verrassende
resultaten opleveren. In de realiteit zou de frequentie van het al dan niet onderbreken van de
behandeling wel in meer detail kunnen onderzocht worden en hoogstwaarschijnlijk interessante
resultaten opleveren zoals bijvoorbeeld de verschillende elementen die meespelen in deze beslissing.
De gevallen waarin de zorgverlener enkel belt en daarna de oproep afwijst om verder te doen aan de
huidige oproep of daarna accepteert om pas na de huidige oproep te vertrekken zijn uiteraard veel
voordeliger, maar zullen zoveel voorkomen als vooraf gedefinieerd wordt. Ook in deze gevallen is de
variabele ‘Disturbed’ ondertussen aangepast, aangezien de oproep bij de bezette zorgverlener is
toegekomen.
De gewichten die aan beide KPIs gegeven worden, kunnen opnieuw vrij gekozen worden door de
leidinggevende, waarbij er hoogstwaarschijnlijk een zwaarder gewicht aan de ‘Disturbed’ variabele
zal moeten gegeven worden, zodat er bij het minimaliseren van de kostenfunctie ook geprobeerd
wordt om de zorgverlening zo weinig mogelijk te onderbreken om het risico op fouten te
minimaliseren.
5.2.8. Aantal keer dat een oproep wordt doorverwezen
Wanneer een zorgverlener beslist om de oproep af te wijzen wordt die oproep teruggestuurd naar
de ‘Dispatcher’, die met behulp van eventuele nieuwe informatie een nieuwe zorgverlener moet
uitkiezen. In de labels van de oproep wordt er geregistreerd door welke zorgverleners hij reeds is
doorverwezen, zodat de ‘Dispatcher’ makkelijk de zorgverleners die de oproep nog niet gekregen
Page 88
64
hebben, kan herkennen. Zorgverleners die deze oproep eerder al doorgestuurd hebben, kunnen deze
dus in eerste instantie niet meer opnieuw toegestuurd krijgen. Op het moment dat de oproep door
alle beschikbare zorgverleners eenmaal is doorverwezen, houdt de ‘Dispatcher’ geen rekening meer
met dit criterium en kan elke zorgverlener opnieuw uitgekozen worden. Het aantal keer dat deze
oproep werd doorverwezen is dus in dit geval gelijk aan het aantal werkende zorgverleners.
Voor alle duidelijkheid wordt deze waarde ook geregistreerd wanneer een oproep opnieuw
verstuurd wordt nadat deze onderbroken was door een zorgverlener die naar een andere patiënt
vertrokken is. Ook wanneer er een tweede persoon voor assistentie gevraagd wordt, wordt deze
geregistreerd. Hierbij worden de personen die de oproep bij zijn initiële lancering afgewezen hebben,
terug opnieuw beschikbaar gesteld voor de ‘Dispatcher’.
De output van deze KPI is één gemiddelde waarde, genomen over alle gelanceerde oproepen, van
het aantal keer dat die oproep werd doorverwezen. Aan deze enkele waarde kan ook een gewicht
toegekend worden om de graad van belangrijkheid in de totale kostenfunctie te bepalen.
5.2.9. De verdeling van de werklast
De bedoeling is om de totale werklast, dus inclusief alle rondes en behandelingen van oproepen, zo
gelijk mogelijk te verdelen over de verschillende zorgverleners. Deze optimale verdeling moet leiden
tot een grotere efficiëntie van het departement en minder overvolle shifts voor bepaalde
zorgverleners. Per zorgverlener worden de percentages gegeven van de verschillende statussen
waarin hij zich bevond tijdens zijn shifts over de volledige simulatieperiode. Deze statussen bepalen
welke taak de zorgverlener op dat moment aan het uitvoeren was. Om een realistische situatie te
simuleren is het aangeraden het takenpakket van de zorgverleners zo samen te stellen dat het
gelijkloopt met eerder uitgevoerde studies over hun tijdsverdeling, zoals eerder besproken is in
paragraaf 4.6.2. Dat takenpakket loopt voor alle zorgverleners gelijkmatig, waardoor de verdeling van
de werklast vooral gebaseerd is op het aantal oproepen dat ze moeten beantwoorden en de vaste
rondes waarvoor ze geselecteerd worden. Hoe meer ze opgeroepen worden om een patiënt te
assisteren, hoe minder tijd ze hebben voor het takenpakket dat voor hen uitgeschreven is tijdens hun
shift. Na het uitvoeren van een volledige simulatie, wordt er nagegaan of een zorgverlener die
gemiddeld gezien over de 52 weken veel rondes toegewezen kreeg, nog veel belast werd met het
beantwoorden van oproepen. Een betere werkverdeling zou ervoor moeten zorgen dat deze
zorgverleners minder oproepen toegewezen kregen dan zorgverleners die zelden aan vaste rondes
werden toegewezen. Deze KPI is moeilijk te vertalen in één numerieke waarde, waardoor deze apart
van de kostenfunctie moet geanalyseerd worden.
Page 89
65
5.2.10. Conclusie
In de voorgaande paragrafen werden de verschillende KPIs besproken die bepalen hoe goed het
systeem in elk scenario presteert. Aan de hand van de bekomen waarden voor deze KPIs wordt de
totale waarde van de kostenfunctie berekent die een indicatie geeft van deze prestaties. De
bijhorende gewichten van de KPIs in deze kostenfunctie zullen naar eigen voorkeur door de gebruiker
moeten ingevuld worden.
Page 90
66
6. Het genereren van een realistische dataset
6.1. Inleiding
De initiële bedoeling was om de klassieke Monte Carlo simulaties toe te passen op de verschillende
scenario’s en op zoek te gaan naar significante verschillen in de resultaten van die scenario’s.
Klassieke Monte Carlo simulaties worden toegepast in situaties waarin het resultaat van één enkele
simulatie niet voldoende representatief is door de verwachte variatie op heel wat elementen in de
simulatie. In deze thesis gaat het hier vooral om de variatie op de behandeltijden. Deze variabiliteit
moet in een Monte Carlo simulatie met voldoende betrouwbaarheid kunnen gekwantificeerd
worden, wat in dit model gedaan wordt aan de hand van gekende statistische verdelingen.
Een dergelijke Monte Carlo simulatie uitvoeren op dit model is niet vanzelfsprekend aangezien er
twee lagen van variabiliteit kunnen onderscheiden worden. Enerzijds is er de variabiliteit op de
verdeling van de oproepen en op de samenstelling van het patiëntenbestand. Deze twee worden los
van FlexSim aangepast in het Excel document dat ingeladen wordt voor de simulatie. Anderzijds is er
de variabiliteit die optreedt in het model zelf, zoals bijvoorbeeld op de procestijden voor zowel het
behandelen van de oproepen als voor het uitvoeren van de rondetaken, op de duur van de
telefonische gesprekken en op de reacties van de zorgverleners wanneer ze een oproep ontvangen.
De ingebouwde ‘Experimenter’ van FlexSim zorgt voor een Monte Carlo simulatie op het model
waarbij hij enkel rekening houdt met de variabiliteit die optreedt binnen het model, de ingeladen
data uit Excel blijven dus constant. Om die reden zijn de resultaten die door het gebruik van de
‘Experimenter’ bekomen worden niet zo relevant, omdat niet geweten is hoe representatief die ene
ingeladen week is. Er zou bij elke replicatie een andere dataset moeten ingeladen worden, wat
buiten de mogelijkheden van deze ‘Experimenter’ ligt.
Om zelf een relevante simulatie op te stellen werd er beslist om data van meerdere weken in te
laden in plaats van de data van slechts één week. Tussen deze verschillende weken zijn enkel het
aantal oproepen per week en de samenstelling van het patiëntenbestand gelijk. De variabiliteit op
het ingeladen bestand wordt gerealiseerd door gebruik te maken van gekende statistische
verdelingen, die later in paragraaf 6.2.3. zullen verduidelijkt worden. Twee macro’s, die
geprogrammeerd werden in VBA van Microsoft Office Excel, zorgen ervoor dat het correcte aantal
verschillende oproepen gegenereerd wordt. De macro ‘Week’ bouwt eerst een oproepenbestand op
voor één week met een aantal oproepen naar keuze. Vervolgens genereert de macro ‘Jaar’ een
vooraf ingesteld aantal gelijkaardige weken met een gelijk aantal oproepen als de eerste week. Op
deze manier wordt er tijdens het uitvoeren van de simulaties rekening gehouden met de beide lagen
Page 91
67
van variabiliteit in het model. Zowel het oproepenbestand als de reacties van het systeem verschillen
nu van week tot week.
6.2. Opstellen van een algemeen oproepenbestand op basis van Televic
data [7].
6.2.1. Inleiding
Om de simulatie betrouwbare resultaten te laten genereren moet deze uiteraard voorzien worden
van een realistische input. Die input bestaat uit een lijst van oproepen met voor elk van deze onder
andere het tijdstip waarop ze gelanceerd wordt, de reden van de oproep, de locatie van waaruit ze
gelanceerd wordt en een binaire variabele die bepaalt of de oproep assistentie zal nodig hebben of
niet. Iedere locatie is ofwel gekoppeld aan een bed, waarin tijdens de volledige simulatie dezelfde
patiënt verblijft, ofwel aan een bepaalde openbare ruimte. Aan elk bed hangt er dus een
vertrouwenswaarde en een graad van hulpbehoevendheid vast. Voor de openbare plaatsen zijn deze
laatste variabelen niet vastgelegd, aangezien in theorie elke patiënt zich naar deze plaats kan
begeven en daar een oproep kan lanceren. Die vertrouwenswaarde wordt, zoals reeds eerder
vermeld, gebruikt om te bepalen wat de vertrouwensband is tussen de zorgverleners en de
patiënten. De hulpbehoevendheid geeft een indicatie voor de procestijd, met name hoe lang het
afhandelen van de oproep ongeveer zal duren. Om met behulp van FlexSim de resultaten zo goed
mogelijk te kunnen analyseren wordt er dus voor gekozen de simulatie over een jaar (52
verschillende weken) te laten lopen. Op die manier wordt er wel genoeg rekening gehouden met de
variaties die mogelijk zijn tussen de verschillende oproepen. Na de simulatie zijn van elke oproep alle
gegevens beschikbaar die nodig zijn om de waarden voor de KPIs te bepalen. Dit is ook het geval voor
elke keer dat de oproep opnieuw verstuurd werd. Ter verduidelijking, wanneer een bepaalde oproep
eerst twee maal werd afgewezen vooraleer die de derde keer geaccepteerd werd, is er van elk van
deze drie keer dat de oproep verstuurd werd, geweten naar hoeveel personen tegelijk dat gebeurde
en hoe lang de patiënt uiteindelijk moest wachten vooraleer hij geholpen werd.
6.2.2. Het samenstellen van een patiëntenbestand
Tijdens de simulaties wordt er in elke week van het gegenereerde jaar gewerkt met een vast
patiëntenbestand. In ieder bed ligt dus een bepaalde patiënt die een zekere graad van
hulpbehoevendheid en een zekere persoonlijke vertrouwenswaarde met zich mee krijgt. De graad
van hulpbehoevendheid wordt in eerste instantie willekeurig gekozen tussen de waardes 1 en 5,
maar er is ruimte gelaten om deze, oorspronkelijk uniforme, verdeling om te vormen naar
bijvoorbeeld een verdeling waar er vooral hoge graden voorkomen. Dit kan het geval zijn in
Page 92
68
departementen waar de patiënten standaard een hoge hulpbehoevendheid hebben, zoals
bijvoorbeeld de afdeling intensieve zorgen. Voor het persoonlijke vertrouwensgetal werd ook
gebruik gemaakt van een uniforme verdeling, ditmaal tussen 0 en 100.
6.2.3. Eigenschappen van een oproep
De bedoeling van het gebruik van het Excel document is om op een automatische manier realistische
en relevante data te genereren. Iedere oproep heeft bepaalde eigenschappen of parameters en
wordt in Excel voorgesteld door een rij waar aan iedere parameter een bepaalde waarde gegeven is.
Deze waarden volgen vooraf ingestelde statistische verdelingen die gebaseerd zijn op de realistische
data en de eigenschappen van de bestudeerde bestaande departementen. Deze verdelingen zullen
later verduidelijkt worden. Een voorbeeld van een volledig gedefinieerde oproep is terug te vinden in
Tabel 2. De namen van de parameters stemmen precies overeen met de gebruikte labels in het
FlexSim model, zodat FlexSim deze waarden correct en eenvoudig kan interpreteren bij het inladen.
Er wordt in Excel gebruik gemaakt van Macro’s om het gewenste aantal willekeurige oproepen te
genereren. In wat volgt zullen alle labels één voor één verduidelijkt worden aan de hand van de rol
die ze spelen in de simulatie. Ook de reden van de gebruikte statistische verdeling zal zoals reeds
beschreven verklaard worden.
De eerste parameter stelt de dag van de week voor waarop de oproep toekomt. Deze omvat ofwel
enkel weekdagen (1 tot 5) ofwel alle dagen van de week (1 tot 7) afhankelijk van de gekozen
ziekenhuisafdeling. Het vaste aantal oproepen per week wordt door middel van een uniforme
verdeling verdeeld over het ingestelde aantal dagen van de week. In het geval dat er in het weekend
minder oproepen verstuurd worden, zoals in departement 2, dan worden de oproepen eerst
opgedeeld in week- en weekendoproepen volgens de vooropgestelde kansverdeling die afgeleid
werd uit de data van Televic [7] en pas daarna uniform verdeeld over het aantal dagen in de week of
het weekend.
De volgende parameter ‘Periode’ bepaalt in welke tijdspanne van de dag de oproep zal gelanceerd
worden. Deze tijdspannes zijn vooropgestelde periodes gedurende de dag waarin een oproep kan
verstuurd worden. Op basis van deze periode wordt één van de belangrijkste parameters bepaald,
met name het tijdstip (‘Arrival Time’) van de oproep. Dit tijdstip in seconden geeft aan FlexSim door
wanneer die bepaalde oproep moet gelanceerd worden in het systeem. De oproepen worden
uniform verdeeld over de vooraf gedefinieerde periodes. Aangezien een opdeling van de dag in shifts
daarvoor niet precies genoeg is, de oproepen zijn immers nooit uniform verdeeld over een shift [7],
moet een dag in meerdere periodes kunnen opgedeeld worden. Er kunnen altijd drukkere momenten
Page 93
69
onderscheiden worden van minder drukke momenten. Hoe er op basis van deze data definitief een
opdeling in periodes doorgevoerd werd, wordt in paragrafen 6.3 en 6.4 meer in detail besproken.
De volgende drie parameters, ‘ItemName’, ‘ItemType’ en ‘Quantity’, liggen vast voor iedere oproep
en worden enkel gebruikt om aan het model in FlexSim duidelijk te maken dat het een oproep
betreft. Voor deze parameters moet dus altijd respectievelijk ‘Call’, 1 en 1 ingevuld worden, andere
mogelijkheden worden in het model niet gebruikt. De volgende parameter betreft de locatie van de
oproep, aangegeven door een getal tussen 1 en het totaal aantal plaatsen in het departement. Zowel
de openbare plaatsen als de kamers zijn hierin meegenomen. Tien procent van de gelanceerde
oproepen wordt toegewezen aan de openbare plaatsen. Dit percentage is arbitrair bepaald en kan
moeilijk gecontroleerd worden, aangezien er voorlopig geen data beschikbaar zijn betreffende dit
soort oproepen. De rest van de oproepen is dus afkomstig uit de verschillende kamers. Om te
bepalen uit welke kamer de oproep verstuurd is, worden verschillende zones met kamers
afgebakend waarbij er enerzijds zones zijn met patiënten die meer oproepen lanceren en dus als
arbeidsintensief kunnen aanschouwd worden, en anderzijds zones met patiënten die minder
assistentie vereisen. Dit onderscheid zou vooral invloed moeten hebben op het verschil in
performantie tussen het huidige verpleegoproepsysteem en het nieuwe dat tijdens het Accio project
werd ontwikkeld.
De volgende parameter definieert de reden van de oproep, die terug te vinden is onder het label
‘CallType’ en volgt uit een zelf opgestelde kansverdeling die gebaseerd is op het taartdiagram op
Figuur 21 dat afgeleid is op de literatuur [8]. De meeste oproepen, 36.7%, hebben een medische
reden, zoals bijvoorbeeld de vraag naar medicatie of problemen met een sonde. Bijna 20% van de
oproepen zijn zorgoproepen, waarbij het bijvoorbeeld gaat om assistentie in de eigen badkamer. De
laatste categorie zijn de hoteloproepen, die minst frequent voorkomen en ook het gemakkelijkst te
behandelen zijn, zoals bijvoorbeeld de vraag naar een glas water. Dit soort oproepen kan door alle
personeelsleden uitgevoerd worden. Tenslotte kan er in meer dan een kwart van de gevallen geen
reden van de oproep achterhaald worden, dit kan gebeuren wanneer de patiënt niet in staat is om te
communiceren met de zorgverlener via telefoon of wanneer de patiënt per ongeluk een oproep
gelanceerd heeft.
Page 94
70
Figuur 21: Verschillende oorzaken van een oproep [8]
De volgende parameters bevatten de informatie over de patiënt die zich in dat bed bevindt tijdens de
simulatieperiode. Deze volgen rechtstreeks uit het opgestelde patiëntenbestand en zijn dus enkel
afhankelijk van de locatie van de oproep. Het gaat om de persoonlijke vertrouwenswaarde en de
graad van hulpbehoevendheid. De graad van hulpbehoevendheid hangt af van de vooraf ingestelde
aard van de afdeling. Een afdeling waar patiënten veel zorg vereisen, heeft meer kans op hogere
graden van hulpbehoevendheid en een patiënt met hogere graad van hulpbehoevendheid vereist
een gemiddeld langere behandelingstijd voor een medische oproep. Voor de hotel- en zorgoproepen
hangen de behandelingstijden niet af van de graad van hulpbehoevendheid.
De kans dat de binaire parameter ‘Assistance’ de waarde ‘1’ aanneemt en dus aangeeft dat het om
een assistentieoproep gaat, werd afgeleid uit de data van Televic [7] waarin een bepaald percentage
van de oproepen geclassificeerd werd als assistentieoproep. Wanneer het departement tijdens een
bepaalde shift slechts één werkende zorgverlener ter beschikking heeft, wordt er in de data op
voorhand voor gezorgd dat er geen assistentieoproep kan gelanceerd worden. Er wordt vanuit
gegaan dat de zorgverlener zelf weet dat hij zich alleen op de afdeling bevindt en dus niet om
assistentie zal vragen binnen zijn eigen departement. In de realiteit zou er in dat geval iemand van
een ander departement kunnen verwittigd worden, maar dit is niet opgenomen in het huidige
model. De laatste twee parameters krijgen bij het genereren van de data standaard de waarde nul en
worden door FlexSim gebruikt om tijdens de simulatie aan te passen naargelang de situatie. De
parameter ‘Redirected’ wordt door FlexSim gebruikt om in een lijst bij te houden door welke
zorgverleners de oproep reeds afgewezen is, zodat die niet opnieuw meegenomen worden in de
beslissingsboom. De parameter ‘SecOp’ gebruikt FlexSim om te registreren welke zorgverlener er
assistentie nodig heeft, zodat deze persoon ook niet meer in rekening gebracht wordt in de
beslissingsboom. Deze parameters worden dus hier al aangemaakt maar hebben bij de eerste
lancering van de oproep de waarde 0.
Page 95
71
Dag Periode Arrival Time ItemName ItemType Quantity CallType
1 1 20278 Call 1 1 NoReason
Location PersTrust Helplessness Assistance Redirected SecOp
18 93 1 0 0 0
Tabel 2: Eigenschappen van oproepen
6.3. Het oproepenbestand voor Departement 1
Het eerste representatief departement dat in FlexSim gebouwd werd, is gebaseerd op een afdeling
waar er enkel tijdens de week patiënten verblijven. De structuur van dit departement kan afgeleid
worden uit Figuur 22. Het betreft een rustig departement met patiënten met een relatief lage
zorgvraag. Er worden eerder weinig oproepen gelanceerd, in de geregistreerde referentieweek
bedroeg het totale aantal oproepen ongeveer 80. De patiënten ondervinden weinig hindernissen om
zich te verplaatsen doorheen het departement. Twee van de 16 kamers hebben twee bedden,
waardoor er in totaal plaats is voor 18 patiënten. De verschillende publieke ruimtes zijn de twee
publieke badkamers en de speelruimte. Oproepen kunnen gelanceerd worden vanuit elk bed en
vanuit de twee badkamers. De samenstelling van het personeelsbestand per shift wordt later in
Tabel 7 en Tabel 9 in hoofdstuk 7.1. verduidelijkt.
Figuur 22: Voorstelling van Departement 1 in FlexSim
Zoals eerder vermeld moet er voor elke afdeling een volledig oproepenbestand gegenereerd worden,
gebaseerd op de anonieme logginggegevens van Televic [7]. Op basis van de tijdstippen waarop de
oproepen verstuurd werden tijdens die referentieweek, werd gezocht naar patronen in het verloop
van de oproepen per dag. De cumulatieve van het aantal oproepen werd voor elke weekdag op de
grafiek op Figuur 23 uitgezet in functie van het tijdstip van de oproep. Elk datapunt op de grafiek stelt
Page 96
72
de lancering van een werkelijke oproep voor. De bedoeling is om aan de hand van deze data de
typisch drukkere periodes te onderscheiden van de andere. Het is immers tijdens deze drukkere
periodes dat de zorgverleners het moeilijk hebben om het aantal oproepen bij te houden, waardoor
ze zeker ook moeten gesimuleerd worden in het model.
Op basis van de figuur werden in eerste instantie enkele mindere drukke en drukkere periodes van
elkaar onderscheiden. Er komen elke dag twee drukkere periodes terug, tussen 7u00 en 9u45 (25000
tot 35000 seconden) en tussen 12u30 en 18u00 (45000 tot 65000 seconden)2. Deze periodes werden
in Tabel 3 apart genomen van de andere periodes. In Tabel 3 zijn deze verschillende periodes op een
dag opgelijst met het percentage oproepen dat tijdens de referentieweek in die periodes gelanceerd
werd. In wat volgt zal geprobeerd worden om de lange periodes waar nodig op te splitsen om tot een
realistischere verdeling van de oproepen over de dag te komen.
Figuur 23: Verloop van het aantal ontvangen oproepen in Departement 1
2 Er werd opgedeeld in periodes van minimaal 5000 seconden (ongeveer 1u25min). Er werden seconden
gebruikt aangezien dit tot een eenvoudigere implementatie in FlexSim leidt. FlexSim kan namelijk geen uren inlezen uit Excel. De weergave in seconden is het aantal seconden dat verlopen is sinds ’s ochtends 00u00
0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 0:00
0
5
10
15
20
25
0 10000 20000 30000 40000 50000 60000 70000 80000
Tijdstip van oproep [uu:mm]
Cu
mu
lati
ef a
anta
l op
roep
en p
er d
ag
Tijdstip van oproep [s]
maandag dinsdag woensdag donderdag vrijdag
Page 97
73
Periode 4 van 12u30 tot 18u00 waarin ongeveer de helft van de oproepen gelanceerd wordt, duurt
bijna even lang als een shift en is verantwoordelijk voor bijna de helft van de dagelijkse oproepen.
Deze periode moet dus noodzakelijkerwijs nog opgedeeld worden in kleinere periodes om een
betere verdeling na te streven. Ook de periodes met minder oproepen kunnen eventueel nog
gesplitst worden in subperiodes indien er tussen deze subperiodes nog grote verschillen in aantal
oproepen gevonden worden. Alle onderstaande periodes werden in de analyse op verschillende
manieren onderverdeeld in subperiodes, waarbij telkens aan de hand van zowel het percentage
oproepen dat binnen deze subperiodes viel als de duur van deze subperiodes beslist werd of de
onderverdeling noodzakelijk was. Wanneer daar grote verschillen optraden, werd de originele
periode definitief gesplitst in deze subperiodes.
Periode Tijdstippen (s) Tijdstippen (u) % oproepen Lengte Periode
Periode 1 0-25000 00:00 - 07:00 10,84 25000 seconden
Periode 2 25000-35000 07:00 - 09:45 22,89 10000 seconden
Periode 3 35000-45000 09:45 - 12:30 4,82 10000 seconden
Periode 4 45000-65000 12:30 - 18:00 45,78 20000 seconden
Periode 5 65000-86400 18:00 - 00:00 15,67 21400 seconden
Tabel 3: Initiële verdeling van een dag in periodes in Departement 1
Een voorbeeld van wat gedefinieerd wordt als een groot verschil trad op bij de splitsing van periode 4
in twee gelijke subperiodes, waarbij ongeveer 17% procent van de oproepen viel tussen 12u30 en
15u15 en 28% van de oproepen tussen 15u15 en 18u00. Hier werd dus duidelijk dat beide
subperiodes andere eigenschappen vertonen wat betreft het aantal oproepen en beter definitief
gescheiden worden. Wanneer de laatste periode van de dag, periode 5, in twee delen gesplitst werd,
vielen geen verschillen op te merken. Tijdens de eerste subperiode, van 18u00 tot 20u50, werd
7,23% van de oproepen gelanceerd, terwijl dat percentage in de andere subperiode, van 20u50 tot
23u59 8,44% bedroeg. Rekening houdende met het feit dat de tweede subperiode ook iets langer is,
kon besloten worden dat periode 5 beter niet opgesplitst werd. Een gelijkaardige analyse werd
doorgevoerd op de andere periodes uit Tabel 3.
De totale analyse leidde uiteindelijk tot de definitieve verdeling van de dag in acht verschillende
periodes met het percentage oproepen dat tijdens die bepaalde periodes gelanceerd werd tijdens de
referentieweek. Deze verdeling is terug te vinden in Tabel 4 en is ook aangeduid op Figuur 23. Het
uiteindelijke doel was om de typisch drukke periodes op een dag te onderscheiden van de andere.
Uit de analyse blijkt dat er drie drukke momenten bestaan op deze afdeling, het gaat om periode 3,
periode 5 en periode 6. Hiervan kan periode 6 echt als een piekmoment beschouwd worden,
aangezien er bijna 20 procent van de dagelijkse oproepen verstuurd werd binnen een periode van
Page 98
74
minder dan anderhalf uur. Deze percentages zullen ook gebruikt worden om een vooropgesteld
aantal oproepen per dag op een correcte manier over de verschillende periodes te kunnen verdelen.
Periode Tijdstippen (s) Tijdstippen (u) % oproepen Lengte Periode
Periode 1 0-10000 00:00 - 02:45 7,23 10000 seconden
Periode 2 10000-25000 02:45 - 07:00 3,61 15000 seconden
Periode 3 25000-35000 07:00 - 09:45 22,89 10000 seconden
Periode 4 35000-45000 09:45 - 12:30 4,82 10000 seconden
Periode 5 45000-55000 12:30 - 15:15 16,87 10000 seconden
Periode 6 55000-60000 15:15 - 16:40 19,28 5000 seconden
Periode 7 60000-65000 16:40 - 18:00 9,63 5000 seconden
Periode 8 65000-86400 18:00 - 00:00 15,67 21400 seconden
Tabel 4: Finale verdeling van een dag in periodes in Departement 1
Op het histogram op Figuur 24 zijn de 83 oproepen die tijdens de referentieweek geregistreerd
werden, verdeeld over de verschillende periodes waarin ze vielen. Over de vijf geregistreerde dagen
werden er dus in totaal 16 oproepen verstuurd tussen 15u15 en 16u40, wat ook kan afgeleid worden
uit Figuur 23 door het aantal datapunten dat binnen periode 6 viel op te tellen.
Figuur 24: Histogram van het aantal oproepen in Departement 1
6
3
19
4
14
16
8
13
0
2
4
6
8
10
12
14
16
18
20
00:00 -02:45
02:45 -07:00
07:00 -09:45
09:45 -12:30
12:30 -15:15
15:15 -16:40
16:40 -18:00
18:00 -00:00
Aan
tal o
pro
epen
Periode [uu:mm - uu:mm]
Page 99
75
6.4. Het oproepenbestand voor Departement 2
Het tweede representatief departement dat in FlexSim gebouwd werd, is gebaseerd op een andere
bestaande afdeling, waar er zowel in de week als in het weekend patiënten aanwezig zijn. De
structuur van dit departement verschilt van het eerste en wordt weergegeven in Figuur 25. Het
betreft een drukker departement waar de patiënten een gemiddelde zorgvraag hebben. Er worden
dus beduidend meer oproepen per week verstuurd dan in het eerste departement. Op dit
departement is er plaats voor 26 patiënten, verdeeld over 18 kamers waarvan acht dubbele kamers.
Er wordt opnieuw gebruik gemaakt van de dataloggings van het Televic verpleegoproepsysteem [7]
die geregistreerd werden tijdens een referentieweek. In die week bedroeg het totale aantal
oproepen in dit departement ongeveer 700. De patiënten kunnen zich, rekening houdende met hun
toestand, ook verplaatsen doorheen het departement. De verschillende publieke ruimtes zijn de drie
publieke badkamers en het terras. Oproepen kunnen gelanceerd worden vanuit elk bed en vanuit de
drie badkamers. De samenstelling van het personeelsbestand per shift wordt later in Tabel 8 en Tabel
10 in hoofdstuk 7.1. verduidelijkt.
Figuur 25: Voorstelling van Departement 2 in FlexSim
Om het oproepenbestand voor deze afdeling te genereren werd geprobeerd om op gelijkaardige
wijze tewerk te gaan als bij de vorige afdeling. De dataloggings van Televic [7] van die bepaalde
referentieweek op dit departement werden eerst grafisch geanalyseerd op Figuur 26, waar opnieuw
de cumulatieve van het aantal oproepen uitgezet werd tegenover de tijd. Onder andere door het
veel grotere aantal oproepen kon er op dit departement heel moeilijk grafisch een onderscheid
gemaakt worden tussen de drukkere en minder drukke periodes. Daarom werd er besloten om op dit
departement de analyse anders aan te pakken en te starten met kleinere periodes die dan eventueel
samengenomen worden tot grotere periodes. Er worden uit deze Figuur 26 wel conclusies getrokken
betreffende het verschil in aantal oproepen tussen de weekdagen en het weekend. Tijdens de
Page 100
76
referentieweek werden er met een gelijke bezetting minder oproepen tijdens het weekend verstuurd
dan tijdens de week. Slechts 22,3 procent van de oproepen werd op zaterdag of zondag gelanceerd.
Deze verdeling tussen week- en weekendoproepen werd dan ook opgenomen in het opstellen van
een realistisch oproepenbestand voor dit departement. Aangezien er dus al in de verdeling van het
aantal oproepen over de verschillende dagen van de week rekening gehouden wordt met het verschil
tussen aantal week- en weekendoproepen, wordt er in de volgende analyse, waar de verdeling van
de oproepen per dag onderzocht wordt, geen rekening meer mee gehouden.
Figuur 26: Verloop van het aantal ontvangen oproepen in Departement 2
Een dag wordt om te beginnen opgedeeld in 18 gelijke periodes van 5000 seconden of ongeveer
1u25min. Van elke periode is in Tabel 6 weergegeven hoeveel procent van alle oproepen die tijdens
de referentieweek geregistreerd werden, binnen die bepaalde periode viel. Meteen valt op dat de
verdeling van de oproepen over de dag inderdaad gelijkmatiger verloopt dan in het eerste
departement. Bijgevolg kunnen er niet meteen extreem drukke periodes onderscheiden worden, wat
in het eerste departement wel het geval was, bijvoorbeeld voor de periode tussen 15u15 en 16u40
0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 0:00
0
20
40
60
80
100
120
140
0 10000 20000 30000 40000 50000 60000 70000 80000
Tijdstip van oproep [uu:mm]
Cu
mu
lati
ef a
anta
l op
roep
en
Tijdstip van oproep [s]
maandag dinsdag woensdag donderdag
vrijdag zaterdag zondag
Page 101
77
(periode 6) met bijna 20 procent van de dagelijkse oproepen. Diezelfde periode in dit departement,
van 15u15 tot 16u40 (periode 12), is ook de drukste periode, maar met slechts 10 procent van de
dagelijkse oproepen.
Periode Tijdstippen [s] Tijdstippen [uu:mm] % oproepen Lengte Periode
Periode 1 0-5000 00:00 – 01:25 4,40 5000 seconden
Periode 2 5000-10000 01:25 – 02:45 3,13 5000 seconden
Periode 3 10000-15000 02:45 – 04:10 3,55 5000 seconden
Periode 4 15000-20000 04:10 – 05:30 2,70 5000 seconden
Periode 5 20000-25000 05:35 – 07:00 4,97 5000 seconden
Periode 6 25000-30000 07:00 – 08:20 4,69 5000 seconden
Periode 7 30000-35000 08:20 – 09:45 7,10 5000 seconden
Periode 8 35000-40000 09:45 – 11:05 6,68 5000 seconden
Periode 9 40000-45000 11:05 – 12:30 6,11 5000 seconden
Periode 10 45000-50000 12:30 – 13:55 6,96 5000 seconden
Periode 11 50000-55000 13:55 – 15:15 7,39 5000 seconden
Periode 12 55000-60000 15:15 – 16:40 9,23 5000 seconden
Periode 13 60000-65000 16:40 – 18:00 7,67 5000 seconden
Periode 14 65000-70000 18:00 – 19:25 6,11 5000 seconden
Periode 15 70000-75000 19:25 – 20:50 8,10 5000 seconden
Periode 16 75000-80000 20:50 – 22:15 5,97 5000 seconden
Periode 17 80000-86400 22:15 – 00:00 5,26 6400 seconden
Tabel 5: Initiële verdeling van een dag in periodes in Departement 2
Om de implementatie in Excel en FlexSim iets eenvoudiger te maken en het aantal periodes te
beperken, worden twee opeenvolgende periodes samengenomen wanneer daarin een gelijkaardig
aantal oproepen verstuurd werd. De periodes worden in volgorde overlopen en enkel
samengenomen wanneer het verschil minder dan 0,5 procent bedraagt. Bijgevolg worden periodes 2
en 3, 5 en 6, 7 en 8, 10 en 11 en 16 en 17 per twee samengenomen. De uiteindelijke onderverdeling
in twaalf verschillende periodes met de corresponderende kans dat een oproep binnen die periode
valt, is terug te vinden in Tabel 6.
Page 102
78
Periode Tijdstippen [s] Tijdstippen [uu:mm] % oproepen Lengte Periode
Periode 1 0 - 5000 00:00 - 01:25 4,40 5000 seconden
Periode 2 5000 - 15000 01:25 - 04:10 6,68 10000 seconden
Periode 3 15000 - 20000 04:10 - 05:30 2,69 5000 seconden
Periode 4 20000 - 30000 05:30 - 08:20 9,66 10000 seconden
Periode 5 30000 - 40000 08:20 - 11:05 13,78 10000 seconden
Periode 6 40000 - 45000 11:05 - 12:30 6,11 5000 seconden
Periode 7 45000 - 55000 12:30 - 15:15 14,35 10000 seconden
Periode 8 55000 - 60000 15:15 - 16:40 9,24 5000 seconden
Periode 9 60000 - 65000 16:40 - 18:00 7,67 5000 seconden
Periode 10 65000 - 70000 18:00 - 19:25 6,11 5000 seconden
Periode 11 70000 - 75000 19:25 - 20:50 8,09 5000 seconden
Periode 12 75000 - 86400 20:50 - 00:00 11,22 11400 seconden
Tabel 6: Finale verdeling van een dag in periodes in Departement 2
Net zoals in het eerste departement worden alle 704 geregistreerde oproepen tijdens de
referentieweek nog eens uitgezet op het histogram op Figuur 27, waar de oproepen verdeeld
worden volgens de periode van de dag waarin ze vielen.
Figuur 27: Histogram van het aantal oproepen in Departement 2
31
47
19
68
97
43
101
65
54
43
57
79
0
20
40
60
80
100
120
00:00 -01:25
01:25 -04:10
04:10 -05:30
05:30 -08:20
08:20 -11:05
11:05 -12:30
12:30 -15:15
15:15 -16:40
16:40 -18:00
18:00 -19:25
19:25 -20:50
20:50 -00:00
Aan
tal o
pro
epen
Periode [uu:mm - uu:mm]
Page 103
79
7. Simulaties
7.1. Inleiding
In de vorige hoofdstukken werd het model opgebouwd en werd data gegenereerd om realistische
simulaties te kunnen analyseren. Deze simulaties worden in wat volgt uitgevoerd in allemaal
verschillende scenario’s. Er wordt begonnen met het simuleren van het traditionele scenario
(‘Traditioneel’)3, dat de huidige situatie zonder het omgevingsbewuste intelligente
verpleegoproepsysteem voorstelt. Vervolgens wordt de werking van het verpleegoproepsysteem
met de huidige regelset gesimuleerd in het Accio scenario (‘Accio’)³. De andere scenario’s kunnen
opgedeeld worden in twee categorieën zoals te zien is op Figuur 28. De eerste drie scenario’s dienen
om de effecten van bepaalde delen van de huidige beslissingsboom in bepaalde situaties te testen
(‘Effect 1’, ‘Effect 2’ en ‘Effect 3’)³ terwijl de volgende drie bedoeld zijn om verbeteringen aan de
huidige regelset te analyseren (‘Aanpassing 1’, ‘Aanpassing 2’ en ‘Aanpassing 3’)³. De scenario’s
worden telkens vergeleken met het Accio scenario en waar nodig ook met het traditionele scenario.
In dit hoofdstuk zullen twee verschillende soorten analyses teruggevonden worden. Vooreerst zijn er
de horizontale analyses, waarbij hetzelfde scenario gesimuleerd wordt voor telkens een verschillend
aantal oproepen per week. Dit gebeurt voor meerdere discrete waarden, gebaseerd op de originele
data die verkregen zijn bij Televic [7]. Zo wordt onderzocht wat de invloed is van het aantal oproepen
per week op de performantie van het systeem in dat scenario. Daarnaast zijn er de verticale analyses,
waarbij twee verschillende scenario’s van het systeem met elkaar vergeleken worden op basis van de
verschillende KPIs. Deze verticale analyses worden in beide scenario’s doorgevoerd op basis van drie
verschillende representatieve waarden voor het aantal oproepen per week. Op die manier kunnen
dus de effecten en verbeteringen gemeten worden. De analyses worden gedaan op de twee
verschillende departementen die reeds ingeleid werden in Hoofdstuk 6. Voor het eerste
departement wordt er gesimuleerd met 80, 160 en 240 oproepen per week en voor het tweede met
600, 700 en 800 oproepen per week. Voor de horizontale analyses worden hier nog enkele aantallen
bijgevoegd. Hierbij moet gelet worden op het feit dat dit oproepenaantal voor het eerste
departement verdeeld is over vijf dagen, terwijl dat bij het tweede departement over zeven dagen is.
De verschillende scenario’s die aan bod zullen komen worden in de volgende paragrafen
verduidelijkt. Eerst worden de scenario’s die een effect meten opgelijst en vervolgens de scenario’s
3 De namen die in deze paragraaf aan de verschillende scenario’s gegeven worden, zullen in wat volgt af
en toe gebruikt worden om naar deze scenario’s te verwijzen.
Page 104
80
die een verbetering aan de regelset analyseren. De rol die elk scenario speelt in de volledige analyse
kan zoals eerder aangehaald afgeleid worden uit Figuur 28. In ‘Effect 1’, ‘Effect 2’ en ‘Effect 3’ wordt
er getracht te onderzoeken hoe het huidige systeem in bepaalde situaties reageert. Het gaat hier niet
om aanpassingen van de regelset, maar om aanpassingen aan de omgeving waarin de regelset moet
functioneren. ‘Aanpassing 1’, ‘Aanpassing 2’ en ‘Aanpassing 3’ kunnen gezien worden als pogingen
tot verbetering van de regelset, waarbij deze verbeteringen geanalyseerd worden.
Figuur 28: Overzicht van de verschillende scenario's
7.1.1. ‘Traditioneel’
Het gaat hier om het scenario dat grotendeels beschreven werd in de literatuurstudie, waar het
huidige systeem dat in veel zorginstellingen nog van toepassing is, geëvalueerd wordt. Elke
verpleegkundige wordt toegewezen aan een bepaald aantal kamers, waarbij elk verantwoordelijk is
voor evenveel patiënten. In het geval van een assistentieoproep, wordt die oproep door de
zorgverlener verstuurd naar alle andere zorgverleners in het departement die op dat moment aan
het werk zijn. De samenstelling van het personeelsbestand met de respectievelijke
vertrouwensgetallen in dit scenario kan teruggevonden worden in Tabel 7 voor departement 1 en
Tabel 8 voor departement 2. Deze vertrouwensgetallen worden in het traditionele scenario echter
nog niet in rekening genomen, maar zijn hier al bijgevoegd omdat dit personeelsbestand ook voor
Page 105
81
‘Effect 1’ zal gebruikt worden. Tijdens de nachtshift op departement 2 werken er in realiteit twee
zorgverleners, waarvan één slechts gedurende 5/9 van de tijd. Dit implementeren in de simulatie was
moeilijk, waardoor de nachtshift in het traditionele scenario werd gesimuleerd met twee voltijds
werkende verpleegkundigen. Departement 1 is gesloten tijdens het weekend, waardoor enkel voor
departement 2 het personeelsbestand voor het weekend is toegevoegd. De resultaten van dit
scenario kunnen gezien worden als ‘benchmark’ die kunnen verbeterd worden door het invoeren van
een verbeterd verpleegoproepsysteem.
Shift Vroeg : 05u30 – 14u00 3 Verpleegkundigen (25, 50, 75)
Shift Laat: 13u30 – 22u00 2 Verpleegkundigen (25, 75)
Shift Nacht: 21u30 – 06u00 1 Verpleegkundige (25)
Shift Dag: 08u00 – 17u00 1 Logistiek Assistent (10) en 1 Hoofdverpleegkundige (50)
Tabel 7: Personeelsbestand ‘Traditioneel’ en ‘Effect 1’ op departement 1
Shift Vroeg : 05u30 – 14u00 5 Verpleegkundigen (10, 25, 50, 75, 90)
Shift Laat: 13u30 – 22u00 4 Verpleegkundigen (10, 25, 50, 75)
Shift Nacht: 21u30 – 06u00 2 Verpleegkundigen (25, 75)
Shift Dag: 08u00 – 17u00 1 Logistiek Assistent (10) en 1 Hoofdverpleegkundige (50)
Shift Weekend Vroeg: 05u30 – 14u00 4 Verpleegkundigen (25, 50, 75, 90)
Shift Weekend Laat: 13u30 – 22u00 3 Verpleegkundigen (25, 50, 75)
Shift Weekend Nacht: 21u30 – 06u00 2 Verpleegkundigen (25, 75)
Tabel 8: Personeelsbestand ‘Traditioneel’ en ‘Effect 1’ op departement 2
7.1.2. ‘Accio’
In het Accio scenario wordt de werking van het omgevingsbewuste intelligente
verpleegoproepsysteem met de huidige regelset getest. Het gaat hier om de regelset die rechtstreeks
uit de bestaande ontologie van Accio gehaald is en in de vorm van een beslissingsboom terug te
vinden is in Bijlage 11.3. De opbouw van het systeem dat in dit scenario gebruikt wordt, is terug te
vinden in Hoofdstuk 4. Eén van de voordelen van het nieuwe verpleegoproepsysteem is dat nu ook
verzorgers (‘Care’ zorgverleners) kunnen toegewezen worden aan oproepen waarvoor ze geschikt
zijn. Dit was in het traditionele scenario niet mogelijk, aangezien daar elke zorgverlener die oproepen
mag beantwoorden vast toegewezen wordt aan een bed. Deze zorgverlener is een verpleegkundige
van opleiding en is dus altijd in staat om de patiënt te helpen, behalve wanneer de tussenkomst van
een dokter nodig is. Het oproepen- en patiëntenbestand is wel gelijk aan dat van het traditionele
Page 106
82
scenario. De samenstelling van het personeelsbestand met de respectievelijke vertrouwensgetallen
kan teruggevonden worden in Tabel 9 voor departement 1 en Tabel 10 voor departement 2.
In departement 2 wordt er met een andere personeelsbezetting gewerkt in het weekend. Deze
zorgverleners die in het weekend werken zijn apart gedefinieerd in FlexSim, om eventuele verschillen
in werklast tussen week en weekend later te onderzoeken. Deze weekendshifts beginnen en eindigen
op dezelfde uren als in de week. Zoals eerder vermeld, werken er tijdens de nachtshift op
departement 2 twee zorgverleners, waarvan één slechts gedurende 5/9 van de tijd. In dit scenario
werd er tijdens de nachtshift één voltijds werkende verzorger en één voltijds werkende
verpleegkundige ingeschakeld.
Shift Vroeg : 05u30 – 14u00 2 Verpleegkundigen (25, 75) en 1 verzorger (25)
Shift Laat: 13u30 – 22u00 2 Verpleegkundigen (25,75)
Shift Nacht: 21u30 – 06u00 1 Verpleegkundige (25)
Shift Dag: 08u00 – 17u00 1 Logistiek Assistent (10) en 1 Hoofdverpleegkundige (50)
Tabel 9: Personeelsbestand ‘Accio’ op departement 1
Shift Vroeg : 05u30 – 14u00 3 Verpleegkundigen (10, 25, 50) en 2 verzorgers (75,90)
Shift Laat: 13u30 – 22u00 3 Verpleegkundigen (10, 25,75) en 1 verzorger (50)
Shift Nacht: 21u30 – 06u00 1 Verpleegkundigen (25) en 1 verzorger (75)
Shift Dag: 08u00 – 17u00 1 Logistiek Assistent (10) en 1 Hoofdverpleegkundige (50)
Shift Weekend Vroeg: 05u30 – 14u00 3 Verpleegkundigen (25, 50, 75) en 1 verzorger (90)
Shift Weekend Laat: 13u30 – 22u00 2 Verpleegkundigen (25, 50) en 1 verzorger (75)
Shift Weekend Nacht: 21u30 – 06u00 1 Verpleegkundige (25) en 1 verzorger (75)
Tabel 10: Personeelsbestand ‘Accio’ op departement 2
7.1.3. ‘Effect 1’: Personeelsbestand
Het scenario ‘Effect 1’ is qua regelset identiek aan het Accio scenario, maar hier wordt het
personeelsbestand van het traditionele scenario gebruikt om het verschil in performantie tussen
beide scenario’s nog verder te onderzoeken. In dit scenario wordt er dus geen gebruik gemaakt van
verzorgers (‘Care’), maar enkel van verpleegkundigen (‘Medical’). Aangezien deze verzorgers niet
dezelfde competenties bezitten als de verpleegkundigen en dus niet alle oproepen mogen
beantwoorden, kunnen het Accio en het traditionele scenario niet perfect vergeleken worden op vlak
van werkverdeling en wandelafstanden. ‘Effect 1’ wordt dus enerzijds gebruikt om de invloed van het
vervangen van verpleegkundigen door verzorgers te meten en anderzijds om de scenario’s met en
zonder het nieuwe verpleegoproepsysteem met elkaar te kunnen vergelijken op het vlak van
Page 107
83
werklastverdeling en wandelafstanden. Er wordt hier gewerkt met exact hetzelfde oproepen-,
patiënten- en personeelsbestand als in het traditionele scenario in zowel het eerste als het tweede
departement, maar wel met de regelset uit het Accio scenario.
7.1.4. ‘Effect 2’: Competentie
In de praktijk worden oproepen in een ziekenhuisafdeling soms behandeld door zorgverleners die de
competenties daarvoor enkel verkregen hebben vanwege hun lange staat van dienst. In theorie
bezitten zij echter niet de juiste kwalificaties om deze oproep te beantwoorden. In de vorige
scenario’s werd deze situatie toegelaten en was het in principe aan de zorgverlener zelf om te
beslissen of hij de oproep kon beantwoorden. In dit scenario wordt het model verplicht om ervoor te
zorgen dat er nooit een oproep wordt beantwoord door een zorgverlener die voor die bepaalde
oproep niet de juiste kwalificaties of diploma’s heeft. Dit zou in enkele uitzonderlijke gevallen tot
heel lange wachttijden kunnen leiden. Er wordt gebruik gemaakt van exact hetzelfde oproepen-,
personeels- en patiëntenbestand als in het Accio scenario.
Dit zal in de simulatie geïmplementeerd worden zoals het in de realiteit ook gebeurt. Een oproep kan
nog altijd toegewezen worden aan iemand zonder de correcte competenties, aangezien er geen
wijzigingen aan de regelset worden aangebracht. De eerste keer dat een oproep door het systeem
moet toegewezen worden aan een zorgverlener is het systeem zoals beschreven nog niet op de
hoogte van de reden van de oproep, waardoor deze situatie zich makkelijk kan voordoen. Op die
momenten kan het zijn dat de zorgverlener van zichzelf vindt dat hij de oproep wel aankan en deze
dus behandelt, ook al weet hij dat hij er niet voor opgeleid is. Het percentage oproepen waarbij er
niet voldaan is aan de competentie is dus zeker niet nul. De wijziging die is aangebracht aan de
simulatie zorgt ervoor dat de zorgverlener die de oproep krijgt en weet dat hij voor deze oproep de
vereiste competenties niet heeft, de oproep systematisch zal afwijzen. Zo blijft het systeem de
oproep terugkrijgen en is het verplicht om de oproep uiteindelijk toe te wijzen aan iemand die wel de
vereiste competenties heeft. Hier wordt dus onderzocht wat het effect is op de KPIs wanneer de
zorginstelling en zijn zorgverleners volledig de wet naleven.
7.1.5. ‘Effect 3’: Vertrouwensband
Tijdens het opbouwen van de ontologie was er onenigheid over het al dan niet implementeren van
een vertrouwensband in de beslissingsboom. Enkele gebruikers waren van mening dat dit niet veel
meerwaarde aan het systeem zou geven. Hier wordt onderzocht wat het effect op de KPIs is wanneer
de vertrouwensband buiten beschouwing gelaten wordt in de beslissingsboom. Er worden voor de
Page 108
84
rest geen wijzigingen doorgevoerd aan de regelset, noch aan het patiënten-, personeels- of
oproepenbestand.
7.1.6. ‘Aanpassing 1’: Status ‘Busy’
In ‘Aanpassing 1’ wordt een eerste aanpassing doorgevoerd in de regelset van het nieuwe
verpleegoproepsysteem. In de huidige regelset wordt een zorgverlener als bezet (‘Busy’)
geregistreerd wanneer hij ingelogd is in een kamer. Wanneer hij aan het wandelen is naar een
oproep, krijgt hij dus de status vrij (‘Free’) toegewezen, waardoor hij meer kans heeft om een nieuwe
oproep te ontvangen. Deze regelset houdt echter geen rekening met zijn bestemming. Het is goed
mogelijk dat de zorgverlener nog twee oproepen geaccepteerd heeft die hij nu wil gaan behandelen.
Een kleine aanpassing in de regelset maakt het mogelijk om rekening te houden met de oproepen die
al door de zorgverlener geaccepteerd zijn. Op die manier kan zijn status op ‘Busy’ blijven staan
wanneer hij nog oproepen geaccepteerd heeft die nog moeten beantwoord worden. Dit zou moeten
leiden tot kortere wachttijden, maar zou normaal gezien geen invloed mogen hebben op de andere
KPIs. Er wordt gebruik gemaakt van exact hetzelfde oproepen-, personeels- en patiëntenbestand als
in het Accio scenario.
7.1.7. ‘Aanpassing 2’: 1 zorgverlener
Wanneer de huidige regelset gebruikt wordt, is het mogelijk dat er na het doorlopen van de volledige
beslissingsboom meerdere zorgverleners tegelijk toegewezen worden aan dezelfde oproep,
waardoor ze soms met twee of meer aan een kamer toekomen. Dit werd ook als één van de nadelen
Figuur 29: Beslissingsboom voor het toekennen van de status aan een 'Staff Member' (SM) bij Accio scenario
Figuur 30: Beslissingsboom voor het toekennen van de status aan een 'Staff Member' (SM) bij ‘Aanpassing 1’
Page 109
85
van het traditionele scenario aangehaald. Na het doorvoeren van ‘Aanpassing 2’ wordt de oproep,
waarvoor er meerdere zorgverleners overblijven na het doorlopen van de boom, toegewezen aan de
zorgverlener die tot dan toe het minst aantal oproepen beantwoord heeft. Op die manier wordt
geprobeerd om ervoor te zorgen dat iedere zorgverlener een vergelijkbaar deel van zijn shift aan
andere noodzakelijke taken kan spenderen en dat er nooit meer twee zorgverleners tegelijk naar
dezelfde kamer gestuurd worden. Er wordt gebruik gemaakt van exact hetzelfde oproepen-,
personeels- en patiëntenbestand als in het Accio scenario.
7.1.8. ‘Aanpassing 3’: Status vs Vertrouwensband
Veel op voorhand gedefinieerde KPIs, zoals het percentage oproepen dat storend was voor een
zorgverlener, hangen rechtstreeks of onrechtstreeks af van de laatste tak van de boom, die
differentieert op basis van de status en locatie van de zorgverlener. Wat gebeurt er nu wanneer deze
Figuur 31: Deel van de beslissingsboom uit Accio scenario dat een oproep toewijst aan een zorgverlener (SM) op basis van status en locatie.
Figuur 32: Deel van de beslissingsboom met ‘Aanpassing 2’ dat een oproep toewijst aan een zorgverlener (SM) op basis van status en locatie.
Page 110
86
tak vroeger in de boom geplaatst wordt? Na het doorvoeren van ‘Aanpassing 3’ wordt in de
beslissingsboom eerst gedifferentieerd op basis van de status en de locatie en daarna indien nodig
pas op basis van de vertrouwensband. Deze verandering wordt visueel voorgesteld op Figuur 34. In
dit geval wordt de vertrouwensband dus wel nog in rekening gebracht, in tegenstelling tot ‘Effect 3’,
maar deze zal pas aangesproken worden wanneer er na de tak die differentieert op basis van de
status en locatie nog zorgverleners overschieten. Hier is een toewijzing enkel en alleen op basis van
vertrouwensband, zonder eerst naar de locatie en de status van de zorgverlener te kijken dus
uitgesloten. Zo wordt er meer gebruik gemaakt van zorgverleners die het minder druk hebben en
wordt er pas indien nodig gekeken naar de vertrouwensband.
Figuur 33: Deel van de beslissingsboom uit Accio scenario waar eerst vertrouwensband gecontroleerd wordt en dan pas status en locatie
Figuur 34: Deel van de beslissingsboom met 'Aanpassing 3' waar eerst status en locatie gecontroleerd worden en dan pas vertrouwensband
Page 111
87
7.2. Resultaten van de scenario-analyse
Bij de analyse en de vergelijking van de verschillende scenario’s, effecten en aanpassingen worden in
wat volgt voornamelijk de resultaten besproken waarbij er een duidelijke invloed te zien is. Sommige
KPIs worden in de komende paragrafen bij bepaalde scenario’s achterwege gelaten omdat er geen
duidelijk verband kan gevonden worden. In onderstaande paragrafen en in Hoofdstukken 8 en 9 zal
geprobeerd worden om een verklaring te zoeken waarom er geen verband teruggevonden werd voor
deze KPIs in die bepaalde scenario’s.
7.2.1. Horizontale analyse van ‘Accio’
Hier wordt de performantie van het verpleegoproepsysteem van Accio getest voor enkele discrete
aantallen oproepen per week, van 40 oproepen per week tot 280 oproepen per week in stappen van
40 oproepen. De oorspronkelijke regelset uit de ontologie wordt gebruikt en er wordt in het
personeelsbestand ook gebruik gemaakt van verzorgers waar mogelijk. De resultaten uit deze
simulaties worden in deze paragraaf besproken. In deze analyse zullen uitzonderlijk de waarden van
alle KPIs besproken worden aangezien ze als referentiewaarden gelden voor de analyse van de
verdere effecten en aanpassingen die altijd betrekking hebben tot dit scenario.
Departement 1
Wanneer gekeken wordt naar de prestaties op het vlak van de wachttijden voor de patiënten,
worden enkele trends duidelijk. Zowel de gemiddelde als de maximale wachttijd stijgt naarmate het
aantal oproepen per week stijgt. De gemiddelde wachttijd stijgt van ongeveer 37 seconden voor 40
oproepen per week naar ongeveer 53 seconden voor 280 oproepen per week. Voor de maximale
wachttijd is dat een stijging van respectievelijk 600 seconden naar ongeveer 1700 seconden. Beide
wachttijden zijn uitgezet in functie van het aantal oproepen per week op Figuur 35 en Figuur 36.
Deze resultaten zijn het gevolg van de hogere werkdruk voor de zorgverleners, waardoor ze niet
altijd even snel kunnen reageren op binnenkomende oproepen. De kans dat een zorgverlener een
oproep afwijst of negeert, is immers groter wanneer hij bezig is met het behandelen van een andere
oproep dan wanneer hij bezig is met het uitvoeren van bijvoorbeeld een controleronde.
Page 112
88
Figuur 35: Gemiddelde wachttijd in functie van het aantal oproepen per week (‘Accio’ op Departement 1)
Figuur 36: Maximale wachttijd in functie van het aantal oproepen per week (‘Accio’ op Departement 1)
Niet alleen de absolute waarden van de wachttijden stijgen naarmate het aantal oproepen per week
vergroot, maar ook de standaardafwijking op deze waarden groeit. De spreiding op deze wachttijden
wordt dus groter, wat ook minder gewenst is. Patiënten kunnen in dit geval minder goed inschatten
hoe lang ze zullen moeten wachten.
Voor deze horizontale analyse werd ook een grafiek opgesteld om de tendens in de wachttijden van
alle oproepen in de simulatie voor te stellen. Deze grafiek is weergegeven op Figuur 37. Aangezien
het aantal oproepen met een wachttijd langer dan 200 seconden verwaarloosbaar is, werd op deze
grafiek met die oproepen geen rekening gehouden.
Figuur 37: Percentage oproepen in functie van de wachttijden (‘Accio’ op Departement 1)
0
10
20
30
40
50
60
40 80 120 160 200 240 280
Gem
idd
eld
e w
ach
ttijd
[s]
Aantal oproepen per week
0
250
500
750
1000
1250
1500
1750
2000
40 80 120 160 200 240 280
Max
imal
e w
ach
ttijd
[s]
Aantal oproepen per week
0%
5%
10%
15%
20%
25%
30%
35%
0 20 40 60 80 100 120 140 160 180 200
Per
cen
tage
beh
and
eld
e o
pro
epen
Wachttijd [s]
80 CALLS
160 CALLS
240 CALLS
Page 113
89
Het verloop van de wachttijden heeft ongeacht het aantal oproepen per week ongeveer dezelfde
vorm. Voor een hoger aantal oproepen per week ligt de eerste piek echter lager. Op Figuur 37 is te
zien dat de piek zich bevindt op een wachttijd van iets meer dan 20 seconden waardoor een groot
deel van de oproepen dus wordt afgehandeld binnen die tijd. Dit aantal wordt inderdaad kleiner
naarmate er meer oproepen per week verstuurd worden. De reden hiervoor is opnieuw omdat de
zorgverleners in die situaties vaker bezig zijn met het behandelen van een andere oproep, waardoor
de kans dat ze de nieuwe binnenkomende oproep doorverwijzen of eerst telefonisch beantwoorden
vergroot. Op Figuur 38 is te zien dat het percentage oproepen dat minstens eenmaal wordt
doorverwezen inderdaad stijgt naarmate het aantal oproepen per week stijgt. Van alle oproepen die
doorverwezen werden, werd het gemiddelde aantal keer dat zo’n oproep doorverwezen werd
berekend. Het is immers mogelijk dat een oproep op een bepaald moment meer dan vijf keer wordt
doorverwezen omdat net op dat moment niemand de oproep kan beantwoorden. Dat gemiddelde
wordt niet beïnvloed door het aantal oproepen per week en bedroeg voor alle gevalleen ongeveer
1,57. Door de structuur van dit departement met alle kamers geschikt rond de centrale verpleegbasis
is het voor de zorgverlener haalbaar om bij de meeste patiënten binnen de 20 seconden na het
versturen van de oproep ter plaatse te zijn. Dit geldt uiteraard niet wanneer de zorgverlener eerst
een telefonisch gesprek heeft met de patiënt.
Wanneer naar de oproepen met langere wachttijden gekeken wordt, valt op dat het verschil
omgedraaid is. Deze wachttijden komen meer voor tijdens drukkere weken, waardoor de trendlijn
van weken met 240 oproepen voor wachttijden langer dan 60 seconden het hoogst komt te liggen.
De oproepen met langere wachttijden zijn diegene waarbij de zorgverlener eerst belt naar de
patiënt, een andere oproep onderbreekt of zijn huidige taak afwerkt vooraleer hij vertrekt. De
wachttijd is immers de geregistreerde tijd vanaf het tijdstip van lanceren totdat de eerste
zorgverlener toekomt in de kamer om de patiënt te helpen. Of de patiënt al dan niet telefonisch
gecontacteerd is tijdens deze wachttijd wordt hier niet in rekening genomen.
Algemeen kan gesteld worden dat het versturen van meer oproepen per week invloed heeft op de
uiterste wachttijden, waarbij de kortere wachttijden meer voorkomen wanneer er minder oproepen
per week verstuurd worden en de langere wachttijden wanneer er meer oproepen per week
verstuurd worden.
Page 114
90
Figuur 38: Percentage oproepen dat minstens eenmaal werd doorverwezen (‘Accio’ op Departement 1)
Wanneer er op Figuur 39 gekeken wordt naar het aantal zorgverleners dat per oproep tegelijk
opgeroepen wordt, kan er niet echt een trend teruggevonden worden in functie van het aantal
oproepen per week. Dit aantal ligt in dit geval immers al heel laag, waaruit kan afgeleid worden dat
de beslissingsboom op dit departement heel selectief is. Dit zorgt ervoor dat er na het overlopen van
de beslissingsboom meestal maar één zorgverlener overschiet, slechts in 5% van de gevallen wordt
de oproep toegewezen aan twee of meer zorgverleners tegelijk. Omdat dit gemiddeld aantal gekozen
zorgverleners al zo laag ligt, heeft het opdrijven van het aantal oproepen per week op deze KPI nog
weinig effect. Verder in dit hoofdstuk zal er gezocht worden naar een verklaring voor dit lage
gemiddelde in dit departement.
Figuur 39: Gemiddeld aantal zorgverleners dat geselecteerd werd per oproep (‘Accio’ op Departement 1)
Wanneer de KPIs betreffende de performantie van het systeem op het vlak van competentie en
vertrouwensband geanalyseerd worden, kunnen hieruit geen of heel weinig conclusies getrokken
worden over de invloed van het aantal oproepen per week. De enige KPI die een duidelijke trend
vertoont, is het percentage oproepen dat moest behandeld worden door een zorgverlener met de
competentie verkregen uit ervaring. In het huidige model is geweten dat dit om de hoofdverpleger
0%
5%
10%
15%
20%
25%
30%
35%
40 80 120 160 200 240 280
Per
cen
tage
do
orv
erw
ezen
o
pro
epen
Aantal oproepen per week
1
1,05
1,1
1,15
1,2
1,25
1,3
1,35
1,4
40 80 120 160 200 240 280
Aan
tal g
esel
ecte
erd
e zo
rgve
rlen
ers
Aantal oproepen per week
Page 115
91
gaat die in geval van nood een zorgoproep gaat afhandelen omdat er echt niemand anders
beschikbaar is. Dit is ook terug te vinden in de tabel in Bijlage 11.2. In realiteit heeft een
hoofdverpleger uiteraard wel de competentie om alle oproepen te beantwoorden, maar aangezien
deze veel ander werk heeft en het dus niet gewenst is dat deze gestoord wordt om oproepen te
beantwoorden, werden deze competenties voor de hoofdverpleger als ervaring geclassificeerd. Dit
zorgt ervoor dat de hoofdverpleger enkel in het slechtste geval opgeroepen wordt en dat er ook een
zware kost in de kostenfunctie aan zou gekoppeld zijn wanneer deze zich hiermee moet bezig
houden. Het percentage blijft ongeveer gelijk zolang het aantal oproepen per week lager blijft dan
160. Voor de gevallen met meer oproepen per week is een duidelijke stijging van datzelfde
percentage op te merken naarmate dat aantal naar 280 evolueert. Dit kan gezien worden op Figuur
40 en is het gevolg van het feit dat bij meer oproepen per week, er meer zorgverleners bezig zijn met
het behandelen van oproepen, waardoor de kans op het afwijzen van een binnenkomende oproep
vergroot. Pas als alle zorgverleners met de correcte competentie afgewezen hebben, komen deze
met de competentie als ervaring en deze zonder de competentie in aanmerking.
Op het moment dat de oproep voor het eerst binnenkomt, weet het systeem niet wat de reden
ervan is, waardoor het deel van de beslissingsboom betreffende de competentie niet in rekening
wordt gebracht bij het toewijzen van de oproep. Op die manier is het dus mogelijk dat het systeem
een medische oproep de eerste maal toewijst aan een verzorger, die dan zelf beslist of hij de oproep
aankan of niet. In departement 1 werkt er enkel een verzorger tijdens de vroege shift, die tijdens die
shift steevast wordt toegewezen aan de langdurige wasronde. Op die manier heeft de verzorger een
groot deel van de tijd de status ‘Busy’, waardoor hij weinig uitgekozen wordt en het geval waarin
deze verzorger een medische oproep beantwoordt, die niet binnen zijn competenties ligt, niet zoveel
voorkomt. Slechts voor iets meer dan 1% van de oproepen wordt deze persoon bij de eerste
lancering opgeroepen. Wanneer er meer verzorgers werken, zoals in departement 2, zou dit
waarschijnlijk meer voorvallen. In deze implementatie van het model is nog niet inbegrepen dat deze
verzorger de oproep niet mag beantwoorden, dit wordt later in ‘Effect 2’ geïmplementeerd.
Page 116
92
Figuur 40: Percentage oproepen dat werd behandeld door een zorgverlener met de vereiste competentie als ervaring (‘Accio’ op Departement 1)
Een ander gevolg van deze hogere werkdruk bij een hoger aantal oproepen per week is de stijging in
het aantal keer dat een zorgverlener tijdens zijn belangrijke opdrachten, zoals bijvoorbeeld het
voorbereiden van de medicatieronde of het behandelen van een oproep, gestoord wordt. Een
zorgverlener wordt best zo weinig mogelijk gestoord om het risico op fouten te minimaliseren,
waardoor een groter aantal oproepen in dit geval minder gunstig is. Deze stijging is terug te vinden
op Figuur 41.
Figuur 41: Percentage oproepen dat storend was voor de geselecteerde zorgverlener (‘Accio’ op Departement 1)
Ten slotte worden in deze horizontale analyse de wandelafstanden van de verschillende
zorgverleners onder de loep genomen. Het verloop van de gemiddelde wandelafstand per shift per
zorgverlener in functie van het aantal oproepen per week is terug te vinden op Figuur 42. De
resultaten zijn voor de hand liggend. De hogere werkdruk zorgt voor meer afgelegde meters in het
departement. Deze stijging is niet zo sterk aangezien de zorgverleners buiten het beantwoorden van
oproepen ook taken moeten uitvoeren over heel het departement, waarbij ze ook grote afstanden
moeten afleggen.
0,00%
0,20%
0,40%
0,60%
0,80%
1,00%
1,20%
40 80 120 160 200 240 280
Per
cen
tage
beh
and
eld
e o
pro
epen
Aantal oproepen per week
0%
10%
20%
30%
40%
50%
40 80 120 160 200 240 280
Per
cen
tage
sto
ren
de
op
roep
en
Aantal oproepen per week
Page 117
93
Figuur 42: Gemiddeld afgelegde wandelafstand per shift per zorgverlener ('Accio' op Departement 1)
Het enige wat merkwaardig kan genoemd worden is het lage en dalende verloop van de gemiddelde
wandelafstand van de verzorger (‘Care_Vroeg’). Dit kan verklaard worden door het feit dat deze
verzorger werkt tijdens de vroege shift, waarbij hij altijd aan de hygiënische ronde wordt
toegewezen. Deze wasronde neemt een groot deel van de tijd van zijn shift in, waardoor hij minder
tijd heeft voor zijn opdrachten die hem naar willekeurige plaatsen in het departement sturen, wat
ook de veel lagere wandelafstand in vergelijking met zijn collega’s verklaart. Hoe meer oproepen er
verstuurd worden, hoe meer kans er is dat deze verzorger tijdens zijn wasronde tussen het wassen
van twee patiënten door opgeroepen wordt. Hoe meer hij onderbroken wordt, hoe langer zijn
wasronde duurt, dus hoe minder tijd hij heeft voor de rest van zijn opdrachten waarbij hij het hele
departement moet doorkruisen, wat de lichte daling van de wandelafstand verklaart.
Departement 2
In wat volgt worden de resultaten van dezelfde horizontale analyse van het Accio scenario besproken
maar nu op het tweede departement. Er zal vooral ingegaan worden op de resultaten die niet perfect
in lijn liggen met de bekomen resultaten op het eerste departement voor hetzelfde scenario.
1
1,5
2
2,5
3
3,5
4
40 80 120 160 200 240 280
Afg
eleg
de
wan
del
afst
and
[km
]
Aantal oproepen per week
FemaleNurse_Nacht FemaleNurse_Vroeg MaleNurse_Vroeg
Care_Vroeg FemaleNurse_Laat MaleNurse_Laat
Page 118
94
Wat het verloop van de wachttijden betreft zijn er weinig verschillen op te merken met het andere
departement. De gemiddelde wachttijd vertoont dezelfde stijgende trend in functie van het aantal
oproepen per week, zij het iets geleidelijker, van 45 seconden voor 500 oproepen per week tot 51
seconden voor 800 oproepen per week. De gemiddelde wachttijden liggen wel hoger voor dit
departement in vergelijking met departement 1, wat een gevolg is van het veel hogere aantal
oproepen per week tegenover een in verhouding minder grotere personeelsbezetting. Ook de
minder gecentraliseerde structuur van het departement heeft een negatief effect op deze wachttijd.
Wat ongunstig is aan deze structuur wordt onderaan deze pagina meer verduidelijkt. De
personeelsbestanden van departement 1 en 2 kunnen vergeleken worden in respectievelijk Tabel 7
en Tabel 9 op pagina’s 81 en 82, waaruit blijkt dat er geen verdubbeling is van het aantal
zorgverleners voor het verwerken van toch een veelvoud van het aantal oproepen. Op het vlak van
maximale wachttijd is er niet echt een trend terug te vinden in functie van het aantal oproepen per
week. Dit maximum varieert tussen de 1300 en 2000 seconden, wat ook duidelijk hoger ligt dan de
maxima die gevonden werden in departement 1.
De conclusies en verklaringen die voor departement 1 gegeven werden betreffende de wachttijden
worden dus met deze simulaties bevestigd. Ook het gemiddeld aantal keer dat een oproep werd
doorverwezen stijgt hier op dezelfde manier als in departement 1, waarbij dat gemiddelde ook
ongeveer dezelfde waarden aanneemt.
Op Figuur 43 is dezelfde grafiek terug te vinden als diegene die geanalyseerd werd op het eerste
departement. Het betreft het verloop van het percentage oproepen in functie van de wachttijden. De
piek die te zien is voor wachttijden van twintig seconden ligt een kleine vijf procent lager dan
diezelfde piek in Figuur 37. Een deel van de oproepen is verschoven naar het lokale maximum rond
veertig seconden. Dit is te wijten aan het verschil in structuur van het departement en niet aan het
hogere aantal oproepen, aangezien hetzelfde verloop werd teruggevonden bij een simulatie met
slechts 200 oproepen per week op dit departement. De kamers bevinden zich in dit departement op
één lijn allemaal aan dezelfde kant van de gang. De minder gecentraliseerde structuur zorgt er dus
voor dat patiënten vaker net iets langer moeten wachten vooraleer er een zorgverlener bij hen komt
om hen te helpen. Voor het overige is het verloop nagenoeg gelijk voor beide departementen.
Page 119
95
Figuur 43: Percentage oproepen in functie van de wachttijden (‘Accio’ op Departement 2)
Een verschil dat in dit departement wel duidelijk optreedt in tegenstelling tot in departement 2 is de
daling van het gemiddeld aantal zorgverleners dat toegewezen wordt aan een oproep in functie van
het aantal oproepen per week. Dit is terug te vinden op Figuur 44. In departement 2 vertoonde dit
gemiddelde een willekeurig verloop in functie van dat aantal oproepen, omdat het door het lage
aantal personeelsleden al zo lage waarden aannam. In dit departement werken er bijna dubbel
zoveel zorgverleners, wat de kans dat er meerdere zorgverleners aan alle voorwaarden voldoen
vergroot. Het gemiddelde ligt dus systematisch hoger op dit departement, maar vertoont nu ook de
duidelijke daling in functie van het aantal oproepen die verwacht werd in departement 1. Deze daling
is te wijten aan het feit dat bij een hogere werkdruk de zorgverleners meer de status ‘Busy’ hebben
waardoor er meer kan gedifferentieerd worden.
Een ander gevolg van het groter personeelsbestand is het lager aantal oproepen waarvoor een
zorgverlener gestoord moest worden. Aangezien er meer zorgverleners aanwezig zijn, is de kans
groter dat de beslissingsboom in het laatste deel komt dat rekening houdt met de status van de
zorgverlener. De boom heeft dus meer kans om te differentiëren op basis van de status. Dat leidt
ertoe dat het percentage oproepen waarvoor iemand moet gestoord worden beduidend lager ligt
dan in departement 1. Het stijgende verloop in functie van het aantal oproepen is terug te vinden op
Figuur 45 en is wel vergelijkbaar met dat van het eerste departement.
0%
5%
10%
15%
20%
25%
30%
35%
0 20 40 60 80 100 120 140 160 180 200
Per
cen
tage
beh
and
eld
e o
pro
epen
Wachttijd [s]
600 CALLS
700 CALLS
800 CALLS
Page 120
96
Figuur 44: Gemiddeld aantal zorgverleners dat geselecteerd werd per oproep (‘Accio’ op Departement 2)
Figuur 45: Percentage oproepen dat storend was voor de geselecteerde zorgverlener (‘Accio’ op Departement 2)
In departement 1 werd de stijgende trend van het aantal oproepen dat beantwoord werd door
iemand met de competentie als ervaring in functie van het aantal oproepen per week besproken. Dit
geval komt in departement 2 niet meer voor, de hoofdverpleger wordt dus nooit meer toegewezen
aan een oproep. Dit is het gevolg van het groter aantal zorgverleners dat nu aan het werk is,
waardoor de kans dat iedereen de oproep afwijst veel kleiner is. Wanneer gekeken wordt naar de
oproepen die beantwoord werden door een zorgverlener zonder de vereiste competenties, dus ook
niet als ervaring, kunnen ook andere conclusies getrokken worden dan in het eerste departement.
Zoals reeds aangehaald bij departement 1, gebeurt het tijdens de eerste lancering van de oproep
soms dat een oproep wordt toegewezen aan iemand met de verkeerde competentie aangezien het
systeem de reden van de oproep nog niet kent. In dit departement werken er meer verzorgers,
waarvan slechts één verzorger toegewezen wordt aan de wasronde, zodat de kans dat een medische
oproep bij de eerste lancering aan een verzorger wordt toegewezen groter is dan bij het eerste
departement. Dat blijkt ook uit het percentage oproepen dat verstuurd werd naar een zorgverlener
zonder de correcte competentie, wat nu met een gemiddelde van 8 procent een stuk hoger ligt dan
de 1 procent die gevonden werd in departement 1.
Op het vlak van confidentie zijn er opnieuw weinig conclusies te trekken over het verloop in functie
van het aantal oproepen per week. Het percentage oproepen dat verstuurd werd naar een
zorgverlener waarmee de patiënt geen persoonlijke vertrouwensband heeft, stijgt wel licht in functie
van het aantal oproepen per week. De percentages van de oproepen waarin een zorgverlener zonder
persoonlijke vertrouwensband toegewezen werd zijn heel gelijkaardig aan het vorige departement.
Een relevante vergelijking op vlak van de wandelafstanden met departement 1 is moeilijk aangezien
er hier meer zorgverleners werken en er ook meer oproepen verstuurd worden. De stijgende trend
1
1,05
1,1
1,15
1,2
1,25
1,3
1,35
1,4
600 650 700 750 800
Aan
tal g
esel
ecte
erd
e zo
rgve
rlen
ers
Aantal oproepen per week
0%
5%
10%
15%
20%
25%
600 650 700 750 800
Per
cen
tage
sto
ren
de
op
roep
en
Aantal oproepen per week
Page 121
97
die gevonden werd in departement 1 wordt hier ook teruggevonden en de afgelegde afstanden zijn
groter. Dit is het gevolg van de minder gecentraliseerde structuur van het departement en het veel
grotere aantal oproepen terwijl het aantal zorgverleners niet evenredig gestegen is.
7.2.2. ‘Accio’ vs ‘Traditioneel’
In deze verticale analyse is het de bedoeling om de werking van het verpleegoproepsysteem zoals
het in het Accio project opgebouwd is, te testen tegenover de traditionele situatie. In het Accio
scenario worden enkele zorgverleners vervangen door verzorgers. Deze personeelswissel volgt uit de
literatuur [58] waar gesteld wordt dat minstens 65% van de zorgverleners bepaalde kwalificaties
moet bezitten en dus een medische zorgverlener moet zijn. De vergelijking met het scenario waarin
deze aanpassing aan het personeelsbestand niet gebeurd is, volgt in paragraaf 7.2.3.
Departement 1
In het traditionele geval krijgt elke zorgverlener evenveel bedden toegewezen in naburige kamers. In
beide gevallen worden uit een bepaalde zone van kamers meer oproepen verstuurd dan uit een
andere. Bed 1 tot 6 versturen samen 40 procent van de oproepen, bed 7 tot 12 25 procent van de
oproepen en bed 13 tot 18 slechts 15 procent van de oproepen. De resterende 10 procent wordt
verstuurd vanuit de publieke ruimtes. Dit komt in de realiteit ook voor en is net de reden waarom er
in de traditionele situatie nooit een eerlijke verdeling van de werklast kan gerealiseerd worden. Door
deze differentiatie door te voeren, zouden de voordelen van het Accio oproepsysteem nadrukkelijker
naar boven moeten komen. Tijdens de vroege shift wordt zoals beschreven één zorgverlener
vervangen door een verzorger.
Het verloop van de gemiddelde wachttijd is in beide scenario’s gelijkaardig zoals kan afgeleid worden
uit Figuur 46. Enkel en alleen op basis daarvan kan dus geen conclusie genomen worden over de
werking van het nieuwe systeem. Bij het Accio scenario worden wel iets lagere maximale wachttijden
bekomen zoals te zien is op Figuur 47, maar dit kan niet als enige argument dienen om een
ziekenhuis te overtuigen het nieuwe systeem te implementeren. Wanneer naar de
standaardafwijking op deze gemiddelde wachttijd in Tabel 11 gekeken wordt, valt er op te merken
dat deze telkens beduidend hoger ligt in het traditionele scenario. Er is echter geen tendens terug te
vinden in dat verschil tussen beide standaardafwijkingen, het fluctueert tussen ongeveer 6 en
ongeveer 30 seconden.
Page 122
98
Figuur 46: Gemiddelde wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Traditioneel’ op Departement 1)
Figuur 47: Maximale wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Traditioneel’ op Departement 1)
Aantal oproepen/week 40 80 120 160 200 240 280
Gemiddelde Accio 37,77 41,9 43,29 47,25 50,59 51,96 53,4
Traditioneel 57,86 69,04 71,5 79,06 88,88 89,5 91
Standaardafwijking Accio 39,15 40,1 43,18 46,87 49,52 50,29 57,67
Traditioneel 69,22 75,76 82,86 92,58 99,74 99,99 121,27
Tabel 11: Gemiddelde wachttijd [s] en zijn standaardafwijking [s] (‘Accio’ vs ‘Traditioneel’ op Departement 1)
Wanneer het aantal oproepen uitgezet wordt ten opzichte van de wachttijd zoals tijdens de
horizontale analyse reeds gedaan werd, kan wel een duidelijk verschil opgemerkt worden. Hierbij
werden opnieuw de wachttijden langer dan 200 seconden uitgesloten omdat deze geen meerwaarde
bieden aan de analyse. Dit werd in Figuur 48 gedaan voor beide scenario’s met elk 160 oproepen per
week, omdat dit het midden van de geteste aantallen is. Het valt op dat, hoewel de gemiddelden van
de wachttijden voor beide systemen niet veel verschillend zijn, er grote verschillen zijn in de
verdeling van die wachttijden, wat ook verklaart waarom de standaardafwijkingen zo verschillend
zijn. Zoals reeds aangehaald zijn de standaardafwijkingen van het oude systeem hoger dan van het
nieuwe systeem. Ongeveer 70 % van de wachttijden in het traditionele scenario ligt lager dan 20
seconden4, terwijl dit voor het Accio scenario ongeveer 40 % is. Dit voordeel van het traditionele
systeem blijft niet aanhouden aangezien er veel meer wachttijden lager dan 120 seconden bereikt
worden in het Accio scenario dan in het traditionele scenario, respectievelijk ongeveer 92,5 % en
82.5 %. Het percentage oproepen dat pas na een wachttijd van langer dan 200 seconden wordt
beantwoord, bedraagt bij het traditionele scenario bijna 5% tegenover 2.5% voor het Accio scenario.
4 Een wachttijd korter 20 seconden wordt in deze thesis als een snel antwoord beschouwd en korter dan
120 seconden als een aanvaardbare wachttijd, waarbij geen enkele patiënt problemen zal maken. Hier werden geen specifieke waarden voor gevonden in de literatuur.
0
10
20
30
40
50
60
40 80 120 160 200 240 280
Gem
idd
eld
e w
ach
ttijd
[s]
Aantal oproepen per week
0
250
500
750
1000
1250
1500
1750
2000
40 80 120 160 200 240 280
Max
imal
e w
ach
ttijd
[s]
Aantal oproepen per week
Accio
Traditioneel
Page 123
99
Deze resultaten zijn grotendeels te verklaren door het feit dat zorgverleners in het traditionele
scenario niet de mogelijkheid hebben om een oproep door te verwijzen. Ook bezitten ze nog geen
informatie over de binnenkomende oproep. De eerste piek die in het histogram van het traditionele
scenario teruggevonden wordt, verzamelt de wachttijden van de oproepen die onmiddellijk
beantwoord worden door de zorgverleners, terwijl de tweede piek de wachttijden van de oproepen
verzamelt waarbij de zorgverlener eerst zijn huidige taak afwerkt en de oproep erna pas
beantwoordt. Andere situaties zijn niet mogelijk, waardoor het vloeiende patroon van het Accio
scenario niet bereikt kan worden. Dat vloeiende patroon is dus het gevolg van het ontstaan van
nieuwe situaties die kunnen optreden door het invoeren van het Accio verpleegoproepsysteem. Zo
kan een oproep bijvoorbeeld één of meerdere keren doorverwezen worden, waardoor de
wachttijden veel gevarieerdere waarden kunnen aannemen.
Figuur 48: Percentage oproepen in functie van de wachttijden (‘Accio’ vs ‘Traditioneel’ op Departement 1)
Wanneer de gemiddelde wandelafstanden per shift in beide scenario’s tegenover elkaar gezet
worden, zie Figuur 42 op pagina 93 en Figuur 49, valt het op dat er grote verschillen optreden voor
enkele zorgverleners. Voor andere zorgverleners blijft het verloop in functie van het aantal oproepen
per week gelijk. De algemene trend die duidelijk wordt is dat de wandelafstand stijgt naarmate het
aantal oproepen per week vermeerdert. Dat deze stijging heel traag gebeurt, is het gevolg van de
geïmplementeerde vaste en willekeurige rondes waarbij de zorgverleners voortdurend heen en weer
door het departement lopen, wat ook in de werkelijkheid zo is. Daardoor leggen de zorgverleners
onafhankelijk van het aantal oproepen al een grote wandelafstand af.
Voor de zorgverlener die verantwoordelijk is voor de shift tijdens de nacht is het verloop van de
wandelafstand in functie van het aantal oproepen per week bijna identiek in beide scenario’s. Dit is
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
50%
0 20 40 60 80 100 120 140 160 180 200
Per
cen
tage
beh
and
eld
e o
pro
epen
Wachttijd [s]
Accio
Traditioneel
Page 124
100
te verklaren door het feit dat de systemen van beide scenario’s heel gelijkaardig zijn wanneer er
slechts één zorgverlener aan het werk is. De belangrijkste meerwaarde die het Accio oproepsysteem
hier biedt, is dat de zorgverlener contact kan opnemen met de patiënt om meer informatie te vragen
en om te melden dat hij binnen enkele minuten zal komen. Deze meerwaarde heeft echter geen
invloed op de KPIs die in deze analyses onderzocht worden.
De wandelafstand tijdens de late shift in het Accio scenario is beter verdeeld onder beide medische
zorgverleners. De totale wandelafstand die door beide zorgverleners is afgelegd over de hele shift is
heel gelijkaardig, maar bij het traditionele scenario moest de ene zorgverlener meer meters afleggen
dan de andere omdat hij verantwoordelijk was voor bedden met patiënten die meer hulp behoeven.
In het Accio scenario met het nieuwe oproepsysteem, worden de oproepen verdeeld over alle
aanwezig zorgverleners en zijn deze afstanden bijgevolg praktisch gelijk.
Figuur 49: Gemiddeld afgelegde wandelafstand per shift per zorgverlener ('Traditioneel' op Departement 1)
In deze verticale analyse tussen beide scenario’s zijn de personeelsbestanden zoals eerder
aangehaald niet gelijk. In het nieuwe systeem is er een verzorger (‘Care’) tijdens de vroege shift om
de twee medische zorgverleners te assisteren. In het oude systeem wordt een verzorger nog niet
toegewezen aan oproepen, dus is deze vervangen door een verpleegkundige (‘Medical’). Op beide
1,5
2
2,5
3
3,5
4
40 80 120 160 200 240 280
Afg
eleg
de
wan
del
afst
and
[km
]
Aantal oproepen per week
KM/shift FemaleNurse_Nacht KM/shift FemaleNurse1_VroegKM/shift FemaleNurse2_Vroeg KM/shift MaleNurse_VroegKM/shift FemaleNurse_Laat KM/shift MaleNurse_Laat
Page 125
101
grafieken wordt de wandelafstand van deze beide zorgverleners in elk scenario voorgesteld door de
paarse lijn. Op die manier kunnen deze drie personen de oproepen wel beter onder elkaar verdelen
aangezien zij alledrie alle oproepen mogen beantwoorden. Daarom werd de vroege shift nog buiten
beschouwing gelaten. Een analyse van de wandelafstanden tijdens deze vroege shift volgt bij de
analyse van ‘Effect 1’ in paragraaf 7.2.3. Bij het bestuderen van de verschillen in de wandelafstanden
moet er wel rekening gehouden worden met het feit dat zorgverleners slechts een klein deel van hun
shift bezig zijn met het beantwoorden van oproepen, waardoor het verpleegoproepsysteem ook
maar op een beperkt deel van de totale wandelafstand van een zorgverlener invloed kan hebben.
Heel ingrijpende wijzigingen aan de totaal afgelegde wandelafstand per shift worden dus niet
verwacht.
Zoals eerder aangehaald leidt het storen van een zorgverlener tijdens het uitvoeren van zijn opdracht
sneller tot fouten. Een belangrijke KPI die daarmee rekening houdt, is het percentage van de
oproepen waarvoor iemand opgeroepen werd die op dat moment bezig was. In deze gevallen werd
deze zorgverlener dus gestoord tijdens een opdracht waar enige concentratie voor vereist is.
Wanneer deze percentages voor een verschillend aantal oproepen per week in zowel het traditionele
als het Accio scenario op Figuur 50 tegenover elkaar uitgezet worden, valt op dat het Accio scenario
slechter presteert voor gelijk welk aantal oproepen per week. Dit is het gevolg van het feit dat de
beslissingsboom voor departement 1 heel discriminerend of selectief is, wat ook al afgeleid kon
worden uit het lage gemiddelde aantal zorgverleners dat per oproep wordt opgeroepen. Dit is een
gevolg van het kleine aantal zorgverleners dat op het departement werkt. Om die reden
differentieert het systeem bijna nooit op basis van de status van de zorgverlener, waardoor er geen
rekening gehouden wordt met het al dan niet storen van deze zorgverlener. Een departement waarin
deze regelset minder discriminerend zou werken zou voor deze KPI betere resultaten behalen. Dit zal
enerzijds verder aangetoond worden in de resultaten van departement 2 en anderzijds door het
analyseren van bepaalde andere scenario’s.
Page 126
102
Figuur 50: Percentage oproepen dat storend was voor de geselecteerde zorgverlener (‘Accio’ vs ‘Traditioneel’ op Departement 1)
De KPI die aangeeft hoeveel keer een behandeling van een oproep onderbroken werd om een
andere oproep te beantwoorden, hangt rechtstreeks af van deze KPI ‘Gestoord’. Dit is het gevolg van
het feit dat de kans dat een zorgverlener zijn huidige oproep zal onderbreken bij het krijgen van een
nieuwe oproep afhangt van de vooraf ingestelde kansverdeling. Deze KPI zal dus geen verrassende
resultaten opleveren.
Andere KPIs werden niet verder besproken aangezien deze niet van toepassing zijn op het
traditionele scenario. Het al dan niet respecteren van de competentie en de vertrouwensbanden
werd in het traditionele scenario niet geregistreerd.
Departement 2
In deze verticale analyse worden evenmin identieke personeelsbestanden gebruikt in beide
scenario’s, zoals ook al te zien was in Tabel 8 en Tabel 10 respectievelijk op pagina’s 81 en 82. Enkele
zorgverleners uit het traditionele scenario zijn in het Accio scenario vervangen door verzorgers.
Opnieuw worden bepaalde zones toegewezen aan de zorgverleners en opnieuw zijn deze zones
verschillend wat betreft aantal oproepen. Bedden 1 tot en met 5 versturen samen 35 procent van de
oproepen, bedden 6 tot en met 10 samen 20 procent van de oproepen, bedden 11 tot en met 15
samen 15 procent van de oproepen en bedden 16 tot en met 20 slechts 10 procent van de oproepen.
De resterende 10 procent wordt verstuurd vanuit de drie publieke ruimtes.
Wanneer naar de wachttijden gekeken wordt, zowel de gemiddelde als de maximale, kunnen
opnieuw weinig conclusies getrokken worden over het verschil tussen beide scenario’s. Zoals eerder
beschreven in de horizontale analyses liggen de wachttijden op departement 2 standaard iets hoger
door de lagere bezetting in vergelijking met het aantal oproepen en door de mindere schikking van
het departement. De standaardafwijking op de gemiddelde wachttijd ligt wel systematisch hoger in
0%
10%
20%
30%
40%
50%
40 80 120 160 200 240 280
Per
cen
tage
sto
ren
de
op
roep
en
Aantal oproepen per week
Accio
Traditioneel
Page 127
103
het traditionele scenario, wat opnieuw ook valt af te leiden uit Tabel 12. De twee pieken in het
frequentiepatroon van de wachttijden van het traditionele scenario zijn op Figuur 51 opnieuw
herkenbaar bij ongeveer dezelfde wachttijden.
Aantal oproepen/week 600 650 700 750 800
Gemiddelde Accio 45,46 46,87 48,24 49,63 50,65
Traditioneel 72,89 77,83 79,45 79,41 83,89
Standaardafwijking Accio 45,66 47,1 47,07 47,76 47,9
Traditioneel 84,63 87,61 87,4 89,52 89,74
Tabel 12: Gemiddelde wachttijd [s] en zijn standaardafwijking [s] (‘Accio’ vs ‘Traditioneel’ op Departement 2)
Figuur 51: Percentage oproepen in functie van de wachttijden (‘Accio’ vs ‘Traditioneel’ op Departement 2)
Zoals eerder gesuggereerd werd, haalt het systeem inderdaad betere resultaten op departement 2
op het vlak van het storen van de zorgverleners. Met een groter personeelsbestand zal het systeem
meer moeten differentiëren op basis van de status en locatie van de zorgverlener, wat ervoor zorgt
dat er dus meer rekening kan gehouden worden met het feit dat zorgverleners liefst zo weinig
mogelijk gestoord worden. Op Figuur 52 is te zien dat het invoeren van het systeem op dit
departement een enorme verbetering teweegbrengt wat deze KPI betreft. Tijdens weken waar er
minder dan 700 oproepen verstuurd worden, realiseert het systeem een halvering van het aantal
oproepen waarvoor een zorgverlener gestoord werd.
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
50%
0 20 40 60 80 100 120 140 160 180 200
Per
cen
tage
beh
and
eld
e o
pro
epen
Wachttijd [s]
Accio
Traditioneel
Page 128
104
Figuur 52: Percentage oproepen dat storend was voor de geselecteerde zorgverlener (‘Accio’ vs ‘Traditioneel’ op Departement 2)
7.2.3. ‘Accio’ vs ‘Effect 1’
Het eerste scenario dat verder onderzocht wordt, is dat waarin het Accio oproepsysteem werkt in
een afdeling waar alleen verpleegkundigen tewerkgesteld zijn, waardoor elke zorgverlener een
medische interventie mag afhandelen. Deze analyse is voornamelijk belangrijk om meer duidelijkheid
te brengen over wat het effect is van het gebruik van een ander personeelsbestand. De resultaten
van ‘Effect 1’ kunnen op het vlak van werkverdeling en wandelafstanden nu wel met deze van het
traditionele scenario vergeleken worden, wat voor het Accio scenario niet het geval was vanwege de
verschillende personeelsbestanden.
Departement 1
Na analyse van de resultaten kan er opgemerkt worden dat de operationele parameters zoals de
wachttijden en het percentage storende oproepen veelal gelijk gebleven zijn in vergelijking met het
Accio scenario. De aanpassing aan het personeelsbestand die doorgevoerd werd bij de overgang naar
het Accio scenario heeft dus niet veel invloed gehad op de werking van de operationele processen in
de afdeling. Wel is het zo dat, aangezien alle zorgverleners hier hetzelfde competentieprofiel
hebben, na het overlopen van de competenties in de desbetreffende tak van de beslissingsboom alle
zorgverleners nog overblijven. Er valt in vergelijking met het Accio scenario dus een discriminerend
deel van de beslissingsboom weg. Er wordt dan ook verwacht dat de persoonlijke vertrouwensband
minder zal geschonden worden. Dit is ook enigszins op te merken op Figuur 53.
0%
10%
20%
30%
40%
50%
600 650 700 750 800
Per
cen
tage
sto
ren
de
op
roep
en
Aantal oproepen per week
Accio
Traditioneel
Page 129
105
Figuur 53: Percentage oproepen dat niet werd behandeld door een zorgverlener met een sterke persoonlijke
vertrouwensband met de patiënt (‘Accio’ vs ‘Effect 1’ op Departement 1)
Ondanks het feit dat het eerste deel van de beslissingsboom nu geen invloed meer heeft, is er geen
daling van het gemiddelde aantal zorgverleners dat aan een oproep wordt toegewezen. Ook is er
geen effect op het percentage oproepen waarvoor een zorgverlener gestoord wordt, wat erop wijst
dat de beslissingsboom niet meer heeft moeten differentiëren op basis van de status van de
zorgverleners, wat toch enigszins verwacht werd. Dit is het gevolg van de karakteristieken van het
departement, met weinig oproepen en een niet zo uitgebreid personeelsbestand. De regelset heeft
hier niet de mogelijkheid om ten volle zijn functionaliteit te gebruiken aangezien er meestal maar
tussen twee zorgverleners kan gekozen worden.
De analyse van de afgelegde wandelafstanden wordt niet voor departement 1 gedaan, maar voor
departement 2 omdat daar door de minder gecentraliseerde indeling grotere effecten verwacht
worden.
Departement 2
Wanneer hetzelfde effect onderzocht wordt in departement 2, wordt er verwacht dat de effecten die
gezocht werden in de resultaten van het eerste departement nu wel duidelijk worden, aangezien uit
de horizontale analyses al bleek dat het systeem op dit departement veel meer invloed heeft door
het grotere aantal oproepen en het grotere aantal zorgverleners. Het wegvallen van het
discriminerend effect van de eerste tak van de beslissingsboom heeft in departement 2 wel invloed
op het gemiddeld aantal zorgverleners dat toegewezen wordt aan een oproep. Dat gemiddelde
aantal verhoogt, wat de kans op het afwijzen van de oproep verkleint, waardoor het percentage
oproepen dat doorverwezen wordt daalt. Het gemiddelde aantal keer dat zo’n doorverwezen oproep
opnieuw verstuurd werd, was ongeveer gelijk aan 1,60. Om diezelfde reden dalen ook de gemiddelde
en maximale wachttijd in vergelijking met het Accio scenario. Wat de gemiddelde wachttijd betreft is
0%
2%
4%
6%
8%
10%
12%
14%
16%
80 160 240P
erce
nta
ge o
pro
epen
Aantal oproepen per week
Accio
Scenario 1
Page 130
106
dit effect eerder klein. Deze conclusies zijn terug te vinden op Figuur 54, Figuur 55, Figuur 56 en
Figuur 57.
Figuur 54: Gemiddeld aantal zorgverleners dat geselecteerd werd per oproep (‘Accio’ vs ‘Effect 1’ op Departement 2)
Figuur 55: Percentage oproepen dat minstens eenmaal werd doorverwezen (‘Accio’ vs ‘Effect 1’ op Departement 2)
Figuur 56: Gemiddelde wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Effect 1’ op Departement 2)
Figuur 57: Maximale wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Effect 1’ op Departement 2)
Het toewijzen van een oproep aan iemand zonder de correcte competenties komt nu nog zelden
voor, aangezien er enkel verpleegkundigen aan het werk zijn. Wanneer dat toch het geval is, zal het
gaan om de hoofdverpleger die in geval van nood een oproep moet beantwoorden. Deze heeft wel
1
1,05
1,1
1,15
1,2
1,25
1,3
1,35
1,4
600 700 800
Aan
tal g
esel
ecte
erd
e zo
rgve
rlen
ers
Aantal oproepen per week
0%
5%
10%
15%
20%
25%
30%
35%
600 700 800
Per
cen
tage
do
orv
erw
ezen
op
roep
en
Aantal oproepen per week
Accio
0
10
20
30
40
50
60
600 700 800
Gem
idd
eld
e w
ach
ttid
j [s]
Aantal oproepen per week
0
250
500
750
1000
1250
1500
1750
2000
600 700 800
Max
imal
e w
ach
ttijd
[s]
Aantal oproepen per week
Accio
Scenario 1
Page 131
107
de correcte competenties, maar zou zich hier in het optimale geval niet mee moeten bezig houden.
Het overzicht van de competenties van de verschillende zorgverleners en de bijhorende uitleg is
terug te vinden in Bijlage 11.2. Op het vlak van de vertrouwensband worden iets betere resultaten
behaald met ‘Effect 1’ dan in het Accio scenario. Aangezien de vertrouwenswaarden in vergelijking
met het Accio scenario ongewijzigd gebleven zijn, toont dit aan dat het systeem dus effectief beter
presteert. Dit is opnieuw een rechtstreeks gevolg van het feit dat de eerste tak van de
beslissingsboom niemand meer uit de lijst met beschikbare zorgverleners filtert, waardoor de tak die
rekening houdt met de vertrouwensband meer kan differentiëren, wat tot de betere resultaten leidt
op dat vlak.
Tabel 13 is afgeleid uit de resultaten van departement 2 met 800 oproepen per week. Hierbij worden
het traditionele scenario en ‘Effect 1’ onderling vergeleken. De tabel geeft weer welk percentage van
de tijd alle zorgverleners belast werden met respectievelijk ‘Direct’ en ‘Utilize’ taken. De percentages
zijn gemiddelden over de totale gewerkte tijd van 52 weken. ‘Direct’ taken stellen de directe
verzorgingstaken voor die bestaan uit alle taken van de zorgverlener waarbij deze rechtstreeks
contact heeft met de patiënt. In deze tabel zijn dit de momenten tijdens de vaste rondes en het
beantwoorden van oproepen van patiënten. ‘Utilize’ gaat enkel om de tijd die de zorgverlener
besteedt aan het bed tijdens het beantwoorden van een oproep. ‘Direct’ is dus de som van ‘Utilize’
en de tijd die de desbetreffende zorgverlener besteedt aan een bed tijdens zijn vaste rondes. De
vaste rondes worden niet toegewezen door het Accio verpleegoproepsysteem, maar zijn uiteraard
wel een deel van de werklast van de zorgverleners. Als het Accio oproepsysteem die zorgverleners
die veel vaste rondes uitvoeren minder belast met oproepen, verdeelt het dus beter de totale
werklast. Een hoog percentage voor ‘Direct’ zou dus moeten gepaard gaan met een laag percentage
voor ‘Utilize’. Uit de resultaten blijkt dat het Accio oproepsysteem hier inderdaad in slaagt. Dit valt
voornamelijk op bij de vergelijking van het traditionele scenario met ‘Effect 1’ waarbij in beide
scenario’s hetzelfde personeelsbestand gebruikt werd. In beide scenario’s deed ‘Verpleegkundige 3’
veel vaste rondes, maar met het Accio oproepsysteem in ‘Effect 1’ heeft deze zorgverlener veel
minder tijd besteed aan het behandelen van oproepen dan met het traditionele oproepsysteem.
Omgekeerd, kreeg ‘Verpleegkundige 2’, die in beide scenario’s bijna geen vaste rondes deed, veel
meer oproepen toegewezen in ‘Effect 1’ dan in het traditionele scenario. Alleen voor
‘Verpleegkundige 5’ geldt dit niet omdat deze sowieso al de bedden toegewezen kreeg die het minst
bellen (zie paragraaf 7.2.2). Het percentage ‘Utilize’ is bij deze zorgverlener dus hoger dan bij het
traditionele scenario omdat het Accio systeem de werklast anders verdeelt, maar het houdt het
aantal oproepen voor deze verpleger toch laag ten opzichte van de anderen door zijn hoge
Page 132
108
percentage directe verzorgingstaken. Deze analyse toont aan dat het Accio systeem er wel degelijk in
slaagt om de werklast beter onder de zorgverleners te verdelen.
‘Traditioneel’ Direct Utilize ‘Effect 1' Direct Utilize
Verpleegkundige 1 14,24% 4,57% Verpleegkundige 1 13,56% 3,39%
Verpleegkundige 2 3,94% 3,78% Verpleegkundige 2 6,75% 6,71%
Verpleegkundige 3 64,95% 4,77% Verpleegkundige 3 63,32% 1,66%
Verpleegkundige 4 12,73% 2,74% Verpleegkundige 4 15,11% 5,91%
Verpleegkundige 5 56,10% 1,44% Verpleegkundige 5 60,05% 2,23%
Tabel 13: Tijdsverdeling van zorgverleners over 'Direct' en 'Utilize' taken bij 800 oproepen per week (‘Traditioneel’ vs ‘Effect 1’)
Zoals vermeld in paragraaf 7.2.1 wordt de analyse van de wandelafstanden voor de vroege shift
gedaan in de bespreking van ‘Effect 1’ zodat het Accio en het traditionele oproepsysteem kunnen
vergeleken worden met hetzelfde personeelsbestand. Uit Figuur 58 en Figuur 59 blijkt dat verplegers
‘Verpleegkundige 3’ en ‘Verpleegkundige 5’ gemiddeld minder afstand afleggen per shift,
‘Verpleegkundige 1’ ongeveer evenveel en ‘Verpleegkundige 2’ en ‘Verpleegkundige 4’ duidelijk
meer. ‘Verpleegkundige 1 heeft voor zowel ‘Direct’ als ‘Utilize’ een lichte daling van de waarden voor
‘Effect 1’ waardoor ook zijn gemiddelde wandelafstand iets korter wordt in ‘Effect 1’.
‘Verpleegkundige 2’ en ‘Verpleegkundige 4’ krijgen in ‘Effect 1’ beduidend meer oproepen
toegewezen omdat het Accio oproepsysteem er rekening mee houdt dat zij minder directe
verzorgingstaken doen. ‘Verpleegkundige 3’ moet op zijn beurt minder oproepen beantwoorden
omdat hij al druk bezet is met de grote rondes sanitair en medicatie, waardoor hij veel minder
oproepen moet beantwoorden dan in ‘Traditioneel’. Door deze veranderingen moet hij een kortere
afstand afleggen in ‘Effect 1’. Hoewel ‘Verpleegkundige 5’ iets meer oproepen moet beantwoorden,
legt deze wel minder afstand af dan in ‘Traditioneel’. De verklaring hiervoor kan gevonden worden in
het feit dat het Accio verpleegoproepsysteem rekening houdt met de locatie van de zorgverleners bij
het toewijzen van een oproep.
Page 133
109
Figuur 58: Gemiddeld afgelegde wandelafstand tijdens de vroege shift per zorgverlener (‘Traditioneel’ op Departement 2)
Figuur 59: Gemiddeld afgelegde wandelafstand tijdens de vroege shift per zorgverlener (‘Effect 1’ op Departement 2)
Op Figuur 60 is te zien dat het Accio oproepsysteem de totaal afgelegde wandelafstand van alle
zorgverleners die werken tijdens de vroege shift lager houdt dan het traditionele oproepsysteem.
Wat er op wijst dat zorgverleners over het algemeen efficiënter worden toegewezen.
Figuur 60: Gemiddelde wandelafstand van alle zorgverleners tijdens de vroege shift ('Traditioneel' vs 'Effect 1' op Departement 2)
1,5
2
2,5
3
3,5
4
600 700 800
Afg
eleg
de
afst
and
[km
]
Aantal oproepen per week
600 700 800Aantal oproepen per week
13,5
14
14,5
15
15,5
600 700 800
Gem
idd
eld
afg
eleg
de
wan
del
afst
and
[km
]
Aantal oproepen per week
Traditioneel
Effect 1
Page 134
110
Het aanwerven van verzorgers in de plaats van sommige verpleegkundigen, die over het algemeen
minder kosten, heeft dus een negatief effect op de KPIs ten opzichte van het ‘Accio’ project, al is dat
negatief effect eerder beperkt. Het is aan het ziekenhuis om een afweging te maken tussen een
lagere kost en iets betere resultaten.
7.2.4. ‘Accio’ vs ‘Effect 2’
In het scenario ‘Effect 2’ wordt onderzocht wat de voor- of nadelen zijn van het niet naleven van de
richtlijnen omtrent de vereiste competenties van de zorgverleners bij het afhandelen van een
oproep. Er wordt verwacht dat langere wachttijden vaker zullen voorkomen dan in het Accio scenario
omdat verzorgers of logistieke medewerkers nu verplicht zijn de oproep af te wijzen wanneer ze de
correcte competenties niet bezitten. Deze persoon zal pas weten dat hij niet geschikt is voor deze
oproep nadat hij contact heeft opgenomen met de patiënt, via telefoon of door naar de kamer te
gaan. Er wordt dus geen aanpassing doorgevoerd aan de regelset, maar enkel aan de richtlijnen die
meegegeven worden aan het personeel.
Departement 1
De resultaten betreffende de gemiddelde en maximale wachttijden wijzen op departement 1 niet
onmiddellijk in die richting. Integendeel, het verloop van de gemiddelde wachttijd in ‘Effect 2’ loopt
volledig gelijk met dat in ‘Accio’. De maximale wachttijd ligt in ‘Effect 2’ zelfs overal lager. Wanneer
er echter dieper ingegaan wordt op de verdeling van die wachttijden en meer specifiek op het
percentage oproepen waarbij de patiënt langer heeft moeten wachten dan de aanvaardbare
wachttijd van twee minuten, is er wel een verschil op te merken. Zoals in Tabel 14 te zien is, ligt dit
percentage steeds hoger voor ‘Effect 2’ dan voor ‘Accio’.
Aantal oproepen/week 80 160 240
Accio 5,36 % 7,31 % 10,25 %
Effect 2 6,58 % 9,08 % 11,89 %
Tabel 14: Percentage oproepen met wachttijd langer dan twee minuten (‘Accio’ vs ‘Effect 2’ op Departement 1)
Het volgende dat opvalt is dat naarmate er meer oproepen per week verstuurd worden, er een
groter deel van die oproepen storend is voor de zorgverlener zoals te zien op Figuur 61. Dit is te
verklaren door het feit dat bij een stijgend aantal oproepen er meer situaties zullen voorkomen
waarin het systeem moet gebruik maken van de zorgverleners die de competentie niet hebben
omdat de andere de oproep al afgewezen hebben. Als deze uitgekozen zorgverleners de oproep
echter systematisch afwijzen, zal uiteindelijk toch een zorgverlener moeten aangesproken worden
met de vereiste competenties. Deze heeft de oproep wellicht eerder al doorverwezen omdat hij op
Page 135
111
dat moment bezig is of was met het behandelen van een andere patiënt. Deze verklaring wordt
enigszins gestaafd door de resultaten van de simulaties. Uit deze resultaten blijkt dat het percentage
oproepen dat verstuurd is naar iemand die niet de correcte competentie bezit, verdubbelt van 80
naar 240 oproepen per week. De cijfers zijn terug te vinden in Tabel 15.
Figuur 61: Percentage oproepen dat storend was voor de geselecteerde zorgverlener (Accio vs ‘Effect 2’ op Departement 1)
Aantal oproepen/week 80 160 240
Ervaring 0,07% 0,23% 0,13%
Competentiebreuk 0,29% 0,58% 0,65%
Tabel 15: Percentage oproepen dat werd toegewezen aan een zorgverlener die de correcte kwalificaties niet had (‘Effect 2’ op Departement 1)
Departement 2
Door beperkingen van de gebruikte hardware is het niet gelukt om deze simulaties uit te voeren,
maar verwacht wordt dat dezelfde bevindingen als in departement 1 zouden gevonden worden.
7.2.5. ‘Accio’ vs ‘Effect 3’
In deze paragraaf wordt onderzocht wat de invloed is op de resultaten wanneer het deel van de
beslissingsboom dat rekening houdt met de vertrouwensband volledig buiten beschouwing wordt
gelaten. De vertrouwensband heeft dus geen enkele invloed meer op het toewijzen van een oproep
aan een zorgverlener. De rest van de regelset blijft identiek, waardoor ‘Effect 3’ enkel dient om na te
gaan hoeveel invloed de vertrouwensband heeft op de volledige regelset.
Departement 1
Eerst wordt gekeken of de meest logische verwachting ingelost wordt. Wanneer de beslissingsboom
een volledige tak buiten beschouwing laat, is deze onmiddellijk een stuk minder selectief waardoor
0%5%
10%15%20%25%30%35%40%45%50%55%
80 160 240
Per
cen
tage
sto
ren
de
op
roep
en
Aantal oproepen per week
Accio
Scenario 4
Page 136
112
er normaal gezien meer zorgverleners per oproep zouden moeten opgeroepen worden. Aangezien
het deel van de beslissingsboom betreffende de vertrouwensband net voor het deel komt dat de
status van de zorgverlener in rekening neemt, zou het systeem ook meer moeten differentiëren op
basis van de status van de zorgverleners, aangezien de overblijvende lijst op dat punt meer
zorgverleners zal bevatten dan in het Accio scenario het geval was. Bijgevolg zou het systeem er
moeten voor zorgen dat er minder zorgverleners gestoord worden. Op het vlak van competentie
worden geen effecten verwacht aangezien dit deel van de beslissingsboom in rekening wordt
genomen vooraleer er over de vertrouwensband wordt gesproken. Deze aanpassing heeft dan ook
geen invloed op het breken van bepaalde competenties.
Op Figuur 62 wordt het gemiddeld aantal zorgverleners dat tegelijk opgeroepen wordt van naderbij
bekeken. De willekeurige trend onafhankelijk van het aantal oproepen per week werd al eerder
aangehaald en is quasi identiek bij beide scenario’s. Bij ‘Effect 3’ worden er wel beduidend meer
zorgverleners aan dezelfde oproep toegewezen, wat gelijkloopt met de verwachtingen.
Een ander logisch gevolg dat al aangehaald werd is het feit dat zorgverleners minder gestoord
worden. De regelset is minder discriminerend wanneer de vertrouwensband achterwege gelaten
wordt, waardoor er in het onderste deel van de beslissingsboom meer kan gedifferentieerd worden
op basis van de status van de zorgverleners. Het verloop van het percentage in functie van het aantal
oproepen per week is gelijk aan dat van het Accio scenario, maar ligt een stuk lager. Dit blijkt ook uit
Figuur 63.
Figuur 62: Gemiddeld aantal zorgverleners dat geselecteerd werd per oproep (‘Accio’ vs ‘Effect 3’ op Departement 1)
Figuur 63: Percentage oproepen dat storend was voor de geselecteerde zorgverlener (‘Accio’ vs ‘Effect 3’ op Departement 1)
Deze conclusies leiden onmiddellijk tot een ander voordeel, namelijk het duidelijk lagere percentage
oproepen dat minstens eenmaal doorverwezen werd. Deze oproepen werden dan gemiddeld 1,57
1
1,05
1,1
1,15
1,2
1,25
1,3
1,35
1,4
80 160 240
Aan
tal g
esel
ecte
erd
e zo
rgve
rlen
ers
Aantal oproepen per week
0%
10%
20%
30%
40%
50%
80 160 240
Per
cen
tage
sto
ren
de
op
roep
en
Aantal oproepen per week
Scenario 5
Accio
Page 137
113
keer rondgestuurd. Wanneer meer zorgverleners geselecteerd worden is de kans kleiner dat de
oproep opnieuw zal verstuurd worden omdat beide zorgverleners beslissen alsof ze alleen
opgeroepen worden. Dit valt ook af te leiden uit Figuur 64.
Figuur 64: Percentage oproepen dat minstens eenmaal werd doorverwezen (‘Accio’ vs ‘Effect 3’ op Departement 1)
Bij het bestuderen van de wachttijden komt voor departement 1 het scenario ‘Effect 3’ er in
elke situatie beter uit dan het Accio scenario. Er worden lagere gemiddelde wachttijden
gerealiseerd, terwijl de maximale wachttijden ongeveer dezelfde grootteorde aannemen. De
standaardafwijking op deze gemiddelde wachttijden is lager bij ‘Effect 3’ dan bij ‘Accio’. Er kan
dus gesteld worden dat het systeem hier beter presteert op vlak van wachttijden, maar dat het
verschil redelijk beperkt blijft. Het feit dat het systeem deze betere prestaties levert is een
rechtstreeks gevolg van het grotere aantal opgeroepen zorgverleners per oproep. Wanneer er
meer zorgverleners opgeroepen worden, is zoals eerder aangehaald de kans dat één van beide
de oproep accepteert groter, waardoor een oproep minder opnieuw moet verstuurd worden,
wat vooral de gemiddelde wachttijden verlaagt, zoals te zien is op Figuur 65. Ook de
standaardafwijkingen op de gemiddelde wachttijden komen in ‘Effect 3’ lager te liggen, zie Tabel
16. De invloed op de maximale wachttijden kan hier niet eenduidig afgeleid worden uit Figuur
66.
0%
5%
10%
15%
20%
25%
30%
35%
80 160 240
Per
cen
tage
do
orv
erw
ezen
op
roep
en
Aantal oproepen per week
Accio
Effect 3
Page 138
114
Figuur 65: Gemiddelde wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Effect 3’ op Departement 1)
Figuur 66: Maximale wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Effect 3’ op Departement 1)
Aantal oproepen/week 80 160 240
Gemiddelde Accio 41,89 47,25 51,96
Effect 3 69,04 79,06 89,5
Standaardafwijking Accio 37,19 41,4 46,88
Effect 3 67,47 74,44 84,82
Tabel 16: Gemiddelde wachttijd [s] en zijn standaardafwijking [s] (‘Accio’ vs ‘Effect 3’ op Departement 1)
De aanpassing in ‘Effect 3’ heeft geen rechtstreekse invloed op de absolute waarde van de maximale
wachttijden, maar wel op de frequentie van deze maximale wachttijden. Het aantal oproepen
waarbij de patiënt langer dan twee minuten moest wachten ligt duidelijk lager dan in het Accio
scenario. De verschillen zijn aangegeven in Tabel 17.
Tabel 17: Percentage oproepen met wachttijd langer dan twee minuten (‘Accio’ vs ‘Effect 3’ op Departement 1)
Afgezien van al deze voordelen zou het niet in rekening brengen van de vertrouwensband ook
negatieve gevolgen moeten hebben die niet altijd gekwantificeerd kunnen worden. Enerzijds zijn er
de nadelen voor de patiënten, die op deze manier hun voor- en/of afkeur voor bepaalde
personeelsleden niet meer kunnen uitdrukken en anderzijds voor de zorgverleners, die nu terug
meermaals met meer personen tegelijk worden opgeroepen. Dat laatste zou moeten leiden tot
grotere wandelafstanden voor de zorgverleners. Na het bestuderen van de grafiek blijkt dat dit effect
echter verwaarloosbaar is door de beperkte frequentie waarin er meer zorgverleners worden
opgeroepen. De kans dat er dan twee zorgverleners effectief naar de kamer wandelen hangt ook nog
af van een vooropgestelde kansverdeling en is zeker niet hoger dan 50 procent. De grote
wandelafstanden die zorgverleners buiten het beantwoorden van oproepen al moeten afleggen door
0
10
20
30
40
50
60
80 160 240
Gem
idd
eld
e w
ach
ttijd
[s]
Aantal oproepen per week
0250500750
10001250150017502000
80 160 240
Max
imal
e w
ach
ttijd
[s]
Aantal oproepen per week
Scenario 5
Accio
Aantal oproepen/week 80 160 240
Accio 7,31% 10,01% 10,90%
Effect 3 5,53% 7,68% 8,88%
Page 139
115
het gebruik van de willekeurige rondes zorgen er hier dus voor dat dit effect verwaarloosbaar is in
deze simulatie.
Departement 2
Wanneer dezelfde aanpassing doorgevoerd wordt aan de regelset in departement 2 blijkt uit de
resultaten dat hoofdzakelijk dezelfde conclusies gelden als voor departement 1. Zowel de invloed op
de gemiddelde wachttijd als op de frequentie van de maximale wachttijden als op het gemiddelde
aantal zorgverleners dat tegelijk een oproep kreeg toegewezen zijn zeer gelijkaardig aan de
invloeden op departement 1. Over deze KPIs wordt er dan ook niet verder uitgewijd.
Wat bij departement 1 niet aan te tonen was met de resultaten, maar op voorhand wel verwacht
werd, komt nu duidelijker naar voren in departement 2. Het betreft de gemiddelde wandelafstanden.
Er werd reeds aangehaald dat het verhogen van het aantal toegewezen zorgverleners per oproep die
gemiddelde afstanden zou moeten doen stijgen. Aangezien het tweede departement groter is dan
het eerste met een minder gunstige structuur, wordt het effect op de wandelafstand duidelijker. Om
dit aan te tonen werd de som van de afstanden van alle zorgverleners per shift opgeteld. Deze
waarden werden voor de late shift in beide scenario’s uitgezet in functie van het aantal oproepen per
week op Figuur 67, waar de duidelijke stijging makkelijk uit af te leiden is.
Figuur 67: Gemiddeld afgelegde afstand voor alle zorgverleners in de late shift (‘Accio’ vs ‘Effect 3’ op Departement 2)
7.2.6. ‘Accio’ vs ‘Aanpassing 1’
Een eerste poging tot het aanbrengen van verbeteringen aan de Accio regelset is zoals beschreven in
paragraaf 7.1.6 het veranderen van de definitie van de status ‘Busy’. Met deze ingreep wordt er
beoogd om de maximale wachttijden te reduceren. Er wordt dus verwacht dat deze lager zullen
liggen dan in het Accio scenario.
8
8,5
9
9,5
10
10,5
600 700 800
Afg
eleg
de
afst
and
[km
]
Aantal oproepen per week
Accio
Page 140
116
Departement 1
Zowel de grafiek met de gemiddelde wachttijden als deze waarbij de oproepen uitgezet werden in
functie van de wachttijden werden onderzocht en verschillen quasi niet. Dit komt omdat het geval
dat hierbij aangepakt wordt, waarbij een zorgverlener nog meerdere oproepen wachtende heeft,
maar nog niet aanwezig is bij een patiënt en dus de status ‘Free’ heeft, niet zo vaak voorkomt in
departement 1. De aanpassing aan de regelset zal dus slechts effect hebben in uitzonderlijke gevallen
waarbij de zorgverlener nog meerdere oproepen af te handelen heeft maar toch de status ‘Free’
heeft. Die uitzonderlijke gevallen zijn de oorzaak voor de maximale wachttijden. Figuur 68 toont dan
ook aan dat die maximale wachttijd lager ligt met ‘Aanpassing 1’ dan in het Accio scenario. Het gaat
enkel om een verlaging van de extreme waarden, want het percentage oproepen waarbij een patiënt
langer dan twee minuten moet wachten blijft wel nagenoeg gelijk (2,9%).
Figuur 68: Maximale wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Aanpassing 1’ op Departement 1)
Het aanpassen van de definitie van de status ‘Busy’ heeft dus het gewenste positief effect op de
maximale wachttijden behaald, zonder daarbij andere KPIs noemenswaardig te beïnvloeden. Ook de
verdeling van de werklast wordt door deze aanpassing niet gewijzigd, andermaal omdat het geval te
weinig voorkomt om de gemiddeldes over al die oproepen aan te passen. De andere KPIs worden
hier dan ook niet verder besproken.
Departement 2
Wanneer op departement 2 ‘Aanpassing 1’ wordt doorgevoerd op de regelset, kunnen net dezelfde
conclusies getrokken worden als in departement 1. Opnieuw worden de maximale wachttijden
verlaagd zonder daarbij invloed te hebben op de andere KPIs zoals de gemiddelde wachttijd. Het
0
250
500
750
1000
1250
1500
1750
2000
80 160 240
Max
imal
e w
ach
ttijd
[s]
Aantal oproepen per week
Accio
Scenario 2
Page 141
117
percentage oproepen dat langer dan twee minuten blijft openstaan blijft ook gelijkaardig (7,72%
voor ‘Aanpassing 1’ en 8,11% voor ‘Accio’).
7.2.7. ‘Accio’ vs ‘Aanpassing 2’
Met ‘Aanpassing 2’ wordt ervoor gezorgd dat het systeem de oproep telkens naar slechts één
zorgverlener stuurt. Wanneer na het overlopen van de beslissingsboom nog meerdere zorgverleners
met dezelfde rol overblijven, wordt de oproep verstuurd naar de zorgverlener die het minst aantal
oproepen tot dan toe heeft beantwoord. Dit zou tot een betere verdeling van de oproepen over de
verschillende zorgverleners moeten leiden. Ook zou het een invloed kunnen hebben op de
wandelafstanden aangezien er nu nooit nog twee zorgverleners samen naar een kamer vertrekken
zonder het van elkaar te weten. Door het lage gemiddeld aantal zorgverleners dat tegelijk aan een
oproep wordt toegewezen in departement 1, worden er daar geen grote verschuivingen verwacht in
de resultaten. In departement 2 daarentegen, waar het gemiddeld aantal opgeroepen zorgverleners
een stuk hoger ligt, zouden deze gevolgen duidelijker naar boven moeten komen. De aanpassing zou
geen invloed mogen hebben op het al dan niet naleven van de competentie- of
confidentievoorwaarden. Het filteren van de zorgverleners op basis van deze voorwaarden wordt in
de beslissingsboom namelijk doorgevoerd nog voor er van deze aanpassing sprake is.
Departement 1
Wat betreft de gemiddelde en maximale wachttijden is het inderdaad zo dat deze zo goed als
volledig gelijk lopen voor beide scenario’s. Ook wat betreft de standaardafwijking op de gemiddelde
wachttijden kunnen weinig verschillen opgemerkt worden. Bijgevolg kan er gesteld worden dat deze
ingreep geen tot weinig effect heeft op de wachttijden voor de patiënten op dit departement. De
bevindingen worden gestaafd door Figuur 69 en Figuur 70.
Page 142
118
Figuur 69: Gemiddelde wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Aanpassing 2’ op Departement 1)
Figuur 70: Maximale wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Aanpassing 2’ op Departement 1)
Uit Tabel 18 blijkt dat, zoals verwacht, deze aanpassing niet veel effect heeft op de werkverdeling van
de zorgverleners op departement 1. Deze tabel wordt op dezelfde manier geïnterpreteerd als Tabel
13 op pagina 108.
‘Accio’ DIRECT UTILIZE ‘Aanpassing 2' DIRECT UTILIZE
Verpleegkundige Nacht 1,52% 1,52% Verpleegkundige Nacht 1,51% 1,50%
Verpleegkundige Vroeg 14,02% 4,03% Verpleegkundige Vroeg 13,91% 4,06%
Verpleegkundige Vroeg 2 12,36% 3,15% Verpleegkundige Vroeg 2 12,18% 3,12%
Verzorger 76,48% 1,43% Verzorger 76,16% 1,42%
Verpleegkundige Laat 35,48% 6,60% Verpleegkundige Laat 36,02% 6,24%
Verpleegkundige Laat 2 36,49% 5,22% Verpleegkundige Laat 2 35,53% 5,36%
Tabel 18:Tijdsverdeling van zorgverleners over 'Direct' en 'Utilize' taken bij 800 oproepen per week (‘Accio' vs ‘Aanpassing 2’ op Departement 1)
Ook op het gemiddeld aantal keer dat een oproep doorverwezen wordt, heeft deze aanpassing
vooralsnog weinig invloed. Dit is allemaal het gevolg van het feit dat slechts in één op de twintig
gevallen er meer dan één zorgverlener wordt uitgekozen. Er wordt verwacht dat de aanpassing voor
een groter aantal oproepen of in een scenario of omgeving waar de regelset minder selectief is dan
hier het geval is, wel effect zal hebben.
Departement 2
Zoals eerder opgemerkt tijdens de horizontale analyse komt het in departement 2 meer voor dat een
oproep naar meerdere zorgverleners tegelijk wordt gestuurd. In dit departement wordt er in 20 tot
25 procent van de gevallen meer dan één iemand opgeroepen met het Accio systeem. ‘Aanpassing 2’
zou hier over het algemeen dus meer invloed moeten hebben dan in departement 1 het geval was.
0
10
20
30
40
50
60
80 160 240
Gem
idd
eld
e w
ach
ttijd
[s]
Aantal oproepen per week
0250500750
10001250150017502000
80 160 240
Max
imal
e w
ach
ttijd
[s]
Aantal oproepen per week
Accio
Scenario 3
Page 143
119
Eerder werd al aangehaald dat het aantal zorgverleners dat geselecteerd wordt, rechtstreeks invloed
heeft op de wachttijden. Hoe minder zorgverleners tegelijk opgeroepen worden, hoe lager de kans is
dat de oproep onmiddellijk geaccepteerd wordt. Oproepen worden dus sneller afgewezen, waardoor
de gemiddelde wachttijden ook langer worden. Deze beide effecten zijn duidelijk terug te vinden op
Figuur 71 en Figuur 72. Aangezien het selecteren van meerdere zorgverleners vooral plaatsvindt
wanneer de oproep voor de eerste maal wordt toegewezen en niet meer wanneer deze al enkele
keren is afgewezen, is er geen duidelijk verband terug te vinden tussen de maximale wachttijden en
het al dan niet doorvoeren van deze aanpassing, wat ook af te leiden is uit Figuur 73.
Figuur 71: Percentage oproepen dat minstens eenmaal werd doorverwezen (‘Accio’ vs ‘Aanpassing 2’ op Departement 2)
Figuur 72: Gemiddelde wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Aanpassing 2’ op Departement 2)
Figuur 73: Maximale wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Aanpassing 2’ op Departement 2)
Zoals eerder vermeld in departement 1 heeft deze aanpassing geen noemenswaardige invloed op de
KPIs betreffende competentie en confidentie. Ook wat betreft de werkverdeling van de zorgverleners
zijn de effecten gering. Het selecteren van maar één zorgverlener zorgt er wel voor dat er minder
0%
5%
10%
15%
20%
25%
30%
35%
600 700 800
Per
cen
tage
do
orv
erw
ezen
op
roep
en
Aantal oproepen per week
Accio
Aanpassing 2
0
10
20
30
40
50
60
600 700 800
Gem
idd
eld
e w
ach
ttijd
[s]
Aantal oproepen per week
0
250
500
750
1000
1250
1500
1750
2000
600 700 800
Max
imal
e w
ach
ttijd
[s]
Aantal oproepen per week
A…
Page 144
120
nutteloze afstanden worden afgelegd. Bij de studie van de resultaten werd van beide scenario’s de
totale wandelafstand voor de vroege shift berekend, afgelegd door alle werknemers die werkzaam
waren tijdens die shift. Dit werd op Figuur 74 uitgezet. Deze wandelafstand was systematisch groter
in het Accio scenario, waarbij de invloed duidelijker werd naarmate er meer zorgverleners werkzaam
waren tijdens de shift.
Figuur 74: Totaal gemiddeld afgelegde wandelafstand tijdens de vroege shift door alle zorgverleners (‘Accio’ vs ‘Aanpassing 2’ op Departement 2)
7.2.8. ‘Accio’ vs ‘Aanpassing 3’
Uit de vergelijkingen van het Accio scenario en het traditionele scenario in departement 1 bleek dat
er bij gebruik van het nieuwe verpleegoproepsysteem nog steeds een groot percentage
zorgverleners gestoord werd door nieuwe oproepen. Het nieuwe systeem is nochtans opgebouwd
om dit nadeel op te lossen. Er moet dus een manier gevonden worden om dat hoge percentage te
doen zakken. Uit de analyse van ‘Effect 3’, beschreven in paragraaf 7.2.5, bleek dat deze percentages
te wijten waren aan de te sterke differentiatie van de zorgverleners op basis van hun
vertrouwensband met de patiënten. Het resultaat hiervan was dat het systeem niet meer in staat
was om te kiezen op basis van de status van de zorgverleners. In departement 2 was dit effect
minder zichtbaar omdat er meer zorgverleners aanwezig waren. Daardoor kon het systeem nog
selecteren op basis van de status na de vertrouwensband. Met dit scenario wordt dus verwacht dat
alle voordelen uit ‘Effect 3’ naar boven komen zonder de vertrouwensband tussen patiënt en
zorgverlener daarbij volledig te verwaarlozen.
13,5
14
14,5
15
15,5
600 700 800
Gem
idd
eld
afg
eleg
de
wan
del
afst
and
[km
]
Aantal oproepen per week
Accio
Aanpassing 2
Page 145
121
Departement 1
Uit Figuur 75 blijkt dat voor departement 1 de aanpassing zijn effect zeker niet mist. Het percentage
oproepen is sterk gedaald tegenover het Accio scenario. Het ligt steeds meer dan 10 % lager. Dit is
eveneens lager dan het traditionele scenario.
Figuur 75: Percentage oproepen dat storend was voor de geselecteerde zorgverlener (‘Accio’ vs ‘Aanpassing 3’ op Departement 1)
Het lagere percentage brengt enkele positieve gevolgen met zich mee. Om te beginnen liggen zowel
de gemiddelde als de maximale wachttijden lager bij ‘Aanpassing 3 ’ dan bij ‘Accio’. Dit volgt uit het
feit dat het minder vaak zal gebeuren dat een zorgverlener nog taken moet afwerken wanneer hij
wordt opgeroepen voor een andere taak. Dit blijkt verder ook uit Figuur 76 en Figuur 77.
Figuur 76: Gemiddelde wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Aanpassing 3’ op Departement 1)
Figuur 77: Maximale wachttijd in functie van het aantal oproepen per week (‘Accio’ vs ‘Aanpassing 3’ op Departement 1)
Het tweede voordeel voor departement 1 is dat het aantal keer dat een oproep doorverwezen werd,
lager ligt met ‘Aanpassing 3’ dan in het Accio scenario zonder dat hierbij het aantal geselecteerde
0%
10%
20%
30%
40%
50%
80 160 240
Per
cen
tage
sto
ren
de
op
roep
en
Aantal oproepen per week
0
10
20
30
40
50
60
80 160 240
Gem
idd
eld
e w
ach
ttijd
[s]
Aantal oproepen per week
0
250
500
750
1000
1250
1500
1750
2000
80 160 240
Max
imal
e w
ach
ttijd
[s]
Aantal oproepen per week
Page 146
122
zorgverleners per oproep gestegen is. Dit is omdat in het model, en in de realiteit, de kans dat een
zorgverlener een oproep doorverwijst hoger is wanneer hij deze oproep krijgt terwijl hij bezig is met
een andere belangrijke taak.
Een nadeel van de aanpassing is wel dat het systeem niet steeds meer de mogelijkheid krijgt om
rekening te houden met de vertrouwensband. Figuur 78 en Figuur 79 tonen aan dat het percentage
oproepen dat niet beantwoord wordt door iemand met een vertrouwensband inderdaad lager
liggen. Het valt op dat de grafiek, zowel voor het Accio scenario als met ‘Aanpassing 3’, dezelfde
willekeurige trend in functie van het aantal oproepen volgt. Het is aan leidinggevenden om te kiezen
of ze de daling van het percentage storende oproepen of de stijging van het percentage
vertrouwensbreuken het belangrijkst vinden.
Figuur 78: Percentage oproepen dat niet werd behandeld door een zorgverlener met een persoonlijke vertrouwensband met de patiënt (‘Accio’ vs ‘Aanpassing 3’ op Departement 1)
Figuur 79: Percentage oproepen dat niet werd behandeld door een zorgverlener met een sterke persoonlijke vertrouwensband met de patiënt (‘Accio’ vs ‘Aanpassing 3’ op Departement 1)
Departement 2
Voor het tweede departement kunnen precies dezelfde conclusies getrokken worden als voor het
eerste. Het percentage storende oproepen daalt en het aantal keer dat de vertrouwensbanden
gebroken worden, stijgt. In departement 2 wordt ook duidelijk dat het aantal oproepen boven de
aanvaardbare wachttijd van twee minuten daalt met ‘Aanpassing 3’, zoals ook blijkt uit Tabel 19.
Aantal oproepen/week 80 160 240
Accio 7,48% 8,34% 9,30%
Aanpassing 3 6,17% 6,79% 7,18%
Tabel 19: Percentage oproepen met wachttijd langer dan twee minuten (‘Accio’ vs ‘Aanpassing 3’ op Departement 2)
0%
2%
4%
6%
8%
10%
12%
14%
16%
80 160 240
per
cen
tage
Aantal oproepen per week
0%
5%
10%
15%
20%
25%
30%
80 160 240
Per
cen
tage
op
roep
en
Aantal oproepen per week
Page 147
123
Net zoals in Tabel 13 op pagina 108, wordt hier de vergelijking gemaakt tussen de tijdsverdeling
onder de zorgverleners. Hier worden echter ‘Accio’ en ‘Aanpassing 3’ vergelijken in plaats van
‘Traditioneel’ en ‘Effect 1’. De gegevens zijn op dezelfde manier opgesteld als in Tabel 13 waardoor
deze ook op dezelfde wijze kunnen geanalyseerd worden. Uit die Tabel 20 blijkt dat het fenomeen
dat reeds gevonden was in Tabel 13 ook geldt tussen ‘Accio’ en ‘Aanpassing 3’. Dit betekent dus dat
de aanpassing betere resultaten teweeg brengt dan ‘Accio’ op vlak van de werkverdeling.
Bijvoorbeeld ‘Verpleegkundige 1’ krijgt meer taken toegewezen omdat deze buiten oproepen
beantwoorden geen andere vaste taken vervult.
‘Accio’ Direct Utilize ‘Aanpassing 3’ Direct Utilize
Verpleegkundige 1 4,99% 4,99% Verpleegkundige 1 5,65% 5,65%
Verpleegkundige 2 19,92% 6,54% Verpleegkundige 2 18,66% 5,55%
Verpleegkundige 3 34,42% 2,47% Verpleegkundige 3 35,33% 3,39%
Verzorger 1 56,25% 2,85% Verzorger 1 56,57% 2,24%
Verzorger 2 57,12% 2,50% Verzorger 2 53,41% 1,96%
Tabel 20:Tijdsverdeling van zorgverleners tijdens de vroege shift over 'Direct' en 'Utilize' taken bij 800 oproepen per week (‘Accio' vs ‘Aanpassing 3’ op Departement 2)
Page 148
124
8. Discussie & aanbevelingen
In dit hoofdstuk worden eerst de geanalyseerde resultaten uit paragraaf 7.2 kritisch besproken.
Daarna worden enkele aanbevelingen gedaan omtrent het invoeren van het Accio
verpleegoproepsysteem om tot slot te eindigen met suggesties voor verder onderzoek.
8.1. Kritische analyse van het onderzoek
In deze paragraaf worden de resultaten besproken op het vlak van nauwkeurigheid en wordt er
geanalyseerd welke extra data deze nauwkeurigheid zouden kunnen verhogen.
Voor verder onderzoek naar bepaalde KPIs was extra data nodig om bijvoorbeeld richtwaardes,
minima en maxima te kunnen bepalen. Die data zou door het uitvoeren van ‘User Studys’ in
verschillende zorginstellingen kunnen verkregen worden. Deze onderzoeken zouden in dat geval wel
grondig moeten uitgevoerd worden, wat enorm tijdrovend is, waardoor ze buiten de scope van deze
thesis vielen.
Uit de resultaten van Hoofdstuk 7 bleek dat het deel van de beslissingsboom dat filtert op het vlak
van de vertrouwensband tussen zorgverlener en patiënt soms te discriminerend was waardoor er
geen rekening meer kon gehouden worden met de status van de zorgverlener. Meer onderzoek naar
de klachten of ervaringen met het breken van die vertrouwensbanden zou verduidelijken in hoeverre
die sterke discriminatie nodig is. Ook zijn er in de literatuur geen standaardtijden gevonden voor het
behandelen van een oproep, enkel voor het afhandelen van vaste rondes. Een tijdsstudie omtrent de
standaardtijden voor het afhandelen van ieder type oproep zou de simulatie nog realistischer kunnen
maken.
Voorts bleek bij het analyseren van de data van de simulaties dat verschillende KPIs niet gemakkelijk
te evalueren waren. Zo was er de wandelafstand die grotendeels bepaald werd door elementen die
niet afhankelijk waren van de oproepen. Vooral de willekeurige taken zorgden ervoor dat de
verschillen in afstanden resulterend uit de oproepen minimaal waren ten opzichte van de totale
wandelafstand waardoor het moeilijk was om daar conclusies uit te trekken. Ook is er niet geweten
in welke mate deze ingevoerde willekeurige rondes echt representatief zijn voor alle taken die buiten
het beantwoorden van oproepen en het voltooien van de vaste rondes deel uitmaken van het
takenpakket van een zorgverlener. Deze willekeurige rondes werden ingevoerd om een realistische
tijdsverdeling en totale wandelafstand na te streven.
Page 149
125
Ten tweede was de verdeling van de werklast moeilijk te evalueren aangezien die werklast niet alleen
bestaat uit het beantwoorden van oproepen, maar ook uit de vaste rondes die moeten afgewerkt
worden. In de resultaten werd een manier om de werklast te kwantificeren naar voor gebracht en
besproken om een zo goed mogelijke analyse tot stand te kunnen brengen. Toch bleef het moeilijk
om hierbij in elk scenario eenduidige conclusies te bekomen over de invloed van het Accio
verpleegoproepsysteem op de verdeling van de werklast onder de zorgverleners. Ook is het moeilijk
om voor deze werklastverdeling één waarde te bepalen die kan gebruikt worden in de kostenfunctie.
Na het bekijken van alle resultaten, bleek dat het invoeren van ‘Aanpassing 2’ niet onmiddellijk de
invloed op de werklastverdeling had die beoogd werd. Met deze aanpassing werd er bij de keuze
tussen twee of meer zorgverleners op het einde van de beslissingsboom immers enkel rekening
gehouden met het aantal oproepen dat deze zorgverleners tot dan toe beantwoord hadden. Beter
zou geweest zijn om ook rekening te houden met het aantal directe verzorgingstaken ze tot dan toe
al uitgevoerd hadden, zoals wel gedaan werd in de analyses toen de werklastverdelingen vergeleken
werden.
Na het uitvoeren van de simulaties werd ook beslist om wel een kostenfunctie op te stellen, maar
geen waarden vast te hangen aan de gewichten van de KPIs. Dit omdat er niet genoeg geweten is
omtrent de onderlinge waardeverhouding van de KPIs. Ook hier kan een extra ‘User Study’ handig
zijn om deze verhoudingen verder te analyseren, bijvoorbeeld door middel van een rondvraag bij
enkele departementsverantwoordelijken. Het bestand waarmee een totale kost kan berekend
worden na het invullen van de simulatieresultaten is terug te vinden op de CD in bijlage. De
gewichten die daar gebruikt worden voor de KPIs werden eerder arbitrair bepaald aan de hand van
de belangrijkheid van de KPI in de beslissingsboom.
Een belangrijke vraag is natuurlijk of de uitgevoerde simulaties representatief zijn voor andere
departementen. Bij de keuze van de te simuleren departementen werd hier wel degelijk rekening
mee gehouden en werd er gezocht naar twee departementen die verschilden qua structuur en qua
type patiënten. Op die manier werd er gestreefd naar een zo breed mogelijke analyse. Daarbij is alle
data-input gebaseerd op reële data van ‘Televic’ [7] om de simulaties zo representatief mogelijk te
houden. De gebruikte plattegronden zijn gebaseerd op bestaande departementen en zouden daar
dus ook toe moeten bijdragen. De analyses zullen wellicht iets andere resultaten opleveren voor
departementen met een volledig andere lay-out zoals een volledig circulaire of gecentraliseerde lay-
out waarbij alle kamers rond de verplegerspost staan, nog meer dan departement 1, maar dezelfde
belangrijke principes zullen blijven gelden zoals ook bleek uit de vergelijkingen tussen
departementen 1 en 2.
Page 150
126
Tot slot wordt er nog opgemerkt dat de regelset die momenteel in het Accio oproepsysteem gebruikt
wordt bij het versturen van een oproep aan de meest geschikte zorgverleners te discriminerend is
vooraleer kan overgegaan worden op het selecteren op basis van de status van de zorgverleners.
Zoals beschreven werd in paragraaf 7.2.5 heeft dit voornamelijk te maken met de vertrouwensband,
maar belangrijk is om te benadrukken dat het systeem de mogelijkheid moet krijgen om rekening te
houden met de status van de zorgverleners. Anders is het risico te groot dat bepaalde zorgverleners
teveel oproepen krijgen die hun huidige opdracht (kunnen) verstoren. Ofwel kan ervoor geopteerd
worden om de te discriminerende tak minder selectief te maken ofwel kan geopteerd worden om
‘Aanpassing 3’ door te voeren waarbij het overlopen van de statussen hoger in de rangorde van de
beslissingsboom wordt geplaatst. Figuur 34 op pagina 86 verduidelijkt deze aanpassing.
8.2. Aanbevelingen betreffende het invoeren van het Nurse Call Systeem
De resultaten toonden aan dat er afwegingen tussen de KPIs moesten gemaakt worden. In
‘Aanpassing 3’ werd de beslissingsboom aangepast door eerst te differentiëren op basis van de status
van de zorgverlener en daarna pas op basis van de vertrouwensband met de patiënt. Dit leverde
zeer goede resultaten op het vlak van het storen van de zorgverleners, maar behaalde mindere
cijfers op het vlak van het respecteren van de vertrouwensband tussen zorgverlener en patiënt.
Daarom wordt er hier aanbevolen om bij het invoeren van het Accio verpleegoproepsysteem een
tool te ontwerpen die het gemakkelijk maakt voor leidinggevenden om wijzigingen aan te brengen in
de beslissingsboom van het oproepsysteem. Dit kan gaan van kleine aanpassingen, zoals bijvoorbeeld
het aanpassen van de grens voor het hebben van een vertrouwensband met de patiënt of het
aanpassen van de straal in de definitie van ‘Close’, tot grotere, zoals het veranderen van de volgorde
van de takken in de beslissingsboom. Op die manier kunnen leidinggevenden het oproepsysteem niet
alleen aanpassen aan de specifieke kenmerken van hun departement, maar ook hun eigen
voorkeuren beter naar voor laten komen.
Een algemene aanbeveling die voortkomt uit de resultaten en geldig zou zijn voor het invoeren van
het verpleegoproepsysteem in elk mogelijk departement kon dus niet opgesteld worden omdat er
nog te weinig voeling was met welke KPIs in welke departementen echt belangrijk zijn.
8.3. Suggesties voor verder onderzoek
In de toekomst zou nog onderzoek kunnen gedaan worden naar een volledig generische vertaaltool
die de vertaling in beide richtingen tot stand kan brengen. Het voordeel van een volledig generische
tool is ook dat deze niet alleen geldig zou zijn voor de regels uit het oproepsysteem, maar ook voor
Page 151
127
regels uit andere systemen die met ontologieën werken, zoals bijvoorbeeld in O’Care Clouds [64]. De
generieke tool die moet ontworpen worden, moet dan alle soorten regels vanuit RIF naar C++
kunnen vertalen zonder een tekstvergelijking te moeten maken.
Het model werd opgebouwd in FlexSim, maar er kan niet geëist worden van elke zorgverlener om
met dit softwarepakket te kunnen werken. Een oplossing daarvoor zou het ontwerp van een
eenvoudig gebruikersplatform kunnen zijn. Dat platform moet als gebruiksvriendelijke tussenstap
dienen om snel aanpassingen aan de regelset te kunnen invoeren en om op nog eenvoudigere wijze
een eigen departement met eigen zorgverleners en eigen vaste rondes na te bouwen zonder dat
daarvoor enige kennis nodig is van FlexSim. FlexSim bezit reeds de functionaliteit om dit te
installeren in de ‘Graphical User Interface’ (GUI), maar in deze thesis werd daar nog niet mee
geëxperimenteerd.
Page 152
128
9. Conclusie
Het eerste doel van deze thesis was om door het ontwerp van het model in een simulatiesoftware na
te gaan of het omgevingsbewuste intelligente verpleegoproepsysteem, dat voortvloeide uit het Accio
project, met de huidige regelset operationeel inzetbaar is en wat de effecten van de invoer zouden
zijn op verschillende vooraf gedefinieerde KPIs. Uit de resultaten kwamen zowel voor- als nadelen
aan het licht. Om te beginnen bleek dat de verdeling van de wachttijden in het departement met het
Accio oproepsysteem een ander verloop kende dan met het traditionele oproepsysteem. Er werd
opgemerkt dat er bij het Accio systeem meer oproepen werden behandeld binnen een aanvaardbare
wachttijd dan bij het traditionele systeem. Dit was een rechtstreeks gevolg van de extra
mogelijkheden die zorgverleners nu hebben om op een oproep te antwoorden, zoals bijvoorbeeld
het in de wacht zetten of het afwijzen van oproepen. Op die manier komt het minder vaak voor dat
de patiënt moet wachten totdat de opgeroepen zorgverlener klaar is met een andere taak.
Uit de vergelijking van het traditionele scenario met ‘Effect 1’, waarbij het Accio oproepsysteem werd
getest met een gelijk personeelsbestand als in het traditionele scenario, konden enkele conclusies
getrokken worden over de prestaties van het Accio verpleegoproepsysteem op het vlak van
werklastverdeling en wandelafstanden. De analyse toonde aan dat het systeem erin slaagde om de
zorgverleners die al een groot deel van hun shift bezet waren met het uitvoeren van vaste rondes
minder aan te wijzen voor oproepen. Op die manier werd de werklast over de totale shift beter
verdeeld over de verschillende zorgverleners dan in het traditionele scenario, waar de patiënten
arbitrair werden toegewezen aan zorgverleners. De invloed op de wandelafstanden hing rechtstreeks
af van de werklastverdeling, maar deze invloed was eerder klein aangezien zorgverleners ongeveer
slechts 5% van hun shift bezig zijn met het beantwoorden van oproepen. De wandelafstanden die de
zorgverleners tijdens de andere 90 tot 95% van hun shift afleggen kon dus moeilijk geoptimaliseerd
worden.
Voorts bleek uit de vergelijking van het Accio scenario met scenario 1 dat het in dienst nemen van
verzorgers met minder kwalificaties in plaats van verplegers geen grote wijzigingen teweegbracht
aan de KPIs. Daarbij moet er uiteraard wel een minimum aan medische verplegers aanwezig zijn op
het departement om voldoende medische kennis te garanderen, maar op die manier kan een
ziekenhuis toch besparen op de loonkosten.
Het invoeren van het nieuwe systeem bracht zoals gezegd niet alleen voordelen met zich mee. Zo
werden zorgverleners in departement 4K6 vaker gestoord met het Accio systeem dan met het
oorspronkelijke, wat toch verwonderlijk is aangezien er door het invoeren van een regelset net
Page 153
129
geprobeerd wordt om dit minder te laten voorkomen. Verder onderzoek bracht aan het licht dat dit
te wijten was aan de te grote selectie die gebeurde op basis van de vertrouwensband. Dit zorgde
ervoor dat de beslissingsboom de mogelijkheid om te differentiëren op basis van de status van de
patiënt in veel gevallen verloor. Tijdens de ontwikkeling van het oproepsysteem in het Accio project
was er discussie omtrent het al dan niet opnemen van de vertrouwensband in de beslissingsboom.
De resultaten toonden aan dat deze tak voor een departement met weinig zorgverleners beter kon
weggelaten worden of, zoals voorgesteld bij ‘Aanpassing 3’, beter geplaatst werd na de differentiatie
op de status van de zorgverleners.
Tot slot wordt er voor het Accio systeem nog de opmerking gemaakt dat het systeem zijn nut vooral
bewijst bij grotere departementen. Dit omdat het systeem er dan beter in slaagt om al zijn
mogelijkheden te benutten en de correcte mensen uit de lijst van de zorgverleners te halen, rekening
houdend met alle aspecten van de beslissingsboom.
In het tweede deel van de thesis moest een automatische vertaaltool ontworpen worden voor het
omzetten van de regelset uit de ontologie naar een regelset die implementeerbaar was in de DES
Software. Er werd besloten dat er niet vertrokken werd vanuit de Jena regels, maar vanuit diezelfde
regels in RIF. Dit omdat Jena regels niet meer frequent gebruikt worden, in tegenstelling tot RIF dat
recentelijk ontworpen is om een formaat te bieden om verschillende taaldialecten samen te
brengen. De tool is er gekomen onder de vorm van een teksteditor, geschreven in Python. Ze zet de
regels in RIF om naar FlexScript zodat deze dan kunnen gebruikt worden in de FlexSim simulator. De
vertaaltool werkt voor alle type regels die voorkomen in het Accio oproepsysteem. Dit deel van de
thesis is dus met succes afgehandeld, aangezien men met één druk op de knop een tekstbestand met
RIF kan omzetten naar één in FlexScript. Deze tekst kan dan gemakkelijk geplakt worden in de
daarvoor voorziene ruimte in de FlexSim ‘User Command’.
Page 155
131
10. Referenties
[1] B. Haeck, „Onze mening na een week in het ziekenhuis,” De Tijd, 2013.
[2] Medicare Systems, „Display panels,” 2011. [Online]. Available: http://www.medicaresystems.co.uk/nurse-call-products/display-panels/. [Geopend 6 December 2013].
[3] Hill-rom, „NaviCare Nurse Call,” 2014. [Online]. Available: http://www.hill-rom.com/usa/Products/Category/Workflow-and-Communications/NaviCare-Nurse-Call/. [Geopend 24 February 2014].
[4] B. &. R. I. Haeck, „Waarom uw ziekenhuis vecht om te overleven,” De Tijd, pp. 4-5, 19 Oktober 2013.
[5] iMinds, „Accio - Ambient aware provisioning of continuous care for intra-muros organization,” [Online]. Available: http://www.iminds.be/nl/projecten/2014/03/04/accio. [Geopend 3 Oktober 2013].
[6] Televic, „Televic Healthcare - Nurse Call,” 2014. [Online]. Available: http://www.televic-healthcare.com/en/INTERAXIONURSECALL. [Geopend 29 Oktober 2014].
[7] Televic, „Geanonimiseerde logginggegevens van het Televic verpleegoproepsysteen geïnstalleerd bij Universitair Hospitaal Gent in 3 representatieve afdelingen.,” Gent, 2008.
[8] Ongenae, „An ontology-based nurse call management system (oNCS) with probabilistic priority assessment.,” BMC Health Services Research 2011, p. 11:26.
[9] Patient Room of the Future, „Patient Room of the Future,” [Online]. Available: http://www.prof-projects.com/. [Geopend 27 May 2014].
[10] I. Renson, „'De druk is immens. Het is wachten op de fout',” De Tijd, p. 7, 22 Oktober 2013.
[11] W. A. R. M. D. W. D. R. Westbrook JI, „Association of Interruptions With an Increased Risk and Severity of Medication Administration Errors.,” Archives of Internal Medicine, pp. 170(8):683-690, 2010.
[12] H. B. &. R. Ine, „'Ik weet dat we sommigen ongelukkig zullen maken',” De Tijd, pp. 11-12, 26 Oktober 2013.
[13] L. Annemans, De prijs van uw gezondheid, Tielt: Uitgeverij Lannoo, 2014.
[14] J. D'Hoore, „De PS toont geen visie over zorg,” De Tijd, p. 7, 19 Februari 2014.
[15] L. Ide, Lof der gezondheid: een voorschrift voor een zieke gezondheidszorg, Tielt: Uitgeverij Lannoo, 2014.
[16] Medscape, „Time to battle alarm fatigue,” 20 February 2014.
[17] Medscape, „Alarm Fatigue Still Top Technology Hazard for 2013,” 30 May 2013.
[18] F. Ongenae, Ontwerp en beheer van ontologieën voor elektronische zorgdiensten, 2013.
[19] M. Meyers, „Calling all nurses,” Health Facilities Management, vol. 2, pp. 20-24, March 2011.
[20] Televic Healthcare, „Voorstelling patiëntenkamer van de toekomst,” 1 July 2010. [Online]. Available: http://www.televic-healthcare.com/nl/PRoF. [Geopend 18 February 2014].
[21] F. O. e. al, „User-driven design of a context-aware application: an ambient-intelligent nurse call system,” INTEC, Ghent University, Gent.
[22] T. R. Gruber, „Toward principles for the design of ontologies used for knowledge sharing,” International Journal Human-Computer Studies, vol. 43, nr. 5-6, pp. 907-928, 1995.
Page 156
132
[23] S. Verstichel, „Semantiek als middel voor een efficiëntere informatie-integratie,” Gent, 2012.
[24] World Wide Web Consortium (W3C), „RIF RDF and OWL Compatibility (Second Edition),” [Online]. Available: http://www.w3.org/TR/2013/REC-rif-rdf-owl-20130205/. [Geopend 19 05 2014].
[25] „W3C: World Wide Web Consortium,” [Online]. Available: http://www.w3.org.
[26] F. O. L. L. F. D. T. F. V. P. D. B. D. a. T. D. S. Verstichel, „Efficient data integration in the railway domain through an ontology-based methodology,” in Transportation Research Part C: Emerging technologies, vol. 19, 2011, pp. 617-643.
[27] M. Horridge, „A Practical Guide To Building OWL Ontologies Using Protégé 4 and CO-ODE Tools (Edition 1.3),” The University of Manchester, Manchester, 2011.
[28] Simio, „Simulation Software: Application Areas,” Simio, [Online]. Available: http://www.simio.com/applications/. [Geopend 28 05 2014].
[29] Wikipedia, „Continuous Simulation,” [Online]. Available: http://en.wikipedia.org/wiki/Continuous_simulation. [Geopend 28 05 2014].
[30] Wikipedia, „Process Simulation,” [Online]. Available: http://en.wikipedia.org/wiki/Process_simulation. [Geopend 28 05 2014].
[31] Wikipedia, „List of Discrete Event Simulation Software,” [Online]. Available: http://en.wikipedia.org/wiki/List_of_discrete_event_simulation_software. [Geopend 15 05 2014].
[32] Wikipedia, „Tortuga (Software),” [Online]. Available: http://en.wikipedia.org/wiki/Tortuga_(software). [Geopend 12 05 2014].
[33] J. Nutaro, „adevs,” [Online]. Available: http://web.ornl.gov/~1qn/adevs/. [Geopend 6 11 2013].
[34] Rockwell Automation, Arena User's Guide, USA: Rockwell Automation Inc., 2013.
[35] Rockwell Automation, „Arena Simulation Software,” Rockwell, [Online]. Available: http://www.arenasimulation.com. [Geopend 25 05 2014].
[36] Arena, „Arena Simulation Software,” [Online]. Available: http://www.arenasimulation.com. [Geopend 28 05 2014].
[37] FlexSim Software Products (FSP), „FlexSim,” [Online]. Available: www.flexsim.com. [Geopend 16 Oktober 2013].
[38] Flexsim Software Products (FSP), „FlexSim Healthcare,” [Online]. Available: www.flexsim.com/flexsim-healthcare. [Geopend 18 Oktober 2013].
[39] Universidad de Los Andes, „Glider with Autonomous, Logic-based Agents,TEmporal reasoning and Abduction (GALATEA),” Galatea Group, [Online]. Available: http://galatea.sourceforge.net. [Geopend 13 11 2013].
[40] George Mason University's Evolutionary Computation Laboratory and the GMU Center for Social Complexity, „MASON,” [Online]. Available: http://cs.gmu.edu/~eclab/projects/mason/. [Geopend 03 11 2013].
[41] C. C.-R. L. P. K. S. a. G. B. Sean Luke, „MASON: A Multi-Agent Simulation Environment,” Simulation: Transactions of the society for Modeling and Simulation International, pp. 517-527, 2005.
[42] Team SimPy, „SimPy,” [Online]. Available: https://bitbucket.org/simpy/simpy/. [Geopend 19 05 2014].
[43] N. Matloff, „Introduction to Discrete-Event Simulation and the SimPy Language,” 2008.
Page 157
133
[44] TIBCO Software Inc., „TIBCO,” [Online]. Available: www.tibco.nl. [Geopend 24 Oktober 2013].
[45] TIBCO, „TIBCO Event Processing,” TIBCO, [Online]. Available: http://www.tibco.com/products/event-processing/complex-event-processing/businessevents/default.jsp. [Geopend 25 05 2014].
[46] I. Banerjee, „Event Processing with TIBCO BusinessEvents,” TIBCO, Palo Alto, 2014.
[47] MITRE Corporation, „tortugades,” [Online]. Available: https://code.google.com/p/tortugades/. [Geopend 03 11 2013].
[48] TIBCO, TIBCO Business Events User Guide, TIBCO, 2008.
[49] TIBCO, TIBCO Business Events Getting Started, TIBCO, 2011.
[50] TIBCO, „Importing an Excel File into TIBCO BusinessEvents Decision Manager at the Command Line,” [Online]. Available: https://docs.tibco.com/pub/businessevents_decision_manager/4.0.1-november-2010/html/tib_be_decision_manager_users_guide/wwhelp/wwhimpl/common/html/wwhelp.htm#context=tib_be_decision_manager_users_guide&file=decision_tables.09.08.htm. [Geopend 27 5 2014].
[51] FlexSim, „Why FlexSim?,” [Online]. Available: http://www.flexsim.com/. [Geopend 16 05 2014].
[52] FlexSim, „FlexSim Users Guide,” FlexSim, 2011.
[53] FlexSim, „FlexSim HealthCare,” [Online]. Available: http://www.flexsim.com/flexsim-healthcare/. [Geopend 26 05 2014].
[54] World Wide Web Consortium (W3C), „OWL 2 Web Ontology Language,” 11 December 2012. [Online]. Available: http://www.w3.org/TR/owl2-overview. [Geopend 27 Mei 2014].
[55] Microsoft, Microsoft Visual Studio C++ 2008, 2008.
[56] World Wide Web Consortium (W3C), “RIF Primer,” 28 October 2012. [Online]. Available: http://www.w3.org/2005/rules/wg/draft/ED-rif-primer-20121028/. [Accessed 28 April 2014].
[57] Wimmics, „RIF-BLD Validation Service,” [Online]. Available: http://wimmics-ws.inria.fr/rifparser/index.jsp. [Geopend 16 05 2014].
[58] Royal College of Nursing, „Policy Briefing: Mandatory Nurse Staffing levels,” RCN: London, 2012.
[59] P. A. L. B. P. L. K. M. R. CHRISTINE M. MEADE, „Effects of Nursing Rounds on Patients’ Call Light Use, Satisfaction, and Safety,” Continuing Education, pp. 58-70, 2006.
[60] D. V. G. V. L. M. G. S. V. &. T. D. Dries Myny, „Determination of standard times of nursing activities based on a Nursing Minimum Dataset,” Journal of Advanced Nursing, pp. 92-102, 31 July 2009.
[61] D. Myny, Developing standard times for the Belgian Nursing Minimum Dataset activities and identifying factors influencing the nursing workload., Ghent, 2012.
[62] C. D. L. L. a. N. J. C. Johanna I Westbrook, „How much time do nurses have for patients? a longitudinal study quantifying hospital nurses' patterns of task time distribution and interactions with health professionals,” BMC Health Services Research, p. 11:319, 2011.
[63] R. H. &. L. T.-S. Heather Williams, „Work sampling: a quantitative analysis of nursing activity,” Journal Of Advanced Nursing (JAN), pp. 2097-2107, 2009.
[64] KU Leuven, „Organizing Care through trusted Cloudy-like Services (O'CareClouds),” 11
Page 158
134
October 2013. [Online]. Available: https://distrinet.cs.kuleuven.be/research/projects/showProject.do?projectID=OCareClouds. [Geopend 27 May 214].
[65] I. Renson, „Geen dokter voor uw oude dag,” De Tijd, p. 7, 23 Oktober 2013.
[66] Wimmics: web-instrumented man-machine interactions, communities and semantics, „RIF-BLD Validation Service,” [Online]. Available: http://wimmics-ws.inria.fr/rifparser/. [Geopend 10 11 2013].
[67] H. B. Michael Kifer, „RIF Overview (Second Edition) W3C Working Group Note,” 5 Februari 2013. [Online]. Available: http://www.w3.org/TR/rif-overview/. [Geopend 16 Oktober 2013].
Page 159
135
11. Bijlagen
11.1. Verklarende FlexSim woordenlijst
Source Standaardelement waarin alle oproepen vooraf geprogrammeerd staan met
alle bijhorende labels en details. Op de ingestelde tijdstippen verstuurt de
‘Source’ de oproepen naar de correcte kamer zodat daar hulp van een
zorgverlener kan gevraagd worden.
Dispatcher Standaardelement waar de volledige regelset van het oproepsysteem wordt
geprogrammeerd. Krijgt als input een oproep en geeft als output een lijst
met één of meerdere zorgverleners die toegewezen worden aan die
oproep. Deze code staat volledig los van de werking van de simulatie.
Experimenter Een invoegtoepassing die de gebruiker toelaat om een Monte Carlo
simulatie uit te voeren. Op die manier wordt het model een vooropgesteld
aantal keer afgespeeld, om zo op gemakkelijke wijze de verschillende KPIs
met hun gemiddeldes en standaardafwijkingen te berekenen.
Normal Call Normale oproep afkomstig van een patiënt die niet geclassificeerd werd als
urgentieoproep.
Context Call Oproep gelanceerd door de controlesystemen aan het bed bij het
registreren van afwijkende waarden.
Assistance Call Assistentieoproep afkomstig van een zorgverlener die bezig is met het
beantwoorden van een oproep en daarbij hulp nodig heeft.
Filtered Staff Members Lijst met beschikbare zorgverleners die tijdens het doorlopen van de
beslissingsboom voortdurend wordt aangepast tot er slechts één
zorgverlener overblijft of tot het einde van de beslissingsboom bereikt is.
Basic Unit Bouwsteen in de FlexSim bibliotheek met alle code reeds geïmplementeerd.
Het kan hier gaan om een kamer, een sanitaire ruimte, een zorgverlener
enzovoort. Met deze bouwstenen kan een leidinggevende snel zijn eigen
departement zo nauwkeurig mogelijk nabouwen.
Page 160
136
User Command Functie die in FlexSim kan geprogrammeerd worden. Deze functie kan dan
opgeroepen in ieder deel code van de simulatie. Onder andere de regelset
is op deze manier geïmplementeerd in het model.
Medical Zorgverlener met de vereiste kwalificaties, ook wel verpleegkundige
genoemd, wordt in de Engelse literatuur als ‘Registered Nurse’ vermeld.
Care Zorgverlener zonder de vereiste kwalificaties om medische oproepen te
beantwoorden, mag ook geen medicatie ronddelen. Deze wordt in de tekst
ook verzorger genoemd. Hulp bij wassen en sanitaire assistentie is wel
toegelaten.
Logistics Assistant Personeelslid dat enkel hoteloproepen mag beantwoorden. Wordt aan het
personeelsbestand toegevoegd om de werkdruk van verzorgers en
verpleegkundigen te verlagen. Kan ook ingeschakeld worden voor het
rondbrengen van eten en het afruimen.
Head Nurse Hoofdverpleger, zorgt voor de coördinatie op het departement, doet vooral
administratieve taken. Wordt in eerste instantie niet aangesproken om
oproepen te beantwoorden, kan eventueel wel wanneer niemand
beschikbaar is.
Page 161
137
11.2. Overzichtstabel van de personeelsleden
Profiel Competentie Training Ervaring
Hoofdverpleger Medisch, Oproep Zorg, Hotel
Dokter Dokter nodig Medisch Zorg, Hotel
Zorgverlener (‘Medical’) Medisch, Zorg, Oproep Hotel
Logistiek medewerker Hotel, Oproep
Verzorger (‘Care’) Zorg, Oproep Hotel
Assistent Hotel
Enkele opmerkingen omtrent de profielen in het model:
De profielen van dokter en assistent werden in dit model niet meegenomen.
De zorgverleners die als competentie ‘Oproep’ hebben, bezitten in het model altijd een
toestel om oproepen te beantwoorden. De hoofdverpleger heeft ‘Oproep’ enkel als
Trainingscompetentie waardoor ze wel opgeroepen kan worden, maar niet verondersteld
wordt het toestel altijd bij te hebben.
Een competentie uit ervaring geldt in dit model als een soort oproep waar zorgverleners met
dit profiel zich eigenlijk niet mee moeten bezig houden. Zo wordt de hoofdverpleger niet
verondersteld om hoteloproepen te beantwoorden, omdat zij aangeworven is voor het
uitvoeren van andere taken. Wanneer ze wel aangewezen wordt voor dit soort oproepen,
kan dat beschouwd worden als een ongunstige situatie. Hetzelfde geldt voor
trainingscompetenties, maar daar weegt het minder zwaar door.
Page 162
138
11.3. Originele beslissingsboom Accio scenario
Page 164
140
11.4. Verplegersrondes in model
NACHT
22u30 Check-up door nieuwe shift 0.84 u
03u00 Check-up nacht 0.84 u
VROEG
6u00 Lange wasronde 6.9 u
6u00 Medicatieronde en check-up nieuwe shift 0.75 u + 1.5 u = 2.25 u
8u00 Ontbijtronde 1.08 u
9u30 Afruimronde 0.6 u
11u00 Check-up ronde 0.84 u
12u00 Lunchronde 1.08 u
13u30 Afruimronde 0.6 u
LAAT
14u30 Check-up door nieuwe shift 0.84 u
16u00 Koffieronde 0.9 u
17u00 Avondetenronde 1.08 u
18u00 Korte wasronde 3.6 u
18u30 Afruimronde 0.6 u
20u00 Check-up ronde 0.84 u
Page 165
141
11.5. Inhoud van de bijgevoegde CD
In deze bijlage wordt een overzicht gegeven van alle bestanden die ter beschikking gesteld zijn
op bijgevoegde CD achteraan dit thesisboek.
1. Map ‘Automatische vertaaltool’
a. Handleiding Python vertaaltool
Handleiding voor het gebruik van de automatische vertaaltool ‘Vertaaltool.py’.
b. ruleset.txt
Tekstbestand dat als input dient voor de automatische vertaaltool. Het bevat alle
regels (in RIF) die gebruikt werden om de vertaaltool op te bouwen.
c. Regelset_FlexScript.txt
Tekstbestand dat alle regels uit ‘ruleset.txt’ bevat, vertaald in FlexScript. Dit bestand
is dus identiek aan het bestand ‘ruleset_FlexScript.txt’ dat als output zal gegenereerd
worden na het runnen van de automatische vertaaltool, zodat het als controle kan
dienen.
d. RIF VALIDATOR
Link naar de online Wimmics RIF Validator [57] waarmee elke RIF regel kan
gevalideerd worden vooraleer hij als input ingevoerd wordt in de automatische
vertaaltool.
e. Vertaaltool.py
Python bestand dat de automatische vertaling van regels verzorgt tussen RIF en
FlexScript.
2. Map ‘Simulaties’
a. Handleiding tot het runnen van een simulatie in FlexSim
Handleiding om zelf één van de scenario’s te runnen met een bepaald aantal
oproepen per week om zelf nieuwe resultaten te genereren.
b. Map ‘Data’
Bevat voor beide departementen de Excel bestanden die ingeladen werden in de
simulaties voor elk aantal oproepen per week. Deze werden gebruikt voor alle
scenario’s met hetzelfde aantal oproepen per week.
Voorbeeld: ‘Dep1_40.xlsm’ : Oproepenbestand dat werd gebruikt in de simulaties op
departement 1 voor 40 oproepen per week.
c. Map ‘Simulatiebestanden’
Bevat voor beide departementen de FlexSim bestanden die gebruikt werden om de
resultaten te genereren. Hierbij zijn alle bestanden toegevoegd, voor elk scenario en
elk aantal oproepen per week.
Voorbeeld: ‘Effect2_dep2_600.fsm’ : FlexSim simulatie die gebruikt werd om
resultaten te genereren voor het scenario ‘Effect 2’ op departement 2 voor 600
oproepen per week.
d. Map ‘Resultaten’
Bevat de resultaten voor alle simulaties die uitgevoerd werden op beide
departementen. In deze Excel bestanden zijn ook telkens de resultaten van het Accio
scenario bijgevoegd, zodat gemakkelijk kan vergeleken worden.
Page 166
142
Voorbeeld: ‘Resultaten_AcciovsAanpassing3_Dep2.xlsm’ : Excel bestand dat de
resultaten bevat van zowel ‘Accio’ als ‘Aanpassing 3’ op departement 2, voor elk
aantal oproepen per week.
3. Map ‘FlexSim Bibliotheek’
Bevat de bibliotheek met alle Basic Units, opgebouwd zijn in FlexSim, die nodig zijn om zelf
een departement samen te stellen.
4. ‘Kostenfunctie.xlsx’
In dit Excel bestand is getracht om een eenvoudige tool op te stellen, waarin de waarden
voor alle KPIs kunnen ingevuld worden. Deze waarden worden automatisch genormeerd
naar een waarde tussen 0 en 1 aan de hand van arbitrair bepaalde minima en maxima voor
deze KPIs. Door deze genormeerde waarden te vermenigvuldigen met hun respectievelijke
gewicht wordt dan de uiteindelijke globale kost berekend. Deze gewichten zijn nu arbitrair
bepaald aan de hand van de volgorde van de boom en kunnen naar voorkeur aangepast
worden. Er is in een tabblad een voorbeeld bijgevoegd voor ‘Effect 1’ op departement 1 met
80 oproepen per week.