Most of what’s written about prior authorization is aimed at the provider side — how to submit one, how to appeal a denial, how long a payer takes to respond. That’s a real problem, but it’s not the one a claims system solves. From the payer side, prior authorization is a rule: a defined list of services, codes, or code categories that require approval before the plan will pay for them, checked automatically against every claim that comes through adjudication.
How it’s enforced at adjudication
Prior auth isn’t a separate workflow bolted onto claims processing — it’s one of the checks a claim runs through in the same sequence as eligibility and pricing. When a claim arrives for a service on the plan’s auth-required list, the system looks for a matching authorization on file: right member, right service or code, within the approved date range and unit count. If it finds one, the claim proceeds through pricing and cost-sharing like any other. If it doesn’t — no authorization on file, an authorization for a different code, or units that exceed what was approved — the claim pends instead of paying. Nobody has to remember to check; the requirement is configured once, against the code or service category, and it applies every time that code shows up on a claim.
A worked example
A plan requires prior authorization for MRI of the lumbar spine (CPT 72148), capped at one unit per authorization. Two claims arrive for the same code, same week. Claim A has a matching authorization on file: approved for this member, this code, dated before the service, one unit requested and one unit billed. It adjudicates straight through. Claim B is for the same member and the same code, but the authorization on file was for a different imaging code — a lumbar X-ray, not an MRI — approved the month before. The auth doesn’t match what was actually billed, so Claim B pends for someone to confirm whether the MRI was in fact authorized separately, billed under the wrong auth, or genuinely doesn’t have one. Same requirement, same code, two different outcomes because the underlying data didn’t match.
Why the requirement list varies by client
What requires prior authorization isn’t fixed — it’s a plan design decision, and it’s often the single biggest lever a plan has over utilization and cost on high-dollar services: imaging, elective procedures, certain specialty drugs, out-of-network referrals. A TPA running multiple client books needs those lists to be genuinely independent per client, not a single global rule set with exceptions bolted on, because one client’s tight authorization requirements on elective surgery shouldn’t apply to another client’s more open plan design — and a rules engine that can’t isolate that config per client will eventually leak one client’s restrictions onto another client’s members.
Why this matters operationally
A prior-auth pend is one of the most common reasons a claim lands in the adjudicator queue, and it’s usually resolvable fast if the data is right — the auth exists, it’s just not matching cleanly. That makes the enforcement mechanics worth getting right: a claims adjudication engine that checks authorization at the point of adjudication, attaches the specific mismatch reason to the pend, and lets requirements be configured per code and per client keeps that check from becoming a manual gate. For a TPA administering client groups with genuinely different authorization rules on the same platform, that per-client isolation is what keeps one client’s utilization controls from becoming another client’s false denials.