Dimitrios Zampelis
Research · NHS Wales · UK Public Healthcare

Electronic Patient Record discovery

Eighteen contextual inquiries, synthesised into the evidence base NHS Digital adopted as the baseline for alpha funding.

Delivered

April 2022 (discovery phase)

Role

Senior UX Consultant, research lead for discovery

Team

Programme clinical lead, clinical safety officer, business analysts, technical team

Project context

Discovery for a national Electronic Patient Record programme, building the evidence base for an alpha funding decision.

Impact

Alpha funded
findings adopted by the national health governance panel as the baseline for alpha funding.
32%
fewer task-completion errors between baseline and revised designs, in moderated testing.
18 sessions
contextual inquiry with clinicians and administrative staff, synthesised into a service blueprint and a prioritised backlog.
40 stories
prioritised user-story backlog, each one traceable back to an observed behaviour.

Discovery's job is to turn opinion into evidence a funding panel can act on. This one did.

i

Anonymised case study (NDA)

This study is anonymised. No patient data or live clinical records are shown, and the diagrams are recreated, as each caption notes. I'm happy to talk through my role and the design decisions in more detail on a call.

FIELDWORK OBSERVATIONS SYNTHESIS DEFINITION VALIDATION DECISION 18 contextual inquiry sessions Observed behaviour, tagged Synthesis 40 user stories, prioritised Inclusive usability testing National health governance panel Doctors, nurses, secretaries, ambulance crews wards, clinics; remote + on-site Interruptions, re-keying, paper workarounds, drops › GOV.UK-style personas › Service blueprint › Journey maps Flows + wireframes at specification level WCAG 2.2 + screen-reader fewer task errors Adopted as the baseline for alpha funding No story without a session behind it
The evidence chain: how eighteen sessions became a funded alpha. Diagram created for this case study.

We were asked to find out what an Electronic Patient Record needed to be for the people who would live inside it

An EPR is not a product clinicians choose. It is the room they work in for an entire shift. Get it wrong and the cost is not churn, it is risk at the point of care. The health service needed evidence, not opinion, about what that room should contain before committing alpha funding to build it.

Clinicians and administrative staff worked across a patchwork of paper notes and legacy systems, with a single task often spanning four to seven separate platforms before it was complete.

My brief was to lead the discovery research: understand how clinicians and administrative staff actually work, turn that into evidence a governance panel could fund against, and define the record at specification level.

Watching the work instead of asking about it

Interviews tell you what people believe they do. Watching them shows you the workarounds, and the workarounds are where the real requirements hide. I ran 18 contextual inquiry sessions across a mix of remote video and on-site visits, with consultants and doctors, medical secretaries, outpatient and clinic administrators, ward nurses, and frontline staff including ambulance crews.

I was looking for the texture of the work: where tasks get interrupted, where information is re-keyed because two systems refuse to talk, where staff keep a private paper backup because they do not trust the screen, and where a handoff between roles silently drops context.

The moment that organised the rest was small: an administrator working from a spreadsheet she kept herself, off to the side of the official system, because it was the only place the information she needed actually sat together. The same gap had a bigger shape across the service. No two hospitals ran the same system and none could pass a record to another, so when a patient was transferred their information went with them on paper, carried by hand. The record was already moving between people and places; it was just moving in private files and printouts rather than through anything designed. That set the problem: not a cleaner screen, but a way for the information itself to travel.

From eighteen sessions to evidence a panel could act on

Raw research does not move funding decisions. Structure does. I synthesised the sessions into GOV.UK-style personas grounded in observed behaviour rather than job titles, a service blueprint connecting front-stage clinical tasks to the back-stage administrative and data flows that make them possible, and journey maps for the highest-risk workflows.

The choice of GOV.UK grammar was deliberate. The audience for this evidence was a national health governance panel that reads service assessments in that format every week. Familiar structure lowers the cost of trust: the panel could interrogate the content instead of decoding the format.

The backlog came last: 40 user stories, prioritised, each traceable back to an observed behaviour. Traceability was the discipline. A story that could not point to a session did not make the list.

E
Eleri, Ward Sister
Composite persona
The work

Runs a medical admissions ward. Her shift is a sequence of interruptions; any task may be paused four times before it finishes.

What she needs from the record
  • Patient context visible in one place before she walks to the bed
  • To trust that what is on screen is current
  • Tasks that survive interruption and show where she left off
  • Handover that does not depend on her memory
What gets in the way
Information split across systems keeps a paper list in her pocket
Re-keying between screens batches data entry to end of shift, increasing error risk
Digital context

Confident user of clinical systems; no patience for ones that waste her time. Uses assistive technology herself, so a screen that defeats a screen reader is not a nuisance, it is a wall between her and the work.

