BloodLink AFGC

“Smarter emergency blood fulfillment through intelligent donor dispatch and real-time inventory coordination."

Comment

About the Project

BloodLink AFGC is a mobile application designed to improve emergency blood fulfillment by coordinating blood-bank inventory and voluntary blood donors through a unified digital workflow.

During an emergency, a hospital may require several units of blood while some compatible units are already available through authorized blood banks and additional units may need to be obtained from voluntary donors. Traditional approaches often treat these sources separately or rely on broad donor communication.

We developed BloodLink AFGC around a different approach: continuously determine how much of the blood requirement is still unresolved and use that information to control donor dispatch.

The central idea is represented by:

$$ G(t) = \max\left(0, Q - I_R(t) - D_C(t)\right) $$

Where:

  • $Q$ = required blood quantity
  • $I_R(t)$ = compatible blood units secured or reserved from authorized inventory
  • $D_C(t)$ = confirmed donor commitments
  • $G(t)$ = remaining fulfillment gap

This allows the system to treat blood inventory and voluntary donors as coordinated fulfillment sources rather than independent workflows.

How It Works

A typical BloodLink AFGC emergency flow is:

Hospital creates emergency request
              ↓
Check compatible blood-bank inventory
              ↓
Reserve available units
              ↓
Calculate remaining fulfillment gap
              ↓
Filter eligible and compatible donors
              ↓
Rank suitable candidates
              ↓
Dispatch a controlled candidate tier
              ↓
Receive donor responses
              ↓
Recalculate fulfillment gap
              ↓
Fulfilled?
       ┌───────────┴───────────┐
      YES                      NO
       ↓                        ↓
Stop dispatch             Next dispatch tier

The controller continuously reacts to changes such as inventory reservation, inventory release, donor acceptance, donor cancellation, and dispatch timeout.

Adaptive Fulfillment Gap Control

The Adaptive Fulfillment Gap Controller (AFGC) is the main processing component of BloodLink.

For example, suppose a hospital needs 4 units:

Required quantity     = 4
Reserved inventory    = 2
Confirmed donors      = 0

Then:

$$ G = \max(0,4-2-0)=2 $$

Only the remaining 2-unit gap needs additional donor fulfillment.

When one donor confirms:

$$ G = \max(0,4-2-1)=1 $$

When a second donor confirms:

$$ G = \max(0,4-2-2)=0 $$

Once the gap becomes zero, the system marks the request as fulfilled and terminates unnecessary pending donor invitations.

This creates a closed-loop fulfillment process rather than a one-time donor search.

Dual-Source Blood Fulfillment

BloodLink AFGC coordinates two sources:

1. Authorized Blood Inventory

The system checks compatible blood units from participating blood banks and reserves available units for the emergency request.

2. Voluntary Donors

Only the remaining unresolved requirement is used to determine the need for donor dispatch.

This allows the system to avoid sending donor requests for blood that has already been secured through inventory.

Donor Selection

The donor matching process applies multiple filtering stages before dispatch.

Candidate Donors
      ↓
Location Filtering
      ↓
Eligibility Check
      ↓
Blood Compatibility
      ↓
Availability
      ↓
Suitability Ranking
      ↓
Dispatch Candidates

Geographic distance is calculated using the Haversine formula:

$$ a = \sin^2\left(\frac{\Delta\phi}{2}\right) + \cos(\phi_1)\cos(\phi_2) \sin^2\left(\frac{\Delta\lambda}{2}\right) $$

$$ d = 2R\cdot \operatorname{atan2} \left(\sqrt{a},\sqrt{1-a}\right) $$

Where:

  • $d$ = distance between two locations
  • $R$ = Earth's radius
  • $\phi$ = latitude
  • $\lambda$ = longitude

The project also uses geospatial candidate filtering before exact distance verification.

Donor Ranking

After filtering, eligible candidates can be prioritized using a multi-factor suitability score.

A configurable scoring model is:

$$ S = w_1P + w_2C + w_3R $$

Where:

  • $P$ = proximity score
  • $C$ = compatibility score
  • $R$ = historical response reliability
  • $w_1,w_2,w_3$ = configurable weights

The ranking stage is performed by the backend rather than the mobile client.

Response-Aware Tiered Dispatch

BloodLink does not need to contact every eligible donor at once.

Candidates can be divided into controlled dispatch tiers:

Tier 1
  ↓
Wait for responses
  ↓
Requirement fulfilled?
  ├── Yes → Stop
  └── No  → Tier 2
                ↓
             Wait
                ↓
             Tier 3

The implementation includes dynamic tier sizing based on the remaining fulfillment gap:

$$ T_k = \min \left( \left\lceil2.5G\right\rceil, N_{\text{available}} \right) $$

Where:

  • $T_k$ = size of the current dispatch tier
  • $G$ = remaining fulfillment gap
  • $N_{\text{available}}$ = number of eligible unnotified candidates

When the gap reaches zero, pending invitations are automatically terminated.

Privacy-Aware Proximity

BloodLink also includes a privacy-oriented proximity mechanism.

Instead of continuously exposing exact donor coordinates, the system can use a temporary proximity representation based on:

  • Request identity
  • Donor identity
  • Distance band
  • Time window

The prototype generates an ephemeral HMAC-SHA256 proximity credential:

$$ EPC = HMAC\text{-}SHA256 \left( K_{\text{ephemeral}}, ReqID \parallel DonorID \parallel DistanceBand \parallel TimeSlot \right) $$

Distance is represented using coarse bands rather than continuously exposing the exact location.

Example:

< 2 km
5 km
10 km
15 km

The temporary credential is associated with the emergency request and can be revoked when the request is fulfilled or terminated.

