Inspiration
We started from a real backend we'd studied — a medical-records RAG system where patients upload documents and ask questions about their own history. It got us asking: what about the other side of the exam room? Doctors are drowning in over a million new papers added to PubMed every year, with no way to know which ones actually matter for the patient sitting in front of them right now. Generic literature search doesn't solve that: it just returns more to read. We wanted research that explains itself against one specific patient's actual record.
What it does
Optimize Labs Assistant is a two-sided AI companion for a doctor–patient relationship:
- Doctors log in, pick a patient from a roster, see a clinical summary, ask a Clinical Assistant grounded in that patient's conditions and medications, and pull live PubMed research, not as a list of links, but with an LLM explaining why each result matters for that exact patient.
- Patients log in, upload a prescription or document and get it read automatically via vision-LLM OCR (no manual transcription), and can ask a health assistant plain-language questions.
Proof it's real, not a mockup: searching for our demo patient (67M, Chronic Kidney Disease Stage 3 + Type 2 Diabetes, on Metformin + Empagliflozin) returned a live PubMed trial studying the exact finerenone + empagliflozin combination for CKD + T2D patients. It scored 100% relevant, with reasoning tied directly to that patient's drug combination.
How we built it
FastAPI backend plus a React/TypeScript/Vite frontend, split across a 2-person team working in parallel against a locked API contract so neither of us blocked the other. The backend does live NCBI E-utilities search, then an LLM (via OpenRouter) scores relevance and writes patient-specific reasoning; OCR runs through a vision-capable LLM instead of a Tesseract/Poppler stack; every LLM-backed endpoint degrades gracefully instead of 500ing if an external API hiccups mid-demo.
Challenges we ran into
- Python 3.14 has no prebuilt wheel for
pydantic-coreyet, so pip tried to compile it from source with Rust and failed. Fixed by developing in WSL (Python 3.12) instead. uvicorn --reloadsilently stopped picking up file edits made from the Windows side of WSL's mounted filesystem. We only caught it because a new endpoint kept 404ing after we'd already written the code. Switched to manual restarts.- Mid-build, the frontend scope grew beyond the original plan (document scanning and a second, doctor-facing chat assistant), which meant designing and shipping a new backend endpoint (
/api/doctor-chat) under real time pressure without breaking what already worked. - Two people, one day: prioritizing which literature sources and features to cut (ClinicalTrials.gov, Semantic Scholar) so the one core flow was rock-solid rather than three flows half-working.
Accomplishments that we're proud of
Everything is live-tested end-to-end in a real browser against the real backend, not just claimed. Real PubMed data, real vision-LLM OCR, real relevance reasoning grounded in an exact patient's conditions and medications. Built, integrated, and demo-ready by a two-person team in about a day.
What we learned
Locking an API contract before splitting up frontend/backend work is what let two people actually parallelize instead of blocking on each other. Modern vision-capable LLMs eliminate a whole category of OCR infrastructure pain (no Tesseract, no Poppler, no binary installs) that used to be a hard requirement. And WSL's filesystem-watching gap between Windows and Linux is a real, silent failure mode worth knowing about before it costs you a demo.
What's next for Optimize Labs Assistant
ClinicalTrials.gov and Semantic Scholar as additional research sources; proactive alerts that resurface new relevant papers automatically instead of only on-demand search; a real document-ingestion pipeline (chunking + embeddings) so patient chat can reason over a full history, not just one upload; real auth and persistence.
Log in or sign up for Devpost to join the conversation.