Textbook of Digital Health

Introduction

The success of digital health initiatives depends less on the technology selected than on how well implementations are planned, executed, and sustained within complex healthcare organisations. Healthcare systems worldwide have invested billions in digital health technologies, yet published estimates suggest that between 50% and 80% of health-IT projects fall short of their intended benefits (Kaplan and Harris-Salamone, 2009; Heeks, 2006) - not because the technology was wrong, but because insufficient attention was paid to change management, workflow integration, and organisational context.

This chapter explores implementation frameworks from implementation science, change management strategies for healthcare settings, workflow analysis and redesign methods, effective training approaches, and methods for measuring implementation success. The recurring theme is that implementation is fundamentally a sociotechnical challenge: getting the technology right is necessary but far from sufficient.

Implementation Science Frameworks

In the early 2000s, researchers studying healthcare improvement noticed a recurring pattern. Evidence would emerge showing that a particular intervention (a new medication protocol, a screening programme, a care pathway) improved patient outcomes. Yet years later, many healthcare organisations still had not adopted these proven practices. The gap between knowing what works and actually doing it in routine care became known as the "evidence-to-practice gap," and it prompted a fundamental question: why do good ideas fail to spread, and what can we do about it?

This question gave rise to implementation science, a discipline dedicated to understanding the factors that help or hinder the adoption of evidence-based practices in real-world settings. Implementation science recognises that moving innovations into routine use requires systematic attention to context, people, and process, not just demonstrating effectiveness.

Consider a hospital implementing a new sepsis alert system. The technology itself might be excellent: sensitive algorithms, clear displays, well-designed interfaces. But whether nurses and physicians actually respond to alerts depends on far more than the system's technical capabilities. Do clinicians trust the alerts, or have they been burned by too many false alarms from other systems? Does the organisational culture encourage speaking up when an alert fires, or do hierarchies suppress concerns? Are there competing priorities that make it easy to dismiss alerts as "one more thing"? Do clinicians have the training and resources to act on alerts effectively? Implementation science provides frameworks for thinking systematically about these questions.

The Consolidated Framework for Implementation Research (CFIR) offers one of the most comprehensive approaches. Originally developed by Damschroder et al. in 2009, CFIR was substantially updated in 2022 as CFIR 2.0 (Damschroder et al., 2022, Implementation Science). The updated framework reorganised and refined its constructs based on over a decade of use across hundreds of studies. CFIR 2.0 retains five domains but with important changes: the original "Intervention Characteristics" domain was renamed "Innovation" to reflect broader applicability beyond clinical interventions, constructs were renamed for clarity (for example, "Intervention Source" became "Innovation Source"), and new constructs were added to address gaps identified by users. The five domains in CFIR 2.0 are: the Innovation itself (is it clearly better than current practice? Can it be adapted to local needs without losing effectiveness?); the Outer Setting of patient expectations, regulatory requirements, and competitive pressures; the Inner Setting of organisational culture, communication patterns, and readiness for change; the Individuals involved, bringing their own knowledge, beliefs, and professional identities to bear; and the Implementation Process, encompassing how planning unfolds, how stakeholders engage, how execution proceeds, and how progress is evaluated.

The power of CFIR lies in recognising that these domains interact. A technically excellent innovation (strong innovation characteristics) can fail in an organisation that lacks readiness (weak inner setting) or where key clinicians feel threatened by the change (individual characteristics). Conversely, strong leadership and organisational readiness can sometimes overcome limitations in the innovation itself. Successful implementation requires attending to the whole system, not just the parts that seem most obvious.

While CFIR addresses the broad range of implementation factors, the Technology Acceptance Model (TAM) (Davis, 1989) zooms in on a crucial question: what makes individual users willing to adopt new technology? Decades of research have converged on two primary drivers. First, perceived usefulness: do users believe the technology will actually help them do their jobs better? Second, perceived ease of use: do users believe they can learn the technology without excessive effort or frustration? These perceptions, not the technology's objective capabilities, determine whether users develop positive attitudes toward adoption and ultimately incorporate the technology into their work.

This insight has practical implications. A system that clinicians perceive as unhelpful or difficult will struggle for adoption, while a simpler system that clearly addresses felt needs may succeed even with technical limitations. Understanding this, implementation teams can focus on demonstrating value in terms clinicians care about, reducing friction in the learning process, and addressing clinicians' underlying perceptions about whether the effort is worthwhile.

