How Real-Time Eligibility Checks Actually Work

A real-time eligibility check is an X12 270 request your system sends to a payer and the 271 response that comes back, usually in seconds. It confirms whether a patient's coverage is active on a given date, and it returns whatever benefit detail the payer chooses to share: copay, deductible, out-of-pocket maximum, network status. It does not promise payment.

Quick answer:

• The 270 asks one payer about one person on one date. The 271 is that payer's answer, parsed onto the patient record as a status plus a list of benefit lines.
• A 271 tells you who is covered. It does not tell you what is payable, which is why a check can pass and the claim can still be rejected or denied.
• Eligibility is the highest-volume transaction in any billing operation. In Ona it runs on the patient record, and the Ona Clearing House plans include 200 checks a month on Starter up to 3,750 on Scale.

The two messages: a 270 out, a 271 back

Strip away the interfaces and an eligibility check is one question and one answer, in a format every US payer understands.

The 270 is the question. Your system packages five things: the payer, the subscriber's member ID, the patient's name and date of birth, the date of service, and a service type code saying what kind of care you are asking after. Service type 30, health plan benefit coverage, is the general one most checks use.

The 271 is the answer, back in seconds rather than the hold music a phone call costs: whether coverage is active, which plan, which network, and a list of benefit lines covering deductibles, copays, coinsurance and limits. Both numbers are X12 transaction types, the standard electronic envelope US payers accept, the same family that carries the 837P professional claim your billing eventually sends.

That standardization is the point. Without it, verifying coverage means a different portal and login for every payer you bill. With it, one request format reaches all of them, and the answers come back in a shape software can parse and file.

In Ona this switches on with insurance itself. One toggle activates real-time eligibility checks, 270 and 271, and claim submission, 837P, because both draw on the same organization data: billing NPI, Tax ID and legal name. See setting up insurance.

What the payer actually sends back

A parsed 271 is longer than most people expect. One response can carry dozens of benefit blocks, each a statement about one benefit rather than a tidy summary.

On the Ona patient record the result shows as a badge in the patient header, reading Insurance Eligible, Ineligible or Unknown, and the same badge appears in the Insurance column of the Visits list so a front desk can scan a whole day for coverage problems before anyone arrives. Clicking it opens the Eligibility Check panel, which stacks four things.

The summary. Status is the overall result. Coverage is whether coverage itself is active. Those are separate fields and they can disagree. Alongside them sit the service type code the check ran for, the date the result was retrieved, and the date it expires.

The policy on file. Member ID, payer ID, group number, and who holds the policy. That last one matters more than it looks: the insured differs from the patient whenever a child sits on a parent's plan, and getting it backwards reliably generates a rejection.

Scripts and authorizations. Where prior authorizations are recorded so they are attached when the claim is built, rather than remembered by one person.

The benefits. This is the parsed 271 itself, and each block carries a coverage code, a benefit type, an insurance type such as commercial, a coverage level such as family or individual, a time period such as year to date, a network flag, an amount, and sometimes free text from the payer. Two fields change what every dollar figure means. Level tells you whether a deductible is the family one or the individual one. Network tells you whether a copay is the in-network figure or the out-of-network figure. Read a number without reading those two and you will quote the patient the wrong amount with complete confidence.

Full detail on reading a response is in reading eligibility results.

What a 271 does not tell you

This is where the disappointment lives, so it is worth being blunt about the limits.

Payers return what they feel like returning. Some send a rich benefit breakdown. Others send little more than an active flag. A sparse response reflects that payer's habits, not a fault in the software asking.

It is a snapshot with an expiry date. A 271 carries a valid-until date, and coverage can lapse mid-month regardless. A check run in June for a visit in August is decoration.

It is not an authorization. A 271 can say a service requires prior authorization. It cannot give you one. Those are different transactions on different timelines: a machine answering in seconds, against a payer review taking days.

