Results Notification: Who Delivers a Normal Result, How Fast

Results notification is a volume problem wearing a safety problem’s clothes. The results that worry everyone are the rare ones. The results that consume the practice are the ordinary ones, arriving every day, each needing somebody to tell a patient that nothing needs to change.

Because the ordinary ones are low stakes individually, they get handled last, which is how a two-day turnaround becomes a two-week one. The patient sees the result in the portal long before anyone calls, decides the silence means something, and phones the practice. Now the practice is doing the work twice, on the patient’s schedule instead of its own.

The failure has been measured and it is not rare

Practices tend to treat missed notification as a hypothetical. The record says otherwise.

A review of more than 5,400 patient records across community and academic primary care practices found a 7.1% rate of failure to inform patients of clinically significant outpatient results, or to document having done so. Failure rates varied widely between practices, which is the encouraging part of the finding, because variation means process rather than fate.

The operative detail for an administrator is the second half of that phrase. Informing the patient and documenting that you informed them are one obligation, and a call that happened without a note is indistinguishable later from a call that never happened.

That is a records problem before it is a communication problem, and it is exactly the kind of work that degrades quietly when the people responsible are also covering the phones.

The line that keeps software out of the exam room

There is one rule that makes this workflow safe to automate, and everything else follows from it.

A clinician reviews the result and decides what the patient should be told. That decision, and the words attached to it, are produced by a licensed person. The automation delivers what was already approved, confirms it reached the patient, writes that fact back to the record, and books anything that needs booking.

So the automation never reads a value and decides it is fine. It never explains what a number means. It never reassures. When a patient asks a question about what the result means for them, the call captures the question and routes it to clinical staff, and the patient is told when to expect that call back.

This is a narrower job than it first appears, and narrower is the point. The delivery, the chasing, the documentation, and the scheduling are the bulk of the labor and none of it requires a license. Separating that bulk from the part that does is what lets a practice move faster without moving anything risky.

Inside athenaOne the anchors are the result document and the actions recorded against it. The document tells you what was released and by whom. The action history is what turns notified into a fact the practice can prove.

The complication: the patient already saw it

Immediate release changed the sequence, and most results workflows were designed before it did.

The patient now frequently reads the result in the portal before the practice has called, sometimes before the ordering provider has opened it. For normal results this is mostly fine and occasionally not, because normal is a clinical characterization and a patient reading raw values does not always arrive at it. The practice’s phone rings with questions about results nobody has called about yet.

A notification workflow built for the old sequence makes this worse by being slow. One built for the new sequence treats portal release as the starting gun rather than as the finish line, and gets the confirming contact out while the result is fresh.

The second complication is routing, and it is the one that quietly misdirects the callback. The primary provider field on the chart is stale in most practices, so routing a result callback by that field sends it to someone who has not seen the patient in years. The reliable signal is who actually saw the patient recently, which is visible in the appointment history and almost never in the field labeled for it.

The automation handles both mechanically. It works released results in order of release time rather than in order of arrival, and it routes by recent encounter rather than by the stale field, flagging the ambiguous ones for a person instead of guessing.

Speed targets that mean something

Most practices have no results turnaround target, and the ones that do usually measure the wrong end of it.

The useful clock starts when the clinician releases the result, not when the lab returned it. The practice does not control the second and fully controls the first, and mixing them produces a number nobody can act on.

Against that clock, three figures describe the operation. Median time from release to patient contact. The share of released results with a documented contact at all. And the tail, meaning the count sitting past a threshold the practice has chosen and can defend.

The tail is where the risk lives and it is almost always small in count and long in age. A handful of results from three weeks ago that nobody closed is a very different problem from a uniformly slow queue, and it needs a different fix. Averages hide this completely, which is why the distribution is worth more than the mean.

What to fix before buying anything

Two structural things determine whether any of this works, and both are inspectable this week.

The first is whether your practice has agreed on what gets a call, what gets a message, and what gets a booked visit. Where that agreement does not exist, every result becomes a small decision, and small decisions at volume are what create the backlog in the first place. Written rules by result category turn most of the queue into routing.

The second is whether a completed notification is recorded consistently enough to be counted. If half the calls are documented in a note, some in a phone message, and some not at all, the practice cannot measure the thing it is trying to improve and cannot demonstrate it later.

Neither of those requires software. Both make software worth having, because an automation that delivers what a clinician approved and writes back a consistent record is only useful if the practice knows what it wants delivered and what it wants written.

Key Takeaways

Keep the review with the clinician and automate only the delivery. A licensed person decides what the patient is told; the automation delivers it, confirms receipt, documents it, and books what needs booking.
Start the turnaround clock at clinician release, not at lab return. You control the first and cannot control the second.
Treat portal release as the starting gun. Patients read results before the call, so a slow workflow generates inbound volume instead of preventing it.
Route callbacks by recent encounter rather than the primary provider field, which is stale in most practices and will misdirect the call.
Report the tail of overdue results, not the average age. A few very old open results is a different problem from a uniformly slow queue.
Write down what gets a call, a message, or a visit by result category before automating. Undefined rules are what turn routine results into a backlog.

Normal results are the largest single category of communication a primary care practice owes its patients, and the least interesting to work, which is why they pile up. An AI team can deliver what the clinician released, chase the patients who did not answer, route the questions to the people licensed to answer them, and leave a documented trail behind every one. The clinical part stays exactly where it is. Start by pulling the count of released results with no documented patient contact.

Sources