Cigna separates referrals, predeterminations, and precertification

Three workflows need three operating states

Cigna's provider page defines precertification as asking for approval before certain services, treatments, or medications. It separately describes predetermination as a way to review specified treatment or benefit questions before care and describes a referral as a primary-care provider directing a patient to another clinician, usually a specialist.

The labels are related but not interchangeable. A system should preserve which plan, population, service, benefit, provider, date, and workflow created the requirement rather than presenting one generic authorized flag across referrals, predeterminations, and precertifications.

Plan and service context determine the route

Cigna says requirements can depend on the patient's plan and identifies medical procedures, medications, behavioral-health services, home health care, durable medical equipment, and imaging as examples. The page also points providers to current lists and plan-specific resources rather than presenting one universal requirement.

Requirement discovery should therefore retain the source, plan, service code or description, effective period, exclusions, and verification time. A cached list, generic payer rule, or prior result should not silently decide a new patient or service request when the governing context has changed.

Ordering and rendering responsibilities differ

The payer assigns the request-and-obtain responsibility for applicable in-network services to referring, ordering, or admitting providers. It separately tells rendering providers or facilities to confirm approval before performing applicable elective services, while noting that a rendering provider may request precertification in some cases.

That division creates a handoff record: who discovered the requirement, who assembled and submitted the request, who received the determination, who confirmed it, and who decided the service could proceed. Software should expose unresolved ownership rather than inferring completion because one party received a status.

Channels and decisions retain their boundaries

Cigna documents several submission paths, including an EDI 278 transaction, phone, fax, payer portals, and delegated workflows for certain services. It also distinguishes medical and pharmacy routes and says required information must accompany the request, with follow-up using the same method when additional information is needed.

A successful transmission or approval is not the final claim-payment record. Cigna explicitly says precertification does not guarantee payment or coverage of all billed services, so eligibility, benefit terms, coding, network status, actual services, claim adjudication, and other conditions remain separate evidence and decisions.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Prior Auth Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.