Eligibility returns 'patient not found' for a clearly covered patient

Stop retyping the member number. A not-found response means the payer could not match the person you described to a record it holds — it is a statement about your identifiers and your routing, not about the patient's coverage. Re-run the identical enquiry with the smallest identifier set the payer will accept, usually the member number plus date of birth. If it comes back clean, one of the fields you just removed is wrong, and you have gone from 6 candidate causes to 1 without a phone call.

This works because eligibility matching is conjunctive. The payer is not scoring a fuzzy similarity; it requires the identifiers you sent to agree with the enrolment record, and any 1 disagreement produces the same flat answer. Sending 6 fields instead of 2 makes a match less likely, not more — the opposite of the reflex at the desk, which is to add the middle name, the group number and the address until something sticks.

Ask again with less, and read the rejection reason rather than the screen

Two things must be visible before this is diagnosable. The first is the exact payload sent, not the form the receptionist filled in — clearinghouses and practice systems normalise names, truncate long ones to whatever the transaction allows, and append suffixes on the way out. The second is the payer's own rejection reason, which distinguishes an invalid or missing subscriber identifier from a subscriber it cannot find, and which most front-desk software hides behind 1 red banner reading unable to verify.

1. Capture the outbound payload verbatim. If your system cannot show it, fix that first — everything below is guesswork without it.
2. Re-run with member number and date of birth only. A clean response localises the fault to a name, a suffix or an extra identifier you were sending.
3. Re-run with surname and date of birth, dropping the member number. Success here says the number on the card is wrong, mis-keyed or belongs to a different member of the family.
4. Re-run against the subscriber rather than the patient, using the subscriber's own date of birth and the relationship field. Success means the record exists and was indexed under somebody else.
5. Check the payer identifier you routed to against the one printed on the card, including any separate identifier for the plan administrator. A well-formed enquiry sent to the wrong entity fails exactly like a bad name.
6. Only if all 4 re-runs fail, call the payer — and record the trace reference the payer gives you against the appointment, so the next person does not repeat the whole sequence.

6 reasons a live policy comes back unknown, most common first

The ordering matters more than the list. The first 3 are per-patient and resolve at the desk in 2 minutes. Causes 4 and 5 are systemic, hit every patient on that plan, and stay invisible while you look at 1 failure at a time — which is why the most valuable report here is a daily count of failed enquiries grouped by payer. A payer that fails 40 enquiries in a morning is not 40 unlucky patients.

Dependants are not indexed under their own name

This is the cause most likely to be misread as a payer fault. Coverage is held against a subscriber — the employee, the policy holder, the member who bought the plan — and everyone else on the policy hangs off that record as a dependant. Ask about a 6-year-old using the child's name and date of birth against the family member number and a strict payer will correctly report no match, because the identifier you sent belongs to the parent.

Two consequences follow for the registration record. It has to carry the relationship to the subscriber as a real field rather than an assumption, and it has to be able to hold subscriber details that are not the patient's own — a different name, a different date of birth, sometimes a different address. Where those fields do not exist, the desk works around them by typing the parent's name into the patient's record, which fixes eligibility today and corrupts the chart permanently. That trade-off is exactly what the fields a registration must carry before a first visit is real is for.

Adding identifiers to a failing eligibility enquiry makes it fail harder. The match is conjunctive: every extra field is one more thing that has to be exactly right.

A perfect enquiry sent to the wrong payer fails identically

Most systemic failures are routing. The identifier that decides which payer receives the enquiry is not the plan name a patient reads off the card, and the entity administering benefits is frequently not the entity whose logo is printed on it. Self-funded employer plans, plans rented onto another network, and blocks of business moved between administrators all produce a familiar card over a routing identifier that changed underneath it.

The signature is unmistakable once you look for it: unrelated patients, same plan, same day, all failing. The fix belongs in the payer mapping table rather than in any individual enquiry, and it needs an owner — because a mapping table nobody maintains is how a clinic ends up running a permanent manual workaround for one insurer. Card capture is upstream of all of this, and a routing identifier read from a glare-covered photograph is a routing identifier that will be wrong: the loop for that is in reading an insurance card from a bad phone photo.

Where each finding sends the work next

• Re-key at the desk. Name, date of birth or member number wrong on a single patient. Resolve now, from the card, and update the record so the next enquiry inherits the correction.
• Subscriber lookup. The patient is a dependant. Capture the subscriber as a first-class record; do not overwrite the patient's own identity to make the check pass.
• Routing correction. A cohort fails together. Fix the payer mapping, then re-run the whole failed cohort rather than waiting for those patients to arrive.
• Call the payer. All 4 re-runs failed. Record the trace reference and the answer against the appointment so the call is never made twice.
• Re-capture coverage from the patient. The card is stale. This is the only branch where the correct next action is a conversation rather than a correction.

Whichever branch it takes, the item needs a state and an owner until it closes. An unresolved eligibility failure behaves exactly like an unacknowledged clinical result: somebody has to be responsible for it reaching a conclusion, and the system has to know whether it did. The pattern is the same one described in closed-loop notification for a critical finding — sending is not the same as being received, and being received is not the same as being acted on. Referred patients raise the same question at the front of the pipeline, where coverage details arrive with the referral and are already weeks old by the time anybody books, which is one reason referrals sit unbooked with nobody able to tell which.

The boundary: a clean check that still ends in a denial

Everything above is about getting an answer. What the answer means is a separate question, and confusing the 2 is how clinics conclude that eligibility checking does not work — an active-coverage response is a membership fact and nothing more, which is the argument in what an eligibility response tells the front desk and what it does not. A visit that verified cleanly and was denied afterwards is not a desk problem at all; it belongs with revenue cycle, prior authorisation and denials, where the relevant failure is an authorisation that was approved and a claim that was denied anyway.

One last structural point. Eligibility is triggered by booking, and bookings now arrive from a portal, a phone agent and the desk at once. If any channel can create an appointment without capturing the identifiers a check needs, that channel manufactures not-found failures — the same cross-channel discipline problem that lets a phone agent book into slots that were already taken. The fix is small and self-contained: a payload log, a re-run ladder, a payer mapping table with an owner, and a queue with a close condition — the shape of an MVP and product build, sitting inside front desk, intake and patient access within a healthcare operations programme.

• eligibility
• patient access
• front desk
• identity matching