A product team at a telehealth company recently asked a question that comes up constantly: if they already run an eligibility check before booking an appointment, why would they also need prior authorization? The patient is covered. The service is in-network. What else does the payer need to know?
The answer is: quite a lot, depending on what you're trying to do. Eligibility checks and prior authorization are two separate payer-side processes that serve different functions, use different data, run on different systems, and return different outputs. Conflating them leads to product architectures that work fine for routine care and fail on exactly the cases where the stakes are highest.
What an Eligibility Check Does
An eligibility check asks one question: is this patient covered for this type of service under their current plan?
You send the payer a request with the patient's insurance ID, their date of birth, and the type of service. The payer returns coverage status: active or inactive, in-network or out-of-network, applicable deductible and copay amounts, and whether the plan covers the general category of care. The underlying transaction standard is EDI 270 (the request) and 271 (the response). Clearinghouses like Availity and Change Healthcare sit in the middle and handle the routing.
Eligibility checks are real-time. Responses typically come back in seconds. They are well-standardized and clearinghouse APIs have broad payer coverage. For most routine care decisions, they are sufficient.
What they do not tell you: whether the payer will actually approve a specific treatment. Coverage for a service category and approval for a specific treatment are not the same thing.
What Prior Authorization Does
Prior authorization asks a different question: does the payer approve this specific drug or procedure for this specific patient, prescribed by this specific provider, right now?
Where eligibility is general, prior authorization is specific. It requires the drug's NDC code or the procedure's CPT code, the patient's ICD-10 diagnosis codes, clinical notes documenting why the treatment is medically necessary, the treating provider's NPI, and in some cases the patient's prior treatment history showing they have already tried lower-cost alternatives. The payer reviews all of this against their medical policy and returns an authorization decision: approved, denied, or pended for clinical review.
Prior authorization is not real-time in the same way. Simple cases can get instant approval. Complex cases, specialty drugs, and payers with manual review queues take hours to days. A denied prior auth triggers an appeals process that can run 90 or more days. For specialty medications costing $30,000 or more per treatment, this delay is the difference between a patient starting care this week and waiting three months.
Why Eligibility Is Not Enough
The most common version of this mistake happens in behavioral health and specialty care platforms. A patient is covered. The therapist, psychiatrist, or specialist is in-network. The plan includes the category of service. The eligibility check comes back clean. The team assumes the workflow is covered.
Then a psychiatrist tries to prescribe a specific medication and the claim is denied. Or a patient needs a specialty sleep therapy device and the insurance won't pay without prior auth that was never obtained. Or a chronic care patient gets referred to a specialty program that requires PA before enrollment, and no one flagged it because the eligibility check said the service was covered.
The issue is that eligibility operates at the plan level. Prior authorization operates at the treatment level. A plan can cover psychiatry broadly while still requiring prior authorization for specific medications within that category. A plan that includes chronic care management benefits may still require PA for specific programs like weight management or cardiac rehab. Coverage and approval are different gates. Passing the first one does not mean you pass the second.
How the Systems Differ
Eligibility checks run through clearinghouse APIs. Availity, Stedi, and Change Healthcare all offer standardized 270/271 interfaces with broad payer coverage. The integration is relatively straightforward, the data format is standardized, and the responses are fast and parseable.
Prior authorization is much more fragmented. A standardized transaction format exists (X12 278) but is not universally supported. Most payers require prior auth requests to be submitted through their own web portals: Availity for some payers, CoverMyMeds for drug-related requests, Carelon for certain behavioral health cases, and payer-specific portals for others. Each portal has its own authentication, its own form structure, its own session behavior, and its own rules about what data is required and in what format.
This is why prior authorization automation is substantially harder than eligibility automation. Clearinghouse APIs give you a single integration point for eligibility across most major payers. Prior auth requires maintaining integrations with dozens of portal environments, each of which can change without notice.
What This Means for Health Tech Teams
If your platform involves specialty medications, durable medical equipment, recurring specialty care, or procedures that fall outside routine in-office visits, you need to model prior authorization as a distinct workflow from eligibility verification. They require different data collection at intake, different payer touchpoints, and different downstream handling for approvals, denials, and appeals.
For engineering teams, the practical implication is: eligibility checks can be handled through standard clearinghouse APIs. Prior authorization requires a separate integration layer, either built against individual payer portals or handled through a managed automation layer that maintains those portal integrations on your behalf.
The good news is that the data you collect for eligibility (patient demographics, insurance ID, provider NPI) is a subset of what you need for prior auth. Teams that design their intake flows with both workflows in mind can collect the clinical data needed for PA at the same time they verify coverage, rather than going back to the provider later when an authorization is triggered.
If you want to add prior auth submission to a product that already handles eligibility, Simplex provides managed endpoints for payer portal submissions. Send patient, provider, and clinical data; get back structured authorization results and session replays. You keep ownership of the eligibility layer and the clinical logic.