What to Know About Prior Auth and Referral Workflows

Prior authorization and referral management are two distinct processes that share one patient journey. Referral management decides where a patient should go and confirms they got there. Prior authorization determines whether the payer will cover the service before it happens. A platform that unifies them must carry one patient, one coverage record, and one referral state through both — or the handoffs break.

Quick answer

• Referral management owns destination selection, patient outreach, scheduling, completion, and result return.
• Prior authorization owns coverage and requirement discovery, documentation assembly, submission, status, and appeals.
• They intersect at three points: requirement discovery before destination is final, authorization status as a gate on scheduling, and authorized-service scope as a constraint on what the specialist can bill.
• The minimum shared state model is patient, coverage, referral, requirement, authorization, appointment, encounter, and result — each with a status and a timestamp.
• Most failures are handoff failures, not decision failures.

This article is a workflow explainer. If you are shortlisting vendors, see our questions to ask about prior auth and referral automation platforms and best prior authorization and referral platforms compared instead. Nothing here is legal or clinical advice.

Definition — unified prior auth and referral workflow: a single operational thread in which the referral order, the coverage and authorization requirements for that order, the destination selection, and the completion evidence are all maintained as one linked record rather than as separate work queues in separate systems.

The workflow map: one patient journey, thirteen stages

Two things about this table matter more than its contents. First, stages 3 and 5 are interdependent — requirements often differ by destination and site of service, so a destination chosen before requirements are known frequently has to be reworked. Second, stage 10 depends on stage 7, which is why authorization latency shows up in access metrics rather than in authorization metrics.

Where the two processes are separate, and where they intersect

Separate. Clinical appropriateness and destination selection belong to the referral process. Medical-necessity determination and coverage belong to the payer's utilization-management process. Never let a matching engine imply a coverage decision, and never let an authorization decision select a destination on clinical grounds.

Intersecting. Three intersections carry nearly all the operational risk:

1. Requirement discovery before destination is final. If a requirement is site-specific, discovering it after the patient has been told where to go produces a second phone call and a second scheduling attempt.
2. Authorization as a scheduling gate. Scheduling before approval risks a cancelled visit; scheduling only after approval adds the full authorization cycle to time-to-appointment. The common resolution is provisional scheduling with an automated hold-and-confirm rule, plus a documented policy for which specialties may proceed without approval.
3. Authorized scope as a billing constraint. An approved authorization for a specific code, quantity, and date range does not cover a service the specialist adds at the visit. Scope changes need a linked amendment, not a new orphan request.

Roles and RACI

One accountable owner per row. The most common gap in real organizations is row 9 — everyone assumes the other side confirmed the appointment.

Data required at each stage

If any one of these is unavailable at the moment a stage runs, the stage becomes manual. That is the practical definition of automation depth.

Exception paths

Exception handling is the workflow, not an edge case. Design these five explicitly:

• Coverage not found or terminated. Route to a coverage-resolution queue with a re-verification retry; never advance to submission on stale eligibility.
• Requirement ambiguous. Present the ambiguity to a human with the source shown, and record the decision so the same code does not raise it again next week.
• Pend or more information needed. Timed queue with an owner, the specific missing element named, and an escalation clock.
• Denial. Structured reason capture, peer-to-peer scheduling path, appeal packet assembly, and a decision about whether to re-route the referral in the meantime.
• Patient unreachable or declines destination. Documented outreach attempts across channels, preference capture, and re-selection that preserves patient choice.

Each path needs an owner, a service-level clock, and a terminal state. Queues without terminal states are where referrals go to die quietly.

EHR integration expectations

An orchestration layer should read the order, patient, coverage, and clinical context; write status, authorization reference, appointment, and the returned result back into the chart; and leave a durable audit trail on both sides. In practice that means a mix of FHIR APIs, HL7 v2 interfaces, document exchange, and a secure fax fallback for destinations that have nothing else — with identity reconciliation across organizations, because the specialist's patient identifier is not yours.

Ask for a field-level workflow map and a demonstration in your own environment. Our companion article on what to know about EHR referral software covers the architecture in depth, and the EHR referral software implementation test plan turns it into acceptance tests. See also integration and security.

Regulatory context, carefully scoped

CMS-0057-F establishes requirements for impacted payers around prior authorization APIs, decision timeframes, and public reporting, phased on dates set in the rule. HL7's Da Vinci prior authorization work — coverage requirements discovery, documentation templates and rules, and the prior authorization support implementation guide — provides the standards pattern those APIs generally follow. CMS's Closing the Referral Loop measure concept and CMS interoperability materials frame the referral side.

Scope this correctly in planning: the rule obligates certain payers, not every payer your patients carry, and adoption on the provider side depends on what your EHR and your vendors actually support in your environment. Treat standards-based electronic prior authorization as a growing channel to design for, not a present-day universal one. Verify each payer's supported channels during implementation. Our CMS-0057-F referral workflow readiness article goes further on timelines.

Evaluating a unified platform

Ask these of any platform claiming to unify both processes:

