Written by Technical Team | Last updated 21.10.2026 | 14 minute read
For much of the last decade, NHS digital transformation has been dominated by acquisition and deployment. Electronic patient records have been procured, infrastructure refreshed, patient portals introduced, data platforms established and national services connected into local technology estates.
That phase is not over, but the engineering problem is changing. Most NHS organisations now have many of the core systems they need. The more pressing question is whether those systems are configured, integrated and operated well enough to deliver the value expected from them.
NHS England is increasingly explicit about this shift. With EPR coverage now widespread, the emphasis is moving from deployment towards optimisation: improving configuration, simplifying high-volume workflows, using existing data more effectively and getting digital systems embedded properly into operational practice. National funding is also being directed towards areas such as EPR optimisation, infrastructure and digital medicines with a clearer expectation that investment should translate into productivity.
This changes what useful digital transformation work looks like.
Installing another application is sometimes necessary. But a surprising amount of untapped value sits inside technology the NHS has already licensed, deployed and connected. It is trapped in poorly configured workflows, duplicated data entry, weak integrations, unused functionality, inconsistent local implementations, manual hand-offs and processes that were digitised without being redesigned.
The opportunity is therefore not simply to make existing systems faster. It is to treat the installed technology estate as an engineering system that can be continuously measured, modified and improved.
An implementation programme tends to work towards a relatively clear event: go-live. There is a defined scope, a target date, migration activities, testing, training and operational readiness. Once the system is stable enough to support clinical activity, the programme gradually transitions into business-as-usual support.
Optimisation has no equivalent endpoint.
A live EPR may contain thousands of configuration decisions covering forms, order sets, alerts, documentation templates, work queues, security models, clinical decision support, task routing and specialty-specific workflows. Those decisions interact with integrations into laboratory systems, imaging, pharmacy, PAS functionality, departmental applications, external services and national infrastructure.
They also interact with people.
A workflow that appeared reasonable during implementation may behave very differently under real operational load. Staff may discover that they need to move between several screens to complete a common task. Information needed at one point in a pathway may have been captured elsewhere but cannot be surfaced automatically. An electronic form may reproduce every field from its paper predecessor even though half of them serve little current purpose. Clinicians may create free-text workarounds because structured capture is cumbersome. Administrative teams may compensate for gaps between systems by exporting spreadsheets and manually reconciling records.
These are rarely dramatic failures. The system works. Patients continue to be treated. The problems appear as thousands of small pieces of friction repeated across thousands of interactions.
NHS England’s national EPR usability work gives some indication of the scale. Only around a third of respondents reported that their EPR made them more efficient, while substantial numbers of clinicians and nurses reported spending at least three hours each week on charting they regarded as duplicative or adding little value.
That is exactly the sort of problem an optimisation programme should attack.
The engineering unit of analysis needs to move below “the EPR” or “the patient portal” and towards individual workflows and transactions. How many interactions does it take to request a test? How many systems are opened during medicines reconciliation? Where is the same demographic or clinical information re-keyed? How many manual actions sit between an outpatient appointment being created and the patient seeing it in the NHS App? What happens when an interface fails halfway through that process?
A system can be technically live while hundreds of these journeys remain inefficient.
The useful question is not whether an organisation has deployed the technology. It is whether each important workflow is using that technology well.
NHS digital transformation is increasingly about optimisation, not just implementation. With electronic patient records (EPRs), digital infrastructure and national NHS services now widely deployed, some of the biggest productivity gains can come from improving existing clinical workflows, EPR configuration, system integration and data use. For NHS organisations, the opportunity is to extract more value from the technology already in place before adding further complexity through new procurement.
The easiest optimisation work to identify is often user-interface friction: too many clicks, difficult navigation, poor defaults or cumbersome forms. These are worth fixing, but treating optimisation as a usability exercise alone misses much of the opportunity.
A clinical workflow commonly crosses several technical boundaries.
Consider a fairly ordinary outpatient pathway. A referral may arrive through e-RS, be registered in a patient administration system, pass through clinical triage, generate an appointment, trigger communication through a patient engagement platform or NHS Notify, create activity inside an EPR, lead to diagnostic orders, generate results from laboratory or imaging systems and eventually create follow-up tasks or correspondence.
Optimising the EPR screen used by the clinician addresses only one section of that chain.
Useful optimisation starts by modelling the complete workflow, including the parts performed outside the nominal “main” system. That means observing real users rather than relying solely on documented processes. Actual workflows often contain additional email inboxes, shared folders, spreadsheets, phone calls, printed lists and informal task queues that disappeared from the official process map years ago.
Once the current workflow is understood, individual steps can be classified. Some are clinically necessary. Some exist for legal, regulatory or audit purposes. Others are historical artefacts, duplicate controls or compensating processes created because systems do not communicate properly.
The technical options then become clearer.
A value already held in the EPR may be used to pre-populate another form. A referral status could be propagated through an API instead of copied manually. An event from a departmental system might automatically create a task rather than relying on staff to monitor a queue. A patient communication could move from SMS to an existing national messaging capability. Duplicate demographic validation could be removed where an authoritative source such as PDS is already being used.
Some improvements require configuration rather than software development. Others require integration, changes to data models, workflow automation or modification of surrounding services.
The important thing is to optimise the transaction rather than one application in isolation.
This becomes especially powerful where the transaction is performed at high volume. Removing thirty seconds from an obscure workflow used ten times a month achieves little. Removing thirty seconds from a task performed 40,000 times a week produces a meaningful operational effect.
A practical optimisation backlog should therefore consider frequency as well as severity. Useful inputs include application telemetry, audit logs, service desk data, EPR usability feedback, integration monitoring, user observation and process-mining data where available.
The highest-value candidates tend to combine several characteristics:
This also changes how work should be prioritised. Large transformation programmes naturally favour large deliverables. Optimisation often produces value through dozens of smaller changes whose individual business cases would never justify a formal project.
That requires a different delivery model.
There is a tendency to think of the installed base as the products an organisation has bought: its EPR, PAS, integration engine, data platform, patient engagement tooling and specialist clinical applications.
The real installed base is larger. It includes configuration, interfaces, terminology mappings, master data, workflow rules, identity models, reporting pipelines, operational processes and the knowledge required to maintain all of them.
This distinction becomes important as systems mature.
EPR implementations accumulate configuration debt in much the same way bespoke software accumulates technical debt. Templates are added for individual departments. Rules are introduced to solve local problems. New alerts appear without old ones being removed. Order sets diverge. Temporary workarounds become permanent. Upgrades introduce capabilities that are never incorporated into existing workflows.
After several years, two organisations running the same underlying product can have radically different experiences.
NHS England’s usability data illustrates this indirectly: substantial variation exists between organisations using products from the same suppliers. Product choice therefore cannot explain the entire difference in performance. Local configuration, governance, training, implementation quality and continuous improvement all influence the outcome.
Optimisation should consequently include regular refactoring of configuration.
This might mean reviewing heavily customised workflows against current vendor capability, removing redundant alerts, consolidating templates, improving defaults, rationalising role-based access or identifying functionality introduced by later releases that can replace locally developed workarounds.
Integration deserves similar treatment.
Interfaces frequently become invisible infrastructure once they work. Yet optimisation opportunities often sit precisely at these boundaries. A clinically useful workflow may still depend on nightly batch transfers when a modern API or event-based interaction is available. Structured information may arrive but be flattened into text. Identifiers may be repeatedly translated between systems. Error handling may send messages into operational queues with little context, creating manual investigation work.
Replacing a system because users experience friction caused by these interfaces would solve the wrong problem.
Instead, integration should be analysed as part of the workflow. For each important data movement, teams should understand the source of truth, transport mechanism, expected latency, error behaviour, reconciliation process and downstream use of the data.
The same applies to national services.
An organisation may already have access to NHS App capabilities, NHS Notify, e-RS APIs, EPS, GP Connect or other national infrastructure without having integrated them deeply enough into local processes to extract their full value. The marginal value is often created not by acquiring another patient-facing product, but by connecting existing local workflows to capabilities that already exist.
A good example is appointment management. Making an appointment visible in the NHS App is useful. Allowing the patient to cancel or rearrange it is more useful. Ensuring that cancellation immediately updates the authoritative scheduling system, releases capacity, triggers the correct downstream workflow and prevents unnecessary communications is where the operational value emerges.
That requires considerably more than exposing data through a front end.
Data platforms present another version of the same problem. Many organisations have invested heavily in collecting and aggregating information. Optimisation asks whether the data is influencing operational behaviour.
A waiting-list dashboard that accurately reports a problem after the fact may be useful for management. A workflow that identifies records requiring validation, routes them to the appropriate team, records the intervention and feeds the outcome back into the operational system is considerably more valuable.
The progression is from visibility to action.
That generally requires tighter integration between analytical platforms and operational systems rather than another layer of reporting.
Continuous optimisation needs a different operating model from implementation.
If every change requires a new business case, programme board and procurement exercise, most small improvements will never happen. If changes are simply handed to a generic support queue, they compete with incidents and maintenance and rarely receive sustained multidisciplinary attention.
A better model resembles product development around the installed estate.
The team needs access to clinical and operational expertise alongside people who understand the technical platform. Depending on the workflow, that may include an EPR analyst, integration engineer, data engineer, service designer, clinical informatician, product manager and representatives from the service itself.
The composition can remain small. The important characteristic is the ability to follow a problem across organisational and technical boundaries.
Work should begin with observable problems rather than requested features. “Add another field” is a request. “Ward teams cannot reliably see whether transport has been arranged before discharge” is a problem. The latter leaves open several possible solutions, including configuration, integration, changed process or removal of unnecessary steps.
Measurement needs to be designed before implementation. Useful measures tend to sit close to the workflow: task completion time, number of manual interactions, turnaround time, duplicate entries, support tickets, failure rates, abandoned transactions, appointment utilisation, documentation time or percentage of a process completed digitally without manual intervention.
Where clinical outcomes or patient experience can sensibly be connected to the change, they should be. But optimisation teams should avoid creating elaborate benefits models where the direct operational effect can be measured from system data.
Instrumentation is therefore essential.
Most mature systems already generate logs, audit trails and transaction histories, but these are often used primarily for troubleshooting and governance. They can also expose behaviour. Frequency distributions reveal rarely used functionality. Sequence analysis shows where users repeatedly move backwards through a workflow. Interface monitoring reveals retry patterns and latency. Service desk categorisation highlights areas where system behaviour routinely confuses users.
Process mining can be particularly useful where events across a workflow can be tied together reliably. It can expose variation between intended and actual pathways, repeated loops, waiting periods and unexpected routes through a process.
None of this removes the need to watch people work. Telemetry reveals what happened; observation often explains why.
Changes should then be delivered incrementally and tested against the original baseline. An optimisation that merely shifts work from one professional group to another is not necessarily an improvement. Nor is a faster digital workflow that creates poorer structured data or additional clinical risk downstream.
Clinical safety therefore belongs inside optimisation rather than at its end. Changes to decision support, medication workflows, documentation, patient identification or the presentation of clinical information may alter existing hazards even if no new product is being introduced. The relevant clinical safety process needs to reflect the actual change and its potential failure modes.
The same principle applies to information governance, accessibility, cybersecurity and operational resilience. Existing technology does not make a new workflow automatically safe merely because the underlying product has already been deployed.
Optimisation is modification of a live socio-technical system. It needs the same engineering discipline as any other production change.
There will continue to be legitimate reasons to buy technology. Some platforms reach the end of their useful life. New clinical models create requirements that existing products cannot support. AI, remote monitoring, diagnostics and patient-facing services will introduce capabilities that are genuinely new.
But procurement should increasingly compete with optimisation for investment.
Before acquiring another application, organisations can ask whether the required capability already exists somewhere in the estate; whether an existing platform can provide it through configuration; whether two systems could meet the requirement if integrated properly; whether an existing national service already provides the necessary component; or whether the underlying problem is a poorly designed workflow rather than absent technology.
That analysis can prevent a familiar pattern in healthcare IT: buying a new layer to compensate for weaknesses in the layers underneath it.
Over time this creates an increasingly complicated estate. Another portal is introduced because information in the EPR is difficult to expose. Another workflow tool is introduced because tasks do not move cleanly between systems. Another data repository appears because operational data is difficult to access. Every additional product then creates another set of identities, interfaces, support responsibilities, licensing costs and data flows.
Sometimes the new product is still the correct choice. The discipline is to make it compete against the cost and feasibility of improving what already exists.
There is also a broader architectural benefit. Extracting more capability from established platforms reduces unnecessary system proliferation and concentrates engineering effort on the interfaces and workflows that connect care.
This is particularly relevant as NHS services become more distributed. Care increasingly spans acute, community, primary care and patient-facing digital channels. Optimising a single organisation’s EPR will therefore deliver diminishing returns if the surrounding pathway still relies on weak information exchange and manual coordination.
The installed-base opportunity ultimately extends beyond individual products. It is the opportunity to make the existing NHS technology estate behave more like a coherent system.
That means configuring systems around real clinical practice, improving the interfaces between them, removing unnecessary manual work, exploiting capabilities already paid for, strengthening the quality and movement of data, and measuring whether each change returns time or improves care.
The NHS has spent years establishing its digital foundations. The engineering task now is to make those foundations work much harder.
Is your team looking for help with technology delivery? Click the button below.
Get in touch