Topic 4.6 — Electronic Patient Records & Clinical Systems

The electronic patient record is the operational backbone of a modern hospital, so how you select, configure, deploy and keep optimizing it is a clinical-safety, workforce-productivity and public-money decision that will shape care for a decade — not a one-off IT procurement.

Why this matters in health and care#

The electronic patient record (EPR) is the single system through which most clinical work now flows. Doctors and nurses read it to know what is wrong with a patient, order the tests and drugs that change the patient's course, and document the decisions that others will rely on hours or years later. When the EPR is good, it makes the safe thing the easy thing: the right dose, the right allergy warning, the results in front of the person who needs them. When it is bad, it buries clinicians in clicks, hides the signal in noise, and quietly reshapes clinical behaviour in ways no one intended.

That is why an EPR programme is unlike almost any other technology project you will run. It touches every clinician, every shift, every patient, and it does so at the exact moment care is delivered. A poorly configured order set can propagate a dosing error across a whole hospital; a botched go-live can lengthen every consultation for months; a data migration that drops allergies or resuscitation status can kill someone. The record is also a legal and regulatory artefact — the medico-legal account of what was done and why — so its integrity, availability and auditability carry statutory weight (see Topic 1.6 — Clinical Safety & Risk Management, and Topic 1.7 — Information Governance, Data Protection & Cyber Security).

The stakes are also financial and strategic. An EPR is among the largest single investments a trust ever makes, often tens of millions of pounds over its life, and it locks the organization into a vendor and a way of working for many years. Nationally, the NHS England frontline digitization programme has made a core EPR the baseline expectation for every acute, community, mental health and ambulance provider, tying capital funding to digital maturity. Getting the EPR right is now inseparable from getting the operating model right (see Topic 1.1 — The Operating Model). Getting it wrong wastes public money, exhausts clinicians, and can set an organization back years.

Core concepts#

An electronic health record (EHR) is the systematized, digital collection of a patient's health information. In UK practice the near-synonym electronic patient record (EPR) usually denotes the core clinical system of a provider organization — the record and the tooling clinicians use at the point of care. Around it sits a family of clinical systems, historically described as a hospital information system (HIS): the patient administration system (PAS) that tracks admissions, discharges, transfers and outpatient appointments; clinical documentation; results reporting; and specialty systems for theatres, maternity, emergency and critical care.

Computerized physician order entry (CPOE, also called order communications or "order comms") is the electronic entry of clinical orders — tests, medications, referrals — directly by the ordering clinician, replacing paper and phone calls. It is where much of an EPR's safety value is realized, because orders can be checked, standardized into order sets, and routed automatically. CPOE is closely coupled to electronic prescribing and to clinical decision support, which surfaces alerts and guidance in the workflow (covered in Topic 4.7 — Clinical Decision Support & Clinical Informatics, and Topic 4.8 — Electronic Prescribing & Medicines Management).

Two design choices define an EPR programme. The first is configuration versus customization: configuration tailors the product using the levers the vendor supports (build screens, order sets, roles, rules) and stays inside the supported upgrade path, whereas customization writes bespoke code or structures the vendor did not intend, which is powerful but becomes a maintenance and safety liability at every upgrade. The second is deployment shape: big bang adoption (direct changeover, where the whole organization switches on one date) versus a phased or modular rollout that brings sites or functions live in sequence. Each shape trades risk concentration against integration complexity and "big bang fatigue".

The programme is led as much by clinicians as by technologists. The chief medical informatics officer (CMIO, in the UK usually the chief clinical information officer, CCIO) and the chief nursing information officer (CNIO) are senior clinicians who own the clinical design, safety and adoption of the system — the bridge between the front line and the build. Their discipline is health informatics: applying information and computer science to improve the management and use of clinical information.