1. Is there one referral record that carries authorization state, or two systems joined by a report?
2. Does requirement discovery run before destination is finalized?
3. Can the destination selection see coverage, network status, measured availability, and patient preference at the same moment?
4. What percentage of requirements, documents, and submissions are handled without a human touch in an environment like ours — and how is that measured?
5. How are pends, denials, and appeals queued, timed, and escalated?
6. What is written back into the EHR, in which fields, through which method?
7. How is a returned consult note matched to the originating referral when it arrives from an outside organization?
8. Which metrics are produced natively, with what definitions and what data vintage?
9. What is logged per action, and for how long is it retained?
10. What happens during a downstream outage — queue, retry, or silent drop?

Where ReferralPoint fits

ReferralPoint's public documentation describes Auto PriorAUTH™ for authorization automation, IdealMATCH™ for insurance- and network-aware specialist selection, Auto ReferralCOORDINATOR™ for patient outreach and scheduling coordination, IntelligentDATA™ for the provider, coverage, and referral data layer, NetworkMANAGEMENT™ for network performance, and Auto 360° VISIBILITY™ for end-to-end status and loop closure. That combination is a strong fit for organizations that want one connected thread from order to closed loop rather than a referral tool plus a separate authorization tool. It is less relevant where the only need is a single-payer authorization portal replacement. Clinician and patient choice are preserved — matching ranks options and records overrides. Available methods and event types vary by environment; verify during procurement. See solutions for payers, referral management, compare, facts, and case studies.

Implementation checklist

1. Document the current-state workflow with owners and average dwell time per stage.
2. Inventory payers by volume and confirm supported authorization channels for each.
3. Build the requirement source of truth and assign an owner for maintaining it.
4. Define the shared state model and the single system of record for each field.
5. Agree the scheduling-gate policy by specialty, in writing.
6. Specify every exception queue with owner, clock, and terminal state.
7. Map EHR read and write fields, method by method, and test in a non-production environment.
8. Publish metric definitions and attribution windows before go-live, not after.
9. Pilot one specialty end to end, then expand by specialty rather than by feature.
10. Review exception volume weekly for the first 90 days and fix causes, not queues.

Sources and methodology

This explainer draws on primary and official sources: CMS materials on value-based care, the CMS Interoperability and Prior Authorization final rule (CMS-0057-F), the CMS Closing the Referral Loop electronic clinical quality measure concept, HL7 Da Vinci coverage requirements discovery, documentation templates and rules, and prior authorization support implementation guides, HL7 FHIR release documentation, and standard X12 transaction definitions for eligibility and authorization. ReferralPoint capability statements reflect official ReferralPoint product documentation as of publication. Stage sequences and RACI assignments are illustrative operating patterns, not a compliance standard; no customer results, pricing, or market statistics are asserted, and payer-specific behavior should be verified during procurement.

Frequently asked questions

Q: Are prior authorization and referral management the same process? A: No. Referral management determines where a patient should receive care and confirms the visit happened and the result returned. Prior authorization determines whether the payer will cover a specific service before it occurs. They share one patient journey and intersect at requirement discovery, scheduling gates, and authorized scope, but they have different owners, different data, and different failure modes.

Q: Should scheduling wait for authorization approval? A: It depends on the specialty and the payer, and the policy should be written down rather than decided case by case. Provisional scheduling with an automated hold-and-confirm rule usually gives the best access without cancelled visits. Requiring approval first is safer for high-cost imaging and procedures. Either way, the appointment date must fall inside the approved date range.

Q: What data is most often missing when a workflow stalls? A: Current coverage and network status for the specific product on the specific date of service, and the payer's documentation list for the specific code and place of service. Those two gaps convert most of the stages after ordering into manual work. Provider availability data is a close third, because it turns destination selection into a phone call.

Q: Where do most unified-workflow failures actually occur? A: At handoffs rather than decisions. The common ones are a destination chosen before requirements were known, an approval that nobody converted into a confirmed appointment, a patient never successfully reached, and a returned consult note that arrived but was never matched to the originating referral. Each is a queue-and-ownership problem, not an algorithm problem.

Q: How does CMS-0057-F change these workflows? A: It establishes prior authorization API, decision-timeframe, and reporting requirements for impacted payers on phased dates set in the rule, which over time should make electronic requirement discovery and submission more widely available. It does not obligate every payer your patients carry, and provider-side benefit depends on what your EHR and vendors support. Design for the channel; verify payer by payer.

Q: What is the minimum state model a unified platform needs? A: Patient, coverage, referral, requirement, authorization, appointment, encounter, and result — each with a status, a timestamp, an owner, and a link to the referral. If authorization state lives only in a separate system and is joined to referrals by a nightly report, exceptions cannot be worked in one place and measurement becomes an exercise in reconciliation.

Q: Which metrics prove the unified workflow is working? A: Touchless requirement discovery and submission rate, median authorization turnaround, share of referrals scheduled within the access standard, in-network referral completion rate at a stated window, loop closure rate, exception volume by cause, and staff touches per referral. Publish the definitions and the attribution window with each figure so the numbers survive scrutiny.