LastMile

Requirements Page
Blood Bank Availability

Inspiration

During a medical emergency — surgery, an accident, postpartum hemorrhage — the hardest part isn't knowing blood exists somewhere in the city. It's knowing which hospital has the exact group you need, right now, with stock that's actually fresh and reachable in time. Families end up cold-calling ten hospitals blind during the worst moment of their lives, while public blood bank listings are outdated and map apps only calculate distance — not availability. We wanted to collapse that panic into one query and one trustworthy answer.

What it does

LastMile takes a plain-text emergency request (e.g. "Need O+ blood urgently near Anna Nagar, Chennai") and:

Extracts blood group, units needed, location, and urgency using an LLM (Groq), with a local regex parser as an instant offline fallback Ranks nearby facilities with a transparent 4-factor Confidence Score — stock availability, proximity (Haversine distance), verification recency, and 24/7 facility fit — instead of just sorting by distance Shows why each result ranked where it did, with a point-by-point contribution breakdown, so the score isn't a black box Applies PRBC blood compatibility logic so compatible substitute units (e.g. O- for an A+ request) count toward availability Lets users place a 10-minute reservation hold on units, backed by atomic database locking to prevent two requests claiming the same stock Falls back to client-side calculations automatically if the backend is unreachable, so the app degrades gracefully instead of breaking How we built it Backend: FastAPI (Python) with Pydantic models, a Haversine-based ranking engine, and SQLite for atomic reservation holds AI extraction: Groq LLM API for natural language parsing, with a hand-written regex NLP fallback for zero-downtime offline operation Frontend: React + Vite, Leaflet.js for the interactive map, with color-coded confidence tiers on facility pins Data layer: A provider abstraction that can switch between a simulated dataset and mock FHIR/HL7 v2 payload formats, to demonstrate how this would plug into real hospital systems Testing: A pytest suite covering the compatibility matrix, scoring formulas, and concurrency locking Deployment: Dockerized backend, deployed via Render, with the frontend on Vercel Challenges we ran into There's no public, unified real-time blood bank inventory API in India (or most places), so we had to build a realistic simulated dataset and be explicit in the UI about what's simulated versus what's architecturally ready for real integration Preventing race conditions on the reservation system — two people hitting "reserve" on the last unit at the same moment — required atomic locking at the database level, not just optimistic UI updates Getting the offline fallback to feel seamless rather than "broken" took real design work: matching the online and offline code paths closely enough that a judge (or a real user) wouldn't notice the difference Tuning the scoring weights so the algorithm felt medically sensible rather than arbitrary — availability needed to dominate, but not so much that a life-saving nearby option got buried Accomplishments that we're proud of A ranking algorithm that's actually explainable — every score comes with a plain-language breakdown of why, not just a number A fully tested core engine (compatibility rules, scoring, concurrency) with a passing automated test suite Real fail-safe architecture: the app keeps working end-to-end even with zero backend connectivity Built provider adapters for FHIR and HL7 v2 to show this isn't just a demo dead-end — it's designed with a real integration path in mind What we learned How to design a multi-factor weighted scoring system that stays interpretable instead of becoming a black box Practical patterns for offline-first, fail-safe frontend architecture The realities of healthcare data interoperability standards (FHIR, HL7) and why "just call the hospital API" is a much harder problem than it sounds How much of building for emergencies is really about designing for the failure case — slow networks, stale data, race conditions — not just the happy path What's next for LastMile Partnering with real blood banks or state health departments to replace simulated inventory with live data feeds SMS/WhatsApp-based donor notification instead of the current simulated broadcast, for areas with low smartphone/data access Expanding beyond Chennai to a multi-city rollout, and building a verification layer so hospital staff can update inventory directly Adding authenticated donor accounts so notified donors can confirm availability in one tap