Topic 8.0 — Phasing in Innovation

In one sentence: Introduce innovation as a deliberate, staged journey — small, evidenced, and safe first, then spread with confidence — rather than as a single leap or a graveyard of pilots that never scale.

Why this matters in health and care#

Health and care sit on a knife-edge between two failures. Move too slowly, and patients are denied treatments and tools that demonstrably work, while staff burn out on processes that better technology could ease. Move too fast, and you risk patient safety, waste public money, entrench inequity, and breach statutory duties around clinical safety and data protection.

The NHS has a well-documented weakness at the second stage of innovation: not invention, but adoption and spread. The King's Fund and others describe a system rich in pilots and poor at scaling them — a pattern nicknamed "pilotitis", where innovations are trialled endlessly in one site and never rolled out. Every stalled pilot represents money spent, staff goodwill consumed, and a benefit never realized at population scale.

For a senior leader, phasing innovation well is therefore both a safety discipline and a value discipline. You are accountable for introducing change in a way that generates evidence, protects patients, satisfies regulators, and reaches enough people to justify the investment. This topic is about doing that on purpose rather than by accident. It connects tightly to change management (see Topic 8.1 — Change Management), which handles the human side of the same journey.

Core concepts#

Diffusion of innovations. Everett Rogers' classic model describes how a new idea spreads through a population over time, following an S-shaped adoption curve across five groups: innovators, early adopters, the early majority, the late majority, and laggards. Rogers identified five attributes that predict how fast something spreads: relative advantage, compatibility with existing practice, simplicity, trialability, and observability of results. If your innovation scores poorly on these, expect slow adoption regardless of how good the underlying idea is.

Pilots, proofs-of-concept, and "pilotitis". A pilot is a time-boxed, small-scale test designed to learn, not to deploy. The pathology of pilotitis arises when piloting becomes an end in itself — when there is no pre-agreed route from a successful pilot to routine adoption, and no owner accountable for scaling. A good pilot is designed from the outset with its exit in mind: what decision it will inform, what evidence it must produce, and who acts on that evidence.

Spread and scale. These are different problems. Spread is horizontal — the same innovation adopted by more sites. Scale is vertical — the depth of adoption and the infrastructure, funding, and workforce change needed to sustain it. NHS improvement bodies distinguish the two deliberately, because an innovation can spread thinly to many sites without ever scaling into embedded, funded, business-as-usual practice.

Evidence generation alongside adoption. In digital health you rarely have complete evidence before you start; you build it as you go. Real-world evaluation — studying an innovation in routine conditions rather than a controlled trial — lets you adopt and learn simultaneously, provided you design the evaluation up front rather than bolting it on afterwards.

The regulatory and assurance stack. In the UK, three overlapping regimes govern digital health innovation. The MHRA (Medicines and Healthcare products Regulatory Agency) regulates software that meets the legal definition of a medical device, including Software as a Medical Device (SaMD). NICE publishes the Evidence Standards Framework (ESF) for digital health technologies, setting out the level of evidence expected for a technology's function and financial risk. DTAC (the Digital Technology Assessment Criteria) is the NHS's baseline for suppliers, covering clinical safety (DCB0129/DCB0160), data protection, technical security, interoperability, and usability. These are not optional extras; they are the entry conditions for safe adoption.

Best practices#

1. Start from the problem, not the product. Anchor every innovation to a clearly stated clinical, operational, or population-health problem, with a baseline measure of how bad it is today. Technologies chosen because they are exciting, or because a supplier is persuasive, tend to fail Rogers' "relative advantage" test in practice. Make the problem statement the thing you protect when the solution changes.

2. Design the pilot with its exit already decided. Before a pilot starts, write down the decision it will inform, the success criteria, the evidence it must produce, the funding route if it succeeds, and the named owner who will act. If you cannot answer "what happens the day this pilot succeeds?", you are building pilotitis. A pilot without a scaling plan is a hobby.

3. Phase by cohort and by geography. Roll out in deliberate waves — an alpha cohort of willing early adopters, then a private beta of a few representative sites, then progressively wider geography — with a go/no-go gate between each wave. Early cohorts should be chosen for their appetite and their ability to give honest feedback, not for being easy. Each wave de-risks the next.

