NHS Primary Care · EMIS Web · UX Case Study
NHS Primary Care · EMIS Web · UX Case Study
Restoring trust in
clinical record
exchange.
Restoring trust in
clinical record
exchange.
Restoring trust in
clinical record
exchange.
Consultation records could fail to reach a patient’s registered GP without anyone knowing. I reframed Consultation Write Back from a UI visibility issue into a clinical continuity and reliability problem, then shaped a phased strategy to make failures visible, recoverable and configurable.
Scope: Discovery → delivery support
Users: PCN Hub clinicians, receiving GPs, practice managers
Users: PCN Hub clinicians, GPs, Managers
Strategy: Visibility → Recovery → Configuration
PCN Hub
PCN Hub
GP Practice
GP Practice
!
!
Missing record between organisations
Missing record between organisations
Role
UX Designer
TIMELINE
6-month PI delivery
Users
PCN Hub clinicians,
receiving GPs, practice
managers
Core outcome
Silent failure → visible recovery
01 · System context
A simple workflow on the
surface. A distributed clinical
system underneath.
A simple workflow on the
surface. A distributed clinical
system underneath.
A simple workflow on the surface. A distributed clinical system underneath.
Consultation Write Back transfers consultation information from PCN Hub or partner-
enabled workflows back to the patient’s registered GP practice. The risk appeared
when the transfer layer failed silently: the sender assumed success, while the receiver
had no reason to question record completeness.
Consultation Write Back transfers consultation information from PCN Hub or partner-enabled workflows back to the patient’s registered GP practice. The risk appeared when the transfer layer failed silently: the sender assumed success, while the receiver had no reason to question record completeness.
APP
APP
APP
CWB
PCN [Primary Care Network) Hub
CWB/API layer
Partner apps
GP record
02 · MY ROLE
I owned the experience
strategy from problem framing to delivery support
I owned the experience
strategy from problem framing to delivery support
My role was not limited to screen design. I helped turn an unclear operational issue into a phased product strategy that reduced clinical and workflow risk.
Lead UX Designer
I led discovery, workflow analysis, stakeholder alignment, solution design, interaction behavior, and delivery documentation across EMIS Web and partner application touchpoints.
⌕
Reframed the
problem
Reframed the
problem
Reframed the problem
Moved the conversation
from UI enhancement to clinical safety, continuity of care, and trust in record exchange.
Moved the conversation from UI enhancement to clinical safety, continuity of care, and trust in record exchange.
⌁
Mapped the
workflow
Mapped the
workflow
Mapped the workflow
Connected insights from focus groups, support tickets, heuristic review,
and workflow analysis to locate failure points.
Connected insights from focus groups, support tickets, heuristic review, and workflow analysis to locate failure points.
↻
Designed
recovery
Created visibility
indicators, actionable
error states, bulk resend, selective resend, and retry behavior rules.
✓
Supported
delivery
Documented states, edge cases, status logic, permissions, configuration
patterns, and handoff
guidance.
Designed
recovery
Designed recovery
Created visibility indicators, actionable
error states, bulk resend, selective resend, and retry behavior rules.
↻
Supported
delivery
Supported delivery
Documented states, edge cases, status logic, permissions, configuration patterns, and handoff guidance.
✓
Visible problem
Missing write-back status
Hidden complexity
Legacy architecture · partner contracts
clinical safety · PI timeline
permissions · server load · governance
03 · Delivery reality
03 · Delivery reality
Designing inside a legacy healthcare ecosystem.
Designing inside a legacy healthcare ecosystem.
Designing inside a legacy healthcare ecosystem.
The challenge was not identifying the problem. The challenge was solving it inside real delivery constraints.
The challenge was not identifying the problem. The challenge was solving it inside real delivery constraints.
Core infrastructure could not be rebuilt within the Program Increment.
Partner applications behaved differently and did not all support the same CWB capability.
Partner applications behaved differently and did not all support the same CWB capability.
Clinical safety could not be compromised by hiding failures or creating false success states.
Clinical safety could not be compromised by hiding failures or creating false success states.
Existing workflows were heavily relied upon by clinicians and
administrative users.
Existing workflows were heavily relied upon by clinicians and administrative users.
Engineering, Product, Support, and SMEs needed alignment before delivery decisions could move forward.
Engineering, Product, Support, and SMEs needed alignment before delivery decisions could move forward.
04 · Discovery
We expected usability issues. We found a trust problem.
We expected usability issues. We found a trust problem.
Focus group input, support evidence, heuristic review and workflow mapping showed that manual workarounds had become the hidden operating model.
CWB
Phone calls
Email messages
Repeated checks
Printouts
Manual workarounds had become the workflow.
Manual workarounds had become the workflow.
Calls, emails and repeated checks were compensating for a system that did not expose failure clearly.
Calls, emails and repeated checks were compensating for a system that did not expose failure clearly.
01
01
Silence created false
confidence.
Silence created false confidence.
When no feedback appeared, users read silence as confirmation. The interface unintentionally suggested that the write-back had succeeded.
When no feedback appeared, users read silence as confirmation. The interface unintentionally suggested that the write-back had succeeded.
02
Failure without recovery became the workflow.
Calls, emails, printouts and repeated checking absorbed clinical and administrative time because the product offered no controlled recovery path.
03
Data without
provenance created risk.
Receiving GPs needed to recognize externally sourced consultations and understand where the information came from.
02
Failure without recovery became the workflow.
Calls, emails, printouts and repeated checking absorbed clinical and administrative time because the product offered no controlled recovery path.
03
Data without
provenance created risk.
Receiving GPs needed to recognize externally sourced consultations and understand where the information came from.
05 · USERS
Two users shared one broken trust loop.
Two users shared one broken trust loop.
PCN Hub clinicians needed to record care and trust that it reached the registered GP. Their pain was uncertainty: they could not tell what transferred, what failed or what needed follow-up.
Receiving GPs and practice teams needed a complete, trustworthy record. Their pain was provenance: external consultations could blend into native records without enough context.
Senders needed confidence that records arrived; receivers needed context to trust what they saw.
Sender
PCN HUB
Clinician
Patient Registered GP
Receiver
05 · Opportunity reframing
From “improve the UI” to “restore confidence in
record continuity”.
From “improve the UI” to “restore confidence in record continuity”.
From “improve the UI” to “restore confidence in record continuity”.
The initial ask could have been treated as a straightforward UI enhancement: add a label, show a message, expose a status.
Discovery showed the deeper problem was trust. A quiet failure in a clinical transfer workflow can create false confidence and downstream uncertainty.
My reframing moved the work from isolated interface fixes to a phased strategy that has resulted in reduced clinical risk caused by invisible failures, missing provenance, and manual recovery work.
06 · DESIGN Strategy
Reduce clinical uncertainty within legacy platform constraints.
Reduce clinical uncertainty within legacy platform constraints.
The real opportunity was to reduce clinical risk and support burden in a pragmatic sequence: make failures visible, give users a controlled recovery path, then move partner behaviour into governed configuration.
Uncertainity
Visible
Recover
Reliable
Unknown failure
Status + provenance
Selective + bulk resend
Partner API config
constraints
Legacy architecture
Support team strain
Fixed PI Scope
Reliable record exchange
Principle 01
Make state visible.
Make state visible.
Clinicians should never need to infer whether clinical information transferred successfully.
Clinicians should never need to infer whether clinical information transferred successfully.
Principle 02
Make recovery
controlled.
Make recovery
controlled.
Recovery should be deliberate,
reviewable and safe, not hidden behind silent automation.
Principle 03
Governance over workaround.
Governance over workaround
Partner configuration belongs with admins and practice managers, not clinicians during care delivery.
06 · DESIGN Strategy
Reduce clinical uncertainty within legacy platform constraints.
The real opportunity was to reduce clinical risk and support burden in a pragmatic sequence: make failures visible, give users a controlled recovery path, then move partner behaviour into governed configuration.
Uncertainity
Visible
Recover
Reliable
Unknown failure
Status + provenance
Selective + bulk resend
Partner API config
constraints
Legacy architecture
Support team strain
Fixed PI Scope
Reliable record exchange
Principle 01
Make state visible.
Clinicians should never need to infer whether clinical information transferred successfully.
Principle 02
Make recovery
controlled.
Recovery should be deliberate,
reviewable and safe, not hidden behind silent automation.
Principle 03
Governance over workaround
Partner configuration belongs with admins and practice managers, not clinicians during care delivery.
07 · Agile Release Train · Program Increment
07 · Agile Release Train · Program Increment
Reliability strategy delivered through phased Program Increments
Reliability strategy delivered through phased Program Increments
A visual map of how design strategy shaped delivery: from visibility, to recovery, to governance
A visual map of how design strategy shaped delivery: from visibility, to recovery, to governance
Program Increment
ART → Program Increment → Biweekly iterations
STRATEGIC PHASE
Make failures visible
Enable controlled recovery
Establish operational governance
PRODUCT DELIVERABLE
Visibility across modules
Resend & Bulk Resend
Partner API Configuration
MY STRATEGIC CONTRIBUTION
Discovery · workflow mapping · provenance
Recovery models · retry rules · trade-off decisions
Admin ownership · EMAS Manager · operational scale
Iteration 10
Iterations
11.1 – I1.2
Iterations
11.3 - 11.5
Iterations
12.1 - 12.3
I&A
PI Planning
PI - Iteration 11.1 -11.2
CWB Visibility
Make the invisible visible.
Make the invisible visible.
Designed enterprise consultation indicators, source context and status logic so users could recognize external consultations and understand whether write-back was behaving as expected.
Designed enterprise consultation indicators, source context and status logic so users could recognize external consultations and understand whether write-back was behaving as expected.
Designed enterprise consultation indicators, source context and status logic so users could recognize external consultations and understand whether write-back was behaving as expected.
External consultation recognition
External consultation recognition
External consultation recognition
Source/provenance cues
Source/provenance cues
Source/provenance cues
Foundation for recovery
Foundation for recovery
Foundation for recovery
PI - Iteration 11.3 - 11.5
Resend mechanism
Turn failure into recovery.
Turn failure into recovery.
Designed selective resend and bulk resend patterns with actionable failure messages, so failed write-backs could be recovered inside the product rather than through manual workarounds.
Designed selective resend and bulk resend patterns with actionable failure messages, so failed write-backs could be recovered inside the product rather than through manual workarounds.
Designed recovery options
Designed recovery options
Added guardrails for retry
Designed recovery options
Added guardrails for retry
PI - Iteration 12.1 - 12.3
Partner API configuration
Make partner workflows
configurable.
Make partner workflows
configurable.
Moved partner complexity into EMAS Manager so practice/admin users could configure partner participation while clinicians stayed focused on care delivery.
Moved partner complexity into EMAS Manager so practice/admin users could configure partner participation while clinicians stayed focused on care delivery.
Defined configuration model
Defined configuration model
Defined configuration model
Prepared final modal behaviour
Prepared final modal behaviour
Prepared final modal behaviour
08 · High-fidelity design explorations
08 · High-fidelity design explorations
Showing the design decisions without exposing patient or organisation data.
Showing the design decisions without exposing patient or organisation data.
Designing for visibility at the point of receipt
Clinicians needed to know if a consultation received from a partner system was complete, when it arrived and where it came from - without leaving their workflow.
Clinicians needed to know if a consultation received from a partner system was complete, when it arrived and where it came from - without leaving their workflow.
DESIGN GOAL
Clinicians needed to know if a consultation received from a partner system was complete, when it arrived and where it came from - without leaving their workflow.
KEY OUTCOMES
New column added to the consultation list.
Tooltip on hover for full context.
Status icons communicate write-back state.
No additional clicks for essential information.
DESIGN PRINCIPLES
Visible
Critical information is immediate and unmissable
Contextual
Details are available on demand without cluttering the view.
Effortless
No extra steps in a busy.
1
New Column
A dedicated column at the receiving end of CWB shows the source system and receipt timestamp
2
Write-back status
Status icons provide at-a-glance indication of write-back state (success, partial, failed).
Status icons provide at-a-glance indication of write-back state (success, partial, failed).
3
Context on hover
A tooltip reveals full details - source system and exact received date/time when the user hovers.
Phase 1 · Visibility and provenance
Making received CWB entries recognisable at the point of review.
Making received CWB entries recognisable at the point of review.
The design highlights the receiving-side CWB indicator and hover tooltip, while redacting clinical text. This keeps attention on the design decision: source, received date/time and write-back context should be visible without requiring another screen.
The design highlights the receiving-side CWB indicator and hover tooltip, while redacting clinical text. This keeps attention on the design decision: source, received date/time and write-back context should be visible without requiring another screen.
Phase 2 · Recovery options
Comparing bulk resend and contextual resend.
The highlighted two recovery entry points explored: a ribbon-level bulk action for reviewed failures, and a row- level action for targeted recovery.
Option 1
Right sidebar Configuration panel
Option 2
Inline partner selection table
Phase 3 · Partner API configuration
Moving partner complexity into admin-owned configuration.
The design focuses on the configuration area only, showing how partner participation could be managed in EMAS Manager without exposing complexity to clinicians during care delivery.
Phase 1 · Visibility and provenance
Making received CWB entries recognisable at the point of review.
The design highlights the receiving-side CWB indicator and hover tooltip, while redacting clinical text. This keeps attention on the design decision: source, received date/time and write-back context should be visible without requiring another screen.
FINAL DESIGN DIRECTION
Modal dialog for Partner API configuration
CWB was structurally incompatible with several partner app workflows. Instead of exposing this complexity to clinicians, configuration was moved
to an admin-level EMAS Manager pattern.
What happened
The issue
PCN Hubs used partner applications such as Accurx, eConsult, and Docman, but CWB did not automatically support all partner created consultations.
The gap was structural, not just occasional failure.
Practice managers needed visibility and control.
Clinicians should not manage configuration during care delivery.
What I did
My UX contribution
I explored multiple configuration layouts in
EMAS Manager.
I moved the configuration responsibility to practice/admin users.
I designed status visibility for partner
capability and activation.
I added contextual prompts after activation and in Data Sharing Manager.
Why this was chosen
Best fit for existing workflow
Partner apps are already managed in EMAS Manager, so the modal stayed close to the user’s existing admin workflow.
Cross-functional alignment
Balanced UX and engineering
I aligned with Product and Engineering to avoid a heavy new page structure while still solving the user problem clearly.
Delivery strength
Workable and shippable
The modal gave a focused experience that was easier to implement, test, and explain
within PI delivery constraints.
FINAL DESIGN DIRECTION
Modal dialog for Partner API configuration
CWB was structurally incompatible with several partner app workflows. Instead of exposing this complexity to clinicians, configuration was moved to an admin-level EMAS Manager pattern.
What happened
The issue
PCN Hubs used partner applications such as Accurx, eConsult, and Docman, but CWB did not automatically support all partner created consultations.
The gap was structural, not just occasional failure.
Practice managers needed visibility and control.
Clinicians should not manage configuration during care delivery.
What I did
My UX contribution
I explored multiple configuration layouts in EMAS Manager.
I moved the configuration responsibility to practice/admin users.
I designed status visibility for partner capability and activation.
I added contextual prompts after activation and in Data Sharing Manager.
Why this was chosen
Best fit for existing workflow
Partner apps are already managed in EMAS Manager, so the modal stayed close to the user’s existing admin workflow.
Cross-functional alignment
Balanced UX and engineering
I aligned with Product and Engineering to avoid a heavy new page structure while still solving the user problem clearly.
Delivery strength
Workable and shippable
The modal gave a focused experience that was easier to implement, test, and explain within PI delivery constraints.
09 · Decision logs & trade-offs
Design decisions were
about risk, not decoration.
Trade-off
Silent auto-retry vs controlled
recovery
Chosen direction
Controlled recovery
Auto-retry looked efficient, but it could hide persistent failures and recreate the original trust problem. Manual, visible recovery kept users informed.
Trade-off
Full rebuild vs phased improvement
Chosen direction
Phased rollout
Core architecture changes were outside the PI scope. The phased approach shipped value while reducing one risk at a time.
Trade-off
Clinician setup vs admin ownership
Chosen direction
Admin configuration
Clinicians should not manage integration rules during care. Configuration was placed where governance, consistency and accountability could be owned.
Trade-off
Unlimited bulk retry vs reviewed resend
Chosen direction
Reviewed resend
Bulk resend needed guardrails because some failures were persistent, not temporary. Review reduced the risk
of repeated failed retries and server load.
09 · Decision logs & trade-offs
Design decisions were about risk, not decoration.
Trade-off
Silent auto-retry vs controlled
recovery
Chosen direction
Controlled recovery
Auto-retry looked efficient, but it could hide persistent failures and recreate the original trust problem. Manual, visible recovery kept users informed.
Trade-off
Full rebuild vs phased improvement
Chosen direction
Phased rollout
Core architecture changes were outside the PI scope. The phased approach shipped value while reducing one risk at a time.
Trade-off
Clinician setup vs admin ownership
Chosen direction
Admin configuration
Clinicians should not manage integration rules during care. Configuration was placed where governance, consistency and accountability could be owned.
Trade-off
Unlimited bulk retry vs reviewed resend
Chosen direction
Reviewed resend
Bulk resend needed guardrails because some failures were persistent, not temporary. Review reduced the risk
of repeated failed retries and server load.
10 · Impact
The outcome was not just a better screen. It was a safer operating model.
User impact
Reduced uncertainty for PCN Hub clinicians by making write-back
behaviour visible and recoverable.
Improved confidence for receiving GPs by clarifying externally sourced
consultations and provenance.
Business impact
Reduced dependency on manual coordination, follow-up calls and support escalation for missing or
uncertain write-backs.
Supported broader adoption across PCN Hub workflows by making partner
gaps manageable.
Product impact
Established reusable patterns for failure visibility, controlled recovery and
partner configuration.
Created a more scalable foundation for future partner-enabled clinical
workflows.
BEFORE
AFTER
PCN Hub
GP Practice
Uncertain handover
PCN Hub
GP Practice
Reduction in uncertainty & clinical risk
10 · Impact
The outcome was not just a better screen. It was a safer operating model.
User impact
Reduced uncertainty for PCN Hub clinicians by making write-back
behaviour visible and recoverable.
Improved confidence for receiving GPs by clarifying externally sourced
consultations and provenance.
Business impact
Reduced dependency on manual coordination, follow-up calls and support escalation for missing or
uncertain write-backs.
Supported broader adoption across PCN Hub workflows by making partner gaps manageable.
Product impact
Established reusable patterns for failure visibility, controlled recovery and partner configuration.
Created a more scalable foundation for future partner-enabled clinical
workflows.
11 · Outcomes
What changed after the design intervention.
Before
The interface reinforced false success. Failed write-backs were silent. Manual workarounds absorbed clinical and admin time.
After
Status visibility made failures knowable. Resend made recovery possible. Partner configuration brought structural gaps into scope.
Next measures
Track failure visibility, resend success, unresolved retry rate, support ticket reduction and partner configuration adoption.
11 · Outcomes
What changed after the design intervention.
Before
The interface reinforced false success. Failed write-backs were silent. Manual workarounds absorbed clinical and admin time.
After
Status visibility made failures knowable. Resend made recovery possible. Partner configuration brought structural gaps into scope.
Next measures
Track failure visibility, resend success, unresolved retry rate, support ticket reduction and partner configuration adoption.
12 · Reflection
Trust is not created
only when systems
work. Trust is created
when systems fail
transparently and help
users recover.
This project changed how I think about safety-critical enterprise UX.
The highest-value design move was not adding more UI. It was sequencing the work so each release reduced a specific risk: visibility before recovery, recovery before configuration, and
configuration before scale.
Case study takeaway
Case study takeaway
Consultation Write Back became a
clearer and safer workflow by turning silent failure into visual indications, manual workaround into structured recovery, and hidden partner gaps into configurable admin-level controls.
Consultation Write Back became a
clearer and safer workflow by turning silent failure into visual indications, manual workaround into structured recovery, and hidden partner gaps into configurable admin-level controls.
12 · Reflection
Trust is not created
only when systems
work. Trust is created
when systems fail
transparently and help
users recover.
This project changed how I think about safety-critical enterprise UX.
The highest-value design move was not adding more UI. It was sequencing the work so each release reduced a specific risk: visibility before recovery, recovery before configuration, and
configuration before scale.
