Module 10 · 95 min
Implementing & Scaling AI in Healthcare
From Approved Use Case to Routine Care. Workflow redesign, pilot design, change management and adoption, stakeholder alignment, integration, go-live gates, monitoring ownership, incident and change management, scaling, and decommissioning as part of the learning loop. The central question: how do we make the chosen AI work safely in practice, and scale it?
- Treat implementation as a change to how work is done, and hold the distinction between a product going live, a service changing, and a benefit actually being realised.
- Map current and future state through the chain of trigger, AI output, human decision, action, and documentation or feedback — and locate the task changes, handoffs, decision rights and new bottlenecks that chain creates.
- Name the operational owner and the exception path for every workflow you propose, and recognise an unowned step as the most common reason a technically sound deployment produces nothing.
- Design a pilot as an instrument for resolving a named uncertainty, with a baseline, a defined population, an explicit exclusion list, and predefined success, adapt, stop and scale criteria attached to a decision date.
- Use staged evaluation modes — offline, shadow or silent running before live influence — where the risk and the uncertainty justify them, without assuming every use case needs the same sequence.
- Read adoption behaviour diagnostically: overrides, edits, workarounds and non-use are information about workflow fit, value and trust before they are anything else.
- Measure adoption with metrics that mean something — eligible use, active use, completion, override and edit burden, abandonment, user-reported burden — instead of logins and licences.
- Assemble a go-live readiness board across workflow, people, technology and integration, data, operations and support, evidence and assurance, governance conditions and benefits baseline, and tell a complete checklist apart from an operating model that can respond.
- Run one operating dashboard covering benefit, workflow and adoption, clinical quality where relevant, and safety and technical signals, with a named owner, a cadence and an action threshold on every metric.
- Distinguish a supplier version change from intentional local adaptation, and hold a review trigger for each.
- Separate scale-up, spread and sustainability, and apply a compact local readiness check to each new context rather than copying a configuration.
- Use scale gates, rollout waves and shared capability to grow the capability rather than the pilot — and treat decommissioning as a legitimate result of measuring value.
Implementation is workflow change, not a technology install
There is a moment in most healthcare AI programmes when the system works, the integration is live, the training slides have been delivered — and nothing has changed. The reports still take as long. The deterioration alerts arrive, and the same ward round happens at the same time in the same way. The value in the business case has not appeared, and no single person can say which step failed.
Nothing failed technically. What was funded was a value mechanism: a specific change in how a decision is made, how work is distributed, or how capacity is used. What was delivered was software. Between the two sits the work of redesign, adoption and operation, and that work is where the value in Module 8's business case is either created or lost.
This is the optimistic reading, not a warning. It means the return is largely in the organisation's own hands. Purchasing decisions are constrained by what suppliers offer; workflow, staffing, decision rights and follow-through are yours. Teams that treat implementation as the product — rather than as the phase after the product — are the ones that convert a working model into shorter waits, earlier intervention or returned clinical time.
What arrives from Modules 8 and 9
Modules 8 and 9 have done their work. Strategy selected the bet and argued the investment; regulation and governance established which rules apply, what has to be produced and who is entitled to say yes. What arrives at this module is an approved or conditionally approved use case with a value hypothesis attached to it. Nothing in that package has yet changed a single clinical or operational decision. That is the whole of Module 10.
Three events, routinely confused
Product go-live
The system is available in the live environment, authenticated, integrated and supported. A technical milestone, verifiable in an afternoon.
Common mistake: Reporting it as delivery. Go-live tells you the tool can be used; it says nothing about whether the work has changed or anyone benefits.
Service change
The work is genuinely different: a step has moved, a decision is made by someone else or at a different time, a handoff has been removed, a role has changed. Observable in the workflow, not in the software.
Common mistake: Assuming it follows automatically from go-live. Without a redesigned workflow, staff absorb the tool as extra work on top of the old process, which is exactly how a productivity case turns into a burden complaint.
Benefit realisation
The value hypothesis has measurably occurred against the baseline the business case used — time released and redeployed, waits shortened, a decision made earlier, a harm avoided.
Common mistake: Treating released minutes as realised value. Module 8 made the point in cash terms; operationally it means that unless the released capacity is deliberately directed somewhere, it disperses and the benefit is unverifiable.
The value chain, link by link
One way to keep the three events distinct is to write the value mechanism as a chain and ask which link the implementation is actually changing. The chain below is generic; the discipline is that every project should be able to complete it in one sentence per link.
1. Trigger
What event causes the AI system to produce something? A study arriving, a consultation starting, an admission, a scheduled batch run.
2. Output
What does it produce, in what form, and where does it appear? A draft, a score, a ranked list, a flag inside an existing screen.
3. Human decision
Who reads it, with what authority and how much time? A decision nobody has the standing or the minutes to take is not a decision.
4. Action
What is done differently as a result? If the honest answer is 'the same thing, slightly better informed', the value mechanism is weak and should be revisited before rollout.
5. Consequence and feedback
What is recorded, who sees the result, and how does the organisation learn whether the action helped? Without this link, adoption cannot be improved and benefit cannot be shown.
Carried forward from Module 8
Module 8 produced the value hypothesis, the baseline expectation and the total cost of ownership. Implementation is where those numbers are either realised or quietly abandoned. Keep the same value statement, the same KPI and the same baseline the business case used, or benefits realisation becomes an argument about definitions.
Two implementations of the same model can differ more than two different models. That is the leadership opportunity in this module: the variable with the largest effect on realised value is usually not which system was bought, but how carefully the surrounding work was redesigned and run.
How to read the structures in this module
The readiness board, the dashboard structure, the local readiness check and the scale gates in this module are teaching structures for organising leadership decisions. They summarise practice described in the cited sources; they are not validated instruments, and completing one is not evidence that an implementation will succeed.
Sources & evidence · 7 sources
This module cites public or consensus guidance, scholarly literature, technical documentation.
Content reviewed: September 2026. Publication dates of the individual sources are shown in each citation.
Vasey B, Nagendran M, Campbell B, et al. Reporting guideline for the early-stage clinical evaluation of decision support systems driven by artificial intelligence: DECIDE-AI. BMJ. 2022;377:e070904.
A reporting guideline for the early live clinical evaluation stage, with emphasis on clinical utility, safety and human factors, and on preparing for larger evaluation. It tells you what should be described, not how to design your pilot, and complete reporting does not make a study large, controlled or applicable to your population.
Open sourceGreenhalgh T, Wherton J, Papoutsi C, et al. Beyond adoption: a new framework for theorizing and evaluating nonadoption, abandonment, and challenges to the scale-up, spread, and sustainability of health and care technologies. J Med Internet Res. 2017;19(11):e367.
The NASSS framework: seven domains of complexity used to explain why technologies are not adopted, are abandoned, or fail to scale, spread and sustain. A lens for structured reflection and conversation. It is not a scoring instrument or a predictive model, and complexity indicates where to plan differently rather than that a project will fail.
Open sourceA practical framework for appropriate implementation and review of artificial intelligence (FAIR-AI) in healthcare. npj Digital Medicine. 2025;8:514.
A practical account of pre-implementation evaluation and post-implementation monitoring, including local review and ongoing surveillance responsibilities. It describes an approach one group considers appropriate; it does not establish that following it improves outcomes.
Open sourceClinical trials informed framework for real world clinical implementation and deployment of artificial intelligence applications. npj Digital Medicine. 2025;8:107.
An implementation and deployment roadmap perspective drawing on clinical-trial practice, covering staged evaluation and readiness for real-world use. A proposed framework rather than a validated instrument, and not evidence about how often such deployments succeed.
Open sourceNHS England Digital. AI Knowledge Repository — Spread and scale AI. Accessed 28 August 2026.
A practitioner resource hub on spreading and scaling AI in a health system, including adoption, local readiness and sustainability considerations. Practical guidance shaped by one health system's context; treat the specifics as transferable prompts rather than as requirements elsewhere.
Open sourceNHS England Digital. A buyer's guide to AI in health and care. Accessed 28 August 2026.
Covers whether a product will work in practice, supporting staff and service users, and managing and maintaining a product after adoption — the operational questions that sit between procurement and routine use. Guidance, not a standard, and it does not assess any individual product.
Open sourceWHO Regional Office for Europe. Artificial intelligence is reshaping health systems: state of readiness across the WHO European Region. 19 November 2025.
System-level context on readiness across the Region: workforce capability, stakeholder engagement, governance and data readiness, and reported adoption barriers. Useful for framing the conditions implementation depends on; it is not evidence that any particular implementation approach works.
Open source
Capstone Board Pack
Add what you just learned to your own strategy document while it is fresh.