RaktSetu: blood for an emergency patient in minutes, without the phone tree

This is a submission for the Hacktoberfest 2026 Week 2 challenge.

What I Built

When a patient in an Indian hospital needs blood urgently, someone at the blood bank desk picks up a phone. They call the bank down the road, then another, then start working through a list of donors who may or may not answer, may or may not be eligible, and may or may not be anywhere close. India has more than 28 lakh donors registered on the government's e-RaktKosh platform, and almost none of them are reachable this way at 2 AM.

RaktSetu replaces that phone tree. A nurse shares the patient's location and answers four questions: what is needed (whole blood, red cells, platelets or plasma), the blood group, how many units, and how urgent. Or they type it the way they would say it: "O+ blood required, 2 units, Andheri, urgent accident case." From there RaktSetu:

1. Reserves what nearby blood banks already have on the shelf, nearest first.
2. Recruits donors only for the shortfall, in batches, nearest and eligible first, widening the search when nobody answers.
3. Tells each donor exactly where to go: hospital, a map link, and the number to call, plus a private page where they can say yes, no, or reply in their own words.
4. Stands everyone else down the moment the request is covered.

Who pays: hospitals and blood banks, as a monthly subscription. What they are buying is staff time during the worst ten minutes of someone's day. Donors and patients never pay anything; blood donation in India is voluntary by law, and the product is built around that.

The spark: a hackathon pitch called RaktKhoj (team Blood Boys, Build What Moves India) laid out this exact problem, including the fact that 12% of Indian districts are more than 100 km from the nearest blood bank. RaktSetu is my own independent build on that problem statement, with its own name, code and architecture.

Demo

Live: https://answered-buyer-latin-underground.trycloudflare.com

The demo runs from my laptop through a temporary tunnel. If it happens to be offline when you visit, the screenshots here and the repo show the full flow.

To try it: fill in any hospital name and number, tap Use demo location (Andheri, Mumbai), answer the four cards, and press Dispatch. Then scroll to the Donor simulator and either answer for a donor or tap Open donor page to see exactly what they would get on their phone. Try typing a reply like "haan aa raha hoon, 20 min mein" or "can I come after 6pm?" and watch where it lands on the hospital side. Each batch gets 60 seconds before the search moves on.

Code

CodersAcademy006 / raktsetu

Emergency blood-donor dispatch console — Gemma + Temporal + MongoDB Atlas (Hacktoberfest 2026)

RaktSetu

Emergency blood dispatch for hospital and blood-bank staff. Built for the Hacktoberfest 2026 "Side Hustle" DEV Challenge.

Staff share the patient's location and answer four questions (component blood group, units, urgency), or describe the need in a sentence. RaktSetu then:

1. Reserves units from nearby blood banks first (within 10 km, exact group before other compatible groups, each unit taken by an atomic conditional decrement so two requests never claim the same one).
2. Recruits donors only for the shortfall, through a durable Temporal workflow: batches of eligible, compatible donors nearest first, every donor at a radius before widening (5, 10, 25, 50 km), early wake-up when a whole batch has answered, and a hard stop when nobody is left.
3. Tells donors exactly where to go: hospital, map link, callback number, and a private link to a donor page where they accept, decline or reply in their own words.
4. …

View on GitHub

How I Built It

The design rule I held myself to: the open model does the language work, and every medical or safety decision stays in plain, testable code. Each piece of open technology has a job the product would fall apart without.

Gemma: three jobs, each with a guard

Gemma 3 (4B, served locally through Ollama) handles everything that involves messy human language, and each of its outputs passes a deterministic check before anything acts on it.

1. Reading requests typed in a hurry. Gemma turns "critical: B+ x3 units, near Powai" into structured fields. Then the code checks that the blood group, the unit count and the locality it returned all literally appear in what the nurse typed. Early on, a request for blood "in Delhi" could get quietly matched to the closest Mumbai locality in the list. Now it is refused with a message telling staff what to fix. A model that helpfully fills in a gap is the most dangerous kind of mistake in this domain, so the system sends the request back instead.

2. Writing to donors. Gemma writes the warm, human opening of each outreach message. The facts that follow (what is needed, which hospital, the map link, the number to call) are assembled from the database record. Any draft containing a digit or a link is thrown away, so the model can never invent an address or a phone number that sends a donor to the wrong place.

