FairWindow

FairWindow replaces first-come-first-serve hospital booking with a short signup window, then fairly allocates slots using barriers + AI urgency scoring. Outputs winners, waitlist, and quick confirm.

Comment

Inspiration

Hospital booking and “last-minute slot” systems often default to first-come-first-serve. It looks neutral, but it rewards whoever has the fastest internet, the newest device, and the ability to stop work instantly. That creates structural unfairness for shift workers, caregivers, people with disabilities, and anyone with limited connectivity. We wanted a booking flow that acknowledges those “silent constraints” instead of amplifying the “noise” of speed.

What it does

FairWindow replaces the click-race with a time-boxed registration window. Patients register during a fixed period and can optionally indicate access barriers and provide a short reason. After the window closes, the system runs an allocation and outputs:

  • a winners list (who gets the slot)
  • a waitlist (ordered backup list)
  • an optional confirmation step to fill the slot quickly if someone can’t make it

How we built it

We built a lightweight web app:

  • Frontend: index.html, style.css, app.js (a simple multi-screen flow for admin + patient actions)
  • Backend: Flask API (app.py) with in-memory storage (storage.py)
  • Allocation engine: allocator.py calls scoring.py to compute a score per registration and then selects winners + waitlist
  • Optional AI urgency: a free-text reason can be converted into an urgency level and bounded urgency points via OpenAI’s Responses API, using structured JSON output.

At a high level, each registration gets a score like:

[\text{score} = \text{base} + 10 \cdot (#\text{barriers}) + \text{urgency_points} + \text{randomness}]

The window design ensures fairness in access time, and the scoring makes the decision process explicit.

Challenges we ran into

  • Avoiding “AI as diagnosis.” We had to design urgency scoring as decision-support only, keep it bounded, and avoid medical claims.
  • Making the demo reliable. We added caching and strict JSON output so model responses wouldn’t break allocation.
  • Timing edge cases. The UI needed to clearly prevent running allocation before the window closed (and explain why), so judges wouldn’t see confusing failures.
  • Balancing fairness and gaming risk. We had to keep the system simple and transparent while acknowledging that self-reported inputs can be abused.

Accomplishments that we're proud of

  • We replaced FCFS with a fair-window + allocation workflow that still respects the reality of limited hospital capacity.
  • We built an end-to-end system that produces winners + waitlist in a way that is easy to explain and demonstrate live.
  • We integrated optional AI urgency scoring with bounded impact and structured outputs.

What we learned

  • “Fairness” is as much about process design as it is about algorithms—changing the mechanism (time window) can remove an entire class of advantage.
  • For real-world systems, guardrails matter: caps, transparency, and graceful failure paths are as important as raw model capability.
  • Small UX details (countdowns, disabled states, clear status) can make or break a live demo.

What's next for FairWindow

  • Add verification options and anti-gaming signals (e.g., repeat submissions, anomaly flags) while keeping the system accessible.
  • Add audit logs and an admin dashboard so decisions are reviewable.
  • Expand barrier support (language access, mobility needs) and allow hospitals to tune weights per department.
  • Move from in-memory storage to a database, add authentication, and deploy as a secure service hospitals can pilot.

Built With

Share this project:

Updates