Composite persona, GOV.UK style: built from behaviour patterns observed across sessions, not an individual.
Admission and triage
Ward round
Results review
Discharge and handover
Patient experience
Repeats history already given at referral
Waits while clinician switches between screens
Asks whether results have arrived
Leaves with printed instructions
Line of interaction
Clinician front-stage
Builds picture from referral letter plus verbal history
Reviews notes across systems at the bedside
Checks, acknowledges, and acts on results
Writes discharge summary under time pressure
Line of visibility
Admin back-stage
Re-keys demographics from referral into the record
Chases missing documentation between teams
Files incoming results against the right patient
Transcribes summary for GP letter
Supporting systems and data
Referral system, patient administration system, paper
Multiple logins, no shared context between systems
Results arrive in a separate system from the notes
Summary re-entered rather than reused
Service blueprint, recreated at structure level with representative content. The original, populated from the eighteen sessions, remains with the health service.

Defining the record at specification level

The output of discovery is not polished UI, and pretending otherwise misleads everyone downstream. I defined the EPR through user flows and wireframes at the fidelity the funding decision needed: enough structure to estimate against, enough honesty to leave room for alpha to learn.

The deeper question was structural. The record was fragmented not only across screens but across organisations: each site held its own and none could pass it on. So I specified the EPR less as one large system and more as a set of smaller, connected apps sharing a common record, on the model of an office suite where each tool does one job but works on the same documents. The design work was defining what each app owned and what they shared, and how a patient's record moved between them and across hospital boundaries, so the information travelled through the system instead of beside it on paper.

The flow I am most proud of is the clinical handover. Handover is the moment the paper bundle existed for: a patient crossing a boundary, a shift change or a transfer to another site, with their context at risk of being dropped. I designed it so the handover assembled itself from the record, the current picture and what was still outstanding held in one place, and travelled with the patient as data the receiving clinician acknowledged rather than as a printout someone hoped had arrived. The lo-fi flow below traces that path.

1
Handover listPatients crossing a boundary, by urgency
the boundary is where context drops
2
Patient context headerWho, where, where to, and why
context before detail
3
Handover summaryCurrent picture and what is still outstanding, assembled from the record
built once, not re-keyed
4
Receiving acknowledgementThe receiving clinician confirms receipt and takes ownership
a handover is not done until someone catches it
5
Audit trailWho handed over to whom, and when
accountability across the boundary
Flow recreated at discovery fidelity. Original wireframes remain with the programme.

Testing inclusively, because in clinical software accessibility is a safety property

I led inclusive usability testing on the proposed flows: screen-reader walkthroughs, WCAG 2.2 checks, sessions with clinicians who rely on assistive technology and administrative staff across a range of ages and digital confidence.

Between the baseline flows and the revised designs, task-completion errors fell by 32%, measured across eight to ten defined tasks in moderated testing. In most products an error means frustration. In an EPR an error can mean the wrong information attached to the wrong patient. The 32% is a safety figure wearing a usability costume.

Task-completion errors (moderated testing) −32% Baseline flows Revised designs
Task-completion errors, baseline versus revised designs in moderated testing.

Decisions and trade-offs

Three calls shaped the discovery more than any single deliverable.

01

Breadth against depth. Eighteen sessions across a national service is thin coverage by volume, so I traded breadth across specialties for depth in the highest-risk workflows, handover and patient transfers above all, where a mistake reaches the patient fastest. I chose them by clinical risk rather than by frequency.

02

Access against the clinical day. The constraint that bit hardest was not the COVID winter or the budget, it was getting time at all with overstretched frontline staff. Recruiting was the bottleneck, so I fit research around shifts rather than scheduling around mine, observing during real work and taking the people I could reach when I could reach them.

03

What we said no to. The programme wanted alpha to cover more than it responsibly could. Testing a record that wide would have meant testing none of it properly, so I argued to narrow scope to the workflows where getting it wrong carried real clinical risk, and to prove those before widening. Saying no to breadth was how the evidence stayed worth anything.

The governance panel

I presented the evidence base to the panel: the personas, the blueprint, the tested flows, the backlog, and the line from each recommendation back to an observed behaviour. The findings were adopted as the baseline for alpha funding.

That is the whole job of discovery, done: the programme moved forward standing on observed behaviour rather than assumption, and the alpha team inherited a map instead of a guess.

Reflection

The design was never really the screens. It was how the record moved: what each part of the system owned, and how information crossed between people and between hospitals. The screens were where that became visible, but the structure underneath was the work. The other thing clinical software taught me, a lesson that held just as firmly when I moved into financial risk work, is that trust in a system is built at the moment of data entry, not at the dashboard. If the person putting the information in does not believe it will be held and used safely, every view downstream is standing on sand.

← All case studiesInteractive version ↗