4. Generate evidence as you adopt. Build a real-world evaluation into the rollout from day one: agreed metrics, a baseline, a comparison where feasible, and a cadence for reviewing results. Align the evidence you gather to the NICE Evidence Standards Framework tier appropriate to your technology, so the evidence is credible to future adopters and commissioners, not just to you.

5. Clear the regulatory pathway early and in parallel. Establish at the outset whether the technology is a medical device (MHRA), what NICE ESF tier applies, and whether it meets DTAC. Doing this late is the single most common cause of a promising innovation stalling at the point of scale. Treat clinical safety cases (DCB0129 for manufacturers, DCB0160 for deploying organizations) as first-class deliverables, not paperwork.

6. Balance innovation with equity. Ask, for every phase, who is being left out by the digital divide — patients without smartphones, digital connectivity, English fluency, or the confidence to use a new tool. An innovation that improves average outcomes while widening inequality fails a core NHS duty. Build inclusion into cohort selection and evaluation metrics, not as an afterthought.

7. Use the national infrastructure that exists. England's fifteen Health Innovation Networks (formerly Academic Health Science Networks, AHSNs) exist specifically to support adoption and spread; the Accelerated Access Collaborative curates nationally-backed innovations. Do not rebuild adoption capability from scratch — plug into these networks for real-world evidence, peer sites, and route-to-scale support.

8. Scan the horizon deliberately. Maintain a lightweight horizon-scanning function so that innovation is a managed portfolio, not a series of reactions to whichever supplier got a meeting. Knowing what is coming — in regulation, in technology, in adjacent systems — lets you sequence adoption rather than being surprised by it.

Questions to discuss with your team#

1. What is our honest, named plan for what happens the day this pilot succeeds — and if we cannot answer that, why are we starting it? This is the single question that separates disciplined phasing from pilotitis, and it is worth putting on the table before any money is committed. In a digital health or care organization the temptation to launch a promising trial is strong — a supplier is keen, a clinician is enthusiastic, a grant is available — but enthusiasm at the start says nothing about the route to scale at the end. The debate should surface the tensions between clinical curiosity and organizational commitment: who owns scaling, where the recurrent funding comes from, and what specific go/no-go decision the evidence will inform. A good, honest answer names a scaling owner, a funding route, and a pre-agreed exit decision, and it is candid where those do not yet exist. Concrete angles include reviewing your current portfolio for pilots with no scaling owner, and testing whether a "successful" pilot last year actually changed practice anywhere. The uncomfortable but valuable version of this conversation is admitting that some of your live pilots are really hobbies, and deciding to stop them.

2. Who is being left behind by each phase of this rollout, and are we willing to slow the innovation to avoid widening inequity? Health and care carry a statutory and moral duty around equity, and digital innovation can quietly improve average outcomes while excluding the people who most need care — those without smartphones, connectivity, English fluency, or digital confidence. The tension to debate is real: inclusion measures, non-digital fallbacks, and diverse cohort selection cost time and money and can slow adoption, so a team under pressure to show results will be tempted to pilot in the easiest, most digitally-engaged sites first. A serious discussion looks at who is in and out of your alpha and beta cohorts, whether deprivation and low digital access are deliberately represented, and what the fallback pathway is for excluded patients. It should also confront the measurement question — are inclusion metrics built into the evaluation from day one, or bolted on afterwards to reassure a board? An honest answer accepts that an innovation which widens inequality is a failure even if its headline numbers improve, and it commits to designing inclusion into cohort selection rather than retrofitting it. The best version names the specific excluded groups in your population and the concrete provision made for them in each wave.

3. Have we cleared the regulatory and clinical-safety pathway in parallel from the start, or are we quietly hoping to sort it out before scale? Discovering late that a tool is an unassessed medical device, fails DTAC, or lacks a clinical safety case is the most common way a genuinely promising innovation stalls at exactly the point it should spread. In a digital health organization this question forces an early, sometimes deflating conversation about MHRA medical-device status, the applicable NICE Evidence Standards Framework tier, and the DCB0129 and DCB0160 safety cases — work that is heavy, unglamorous, and easy to defer behind the excitement of the product. The trade-off to debate is speed versus assurance: front-loading regulation slows the first pilot but is the only way to avoid a wall at scale, and treating safety cases as paperwork rather than first-class deliverables stores up risk. Useful angles include mapping each live innovation against the three regimes today, and asking whether your clinical safety officer has been engaged as a designer or merely as a signatory at the end. A good answer treats the regulatory pathway as core delivery managed in parallel, names who owns each safety case, and is honest about which current initiatives are proceeding on hope rather than assessment.

