The remittance arrives on a Tuesday with fourteen denials from one payer. Six are CO-31, patient cannot be identified as our insured. Four are CO-27, expenses incurred after coverage terminated. Three are CO-22, this care may be covered by another payer. One is CO-140, the identification number and name do not match. The billing team will spend most of the afternoon on the phone and in portals, and when they are done they will have learned that a middle initial was entered as a first name, that a patient switched plans in January and nobody asked, that a retiree has Medicare and a spouse's employer plan and nobody asked that either, and that a card was scanned upside down and never read.
Every one of those denials was decided at the front desk weeks earlier. None of them is a billing problem in the sense that billing can prevent them. Billing can only clean up after them, slowly, while the timely filing clock runs. That is why, when we are asked to fix a denial rate, we usually start at the check-in window rather than in the billing office.
Front desk workflows prevent denials by getting four things right before the visit starts: the patient's identity exactly as the payer holds it, the active coverage for the date of service including any secondary plan, the authorization or referral the payer requires for the service, and the patient's financial responsibility collected at the time of service. Done consistently, these four steps remove the registration and eligibility denials that make up a large share of first-pass rejections at most practices. This playbook assigns each step to a role, shows the hand-offs between roles, and gives the numbers a manager should watch.
Scheduler: the visit starts here, not at check-in
The scheduler's job is to collect the data that makes the eligibility check possible and to set the appointment type that tells everyone downstream what to expect. The exact steps for a new patient are: record the legal name as it appears on the insurance card (not the preferred name, which goes in a separate field), date of birth, sex as the payer records it, address and phone; collect the insurance name, member ID, group number and the subscriber's name and date of birth if the patient is a dependent; ask the two questions that find secondary coverage ("Do you have any other insurance, including through a spouse or parent?" and, for patients over 65 or disabled, "Are you or your spouse still working, and is there an employer plan?"); and record the reason for the visit in enough detail to know whether it needs an authorization or a referral.
For an established patient the scheduler confirms, rather than re-collects: "Is your insurance still the same plan you had at your last visit?" is the one question that catches most January changes. The scheduler also sets the appointment type correctly, because the appointment type drives the eligibility batch, the time-of-service estimate and the charge expectation. A procedure booked as a routine follow-up will not trigger the authorization check.
What the scheduler hands off: a complete demographic and insurance record flagged "verify", an appointment type that matches the service, and a note on any coverage question the patient could not answer. What the scheduler should never do is guess a payer from a description over the phone. "Blue Cross" is a dozen different payers with different payer IDs; ask the patient to read the payer name and claims address from the back of the card, or send a secure link to upload a photo of it.
Pre-visit verification: the 48-hour check
Whoever owns pre-visit verification (in a small practice this is often the same person who checks patients in, working the next two days' schedule each afternoon) runs the eligibility check for every scheduled visit one to two business days ahead. The check is the HIPAA 270/271 eligibility transaction through the practice management system or clearinghouse, or the payer portal where the transaction is not available. For Medicare patients the response comes from the CMS HIPAA Eligibility Transaction System, which returns Part A and B effective dates, Medicare Advantage enrollment, deductible status and whether another payer is primary.
The steps are the same every time. Confirm the plan is active on the date of service, not just today. Read the plan type and network: an HMO response means a referral is probably needed, and a Medicare Advantage flag on a patient registered as traditional Medicare means the claim will go to the wrong payer. Record the copay for the visit type, the remaining deductible and the coinsurance. Check the response for other insurance; many 271 responses carry a coordination of benefits segment that names the primary payer. Then look at the service: if the reason for visit is a procedure, an imaging order, an injection of a specialty drug or a visit type the payer lists, run the prior authorization lookup for that payer and either confirm an authorization is on file with its number and date range or open a task for clinical staff to obtain one.
What verification hands off: a visit flagged "verified" with the copay and estimated responsibility written into the appointment, or flagged "problem" with a specific reason (inactive, different plan, authorization needed, referral needed, other payer primary). Problem flags go to the patient by phone or portal message before the visit, not at the window. In our experience calling the day before resolves most inactive-coverage visits either by getting the new card information or by rescheduling, and the patient is far less upset than when told at check-in.
Check-in: the last chance to fix the record
Check-in confirms identity, scans the card, collects the money and catches what the batch check could not. The steps: ask the patient to state their name and date of birth (do not read it to them and ask for a yes); compare the photo ID to the person and the insurance card to the registration record field by field, including the member ID suffix, which identifies the dependent on many commercial plans; scan the front and back of the card into the record at every visit where anything has changed and at least once a year regardless; confirm address and phone; and ask the coverage question again in plain words: "Any other insurance we should know about?"
For Medicare patients, confirm the Medicare Beneficiary Identifier on the card matches the record exactly. The MBI is eleven characters of numbers and uppercase letters, and it never uses the letters S, L, O, I, B or Z, so a record with an O where a zero belongs will deny with CO-140 or CO-31. For patients with Medicare and an employer plan, the Medicare Secondary Payer questions decide which payer is billed first: is the patient or spouse actively employed with group coverage, is the visit related to an accident or a workers' compensation claim, is there end-stage renal disease coverage in a coordination period. Hospitals are required to ask these questions; physician offices are not, but the office that skips them earns the CO-22 denials.
Then the money. Collect the copay shown on the eligibility response before the visit, every time, and collect against the remaining deductible for scheduled procedures where the practice's financial policy allows an estimate. Post the payment to the right encounter at the moment it is taken, give a receipt, and record the payment method. Unapplied cash is a billing problem created at the front desk. What check-in hands off: a patient arrived in the system with a verified record, a scanned card, a posted time-of-service payment and any new flags for billing (new secondary plan, accident-related visit, patient declined to pay).
Clinical staff: authorizations, referrals and the order that changes the visit
Clinical staff own the authorization and referral work that the front desk cannot do because it requires clinical information. When verification flags a visit as needing an authorization, the medical assistant or nurse submits the request with the diagnosis, the planned CPT code, the clinical notes the payer requires and the date range, then records the authorization number, the approved codes and units and the valid dates in the field the billing system reads, not in a free-text note. If the payer requires a referral from a primary care provider, clinical staff confirm it is on file with the payer and that it names the correct rendering provider and the right number of visits.
The second responsibility is the order that changes the visit. A patient scheduled for a follow-up who ends up needing a joint injection, an in-office procedure or a specialty drug has just changed the authorization requirement in real time. The step here is a quick check: before performing a service that commonly requires authorization, ask whether an authorization exists, and if not, either obtain it (many payers can turn around urgent requests the same day) or have a direct conversation with the patient and the provider about proceeding without it. The CO-197 denial, authorization absent, is the one that is hardest to overturn after the fact.
What clinical staff hand off: authorization and referral numbers in structured fields with dates and units, a note on any service performed without authorization and why, and the superbill or charge set that matches what was actually done so billing can see whether the authorized codes and the billed codes agree.
Billing: the feedback loop
Billing cannot prevent registration denials, but billing is the only role that sees them in aggregate, and that makes billing responsible for the feedback loop. The steps: run the claim scrubber before submission and return every registration edit (invalid member ID format, missing subscriber date of birth, payer ID mismatch) to the front desk the same day with the patient name and the fix needed; sort incoming denials by claim adjustment reason code weekly and separate the front-end codes (CO-16 with a registration remark, CO-22, CO-27, CO-31, CO-109, CO-140, CO-197) from everything else; and work those denials by correcting the record first, so the next visit is clean, then correcting the claim.
Once a month, billing produces a one-page report for the practice manager: front-end denials by reason code, by location and by the staff member who registered the patient, with the three most common root causes written in plain words. "Secondary coverage not captured for Medicare patients with working spouses" is a finding the front desk can act on. "CO-22 up 12 percent" is not. The denial code lookup helps translate unfamiliar codes and remark combinations into the plain-words version.
Billing also owns the payer file. When the front desk picks the wrong "Blue Cross" from a list of nine, the list is the problem. A clean payer master file with one entry per plan and the payer ID the clearinghouse expects prevents a whole category of CO-109 denials, claim not covered by this payer.
Provider: three habits that keep the front end honest
Providers do not register patients, but three provider habits decide whether the front desk's work survives the visit. First, document the diagnosis to the specificity the authorization and the payer policy require; an authorization for a knee injection with a specific diagnosis does not cover a claim coded to an unspecified joint pain code. Second, tell clinical staff before performing an unplanned service that may need authorization, rather than after. Third, when the schedule says follow-up and the visit becomes a procedure, let checkout know so the time-of-service estimate and collection can be updated before the patient leaves.
Providers also set the tone on collections. "Don't worry about the copay today" undoes the front desk's work and the financial policy in one sentence; "the front desk can walk you through what your plan covers" keeps the financial conversation with the people trained for it.
Practice manager: the numbers and the training
The manager's steps are weekly and monthly. Weekly: look at the verification completion rate (scheduled visits with a verified flag before the day of service), the problem-flag resolution rate (how many were resolved before the patient arrived) and the time-of-service collection rate (copays collected divided by copays due). Monthly: read billing's front-end denial report, pick the top root cause, and fix it with a specific change (a script, a field made mandatory, a payer file correction, a retraining) rather than a general reminder to be careful. Quarterly: audit twenty registrations against the scanned cards for field-level accuracy, and re-run the front desk training module on whatever the audit finds.
The manager also decides what the system enforces: a mandatory subscriber date of birth when the relationship is not "self", a card scan before check-in completes, a block on check-in when eligibility is unverified, and a payment or a documented reason before the encounter closes. Each setting removes a conversation the manager would otherwise have later.
The hand-off table
| From | To | What is handed off | When | How the receiver knows it is complete |
|---|---|---|---|---|
| Scheduler | Pre-visit verification | Legal name, DOB, insurance details, subscriber details, reason for visit, appointment type | At booking | Record flagged "verify"; no required field blank |
| Pre-visit verification | Check-in | Eligibility result, copay and deductible, network type, other-payer flag, authorization status | One to two business days before the visit | Visit flagged "verified" or "problem" with a reason |
| Pre-visit verification | Clinical staff | Authorization or referral task with diagnosis, planned code and date | As soon as the need is identified | Task assigned with a due date before the visit |
| Check-in | Clinical staff and provider | Patient arrived, card scanned, payment posted, new flags (secondary plan, accident, declined payment) | At arrival | Arrival status set; flags visible on the encounter |
| Clinical staff | Billing | Authorization number, approved codes, units and dates in structured fields; charge set matching services performed | Before the encounter is closed | Authorization field populated; charges present |
| Billing | Front desk and manager | Scrubber edits same day; weekly front-end denial list; monthly root-cause report | Daily, weekly, monthly | Each edit has a named owner; report lists three actionable causes |
| Manager | All roles | Process changes, system settings, retraining on audit findings | Monthly and quarterly | Change written into the workflow document with a date |
What good looks like
In a practice where this playbook is running, eligibility is verified for 98 percent or more of scheduled visits before the day of service, and the few that are not are same-day add-ons checked at the window. Problem flags are resolved before arrival at least four times out of five. Time-of-service collection runs at 90 percent or better of copays due, and unapplied payments at month end are a short list with names rather than a balance. Front-end denials (CO-22, CO-27, CO-31, CO-109, CO-140 and registration-related CO-16) fall below two percent of claims submitted and keep falling, because each month's report removes a root cause. The card scan is current for every active patient, the subscriber fields are complete on every dependent record, and the payer master file has one entry per plan. The first-pass acceptance rate at the clearinghouse sits in the high nineties, which is where the billing team wants it so they can spend their time on the denials that need clinical judgment rather than on retyping a member ID.
Questions we hear
How far ahead should eligibility be checked?
One to two business days before the visit, and again on the day of service for anything that was flagged. Checking a week out gives you a result that may change (coverage terminations are often effective at month end), and checking only at the window leaves no time to resolve a problem. For Medicare patients, the HETS response reflects enrollment as of the query, so a same-day recheck for scheduled procedures is cheap insurance. Many practices run a batch for the next two days each afternoon and a quick same-day batch each morning.
Do we really need to scan the card at every visit?
Scan whenever anything has changed and at least once a year regardless. The card is the evidence when a claim denies for an identification mismatch, and it is where the payer ID, the claims address, the plan name and the dependent suffix live. A practice that relies on a card scanned three years ago is relying on a plan that may no longer exist. Asking "has anything changed?" is not enough on its own; many patients do not know their employer switched carriers until they are told at the pharmacy.
What do we do when a patient has two plans and we are not sure which is primary?
Ask the questions, record both plans, and bill the one the rules say is primary rather than the one the patient thinks is primary. For commercial-to-commercial, the birthday rule usually decides for dependents and the subscriber's own plan is primary for the subscriber. For Medicare, the Medicare Secondary Payer rules decide based on employment status, employer size, disability and ESRD, and CMS's Benefits Coordination and Recovery Center maintains the record Medicare uses. When the primary payer denies with CO-22 and names another payer, correct the coordination of benefits with the patient and both payers before rebilling, or the same denial will come back.
How should the front desk handle a patient who cannot pay the copay?
Follow the financial policy, which should already say what happens: offer a payment plan or a card on file, document the conversation and the reason, and never quietly waive the copay, because routine waivers of cost sharing create compliance problems with federal programs and contract problems with commercial payers. The front desk should have the script ready and the authority to offer the options in the policy without calling a manager. What the front desk should not do is decide on its own that this patient does not need to pay.
Which denial codes tell us the front desk workflow is failing?
CO-31 (patient cannot be identified as our insured) and CO-140 (identification number and name do not match) point to registration accuracy. CO-27 (expenses incurred after coverage terminated) and CO-26 (before coverage) point to eligibility verification. CO-22 (another payer may be primary) points to the coverage questions. CO-109 (not covered by this payer) often means the wrong payer entry was selected. CO-197 (authorization absent) points to the authorization hand-off. CO-16 with a remark code about the subscriber or the insured's identification points to incomplete dependent records. Sort denials by these codes monthly and the front-end story tells itself.
Sources and references
- HIPAA Eligibility Transaction System (HETS), CMS: how real-time Medicare eligibility inquiries (270) and responses (271) work, who can connect, and what the response contains.
- Eligibility Inquiry, CMS Medicare Electronic Billing and EDI: the Medicare fee-for-service guidance on submitting eligibility inquiries and reading the results.
- Coordination of Benefits, CMS: how Medicare determines primary and secondary payers and the role of the Benefits Coordination and Recovery Center.
- New Medicare Card, CMS: the Medicare Beneficiary Identifier format and the rules for using the MBI on claims, appeals and eligibility checks.
- 270/271 Health Care Eligibility Benefit Inquiry and Response (005010X279), X12: worked examples of the eligibility transaction that practice management systems and clearinghouses send and receive.
- Claim Adjustment Reason Codes, X12: the official list and definitions of the CARC codes, including the registration and eligibility codes discussed in this article.
- Administrative Simplification, CMS National Standards Group: the HIPAA transaction standards, operating rules and code set requirements that govern eligibility and claims exchanges.