It is not a quote, and it is not a guarantee of payment. A complete benefits list describes the plan's structure, not what this visit costs once the plan applies its own logic to your codes. No payer treats an eligibility response as a commitment.

Why a check passes and the claim still fails

An active 271 means the person is covered. The claim is judged on everything the eligibility check never asked about, which is most of what a claim contains.

Separate the two ways a claim comes back, because the fix differs. A rejection bounced before adjudication, usually a format or data problem, so you correct it and resubmit. A denial was adjudicated and refused, a coverage or clinical decision, so the route is appeal or patient billing. Mixing them up is the most expensive habit in a billing queue: appealing a rejection and resubmitting a denial both waste days.

The common reasons a verified patient still produces a failed claim:

• Identity mismatch. A transposed digit in the member ID, or a date of birth the payer's record disagrees with. This also causes Ineligible and Unknown badges, so it usually shows up at the check rather than the claim.
• Provider identifiers. The rendering NPI, the Type 1 identifier for the clinician who delivered the care, has to match the national registry; one the payer cannot match is a common cause of rejection. Ona validates these against NPPES and flags any it cannot find.
• The wrong taxonomy. A clinician can hold several taxonomy codes and only the primary one goes on claims. Rendering, billing and service facility taxonomy are three separate fields describing three separate parties on the same claim.
• Coding gaps. A claim without a linked diagnosis code usually rejects. So does a billable code with no units on it.
• No note behind the visit. Billing without documentation is what audits look for, so Ona's note-required-per-visit rule is on by default and blocks the claim until the note is signed.
• The filing deadline. Every payer sets its own, and a claim submitted after it is unpayable regardless of merit. Ona can warn you before a payer's deadline passes.
• Missing enrollment. Connecting a clearinghouse is not the same as being authorized to transact with a given payer. Enrollments take weeks, often two to six, and some payers still want paper.
• Prior authorization that was required and not obtained. The 271 may have told you. The claim will certainly tell you.

The practical response is to catch these before submission. Ona scrubs every claim against configurable billing rules, and a custom rule can warn, silently correct, or block submission outright. Rules cascade from organization-wide defaults down to insurance-type and payer overrides, so one unusual payer does not force you to loosen the rule for everyone. See scrubbing claims with billing rules and working the claims queue.

Where the check should run

Every option below sends the same 270 and reads the same 271. What differs is where the answer lands, and that is the only axis ranked here. It is not a quality ranking, and it is not a price ranking. What separates the rows is where your team already works and how far the answer travels on its own.

Where the 271 lands	Platform	What you get	What it does not do	Best fit
1. On the chart that becomes the claim	Ona	Badge on the patient header and in the Visits list, parsed benefits on the record, prior authorizations attached, and the same record produces the superbill and the claim	Not a standalone purchase: eligibility runs through Ona Clearing House or a connected Claim.MD account, on top of seats	Ambulatory practices of any size running coverage, care and billing on one system
2. In the EHR through a billing integration	Healthie	Real-time eligibility results displayed in the chart through the Claim.MD integration	Eligibility is not native to the base plans; it arrives with a paid integration on top	Practices already on Healthie that want eligibility without leaving it
3. In a clearinghouse portal	Claim.MD	Eligibility, claims and ERA in one billing system with published per-transaction rates and included volumes	Lives beside the chart, so results are read in one system and acted on in another	Billing teams who work in the clearinghouse all day
4. In a payer portal	Availity Essentials	Real-time eligibility, claim status, remittance and appeals across the payers that sponsor the portal, free to providers	Payer-sponsored coverage; reaching non-sponsoring payers needs the paid Essentials Plus subscription	Practices whose payer mix already pushes them into the portal
5. In your own code	Stedi	Direct API access to the 270 and 271 with per-transaction pricing, no monthly minimum, and a signed BAA	Ships you a response, not a workflow. Everything downstream is yours to build	Teams with engineers assembling their own billing stack