4. When we say we want to "scale" this, do we mean genuine scale — funded, staffed, embedded as business-as-usual — or are we quietly settling for thin spread across many sites? Spread and scale are different problems, and conflating them is how organizations congratulate themselves on adoption that never actually beds in. Spread is horizontal — more sites using the innovation — while scale is vertical, the depth of adoption plus the recurrent funding, infrastructure, and workforce change needed to sustain it, and an innovation can spread thinly to dozens of sites without ever scaling into embedded practice anywhere. The tension to debate is that spread is visible and reportable — a map with more pins on it looks like success to a board — whereas scale is expensive, slow, and demands hard decisions about permanent budget and staffing that no one wants to own. A serious discussion distinguishes the two explicitly for the innovation in front of you: what depth of adoption counts as "done", what workforce redesign it implies, and whether the recurrent money to sustain it actually exists. Concrete angles include auditing where a widely-spread innovation is genuinely load-bearing versus merely installed, and asking whether last year's "rollout" changed any job description or funding line. An honest answer admits when the plan is really spread dressed up as scale, and either commits the resources to embed it properly or is candid that it will remain shallow.

5. How are we choosing our early cohorts — for honest feedback and representativeness, or for an easy win that flatters the evidence? The sites you pilot in shape everything you learn, and there is a strong pull towards the most enthusiastic, best-resourced, most digitally-engaged teams because they make the innovation look good. That pull is dangerous: early cohorts chosen for ease produce evidence that does not transfer, so the innovation sails through alpha and beta and then fails when it meets ordinary sites with real constraints, tired staff, and patients on the wrong side of the digital divide. The trade-off to debate is that appetite and honesty matter — you do want willing early adopters who will give candid feedback rather than polite silence — but appetite must be balanced against representativeness so that deprivation, low digital access, and awkward workflows are deliberately in the sample, not designed out of it. Useful angles include naming who is in your alpha and beta and why, checking Rogers' attributes (relative advantage, compatibility, simplicity, trialability, observability) against a typical rather than a flagship site, and asking whether any of your cohorts would embarrass the evidence if they spoke freely. A good answer picks cohorts for their ability to tell you the truth and to stand in for the real system, and it treats a pilot that only works in ideal sites as a warning, not a success.

6. Is our innovation a deliberately managed portfolio, or a series of reactions to whichever supplier or clinician got a meeting? Phasing innovation well is a portfolio discipline, not a sequence of one-off enthusiasms, and the difference shows in whether you can say what you are deliberately not doing. Without a lightweight horizon-scanning function and an owned portfolio view, innovation becomes reactive — driven by persuasive suppliers, grant deadlines, and individual champions — and the organization ends up with many overlapping, half-owned initiatives competing for the same scarce assurance, evaluation, and scaling capacity. The tension to debate is between openness to genuinely good ideas that arrive unbidden and the discipline to sequence adoption against strategy, capacity, and what is coming in regulation and technology. Concrete angles include listing every live innovation and who sponsored it, asking how many were chosen versus merely accepted, and testing whether your go/no-go gates function as real investment decisions or as rubber stamps. An honest answer acknowledges where the current portfolio is really a pile of reactions, and commits to horizon scanning and prioritization so that limited capacity backs the innovations that matter most rather than the ones that shouted loudest.

In practice: a health & care example#

An integrated care system (ICS) wants to reduce avoidable admissions among people with heart failure. Rather than buying a remote-monitoring platform for its whole population on day one, the program lead frames the problem with a baseline: current admission rates, the cohort size, and the target reduction.

They confirm the regulatory picture first — the platform is a Class I medical device, the supplier holds a DCB0129 safety case, and the ICS completes its own DCB0160 deployment safety case and a DTAC assessment. They map the product to the relevant NICE ESF evidence tier and design a real-world evaluation with the local Health Innovation Network as evaluation partner.

