Compétences en informatique clinique pour les étudiants en pharmacie

Les programmes de formation en pharmacie contiennent certains éléments d’informatique clinique. Il existe des curriculums de formation créés par plusieurs associations qui peuvent être utilisés par les facultés de pharmacie pour intégrer l’informatique clinique à leurs cours. J’ai déjà parlé de Partners in E, un programme américain, ainsi que d’un programme canadien similaire. Mon dernier accès à la documentation de Partners in E remonte à l’an dernier, et à ce moment, la dernière mise à jour datait de 2016. Depuis, l’accès aux modules ne semble plus fonctionner, je ne sais pas ce qui se passe. Ce programme est-il encore maintenu ? Du côté canadien, le programme a déménagé à l’adresse http://elearnhcp.ca et s’est développé, même si ça demeure un cours d’introduction. L’accès est maintenant ouvert à tous sur simple inscription en ligne.

Un article paru en mars dans le American Journal of Pharmaceutical Education, et disponible en texte complet sur PubMed Central, discute du contenu des formations en informatique clinique destinées aux étudiants en pharmacie. Il s’agit d’une démarche menée par l‘American Association of Colleges of Pharmacy, qui avait pour objectif de réviser la liste de compétences à inclure dans les programmes de premier cycle en pharmacie.

Un groupe de l’organisation a établi une liste initiale de compétences sur la base d’une revue de littérature et de leur expérience personnelle. Ensuite, deux rondes de focus groups d’une durée d’une heure ont été menées avec des participants recrutés parmi l’ensemble des membres de l’AACP. La liste de compétences a été ajustée suite à ces discussions.

8 personnes ont participé aux focus groups. Ça me semble peu, il aurait été intéressant d’avoir une idée de combien de personnes étaient éligibles, et combien ont été invitées. Les commentaires des participants étaient que la liste de compétences était trop grande et contenait trop d’éléments rudimentaires ou non spécifiques à la pharmacie. Les participants ont discuté de la manière d’intégrer l’informatique clinique dans la formation universitaire, par exemple dans un cours spécifique ou à travers plusieurs cours.

Les compétences que les participants ont identifiées comme prioritaires étaient:

  • Les standards d’interopérabilité
  • L’informatique biomédicale (je ne suis moi-même pas certain de ce que c’est…)
  • Les technologies émergentes
  • Les enjeux légaux et réglementaires
  • Les concepts de sécurité de la prescription électronique

Les auteurs présentent les compétences qu’ils ont identifiées sous la forme de schémas et tableaux. Je dois dire que je suis d’accord avec le commentaire que les compétences ciblées sont très éparpillées et certaines sont très génériques et d’autres spécifiques mais non reliées à la pharmacie, comme la gestion de courriels, les protocoles de communication de l’internet en général, les mots de passe… Le contenu le plus intéressant de l’article est un tableau détaillé des compétences spécifiques à la pharmacie. Le lien est difficile à trouver dans l’article donc je le donne ici:
https://files.acrobat.com/a/preview/57009581-eccf-4868-8526-def02eff200b . C’est un très gros tableau qui liste une multitude de compétences qui ne sont pas toutes d’utilité égale, mais je trouve quand même utile pour une personne qui veut travailler en informatique de pharmacie de lire l’ensemble du tableau et de s’assurer d’au moins connaître chacun des points listés et de pouvoir en discuter.

Erreurs de prescription électronique en clinique externe de pédiatrie

L’Académie Américaine de Pédiatrie (AAP) a émis des lignes directrices sur les fonctionnalités de prescription électronique qui sont nécessaires pour sécuriser ce processus en pédiatrie. Je n’ai pas parlé de ces lignes directrices sur ce blogue car elles datent de 2013 et elles se centrent surtout sur la prescription faite en clinique externe et destinée aux pharmacies communautaires. En 2015, je mentionnais un article espagnol qui incluait ces lignes directrices dans une revue plus générale des technologies de prescription et d’administration destinées à la pédiatrie.

Un nouvel article paru au début du mois d’avril s’est penché sur les erreurs de prescription électronique en pédiatrie, et les a examinées en regard des critères de l’AAP. L’étude a eu lieu dans trois cliniques de médecine de famille ou de pédiatrie dans 3 organisations de santé américaines étant dotées d’un dossier électronique unique. Les logiciels précis sont nommés dans l’article. Les ordonnances incluses était les ordonnances de médicaments destinées aux pharmacies communautaires. Toutes les ordonnances émises pour des patients pédiatriques durant une période de 1 à 2 mois, c’est-à-dire jusqu’à l’obtention de 400 ordonnances ou plus par clinique, étaient incluses. Chacun des trois logiciels a été évalué pour sa conformité aux lignes directrices de l’AAP sur une échelle à trois niveaux; le tableau de cette conformité est présenté dans l’article. Les ordonnances ont ensuite été revues par un panel composé de pharmaciens et médecins qui ont déterminé la présence d’erreurs en fonction de critères pré-établis.

