Streamlining EMR Search for Faster, Safer Patient Matching

Care coordinators were spending 2–3 minutes manually matching medical faxes to patient records a slow, error-prone process with privacy risks. I led end-to-end research and design to transform this into a confident ~60-second workflow.

team:

1 Product Manager

1 Designer

2 Developers

1 Product Manager

1 Designer

2 Developers

ROLE:

Product Designer

timeline:

4 months

Overview

Dialogue is a virtual healthcare platform serving 1M+ patients across Canada. Care Coordinators (CTMs) triage hundreds of incoming medical faxes daily — matching each one to the correct patient record before routing it to the right care team. Speed and accuracy aren't just efficiency goals here, a mismatch is a privacy breach.

The existing EMR search only supported three fields: name, email, and date of birth. When faxes arrived with incomplete or inconsistent information, CTMs had no fallback — just guesswork and time.

My responsibilities: User shadowing and workflow mapping · Ideation and prototyping within EMR constraints · Validating designs through usability testing · Collaborating with PMs and engineers to ship

impact

66%

faster patient matching
(2–3 min → ~60 sec)

< 1%

mismatch rate
(post-launch QA audits)

$15k

monthly operational savings
(time saved × CTM hourly cost)

problem

Receive fax with limited identifiers
Search name → multiple similar results
Open 5–6 profiles in tabs
Manually compare DOB, address, phone
Second-guess the decision
Repeat for the next fax

Why this mattered:

100+ faxes weekly = 16–25 hours of additional investigation time per week
High cognitive load during triage meant less time for patient-facing work
Privacy risk: a wrong match = PHI breach with legal and trust implications

Why this mattered:

100+ faxes weekly = 16–25 hours of additional investigation time per week
High cognitive load during triage meant less time for patient-facing work
Privacy risk: a wrong match = PHI breach with legal and trust implications

I wish we could search by phone number at the least. It’d make my life so much easier

Mariah (Care Coordinator)

research + discovery

My approach

To understand the real workflow (not assumptions), I embedded with the CTM team for 2 weeks and combined qualitative and operational data.

8 SHADOWING SESSIONS

12 CONTEXTUAL INTERVIEWS

WORKFLOW MAPPING

ANALYZED 100+ SUPPORT TICKETS

Key insights

1. The search fields didn't match what was on faxes
90% of faxes included phone numbers or Health IDs — but these weren’t searchable. CTMs defaulted to partial-name guessing.

2. Disambiguation—not search—was the core problem
Common names returned many matches. The real challenge was narrowing results confidently.

3. Fear of mistakes drove behaviour
The biggest pain wasn’t time — it was anxiety about privacy breaches. CTMs optimized for safety over speed.

1. The search fields didn't match what was on faxes
90% of faxes included phone numbers or Health IDs — but these weren’t searchable. CTMs defaulted to partial-name guessing.

2. Disambiguation—not search—was the core problem
Common names returned many matches. The real challenge was narrowing results confidently.

3. Fear of mistakes drove behaviour
The biggest pain wasn’t time — it was anxiety about privacy breaches. CTMs optimized for safety over speed.

Constraint That Shaped the Solution

Phone numbers and Health IDs lived in a separate legacy database. The system couldn’t reliably interpret numeric input (e.g., phone vs Health ID vs email fragment).

Engineering viewed unifying these as a multi-month backend effort. This meant the solution couldn't rely on a unified search backend — the design had to work around the data constraint, not wait for it to be resolved.

Phone numbers and Health IDs lived in a separate legacy database. The system couldn’t reliably interpret numeric input (e.g., phone vs Health ID vs email fragment).

exploration

How might we enable phone and Health ID search without waiting 6+ months for backend changes?

Constraints to consider:

Separate databases for different identifier types
System can't auto-detect what type of number the user is entering
Solution needed to ship in weeks, not months
CTMs had varying tech literacy—some very comfortable, others less so

Separate databases for different identifier types
System can't auto-detect what type of number the user is entering
Solution needed to ship in weeks, not months
CTMs had varying tech literacy—some very comfortable, others less so

I explored three approaches: search-type dropdown, radio button selectors, and prefix-based search — evaluating each against usability, speed, and engineering feasibility.

Let's compare concepts:

Concept

Dropdown

Radio

Prefix