Several system-level concepts recur. Data migration is the one-off transfer of historical records from legacy systems into the new EPR — technically routine, clinically fraught. An integration engine (interface engine) routes messages between systems using standards such as Health Level Seven (HL7) and FHIR (see Topic 4.3 — Interoperability & Data Standards). A health information exchange or shared care record lets organizations across an area read each other's records. And because the record is safety-critical, downtime procedures — the business-continuity plans for when the EPR is unavailable — are a core part of the system, not an afterthought (see Topic 3.9 — Business Continuity & Disaster Recovery). Digital maturity is commonly benchmarked with the Electronic Medical Record Adoption Model (EMRAM) from the Healthcare Information and Management Systems Society (HIMSS), a 0–7 scale of clinical-system capability.

Best practices#

1. Make clinical leadership the spine of the programme, not a consultee. An EPR succeeds or fails on whether clinicians own it. Appoint and properly resource a CCIO and CNIO with real authority and protected time, build a network of clinical "digital champions" in every specialty and ward, and give clinical design leadership genuine decision rights over build and configuration. The pattern that fails is a technically-run programme that "engages" clinicians through occasional workshops; the pattern that works treats practising clinicians as co-authors of the system they will use every shift.

2. Configure to the supported product; customize only with eyes open. Every bespoke customization is a debt you repay at every upgrade, and a hidden clinical-safety surface no one re-tests. Default to configuring within the vendor's supported model, adopt the product's tested content and order sets where they are safe, and reserve true customization for the few places where a genuine clinical or statutory need cannot be met otherwise — each one documented, risk-assessed and owned. Resist the urge to rebuild your old system inside the new one; "make it work like the paper form" is how organizations pay for a modern EPR and inherit their legacy problems.

3. Choose the deployment shape deliberately, and de-risk whichever you pick. Big bang concentrates risk on one date but avoids the pain and cost of running two systems in parallel and integrating them; a phased or modular rollout spreads risk and lets you learn, but multiplies interfaces, dual-running and change fatigue. Decide based on your risk appetite, integration complexity, and how much clinical disruption the organization can absorb at once (see Topic 8.0 — Phasing in Innovation). Whichever you choose, invest disproportionately in the cutover: rehearsed dry runs, a command centre, mass floor-walking support in the first weeks, and a clear, practised rollback position.

4. Treat data migration as a clinical-safety exercise, not a data-plumbing task. Deciding what history moves into the new record — and verifying it arrived correctly — is where migrations harm patients, through dropped allergies, mismatched identifiers, or truncated medication histories. Agree explicitly what migrates automatically, what is summarized, what is left in a read-only archive of the legacy system, and how clinicians will reach it; then reconcile and validate migrated data with clinical sign-off before go-live. Never assume a field mapped cleanly because the load ran without errors — a technically successful migration can still be clinically wrong (see Topic 4.9 — Data Quality & Master Data Management).

5. Plan for the productivity dip, and fund the optimization that follows it. Almost every EPR go-live is followed by a period of reduced throughput as staff learn the system, and organizations that pretend otherwise damage both safety and morale. Reduce elective activity deliberately around go-live, protect training time, and set realistic recovery trajectories with the board so the dip is a planned event, not a crisis (see Topic 8.1 — Change Management). Crucially, budget and staff for continuous optimization afterwards: the value of an EPR is realized in the years after go-live, through iterative tuning of workflows, order sets and alerts — a product discipline, not a project that ends at cutover (see Topic 5.0 — Product-Led Work).

6. Design order sets, alerts and workflows to reduce burden, and govern them continuously. The clinical build is where an EPR either saves cognitive load or adds it. Standardize order sets around good evidence, tune decision-support alerts so clinicians see the few that matter rather than drowning in low-value pop-ups, and measure documentation burden as a first-class outcome. Establish a standing clinical-informatics governance group that owns the build over time, reviews alert firing and override rates, and retires content that no longer earns its place (see Topic 4.7 — Clinical Decision Support & Clinical Informatics).

7. Build downtime and business continuity into the record from the start. The EPR will one day be unavailable — through a failed upgrade, a network outage, or a ransomware attack — and a hospital that cannot function on paper for those hours is a patient-safety incident waiting to happen. Provide read-only access to a recent copy of the record during outages, maintain rehearsed paper-based clinical workflows, and practise both planned and unplanned downtime so staff are not improvising under pressure. Agree the recovery-time and recovery-point objectives for the clinical record explicitly, and test the reconciliation of paper records back into the system after recovery (see Topic 3.9 — Business Continuity & Disaster Recovery).

