Healthcare conversations often separate the intervention from its implementation. First we decide what is clinically desirable; later someone else works out how to introduce it. That separation is convenient, but it can make good ideas fail for predictable reasons.
An intervention does not enter an empty space. It enters a service with existing routines, pressures, professional identities, information systems and informal workarounds. Implementation belongs in the clinical conversation because those conditions affect safety and effectiveness.
“Does it work?” is only the first question
Evidence may show that a treatment, pathway or technology can improve an outcome. The next questions are where, for whom and under what conditions. A tool that performs well in a controlled setting may create delay or confusion when placed inside a different workflow.
This is not an argument against innovation. It is an argument for taking its real-world context seriously.
Implementation is not the administrative phase after the important decision. It is part of the decision.
Map the work before changing it
Process maps are useful, but the formal process is not always the real process. Observation and conversation reveal the adaptations that keep a service functioning: who checks an incomplete referral, who notices a result has not returned, which spreadsheet compensates for a limitation elsewhere.
Removing a workaround without understanding why it exists can remove a hidden safety mechanism. Before redesigning work, teams need to see both the official pathway and the lived pathway.
Make ownership explicit
New interventions often add tasks without removing old ones. A clinician is expected to review another alert, an administrator enters the same data twice or a new dashboard exists without a clear owner. Adoption then appears poor when the deeper problem is role design.
Every change should identify who initiates it, who responds, what happens outside normal conditions and how completion is confirmed. If no one can explain the end-to-end responsibility, the implementation is not ready.
Trust is a technical requirement
People need to understand the limits of a new system, especially when it influences clinical decisions. Overstating capability may accelerate initial enthusiasm but damage long-term trust when the first edge case appears.
Transparent communication supports appropriate reliance. Users should know what the tool does, what it does not do, where the information comes from and how to challenge an output. In healthcare, scepticism can be a safety resource when a system is designed to receive it.
Pilot for learning, not theatre
A pilot should test assumptions. It should include enough diversity to expose difficult cases and enough feedback to change the design. Success cannot be defined only as completion of the pilot or a positive launch event.
Useful measures may include time, error, workload, equity, adoption and unintended consequences. Qualitative feedback matters too: where did users hesitate, what did they misunderstand and what work moved elsewhere?
Implementation continues after launch
Services change. Staff rotate, demand shifts and software is updated. A process that worked at launch can degrade when training fades or responsibilities move. Implementation therefore needs maintenance: review, reinforcement, data and a route for improvement.
Clinicians should be involved because they understand the decisions the change is meant to support and the risks it may introduce. Operational colleagues should be involved because they understand the system in which those decisions occur. Patients should be involved because they experience consequences that may not be visible from inside the service.
Bringing implementation into the clinical conversation does not slow good innovation. It gives it a better chance of becoming safe, useful and durable.
Part of My Side of the Stethoscope.