Techno-economische evaluatie van eHealth...

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

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

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.

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

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.

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

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

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)


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


Accio

Traditional

Effect 3

8

8,5

9

9,5

10

10,5

600 700 800To

tal t

rave

lled

dis

tan

ce [

km]


Accio

Effect 3

0

500

1000

1500

2000

80 160 240

Wai

tin

g ti

me

[s]


Accio

Adjustment 1

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


Accio

Adjustment 3

0%

5%

10%

15%

80 160 240

Per

cen

tage

han

dle

d c

alls


Accio

Adjustment 3

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

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

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

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 71: Percentage oproepen dat minstens eenmaal werd doorverwezen (‘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 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

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

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

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



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

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]

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?’

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

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.

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]

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.

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.

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.

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

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

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]

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

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]

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

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]

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.

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.

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

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]

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

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.

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.

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

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.

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

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

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]

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

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

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

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.

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

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.

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

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

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.

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.

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.

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

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

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.

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.

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

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.

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.

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.

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.

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

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

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.

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:

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

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.

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

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.

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.

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.

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

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

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

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

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

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

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.

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.

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

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

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

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.

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.

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

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

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





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

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









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]

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

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

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

















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.

78

Periode Tijdstippen [s] Tijdstippen [uu:mm] % oproepen Lengte Periode

Periode 1 0 - 5000 00:00 - 01:25 4,40 5000 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]

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.

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

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 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

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)


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 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

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

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’

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.

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

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.

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]


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

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.

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


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


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.

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


0%

10%

20%

30%

40%

50%

40 80 120 160 200 240 280

Per

cen

tage

sto

ren

de

op

roep

en


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

]


FemaleNurse_Nacht FemaleNurse_Vroeg MaleNurse_Vroeg

Care_Vroeg FemaleNurse_Laat MaleNurse_Laat

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.

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

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


0%

5%

10%

15%

20%

25%

600 650 700 750 800

Per

cen

tage

sto

ren

de

op

roep

en


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.

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]


0

250

500

750

1000

1250

1500

1750

2000

40 80 120 160 200 240 280

Max

imal

e w

ach

ttijd

[s]


Accio

Traditioneel

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

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

]


KM/shift FemaleNurse_Nacht KM/shift FemaleNurse1_VroegKM/shift FemaleNurse2_Vroeg KM/shift MaleNurse_VroegKM/shift FemaleNurse_Laat KM/shift MaleNurse_Laat

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.

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


Accio

Traditioneel

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

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


Accio

Traditioneel

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


Accio

Scenario 1

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


0%

5%

10%

15%

20%

25%

30%

35%

600 700 800

Per

cen

tage

do

orv

erw

ezen

op

roep

en


Accio

0

10

20

30

40

50

60

600 700 800

Gem

idd

eld

e w

ach

ttid

j [s]


0

250

500

750

1000

1250

1500

1750

2000

600 700 800

Max

imal

e w

ach

ttijd

[s]


Accio

Scenario 1

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

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%





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.

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

]


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

]


Traditioneel

Effect 1

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.


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

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)


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.


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


Accio

Scenario 4

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


0%

10%

20%

30%

40%

50%

80 160 240

Per

cen

tage

sto

ren

de

op

roep

en


Scenario 5

Accio

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


Accio

Effect 3

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)


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]


0250500750

10001250150017502000

80 160 240

Max

imal

e w

ach

ttijd

[s]


Scenario 5

Accio


Accio 7,31% 10,01% 10,90%

Effect 3 5,53% 7,68% 8,88%

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

]


Accio

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]


Accio

Scenario 2

117

percentage oproepen dat langer dan twee minuten blijft openstaan blijft ook gelijkaardig (7,72%

voor ‘Aanpassing 1’ en 8,11% voor ‘Accio’).


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.

118

Figuur 69: Gemiddelde 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]


0250500750

10001250150017502000

80 160 240

Max

imal

e w

ach

ttijd

[s]


Accio

Scenario 3

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)



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


Accio

Aanpassing 2

0

10

20

30

40

50

60

600 700 800

Gem

idd

eld

e w

ach

ttijd

[s]


0

250

500

750

1000

1250

1500

1750

2000

600 700 800

Max

imal

e w

ach

ttijd

[s]


A…

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)


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

]


Accio

Aanpassing 2

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.



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


0

10

20

30

40

50

60

80 160 240

Gem

idd

eld

e w

ach

ttijd

[s]


0

250

500

750

1000

1250

1500

1750

2000

80 160 240

Max

imal

e w

ach

ttijd

[s]


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.


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


0%

5%

10%

15%

20%

25%

30%

80 160 240

Per

cen

tage

op

roep

en


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




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)

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.

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.

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

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.

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

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’.

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.

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.

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

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].

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.

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.

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.

138

11.3. Originele beslissingsboom Accio scenario

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


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


20u00 Check-up ronde 0.84 u

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.

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.

Techno-economische evaluatie van eHealth...

Documents

Transcript of Techno-economische evaluatie van eHealth...