VitaTrace

Every drop traced. Every life counted.

Comment

VitaTrace — Our Story

STEMINATE HACKS 2026 | GreenPT Bounty Submission

Team: Swaroop Chandra Ponnada & Reenu Supreeta

Where It Started

I'll be honest — we almost built something else.

We had a different idea early in the week. Something safer, smaller, more "hackathon-sized." But I kept coming back to a conversation I'd had with a relative who has been managing thalassemia for years. Every three weeks, without fail, they need blood. And every three weeks, without fail, there's a scramble. Calling blood banks. Asking in family group chats. Hoping someone in the network knows a donor with the right type who donated recently enough.

I looked into it and realized this wasn't a one-family problem. It's the standard experience for tens of millions of people in India.

India has over 40 million people living with blood disorders. Thalassemia. Sickle cell. Hemophilia. Aplastic anemia. These aren't rare edge cases — for thalassemia alone, India accounts for 1 in every 8 patients in the world. And the entire support system for most of these patients is held together with phone calls, WhatsApp threads, and goodwill from strangers.

The gap that struck me wasn't just the shortage of blood — it was the shortage of information. Donors not knowing if their blood reached anyone. Patients not knowing what's in stock where. Hospitals working off spreadsheets. NGOs coordinating urgent requests by hand. Everyone operating with incomplete information, in a system where incomplete information costs lives.

That's when the idea locked in. What if there was one platform — built specifically for every person in this ecosystem? Patients who need blood. Donors who want to help but never find out if they did. Hospitals drowning in paper requests. Admins trying to guess where the next shortage will hit before it hits.

We called it VitaTrace.

What We Decided to Build

We wanted four portals, each designed for a completely different kind of person:

Patients — register with their disease, request blood when they need it, and actually know when their blood arrived. Not just "request fulfilled" — a real notification. "Blood from a donor reached you today." And if they wanted, they could send that donor a message. One message, anonymous. The donor could choose to open a chat or not.

Donors — record donations, see the impact of what they did ("your blood reached 3 patients"), earn points, climb a leaderboard. Make giving blood feel like it means something instead of just walking in, giving blood, and walking out never knowing what happened.

Hospitals — request blood from nearby banks, see real stock levels on a map, and trace donated blood to specific patients. That last part is what triggers the whole blood journey notification chain.

Admins — a national command center. A live heatmap of blood shortages across India. AI-generated shortage analysis. Everything in one place instead of sixteen spreadsheets.

And powering all of it: GreenPT. We're genuinely grateful for what they've built and made accessible — EU-hosted infrastructure, OpenAI-compatible API, and a sustainability story that actually holds up. Sensitive patient health data stays out of Amazon and Google's servers. 40–50% less CO₂ per inference, 93% less water. For an NGO running on donated infrastructure, that's not a marketing line — it's a real constraint that GreenPT actually solves.

How We Planned It

We spent the first day just designing. Not touching code.

We mapped out every database table we'd need. Eleven of them. Every API endpoint. Every user flow. We wrote out the exact sequence of what happens when a hospital traces blood to a patient — because that flow touches six different tables and three different user notifications and we didn't want to discover the complexity halfway through building.

We planned the GreenPT integration in detail too. Six features:

  • green-l-raw for the chatbot — disease Q&A, diet guidance, donation eligibility in plain language
  • green-r-raw for the admin shortage analysis — feeding live stock data and disease epidemiology to a reasoning model and asking it to think, not just retrieve
  • Embeddings (green-embedding) for the RAG pipeline — so the chatbot pulls from a real medical knowledge base of 64 disease and diet chunks, not just training data
  • Reranker (green-rerank) — takes the top 20 retrieved chunks and narrows them to the 5 most relevant before the LLM ever sees them, so the context is tight and accurate
  • MCP tools — four live database queries the chatbot can call in real time: check if a donor is eligible, look up blood compatibility, find shortage alerts, see how many patients a donor's blood reached
  • Router — manual routing logic that sends everyday chatbot questions to green-l-raw and the complex multi-signal shortage analysis to green-r-raw, so each model is only doing what it's actually built for

Then we started building.

The Build

The first thing that broke was Python.

We're running Python 3.14 locally. Almost nothing in the data/web ecosystem has a 3.14 wheel yet. psycopg2 — the standard PostgreSQL driver — just flat-out refused to install. pydantic-core hit a version ceiling at 3.13. passlib, which handles password hashing, crashed at runtime with a bcrypt binding error.

Three blockers before we'd written a single line of business logic.

