Inspiration
Healthcare in the US is notoriously fragmented. A physician prescribing a specialty drug, say, a biologic for Crohn's disease, has to manually dig through dozens of pages of insurance policy PDFs from BCBS, Cigna, UnitedHealthcare, and others, just to answer: "Will this drug be covered for my patient?" That process can take hours. Errors lead to claim denials, delayed treatment, and frustrated patients. We wanted to build a tool that collapses that research from hours to seconds.
AntonRx was born from a simple question: What if a clinician could just ask, in plain English, "Is Drug X covered under UHC for a patient with diagnosis Y?" and get a sourced, accurate answer instantly?
What it does
AntonRx is a full-stack AI-powered medical benefit drug policy tracker. It lets healthcare professionals query and compare drug coverage policies across major US payers (BCBS, Cigna, UnitedHealthcare, Priority Health, UPMC) using natural language.
What we built?
The system is built around a two-tier architecture:
Tier 1: Structured Lookups (free, instant): A SQLite database stores pre-extracted policy metadata across 8 dimensions per drug:
$$\text{Policy} = {D, C, A, I, PA, ST, SOC, DL}$$
where D= Drug Name, C = Category, A = Access Status, I = Covered Indications, PA = Prior Authorization requirements, ST = Step Therapy, SOC= Site-of-Care, DL = Dosing Limits.
Tier 2 - RAG + Claude (~\$0.01/query): For complex, nuanced questions, we run a full Retrieval-Augmented Generation pipeline.
The backend scrapes policy PDFs from payer websites, chunks them into ~6,100 semantic fragments, embeds them into ChromaDB, and retrieves the top-k most relevant passages at query time. Claude (via Anthropic API) synthesizes a grounded, cited response - and is explicitly instructed never to fabricate coverage information.
How we built it
Frontend: Next.js 16, React 19, TypeScript, Tailwind CSS 4, Framer Motion State / Data: Zustand, React Query, Recharts Backend: FastAPI (Python), SQLAlchemy, Pydantic AI: Anthropic Claude API Scraping / Parsing: BeautifulSoup, httpx, PyMuPDF Database: SQLite + ChromaDB (vector store)
The pipeline works end-to-end: scraper → PDF parser → chunker → vector indexer → RAG → Claude → Next.js UI. Answers are cached for 10 minutes to reduce redundant API calls.
Challenges we ran into
1. PDF chaos. Insurance policy documents are not standardized. Some are scanned images, some have multi-column layouts, and some bury the key clinical criteria in footnotes. Getting PyMuPDF to consistently extract clean, semantically coherent text across payers required significant preprocessing.
2. Grounding Claude. The biggest risk in a medical tool is hallucination. We spent considerable time crafting the system prompt to keep Claude strictly within the retrieved context: no fabrication, always cite, always include a coverage verdict based only on what the document says.
3. Cost vs. quality tradeoff. Full Claude Sonnet on every query was too expensive for a hackathon demo budget. We landed on a hybrid: structured DB for simple lookups, Claude 3 Haiku only for complex RAG queries, with caching — bringing cost to roughly $0.01 per complex question.
4. Scope in 36 hours. We had to ruthlessly prioritize. Multi-payer comparison, version diffing, and a full scraping pipeline all made the cut. A few features (live payer API integrations, user accounts) did not.
Accomplishments that we're proud of
- We were able to parse both types of PDFs (single drug policies and consolidated mega policies).
- We were able to scrape the live data from the website and build our own database.
- We are proud of our UI, which can show all of the stated data on a single page.
- We are proud of the optimizations that we did to ensure the lower cost of our retrievals while increasing their speed.
What we learned
- RAG quality is almost entirely a function of chunking strategy; splitting at the wrong boundary destroys retrieval relevance.
- System prompt engineering matters enormously for reliability in high-stakes domains. A generic prompt produces generic (and potentially dangerous) medical answers.
- FastAPI + Next.js is a genuinely fast stack for hackathons. The type safety across the boundary, enabled by Pydantic and TypeScript, saved us from several integration bugs.
- Building for a real, painful workflow (not a toy demo) kept the team motivated and focused throughout the weekend.
What's next for RxRefactor
- Expand payer coverage and automate policy update detection (diff alerts when a payer changes a step therapy requirement)
- Add a formulary comparison view across all payers for a single drug
- Integrate with EHR systems so clinicians can query directly from the patient chart context
Built With
- beautiful-soup
- chromadb
- claude
- fastapi
- next.js
- pymupdf
- react
- sqlalchemy
- sqlite
- tailwind
Log in or sign up for Devpost to join the conversation.