MIRA | Devpost

Inspiration

About the Project MIRA was inspired by a simple but uncomfortable reality: access to healthcare in the U.S. is not just about availability, it’s about understanding. While insured and English-speaking patients can easily compare clinics, check drug prices, and navigate billing systems, millions of undocumented, uninsured, and low-income individuals are forced to make medical decisions without clear information or guidance. This project started with a question: what if healthcare navigation worked like translation, turning a complex, fragmented system into something understandable, actionable, and human?

What Inspired Us We were especially motivated by the information gap around: Charity care programs that most patients never hear about Sliding-scale clinics that are hard to discover Prescription drugs that vary wildly in price despite identical generics Medical bills that are nearly impossible to interpret without expertise We wanted to build something that doesn’t just show information, but explains it in context, in the user’s language, and with immediate next steps.

How We Built It MIRA is a full-stack Next.js application powered by: Claude (Anthropic API) for document understanding, summarization, and multilingual responses Public healthcare datasets (HRSA FQHCs, CMS hospital data, RxNorm, OpenFDA, NADAC) Leaflet + OpenStreetMap for cost-free mapping Lightweight local storage (sessionStorage) for privacy-first state handling Custom RAG pipeline (ChromaDB) for document-based chat

The system is organized into four core modules: Find Care → geocodes ZIP codes, ranks nearby clinics/hospitals using distance + eligibility signals Understand Docs → uses multimodal Claude to extract structured medical data from PDFs/images Lower Costs → maps brand-name drugs to generics using RxNorm and price benchmarks from NADAC Get Help Applying → generates charity care applications and eligibility checks using hospital policy data Everything runs without accounts, cookies, or persistent storage.

Key Technical Ideas: Offline-first geocoding. Static centroid table for all 160 Cook County ZCTAs (Census 2020) with Nominatim fallback demo never blocks on network. Score-based facility ranking. Haversine distance + tag-aware boosts: ER facilities surge for emergency cases, OB/peds providers surge for pregnant/parent users single sortable score over a heterogeneous (FQHC + hospital) pool. Layered emergency detection. Multilingual keyword model (en/es/ar) over symptoms text plus explicit user-flag override, separating user intent from inferred risk to avoid false dismissal or false alarms. Multimodal Claude as a structured-data extractor. PDFs/images → typed JSON (bills, labs, prescriptions) via tool-use prompts, not free-form chat turns a vision model into a deterministic extractor. Brand → generic price collapse. RxNorm RxCUI normalization joined to NADAC pricing, so "Lipitor" and "atorvastatin" land on the same row with the cheaper alternative shown. RAG-backed doc chat. Per-session ChromaDB embedding of just the user's uploaded docs, scoped to one session chat answers cite the user's own paperwork, not the open web. Privacy as an architecture constraint, not a setting. No DB, no accounts, no cookies — session-only sessionStorage state, ChromaDB collections wiped on session end. The "no persistence" promise is enforced by having nowhere to persist to. Bundled public-data normalization. HRSA/CMS/NADAC/NeedyMeds/charity sources collapsed into a single uniform Facility schema at build time, so runtime code never branches on dataset origin.

Challenges We Faced

Data fragmentation Healthcare data is spread across multiple inconsistent public datasets. We had to normalize HRSA, CMS, and drug pricing data into a unified structure.
Multilingual medical understanding Ensuring that Claude outputs remain accurate and culturally understandable across languages (especially Arabic and Spanish) was non-trivial.
Trust & privacy constraints We deliberately avoided accounts, analytics, and persistent storage, which required rethinking state management entirely around session-only flows.
Safety in medical interpretation Designing emergency detection that is sensitive enough to catch real risk signals without over-triggering false alarms required careful keyword modeling and layered logic.

What We Learned: public data becomes powerful only when it is structured and contextualized LLMs are most impactful when used as translation layers for complex systems, not just chatbots UX for vulnerable populations must prioritize clarity, speed, and trust over features Healthcare systems are not just technical problems—they are information accessibility problems Closing Thought: MIRA is not just a tool, it’s a bridge between complex systems and the people who are most affected by them but least supported by them. Our goal is simple: If care exists, people should be able to find it, understand it, and access it.