# Prior authorization follow-up, worked case | SourceX

Canonical: https://refer.sourcex.si/guides/prior-authorization-follow-up-exception-examples
Last updated: 2026-10-18

The prior authorization records that explain how an exception was handled are the version chain: each submission as it was sent, with its attachments; the pend or missing-document request that stopped it; the internal task that fixed it; and the final status with its authorization number and dates. A single final status hides the exception. The versions in order show the problem, the authorized action and the checked result. The illustrative case below works through one such chain.

This worked case belongs to the [prior authorization follow-up hub](/guides/workflow-prior-authorization-follow-up), which covers what to inventory before a platform change. Here the job is to walk one hard case and show why its sequence is evidence.

## The request and the rule that moved (Illustrative)

Fictional, written for this page; it does not describe any real patient, payer or company. A 260-person outpatient imaging group runs its own authorization team. The team submits requests through payer portals and tracks each one in an internal work queue.

On day 0 the team sends a request for a lumbar MRI with the order, the clinical notes and the imaging history the payer's policy listed at that time. On day 1 the payer publishes an updated policy that also asks for documentation of a completed course of conservative treatment. On day 2 the request is pended with a message citing the new policy. The first submission was correct when sent; the requirement moved while it was in flight. That is the exception.

## Six dated steps, version 1 to approval

| Day | Step | Record | Version | Where it lives |
|---|---|---|---|---|
| 0 | Request sent with order, notes and imaging history | Submission with attachment list | Version 1 | Payer portal; copy in work queue |
| 1 | Payer publishes updated policy | Policy bulletin | Not a submission | Payer website; often only a staff email |
| 2 | Request pended, missing-document message cites the new policy | Pend message and status change | Version 1 | Payer portal; work queue status |
| 3 | Task to the ordering clinic for physical therapy notes | Work queue task with owner and due date | Not a submission | Work queue only |
| 4 | Resubmission with therapy notes attached | Submission with new attachment list | Version 2 | Payer portal; copy in work queue |
| 6 | Approval with authorization number and validity dates | Decision record | Version 2 | Payer portal; number copied to scheduling |

## Who acted at each step, and the record it left

1. **Authorization specialist, day 0.** Chose what to attach against the policy as published. The attachment list on version 1 is the proof the team met the rule of the day.
2. **Payer, days 1 and 2.** Changed the rule, then pended the request. The pend message, quoting the new requirement, is what connects the two events. Without it the pend looks like a team error.
3. **Team lead, day 3.** Read the pend, decided which clinic held the missing notes and assigned the task. This decision lives only in the work queue.
4. **Specialist, day 4.** Resubmitted with the new document. Version 2's attachment list shows exactly what changed.
5. **Payer, day 6.** Approved version 2. The decision record carries the authorization number and validity dates the scheduling team needs.

Timing explains why each date matters. Under the CMS Interoperability and Prior Authorization Final Rule, beginning primarily in 2026, impacted payers must send decisions within 72 hours for expedited requests and seven calendar days for standard ones, and must give a specific reason for a denial; the rule does not cover drugs and excludes QHP issuers on the federally facilitated exchanges from those timeframes. CMS's frequently asked questions add a detail that fits this case closely: the decision timeframe starts when the payer receives the request, and it does not stop or restart if the payer asks for documentation that was not disclosed to the provider when the original request was submitted, although extensions may apply where program rules permit. For a covered payer, then, day 0 rather than day 4 is the clock's starting point, and only a record of version 1's date shows it.

## Why the version chain is better evidence than the final status

Read alone, the day 6 approval looks like a routine standard request. Read as a chain, it shows something an AI system learning this work needs to see: a correct submission became incomplete because the rule changed, the team detected the pend, routed a task to the right clinic and resubmitted within two days, and the payer approved the corrected version. That is judgment under a moving requirement, with a checked result.

The two rows marked "Not a submission" are the most fragile. The policy bulletin sits outside the company's systems unless someone logged it, and the work queue task disappears with the platform if the queue is retired without its history. A company that keeps a dated log of payer requirement changes, as its own work product, can explain a version 1 failure without opening any patient record. Similar evidence patterns in non-clinical work are described in the guides to [procurement approvals and exception workflows](/guides/how-to-assess-procurement-approvals-and-exception-workflows) and [logistics exceptions](/guides/how-to-identify-logistics-exceptions-and-their-documented-resolutions).

## Spotting the same pattern at a client

Ask the revenue cycle director, and listen for:

- **"We keep every submission, not just the latest."** The chain exists.
- **"Pend messages are stored with the request."** The reason for each exception survives.
- **"The work queue keeps closed tasks."** The authorized action has an owner and a date.
- **"Someone logs payer policy changes."** The cause of a version 1 failure can be shown without patient data.
- **"Authorization numbers are copied to scheduling."** The result can be checked against what happened next.

Three or more of these suggest a company whose follow-up history is worth describing in an introduction. To see which identifiers would join the pieces, read the [system map for prior authorization follow-up](/guides/prior-authorization-follow-up-records-across-systems).

## Qualification and open questions

These records are protected health information as they stand, so licensing would require de-identified data. HIPAA's de-identification standard can be met by Expert Determination or Safe Harbor, compared in [Safe Harbor vs Expert Determination](/compare/hipaa-safe-harbor-vs-expert-determination); [licensing healthcare operational data without PHI](/questions/license-healthcare-operational-data-without-phi) covers the wider question. The revenue cycle director sponsors; the [who-can-say-yes tree](/questions/who-can-license-prior-authorization-follow-up-records) shows who approves. Partners never request or handle the records.

An introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Provider and payer agreement terms, de-identification, buyer interest and any offer stay unknown until SourceX's rights review. SourceX licenses approved business data directly from companies for AI training and evaluation and manages the agreement, rights review, data preparation, delivery and payout.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If a client keeps its submission versions, pend messages and closed work queue tasks together, [register as a partner](/register), check the company against [who qualifies](/who-qualifies) and read the [program terms](/terms) before introducing its revenue cycle director.

## Sources

- https://www.cms.gov/files/document/fact-sheet-cms-interoperability-and-prior-authorization-final-rule-cms-0057-f.pdf
- https://www.cms.gov/initiatives/burden-reduction/overview/interoperability/frequently-asked-questions/prior-authorization-api
- https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html
- https://refer.sourcex.si/terms