Inspiration

Healthcare planning in India is difficult - not because of a lack of data but because of a lack of trust in the data. We kept coming back to the same question: if a district shows up blank on a coverage map, does that mean people there have no access to care, or just that nobody recorded it properly? That distinction matters enormously when you're deciding where to send resources. Disha started as an attempt to answer it honestly.

What it does

Disha helps non-technical planners find where healthcare is actually missing across India, not just where the data runs out. Planners select a capability (maternity, ICU, NICU) and a geography, and Disha returns a map of districts categorized by risk: real deserts where coverage is sparse and health outcomes back it up, data poor regions where coverage is sparse but outcomes are fine, and hidden risks where there are enough facilities on paper but the survey data tells a different story. Every claim is backed by citations from the underlying facility text, and confidence levels are surfaced so planners know when to trust the signal and when to dig deeper.

How we built it

FastAPI backend, React and TypeScript frontend, deployed as a Databricks App. The core data pipeline joins three Delta Lake tables: 10,000 facility records, a 165,000 row pincode directory, and 706 district level NFHS-5 health survey rows. We extracted structured capability evidence from free text facility descriptions and weighted that evidence by source reliability. The frontend uses Leaflet for an interactive choropleth map with stripe patterns to communicate low confidence districts visually.

Challenges we ran into

The NFHS to pincode join was the single hardest problem. Government district names across three datasets were spelled differently, abbreviated differently, or renamed entirely after administrative reorganizations. We ended up building three resolution layers: a SQL normalization step, a state alias file, and a 141 row district alias table, 75 auto accepted via fuzzy string matching and 66 hand curated. There was also a literal "null" string in the facility data (not a SQL null, the actual text "null") that silently broke zip code lookups until we caught it in EDA.

On the frontend, matching API district names to GeoJSON geometry required another round of fuzzy matching because the spelling inconsistencies were completely different from the ones we had already solved on the SQL side.

Accomplishments that we're proud of

Getting to 100% NFHS district coverage after starting with that join mess felt like a real milestone. The confidence weighted categorization system, distinguishing real deserts from data gaps instead of just counting facilities, is the core of the whole thing and we're glad it held up. The stripe pattern for low confidence districts is a small detail but we think it's the right way to show uncertainty without cluttering the UI.

What we learned

Data quality work is the product when you're building a planning tool. A confident wrong answer is worse than an honest "we're not sure." We also hadn't fully appreciated how big the gap is between a facility existing and a facility being capable. A clinic that mentions ICU in a single sentence is not the same as one with detailed equipment records, and treating them the same produces bad maps.

What's next for Disha

Scenario planning, letting a planner add a hypothetical facility to a district and see how the map changes. And the underlying approach isn't India specific. Anywhere you have facility registries and health survey data, the same framework applies. The problem of separating coverage gaps from data gaps is pretty universal.