Closing a Patient Case: Reasons, Rules, and What Gets Measured

Closing a patient case is the last thing anybody does with it and the only thing that gets counted. In most multi-specialty groups the close is a single click with a default reason attached, which means the queue produces a clean report every month and almost no information about what actually happened.

The reason is structural. Staff close cases under time pressure, and the fastest available reason is the one that gets used. If the practice’s list is short and generic, every outcome collapses into the same bucket: resolved, completed, done.

So a case where the patient was reached and booked, a case where the patient was never reachable, and a case someone gave up on all look identical in the report. The queue clears, the metric looks healthy, and the practice has no way to tell the difference between work that finished and work that stopped.

The close reason is the only structured record of the outcome

Everything else about a case describes what it was. The close reason is the only field that describes how it ended.

athenaOne treats this as configuration rather than free text. The practice’s list of close reasons for patient cases is readable through GET /reference/documents/patientcase/closereasons, and the close itself runs through PUT /patients/{patientid}/documents/patientcase/{patientcaseid}/close. That means the taxonomy is something a group chooses, and choosing it badly is a decision rather than an accident.

A useful list separates outcomes that require different responses. Reached and resolved. Reached and declined. Unreachable after the agreed number of attempts. Duplicate of another case. Not actionable, because the underlying request was already handled elsewhere. Routed out, because it belonged to a different team entirely.

Those six describe six different management problems. Collapsed into one reason they describe nothing, and the monthly report becomes a volume count wearing the costume of a quality metric.

Reopen rate is the number that catches a premature close

A close reason records what someone said happened. A reopen records what actually happened.

athenaOne supports reopening a patient case, and the ratio between closes and reopens is the cheapest quality signal a front office has. A case closed on Monday and reopened Thursday because the patient called back was not resolved. It was cleared.

Watching that ratio by close reason is where it gets useful. A high reopen rate against resolved suggests the closes are optimistic. A high reopen rate against unreachable usually means the attempt policy is too short, or that the practice is calling one number when it has two.

This matters more once any of the work is automated, because the failure mode of an automation under a throughput target is exactly the same as a person’s under time pressure. It closes things. Building the reopen rate into the reporting from the start is what stops a queue-clearing metric from being gamed by whatever is doing the clearing, human or otherwise.

MGMA’s guidance on measuring front-office phone operations points at the same family of numbers: call abandonment, time to resolution, staff minutes per call, touches per request, and after-hours message backlogs. Every one of those describes whether the work finished rather than whether the queue emptied.

The complication: the case can close correctly and the outcome still be wrong

This is the failure that makes close-reason reporting look fine while money leaks somewhere else entirely.

At a multi-site pain practice, between 6% and 8% of procedures were being scheduled outside the prior-authorization window by human schedulers. Every one of those cases closed correctly. The patient was reached, the appointment was booked, the request was satisfied, and the close reason was accurate. The failure appeared weeks later at checkout, in a different department, attached to a different report.

That is the limit of close reasons as a quality system. They record whether the task was completed, not whether completing it that way produced a claim that survives. A practice measuring only its queue will keep reporting success while the consequence accumulates in accounts receivable.

The fix is to pair the close with the constraint the close was supposed to respect. A case that ends in a booking should record whether the booking landed inside the authorization window, whether the appointment type matched the request, and whether eligibility was verified against the date of service rather than the date of the call. Those are checks a system can run at the moment of close, which is the only moment where fixing it is still cheap.

The handoff is any close the checks cannot clear. A booking outside the authorization window should not close as completed and should not be silently rebooked. It goes to the person who owns authorizations, with the window, the booked date, and the gap stated. The point of automating the close is to make the exceptions visible on the day they happen rather than at billing.

Governance decides whether the taxonomy survives contact with staff

A well-designed close-reason list decays quickly if nobody owns it, and the decay is predictable.

Staff use the reason at the top of the list, the one they used last time, or the one that generates the fewest follow-up questions. Within a quarter the distribution collapses toward two or three values regardless of how many exist. That is not carelessness. It is a rational response to a list that is longer than the decision it supports.

So keep the list short enough that each value is genuinely distinguishable in the moment, and audit the distribution monthly. A reason that never gets used should be removed or explained. A reason carrying most of the volume should be split, because it is doing too much work.

This is the same governance question that decides whether automation helps. A Jan. 20 MGMA Stat poll found 42% of leaders said their organization has, or is developing, AI governance or a formal AI-use policy. MGMA’s own framing is that automation scales agreed-upon rules or it scales inconsistency, and a close-reason taxonomy is exactly the kind of agreed-upon rule that has to exist before anything can be scaled against it.

Write the definitions down. Two people should be able to look at the same case and pick the same reason, and if they cannot, the list is the problem rather than the people.

Report the outcomes, then report what they cost

Once close reasons carry real information, the reporting question changes from how much did we clear to what happened and what did it take.

The outcome mix is the first view. What share of cases end reached and resolved, versus unreachable, versus routed out. Movement in that mix is the earliest signal that something upstream changed, and it usually points at contact data or at intake quality rather than at the team working the queue.

Effort per outcome is the second. Touches and elapsed days by close reason, which is what tells you that unreachable cases are consuming four attempts each before anyone gives up. That number justifies changing the attempt policy or the channel, and no aggregate can produce it.

The third is the honest one: cases closed that reappeared as a different case within thirty days. Not a reopen, a new case for the same underlying request. That is where a practice discovers it is resolving the downstream effects of one broken upstream process over and over.

MGMA’s analysis of cost-cutting through automation makes the same argument from the finance side, noting that an automation which cannot point to the workflow improvement replacing the labor it removes is rarely cutting cost and is usually shifting it into overtime. A close-reason taxonomy that distinguishes real outcomes is how a practice proves which one it did.

Key Takeaways

Treat the close-reason list as a measurement design, not a dropdown. It is the only structured record of how a case ended.
Separate reached and resolved from unreachable and from routed out. Those are different management problems that a single completed value hides.
Track reopen rate by close reason. A case closed Monday and reopened Thursday was cleared, not resolved.
Build reopen rate into reporting before automating any of the closing. A throughput target pressures software the same way it pressures people.
Check the constraint at the moment of close. A correctly closed case can still have produced a booking outside the authorization window.
Escalate closes the checks cannot clear instead of silently rebooking them. The exception is cheap to fix on the day and expensive at billing.
Keep the list short enough that two people pick the same reason, and audit the distribution monthly. Unused values and overloaded values are both defects.
Report cases that reappear as a new case within thirty days. That number exposes a broken upstream process that the queue metric will never show.

Most front-office reporting measures whether the queue emptied, which is the one thing a practice can always achieve and the one thing that proves nothing. Close reasons are where that changes, because they are the only place the system records a difference between finishing work and stopping it. Getting the taxonomy right, checking constraints at the moment of close, and watching reopens is quiet work that makes every other number in the report trustworthy. An AI team working cases inside athenaOne can close against a real taxonomy, run the constraint checks before it closes anything, and escalate the cases that do not clear rather than clearing them.

Sources