Everyone went live.Not everyone went digital.
Everyone went live.
Not everyone went digital.
The cultural problem at the heart of NHS EPR programmes — and why “live” was never the finish line.
Almost every NHS organisation now has an EPR live, or will have shortly. Far fewer would say their staff are getting everything the original business case promised. Addressing that gap — between going live and actually delivering — was the purpose of my talk at HPN last week, and is now the purpose of this piece.
The NHS has spent the best part of a decade, and an enormous amount of money, reaching “live.” But live was never the finish line. It is the starting line for a harder problem, which has far less to do with buying the right technology than most people buying and selling technology in healthcare would like to admit.
At Health Systems Support we do the human work of an EPR programme: process mapping, training, go-live support, and the part that begins after the software works but the people still do not work with it. Most programmes treat the technology as the project and the people as a workstream. We think that has it the wrong way round. It is the problem we live in every day, and the one we have made our niche. What follows is an honest account of why this part is so hard, and what we have learned about doing it well.
I want to answer four questions:
- 01Are EPR programmes mostly poorly delivered change programmes?
- 02Why is the human side so critical to the outcome?
- 03If we know it is critical, why do we keep doing it so poorly?
- 04And what does HSS do to help Trusts do this part better?
Are EPR programmes mostly poorly delivered change programmes?
According to NHS England and most of the studies on the subject — yes.
In 2016, the government asked Robert Wachter to work out why NHS IT kept failing. This was after the National Programme for IT collapsed, having cost the best part of £7 billion. His conclusion, in his own words, was that digitising effectively is “not simply about the technology. It is mostly about the people.” Failed engagement with the workforce, not failed software, was the through-line.
Digitising effectively is not simply about the technology. It is mostly about the people.
That was ten years ago, and in the decade since, the same problem has been noticed repeatedly.
By NHS England’s own recent figures, 44% of clinical staff report having had no further EPR training since the day they joined their organisation. 60% of doctors and 70% of nurses say they would welcome more. NHS England now says the next phase depends on “leadership, workforce capability and service redesign.” When the national body has to tell you the people side is what matters now, that is a quiet admission it was not done before go-live, or in the months or years of optimisation since.
The clinical leaders who have lived through it put it more bluntly. One Midlands-region CDIO, writing this year after a major go-live, said the real success or failure of these programmes has very little to do with the technology itself.
So here is the paradox at the centre of all of this. Everyone agrees the human side decides the outcome, and everyone agrees it is the part we deliver worst. When something is universally acknowledged and universally underdone, it is tempting to blame institutional failings, or the EPRs themselves. I think there is a structural reason it keeps happening.
Why the human side is so critical
Joseph Campbell, the mythologist, said something decades ago that is the best one-line description of the core problem with any IT system, let alone an EPR:
Computers are like Old Testament gods: lots of rules, and no mercy.
Your EPR is the merciless rule-engine. It is rigid and unforgiving of exceptions. Clinical reality is the opposite: judgement, ambiguity, patients who do not cleanly fit an idealised pathway of care. The human layer exists to stand between that merciless system and that messy reality — and where no one builds it, staff quietly invent their own private rituals to make peace with a god they cannot know. It’s a dramatic metaphor, but the comparison holds uncomfortably well.
There are two mechanisms at work, and the single word “culture” tends to hide the difference between them.
The knowledge gap
The first is a knowledge gap. Before you can train anyone on a process, someone has to understand that process end to end and describe it — and processes are not equally describable.
Think about ordering and collecting bloods. It is intensely clinical and intensely physical, yet it goes into almost every EPR relatively cleanly. The inputs are finite, the rules are clear, and there is one integration to the lab. Most of the difficulty is in making one system talk to another. Once that is done, the EPR presents the process so smoothly that people forget there are real humans in the lab, and start to imagine the results arrive by magic. The worst that tends to happen at go-live is a mislabelled bottle.
Safeguarding is the opposite. I have never worked with a Trust that found it easy to put into a system. It is irreducibly a matter of judgement. It has to be operated by a huge range of staff. It differs in every Trust, and it reaches beyond the Trust into the local authority, the police, and other services no one controls.
What separates these two is codifiability. A process is hard to digitise to the degree that it depends on tacit judgement, must absorb many exceptions, and crosses many organisational boundaries. How clinical it is, or how close it sits to IT, barely matters.
The human work in an EPR programme is heaviest exactly where a process resists being reduced to rules, and healthcare is full of those processes.
The will gap
The second mechanism is harder to solve, and is best described as a will gap.
Suppose you have closed the knowledge gap completely, so that the process is understood, described and trained to perfection. You will still be worked around. In a high-pressure moment, the member of staff at the keyboard faces a simple sum:
The benefit of doing it properly is diffuse, arrives later, and lands on someone else: the analyst, the next clinician, the population-health team, the business case no one at the bedside has read — even if they were given the opportunity to.
This is not laziness, and health informatics has a name for it: the workaround. The research is consistent. Workarounds are rational responses to a mismatch under pressure. They give the individual a short-term win while creating risk for the patient, the organisation and the data. Staff write things on paper. They keep a shadow spreadsheet. They pass the information to the next person by word of mouth. Each one is a sensible local choice that quietly erodes the collective benefit the system was bought for.
This is a commons problem, and you cannot train your way out of a commons problem. More of the training that failed to change the incentive will not change the incentive.
It also has a shape most people in this field will recognise. Performance drops after go-live before it recovers — the J-curve. Industry data puts the early productivity hit at somewhere between 10% and 40%, lasting weeks or months. How deep that trough goes, and how quickly an organisation climbs out, depends largely on how well the human layer was handled.
The software decides whether you can recover. The people decide whether you do.
If we know it is critical, why do we keep doing it so poorly?
If we all know this, why does it keep happening? Several reasons — and they compound on each other.
The work is genuinely hard, and hard in an invisible way. To describe a process end to end, you have to bring everyone who holds a piece of it into one room, get them to understand each other’s work, and codify the whole thing without dropping anything and without drifting into the next process along. The documentation that should already capture this is usually missing or out of date. And the more stakeholders a process has, the harder it is to map in a way that satisfies all of them.
An EPR programme does more than describe how the work is done. It prescribes how the work will be done from now on, because the configuration encodes a decision. That decision is usually made by a build team under time pressure, often without the people who actually do the work present. So the real failure is rarely just a process described wrongly. More often it is a process whose design was settled by the wrong people, and found to be wrong at (or just before) go-live, when it was too late to change. This is exactly what user-centred design exists to prevent.
There is also a trap hidden in the bloods example from earlier. Bloods feels easy now, but it was not easy. Someone in the programme did the hard human work of defining and integrating it, and that work then became invisible. A clean process is a monument to successful human work that no one can see any more — not evidence that the work was ever simple. That invisibility drives underinvestment: leaders look at the processes that already work, conclude the system works, and underestimate what the messy processes will cost. The better the past work was, the more it tempts you to skip the same work next time.
Add time pressure, and the fact that there is always easier and equally important work to get on with, and the human side simply does not get done. Its importance only comes into focus when someone finally has to fit all the clean pieces together and works out, by elimination, which pieces have been missing all along. Usually that someone is a systems trainer — or, in programmes without a robust training workstream, a staff member at go-live. A commons problem is invisible precisely because no one owns it, and you cannot escalate, resource or govern what no one can see.
What we actually do about it
Everything in this part of the piece is shaped by recognising the challenges above and working to resolve them directly, instead of trying to work around or on top of them. Our approach has two layers: first a method — a disciplined way of working that is required to resolve or mitigate these challenges — and second a set of systems we built to serve that method. The method directs the response; the tools exist to make it repeatable, measurable and affordable, not the other way round.
It is worth being clear about why the method comes first, because the temptation is always to reach for a tool instead. Technology takes the skill of a few people and makes it repeatable for many — increasingly it does so without asking the user to understand what sits underneath. You do not need to know how a smartphone works to use it; the entire experience is designed to be as low-effort as possible. But there is another way to use technology — the one required for serious work.
Faced with any software, including an EPR, the instinct is to use it like social media — or, more charitably, like a smartphone. As people who do this for a living, it is frustrating to watch; but it is not the users’ fault. It is the rational response when no one has told them they are closer to flying a jet, and then shown them how. You have bought a system that should let clinicians do more than any generation before them, and most of the time it is used at the level of a phone app. Closing that gap is the work. So our approach — establishing a method and a goal, instilling it in our teams, then using bespoke systems to maximise, enable and enforce good work — is really just practising what we preach with EPRs.
Making the process knowable
Against the knowledge gap, the aim is simple to state and hard to do: understand a process fully before anyone tries to build it or teach it. A few principles follow from that.
Recognise, and properly value, a role that EPR programmes rarely name. It sits between the subject-matter expert, who knows how the work is really done, and the build or configuration analyst, who knows what the system can be made to do. Doing it well takes someone technical enough to follow the build, social enough to sit with a ward sister and a workstream lead and reconcile two different accounts of the same process, and disciplined enough to write the result down so clearly that someone else can train from it. That combination is rare, and it is the real work of a senior or principal trainer. Suppliers often hand it to junior analysts, and Trusts often default to their existing systems trainers. It is a different job, and treating it as the same one is where a great many programmes quietly come undone. In practice it means we do not ask everyone the same questions: we talk to workstream leads about the build and to subject-matter experts about the daily work, then reconcile the two into a single account and hand it back to both sides to confirm we have it right. The Trust keeps that account, along with the procedures and trained super-users that come out of it. This is also where user-centred design earns its place, as the discipline that stops the wrong people quietly deciding how the work will be done.
Hold complexity rather than hide from it. A real process has more inputs, dependencies and exceptions than anyone can carry in their head, and a spreadsheet will not hold them reliably. So we put that structure into a system that carries it for us and surfaces to each person only the part that is theirs. The reason is practical rather than tidy: it frees skilled people from clerical load so they can spend their attention where human judgement is actually needed, and it lets measurement fall out of the work itself instead of becoming a separate reporting exercise laid on top. Managers and systems should serve the people producing the work, and good metrics should be a by-product of that work being done rather than a tax on it.
Make it as easy as possible for people to give us what we need, because the information that shapes a programme is scattered across hundreds of busy people. The easier we make contributing, the more complete and current the picture stays.
Fix adjacent problems when they touch our work, rather than defending the edge of a contract. When something upstream is unclear and it will damage what we deliver, it is worth the time to help put it right. This is why we keep genuine development capability in-house, which is unusual for a consultancy our size, and it is how some of our most useful features came about. We built a way to link the clinical-safety hazards that are mitigated by training directly to the materials that mitigate them, so that safety and training stop being two separate conversations, and we have tied training completion to practical things like system access. None of that sat in a scope document. It came from treating a gap in the programme as our problem too.
Underneath all of it is one habit worth naming on its own: we work to the outcome, not the indicator. A KPI is only a proxy for the result it is meant to track, so when the two pull apart we ask honestly whether the team has underdelivered or the measure has simply stopped describing the work.
Making the right thing the easiest thing
Against the will gap the aim changes. Here a process can be perfectly understood and still ignored, so the work is to make the right action the easiest one to take, and to make people want to take it.
The starting point is an uncomfortable truth. In healthcare our work will almost never be the priority for the end user, however well we argue its importance, because there is usually a patient in front of them who matters more. So we design for that reality by stripping out friction wherever we can. At the scale of training a whole Trust, that means making it as simple as possible to tell us who needs training on what, and as simple as possible to book it. In the classroom it means training that is salient and immediately useful, so the time spent pays off there and then rather than in the abstract. And alongside making the right thing easy, we work to make people want to do it, by being clear and honest about why it matters rather than relying on instruction alone.
We also set expectations deliberately. At the outset we agree a hard, high and realistic minimum: the deliverables and standard we will not drop below. Then we aim to beat it. A gold standard keeps the work ambitious, while a fixed floor makes sure that ambition never becomes the enemy of a complete, delivered result.
The last part of this is honesty, especially with leadership — and it is also our answer to a limit we cannot escape. We cannot override a programme board; no supplier can, and frankly none should be able to. What we can do is make a human-side risk legible and evidenced, and put it in front of the people who own it, in their language, so that it becomes a conscious, documented decision rather than an invisible one. Where a risk touches patient safety it is more than our opinion, because it has a formal home in the clinical safety case, and the hazard-to-training links I mentioned earlier are part of how we evidence it. That honesty has to run both ways: when we get something wrong, we say so early and bring a solution with us. Leaders can only act on information they trust, so earning that trust is part of the method rather than a courtesy on top of it.
Tools built to serve the method
A method like this does not scale on goodwill and spreadsheets, which is why we built our own systems. Each one carries a part of the method that would otherwise depend on individual heroics, and each came from meeting the same problem often enough that we decided to make good practice the default. This is the second half of practising what we preach: having settled the method and the goal, we use bespoke systems to enable and enforce it, exactly as a well-run EPR should for the clinicians using it.
Our Training Development Management System (TDMS) is an example of where we hold the complexity. It keeps the whole structure of training development — every role, module and dependency — and shows each person only the slice relevant to them, which is, fittingly, how a good EPR behaves. It carries the structural load so our people are free for the judgement, and it lets progress and quality be read straight off the work rather than chased separately.
Our TMA tool is an example of how we make contributing easy and readiness visible. It maps staff to the right training and coordinates booking across a whole Trust, and in doing so it turns the human layer from a guess into something you can see — down to the team, the supervisor, and the individual who is still not booked. That is what lets leadership act on specific risks rather than on a vague sense of trepidation. You cannot manage what you cannot see, and most programmes cannot see this clearly in one place.
Our go-live tool, TAIC, is an example of how we get support to the point of need. A member of staff can ask for help where they are, and we send the right floorwalker or super-user — with the right system knowledge — straight to them. Support arrives faster, without getting lost in a queue, and it usually takes fewer people on the ground, which lowers the cost of the thing that works best.
What we don’t lean on
We are clear, too, about what does not do this job. Our own tools serve the method — they do not stand in for it — and neither does anyone else’s technology. Good interface design is real, and it does a great deal to filter information and surface what matters, but it cannot fix an incentive problem or tame a process that is irreducibly about judgement and crosses organisational boundaries. Safeguarding does not become easy because the screen became prettier.
And then there is AI, sold as the mercy for Campbell’s merciless god: the scribe, the assistant that removes the clicks. My worry is straightforward. AI works from a flattened, generalised model of the world, built from what everyone says and what can be looked up. It does not know the specific, unwritten context held in a particular Trust’s memory, so it will produce a fluent and confident account of how your process works that is wrong in precisely the ways that matter. I call that confident incompetence, and it is more dangerous than an obvious gap, because someone will believe it at a glance. AI raises the stakes on getting the human and process layer right; it does not remove the need to. Put it on top of an undescribed, worked-around process and you have automated the mess — faster, and with more conviction.
What it looks like in practice
The Trust went live without bringing in any external floorwalking support, using only our end-user trainers and the Trust’s own Navigator programme. They could do that because, by go-live, 98% of staff had been trained, and trained properly.
It came together as method and tools working as one. We built the training materials in TDMS, so they were role-based from the start. TMA gave leadership the overall picture of who was booked and who had attended, and let us drill in to show the CCIO and the CNIO exactly which supervisors still had staff who were not booked. Those leaders then contacted the supervisors directly.
The data fixed nothing on its own. It worked because the Trust’s leadership recognised what it allowed them to do, and used it. The credit for the Navigator programme belongs to the Trust, and it was genuinely excellent; our part was making sure the systems training inside it was well-organised and properly role-based.
Beyond the go-live
This is the point at which “live” stops being the finish line. The same data that coordinates go-live support is also a live map of where your processes and your training are failing. When you break down what go-live tickets are actually about, the largest category — by a long way — isn’t broken software. It’s people needing to be shown how to work.
That is the instrument the whole sector now needs, as the question shifts from “do you have an EPR?” to “is it actually working?” Optimisation uses the same method as implementation, applied at the moment most programmes stop paying attention. The sector is only now arriving at this question — but the method and the tools are the same ones that get you safely through day one.
In closing
So here is a question worth sitting with. How many of your staff were trained on your EPR once, at go-live, and never again? If the honest answer is “most of them” — or the best thing you can say about your training is “it exists” — then that is probably where your productivity gap is sitting right now. It is the distance between the system you bought and the system being used like a phone app, and it is the most fixable problem you have, because, unlike the technology, it does not need a re-procurement or another decade. It needs the human side taken as seriously as the technical side.
When I was putting these ideas together, I asked some of the people we have worked with — and one of our own training managers — what HSS actually does differently from other implementation partners. The answer that kept coming back was a version of “you lot actually give a damn.” The real version is a little too blue to print, but that was the gist. It is a kind thing to hear, and useless on a page, because I cannot simply tell you we care more than the next supplier and expect you to believe it. Everyone says it.
So I have not asked you to take it on trust. Everything above is the evidence instead: a method we hold to, and a set of tools we built ourselves to serve it, refined over five years on real programmes, because we decided this was the part worth being best at. That, more than anything I could claim, is what caring about this work looks like.
What it has mostly made us is the people you call once it has already gone wrong. We have built a reputation for rescuing training and go-live workstreams — doing in three months what a programme failed to do in twelve, after it failed. We are proud of that. But we would still rather join programmes sooner.