Two footnotes. Ona Clearing House runs on Stedi, with no separate Stedi account, contract or bill on the practice's side, so rows one and five are the same pipes at different layers. And a practice already submitting through Claim.MD can connect that account to Ona with an API key rather than re-enrolling with every payer. See setting up your clearinghouse, where Waystar and Office Ally are listed as coming soon.

Sizing eligibility volume honestly

Eligibility is the highest-volume transaction a billing operation runs, and practices underestimate it because checks are not one per patient. They get re-run when a result expires before the visit, when a member ID is corrected, when a patient adds secondary coverage, and when the front desk verifies tomorrow's list.

That is why every Ona Clearing House plan carries more eligibility checks than claims: 200 checks against 100 claims on Starter at $69 a month, 500 against 250 on Core at $149, 750 against 500 on Practice at $249, 1,500 against 1,000 on Growth at $499, and 3,750 against 2,500 on Scale at $1,099. Every plan includes unlimited providers and payer enrollments, higher volumes are quoted individually, and cash-pay practices need no plan at all. Current numbers sit on the pricing page.

Ona is a general ambulatory EHR that scales from solo clinicians to multi-location groups and enterprise systems, which is how the homepage FAQ puts it: Ona scales from solo clinics to enterprise systems. Eligibility works the same way at every size, because the transaction is the same transaction. What changes is volume and who watches the queue. The only work Ona is not built for is inpatient and hospital workflows.

Frequently asked questions

What does a real-time eligibility check actually do?

It asks one payer, electronically, whether a named person is covered by a named plan on a given date, and it stores the answer. The payer returns coverage status plus whatever benefit detail it chooses to share: copay, deductible, out-of-pocket maximum, network status, plan type. It is a lookup, not an approval.

What is the difference between a 270 and a 271?

They are the two halves of the same conversation. The 270 is the question your system sends: this patient, this payer, this member ID, this date, this service type. The 271 is the payer's answer. Both are X12 formats, the standard electronic envelopes payers accept, so the same request works across payers instead of needing a different portal for each.

Why did my claim get denied when eligibility came back active?

Because an active 271 answers who is covered, not what is payable. The claim is judged on everything the eligibility check never saw: the codes, the diagnosis linkage, the rendering provider, the place of service, the filing deadline, and whether the service needed prior authorization. Coverage being live is the floor, not the decision.

How long is an eligibility check good for?

Only as long as the payer says. A 271 carries a valid-until date, and an eligibility result is a snapshot of what the payer said on a given day, not a standing guarantee. Coverage can lapse mid-month. If the visit is well after the check, or the result is close to expiring, run it again rather than trusting the badge.

Does an eligibility check tell me whether a specific service is covered?

Sometimes, and never reliably. You can ask about a specific service type rather than general health plan coverage, and many payers answer it. But payers vary enormously in how much they return, so a thin benefits list reflects that payer's response rather than a fault in your software. For anything expensive, confirm with the payer directly.

Is an eligibility check the same as prior authorization?

No. An eligibility check is an automatic lookup that returns in seconds and commits the payer to nothing. Prior authorization is a reviewed request for permission to deliver a specific service, decided by a human or a payer rule, and it takes days. A 271 can tell you authorization is required. It cannot grant it.

How many eligibility checks does a practice need per month?

Budget more than one per insured visit, because checks are re-run when coverage expires, when a member ID is corrected, and when a patient adds secondary coverage. Ona Clearing House plans are sized on that basis and include 200 checks on Starter, 500 on Core, 750 on Practice, 1,500 on Growth and 3,750 on Scale, alongside claims and ERA volume.

Next step

The honest test is one of your own patients, not a demo record: run the check, read the benefit lines, and see whether the answer lands where the claim can use it. Book a 15-minute demo and bring a payer that usually gives you trouble, or start the 14-day free trial, full access, no credit card. Feature detail sits on the insurance and eligibility page.