Insurance verification is a fixed sequence of ten checks. Confirm the plan is active on the date of service, that the rendering provider is in network for that product, which payer is primary, whether the planned code needs prior authorization, and what the patient will owe. A clearinghouse 270/271 answers part of this. A front desk has to close the rest.
The ten checks that belong before every visit
Insurance verification is not a single transaction. It is a short sequence of confirmations that happen before the patient is roomed, because each one has a failure mode that shows up later as a denial. Run them in the same order every time and the exceptions stand out.
- Confirm the plan is active on the date of service, not the day you call
- Read the effective date and, when a plan is ending, the termination date
- Identify the product type: HMO, PPO, EPO, POS, HDHP, Medicare Advantage or Medicaid
- Confirm the specific rendering provider is in network for that exact plan
- Match the member identifier to the payer’s own format, not last year’s card
- Run coordination of benefits and confirm which payer is primary
- Ask the Medicare Secondary Payer questions when Medicare is involved
- Check prior authorization and referral rules for the planned CPT or HCPCS code
- Confirm the benefit category that covers the service, including deductible and visit limits
- Estimate the patient’s financial responsibility and note what changed since the last visit
| Check | What you are confirming | Source that owns the answer | Can a 270/271 answer it? |
|---|---|---|---|
| Eligibility status | Whether the plan is active on the date of service | The payer’s eligibility system | Yes, active or inactive |
| Effective and termination dates | The exact coverage window | The payer’s eligibility system | Yes, when returned |
| Product type | HMO, PPO, EPO, POS, HDHP, Medicare Advantage, Medicaid | Plan documents and the member card | Partly, and often unclear |
| Network status | Whether this provider is contracted for this plan | The directory and your participation file | No, not reliably |
| Member identifier | Which number the payer will accept | The payer’s identifier format | Partly, if the ID is right |
| Coordination of benefits | Which payer is primary | The payers and the BCRC | Sometimes, via MSP data |
| Medicare Secondary Payer | Whether Medicare is primary or secondary | The MSP questionnaire and HETS | Yes, MSP data on HETS |
| Prior authorization | Whether the planned code needs authorization | The payer’s authorization list | No |
| Benefit category | Deductible, visit limits and exclusions | Plan benefit documents | Partly, as benefit data |
| Patient responsibility | What the patient will owe | Your fee schedule plus benefits | Partly, never a guarantee |
The right-hand column is the part most front desks get wrong. A clearinghouse eligibility response is a real answer to some of these questions and no answer to others. Treating the list as solved because the 270 came back active is how practices get a preventable denial.
Eligibility and effective dates come first, and a 270 does answer them
Eligibility is the payer’s statement that coverage was in force on a specific date. Active or inactive is the core answer, and a 270 request returns it with the benefit window the payer holds. CMS sets the Medicare HETS 270/271 date range at up to four years back and four months forward from the transaction date.
How far a Medicare 270 request will look
Source: CMS HETS 270/271 5010 Companion Guide.
A date problem is the denial you will recognize later. X12 code 27 reports expenses incurred after coverage terminated, which means the date of service fell outside the active window the payer holds. The current X12 code list states the wording, and the code is active. A terminated plan and a plan that has not started produce two different codes and two different fixes.
Read the effective date as well as the active flag. A patient who changed plans on the first of the month can be active on the new plan and terminated on the old one in the same breath, and the two records will disagree about the same visit.
Checking coverage as of today and accepting the patient next week leaves a gap. Re-run the check close to the appointment, because a plan that is active today can be terminated by the time the patient walks in.
What a 270/271 can answer, and what it cannot
The 270 is the eligibility inquiry and the 271 is the payer’s response. It pays to be precise about the boundary, because the transaction is narrow. The CMS companion guide states that the 271 is not intended to provide a comprehensive list of all benefits. It indicates eligibility status and patient financial responsibility for Medicare Parts A and B.
| Question the front desk asks | What the 271 returns | Where to confirm instead |
|---|---|---|
| Is the plan active on the date of service? | Eligibility status, usually active or inactive | Nowhere else, unless the response is unclear |
| Is this provider in network for this plan? | A benefit-level network indicator, not a contract check | The payer’s directory and your participation agreement |
| Does this code need prior authorization? | Nothing about authorization requirements | The payer’s own prior authorization list |
| What will the patient owe? | Deductible and coinsurance amounts when returned | The plan’s benefit documents and your fee schedule |
| Is another payer primary? | Medicare Secondary Payer data on Medicare responses | The CMS MSP questionnaire and the BCRC |
The CMS companion guide is blunt about this. The 271 response should not be interpreted as a guarantee of payment, and payment remains subject to all plan terms, limits, conditions, exclusions and the patient’s eligibility at the time of service. A clean eligibility check is a starting point, not an authorization to collect.
Medicare Advantage is the clearest example of the boundary. CMS advises providers to contact the plan directly to confirm a Medicare Advantage member’s eligibility information, because the plan, not Medicare fee for service, owns the benefit. The same logic holds for any commercial plan: the payer’s own documents own the coverage rules, and the 271 is a snapshot of one database.
Let the 270/271 settle eligibility and the money figures it returns. Let the payer’s provider manual settle network, authorization and coverage. Let the patient settle the history no database carries, such as a new job or an injury that may involve a third party.
Plan type, network status and the rendering provider
Product type changes everything downstream. An HMO usually needs a referral and a participating provider. A PPO pays out of network at a lower rate. A high-deductible plan collects the first several thousand dollars from the patient. Medicare Advantage replaces fee for service with the plan’s own rules. Read the product, not the payer’s logo.
Network status is the check the 271 cannot finish. A 271 can tell you whether a benefit is considered in network for the member’s plan. It cannot tell you whether this specific rendering provider holds a current contract for that specific product. That answer lives in the payer’s provider directory, your participation agreement, and the credentialing record for the provider and the group.
Verify the rendering provider, not the practice. In a group, one physician can be credentialed for a product while a new associate is still in the enrollment queue. Billing under a provider who is not yet participating in that product is a self-inflicted out-of-network claim, and it is worth a two-minute directory check before the schedule is set.