8. Realize benefits deliberately, and measure the outcomes you promised. An EPR business case rests on safety, quality and efficiency benefits that do not appear automatically; they must be designed for, owned and tracked. Baseline the metrics before go-live, tie each benefit to a named owner and a workflow change, and review realization against the case at defined intervals rather than declaring victory at cutover (see Topic 6.2 — Benefits Realization & Value Management). Use a recognized maturity benchmark such as HIMSS EMRAM to give the board an external, comparable measure of progress rather than only internal anecdote.

9. Manage convergence and interoperability as a system, not just a trust programme. Across an integrated care system (ICS), the strategic pull is towards fewer EPR instances and a shared care record so a patient's information follows them between organizations. Converging on a common EPR can cut cost and smooth patient flow, but it concentrates risk and dilutes local control, so weigh it against strong interoperability between distinct systems (see Topic 4.3 — Interoperability & Data Standards). Whatever the shape, insist on open standards and a realistic exit strategy to limit vendor lock-in, because an EPR you cannot get your data out of is an EPR that owns you (see Topic 6.3 — Procurement & Commercial).

Questions to discuss with your team#

1. Who really owns the clinical design of our EPR — and do they have the authority, time and credibility to make hard calls the front line will accept? This matters because the single strongest predictor of EPR success is genuine clinical ownership, and the single most common failure is a programme that is technically competent but clinically hollow. Debate whether your CCIO and CNIO have protected sessions, a real budget, and decision rights, or whether they are respected figureheads overruled by delivery timelines and vendor defaults. Surface the tension between clinical variation and standardization: every specialty wants its own build, but a thousand local variants become unmaintainable and unsafe. Consider how disputes are actually resolved today — by clinical consensus, by the loudest voice, or by whoever controls the schedule. Look at whether front-line champions exist in every area or only on paper. A good, honest answer names the accountable clinical owners, admits where authority is currently too thin, and describes a governance route where clinical design decisions are made by clinicians and stick.

2. What will the productivity dip actually cost us, and has the board signed up to it with eyes open? Almost every go-live slows the organization down before it speeds it up, yet business cases and boards routinely assume a smooth curve, setting the programme up to be judged a failure precisely when it is behaving normally. Discuss how far you will deliberately reduce elective activity around go-live, how long recovery realistically takes for your specialty mix, and what you will tell regulators and patients about waiting times during that window. Weigh the trade-off between a shorter, sharper dip with heavy upfront support and a gentler, longer one — and who bears the operational and financial risk of each. Probe whether training hours are truly protected or the first thing sacrificed when the rota is tight. Consider what leading indicators would tell you the dip is deeper or longer than planned, and what your response would be. A good answer states a planned, funded, board-endorsed dip with recovery trajectories, not a hope that clinicians will simply absorb it.

3. When the EPR goes down, can we still run a safe hospital — and when did we last prove it? The record is now so central that its unavailability is a clinical emergency, yet downtime procedures are often the least rehearsed part of the whole programme. Discuss which clinical functions would be most dangerous to lose, whether staff can actually reach a recent read-only copy of the record during an outage, and whether the paper fallback workflows exist and are practised or are dusty binders no one has opened. Surface the hardest scenario — a prolonged, unplanned outage such as a cyber-attack lasting days, not the tidy planned upgrade window — and whether your recovery-time and recovery-point objectives for the clinical record are agreed and tested. Consider the reconciliation problem: how paper records created during downtime get safely back into the system afterwards without losing or duplicating information. A good answer points to recent, realistic downtime exercises, named objectives for the record, and staff who know what to do rather than a plan that has only ever existed on paper.