The rollout is phased. An alpha runs in one community heart-failure team of enthusiastic clinicians for eight weeks, purely to learn about workflow, alerts, and false positives. A beta then extends to three geographically and demographically varied localities — deliberately including an area with high deprivation and low digital access, with telephone-based fallback so the innovation does not widen inequity. A go/no-go gate reviews admission data, clinician workload, patient-reported experience, and inclusion metrics before wider spread.

Only after the beta shows a credible admissions reduction and a workable staffing model does the ICS commit recurrent funding and spread to remaining localities — with the scaling owner, funding, and evaluation already agreed. The pilot never became a dead end because its exit was designed before it began.

Sector lenses#

Startup#

For a small, venture- or grant-funded digital-health company, phasing is existential rather than merely prudent: runway is finite, so a pilot that stalls without a route to a paid contract can be fatal. Startups compete on Rogers' trialability and observability — a lightweight, low-commitment pilot that quickly shows results is how they win the reference sites that unlock the next funding round. They usually carry the manufacturer's clinical-safety burden themselves (DCB0129) and self-fund DTAC and their NICE ESF evidence, which is heavy for a small team, so they should pick one narrow beachhead cohort rather than spreading thin. Crucially, they must design the pilot's exit as a commercial decision (who signs a recurring contract on success), not only a clinical one, because a clinically successful pilot that no budget adopts still kills the company. Their advantage is speed and focus; their risk is running out of cash before evidence and adoption catch up.

Small business#

For an established small provider — a GP practice, a community pharmacy, a care home, a domiciliary-care agency, a single-site clinic, or a small health-tech supplier past the startup stage — phasing is constrained less by runway than by having real patients to protect and almost no spare capacity to run a proper pilot. Such organizations carry the same statutory duties as a large trust — DTAC-level expectations, DCB0160 clinical safety when deploying, data protection — but without a clinical safety officer, an information-governance team, or an evaluation partner on staff, so the honest move is to adopt innovations that others have already evidenced rather than to pioneer unproven ones alone. Their sensible phasing is a small, cheap, reversible trial in their own single setting, with a manual fallback kept running so a failed tool never leaves patients stranded. Because they cannot spread across sites, "scale" for them means deepening one workflow reliably, and their best route to assurance and route-to-scale support is to lean on the local Health Innovation Network and on suppliers who bring a ready-made DCB0129 safety case. Their advantage is that a single owner can decide and act quickly; their risk is that thin digital capability tempts them either to avoid useful innovation altogether or to adopt it without the safety and equity checks the duties still require.

Enterprise#

A large NHS trust, ICS, or established health-tech supplier has the convening power to run genuine multi-site betas and the standing infrastructure — clinical safety officers, information governance, evaluation partners, Health Innovation Network links — that a startup lacks. Its characteristic failure is the opposite: death by pilot, dozens of simultaneous small trials none of which is owned through to spread, because accountability is diffuse and priorities compete. Phasing here is a portfolio-governance problem: each go/no-go gate should be a formal investment decision tied to recurrent funding and a named senior responsible owner, in the spirit of Management of Portfolios. The enterprise can afford deliberate, evidenced waves and should use them, but must fight organizational inertia and the temptation to big-bang a favored supplier's product. Its advantage is scale and assurance capability; its risk is that scale becomes sludge.

Government#

A national or local public body — NHS England, DHSC, UKHSA, a devolved administration, or a local authority — mostly does not run the pilot at all; it shapes the enabling environment in which everyone else phases innovation. Its levers are standards (DTAC, the NICE ESF), the spread infrastructure it funds (Health Innovation Networks, the Accelerated Access Collaborative), and the structural barriers it can remove — procurement routes, tariff and reimbursement, interoperability mandates — that otherwise strand proven innovations at the point of scale. Accountability runs to Parliament and the public purse, and equity and universal coverage are statutory duties, so a government-led rollout must design out the digitally excluded from the very first phase, not retrofit inclusion. Its risk appetite is the lowest and its scrutiny the highest: a failed national rollout is a headline and an audit, so it phases conservatively and evidences publicly. The government's real job is to make the pathway from evidence to national adoption navigable for the whole system.

Common failure modes#

