Service DesignUser ResearchPublic SectorAccessibilityDesign Systems

NHS GP2GP record transfers

Giving GP practices visibility and control over patient record transfers.

Role

Product Designer, NHS England

Duration

Discovery into private beta

Phases

Discovery, alpha, private beta

Year

2023

Overview

GP2GP moves around 200,000 patient records between practices every month. When a transfer fails it falls back to print, post and re typing by hand, and the failure is usually invisible until a GP opens an incomplete record in front of a patient. I designed a dashboard and a set of plain language patterns so practice staff could see, prioritise and resolve stuck transfers before they reached the point of care.

Project at a glance

The problem

Practice staff had no single place to see the status of incoming transfers. They found out something had gone wrong only when it was already a problem.

The objective

Give practice staff visibility and control over incoming transfers, so delays are caught and resolved before they affect care.

My role

Product designer on a cross functional team. I led service mapping, interaction design and usability testing, alongside a user researcher, a delivery manager, engineers, and stakeholders from NHS England and GP system suppliers.

The outcome

Far fewer technical failures, hundreds of thousands of staff hours saved, and a clear place for staff to act on the cases that do stall.

Headline results

84%

Fewer technical transfer failures

432k

Staff hours saved each year

£7.2m

Estimated annual cost saving

WCAG 2.1 AA

Accessibility standard met

01. The problem

Failures were invisible until they reached the patient.

When a patient moves to a new GP practice their medical record needs to follow them. The GP2GP service handles around 200,000 of these transfers between practices every month, for a population where GPs make care decisions for as many as 34 million patients.

When a transfer fails electronically the record falls back to being printed and posted, then re typed by hand. That is slow, error prone, and puts sensitive information at risk. Worst of all, the failure is usually invisible until a GP opens an incomplete record in front of a patient.

02. Discovery and research

I needed to see how a record actually moves between two practices.

Records are complex. They hold many data types, pass through several supplier systems, and carry information that cannot be lost or misread. I started by listening to the people who handle them every day.

One finding shaped everything that followed. The people who feel the pain are not the people who can see the data. Practice staff carry the workload, but the status of a transfer lived in supplier systems they could not reach.

·12 stakeholder interviews across NHS England and two GP system suppliers
·Contextual inquiry in 4 GP practices, watching summarisers process incoming records
·A service blueprint workshop mapping the full lifecycle of a record
·A review of transfer data to find where and how often records stalled

03. Who we designed for

Three roles, one daily user.

Three roles came out of research. I designed primarily for Anita, a practice summariser, because she does the daily work and had the least support. Dr Okafor needs a complete record at the point of care. Raymond, an NHS systems analyst, needs aggregated data to fix things at the root.

The patient is the person who benefits most, and the person furthest from the screen. Keeping them in view kept the team honest about why speed and reliability mattered.

04. Journey map

Experience drops at two moments, silent failure and manual fallback.

Mapping the record's journey from registration to a summarised record in the new practice showed two clear dips. The first when a transfer silently fails with no alert. The second when staff have to fall back to printing, posting and re typing by hand. Those two dips were where the design needed to do its work.

05. Defining the work

How might we give staff a place to stand.

I framed the opportunity as a single question for the team to design against. How might we give practice staff visibility and control over incoming transfers, so delays are caught and resolved before they affect care.

That reframed the brief. The job was not a prettier transfer engine. It was a place for staff to stand, a clear view of what has arrived, what is stuck, and what needs them now.

·Show status in plain words, never in jargon or system codes
·Surface what needs attention first, before the full list
·Let staff act on a transfer without leaving the screen
·Never rely on colour alone, so the service works for everyone

06. Wireframes and prototype

Structure first, visual detail second.

I started low fidelity to test structure before visual detail. The question was order and hierarchy, what does a summariser need to see in the first three seconds.

The overview leads with an attention panel, then the numbers, then the list. The transfer detail screen shows a timeline of what happened and a clear next action. The prototype was built in the style of the GOV.UK Design System so it could be tested at fidelity with real practice staff.

07. Usability testing

Words did as much work as layout.

I ran moderated sessions with 5 practice summarisers, the people who would use this every day. Each worked through three tasks, find what needs attention, resolve a stuck transfer, and check this month's volume.

After iteration all 5 participants completed every task without help. Time to find a stuck transfer dropped from a hesitant scan of the whole list to a glance at the panel.

·Stuck transfers were missed in the full list, so a red attention panel moved to the top
·Pending was read three different ways, so plain status replaced system words, In progress, Delayed, Failed
·Two participants relied on colour alone, so every colour was paired with a text label and a tag
·People hesitated before Resolve, so actions were renamed to say what happens, with on screen confirmation

08. Impact

Quiet wins that show up in the consulting room.

Once optimisations and the dashboard were in place the service processed transfers quickly and at a high success rate, and staff could finally see and act on the cases that did stall.

The number I care about most sits behind the headlines. Far fewer records printed and re typed by hand, which means fewer gaps in front of a GP and a patient.

09. Design vision

Accessibility is the floor, plain language is the lever.

Designing for the public sector is designing for people who have no choice but to use what you make, often under pressure, often for someone who is unwell. That raises the bar, and I think it is the most rewarding place to design.

When this work goes well, no one notices. The record arrives, a stuck transfer gets picked up in time, and the GP can sit with the patient without having to say sorry for missing notes.

·Accessibility is the floor, not a feature. If it does not work without colour, without a mouse, or with a screen reader, it is not finished
·The interface should speak the user's language. Most wins here came from words, not pixels
·A design system is a head start, not a cage. GOV.UK components let me spend effort on the model and the flow
·Measure what matters to people. Success here was staff hours and safe records, not time on page

Interactive prototype

A place for practice staff to stand.

Open a transfer that needs attention, read what happened on the timeline, then mark it resolved or send it for manual handling. The attention panel and the list update as you act.

GOV.UK

GP2GP record transfers

Prototype

Greenfield Medical PracticeManage incoming patient record transfers

Transfers need your attention

2 transfers have failed or delayed. Review the transfer and choose the next action.

— failed, 6 days since request. Record too large for electronic transfer.
— delayed, 4 days since request. No response from sending practice.

2Needs attention

2In progress

185Complete this month

6Failed last 30 days

Transfer T-10293

Aaliyah Bukhari

NHS number 485 777 3456. From Mill Lane Surgery. 6 days since request.

Failed

Why this needs you: Record too large for electronic transfer.

What happened so far

Patient registered at Greenfield6 days ago
Transfer requested from Mill Lane6 days ago
Sender attempted transfer5 days ago
Transfer failed, record too large5 days ago
Awaiting action from your practicenow

Prototype only, no live data. Built for this case study using the portfolio's design tokens, modelled on the GOV.UK Design System patterns used in the live service.

Next case

Newcastle GovJam 2022

← All work