4. Where are we drawing the line between configuring the supported product and building our own, and who is accountable for every exception? Every bespoke customization feels justified in the moment — a clinician's strong preference, a workflow the old system supported, a report someone insists on — but each one is a debt repaid at every upgrade and a clinical-safety surface no one re-tests. Discuss whether you have a stated configure-to-supported principle or whether customization decisions are made ad hoc, module by module, under delivery pressure. Surface the real tension: adopting the vendor's tested content is safer and cheaper to maintain, but it forces clinicians to change how they work, and "the product doesn't do it our way" is a powerful lobby. Examine who signs off an exception, whether each is documented and risk-assessed, and whether anyone ever revisits and retires the customizations you already carry. Consider how this compounds over a decade and how it shapes your ability to take future upgrades cleanly. A good, honest answer describes an explicit standard, a named route for approving and owning exceptions, and a realistic account of how much bespoke build you are already committed to maintaining.

5. After go-live, who keeps improving the EPR — and is that funded as a permanent function or hoped for as a favour? Most of an EPR's promised value is realized in the years after cutover, through iterative tuning of workflows, order sets and alerts, yet organizations routinely disband the programme at go-live and expect optimization to happen for free. Discuss whether you have a standing clinical-informatics and optimization team with protected staff and budget, or whether improvement depends on goodwill once the project money runs out. Weigh the trade-off between spending to sustain that capability and the pressure to book savings immediately in the business case. Probe how benefits are actually tracked: are they baselined before go-live, tied to named owners and specific workflow changes, and reviewed against the case at set intervals, or quietly assumed to have landed? Consider how you decide which alerts to retire, which order sets to revise, and how the front line requests and sees changes. A good answer names a permanent, resourced function with a clear benefits-realization rhythm, not a project that ends at cutover.

6. Are we optimizing for our own trust or for the wider system a patient actually moves through? The strategic pull across an integrated care system is towards fewer EPR instances and a shared care record, so information follows the patient between hospital, community, mental health and primary care rather than stopping at each front door. Discuss whether your EPR choices strengthen or undermine that: do you insist on open standards and clean interoperability, or are you building a well-run island? Surface the genuine tension between convergence — which can cut cost and smooth flow but concentrates risk and overrides local clinical preference — and strong interoperability between distinct systems that preserves autonomy at the price of more interfaces. Examine how much you are exposed to vendor lock-in, and whether you have a realistic exit strategy and the ability to get your own data out. Consider who at the ICS level is making these calls and whether your local decisions align with them. A good answer shows an explicit position on convergence versus interoperability, a commitment to open standards and safe exit, and an honest view of where local and system interests currently pull apart.

In practice: a health & care example#

Brackenmoor NHS Foundation Trust, a medium-sized acute and community provider, is replacing three ageing systems — a patient administration system, a separate order-comms system, and a patchwork of departmental databases — with a single supplier EPR, funded in part through the national frontline digitization programme. Its current HIMSS EMRAM stage is low, and its business case promises safety and efficiency benefits the board is counting on. The temptation, voiced early, is to "lift and shift" the old ways of working into the new system to minimize disruption.

The programme resists it. A CCIO (a practising consultant) and a CNIO (a senior nurse) are appointed with protected time and given joint sign-off over the clinical build, supported by a digital-champion network reaching every ward and clinic. They set a firm principle: configure to the vendor's supported model and adopt its tested order sets wherever clinically safe, customizing only where a genuine need cannot be met otherwise, with each exception documented and risk-assessed through the clinical safety process under DCB0160. Order sets and decision-support alerts are designed with the specialties that will use them, with a deliberate bias towards fewer, higher-value alerts to avoid burying staff in pop-ups.

Data migration is run as a clinical exercise, not just a technical one. The clinical teams decide that active problems, allergies, current medications and key results migrate into the structured record; older history is summarized or left in a read-only archive of the legacy systems, reachable in one click. Clinicians reconcile and sign off samples of migrated data before go-live, and the team catches a mapping error that had silently truncated some allergy entries — a fix made before, not after, it could harm anyone. The board agrees a planned productivity dip: elective activity is reduced by an agreed amount for six weeks around go-live, training time is ring-fenced, and recovery trajectories are set so the dip is a managed event rather than a surprise.