Usability

Low

Medium

High

Speed

Slow

Medium

Fast

Dev. Effort

Low

Verdict

❌

✅

Prefix-based search was the clear direction: familiar pattern, minimal backend lift, and it supported both novice and power users without adding friction to every search.

Concept 3: Prefix Based Search

Early prototype of prefix-based search logic

Hypothesis
Use prefixes (phone:, id:, email:) to signal search type.

What worked

Familiar pattern from other tools
Minimal engineering lift
Supported both novice and power users
Allowed stacked queries
Enabled clear match highlighting

Decision
Moved forward with this direction.

Hypothesis
Use prefixes (phone:, id:, email:) to signal search type.

What worked

Familiar pattern from other tools
Minimal engineering lift
Supported both novice and power users
Allowed stacked queries
Enabled clear match highlighting

Decision
Moved forward with this direction.

solution: prefix-based search w/ smart feedback

The solution focused on helping CTMs search confidently without adding friction or requiring backend restructuring.

Prefix search with smart match highlighting and stacked filters

How the solution works:

CTMs could use familiar prefixes to signal intent, enabling precise search without new UI controls.

phone: 5551234567 → phone search
id: AB123456 → Health ID search
email: sarah@email.com → email search
Sarah Johnson → default name search
phone: 555 name: Sarah → stacked filters

CTMs could use familiar prefixes to signal intent, enabling precise search without new UI controls.

phone: 5551234567 → phone search
id: AB123456 → Health ID search
email: sarah@email.com → email search
Sarah Johnson → default name search
phone: 555 name: Sarah → stacked filters

Design principles that guided the solution

Progressive disclosure
Power features for those who want them, simple defaults for everyone else.

Immediate feedback
Each keystroke shows what matched and why.

Forgiveness over precision
Typos and syntax mistakes gracefully fall back to standard search.

What I Owned End-to-End

Interaction specs: Documented every state (empty, typing, results, no results, errors)
Component library additions: Designed reusable "matched field highlight" component for future search features
Accessibility: Ensured screen readers announced "Phone number match" when highlighting appeared
Responsive behavior: Optimized for the mix of large monitors (desktops) and smaller screens (some CTMs used laptops)
Developer handoff: Built interactive Figma prototype with all states + annotations for edge cases

Interaction specs: Documented every state (empty, typing, results, no results, errors)
Component library additions: Designed reusable "matched field highlight" component for future search features
Accessibility: Ensured screen readers announced "Phone number match" when highlighting appeared
Responsive behavior: Optimized for the mix of large monitors (desktops) and smaller screens (some CTMs used laptops)
Developer handoff: Built interactive Figma prototype with all states + annotations for edge cases

validation & results

Before full rollout, we ran a 2-week beta with 10 CTMs behind a feature flag to validate the experience in real conditions.

You don't know how amazing this is. Our team is blasting through triaging now.

james (Care Coordinator)

How work actually changed:

Phone number became the primary identifier (85% of searches)
CTMs stopped cross-checking multiple profiles — confidence replaced guesswork
No confusion around syntax or usage
100% adoption within 24 hours of full rollout, zero critical issues reported

Phone number became the primary identifier (85% of searches)
CTMs stopped cross-checking multiple profiles — confidence replaced guesswork
No confusion around syntax or usage
100% adoption within 24 hours of full rollout, zero critical issues reported

Business ripple effects

Faster record updates → quicker clinical decisions
Estimated 2–4 hour improvement in urgent referral response times
Team handled increased fax volume without added headcount
Improved client reporting gave enterprise partners clearer visibility into Dialogue's impact — strengthening ROI conversations and renewal confidence

Faster record updates → quicker clinical decisions
Estimated 2–4 hour improvement in urgent referral response times
Team handled increased fax volume without added headcount
Improved client reporting gave enterprise partners clearer visibility into Dialogue's impact — strengthening ROI conversations and renewal confidence

what's next?

Early OCR tests showed ~95% accuracy for auto-assignment — validating that automation could eventually eliminate manual triage for structured faxes entirely. This work helped spark broader automation initiatives across the product.

Long-term, database unification would enable true auto-detection without prefixes. The user value validated here is now helping prioritize that infrastructure investment.

Thanks for reading!

Take me home

Next: Event Tracking Automation

Download CV