• Pilotitis. Endless successful pilots that never scale, because no one owns the route from evidence to adoption. Avoid it by refusing to start a pilot without a named scaling owner and funding route.
• Solution in search of a problem. Adopting technology because it is impressive, not because it addresses a measured need. Avoid it by protecting the problem statement and baseline.
• Regulatory afterthought. Discovering at the point of scale that the tool is an unassessed medical device or fails DTAC. Avoid it by clearing MHRA/NICE/DTAC in parallel from the start.
• Big-bang rollout. Skipping phased cohorts and deploying everywhere at once, so a design flaw becomes a system-wide incident. Avoid it by using go/no-go gates between waves.
• Evaluation bolted on late. No baseline captured, so "success" cannot be demonstrated and future adopters are unconvinced. Avoid it by designing the evaluation before the first patient.
• Innovation that widens inequity. Improving averages while excluding the digitally marginalized. Avoid it by measuring inclusion in every phase.

Maturity model#

Checklist#

• Every innovation has a stated problem and a quantified baseline.
• Each pilot has a named scaling owner, funding route, and pre-agreed exit decision.
• Rollout is phased into cohorts/geographies with go/no-go gates between waves.
• A real-world evaluation with metrics and baseline is designed before launch.
• MHRA (medical device) status, NICE ESF tier, and DTAC compliance are confirmed early.
• Clinical safety cases (DCB0129/DCB0160) are complete and owned.
• Inclusion and equity are measured in every phase, with a non-digital fallback.
• The relevant Health Innovation Network / national adoption route is engaged.
• Horizon scanning feeds a managed innovation portfolio, not reactive purchasing.

Key sources#

• Everett M. Rogers, Diffusion of Innovations (5th edition) — the adoption curve and the five attributes of spreadable innovations.
• NICE, Evidence Standards Framework (ESF) for digital health technologies — evidence tiers by function and financial risk (nice.org.uk).
• Digital Technology Assessment Criteria (DTAC), NHS England — clinical safety, data protection, security, interoperability, usability baseline for suppliers.
• MHRA — Software and AI as a Medical Device guidance (gov.uk).
• Clinical safety standards DCB0129 (manufacturers) and DCB0160 (health organisations deploying), NHS Digital.
• The Health Innovation Network (formerly the AHSN Network) and the NHS Accelerated Access Collaborative — adoption and spread infrastructure (england.nhs.uk; thehealthinnovationnetwork.co.uk).
• The King's Fund, Adoption and spread of innovation in the NHS — analysis of "pilotitis" and the adoption gap (kingsfund.org.uk).
• NHS Horizons — spread and adoption methods and the spread/scale distinction (horizonsnhs.com).

References#

1. Diffusion of innovations — Wikipedia — https://en.wikipedia.org/wiki/Diffusion_of_innovations
2. Everett Rogers — Wikipedia — https://en.wikipedia.org/wiki/Everett_Rogers
3. Technology adoption life cycle — Wikipedia — https://en.wikipedia.org/wiki/Technology_adoption_life_cycle
4. Proof of concept — Wikipedia — https://en.wikipedia.org/wiki/Proof_of_concept
5. Real world evidence — Wikipedia — https://en.wikipedia.org/wiki/Real_world_evidence
6. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
7. National Institute for Health and Care Excellence — Wikipedia — https://en.wikipedia.org/wiki/National_Institute_for_Health_and_Care_Excellence
8. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
9. Health equity — Wikipedia — https://en.wikipedia.org/wiki/Health_equity
10. Digital divide — Wikipedia — https://en.wikipedia.org/wiki/Digital_divide
11. Horizon scanning — Wikipedia — https://en.wikipedia.org/wiki/Horizon_scanning
12. Integrated care system — Wikipedia — https://en.wikipedia.org/wiki/Integrated_care_system
13. Evidence Standards Framework (ESF) for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/our-programmes/evidence-standards-framework-for-digital-health-technologies
14. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/about-us/digital-technology-assessment-criteria-dtac/
15. Software and AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
16. Adoption and spread of innovation in the NHS — The King's Fund — https://www.kingsfund.org.uk/insight-and-analysis/reports/adoption-spread-innovation-nhs
17. Diffusion of Innovations, 5th edition — Everett M. Rogers, Free Press (2003), ISBN 978-0743222099
18. The Health Innovation Network — https://thehealthinnovationnetwork.co.uk/
19. Accelerated Access Collaborative — NHS England — https://www.england.nhs.uk/aac/