“Not a UX problem but a language layer problem. Patients speak symptoms. Hospitals organize by specialty.”
Built for a product management interview, then rebuilt from a single-file demo into a working prototype - sourced from the real deck and build history.
The problem came from primary research, including live-testing a real competitor.
Primary Research
Tested 5 hospital DXE sites with real symptom queries: "knee pain," "chest tightness," "memory issues."
Every site: generic specialty lists, 50+ results, no ranking logic.
NYU Langone · Live Test
Typed "shoulder pain" into NYU’s real AI assistant. Answered its follow-ups.
Result: a 30+ insurance sub-plan wall, then "I cannot book. Click the link."
Mount Sinai · Ops Data
Interviewed the Ambulatory team, reviewed patient navigation data directly.
"Wrong department" is the top friction. Every wrong visit delays care.
ArrivesHospital site
↓→
SearchesFind a Doctor
↓→
FiltersSpecialty / Ins.
↓→
AbandonsLeaves to Google
↓→
ConvertsBooks appt
02
The problem Cura solves
That core insight above came from primary research across 14 sites and the Mount Sinai interview. It goes one layer deeper than just language, though.
Patients decide in layers: insurance and location fit first, then trust signals like reviews and ratings, then availability, language, and gender, in that order. A specialty-first search skips straight past all of that.
77%
of patients start care journeys online
50%
specialty mismatch rate for conditions like headache
$300–800
admin cost per wrong-specialty referral
The chain every hospital site forces, and where Cura cuts in
Patient has a symptom
Cura cuts here
Must self-select a specialty
→
Searches within that specialty
→
Often the wrong department
Every hospital site depends on the patient already knowing which specialty their symptom maps to. Cura decouples that step, accepting the symptom directly and doing the specialty mapping itself.
Exhibit A: the competitor gap
Asked to book, it can only confirm a specialty type, then hands off to a phone number or a separate provider search. No name, no ranking, no booking.nyulangone.org/ai-assistant
03
What I considered instead
Every choice was deliberate, benchmarked directly against what NYU Langone actually shipped and where it failed live.
How Cura actually works, in 3 steps
1Symptom Intake
Patient types in plain language. AI classifies urgency, body system, care level.
Max 2–5 dynamic follow-ups. Each extra step costs form completion.
→
2Intelligent Matching
Clinical ontology maps symptom to specialty, filtered by insurance, location, availability.
Top 3 with plain-language reasoning. Patients view 10+ profiles before choosing; this replaces that with 3.
→
3Guided Conversion
Doctor profiles show condition-specific fit. One-click booking, symptom pre-fills the intake.
Completes inside DXE. Closing the loop here is what avoids the handoff drop-off.
Decision by decision, against the competitor benchmark
Decision
What NYU built
Our choice, and why
Symptom → Specialty
Silent routing, no reasoning shown
Explained in plain language. Trust requires transparency.
Insurance intake
30+ sub-plan dropdown wall
"Tell us your insurance" → auto-matches top 3 providers
Doctor selection
Availability only
Ranked by condition fit + availability
Why this doctor
Specialty label only, no context
One sentence: why this doctor fits your situation
Booking completion
"Click link" handoff that loses the patient from the funnel
Completes inside DXE with zero handoff friction
Symptom → Specialty
What NYU builtSilent routing, no reasoning shown
Our choice, and whyExplained in plain language. Trust requires transparency.
Insurance intake
What NYU built30+ sub-plan dropdown wall
Our choice, and why"Tell us your insurance" → auto-matches top 3 providers
Doctor selection
What NYU builtAvailability only
Our choice, and whyRanked by condition fit + availability
Why this doctor
What NYU builtSpecialty label only, no context
Our choice, and whyOne sentence: why this doctor fits your situation
Booking completion
What NYU built"Click link" handoff that loses the patient from the funnel
Our choice, and whyCompletes inside DXE with zero handoff friction
The “Symptom → Specialty” and “Insurance intake” rows above are step 1 of the flow shown earlier. Here's what that step actually looks like, live.
Exhibit B: the chosen approach, live
Plain-language input, sample prompts, no account required. The “explainable, in-flow” bet made visible.
04
Assumptions I'm making
Each one labeled by how confident I actually am.
Inferred, not tested
Explainability builds trust where silent AI routing didn't
A direct contrast to NYU's silent match, but never validated head-to-head, only against their live failure
Backed by Zocdoc: patients view ~21 profiles before choosing. Reducing that is the actual bet.
Pending Phase 1 test
Closing the loop inside DXE prevents the drop-off NYU had
Untested at scale. Phase 1's A/B test against the current keyword finder is where this gets proven.
05
What I'd cut under tighter constraints
Phase 1 is already the minimum. Under more pressure, the cut is inside Phase 1 itself. The multilingual, voice, and mobile work was never in scope for v1.
Phase 1 · Weeks 1–4
Discover & Validate
NLP symptom intake
Hard-coded ER/urgent/PCP triage
Explainable match UI
A/B vs. keyword finder
Target: 2× booking conversion
Phase 2 · Weeks 5–10
Build & Pilot
Multilingual input (20+ languages)
Live payer-API insurance verification
Pre-visit physician brief
Target: 18% no-show reduction
Phase 3 · Weeks 10–16
Scale & Package
Voice-first interface
Longitudinal symptom tracking
Standalone mobile app
Target: $3–5M ARR module
06
Risks I was watching for
Competitive first, then the build and operational risks that came up while actually shipping it.
Competitive
Amazon One Medical
High
Closed ecosystem, $99/yr fee, no multisystem network
High
Ada Health
Med
No EHR context, no booking, no hospital integration
Med
Current hospital tools
Low
90% specialty mismatch, stale data, zero AI
Low
Build & operational
Safety rule
Emergency symptom reaches doctor-matching anyway
Hard rule: triage runs first. If "emergency," the flow MUST stop before clarifying questions. Never doctor cards.
Cost design
Token/inference cost scales with every query
Fast classifier first, LLM only for ambiguous cases. A cost-engineering call as much as a UX one.
Architecture
New infrastructure adds integration risk
Shipped as one Drupal module that inherits existing Salesforce, Eloqua, and Analytics wiring.
Fixed
External model dependency breaks silently
A deprecated Gemini model returned a raw error to users. Found it re-testing for this case study.
Open
Fictional hospital reads as a real one
Still open. No disclaimer live yet on the prototype.
The modeled conversion jump behind the $37.5M figure
3.5%
Baseline Find-a-Doctor conversion
+ Cura
Symptom-to-specialist routing
10%
Target conversion, Phase 1
Baseline and target use the midpoints of the deck’s own stated range (3-4% and 8-12%) - Cura is a prototype, so these are modeled projections rather than measured conversion data.
Health System
$37.5M
modeled annual uplift for a mid-size system, from 3 - 4% → 8 - 12% Find-a-Doctor conversion
Patient
18 - 24%
fewer no-shows with pre-visit communication, on top of a right-specialty-first match
Cura
$2.5M ARR
at 50 clients, as a premium DXE module, ~2.4yr break-even per client
Get in Touch
Let's talk about what you're building.
Interested in how I can help your team ship faster? I'd love to hear what you're working on.