Mobile Application

The mobile application is built using:

React Native
TypeScript
React Native CLI

The project uses bare React Native and does not use Expo.

The application contains role-specific workflows for:

Donors

  • View blood group
  • Manage availability
  • View eligibility
  • Receive emergency requests
  • Accept or decline requests
  • View donation history

Hospitals

  • Create emergency blood requests
  • View blood requirements
  • Monitor fulfillment
  • View inventory
  • Monitor donor responses
  • View AFGC telemetry

Blood Banks

  • Maintain blood inventory
  • Track available and reserved units
  • Support emergency inventory coordination

Backend Architecture

The backend is implemented using:

Node.js
Express
TypeScript

The architecture is modular:

backend/
├── routes/
├── middleware/
├── services/
│   ├── afgcEngine.ts
│   ├── inventoryService.ts
│   ├── matching.ts
│   ├── compatibility.ts
│   ├── eligibility.ts
│   ├── haversine.ts
│   ├── proximityCredential.ts
│   ├── tieredDispatch.ts
│   └── stateMachine.ts
├── types/
└── tests/

The AFGC logic is isolated in its own service so that the emergency fulfillment controller can be evaluated independently from the mobile interface.

The project documentation also defines dedicated modules for inventory reservation, proximity credentials, state transitions, and tiered dispatch.

Real-Time Request State

Emergency requests move through controlled states such as:

CREATED
   ↓
MATCHING
   ↓
NOTIFIED
   ↓
PARTIALLY_FULFILLED
   ↓
FULFILLED

Other possible states include:

DECLINED
CANCELLED
EXPIRED
EN_ROUTE
COMPLETED

A donor cancellation can reopen the fulfillment gap and activate a subsequent dispatch stage.

Example

Consider a hospital request for 4 B+ units.

Required                 4
Blood-bank reserve       2
Confirmed donors         0
Remaining gap            2

The first dispatch stage is activated.

Suppose one donor accepts:

Required                 4
Blood-bank reserve       2
Confirmed donors         1
Remaining gap            1

The system continues the dispatch process because the request is still partially fulfilled.

A second donor accepts:

Required                 4
Blood-bank reserve       2
Confirmed donors         2
Remaining gap            0

The emergency request becomes:

FULFILLED

Pending donor invitations are then terminated and the matching cycle stops.

Performance Evaluation

To evaluate the proposed approach, BloodLink AFGC includes a comparative benchmark framework.

Three strategies are considered:

1. Legacy Broadcast Model
2. Static Nearest-N Model
3. BloodLink AFGC

The evaluation focuses on:

  • Notification volume
  • Redundant donor dispatch
  • Fulfillment time
  • Dispatch efficiency
  • Network traffic
  • Candidate processing
  • Location exposure

A useful dispatch metric is:

$$ \eta = \frac{D_C}{N_{\text{dispatched}}} $$

Where:

  • $D_C$ = confirmed donor commitments
  • $N_{\text{dispatched}}$ = total donor invitations sent

The purpose is to evaluate whether a requirement-aware dispatch mechanism can achieve emergency fulfillment with less unnecessary outreach.

What We Built

The prototype currently includes:

Adaptive Fulfillment Gap Controller
Dual-Source Inventory Reservation
Blood Compatibility Filtering
Donor Eligibility Filtering
Haversine Distance Calculation
Geospatial Candidate Filtering
Multi-Criteria Donor Ranking
Response-Aware Tiered Dispatch
Ephemeral Proximity Credentials
Emergency Request State Machine
React Native Mobile Interface
Node.js REST API
Comparative Benchmark Engine

The implementation documentation records dedicated tests for the AFGC engine, inventory service, proximity credentials, matching, tiered dispatch, state transitions, eligibility, compatibility, and API integration.

Challenges

One of the biggest challenges was designing the system around changing emergency conditions.

A donor may accept, decline, or cancel. At the same time, blood-bank inventory may become available or be released.

This means the system cannot calculate a result only once.

It has to continuously respond to changes:

Inventory Change
      ↓
Recalculate

Donor Acceptance
      ↓
Recalculate

Donor Cancellation
      ↓
Recalculate

Tier Timeout
      ↓
Evaluate Next Tier

Another challenge was balancing the complexity of the backend logic with the simplicity required in the mobile interface.

What We Learned

Through BloodLink AFGC, we learned how to combine:

  • Mobile application development
  • REST API design
  • Backend system architecture
  • Geospatial algorithms
  • State-machine design
  • Resource reservation
  • Real-time event processing
  • Privacy-aware system design
  • Performance benchmarking

More importantly, we learned how a real-world emergency problem can be converted into a measurable software control workflow rather than simply another CRUD application.

Future Scope

Future versions of BloodLink AFGC could include:

  • Integration with authorized blood-service networks
  • Real road travel-time estimation
  • Larger regional donor networks
  • Multilingual support
  • Advanced demand forecasting
  • Hospital-to-hospital inventory transfer
  • Improved analytics and operational dashboards
  • Large-scale real-world validation

Conclusion

BloodLink AFGC provides a different approach to emergency blood coordination by treating blood-bank inventory and voluntary donors as coordinated fulfillment resources.

Instead of simply searching for nearby donors, the system continuously evaluates the unresolved emergency requirement and adapts the donor-dispatch process according to the current fulfillment state.

The result is a prototype focused on efficient emergency coordination, controlled donor outreach, real-time fulfillment tracking, and privacy-aware proximity handling.

The project demonstrates how mobile development, backend engineering, mathematical models, and event-driven system design can be combined to address a real-world healthcare coordination problem.

Share this project:

Updates

Submission history