TAM's influence led to more comprehensive models. The Unified Theory of Acceptance and Use of Technology (UTAUT), developed by Venkatesh et al., 2003, synthesised eight prior models (including TAM) into a framework with four key determinants of technology use: performance expectancy, effort expectancy, social influence, and facilitating conditions. UTAUT2 (Venkatesh et al., 2012) extended the model further by adding hedonic motivation, price value, and habit as additional drivers. Both UTAUT and UTAUT2 are widely used in health IT research, particularly for understanding adoption of patient-facing technologies such as patient portals and mHealth applications where social and contextual factors play a significant role alongside individual perceptions.

Finally, even successful initial implementation means little if changes do not persist. The RE-AIM framework (Glasgow et al., 1999) addresses this by extending evaluation beyond simple adoption to encompass the full journey from initial reach through long-term maintenance. Did the implementation reach the intended population, including those typically underserved? Did it produce meaningful improvements, including avoiding unintended harms? Was it adopted broadly across relevant settings and by the staff meant to deliver it? Was it implemented consistently and faithfully, or did essential elements get lost in adaptation? And critically, will it be maintained over time, or will the organisation gradually drift back to previous practices once the implementation spotlight moves elsewhere?

Taken together, these frameworks transform implementation from intuition and hope into a more systematic discipline. They do not guarantee success; implementation remains difficult, context-dependent work. But they provide a shared vocabulary for diagnosing problems, a structured approach to planning, and a comprehensive lens for evaluation. Organisations that apply them thoughtfully give their digital health investments better odds of achieving lasting benefit.

Change Management

In 1996, Harvard professor John Kotter published Leading Change (Kotter, 1996), a book that would influence how organisations think about change. Drawing on his study of transformation efforts at over one hundred companies, he concluded that most change initiatives fail not because of flawed strategies or inadequate resources, but because leaders underestimate the difficulty of driving people out of their comfort zones. Healthcare, with its established hierarchies, professional autonomy, and high stakes, presents these challenges in heightened form. A surgeon who has spent twenty years developing efficient workflows, a nurse who knows exactly where to find what she needs in the current system, an administrator who has built processes around existing technology: all face real losses when digital change arrives, even if it promises collective gains.

This is why change management matters. Digital health implementations are human endeavours that ask people to abandon familiar practices, learn new skills, and trust that the disruption will ultimately prove worthwhile. Organisations that treat implementation as primarily a technology deployment problem (get the system installed, train users on the mechanics, flip the switch) routinely discover that their expensive new tools sit unused, generate workarounds, or become sources of persistent frustration rather than improvement.

The journey typically begins with creating readiness: helping stakeholders recognise that the status quo is no longer acceptable while believing that change can make things better. This is more delicate than it sounds. Push too hard on the problems with current practice, and people become defensive or demoralised. Fail to create any sense of urgency, and no one sees reason to endure the disruption that change requires. Skilled change leaders find the balance: acknowledging what works well in current practice while clearly articulating why change is necessary, painting a picture of a better future while being honest about the challenges of getting there.

Leadership commitment must run deeper than announcements and memos. Staff have seen enough initiatives launched with fanfare only to quietly fade as leadership attention moves elsewhere. They watch what leaders actually do: whether resources appear when promised, whether barriers get removed when identified, whether competing priorities are genuinely addressed or simply added to already overwhelming workloads. Most telling of all, they notice whether leaders themselves use the new technologies: whether the chief medical officer actually documents in the new EHR or delegates to support staff, whether executives pull up dashboards in meetings or still ask for printed spreadsheets. Staff read these signals accurately, and what leaders do with the system says more about the organisation's commitment than any announcement.

Abstract visions such as "becoming a digital health leader" or "improving care delivery" mean little to a ward nurse wondering how the new system will change her Tuesday morning medication round. Effective change management translates organisational goals into concrete, specific answers about what will be different in daily work and why those differences matter. What will I do differently? How will it help my patients? What support will I receive during the transition? What happens if I struggle?

Communication must flow in two directions. Top-down messages about project progress and upcoming changes certainly matter. But equally important are genuine channels for feedback that actually influence decisions. Staff can tell immediately whether their input is valued or merely collected. When concerns raised are acknowledged, investigated, and where possible addressed, trust builds. When feedback disappears into a void or receives only defensive responses, cynicism grows. The most successful implementations create mechanisms (regular forums, accessible champions, responsive leadership) that make genuine dialogue possible throughout the process.

