le transport intrahospitalier : conception et ... · afin de supporter les différentes activités...
TRANSCRIPT
© Maxime Painchaud, 2019
Le transport intrahospitalier : conception et développement d'un modèle de simulation
Mémoire
Maxime Painchaud
Maîtrise en sciences de l'administration - opérations et systèmes de décision -
avec mémoire
Maître ès sciences (M. Sc.)
Québec, Canada
Le transport intrahospitalier : Conception et développement d'un modèle de simulation
Mémoire
Maxime Painchaud
Sous la direction de :
Angel Ruiz, directeur de recherche
Valérie Bélanger, codirectrice de recherche
iii
Résumé
Afin de supporter les différentes activités au sein d’un centre hospitalier, le département de logistique
est primordial pour offrir un service de qualité. Plus particulièrement, un service de brancarderie est
nécessaire afin d’acheminer les patients non autonomes ou du matériel aux différentes unités de soins.
La planification de ces activités de transport présente d’importants défis, car elle s’opère dans un
environnement dynamique et imprévisible. En plus, l’aspect humain des transports apporte son lot de
complication.
Ce document traitera de la problématique du transport intrahospitalier au Centre Hospitalier
Universitaire de Sherbrooke (CHUS). Cet établissement de santé coordonne ses activités de transports
par le biais d’un système centralisé affectant des requêtes de transports aux différents brancardiers.
L’outil de simulation va permettre de reproduire les flux à l’intérieur d’un établissement cible. Ensuite,
le comportement du modèle de simulation sera mesuré et analysé lorsque des modifications au niveau
des différents paramètres sont apportées.
iv
Table des matières Résumé .............................................................................................................................................................. iii
Table des matières ............................................................................................................................................. iv
Table des figures ................................................................................................................................................ vi
Table des tableaux.............................................................................................................................................. vi
Introduction ......................................................................................................................................................... 1
Objectif ........................................................................................................................................................... 2
1. Le transport intrahospitalier ............................................................................................................................ 3
1.1. La gestion du transport de personnes ..................................................................................................... 5
1.2. Enjeux ..................................................................................................................................................... 6
1.3. Revue de littérature ................................................................................................................................. 7
1.4. La solution de Christi InnoMed, Stat-Dev Transort .................................................................................. 9
1.4.1. Tableau de bord ............................................................................................................................. 10
1.4.2. Mode de fonctionnement et paramétrage ...................................................................................... 13
1.4.3. Statistiques et traçabilité ................................................................................................................ 14
2. Le modèle de simulation ............................................................................................................................... 15
2.1. Historique .............................................................................................................................................. 15
2.2. Les fondements de la simulation ........................................................................................................... 16
2.3. La simulation dans un contexte de gestion............................................................................................ 16
2.4. Application de la simulation ................................................................................................................... 17
2.5. Étapes d’un projet de simulation ........................................................................................................... 17
2.6. Modèle de simulation ............................................................................................................................. 18
2.7. Simulation à événements discrets ......................................................................................................... 19
3. Implantation du simulateur ............................................................................................................................ 21
3.1. Système réel.......................................................................................................................................... 21
3.1.1. Algorithme de décision ................................................................................................................... 22
3.1.2. Comportement de l’algorithme d’affectation ................................................................................... 23
3.2. Modèle de simulation ............................................................................................................................. 25
3.2.1. Hypothèses et différences entre la réalité et le modèle.................................................................. 28
3.2.2. Algorithme du modèle de simulation .............................................................................................. 29
3.3 Codage du simulateur ............................................................................................................................ 30
3.3.1. Matrice Origine-Destination ............................................................................................................ 30
v
3.3.2. Liste de brancardiers ...................................................................................................................... 31
3.3.3. Générateur de requêtes ................................................................................................................. 31
3.3.3.1. Temps d’arrivée ...................................................................................................................... 31
3.3.3.2. Origine, destination, niveau de priorité et facteur d’importance .............................................. 34
3.3.4. Moteur de simulation ...................................................................................................................... 35
3.3.5. Mesures de performance ............................................................................................................... 36
3.4. Algorithme de la simulation ................................................................................................................... 36
3.4.1. Algorithme des trois phases (Tocher, 1963) .................................................................................. 37
3.4.1.1. Algorithme des 3 phases - Phase A ........................................................................................ 37
3.4.1.2. Algorithme des 3 phases - Phase B ........................................................................................ 37
3.4.1.3. Algorithme des 3 phases - Phase C ....................................................................................... 38
3.4.2. Routine d’initialisation et condition de fin ....................................................................................... 39
3.5. Langage de programmation .................................................................................................................. 39
4. Validation et vérification ................................................................................................................................ 40
4.1. Définition de vérification et validation .................................................................................................... 40
4.2. Validation des entrants .......................................................................................................................... 41
4.3. Vérification du code et de la logique ...................................................................................................... 42
4.4. Observation des extrants ....................................................................................................................... 43
5. Expériences numériques .............................................................................................................................. 45
5.1. Définition des expériences .................................................................................................................... 45
5.2. Mesure de performance ........................................................................................................................ 45
5.2.1. Temps d’attente système ............................................................................................................... 45
5.2.2. Temps d’attente patient .................................................................................................................. 46
5.2.3. Équipe de brancarderie .................................................................................................................. 46
5.3. Résultats ............................................................................................................................................... 47
Conclusion ........................................................................................................................................................ 53
Bibliographie ..................................................................................................................................................... 54
Annexes ............................................................................................................................................................ 56
Annexe 1 : Table de probabilité pour déterminer l’origine ............................................................................ 56
Annexe 2 : Tables de probabilité pour déterminer la destination selon la zone d’origine ............................. 57
Annexe 3 : Table de validation des zones .................................................................................................... 65
vi
Table des figures Figure 1 : Cartographie du processus de transport .............................................................................. 4 Figure 2 : Nombre de transport selon l'heure de la journée ................................................................. 6 Figure 3 : Stat-Dev - Interface ............................................................................................................ 10 Figure 4 : Stat-Dev - Tableau de bord ................................................................................................ 11 Figure 5 : Fiche de transport .............................................................................................................. 13 Figure 6 : Algorithme actuel ............................................................................................................... 24 Figure 7 : Architecture du modèle de simulation ................................................................................ 30 Figure 8 : Nombre de requêtes par heure .......................................................................................... 33 Figure 9 : Méthode des trois phases (Ruiz, A. Gagliardi, JP., 2014) .................................................. 38 Figure 10 : Pourcentage d'occupation................................................................................................ 43 Figure 11 : Temps moyen d'attente ................................................................................................... 44 Figure 12 : Temps d'attente suite à l'expérience 1 ............................................................................. 49 Figure 13 : Temps d'attente système suite à l'expérience 2 ............................................................... 51
Table des tableaux
Tableau 1: Délai selon le type de transport ........................................................................................ 22 Tableau 2 : Table évènementielle ...................................................................................................... 25 Tableau 3 : Liste des abréviations ..................................................................................................... 27 Tableau 4 : Table évènementielle ...................................................................................................... 27 Tableau 5 : Temps moyens historiques ............................................................................................. 32 Tableau 6 : Probabilité selon le niveau de priorité ............................................................................. 34 Tableau 7 : Exemple de requêtes générées ...................................................................................... 35 Tableau 8 : Nombre moyen de transports .......................................................................................... 48 Tableau 9 : Résultat de l'expérience 1 ............................................................................................... 48 Tableau 10 : Résultat de l'expérience 2 ............................................................................................. 50
1
Introduction
Depuis plusieurs années, une tendance de compression budgétaire frappe le système de santé
québécois de plein fouet. En effet, les établissements de santé subissent des pressions afin de livrer
un service de qualité avec des ressources de plus en plus limitées.
« Les établissements de santé du Québec devront encore mettre en place d’importantes mesures
d’optimisation durant l’année à venir, puisqu’ils subissent des compressions de 242 M$ pour l’année
financière 2016-2017 »1
Cette citation parue dans La Presse démontre le contexte dans lequel les établissements de santé
doivent maintenant opérer. Cette transformation du réseau québécois de la santé force les décideurs
à innover afin de rendre plus efficients les services offerts à la population. D’autant plus qu’à elle seule,
les dépenses du gouvernement québécois en matière de santé et services sociaux représentent près
de 50% de toutes les dépenses des services publics en 2016-20172. Dans le rapport « Série logistique
hospitalière : Portrait de la province de Québec » publié en octobre 2015 par le CPP de HEC Montréal3,
on y fait un constat peu flatteur de la performance logistique des établissements de santé du Québec.
Il en ressort « que le principal défi de la réorganisation régionale des activités de logistique hospitalière
sera d’élever la performance de certaines activités de logistique ». Bien que le rapport mette l’emphase
sur l’approvisionnement interne et externe de biens et services ainsi que la gestion des stocks, on
comprend qu’il y a place à l’amélioration dans toutes les sphères de la logistique hospitalière. Selon
un document du MSSS, les activités de logistique représentent près de la moitié du budget d’un centre
hospitalier4. Le terme logistique hospitalière couvre un large éventail d’activités telles que la gestion
des approvisionnements des biens nécessaires au fonctionnement de l’établissement ainsi que sa
gestion des stocks, mais aussi tous les autres types de flux internes ou externes. Ce projet de
recherche se concentrera sur les flux physiques, mais il est important de savoir qu’il en existe d’autres
1 http://www.lapresse.ca/actualites/sante/201606/18/01-4993252-nouvelles-compressions-de-242-millions-en-sante.php 2 http://www.budget.finances.gouv.qc.ca/budget/2016-2017/fr/documents/Graphiques_Tableau.pdf 3 http://cpp.hec.ca/serie-logistique-hospitaliere/ 4 http://www.msss.gouv.qc.ca/documentation/planification-immobiliere/app/DocRepository/1/Publications/Guide/110629_Guide_logistique_hospitaliere.pdf
2
types tel que les flux d’informations ou financier par exemple. Plus spécifiquement, ce document
traitera de la problématique de la planification des activités de transport intrahospitalier. Que ce soit
par le transport de matériel, d’échantillon ou de patient, la grande majorité des employés et utilisateurs
du système de santé sont touchés de près ou de loin par l’efficacité ou l’inefficacité des flux physiques
à l’intérieur d’un même établissement de santé.
Objectif
Dans le cadre de ce projet, l’établissement cible sera le Centre hospitalier universitaire de Sherbrooke
(CHUS). L’affluence de cet établissement ne cesse d’augmenter selon les rapports annuels publiés.
En 2014 seulement, c’est 91 323 visites à l’urgence, 31 545 hospitalisations, 27 391 chirurgies ainsi
que 246 861 visites qui eurent lieu pour consultation. On peut facilement s’imaginer la logistique
nécessaire afin de mener à bien ces activités.
Dans un contexte où les ressources financières sont de plus en plus limitées, la recherche de gain
d’efficience et d’optimisation des processus devient la seule solution face à cette nouvelle réalité. Ce
document traitera de la problématique du transport de patients non autonomes ou de matériel au sein
d’un même établissement. Plus particulièrement, il consistera à la conception d’un outil de simulation
générique et flexible servant à l’émulation des activités de transport intrahospitalier. Cet outil permettra
de reproduire les activités de transports selon les paramètres spécifiques de l’établissement étudié,
soit le CHUS. Étant donné qu’il calque les transports intrahospitaliers, l’outil permettra entre autres de
tester différentes règles d’affectation de transports au brancardier et d’en évaluer la performance selon
des indicateurs prédéterminés. Dans le meilleur des cas, l’outil de simulation permettra d’améliorer la
planification des activités de brancarderie, soit les personnes responsables du transport à l’intérieur
d’un centre hospitalier.
3
1. Le transport intrahospitalier
La mission d’un centre hospitalier est d’offrir des services diagnostiques ainsi que des soins médicaux
généraux et spécialisés5. Cette offre de service dépend en grande partie du niveau de cohérence entre
tous les acteurs impliqués. Cette cohérence découle d’un réseau logistique intégré et performant
assurant le bon fonctionnement des opérations de soins de santé. La section suivante détaillera le
transport intrahospitalier et présentera quelques statistiques afin de démontrer l’ampleur des activités
logistique au sein d’un établissement de santé, le CHUS dans le cas présent.
Selon son rapport annuel, le CHUS a un budget d’exploitation de 476 M$ et doit composer avec des
compressions de 8,8 M$ en moyenne par année, d’où l’importance d’optimiser son réseau logistique.
Concernant les activités de transports internes, l’établissement opère 24h/24h, 7 jours par semaine et
365 jours par année. C’est en moyenne 45 personnes par jour dédiées seulement au transport interne
durant les jours de semaines et 20 personnes la fin de semaine. Avec 1200 transports en moyenne la
semaine et 670 la fin de semaine pour un total d'environ 385 000 transports en 2015, l’amélioration,
bien qu’infime, des activités des transports intrahospitaliers se matérialisera par des gains d’efficacité
substantiels.
Dans son cas le plus général, le transport intrahospitalier consiste en un flux de personnes et de
matériel à l’intérieur d’un établissement. Dans le cas d’un patient non autonome, la trajectoire de celui-
ci se caractérise par une suite d’activités, ou de lieux à visiter, dans une fenêtre de temps défini par le
type d’activité auquel ce dernier doit assister. Par exemple, il peut aussi s’agir du déplacement d’un
patient de sa chambre vers le département de radiologie. La trajectoire est rarement linéaire, car les
destinations sont souvent multiples et dans des unités de soins différents. Le transport de matériel est
le type de transport intrahospitalier le plus fréquent, soit près de 54% de tous les transports. Ces
transports sont récurrents selon des critères bien précis. Par exemple, ils sont utilisés afin de générer
des transports de routine tels que la récupération de spécimens ou le déplacement de matériel roulant.
Bien que la trajectoire de fournitures médicales soit prévisible, celle d’équipements médicaux et de
5 http://www.msss.gouv.qc.ca/reseau/etablissements.php#ch
4
prélèvement est imprévisible et souvent variable, car elles dépendent directement des besoins des
patients.
La figure suivante représente une cartographie simplifiée du processus de transport tel qu’instauré au
CHUS.
Figure 1 : Cartographie du processus de transport
5
1.1. La gestion du transport de personnes
L’un des principaux objectifs de la gestion du transport de personnes est de coordonner les flux avec
toutes les activités de soins pour maximiser l’utilisation de toutes les ressources impliquées dans le
processus afin d’assurer le confort du patient et ainsi assurer un service de qualité. Cette coordination
permettra une plus grande fluidité des activités de transports intrahospitaliers. On veut que le patient
soit au bon endroit, au bon moment tout en respectant le confort de ce dernier. Ce confort se
caractérise par un transport sécuritaire et adapté aux conditions du patient en plus de réduire au
minimum les périodes d’attentes aux différentes activités de soin. De plus, ces transports doivent être
le plus efficient possible, c’est-à-dire qu’il faut trouver un équilibre entre les demandes de transports et
l’offre de brancardier pouvant répondre à ces demandes. Selon une étude de Beaulieu et Landry6
portant sur la logistique hospitalière du secteur québécois de la santé, deux approches sont observées
afin d’optimiser le réseau logistique, soit la réingénierie de la logistique et le Lean Healthcare. Bien que
la réingénierie de la logistique porte principalement sur les approvisionnements et la gestion des
stocks, le Lean Healthcare concerne entre autres le transport. En s’inspirant du monde industriel, cette
approche consiste à l’élimination des activités qui n’ajoutent pas de valeur. Dans le cas du transport
intrahospitalier, les déplacements à vide des brancardiers, le temps d’attente de ceux-ci ainsi que le
temps d'attente des patients représentent des activités qui n’ajoutent aucune valeur. L’application de
cette approche devient alors un objectif incontournable pour les établissements de santé désirant
dégager des économies afin de respecter le cadre budgétaire serré auquel elles sont soumises.
En d’autres mots, on veut minimiser les coûts d’exploitation, le temps d’attente des patients ainsi que
les activités des brancardiers sans valeur ajoutée tout en maximisant l’utilisation des brancardiers et
autres ressources.
6 http://www.aqesss.qc.ca/docs/pdf/reflexion_logistique_approvisionnement_hecmontreal2010.pdf
6
1.2. Enjeux
La logistique hospitalière dans son ensemble comporte plusieurs défis auxquelles les décideurs
devront s’attaquer afin de rendre leurs établissements plus efficients. Les principaux enjeux découlent
du fait que le réseau logistique interne d’un centre de santé évolue dans un environnement dynamique
et incertain. La section suivante présentera ces enjeux.
Un des principaux enjeux dans le transport intrahospitalier est la variation du volume de transport. La
figure 2 illustre la variabilité du nombre de requêtes de transport durant la journée au CHUS.
Figure 2 : Nombre de transport selon l'heure de la journée
On remarque qu’en plus de varier selon l’heure de la journée, les bandes grises représentant l’écart-
type démontrent que dans les pics d’achalandage, le volume varie aussi beaucoup. À titre d’exemple,
le nombre moyen de transports entre 9h et 10h pour l’année 2015 au CHUS est de 97 transports avec
un écart-type de 32 transports. Il devient alors extrêmement difficile de trouver un équilibre entre l’offre
de brancardiers et la demande de transport ce qui a pour effet d’affecter le temps d’attente. De plus,
certains évènements imprévisibles tels que l’éclosion de la grippe H1N1 en 2009 par exemple ajoutent
un volume supplémentaire difficilement planifiable. En plus de la variabilité à travers le temps, certaines
demandes de transport jugées urgentes ne sont connues qu’en temps réel et doivent être réalisées
dans les plus brefs délais.
0
20
40
60
80
100
120
140
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Nombre
moyen d
e t
ransp
ort
Heure de la journée
7
Un autre défi important dans la gestion des flux de personnes est la spécificité de chaque transport.
En effet, les patients sont de tout âge et de toutes conditions physiques et mentales. Lorsque ceux-ci
ne sont pas autonomes, il faut des moyens de transport adaptés (civière, fauteuil roulant) nécessaires
au transport du patient. La disponibilité ainsi que la proximité du matériel sont donc primordiales au
bon fonctionnement des activités de brancarderie.
L’incertitude peut aussi se matérialiser par un patient qui n’est pas prêt à l’arrivée des brancardiers ou
par la non-disponibilité du personnel soignant à l’arrivée du patient. Ceci a pour conséquence de
réassigner le transport à plus tard et du même coup, occasionner des délais supplémentaires tant au
patient qu’à l’unité de soins qui devait le recevoir ainsi qu’une perte de productivité du service de
brancarderie. Des transports sont aussi réassignés lorsqu’une erreur de saisie se glisse dans le
système et le brancardier chargé du transport n’a pas l’équipement ou la formation pour procéder. Pour
certaines unités de soins, un retard de 5 minutes à un rendez-vous planifié occasionne une cascade
d’événements menant à des délais d’attente importants pour les patients et l’annulation de certains
rendez-vous qui devront être à réassigner ultérieurement. Finalement, le temps de transport de l’origine
à la destination ainsi que la trajectoire ne sont connus d’avance et occasionnent de sérieux défis au
niveau de la planification des opérations. Le temps de parcours dépend en grande partie de
l’achalandage et autres facteurs incontrôlables tel que la panne d’un ascenseur.
1.3. Revue de littérature
La littérature scientifique s’intéresse de plus en plus à la logistique hospitalière mais peu d’articles
couvrent le transport intrahospitalier. Tel qu’indiqué par Fondrevelle (2010), bien qu’il existe une
panoplie de travaux consacrés à la planification des opérations hospitalières, très peu traitent du
transport intrahospitalier. Cette section présentera les principaux articles concernant les flux internes
au sein d’un établissement de santé et comment ceux-ci ont été traités dans la littérature.
André et Fenies (2007) ont présenté et modélisé les différents types de flux au sein d’un hôpital. En
fait, ils ont même simulé les flux logistiques lors de la construction d’un nouvel hôpital en France.
Beaudry et al (2010) se sont intéressés au transport de patient au sein de plusieurs pavillons et on
développer une heuristique permettant de facilement insérer des nouvelles requêtes dans un transport
8
déjà débuté. Déjà dans le début des années 1990, des chercheurs s’intéressent au sujet du transport
intrahospitalier (Venkataraman et Orr (1992); Boyd, Corse et Campbell (1991)). Hendrich et Lee (2005)
ont documenté les impacts négatifs d’une inefficacité du transport de patient. Kuchera et Rohleder
(2011) ont développé et implanté un outil Excel augmentant l’efficacité de l’équipe de brancarderie en
permettant les compromis par rapport au temps d’attente des patients et le nombre de ressources
disponibles. Face à la complexité de développer un modèle d’optimisation des transports
intrahospitalier, Naessens et Gelders (2009) ont proposé une réingénierie du département de transport
en décentralisant les opérations ce qui s’est conclu par une amélioration globale de la performance.
Evans et Pannesi (2004) ont documenté un projet portant sur les communications radio à double volet
permettant ainsi de réduire les impacts d’une mauvaise communication entre le répartiteur et les
brancardiers.
Le manque de références scientifiques est d’autant plus vrai lorsque la simulation est utilisée afin
d’aborder ce sujet. Jun et al (1999) ont fait une enquête sur l’application de la simulation au domaine
de la santé. Dans le même ordre d’idée, Katsaliaki et Mustafee (2010) ont passé en revue près de 250
articles scientifiques publiés entre 1970 et 2007 qui traitaient de l’application de la simulation au
domaine de la santé. Ferrin et Szymanski (2003) ont développé un modèle générique de simulation
réduisant le temps d’attente en s’appuyant sur la méthode six sigma. Dans un contexte déterministe
et statique, Turan et al (2011) ont proposé un modèle permettant d’acheminer les patients à leurs
rendez-vous respectifs en considérant les irritants au niveau patient et administratif. Fiegl et Pontow
(2009) ont développé un algorithme qui optimise l’horaire des tâches de brancarderie ce qui résulte en
la réduction du temps d’attente et des coûts associés au transport de patient. Finalement, Hensaw
(2015) a développé un outil générique de simulation pour mesurer différentes règles de gestion, tel
que l’ajout de brancardier à des moments clés de la journée.
9
1.4. La solution de Christi InnoMed, Stat-Dev Transort
La problématique abordée dans ce document est le fruit d’une collaboration avec Christie Innomed,
entreprise œuvrant dans le domaine des soins de la santé. Christie Innomed développe, distribue,
intègre et soutient des solutions et produits qui améliorent la performance des institutions de santé du
Québec et du Canada, dans les domaines de l'imagerie médicale et des solutions de gestion des
informations.7 Christie Innomed se compose de trois principales divisions, soit l’imagerie médicale,
l’informatique médicale et Christie Technologies qui propose des applications et des systèmes
d’intelligence d’affaire en santé. Une de ces applications est STAT-Brancarderie, une solution qui offre
une gestion automatisée des déplacements internes au sein d’un même établissement. Le système
offert par Christie Innomed permet d’affecter rapidement et efficacement les ressources afin de
transporter des patients et du matériel en toute sécurité et dans un délai raisonnable.
L’application offerte par Christie Innomed permet de gérer tous les flux internes en temps réel. Il assiste
le répartiteur afin que ce dernier s’assure que l’affectation des transports se déroule rondement. La
section suivante présentera les différentes composantes de l’application ainsi que son utilisation.
7 http://www.christieinnomed.com/fr/a-propos-de-nous/
10
1.4.1. Tableau de bord
Figure 3 : Stat-Dev - Interface
La figure 3 représente l’interface qu’utilise le répartiteur afin de gérer les activités de transports
internes. L’écran est séparé en trois sections distinctes représentant l’état de la situation actuel par
rapport aux demandes en attente, ceux assignés et le portrait global de l’équipe de brancarderie. Les
trois sections mentionnées seront définies plus en détail dans ce document. Le tableau de bord permet
d’avoir un portrait global de la situation et permet au répartiteur de permuter certains transports s’il le
juge nécessaire.
La première section concerne les transports en attente. Tel que mentionné plus haut, les différentes
unités de soins créent des requêtes de transports via le système central pour qu’ensuite ceux-ci soient
assignés à un brancardier. Lors de la création d’une requête, plusieurs champs doivent être remplis
afin de donner un maximum d’information au brancardier. Les deux images ci-dessous représentent
l’interface de l’application lors de la création d’une demande ainsi que la demande une fois que celle-
11
ci est créée et visible dans la première section du tableau de bord représentant les transports en attente
d’assignation.
Figure 4 : Stat-Dev - Tableau de bord
Tel qu’illustré, lors de la création d’une demande, plusieurs champs doivent être remplis. Il faut d’abord
indiquer le statut de la demande, le type de transport (patient ou matériel) et dans le cas d’un transport
de patient, son nom. Si le patient est déjà hospitalisé, la recherche dans la base de données indiquera
au créateur de demande toutes les particularités propres au patient telles que son origine, les
précautions à prendre, etc. Ensuite, les champs origine et destination ainsi que le niveau de priorité
doivent être remplis. Dans le cas du CHUS, l’établissement est divisé en 2 pavillons, Hôtel-Dieu et
Fleurimont et chaque pavillon est divisé en zone. Une zone n’est pas nécessairement un département,
12
mais plutôt un espace géographique dans le pavillon. Le découpage de la superficie du CHUS en zone
est primordial afin de définir dans l’espace les origines et destinations de chaque requête de transport
et ainsi déterminer le temps de parcours prévu entre celles-ci. Cette représentation sera fort utile pour
l’algorithme d’affectation tout comme les origines et destinations, l’impact du niveau de priorité
influencera le comportement de l’algorithme qui sera présenté plus bas dans le document. Au CHUS,
quatre niveaux sont utilisés, soient urgent, important, tour de rôle ainsi que non prioritaire. Une
demande urgente signifie que la vie du patient est en danger alors qu’une demande est importante
lorsque l’état du patient est stable et qu’il ne se sent pas bien, mais dont la vie n’est pas en danger.
Ensuite, lorsque l’état du patient est stable et qu’il est en mesure d’attendre, le code de priorité « tour
de rôle » est affecté à la demande. Enfin, la classe non prioritaire est utilisée pour le transport de
matériel seulement. Finalement d’autres champs sont remplis et permettront au brancardier d’avoir
toute l’information nécessaire afin de procéder au transport tel que le moyen de transport, le nombre
de brancardiers nécessaire, etc. Tous ces champs sont configurables.
La seconde section du tableau de bord indique au répartiteur les requêtes qui sont présentement
assignées et en cours de transport. La majorité des informations de la première section sont
reconduites dans la seconde, mais on y retrouve en plus d’autres indicateurs pertinents. En autre, le
répartiteur peut voir le délai qui s’est écoulé entre la création de la demande et son assignation, le
temps prévu pour compléter le transport et le brancardier qui effectue présentement le transport. Lors
de l’assignation, il est possible pour le transporteur d’imprimer une feuille contenant toutes les
informations utiles telles qu’illustrées dans la figure ci-dessous.
13
Figure 5 : Fiche de transport
Finalement, la troisième section dresse un portrait global de l’équipe de brancarderie. On y retrouve
les brancardiers effectuant présentement un transport, ceux disponibles ainsi que ceux en pause ou
non-disponibles. Il est aussi possible d’avoir les statistiques sur la journée et le nombre de transports
pour chacun des transporteurs. La section sur les statistiques et la traçabilité sera détaillée plus bas.
1.4.2. Mode de fonctionnement et paramétrage
Le CHUS utilise un système de téléphone fixe afin de procéder à l’affectation de transport. Plusieurs
téléphones sont répartis dans le centre hospitalier et lorsqu’un brancardier désire « prendre » un
transport, il peut le faire via un téléphone ou directement à partir de la centrale de brancarderie.
Lorsqu’il utilise le système de téléphonie, le brancardier reçoit les informations à l’aide d’un générateur
de voix Text-To-Speech. Le service de téléphone sert aussi afin de signaler un transport complété et
en aviser le répartiteur qui recevra les informations en temps réel. Ce mode de fonctionnement
décentralisé permet de communiquer facilement avec les brancardiers. Si par exemple il y a un
ascenseur hors service, le répartiteur peut envoyer une alerte à tous les transporteurs susceptibles
14
d’emprunter cet ascenseur et ainsi réduire un possible délai supplémentaire. L’application a été conçue
afin d’offrir une grande flexibilité au niveau du paramétrage de sorte qu’il peut être utilisé et modifié
dans plusieurs établissements ou pavillons avec des configurations différentes.
1.4.3. Statistiques et traçabilité
Le système est en mesure de produire un large éventail de rapports statistiques et de graphiques selon
différents critères. Du temps moyen d’attente entre deux dates pour un niveau de priorité précis au
nombre de transport effectué pour une unité de soin, la flexibilité de l’application permet au gestionnaire
de mieux évaluer la performance du service de brancarderie. De plus, toutes les données sont
conservées dans une base de données pour ainsi faire une rétrospective des activités de transport.
On pourrait par exemple analyser l’impact d’un changement au niveau de l’algorithme d’affection en
produisant des rapports avant et après le changement. De plus, il est possible de suivre en détail
chaque activité d’un brancardier pour n’importe laquelle de ses journées travaillées. La traçabilité
s’effectue aussi au niveau des transports.
15
2. Le modèle de simulation
2.1. Historique
C’est dans le milieu des années 1940 que le domaine de la simulation par ordinateur prit naissance.
Comme c’est le cas avec plusieurs nouvelles technologies, l’arrivée des premiers ordinateurs ont
permis de faire d’importantes avancés scientifique. En effet, les travaux des mathématiciens Jon Von
Neumann et Stanislaw Ulam portant sur l’utilisation d’un ordinateur afin de résoudre la problématique
de diffusions des neutrons à l’aide de la méthode de Monte-Carlo a été la première vraie simulation
d’envergure8. Les chercheurs travaillaient sur ce problème dans le but de créer la première bombe
atomique dans les laboratoires du Los Alamos National Laboratory dans le cadre du projet Manhattan.
Le modèle de diffusion de neutrons étant trop compliqué à décrire et à résoudre avec des équations
algébriques, ceux-ci ont dû trouver une nouvelle approche. C’est alors que l’idée d’introduire des
nombres aléatoires dans ces équations et en simuler le résultat permettra ultimement de prédire le
comportement des neutrons et ainsi créer la réaction en chaine nécessaire à la détonation nucléaire.
Ensuite, c’est près de 10 ans plus tard, en 1958, que le professeur Keith Douglas Tocher développa le
premier simulation package avec des visées industrielles. C’est aussi le premier à avoir publié des
articles concernant la simulation, incluant la méthode des trois phases que nous verrons plus bas dans
le document. Il a aussi écrit le livre The Art of Simulation (1963), première véritable référence en
matière de simulation. À partir de ces années, la simulation a évolué très rapidement lorsque des
entreprises tels que Rand Corporation et IBM on investit massivement dans le développement de
langages et librairies de simulation telles que Simscript et GPSS (General Purpose Simulation System).
8 http://www.informs-sim.org/wsc09papers/028.pdf
16
2.2. Les fondements de la simulation
La simulation permet d’appréhender le comportement de systèmes complexes dont l’évolution serait
difficile à prévoir autrement. Selon Pidd (2004) la simulation par ordinateur est somme toute très
simple. Premièrement un modèle représentant un système réel est développé. Ensuite, ce modèle est
converti en programme informatique, soit à l’aide d’un logiciel ou simplement avec un langage de
programmation. Finalement, on étudie le comportement du système en modifiant certains paramètres
afin d’obtenir des informations utiles sur le système réel. Les gestionnaires sont toujours à la recherche
de gains d’efficience dans leurs opérations, peu importe le type d’entreprise qu’il dirige. Dans cette
optique, l’utilisation de la simulation est devenue un outil supplémentaire dans la gestion des
opérations.
2.3. La simulation dans un contexte de gestion
Le choix d’utiliser la simulation pour améliorer la gestion des transports intrahospitaliers est justifié par
la capacité de reproduire le comportement d’un système. Ceci permet entre autres de mesurer les
gains d’efficience possible sans faire aucune modification dans le système réel. De plus, le transport
de patient au sein d’un établissement de santé est critique, car la vie de ceux-ci est parfois en jeu.
Dans cette optique, l’utilisation de la simulation dans la planification d’effectifs ou la modification des
règles d’affectation permet d’éviter des conséquences néfastes sur le confort des patients. En d’autres
mots, la simulation permet de prédire le comportement du système et ainsi prendre de meilleures
décisions de gestion. C’est pour ces raisons que c’est un outil approprié à l’amélioration de la gestion
des flux internes au sein d’un établissement de santé.
Dans ce projet de recherche, le développement d’un outil de simulation générique permettra d’obtenir
une réponse adéquate du système actuel lorsque différents paramètres sont modifiés tels que le
nombre de brancardiers ou les différentes règles de gestion.
17
2.4. Application de la simulation
Il existe une multitude d’applications à la simulation par ordinateur. La principale est sans aucun doute
le domaine manufacturier, mais la simulation est aussi utilisée dans le domaine de la santé, des
transports ou dans les entreprises de service. Par exemple, la simulation pourrait être utilisée pour
élaborer un nouveau design d’entrepôt de distribution afin de réduire la distance parcourue par les
caristes ou simplement pour déterminer le nombre de caissiers nécessaire dans une banque. Dans le
cas d’une simulation de file d’attente dans une banque, la première étape serait de construire le modèle
en identifiant et quantifiant les principales composantes du système tel que le taux d’arrivée des clients
et le temps de service d’un caissier. Ensuite, plusieurs expérimentations pourront être faites en variant
le nombre de caissiers et en étudiant la réponse du modèle au niveau du temps d’attente des clients
et du taux d’occupation d’un caissier.
La simulation est souvent préconisée pour différentes raisons. Premièrement, la simulation permet au
décideur d’expérimenter différents scénarios sans pour autant altérer le système actuel. Il est alors
possible de quantifier les gains espérés à faible coût tout en minimisant le risque d’empirer la situation
actuelle. Deuxièmement, bien que la conception d’un modèle sur un support informatique prenne un
temps considérable à développer, une fois que ce dernier est fonctionnel, il est possible de simuler des
semaines ou des mois en l’espace de quelques secondes. Finalement, il se peut qu’on ne puisse
modifier un système et la simulation devient la seule option. Par exemple, il est impossible
d’expérimenter la configuration d’une usine qui n’est pas encore construite. En ce sens, la simulation
est un outil extrêmement utile lorsque vient le temps de représenter et expérimenter analytiquement le
comportement d’une réalité complexe.
2.5. Étapes d’un projet de simulation
Law (2006) a défini les étapes nécessaires afin d’assurer le succès d’un projet de simulation. La
première étape est d’effectuer une étude approfondie du système. Dès le départ, l’objectif de l’étude
ainsi que les résultats escomptés doivent être clairs afin de permettre un niveau de détail cohérent
avec la réalité. Cette première étape se fait en étroite collaboration avec les décideurs et ceux
18
travaillant au développement de l’outil de simulation. Il est très important de bien comprendre le
système afin que le modèle soit une représentation fidèle de la réalité. Deuxièmement, il faut avoir
accès aux données ainsi qu’aux paramètres dans lequel évoluera la simulation afin de bien définir le
modèle. En ce sens, la représentation d’un système est beaucoup trop complexe à modéliser et
nécessite la création d’un modèle, soit une version simpliste du système, afin de simuler et étudier son
comportement. Cette étape est le fondement d’un projet de simulation et doit du même coup être
réalisée avec parcimonie. C’est aussi à ce moment que des hypothèses devront être émises afin de
rendre la simulation réalisable. Ces hypothèses devront être validées par les différentes parties
prenantes du projet afin de s’assurer de la validité du modèle. Ensuite, il faut traduire le modèle en
programme informatique et effectuer des tests afin de valider que la réponse du modèle est cohérente
avec la réalité. Cette validation peut s’effectuer par le biais de comparaison avec des données
historiques ou par discussion avec les dirigeants. Par la suite, il faut effectuer des expériences à l’aide
de l’outil de simulation et spécifier différents critères tels que la durée de la simulation, la période de
warm-up de la simulation ainsi que le nombre de simulations pour chaque bloc de donnée dans le cas
d’une simulation comprenant de l’aléatoire. Finalement, on collecte, analyse et documente les résultats
obtenus suite à la simulation.
2.6. Modèle de simulation
Selon Pidd (2004), il existe trois principaux éléments à prendre en considération lors du développement
d’un modèle de simulation. Premièrement, il faut déterminer la manière dont le temps (horloge de
simulation) est géré à l'intérieur du modèle. Une manière simple serait de gérer l’horloge avec des
intervalles de temps égaux et de simuler un modèle dit synchrone. En fonction de la nature du système,
cette méthode est souvent à éviter, car elle implique beaucoup de calculs inutiles dans le sens où le
modèle doit être recalculé à chaque intervalle même s’il n’y a aucun changement dans l’état du
système. La méthode la plus répandue, et aussi celle qui sera utilisée dans le cadre de ce projet de
recherche est la simulation à événements discrets. L’horloge de simulation avancera à l’évènement
suivant alors le modèle se recalculera seulement si l’état du système change. Par exemple, dans la
simulation d’un atelier de fabrication de pièces métalliques, le système se recalcule lorsqu’une pièce
arrive ou lorsque le processus de fabrication débute ou se termine. Le deuxième élément à prendre en
19
considération est directement lié à la nature du système étudié. En effet, il est important de savoir si le
système est déterministe ou stochastique. Dans le cas d’un système déterministe, son comportement
est entièrement prévisible alors qu’un système stochastique comporte une part d’incertitude. La plupart
des systèmes que l’on retrouve en pratique comportent de l’incertitude comme c'est le cas dans le
transport de patients à l'intérieur d'un même établissement. Étant donné que plusieurs variables d’une
simulation sont représentées par des distributions statistiques, les résultats d’une simulation sont
dépendants de l’échantillon simulé. Il est alors nécessaire d’effectuer plusieurs simulations pour
construire des intervalles de confiance afin de tirer des conclusions. Finalement, il est primordial de
savoir comment le système évolue dans le temps. Un système peut changer d’état de manière continue
ou discrète. La simulation à événements discrets est appropriée pour les systèmes dont l’état évolue
par les successions d’événements à différents points dans le temps. La majorité des simulations
discrètes implique des files d’attente et des tâches à accomplir. En contraste, la simulation continue
est appropriée pour les systèmes dont la modification d’état est continue dans le temps et peut souvent
être décrite par des équations différentielles. Par exemple, la simulation continue pourrait être utile afin
de résoudre analytiquement le taux de concentration d’un certain liquide lorsque ce dernier est
transvidé dans un autre liquide.
Dans le cadre du projet d’étude, une simulation à événements discrets sera utilisée afin de modéliser
les transports intrahospitaliers. Puisque les activités de transport intrahospitalier comportent beaucoup
d’incertitude, plusieurs composantes de la simulation évolueront de manière stochastique. Les
composantes seront détaillées plus bas dans le document.
2.7. Simulation à événements discrets
Dans ce type de simulation, le système est caractérisé par des entités, des événements ainsi que des
états propres aux différentes entités transitant dans le système. Une entité est une composante
évoluant dans un système et dont son comportement est étudié. Il est important de représenter
explicitement chacune des entités à l’aide d’attributs, car ceux-ci changent durant la simulation. La
description des entités et de leurs attributs à un moment précis constitue l’état du système. En d’autres
mots, l’état du système est soumis à un changement continu au fur et à mesure que les événements
s’enchainent. La mécanique de la simulation est gérée par le biais d’événements qui créent, détruisent,
20
modifient ou déplacent différentes entités. Il existe deux types d’événements, ceux qui sont la
conséquence d’un autre événement et ceux qui se déclenchent seulement lorsque certaines conditions
sont satisfaites. Les conditions seront directement reliées à l’état actuel du système. Un événement
représente un moment instantané dans le temps et n’a donc pas de « durée ». Dans le cas d’une
simulation de transport aérien par exemple, l’atterrissage ou le décollage d’un avion constituerait un
événement. La mécanique (moteur de simulation) est gérée par le biais de l’horloge de simulation.
Cette variable n’a aucune relation avec le temps réel, elle ne sert qu'à ordonner chacun des
événements. Le temps de la simulation est alors géré par une succession linéaire d’événements stocké
dans une liste. En d’autres mots, une fois un événement terminé, la simulation progresse en traitant le
prochain événement préalablement ordonné chronologiquement. La liste d’événement est dynamique,
car au fur et à mesure que la simulation progresse, des événements s’insèrent dans cette liste. Le
temps se retrouve alors à être discrétisé.
21
3. Implantation du simulateur
La section suivante détaillera le transport intrahospitalier au sein du CHUS pour ensuite présenter le
modèle de simulation. C’est à ce moment que les différentes hypothèses seront émises et expliquées.
Finalement, l’implantation du modèle théorique en langage de programmation sera détaillée.
3.1. Système réel
La première étape du processus de transport intrahospitalier au CHUS consiste en l’arrivée d’une
requête de transport dans le système. Les différentes unités de soins créent et envoient au répartiteur
une requête de transport afin de déplacer un patient ou du matériel d’une origine à une destination.
Une fois dans le système, la requête apparaitra comme étant en attente dans l’application STAT-DEV.
Plusieurs requêtes sont planifiées et récurrentes de sorte qu’elles apparaissent dans le système
automatiquement. Ce type de transport sert souvent au déplacement de matériel roulant. Bien que ces
requêtes de transport soient planifiées pour une certaine heure, si un brancardier a du temps libre, ce
dernier peut effectuer le transport en avance. Une fois la requête entrée dans le système, cette dernière
doit être assignée à un brancardier. Il existe deux façons dont un brancardier peut se faire assigner
une requête. Cela peut se faire directement via la centrale de brancarderie, où se retrouve le répartiteur
responsable de l’application, ou par le biais de téléphones fixes. Cette seconde manière est la plus
utilisée. En effet, plusieurs téléphones fixes sont répartis stratégiquement dans l’établissement. Ces
téléphones permettent d’assigner un transport à un brancardier, mais aussi d’en signaler la fin. Dès
qu’un brancardier se fait affecter un transport, ce dernier se dirige vers l’origine. La trajectoire entre le
téléphone est l’origine est rarement linéaire, car le brancardier doit par exemple récupérer le moyen
de transport afin de procéder au transport ou la fiche du patient. Une fois à l’origine, dans le cas d’un
transport de patient, le brancardier s’assure que le patient est prêt. Dans le cas contraire, il doit se
rendre au téléphone le plus prêt et signaler que le patient n’est pas prêt de sorte que la requête
réapparaisse dans les transports en attente. Aussi, certains transports nécessitent l’assistance d’un
second brancardier. Dans ce cas, le brancardier doit attendre le brancardier à l’origine. Si le patient
est prêt, le brancardier conduit le patient vers la destination. Une fois rendu à destination, le brancardier
22
dépose le patient à l’unité de soins en s’assurant que ce dernier est bel et bien attendu pour ensuite
se rendre au téléphone le plus proche et signaler la fin du transport. Dans la majorité des cas, le
brancardier reprend un transport à même le téléphone ayant servi pour le signalement de la fin du
transport précédent. La mécanique est sensiblement la même pour les autres types de transports tels
que les transports d’échantillons ou de matériel roulant. Il est important de mentionner que l’équipe de
brancarderie n’est pas homogène. Certains brancardiers sont affectés à une zone ou un département
alors que d’autres effectuent un seul type de transport.
3.1.1. Algorithme de décision
Bien que le répartiteur puisse assigner un transport au brancardier, le système utilise un algorithme
d’affectation proposant les meilleurs transports selon des règles préétablies. Plusieurs éléments
essentiels se doivent d’être paramétrés lors de l’implantation de l’application afin d’ordonner
adéquatement les transports. Premièrement, chaque téléphone servant à l’affectation des requêtes est
associé à une zone géographique de l’établissement. Du même coup, chaque origine ou destination
est aussi associée à une zone. Par exemple, les chambres du 3e étage d’une unité de soins
représentent la zone 4 alors que les salles de chimiothérapie se trouvent dans la zone 21. Ensuite la
distance théorique (temps de parcours) entre les différentes zones est estimée et stockée dans une
matrice origine-destination nécessaire au fonctionnement de l’algorithme. Finalement, chaque niveau
de priorité d’une requête de transport est associé à un délai d’attente maximum jugé acceptable par
les responsables. Une demande urgente aura toujours un délai de 0 minute alors qu’une demande
importante aura un délai de 7 minutes. Pour les demandes « tournée » et « non prioritaire », le délai
est respectivement de 20 minutes et de 60 minutes. Tous ces délais sont configurables et auront un
impact sur le comportement de l’algorithme de décision.
Type de transport Délai (min)
Urgent 0
Important 7
Tournée 20
Non-Prioritaire 60
Tableau 1: Délai selon le type de transport
23
3.1.2. Comportement de l’algorithme d’affectation
La première étape de l’algorithme consiste à l’identification du brancardier ainsi que son secteur
d’activités et les transports en attente en relation avec ses tâches. Par la suite, une fois la zone du
brancardier identifiée, le système détermine tous les transports dont le délai d’attente maximum est
dépassé sans tenir compte de la zone. Étant donné que les transports urgents ont un délai d’attente
de 0, ceux-ci sont toujours les premiers à être affectés. Ensuite, de tous les transports avec le délai
maximal dépassé, le système tri les transports en fonction du niveau de priorité, des transports urgents
au transport non prioritaire. Une fois que ce premier regroupement de transports est traité, le système
propose les transports se trouvant le plus près de la zone où le brancardier s’est identifié. Si plusieurs
transports se retrouvent dans cette même zone, l’ordonnancement des transports s’effectue
premièrement selon le niveau de priorité et dans le cas d’un niveau identique, celui avec le temps
d’attente le plus élevé est alors proposé en premier. Il existe cependant une subtilité à l’algorithme de
décision lorsqu’un transport requiert deux brancardiers. Dans ce cas, le premier brancardier
s’approprie le transport et le second brancardier se fera proposer d’aller rejoindre le premier afin de
procéder au transport, et ce, sans tenir compte des délais et des niveaux de priorité. Par contre, dans
le cas où un transport urgent serait en attente dans le système et qu’en même temps un brancardier
attend de l’aide pour procéder au transport, il en revient au répartiteur de prioriser le transport urgent.
Le diagramme de processus ci-dessous illustre le comportement de l’algorithme.
24
Figure 6 : Algorithme actuel
25
Le temps d’attente est souvent critique pour certains départements tels que le bloc opératoire. Afin de
favoriser les transports en fonction d’une origine ou d’une destination spécifique, il est possible de
configurer des facteurs d’importances modifiant le temps d’attente. Au CHUS par exemple, tous les
transports ayant comme destination le bloc opératoire ont un facteur d’importance de 1,4. C’est-à-dire
que le temps d’attente depuis son arrivée dans le système augmente à 140% du temps normal et donc
réduit le délai. De plus, tel que mentionné plus haut, il arrive que le patient ne soit pas prêt à l’arrivée
du brancardier. Dans ce cas, le brancardier doit réassigner le transport via un téléphone et le système
est configuré de sorte que le transport prendra un certain temps avant de réapparaitre dans les
transports en attente afin d’éviter qu’un autre brancardier accepte prématurément le transport.
3.2. Modèle de simulation
Tel que mentionné plus haut, le modèle de simulation doit représenter fidèlement le système réel. Dans
un premier temps, il faut définir les composantes du modèle pour ensuite expliquer comment ceux-ci
interagissent. La section suivante détaillera le modèle ainsi que les différentes hypothèses nécessaires
au fonctionnement de la simulation.
Le modèle est constitué de deux entités qui transitent dans le système, soit des requêtes de transport
ainsi que des brancardiers. Le tableau ci-dessous détaille les attributs ainsi que les différents états de
chacune des entités.
Entités
Requête Brancardier
Attributs États Attributs États
Numéro En attente Numéro Disponible
Origine En cours Position Non disponible
Destination Terminé Début du quart À l'origine
Niveau de priorité Fin du quart À la destination
Facteur d’importance 1re pause Déplacement à l'origine
2e pause Déplacement à la destination
Tableau 2 : Table évènementielle
26
L’état d’une entité sert à décrire son statut à un instant donné. Cet état évoluera tout au long de la
simulation et permet entre autres de détailler son comportement. Par exemple, une requête qui entre
dans le système sera « en attente » et une fois qu’un brancardier se fait assigner la requête, cette
dernière change d’état et devient « en cours ». Les attributs d’une entité servent principalement à la
distinguer parmi les autres entités de sa classe. La définition d’un brancardier se caractérise par un
numéro qui l’identifie ainsi qu’une position qui évolue tout au long de la simulation. Un brancardier a
une date de début de quart qui correspond au moment où ce dernier devient disponible pour effectuer
un transport, et ce, pour une période de 8 heures. Il y a aussi deux pauses de 30 minutes. À noter que
si par exemple six brancardiers commencent leur quart de travail à 8h00, trois d’entre eux auront une
pause vers 10h00 alors que les trois autres en auront une vers 10h30. Quant à eux, les requêtes de
transport se différencient par un numéro distinct, une origine et une destination. Chacune d’entre elles
possède un des quatre niveaux de priorité et tout dépendant de l’origine ou de la destination, un facteur
d’importance est défini (poids). Dans notre simulateur, les requêtes sont générées aléatoirement
utilisant le processus qui sera détaillé plus bas dans le document.
Une fois les composantes du modèle de simulation définies, il faut décider comment ceux-ci
interagissent et définir l’environnement dans lequel la simulation se déroulera. Comme son nom
l’indique, la simulation à événements discrets utilise des événements afin de faire évoluer le modèle
dans le temps. Chaque événement impliquera un changement dans l’état d’une ou plusieurs entités et
du même coup, modifiera l’état global du système. Afin de conceptualiser un modèle de simulation,
une table événementielle est souvent utilisée afin de mettre en relation les différents événements et
ainsi faire évoluer la simulation telle qu’il sera expliqué dans la section suivante. Il existe deux types
d’événements. Ceux dont la création dépend uniquement de l’exécution d’un événement précédent
sont nommés bound. Le second type d’événement dit conditionnel est un événement qui dépend d’une
ou plusieurs conditions liées à l’état actuel du système. La table suivante décrit l’interaction entre les
événements qui constitue du même coup la mécanique du modèle de simulation.
27
Abréviation Définition
Bra Brancardier
Req Requêtes
RR Réception d'une requête
AR Affectation d'une requête
DO Déplacement à l'origine
AO À l'origine
DD Déplacement à la destination
AD À la destination
RT Requête terminée
VP Vérification pause
RP Retour de pauseTableau 3 : Liste des abréviations
Événement Type Conditions Changement d'état Événement créé
RR B Req = en attente RR
AR C Bra = disponible Bra = non-disponible
DO Nb de requête en attente ≥ 1 Req = en cours
DO B Bra = DO AO
AO B Bra = AO DD
DD B Bra = DD AD
AD B Bra = AD RT
RT B Bra = disponible
Req = Terminé
VP C Bra = disponible
Bra = non-disponible RP Horloge > fenêtre de pause
RP B Bra = disponible Tableau 4 : Table évènementielle
28
3.2.1. Hypothèses et différences entre la réalité et le modèle
On remarque que la réalité et le modèle de simulation sont différents sur quelques points et certains
éléments sont volontairement simplifiés afin de rendre réalisable la simulation. Premièrement, le temps
entre l’arrivée d’une requête et son assignation est considéré nul si un brancardier est disponible. C’est
un événement conditionnel de sorte qu’à partir du moment où il y a plus d’une requête dans le système
et qu’un brancardier est disponible, cette dernière s’affecte automatiquement. Dans la réalité, il y a un
délai à partir du moment où l’unité de soin envoie une requête de transport dans le système et le
moment où un brancardier prend le téléphone afin de procéder au transport. Le même principe
s’applique lorsqu’un brancardier arrive à destination. Du moment qu’il arrive à destination, la requête
est considérée comme terminée et le brancardier est déjà disponible pour un nouveau transport. En
pratique, le brancardier devrait déposer le patient à sa destination, se rendre au téléphone le plus prêt
pour signaler la fin du transport et ainsi prendre une nouvelle requête. Aussi, le patient est considéré
comme étant toujours prêt de sorte qu’aucune réassignation de transport ne s’effectue. Dans le même
ordre d’idée, l’équipement ainsi que les moyens de transport sont toujours disponibles. De plus, la
trajectoire d’un transport dans le modèle est linéaire et déterministe. En effet, une matrice origine-
destination entre chacune des zones sert à déterminer le temps de transport. Dans la réalité, les
périodes d’achalandage et les différentes perturbations telles qu’un bris d’ascenseur affectent le temps
de transport alors que dans le modèle, le temps est déterministe. Dans le modèle de simulation,
l’équipe de brancarderie est homogène. C’est-à-dire que chaque brancardier peut effectuer n’importe
quel type de transport et aucun brancardier n’est affecté à une zone spécifique alors qu’en réalité,
certains brancardiers ayant des formations spécifiques sont assigné au zone critique tel que le bloc
opératoire Quant aux requêtes des transports, aucune requête n’est connue d’avance comme c’est le
cas pour les transports récurrents. Les transports nécessitant deux brancardiers représentaient moins
de 1% des transports en 2015, c’est pourquoi que toutes les requêtes requièrent seulement un
brancardier. Tel que mentionné plus haut, certains transports sont récurrents et toujours à la même
heure et ce, à chaque jour de sorte qu’un brancardier peut effectuer ce transport « en avance ».
N’ayant pas l’information concernant le moment où ces transports apparaissent dans le système, ceux-
ci ne seront pas pris en compte lorsque les paramètres servant à la génération de transports aléatoires
seront calculés. En d’autres mots, les transports récurrents et connus d’avance ne seront pas simulés
29
malgré le fait qu’il représente près de 10% de tous les transports. Toutes ces hypothèses et
simplifications contribuent au développement d’un modèle simple mais ayant un niveau de détail
suffisant pour la simulation.
Ces hypothèses auront un impact sur les différentes mesures de performance. Plus particulièrement,
le fait de ne pas considérer les transports récurrents viendra effectivement modifier le taux d’utilisation
des brancardiers. Afin de minimiser ces impacts, l’échantillon sur lequel se basera la génération des
requêtes de transport ne tiendra pas compte de certains types de transport. Cela veut dire que tous
les paramètres utilisés par l’algorithme de création de transport se basent sur un échantillon excluant
les transports récurrents et ceux nécessitant deux brancardiers. Cependant, considérant que certains
types de transports ne sont pas simulés, le nombre de brancardiers disponible sera alors inférieur à
celui observé sur le plancher étant donné que le nombre de transports simulé sera près de 10% moins
élevé que celui observé au CHUS.
3.2.2. Algorithme du modèle de simulation
L’algorithme implanté à l’intérieur du simulateur diffère légèrement de celui utilisé au CHUS afin de
tenir compte des simplifications. Cependant, l’algorithme sera validé plus bas dans le document et il
sera démontré que ce dernier est cohérent avec la réalité. Cette cohérence est nécessaire de sorte
que les résultats obtenus permettront de tirer des conclusions réalistes.
Du moment qu’un brancardier est disponible, l’algorithme à l’intérieur du simulateur affecte les
requêtes de transport sensiblement comme celui à l’intérieur du système qu’utilise le CHUS. Étant
donné qu’aucun brancardier n’est affecté à une zone spécifique du moment que le délai d’un transport
est dépassé, même si le brancardier est complètement à l’opposé de l’établissement, il se fera affecter
le transport. Cela aura pour effet d’affecter un transport à un brancardier même si ce dernier est
complètement à l’opposé et ainsi augmenter le temps qu’un brancardier effectue des tâches sans
valeur ajoutée.
30
3.3 Codage du simulateur
Tel qu’illustré dans la figure ci-dessous, le modèle de simulation se caractérise par cinq composantes
distinctes.
Figure 7 : Architecture du modèle de simulation
3.3.1. Matrice Origine-Destination
La matrice origine-destination consiste à un fichier texte indiquant le temps de parcours théorique entre
chacune des zones représentant la configuration de l’établissement. Cette matrice est utile pour
déterminer le temps qu’un brancardier prendra pour se rendre d’une zone à une autre. C’est cette
même matrice qui est utilisée afin que l’algorithme d’affectation propose des transports le plus près
possible du brancardier. Contrairement à la réalité où le temps de déplacement entre les zones est
variable, la matrice utilisée dans le modèle est déterministe.
Moteur de simulation
Matrice origine-destination
Mesures
Brancardiers
Requêtes
31
3.3.2. Liste de brancardiers
Encore sous forme de fichier texte, la liste de brancardiers indique le nombre de brancardier et l’heure
à laquelle ils commence leur quart de travail. Ensuite, une fonction implantée à même l’outil de
simulation définit les différents attributs du brancardier. La méthode affecte un numéro au brancardier
ainsi que deux fenêtres de temps pour ses pauses. Elle détermine aussi l’heure à laquelle un
brancardier deviendra non disponible, soit 8 heures après avoir commencé son quart.
3.3.3. Générateur de requêtes
Tel que mentionné plus haut dans le document, le transport intrahospitalier évolue dans un
environnement incertain de sorte que certains processus se doivent d’être modélisés à l’aide d’une
composante aléatoire. Dans le cadre de cette simulation, seules les requêtes de transport seront
générées aléatoirement, plus précisément le temps d’arrivée de celles-ci, l’origine et la destination ainsi
que le niveau de priorité. L’historique des requêtes collectées durant le mois de novembre 2015 a servi
d’échantillon pour modéliser les processus de génération tel qu’il sera décrit dans les prochains
paragraphes. Le choix de cet échantillon s’est fait suite aux discussions avec les responsables de la
solution Stat-Dev implanté au CHUS. La section suivante détaille la manière dont les requêtes de
transports sont générées.
3.3.3.1. Temps d’arrivée
Afin de modéliser le temps écoulé entre deux événements, une distribution exponentielle sera utilisée.
Cependant, tel qu’illustré plus tôt, le nombre de requêtes par heure varie beaucoup durant une journée.
Pour cette raison, un taux moyen d’arrivée entre chacune des requêtes a été calculé pour chaque
heure. Le tableau suivant représente les différents temps moyens historiques entre deux requêtes
selon l’heure de la journée alors que le graphique représente le nombre moyen historique de requêtes
de transport par heure.
32
De À Temps moyen (min)
0 h 00 1 h 00 11,07
1 h 00 2 h 00 11,67
2 h 00 3 h 00 10,03
3 h 00 4 h 00 13,78
4 h 00 5 h 00 13,34
5 h 00 6 h 00 12,72
6 h 00 7 h 00 9,53
7 h 00 8 h 00 3,23
8 h 00 9 h 00 1,06
9 h 00 10 h 00 0,85
10 h 00 11 h 00 1,02
11 h 00 12 h 00 1,12
12 h 00 13 h 00 1,43
13 h 00 14 h 00 1,15
14 h 00 15 h 00 1,03
15 h 00 16 h 00 1,33
16 h 00 17 h 00 2,26
17 h 00 18 h 00 2,48
18 h 00 19 h 00 3,68
19 h 00 20 h 00 3,36
20 h 00 21 h 00 4,14
21 h 00 22 h 00 4,24
22 h 00 23 h 00 5,15
23 h 00 0 h 00 5,21
Tableau 5 : Temps moyens historiques
33
Figure 8 : Nombre moyen de requêtes par heure
Pour la génération de temps interarrivée, 24 périodes de temps seront définies et à l’intérieur de
chaque période, le taux d’arrivée sera supposé constant. Afin de générer les temps entre chaque
arrivée de requête, la méthode de la transformée inverse sera utilisée. Dans le cas d’une variable
continue avec une fonction de répartition �(�) = �(� ≤ �) pour tout �� < ���� l’algorithme pour
générer des temps interarrivés est :
1. Générer un nombre aléatoire �~�(0,1)
2. Calculer � = ���(�)
La fonction de répartition d’une variable aléatoire caractérisée par une loi exponentielle est :
Ensuite, en posant � = �(�), on trouve alors que le temps entre-deux arrivés de requêtes (x) est :
� = −�
�ln (�). À noter que le nombre aléatoire U est généré à partir d’une fonction dans EXCEL et
�
� correspond à la valeur dans le tableau ci-dessus, soit le temps moyen entre deux requêtes.
0
10
20
30
40
50
60
70
80
1h 2h 3h 4h 5h 6h 7h 8h 9h 10h
11h
12h
13h
14h
15h
16h
17h
18h
19h
20h
21h
22h
23h
24h
Nombre moyen de requêtes de transport par heure
Requêtes par heure
34
3.3.3.2. Origine, destination, niveau de priorité et facteur d’importance
Contrairement à l’heure d’arrivée d’une requête qui est une variable aléatoire continue, les trois autres
variables générées, soit l’origine, la destination et le niveau de priorité, sont des variables discrètes.
Malgré leur nature différente, la méthode pour générer une variable aléatoire discrète se ressemble
beaucoup. Dans le cas discret :
�(�) = �(� ≤ �) = � �(��) �ù �(��) = �(� = ��)
����
L’algorithme afin de générer n’importe quelle observation aléatoire discrète est :
1. Générer un nombre aléatoire �~�(0,1)
2. Déterminer le plus petit entier I tel que � ≤ �(��)
3. Retourner � = ��
À titre d’exemple, si l’on se réfère à la table ci-dessous et que le nombre aléatoire généré est 0,93, la
requête générée sera de niveau non prioritaire.
Entre et Niveau de priorité Probabilité
0 0,521 Important 52,08%
0,521 0,912 Tournée 39,15%
0,912 0,996 Non-prioritaire 8,39%
0,996 1 Urgent 0,38%Tableau 6 : Probabilité selon le niveau de priorité
Dans le tableau ci-dessus, ce sont les données historiques de novembre 2015 qui permettent de
déterminer les différents seuils nécessaires à la génération de nombres aléatoires. Le même principe
s’applique pour déterminer l’origine du transport ainsi que sa destination. Étant donné que la
destination d’un transport est en relation directe avec son origine, une table de probabilité est associée
à chacune des origines possibles. Il y aura une seule table de probabilité pour déterminer l’origine alors
qu’il y aura autant de tables que d’origines afin de déterminer la destination. Par exemple, la probabilité
35
que la destination soit la salle d’opération n’est pas la même si l’origine est la chambre d’un patient ou
la buanderie. Finalement, le facteur d’importance est déterminé selon l’origine du transport. Tel
qu’expliqué précédemment, ce facteur accélère le temps permettant de déterminer si un transport a
dépassé le délai maximal. Toutes les tables se trouvent aux annexes 1 et 2. La figure ci-dessous
représente un échantillon tel qu’obtenu avec le générateur de requêtes.
No. Date d'arrivée Origine Destination Niveau de
priorité Facteur
d'importance
1 9,67 6 13 3 100
2 12,91 33 15 9 100
3 19,48 6 13 9 100
4 40,66 25 33 9 110
5 49,62 1 24 3 100
6 53,23 2 15 3 100
7 56,75 26 15 9 100
8 94,81 3 20 3 100
9 105,74 10 15 99 100
10 126,34 10 31 3 100
Tableau 7 : Exemple de requêtes générées
3.3.4. Moteur de simulation
Composé d’une l’horloge de simulation et d’une liste d’évènements, le moteur de simulation sert à
synchroniser la simulation en assurant le changement d’état des différentes entités, et ce, dans le bon
ordre. L’horloge de simulation indique le temps à l’intérieur de la simulation et il est important de
mentionner qu’il ne représente pas le temps réel. La liste est dynamique de sorte que durant
l’exécution, plusieurs évènements s’ajoutent alors que d’autres sont traités. À titre d’exemple, dans la
simulation des transports intrahospitaliers, du moment que l’évènement « Déplacement vers la
destination » est traité, un évènement « À destination » est créé et inséré dans le moteur de simulation
avec comme date d’exécution : ������� �� ���������� + ���������������,����������� . La
distance entre une origine et une destination se réfère à la matrice décrite plus tôt où la distance entre
36
deux zones est définie par un nombre de minutes. En somme, la simulation évolue en exécutant le
prochain événement dans la liste et en mettant à jour l’horloge à la date du dernier évènement traité.
3.3.5. Mesures de performance
La dernière composante du modèle permet la production et l’analyse de mesures de performance.
Tout au long de la simulation, chaque événement, chaque mouvement de brancardier et chaque
requête complétée sontstockés dans des listes, et ce, pour chacune des réplications de la simulation.
Cela permet d’estimer le temps entre l’arrivée d’une requête dans le système et son affectation ou la
proportion du déplacement à vide d’un brancardier. Une liste exhaustive des indicateurs de
performance sera détaillée dans la section suivante.
3.4. Algorithme de la simulation
Une fois l’architecture du moteur de simulation défini, il faut développer une structure permettant de
bien séquencer les événements. Tocher (1963) propose une méthode appelée algorithme des trois
phases qui sera détaillée plus tard. L’idée principale avancée par Tocher est qu’il existe seulement
deux manières dont un événement peut se créer dans une simulation à événement discret. Il y a les
événements bound (B) et les événements conditionnels (C). Les événements B sont prévisibles et
leurs créations dépendent uniquement de l’exécution d’un événement précédent. À l’inverse, les
événements C ne dépendent pas de l’horloge ou de l’exécution d’un autre événement, mais se
génèrent lorsqu’une ou plusieurs conditions liées à l’état actuel du système sont remplies. À titre
d’exemple, l’événement « Affectation d’une requête » s’exécute seulement s’il y a au moins une
requête en attente dans le système et qu’un brancardier est disponible. De manière générale,
l’exécution d’un événement C engendre la création d’un événement B. Dans l’exemple cité plus haut,
l’événement créé sera « Déplacement vers l’origine ».
37
3.4.1. Algorithme des trois phases (Tocher, 1963)
Comme son nom l’indique, l’algorithme comporte trois phases, soit A, B et C représentent les étapes
qui se répèteront en boucle jusqu’à la fin de la simulation. Le détail de chacune des phases se fera
plus bas dans le document. Pour que cette méthode fonctionne, chaque événement doit contenir un
minimum d’information. La plus importante est la date d’occurrence qui permet au moteur de simulation
de bien ordonner la mécanique de simulation. Ensuite, chaque événement doit contenir un libellé
permettant de le distinguer afin d’effectuer le traitement approprié, soient la modification d’entités et la
création d’événements subséquents tel qu’indiqué dans la table événementielle. Ensuite, tout
dépendant du modèle de simulation, certaines informations sont nécessaires au bon fonctionnement
de l’algorithme. Dans le cas de cette simulation, un brancardier et une requête peuvent être associés
à un événement, mais ce n’est pas obligatoire.
3.4.1.1. Algorithme des 3 phases - Phase A
La première phase consiste à récupérer l’événement dans la liste ayant la date d’occurrence la plus
rapprochée de l’horloge de simulation. Ensuite, chaque attribut de l’événement est mémorisé afin
d’effectuer les traitements nécessaires et ainsi modifier l’état du système. La phase A se termine en
retirant l’événement de la liste et en avançant l’horloge de simulation au temps d’occurrence de
l’événement en cours. À noter que c’est seulement dans cette phase que l’horloge est modifiée.
3.4.1.2. Algorithme des 3 phases - Phase B
La seconde phase consiste à effectuer le traitement approprié selon le type d’événement récupéré
dans la phase précédente. Cette phase aura pour effet de mettre à jour l’état du système, générer les
événements futurs associés à l’événement en cours pour ensuite les ajouter à la liste d’événements
non traités. C’est aussi à ce moment que les statistiques sont compilées. À titre d’exemple, si
l’événement récupéré dans la phase A est « Requête terminée », le brancardier affecté à cet
événement passera de « Non disponible » à « disponible », la requête quant à elle, passera de « en
cours à « terminé » et aucun événement ne sera généré. La requête s’ajoutera à la liste de toutes les
38
requêtes complétées alors que l’événement sera ajouté à la liste des événements traités. C’est entre
autres avec ses listes que les différents indicateurs de performance sont calculés.
3.4.1.3. Algorithme des 3 phases - Phase C
La dernière phase consiste à vérifier les conditions associées à chaque événement de type C pour les
exécuter si celles-ci sont remplies. Par exemple, l’événement C « vérifications des pauses » s’exécute
seulement si un brancardier est « disponible » et que l’horloge de simulation est supérieure à la fenêtre
de pause préalablement assignée aux brancardiers. Dans le cadre de cette simulation, seulement deux
événements sont de type C, soit l’affectation d’une requête ainsi que la vérification des pauses. C’est-
à-dire qu’à chaque fois que l’horloge de simulation avance, le moteur de simulation vérifiera si les
conditions propres aux deux événements de type C sont remplies pour ensuite les insérer dans la liste
d’événements à traiter.
La figure suivante illustre chaque étape d’une simulation à événements discrets et positionne les
différentes phases au travers du processus. À noter que dans notre cas, la génération d’observations
aléatoires se fait au niveau de l’initialisation. C’est-à-dire que les requêtes de transport sont générées
a priori à l’aide de l’algorithme mentionné plus haut et sont stockées dans une liste qui est passée en
paramètre lors de l’initialisation de la simulation. Cela aura pour effet d’accélérer la simulation.
Figure 9 : Méthode des trois phases (Ruiz, A. Gagliardi, JP., 2014)
39
3.4.2. Routine d’initialisation et condition de fin
Bien que l’algorithme des trois phases soit le cœur de l’outil de simulation, d’autres éléments doivent
être pris en considération. Premièrement, chaque simulation ou chaque réplication de simulation doit
avoir une routine d’initialisation. Cette routine remet l’horloge de simulation à zéro, vide toutes les listes
et initialise chaque variable du système. À titre d’exemple, au début d’une simulation, une liste de
requête sera importée, les listes d’événements et liste de requête en cours et complétées seront vidées
et toutes les statistiques seront remises à zéro. Il faut aussi, dès le début de la simulation, établir une
condition de fin. Il existe principalement deux façons de terminer une simulation. La simulation peut
arrêter après un certain temps ou, comme c’est le cas dans ce projet d’étude, la simulation s’arrête
après avoir traité un certain nombre de requêtes. Dans notre cas, une liste prédéterminée de requêtes
est stockée dans le simulateur et ce dernier exécute les 3 phases jusqu’à ce qu’elle soit vide.
3.5. Langage de programmation
Bien qu’il existe une multitude de logiciels facilitants de développement d’outils de simulation, le modèle
de simulation répliquant les transports intrahospitaliers est implanté en JAVA, soit un langage de
programmation orienté objet. Le caractère flexible de ce type de langage facilite le développement
d’algorithmes décisionnel par la réutilisation d’objet. En utilisant un langage de programmation
générique, aucune restriction quant à l’architecture de l’outil de simulation n’est nécessaire. Par contre,
cela est beaucoup plus complexe et demande une charge de travail plus importante au développeur.
40
4. Validation et vérification
Dans tous projets de simulation, une attention particulière doit être mise sur la validation et la
vérification du modèle de simulation. Cette étape est nécessaire afin de confirmer que ce dernier
représente fidèlement la réalité sans en prouver l’exactitude. En fait, il est impossible de valider qu’un
modèle reproduit le comportement du système réel avec exactitude (Pidd 2004). Ce qui doit être
démontré est que le modèle est valide pour une situation spécifique. La section suivante présentera la
validation et la vérification pour ensuite détailler les méthodes utilisées dans le cadre de ce projet
d’étude.
4.1. Définition de vérification et validation
La vérification est le processus assurant que le modèle théorique de simulation s’est correctement
traduit en modèle de simulation sur support informatique (Davis 1992). En d’autres mots, la vérification
s’assure que l’outil de simulation tel qu’implanté en JAVA correspond au modèle défini par la table
événementielle. La validation quant à elle s’assure que le modèle représente fidèlement la réalité. En
somme, la vérification et la validation s’assurent que le modèle est suffisamment précis pour avoir
confiance dans les résultats (Law 2000). Il existe deux approches afin de valider un modèle de
simulation, black-box validation et white-box validation (Law 2000). La première approche consiste à
comparer les données provenant du « monde réel » avec ceux de la simulation lorsque celle-ci est
effectuée sous les mêmes conditions et paramètres. Si les deux séries de données sont
significativement semblables, on peut alors conclure que le modèle de simulation a un pouvoir prédictif
du monde réel. Cette approche ne sera pas utilisée dans cette simulation, car en plus d’avoir fait
certaines hypothèses simplificatrices tel qu’illustré dans la section précédente, les données historiques
ne sont pas assez détaillées. En effet, les données historiques permettent d’avoir une idée globale du
système et de son comportement, mais ne permettrent pas de détailler chaque mouvement et activité
des brancardiers, ce qui rend impossible la validation par l’approche black-box. À titre d’exemple, il est
impossible de savoir quelles sont les requêtes qui ont été annulées ou ceux qui nécessitaient plus d’un
brancardier. À l’inverse, l’approche white-box consiste à rendre le modèle assez transparent de sorte
41
qu’on puisse prévoir le fonctionnement interne de chacune des composantes. Afin de valider le modèle
qui a été préalablement défini, les trois aspects suivants seront approfondis.
4.2. Validation des entrants
Comment mentionné plus haut, la simulation fait intervenir des variables aléatoires afin de modéliser
l’incertitude quant à la création de requêtes de transport. Afin de vérifier et valider si la distribution de
probabilité utilisée représente significativement l’échantillon, des tests d’hypothèses sont effectués. Il
est cependant important de mentionner que ces tests ne prouvent pas qu’un échantillon d’observations
soit associé à une distribution théorique spécifique. Dans le cas de l’arrivée entre chaque requête de
transport, le test permettra de suggérer que les observations indépendantes sont tirées d’une
distribution exponentielle. Le test d’hypothèse sera celui de Kolmogorov-Smirnov (K-S) qui permet de
comparer si une distribution empirique (observations) est distribuée approximativement comme une
distribution théorique (exponentielle). La formulation des hypothèses va comme suit :
H0 : Les observations suivent approximativement une distribution exponentielle
Ha : Les observations ne suivent pas une distribution exponentielle
Le niveau de signification (α), ou le risque de rejeter l’hypothèse nulle alors qu’elle est vraie est de 5%.
La première étape pour conduire un test de K-S est d’ordonner les observations en ordre croissant.
L’échantillon choisi comprend 3147 observations de temps interarrivée avec comme moyenne 2,85
minutes. Ensuite, une distribution exponentielle cumulative à partir des observations est construite :
��(�) =�
� où i = 1,2,…, 3147 et N=3147
Ensuite on calcule � = max�����
{���(�) − )(ˆ xF �} où )(ˆ xF représente une distribution cumulative
exponentielle de moyenne 2,85. Dans notre échantillon, D = 0,1473 alors que la valeur critique avec
α=5% pour un test K-S avec une taille d’échantillon supérieur à 35 est
1,358
√3147= 0,024
42
La règle de décision pour ce test est :
Rejeter H0 si valeur critique K-S < D
Dans notre cas, K-S < D (0,024 < 0,1473) alors nous ne pouvons pas rejeter l’hypothèse nulle de sorte
que nous pouvons supposer que les observations sont distribuées de façon comparable à une
distribution exponentielle. Cela nous permet donc de justifier l’utilisation de cette distribution dans la
génération de requêtes de transport, plus spécifiquement pour le temps entre chacune des arrivées
dans le système.
4.3. Vérification du code et de la logique
La transformation du modèle théorique en langage de programmation est l’une des principales sources
de complexité d’un projet de simulation. La première étape est de faire valider la table événementielle
par des spécialistes ayant une connaissance approfondie du système réel. En ce sens, la table
événementielle détaillée plus haut a été validée par des employés de Christie Innomed, compagnie
développant l’application permettant de gérer les flux internes dans des établissements de santé.
Ensuite, une fois le modèle implanté en JAVA, les différentes règles logiques régissant le
comportement de la simulation doivent être à leur tours vérifiées. Le code est en fait une succession
de conditions et chaque condition doit reproduire avec exactitude le comportement du système réel.
Par exemple si un brancardier est « En déplacement vers l’origine », sa prochaine position devra être
« à l’origine ». En gardant en mémoire chacun des événements, il est possible de retracer chacun des
mouvements de requêtes ou de brancardiers durant la simulation. C’est en analysant ces données
qu’on s’assurera que la séquence d’une requête est cohérente. Par exemple, pour toutes les requêtes
la condition suivante sera validée. ���������é ≤ ��������������� < ����������é. C’est aussi à
ce moment qu’on validera le comportement de l’algorithme d’affectation. Pour ce faire, une liste de
requêtes fictives est passée en paramètre où l’ordre d’affectation est connu d’avance. Si l’ordre
d’affectation lors de la simulation est exactement comme celui définit préalablement, on peut
considérer que l’algorithme réagit en cohérence avec l'algorithme actuel. Aussi, la liste de tous les
événements traités a été analysée pour s’assurer que ceux-ci sont traités en ordre chronologique et
43
que la logique de la table événementielle était respectée. Par exemple, on valide qu’après chaque
événement « Déplacement vers la destination », l’événement « Requête terminée » est créé.
4.4. Observation des extrants
L’observation des extrants permet de valider si le comportement de l’outil de simulation est cohérent
avec la réalité, sans pour autant le valider analytiquement. À titre d’exemple, si l’on cherche à simuler
la congestion automobile sur un pont, on peut croire qu’avec un nombre plus élevé de véhicules, la
congestion augmentera. Afin de vérifier la cohérence du modèle avec la réalité, deux scénarios
hypothétiques seront simulés. Dans les deux cas, 700 requêtes de transport seront traitées et pour le
scénario A, 18 brancardiers seront disponibles contrairement à 20 pour le scénario B. Théoriquement,
si l’on regarde le taux d’occupation des brancardiers et le temps d’attente moyen par requête avant
d’être assigné, dans les deux cas les indicateurs devraient diminuer. Les deux figures suivantes
représentent graphiquement les deux scénarios.
Figure 10 : Pourcentage d'occupation
15,0%
15,5%
16,0%
16,5%
17,0%
17,5%
18,0%
18,5%
19,0%
A B
Pourcentage d'occupation de l'équipe de brancarderie
% d'occupation
44
Figure 11 : Temps moyen d'attente
On remarque que dans les deux cas les indicateurs diminuent lorsque le nombre de brancardiers
disponible augmente, ce qui est logique. Cette méthode ne sert pas de validation en soi, mais ajoute
un élément supplémentaire afin de valider que le modèle se comporte de manière cohérente avec la
réalité.
De plus, d’autres extrants tels que l’origine, la destination ainsi que le niveau de priorité ont été
analysés. Cette fois-ci, la moyenne des 25 réplications de 700 requêtes a été comparée avec les
données historiques du mois de novembre 2015 au pavillon Fleurimont du Centre Hospitalier
Universitaire de Sherbrooke. En analysant les tables à l’annexe 3, on s’aperçoit que la différence en
valeur absolue de la proportion de transport entre les données historiques et simulées est semblable.
On remarque que, tant pour l’origine que pour la destination, le nombre de transports est sensiblement
le même pour les données historiques et simulées. Cette analyse permet de valider que le générateur
de requêtes affecte correctement les origines et destinations et permet en même temps de valider la
cohérence du modèle avec la réalité.
0
2
4
6
8
10
12
14
16
0h-6h 6h-12h 12h-18h 18h-24h
Temps moyen d'attente
Scénario A
Scénario B
45
5. Expériences numériques
5.1. Définition des expériences
Les expériences réalisées à l’aide de l’outil de simulation visent à évaluer la sensibilité du système par
rapport au nombre de brancardiers et à différentes règles d’affectation de transport.
La première expérience consistera à mesurer la sensibilité du système lorsque le nombre de
brancardiers disponible est modifié durant la fenêtre de temps étudiée. Trois scénarios seront alors
répliqués. Chacun de ces scénarios aura respectivement 16, 17 et 18 brancardiers disponibles.
La seconde expérience quant à elle permettra de mesurer la sensibilité du système lorsque différentes
règles d’affectation sont appliquées. Trois scénarios seront simulés, et ce, avec 17 brancardiers. Le
premier scénario servira de référence, car il reproduira les transports avec l’algorithme actuel tel que
décrit plus haut. Le second algorithme affecte le transport le plus proche au brancardier en ne tenant
pas compte des niveaux de priorités ni des délais d’attente. Dès qu’un brancardier devient disponible
et qu’une requête de transport est en attente, le système affectera le transport le plus près de la zone
où se trouve le brancardier. Finalement, le troisième suit la règle de premier arrivé, premier servi.
5.2. Mesure de performance
Afin de mesurer la sensibilité du modèle lorsque différents paramètres sont modifiés, et plusieurs
indicateurs sont enregistrés tout au long de la simulation.
5.2.1. Temps d’attente système
Cette mesure correspond au temps d’attente d’une requête du point de vue du système. Ce temps est
obtenu en soustrayant à la date à laquelle un transport est affecté à laquelle elle fut arrivée dans le
système. À titre d’exemple, une requête qui arrive dans le système au temps 510 (8h30 AM) et qui est
affectée à un brancardier au temps 525 (8h45AM) aura un temps d’attente système de 15 minutes.
46
C’est cette même mesure qui est utilisée pour déterminer si un transport a dépassé le délai maximal
dans l'algorithme d'affectation.
5.2.2. Temps d’attente patient
Contrairement à la mesure précédente, cette mesure prend le point de vue du patient. Au lieu de
mesurer le temps entre l’affectation et l’arrivée dans le système, cet indicateur mesure le temps entre
l’arrivée du brancardier à l’origine et l’arrivée de la requête dans le système. Cette mesure est très
importante, car il ne faut pas perdre de vue que le transport intrahospitalier s’opère dans un contexte
où le confort du patient est primordial.
5.2.3. Équipe de brancarderie
Cette mesure se traduit en quatres indices distincts permettant de mesurer la performance globale de
l’équipe de brancarderie par rapport au nombre moyen de transports, le transport à vide, le transport
chargé ainsi que le taux d’occupation. Le premier indice fournit le nombre moyen de transports
effectués par un brancardier. Cette mesure s’obtient en divisant le nombre total de transports par le
nombre de réplications. Ensuite, le transport à vide est le temps total qu’un brancardier se déplace
sans valeur ajoutée, c’est-à-dire, sans patient ou équipement avec lui. C’est souvent cette mesure que
l’on cherche à minimiser dans les projets d’optimisation des transports. Par exemple, un transport à
vide consisterait au déplacement d’un brancardier d’un téléphone à l’origine. À l’inverse, le transport
chargé correspond au temps total de déplacement avec un patient. Finalement, le taux d’occupation
représente le pourcentage de temps qu’un brancardier passe à effectuer des transports. Ce taux
s’obtient en divisant le somme du temps de transport à vide et chargé avec le temps total qu’un
brancardier est disponible durant la journée. Ces quatre indices permettent alors d’évaluer la
performance globale de l’équipe de brancarderie.
Bien que la simulation se déroule sur une période de 24h, seuls les transports s’effectuant entre 8h et
16h sont comptabilisés et du même coup, les mesures de performances reflètent seulement ces
transports. Ce choix de fenêtre de temps est justifié par le fait que près de 80% des transports
s’effectuent durant cette période. De plus, le fonctionnement de l’équipe de brancarderie n’est pas le
47
même durant le jour et la nuit, car l’algorithme d’affectation n’est pas le même et que certains
départements ne sont pas ouverts durant la nuit.
5.3. Résultats
Lorsque plusieurs configurations sont mesurées entre elles et que le modèle implique la génération de
nombres aléatoires, il faut être prudent lors de la comparaison entre celles-ci. Afin de minimiser l’impact
d’une variance dû au processus stochastique et ainsi augmenter la précision des résultats obtenus,
Law et Kelton (2000) proposent une technique de réduction de la variance. Cette technique consiste à
utiliser des nombres aléatoires indépendants entre les réplications, mais à synchroniser ces mêmes
nombres aléatoires pour chacune des configurations. Cette technique réduit beaucoup la variance et
du même coup, il est plus facile comparer la performance de chacune des configurations. À l’aide du
générateur de requêtes expliqué dans la section 4.3.3, ce sont 25 listes de 650 transports qui ont été
générés. Ce sont ces mêmes 25 listes qui seront utilisées pour chacune des expériences numériques.
De plus, 23 brancardiers seront disponibles tout au long de la simulation, mais tel que mentionné plus
tôt, seulement 17 d’entre eux sont disponibles dans la fenêtre de temps étudiée.
La première expérience consiste à mesurer la sensibilité du système par rapport au changement du
nombre de brancardiers. Aussi, elle permettra de valider si le comportement du modèle est cohérent,
car il est logique qu’en augmentant le nombre de brancardiers disponible, les délais d’attente doivent
nécessairement diminuer. Les tableaux 8 et 9 représentent respectivement le nombre moyen de
transports effectués entre 8h et 16h pour les 25 réplications ainsi que les résultats de la première
expérience.
48
Type de transport Nombre moyen de transports
Urgent 1,56
Important 224,64
Tournée 168,92
Non-prioritaire 36,16 Tableau 8 : Nombre moyen de transports
16 brancardiers 17 brancardiers 18 brancardiers
Temps d'attente système (minutes)
Urgent 0,58 0,42 0,39
Important 3,06 2,36 1,90
Tournée 8,89 6,62 4,86
Non-Prioritaire 15,94 11,18 7,84
Temps d’attente moyen 6,42 4,76 3,55
Temps d'attente patient (minutes)
Urgent 7,28 7,66 7,44
Important 9,64 8,96 8,53
Tournée 15,38 11,17 11,46
Non-Prioritaire 22,22 18,43 13,99
Temps d’attente moyen 12,94 10,61 10,13
Équipe de brancarderie
Nb moyen de transport par jour 26,10 24,97 23,40
Transport à vide (minutes) 197,39 188,70 181,08
Transport chargé (minutes) 215,13 204,65 195,38
Taux d'occupation 85,94% 81,95% 78,43%
Tableau 9 : Résultat de l'expérience 1
49
Figure 12 : Temps d'attente suite à l'expérience 1
Pour les deux premiers indicateurs représentant le temps d’attente, un temps d’attente moyen est
calculé en effectuant une moyenne pondérée par le nombre de transports par type. On remarque que
pour chacun des indicateurs, la réaction du modèle face à la variation du nombre de brancardiers est
cohérente. Du point de vue du temps d’attente, chacun des indicateurs diminue lorsque le nombre de
brancardiers augmente. Du point de vue de l’équipe de brancarderie, le nombre moyen de transports
par jour diminue et conséquemment, le temps de transport et le taux d’occupation diminuent aussi.
Ces résultats ne sont pas surprenants, car pour un même nombre de transports, le nombre de
brancardiers augmente. De plus, on remarque que l’impact sur la diminution des temps d’attentes est
plus importante pour les transports de type tournées et non-prioritaire. Ceci est cohérent avec le
comportement de l’algorithme qui préconise les transports urgents. On peut donc dire que l’ajout de
brancardier aura surtout un effet sur les transports moins urgents.
La seconde expérience consiste à mesurer la sensibilité du système par rapport aux différentes règles
d’affectation. Le tableau suivant présente les indicateurs de performance.
0 5 10 15 20
Urgent
Important
Tournée
Non-Prioritaire
16 brancardiers
17 brancardiers
18 brancardiers
50
Règle d'affectation
Algorithme actuel Transport le plus proche Premier arrivé, premier servi
Temps d'attente système (minutes)
Urgent 0,41 2,86 3,12
Important 2,35 3,86 4,43
Tournée 6,62 4,38 5,51
Non-Prioritaire 11,18 3,78 4,97
Temps d’attente moyen 4,76 4,05 4,89
Temps d'attente patient (minutes)
Urgent 7,66 7,64 11,87
Important 8,96 9,1 12,96
Tournée 11,17 10,57 13,13
Non-Prioritaire 18,43 9,97 13,93
Temps d’attente moyen 10,61 9,74 13,10
Équipe de brancarderie
Nb moyen de requête par jour 24,97 25,63 25,64
Transport à vide (minute) 188,7 170,12 212,1
Transport chargé (minute) 204,65 206,72 200,7
Taux d'occupation 81,95% 78,51% 86,00%
Tableau 10 : Résultat de l'expérience 2
51
Figure 13 : Temps d'attente système suite à l'expérience 2
En comparant la règle d’affectation proposant le transport le plus proche avec celle de l’algorithme
actuel, on remarque que les temps d’attentes sont plus uniformes et que le système ne tient plus en
compte le niveau de priorité d’un transport. Le temps d’attente moyen, tant au niveau système qu’au
niveau patient est inférieur dans l’algorithme actuel. Cette diminution est principalement attribuable au
transport non prioritaire où une diminution de 66,19% est observée par rapport à l’algorithme
actuellement en place. Cependant, cette diminution de temps d’attente n’est pas nécessairement
associée avec une meilleure performance, car elle ne tient pas compte du niveau de priorité. Dans un
contexte de transport intrahospitalier, il est beaucoup plus important d’avoir de très bas temps d’attente
pour les demandes urgentes et importantes que pour le transport de matériel ou d’échantillons. Du
point de vue des brancardiers, le nombre moyen de requêtes par jour ainsi que le transport chargé est
sensiblement le même. Cependant, on remarque une importante diminution du temps passé à faire du
transport à vide. Cette réduction n'est pas étrangère au fait que d’affecter le transport le plus près a
justement pour objectif de réduire le temps de déplacement vers l’origine.
Lorsque l’on compare l’algorithme actuel avec la règle du premier arrivé, premier servi, on remarque
encore l’uniformité des temps d’attente, mais contrairement à la règle précédente, le temps d’attente
global a légèrement augmenté. Cette augmentation est encore plus prononcée au niveau du temps
0 2 4 6 8 10 12
Urgent
Important
Tournée
Non-Prioritaire
Premier arrivé, premierservi
Transport le plus proche
Algorithme actuel
52
d’attente patient. Ceci est compréhensible, car l’algorithme propose le premier transport arrivé dans le
système, même si ce dernier est complètement à l’opposé de la position du brancardier. C’est le même
principe qui explique le temps de transport à vide nettement supérieur aux deux autres règles
d’affectation.
En analysant ces résultats, on remarque que les deux algorithmes alternatifs ont des « forces »
respectives. Celui affectant le brancardier le plus prêt réduit considérablement le temps d’attentes, tant
système que patient, en plus de réduire le temps d’inoccupation des brancardiers. Dans le cas du
premier arrivé, premier servi, on remarque que l’algorithme est peu performant dans l’optimisation du
transport à vide ainsi qu’au niveau du temps d’attente, tant système que patient. Ce résultat est peu
surprenant, car bien qu’un brancardier soit complètement à l’opposé d’un transport, si ce dernier est
disponible et que c’est cette requête qui est arrivée la première, le transport sera affecté au brancardier.
Bien que l’algorithme du transport le plus prêt semble être globalement le plus performant, il ne
s’applique pas dans un contexte hospitalier. Étant donné la nature humaine des transports, les
indicateurs à eux seuls ne permettent pas de bien comparer les algorithmes. L’un des principaux
indicateurs afin de mesurer cette performance n’est pas quantifiable, car c’est le confort du patient et
dans certains cas, la survie de celui-ci. En dépit des indicateurs, l’algorithme actuel est le plus
performant, car il assure une priorisation selon le niveau d’importance, mais est équitable sur le plan
de la répartition des transports sans engendrer des délais indus pour les transports non prioritaires.
C’est ce qui explique l’uniformité des temps d’attente pour les deux algorithmes alternatifs
contrairement au temps d’attente proportionnelle au niveau de priorité de l’algorithme actuel.
53
Conclusion
À la lumière du présent document, on constate que la logistique hospitalière s’opère dans un contexte
très imprévisible et complexe. Plus particulièrement, le transport intrahospitalier est une étape critique
au niveau de la prestation de soin, car il sert de liaisons entre chacune des activités d’un établissement
de santé. Évoluant dans un environnement extrêmement dynamique et incertain, la planification et la
gestion du brancardage dans les hôpitaux deviennent alors extrêmement complexes.
L’objectif de ce document était de modéliser le transport de patient et de matériel en développant un
outil de simulation. Une fois validé, cet outil a permis de reproduire les transports au sein de
l’établissement cible et ainsi mesurer l’impact sur différente mesures de performance lorsque certains
paramètres sont modifiés.
Une fois développé et implanté, l’outil de simulation offre une infinité de possibilités. En effet, il pourrait
être intéressant de mesurer le comportement du système lorsque le délai maximum d’une requête est
modifié. L’ajout d’un autre niveau de priorité pour un type de transport spécifique pourrait également être
simulé et les différents indicateurs permettraient ainsi de mesurer son impact. De plus, l’outil permettra
de trouver l’équilibre entre le niveau de service désiré et le nombre de brancardiers nécessaire. Le
développement de l’outil est assez flexible de sorte qu’il est facilement implantable dans d’autres
établissements de santé. Étant donné que la majorité des paramètres nécessaire à la simulation sont
externe, ceux-ci peuvent être adaptés à un autre contexte et l’outil de simulation sera parfaitement
fonctionnel. L’utilisation d’un outil de simulation devient alors un outil supplémentaire à la prise de
décision dans la gestion et la planification du transport intrahospitalier.
54
Bibliographie
André, V.; Fenies, P. Modélisation et simulation des flux logistiques du Nouvel Hôpital d’Estaing, Logistique & Management, vol. 15, n° 1, 2007, p. 49-59.
Beaudry, A.; Laporte, G.; Melo, T.; Nickel, S. Dynamic Transportation of Patients in Hospitals », OR Spectrum, vol. 32, n° 1, 2010, p. 77-107.
Bouabdallah, MN & al. 2013. Organization and management of hospital patient transportation system, Proceeding of 2013 International Conference on Control, Decision and Information Technologies.
Boyd CR, Corse KM, Campbell RC: Emergency intrahospital transport of the major trauma patient: Air versus ground. J Trauma 1989; 29:789–793 (b)
Evans, S. et Pannesi, R. “The Patient Transportation Project at University Hospitals,” in Continuous Quality Improvement in Health Care (C. McLaughlin and Bibliography 83 A. Kaluzny, eds.), pp. 551–584, Sudbury, MA: Jones and Bartlett Publishers Canada, 2004.
Fiegl C, Pontow C (2009) Online scheduling of pick-up and delivery tasks in hospitals. Journal of Biomedical Informatics 42:624–632
Hendrich, A.L.; Lee, N. Intra-Unit Patient Transports: Time, Motion, and Cost Impact on Hospital Efficiency, Nursing Economics, vol. 23, n° 4, 2005, p. 157-164.
Jun, J., Jacobson, S. et Swisher, J. Application of discrete-event simulation in health care clinics: A survey, Journal of the Operational Research Society, vol.50, Issue2, 1999, p.109-123.
Katsaliako, K., Mustafee, N. Applications of simulation within the healthcare context, Journal of the Operational Research Society, vol 62, 2011, p.1431-1451.
Kuchera, D.; Rohleder, T.R. Optimizing the Patient Transport Function at Mayo Clinic, Quality Management in Health Care, vol. 20, n° 4, 2011, p. 334-342.
Law A. Simulation Modeling & Analysis. McGraw-Hill, Boston, MA, 2006
Miller, M. J., D. M. Ferrin, and J. M. Szymanski. 2003. Simulating six sigma improvement ideas for a hospital emergency department. In Proceedings of the 2003 Winter Simulation Conference.
Naesens, K.; Gelders, L. Reorganising a Service Department: Central Patient Transportation, Production Planning & Control, vol. 20, n° 6, 2009, p. 478-483.
Pidd, M. Computer simulation in management science 4th Edition, Hill John Wiley & Sons, Inc. 2004
55
Pollack-Johnson, B. 1987. Simulation of a hospital patient transportation system, Proceedings of the 1987 Winter Simulation Conference.
Takakuwa, S., Shiozaki, H. 2004. Functional analysis for operating emergency department of a general hospital, Proceedings of the 20004 Winter Simulation Conference.
Turan, B., Schmid, V., Dörner, K.F. 2011. Models for Intra- Hospital Patient Routing. 3rd IEEE International Symposium on Logistics and Industrial Informatics
Venkataraman ST, Orr RA: Intrahospital transport of critically ill patients. Crit Care Clin 1992; 8:525–531 (c)
56
Annexes
Annexe 1 : Table de probabilité pour déterminer l’origine
Entre Et Zone
0,000 0,172 25
0,172 0,261 33
0,261 0,346 15
0,346 0,416 2
0,416 0,482 1
0,482 0,546 4
0,546 0,598 31
0,598 0,641 18
0,641 0,682 8
0,682 0,718 3
0,718 0,752 7
0,752 0,779 10
0,779 0,806 26
0,806 0,830 5
0,830 0,854 11
0,854 0,871 12
0,871 0,887 14
0,887 0,904 22
0,904 0,920 6
0,920 0,935 13
0,935 0,948 17
0,948 0,962 20
0,962 0,976 21
0,976 0,983 9
0,983 0,990 19
0,990 0,997 29
0,997 0,998 23
0,998 1,000 24
57
Annexe 2 : Tables de probabilité pour déterminer la destination selon la zone d’origine
Origine : zone 1 Origine : zone 2
Entre et Zone Entre et Zone
0,000 0,310 15 0,000 0,473 15
0,310 0,527 24 0,473 0,662 33
0,527 0,682 33 0,662 0,702 2
0,682 0,767 14 0,702 0,738 25
0,767 0,822 13 0,738 0,771 1
0,822 0,857 1 0,771 0,804 14
0,857 0,888 7 0,804 0,825 13
0,888 0,911 20 0,825 0,847 18
0,911 0,926 2 0,847 0,865 7
0,926 0,942 25 0,865 0,884 20
0,942 0,953 23 0,884 0,902 22
0,953 0,965 26 0,902 0,916 3
0,965 0,977 31 0,916 0,931 29
0,977 0,984 6 0,931 0,942 4
0,984 0,992 22 0,942 0,953 11
0,992 0,996 4 0,953 0,964 17
0,996 1,000 18 0,964 0,971 12
0,971 0,978 19
0,978 0,985 26
0,985 0,989 6
0,989 0,993 23
0,993 0,996 24
0,996 1,000 31
58
Origine : zone 3 Origine : zone 4
Entre et Zone Entre et Zone
0,000 0,529 15 0,000 0,680 15
0,529 0,750 33 0,680 0,794 33
0,750 0,800 20 0,794 0,830 22
0,800 0,829 5 0,830 0,856 5
0,829 0,857 7 0,856 0,876 2
0,857 0,886 17 0,876 0,897 18
0,886 0,907 22 0,897 0,918 31
0,907 0,921 1 0,918 0,933 13
0,921 0,936 18 0,933 0,943 4
0,936 0,950 23 0,943 0,954 12
0,950 0,964 26 0,954 0,964 19
0,964 0,979 31 0,964 0,974 23
0,979 0,986 2 0,974 0,979 1
0,986 0,993 13 0,979 0,985 7
0,993 1,000 25 0,985 0,990 20
0,990 0,995 24
0,995 1,000 25
Origine : zone 5 Origine : zone 6
Entre et Zone Entre et Zone
0,000 0,299 33 0,000 0,333 13
0,299 0,577 15 0,333 0,533 33
0,577 0,670 19 0,533 0,711 19
0,670 0,732 11 0,711 0,800 1
0,732 0,794 13 0,800 0,867 22
0,794 0,835 25 0,867 0,911 15
0,835 0,866 17 0,911 0,933 17
0,866 0,897 31 0,933 0,956 20
0,897 0,918 18 0,956 0,978 21
0,918 0,938 20 0,978 1,000 31
0,938 0,959 21
0,959 0,979 29
0,979 0,990 3
0,990 1,000 23
59
Origine : zone 7 Origine : zone 8
Entre et Zone Entre et Zone
0,000 0,331 33 0,000 0,787 15
0,331 0,549 15 0,787 0,851 20
0,549 0,684 14 0,851 0,915 23
0,684 0,752 1 0,915 0,947 29
0,752 0,820 25 0,947 0,979 31
0,820 0,857 20 0,979 0,989 25
0,857 0,880 3 0,989 1,000 33
0,880 0,902 22
0,902 0,917 2
0,917 0,932 11
0,932 0,947 23
0,947 0,962 31
0,962 0,970 6
0,970 0,977 12
0,977 0,985 18
0,985 0,992 19
0,992 1,000 29
Origine : zone 9 Origine : zone 10
Entre et Zone Entre et Zone
0,000 0,545 15 0,000 0,571 15
0,545 0,727 10 0,571 0,714 31
0,727 0,909 23 0,714 0,794 33
0,909 1,000 33 0,794 0,857 13
0,857 0,921 18
0,921 0,952 19
0,952 0,968 7
0,968 0,984 20
0,984 1,000 23
60
Origine : zone 11 Origine : zone 12
Entre et Zone Entre et Zone
0,000 0,600 15 0,000 0,286 15
0,600 0,860 29 0,286 0,469 33
0,860 0,900 2 0,469 0,531 1
0,900 0,940 19 0,531 0,592 13
0,940 0,980 26 0,592 0,653 20
0,980 1,000 7 0,653 0,714 22
0,714 0,776 31
0,776 0,816 7
0,816 0,857 14
0,857 0,898 18
0,898 0,918 3
0,918 0,939 4
0,939 0,959 5
0,959 0,980 19
0,980 1,000 25
Origine : zone 13 Origine : zone 14
Entre et Zone Entre et Zone
0,000 0,293 6 0,000 0,323 7
0,293 0,483 25 0,323 0,613 1
0,483 0,655 1 0,613 0,726 2
0,655 0,741 5 0,726 0,839 15
0,741 0,793 2 0,839 0,903 31
0,793 0,845 4 0,903 0,952 12
0,845 0,897 33 0,952 0,968 6
0,897 0,931 12 0,968 0,984 18
0,931 0,966 15 0,984 1,000 25
0,966 0,983 3
0,983 1,000 10
61
Origine : zone 15 Origine : zone 17
Entre et Zone Entre et Zone
0,000 0,155 3 0,000 0,875 15
0,155 0,302 31 0,875 0,917 1
0,302 0,369 4 0,917 0,958 10
0,369 0,436 7 0,958 1,000 12
0,436 0,500 2
0,500 0,561 25
0,561 0,613 12
0,613 0,662 5
0,662 0,710 33
0,710 0,756 10
0,756 0,799 1
0,799 0,838 8
0,838 0,872 15
0,872 0,899 29
0,899 0,921 23
0,921 0,942 26
0,942 0,960 22
0,960 0,976 6
0,976 0,982 9
0,982 0,988 20
0,988 0,991 17
0,991 0,994 18
0,994 0,997 24
0,997 1,000 27
62
Origine : zone 18 Origine : zone 19
Entre et Zone Entre et Zone
0,000 0,234 15 0,000 0,320 5
0,234 0,355 10 0,320 0,640 6
0,355 0,452 4 0,640 0,760 4
0,452 0,540 9 0,760 0,840 2
0,540 0,613 2 0,840 0,880 7
0,613 0,677 7 0,880 0,920 10
0,677 0,734 5 0,920 0,960 11
0,734 0,790 6 0,960 1,000 26
0,790 0,839 12
0,839 0,879 3
0,879 0,919 18
0,919 0,935 1
0,935 0,952 8
0,952 0,968 25
0,968 0,976 11
0,976 0,984 26
0,984 0,992 31
0,992 1,000 33
Origine : zone 20 Origine : zone 21
Entre et Zone Entre et Zone
0,000 0,154 2 0,000 0,814 24
0,154 0,269 1 0,814 0,907 4
0,269 0,385 5 0,907 0,953 15
0,385 0,500 6 0,953 0,977 5
0,500 0,615 10 0,977 1,000 6
0,615 0,731 15
0,731 0,808 3
0,808 0,885 8
0,885 0,923 4
0,923 0,962 7
0,962 1,000 12
63
Origine : zone 22 Origine : zone 23
Entre et Zone Entre et Zone
0,000 0,426 15 0,000 0,200 2
0,426 0,541 4 0,200 0,400 5
0,541 0,623 25 0,400 0,600 7
0,623 0,689 2 0,600 0,800 10
0,689 0,754 6 0,800 1,000 15
0,754 0,820 7
0,820 0,869 3
0,869 0,918 12
0,918 0,951 1
0,951 0,984 26
0,984 1,000 13
Origine : zone 24 Origine : zone 25
Entre et Zone Entre et Zone
0,000 0,400 25 0,000 0,570 15
0,400 0,600 4 0,570 0,676 33
0,600 0,800 9 0,676 0,735 10
0,800 1,000 10 0,735 0,780 1
0,780 0,825 31
0,825 0,855 5
0,855 0,877 3
0,877 0,900 7
0,900 0,921 6
0,921 0,940 13
0,940 0,957 2
0,957 0,969 12
0,969 0,978 4
0,978 0,985 22
0,985 0,990 14
0,990 0,994 20
0,994 0,997 19
0,997 0,999 18
0,999 1,000 26
64
Origine : zone 26 Origine : zone 29
Entre et Zone Entre et Zone
0,000 0,548 15 0,000 0,864 15
0,548 0,677 33 0,864 0,955 8
0,677 0,758 3 0,955 1,000 12
0,758 0,823 2
0,823 0,871 1
0,871 0,919 5
0,919 0,952 22
0,952 0,968 7
0,968 0,984 12
0,984 1,000 19
Origine : zone 31 Origine : zone 33
Entre et Zone Entre et Zone
0,000 0,692 15 0,000 0,165 25
0,692 0,821 25 0,165 0,304 2
0,821 0,846 4 0,304 0,429 7
0,846 0,866 3 0,429 0,545 1
0,866 0,886 10 0,545 0,652 3
0,886 0,905 33 0,652 0,742 5
0,905 0,920 1 0,742 0,829 4
0,920 0,935 6 0,829 0,881 6
0,935 0,950 12 0,881 0,922 12
0,950 0,965 14 0,922 0,945 15
0,965 0,975 5 0,945 0,968 31
0,975 0,985 7 0,968 0,980 10
0,985 0,995 8 0,980 0,986 8
0,995 1,000 23 0,986 0,991 18
0,991 0,994 13
0,994 0,997 22
0,997 1,000 26
65
Annexe 3 : Table de validation des zones
Différence
Zone Nb transport Proportion (%) Nb transport Proportion (%) |hist-simul|
1 1250 6,60% 1335 7,04% 0,45%
2 1355 7,15% 1250 6,60% 0,56%
3 675 3,56% 710 3,75% 0,18%
4 1205 6,36% 1155 6,09% 0,27%
5 485 2,56% 485 2,56% 0,00%
6 310 1,64% 320 1,69% 0,05%
7 655 3,46% 605 3,19% 0,27%
8 775 4,09% 775 4,09% 0,00%
9 145 0,77% 145 0,77% 0,00%
10 510 2,69% 500 2,64% 0,05%
11 445 2,35% 440 2,32% 0,03%
12 325 1,72% 270 1,42% 0,29%
13 290 1,53% 305 1,61% 0,08%
14 315 1,66% 340 1,79% 0,13%
15 1615 8,53% 1750 9,23% 0,71%
17 255 1,35% 250 1,32% 0,03%
18 790 4,17% 880 4,64% 0,47%
19 135 0,71% 110 0,58% 0,13%
20 265 1,40% 160 0,84% 0,55%
21 265 1,40% 275 1,45% 0,05%
22 320 1,69% 350 1,85% 0,16%
23 30 0,16% 40 0,21% 0,05%
24 30 0,16% 30 0,16% 0,00%
25 3325 17,56% 3310 17,47% 0,09%
26 495 2,61% 455 2,40% 0,21%
29 125 0,66% 115 0,61% 0,05%
31 835 4,41% 950 5,01% 0,60%
33 1715 9,05% 1640 8,65% 0,40%
SimulationHistorique
Origine
66
Différence
Zone Nb transport Proportion (%) Nb transport Proportion (%) |hist-simul|
1 1630 8,65% 1755 9,26% 0,61%
2 735 3,90% 495 2,61% 1,29%
3 680 3,61% 505 2,66% 0,94%
4 505 2,68% 410 2,16% 0,52%
5 785 4,17% 1020 5,38% 1,22%
6 415 2,20% 430 2,27% 0,07%
7 705 3,74% 825 4,35% 0,61%
8 185 0,98% 35 0,18% 0,80%
9 75 0,40% 105 0,55% 0,16%
10 465 2,47% 360 1,90% 0,57%
11 90 0,48% 60 0,32% 0,16%
12 340 1,80% 315 1,66% 0,14%
13 525 2,79% 655 3,46% 0,67%
14 290 1,54% 225 1,19% 0,35%
15 6420 34,07% 6345 33,48% 0,58%
17 55 0,29% 105 0,55% 0,26%
18 265 1,41% 165 0,87% 0,54%
19 150 0,80% 275 1,45% 0,66%
20 230 1,22% 205 1,08% 0,14%
21 35 0,19% 10 0,05% 0,13%
22 220 1,17% 325 1,72% 0,55%
23 135 0,72% 215 1,13% 0,42%
24 545 2,89% 585 3,09% 0,20%
25 585 3,10% 460 2,43% 0,68%
26 120 0,64% 150 0,79% 0,15%
27 5 0,03% 5 0,03% 0,00%
29 205 1,09% 260 1,37% 0,28%
31 610 3,24% 810 4,27% 1,04%
33 1840 9,76% 1840 9,71% 0,05%
Historique Simulation
Destination