EPS - Prescription WORKFLOW
EPS - Prescription WORKFLOW
WORKFLOW OPTIMIZATION
WORKFLOW OPTIMIZATION
WORKFLOW OPTIMIZATION
CLINICAL DECISION SUPPORT
CLINICAL DECISION SUPPORT
Making Pharmacy Search Reliable Under Real-World Clinical Conditions
Making Pharmacy Search Reliable Under Real-World Clinical Conditions
background context
At first glance, pharmacy search in EMIS Web appeared to be working. Clinicians could search for pharmacies and issue prescriptions. But under time-critical prescribing conditions, a different story emerged.
Some searches returned no results. Others behaved differently depending on the information entered. In some cases, the system appeared to fail without explaining why.
At first glance, pharmacy search in EMIS Web appeared to be working. Clinicians could search for pharmacies and issue prescriptions. But under time-critical prescribing conditions, a different story emerged.
Some searches returned no results. Others behaved differently depending on the information entered. In some cases, the system appeared to fail without explaining why.
The challenge was not just to improve search. It was to make clinicians feel confident when the system was under pressure.
The challenge was not just to improve search. It was to make clinicians feel confident when the system was under pressure.
The challenge was not just to improve search. It was to make clinicians feel confident when the system was under pressure.
Client
NHS Wales, UK
NHS Wales, UK
Plaform
EMIS Web
EMIS Web
EMIS -X
EMIS -X
Team
Product
Product
ENGINEERING
ENGINEERING
CDG
CDG
Content
Content
Role
Dedicated UX Designer
Dedicated UX Designer
Shipped
February, 2025
February, 2025
THE CHALLENGE
A simple search form was hiding a reliability problem.
A simple search form was hiding a reliability problem.
The complexity only became visible when mapping search behavior across prescribing scenarios.
Behind a familiar interface, different search paths produced inconsistent outcomes—results, errors, or no feedback—forcing clinicians to retry, adjust inputs, or guess what went wrong.
The complexity only became visible when mapping search behavior across prescribing scenarios.
Behind a familiar interface, different search paths produced inconsistent outcomes—results, errors, or no feedback—forcing clinicians to retry, adjust inputs, or guess what went wrong.
What was at stake?
This work informed future pharmacy search patterns in EMIS X. The challenge was not search itself, but reliability. Clinicians needed clear feedback, predictable outcomes, and safe recovery paths when services failed. The solution had to balance clinical confidence with existing platform constraints.
This work informed future pharmacy search patterns in EMIS X. The challenge was not search itself, but reliability. Clinicians needed clear feedback, predictable outcomes, and safe recovery paths when services failed. The solution had to balance clinical confidence with existing platform constraints.
MY ROLE & CONTRIBUTIONS
I helped move the conversation from “search usability” to “system reliability”.
I led the UX design work across problem framing, workflow analysis, error-state design, and design decision documentation. The work sat between clinical safety, prescribing behaviour, API constraints, and legacy product consistency.
I led the UX design work across problem framing, workflow analysis, error-state design, and design decision documentation. The work sat between clinical safety, prescribing behaviour, API constraints, and legacy product consistency.
My contribution was not just producing screens. I clarified where the problem actually lived, what failure meant in a clinical workflow, and how the product should behave when the system could only partially recover.
My contribution was not just producing screens. I clarified where the problem actually lived, what failure meant in a clinical workflow, and how the product should behave when the system could only partially recover.
Discovery
Mapped the behaviour
I reviewed how different input combinations behaved, where search silently failed, and which outcomes were invisible to clinicians.
I reviewed how different input combinations behaved, where search silently failed, and which outcomes were invisible to clinicians.
Design
Designed recovery paths
I created clearer search pathways, differentiated error states, and fallback actions that helped clinicians keep moving.
I created clearer search pathways, differentiated error states, and fallback actions that helped clinicians keep moving.
Alignment
Aligned teams
I worked with Product, Engineering, Clinical Design, and Content teams to balance safety, technical feasibility, and platform consistency.
I worked with Product, Engineering, Clinical Design, and Content teams to balance safety, technical feasibility, and platform consistency.
WHAT I DISCOVERED
The rules existed. Clinicians just could not see them.
What looked like one search experience was actually several different behaviors. That was the turning point in the project.
What looked like one search experience was actually several different behaviors. That was the turning point in the project.
Search Input Combination
Result
Status
Full postcode only
Full postcode only
All pharmacies in that postcode returned
All pharmacies in that postcode returned
Works
Works
Partial postcode only
Partial postcode only
Error prompt — name field required
Error prompt — name field required
Error Shown
Error Shown
Partial postcode + Name
Partial postcode + Name
Only that named pharmacy at partial postcode
Only that named pharmacy at partial postcode
Partial only
Partial only
Name only (full or partial)
Name only (full or partial)
Matching results returned
Matching results returned
Works
Works
Street + Name + Town + Postcode
Street + Name + Town + Postcode
Results returned
Results returned
Works
Works
Any misspelled input
Any misspelled input
No results — no feedback given
No results — no feedback given
Silent Fail
Silent Fail
Multistep retry loop
Multistep retry loop
No system feedback
No system feedback
Prescription delay risk
Prescription delay risk
Before — Old Electronic Prescription Services API
Before — Old Electronic Prescription Services API
After — New Search Service API EPS
After — New Search Service API EPS
One-off Pharmacy nomination search
Search for the nearest pharmacy based on postcode, address or pharmacy name.
Postcode
LS19 6BA
Pharmacy name
Timeframe
Next 24 Hours
Search by address:
Street
Town
Search
Code
Pharmacy name
Pharmacy address
Telephone
Distance
(miles)
In a straight line
Opening days
Opening hours
FPW64
Boots
11 NEW ROAD SIDE, RAWDON, LS19 6BA
01132502053
0.12
Monday
Tuesday
09:00 - 17:00
09:00 - 17:00
FPW64
Boots
11 NEW ROAD SIDE, RAWDON, LS19 6BA
01132502053
0.12
Monday
Tuesday
09:00 - 17:00
09:00 - 17:00
FPW64
Boots
11 NEW ROAD SIDE, RAWDON, LS19 6BA
01132502053
0.12
Monday
Tuesday
09:00 - 17:00
09:00 - 17:00
FPW64
Boots
11 NEW ROAD SIDE, RAWDON, LS19 6BA
01132502053
0.12
Monday
Tuesday
09:00 - 17:00
09:00 - 17:00
FPW64
Boots
11 NEW ROAD SIDE, RAWDON, LS19 6BA
01132502053
0.12
Monday
Tuesday
09:00 - 17:00
09:00 - 17:00
OK
Cancel
No address fields
No address fields
Unsorted results
Unsorted results
Pharmacy Name silently ignored at API
Pharmacy Name silently ignored at API
Distance sorted
Distance sorted
Opening times inline
Opening times inline
Wales enabled
Wales enabled
The problem was not that search sometimes failed. The problem was that clinicians could not understand why it failed or what to do next.
The problem was not that search sometimes failed. The problem was that clinicians could not understand why it failed or what to do next.
Search Input Combination
Result
Status
All pharmacies in that postcode returned
Works
Full postcode only
Partial postcode only
Error prompt — name field required
Error Shown
Partial postcode + Name
Only that named pharmacy at partial postcode
Partial only
Name only (full or partial)
Matching results returned
Works
Street + Name + Town + Postcode
Results returned
Works
Any misspelled input
No results — no feedback given
Silent Fail
Multistep retry loop
No system feedback
Prescription delay risk
EXPERIENCE SHIFT
From retry loop to a predictable route through the task.
UI changes are invisible without workflow context. This is what the same task actually felt like for a clinician.
UI changes are invisible without workflow context. This is what the same task actually felt like for a clinician.
Before
Unreliable under pressure
A clinician could enter a postcode, scan unsorted results, try pharmacy name, hit a silent failure, and retry with different combinations.
The system gave little guidance and created doubt during a time-sensitive task.
A clinician could enter a postcode, scan unsorted results, try pharmacy name, hit a silent failure, and retry with different combinations.
The system gave little guidance and created doubt during a time-sensitive task.
~10–20s of cognitive load
~10–20s of cognitive load
Dead end with no signal
Dead end with no signal
Prescription delay risk
Prescription delay risk
After
Clearer and recoverable
The redesigned experience prioritised postcode, sorted results by distance, showed opening times inline, and gave a clear recovery path when something failed.
The clinician could understand the result and move forward with more confidence.
The redesigned experience prioritised postcode, sorted results by distance, showed opening times inline, and gave a clear recovery path when something failed.
The clinician could understand the result and move forward with more confidence.
~3–5s to nearest option
~3–5s to nearest option
Zero extra steps
Zero extra steps
Predictable behaviour
Predictable behaviour
Workflow-Level Impact
Workflow-Level Impact
At the scale of hundreds of One off nominated pharmacy searches per practice per week, eliminating retry loops and reducing scan time translates to meaningful recovery of clinician time in high-pressure workflows — and lower risk of delayed prescriptions.
At the scale of hundreds of One off nominated pharmacy searches per practice per week, eliminating retry loops and reducing scan time translates to meaningful recovery of clinician time in high-pressure workflows — and lower risk of delayed prescriptions.
scenario PROMPTS
One-off Nomination Pharmacy (OON) isn't a convenience feature. It's used when something has gone wrong.
The three primary OON use cases — confirmed by clinical design group CDG — are all time-critical. This is not a workflow where a user can afford to retry, troubleshoot, or wait. Every design decision was stress-tested against the question: does this work when a clinician is under pressure, with a patient on the line?
The three primary OON use cases — confirmed by clinical design group CDG — are all time-critical. This is not a workflow where a user can afford to retry, troubleshoot, or wait. Every design decision was stress-tested against the question: does this work when a clinician is under pressure, with a patient on the line?
A clinician searching for an out-of-network pharmacy is not browsing. They are reacting to a specific situation — a patient call, a late-night emergency, a holiday prescription — in real time. Search failure in this context does not cause mild frustration. It can cause a delayed or missed prescription.
A clinician searching for an out-of-network pharmacy is not browsing. They are reacting to a specific situation — a patient call, a late-night emergency, a holiday prescription — in real time. Search failure in this context does not cause mild frustration. It can cause a delayed or missed prescription.
Scenario 01
Urgent or out-of-hours prescription: usual pharmacy unavailable
A patient needs medication urgently, but their usual pharmacy is closed or unavailable. The clinician needs to find a nearby pharmacy that is open within the relevant time window, without manually checking multiple places or cross-referencing opening hours.
A patient needs medication urgently, but their usual pharmacy is closed or unavailable. The clinician needs to find a nearby pharmacy that is open within the relevant time window, without manually checking multiple places or cross-referencing opening hours.
Goal
Help the clinician identify the closest suitable open pharmacy quickly and confidently.
Why this scenario matters
In urgent and out-of-hours prescribing, the risk is not just a slower search. It is delay, uncertainty, or choosing a less suitable pharmacy because the system does not make the safest next step clear.
DESIGN RESPONSE
Postcode first
Fastest way to start the search using available patient/location information.
Faster task start
Nearest open option first
Results are distance-sorted so the most practical pharmacy appears first.
Reduces manual scanning
Opening hours visible
opening status and hours are shown directly in the results.
Supports faster choice
Relevant timeframe only
Search returns pharmacies useful for the prescription window, not every possible pharmacy.
Keeps results actionable
Keeps results actionable
Why this mattered
In urgent prescribing situations, uncertainty can lead to delays, unnecessary retries, or selecting a less suitable pharmacy. The interface needed to make the safest next step obvious.
User Impact
Less uncertainty during urgent prescribing and fewer decisions made from incomplete information.
WoRKFLOW IMPACT
Fewer retries, less scanning, and a clearer path from search to pharmacy selection.
PRODUCT IMPACT
A search pattern that can scale into EMIS X with stronger defaults and clearer decision support.
Scenario 03
Patient away from Home - Holiday patient: no local postcode, patient on the phone
A patient is away from home and needs an urgent prescription, but they do not know the local postcode. They can describe the area, a nearby street, or the pharmacy name they can see.
A patient is away from home and needs an urgent prescription, but they do not know the local postcode. They can describe the area, a nearby street, or the pharmacy name they can see.
Goal
Help the clinician find a suitable pharmacy using location clues or a recognisable pharmacy name, without forcing the patient to provide a postcode.
Help the clinician find a suitable pharmacy using location clues or a recognisable pharmacy name, without forcing the patient to provide a postcode.
DESIGN RESPONSE
Make address search easy to discover
Street and town fields are available as a clear alternative when postcode is not known. This gives clinicians another way to search using the information the patient can actually provide.
Prevents postcode from becoming a dead end
Support partial pharmacy name search
Support partial pharmacy name search
If the patient says “I can see a Boots nearby”, the clinician should not need the exact branch name. Partial pharmacy names help return recognizable options quickly.
Turns vague information into useful results
Keep the journey usable without postcode
The flow should not rely on postcode as the only successful path. Address and name search remain available so the clinician can recover when the patient has limited location details.
Keeps the clinician moving forward
Why Recovery matters
In this scenario, the patient is relying on the clinician to work with incomplete information. If postcode becomes the only path forward, the journey breaks down. The search experience needs to provide alternative ways to recover and continue safely.
Design principle applied
Design for graceful recovery. When the ideal input is missing, the system should still offer a clear next path instead of making the clinician start again.
Design for graceful recovery. When the ideal input is missing, the system should still offer a clear next path instead of making the clinician start again.
constraints
The interface looked simple, but the behaviour underneath was fragmented.
The interface looked simple, but the behaviour underneath was fragmented.
Before exploring design options, I worked with Product and Engineering to understand the practical constraints surrounding pharmacy search. These constraints shaped what could be delivered and helped focus the design effort on changes that would have the greatest impact.
Before exploring design options, I worked with Product and Engineering to understand the practical constraints surrounding pharmacy search. These constraints shaped what could be delivered and helped focus the design effort on changes that would have the greatest impact.
No analytics
No analytics
No reliable data on search behaviour or error frequency.
No reliable data on search behaviour or error frequency.
Legacy parity
Legacy parity
OON needed to align with existing Primary Nomination patterns.
OON needed to align with existing Primary Nomination patterns.
API limits
API limits
Postcode lookup capability was inconsistent across products.
Postcode lookup capability was inconsistent across products.
Failure detection
Failure detection
Some failures were only visible after a search attempt.
Some failures were only visible after a search attempt.
DESIGN PRINCIPLES
P1 — Consistency
P1 — Consistency
Match Primary Nomination patterns wherever possible.
Match Primary Nomination patterns wherever possible.
Match Primary Nomination patterns wherever possible.
P2 — Urgency Awareness
P2 — Urgency Awareness
Reduce effort & surface the most actionable option first.
Reduce effort & surface the most actionable option first.
Reduce effort & surface the most actionable option first.
P3 — Graceful Recovery
P3 — Graceful Recovery
Ensure failures always have a clear next step.
Ensure failures always have a clear next step.
P4 — Minimal Change
P4 — Minimal Change
Change only what the problem required.
Change only what the problem required.
ERROR STRATEGY
Designing for failure, not just the happy path.
Pharmacy search depended on more than one service, so not every failure meant the same thing. Some issues could be corrected by the clinician. Some meant only postcode lookup was unavailable. Others meant search could not continue at all.
I simplified the error strategy around one practical question:
Pharmacy search depended on more than one service, so not every failure meant the same thing. Some issues could be corrected by the clinician. Some meant only postcode lookup was unavailable. Others meant search could not continue at all.
I simplified the error strategy around one practical question:
What can the clinician still do next?
What can the clinician still do next?
User correctable
Invalid postcode
The search input is the issue. The clinician needs clear feedback and an immediate route to try address or pharmacy name instead.
The search input is the issue. The clinician needs clear feedback and an immediate route to try address or pharmacy name instead.
Partial recovery
Postcode lookup unavailable
One service is down, but the task can still continue through address or name search. Progress should be preserved.
One service is down, but the task can still continue through address or name search. Progress should be preserved.
No search possible
Search service unavailable
No digital search route is available. The interface needs to be honest, explain the failure, and guide clinicians to safe alternatives.
No digital search route is available. The interface needs to be honest, explain the failure, and guide clinicians to safe alternatives.
Recovery model applied to the interface
Scenario 1
Invalid Postcode
User Correctable
Design response
The issue is recoverable, so the UI should not make the clinician feel the service has failed. The message explains the input problem and points to the next useful search route.
The issue is recoverable, so the UI should not make the clinician feel the service has failed. The message explains the input problem and points to the next useful search route.
Clear recovery
Clear recovery
Input issue, not system failure
Input issue, not system failure
Redirects to address or name search
Redirects to address or name search
Scenario 2
Scenario 2
Postcode lookup unavailable
Postcode lookup unavailable
Postcode lookup unavailable
Partial recovery · inline banner
The Postcode search is currently unavailable
The Postcode search is currently unavailable
The Postcode search is currently unavailable
Try again later, or issue an EPS - Any Pharmacy or printed prescription instead. If this problem persists, contact Optum Help Centre.
Design response
The service is degraded, not fully broken. The postcode stays visible, entered information is not cleared, and the clinician can continue using the search paths that still work.
The service is degraded, not fully broken. The postcode stays visible, entered information is not cleared, and the clinician can continue using the search paths that still work.
Postcode is kept
Postcode is kept
Address and name still work
Address and name still work
No false full-service failure
No false full-service failure
Scenario 3
Scenario 3
Pharmacy search service unavailable
Pharmacy search service unavailable
Operational fallback
The pharmacy search service is currently unavailable.
The pharmacy search service is currently unavailable.
Try again later, or issue an EPS - Any Pharmacy or printed prescription instead. If this problem persists, contact Optum Help Centre.
Try again later, or issue an EPS - Any Pharmacy or printed prescription instead. If this problem persists, contact Optum Help Centre.
Design response
When search cannot continue, the interface should stop implying recovery through another input. It needs to clearly state the system issue and make the safest next step visible.
When search cannot continue, the interface should stop implying recovery through another input. It needs to clearly state the system issue and make the safest next step visible.
System issue
System issue
Search cannot continue
Search cannot continue
Safe next step is still visible
Safe next step is still visible
What changed
The experience moved from silent failure to guided recovery. Each error state was designed around the clinician's next possible action, not around the technical reason the service failed.
The experience moved from silent failure to guided recovery. Each error state was designed around the clinician's next possible action, not around the technical reason the service failed.
DESIGN DECISIONS
Every design choice had to balance urgency, familiarity, and feasibility.
Tension
Tension
Resolution
Resolution
Friction Removed
Friction Removed
Postcode reordered to first position
Postcode reordered to first position
Interaction cost reduction
Urgent Context
The existing screen prioritised Pharmacy Name, but clinicians typically started their search with a postcode. In urgent prescribing situations, even small interaction costs can slow down a task that needs to be completed quickly.
The existing screen prioritised Pharmacy Name, but clinicians typically started their search with a postcode. In urgent prescribing situations, even small interaction costs can slow down a task that needs to be completed quickly.
Tension
I moved Postcode to the first position and placed focus on the field when the dialog opened. Where available, the patient’s registered postcode was pre-populated, allowing clinicians to start searching immediately.
I moved Postcode to the first position and placed focus on the field when the dialog opened. Where available, the patient’s registered postcode was pre-populated, allowing clinicians to start searching immediately.
Resolution
Clinicians could begin searching without additional clicks or unnecessary input. The workflow aligned more closely with real-world behaviour and helped them find the right pharmacy faster.
Clinicians could begin searching without additional clicks or unnecessary input. The workflow aligned more closely with real-world behaviour and helped them find the right pharmacy faster.
~15s saved per OON search
~15s saved per OON search
Friction removed
Address search visible, not dominant
Address search visible, not dominant
Primary Nomination parity vs. cognitive load
Platform Parity
Most clinicians searched using a postcode, so showing extra address fields by default risked adding unnecessary complexity. But hiding address search completely made it harder to support patients who did not know their postcode.
Most clinicians searched using a postcode, so showing extra address fields by default risked adding unnecessary complexity. But hiding address search completely made it harder to support patients who did not know their postcode.
Tension
Address search remained visible but secondary to the primary postcode workflow. This kept the interface focused while ensuring alternative search paths were easy to discover when needed.
Address search remained visible but secondary to the primary postcode workflow. This kept the interface focused while ensuring alternative search paths were easy to discover when needed.
Resolution
Clinicians could quickly switch to address-based search when a postcode was not available, without disrupting the experience for users who relied on postcode as their primary search method.
Clinicians could quickly switch to address-based search when a postcode was not available, without disrupting the experience for users who relied on postcode as their primary search method.
Zero additional engineering spend
Resolution
KEY DESIGN TRADE-OFFS
Every significant design decision was evaluated against clinical urgency, platform consistency, technical feasibility, and delivery risk.
Every significant design decision was evaluated against clinical urgency, platform consistency, technical feasibility, and delivery risk.
Proposal
Proposal
DECISION
DECISION
Replaced by
Replaced by
Postcode Lookup
Postcode Lookup
Postcode Lookup
Proposal
Rejected
Rejected
DECISION
Engineering confirmed postcode lookup capability was inconsistent across EMIS products and would create parity issues with existing prescribing workflows.
Engineering confirmed postcode lookup capability was inconsistent across EMIS products and would create parity issues with existing prescribing workflows.
REPLACED BY
Disable Search When Service Fails
Disable Search When Service Fails
Disable Search When Service Fails
Proposal
DECISION
Rejected
Rejected
Service failures could only be detected after a search attempt. Proactively disabling the interface would create a misleading experience.
Service failures could only be detected after a search attempt. Proactively disabling the interface would create a misleading experience.
REPLACED BY
Auto Search On Dialog Open
Auto Search On Dialog Open
Proposal
DECISION
Rejected
Rejected
Increased API usage, introduced unnecessary network calls, and risked returning irrelevant results before the clinician had entered context.
Increased API usage, introduced unnecessary network calls, and risked returning irrelevant results before the clinician had entered context.
replaced by
Postcode First
Postcode First
Accepted
Accepted
Clinical Design Group confirmed postcode was the most common starting point during urgent prescribing scenarios.
Clinical Design Group confirmed postcode was the most common starting point during urgent prescribing scenarios.
Opening Hours Inline
Opening Hours Inline
Accepted
Accepted
Removed the need for clinicians to cross-check opening times outside the workflow.
Removed the need for clinicians to cross-check opening times outside the workflow.
Address + Name Search Retained
Address + Name Search Retained
Accepted
Accepted
Supported recovery when postcode information was unavailable or incomplete.
Supported recovery when postcode information was unavailable or incomplete.
Outcome
Outcome
This decision log became a shared reference across Product, Engineering, Clinical Design Group, and Content reviews. Rather than debating individual UI elements, discussions focused on trade-offs, risks, and the safest path to delivery within existing platform constraints.
This decision log became a shared reference across Product, Engineering, Clinical Design Group, and Content reviews. Rather than debating individual UI elements, discussions focused on trade-offs, risks, and the safest path to delivery within existing platform constraints.
