Consultation Write Back
Eliminating silent failures in clinical data exchange by making write-back status visible, recoverable, and configurable across native EMIS Web and partner application workflows.
ROLE
UX Designer
SCOPE
Discovery → 3-phase rollout
USERS
PCN Hub clinicians, receiving GPs, practice managers
CORE OUTCOME
Visibility → recovery → safer record continuity
01 - CASE SUMMARY
This was not a usability problem. It was a patient safety problem.
EMIS Web is the UK's most widely used primary care EHR, serving NHS GP Practices and PCNs across England. Consultation Write Back sends consultation records from a PCN Hub or partner-enabled workflow back to the patient’s registered GP practice. When this transfer failed, the sender had no clear status, the receiver had no visibility, and the interface quietly implied that nothing was wrong.
When it failed, no one knew. The UI remained unchanged, reinforcing a false success state. The system reported no error because it had no mechanism to detect one.
The system did not fail loudly. It failed silently — and silence looked like success.
450+
PCN Hub practices within CWB scope
15–20
Partner apps commonly used across PCN workflows
45+ min
Daily manual follow-up reported by clinicians
3 phases
Visibility, recovery, partner configuration
"A GP nearly prescribed contraindicated medications because a patient's consultation from another practice didn't transfer. This wasn't just a software glitch — it was a patient safety emergency."
Senior GP — NHS PCN · Discovery Interview
Core Technical Failure
When a consultation fails at the transport layer, no event is returned to the sender. The UI remains unchanged — reinforcing a false success state. The system reported no error because it had no mechanism to detect one.
01 - CASE SUMMARY
Core Technical Failure Chain
ORIGIN
PCN Hub
No send status
Transport
CWB API Layer
Silent Failure
Partner Apps
Accurx / eConsult
Not supported
Destination
GP Surgery
No visibility
Failure Analysis by Stage
STAGE
FAILURE IDENTIFIED
USER IMPACT
RISK LEVEL
Send — PCN Hub
No status indication; success assumed by default
False confidence; gaps go unnoticed indefinitely
High
Transport — API
Failure silent; no resend or recovery path
Manual follow-up; 45+ min daily overhead per clinician
High
Partner Apps
CWB incompatible with all 15–20 partner apps in use
Data never transferred; practice managers unaware
High
Receive — GP Surgery
No visual distinction: native vs. external consultations
Clinical accountability and governance confusion
Medium
02 - PROBLEM STATEMENT
"How might we eliminate silent failures in consultation write-backs — working within legacy system constraints and minimizing clinician cognitive load?"
Risk Awareness
Constraint awareness
System-level thinking
Problem Characterisation
DIMENSION
CHARACTERISATION
System Type
Distributed NHS ecosystem — PCN Hub ↔ API transport ↔ Registered GP Surgery
Failure Type
Silent data loss — no event returned to sender; UI reinforces false success state
Risk Profile
Clinical safety + legal accountability + patient record completeness
Constraints
Legacy EMIS architecture · Partner API inconsistency · PI planning capacity · No backend observability
03 - DISCOVERY & RESEARCH
Three Insights that Drove Every Design Decision
Methods: In-depth interviews (PCN Hub clinicians, receiving GPs, practice managers) · Focus groups · Heuristic evaluation · Support ticket analysis.
We initially assumed the primary pain was usability. That assumption failed quickly — the real problem was the system's inability to surface its own failure states.
01
Silence Creates False Confidence
02
Failure Without Recovery Becomes the System
03
Data Without Context Creates Risk
No feedback means clinicians assume success. This isn't a behaviour problem — it's the system exploiting a cognitive default. Absence of error reads as confirmation. The UI was actively misleading its users.
The system lied by saying nothing.
Manual workarounds filled the gap: phone calls, emails, printouts. After enough repetitions, the workaround became the workflow. 36% of reported effort maintained a process that shouldn't have existed.
The workaround was the real product.
Receiving GPs couldn't distinguish externally sourced consultations from native ones. From a clinical governance standpoint, this created an accountability gap — clinicians couldn't identify what they were responsible for vs. referencing.
Invisible provenance = clinical risk.
user Persona - discovery interviews & Focus groups
Two voices, one broken system
In-depth interviews with PCN Hub clinicians and receiving GPs crystallised the human cost of silent failures. Two distinct need profiles emerged — both underserved by the same feature.
EV
Dr. Eleanor Vance
Specialist · PCN Hub (Sender Practice)
→ "I want CWB to be a silent partner, working seamlessly in the background. Instead, it is often a source of anxiety and extra work."
USER GOAL
To collaborate to provide better, more joined-up healthcare services for their patients, ultimately improving the health of the local population — without administrative overhead.
Pain Points
Can't track which consultations have been successfully written back to home practice.
Spends 45+ minutes daily following up on failed transmissions.
Manual workarounds are time-consuming and prone to human error while coding.
User Needs
Clear confirmation that patient information reaches home practices.
Audit trail to ensure accountability and transparency.
MOTIVATIONS
Delivering efficient, coordinated care across PCNs.
Minimising administrative overhead to focus on clinical work.
DS
Dr. Sparkle
GP · Receiving Practice (Patient's Usual GP)
→ "As a GP, I require patients' records from the PCN Hub to be at my fingertips. I expect consultation notes to be seamlessly integrated into their EMIS record."
USER GOAL
To seamlessly integrate received enterprise consultations into patient records — maintaining comprehensive care view and clinical governance without significant manual effort.
Pain Points
Struggles to quickly identify externally sourced consultations in patient records.
If the system fails to send, the GP is unaware of the patient's recent PCN Hub interaction.
Clinical codes not being mapped to SNOMED CT standards — makes search harder.
Unclear about responsibility for follow-up actions on received records.
User Needs
Visibility of all patient interactions across the healthcare system.
Know the context — accountability vs. reference.
Clinical data coded to SNOMED CT, not just free-text.
Complete and comprehensive patient record.
MOTIVATIONS
Providing comprehensive and coordinated care.
Ensuring patient safety.
What we underestimated:
The depth of partner app dependency. We knew apps like Accurx and eConsult were used — we didn't realise PCN Hubs had structured entire consultation workflows around them. Fixing native CWB alone wouldn't solve the problem.
Key data from interviews
01
~450 PCN Hub practices report using 15–20 partner apps as part of their daily routine
02
Of those, 4–5 apps are used specifically for clinical consultations — most commonly Accurx, eConsult, Docman, Hero Health
03
38% of concerns centred on duplicated effort to manually transmit consultation data to the patient's usual GP
Heuristic Review — UX Gaps in Consultation Write Back Feature
A comprehensive evaluation of the CWB feature against Nielsen's 10 usability heuristics, blending UX principles with system logic and clinical safety requirements. Objective: identify failure points across the end-to-end experience and bridge the gap between user expectations and backend system behavior.
User Scenario
"A GP at PCN Hub sees a patient who has a usual GP allocated by the GP Surgery in England. The consultation is recorded at PCN Hub. Later a clinician at GP Surgery opens the patient record expecting to see the write back of that consultation."
Usability Issue
User Impact & Pain Points
Heuristic Violated
Priority
Partner Product API → Registered GP's System (EMIS Web)
CWB can't copy consultations from partner applications to patient's care record in practice
Managers and clinicians are unaware that expected consultations are missing, causing critical gaps in care record
#1 Visibility of System Status
High
Recording Consultation at PCN Hub — Sender Practice
No status indication whether the consultation was successfully sent or not
GPs and clinicians lack feedback and confidence. They assume the consultation was sent
#1 Visibility of System Status
High
No option to resend failed consultations
Clinicians contact support team for recovery — increases support workload and data loss risk
#5 Error Recovery
High
Error messages contain technical terms without actionable insights
Clinicians can't interpret or act on the errors when the consultation fails to resend
#9 Help Users with Errors
Medium
Viewing Patient Record at Receiving Practice — Registered GP Surgery
If consultation is received, it is not visually distinct from native consultation data
From clinical safety and legal perspective, GPs must know which information they are responsible for vs. referencing from others
#6 Recognition over Recall
Medium
Consultation data from PCN Hub is often delayed
Clinicians don't have updated info — inaccurate decisions may affect patient care
#1 Visibility of System Status
Medium
How violations mapped to design phases ?
Phase 01 Resolved
Heuristic #6 — Recognition
Visual indicator + Enterprise label eliminates ambiguity between native and external consultations at a glance
Phase 02 Resolved
Heuristics #1, #5, #9
Send status visibility, resend mechanism, and actionable error language resolve all three sender-side failures
Phase 03 Resolved
Heuristic #1 — Visibility
Partner API configuration brings previously invisible data gaps into scope — consultations that were structurally missing by design
04 - Design Strategy
What We Chose to Solve and What We Deliberately Didn't
Design principles
01
Make State Visible
Clinicians must never need to guess. Ambiguity is the root cause, not a symptom.
02
Enable Recovery
Replace manual workarounds with a structured resend mechanism. Close the loop.
01
Provide Context
Give receiving GPs immediate provenance clarity — what they are accountable for vs. referencing.
01
Respect Constraints
UI-layer transparency first. Avoid backend dependency not deliverable within this PI.
Risk elimination, not feature addition.
The constraints ruled out infrastructure-level fixes. Legacy EMIS architecture had no event-driven transport. Rebuilding it exceeded PI scope. The solution had to be UI-led.
Real constraints — not assumed
Legacy EMIS architecture
No event-driven feedback
Limited PI scope
No event-driven feedback
15–20 partner APIs, inconsistent contracts
Rather than building features, we mapped the risks and worked backwards from what needed to be eliminated. This reframing was critical: it kept the team from solving the wrong problem twice.
Phase
Risk eliminated
What this unlocks
P1
Unknown failure — clinicians have no idea anything went wrong
Provenance clarity for receiving GPs. Accountability restored.
P2
Irrecoverable failure — no path to fix what broke
Manual workarounds replaced with structured recovery. Trust loop closed.
P3
Structural data absence — partner apps never integrated
Partner gaps made visible. Admin-level config, no burden on clinicians.
Rejected Decisions — Rationale
Rejected Decision
Rationale
Risk Accepted
Real-time sync
Legacy EMIS architecture does not support event-driven transport. Rebuilding would exceed PI scope.
Delayed consistency
Auto-retry
Silent retries could mask persistent failures — recreating the original problem at scale. Users need to know a failure happened, not just that it was retried.
Opacity risk
Full partner integration
15–20 partner apps each have different API contracts and auth models. Complete integration in one PI would be brittle and untestable.
Phased rollout
SNOMED CT mapping
Requires clinical governance input outside design team's remit in this PI. Raised as separate workstream.
Backlog
Why Phase 2 (Resend) didn't ship before Phase 1 (Visibility)
Engineering's instinct was to priorities resend — most requested capability. We pushed back. Without visibility of which consultations had failed, resend becomes blind retry. Clinicians would click "Resend All" without knowing which records needed it, increasing server load without solving the trust problem. Visibility had to come first. This was a sequencing argument, not a priority argument.
Prioritisation — Impact × Effort
High Impact · High Effort
Resend Mechanism
Partner API Config
High Impact · Low Effort → Phase 1
Visual Differentiation
Low Impact · High Effort
Retrospective Label
Low Impact · Low Effort
No Fill ins
05 - PHASE 1 - MAKE FAILURES VISIBLE
Design principles
Problem
Receiving GPs could not identify which consultations originated externally
Clinical governance requires clear provenance
Every consultation row appeared identical regardless of origin
Decision
Icon in the primary scan column
Applied across all Care Record modules consistently
DESIGN RATIONALE
Icon is processed pre-attentively — recognised before deliberate focus
Text labels increased fixation time per row in testing
Colour coding introduced accessibility risk
Phase 1 validation - Post launch clinician feedback
"Oh that's useful! Now, I can immediately see which consultations have come in via CWB. It's a quick visual confirmation."
"It's a subtle but helpful visual cue. It doesn't clutter the screen but gives me that extra bit of information at a glance."
"Good! It helps differentiate the consultations. I know that a CWB consultation might have a slightly different context or follow-up needs."
06 - Phase 2 Resend Mechanism for Failed Write-Backs
Receiving GPs had no way to distinguish externally sourced consultations from native ones. Clinical governance requires clear provenance. The fix had to be pre-attentive — recognised before deliberate focus.
Problem
No recovery path existed within EMIS Web
Manual workarounds had become de facto process
45+ minutes per clinician per day on calls, emails, printouts
Decision — Dual-Mode Resend
Bulk resend via toolbar — systematic recovery across all failures
Selective resend via context menu — single retry with failure reason shown
Status updated in real-time · Error messages rewritten as actionable language
Interaction Risks Mitigated
Duplicate sends → status validation lock before resend fires
Server overload → batching strategy limits concurrency
Persistent errors separated from retryable ones
Friction Encountered
Engineering proposed auto-retry. We spent two sessions working through why this recreated the original problem — a silent process optimising system metrics while hiding persistent failures from users. Manual resend with batching was agreed.
Discussion with triad — finalizing MVP
A comprehensive approach that allows clinicians with the:
– Ability to resend all failed consultations for an indefinite period after the initial consultation.
– Consultations can be resent from either the Consultation screen.
– The re-sent Consultation is then filed back to the registered GP Record.
Design options explored
Option 1 — Ribbon button with bulk resend modal
EXPLORED
Option 2 — Contextual Menu with per-consultation resend
EXPLORED
Technical Challenges
Handling Different Failure Reasons
Some errors require immediate retry — Network error, Session time out, Internal server error
Other errors are persistent — No sharing agreements activated, No usual GP, Unknown error, No status
Retry Mechanisms and Logic
Deciding on retry strategy — immediate retry vs. delayed retry
System must track the number of retry attempts to prevent infinite loops
Server Load
Resend all functionality could potentially put significant load on EMIS Web servers
Risk increases if many users trigger simultaneously or a large number of consultations are being resent
Comparing Option 1 & Option 2
DESIGN OPTION
Option 1 — Ribbon Button
Option 2 — Contextual Menu
Technical Effort
Bulk Resend
✓ Supported
✓ Supported
●●○ Medium–High
Per-Consultation Resend
✓ Supported
✓ Supported
●○○ Low
End of phase 2 - finalized MVP - Post discussion of phase 2
Actionable Error
EXPLORED
07 - Phase 3 - Partner Application Configuration in EMAS Manager
CWB was structurally incompatible with every partner app PCN Hubs relied on. Consultations recorded in Accurx, eConsult, Docman were never transferred — not occasionally, but by design. Three layout approaches were explored before arriving at a simpler modal solution.
Problem
CWB was structurally incompatible with every partner app PCN Hubs relied on
Consultations in Accurx, eConsult, Docman were never transferred — by design
Decision
Admin-level CWB configuration in EMAS Manager
Practice managers view all partner apps, check CWB capability per-app, and activate
Clinicians never see this complexity
Why Admin-Level
Clinicians not burdened with system config decisions
Consistent settings enforced at organisation level
Centralised audit trail for NHS compliance
Design options explored
Iteration 1a
IDEATIION 1
Iteration 1b
IDEATION
Decision Logs
Decision details
Reasons
Technical feasibility/Efforts
Option 1
A new page structure Dedication section with CWB Tab for PA Config Dynamic details panel (horizontally & vertically).
Technical constraints
Statement management challenges Potential Performance Impact Integration Complexity with Existing EMAS Manager Architecture.
●●● High
Option 2
Dedication section with Tab for PA Config. Dynamic center panel - loads context specific configuration details. Side Tabs
Increased technical complexity and development effort. Potential performance Issues. Inconsistency with Existing EMAS Manager UI Patterns.
●●● High
Iteration 2 — Simplified modal approach
Scenario 1:
For Practices using EMIS Web with some partner applications already integrated and activated, we could potentially show a:
A Ribbon action button for Partner API Configurations. A Modal dialog to enable CWB ability.
Scenario 2b:
When PCN Hubs installs/activates a new partner API with CWB ability.
Show a alert pop-up to the practice manager or admin Pop-up dialog should appear immediately after successful integration.
Pop-up dialog should appear immediately after successful integration.
Touch Point 1
Scenario 2b:
To show this banner only after the user activates or reactivates a CWB agreement.
To show only to agreements where the organizations uses partner api for consultation
Touch Point 2
Modal approach eliminated the need for a dedicated configuration page, removing all architectural complexity from Iteration 1. Clinicians never see the configuration — complexity stays at admin level, ensuring governance and a centralised NHS audit trail.
09 - Outcomes & Impact - Closing the feedback
The impact flows from a specific causal chain: visibility → recovery → reduced silent failures → improved data completeness → safer clinical decisions.
State Before Intervention
UI reinforces false success state; failures completely silent
45+ min daily manual recovery per clinician
GPs operated on incomplete histories without knowing what was missing
Partner app consultations structurally excluded from CWB
No provenance distinction in received consultation records
State After Intervention
Status display closes sender feedback loop; failures known, not assumed
Bulk + selective resend eliminates manual recovery workflows entirely
Visual indicator gives GPs immediate provenance context on every record
Partner config brings all major clinical tools into CWB scope
PartAudit trail supports NHS compliance and accountability requirements
Behavioural change — What actually shifted
01
Clinicians Stopped Calling Support
02
GPs Trusted Records Without Cross-Checking
03
Data Without Context Creates Admins Proactively Configured Integrations
Failed write-backs are now managed directly within EMIS Web — no escalation, no phone calls to the PCN Hub required.
With provenance visibility, GPs no longer needed to verify externally sourced consultations by contacting the originating practice. The record was self-explaining.
Practice managers began proactively configuring CWB for newly activated apps as part of standard onboarding — a workflow that didn't exist before.
Honesty note on metrics
The 68% reduction in clinical risk incidents is correlated with improved failure visibility rather than full system reliability improvements — the underlying transport layer was not rebuilt in this PI. Remaining risk exists at the infrastructure level and has been raised as a subsequent workstream.
Feedback alignment — full three-phase rollout
Easy to Track
Track CWB status at a glance. No more guessing.
Clarity
Reduces the risk of overlooking important information about shared consultations.
Easy to Manage
Can now proactively manage failed write-backs directly from consultation list.
Consistent
Consistent, easily visible indicator that consultation has been written back.
Systems don't fail when they break.
Systems fail when they hide that they are broken.
