Referral Copilot: find care nearby, backed by evidence

Inspiration

When someone in India needs a specific kind of care — say dialysis near Jaipur — a care coordinator has to find a facility that actually provides it, that's actually nearby, and then trust that information enough to act on it. Today that means hours of phone calls, stale directories, and guesswork. We wanted to turn "location + care need" into an evidence-backed shortlist you can act on in seconds — without ever letting an AI invent a fact about someone's health options.

What it does

Referral Copilot takes a plain-English request like "dialysis near Jaipur" and returns a ranked shortlist of healthcare facilities, where every claim is cited from the underlying dataset:

• Ask in plain English. A Foundation Model parses free text into need + city + state. Crucially, the LLM only parses the question — it never ranks results and never generates evidence.
• Real proximity, not just name-matching. We rank by true geographic distance to the place you searched, surfacing good options in neighbouring towns too — not only exact city-name matches.
• Two independent trust signals per result. (1) A facility-level evidence score (0–12) for how well-documented the facility is, and (2) a per-need signal showing whether the searched service is cited (capability claim + source), listed (specialty), or only mentioned in free-text — flagged in amber so weak evidence is never hidden.
• Act on it. Click-to-call, website links, and a personal shortlist with notes, status overrides, and review decisions — all persisted per user.

How we built it

A Databricks App built on AppKit (TypeScript + React):

• The Virtue Foundation healthcare dataset lives in Unity Catalog; we query it through a Serverless SQL Warehouse.
• Ranking + the evidence score + proximity all run in SQL (parameterized, no string interpolation). We derive each city's reference point from the dataset's own coordinates using the median of lat/lon (robust to mis-geocoded rows), then rank by great-circle (haversine) distance:

$$ d = 2r\,\arcsin!\sqrt{\sin^2!\frac{\Delta\varphi}{2} + \cos\varphi_1\cos\varphi_2\sin^2!\frac{\Delta\lambda}{2}} $$

• Natural-language parsing calls Databricks Model Serving (Llama 3.3 70B) via a guarded /api/parse-query route that returns strict JSON validated with Zod.
• User actions (shortlist, notes, status) persist in Lakebase (Postgres), with the app's service principal owning the schema.

Challenges we ran into

• Separating "facility is documented" from "evidence for this need." A facility could score "Strong · 12" yet only mention the searched service in free text. We solved this with two explicit, independently-labeled signals instead of one misleading number.
• Proximity that doesn't lie. Averaging coordinates was thrown off ~20 km by outliers in big cities; switching to the median fixed it.
• Keeping the AI honest. We deliberately confined the LLM to parsing only, so 100% of displayed evidence is traceable to a dataset column — and added an in-app explainer of exactly how confidence is computed.
• Cold starts. Warehouse + Model Serving + Lakebase all auto-suspend; we built a warm-up routine and graceful degradation (structured search still works if NL parsing is down).

What we learned

Trust is a UX problem as much as a data problem. Surfacing uncertainty honestly — and showing the cited source behind every claim — does more for credibility than a single confidence number ever could.

What's next

A live map with road-distance routing (vs. straight-line today), capacity-aware ranking, and a referral hand-off that contacts the facility directly. The evidence spine — cited claims, never fabricated — stays the same.

Built With

• databricks-appkit
• databricks-apps
• databricks-model-serving
• databricks-sql-(serverless-warehouse)
• express.js
• foundation-model-api
• lakebase
• llama-3.3-70b
• node.js
• playwright
• postgresql
• react
• tailwind-css
• typescript
• unity-catalog
• vite
• zod