The 271 envelope is standardized; the data inside is not. What the eligibility transaction reliably carries, the five gaps that force a phone call anyway, and what both mean for anyone building an agent on the rail.
A standard everyone adopted and nobody fully trusts
Eligibility verification is the single highest-volume administrative transaction in US healthcare: 31.5 billion medical eligibility and benefit checks a year, 51% of all measured medical administrative transaction volume [1]. On paper it is also an automation success story. The X12 270/271 transaction pair — the HIPAA-mandated electronic format for asking a payer "is this patient covered, and for what?" — is supported fully electronically by 96% of medical health plans [1], and operating rules require real-time answers within 20 seconds [6].
And yet, in the same measurement year, provider staff still placed roughly 628 million fully manual eligibility checks by phone, fax, mail, and email — plus another 3.77 billion through payer web portals and IVR phone trees [1]. That is more than four billion checks a year routed around a real-time electronic standard nearly every payer supports. One practice explained the behavior to CAQH's researchers in a single sentence: "When it comes to eligibility and benefits, I don't have an automated tool that I can trust, so I don't use it." [1]
This article is about why that distrust is structurally justified — and precisely scoped. The thesis is simple: the 271 envelope is standard; the data inside is not. The transaction reliably answers some questions and structurally cannot answer others, and the boundary between the two explains almost every phone call a front desk still makes. It is also the data-layer foundation under our broader analysis of what AI agents can and cannot automate in insurance eligibility verification — every automation boundary drawn there traces back to a gap described here.
I write about natural-language interfaces to enterprise data for a living, and the 270/271 pair is the cleanest case study I know of the lesson that governs that entire field: a shared schema does not buy you shared semantics. Two payers can emit perfectly conformant 271s for the same patient and still tell you different things, in different places, in different formats [2]. Everything that follows is that lesson worked out in detail.
What a 270/271 round trip actually carries
You do not need to have opened a raw X12 file to reason about this transaction — but you do need its five moving parts. The current version, 005010X279A1, is the HIPAA-mandated eligibility transaction every covered health plan must support [3].
A 270 is the inquiry. It carries the payer ID, the provider's name and NPI, the subscriber's identifiers — ideally member ID, first name, last name, and date of birth together, though payer minimums vary — the date of service, and one or more Service Type Codes describing what is being asked [4].
A Service Type Code (STC) scopes the question. Most requests send the generic STC 30, "Health Benefit Plan Coverage," which asks the payer to describe the plan broadly; explicit codes (STC 2 for surgery, for example) narrow the inquiry to one benefit. A 271 answering a generic 30 inquiry returns benefit detail across many service types — but codes 30 and 60 themselves can never appear in the response [5].
The 271 is the response, and its payload lives in EB (eligibility/benefit) loops. Each EB segment states one slice of the answer: coverage status, a benefit type, a money amount (copay, coinsurance percentage, deductible), a time qualifier (calendar-year versus year-to-date versus remaining), and in-network versus out-of-network variants [4]. A single 271 can carry dozens of these loops.
When the round trip fails, it fails with AAA rejection codes — machine-readable reasons such as AAA 75, "Subscriber/Insured Not Found," which in practice usually means a demographic mismatch rather than a genuinely uninsured patient [4].
| Piece | What it is | Why an agent designer cares |
|---|---|---|
| 270 | The inquiry: payer ID, provider NPI, member identifiers, date of service, STCs | Identifier quality drives match rates; bad demographics surface as AAA errors [4] |
| STC | Scopes the question — generic (30, 60) or benefit-specific | A generic STC 30 inquiry fans out into many benefit answers [5] |
| 271 | The response, structured as EB loops | The machine-readable core lives here — and so do the silences |
| EB loop | One benefit statement: status, amounts, time qualifiers, network variants | Most fields are optional; presence varies payer by payer [2] |
| AAA code | Structured rejection reason (e.g., AAA 75) | Retry instructions, not exceptions — see the design rules below |
Timing is governed by the CAQH CORE operating rules layered on top of the X12 standard: a real-time 271 must return within 20 seconds, and a payer is conformant when 90% of its responses in a calendar month meet that bar [6]. Real-time inquiries are single-patient and synchronous; batch files submit many members asynchronously — the mode typically used for the overnight sweep of tomorrow's schedule.
What the 271 reliably returns: the core an agent can fully own
Judged against what payers consistently populate, the 271 has a dependable core:
| Data element | Reliability in practice | Notes |
|---|---|---|
| Active/inactive coverage status | High | The question the transaction was built to answer [7] |
| Coverage and plan dates | High | Effective and termination dates [7] |
| Plan name and coverage level | High | Plan/group numbers vary by payer [7] |
| Copay and coinsurance | High for common service types | CORE data-content rules require patient financials for a defined service-type list [8] |
| Deductible — total and year-to-date | High | Same CORE requirement [8] |
| Deductible / OOP-max remaining | Payer-permitting | The "remaining" time qualifier (code 29) is not returned by all payers [7] |
| In/out-of-network benefit variants | Moderate | Amounts often split by network flag — but see gap #3 for what's still missing |
This reliable core matters because it covers most of the routine work. CAQH's time-and-motion measurements put a fully manual eligibility check at 16 minutes of staff time and $12.95 in industry cost, against 4 minutes and $2.04 fully electronic — every check moved from phone to wire returns roughly 12 minutes and $10.91 [1]. At clinic scale — every scheduled patient, checked ahead of the visit and re-checked at check-in — this is exactly the deterministic, high-volume, low-ambiguity work software should own outright. The verification sweep does not need a large language model; it needs a scheduler, a clearinghouse API, and a careful parser.
The catch — the reason "parse the 271" is a harder engineering problem than it sounds — is payer variance inside the standard. As clearinghouse Stedi puts it: "The 271 format is standard, but the data inside isn't — most fields are optional, and payers use them in different ways. Two payers might return different info for the same patient or put the same info in different places." Benefits can even land in free-text message segments rather than structured fields [2]. Anyone who has built a natural-language data agent over healthcare databases will recognize the shape of the problem: schema-identical sources with source-specific semantics, where the normalization layer is the product.
The five gaps that force a phone call
Now the part the front desk already knows. Five categories of information either aren't in the 271 at all or can't be trusted when they are — and each one maps to a question staff still have to ask a live payer representative.
| # | The gap | The front-desk question it leaves unanswered | Why the wire can't answer it |
|---|---|---|---|
| 1 | Visit limits and visits used | "How many therapy visits does the patient have left this year?" | Payers don't include service history in eligibility responses, and frequency-limit data is rare in medical 271s [7] |
| 2 | Prior-auth and referral indicators | "Does this service need an authorization or a referral?" | The format has slots for these flags, but they're optional and inconsistently populated — a 271 "doesn't reliably tell you whether a referral is required" [7] |
| 3 | Network status | "Is this provider in-network for this specific plan?" | Most payers don't include the querying provider's network status in the response [7] |
| 4 | Coordination of benefits | "Is this plan primary or secondary?" | Other-payer information appears inconsistently and isn't reliable; COB truth requires a separate process [7] |
| 5 | Accumulator lag | "What's actually left on the deductible?" | Remaining amounts lag claims adjudication; even a clean 271 is a snapshot, not a guarantee [7] |
These five gaps map almost one-to-one onto the standard verification call script — active status and term dates, visits remaining, copay and deductible status, referral and pre-authorization requirements, network status — a script practices are advised to run at least 72 hours before an initial visit, again at check-in, and monthly for recurring-care patients, because coverage changes mid-episode [9].
The gaps also compound in the specialties least able to absorb them. CAQH's provider interviews single out behavioral health: "Behavioralist benefits are often poorly clarified/documented and may require more interaction with health plans to understand and confirm" [1]. Physical therapy, occupational therapy, chiropractic, behavioral health — the specialties whose economics turn on visit limits, which is gap #1 — are precisely where the electronic answer is thinnest.
Two things are worth stating plainly. First, the payer portal does not close these gaps: portal information runs stale, and only a live representative can answer plan-specific questions like carve-outs and visits remaining [9]. Second, when the structured rail doesn't carry the answer, the answer often exists on paper — plan documents, EOBs, faxed benefit summaries. That is extraction territory, covered in our guide to intelligent document processing, not transaction territory; no amount of 270 tuning will pull a carve-out clause off a fax.
Why the gaps persist: optional fields and unfinished operating rules
It is tempting to read the gaps as payer obstruction or legacy inertia. The duller truth is that they are what the rules currently permit. The federally mandated CAQH CORE operating rules for 270/271 require four things of payers: real-time responses, the return of patient financial responsibility, defined error reporting, and 86% system availability [10]. Everything the front desk actually calls about — remaining benefits, visit counts, prior-auth indicators, procedure-level detail — sits outside that mandate. Optional fields stay optional, and optional in a 31.5-billion-transaction system means absent at scale.
The fix exists, and it is stuck. The updated CORE Eligibility & Benefits Data Content Rule would, for the first time, "require health plans to return eligibility information related to telemedicine, prior authorization, remaining coverage benefits, tiered benefits, procedure-level detail, and patient attribution status" [1]. NCVHS recommended it to HHS in June 2023; as of mid-2026 it remains queued in rulemaking [1]. Until it lands, "how many visits are left" has no mandated electronic answer — and an AI agent, however capable, can only do what a human does: call and ask.
The stakes of that unfinished rulemaking are not small. The US medical industry spends $44 billion a year on eligibility verification — 53% of all measured medical administrative transaction spend, the largest line item — with an $11.7 billion annual savings opportunity, the largest of any transaction CAQH tracks and one that grew 27% year over year [1].
For anyone architecting an eligibility system in 2026, the regulatory timeline is a design input. The honest planning assumption is that the five gaps persist for years; that they close payer by payer rather than all at once when the rule finalizes; and that "the payer now returns it" still needs per-payer verification afterward. Optionality has a long tail.
The clearinghouse layer: JSON APIs over EDI rails
Practically, almost nobody — human or agent — writes raw X12 anymore. The working integration surface is the clearinghouse REST API, which accepts a 270 as a JSON object and returns the 271 translated back to JSON:
| Clearinghouse | Eligibility surface | Notes for builders |
|---|---|---|
| Optum (Change Healthcare) | /eligibility/v3, JSON-to-EDI | Enhanced Eligibility API adds response normalization and asynchronous coverage discovery [11] |
| Availity | REST POST /v1/coverages | OAuth 2.0 client-credentials auth on all REST APIs [12] |
| Stedi | JSON, raw X12, and CAQH CORE SOAP endpoints | Real-time 270/271 plus batch refresh; developer-first documentation [4] |
Normalization is the real value a clearinghouse adds on top of connectivity: it absorbs payer-by-payer quirks — where the deductible appears, which loops a given payer populates — so downstream code sees one shape. But normalization cannot create data a payer never sent. A clearinghouse can standardize where the deductible shows up; it cannot conjure a visits-remaining count that isn't on the wire. The five gaps pass straight through the JSON.
The clearinghouse layer also carries the cluster's hardest operational lesson. On February 21, 2024, ransomware took Change Healthcare offline — the largest healthcare data breach on record, ultimately affecting roughly 192.7 million individuals [13], with response costs around $2.457 billion by UnitedHealth Group's own earnings disclosures [14]. Change processes on the order of 15 billion transactions a year and touches an estimated one in three US patient records [14] — and for weeks, practices that had wired all eligibility and claims traffic through that single rail had no rail. The architectural conclusion generalizes: concentrating every credential and every transaction in one intermediary is the single-point-of-failure anti-pattern, the same blast-radius reasoning our governed AI security framework applies at the platform layer. Multi-clearinghouse routing with segmented credentials per rail is now table stakes for any eligibility system, agentic or not.
Designing agents around the gap: API-first, phone-fallback
Everything above compresses into four design rules for an eligibility agent.
1. The electronic sweep is the floor, not the feature. Batch 270s for every scheduled patient ahead of the visit — industry guidance says at least 72 hours out — and re-check at check-in [9]. Parse the reliable core into the practice-management system automatically. This rung is deterministic and costs about $2.04 a check [1]; the agent's contribution is orchestration, parsing, and exception surfacing, not conversation.
2. Trust is a per-field property, not a per-transaction property. Treat active status, dates, plan name, copay, coinsurance, and deductible figures as machine-truth with timestamps. Treat gap fields as unanswered rather than answered-in-the-negative. The most expensive failure mode in eligibility automation is an agent that reads an empty authorization-indicator slot as "no auth required" — in a 271, silence is not a no [2]. Every parsed field should carry provenance: which payer, which service type code, which loop, retrieved when.
3. Error codes are control flow. AAA 75 "Subscriber/Insured Not Found" usually means the demographics are off, not that the patient is uninsured [4]. The correct response is a corrected retry — normalize the name, re-check the DOB, try the alternate member ID — before anything escalates to a human. Encode retry semantics per AAA code; reserve human attention for the failures that survive them.
4. The phone is a designed fallback rung, not a failure state. The five gaps guarantee that a share of verifications will end in a phone call for years, whatever the model does. Route those calls deliberately — a queue, with the specific unanswered fields attached — rather than letting them accumulate as ad-hoc staff work. That queue is where voice AI agents that call payers enter the architecture, with real capabilities and their own human-escalation reality; the point here is simply that the call exists because the wire structurally could not answer, and the agent should know which fields it is calling about.
On the tooling side, clearinghouse APIs wrap naturally as Model Context Protocol tools — Stedi shipped the industry's first clearinghouse MCP server on August 5, 2025, a thin wrapper over its real-time eligibility and payer-search APIs with error-recovery guidance for exactly the AAA-code cases above built in [15]. Wrapping the rail is the easy part; governing it — one credential broker, one policy layer, one audit log — is where a gateway such as Jarvis Registry enters the picture, and that layer is the subject of our companion reference architecture for building an eligibility-verification agent on MCP.
Step back and the shape is familiar from the rest of agentic AI: bounded workflow, structured evidence, explicit human checkpoints — the profile that deploys first everywhere. An eligibility agent built this way does not promise the end of payer phone calls. It promises something more defensible: that every call that still happens is one the wire genuinely could not answer — and with roughly 4.4 billion manual and portal checks a year running against a standard payers already support [1], that is a large enough promise to be worth engineering properly.
FAQ
Does a 271 show the remaining deductible?
Often, but not dependably. The 271 has a structured way to express remaining amounts — a "remaining" time qualifier (code 29) alongside calendar-year and year-to-date figures — but not all payers return it [7]. Even when present, it is a snapshot: accumulators lag claims adjudication, so the figure can trail reality. Treat remaining-amount fields as payer-permitting data with a timestamp, never as settled financial truth.
Why doesn't the 271 include visits remaining?
Because nothing requires it, and most payers don't volunteer it. Payers don't include service history in eligibility responses, and frequency-limit data is rare in medical 271s [7]. The updated CAQH CORE data-content rule would mandate "remaining coverage benefits" for the first time — NCVHS recommended it to HHS in June 2023, and it remains in rulemaking as of mid-2026 [1]. Until it lands, visit counts come from a phone call to the payer.
What is an AAA 75 error in an eligibility response?
AAA 75 is the structured rejection code for "Subscriber/Insured Not Found" [4]. In practice it usually signals a demographic mismatch — a name spelling, a transposed date of birth, a member ID that doesn't match the payer's enrollment file — rather than a patient without coverage. Well-built systems treat it as a retry instruction: correct the identifiers and resubmit before anything reaches a human queue.
How fast must a payer answer an electronic eligibility check?
The CAQH CORE infrastructure rule requires a real-time 271 response within 20 seconds, with conformance defined as 90% of responses meeting that bar in a calendar month [6]. Speed is genuinely solved — the round trip beats any phone call by half an hour. Completeness is not: those sub-20-second answers still omit the visit limits, authorization indicators, and network status the front desk needs, which is why the calls persist.
References
- CAQH, "2024 CAQH Index Report" — transaction volumes and mode split, per-check time and cost, savings opportunity, provider interviews, and the pending CORE data-content rule (2025): https://www.caqh.org/hubfs/Index/2024%20Index%20Report/CAQH_IndexReport_2024_FINAL.pdf
- Stedi, "How to deal with gaps in eligibility responses" — optional fields, payer-to-payer variance, benefits in free text (2025): https://www.stedi.com/blog/how-to-deal-with-gaps-in-eligibility-responses
- X12, "005010X279 Examples — Health Care Eligibility Benefit Inquiry and Response" (2024): https://x12.org/examples/005010x279
- Stedi, "Send eligibility checks" — 270 contents, EB loops, AAA rejection codes, real-time and batch endpoints (2025): https://www.stedi.com/docs/healthcare/send-eligibility-checks
- UnitedHealthcare, "EDI 270/271 Companion Guide, 005010X279A1" — Service Type Code request/response semantics (2024): https://www.uhcprovider.com/content/dam/provider/docs/public/resources/edi/EDI-270-271-Companion-Guide-005010X279A1.pdf
- CAQH CORE, "Eligibility & Benefits (270/271) Infrastructure Rule vEB.2.0" — 20-second real-time response, 90% monthly conformance: https://www.caqh.org/hubfs/43908627/drupal/CAQH%20CORE%20Eligibility%20%20Benefit%20(270_271)%20Infrastructure%20Rule%20vEB.2.0.pdf
- Stedi, "What you can reliably get from a 271 eligibility response" — the reliable core versus visit limits, auth/referral indicators, network status, COB, and accumulator lag (2025): https://www.stedi.com/blog/what-you-can-reliably-get-from-a-271-eligibility-response
- CAQH CORE, "Eligibility & Benefits (270/271) Data Content Rule vEB.2.1" — required patient financials by service type: https://www.caqh.org/hubfs/CORE%20Eligibility%20&%20Benefits%20(270_271)%20Data%20Content%20Rule%20vEB.2.1.pdf
- WebPT, "How to Verify Patient Insurance in Three Easy Steps" — the verification call script, re-verification cadence, and portal limitations (2023): https://www.webpt.com/blog/how-to-verify-patient-insurance-in-three-easy-steps
- DataSpring, "CAQH CORE Priority Topics" — scope of the currently mandated 270/271 operating rules (2026): https://www.dataspring.com/core/priority-topics
- Optum Developer, "Medical Network Eligibility v3 API Overview" — JSON-to-EDI eligibility and Enhanced Eligibility (2025): https://developer.optum.com/eligibilityandclaims/reference/medical-network-eligibility-v3-overview
- Availity Developer, "Availity API Guide" — REST coverages endpoint and OAuth 2.0 client-credentials (2025): https://developer.availity.com/blog/2025/3/25/availity-api-guide
- HHS Office for Civil Rights, "Change Healthcare Cybersecurity Incident — Frequently Asked Questions" (2024): https://www.hhs.gov/hipaa/for-professionals/special-topics/change-healthcare-cybersecurity-incident-frequently-asked-questions/index.html
- The HIPAA Guide, "Change Healthcare Data Breach" — ~192.7M individuals affected, ~$2.457B in costs, transaction footprint (2025): https://www.hipaaguide.net/change-healthcare-data-breach/
- Stedi, "Introducing the Stedi MCP server" — first clearinghouse MCP server, with AAA-code error-recovery guidance (2025): https://www.stedi.com/changelog/introducing-the-stedi-mcp-server