Credentialing and network status are the same question asked from two directions. A payer can list a provider as in network on the directory while the enrollment is still pending internally, and the claim will pay out of network. Credentialing services exist to keep the record and the directory from drifting apart.
Coordination of benefits and Medicare Secondary Payer
Coordination of benefits decides which payer is primary when a patient holds more than one plan. Get the order wrong and the claim goes to the wrong payer first, which is the denial X12 code 22 describes: this care may be covered by another payer per coordination of benefits. The X12 code list carries that wording today.
Medicare has its own version of the rule. The Medicare Secondary Payer provisions apply when another payer is primary to Medicare, and the statute requires every entity that bills Medicare to determine whether Medicare is primary for the service. The situations are specific and the thresholds are fixed.
| Situation | What makes Medicare secondary | Who pays first |
|---|---|---|
| Working aged | Age 65 or older with a group health plan through current employment at an employer of 20 or more employees | The group health plan |
| Disability | Disabled and covered by a large group health plan of 100 or more employees | The large group health plan |
| End-stage renal disease | ESRD with a group health plan during the first 30 months of Medicare eligibility | The group health plan |
| Retiree coverage | Age 65 or older with an employer retiree plan | Medicare |
| No-fault and liability | An accident where no-fault or liability insurance covers the services | The no-fault or liability insurer |
| Workers’ compensation | A work-related injury or illness | Workers’ compensation |
Employer size that makes a group health plan primary to Medicare
Source: CMS, Medicare Secondary Payer.
The questionnaire is how a practice establishes the facts. CMS publishes a model Medicare Secondary Payer questionnaire, and its intake tool describes six parts asked in sequence at each inpatient or outpatient admission. It is built to be followed in order, because the answers route the patient to the next set of questions.
Document what you find and keep it. The provider agreement at 42 CFR 489.20(f) requires a system that identifies primary payers during admission, and the CMS MSP manual recommends retaining that information for 10 years. The regulations themselves sit in 42 CFR Part 411 Subpart B, from sections 411.20 through 411.25.
For Medicare patients, some of this is available electronically. The CMS MSP manual notes that providers with online access can pull Medicare Secondary Payer information, including effective and termination dates and insurer details, through HETS or the Common Working File.
Prior authorization, benefit category and the patient estimate
Prior authorization is the check with no shortcut. The 271 does not report whether a specific planned code needs authorization. That answer lives in the payer’s own list. UnitedHealthcare, for example, publishes its commercial prior authorization requirements as a code-level list it updates monthly, so the copy you printed last quarter may already be stale.
Read the payer’s list against the exact codes you plan to bill. Most lists are organized by service category and CPT or HCPCS code, and they move by month, so the reliable habit is to open the live list before the service, per plan and per code.
The benefit category is the quieter failure. A service can be covered by the plan and still not covered by the benefit the patient actually holds. Physical therapy has a visit limit, preventive care may be carved out, and a service can fall under a deductible that has not been met. The 271 returns some of this as benefit data, and the plan documents own the rest.
The financial estimate is where the checks pay off for the patient. Take the allowed amount for the planned code, subtract the deductible that is still open, apply the coinsurance, then add any copay the plan sets for that service type. Give the patient the number before the visit so the balance afterward is not a surprise. Eligibility verification done early is what makes that number usable.
Close the loop with what changed since the last visit. Confirm the plan, the product, the members on the plan, the primary payer and the prior authorization vendor are all the same as last time, because each can move between visits and none sends a notice to your schedule.
What to ask any billing partner about verification
Any billing company can put a verification line on an invoice. Five questions separate the work that is real from the work that is a line item.
- Ask for your eligibility-related denial rate by payer for the last six months. Verification is working when code 27 and code 22 volume falls.
- Ask who checks network status for each new provider and how fast a directory change gets caught. That work sits between credentialing and billing.
- Ask whether prior authorization is checked against the payer’s live list or a saved spreadsheet. The live list is the only one that stays current.
- Ask how the patient estimate is built and when it is delivered. A number given at check-in is a collection problem, not a courtesy.
- Ask what gets pushed back to the front desk after a denial. Verification that never learns from denials repeats itself.
We run this front end as a service. Eligibility verification and prior authorization sit on top of full-cycle medical billing, so the people checking coverage are the same people who see the denials it prevents. When a payer changes a rule, the change reaches the schedule instead of a report. If denials are landing in categories these checks should have caught, start with the claim denial codes and work backward to the front desk.
Questions practices ask us about this
What is insurance verification and when should it happen?
Insurance verification is the set of checks a practice runs before a visit to confirm coverage, network status, coordination of benefits, authorization requirements and the patient’s cost. Run it close to the appointment rather than at booking, because coverage can change between the two dates.
Does a clearinghouse eligibility check confirm the provider is in network?
No. A 271 response can indicate whether a benefit is considered in network for the member’s plan, which is a benefit-level answer, not a contract check. It does not confirm that this rendering provider holds a current agreement for that exact product. Network status lives in the payer’s directory and your participation file, and it should be checked against the individual provider.
Can a 270/271 tell me whether a service needs prior authorization?
No. The eligibility transaction reports status and benefit figures, not authorization requirements. Whether a planned code needs authorization is set by the payer in its own prior authorization list, which many payers update monthly. Check the live list per plan and per code before the service, because a requirement can be added or removed between visits.
What is the Medicare Secondary Payer questionnaire and who completes it?
It is a model set of questions CMS publishes to identify payers that may be primary to Medicare. CMS describes it as six parts asked in sequence at each inpatient or outpatient admission, and the answers route you to the next part. Ask the patient or their representative to answer it, document the result, and update it when employment or coverage changes.
How far back will a Medicare eligibility check look?
The CMS HETS 270/271 system accepts a date span of up to four years in the past and up to four months in the future from the transaction date. That window matters when you verify a date of service that has already passed, or one that is scheduled. Dates outside the span come back as an error, not an eligibility answer.
What does claim adjustment reason code 27 mean?
Code 27 reports expenses incurred after coverage terminated, which means the date of service fell after the payer’s coverage ended. X12, which maintains the code list, has carried that wording since 1995, and the code is active. The paired group code decides the money: a PR prefix shifts the balance to the patient, while a CO prefix is a write-off you cannot bill.
How accurately can I estimate the patient’s bill before a visit?
You can get close for a defined service when the plan returns deductible and coinsurance data. Take the allowed amount for the planned code, subtract the remaining deductible, apply coinsurance, and add any copay the plan sets for that service type. The figure is an estimate, not a guarantee, so present it as one.
Want the front end checked before the next denial?
We verify eligibility, network status, coordination of benefits and prior authorization for practices across the country, then feed what we learn back into billing. Send us a few months of claims and we will show you which denials these checks would have stopped.
Book a free billing review- CMS, Medicare Secondary Payer (overview of primary and secondary payer rules). cms.gov/medicare/coordination-benefits-recovery/overview/secondary-payer
- CMS, Part A Other Insurer Intake Tool (the model MSP questionnaire). cms.gov/medicare/coordination-of-benefits-and-recovery/providerservices/partaotherinsurerintaketool
- CMS, Medicare Secondary Payer Manual, Chapter 3. cms.gov/regulations-and-guidance/guidance/manuals/downloads/msp105c03.pdf
- CMS, HETS 270/271 Health Care Eligibility Benefit Inquiry and Response 5010 Companion Guide. cms.gov/files/document/current-hets-270-271-companion-guide.pdf
- eCFR, 42 CFR Part 411 Subpart B, Insurance Coverage That Limits Medicare Payment. ecfr.gov/current/title-42/chapter-IV/subchapter-B/part-411/subpart-B
- CMS, Coordination of Benefits. cms.gov/medicare/coordination-of-benefits-and-recovery/coordination-of-benefits-and-recovery-overview/coordination-of-benefits/coordination-of-benefits
- UnitedHealthcare, Prior authorization and notification (provider requirements). uhcprovider.com/en/prior-auth-advance-notification.html
- X12, Claim Adjustment Reason Codes (current list). x12.org/codes/claim-adjustment-reason-codes