How to Track Prior Authorization for Dental-to-Medical Claims

A prior authorization tracker should show each step and its proof. It should list the source, request, reply, open task, and next owner. It should never turn an approval into a promise of coverage or payment.

Prior authorization is a payer review before care or a claim. A dental-to-medical case may need several calls, files, and replies. One short status field cannot tell the full story. A clear tracker can.

What should a prior authorization tracker do?

It should show what is known, what is missing, and who must act next.

The tracker should answer basic questions. Which payer gave the rule? Which plan does it cover? Which patient and provider does it name? What service and place were listed? What did staff send? What did the payer say?

The tracker is an index. It should point to the full record. It should not copy extra private data into an open sheet or chat. Access must follow the site's privacy and safety rules.

A referral and an authorization are not the same. The referral and prior authorization guide explains the difference.

Which fields belong in the tracker?

Each field should help staff check the source, scope, proof, time, or owner.

Use fields such as:

• Payer and plan name.
• Source of the payer rule.
• Date that staff checked the source.
• Patient and account reference.
• Provider, service, and care site.
• Planned service date when known.
• Payer request or case number.
• Date and route of each send.
• Receipt or other send proof.
• Current payer reply in its own words.
• Any item the payer still wants.
• Scope and end date if the payer states one.
• Person or role that owns the next step.
• Escalation level and the named path for the next review.
• Dated status history with each source, state, and owner.
• Link to the full record.

Not every payer uses the same words. Some may not give every field. Staff should keep the payer's own wording. They should not make a reply sound stronger than it is.

Treat the dated status history as immutable and append-only. Do not overwrite an old payer state. Add a new entry and link any correction to the state it changes.

The provider controls the care plan and clinical facts. The tracker records those facts only as the approved record states them.

How should staff record payer replies?

Staff should keep the exact reply and label any team note as a summary.

CMS says an impacted payer may send one of several replies. It may approve and state when the approval ends. It may deny and give a reason. It may ask for more facts. See the CMS prior authorization API frequently asked questions.

That CMS description has a set scope. It does not set one rule for every payer, plan, service, or system.

For an approval, save the full reply. Record the provider, service, site, terms, and end point it names. For a denial, keep the stated reason. For a request, list the exact item still needed.

Billing staff may route a request for a clinical record. They must not write the missing clinical facts. The provider or record owner must decide what the true record supports.

How should open tasks and follow-up be tracked?

Each open item needs a clear task, source, owner, status, and next check.

A vague note such as follow up soon is not enough. A useful note says what the payer asked for. It says who will respond and where the source is kept. It also says what event will cause the next review.

Do not invent one call schedule for all payers. Timing should come from current payer steps. A written reply or contract may also guide it. The site's approved process may add its own controls.

For each contact, record:

• The date and contact route.
• The request or case number.
• The exact status given.
• The file or fact still needed.
• The proof saved from the contact.
• The next action and its owner.

A sent file is not always a received file. A phone update is not always a written result. Keep those states apart.

What does full tracking look like in a dental-to-medical case?

Full tracking links the first rule check to the final written reply.

Hypothetical scenario: A provider plans a dental service that may lead to a medical claim. Staff find a current payer rule. It says that payer review is needed.

The team records the rule source and request scope. Staff then send the provider-approved file. They keep the receipt and a copy of what was sent.

The payer asks for one more clinical record. The tracker sends that task to the record owner. Staff do not add new clinical text. The owner finds the true record and approves the reply.

A written approval later arrives. Staff compare its provider, service, site, terms, and end point with the plan. One key detail does not match. The team pauses and asks the payer for current steps.

The team does not stretch the reply to fit a changed service. The authorization timing guide explains why scope and time matter.

What should staff check before claim work begins?

Staff should confirm that the current plan still fits the payer's written reply.

The final check should cover the named provider, service, care site, terms, and any stated end point. It should also show that all open payer requests were handled.

A plan change may call for a new payer check. A plan status change may call for a fresh benefit check. Staff should use current facts and payer steps.

Keep each question separate. Plan status is not coverage. Coverage is not approval. Approval is not a network term. None of those facts proves payment or patient cost.

Is a portal status enough to show prior authorization?

A portal status can be useful proof. Staff should still keep the full reply when it is available. They should also check the stated scope.

Does prior authorization prove that a claim will be paid?

No. Plan status, coverage, network terms, claim facts, review, payment, and patient cost stay separate.

This guide is general administrative information, not legal, medical, clinical, dental, coding, documentation, privacy, security, contract, accounting, financial, patient-billing, or coverage advice, and not a statement that any workflow, record, request, response, claim, payment, adjustment, deadline, decision, or outcome is accurate, complete, compliant, authorized, covered, or payable. Requirements and outcomes vary by payer, program, plan, patient, provider, service, record, agreement, system, jurisdiction, and date.