Web App

Donor-Recipient Matching System

A web-based automated operation system for blood donor-recipient matching and request management

Details

Role

Project Lead & Solo Full-Stack Developer

Project Type

Capstone Project

Duration

5 months

Status

Completed

Recognition

Capstone - Best UI/UX AwardCapstone - Best System Design and Implementation

Links

Visit Demo

Redesigned demo

Built With

JavaScript

Tailwind

HTML

CSS

Express.js

Firebase

Google Gemini

What it is

A donor and blood request operations system built for Philippine Red Cross – Antique Chapter. Staff encode donor records and blood requests, review ranked matches, and contact donors by SMS while keeping each request in one place.

It supports how PRC - Antique Chapter finds and contacts donors. It does not replace medical screening, transfusion, or the national blood bank system.

The problem

Context

In Antique, locating a compatible donor often meant working through paper records, calls, and lists that were not in one place—especially when a request was urgent.

Impact

Eligible donors were easy to miss, staff spent more time coordinating by hand, and requesters waited on updates that were hard to track.

What I did

I designed and built the system end to end, from the donor registry and matching model to the administrative workflows the system was designed around.

Designing donor records around Donor ID, blood type, municipality, eligibility, donation history, and response reliability.
Building the TOPSIS ranking logic in JavaScript to evaluate compatibility, including Rh, proximity, eligibility, donation frequency, and response history.
Connecting Mobile Blood Donation encoding to the donor registry, then to request matching.
Building the admin workspace for donors, requests, matching, MBD records, notifications, and reports.

Wiring Semaphore SMS for matching, batch outreach, OTP lookup, and alerts to donors, admins, and requesters.
Adding a contact form so support messages can be answered by email, separately from request SMS.
Integrating a chatbot with PRC - Antique Chapter-specific guidance on donating, requesting blood, and chapter information.

How I designed it

Keep the request at the center

Every donor match, notification, and status update connects back to one blood request, giving each role the same source of truth.

PRC staff encode donors during Mobile Blood Donation. Each record gets a Donor ID in the registry instead of living only on paper.

Rank donors instead of simply filtering them

Blood type, including Rh, sits alongside proximity, eligibility, donation frequency, and how reliably someone has responded before.

Keep the administrator in control

The system ranks candidates. Staff choose who to notify, and urgent requests can go out in SMS batches if the first group does not confirm.

Main features

Donor Matching

Ranks eligible donors on blood type including Rh, proximity, eligibility, donation frequency, and response history.

Request Management

Gives administrators one place to create, review, and track blood requests.

Donor Management

Centralizes Donor ID records, eligibility, donation history, and who registered them at an MBD.

MBD records

Tracks Mobile Blood Donation activity, who donated, collected units, and related statistics.

SMS notifications

Sends matching alerts, SMS OTP for donor lookup, and updates to donors, admins, and requesters.

AI Assistant

Answers localized questions on donating or requesting blood at PRC - Antique Chapter, plus FAQs and chapter contact details.

Built with

JavaScript and Tailwind

Built the admin and public interfaces, request workflows, and the TOPSIS matching logic that ranks eligible donors.

Firebase

Stored donor records, blood requests, matching results, and Mobile Blood Donation data in one shared data layer.

Semaphore

Handled matching SMS, batch donor outreach, OTP lookup, and alerts when donors respond or request statuses change.

Google Gemini

Powered the public chatbot with PRC - Antique Chapter-specific guidance, donation and blood request information, FAQs, and chapter contact details..

Resend

Handled email replies to contact and support messages, keeping support communication separate from request SMS.

jsPDF, AutoTable, and SheetJS handle PDF and spreadsheet exports.

Hard parts and how I solved them

Making matching more than blood type

TOPSIS ranks donors across Rh-aware compatibility, proximity, eligibility, donation frequency, and response history, so staff get a list they can review.

Keeping coordination tied to the request

SMS to donors, admins, and requesters stays attached to request state. Email is reserved for support replies, not matching.

Keeping the system consistent as a solo build

Auth, matching, notifications, and the chatbot all work from the same underlying request and donor records.

Deciding what TOPSIS should weigh

Compatibility including Rh, proximity, eligibility, donation frequency, and response history all matter, but not equally. The ranking had to reflect that, while staff still choose who to contact.

How it works

1
A request is created
After a blood order reaches PRC - Antique Chapter, staff encode blood type, urgency, quantity, and requester details.
2
Suitable donors are ranked
The system evaluates eligible donors using the matching criteria and produces a ranked list.
3
A donor is contacted
Staff pick from the ranked list. Urgent requests can notify one SMS batch first, then another if confirmations fall short.
4
The request moves forward
YES/NO replies notify admins by SMS. Requesters get SMS when a match is found or the status changes.

What came from it

The project produced a working operations system for PRC - Antique Chapter that brings the donor registry, TOPSIS matching, SMS coordination, and MBD records into one workflow.

It was developed as a capstone and remains a working prototype. It supports chapter operations; it does not replace medical assessment or the national blood bank system.

What I learned

Recommendations need to be explainable. Operations teams need to understand why someone was ranked highly, not just receive a score.
Notifications need context. SMS is useful when it is part of a clear request lifecycle, not just an isolated alert.
One source of truth matters. Keeping the request at the center of the system helped keep donor, administrator, and notification states aligned.

About the Demo

The demo features a refreshed user interface created for portfolio presentation. It retains the project's original purpose while exploring a more modern visual direction. The original interface is shown in the screenshots below.

The demo focuses on the general user-facing pages and does not include the administrative interface.

Screenshots

Original interface

Admin Side Pages

Admin Dashboard

Overview of the admin dashboard with key metrics and controls.

Donor Side Pages

Home

Introduction to the system with a brief overview for general users.

Next project

Pathify

A prediagnosis and specialist shortlist to guide patients toward appropriate care.