We worked through each one. Switched from psycopg2 to psycopg[binary] (version 3 of the library, which did have a wheel). Grabbed a pre-release pydantic build. Ripped out passlib entirely and implemented bcrypt directly. Took about two hours of debugging before the backend even started.

Once it started, we moved fast. Backend foundation first: all eleven database models, JWT auth, role-based middleware on every route. Then the four role routers. Then the AI layer.

The GreenPT integration had its own set of surprises.

model="auto" — which the initial docs suggested as a way to let GreenPT's router pick the right model — turned out to not be a valid model ID at all. The API just returned a 422 error. We had to use green-l-raw explicitly.

green-l (without the -raw suffix) silently ignores your system prompt. We only found this out because the chatbot was ignoring all our multilingual instructions and just responding however it felt like. The raw variant, green-l-raw, is the one that actually respects your system prompt.

The reranker endpoint is green-rerank — not green-reranker. One character difference. Took longer than I'd like to admit.

The Feature Nobody Else Has Built

Halfway through the build, we kept coming back to one question: what happens after the blood is used?

Right now, a donor gives blood. It goes into inventory. A hospital requests it. A patient receives it. And that's the end of the story — for everyone involved. The donor never knows. The patient has no way to say anything. The connection between two human beings in that moment is just... lost.

We built the blood journey feature specifically to close that gap.

Here's how it works. When a hospital traces a unit of donated blood to a specific patient — which triggers a database record linking that donation to that patient — the patient receives a notification. Not "your request was fulfilled." Something more personal: "Blood from a donor reached you today."

The patient can then write one message. Just one. It goes to the donor anonymously — no names, no personal information shared. Just the message.

The donor sees it in their dashboard under pending chat requests. They can accept or decline. If they accept, a private chat opens between the two of them. No personal details exchanged unless they choose to share them. The platform just creates the space.

Technically, this was the most complex flow in the entire system. A single trace-blood call from the hospital touches the donations table, creates a blood_journey record, notifies the patient, and gates the entire messaging system on whether the donor accepts. We had to add an existence check to prevent duplicate journeys from being created if the hospital accidentally submitted the same trace twice. The chat itself polls every 10 seconds — no WebSockets, simple and reliable for a hackathon timeline.

But the reason we built it isn't technical. It's because we genuinely believe that connection — knowing your blood reached someone, or being able to say thank you to a stranger who probably saved your life — is what makes someone donate again. And again. The biggest barrier to regular blood donation isn't logistics. It's that it feels anonymous and thankless. VitaTrace makes it feel like it meant something. Because it did.

The original plan was to seed ten blood banks manually — Apollo Hyderabad, AIIMS Delhi, KEM Mumbai, and so on. Enough to demonstrate the heatmap.

But it felt hollow. A heatmap with ten dots isn't a national shortage dashboard. It's a toy.

We found eRaktKosh — India's national blood bank portal — which publishes a CSV of blood bank data. 47,216 rows. 4,114 unique hospitals after deduplication. Thirty-six states.