3. Understanding replies. Donors answer however they answer. "haan aa raha hoon, 20 min mein pahunch jaunga" becomes an accept with a 20 minute ETA. "Sorry, I had fever last week" becomes a decline with a note for staff. During testing, Gemma read "Can I come after 6pm instead?" as a yes. So now any negation or condition in a reply (a question mark, "after", "instead", "maybe", "kal") vetoes an accept and puts the reply under Needs a call, with the donor's number one tap away. Marking a donor as coming when they are not is the expensive error; one extra phone call is cheap.

If Gemma is slow or unreachable, the wording falls back to fixed text. Dispatch never waits on the model.

Temporal: waiting on humans, durably

The hard part of this product is time. You message ten people, then wait. Some answer in a minute, some never do, and the server should be able to crash in the middle without anyone getting messaged twice or forgotten.

EmergencyRequestWorkflow is a Temporal workflow that:

• reserves bank units first and finishes immediately if the banks cover everything,
• sends a batch of the nearest eligible donors and waits on a durable timer,
• treats each donor's reply as a signal, so the moment the target is met it stops,
• wakes early when every donor in a batch has answered (for example, all declined) instead of sitting out the timer,
• works through every eligible donor at a radius before widening (5, 10, 25, then 50 km),
• and when it ends, tells every donor still pending that they are no longer needed.

Activities are retry-safe: each message is written as an upsert keyed on request and donor, so a retried activity never messages the same person twice. This mattered in practice. The network I built this on drops connections to the database every so often, and I watched activities fail mid-request, retry with backoff, and carry on exactly where they left off, with the hospital view never noticing. The workflow logic is covered by tests that run the real workflow on Temporal's time-skipping test server, including the full escalation ladder and the all-decline early wake-up.

MongoDB Atlas: geography and medicine in one query

Donors and blood banks live in Atlas with 2dsphere indexes. Finding the next batch is a single $geoNear query that also applies the medical rules, so the batch limit counts only donors who can actually give:

• Eligibility, from India's NBTC guidelines: age 18 to 65, at least 45 kg, and 90 days since the last donation for men or 120 days for women.
• Compatibility by component. Red cells follow the familiar donor table. Plasma runs the other way: AB is the universal plasma donor and Rh does not matter. Platelets follow the plasma rule and give Rh-negative patients Rh-negative donors only.

Bank stock is reserved with an atomic conditional decrement, so two hospitals asking at the same moment can never be promised the same bag.

Built to be trusted

Staff endpoints sit behind a per-hospital access code (switched off for this public demo, since all data is synthetic). Each donor's link carries a random ID in the URL fragment, so it never shows up in server logs. Staff only see a donor's phone number after that donor says yes or asks for a call. The page runs under a strict Content Security Policy with no inline scripts or styles. 33 tests cover the medical rules, the model guards and the workflow.

What is simulated

I do not have access to e-RaktKosh, so donors and banks are synthetic: 460 donors and 13 banks across Mumbai, plus a cluster near Pune and Nashik with no banks at all, which is what the 12% of districts far from a bank look like. Messages are shown in the donor simulator and on the donor page instead of going out over WhatsApp. Sending is behind a single NotificationProvider interface, so plugging in the WhatsApp Cloud API changes one file and nothing in matching or the workflow.

Why Does Open Innovation Matter?

The pitch that inspired this never made it past a demo. That is the usual fate of good public-interest ideas: building them for real needs a team, a budget, and an API bill that grows with every message.

Open tools change that math. Gemma runs on the hospital's own machine, so a patient's blood group and location never leave the building, and reading a donor's reply costs nothing per message. That matters for a product whose busiest night, a highway pile-up or a dengue surge, is exactly when a per-request bill would spike. Temporal's open-source server gave me production-grade durable workflows on a laptop, the same engine large companies run, with no license standing between a solo builder and reliability. And because each of these is open, a state health department or an NGO can inspect exactly how a donor gets chosen, run it themselves, and change it. For a system that decides who gets asked to give blood, that transparency is part of the product.

Prize Categories

• Best Use of Gemma: request parsing, outreach writing and donor reply understanding, each with a deterministic safety guard.
• Best Use of Temporal: the whole dispatch lifecycle is one durable workflow that retries failed steps, resumes after crashes, and never double-messages a donor.
• Best Use of MongoDB Atlas: the data layer, with geospatial matching, eligibility in the query, and atomic bank-stock reservation.