# Prior authorization follow-up system map | SourceX

Canonical: https://refer.sourcex.si/guides/prior-authorization-follow-up-records-across-systems
Last updated: 2026-10-18

Reconstructing one prior authorization follow-up takes five links: the internal request or encounter ID, the payer's reference or authorization number, the version or resubmission sequence, the attachment list for each version, and the date of each status change. The internal work queue usually anchors the request; the payer portal or a clearinghouse's 278 log holds what was sent and returned; a document system holds attachments; scheduling receives the final authorization number. The version sequence is often the weakest link.

This system map is part of the [prior authorization follow-up hub](/guides/workflow-prior-authorization-follow-up). The [worked case](/guides/prior-authorization-follow-up-exception-examples) follows one request through time; this page shows which systems hold the pieces and which identifiers let anyone put them back together.

## The five systems a follow-up touches

**Internal work queue or revenue cycle platform.** Where the authorization team tracks each request, assigns tasks and records status. It owns the internal request ID and, if edit history is kept, the record of each version.

**Clearinghouse.** Electronic requests and responses commonly use the HIPAA standard transaction for prior authorization and referrals, ASC X12N 278 Version 5010. Where a clearinghouse carries them, it may keep transaction logs under its own contract.

**Payer portal.** Many requests are keyed directly into each payer's website. The portal holds the payer's reference number, pend messages and the decision, on the payer's system and under the payer's retention.

**Document system.** Clinical notes and other attachments are often stored apart from the queue, linked by a document reference on the task.

**Scheduling or practice management.** Receives the authorization number and validity dates so the service can be booked. It is where the result is checked against what actually happened.

## Linking keys: system, record, key and owner

| System | Record | Linking key | Owner |
|---|---|---|---|
| Work queue | Request and its status history | Internal request or encounter ID | Authorization team lead |
| Work queue | Edit history or version records | Request ID plus version number | Authorization team lead |
| Clearinghouse | 278 request and response logs | Trace or control number, mapped to request ID | IT and vendor management |
| Payer portal | Submission, pend message, decision | Payer reference number | Payer system; copies held by the team |
| Document system | Attachments per submission | Document reference on the task | Health information or records team |
| Work queue | Tasks between versions | Task ID on the request | Authorization team lead |
| Scheduling | Booked service with authorization | Authorization number and dates | Scheduling manager |
| Policy log, if kept | Dated payer requirement changes | Payer and policy identifier | Revenue cycle director |

The internal request ID is the spine. Every other key matters only if someone recorded it against that ID: the payer reference typed back into the queue, the attachment linked to the right version, the authorization number copied to scheduling.

## Where the joins break, hop by hop

| Hop | What should connect | What usually breaks it |
|---|---|---|
| Queue to payer | Request ID to payer reference | Reference typed into a free-text note, or not at all |
| Version to version | Version 1 to version 2 | Queue overwrites the request instead of keeping versions |
| Version to attachments | Each version to its document list | Attachments stored once, not per version |
| Pend to reason | Status change to the payer's message | Staff status codes map loosely to payer reasons |
| Decision to service | Authorization number to scheduling | Number not copied back, or copied without dates |
| Exception to cause | Pend to the payer policy that changed | Policy updates circulated by email only |

The last hop is often the most revealing. A dated log of payer requirement changes, kept as the company's own work product, can explain why a version 1 request fell short without opening any patient record.

Payer responses may become more structured over time. CMS's fact sheet on the Interoperability and Prior Authorization Final Rule says that beginning January 1, 2027, impacted payers must implement a Prior Authorization API that lists covered items and services, identifies documentation requirements and supports requests and responses, including approval with its end date or circumstance, denial with a specific reason, or a request for more information. Where a company's history straddles that change, the map should note whether older and newer responses are stored the same way. Which records exist and can be exported depends on each platform, version and contract; only the company's administrators can confirm it.

## One request, fully joined (Illustrative)

Fictional, written for this page. A 320-person revenue cycle management company handles authorizations for orthopedic practices.

| Step | System | Record | Key carried forward |
|---|---|---|---|
| Created | Work queue | Request REQ-55120 for an outpatient procedure | REQ-55120 |
| Version 1 sent | Clearinghouse | 278 request with its control number | Control number mapped to REQ-55120, version 1 |
| Pended | Payer portal | Pend message asking for imaging report | Payer reference PR-7781, typed into REQ-55120 |
| Task | Work queue | Task to the practice for the imaging report | Task on REQ-55120 |
| Attachment | Document system | Imaging report filed | Document reference linked to version 2 |
| Version 2 sent | Clearinghouse | 278 resubmission | Control number mapped to REQ-55120, version 2 |
| Approved | Payer portal and work queue | Decision with authorization number and dates | Authorization number on REQ-55120 |
| Booked | Scheduling | Procedure booked inside the validity dates | Authorization number |

Every hop here carries a key back to REQ-55120, so the request can be read end to end. Many real companies will have the first and last hops and a patchier middle. When an authorization problem is found only at billing, the chain continues into [claim denial routing](/guides/workflow-claim-denial-routing).

## Questions for the revenue cycle director

1. Does the work queue keep every version of a request, or only the latest?
2. Is the payer reference recorded in a dedicated field, a note, or not at all?
3. Are attachments linked to a specific version?
4. Does a clearinghouse carry 278 transactions, and how long does its contract keep logs?
5. Is there any log of payer policy changes, and since when?
6. Is the authorization number copied to scheduling with its dates?

## Qualification and open items

Authorization records are protected health information as they stand. A revenue cycle company is often a business associate: HHS lists billing and claims processing among the functions that can make an entity one, and a business associate may use or disclose protected health information only as its contract permits or the law requires. [What a business associate is](/questions/what-is-a-business-associate-hipaa) explains the role, and any licensing would require de-identified data under Expert Determination or Safe Harbor. Some companies cannot license at all; [which companies cannot license their data](/questions/which-companies-cannot-license-their-data) covers the common reasons.

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. Contract terms, de-identification, buyer interest and any offer stay unknown until SourceX reviews the opportunity. More on this sector is on the [revenue cycle management companies](/industries/refer-revenue-cycle-management-company-data-licensing) page, and the answers above belong in the [referral brief template](/resources/prior-authorization-follow-up-referral-brief-template).

## 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 the director's answers show that one request ID holds the versions, attachments and authorization number together, [register as a partner](/register), check the company against [who qualifies](/who-qualifies) and read the [program terms](/terms) before making the introduction.

## Sources

- https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/hipaa/adopted-standards-operating-rules
- https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-prior-authorization-final-rule-cms-0057-f
- https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html
- https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html
- https://refer.sourcex.si/terms