We wrote a seed script that processes the full CSV, deduplicates by hospital code, maps every hospital to a latitude/longitude based on state and district centroids, and loads everything into the database on startup. Now the heatmap has 4,114 real dots across real locations. The shortage data is synthetic (we can't connect to live stock systems), but the geography is real.

That changed how the admin dashboard felt. Suddenly it looked like something an NGO would actually use.

The Prediction System — Going Deeper Than We Planned

We built a RandomForest model early on. Region × blood type × month → shortage risk score. It worked. But the more we thought about it, the more it bothered us.

The model was purely reactive. It could only tell you what shortage looked like based on what was in the database right now. It had no idea that thalassemia patients need blood every 21 days. That Madhya Pradesh has 38,000 sickle cell patients. That blood donation drops 30–40% during summer heat.

So we rebuilt the prediction layer from actual research.

We went through peer-reviewed literature and government data — ASH publications, Lancet Haematology, PMC/NIH meta-analyses, India's National Sickle Cell Anaemia Elimination Mission reports. Not to cite-drop, but because the numbers actually matter when you're building a shortage alert system. Guessing at patient populations produces noise. Research-backed numbers produce signal.

Here's what we found:

India has approximately 1,50,000 active thalassemia major patients — the highest concentration in the world, with carrier rates reaching 15–18% in specific communities in Gujarat and Punjab. Each of these patients needs 2 units of packed red blood cells every 21 days under adequate care standards. That's roughly 40 lakh units of blood per year from thalassemia alone.

Sickle cell is heavily concentrated in tribal belt states — Madhya Pradesh (38,000 patients), Chhattisgarh (28,000), Maharashtra's Vidarbha region (22,000). Chronic sickle cell patients average a transfusion every 45 days plus crisis episodes on top of that.

For hemophilia, we made a deliberate decision: India has an estimated 1,30,000 total cases, but 80% are undiagnosed. An undiagnosed patient doesn't walk into a blood bank. Modelling from total prevalence would have inflated our predictions by 5x. We modelled only the 26,000 who are actively managed — the people who actually create blood bank demand today.

Aplastic anemia incidence in India is 3–4x higher than in Europe, linked to pesticide and benzene exposure in agricultural communities. We found this in Oxford Academic's Journal of Public Health and an ASH Blood 2024 registry study. 50,000 active patients, each needing both packed red cells every 10 days and platelets every 7 days — two separate blood components, both critical.

We also built in a seasonal supply index. Chronic disease patients need blood every N days regardless of season — their bodies don't care about summer heat or Diwali. But blood donation drops 30–40% in March through May and 20–30% in October and November. So the same monthly demand becomes dramatically harder to meet at certain times of year. We applied the seasonal factor to shortage risk, not to demand — because medically, demand doesn't change. Supply does.

All of this gets fed to GreenR as structured context alongside live eRaktKosh stock data. So instead of GreenR looking at a number and saying "stock is low, alert triggered," it can actually reason: "Maharashtra has 28,000 thalassemia patients needing approximately 5,700 units of packed red blood cells per month. eRaktKosh shows 2,100 units currently available across Maharashtra banks. It is March, which is peak supply-drop season. This is a structural shortage, and it will get worse before it gets better."

That's a completely different quality of analysis. And it came from spending a few hours reading the actual research instead of training a model on synthetic data and hoping it generalised.

What We're Actually Proud Of

The blood journey feature. Not because it was technically the most complex thing we built (it was), but because it closes a loop that nobody closes.

Right now, a donor walks into a blood bank, gives blood, and leaves. They never find out what happened. The blood goes into inventory. Maybe it reaches a patient. Maybe it doesn't. There's no feedback, no acknowledgment, no connection.

VitaTrace shows the donor: "Your blood reached a patient." And if that patient wants to say something — even just thank you — they can. One message. The donor decides whether to respond. No personal information shared. Just a moment of connection between two people who would otherwise never know each other existed.

We think that's the kind of thing that makes someone donate again.

What Didn't Make It

Multilingual chatbot — we built English, Hindi, and Telugu support, but Telugu had the Japanese character bug that took real time to fix. Eventually we simplified to English-only for the submission to keep the experience clean and reliable. The infrastructure is still there; we just removed the language toggle from the UI.

RandomForest in the admin UI — we removed the "Run ML Predictions" button in the final session. The GreenR reasoning engine does a better job, and having both was confusing. The RandomForest model still exists in the codebase; it's just not surfaced to the user anymore.

Voice input (GreenS) — we wanted to add GreenPT's speech-to-text for patients with limited literacy, especially in rural areas where voice input would matter more than text. Didn't make it into the hackathon scope. It's the first thing we'd add post-submission.

WebSocket chat — the donor-patient chat polls every 10 seconds. It works fine for a demo. Real usage would need WebSockets. We know.

Where This Goes Next

VitaTrace isn't a hackathon prototype that lives in a zip file. The problems it's trying to solve are real and ongoing.

The next version needs GreenPT's voice input so patients in rural India who can't type can still ask the chatbot about their disease. It needs real blood bank API integration instead of seeded CSV data. It needs NGO white-labeling so Blood Warriors, Thalassemia Society of India, and others can deploy their own branded instances without touching code.

And it needs to be on mobile. Most patients dealing with blood disorders in India are on Android phones. A desktop-first platform is the wrong choice for the people who need it most. We built what we could in the time we had. The architecture is designed to extend.

One Last Thing

We want to thank GreenPT for building something that actually aligns with what a project like this needs. The people who need VitaTrace the most are the same people whose data should absolutely not be sitting on a commercial cloud server getting fed into training pipelines.

A thalassemia patient's disease history. A hemophilia patient's transfusion records. This is deeply personal medical information. GreenPT processes it in EU-hosted infrastructure, with a sustainability story that's real — not a badge we pinned on at the end. That mattered to us from day one.

That's VitaTrace. Built in this week for the Hackathon.

Swaroop Chandra Ponnada & Reenu Supreeta — STEMINATE HACKS 2026

Built With

Share this project:

Updates