· 2026
ICAP — attending physician on-call system
A multi-user web application where attending physicians choose their own on-call days. It doesn't generate a schedule; it keeps everyone's individual choices from colliding.
The problem
With the junior doctor and nurse schedulers the problem was clear: one person has to build a fair schedule for everyone. With attending physician on-call, the situation is different. Attendings don’t want a finished schedule handed to them — they want to choose their own on-call days around their own lives. The work here isn’t generating a schedule, it’s coordination: keeping everyone’s individual choices from colliding while each person picks their own piece.
This used to run over WhatsApp. People would post “I’m taking these days,” I would update an Excel file, last-minute changes happened and had to be relayed to me for quick entry. Everyone had to track their own hour totals by hand.
What I built
A multi-user web application. Each attending physician has their own login; they sign in and select their on-call days on the next month’s calendar. Selections register on the calendar immediately — the days other physicians have chosen are visible too, so everyone sees the shared table at the same time.
The system’s one hard rule: two physicians from the same specialty can’t be on call on the same day. If there are two orthopedists, they have to pick different days — the system blocks the second selection. Everything else is left to the physician’s own preference.
Below the calendar, each physician’s running on-call total updates live (16 hours for a weekday, 24 for a weekend or national holiday). Turkish national holidays — the fixed ones and the religious holidays computed from the Hijri calendar — are marked automatically. Physicians can preview their selections as a table and finalize them; after finalizing, the lock can be released to edit again. On the last day of each month the schedule is archived automatically, and past records can be downloaded as Excel files.
What was technically interesting
What’s interesting in this project isn’t optimization — there’s no schedule being generated here. What’s interesting is the multi-user condition itself.
The first technical issue was a problem the architecture itself created: concurrency. In the Excel era there was no such thing as a concurrency problem, because I was the only writer — but my being the only writer was exactly the problem. Once ICAP distributed the work across a dozen-odd people, concurrency became a condition that arises automatically: when several physicians make selections at the same time, the shared table has to stay consistent on everyone’s screen. With this many people, sooner or later two will select at the same moment; the system has to assume that and check for it. I solved this with server-side validation — a selection is checked on the server, not the client; the client only displays the result.
The second issue was authentication. This was a layer that simply didn’t exist in the single-file tools I’d built before: each physician’s own account, own password, own selection rights. I learned Flask’s session management and hashed password storage for this project.
The third was scheduled archiving: on the last day of each month, the system needed to save that month’s schedule automatically. The server doing work at a specific time even when no one triggers it — that’s a persistent-service behavior the single-file tools never had.
ICAP runs as a persistent service on Railway. Unlike the single-file tools, this isn’t a file; it’s an application that has to be kept up, updated, and running. With this project I learned, in practice for the first time, the difference between “a file you distribute” and “a service you operate.”
Outcome
Attending on-call has run on this system for several months now. Any physician can make their selections however they like and change them up to the final hour of the month’s last day. The delays that came from the human relay in the middle are gone. Because the hour totals are shown dynamically in the app, the imbalances — one physician at 320 hours, another at 250 — are no longer a thing.
The repo is public. Anyone who wants to set up a similar system for their own department can clone the code and deploy their own instance — but the running instance is our hospital’s, with its own physician accounts.