Meaningful stakeholder engagement goes further still. Rather than presenting fully formed plans for comment, effective change management involves those affected by change in shaping decisions from the early stages. Frontline clinicians understand workflow realities that outside observers miss. They know which workarounds exist because official processes do not work, which handoffs are fragile, which practices vary between individuals despite official standardisation. Engaging them surfaces this knowledge while building ownership.

Momentum matters, which is why experienced change leaders prioritise quick wins: visible, early successes that demonstrate change is working. A department that achieves measurable improvement in documentation completeness, a clinic where wait times noticeably decrease, a unit where nurses report that a previous frustration has been resolved: these concrete successes counter the scepticism that greets every organisational initiative. They provide evidence that the disruption is worthwhile and sustain energy through the long slog of full implementation.

Most neglected is sustainability planning, which deliberately addresses how changes will persist once organisational attention shifts to newer priorities. Organisations have limited attention; new priorities inevitably emerge. Without embedding changes into policies, workflows, hiring practices, performance expectations, and organisational culture, practices that seemed firmly established during intensive implementation gradually erode. Staff who championed the change leave and are replaced by newcomers who never experienced the transformation. Small deviations become normalised. Within a few years, the organisation may have drifted back to practices remarkably similar to where it started, the expensive new technology either underutilised or generating frustration without delivering promised benefits.

Table 11.1: Kotter's Eight Steps for Digital Health Implementation

Learning from Implementation Failures

Some of the most instructive lessons in digital health come from implementations that went wrong.

The NHS National Programme for IT (NPfIT) in England represents one of the largest health IT failures in history. Launched in 2002 with an estimated budget of £6 billion (later revised to over £12 billion), NPfIT aimed to create a unified electronic care record system across the NHS. The programme was formally dismantled in 2011 without achieving its primary objectives. Key factors contributing to failure included: a centralised, top-down approach that failed to engage clinicians in design; unrealistic timelines imposed politically rather than based on implementation realities; underestimation of the complexity and variation across NHS organisations; contractual structures that prioritised vendor compliance over clinical usability; and insufficient attention to change management and local adoption. The National Audit Office concluded in 2011 that the £2.7 billion spent on care records systems up to that point did not represent value for money (National Audit Office, 2011), and the House of Commons Public Accounts Committee, reviewing the dismantled programme in 2013, found that the benefits delivered fell far short of the costs incurred and that the taxpayer was continuing to pay the price for the programme's failures (Public Accounts Committee, 2013).

After NPfIT was dismantled in 2011, the NHS pursued a different strategy: a distributed approach with local systems connected by national infrastructure services. Rather than mandating a single system, the NHS allowed trusts to select their own electronic health records while investing in national services for interoperability, identity, and messaging. The NHS App, launched in 2018, became a key digital front door for patients, providing access to GP records, appointment booking, and prescriptions without requiring a monolithic national system. That distributed approach, local systems within national frameworks, formed the basis of NHS digital strategy through the 2020s.

Lessons from NPfIT and similar failures include the importance of clinical engagement from the outset, the need for realistic timelines and iterative approaches, the value of local flexibility within national frameworks, and the recognition that technology alone cannot transform care without attention to people and processes.

Other instructive failures have occurred at individual hospital level. Cambridge University Hospitals NHS Foundation Trust implemented its Epic electronic health record system (initially branded as eHospital) in October 2014, and the go-live led to significant patient safety concerns, staff distress, and leadership changes: the Care Quality Commission's 2015 inspection found that the new system had diminished the trust's ability to report and act on patient data, and the trust was rated inadequate and placed in special measures (Purohit, 2021). Post-implementation analysis revealed inadequate testing, insufficient training, and lack of contingency planning. After significant additional investment, organisational restructuring, and sustained effort over several years, the hospital eventually stabilised the system, and Epic has since become operational and embedded in clinical workflows. The Cambridge experience demonstrates that even well-resourced organisations with strong technical capabilities can face severe difficulties when implementation fundamentals are neglected, though recovery is possible with sustained commitment.

Workflow Analysis and Redesign

Consider an emergency department on a busy weeknight. A patient arrives with chest pain. Over the next several hours, she will be triaged, assessed by a nurse, seen by a physician, have blood drawn, undergo an ECG and possibly imaging, wait for results, receive a diagnosis, and be either admitted or discharged with a care plan. Dozens of individual steps, multiple handoffs between staff, information flowing between people and systems, decisions made under time pressure: this is clinical workflow in action.

