Guide · Published Aug 10, 2026 · Updated Sep 2026

Fax Is Not a Workflow: Auth Submissions Without New Software

Yes, you still fax prior auths. No, that is not your problem. The channel you submit through, fax or portal, is not the same as the workflow that gets the authorization done. Fix the workflow, tracking, ownership, follow-up, and you fix prior auth, without buying a thing.

Fax and payer portals are submission channels, not workflows. A fax sends a request; it does nothing to track whether it was received, follow up on status, catch it before it expires, or ensure someone owns it to completion. Prior authorization is won or lost on the workflow around the channel, a tracked pipeline, a clear owner, and follow-up, which you can build in a tool you already have. Fix the workflow, not the channel, and skip the new software.

Ask a practice why prior auth is a mess and you will often hear "because we are still on fax." It feels like the answer, but it is not. Plenty of practices submit by fax and run prior auth smoothly, and plenty submit through slick portals and still lose authorizations constantly. The difference is not the channel. It is whether there is a workflow around the channel, and that is what actually determines whether prior auth works.

Channel versus workflow

The core confusion worth clearing up is between the channel and the workflow, because practices blame the first when the problem is the second. The channel is how you send a request to the payer: by fax, through a payer portal, or, increasingly, electronically. The workflow is everything that surrounds that submission and actually gets the authorization done: knowing what needs authorization, submitting it, tracking that it was received, following up on its status, catching it before it expires, working it if denied, and making sure someone owns each request to completion. These are entirely different things, and the mistake is treating the channel as if it were the workflow, believing that if only you had a better way to send requests, prior auth would be fixed. It would not, because the losses in prior auth, expired authorizations, lost requests, unworked denials, do not come from how the request was sent; they come from the absence of a system managing it after it was sent. A fax and a portal are both just ways to move the request; neither manages it. That is why upgrading the channel without building the workflow changes little, and why building the workflow fixes prior auth even on fax, the system laid out in the Zero-Slip guide.

What fax does not do

To see why the channel is not the system, look concretely at what a fax, or an untracked portal submission, does not do. It does not track whether the request was received or where it stands, so the request disappears into the payer with no visibility. It does not follow up, so a request that stalls or gets lost stays lost until someone happens to notice, often too late. It does not catch expirations, so an authorization obtained and then not used before its deadline lapses silently, the pure waste covered in the expirations guide. It does not assign ownership, so a faxed request belongs to no one after the fax goes through. And it does not work denials, so a denied request is not systematically appealed. Every one of these gaps is where authorizations are actually lost, and not one of them is solved by a nicer channel, because they are all about managing the request after submission, which the channel simply does not do. This is the same lesson as everywhere else in operations: the tool that moves the work is not the system that manages it, and the losses live in the management, not the movement. A portal that submits faster but still does not track, follow up, or assign ownership will lose authorizations just as a fax does, which is why practices that switch channels expecting relief so often do not get it.

The workflow that actually works

The fix is to build the workflow the channel lacks, and it is the same regardless of whether you submit by fax or portal. It has four parts. A tracked pipeline: every authorization request in one place with its status and deadline visible, so nothing disappears after submission, the front-desk-facing version in the front-desk PA workflow. A clear owner: a person accountable for each request through to completion, so no request belongs to no one. A follow-up cadence: a regular rhythm of checking pending requests and chasing anything stalled, so requests move rather than stall, the speed tactics in the speed-up guide. And expiration and denial handling: tracking deadlines so nothing lapses, and working denials so recoverable revenue is not abandoned, reducing preventable denials up front per the reduce-denials guide. That is the whole system, and notice that none of it specifies a channel: you can run every part of it while still faxing, because the pipeline, the owner, the follow-up, and the expiration tracking all live in your workflow, not in how the request is transmitted. Build these four around whatever channel you use, and prior auth works; skip them, and it does not, no matter how you submit.

Without new software

Here is the part that saves money: you can build this workflow in a tool you already have. Because the workflow is about tracking, ownership, and follow-up, not about a special submission technology, it can run in the project tool your practice already uses, a tracked pipeline in ClickUp, Monday, or Asana, or even a well-structured tracker, with owners assigned and a follow-up cadence built into the routine. The instinct when prior auth hurts is to buy prior authorization software, and vendors are glad to sell it, but most practices do not have a software gap; they have a workflow gap, and buying a tool without building the workflow just adds cost without fixing the losses. The right sequence is workflow first: build the tracking, ownership, and follow-up in a tool you have, prove it works, and only then consider whether software would make it more efficient, exactly the systems-before-software principle that runs through all of ClinicOps. A practice running a disciplined prior auth workflow on a basic tracker will lose far fewer authorizations than one with expensive software and no workflow discipline. So do not let "we need new software" be the reason prior auth stays broken; the fix is a workflow you can build now, and it costs nothing but the discipline to run it.

What CMS-0057-F changes

It is worth being straight about where the channel is genuinely heading, because it does change, just not in a way that removes the need for a workflow. The federal CMS-0057-F rule requires certain payers, Medicare Advantage, Medicaid and CHIP managed care, and qualified health plans on the federal exchanges, to implement electronic prior authorization APIs by January 1, 2027, which over time will make electronic submission smoother for those payers, detailed in the CMS-0057-F guide. That is real progress on the channel. But two caveats keep the workflow essential. First, the rule does not cover all payers, notably traditional Medicare and most commercial plans outside those categories, so fax and portals will remain in the mix for years. Second, and more fundamentally, even a perfect electronic channel still needs a workflow around it: an API that submits your request faster does not track it, own it, follow it up, or catch its expiration any more than a fax does, so the tracking, ownership, and follow-up discipline remains exactly as necessary. Better channels are coming for some payers, and they are welcome, but they do not change the lesson: the channel moves the request, the workflow gets it done, and the workflow is where you win or lose prior auth. Build it now, on the channels you have, and you are ready for the better ones when they arrive. Start with the prior authorization guide for the full picture.

Frequently asked questions