Les trois logiciels en place dans les cliniques rencontraient les critères de l’AAP à 21-47%. Les cliniques 1, 2 et 3 ont fourni respectivement 477, 408 et 633 ordonnances, avec un taux d’erreur de 13,2, 8,8 et 6,6%. Il est intéressant de noter que la classe des antimicrobiens était la plus prescrite et comptait pour 24 à 33% des erreurs. Selon les auteurs, 83% des erreurs auraient pu être prévenues si la conformité aux critères de l’AAP avait été complète.

L’article me semble intéressant car il montre que des logiciels pourtant très populaires et matures ne sont pas parfaitement conformes à des principes de sécurité de prescription pédiatrique relativement simples et connues depuis plusieurs années. Pensons notamment à la documentation du poids en kg uniquement ou à l’affichage du volume correspondant à une dose pour une prescription d’un médicament liquide. Il semble que la plupart des erreurs seraient évitables avec une meilleure conformité à ces critères. Je trouve cependant dommage que l’article ne détaille pas les erreurs ni leur répartition par catégorie; cela aurait permis de voir si les lacunes se situent davantage au niveau des critères simples (ex: volume en fonction de la dose, présence de dose, voie, fréquence et quantité, etc.) ou de critères plus complexes (ex: dose en fonction de l’indication).

Prototype de prescription électronique incluant l’indication

En juillet 2018, je vous parlais d’un article qui discutait de l’ajout de l’indication dans les prescriptions électroniques. Une des recommandations était de débuter le processus de prescription par la sélection de l’indication, plutôt que de documenter l’indication en texte libre après la rédaction de l’ordonnance. Un avantage de cette façon de faire est que la sélection des médicaments pour l’ordonnance peut être ajustée en fonction de l’indication sélectionnée; théoriquement, les erreurs de sélection de médicament pourraient être diminuées avec cette façon de faire.

Le même groupe revient maintenant avec une étude de simulation portant sur un prototype de logiciel de prescription incorporant cette façon de faire, en comparaison avec deux logiciels commerciaux populaires aux États-Unis.

Le prototype conçu par les auteurs permettait de débuter la prescription par la sélection d’une indication puis de choisir de médicament, ou de choisir le médicament puis l’indication. Les choix de médicaments affichés pour les indications des scénarios testés ont été élaborées à partir de lignes directrices, des indications officielles des produits, et de particularités d’assurance. Les choix de dose et de posologie par défaut reflétaient également l’indication. De plus, les caractéristiques du patient (allergie, insuffisance rénale, poids) se reflétaient dans les choix proposés.

Les participants aux scénarios de test ont été recrutés parmi les cliniciens d’un centre d’affiliation d’un des auteurs. 8 scénarios cliniques ont été élaborés, incluant certaines difficultés au niveau de la prescription comme des allergies, la présence de médicaments look-alike, sound-alike (LASA) dans les choix, etc. Les participants complétaient 4 scénarios avec le prototype et 4 scénarios avec leur logiciel habituel. 17 médecins, 13 résidents et 2 assistants médecins ont complété 256 scénarios. 20 des 32 participants ont utilisé un logiciel commercial et le reste ont utilisé un autre.

Le temps de complétion d’un scénario était plus rapide avec le prototype (premier logiciel 3,37 ± 1,90 minutes, deuxième logiciel 2,93 ± 1,52 minutes, prototype 1,78 ± 1,17 minutes). 28,8% des participants ont utilisé une référence externe pour prescrire avec le prototype comparativement à 58,8% avec les logiciels commerciaux, p < 0,001. Enfin, 5,5% des ordonnances avec le prototype comportaient une erreur contre 29,7% avec les logiciels commerciaux, p < 0,001. Le taux d’erreur liées aux médicaments LASA n’était pas significativement différent entre les groupes.

Je trouve l’étude intéressante car elle démontre l’avantage d’inclure l’indication dans les prescriptions, pas seulement du point de vue du travail du pharmacien, mais bien d’un point de vue du workflow clinique du médecin prescripteur. Elle démontre un avantage de sécurisation du processus, en plus d’être plus rapide. Néanmoins, comme les auteurs le soulignent dans la discussion, ce genre de fonctionnalité demande une banque de données fournissant toute l’information nécessaire en arrière-plan. Les auteurs mentionnent comment les fournisseurs de logiciels de prescription électronique et d’aide à la décision sont peu enclins à offrir des recommandations de traitement de cette manière par crainte de répercussions légales. Si ce genre de contenu ne peut être acquis commercialement, on peut imaginer qu’il soit nécessaire de le développer localement, ce qui représente un volume de travail très important. L’idée est donc bonne, mais sa mise en place risque d’être assez difficile.