A small practice tracks prior authorizations by logging every request in one shared queue with the patient, payer, service, codes, date submitted, reference number and status, then following up on a fixed schedule until a decision arrives and recording the approval number and dates. Denials move to an appeal step with their own deadline, and nothing is scheduled until the authorization is approved and in date.
A small practice tracks prior authorizations by putting every request in one shared queue, with the patient, payer, ordering provider, requested service, codes, date submitted, payer reference number and a status, then following up on a set date until a decision comes back. Approvals get their authorization number, approved units and start and end dates recorded, and the visit or procedure is not booked as final until the authorization is approved and in date. Denials move to an appeal step with their own deadline and owner. The goal is simple: no patient arrives for care that has not been approved, and no request sits pending because everyone assumed someone else called.
Most small practices run this today on a mix of payer portals, fax confirmations, sticky notes, a spreadsheet and memory. Each payer works differently, and the person who knows which ones need a phone call is usually the one on vacation when the problem comes up.
What slips without a tracker
- Requests go quiet. Submitted, never followed up, still pending the day before the appointment.
- Approvals expire unnoticed. An authorization good for 90 days or 12 visits runs out partway through a course of care.
- Denials miss appeal windows. The letter arrives, gets filed, and the deadline passes.
- Front desk and billing work from different lists. Scheduling books a visit that billing knows is not yet approved.
- Status questions eat the day. Patients, providers and staff all ask "is it approved yet?" Asana's Anatomy of Work research reports that workers spend 60% of their time on "work about work," such as chasing status. A prior authorization queue is mostly that.
What the tracker should contain
The request
- Patient (name, date of birth, internal patient number).
- Payer and plan, and member ID.
- Ordering provider.
- Requested service, procedure, test, equipment or medication.
- Diagnosis and procedure codes, as your billing team uses them.
- Number of visits or units requested.
- Planned date of service, if booked.
- Urgency: routine or urgent.
- How it was submitted: portal, phone, fax.
- Date submitted and payer reference number.
- Supporting documents attached, such as clinical notes sent.
- Assigned staff member.
- Next follow-up date.
The decision
- Decision: approved, partly approved, denied, or no authorization required.
- Authorization number.
- Approved units or visits, and how many have been used.
- Start and end dates.
- Conditions or limits.
- Decision date and how it arrived.
Denials and appeals
- Denial reason, as stated by the payer.
- Appeal deadline.
- Appeal owner.
- Steps taken: peer-to-peer requested, additional records sent, appeal submitted.
- Outcome and date.
Statuses at a glance
| Status | What it means | What happens next |
|---|---|---|
| Needed | Provider ordered a service that requires authorization | Assigned staff member prepares the request |
| Submitted | Sent to the payer | Follow-up date is set |
| Pending, info requested | Payer asked for more records | Clinical team is alerted with a due date |
| Approved | Authorization number received | Front desk can book or confirm; dates and units tracked |
| Partly approved | Fewer units or a different service approved | Provider is told; plan of care may change |
| Denied | Payer declined | Moves to appeal review with a deadline |
| Appeal in progress | Appeal submitted | Follow-up on the appeal date |
| Expiring or used up | End date near or units nearly used | Renewal request starts |
| Closed | Care complete or request withdrawn | Kept for history |
Follow-up rules
The follow-up date is the heart of the tracker.
- Every submitted request gets a follow-up date. No exceptions.
- The date depends on the payer and urgency. Note in each payer's record how quickly they usually respond, and set the date from that.
- Overdue follow-ups go to the top. The assigned person sees them first thing; the practice manager sees any that are two days late.
- Each follow-up is logged. Who called or checked, what the payer said, and the next date.
- Appointments drive urgency. Any request still pending within five business days of a booked date is flagged to the practice manager.
Roles
- Authorization coordinators work the queue: submit, follow up, record decisions and appeals.
- Front desk sees whether a patient's upcoming visit is approved, with dates and remaining visits, but not the clinical documents.
- Providers see requests they ordered, respond to information requests and peer-to-peer calls.
- Billing sees decisions and authorization numbers for claims.
- Practice manager sees everything, including overdue and denial reports.
Patient details are sensitive. Health privacy laws such as HIPAA in the United States set obligations for anyone handling patient information and for the vendors who store it, and your compliance advisor decides what applies to your practice. Whatever tool you use, the access rules have to be real. Broken access control, where people can reach records they should not, tops the OWASP list of web application risks. In May 2026, Axios reported on research that found AI-built apps and pages exposing sensitive data, including hospital patient summaries, and in 2021 UpGuard found 38 million records exposed across 47 Microsoft Power Apps portals. A prior authorization queue should never be a link anyone can open.
Connect it to scheduling
Two rules prevent most surprises:
- The schedule shows authorization status next to every visit that needs one: approved with dates and visits left, pending, or denied.
- Visits beyond the approved count or end date are flagged before the patient is booked, so renewal starts in time.
Reports
- Pending by age: how long each open request has been waiting, by payer.
- Overdue follow-ups by staff member.
- Upcoming visits without approval in the next two weeks.
- Authorizations expiring or nearly used in the next 30 days.
- Denials by payer and reason, which shows where requests need better documentation.
- Appeal outcomes, so you know which appeals are worth the effort.
Questions to settle before you build
- Which services and payers need authorization? Start with the ones that cause the most trouble.
- Who owns the queue, and who is the backup?
- How much clinical detail belongs in the tracker, and how much stays in your records system? Keep only what the work needs.
- Who can open attached documents?
- What are your appeal steps, and who decides whether to appeal?
Example request
Example request: "Build a prior authorization tracker for our four-provider physical therapy practice. Each request has patient name, date of birth, patient number, payer, plan, member ID, ordering provider, requested service, diagnosis code, procedure codes, visits requested, planned start date, urgency, how it was submitted, date submitted, payer reference number, attached documents, assigned coordinator and next follow-up date. Statuses are needed, submitted, pending info requested, approved, partly approved, denied, appeal in progress, expiring and closed. Approvals record authorization number, approved visits, visits used, start date and end date. Denials record reason, appeal deadline, appeal owner and outcome. Every submitted request must have a follow-up date; show overdue follow-ups at the top of each coordinator's list, and alert the practice manager when one is two days late. Flag any request still pending within five business days of a booked visit, and any authorization within 30 days of its end date or with two or fewer visits left. Front desk sees approval status, dates and visits left but not attached documents. Providers see requests they ordered. Coordinators and the practice manager see everything. Roles are practice manager, coordinator, provider, front desk and billing. Only invited people can sign in."
How to roll it out
- Start with your highest-volume payer or the service that causes the most denials.
- Load every open request from the current spreadsheet or notes, with a follow-up date on each.
- Run it for two weeks with the coordinators only.
- Add front desk once statuses are reliable.
- Add providers for information requests and peer-to-peer calls.
- Review the denial report monthly and fix documentation patterns.
Mistakes to avoid
- No follow-up date. The request without one is the one that stalls.
- Tracking approvals but not their limits. Dates and visit counts run out.
- Too much clinical detail. Keep the tracker to what the authorization work needs.
- Everyone sees everything. Front desk does not need clinical documents to know a visit is approved.
- Filing denials instead of working them. Every denial gets an appeal decision and a deadline.
How to measure that it works
Compare with the three months before launch:
- Visits rescheduled or written off for missing authorization.
- Average days from submission to decision, by payer.
- Requests pending past their follow-up date.
- Denial rate by payer, and appeal success rate.
- Time the front desk spends answering "is it approved?"
How FORGE handles it
On FORGE, your practice manager describes the tracker in plain words, much like the example above, and FORGE builds it. A panel of top AI models plans the tool, a dedicated AI crew builds it, and every piece is checked for quality and security before it is saved. Most teams have their first real tool the same day.
Every app lives inside your company and anyone outside it gets nothing back. People join only by invite, and coordinators, front desk, providers and billing each see what their role allows, with a complete record of who did what, which is the kind of record your compliance advisor will ask about. Staff who only use the tracker are $10 a user a month, builders are $49 a seat a month with 3 builds included, and adding a new payer rule later is a small fraction of a build. Our team onboards every practice ourselves, starting with a workflow workshop, and your compliance advisor is welcome to join. Read our security page or talk to us.
Questions people ask
What is a prior authorization?
A prior authorization is approval a health plan requires before it will cover certain services, procedures, tests, equipment or medications. Without it, the plan may deny the claim even if the care was needed.
Who in a small practice should own prior authorizations?
One named person, often a billing coordinator or front office lead, with a trained backup. Ownership matters more than the tool: requests stall when everyone assumes someone else is following up.
How often should we follow up on a pending authorization?
Set a follow-up date when you submit, based on how quickly that payer usually responds, and follow up on that date every time. A request with no follow-up date is the one that is still pending the day before the appointment.
What should we record when an authorization is approved?
The authorization number, the approved service and codes, the number of visits or units approved, the start and end dates, and any conditions. Then check those details again before each visit, because authorizations expire and visit counts run out.
Can we track prior authorizations in a spreadsheet?
Many practices start there. A spreadsheet has no reminders, no roles, no record of who changed what, and it is easy to share too widely. Once more than one person works the queue, a shared tracker with follow-up dates and access rules is safer and faster.
Can FORGE build a prior authorization tracker?
Yes. Your practice manager describes the queue in plain words and FORGE builds it, with roles so each person sees only what they need and a complete record of who did what. Your compliance advisor is welcome in the onboarding workshop.
See what FORGE builds for your team
We onboard every team ourselves, starting with the work that costs you the most time.
Talk to us
