Skip to content
Leandro FariaUTC−3
← SELECTED WORK

Sistema de Retomada

COVID shut a dental clinic for three months. I built the system that decided who came back first.

THE SHORT VERSION

COVID closed the clinic for three months and left a queue of suspended appointments at a place that normally saw over a thousand a day. Reopening at reduced capacity meant deciding who came back first, and first come first served would have left interrupted treatments to get worse. I built a system that ranked patients by clinical risk and by how close their treatment was to finishing — critical and nearly done goes first, because someone who finishes doesn't come back next month and that frees a slot. It took a month to build and six months to clear the queue, and the clinic was later invited to present the work to the Air Force health directorate.

WHEN
2020 — 2021
MY PART
I proposed it, planned it, built it, deployed it and supported it until the queue was gone.
BUILT WITH
Angular · MySQL

CONTEXT

The clinic is the Brazilian Air Force dental clinic in Brasília, serving military personnel and their families. On a normal day it saw more than a thousand appointments.

It kept working through the start of the pandemic, then stopped for about three months during the worst of it, taking only emergencies. Reopening was straightforward; the queue that had built up behind it was not.

Three months of a thousand appointments a day is the size of the problem, and the clinic could not take them all back at once. The order in which people returned carried clinical consequences, which ruled out first come, first served.

WHAT CONSTRAINED IT

  • Capacity on reopening was lower than normal, because of the sanitary protocol.
  • There was risk in both directions: bringing people into a waiting room, and leaving an interrupted treatment sitting for months.
  • The patient data lived in the clinic's legacy system and was months out of date. During the shutdown, reality had moved on without it.
  • It ran inside a military health service, where every action had to remain traceable afterwards.
  • I had roughly a month to deliver it.

DECISIONS

  1. 01

    Rank by clinical risk and by how close the treatment was to finishing

    The queue put people who were both at risk and close to discharge first, because someone who finishes doesn't come back next month and that frees a slot for the next person.

    Ranking by severity alone is the obvious approach, and it is half of the answer. The system also weighed how much treatment each patient had left.

    The second half is about throughput. Ranking by severity alone fills the calendar with long treatments and stalls everyone waiting behind them, which serves nobody.

    INSTEAD OF
    Ordering by clinical urgency alone
    WHAT IT COST
    Someone with a serious but long treatment could wait behind someone less urgent who could be discharged in two visits. That's a real cost and I accepted it, because the alternative was a queue that moved slower for everybody.
  2. 02

    Ordered rules, not a score

    Criteria are evaluated in order of weight rather than added into a score, so a dentist looking at the queue could see why a patient was where they were.

    Is the patient elderly, do they have comorbidities, was there an interrupted procedure that gets worse if left, how much treatment remains, and so on down the list.

    I chose ordering over points because I could explain it. A score with invented weights produces a number nobody can argue with, which is not the same as a number that's right.

    INSTEAD OF
    A weighted point score
    WHAT IT COST
    Ordered rules can't express "slightly more important than". A criterion either outranks another or it doesn't, and a case that sits between two rules has nowhere to go.
  3. 03

    Put a phone campaign between the legacy data and the ranking

    Before ranking anyone I had the dentists call every patient, because the database was months stale and people had finished their treatment elsewhere, been hospitalised, or died.

    The gap between the database and reality wasn't random, and none of it was recoverable from the data itself.

    So the dentists called, asked a short set of questions, and the answers went into the system. Only then did they join the legacy data to produce the ranking. It's a refresh step with a human in the loop, sitting deliberately between the source and the decision.

    INSTEAD OF
    Ranking straight from the database
    WHAT IT COST
    Weeks of dentists' time on the phone before a single appointment was scheduled. Skipping it would have been faster and would have meant calling people who were no longer there.
  4. 04

    Release the system one phase at a time

    I shipped each phase as the operation reached it, and never built a screen for a phase whose data didn't exist yet.

    Registration first, while the clinic was still closed and the dentists could enter the backlog from their own appointment books. Then the calling campaign. Then scheduling, working down the ranked list within whatever capacity the clinic had that week.

    INSTEAD OF
    Building the whole system and releasing it when it was done
    WHAT IT COST
    The system was never finished, and there was no point where I could hand it over and walk away. It also meant redesigning parts of later phases once the earlier ones showed what the data actually looked like.
  5. 05

    Log every call, not just its outcome

    Every call was recorded in full — who made it, when, what the patient said, whether they still wanted to continue — because a queue that reorders people has to be able to explain itself months later.

    This was in from the start rather than bolted on at the end. In a military health service, someone will eventually ask why a particular patient was where they were, and they won't have been in the room.

    INSTEAD OF
    Recording only the result of each call
    WHAT IT COST
    More typing for a dentist who was already making dozens of calls a day.

WHAT CAME OUT OF IT

1,000+
appointments a day, the clinic's normal volume
~3 months
fully suspended, emergencies only
~6 months
to clear the backlog and absorb new demand
1 month
from idea to deployed

WHAT I WOULD DO DIFFERENTLY

The criteria were incomplete on day one, and I only found out once the calls started. Patients came back with situations that weren't in the list of options I had written, so I added them and shipped the changes while the operation was running.

That worked because I was the only person touching the code. Today I'd model the criteria as data from the start instead of something I edit and redeploy — the clinic understood the ranking better than I did, and they should have been able to change it without me.

The clinic was later invited to present the work to the Air Force health directorate, as the unit that had cleared a backlog other units allowed to persist.