In recent years, the role of community pharmacists in Canada has expanded considerably.
Beyond dispensing medications, they now assess patients, adjust therapies, and prescribe treatments for certain conditions. They play an active role in primary care and now hold a central place in public health: in 2023–2024, most Canadians adults who received a flu vaccine were vaccinated in a pharmacy.
This increased autonomy comes with a very real challenge: making more clinical decisions, of greater complexity, within a limited amount of time. Hence the growing need for digital tools suited to this new reality.
This raises an important question: how can we turn clinical recommendations into reliable digital tools that are integrated into the clinical workflow?
The answer lies in close collaboration between pharmacists and developers.
Let’s illustrate this with a fictional case inspired by a feature in RxVigilance.
Ms. Tremblay, age 74
Medical conditions: heart failure, COPD, depression
Current treatment:
Allergy: penicillin (skin rash)
New prescription: clarithromycin, 500 mg twice daily for 5 days for an acute exacerbation of COPD
When the pharmacist reviews the patient profile in RxVigilance, an alert related to QT interval prolongation (Figure 1) is generated by the clinical algorithm.
Figure 1. Example of a QT interval prolongation risk alert in RxVigilance (shown for illustrative purposes and inspired by a fictional clinical case).
In this situation, the pharmacist must determine the best course of action: adjust the therapy, increase monitoring, or contact the prescriber.
In addition to generating the alert, RxVigilance supports the pharmacist by directing them to a QT prolongation risk assessment tool adapted from a clinical resource published by the Regroupement de pharmaciens experts en cardiologie of the Association des pharmaciens des établissements de santé du Québec (A.P.E.S.) The original A.P.E.S. resource is available in French only. The English version of the adapted tool was translated by Vigilance Santé. A.P.E.S. did not participate in the translation process and, therefore, cannot be held responsible for any inacurracies or errors that may result from this translation.
Originally, this resource was presented as a structured clinical document. Like many tools developed by experts, it already contained all the logic needed to assess risk and guide clinical action.
The question then became: what if this logic could be integrated directly into the pharmacist’s workflow?
Instead of consulting an external document and manually interpreting the criteria, the idea emerged to transform this static tool into a dynamic one. The algorithm could then identify relevant risk factors, calculate a score, and suggest an appropriate course of action in just a few steps.
All of this happens within seconds in the application, but behind that simplicity lies complex development work.
In any clinical tool development project, the starting point is a structured clinical logic: defined criteria, a hierarchy of information, and, where applicable, a proposed course of action. Before writing a single line of code, that logic must be made explicit and actionable:
The pharmacist formalizes the reasoning. The developer translates it into structured rules.
At the start of a project, I need to put the clinical logic into writing: I lay out the steps, identify the risk factors, define the exclusions, and specify the expected course of action. In other words, I translate clinical reasoning into pseudocode: rules that are understandable, testable, and reproducible.
At this stage, I work alongside the pharmacist. I ask questions and validate decisions to avoid anything that could become unclear once implemented: exceptions, grey areas, definitions, and dependencies between fields. The goal is not to make things more complicated, but to make the logic more robust and to produce a clear, solid implementation roadmap that also covers test cases.
The discussion quickly turns to concrete user experience issues: the order of fields, the clarity of labels, and how to present the recommended course of action. The challenge is to strike the right balance: preserving clinical rigor without compromising the usability of the tool in the reality of day-to-day work at the pharmacy counter.
At this stage, the objective is simple: the tool must support the analysis without creating unnecessary friction. An ambiguous label or poorly placed key information is enough to create friction.
Whatever the clinical tool being developed, the prototyping stage is always revealing: this is where theory meets practice.
When I test an initial version, I go through typical cases to make sure the algorithm behaves as expected and respects the established criteria. At the same time, I ask myself whether the user would immediately understand what is being presented, whether it is a question to answer or a recommendation generated by the system, and how that information affects the clinical decision. Even when the logic is sound, friction points can still affect workflow: hesitation, backtracking, ambiguous labels, or an information hierarchy that fails to highlight the key elements.
On my end, the priority is to ensure the logic is solid: consistent rules, robust calculations, and anticipated edge cases. But a tool can be technically impeccable without necessarily being intuitive for the clinician. We often talk about agility in solution development, but that agility must also be reflected in collaboration between colleagues.
Clinical observations lead to technical adjustments, which may in turn require renewed clinical validation. We test, discuss, and refine until we arrive at a tool that is rigorous, clear, and usable in practice.
Initial testing almost always reveals adjustments that need to be made. From a clinical perspective, it can bring to light scenarios or combinations that were not fully anticipated during the original design—for example, a rule that needs to apply differently depending on the context, a clinical combination that requires a weighting to be revisited, or an exclusion criterion that had gone unnoticed. At the same time, these tests help identify interface issues: a label may be confusing, crucial information may be less visible or harder to spot than it should be, and a step that seems logical on paper may prove redundant in the real workflow.
From my side, every change, even one that appears minor, can have an impact on the underlying structure. Adjustments must be made without weakening anything, usability must be simplified without sacrificing precision, and then the full set of test cases must be run again to confirm that the results remain consistent.
The digital tool structures the analysis and helps guide the course of action. It does not replace clinical judgment, clinical guidelines, or official product monographs.
In other words, its purpose is to:
The balance remains delicate: oversimplify, and you betray the complexity of real-life situations; overcomplicate, and you undermine usability.
Translating clinical reasoning into code is not simply a matter of “digitizing” a recommendation. It means making that recommendation usable, at the right time, by the right person, in the reality of practice. That is why, at Vigilance Santé, collaboration between clinical expertise and development is at the heart of our pharmacotherapy tools.
As pharmacists’ autonomy continues to expand, this co-construction is not a luxury. It is what allows us to create tools that are relevant, reliable, and sustainable to support the level of decision-making required every day in practice.
What about you? What kind of tool would save you time without compromising your clinical judgment?