A practical way to make physician call schedules fair

Start with the coverage requirement. List the call types, shift times, staffing counts, sites, skills and backup roles that must be filled. Do this before collecting preferences, because coverage defines the minimum viable schedule.

For a physician group, this usually means separating weekday call, weekend call, holiday call, backup call and any site-specific coverage into clear categories. A single line called call is too vague if one assignment means a quiet weekday and another means a high-friction weekend.

Write the requirement in operational terms: how many physicians are needed, which credentials or roles qualify, when the shift starts and ends, and whether the assignment creates a rest concern for the next day. This gives the schedule maker a stable base before preferences enter the process.

A constraint is something the schedule should not violate: unavailable dates, required rest, skill coverage or site eligibility. A preference is a request that should be considered when possible.

Mixing the two creates conflict. If every preference is treated like a hard rule, the schedule may become impossible. If every constraint is treated casually, the schedule may become unsafe or unacceptable.

A practical rule is to label each input before scheduling starts. Unavailable dates, required skills, post-call limits and site eligibility are constraints. Requested days off, preferred weekends, preferred partners and soft workload preferences are requests. The schedule should protect constraints first and optimize requests second.

Do not collect availability by email, text message, hallway conversations and spreadsheet comments at the same time. Fragmented intake is one of the easiest ways to create a dispute later, because the schedule maker cannot prove which request was received, changed or missed.

Set a deadline and a format. Tell physicians what counts as unavailable, what counts as a preference and what happens after the deadline. Late requests may still be considered, but they should not quietly override earlier rules unless the group agrees to that policy.

The point is not bureaucracy. It is fairness. A physician who submits a request through the official process should not lose priority to a private message that arrives after the draft is already built.

Fairness is not only about equal totals. The group usually cares most about difficult assignments: nights, weekends, holidays, backup call, late shifts and heavy sequences.

Track those categories separately. If you only count total assignments, one physician can receive the same number of shifts as another but a much heavier burden.

Define difficult assignments before looking at the draft. If the group decides that a weekend is difficult only after seeing who received it, the process becomes subjective. Common categories include Friday night, Saturday, Sunday, major holidays, high-volume locations, backup call and close sequences.

Also decide whether every difficult assignment has the same weight. Some groups treat all weekends equally. Others weigh major holidays, overnight call or backup call differently. The exact model can be local, but it should be explicit enough that the schedule maker can explain it.

A workable call schedule is not automatically the best schedule. If the first draft covers every shift but creates repeated difficult sequences for the same physician, keep iterating before publication. The first goal is feasibility. The second goal is a fair distribution the group can understand.

Compare drafts by the same measures each time: uncovered shifts, violated constraints, preference satisfaction, difficult assignment distribution and visible edge cases. This prevents the schedule maker from choosing a draft just because it looks cleaner on the calendar.

Once coverage, constraints and preferences are entered, generate a draft. Do not publish the first workable version immediately. Review it for coverage gaps, repeated hard assignments, rest issues and fairness concerns.

SaniShift uses a transparent fairness score from 0 to 100 to help the schedule maker inspect the distribution before publication.

The review should be specific. Look for people with back-to-back hard assignments, people who received multiple weekends close together, holiday patterns that repeat from the prior cycle and swaps that were assumed but not approved. If a physician asks why the schedule landed that way, the answer should come from the rules and the draft review, not memory.

A fair process also explains change. If the group moved from a manual spreadsheet to a new workflow, tell physicians what is different: where availability is submitted, how preferences are considered, how difficult assignments are tracked and who approves swaps.

The communication does not need to be long. A short publication note can say which constraints were protected, how difficult shifts were balanced and where physicians should request changes. That note helps the schedule feel deliberate instead of arbitrary.

After publication, swaps are inevitable. They should be easy to request but not invisible. A swap can create a coverage gap, rest problem or fairness imbalance if nobody reviews it.

Use an approved swap workflow. Let physicians request changes, then have the schedule maker validate coverage and fairness before accepting.

The approval step should check both people involved in the swap and the schedule around them. A swap may appear harmless on the target date but create a bad sequence, missing skill or excessive burden later in the week. Approval keeps the official schedule from drifting away from the rules that made the published version fair.

After the schedule period ends, review what happened. Which shifts were hardest to fill? Which physicians needed repeated exceptions? Which swaps were approved, denied or requested too late? This turns each schedule into input for the next one.

The schedule maker should not have to start from zero every month. A simple record of rules, exceptions and pain points makes the next cycle faster and more defensible. It also helps the group refine policy without rewriting everything during a deadline.

The first trap is treating a clean-looking calendar as a fair calendar. A month can look balanced visually while one person carries the worst weekends or receives hard assignments immediately after prior commitments. Always review the burden categories, not only the grid.

The second trap is fixing complaints one by one after publication. Each private exception can make sense alone and still damage the schedule as a whole. Use a controlled change process so the schedule maker can see the impact before the exception becomes official.

The third trap is changing the fairness definition mid-cycle. If the group wants holidays, weekends or backup call weighted differently, adjust the rule for the next cycle unless there is a clear operational reason to reopen the current one. Stable rules build trust over time and make every later review easier.