Now imagine dropping a new digital health technology into the middle of this complexity. An electronic documentation system that requires physicians to enter information in a particular sequence. An alert system that demands acknowledgment before proceeding. A new patient portal that generates messages staff must respond to. Each technology makes assumptions about how work happens, and those assumptions may or may not match the reality of clinical practice in this particular emergency department, with its particular staffing patterns, physical layout, patient population, and organisational culture.

When technology assumptions clash with workflow realities, the results are predictable: frustration, inefficiency, and workarounds. Clinicians find ways to get their work done despite the system rather than with it, whether by typing notes in personal apps and copying them later, ignoring alerts that interrupt their flow, or having medical assistants navigate systems while they focus on patients. These workarounds are not laziness or resistance to change; they are rational responses to technology that makes work harder rather than easier. But they also undermine the benefits that technology was meant to provide, create safety risks when information does not flow as intended, and generate the user frustration that becomes entrenched opposition to digital transformation.

This is why workflow analysis must precede technology implementation. Before introducing new systems, implementation teams need to understand how work actually happens. This means not how policy documents say it should happen, not how managers assume it happens, but what clinicians actually do on Tuesday afternoon when the department is understaffed and three critical patients arrive simultaneously. This requires getting out of conference rooms and into clinical spaces: observing work directly, following patients through their journeys, shadowing clinicians through their shifts, mapping the actual steps and decision points and information flows and handoffs that constitute real clinical workflow.

This current state analysis often reveals surprises. Practices that seem inefficient often turn out to serve purposes that are not obvious from outside, including workarounds that compensate for system limitations, informal communication channels that supplement official processes, and variations between individuals that reflect legitimate differences in patient populations or clinical judgement. Understanding the rationale behind existing practices prevents the common mistake of designing new workflows that break things that currently work while failing to address actual pain points.

With current state understood, future state design can begin, envisioning how workflow should function with new technology capabilities. This is inherently creative work that involves rethinking what should happen. Perhaps steps that exist only because of previous technology limitations can be eliminated. Perhaps information that was previously locked in silos can now flow to where it is needed. Perhaps decisions that required human effort can be automated, freeing clinicians for work that truly requires their expertise. But future state design also requires humility: preserving what works well in current practice, recognising that not every process needs transformation, and involving frontline clinicians who understand constraints that outside observers miss.

The gap between current and future state defines what implementation must accomplish. This gap analysis is often larger than initially apparent. Technical changes are usually obvious: new systems to deploy, integrations to build, interfaces to configure. But technical changes ripple outward: policies must be updated to reflect new processes, training must prepare staff for new workflows, roles may need modification as tasks shift between people and systems, even physical environments may need adjustment as work patterns change. Comprehensive gap analysis prevents the surprises that derail implementations when an overlooked dependency suddenly becomes critical.

Testing workflows before they go live, while changes are still practical to make, reduces implementation risk. Simulation environments where staff can practice new workflows without patient consequences, pilot programmes in limited areas where problems can be discovered and addressed before organisation-wide rollout, and staged implementations that allow learning between phases all create opportunities to refine designs based on actual experience rather than theoretical assumptions. The cost of discovering a workflow problem in a pilot is modest; the cost of discovering it after organisation-wide go-live can be enormous.

Even after go-live, workflow monitoring must continue. Intended workflows do not always function as designed when they meet the unpredictable realities of clinical practice. Observation, user feedback, and analysis of system data reveal deviations from design. Some represent problems that require correction, while others represent creative adaptations that work better than the original design and should be spread. The goal is continuous refinement as the organisation learns what actually works.

Training Strategies

A consultant arrives at a hospital three months after their major EHR implementation. On paper, everything looks successful: the system is live, staff have completed their required training hours, and basic functions are operational. But walking the wards reveals a different story. Physicians hunt through screens searching for information they need, muttering about where something used to be. Nurses have developed personal workarounds, some ingenious and some potentially dangerous. Administrators answer the same questions repeatedly because staff cannot remember what they learned in sessions held weeks before go-live. The training boxes were checked, but the learning did not stick.

This scenario plays out repeatedly because organisations underestimate what effective training for digital health technology actually requires. Showing someone how to click through screens is not the same as enabling them to use technology fluently within their clinical workflow. Teaching in a classroom three weeks before go-live is not the same as supporting learning when it matters: in the moment when a clinician needs to accomplish a task under time pressure. Treating training as a discrete phase that ends at go-live ignores the reality that learning technology is an ongoing process.

