Insurance eligibility verification automation sends a 270 inquiry for each scheduled patient, reads the payer's 271 response, and sorts the results. Clean active coverage with matching plan details is marked verified with no human touch. Inactive coverage, member not found, other insurance, managed care plans and authorization flags go to a person before the visit.
What does insurance eligibility verification automation check?
Insurance eligibility verification automation checks whether a patient's coverage is active on the date of service, which plan it is, what the patient will owe and whether another payer comes first. It asks with an X12 270 inquiry and reads the answer from the 271 response. The schedule supplies the patients; the response supplies the facts.
What the 270 asks and the 271 answers
The X12 transaction set list describes the 270 as an inquiry "about the eligibility, coverages or benefits associated with a benefit plan, employer, plan sponsor, subscriber or a dependent." It describes the 271 as carrying "benefit status, explanation of benefits, coverages, dependent coverage level, effective dates, amounts for co-insurance, co-pays, deductibles, exclusions and limitations." HIPAA names this pair as the standard for the eligibility transaction. 45 CFR 162.1202 (eCFR, current as of 2026-10-14) has adopted the ASC X12 005010X279 version since January 1, 2012, and keeps it in the periods that follow; only the retail pharmacy standard changes, starting August 14, 2027.
A 270 has to identify four parties: the payer, the provider asking, the subscriber, and the patient if the patient is a dependent. The X12 270/271 example set shows that layout with a fictional payer, a clinic, a subscriber and a dependent child. The subscriber block needs a member ID, a name and a date of birth. Those come from the insurance card and the intake form; the guide to using member ID and group number for eligibility checks covers which card fields feed the request.
Which facts the automation records
A useful eligibility record stores five groups of facts: coverage status with the date range, the plan name and plan type, cost share (deductible, coinsurance and copay, with amounts met so far), other coverage that may be primary, and any authorization or limitation flags. The inquiry can ask about a general benefit or a specific service. The X12 service type code list defines code 30 as "Plan Coverage and General Benefits," a sensible default when the visit has no more specific service type.
Eligibility sits at the front of the revenue cycle, next to scheduling and registration. The post on the front-end revenue cycle steps shows where it fits and what it hands to the claim.
Scheduling batch eligibility verification before visits
Scheduling batch eligibility verification before visits means running one inquiry per scheduled patient a few days ahead, then a second check on the visit day. The early run leaves time to fix a wrong member ID or reach the patient about lapsed coverage. The same-day run catches changes that happened in between.
Choosing how far ahead
How many days ahead is a choice each office makes, not a rule. Pick a window long enough to call a patient and fix a record; two to five business days is a reasonable starting point to adjust from. A payer may limit how far forward it will answer. The CMS HETS 270/271 companion guide (version 15-1, May 2026), which describes Medicare's eligibility service, accepts requested dates "up to four years in the past and up to four months in the future." A request outside that range comes back with reject reason code 62.
Re-checking on the visit day
The same-day check should be quick and narrow. It confirms that coverage is still active and that nothing new appeared, such as another plan reported as primary. A result that matches the earlier one needs no one. A result that changed goes to the front desk before the patient is roomed.
Recurring patients
Recurring patients, such as weekly therapy visits or monthly infusions, tempt teams to check once and trust it for months. Coverage can end mid-month, and a new plan year can reset the deductible. A practical rule is to check at least once per calendar month and on the first visit after any plan year starts, in addition to the visit-day check. A fictional example: patient Dana Example, member ID EX-4471-02, has physical therapy every Tuesday. The batch runs each Friday for the next week, and the visit-day check runs Tuesday morning.
Reading 271 responses in automated eligibility verification
Reading 271 responses in automated eligibility verification means turning benefit segments into a few clear facts: active or not, which plan, what cost share, and whether anything needs attention. The fields that matter most are the benefit status code, the coverage dates, the plan type and the cost-share amounts.
The benefit fields that matter
Each benefit in a 271 sits in an EB segment. Its first element is the benefit status. The CMS HETS companion guide, as one documented example, uses EB01 "1" for periods of active Medicare entitlement and "6" for inactive coverage, and "U" when the beneficiary is enrolled in a Medicare Advantage plan. It returns deductibles with EB01 "C" and copayments with EB01 "B", each with a dollar amount. Coverage dates arrive in DTP segments next to the benefit. Other payers use the same segment structure but publish their own companion guides, so read the guide for each plan you check.
Vague and incomplete responses
Some responses look like an answer and are not. A 271 can say coverage is active without giving any cost share for the service you asked about. It can return only the general plan benefit when you asked about a specific service type. It can carry the plan name and a phone number in free-text MSG segments instead of coded fields. The HETS guide notes that it returns "only the most recent plan designation" for a Medicare Advantage contract, even if the plan type changed after the patient enrolled.
Treat a response as incomplete when any of the five fact groups from the first section is missing for the service on the schedule. Incomplete is not the same as bad. It means the result needs a person or a second inquiry with a more specific service type.
When the response is a rejection
A 271 can also reject the inquiry with an AAA segment instead of returning benefits. In the HETS guide, reject reason 72 means the member ID is invalid or cannot be matched, 73 means the last or first name did not match, 71 means the date of birth did not match, and 42 means the system was unable to respond. Codes 71, 72 and 73 point at data entry. Code 42 means try again later.
Which eligibility verification results need a person?
Eligibility verification results that need a person are the ones where the next step is a judgment or a phone call: inactive coverage, member not found, other insurance on file, a managed care plan and a flag that authorization is required. Everything else can be marked verified automatically with the response stored.
An exception routing table
The codes below follow the CMS HETS companion guide; other payers' values may differ. Names and member IDs are fictional.
| 271 result | What it means | Automated action | Who handles it |
|---|---|---|---|
| EB01 = 1, dates cover the visit, cost share returned | Active coverage with usable detail | Mark verified, store the response, post the copay to the visit | No one |
| EB01 = 6 for the requested date | Coverage not active on that date | Hold the visit in a queue, flag the account | Front desk calls the patient for new coverage |
| AAA 72 (member ID not found) | The ID sent does not match the payer's records | Re-check the ID against the scanned card once | Registration staff compare the card image to the record |
| AAA 71 or 73 (birth date or name mismatch) | Demographics differ from the payer's file | Queue with the field that failed | Registration staff confirm with the patient |
| EB01 = R with other payer details | Another plan may pay first | Do not set primary automatically | Billing staff confirm coordination of benefits |
| EB01 = U, Medicare Advantage plan listed | The patient is in a managed care plan | Route to check plan network and billing rules | Front desk or authorization staff contact the plan |
| EB11 = Y for a scheduled HCPCS code | The payer flags prior authorization | Hold scheduling confirmation | Authorization staff request approval |
| AAA 42 (unable to respond) | The payer's system did not answer | Retry automatically later the same day | No one, unless retries fail |
A fictional example: Lee Sample, member ID EX-90812, is scheduled for Thursday. The Monday batch returns EB01 = R with an employer plan listed as primary. The automation does not change the payer order. It puts the visit in the billing queue, where a person calls the patient, confirms the employer plan and updates the record before Thursday.
Why these results need a person
The HETS guide states that the prior authorization indicator "is informational only and is in no way a guarantee of coverage or payment." For Medicare Advantage it says CMS "strongly recommends" contacting the plan directly to confirm eligibility. For other primary coverage it returns details such as policy number and enrollment dates, which a person compares with what the patient reports. In each case the response starts the work; it does not finish it.
Registration mistakes caught here are cheaper than the denials they become later. The post on which denial reasons trace back to registration lists the codes that appear when these results are missed.
When eligibility verification automation reports active coverage that is wrong
Eligibility verification automation can report active coverage that turns out to be wrong. The three usual causes are a retroactive termination entered after the check, a benefit carved out to a separate vendor, and a patient billed under the wrong plan. Each passes the automated check and fails at the claim.
Retroactive terminations
An employer or plan can end coverage after the fact. The check on the visit date said active; a later update moved the end date back. The claim then comes back with the X12 reason code 27, "Expenses incurred after coverage terminated," from the claim adjustment reason code list. The HETS guide warns that its response is "based on information obtained from the CMS database at the time of inquiry and should not be considered a guarantee of payment." Keep the stored 271 with its date and time, because it shows what the payer said when you checked.
Carved-out benefits
Some plans hand a benefit, such as behavioral health, vision or pharmacy, to a separate company. The medical plan's 271 says active, and it is, but not for that service. A general benefit inquiry with service type 30 will not reveal this. Send the inquiry with the specific service type for the visit, and route any response that names a different administrator to a person.
The wrong plan on file
A patient can have two active plans, or a new card the office never scanned. The check against the old plan can still come back active, for example if the patient kept a spouse's plan as secondary. The claim then goes to the wrong payer and is denied with code 22 ("may be covered by another payer per coordination of benefits") or code 109 ("not covered by this payer/contractor"). If the first payer paid before the error was found, the result is a credit that must be returned; the guide to credit balance and patient refund processing covers that cleanup.
Feeding the request with clean data
Many of these failures start with a member ID or birth date keyed wrong from an intake form or card copy. Schema Care reads patient intake forms, including the insurance section, into structured fields with a confidence score on each one. A field it is unsure of goes to a person who checks it against the highlighted page before it reaches the record. It does not send 270 inquiries or verify coverage itself.
If eligibility is your first automation project, the scoring worksheet in where to start automating the revenue cycle helps compare it with other tasks. Mismatches between the coverage verified and the charges billed are also a monthly check in revenue integrity basics.