Athos: Free Framer Template for UX Designer Portfolio

KOWSALYA

EPS - Prescription WORKFLOW

WORKFLOW OPTIMIZATION

CLINICAL DECISION SUPPORT

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.

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

Plaform

EMIS Web

EMIS -X

Team

Product

ENGINEERING

CDG

Content

Role

Dedicated UX Designer

Shipped

February, 2025

THE CHALLENGE

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.

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.

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.

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.

Design

Designed recovery paths

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.

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.

Search Input Combination

Result

Status

Full postcode only

All pharmacies in that postcode returned

Works

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

Before — Old Electronic Prescription Services API

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

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

FPW64

Boots

11 NEW ROAD SIDE, RAWDON, LS19 6BA

01132502053

0.12

Monday

Tuesday

09:00 - 17:00

FPW64

Boots

11 NEW ROAD SIDE, RAWDON, LS19 6BA

01132502053

0.12

Monday

Tuesday

09:00 - 17:00

FPW64

Boots

11 NEW ROAD SIDE, RAWDON, LS19 6BA

01132502053

0.12

Monday

Tuesday

09:00 - 17:00

FPW64

Boots

11 NEW ROAD SIDE, RAWDON, LS19 6BA

01132502053

0.12

Monday

Tuesday

09:00 - 17:00

Cancel

No address fields

Unsorted results

Pharmacy Name silently ignored at API

Distance sorted

Opening times inline

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.

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.

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

Dead end with no signal

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

Zero extra steps

Predictable behaviour

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.

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?

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.

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

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.

Goal

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

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.

constraints

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.

No analytics

No reliable data on search behaviour or error frequency.

Legacy parity

OON needed to align with existing Primary Nomination patterns.

API limits

Postcode lookup capability was inconsistent across products.

Failure detection

Some failures were only visible after a search attempt.

DESIGN PRINCIPLES

P1 — Consistency

Match Primary Nomination patterns wherever possible.

P2 — Urgency Awareness

Reduce effort & surface the most actionable option first.

P3 — Graceful Recovery

Ensure failures always have a clear next step.

P4 — Minimal Change

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:

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.

Partial recovery

Postcode lookup unavailable

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.

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.

Clear recovery

Input issue, not system failure

Redirects to address or name search

Scenario 2

Postcode lookup unavailable

Partial recovery · inline banner

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.

Postcode is kept

Address and name still work

No false full-service failure

Scenario 3

Pharmacy search service unavailable

Operational fallback

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.

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.

System issue

Search cannot continue

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.

DESIGN DECISIONS

Every design choice had to balance urgency, familiarity, and feasibility.

Tension

Resolution

Friction Removed

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.

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.

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.

~15s saved per OON search

Friction removed

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.

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.

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.

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.

Proposal

DECISION

Replaced by

Postcode Lookup

Proposal

Rejected

DECISION

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

Proposal

DECISION

Rejected

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

Proposal

DECISION

Rejected

Increased API usage, introduced unnecessary network calls, and risked returning irrelevant results before the clinician had entered context.

replaced by

Postcode First

Accepted

Clinical Design Group confirmed postcode was the most common starting point during urgent prescribing scenarios.

Opening Hours Inline

Accepted

Removed the need for clinicians to cross-check opening times outside the workflow.

Address + Name Search Retained

Accepted

Supported recovery when postcode information was unavailable or incomplete.

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.

Future direction after EMIS Web

Conceptual Design : Designing a safe contextual One-Off Nomination experience for EMIS X

After solving the immediate One-Off Pharmacy reliability problem in EMIS Web, I explored how the same workflow could evolve in EMIS X GP. The opportunity is to bring One-Off Pharmacy guidance closer to the prescribing workflow by using relevant patient, prescribing, and pharmacy service context.

For EMIS X, the safer design direction is contextual prompting — not constant prompting.

What stays standard

Primary nomination remains the default

Routine prescriptions should continue through the patient’s nominated pharmacy when the route appears suitable.

