Blood Donor Matching and Request Coordination

The problem families face finding blood donors

When a patient needs blood urgently, for surgery, childbirth, an accident or regular transfusions for thalassaemia, the family is often asked to arrange donors. What follows is frantic forwarding of the same message in WhatsApp groups and on social media. The message is unverified, spreads long after the need is met, reaches mostly people who cannot donate, and exposes the family's phone number to thousands of strangers. Meanwhile willing donors are not contacted because nobody has an organised list, and some are contacted again weeks after donating when they are not yet eligible.

What already exists and the gap

• The American Red Cross Blood Donor app manages appointments, reminders and donation history for people donating at Red Cross drives.
• Hospital and NGO blood banks keep their own donor lists, usually in a register or spreadsheet, and phone donors one by one.
• Social media blood donation features and WhatsApp groups spread requests widely but do not check eligibility or protect contact details.

Appointment apps assume a national blood service with scheduled drives. The volunteer group model has reach but no matching, no eligibility rules and no privacy. The gap is a coordination tool that turns one verified request into targeted, eligible, nearby donor contacts, and protects donors while doing it.

What you build

Three roles:

• Donor: registers once through a link, updates their last donation, and replies to SMS requests.
• Requester: a hospital coordinator, or a family verified through one, who raises a request and sees accepted donors.
• Administrator: verifies hospitals and coordinators and reviews abuse reports.

Main flow: request raised, eligible donors found, first wave messaged, replies collected, next wave sent if needed, request closed when enough donors accept, and donors who were not needed are told so.

The technically interesting part

Eligibility as sourced, tested rules. Red cell compatibility is a fixed table and easy. The minimum interval between whole blood donations differs by country and service (for example, the US Red Cross uses 56 days), and deferral rules for illness, travel, age and weight vary too. Keep rules as data with a citation for each one from your national transfusion service, and write tests. Getting this wrong is not a bug, it is a safety problem.

Escalation without spamming. Message the smallest set of donors likely to cover the need, wait, then widen. Track how often each donor is contacted and rest them. Handle replies that arrive after the request closed.

Privacy. Donor phone numbers are never shown to requesters before acceptance; the platform mediates contact. Write down the threat model: this is health information about identifiable people.

How to evaluate it

• Rule correctness: at least 40 test cases for compatibility and eligibility, each traced to a cited source.
• Simulation: generate a synthetic city with 2,000 donors and realistic response rates; compare wave strategies on time to fill a request and messages sent per unit covered.
• Pilot: run it with a student blood donation society or a hospital coordinator for a few weeks; report requests, acceptances and time to first accept.
• Privacy review: a checklist based review against OWASP ASVS items for access control and data protection.

Suggested plan

1. Weeks 1 to 2: talk to a blood bank or donation society; collect and cite eligibility rules.
2. Weeks 3 to 5: donor registry, rules engine and tests.
3. Weeks 6 to 8: requests, geospatial matching and SMS waves.
4. Weeks 9 to 10: privacy model, coordinator dashboard, audit log.
5. Weeks 11 to 14: simulation, pilot, write up.

Path to a product

The first customer is a university blood donation society, a thalassaemia centre or a hospital blood bank that already coordinates donors by phone. The realistic model is non-profit: a grant or hospital funded deployment covering SMS costs, or a small monthly fee per hospital for the coordinator dashboard. Never charge donors or families.

Scope warning

Do not build blood bank inventory management, cross matching or anything clinical. Matching a verified request to willing donors is the project. Do not publish donor lists or maps of donors.

Learn what you need on Sefism

• Backend roadmap : APIs, databases and background jobs for waves and replies.
• Backend cheat sheet : quick reference for auth, queues and data modelling.
• PostgreSQL Documentation : the database under PostGIS radius queries.
• OWASP ASVS : a checklist for access control and sensitive data handling.
• EU Data Protection Rules for Business : a clear model of consent and data minimisation to follow.

Get help with this idea

This project matters because it deals with real people's health data, so rules and privacy come first. Tauseef can help you scope the rules engine, design the escalation strategy, and plan a simulation and pilot examiners will respect. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session