Expérience d’optimisation d’un dossier électronique au Danemark

J’ai déjà parlé d’un article décrivant l’expérience d’implantation d’un dossier électronique commercial dans trois pays européens (incluant le Danemark) ainsi que d’un article de revue sur le sujet. Une nouvelle publication en janvier 2021 décrit l’expérience de mise en place d’un programme d’optimisation des éléments cliniques (les flux de travail, les protocoles, etc.), après la phase de déploiement initiale, dans deux réseaux de santé totalisant 12 hôpitaux danois.

La manière de réaliser cette optimisation suggérée par le fournisseur du logiciel en question repose sur des physician builders, des médecins formés comme pilotes des éléments cliniques du système. Cette optimisation est un processus continu, nécessaire avec l’évolution de la pratique clinique et des technologies, qui permet de garder le système à jour, d’utiliser les nouvelles fonctionnalités et d’éliminer progressivement les problèmes. L’étude qui a été réalisée ici consiste en des entrevues semi-structurées ayant eu lieu entre janvier 2018 et octobre 2019, avec des gestionnaires, des spécialistes TI et des médecins qui ont participé à ce projet. 26 entrevues ont eu lieu, 16 d’entre elles étaient avec des physician builders et le reste avec différents gestionnaires et spécialistes TI. Des documents reliés au projet ont aussi été révisés.

Les constats tirés de ces entrevues sont très intéressants et sont des leçons à garder en tête par ceux qui pourraient voir l’implantation d’un tel système comme une opportunité de centraliser et standardiser les processus cliniques indépendamment de la volonté des cliniciens et des institutions locales. Je vous encourage à lire le texte complet, voici quelques points clés:

  • Les gestionnaires du projet national avaient initialement une visée de standardisation clinique « mur à mur », en programmant dans le système des contenus cliniques rigides et orientés davantage vers la capture de données standardisées plutôt que l’adaptation du logiciel aux besoins des cliniciens.
  • Les gestionnaires du projet étaient opposés à l’adaptation locale du contenu clinique, décrétant même un gel des changements au contenu du logiciel après l’implantation, rendant impossible par exemple la correction de problèmes manifestes pendant plusieurs mois.
  • Les cliniciens ont rapidement constaté que les flux de travail cliniques et les autres éléments cliniques étaient inutilisables, le fournisseur a aussi fortement encouragé les responsables du projet à mettre sur pied rapidement le programme de physician builders dans une optique de personnalisation du contenu localement.
  • Un programme de physician builders a finalement été mis en place sous la pression des cliniciens et du fournisseur, mais avec des contraintes rigides et sans financement, ceux-ci devaient développer un contenu standardisé à toute une spécialité médicale (ex: neurologie) à travers tous les hôpitaux sans tenir compte des particularités locales, devaient soumettre tout changement à un processus d’approbation formel et centralisé, et devaient être supervisés par des « mentors », qui se sont avéré davantage des adversaires visant à empêcher les changements que des collaborateurs. Le nombre de médecins autorisés à être builders était aussi limité.
  • Finalement, devant l’échec de ce programme limité, le programme a été élargi et il a été permis d’adapter le contenu localement pour tenir compte de la réalité de chaque hôpital, le programme de mentors a été aboli et le processus d’approbation a été assoupli. Il a été constaté que le nombre d’outils locaux développés était en augmentation suite à ces changements mais malheureusement la majorité des outils demeuraient peu utilisés pour une variété de raisons élaborées dans l’article.

La discussion est intéressante, elle parle des tensions entre la volonté de standardiser et les pratiques locales, de même que la tension entre le contrôle centralisé et l’autonomie locale, des sujets très d’actualité dans le système de santé. Les auteurs concluent avec des questions que les gens qui entreprennent des projets similaires devraient se poser quant au degré de standardisation souhaité et à l’autonomie à conférer aux cliniciens qui participent comme pilotes à de tels projets, éléments qui devraient être clarifiés avant de débuter le projet.

Revue systématique sur les compétences en informatique clinique

La dernière fois que j’ai parlé de compétences en informatique clinique, c’était avec la perspective du curriculum des programmes de pharmacie. Un article publié en septembre 2020 a effectué une revue systématique de la littérature sur les compétences en informatique clinique avec une vision plus générale.

La méthodologie de la revue est intéressante, bien qu’elle diverge un peu d’une vraie revue systématique de littérature scientifique. Les auteurs ont inclus non seulement une recherche de publications scientifiques sur les compétences et les tâches de professionnels en informatique clinique, mais également des descriptions de tâches pour des emplois en informatique clinique, des exigences de formation continue, ainsi que d’autres articles de revue qui formulaient des recommandations précises. Les publications de 2015 jusqu’au moment de la réalisation de la recherche (on assume en 2020 puisque les auteurs mentionnent 5 ans) ont été recherchées avec une méthode décrite dans l’article. 2 réviseurs ont effectuée la recherche et l’extraction des données et ont résolu leurs divergences par consensus.