What changes

OON becomes a supported decision

When relevant signals exist, EMIS X can surface guidance inside the medication issue flow, reducing the need to leave the task and manually investigate.

Bridge from EMIS Web to EMIS X

Why EMIS X changes the opportunity

In EMIS Web, the clinician has to recognise the need for One-Off Nomination, open the nomination area, choose One-Off Pharmacy and click Find. That gives control, but it separates the decision from the prescribing context. EMIS X creates an opportunity to surface pharmacy guidance at the point of prescribing rather than requiring clinicians to initiate a separate search journey.

EMIS Web pattern

EMIS-X OPPORTUNITY

OON is accessed through a separate nomination-management action.

Helps understand whether the patient already has a dispensing route and whether location context may matter.

The clinician must remember when OON may be appropriate.

Relevant patient, prescribing and pharmacy context can be checked earlier.

The search experience is manual and form-led.

The experience can support contextual guidance while keeping the standard route available.

The desktop workflow is constrained by established patterns.

The cloud product can use connected service capability and more responsive patterns.

Product feasibility

What EMIS X would need to support this safely

I treated this as a product feasibility problem, not only an interface idea. The concept assumes EMIS X has access to core patient, prescribing and nomination context, and could leverage connected pharmacy service integrations where available.

PATIENT CONTEXT

Who and where

Patient demographics, registered address, temporary address where captured, and existing nomination status.

Prescribing context

What is being issued

Acute/repeat context, issue timing, prescription method and whether the medication is being issued now.

Nomination context

Current route

Primary nomination and whether a one-off nomination is being selected for this prescription only.

Connected services

Pharmacy signals

Pharmacy directory/search data, opening hours and EPS-related service information where available.

Important product constraint

Important constraint: the quality of any prompt depends on service integration availability, data accuracy, clinical governance and Engineering validation.

Clinical decision support pattern

How the contextual prompt would work

Clinical decision support means using relevant information to help the clinician at the right moment. In this concept, EMIS X recognises context, explains the recommendation, and presents the most appropriate next action.

The safest pattern is: EMIS X notices context, explains the reason, and leaves the decision with the prescriber.

FACT

OON should remain temporary

One-Off Nomination applies to this prescription and must not replace the patient’s primary nomination.

INSIGHT

The task is not “search pharmacy”

The real decision is whether the patient can realistically use their usual dispensing route right now.

ASSUMPTION

Memory burden can be reduced

EMIS X can surface OON when context makes it relevant, rather than relying entirely on clinician recall.

Challenges and principles

Designing the prompt responsibly

Challenge

Avoid alert fatigue

The prompt should appear only when evidence is strong enough to be useful.

Challenge

Explain the reason clearly

The prompt must clearly say why it appeared, such as “primary pharmacy appears closed”.

Challenge

Handle uncertain data

Opening hours and service information may be incomplete, so language must remain careful.

Design principle

Application

P1 — Standard first

Do not interrupt routine medication issue when the nominated route looks suitable.

P2 — Recommend, don’t decide

The prompt supports a decision; the clinician remains responsible for the final choice.

P3 — Protect nomination

Make it explicit that selecting a one-off pharmacy will not change the primary nomination.

CONCEPTUAL DESIGN

Design options explored

I explored three options. Each keeps clinician control, but they differ in timing, interruption level and product maturity.

Option A

Manual OON action in issue panel

Bring the EMIS Web manual action into the EMIS X issue panel.

Why not recommended

Safe and simple, but still relies on clinician memory. It does not use EMIS X’s potential to support the decision contextually.

Option B

Recommended

Contextual OON prompt inside medication issue

Prompt only when patient, prescription and pharmacy context suggests the usual route may not be suitable.

Why not recommended

It uses connected context without removing control. The prescriber stays in the medication workflow, understands why the prompt appeared, and can choose the safest next step.

Recommended EMIS X flow

