Someone on your team is on hold with a payer right now. A procedure is booked for Thursday, the authorization still is not back, and the patient has already called twice to ask whether it is really happening. In another corner of the office, a claim from three weeks ago just came back denied for missing documentation that was sitting in the chart the whole time. Neither of these is a payer problem you can argue your way out of. Both are workflow problems, and both cost you staff time and cash.
Prior authorization and claims look like paperwork from the outside. From inside a practice or a revenue cycle team, they are a coordination job. Every request has to move from a clinical need to a payer decision with the right evidence attached, a clear owner, a visible status, and a next follow-up date. When that job is organized, delays shrink and staff stop chasing. When it is not, the work hides in portals and inboxes until a deadline or a denial forces it back into view.
This guide is written for the person who owns that work: a practice manager, a revenue cycle lead, a billing manager, or a founder running a growing provider group. It stays on the administrative side of the job. Deciding medical necessity, writing the clinical part of an appeal, or making a coding call belongs to clinicians and certified coders. Everything around those decisions, from assembling the packet to tracking status to capturing why a denial happened and getting the next action to the right person, is where most of the lost time actually lives.
Start with the one delay everyone already complains about
You do not need a program to fix prior authorization and claims. You need one delay pattern that everybody in the office already recognizes, and you need to fix that one first.
It is usually specific. A high-volume procedure that keeps getting delayed while staff chase the authorization. One payer whose portal nobody trusts. One denial reason that shows up again and again and forces the same rework every month. A referral type where the note is never ready in time. Pick the pattern that costs you the most in staff hours, patient frustration, or delayed cash, and make that your first target. It should be narrow enough to draw on one page and painful enough that fixing it changes something you can feel.
Trying to redesign the whole revenue cycle at once is how these projects stall. The point of starting small is not caution for its own sake. It is that a narrow problem gives you a real workflow to look at instead of a general complaint about payers.
Name the real job behind authorization and claims
A useful workflow answers five plain questions for every request. What is being requested or billed? What does this payer require for it? What evidence supports that? Where is it right now? And what happens next if it is approved, still pending, denied, or headed for appeal?
That job is bigger than a task list. It runs from eligibility check and requirement lookup, through evidence assembly and submission, to payer response, status follow-up, denial handling, appeal preparation, and the patient or clinic update along the way. Most practices do all of this. The problem is that the steps are split across the EHR, payer portals, the clearinghouse, spreadsheets, email, and phone calls, so no single person can see the whole request without opening four systems and making a call.
The fix is not to replace those systems. It is to give the work one place where its status is visible even though the source systems stay where they are. A request should never be lost simply because the only record of it was in someone's memory of a portal they checked on Tuesday.
Map how the work moves before you change it
Before you buy anything or automate anything, trace one request from the moment it is triggered to the moment it is paid or written off. Who starts it? Where is eligibility checked? How is the payer requirement looked up? Who pulls the evidence? Who submits? How is status watched? Who reads the denial code? Who prepares the appeal or the resubmission?
When you draw this out honestly, the gaps show themselves. Usually there is a point where the request goes quiet because the only way to know its status is for a specific person to log into a specific portal, and that person is busy. There is another point where evidence that already exists in the chart is requested again because nobody knew it was there. And there is almost always a denial that repeats because the reason was fixed on one claim but never fed back into how the packet gets built.
You are looking for those three things: where status goes invisible, where evidence gets re-gathered, and where the same denial keeps happening. Those are the parts worth fixing first.
Give every request a status you can actually see
The single most useful thing you can add is a shared worklist where every authorization and claim carries a status that means something. Not a folder of open items, but a set of stages that tell you what has to be true before a request moves forward and who owns it while it sits there.
| Stage | What it means | What has to be true before it moves | Who owns it |
|---|---|---|---|
| Triggered | An order, referral, or scheduled service has created work | The service, payer, and patient are identified | Scheduling |
| Requirements known | You know what this payer needs for this service | Plan, code, policy, and required documents are looked up | Authorization specialist |
| Evidence incomplete | Something the packet needs is missing | The missing note, result, or order is assigned to a person | Auth specialist and clinic |
| Ready to submit | The packet is complete and checked | A second set of eyes confirms nothing is missing | Authorization specialist |
| Submitted | The request is with the payer | A reference number is recorded on the request | Authorization specialist |
| Pending | You are waiting on the payer | A follow-up date and owner are set, not left open | Authorization specialist |
| Decided | Approved, denied, or appealed | The outcome and its reason are written down in a form you can count | Billing and revenue cycle |
The reason this matters is simple. A status model turns invisible waiting into managed work. Once every request sits in a named stage with an owner and a follow-up date, you can see at a glance which delays are yours to fix, which are the payer's, which are about missing documentation, and which are about coding. That distinction is what tells you where to spend effort.
A worked example: 300 prior authorizations a month
Here is an invented example to make the shape concrete. Treat the numbers as illustration, not a benchmark. A specialty cardiology practice submits around 300 prior authorizations a month across four main payers. Most go through without drama. But roughly one in six comes back with a request for more information, and a handful each week are performed before the authorization lands because the schedule would not hold.
When the office looks at a month of these, the pattern is not random. About forty of the delayed requests trace to one imaging procedure with one payer, and the reason is almost always the same: the medical necessity form is submitted without the most recent clinic note attached, so the payer asks for it, and the request sits for another four days. On the claims side, a cluster of denials all carry the same code, and when someone finally lines them up, they are all cases where the service happened before the authorization number came back and the number was never added to the claim.
Nothing here needs a new platform to fix. It needs the imaging procedure to have a defined packet that will not be marked ready to submit until the current note is attached, and it needs the schedule and the billing side to share one field for the authorization number so a claim cannot go out without it. Two narrow changes, aimed at the two patterns that were actually costing the practice money and patient goodwill.
Where prior authorization and claims actually break
The breakpoints are predictable. They look slightly different in every office, but the underlying failures repeat.
Eligibility is checked too late, or not at all
When coverage and plan detail are not confirmed at booking, the office finds out at the worst possible time: after the service, when the claim is denied as non-covered. Moving the eligibility check to the front of the process removes a whole category of downstream denials.
The payer requirement is out of date
Payer rules change, and a packet built from last quarter's requirement gets bounced. If nobody owns keeping the requirement current for your top procedures, staff keep submitting to a rule that no longer applies.
Evidence is assembled at the last minute
The note, the prior imaging, the lab, the treatment history: these usually exist somewhere in the chart, but they get gathered under deadline pressure. Late assembly is how the wrong version gets attached, or a piece gets forgotten, or the request goes out thin.
Requests go out incomplete to hit a deadline
When the schedule will not wait, staff submit what they have rather than what the payer needs. It feels like progress and it is not. An incomplete request comes back as a request for more information, which is slower than holding it one day and sending it complete.
Status disappears into the portal
A submitted request with no follow-up date is a request nobody is watching. It resurfaces when the patient calls or the deadline hits. Every pending item needs a date and an owner, or it goes quiet.
Denials get worked one at a time
Working denials case by case keeps the office busy and teaches it nothing. The same reason keeps recurring because the fix is applied to one claim and never fed back into how the packet is built. A denial reason that shows up twelve times in a month is a process signal, not twelve separate chores.
Every appeal starts from a blank page
When there is no assembled record of what was submitted and why it was denied, each appeal is rebuilt from scratch. Much of an appeal packet is administrative assembly that can be prepared in advance, leaving the clinician only the clinical judgment to add.
Nobody counts why claims stall
If denial reasons are not captured in a countable form, the office cannot see its own patterns. The most expensive habit in the whole workflow is solving the same problem repeatedly without ever measuring it.
Define the required evidence before you automate anything
For the one procedure or claim type you chose, write down the required evidence in plain language. What note, diagnosis, order, lab, imaging result, prior treatment, or medical necessity statement does the payer actually require? Which fields must be present before the request can go out? Who checks the packet, and what exactly counts as ready to submit?
This is unglamorous and it is the part that pays off. A defined packet and a clear ready-to-submit rule is what lets you stop requests going out thin, and it is the thing any automation later has to attach to. If you cannot describe when a packet is complete, no tool can enforce it for you.
The same discipline applies to denials. Every denial and every rework event should record the reason, the missing item, the payer response, the owner, and the final outcome, in fields you can count later. Without that, the office keeps rediscovering the same problem one case at a time.
Fit the data and systems to the work
You do not need to centralize everything. You need to decide, for each question the workflow asks, which system holds the trusted answer. The systems are usually already in place: the EHR, scheduling, practice management, eligibility tools, payer portals, the clearinghouse, document storage, coding tools, and patient communication. The job is to name the source of truth for status and the source of truth for evidence, then keep a short, practical set of fields moving between them.
| Question | Data you need | Likely source of truth | Owner |
|---|---|---|---|
| What was requested or billed? | Patient, payer, plan, service, procedure code, ordering clinician | EHR and scheduling | Scheduling |
| What does the payer require? | Policy, required documents, submission portal, current rule | Payer portal and policy lookup | Authorization specialist |
| Is the evidence there? | Clinical note, prior treatment, imaging, lab, necessity statement | EHR and document store | Auth specialist and clinic |
| Where is it now? | Reference number, status, last checked, next follow-up date | Shared authorization worklist | Authorization specialist |
| Why was it denied? | Denial code, plain reason, missing item | Clearinghouse and payer remittance | Billing |
| Did it get paid? | Claim status, paid amount, days in accounts receivable | Practice management and clearinghouse | Billing |
Writeback is the part that saves time. When a missing note is found, it should create a task for the right person rather than a note in someone's head. When a payer response changes status, the shared worklist should update without waiting for a staffer to remember a portal check. When a denial reason repeats, it should inform how the packet is built next time. The goal is not a perfect data model. It is enough shared truth to support the next decision and stop the repeated chasing.
The claim does not end when you hit submit
Prior authorization gets most of the attention because it delays care visibly, but the claims side is where a lot of the money quietly leaks. A clean claim, one that passes the payer's checks the first time, is the difference between getting paid in a normal cycle and starting a rework that can run for weeks.
Scrubbing before submission is where you catch the avoidable problems: a service billed without the authorization number attached, a code or modifier that conflicts with what was authorized, an eligibility detail that changed. The same denial patterns you see on the authorization side show up again here, which is why capturing reasons in a countable form matters so much.
| Common denial reason | What it usually points to (administrative) | Who acts first |
|---|---|---|
| Missing or insufficient documentation | The packet went out before the note or result was attached | Auth specialist and clinic |
| No prior authorization on file | The service ran before authorization returned, or the number never made it onto the claim | Scheduling and billing |
| Service not covered | Eligibility or plan detail was not confirmed at booking | Front desk and eligibility |
| Coding or modifier mismatch | Scrubbing did not catch a code that conflicts with the authorization | Certified coder |
| Timely filing | The claim sat in a queue past the payer's window | Billing lead |
The revenue impact is worth naming plainly, because it is what makes this worth a leader's attention. Every request that stalls adds days to your accounts receivable, and a denial that is not worked before the timely-filing window closes is not a delay, it is a write-off. Reducing the share of requests that stall, and catching more claims before they go out, moves cash timing and reduces the money you simply never collect. That is the case for doing this, stated without dressing it up.
Put AI inside the assembly and review steps
AI earns its place in this workflow when it does the gathering and drafting that eats staff time, and stays out of the decisions that require a license. It can summarize the chart context behind a request, suggest which evidence the payer will likely want, draft an evidence checklist, extract the denial reason from a remittance, prepare a first-pass appeal outline, compare a case with similar prior ones, and write a plain-language status note for staff to check. Each of those shortens assembly and makes the worklist easier to read.
What it should not do is decide medical necessity, submit anything without review, override a payer rule, finalize coding, or send a patient-facing message on its own. The workflow should keep the source references, the model's output, the reviewer's edits, and the final submitted content, so anyone can see why a case was marked ready or incomplete. The safe pattern is narrow: AI gathers, summarizes, and flags; people approve the clinical content, the coding, the submission, the appeal language, and anything a patient will read.
Where staff judgment has to stay human
These are not just records moving through a queue. They affect whether a patient gets care on time, whether the practice gets paid, and whether the office stays on the right side of payer and privacy rules. So people still decide the things that carry consequence: whether the clinical evidence genuinely supports the request, whether a denial is worth appealing or better resubmitted, how a coding question resolves, and what a patient is told about a delay. Patient information stays inside your approved systems throughout. The workflow's job is to remove the copying, searching, and chasing so that judgment is spent on the cases that need it, not on hunting for a status.
What the worklist looks like in practice
When it is working, a single view tells you what is stuck, why, who owns it, and what happens next. It reads less like a report and more like a short list of the day's real decisions.
| Case | Status signal | Owner | Next action |
|---|---|---|---|
| MRI prior authorization, Payer A | Clinical note attached; medical necessity form still missing | Authorization specialist | Request the form from the clinic before the submission cutoff |
| Denied claim, procedure group B | Same denial reason on 12 claims this month | Billing lead | Take the pattern and the payer rule to the clinical owner before more claims go out |
| Appeal packet, Patient C | Draft summary assembled; source documents need clinician sign-off | Revenue cycle | Send to the reviewing clinician and update the patient status message |
None of these rows require a new system to exist. They require a shared place where status, owner, and next action live together instead of scattered across a portal, an inbox, and someone's recollection.
Ship the first month slice
Keep the first month narrow. Choose one high-volume or high-cost pattern, such as a single payer and procedure group, or the one denial reason that creates the most repeated rework, and work it end to end.
- Pull a month of recent cases and sort them by why they were delayed, denied, or reworked.
- Trace the current handoffs from trigger to paid or written off, and mark where status goes invisible.
- Write the evidence checklist and the ready-to-submit rule for that one pattern.
- Stand up a shared worklist with owner, status, follow-up date, missing evidence, and outcome fields.
- Run one weekly review of pending, denied, appealed, and resubmitted cases.
- Add AI for evidence summaries or denial-reason extraction once the review rules are clear, not before.
- Measure avoidable rework, time in each status, the repeating denial reasons, staff touches, and patient status calls.
By the end of the month you should have a cleaner queue for that one pattern and, more importantly, a repeatable way to learn from the denials and missing evidence instead of re-solving them.
How Ubisar would implement this workflow
In week 1, Ubisar would pick one payer, procedure group, or denial pattern with you and trace how a request moves today from trigger to submission, denial, appeal, or closure. The first thing we would leave you with is a working authorization and claims worklist: evidence checklist, payer requirement, missing item, owner, follow-up date, patient impact, next action, and final outcome, all in one place.
In weeks 2 and 3, we would connect the minimum EHR, scheduling, payer portal, billing, document, and denial data needed to keep that worklist current, keeping patient information inside your approved systems. AI would help summarize evidence, pull denial reasons, and prepare reviewer notes, while your clinical and revenue cycle owners approve every submission and appeal. By week 4, the aim is a cleaner queue and a review your team can repeat on its own.
At the end of month one, keep going if delays, missing evidence, and repeat denials are surfacing earlier and getting fixed; narrow or stop if the workflow cannot yet separate payer rules from clinical evidence from staff ownership. This is one focused month inside AI, Data & Tech Implementation. If prior authorization or claims is the thing slowing you down right now, tell us the pattern and we will map the first month with you.
Use the related Ubisar resources
For sector context, start with the healthcare workflow page. To see how this compares with other provider workflows, browse the workflow guide library. If you are still deciding what to fix first, read how to choose the first workflow to improve with AI.
For the business case, use the manual work cost guide and the implementation cost guide. If you are weighing outside help, read the consultant, agency, and software comparison. To gauge where your data stands, try the AI readiness assessment.
Sources and useful references
Useful references include the CMS interoperability and prior authorization final rule at cms.gov, CMS burden reduction material at cms.gov/priorities/key-initiatives/burden-reduction, and AMA prior authorization resources at ama-assn.org. Use them to frame the payer requirements and rules, then design the workflow around your own payer mix and clinical setup.