12 688 publications ont été identifiées, 82 ont finalement été incluses. 25 étaient des sondages, 23 étaient des descriptions narratives, et les publications venaient principalement des États-Unis. Les compétences générales identifiées à partir des données extraites sont les suivantes:

  • La gestion des données
  • Les soins de santé
  • Les facteurs humaines
  • La gestion de l’information
  • Le leadership
  • La gestion de projets
  • La recherche
  • Le développement et l’évaluation de systèmes

Une liste très détaillée de chacun de ces points est disponible dans l’article. Les auteurs détaillent aussi des modèles de curriculums de formation existants, les niveau de formations existants, de même que les exigences décrites dans les offres d’emploi. Les auteurs soulignent également que l’informatique de pharmacie est un domaine ou la variabilité des compétences est très grande, dans certains cas requérant des connaissances spécialisées sur la prescription électronique et les systèmes de gestion et d’opérations.

Évaluation du système québécois de transmission des ordonnances électroniques en milieu communautaire

Cet article est paru en août 2019 et décrit une étude qui a eu lieu de juillet 2017 à juin 2018 pour évaluer le système centralisé de transmission des ordonnances électroniques de médicament en milieu communautaire du Québec. Spécifiquement, on parle de la transmission d’une ordonnance à partir d’un dossier médical électronique (DMÉ) d’une clinique médicale ou GMF vers ce répertoire centralisé, puis sa récupération dans un système de pharmacie communautaire en vue d’une délivrance au patient.

Le système québécois est différent d’autres systèmes de par le fait qu’il repose sur une banque de données centralisée vers laquelle les ordonnances sont envoyées par les DMÉ, puis de laquelle elles sont récupérées par les pharmacies communautaires. Ceci diffère de modèles point-à-point où les ordonnances sont envoyées d’un DMÉ directement vers une pharmacie communautaire. Pour la présente étude, les données d’utilisation du système durant la période d’étude ont été extraites. Une pharmacie communautaire a été visitée pour compiler les données sur les ordonnances exécutées durant une semaine, et des entrevues ont été menées avec des utilisateurs de 2 DMÉ et 5 logiciels de pharmacie.

Durant la période d’un an, 13% des ordonnances dispensées ont été rédigées électroniquement. Cependant, peu de cliniciens ont rédigé des ordonnances électroniques, soit entre 2400 et 3900 par mois sur un potentiel de plus de 10 000. En pharmacie, l’échantillon a démontré que 55% des ordonnances ont été rédigées à partir d’un DMÉ mais seulement 35% ont été transmises électroniquement. Seulement 2% des ordonnances ont été reçues électroniquement. En considérant uniquement les ordonnances envoyées électroniquement, seulement 16% des ordonnances électroniques ont été récupérées.

Les problèmes identifiés qui contribuaient à cet état de situation sont détaillées dans l’article, je vous présente ici un résumé mais je vous invite à lire le texte complet pour tous les détails:

Du côté des DMÉ:

  • La conception des ordonnances basées sur le DIN. Le DIN décrit un produit commercial d’un manufacturier précis, hors la plupart du temps le prescripteur veut prescrire une molécule et non un produit commercial précis. J’ai déjà parlé de ce sujet sur ce blogue. Les auteurs soulignent aussi que la banque de données des DIN était mal maintenue, comportant par exemple des produits discontinués.
  • L’absence d’aide à la décision lors de la prescription.
  • L’absence de fonctionnalités connexes à la prescription comme la possibilité de recevoir électroniquement des demandes de renouvellements de la part de pharmacies et d’y répondre directement à partir du DMÉ.
  • La notion qu’une copie papier de l’ordonnance devait être remise au patient, forçant ainsi l’impression d’une copie papier permettant ainsi au prescripteur de modifier la copie papier de sans ajuster la version électronique pour y correspondre.

Et du côté des pharmacies:

  • L’absence de notification de la disponibilité d’une ordonnance électronique.
  • Un mauvais design des logiciels forçant l’exécution d’une ordonnance électronique lors de sa consultation ou empêchant l’importation de plusieurs ordonnances.
  • La fonctionnalité d’auto-complétion des champs du logiciel de pharmacie à partir de l’ordonnance électronique était déficiente et générait des erreurs.
  • L’impossibilité de consulter la version « originale » de l’ordonnance électronique une fois exécutée, afin de vérifier que ce qui a été entré au dossier pharmacologique était adéquat en fonction de l’ordonnance reçue.

L’article est très détaillé et illustre bien les conséquences d’une inadéquation entre les besoins cliniques (et même les obligations légales, par exemple de pouvoir retrouver l’original d’une ordonnance) et les fonctions offertes par les systèmes informatiques.