Inspiration

In many hospitals, families are asked to bring eligible donors before an operation. When a patient has no nearby relatives, the request often spreads through phone calls and social media. These posts may expose patient information, omit essential details, and remain online after the need has ended.

As a general practitioner, I wanted to explore a safer coordination layer: community response, hospital control.

The urgency is even greater in conflict-affected and resource-constrained areas, including communities in Sudan, where travel is difficult, hospital capacity is stretched, and families may have limited networks. In these settings, reducing the delay between a hospital request and a willing donor learning about it can be vital.

What it does

Nidaa Blood AI turns a natural-language hospital request into a clear, privacy-safe, time-limited community appeal.

A requester can write in Arabic or English. The workflow identifies the hospital, requested blood group, number of willing donors, deadline, and area. It removes patient-identifying information and highlights details that still require confirmation.

The requester reviews every field before publishing. Relevant opt-in community members can view the appeal and indicate that they are willing to visit the hospital.

Nidaa never decides who is eligible, confirms blood compatibility, or replaces official services. Final screening, testing, collection, and use of blood remain entirely under hospital control.

Potential impact

Nidaa is designed as a coordination bridge—not a replacement for emergency, hospital, or medical services.

By quickly distributing a verified, minimum-data alert to relevant community members, Nidaa could shorten the coordination time between a hospital request and a willing donor responding.

This could be especially valuable in conflict-affected or underserved areas. Responsible deployment would require verified hospital partners, low-bandwidth or SMS options, strong privacy and security controls, local legal review, and plans for internet or electricity interruptions.

How I built it

I built the responsive React prototype with Codex as my product and engineering collaborator. I began with the healthcare workflow, privacy boundaries, and hospital-control requirements rather than with code.

Codex helped transform these requirements into a working product: the responsive interface, user journey, application states, bilingual examples, analysis flow, safety language, and iterative testing.

GPT-5.6 was used during development to design and test the natural-language-to-structured-appeal workflow, privacy rules, missing-information checks, and Arabic and English examples.

The public prototype demonstrates this workflow using fictional data and a constrained demonstration endpoint.

Challenges

The main challenge was preserving urgency without turning the application into medical advice or exposing patient identity.

Another challenge was making a multi-step process understandable on mobile for people experiencing stress. I addressed these challenges through minimum-data defaults, editable review fields, transparency labels, automatic closure design, and repeated reminders that the hospital remains the final authority.

Designing for conflict-affected areas introduced additional questions about connectivity, request verification, misuse prevention, and the safety of donors and requesters.

Accomplishments

  • Built a complete mobile-first appeal workflow
  • Supported Arabic and English request examples
  • Added privacy-focused structuring and missing-information prompts
  • Created clear verification and transparency states
  • Designed automatic expiry and fulfillment behavior
  • Kept medical eligibility and compatibility decisions with hospitals
  • Turned healthcare experience into a working prototype without a previous coding background

What I learned

Codex enabled a healthcare professional without a coding background to transform domain knowledge into a functioning prototype.

I learned that AI is most useful in this project as a structuring, communication, and safety assistant—not as a medical decision-maker.

I also learned that meaningful healthcare technology requires more than a working interface. It requires privacy protection, verification, accessibility, local partnerships, and clear responsibility boundaries.

What's next

The next steps are to work with hospitals and blood banks, create verified request intake, develop opt-in donor accounts, strengthen consent and notification controls, and complete local legal and security reviews.

Future versions could include low-bandwidth interfaces, SMS-based alerts, approved messaging channels, multilingual support, offline request queues, accessibility improvements, and supervised pilots under official hospital and blood-bank governance.

Built With

Share this project:

Updates