Brackenmoor chooses a phased rollout by site rather than a single trust-wide big bang, accepting extra integration and dual-running in exchange for the chance to learn between phases. Each cutover runs through a rehearsed command centre with heavy floor-walking support in the first two weeks. Before the first go-live, the trust runs a full downtime exercise — read-only record access, paper workflows, and reconciliation back into the system — because a neighbouring trust's cyber-incident has made the risk vivid. After go-live, the programme does not disband: it becomes a standing optimization and clinical-informatics function that tunes workflows and alerts, tracks the promised benefits against the business case, and moves the trust deliberately up the EMRAM scale over the following two years.

Sector lenses#

Startup#

A digital-health startup rarely sells a full EPR, but it lives or dies by how well it plugs into one. Design for the reality that hospitals run on a core clinical system you do not control: support open standards such as HL7 and FHIR, integrate through the trust's integration engine rather than demanding a bespoke link, and write back into the record cleanly and safely. Your fastest route to adoption is to reduce, not add to, the clinician's click burden inside the EPR they already use. Treat the EPR vendor's ecosystem and the trust's information governance as constraints to design around, not obstacles to complain about.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home or a single-site clinic — usually buys a clinical system rather than building one, and carries the same record-keeping, safety and information-governance duties as a large trust with none of its IT resources. Choose a supported, well-integrated product and resist local customization you cannot maintain, because there is no in-house team to repay that debt at each upgrade. Treat data migration from your old system as a clinical-safety task even at small scale: allergies, current medications and active problems must arrive intact and be checked by a clinician, not assumed correct because the load ran. Plan for the productivity dip too — a handful of clinicians learning a new system can halt a small practice, so protect training time and stagger the change rather than switching everything on cold. Above all, insist on interoperability and a shared care record so your patients' information follows them into the wider system, and on a realistic exit so a single supplier does not own your data.

Enterprise#

A large NHS trust or an ICS running an EPR programme is making a decade-long, multi-million-pound commitment that reshapes every clinical workflow. Its central challenges are clinical ownership at scale, disciplined configuration over sprawling customization, a deliverable deployment shape, and the stamina to fund optimization and benefits realization long after go-live. Convergence across the ICS onto fewer EPR instances offers real prizes — shared records, smoother patient flow, lower unit cost — but concentrates risk and can override local clinical preference, so it must be led with genuine engagement and a clear-eyed view of vendor lock-in. At this scale, the biggest returns come from a few disciplines held consistently — clinical leadership, supported configuration, rehearsed cutover, continuous optimization — not from heroics on any single module.

Government#

National bodies shape the environment every EPR programme operates in. Through NHS England's frontline digitization programme, government sets the expectation that every provider has a core EPR, ties capital funding to digital maturity, and steers the market through convergence and procurement frameworks. Its leverage is to make open standards, interoperability and safe exit the default terms of the market, so individual trusts are not each negotiating from weakness against a small number of large vendors (see Topic 9.1 — Working with Local & National Governments). Government also carries the system-wide learning duty: spreading what works between trusts, benchmarking maturity nationally, and ensuring that a shared care record improves care across organizational boundaries rather than stopping at each trust's front door.

Common failure modes#

• The clinically hollow programme. A technically well-run project that treats clinicians as consultees produces a system no one wants to use. Give the CCIO and CNIO real authority, protected time and decision rights over the build.
• Paving the cowpaths. Rebuilding old paper forms and legacy workflows inside a modern EPR pays for new software and inherits old problems. Adopt the supported product's tested content and redesign workflows rather than replicating them.
• Customization sprawl. Every bespoke change is re-paid at each upgrade and re-opens a safety surface no one re-tests. Configure to the supported model; document, risk-assess and own each true exception.
• The migration that "ran cleanly". A load with no technical errors can still drop allergies or mismatch patients. Reconcile and clinically sign off migrated data before go-live, and keep a reachable legacy archive.
• Pretending there is no dip. Assuming a smooth productivity curve turns a normal post-go-live slowdown into a perceived disaster. Plan, fund and board-endorse a reduced-activity window with realistic recovery.
• Stopping at go-live. Treating the EPR as a project that ends at cutover leaves its benefits unrealized. Stand up a permanent optimization and benefits-realization function.
• Alert overload. Firing too many low-value decision-support alerts trains clinicians to click past all of them, including the ones that matter. Tune, measure override rates, and retire noise.
• Untested downtime plans. A downtime binder no one has opened is not a plan. Rehearse planned and unplanned outages, including reconciliation back into the record.

