Nobody's Job

Here's a way to lose money that requires nobody to make a mistake.

A resident at a nursing facility needs a drug. The order goes from the facility's EHR to the pharmacy, the pharmacy bills the payer, and the payer answers in real time. Usually it pays.

Sometimes it rejects, because the drug needs prior authorization. When that happens, the pharmacy's system moves the charge onto the facility's account, which clears the pharmacy's billing queue. The drug ships. The resident gets their medication on schedule.

Nobody is harmed. Nobody is inconvenienced. And the facility has started paying for a drug the payer would probably have covered.

Notice of this goes out as a fax, or a line in a pharmacy web portal. Nobody at the facility reads the fax, because facilities get hundreds of them. Nobody opens the portal, because working that queue isn't anyone's assignment.

That's the whole thing. Every party did exactly what it was supposed to do. The pharmacy cleared its queue, which is correct. The payer applied its criteria, which is correct. The drug went out on time, which is the thing you'd most want to protect. There's no villain here and no mistake, and the money left anyway.

We're organized around failures that hurt someone. Those have departments, and reporting requirements, and people whose entire job is to notice them. There's no equivalent anywhere for a failure that hurts nobody in particular and turns up six weeks later as a slightly bigger invoice.

And fixing it isn't hard, which is the part that bothers me. Getting the money back means filing a prior authorization, and filing a prior authorization is paperwork. It's just paperwork spread across seven people who don't work for each other.

Somebody has to see the rejection. Somebody has to pull the diagnosis codes and clinical notes and med history out of the chart. For Medicaid drug programs the authorization gets filed by the pharmacy or the prescriber, so the facility can't file it even if it wants to. It assembles the packet and asks the pharmacy to submit, and the pharmacy's billing staff are in no hurry, because they're already being paid. Some of these need the prescriber to sign, and medical directors are hard to get on the phone. Then the payer reviews it, which takes a day or two once the packet is complete.

Look down that list and you'll notice every step has somebody whose job it is, except two.

The first is the one we started with. The rejection arrives as a fax and a portal line, and no person is assigned to either. That one unowned step creates the entire pool of money we're talking about.

It's worse than unassigned. When a facility does think to ask, the answer it gets is usually that everything was approved. Rejection codes don't survive the trip. So the one channel that could tell you what happened is operated by the party with the least reason to be precise about it.

The second is better. Say everything goes right and the payer approves the authorization. Nothing happens. Approval doesn't move money. Somebody at the pharmacy still has to reverse the charge, rebill the payer, and post a credit on a future statement, and no system anywhere triggers that. So a facility can do all of the work, win, and still not get paid, because winning and getting paid are separate events and the second one has no owner either.

There's a second-order effect here I didn't expect. Compare notes across buildings and you find the rules themselves bend. Pharmacies apply prior authorization requirements inconsistently, and how strictly they apply them tracks how much a given administrator pushes back. Which makes sense once you see it. If almost nobody pushes, then pushing is an exception you handle case by case instead of a policy you write down. The buildings that ask get treated differently from the buildings that don't, and most don't ask.

The leverage to push with is usually already sitting there. The clause obliging the pharmacy to submit on request tends to be in the contract. The contracts are old and nobody has read them.

Underneath all of it is an incentive structure that points the wrong way at every step. Losing the money is free. No decisions, no work, same day. Getting it back takes five handoffs across four organizations, and exactly one of the parties involved has any money at stake.

The pharmacy is already being paid, so filing the authorization is work with no upside, and reversing the charge later is work that moves money out of its own pocket. The prescriber gets nothing for signing. The payer does better if it's never filed at all. And the facility, the only party that loses anything, is the one that can't file it.

Once you have this shape in your head you start seeing it everywhere. Coverage that never gets verified before an admission. A Medicaid application sitting in a county queue. A discharge that stalls while two organizations each wait on the other. Money sitting in a contract nobody has read. Walk into one building and you can usually find several of these running at the same time, each worth real money, none of them anybody's job. Everyone involved is competent inside their own walls and carries no responsibility past them.

There's a structural reason for that, and it has to do with who buys software.

Every system in that chain was bought by one organization to make that organization's work easier. The pharmacy's dispensing system exists to get drugs out the door and keep its billing clean. The payer's adjudication engine exists to apply the payer's rules quickly. The facility's EHR exists to run the facility. Each one is good at its job. Shifting the rejected charge onto the facility is the pharmacy's system doing its job well.

Software follows the org chart, because org charts are what sign the checks. The work in the gaps has never had anyone to buy software for it, because there's no organization standing in the gap. It's nobody's job, so there's no budget line, so there's no product, so it stays nobody's job.

That explains why nobody built it. There's a second reason nobody could.

Every individual step here is trivial. Reading a rejection off a portal is trivial. Pulling notes out of a chart is trivial. Sending an email with a contract clause in it is trivial. We've been able to do all of those for twenty years.

What software has never been able to do is care about something for three months.

Three months is roughly what this takes. There's maybe two hours of actual work in it. Everything else is waiting. A fax sits in a tray. A prescriber doesn't call back. The payer takes 48 hours. The retro billing window runs up to a year, and the credit turns up on some future statement whenever the pharmacy gets to it.

That's an odd shape for a problem, and it's why this work has stayed manual. Two hours of effort spread over ninety days, with the thread dropping every few days. People are bad at that for obvious reasons. You can't hold four hundred open threads in your head, and the ones you drop don't announce themselves. Software was bad at it for a different reason. Nothing was ever durable enough to still be working your case in week nine.

That's the thing we're building. You hand Kaigo a case and it holds the thread until the case is finished. For a rejected pharmacy claim, finished means a credit posted on a statement. Filing the authorization is a step along the way.

So it reads the rejection off the portal, which is the step that currently doesn't happen at all. It pulls the documentation. It drafts the packet and the request to the pharmacy with the contract language cited, then hands that to someone at the facility to send, because that message should have a human name on it. It tracks the review. When approval comes back it stays on the case, watching statements and pushing the pharmacy until the credit actually posts.

The rule we hold it to is that it comes back with one of two things. The outcome, verified. Or one specific decision that needs a person, named. It doesn't come back with a summary of its efforts.

There are places in this chain where a person is the right answer and we aren't trying to design them out. A prescriber has to sign. Somebody has to decide how hard to push on a denial when the facility depends on that same pharmacy for tomorrow's delivery. Kaigo drafts, a human sends.

Calling and reading and writing are commodities now, and getting cheaper every quarter. What's left is all the specific stuff. Knowing that for this pharmacy the portal is where rejections really land and the fax is decorative. Knowing where in this contract the clause sits that says they'll submit on request. Knowing which prescribers sign and which ones you route around. Knowing that an authorization isn't finished until a credit posts. None of that lives in a model. It shows up one case at a time.

We'll know whether it works by looking at a statement. Either the credit posted or it didn't. I'd rather be measured on that than on hours saved, which is the easiest number to claim and the least interesting one. And if it turns out we can only make it work at facilities where we've hand-tuned everything, then we've built a consulting business with a model attached, and we'll find that out quickly.

The pharmacy part is almost incidental. That rejection is sitting in a fax tray right now, in that building and in every building like it, and nobody involved is doing anything wrong. There's no mistake to find and nobody to call about it. It's just nobody's job.