What Inspired Us
Blood shortages are a recurring crisis that rarely make front-page news but quietly cost lives every day. We kept coming across reports and awareness campaigns highlighting how hospitals struggle to find compatible donors fast enough during emergencies — often relying on outdated methods like phone trees, WhatsApp forwards, and social media appeals. It struck us that in a time when real-time logistics power everything from food delivery to ride-sharing, blood donation coordination was still stuck in the past. We wanted to build something that treated every second of a blood request with the urgency it deserves — which became the foundation for PulseLink.
What We Learned
Building PulseLink as a team taught us a lot beyond just code:
- System design at scale — modeling relationships between Donors, Hospitals, Blood Banks, and Requests required careful schema planning so the system could scale without becoming a tangle of redundant data.
- The real-world complexity of "matching" — what looks like a simple lookup problem (find a donor with blood group X) is actually a multi-variable optimization problem once you add location, availability, and response history.
- Spring Boot's ecosystem — particularly how Spring Security and Spring Data JPA work together to keep role-based access (Donor / Hospital / Blood Bank / Admin) clean and secure.
- Team collaboration under deadline pressure — dividing frontend, backend, and database responsibilities while still keeping the system cohesive.
How We Built It
We approached PulseLink in layers:
- Database design — Designed core tables (
User,Donor,Hospital,BloodRequest,BloodBank) with clear relationships in MySQL. - Backend development — Used Java with Spring Boot for the REST API layer, Spring Security for authentication and role management, and Spring Data JPA for clean object-relational mapping.
- Frontend development — Built the interface using HTML, CSS, JavaScript, and Bootstrap for a responsive, accessible experience across hospital and donor portals.
- Donor matching engine — Implemented logic to rank donors based on compatibility, availability, and proximity (detailed below).
- Testing — Used Postman extensively to test API endpoints before wiring up the frontend.
- Version control — Managed collaboratively via GitHub, with Maven handling build and dependency management.
Challenges We Faced
Our biggest challenge by far was the smart donor matching logic.
Matching isn't just "same blood group, send notification." We had to design a system that weighs multiple factors simultaneously to rank the best donor first. We modeled it conceptually as a weighted scoring function:
$$ \text{Score}(d) = w_1 \cdot C(d) + w_2 \cdot A(d) + w_3 \cdot \frac{1}{D(d) + \epsilon} + w_4 \cdot R(d) $$
Where, for a donor $d$:
- $C(d)$ — blood group compatibility score (binary or partial, for compatible types)
- $A(d)$ — availability status (1 if available, 0 otherwise)
- $D(d)$ — distance from the hospital making the request
- $R(d)$ — historical responsiveness (e.g., past acceptance rate)
- $\epsilon$ — a small constant to avoid division by zero for very close donors
- $w_1, w_2, w_3, w_4$ — tunable weights reflecting priority (compatibility and availability weighted highest)
Donors are then ranked by:
$$ \text{RankedDonors} = \text{sort}\big({d_1, d_2, \dots, d_n}, \text{key} = \text{Score}, \text{descending}\big) $$
Getting this right meant constantly testing edge cases — what happens when no donor is "perfect"? When two donors tie in score? How do we re-trigger the escalation mechanism if the top-ranked donors don't respond within a time threshold $T$? We modeled escalation as a simple time-based trigger:
$$ \text{Escalate} = \begin{cases} \text{true}, & \text{if } t_{\text{elapsed}} > T \text{ and no donor has accepted} \ \text{false}, & \text{otherwise} \end{cases} $$
Balancing correctness, performance, and simplicity — all while coordinating as a team under hackathon time pressure — pushed us to iterate quickly and communicate constantly about design tradeoffs.
Log in or sign up for Devpost to join the conversation.