PRODUCT DESIGN CASE STUDY
PRODUCT DESIGN CASE STUDY
PRODUCT DESIGN CASE STUDY
Making Reasonable Adjustments visible at the point of care.
Reasonable Adjustment Flags (RAFs) ensure that a patient’s accessibility and support needs are clearly identified and acted upon during care. Rooted in the Equality Act 2010, they help healthcare providers anticipate needs such as communication support, longer appointments, or accessible formats. By making these needs visible within clinical workflows, RAFs enable safer and more equitable patient care.
Reasonable Adjustment Flags (RAFs) ensure that a patient’s accessibility and support needs are clearly identified and acted upon during care. Rooted in the Equality Act 2010, they help healthcare providers anticipate needs such as communication support, longer appointments, or accessible formats. By making these needs visible within clinical workflows, RAFs enable safer and more equitable patient care.
Headquarters
Headquarters
London, United Kingdom
London, United Kingdom
Founded
Founded
2006
Company
Company
Optum / EMIS
Industry
Industry
Healthcare
Company size
Company size
10,000+
The Problem
Accessibility is not a data problem. It is a visibility problem.
Every NHS site we observed was technically compliant. SNOMED codes ((standardized clinical data) were recorded. Equality Act obligations were documented.
Every NHS site we observed was technically compliant. SNOMED codes ((standardized clinical data) were recorded. Equality Act obligations were documented.
Yet 40% of interpreter bookings were being missed. Consultation restarts were routine. Clinicians were reaching clinical decisions without knowing a patient needed Easy Read materials, an interpreter, or an extended slot. The adjustment data existed in the record. The problem was that nothing surfaced it at the moment the clinician needed it — during the consultation itself.
Yet 40% of interpreter bookings were being missed. Consultation restarts were routine. Clinicians were reaching clinical decisions without knowing a patient needed Easy Read materials, an interpreter, or an extended slot. The adjustment data existed in the record. The problem was that nothing surfaced it at the moment the clinician needed it — during the consultation itself.
“
I open the record and I'm immediately into the consultation. There's nothing in front of me that flags this patient needs Easy Read — I find out when I hand them a leaflet and they look confused.
I open the record and I'm immediately into the consultation. There's nothing in front of me that flags this patient needs Easy Read — I find out when I hand them a leaflet and they look confused.
—
General Practitioner (6 years)
Regional Primary Care Centre
(Regional Primary Care Centre)
Note:
Data points derived from 1:1 clinical observations and expert user interviews during the Discovery phase.
Results
The redesigned system transformed hidden adjustment data into visible, actionable signals within the clinical workflow, enabling clinicians to access critical patient needs instantly without additional navigation.
The introduction of persistent visibility reduced access time from 10 or more minutes to under 5 seconds, eliminating the need for manual search during time-pressured consultations.
By surfacing adjustments at the point of care, the solution reduced missed adjustments and improved clinical decision-making, while also lowering the burden on patients to repeatedly disclose their need
The redesigned system transformed hidden adjustment data into visible, actionable signals within the clinical workflow, enabling clinicians to access critical patient needs instantly without additional navigation.
The introduction of persistent visibility reduced access time from 10 or more minutes to under 5 seconds, eliminating the need for manual search during time-pressured consultations.
By surfacing adjustments at the point of care, the solution reduced missed adjustments and improved clinical decision-making, while also lowering the burden on patients to repeatedly disclose their need
100%
100%
Inclusive Design: All RA (Reasonable adjustment) mandates coverage
Inclusive Design: All RA (Reasonable adjustment) mandates coverage
< 5 seconds
< 5 seconds
Flag visibility vs 15–45s with legacy search
Flag visibility vs 15–45s with legacy search
Zero
Zero
Missed adjustment flags. Validated from Expert clinical users
Missed adjustment flags. Validated from Expert clinical users
CONTEXT
CONTEXT
The Compliance Gap
Desk research established a stark finding: the existing system was simultaneously legally compliant and technically over-engineered. The Equality Act 2010 mandates anticipatory reasonable adjustments — meaning adjustments must be known and arranged before the patient arrives. NHS RBAC frameworks specified three permission tiers, yet no UI pattern existed to implement them.
Desk research established a stark finding: the existing system was simultaneously legally compliant and technically over-engineered. The Equality Act 2010 mandates anticipatory reasonable adjustments — meaning adjustments must be known and arranged before the patient arrives. NHS RBAC frameworks specified three permission tiers, yet no UI pattern existed to implement them.
What Existed (The False Compliance)
What Was Missing (The Real Gap)
Reasonable adjustment needs recorded at registration
Reasonable adjustment needs recorded at registration
Proactive surfacing at clinical touchpoints
Proactive surfacing at clinical touchpoints
Equality Act obligations documented
Equality Act obligations documented
Anticipatory adjustment workflow in the system
Anticipatory adjustment workflow in the system
NHS Spine infrastructure available
NHS Spine infrastructure available
GP system UI for managing and surfacing flags
GP system UI for managing and surfacing flags
NHS-standard RBAC permission tiers
NHS-standard RBAC permission tiers
Any UI pattern to implement RBAC visibly
Any UI pattern to implement RBAC visibly
Patient data stored in Patient care record
Patient data stored in Patient care record
Cross-organisational interoperability via NHS Spine
Cross-organisational interoperability via NHS Spine
“A system that discovers needs at the consultation door is structurally non-compliant with the Equality Act 2010.”
“A system that discovers needs at the consultation door is structurally non-compliant with the Equality Act 2010.”
“A system that discovers needs at the consultation door is structurally non-compliant with the Equality Act 2010.”
Discovery
Contextual enquiry
Contextual enquiry
Closing the Reality Gap
Field shadowing across 4 NHS sites revealed why the UI failed clinical workflows. Staff weren't misusing the system — the system was architecturally misaligned with how care actually happens.
Field shadowing across 4 NHS sites revealed why the UI failed clinical workflows. Staff weren't misusing the system — the system was architecturally misaligned with how care actually happens.
5
Participants
4
NHS Sites
3
Architecture Implications Identified
12
Field observation Notes
Three insights from the field
Three insights from the field
Insight 01 / 03
Record-Open Visibility Gap
Clinicians missed critical adjustment data because it was never visible at record open. Staff assumed patient was unaware — the data existed, just hidden.
Clinicians missed critical adjustment data because it was never visible at record open. Staff assumed patient was unaware — the data existed, just hidden.
Clinicians missed critical adjustment data because it was never visible at record open. Staff assumed patient was unaware — the data existed, just hidden.
Root cause
The system depends on a reactive search pattern, assuming clinicians have time to hunt for critical flags during time-pressured consultations.
The system depends on a reactive search pattern, assuming clinicians have time to hunt for critical flags during time-pressured consultations.
The system depends on a reactive search pattern, assuming clinicians have time to hunt for critical flags during time-pressured consultations.
Search Pattern Failure
Insight 02 / 03
Structured Data Breakdown
Complex clinical taxonomies pushed clinicians toward free-text entries. Over 300+ SNOMED options with no filtering — structured input felt slower than typing.
Complex clinical taxonomies pushed clinicians toward free-text entries. Over 300+ SNOMED options with no filtering — structured input felt slower than typing.
Complex clinical taxonomies pushed clinicians toward free-text entries. Over 300+ SNOMED options with no filtering — structured input felt slower than typing.
Root cause
No smart filtering or provenance capture — the system rewarded workarounds over compliance.
No smart filtering or provenance capture — the system rewarded workarounds over compliance.
No smart filtering or provenance capture — the system rewarded workarounds over compliance.
Free-Text Drift
Insight 03 / 03
Persistence Gap
Safety information disappeared when clinicians navigated between modules. Seen on Summary — gone by Prescribing. A 10-minute consultation spans 8 screens.
Safety information disappeared when clinicians navigated between modules. Seen on Summary — gone by Prescribing. A 10-minute consultation spans 8 screens.
Safety information disappeared when clinicians navigated between modules. Seen on Summary — gone by Prescribing. A 10-minute consultation spans 8 screens.
Root cause
Module-specific state — no globally persistent UI element carrying critical safety context.
Module-specific state — no globally persistent UI element carrying critical safety context.
Module-specific state — no globally persistent UI element carrying critical safety context.
Mid-consultation loss
From Evidence to Design Direction
From Evidence to Design Direction
Research tells you what is broken. How Might We questions reframe each failure as a design opportunity — the bridge between an observed problem and a testable solution space. Each question here is directly traceable to one of the three insights above.
Research tells you what is broken. How Might We questions reframe each failure as a design opportunity — the bridge between an observed problem and a testable solution space. Each question here is directly traceable to one of the three insights above.
1
How might we surface the RAF flag at the first point of contact — without requiring any deliberate navigation?
How might we surface the RAF flag at the first point of contact — without requiring any deliberate navigation?
Admin staff completed patient ID and check-in within 60 seconds. Flags hidden in deep tabs were consistently missed at this critical point of entry.
Admin staff completed patient ID and check-in within 60 seconds. Flags hidden in deep tabs were consistently missed at this critical point of entry.
Admin staff completed patient ID and check-in within 60 seconds. Flags hidden in deep tabs were consistently missed at this critical point of entry.
FIRST CONTACT VISIBILITY
DESIGN DIRECTION
RAF badge in precis bar — visible on record open
RAF badge in precis bar — visible on record open
2
Structured Data Failure
Structured Data Failure
How might we make creating compliant flag records faster than free-text — without increasing cognitive load?
How might we make creating compliant flag records faster than free-text — without increasing cognitive load?
Clinicians abandoned structured fields in under 10 seconds when faced with 300+ unfiltered options. Non-compliance was a UX failure, not a behaviour failure.
Clinicians abandoned structured fields in under 10 seconds when faced with 300+ unfiltered options. Non-compliance was a UX failure, not a behaviour failure.
Clinicians abandoned structured fields in under 10 seconds when faced with 300+ unfiltered options. Non-compliance was a UX failure, not a behaviour failure.
DESIGN DIRECTION
Pre-filtered SNOMED input with provenance capture (author, date, role) baked into creation flow
Pre-filtered SNOMED input with provenance capture (author, date, role) baked into creation flow
3
IA Architecture
IA Architecture
How might we design a secure, scalable home for RAF that accommodates future flag types without increasing legacy technical debt?
How might we design a secure, scalable home for RAF that accommodates future flag types without increasing legacy technical debt?
Integrating flags into existing legacy tabs creates technical fragility and prevents the RBAC enforcement required by NHS safety standards.
Integrating flags into existing legacy tabs creates technical fragility and prevents the RBAC enforcement required by NHS safety standards.
Integrating flags into existing legacy tabs creates technical fragility and prevents the RBAC enforcement required by NHS safety standards.
DESIGN DIRECTION
Dedicated Patient Flags page — RBAC enforced at page level
Dedicated Patient Flags page — RBAC enforced at page level
Architecture-ready container for CPIS and FGM flags on roadmap
Architecture-ready container for CPIS and FGM flags on roadmap
4
PERSISTENT FAILURE
PERSISTENT FAILURE
How might we keep the flag in a clinician's awareness across 8–12 screen transitions — without adding visual noise or viewport cost?
How might we keep the flag in a clinician's awareness across 8–12 screen transitions — without adding visual noise or viewport cost?
"Clinicians saw the flag on Summary, then it was gone 3 minutes later mid-prescription. Module-specific state meant safety context was lost every time the user navigated."
"Clinicians saw the flag on Summary, then it was gone 3 minutes later mid-prescription. Module-specific state meant safety context was lost every time the user navigated."
"Clinicians saw the flag on Summary, then it was gone 3 minutes later mid-prescription. Module-specific state meant safety context was lost every time the user navigated."
DESIGN DIRECTION
Précis bar badge — persists identically across all 12 EMIS modules. Zero viewport cost.
Précis bar badge — persists identically across all 12 EMIS modules. Zero viewport cost.
GAP ANALYSIS
DISCOVERY
Service Failure Map: Where the System Let Patients Down
Service Failure Map: Where the System Let Patients Down
Service Failure Map: Where the System Let Patients Down
Contextual inquiry across four NHS sites mapped the clinical encounter against adjustment visibility state. The failure pattern concentrated in the consultation workflow — the moment where a clinician's awareness of a patient's needs has direct clinical consequence.
Contextual inquiry across four NHS sites mapped the clinical encounter against adjustment visibility state. The failure pattern concentrated in the consultation workflow — the moment where a clinician's awareness of a patient's needs has direct clinical consequence.
Contextual inquiry across four NHS sites mapped the clinical encounter against adjustment visibility state. The failure pattern concentrated in the consultation workflow — the moment where a clinician's awareness of a patient's needs has direct clinical consequence.
ACTOR/LAYER
PATIENT
Pre-Consultation Prep
Gap
Adjustment needs not recorded at registration — patient assumes clinician is aware
Record Open
Normal
Needs to be known without re-disclosing — not surfaced at point of care
Active Consultation
Fail
Cannot re-disclose in 45-second consultation — communication approach mismatched
Clinical Decision
Fail
Decision made without adjustment data — wrong format or communication approach
Referral & Follow-Up
Fail
Adjustment needs not carried into referral — cycle restarts at next provider
CLINICIAN
Fail
No pre-consultation RAF signal — enters appointment with no awareness of adjustment needs
Gap
Précis bar absent from record open — must navigate to check for flags
Fail
RAF context lost mid-consultation — 45-second average to locate. Clinical decision timer running.
Fail
Decision made without adjustment context — wiring wrong format, pace or documentation
Fail
Referral letters lack RAF data — no SNOMED, no Spine sync
SYSTEM (EMIS)
Fail
No RAF signal in consultation view — worklist and queue carry zero adjustment context
Fail
Précis bar absent on record open — RAF indicator missing from core consultation screens
Fail
Adjustment data exists only in free-text Additional Information — no structure, no visibility hook
Fail
No SNOMED-coded RAF data available to inform clinical decision support
Fail
Free-text field — no Spine sync, no SNOMED coding, no structured export to referral or discharge
The Root Failure: Invisible Data at the Point of Care
The system held adjustment information but surfaced none of it during the clinical encounter. Clinicians were not failing to check — the system gave them no signal to act on. Visibility is not a behaviour problem. It is an architectural one.
“
I've worked here 12 years. I know Mrs. Anna Condo needs longer slots, Mr. John Doe needs Easy Read. But when I'm on holiday or we get a locum, there's no system that holds it.
I've worked here 12 years. I know Mrs. Anna Condo needs longer slots, Mr. John Doe needs Easy Read. But when I'm on holiday or we get a locum, there's no system that holds it.
I've worked here 12 years. I know Mrs. Anna Condo needs longer slots, Mr. John Doe needs Easy Read. But when I'm on holiday or we get a locum, there's no system that holds it.
—
GP
— GP
St Thomas Hospital
St Thomas Hospital
18 years experience
SOLUTION OVERVIEW
One Flag. Two Products. Five Surfaces. Three Role Views.
One Flag. Two Products. Five Surfaces. Three Role Views.
One Flag. Two Products. Five Surfaces. Three Role Views.
The RAF is not a feature in one product — it is a data point that surfaces differently across two EMIS products, five distinct UI surfaces, and three NHS RBAC role tiers. The design challenge was not where to put the flag. It was how to make a single structured record render the right level of information, to the right person, at the right workflow moment — without any surface ever disclosing more than its role is permitted to see.
The RAF is not a feature in one product — it is a data point that surfaces differently across two EMIS products, five distinct UI surfaces, and three NHS RBAC role tiers. The design challenge was not where to put the flag. It was how to make a single structured record render the right level of information, to the right person, at the right workflow moment — without any surface ever disclosing more than its role is permitted to see.
The Interaction Model: Signal → Bridge → Detail
The Interaction Model: Signal → Bridge → Detail
STEP 1
EMIS WEB
The Signal
A lightweight ⚑ flag appears in the Precis Bar on every patient screen. All roles see the presence of the flag. Nobody has to search for it.
A lightweight ⚑ flag appears in the Precis Bar on every patient screen. All roles see the presence of the flag. Nobody has to search for it.
A lightweight ⚑ flag appears in the Precis Bar on every patient screen. All roles see the presence of the flag. Nobody has to search for it.
Visible to all roles
Receptionists, admin, practice managers, clinicians — flag presence is universal. What differs is what happens when you click it.
Receptionists, admin, practice managers, clinicians — flag presence is universal. What differs is what happens when you click it.
STEP 2
EMIS WEB
The Bridge
Clicking the flag opens a Companion View — -screen panel that slides in from the right. The main EMIS Web screen stays open. The companion panel renders EMIS X content live, in context, without navigating away.
Clicking the flag opens a Companion View — -screen panel that slides in from the right. The main EMIS Web screen stays open. The companion panel renders EMIS X content live, in context, without navigating away.
RBAC Restrictions
The companion panel checks the user's role before rendering. Same entry point — completely different output depending on access tier.
The companion panel checks the user's role before rendering. Same entry point — completely different output depending on access tier.
STEP 3
EMIS X (Rendered in Companion)
EMIS X (Rendered in Companion)
The Detail
The EMIS X RBAC engine renders the appropriate view inside the companion panel. Same flag, same click — completely different disclosure depending on role.
The EMIS X RBAC engine renders the appropriate view inside the companion panel. Same flag, same click — completely different disclosure depending on role.
B0264 Reception / Admin
NHS-mandated helper text · No impairment · No SNOMED · Escalation options
NHS-mandated helper text · No impairment · No SNOMED · Escalation options
B0257 Clinician
Full clinical detail · SNOMED impairment · Adjustment · Provenance
Full clinical detail · SNOMED impairment · Adjustment · Provenance
B0257 Clinician
Full detail + Create · Edit · Delete · Audit log
Full detail + Create · Edit · Delete · Audit log
System Architecture — Two Products, One Flag
System Architecture — Two Products, One Flag
Strategic Justification
Designed as a federated system, EMIS Web surfaces lightweight visibility signals while EMIS X handles structured flag management, RBAC logic, and detailed views. This approach enabled a safe, scalable solution without rewriting the legacy booking workflow.
Designed as a federated system, EMIS Web surfaces lightweight visibility signals while EMIS X handles structured flag management, RBAC logic, and detailed views. This approach enabled a safe, scalable solution without rewriting the legacy booking workflow.
PRINCIPLES & CONSTRAINTS
Before a Single Screen Was Designed
Before a Single Screen Was Designed
Field research defined three frictions. Before moving to interaction design, the team needed to establish what the design was allowed to do, what it was forbidden from doing, and what principles would arbitrate every contested decision. These were not aspirational values — they were operational rules derived directly from the evidence.
Field research defined three frictions. Before moving to interaction design, the team needed to establish what the design was allowed to do, what it was forbidden from doing, and what principles would arbitrate every contested decision. These were not aspirational values — they were operational rules derived directly from the evidence.
Field research defined three frictions. Before moving to interaction design, the team needed to establish what the design was allowed to do, what it was forbidden from doing, and what principles would arbitrate every contested decision. These were not aspirational values — they were operational rules derived directly from the evidence.
Redefined Problem Statement
Redefined Problem Statement
Disabled patients attending GP practices have their reasonable adjustments recorded in EMIS — but those adjustments are structurally invisible to the staff responsible for acting on them. Receptionists book appointments without seeing flags. Practice managers prepare schedules without knowing who needs what. Clinicians enter consultations without adjustment context. The data existed. The legal duty was documented. The failure was entirely architectural: the system never surfaced what it stored, to the people who needed it, at the moment they needed it.
Disabled patients attending GP practices have their reasonable adjustments recorded in EMIS — but those adjustments are structurally invisible to the staff responsible for acting on them. Receptionists book appointments without seeing flags. Practice managers prepare schedules without knowing who needs what. Clinicians enter consultations without adjustment context. The data existed. The legal duty was documented. The failure was entirely architectural: the system never surfaced what it stored, to the people who needed it, at the moment they needed it.
Disabled patients attending GP practices have their reasonable adjustments recorded in EMIS — but those adjustments are structurally invisible to the staff responsible for acting on them. Receptionists book appointments without seeing flags. Practice managers prepare schedules without knowing who needs what. Clinicians enter consultations without adjustment context. The data existed. The legal duty was documented. The failure was entirely architectural: the system never surfaced what it stored, to the people who needed it, at the moment they needed it.
Design Principles
Design Principles
PRINCIPLE 01
Push, don't pull
Push, don't pull
Surface critical information at the right moment without requiring search.
Surface critical information at the right moment without requiring search.
PRINCIPLE 02
Structure, not just presence
Structure, not just presence
Make structured data the easiest path to ensure compliance and usability.
Make structured data the easiest path to ensure compliance and usability.
PRINCIPLE 03
Persist across context switches
Persist across context switches
Maintain visibility across screens to prevent loss of clinical context.
Maintain visibility across screens to prevent loss of clinical context.
PRINCIPLE 04
Clinical Safety over Admin Convenience
Clinical Safety over Admin Convenience
Prioritise patient safety over operational efficiency.
Prioritise patient safety over operational efficiency.
Non-Negotiable Constraints
These were not design decisions. They were fixed boundaries — legal mandates, technical limits, and NHS standards — that scoped every iteration before it was drawn.
These were not design decisions. They were fixed boundaries — legal mandates, technical limits, and NHS standards — that scoped every iteration before it was drawn.
Strict Role-Based Privacy
Receptionist
Only see flag presence. Full clinical details blocked. Exposing detail is a privacy breach
SNOMED CT Codes - NHS Mandate
Free-text flags banned.
Pre-excluded by NHS DAPB4019. Structured coding required for cross-practice interoperability and Spine data sharing.
Reasonable Adjustments
Adjustments
Flags must be anticipatory, not discovered during consultation
Allergy Alert Salience
Patient Safety
Cannot reduce visibility of existing safety signals (e.g. allergies)
Design Iterations
INSIGHT 01
Record open visibility → Search Pattern Failure
Challenge 1: Where Does the Badge Live?
Challenge 1: Where Does the Badge Live?
Two research insights converged on a single architectural question: where to place the RAF badge. Insight 01 said it must surface the moment a record opens — not require deliberate navigation. Insight 03 said it must persist across all 12 consultation modules without being lost mid-appointment. These are not two separate placement decisions. The right answer had to solve both simultaneously.
Two research insights converged on a single architectural question: where to place the RAF badge. Insight 01 said it must surface the moment a record opens — not require deliberate navigation. Insight 03 said it must persist across all 12 consultation modules without being lost mid-appointment. These are not two separate placement decisions. The right answer had to solve both simultaneously.
Two Root Causes, One Design Decision
Insight 01 — Booking Friction:
Staff hunted. The system didn't push.
Staff hunted. The system didn't push.
Receptionists were expected to remember to check flags — no trigger, no prompt. The flag had to inject itself into the moment a record opens, with zero extra navigation.
Receptionists were expected to remember to check flags — no trigger, no prompt. The flag had to inject itself into the moment a record opens, with zero extra navigation.
Needed: Push pattern
Needed: Push pattern
Insight 03 — Persistence Failure:
The flag vanished mid-consultation.
The flag vanished mid-consultation.
Visible on one module, gone the moment the GP navigated to Prescribing or Problems. Over a 10-minute, 8-screen consultation, context was lost repeatedly.
Visible on one module, gone the moment the GP navigated to Prescribing or Problems. Over a 10-minute, 8-screen consultation, context was lost repeatedly.
Needed: Global persistence
Needed: Global persistence
Three options explored
Three options explored
RAF Badge in Patient Search List
RAF Badge in Patient Search List
OPTION A
OPTION A
-
NOT FEASIBLE
NOT FEASIBLE
Flag surfaced in the patient search results — visible at the exact booking moment, before opening the record.
Engineering constraint
Each search row requires a separate API call to retrieve flag status — introducing latency across 6,500+ practices at scale. Ruled out in technical review before design progressed.
Each search row requires a separate API call to retrieve flag status — introducing latency across 6,500+ practices at scale. Ruled out in technical review before design progressed.
Full-width alert banner on Every Screen
Full-width alert banner on Every Screen
Full-width alert banner on Every Screen
OPTION B
OPTION B
-
NOT SELECTED
NOT SELECTED
A persistent banner at the top of every patient record screen — globally visible, impossible to miss.
A persistent banner at the top of every patient record screen — globally visible, impossible to miss.
Patient safety trade-off
Consumes 15% of clinical viewport, pushing problem lists and prescribing below the fold. More critically: competes directly with allergy and drug interaction banners. Clinicians develop reflexive dismissal — a direct safety regression on the most critical alerts in the system.
Consumes 15% of clinical viewport, pushing problem lists and prescribing below the fold. More critically: competes directly with allergy and drug interaction banners. Clinicians develop reflexive dismissal — a direct safety regression on the most critical alerts in the system.
Precis Bar Badge
RAF Badge in Precis Bar
OPTION B
OPTION B
-
sELECTED
sELECTED
Badge embedded in the précis bar — the one UI element that persists identically across all 12 EMIS consultation modules.
Badge embedded in the précis bar — the one UI element that persists identically across all 12 EMIS consultation modules.
EMIS WEB
EMIS X - GP
Decision: RAF badge in the precis bar
The precis bar is the only UI element that persists unchanged across all 12 EMIS modules. Placing the badge there satisfies both constraitns - it surfaces immediately when a record opens (Push pattern) and remains visible through every screen of the consultation (Global persistence) - while adding zero viewport cost and no competition with existing clinical alerts.
The precis bar is the only UI element that persists unchanged across all 12 EMIS modules. Placing the badge there satisfies both constraitns - it surfaces immediately when a record opens (Push pattern) and remains visible through every screen of the consultation (Global persistence) - while adding zero viewport cost and no competition with existing clinical alerts.
Push Pattern
Global persistence
Zero viewport cost
No alert competition
No alert competition
Technically feasible
"Zero viewport cost. Relies on peripheral vision, not deliberate attention."
Design Iterations
INSIGHT 03
Structured Data Failure → Unsupported SNOMED Entry
Challenge 3: How should clinicians create a flag?
NHS compliance requires every RAF record to be SNOMED-coded with impairment type, adjustment detail, and author provenance. Field research found clinicians abandoned the structured picker within seconds — not because they were careless, but because the system made compliance harder than non-compliance.
NHS compliance requires every RAF record to be SNOMED-coded with impairment type, adjustment detail, and author provenance. Field research found clinicians abandoned the structured picker within seconds — not because they were careless, but because the system made compliance harder than non-compliance.
The system failure
300+
Raw SNOMED codes presented as a flat, unfiltered list. No plain-language labels. No context. Clinicians spent more time navigating the picker than it took to type a free-text note — so they did exactly that.
Raw SNOMED codes presented as a flat, unfiltered list. No plain-language labels. No context. Clinicians spent more time navigating the picker than it took to type a free-text note — so they did exactly that.
The compliance consequence
0%
Structured, auditable flag records being produced. Records were uncodeable, invisible to SNOMED queries, and useless to locums or other practices reading them. The system produced the illusion of data.
Structured, auditable flag records being produced. Records were uncodeable, invisible to SNOMED queries, and useless to locums or other practices reading them. The system produced the illusion of data.
The design problem — before and after
The design problem — before and after
Before: Raw SNOMED picker
Before: Raw SNOMED picker
What Existed
What Existed
Clinical codes with no plain-language labels — clinicians don't speak taxonomy
No filtering, no context — every search starts from scratch
Provenance fields blank — author, role, date entered manually or left empty
Cognitive cost exceeds typing a note — free-text becomes the path of least resistance
After: Guided structured form
After: Guided structured form
Design solution
Design solution
Plain-language labels silently mapped to SNOMED — clinicians choose words, not codes
Three selections to completion — impairment type, adjustment, done
Provenance captured server-side — author, role, org, date. Never a manual field
Every record structured, coded, and auditable by design — not by discipline
DECISION LOGS
DECISION LOGS
Four specific design decisions — and why each was made
Four specific design decisions — and why each was made
Decision 01
Plain language over clinical taxonomy
Plain language over clinical taxonomy
Impairment and adjustment options use everyday clinical language — "Hearing impairment", "British Sign Language support" — not SNOMED codes. The mapping to taxonomy happens silently on submission. Clinicians never see a code unless they audit.
Impairment and adjustment options use everyday clinical language — "Hearing impairment", "British Sign Language support" — not SNOMED codes. The mapping to taxonomy happens silently on submission. Clinicians never see a code unless they audit.
Removes 300+ code cognitive load
Removes 300+ code cognitive load
Decision 02
Equality Act code auto-populates
Equality Act code auto-populates
The mandatory Equality Act classification is pre-populated and locked. It cannot be incorrectly entered or left blank. Compliance is enforced at the form level, not dependent on the clinician knowing the correct code.
The mandatory Equality Act classification is pre-populated and locked. It cannot be incorrectly entered or left blank. Compliance is enforced at the form level, not dependent on the clinician knowing the correct code.
Eliminates a class of compliance errors
Eliminates a class of compliance errors
Eliminates a class of compliance errors
Decision 03
Provenance captured server-side
Provenance captured server-side
Author name, role, organisation, and date are written automatically on form submission from the active session. They are never manual fields. Records are always attributable — a legal requirement under DAPB4019 — without adding a single extra step to the clinical workflow.
Author name, role, organisation, and date are written automatically on form submission from the active session. They are never manual fields. Records are always attributable — a legal requirement under DAPB4019 — without adding a single extra step to the clinical workflow.
DAPB4019-compliant by default
DAPB4019-compliant by default
Decision 04
Structured input = lower effort than free-text
Structured input = lower effort than free-text
The form was designed so that completing it takes fewer keystrokes than typing a free-text note. Two dropdowns and one click. If structured input is faster than unstructured input, compliance stops being a behaviour problem and becomes the natural path.
The form was designed so that completing it takes fewer keystrokes than typing a free-text note. Two dropdowns and one click. If structured input is faster than unstructured input, compliance stops being a behaviour problem and becomes the natural path.
Compliance through friction removal
Compliance through friction removal
Downstream benefit — book appointment modal
Downstream benefit — book appointment modal
Downstream benefit — book appointment modal
Because every flag record is now structured and SNOMED-coded, the booking appointment modal can query flag status reliably at the point of scheduling. Receptionists see the RAF indicator without opening the patient record — the structured creation flow makes this downstream surface possible. Without SNOMED structure, there is nothing to query.
Because every flag record is now structured and SNOMED-coded, the booking appointment modal can query flag status reliably at the point of scheduling. Receptionists see the RAF indicator without opening the patient record — the structured creation flow makes this downstream surface possible. Without SNOMED structure, there is nothing to query.
Decision: Guided structured form — plain language mapped to SNOMED
Decision: Guided structured form — plain language mapped to SNOMED
Compliance was being treated as a behaviour problem. It was an interaction design problem. By making structured input faster than free-text — through plain-language dropdowns, auto-populated fields, and server-side provenance — every record becomes coded and auditable by default. The clinician makes three choices. The system handles the rest.
Compliance was being treated as a behaviour problem. It was an interaction design problem. By making structured input faster than free-text — through plain-language dropdowns, auto-populated fields, and server-side provenance — every record becomes coded and auditable by default. The clinician makes three choices. The system handles the rest.
3 selections to completion
SNOMED-coded by default
DAPB4019 compliant
Provenance automatic
Faster than free-text
DAPB4019 compliant
Clinical VALIDATION
Simulation, Not Just Sign-Off
Simulation, Not Just Sign-Off
Clinical Design Group sign-off confirms experienced clinicians find the design coherent. It does not confirm a receptionist will locate a flag in 3 seconds under booking pressure. These are different validation questions — and both were tested.
Clinical Design Group sign-off confirms experienced clinicians find the design coherent. It does not confirm a receptionist will locate a flag in 3 seconds under booking pressure. These are different validation questions — and both were tested.
87%
Overall Design Confidence Score
Phase 1 MVP · Composite across 5 dimensions · Figma walkthrough sessions
Phase 1 MVP · Figma walkthrough sessions
Clinical Safety Adequacy
Clinical Safety Adequacy
94%
Workflow Integration
89%
RBAC Clarity
85%
Reception Task Completion
82%
Flag Creation Speed (≤30s)
79%
Workflow Integration
Workflow Integration
89%
RBAC Clarity
RBAC Clarity
85%
Reception Task Completion
Reception Task Completion
82%
Flag Creation Speed(≤30s)
Flag Creation Speed(≤30s)
79%
Scoring methodology: Composite of task completion rate in simulation (weighted 40%), Clinical Design Group rating 1–5 per dimension (weighted 40%), and heuristic evaluation score (weighted 20%). All scores based on Figma walkthrough sessions; not live deployment data.
Scoring methodology: Composite of task completion rate in simulation (weighted 40%), Clinical Design Group rating 1–5 per dimension (weighted 40%), and heuristic evaluation score (weighted 20%). All scores based on Figma walkthrough sessions; not live deployment data.
Clinical Design Director A
Clinical Design Director A
High
High
GP Partner · 22 years EMIS experience · 92%
"The persistent precis bar badge addresses a failure mode we've documented for years. Clinicians simply do not navigate to secondary tabs during time-pressured consultations. This finally solves it."
"The persistent precis bar badge addresses a failure mode we've documented for years. Clinicians simply do not navigate to secondary tabs during time-pressured consultations. This finally solves it."
Precis bar — pass
Precis bar — pass
RBAC tiers — pass
RBAC tiers — pass
Flag creation: 34s avg (target 30s)
Flag creation: 34s avg (target 30s)
Clinical Design Director B
Clinical Design Director B
High
High
GP Partner · 14 years EMIS experience · 88%
"The yellow flag badge is immediately distinct from allergy alerts — well-considered. The SNOMED category approach is sensible; I can complete a flag in under 30 seconds for most patients."
"The yellow flag badge is immediately distinct from allergy alerts — well-considered. The SNOMED category approach is sensible; I can complete a flag in under 30 seconds for most patients."
Badge colour semantics — pass
Badge colour semantics — pass
Flag creation flow — pass
Flag creation flow — pass
Requested bulk edit mode
Requested bulk edit mode
Clinical Safety Officer
Clinical Safety Officer
High
High
NHS Digital · RBAC Compliance · 94%
"RBAC implementation is correct and auditable. Provenance metadata on every flag is essential for legal compliance — this is designed correctly. The flag icon choice is well-reasoned: condition-neutral and future-proof for CPIS and FGM."
"RBAC implementation is correct and auditable. Provenance metadata on every flag is essential for legal compliance — this is designed correctly. The flag icon choice is well-reasoned: condition-neutral and future-proof for CPIS and FGM."
B0257 clinical view — pass
B0257 clinical view — pass
Provenance metadata — pass
Provenance metadata — pass
Practice Manager
Practice Manager
Medium
Medium
Operations Lead · 3 NHS sites · 78%
"Reception staff will need formal training on what the flag means. The presence modal language is clear — they know exactly what to do. Concern: locums won't know to look for the badge without induction."
"Reception staff will need formal training on what the flag means. The presence modal language is clear — they know exactly what to do. Concern: locums won't know to look for the badge without induction."
Precis bar — pass
Precis bar — pass
Locum onboarding gap flagged
Locum onboarding gap flagged
Bulk import — deferred
Bulk import — deferred
Future Opportunities
PHASE 2
Handoff Coverage — Making the Flag Travel
Prescribing Screen Contextual Prompt
Prescribing Screen Contextual Prompt
'Patient has adjustments — verify label format.' Active acknowledgment at pharmacy handoff. ~1–2 weeks.
'Patient has adjustments — verify label format.' Active acknowledgment at pharmacy handoff. ~1–2 weeks.
'Patient has adjustments — verify label format.' Active acknowledgment at pharmacy handoff. ~1–2 weeks.
Medium
Medium
Referral Form RAF Inclusion
Referral Form RAF Inclusion
'RAF present — include in referral letter?' One click inserts structured data into hospital referral. ~3–4 weeks.
'RAF present — include in referral letter?' One click inserts structured data into hospital referral. ~3–4 weeks.
'RAF present — include in referral letter?' One click inserts structured data into hospital referral. ~3–4 weeks.
High
High
Follow-Up Booking Carry-Forward
Follow-Up Booking Carry-Forward
'Previous: BSL Interpreter arranged. Confirm?' Eliminates most common handoff failure. ~3 weeks.
'Previous: BSL Interpreter arranged. Confirm?' Eliminates most common handoff failure. ~3 weeks.
'Previous: BSL Interpreter arranged. Confirm?' Eliminates most common handoff failure. ~3 weeks.
Medium
Medium
Local ↔ NHS Spine Bi-Directional Sync
Local ↔ NHS Spine Bi-Directional Sync
Flags created locally sync to NHS Spine PDS via Patient Flag API + CIS2. ~6 weeks.
Flags created locally sync to NHS Spine PDS via Patient Flag API + CIS2. ~6 weeks.
Flags created locally sync to NHS Spine PDS via Patient Flag API + CIS2. ~6 weeks.
High
High
PHASE 3
Equity Closure — Zero Re-Disclosure, Everywhere
Cross-Organisational Spine Sync
RAF flags travel to secondary care, community nursing, mental health, and pharmacy via Spine. Patient arrives anywhere in NHS — adjustment record already there.
RAF flags travel to secondary care, community nursing, mental health, and pharmacy via Spine. Patient arrives anywhere in NHS — adjustment record already there.
very High
very High
Patient-Facing Flag Management via NHS App
Patients propose, update, consent to their own flags through NHS App — no clinical appointment required.
Patients propose, update, consent to their own flags through NHS App — no clinical appointment required.
very High
very High
Strategic Positioning: Why Phase 1 Ships First
Strategic Positioning: Why Phase 1 Ships First
All Phase 1 features sit in the high-impact, low-complexity quadrant — solving documented visibility failures (40% adjustment miss rate) with UI-level changes requiring no external API dependencies. Total implementation: ~6 weeks. Phase 2 features deliver equal impact but require 3–6 weeks each due to API integration. By shipping Phase 1 first, we reduce patient harm immediately while Phase 2 engineering runs in parallel.
All Phase 1 features sit in the high-impact, low-complexity quadrant — solving documented visibility failures (40% adjustment miss rate) with UI-level changes requiring no external API dependencies. Total implementation: ~6 weeks. Phase 2 features deliver equal impact but require 3–6 weeks each due to API integration. By shipping Phase 1 first, we reduce patient harm immediately while Phase 2 engineering runs in parallel.
REFLECTION
What This Project Taught Me
What This Project Taught Me
Clinical Design Group sign-off confirms experienced clinicians find the design coherent.
1
Observation outperforms interviews
Staff consistently said in interviews they needed "better documentation." Observation revealed they didn't read documentation — they scanned headers. One observed behavior changed the entire system architecture from a Search pattern to a Persistence pattern. In healthcare, contextual inquiry is non-negotiable.
Staff consistently said in interviews they needed "better documentation." Observation revealed they didn't read documentation — they scanned headers. One observed behavior changed the entire system architecture from a Search pattern to a Persistence pattern. In healthcare, contextual inquiry is non-negotiable.
2
Trust is an architectural decision
Provenance metadata was added because without it, locums ignored flags entirely. Trust in a clinical system cannot be assumed — it must be designed. Author visible, organisation visible, date visible, without additional clicks. When a locum can verify who created a flag, they act on it.
Provenance metadata was added because without it, locums ignored flags entirely. Trust in a clinical system cannot be assumed — it must be designed. Author visible, organisation visible, date visible, without additional clicks. When a locum can verify who created a flag, they act on it.
3
Knowing when not to build
Refusing bulk import and legacy migration in Phase 1 was the correct call — and required holding the line under genuine stakeholder pressure. The risk/impact matrix made that conversation concrete. "High complexity, low clinical value" is not an opinion; it is a documented position that can be defended.
Refusing bulk import and legacy migration in Phase 1 was the correct call — and required holding the line under genuine stakeholder pressure. The risk/impact matrix made that conversation concrete. "High complexity, low clinical value" is not an opinion; it is a documented position that can be defended.
4
What I'd do differently
Capture quantitative baselines before deployment: interpreter booking rates, check-in durations, consultation restart frequencies. Without pre-deployment data, impact can only be described, not measured. I would also run a cross-organisational pilot earlier in Phase 2 to surface NHS Spine API edge cases before engineering lock-in.
Capture quantitative baselines before deployment: interpreter booking rates, check-in durations, consultation restart frequencies. Without pre-deployment data, impact can only be described, not measured. I would also run a cross-organisational pilot earlier in Phase 2 to surface NHS Spine API edge cases before engineering lock-in.
“
The persistent precis bar badge addresses a failure mode we've documented for years. Clinicians simply do not navigate to secondary tabs during time-pressured consultations. This finally solves it.
The persistent precis bar badge addresses a failure mode we've documented for years. Clinicians simply do not navigate to secondary tabs during time-pressured consultations. This finally solves it.
— Clinical Design Directors, EMIS Group · 36+ years combined NHS system experience
NHS Wales - One off Pharmacy nomination
Optum Healthcare / EMIS Group
Healthcare systems
Kowsalya Ramachandran
UX Designer
Optum Healthcare
Reasonable adjustment flag case study
Kowsalya Ramachandran
UX Designer
Optum Healthcare
Reasonable adjustment flag case study
Optum Healthcare / EMIS Group
Healthcare systems
Kowsalya Ramachandran
UX Designer
Optum Healthcare