The difficult part wasn't assigning students. It was making the whole year work.
143 students submitted four rotations each, creating 572 hospital-level assignments to reconcile.
Those requests had to coexist within three hospitals, four departments, four rotation periods, and different student preferences.
One simple approach would be to create permanent groups and rotate them together throughout the year.
But a student could end up spending the entire clerkship cycle with a group they did not choose.
Another approach would be to place students manually and adjust the groups until the numbers looked reasonable.
But every adjustment could affect another student's preference, another department, another hospital, or another rotation.
Or we could simply prioritize the most requested choices.
But without class-wide balancing, some hospital–department groups could become too large while others become too small.
That is why a digital allocation solution was built. Not simply to replace manual work, but to make it possible to evaluate the class as one connected system—preserving meaningful student preferences while keeping clinical groups workable and the overall rotation cycle coherent.
The preferences were not evenly distributed
143 students submitted four rotations each, creating 572 hospital-level assignments to reconcile. Those requests did not arrive as an even distribution across the three hospitals.
The allocation therefore could not simply assign students according to the raw popularity of each hospital. Demand had to be reconciled with clinical capacity and the structure of the four-rotation cycle.
A hospital preference was never just a hospital preference.
Each request carries several dimensions at once: Hospital · Department · Rotation · the student's complete four-rotation plan.
The system had to reason about the complete rotation cycle rather than treating each request as an isolated placement.
How the allocation works
The allocation engine evaluates the class as a connected system rather than making independent decisions for each student.
- ✕It is not randomly assigning students.
- ✕It is not ignoring submitted preferences.
- ✕It is not simply giving everyone their first choice regardless of class-wide consequences.
- ✕It is not intentionally creating unnecessary hospital movement.
- ✕It is not arbitrarily changing students' choices.
- ✕It is not treating every student identically regardless of their actual preference structure.
- ✕It is not filling groups without considering whether the resulting four-rotation cycle is valid.
The goal was not to make every request possible.
With finite clinical capacity and competing preferences, it is not possible to satisfy every individual request exactly.
The objective was to preserve meaningful student preferences wherever possible while producing a complete allocation that remains workable for the entire class.
From preferences to a workable allocation
After the submitted preferences were reconciled with the allocation constraints, the resulting clerkship schedule could be examined across hospitals, rotation blocks, and departments.
This reflects published allocation data, distinct from the original preference data shown above.
Three phases. One complete allocation journey.
Preference Submission
Students submitted their desired four-rotation plans.
Purpose: capture the class's original preferences before allocation.
Provisional Allocation & Student Swap Window
After optimization, students received their provisional clerkship allocation, then a defined window to exchange clerkship sites among themselves.
Final Clerkship Decision
After the swap window closed, submitted swap requests were reviewed and incorporated where appropriate. The resulting allocation was finalized → sealed → communicated.
Every phase had a corresponding student communication
Three existing email artifacts, one per phase.
The system automatically generated and sent the appropriate student communication at each phase by reading the relevant submitted preferences, provisional allocation, swap/review outcomes, and final clerkship data.
This same workflow allowed the system to generate the clerkship documents required for the process without manual preparation or repetitive data entry.
We Received Your Rotation Plan
Preference submission confirmation
Phase II Clerkship Decision
Provisional allocation + 72-hour swap window
Final Clerkship Decision
Final allocation after the review and swap process
From data to documents
Once the underlying clerkship data was available, the system could generate the documents needed for the process automatically — including student communications, allocation outputs, rotation information, and related clerkship materials — without requiring manual preparation for each student.
This was not just a scheduling algorithm
It was a complete workflow — collecting preferences, analyzing demand, optimizing a class-wide allocation, producing the published clerkship schedule, handling the three-phase communication process, and automatically generating the required student communications and clerkship documents.
Reconciling preferences and constraints
The system reconciles student preferences and operational constraints.
Understanding the data
The system makes the resulting preference and allocation data understandable.
Generating communications and documents
The system uses the resulting data to generate the required clerkship communications and documents.
🔒 Anonymized examples
The names, registration numbers, student identities, and student-level records shown throughout this presentation are anonymized placeholders or illustrative examples.
The original submission data, allocation records, student roster, and related student-level information are confidential property of the University of Rwanda Medical School, DOC 3 Class of 2027, and are reserved for authorized access only.
From 143 preferences to a sealed clerkship schedule
Under the Hood
Inputs
- Student preferences
Processing
- Preference normalization
- Hospital eligibility
- Rotation structure
- Capacity considerations
- Allocation logic
- Validation
Outputs
- Published Clerkship
- Student allocation emails
- Rotation team information
- Analytics
The goal was never to make every individual schedule perfect.
The goal was to create the strongest workable allocation for the class — one that respects student preferences as far as possible while maintaining practical clinical groups, sensible hospital logistics, and a coherent four-rotation cycle.