A prior authorization request is submitted. What follows is a follow-up call to check status, a documentation request that needs a response, a payer contact that needs to be logged, and an approval that needs to be confirmed before the service is scheduled. The EHR and billing platform have primary jobs elsewhere. Managing the operational work of prior authorization after submission is not one of them.
Prior authorization is one example of the operational work healthcare teams manage alongside their clinical and financial systems.
When billing teams track it in spreadsheets, the spreadsheet holds submission dates, payer names, and current status. The harder problem is what needs to happen next: which authorizations are past the follow-up threshold, who is responsible for each one, what the last payer contact said, and what the next step is.
A prior authorization tracking system's primary job is not to record that a request was submitted. It is to manage everything that happens after submission, so no pending authorization sits without an owner, a next action, and a visible timeline.
Prior authorization is not a single event. It is a workflow that begins at submission and ends when the authorization reaches a terminal state: approved, denied, appealed and resolved, or withdrawn.
Submission. The authorization request goes to the payer with clinical documentation, procedure codes, diagnosis codes, and treating provider information. Submission channels vary by payer: some accept portal submissions, some require phone or fax, some accept electronic transactions. The submission date and channel need to be recorded. A request submitted by fax and a request submitted through a portal have different confirmation paths and different follow-up implications.
Payer acknowledgment and reference identifier. Many payers assign a reference or tracking number when a prior authorization request is received. When one is issued, that identifier becomes the primary reference for every subsequent contact. A billing team that records the reference number at submission eliminates the need to reconstruct patient demographics and procedure details on every follow-up call. Without it, each contact starts from scratch.
Pending status and decision window. After submission, the authorization enters a pending state. For Medicare Advantage plans and Medicaid managed care organizations, CMS regulations effective January 2026 require payers to issue standard authorization decisions within seven calendar days and expedited decisions within 72 hours. [CMS-0057-F, cms.gov] These requirements apply to those specific plan types and generally exclude drugs. Commercial and employer-sponsored plans are not universally subject to the same regulatory window, and actual timelines vary by payer, plan type, and urgency designation. What does not vary is the operational requirement: the billing team needs to know when a decision is expected and when to follow up if it has not arrived.
Follow-up. When no decision arrives within the expected window, the billing team contacts the payer to check status. That contact needs to be documented: who called, when, what the payer said, and what the expected timeline is now. Without documentation, the next follow-up call begins without context. The same questions get asked again, and the payer conversation has to start over.
Additional information requests. Payers sometimes request additional clinical documentation before issuing a decision. When that happens, new documentation needs to be tracked: what was requested, when it was sent, and whether it has been acknowledged. An authorization waiting on additional documentation has a different next action than one pending a decision, and a tracker that does not distinguish between the two will generate incorrect follow-up priorities. Whether additional information requests affect the decision timeline varies by payer and plan.
Decision: approval, denial, or payer hold. When the payer responds, the outcome determines what happens next. Approval enables service scheduling, within any validity window the authorization specifies. Denial triggers either an appeal or a reconsideration request, depending on the payer's process. A payer hold (where the authorization is neither approved nor denied but placed in a secondary review) requires its own tracking and follow-up cadence.
Denial reason and appeal. Prior authorization denials include a denial reason from the payer. Beginning January 2026, under CMS-0057-F, impacted payers are required to provide a specific reason when denying a prior authorization for a medical item or service (the same regulation cited above for decision timelines). [CMS-0057-F, cms.gov] That reason determines the appropriate next step: a medical necessity denial may warrant a clinical peer-to-peer review; an administrative denial may be correctable with additional documentation. Tracking the denial reason precisely is what makes the appeal response targeted rather than generic. Appeal timelines and processes vary by payer and plan. Confirm the applicable window before filing.
Closure. An authorization is closed when it reaches a terminal state: approved and the service rendered within the valid window, denied with no further action, appeal resolved, or withdrawn. The closure record should include the date, the basis for closure, and the name of the person who confirmed it.
The field list below reflects the operational requirements of the workflow described above.
Identification and source fields:
Status and timeline fields:
Follow-up and contact history fields:
Outcome fields:
A prior authorization record can contain patient identifiers, provider information, procedure details, clinical documentation, payer correspondence, and decision history. Access to that information needs to reflect each person's role in the authorization process.
The same principle applies to workflow actions. The person responsible for payer follow-up may need to update contact history and the next action. A manager may need visibility across pending authorizations and aging requests. Other staff may only need access to the records involved in their work. Keeping those responsibilities inside the workflow helps teams manage the authorization process without giving every user the same level of access.
For healthcare organizations evaluating a platform for this work, those workflow requirements need to be considered alongside the platform's security controls and support for HIPAA-regulated use. Kintone documents its security practices, certifications, and HIPAA information in the Kintone Trust Center.
A spreadsheet can record what happened. The harder problem is coordinating what happens next.
A spreadsheet can record that a prior authorization was submitted weeks ago and has not received a decision. Recording that fact is different from assigning the follow-up call to a specific person with a deadline, tracking whether they made the call, and escalating to a manager when they have not. The more the process depends on assignment logic, deadline tracking, and ownership visibility, the more coordination infrastructure has to be built around the spreadsheet.
Data without assignment. A tracker can show that an authorization is pending. It does not show who is responsible for the next contact, when that contact should happen, or what happens if no contact is made. Pending is a status. The next follow-up call is an action.
Status without aging logic. A status field can read "pending." Making aging visible (identifying authorizations that have crossed the expected decision window without a recorded response) requires the system to do something with the date fields it already holds. That behavior is coordination logic, not data storage. A tracker that cannot distinguish a recently submitted pending authorization from one that has been waiting past its expected decision window without a manual sort is not managing the workflow.
Records without structured history. A tracker reflects the current state of an authorization. A structured contact history records the sequence of what happened before that state: each call made, each payer response, each document submitted, each status change. Current status tells you where something is. Structured history tells you how it got there and gives the context the next person needs when they pick it up: who spoke to the payer last, what was promised, what documentation is still outstanding. A handoff, a manager review, or a payer dispute all depend on the history, not just the current status.
The tracker needs to show what requires action today, assign the next step to a named person, make aging visible without a manual sort, and treat status changes as part of processing the workflow rather than a separate documentation task.
Teams that have moved beyond spreadsheets for prior authorization tracking build systems that meet those requirements, connecting submission records, contact history, ownership assignments, and closure documentation in one place rather than across email threads and individual files. That is what the operational layer alongside your EHR needs to do for authorization management.
A 15-minute walkthrough shows what your workflow looks like when the assignment, the contact history, and the closure record all live in the same place. See how the tracker surfaces what needs action today without a manual sort. Within 48 hours, a Kintone expert can walk you through the process and answer questions about your specific setup without a sales pitch before the conversation happens.
A complete authorization record tells you what was submitted and what the outcome was. That is the log. A complete authorization workflow tells you who owns the next action, what has been pending past the follow-up threshold, what documentation is outstanding, and what needs attention before it becomes a billing problem. That is the system.
A log records what happened. A system coordinates what happens next. Prior authorization tracking requires both: the record of what was submitted and decided, and the workflow that assigns, ages, and closes what is still in motion.
For healthcare practices managing referrals alongside prior authorizations, the same coordination logic applies to incoming referrals: from assignment through appointment confirmation and referring provider notification. That workflow is covered in the healthcare referral tracking guide.