Skip to main content

Practice Operations

Reassigning a Patient Case Without Losing the Thread

Reassignment is the most-used verb in front-office task work and the least designed. What a patient case has to carry so the next person is not starting over.

9 min read

In a multi-specialty group the patient case is where front-office work actually lives, and reassignment is the thing that happens to it most. A request comes in, lands in one queue, turns out to belong somewhere else, and gets passed along. Nobody designed that process. It grew.

Reassignment is treated as a routing action when it is really a handoff, and handoffs are where context goes missing. The person passing the case knows what they already tried, which number was disconnected, what the patient said at 4pm on Tuesday. The person receiving it gets a case and a category.

So the second person redoes the first person’s work. They call the number that was already tried, ask the question that was already answered, and the patient experiences a practice that is not listening. In a group with several departments and a central team this multiplies, because a case can move three times before it reaches someone who can finish it.

Rework is the cost, and it is larger than the routing error

The visible failure is a case sitting in the wrong queue. The expensive failure is what happens after it moves.

MGMA’s reporting on front-office phone work describes this pattern directly for intake and registration: the time sink lies both in the first call collecting details and in the rework that follows when information is missing or inconsistent, such as calling back to clarify a policy number, a spelling, a prior visit history, or a medication list. Each gap cascades into additional eligibility checks, rescheduled appointments, or chart clean-up.

That same March 10, 2026, MGMA Stat poll of 294 applicable responses ranked the most time-consuming phone work as eligibility and prior authorization at 45%, scheduling at 31%, intake at 9%, and prescription refills at 6%. Those are the categories that generate the cases, and they are the ones that get reassigned when a request crosses a boundary.

A practice that measures only queue accuracy will report improvement while the rework stays constant. The number worth having is touches per resolved request, because that is what reassignment actually inflates.

The case is the record, so the context has to live on the case

Most practices carry handoff context in the wrong place, which is a person’s head or a sticky note.

athenaOne gives the case somewhere better. Reassignment runs through PUT /patients/{patientid}/documents/patientcase/{patientcaseid}/assign, and the case carries action notes readable and writable through GET and POST on /documents/patientcase/{patientcaseid}/actions. Those notes are the handoff artifact. If they are empty, the reassignment is a hot potato.

What belongs in them is narrow and specific: what was attempted, what the outcome was, what remains, and what the next person should not repeat. Two calls attempted, mobile disconnected, alternate number obtained from the pharmacy, coverage confirmed, still needs authorization before booking. That is thirty seconds to write and saves the next person fifteen minutes.

The discipline problem is that writing the note benefits the receiver, not the writer. Which is exactly why it does not happen consistently in a busy practice, and exactly why it is worth automating the parts that can be generated rather than typed. An attempt that was made by the system can record itself.

The complication: a case usually needs two things done, and only one gets tracked

This is the failure mode that makes a well-run queue produce bad outcomes anyway.

A large share of front-office cases carry more than one required action. Get the prior records and verify the coverage. Confirm the authorization and book inside the window it permits. Reach the patient and correct the demographics the last claim bounced on. The case is one object, the work is two threads, and the queue shows one status.

The reliable failure is that someone completes the first thread and reassigns or closes on it. The second half silently does not exist until a human catches it in review, which usually means at check-in or at billing. It looks like a successful handoff right up until the visit happens.

Authorization makes this concrete. Rescheduling an appointment silently breaks the link to an existing authorization, so a case that was reassigned after the reschedule was handled arrives at the next person looking complete, with the authorization quietly detached. An appointment whose authorization has not returned can only be pushed later, never pulled earlier, so discovering this late removes options rather than just adding work.

The automation’s job here is to make the second thread impossible to lose. Every required action gets recorded on the case as its own item with its own status, a reassignment carries the open items forward explicitly, and a case with an unfinished item cannot be closed by accident.

The handoff is anything the automation cannot finish itself. When the authorization has not returned, when the records request has been outstanding for two weeks, or when the patient has been unreachable across every channel, the case goes to a person with the attempt history attached and the specific open item stated. That is a different thing from putting an unexplained case back in a queue.

Route on what the case needs, not on who touched it last

The most common routing rule in a multi-specialty group is accidental: the case goes wherever it went last time, or to whoever is named in the chart.

Both of those rules decay over time. Panels shift, providers leave, departments reorganize, and the fields that encode those relationships are updated inconsistently. Routing built on them sends a steady trickle of cases to people who cannot act on them, and each of those becomes another reassignment.

The stable rule is to route on the open item. A case whose open item is an authorization goes to the authorization team regardless of which department opened it. A case whose open item is a records request goes to whoever chases records. The department matters for context and for who the patient hears from, but the open item is what determines who can actually finish it.

That also makes the queue legible to a manager for the first time. A queue sorted by open item shows where the group is genuinely constrained. A queue sorted by department shows which department is busiest, which is a different and much less useful fact.

The staffing effect is a second pass, not a smaller team

Automating case work changes what the people doing it spend their day on, and the honest version of that change is more persuasive than the exaggerated one.

A June 2, 2026, MGMA Stat poll of 260 applicable responses found 68% of practice leaders say their organization has not redesigned a role or adjusted staffing with the help of AI in the past year, while 26% say they have. MGMA describes the pattern among those who have as tier-shifting within existing job titles: coders, billers, schedulers, and front-office staff increasingly work a second pass, reviewing output, working denials, handling exceptions, and taking the patient-facing interactions that get handed off.

That is what happens to a case queue. The first pass, which is attempting contact, recording the outcome, chasing a records request, and re-checking whether the authorization has returned, is repetitive and time-bound. The second pass, which is the case that has gone wrong in an interesting way, is where experienced staff are worth what they cost.

The morale argument runs alongside it. MGMA’s reporting on practice staff morale lists rising administrative burdens among the reasons leaders cite when morale is worse, alongside staffing gaps and pay. Reassignment rework is precisely that kind of burden: high effort, invisible in any report, and entirely caused by the process rather than by the patient.

Key Takeaways

  • Measure touches per resolved request, not queue accuracy. Reassignment inflates the first number while leaving the second one looking fine.
  • Put handoff context on the case itself through action notes. Context carried in someone’s head does not survive a reassignment or a vacation.
  • Write what was attempted, what happened, and what remains. The next person needs to know what not to repeat more than they need a summary.
  • Record every required action on a case as its own item with its own status. A case with two threads and one status will lose one of them.
  • Carry open items forward explicitly on reassignment, and block closure while any remain open. Completing the first thread is the most common way the second disappears.
  • Re-check authorization links after any reschedule. The link breaks silently, and a case reassigned afterwards looks complete when it is not.
  • Route on the open item rather than the department or the provider named in the chart. Those fields decay and generate the next reassignment.
  • Automate the first pass and staff the second. The repetitive attempt-and-record work is what scales; the interesting failures are what experienced staff are for.

Reassignment looks like a small mechanical act, which is why no one designs it, and it is where most front-office rework in a multi-specialty group is manufactured. The fix is unglamorous and durable: put the context on the case, track every open item separately, route on what the case needs, and make it impossible to close something half-finished. An AI team working patient cases inside athenaOne can run the first pass on every case, record its own attempts as it goes, carry the open items through each handoff, and give a person the cases that have genuinely stalled with the history already attached.

Sources

Ready to See It in Action?

See how PGA works patient case queues and handoffs inside athenaOne

Schedule a Demo →

Written by Kevin Henrikson