An approval is not a document — it is a state with an expiry
Most claim rejections do not begin at submission. They begin weeks earlier: a procedure performed against an approval that had expired, or a request sent and never chased. An approval is a state with a lifespan, and treating it as one changes what you collect.
When a claim is rejected, the instinct is to look at the moment of submission: a missing code, an unattached document. But a great deal of rejection traces back to a decision made weeks earlier — a procedure performed against an approval that had not arrived yet, or one that arrived and then expired before the patient's appointment.
The difference between a clinic that collects and one that leaks is not only coding accuracy. It is whether prior authorisation is treated as a document filed away, or as a state with a lifespan that has to be tracked to its end.
An approval has five states, not two
The common mistake is reducing an authorisation to "we have one / we don't". In reality the request moves through a full path, and every transition has a date and someone responsible for it. Recording the state explicitly is what makes "where has this patient's request got to?" answerable in a second rather than a round of phone calls.
| State | What it means | What it needs |
|---|---|---|
| Pending | Logged but not yet sent | Complete the codes and documents, then submit |
| Submitted | Sitting with the insurer | A clock — this is the state that gets forgotten |
| Approved | Issued with a number and an expiry | Schedule the patient before it lapses |
| Rejected | Refused, with a stated reason | Correct and resubmit, or tell the patient |
| Expired | Approved once, now lapsed | A new request — do not treat against this one |
The two states that cost money
Of the five, only two cause real losses, and both are silent: neither raises an alert or appears on anyone's screen unless the system was built to surface them.
- Submitted with no reply. The request went out and never came back, and because nobody is looking at it any more the patient waits for an appointment that never gets booked. This state needs a daily list of anything older than a reasonable turnaround.
- Approved, then expired. More dangerous than a rejection, because a rejection announces itself while an expiry happens quietly — and is discovered after the procedure, once the money is already owed by the patient or absorbed by the clinic.
The expiry date is not an optional field
An approval with no recorded expiry is one no system can warn you about. Capturing it the moment the approval arrives is the cheapest preventative step in the whole revenue cycle.
Attach it to the patient and the appointment
When approvals live in a side spreadsheet or a shared folder, the link that actually matters breaks: whoever books the appointment cannot see the approval's state, and whoever chases the approval does not know an appointment has already been booked. Tying the request to the patient's file and to the visit puts the information in front of the person who will act on it.
This is the same logic that reduces claim rejections: the right fact has to appear on the screen where the decision is made, not in a report reviewed afterwards.
What management should see weekly
Daily chasing is the front desk's job, but management needs a different picture: where money is leaking and where things are stalling. Three numbers usually cover it:
- How many submitted requests have passed the usual turnaround, and by how much on average.
- How many approvals expire within a fortnight and still have no appointment booked against them.
- The most frequent rejection reasons — because a repeated reason is a broken internal step, not an insurer problem.
The third number matters most over time. One rejection for one reason is an incident; twenty for the same reason means a step in your own workflow is performed wrongly every time, and fixing it once is cheaper than reworking every claim individually.
Someone has to own the chase
Approvals usually get lost because they are a shared responsibility with no clear owner: reception assumes the insurance coordinator is chasing, and the coordinator assumes the doctor will ask. Naming one owner for the submitted list — a person who opens it every morning — solves more than half the problem before any software changes hands.
Track every approval to its end
Record the request, its state and its expiry against the patient's file and their visit, and see what is about to lapse before it does.
See what the system does