Understanding what different users actually need to learn provides the foundation for effective training. This seems obvious, but many organisations default to one-size-fits-all approaches that waste time teaching physicians functions they will never use while leaving nurses underprepared for tasks critical to their workflow. A training needs assessment examines roles, prior technology experience, and the specific functions each group will use, then designs appropriately differentiated learning paths. The veteran physician who is uncomfortable with computers needs different support from the recent graduate who grew up with technology but does not understand the organisation's clinical workflows. The nurse using the system all day needs deeper proficiency than the consultant who documents a few notes per week.

Training content matters as much as training method. Teaching technology mechanics (where to click, how to navigate screens, what buttons do) is necessary but far from sufficient. Clinicians need to understand how technology fits into their clinical workflows: how the ordering workflow integrates with verification, dispensing, and administration. They need to understand relevant policies: why the system requires additional steps for controlled substances and what happens if they try to bypass them. Most importantly, they need to understand the rationale for changes. Adults learn better when they understand why something matters, and clinicians who see how changes benefit their patients engage far more fully than those who perceive arbitrary mandates from administration.

How training is delivered shapes how well learning sticks. Classroom sessions provide efficient delivery of foundational knowledge and create opportunities for questions and discussion, but retention fades quickly without reinforcement. E-learning modules offer flexibility for busy clinicians to learn at their own pace, but completion statistics often mask minimal engagement. Simulation exercises create safe spaces to practice realistic scenarios, building confidence before live patient care. Hands-on practice in training environments, working through actual clinical scenarios with realistic data, bridges the gap between abstract instruction and practical proficiency. The most effective approaches blend these methods, recognising that different content and different learners benefit from different modalities.

Timing training appropriately requires balancing competing pressures. Train too early, and staff forget what they learned by the time go-live arrives (a particular problem when implementations face delays). Train too late, and staff have no time to practice, consolidate learning, or raise questions before they must use new systems with real patients. The solution typically involves multiple training touches: initial orientation sessions to build foundational understanding and reduce anxiety, intensive skills training close to go-live when knowledge will be immediately applied, and refresher sessions after go-live when staff have encountered real-world questions and can learn at a deeper level.

The super user model extends training capacity in ways that formal programmes cannot. Super users are carefully selected staff, typically respected clinicians with aptitude for technology and commitment to helping peers, who receive intensive training and then serve as local experts supporting colleagues during implementation and beyond. When a ward nurse cannot figure out how to accomplish something, her first instinct is not to call a help desk or search documentation but to ask a trusted colleague. Super users fill this role, providing accessible assistance in the flow of clinical work, answering questions in the language of the ward rather than the language of IT, and serving as feedback channels for identifying problems that formal reporting mechanisms miss. Selecting the right super users (clinicians respected by their peers, patient with learners, and genuinely committed to the implementation) matters far more than the mechanics of the programme.

Go-live represents a transition point where training success is tested against reality. Organisations that invest heavily in pre-go-live training but then leave staff to struggle alone when the system actually launches squander their investment and generate lasting frustration. Intensive go-live support, including at-the-elbow assistance from super users, trainers, and vendor specialists during the first days and weeks of live operation, addresses problems in real time, prevents small frustrations from escalating into major grievances, and demonstrates that leadership genuinely supports successful transition. The visible presence of support staff during go-live sends a message that resonates far more than any memo.

Training must not end when go-live settles down and normal operations resume. Systems change and evolve; upgrades introduce new features that require new learning. Knowledge fades without reinforcement; staff who do not use certain functions regularly need refresher training when situations arise that require them. New staff join the organisation and need onboarding that current staff never experienced. Advanced skills training helps experienced users work more efficiently and take advantage of capabilities they never learned initially. Organisations that treat training as a go-live activity rather than an ongoing capability find their initial investment eroding as workflows drift, workarounds develop, and new staff learn bad habits from undertrained predecessors.

Measuring Implementation Success

How do you know if a digital health implementation has succeeded? The question seems straightforward, but the answer proves complex. A system might be technically functional yet barely used. It might show high adoption rates but generate workarounds that undermine intended benefits. Clinicians might report satisfaction while patient outcomes remain unchanged, or report frustration even as objective quality measures improve. Financial projections might be met while staff burnout increases. Success, it turns out, has many dimensions, and different stakeholders may have legitimately different perspectives on whether an implementation delivered value.

