Inspiration
Healthcare planning fails when the data looks complete but is actually fragile. The dataset had 10,000 Indian healthcare facility records, but many important fields were noisy, sparse, repetitive, or weakly supported by free-text claims. We wanted to build something for a planner, NGO coordinator, or analyst who does not just need “an answer”; they need to know what can be trusted, what needs review, and what evidence supports a decision. That led to CareTrust, with two workflows: Data Readiness Desk for improving the dataset, and Referral Copilot for turning the cleaned evidence into referral shortlists so that the patient or coordinator actually know which facilities to go.
What it does
Data Readiness Desk helps users answer: What needs to be fixed before this dataset can be trusted for planning?
It profiles facility records, surfaces suspicious or incomplete data, and prioritizes records for human review. It highlights issue types such as weak source support, missing staff or capacity, sparse evidence, facility type conflicts, and complex clinical claims with thin supporting evidence. Users can add notes, mark review decisions, shortlist facilities, override priority, and propose facility-record corrections. Those proposed corrections update the summary numbers and field coverage indicators so the app reflects human improvement work immediately.
Referral Copilot helps users answer: Where should a patient or coordinator actually go?
A user can ask questions like dialysis near Jaipur, emergency surgery near Patna, or cardiology near Pune. The app queries the configured Databricks Genie space 'As an MCP Server' and returns an evidence-attached shortlist of candidate facilities. It cites fields such as specialties, description, capability, procedure, equipment, and source_urls, and it communicates uncertainty instead of presenting extracted claims as verified facts.
How we built it
We built the app using these Databricks technologies:
- Databricks Apps (Creating a new app from templates)
- Unity Catalog
- Databricks App using AppKit
- Lakebase Autoscaling Postgres
- Genie Space
- MCP Server
- Coding using Genie in the UI for some data engineering
- Lakeflow pipeline
- Databricks Model Serving (databricks-meta-llama-3-3-70b-instruct)
- Databricks AI Search and vector database (Tried but it is not in the final version)
For Data Readiness Desk, we synced the Unity Catalog facility table into Lakebase Postgres for low-latency application queries. The synced facility table remains read-only, while separate Lakebase tables persist review decisions, notes, shortlists, priority overrides, and proposed corrections. The app combines the original facility data with user-proposed changes to recalculate summary metrics and field coverage.
For Referral Copilot, we connected the app to the configured Genie space for the facilities table through Databricks Genie MCP. Before querying Genie, a Databricks Model Serving LLM turns each user request into a care-search plan: primary care need, related care terms, primary location, and nearby locations. The backend then sends Genie a structured referral prompt with that plan, polls the MCP response, extracts only the final user-facing answer, and keeps the internal prompt/instructions out of the UI.
Challenges we ran into
One challenge was limited free-tier resources because we tried Databricks AI Search and a vector database, and ran out of serverless compute quota and Codex credits. Another challenge was separating claims from facts: listing ICU, dialysis, cardiac care, or surgery does not prove availability. The app therefore labels these as claims, shows evidence, and exposes uncertainty. For write-back, the synced Lakebase table was read-only, so we used separate review and correction tables and layered proposed fixes over the source records.
Accomplishments that we're proud of
- We are proud that we learned a lot while working on building these two apps using codex agentic tool (Refer to what we learned section).
- We are proud that our work contributes to a meaningful social impact problem. The app gives healthcare planners a practical way to inspect evidence, prioritize fixes, and preserve human judgment.
- We are also proud that we were able to work across multiple tracks, not just one. In one day, we quickly built multiple connected apps: Data Readiness Desk improves trust in the facility dataset, while Referral Copilot uses that evidence to support referral decisions.
- A smaller but important win was making user corrections visible in the metrics. When someone proposes a field correction, the dashboard numbers and field coverage reflect that work, making data improvement feel measurable and encouraging users to stay engaged.
What we learned
We learned how to work with Lakebase and how to sync data from Unity Catalog into a Lakebase table for app-ready access. We also learned how to use Codex agentic coding, how to set it up with Databricks documentation and the Databricks CLI for building and deploying.
We learned how to build Databricks Apps by starting from a template in the UI and extending it into a real workflow with review queues, correction tables, and user-facing interactions.
We also explored Genie, its capabilities, and how it can be embedded into an app as a MCP endpoint! One important lesson was how much the quality of the Genie prompt matters: the instructions we give Genie directly shape the usefulness, safety, and reliability of the answers.
Finally, we learned a lot about healthcare facility data. The dataset showed us how messy real-world public data can be, especially when facility claims, locations, specialties, equipment, and contact fields are incomplete or inconsistent.
What's next for CareTrust: Data Readiness Desk + Referral Copilot (Track 4 and Track 3)
Next, we would make the app more complete by adding a approval workflow. Reviewers could approve, reject, or edit proposed fixes before those changes are used in planning. We would also improve Referral Copilot if we had more compute resources (other than the free edition), we would use Databricks AI Search and a vector database to find stronger evidence from facility descriptions and source links. We would also continue building the other tracks. Track 1 and Track 2. The long-term goal is to connect everything into one workflow: find bad data, review it, fix it, verify facility claims, and then use the improved data for safer referrals and better planning.
Built With
- databricks
- genie
- lakebase
- llm
- mcp
- vscode
- xcode

Log in or sign up for Devpost to join the conversation.