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.)
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
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.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
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
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
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.
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
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.
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
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 N om br e m oy en d e tr an sp or t Heure de la journée
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.
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.
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-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.
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.
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).
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.
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
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é.
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
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
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
2epause 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.
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 pause
Tableau 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
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
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
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
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
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é
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é d'importanceFacteur
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