From standard issue to one-off pharmacy selection

This is the future flow I would recommend after service integrations and clinical safety governance are validated.

STEP 01

Standard medication issue flow

The clinician selects medication and clicks Issue. No OON prompt appears yet because the system should not interrupt before it has checked context.

STEP2

EMIS X to checks contextual signals before showing anything

The system checks whether the primary route appears suitable. If there is no issue, nothing changes. If there is a meaningful signal, the prompt appears.

Patient

Primary Nomination

Primary pharmacy exists.

PRESCRIPTION

Urgency

Acute medication, issue now.

SERVICE

Opening hours

Primary pharmacy appears closed.

RULE

OON relevance

Prompt is appropriate.

STEP 3

A contextual OON prompt appears inside the issue panel

The prompt explains the reason. It does not block the clinician unless the workflow requires it. The wording remains careful because service data can be imperfect.

STEP 4

Selects One-off Pharmacy

If the prescriber chooses to find a One-Off Pharmacy, EMIS X opens a focused selection drawer. Results are based on connected pharmacy service information and sorted around the clinical need: open, nearby, and EPS-capable where data supports it.

STEP 5

Return to issue panel

RECOMMENDATION

What I would recommend shipping

I would recommend shipping the contextual prompt as a future EMIS X concept only after service integrations and clinical safety governance are validated.

Recommended scope

Safe first release

Manual OON route always available.

Prompt only for high-confidence signals such as no nomination or primary pharmacy appears closed.

Never auto-select or change the pharmacy.

Measure carefully

Prompt acceptance rate.

Dismissal and override rate.

Time from prompt to pharmacy selection.

Prompt acceptance rate.

Dismissal and override rate.

Time from prompt to pharmacy selection.

Validate before scale

Clinical safety review.

Engineering feasibility review.

Data reliability checks for connected services.

Clinical safety review.

Engineering feasibility review.

Data reliability checks for connected services.

The design direction is safe because it keeps the standard prescribing route intact, while giving clinicians contextual support when the usual dispensing route may not be suitable.

IMPACT & REFLECTION

From a shipped EMIS Web solution to a future EMIS X opportunity

The shipped EMIS Web work solved the immediate reliability problem for One-Off Pharmacy search. The EMIS X concept extends the same learning into a safer, more contextual prescribing experience — while clearly separating what was delivered from what is a future-facing recommendation.

SHIPPED IMPACT · EMIS Web

Pharmacy search became more reliable under pressure

CLINICAL IMPACT

Made search failures easier to recover from during urgent prescribing tasks.
Provided clear next steps when pharmacy searches could only partially recover.

PRODUCT IMPACT

Shifted the focus from search usability to prescribing reliability.
Created reusable recovery and fallback patterns for future prescribing workflows.

team impact

Established a shared decision-making framework across cross-functional teams.
Focused discussions on clinical safety, feasibility, and workflow impact over UI preferences.

Future impact · EMIS X

The opportunity is to reduce reliance on clinician memory

Identified how contextual pharmacy guidance could fit within the prescribing workflow.

Defined the capabilities, service integrations, governance requirements, and safety principles needed to support future clinical decision support.

Established a future direction for EMIS X while keeping the delivered EMIS Web solution grounded in current platform constraints.

Identified how contextual pharmacy guidance could fit within the prescribing workflow.

Defined the capabilities, service integrations, governance requirements, and safety principles needed to support future clinical decision support.

Established a future direction for EMIS X while keeping the delivered EMIS Web solution grounded in current platform constraints.

Reflection

What initially appeared to be a pharmacy search problem turned out to be a reliability problem. By focusing on recovery, clarity, and clinician confidence, the design had a greater impact than redesigning the search interface alone. The most valuable outcome was helping clinicians understand what to do next when the usual dispensing route was no longer suitable.

The most valuable outcome was not a better pharmacy search. It was helping clinicians understand what to do next when the usual dispensing route was no longer suitable.

KOWSALYA