This complexity makes measurement essential. Without deliberate attention to tracking implementation progress and outcomes, organisations operate on impressions and anecdotes: the loud complaints of dissatisfied users, the optimistic reports of project champions, the selected success stories that make their way to leadership. Systematic measurement provides the objective foundation for understanding what is actually happening, identifying problems that require intervention, demonstrating value to decision-makers, and driving continuous improvement.

Implementation metrics focus on the process of adoption itself: who is using new technologies, how intensively, and in what ways. Adoption tracking reveals whether the intended users are actually engaging with systems: whether clinicians log in regularly, complete workflows in the system, and use intended features. Usage patterns illuminate how technologies are being used: which features see heavy use and which languish neglected, whether usage follows intended workflows or suggests problematic workarounds, whether patterns vary across units or user groups in ways that indicate localised problems or successes. Training completion rates, support ticket volumes and themes, workflow compliance measures, and user satisfaction surveys round out the picture of implementation quality.

But process measures, while important, ultimately matter only insofar as they connect to outcomes that justify the investment. Outcome metrics assess whether implementations deliver on their promises: clinical outcomes that improve patient health, operational efficiency that enables better resource use, user experience that supports rather than hinders professional work, patient experience that strengthens engagement and trust. This is where the "so what" of implementation becomes concrete. Higher adoption rates mean little if clinical outcomes do not improve. Efficiency gains are hollow victories if they come at the cost of clinical quality or staff wellbeing.

Outcome measurement must be honest about unintended consequences as well as intended benefits. New documentation requirements might improve care coordination while increasing physician burnout. Clinical decision support might catch some errors while causing others through alert fatigue and automation complacency. Patient portals might improve access for tech-savvy patients while widening disparities for those less comfortable with digital tools. Comprehensive measurement captures these trade-offs rather than cherry-picking metrics that make implementation look successful.

Return on investment analysis brings financial rigour to implementation assessment, comparing benefits achieved against costs incurred. This seems straightforward but quickly becomes complicated in practice. Costs extend beyond initial implementation expenses to include ongoing operational costs (maintenance, support, infrastructure, training) and indirect costs that organisations often overlook, such as productivity loss during transition and the time staff spend in training and adjustment. Benefits may include revenue enhancement, cost savings, quality improvements, and risk reduction. However, many benefits are difficult to quantify in financial terms, and attributing outcomes to specific technology investments when multiple factors influence results requires careful analytical approaches.

Given this complexity, many organisations turn to balanced scorecard approaches that track performance across multiple dimensions simultaneously (clinical quality, operational efficiency, user experience, patient experience, and financial performance) rather than reducing success to any single metric. This prevents the common error of overemphasising easily measured dimensions while neglecting harder-to-quantify but equally important factors. A financially successful implementation that damages staff morale and increases turnover may prove less valuable than initial numbers suggest. A clinically successful implementation that creates unsustainable financial burdens cannot be maintained.

Table 11.2: Digital Health Implementation Balanced Scorecard

Most importantly, measurement should drive continuous improvement, not merely render a verdict on whether implementation succeeded or failed. The learning health system model treats measurement as an ongoing capability embedded in operations rather than a one-time evaluation conducted after go-live. Data flows continuously, revealing opportunities for optimisation, identifying emerging problems before they become crises, and enabling the iterative refinement that improves implementations over time. In this view, implementation is a continuous process of learning and improvement that persists as long as the technology remains in use.

Summary

The evidence from both research and high-profile failures is consistent: digital health implementations succeed or fail primarily on organisational and human factors rather than technical ones. The NHS National Programme for IT demonstrated that even massive investment cannot overcome a top-down approach that neglects clinical engagement and local context. The Cambridge Epic implementation showed that even well-resourced organisations face severe difficulties when implementation fundamentals are neglected, though also that recovery is possible with sustained commitment.

Implementation science provides frameworks (CFIR, TAM, RE-AIM) that make these challenges more tractable by offering structured approaches to diagnosis, planning, and evaluation. Change management principles - genuine leadership commitment, two-way communication, meaningful stakeholder engagement, and sustainability planning - address the human dimensions that determine whether technology is adopted or resisted. Workflow analysis ensures that new systems fit clinical reality rather than disrupting it, and effective training goes well beyond showing people where to click. Systematic attention to these factors does not remove the difficulty, but it changes the odds. Organisations that recover from bad implementations tend to be the ones that treat the failure as an organisational problem rather than a technical one.