Au cours des dernières années, le rôle des pharmaciens communautaires au Canada s’est considérablement élargi.
Au-delà de la distribution des médicaments, ils évaluent des patients, ajustent des thérapies et prescrivent des traitements pour certaines conditions. Ils participent activement aux soins primaires et jouent désormais un rôle central en santé publique : en 2023-2024, la majorité des adultes canadiens qui ont reçu un vaccin contre la grippe l’ont fait en pharmacie.
Cette autonomie accrue s’accompagne d’un défi bien concret : prendre davantage de décisions cliniques, plus complexes, dans un temps limité. D’où le besoin grandissant d’outils numériques adaptés à cette nouvelle réalité.
La question qui se pose alors est la suivante : comment pouvons-nous transformer des recommandations cliniques en des outils numériques fiables, intégrés au flux réel de la pratique?
La réponse repose sur la collaboration étroite entre pharmacien et développeur.
Illustrons notre propos par un cas fictif inspiré d’une fonctionnalité offerte dans RxVigilance.
Mme Tremblay, 74 ans
Conditions médicales : insuffisance cardiaque, MPOC, dépression
Traitement actuel :
Allergie : pénicilline (éruption cutanée)
Nouvelle ordonnance : clarithromycine, 500 mg BID x 5 jours pour une EAMPOC
Lorsque le pharmacien analyse le dossier de la patiente dans RxVigilance, une alerte liée à l’intervalle QT (Figure I) est générée par l’algorithme clinique.
Figure 1. Exemple d’alerte de risque d’allongement de l’intervalle QT dans RxVigilance (présentée à titre illustratif et inspirée d’un cas clinique fictif).
Dans cette situation, il faut déterminer la meilleure conduite : ajuster la thérapie, renforcer la surveillance ou communiquer avec le prescripteur?
En plus de l’alerte, RxVigilance soutient le pharmacien en l’orientant vers un outil d’évaluation du risque d’allongement de l’intervalle QT (Figure 1, en bleu pâle), adapté à partir d’une ressource clinique publiée par le Regroupement de pharmaciens experts en cardiologie de l’Association des pharmaciens des établissements de santé du Québec (A.P.E.S.).
À l’origine, cette ressource se présentait sous la forme d’un document clinique structuré. Comme bien des outils produits par des experts, elle contenait déjà toute la logique nécessaire pour évaluer le risque et orienter la conduite.
La question s’est alors posée : et si cette logique pouvait être intégrée directement dans le flux de travail du pharmacien?
Plutôt que de consulter un document externe et d’interpréter les critères manuellement, l’idée a émergé de transformer cet outil statique en un outil dynamique. L’algorithme identifie alors les facteurs pertinents, calcule un score et suggère une conduite en quelques étapes.
Le tout s’effectue en quelques secondes dans l’application, mais derrière cette simplicité se cache un travail complexe de développement.
Dans tout projet de développement d’outil clinique, le point de départ est une logique structurée : des critères définis, une hiérarchisation de l’information et, selon le cas, une conduite proposée. Avant d’écrire une seule ligne de code, il faut rendre cette logique explicite et opérable :
Le pharmacien formalise son raisonnement. Le développeur le traduit en règles structurées.
Ainsi, en début de projet, je dois mettre par écrit la logique clinique : je détaille les étapes, j’identifie les facteurs de risque, je définis les exclusions, et je précise la conduite attendue. Autrement dit, je traduis le raisonnement clinique en pseudo-code : des règles compréhensibles, testables et reproductibles.
Durant cette étape, j’accompagne la pharmacienne. Je pose des questions et je valide les choix pour éviter ce qui risque de devenir flou une fois implémenté : exceptions, zones grises, définitions et dépendances entre champs. Le but n’est pas de compliquer les choses, mais de sécuriser la logique et de produire une ligne directrice d’implantation claire, robuste, et qui couvre les cas de test.
La discussion s’engage rapidement sur des enjeux concrets d’expérience utilisateur : ordre des champs, clarté des libellés, et manière de présenter la conduite recommandée. L’enjeu est de trouver le juste équilibre : préserver la rigueur clinique, sans compromettre l’utilisabilité de l’outil dans la réalité du travail au comptoir.
À cette étape, l’objectif est simple : que l’outil soutienne l’analyse sans créer de friction inutile. Un libellé ambigu ou une information clé mal placée suffit à créer de la friction.
Quel que soit l’outil clinique développé, l’étape de réalisation du prototype est révélatrice : c’est là que la théorie rencontre le terrain.
Lorsque je teste une première version, je parcours des cas types pour m’assurer que l’algorithme se comporte comme prévu et qu’il respecte les critères établis. En parallèle, je me demande si l’utilisateur comprendrait immédiatement ce qui est présenté, que ce soit une question à laquelle répondre ou une recommandation générée par le système, et comment cette information influence la décision clinique. Même si la logique est correcte, des points de friction peuvent nuire à la fluidité : hésitations, retours en arrière, libellés ambigus ou hiérarchisation de l’information qui ne met pas en évidence les éléments clés.
De mon côté, la priorité est d’assurer une logique irréprochable : des règles cohérentes, des calculs robustes et des cas limites anticipés. Mais un outil peut être techniquement impeccable sans pour autant être intuitif pour le clinicien. On parle souvent d’agilité dans le développement de solutions, mais elle doit aussi se vivre dans la collaboration entre collègues.
Les observations cliniques mènent à des ajustements techniques, qui requièrent parfois une nouvelle validation clinique. On teste, on discute et on affine, jusqu’à obtenir un outil rigoureux, clair et utilisable sur le terrain.
Les premiers tests révèlent presque toujours des ajustements à apporter. Sur le plan clinique, ils peuvent mettre en lumière des scénarios ou des combinaisons qui n’avaient pas été pleinement anticipés lors de la conception initiale, par exemple une règle qui doit s’appliquer différemment selon le contexte, une combinaison clinique qui oblige à revoir une pondération, ou encore une condition d’exclusion passée inaperçue. En parallèle, ces essais permettent de repérer des enjeux d’interface : un libellé peut prêter à confusion, une information cruciale peut être moins visible ou plus difficile à repérer qu’elle ne devrait l’être, et une étape pourtant logique sur papier peut se révéler redondante dans le flux réel de travail.
De mon côté, chaque modification, même minime en apparence, peut avoir un impact sur la structure sous-jacente. Il faut faire des réglages sans rien fragiliser, simplifier l’utilisation sans perdre en précision, puis relancer l’ensemble des cas de test pour confirmer que les résultats demeurent conformes.
L’outil numérique structure l’analyse et oriente la conduite. Il ne remplace ni le jugement clinique, ni les lignes directrices, ni les monographies officielles.
Autrement dit, il vise à :
Transformer un raisonnement clinique en code ne consiste pas simplement à « numériser » une recommandation. C’est la rendre applicable, au bon moment, par la bonne personne, dans la réalité du terrain. C’est pourquoi, chez Vigilance Santé, nous plaçons la collaboration entre expertise clinique et développement au cœur de nos outils de pharmacothérapie.
Alors que l’autonomie des pharmaciens continue de s’élargir, cette co-construction n’est pas un luxe : elle permet de créer des outils pertinents, fiables et pérennes, à la hauteur des décisions que vous avez à prendre chaque jour.
Et vous? Quel type d’outil vous ferait réellement gagner du temps sans jamais compromettre votre jugement clinique?