Maturity model#

Checklist#

• A CCIO and CNIO are appointed with protected time, budget and real decision rights over the clinical build, supported by a digital-champion network.
• The programme configures to the vendor's supported model by default; every customization is documented, risk-assessed and owned.
• The deployment shape (big bang versus phased/modular) is chosen deliberately against risk appetite and integration complexity, with a rehearsed cutover and rollback plan.
• Data migration is run as a clinical exercise: migration scope agreed, data reconciled and clinically signed off, and a reachable legacy archive provided.
• A productivity dip is planned, funded and endorsed by the board, with reduced activity, protected training and realistic recovery trajectories.
• Order sets and decision-support alerts are co-designed with clinicians and governed continuously, with alert firing and override rates monitored.
• Downtime and business-continuity procedures — read-only access, paper workflows, agreed RTO/RPO, reconciliation — exist and are rehearsed for planned and unplanned outages.
• Benefits are baselined before go-live, tied to named owners and workflow changes, and reviewed against the business case after go-live.
• Digital maturity is benchmarked (e.g. HIMSS EMRAM) and used to track progress with the board.
• A permanent optimization and clinical-informatics function continues after cutover.
• Open standards, interoperability and a realistic exit strategy are secured to limit vendor lock-in, aligned with ICS convergence plans.

Key sources#

• NHS England — Frontline Digitisation programme and What Good Looks Like / Who Pays for What digital maturity frameworks for provider clinical systems.
• HIMSS — Electronic Medical Record Adoption Model (EMRAM), a 0–7 international benchmark of clinical-system digital maturity.
• NHS England / NHS Digital — clinical safety standards DCB0129 (manufacture) and DCB0160 (deployment) governing health IT systems including EPRs.
• Faculty of Clinical Informatics and the CCIO/CNIO Network — professional guidance for clinical information leadership roles.
• HL7 International — HL7 v2 and FHIR standards for messaging and integration between clinical systems.
• HM Treasury — The Green Book and Five Case Model for the EPR business case and benefits realisation.
• Wachter Review (Making IT Work, 2016) and the Topol Review — national reviews on digitising NHS providers and the clinical workforce.

References#

1. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
2. Hospital information system — Wikipedia — https://en.wikipedia.org/wiki/Hospital_information_system
3. Computerized physician order entry — Wikipedia — https://en.wikipedia.org/wiki/Computerized_physician_order_entry
4. Clinical decision support system — Wikipedia — https://en.wikipedia.org/wiki/Clinical_decision_support_system
5. Big bang adoption — Wikipedia — https://en.wikipedia.org/wiki/Big_bang_adoption
6. Chief medical informatics officer — Wikipedia — https://en.wikipedia.org/wiki/Chief_medical_informatics_officer
7. Health informatics — Wikipedia — https://en.wikipedia.org/wiki/Health_informatics
8. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
9. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
10. Health information exchange — Wikipedia — https://en.wikipedia.org/wiki/Health_information_exchange
11. Healthcare Information and Management Systems Society — Wikipedia — https://en.wikipedia.org/wiki/Healthcare_Information_and_Management_Systems_Society
12. NHS England — Frontline Digitisation — NHS England — https://www.england.nhs.uk/digitalhealth/connecting-frontline-digitisation/
13. NHS England — What Good Looks Like framework — NHS England — https://www.england.nhs.uk/digitalhealth/what-good-looks-like/
14. HIMSS — Electronic Medical Record Adoption Model (EMRAM) — HIMSS — https://www.himss.org/what-we-do-solutions/digital-health-transformation/maturity-models/electronic-medical-record-adoption-model-emram
15. NHS Digital — Clinical Safety standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
16. Robert Wachter — Making IT Work: Harnessing the Power of Health Information Technology to Improve Care in England — GOV.UK — https://www.gov.uk/government/publications/using-information-technology-to-improve-the-nhs
17. Faculty of Clinical Informatics — professional body for clinical informaticians — FCI — https://facultyofclinicalinformatics.org.uk/