Michel Gosselin1,2, B.Pharm., M.Sc.
Reçu le 23 août 2016; Accepté après révision le 12 décembre 2016
Résumé
Objectif : Présenter la manière de gérer une panne informatique au sein d’un département de pharmacie d’un établissement de santé. Présenter un plan de contingence pour prévenir un bris de service.
Description de la problématique : Le département de pharmacie du Centre universitaire de santé McGill a dû composer avec la perte de son système informatique de pharmacie pendant une période de 54 heures en décembre 2014. La perte du système était due à un bris d’équipement informatique d’un serveur de l’hôpital, ce qui a mené à une panne du système informatique de pharmacie causant une corruption de la base de données.
Résolution de la problématique : Les gestionnaires de la pharmacie ont eu besoin de réaménager les ressources humaines et matérielles en s’inspirant du plan de contingence existant. Pendant cette période, le personnel de pharmacie a été contraint de gérer les profils pharmacologiques et le processus de distribution des médicaments de façon manuelle. La communication interdépartementale a été une des clés du succès de la gestion de cette panne.
Conclusion : La panne informatique a obligé le personnel du département de pharmacie à travailler manuellement pendant 54 heures avant de pouvoir récupérer son système. Les médecins et les infirmières ont également subi des désagréments occasionnés par le bris du circuit du médicament. Un plan d’urgence a été mis en place pour réduire les effets de cette panne et pouvoir assurer la distribution sécuritaire des médicaments.
Mots clés : Circuit du médicament, équipement technologique, panne informatique, plan de contingence, système informatique, système de pharmacie
Abstract
Objective: To explain how to deal with a computer outage in a health-care facility’s pharmacy department and to present a contingency plan to prevent a disruption in service.
Problem description: The McGill University Health Centre’s Department of Pharmacy experienced a loss of its pharmacy computer system for a period of 54 hours in December 2014. The outage was due to a hardware malfunction on one of the hospital’s servers, which caused the pharmacy’s computer system to crash and, in the process, the database to become corrupted.
Problem resolution: The pharmacy’s managers had to rearrange the human and physical resources, taking guidance from the existing contingency plan, and the pharmacy’s staff had to manage the drug profiles and the drug dispensing process manually during this period. Interdepartmental communication was one of the keys to success in dealing with the outage.
Conclusion: The computer outage forced the Department of Pharmacy’s staff to do their work manually for 54 hours before its system was restored. As well, the physicians and nurses were inconvenienced by the interruption in the medication circuit. An emergency plan was put in place to minimize the impact of the outage and to ensure safe drug dispensing.
Keywords: Computer outage, computer system, contingency plan, medication circuit, pharmacy system, technical equipment
La technologie est de plus en plus présente dans nos vies. Toute activité que nous effectuons quotidiennement comporte désormais un aspect technologique. Pensons aux innombrables télécommandes qu’il faut savoir manier pour regarder un film à la télévision, aux cartes d’accès qu’il nous faut posséder pour pouvoir entrer dans un local, aux lecteurs de codes-barres nécessaires pour identifier un article à la caisse. La distribution des médicaments n’a pas échappé à cette course à la technologie, et les étapes entre la prescription du médicament par le médecin et son administration au patient par l’infirmière (connues comme le circuit du médicament) nécessitent aujourd’hui l’utilisation d’équipements technologiques et informatiques desquels nous dépendons beaucoup. Pour éviter tout bris dans ce circuit du médicament, le département de pharmacie doit s’assurer d’avoir un plan de contingence qui saura pallier les manques à une étape ou l’autre de la distribution des médicaments.
Un plan de contingence est un type de plan préventif, prédictif et réactif1,2. Il présente une structure stratégique et opérative qui aide à prendre le contrôle d’une situation d’urgence et à réduire ses conséquences négatives (temps d’arrêt et autres). Le plan de contingence propose tout un ensemble de procédures de substitution au fonctionnement normal d’une organisation, lorsque l’une de ses fonctions habituelles est affectée par une contingence interne ou externe1. Il comporte la liste des personnes à contacter d’urgence et décrit les actions à poser lorsqu’une ou plusieurs composantes du système tombent en panne ou pour la mise en œuvre d’un plan de récupération (restauration des données et retour à un mode de fonctionnement normal).
Le plan de contingence d’un système informatique dépend de plusieurs facteurs : le type de système affecté, le type de panne et l’importance de la panne2. Le plan de contingence variera donc en fonction de l’un ou l’autre de ces facteurs.
Lorsque le système d’admission de l’hôpital est affecté, le système informatique de pharmacie ne pourra plus recevoir automatiquement les admissions, les transferts et les congés des patients hospitalisés par son interface. Il s’ensuivra une désynchronisation du recensement des patients dans le système informatique de pharmacie. Le personnel devra donc prendre manuellement les admissions, les transferts et les congés afin que les équipements et les étiquettes déterminent correctement l’endroit où se trouvent les patients. Si le système clinique centralisé de l’hôpital fait défaut, les dossiers-patients électroniques ne seront plus mis à jour, et il faudra prévoir un autre mécanisme capable de fournir l’information au personnel médical.
Le plan de contingence variera aussi en fonction du type de panne. Si la panne est prévue, on peut réduire les conséquences en choisissant le meilleur moment de la journée pour déclencher cette panne. Si la panne n’est pas prévue, l’ampleur du problème sera fonction de la composante qui tombe en panne (pièce d’équipement, panne logicielle, panne de courant).
De plus, le plan de contingence devra être choisi en fonction de la durée de la panne. Si on estime que la panne sera de courte durée, soit moins de deux heures, on pourra décider de ne pas déclencher de plan de contingence. Par contre, si on estime que la panne durera de quatre à huit heures, la décision de démarrer immédiatement un plan de contingence se justifie. La décision de démarrer un plan de contingence n’est pas toujours facile à prendre, puisqu’elle implique le déplacement du personnel de pharmacie, le retrait ou l’ajout de ressources à certains endroits critiques du circuit du médicament3. Ce sont les gestionnaires des départements affectés, soit la pharmacie, les soins infirmiers, les médecins, qui prennent cette décision après consultation du département et du fournisseur du logiciel et de l’équipement affectés. Une fois les problèmes corrigés, il est nécessaire de mettre en place un plan de récupération qui porte entre autres sur la réparation de l’équipement, la correction du logiciel ou le rétablissement du courant4. Il faudra prévoir en outre du personnel et du temps supplémentaires pour effectuer les validations et vérifications nécessaires.
Le plan de contingence en place au Centre universitaire de santé McGill (CUSM) n’avait pas été mis à jour depuis 2005 (voir les tableaux I, II et III). Ce plan prenait en compte les principaux éléments (serveurs et imprimantes), mais écartait les nouvelles technologies (par exemple les cabinets automatisés).
Tableau I Plan de contingence au Centre universitaire de santé McGill : Actions à entreprendre lors de situations critiques
Tableau II Plan de contingence au Centre universitaire de santé McGill : Liste de communication
Tableau III Plan de contingence au Centre universitaire de santé McGill : Actions à entreprendre lors de situations de plus longue durée
Tableau IV Panne informatique et processus de résolution
Cet article présente une panne informatique vécue au CUSM en décembre 2014, qui a affecté le système de distribution des médicaments pendant trois jours. Il décrit les problèmes rencontrés et présente les solutions retenues en soulignant l’importance de disposer d’un plan de contingence bien élaboré et de connaître le moment opportun pour le déployer.
À 10 heures du matin, le système informatique de la pharmacie cesse subitement de fonctionner. Le logiciel CentricityMD, de la compagnie BDMMD, est utilisé depuis 2002 sur les cinq sites du CUSM, soit l’Hôpital Royal Victoria, l’Hôpital général de Montréal, l’Hôpital de Montréal pour enfants, l’Institut thoracique de Montréal et l’Hôpital neurologique de Montréal. Tous ces sites étant branchés sur un seul serveur, la panne a affecté tous les sites en même temps.
CentricityMD ne fonctionnant plus, il était impossible de recevoir les transactions de l’admission, d’envoyer les profils électroniques au système clinique centralisé et aux équipements technologiques, de générer les feuilles d’administration des médicaments pour les infirmières (FADM), de saisir les ordonnances dans le système et de générer des étiquettes pour la distribution. À cette date, en 2014, les seuls équipements technologiques en service étaient deux ensacheuses unidose PacmedMD à l’Hôpital Royal Victoria et à l’Hôpital général de Montréal et une quinzaine de cabinets automatisés décentralisés AcuDoseMD sur tous les sites. Aucun robot et carrousel n’était utilisé à cette époque.
Le type d’erreur présent sur les écrans des usagers au moment de la panne laissait présager une panne majeure qui a effectivement été confirmée par le fournisseur BDMMD et par le département d’informatique du CUSM. En fait, deux pannes simultanées ont eu lieu : la panne qui a précipité le tout a été causée par le bris d’une pièce d’équipement du réseau de stockage (SAN, de l’anglais Storage Area Network) de l’hôpital, endroit où se trouvent les bases de données. Le bris de cette pièce d’équipement a fait basculer vers le SAN redondant toutes les applications du CUSM qui utilisaient le SAN. Ces applications ont ainsi pu récupérer leurs données, sauf CentricityMD, qui utilisait à ce moment-là une version surannée de son système d’exploitation AIXMD pour Unix, ce qui l’a empêché de basculer correctement vers le SAN redondant. De plus, la configuration de basculement de CentricityMD était défectueuse et n’a pas permis la synchronisation correcte des données dans le SAN redondant, ce qui a entraîné la corruption des données. Celles-ci étant corrompues, BDMMD a dû récupérer la base de données à partir d’une des dernières sauvegardes effectuées. En même temps, le département d’informatique a procédé au remplacement de la pièce défectueuse.
Étant donné que la partie affectée par la panne était le système informatique de pharmacie lui-même et qu’on estimait que la panne logicielle serait de longue durée, la décision de démarrer immédiatement le plan de contingence s’imposait. Ce dernier ne représentant plus tout à fait la réalité de 2014, il a fallu l’ajuster et l’adapter en fonction des équipements en place.
Le matin même de la panne, avant dix heures, tous les rapports et toutes les étiquettes de la journée avaient été générés, si bien que les étiquettes nécessaires à la préparation des médicaments injectables et les fichiers requis pour l’ensachement unidose des médicaments par les ensacheuses étaient disponibles. Les renouvellements de services durant la journée étaient donc assurés. Par contre, toutes les nouvelles ordonnances ont dû être traitées manuellement. Pour ce faire, le personnel devait disposer des étiquettes et des profils de patients. Les étiquettes ont été immédiatement imprimées à l’aide du logiciel MS-WordMD et des pages d’étiquettes de type AveryMD. La décision a été prise d’imprimer des séries d’étiquettes pour les médicaments à préparer au service centralisé d’addition aux solutés (SCAS), en laissant un espace vide pour l’identification du patient, la mention de l’étage et de la dose. Quant aux étiquettes des autres médicaments (oraux, topiques, injectables en fioles, etc.) elles étaient totalement rédigées à la main.
Afin de permettre aux infirmières d’accéder aux médicaments prescrits et puisque les cabinets AcuDoseMD ne pouvaient plus recevoir les ordonnances du système informatique de pharmacie pour libérer les médicaments spécifiques aux patients, ils ont tous été mis en accessibilité totale (override mode).
Les copies des FADM utilisées par les infirmières aux unités de soins ont fait office de profils de patients, car elles étaient plus à jour que les profils disponibles dans le système clinique centralisé, puisqu’elles renfermaient les toutes dernières ordonnances qui n’étaient pas encore inscrites dans CentricityMD. Ces copies de FADM étaient donc mises à jour avec les nouvelles ordonnances reçues à la pharmacie. Pour aider à la distribution des médicaments, étant donné que les inscriptions devaient se faire manuellement, tous les pharmaciens travaillant aux unités de soins des différents milieux hospitaliers (n = 12) ont été rapatriés à leur pharmacie principale respective.
Ce modèle de travail a été maintenu pour le reste de la journée, puisque le fournisseur BDMMD a été confronté toute la journée à des erreurs de récupération de la base de données. Cette version de la base de données (construite en langage ProgressMD) comportait un bogue l’empêchant de récupérer les données à l’aide de l’outil de sauvegarde. Le fournisseur BDMMD a décidé de réparer la base de données (au lieu de la récupérer) en transformant les données de façon à recréer une base de données fraîche. Ce travail a été effectué durant la nuit.
En fin d’après-midi, une conférence téléphonique s’est tenue avec la directrice des services professionnels et la directrice des soins infirmiers dans le but de préparer une communication à l’intention des médecins et du personnel infirmier pour les avertir que l’information dans le système clinique centralisé n’était plus à jour depuis 10 heures du matin. Le seul document mentionnant tous les médicaments de chaque patient était la FADM. Le personnel infirmier a été informé que la pharmacie ne serait pas en mesure de produire une nouvelle version des FADM et qu’il devrait utiliser les FADM du 17 décembre pour enregistrer les doses administrées le 18 décembre.
Mauvaise nouvelle : à 7 heures du matin, le processus de transfert de données vers une nouvelle base de données a connu des erreurs durant la nuit. Le fournisseur BDMMD devait donc reconstruire les index de la base de données. Cette procédure devait prendre une bonne partie, sinon la totalité de la journée.
À 7 h 30, une conférence téléphonique a été tenue avec les gestionnaires des sites de pharmacie et les chefs d’équipe pour établir le plan de match de la journée. Ils ont décidé de rapatrier à nouveau à la pharmacie centrale tous les pharmaciens normalement assignés aux unités de soins pour effectuer les tâches requises à la distribution des médicaments. Les FADM utilisées la veille ont été utilisées pour une deuxième journée consécutive. Elles ont été photocopiées pour être utilisées au service centralisé d’addition aux solutés (SCAS) en vue de déterminer les médicaments injectables à préparer. On a eu recours au fichier de l’ensacheuse de la veille pour ensacher les médicaments unidoses, et on a procédé à la mise à jour du contenu des tiroirs-patients dans les chariots de transfert à partir des FADM de la pharmacie.
À midi, une nouvelle conférence téléphonique s’est tenue avec le fournisseur BDMMD, le département d’informatique, la directrice des services professionnels et la directrice des soins infirmiers pour confirmer le statut de la panne et décider de la poursuite du plan de contingence. Nous avons décidé que les infirmières recopient de nouvelles FADM pour créer celles du 19 décembre à partir de celles du 17 qui ont été maintenues à jour depuis cette date. Vers 23 heures, CentricityMD était disponible. Après quelques vérifications par l’administrateur du système de pharmacie, le département d’informatique a demandé de quitter l’application pour être en mesure d’effectuer une copie de la base de données sur le serveur redondant. Durant toute la nuit, le département d’informatique a effectué les vérifications nécessaires.
À 8 heures du matin, les gestionnaires de sites et les chefs d’équipe ont établi le même plan de match que la veille : les pharmaciens rapatriés, les FADM manuelles, les étiquettes manuscrites, le fichier du 17 décembre pour l’ensacheuse. CentricityMD était encore entre les mains du département d’informatique. Le fichier de l’ensacheuse commençait à être désuet et risquait d’être de moins en moins conforme aux besoins réels. Il s’agissait cependant de la seule façon d’obtenir un nombre suffisant de médicaments automatiquement ensachés. Une validation a eu lieu avant la livraison des chariots unidoses pour vérifier l’exactitude des médicaments à partir des FADM manuellement maintenues à jour.
Le 19 décembre à 10 heures, CentricityMD était à nouveau totalement disponible et fonctionnel. L’administrateur du système de pharmacie devait cependant procéder à une vérification de son état : configurations, données, interfaces, etc. Il a fallu rétablir les horloges des différents rapports de distribution automatisés, remettre en fonction les interfaces pour l’admission, le système clinique centralisé et les cabinets. Le recensement des patients dans le système de pharmacie a dû être synchronisé avec l’admission. Des tests préliminaires avec un pharmacien de chaque site ont été effectués pour s’assurer du fonctionnement correct du système : saisie des ordonnances, génération des étiquettes, calcul des quantités à distribuer, envoi des résultats vers le système clinique centralisé et les cabinets. Toutes ces étapes de vérification du bon fonctionnement et de l’intégrité du système se sont déroulées entre 10 heures et 15 heures.
À 12 heures, une autre conférence téléphonique s’est tenue avec le département d’informatique, la directrice des services professionnels et la directrice des soins infirmiers pour confirmer la levée de la panne et la récupération imminente du système. Ils ont pris connaissance du fait que le système clinique centralisé ne serait à jour qu’en fin de soirée, une fois terminé le rattrapage des ordonnances. Les infirmières devront peut-être recopier à nouveau les FADM si le rattrapage des ordonnances n’est pas terminé à temps pour l’impression des FADM en soirée.
À 15 heures, une conférence téléphonique s’est tenue avec les gestionnaires de sites et les chefs d’équipes pour établir le plan de récupération de la saisie des ordonnances et la procédure du contrôle de la qualité dans le but d’assurer la concordance des données entre le dossier pharmacologique, les ordonnances des dernières 48 heures et les FADM. Nous avons évalué les besoins en ressources humaines pour la soirée.
À 16 heures, le plan d’action pour la soirée était achevé, et le système informatique de pharmacie était remis à la disposition des usagers. Étant donné l’heure tardive, on a décidé de ne pas demander aux médecins de prescrire à nouveau les médicaments actifs des patients. Nous avions la conviction que les profils manuels (maintenus à jour à partir d’une copie des FADM) étaient suffisamment fiables pour qu’il puissent servir à la saisie des ordonnances dans le système.
Nous avons donc décidé d’utiliser les profils/FADM de la pharmacie pour saisir les ordonnances manquantes et retirer celles qui n’étaient plus actives.
La saisie ne portait que sur les ordonnances actives qui ne se trouvaient pas dans CentricityMD. On n’a pas tenu compte des ordonnances ayant été prescrites ou ayant expiré durant l’intervalle de la panne. Les pharmaciens des unités de soins sont restés en poste jusqu’à ce que les profils de leurs patients aient été validés. Une deuxième équipe de pharmaciens a été mise à contribution à la pharmacie centrale de chaque site pour s’occuper des ordonnances manquantes. L’équipe de pharmaciens déjà en place s’est occupée des ordonnances courantes. Lorsque les ordonnances ont été validées pour chacune des unités de soins, l’administrateur du système d’informatique de la pharmacie a imprimé manuellement les FADM directement aux unités de soins. Le rattrapage des ordonnances s’est terminé à deux heures du matin dans la nuit du vendredi au samedi.
Entre 6 heures et 8 heures du matin, l’administrateur du système informatique de pharmacie s’est assuré que l’impression des rapports et des étiquettes était correcte. De 9 heures à 14 heures, le pharmacien-chef a visité chacun des sites pour prendre connaissance des problèmes et s’assurer du bon déroulement de la journée. Aucun problème n’est survenu, si ce n’est de légers écarts par rapport à certaines FADM, qui ont été faciles à corriger. À 12 heures, une dernière conférence téléphonique s’est tenue avec le département d’informatique, la directrice des services professionnels et la directrice des soins infirmiers pour confirmer que le système de pharmacie fonctionnait normalement, que le système clinique centralisé était à jour et que les FADM seraient imprimées automatiquement en soirée.
À l’Hôpital Royal Victoria, on a examiné un échantillon de trois dossiers patients par unité de soins pour confirmer la concordance des données entre les dossiers pharmacologiques du système de pharmacie, les FADM et les ordonnances des médecins. Les résultats n’ont démontré aucun écart et aucun rapport d’erreur. Le tableau IV résume les différentes étapes de la panne et de son processus de résolution.
Étant donné le nombre important de systèmes informatiques interreliés, la panne d’une seule composante ne peut pas être considérée comme un incident isolé qui peut être géré en vase clos1. La perte du cœur du circuit, c’est-à-dire du système informatique de pharmacie, paralyse ou affecte grandement les intrants (les admissions, transferts et départs) et les extrants (profils au système clinique centralisé, étiquettes et distribution des médicaments, FADM). Tous les autres intervenants, soit les médecins et les infirmières, doivent être mis à contribution, puisqu’ils seront affectés d’une manière ou d’une autre par la perte du système de pharmacie : les uns par la perte du profil électronique au système clinique centralisé, les autres par la perte des FADM automatisées. La communication joue ici un rôle crucial, et il est important de bien informer tous les intervenants au fur et à mesure de l’apparition de nouvelles données3.
Le choix d’utiliser les FADM des infirmières plutôt que le profil existant dans le système clinique centralisé au moment de la panne a été déterminé par l’exhaustivité des données colligées. Les photocopies des FADM de tous les patients ont servi de profils médicamenteux aux pharmaciens. La gestion des profils FADM a été un enjeu de taille, soit un nombre important de papiers qu’il a fallu classer dans un ordre logique de façon à être en mesure de retrouver rapidement le profil de chaque patient. Le nombre important de transferts de patients d’une unité de soins à une autre augmentait la complexité de la gestion de la tâche.
Les cabinets AcuDoseMD étaient installés dans les endroits où la pharmacie ne distribuait pas ou peu les médicaments de façon nominative (ex.: urgence, soins coronariens, soins intensifs neurologiques). La grande majorité des médicaments provenait donc des cabinets. L’accessibilité totale (override mode) à tout le contenu des cabinets était devenue un enjeu de sécurité. En effet, les infirmières pouvaient accéder à toutes les pochettes de médicaments sans passer par le profil médicamenteux du patient inscrit au cabinet et qui n’était de surcroît plus à jour, ce qui accroissait le risque de choisir la mauvaise pochette et d’administrer le mauvais médicament.
Les étiquettes des premières doses étaient écrites par les pharmaciens et remises aux assistants techniques en pharmacie (ATP) qui remplissaient les ordonnances ou qui les relayaient au SCAS. Les étiquettes des renouvellements de services des médicaments injectables fabriqués au SCAS étaient écrites par les ATP, qui consultaient les profils/ FADM. Pour accélérer la transcription manuelle des informations sur les étiquettes des médicaments préparés au SCAS, nous avons utilisé des feuilles d’étiquettes de type AveryMD sur lesquelles nous avons inscrit les informations de base sur l’administration des médicaments les plus communs (diluant, route, vitesse de perfusion, information de réfrigération, etc.). Seuls les champs de la dose et de la fréquence d’administration restaient vides pour permettre d’y inscrire les données spécifiques à chaque ordonnance.
La préparation des médicaments ensachés unitairement par la PacmedMD devenait un enjeu de taille au moment de la livraison. Les différences entre le fichier du 17 décembre, qui a servi pour la construction des bandelettes de médicaments ensachés des 18 et 19 décembre et les ordonnances actives de ces jours-là s’accroissaient. Il fallait donc porter une grande attention aux médicaments qui devaient être retirés des bandelettes en fonction des profils/FADM manuellement maintenus à jour par les pharmaciens. Et il fallait aussi veiller à ajouter dans les tiroirs-patients les sachets des médicaments qui ne faisaient pas partie des bandelettes et qui se trouvaient être les nouvelles ordonnances émises depuis la panne.
Il ne faut pas minimiser le travail nécessaire pour remettre le système en état2. Il ne suffit pas que le système informatique de pharmacie fonctionne à nouveau pour que tout soit réglé : il faut saisir les données qui n’ont pas pu être enregistrées lorsque le système n’était pas fonctionnel. Nous avons choisi d’ignorer les ordonnances qui ont été prescrites après le début et qui ont expiré avant la fin de la panne, comme les doses uniques.
Une panne informatique pouvant survenir à tout instant, il est primordial d’avoir un plan de contingence à jour et connu de tous les intervenants engagés dans ce processus. Un système de communication, non seulement interne à la pharmacie, mais aussi externe avec les autres départements (informatique, médical, infirmier) est essentiel au bon déroulement du plan de contingence6. L’accès aux documents papier (ex. : ordonnances médicales, FADM) et aux étiquettes préimprimées est un atout précieux; si la prescription et l’enregistrement des doses se font électroniquement, il est d’autant plus important que les formules papier de ces documents soient encore disponibles7.
Lors de la remise en état du système, il est nécessaire d’avoir des équipes qui se consacrent à des tâches précises : une équipe qui vérifie l’intégrité du système, une qui procède à la saisie des ordonnances passées, une à celle des nouvelles, une autre qui vérifie la concordance entre les ordonnances écrites et les profils médicamenteux. Cette phase peut potentiellement générer de la confusion parmi les employés et nécessite une étroite coordination2.
Le plan de contingence ne devrait pas seulement être connu des administrateurs et des gestionnaires, mais aussi de tous les employés, de sorte que lorsque survient une panne informatique, de quelque importance que ce soit, tous soient conscients des efforts qui seront requis pour maintenir un circuit du médicament fiable. Idéalement, il faudrait organiser des simulations de pannes de telle ou telle composante du circuit, sous des conditions très strictes, pour amener les employés à connaître les tâches auxquelles ils seraient confrontés lors d’une panne réelle6.
Le plan de contingence du CUSM doit prendre en compte toutes les nouvelles technologies apparues au cours des dernières années. En effet, depuis le déménagement au site Glen de l’Hôpital Royal Victoria, de l’Hôpital de Montréal pour enfants et de l’Institut thoracique de Montréal en mai et juin 2015, l’ajout de nouveaux équipements technologiques, tels qu’un robot, des carrousels, une ensacheuse supplémentaire, des cabinets automatisés à chaque unité de soins et des chariots d’anesthésie dans les salles d’opération, le risque de faire face à une panne s’est multiplié en raison du plus grand nombre d’équipements.
Par contre, la mise à jour du système informatique de pharmacie, prévue pour mars 2017, accroîtra le degré de sécurité à cause des serveurs neufs, plus performants, dont les composantes sont maintenant à jour. La révision du plan de contingence doit prendre en compte tous ces équipements et les liens qui les réunissent. Une fois le système informatique de pharmacie mis à jour, avec ses nouvelles composantes plus robustes et récentes, nous serons en mesure de simuler des pannes en vue de mettre à jour le plan de contingence tout en réduisant les risques de perte de contrôle de la situation.
Comme nous vivons maintenant dans un environnement informatisé où (presque) plus rien n’est manuel, il faut toujours prévoir le pire. Des équipements à jour, un plan de contingence et d’excellentes communications avec nos partenaires (pharmaciens, assistants techniques, soutien informatique, personnel médical et infirmier) sont essentiels pour pouvoir survivre à une panne informatique.
1. Définition de plan de contingence - Concept et Sens. [en ligne] http://lesdefinitions.fr/plan-de-contingence#ixzz4GGfGd8XV (site visité le 9 avril 2016).
2. Miller AS. Planning for downtime. Dans : Domitru D, éditeur. The pharmacy informatics primer. Bethesda : ASHP; 2008. p. 195–219.
3. Plan B. A practical approach to downtime planning in medical practices. [en ligne] http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_045486.hcsp?dDocName=bok1_045486 (site visité le 9 avril 2016).
4. Getrz L. Dealing with downtime. [en ligne] http://www.fortherecordmag.com/archives/110909p16.shtml (site visité le 9 avril 2016).
5. M. Gosselin. Plan de contingence informatique du département de pharmacie du CUSM, 2005.
6. Bilodeau K. Preparing for EHR downtime and system failures. [en ligne] https://www.unitedadlabel.com/resource-center/whitepapers/ehr-downtime-preparation (site visité le 9 avril 2016).
7. Minghella L. Be prepared :lessons from an extended outage of a hospital’s EHR system. [en ligne] http://www.healthcare-informatics.com/article/be-prepared-lessons-extended-outage-hospital-s-ehr-system (site visité le 9 avril 2016).
PHARMACTUEL, Vol. 50, No. 1, 2017