EDI 270/271 Eligibility Verification: Stop Claim Denials Before They Start

How the 270/271 Transaction Pair Works

The 270/271 transaction pair is a request-response mechanism for insurance eligibility verification. You send a 270 (Eligibility/Benefit Inquiry) to a payer; the payer returns a 271 (Eligibility/Benefit Information Response) telling you what coverage, benefits, and cost-sharing apply to a specific patient on a specific date.

Before 270/271 existed, eligibility verification meant calling the payer's provider services line and having a staff member read benefit information over the phone — a process that took 8–12 minutes per patient, was error-prone, and left no electronic record. The 270/271 standard reduced this to a sub-second automated transaction that produces a structured, auditable record.

Under HIPAA and the CAQH CORE Operating Rules, covered payers must support real-time 270/271 transactions and respond within 20 seconds. They must also support batch eligibility (submitting multiple 270 inquiries in a single file for next-day response) for high-volume pre-verification workflows.

The HIPAA transaction standards for 270/271 are governed by the X12 005010X279A1 implementation guide. For broader HIPAA context, see our guide on HIPAA EDI compliance requirements.

The 270 Inquiry: What You Send

The 270 transaction is structured in a loop hierarchy: the BHT header identifies the inquiry, Loop 2000A identifies the information source (payer), Loop 2000B identifies the information receiver (provider), Loop 2000C identifies the subscriber (insurance member), and Loop 2000D (if different from the subscriber) identifies the dependent.

ST*270*0001*005010X279A1~
BHT*0022*13*REQ-001*20260414*1430~    ← 13=Real-time request

Loop 2000A — Information Source (Payer)
  HL*1**20*1~                          ← HL level 20 = Information Source
  NM1*PR*2*BLUE CROSS BLUE SHIELD*****PI*87726~  ← Payer NM1

Loop 2000B — Information Receiver (Provider)
  HL*2*1*21*1~                         ← HL level 21 = Information Receiver
  NM1*1P*2*ACME MEDICAL GROUP*****XX*1234567890~ ← Provider NPI
    REF*4A*PROV-ID-001~                ← Provider additional ID

Loop 2000C — Subscriber (Patient/Member)
  HL*3*2*22*0~                         ← HL level 22 = Subscriber; 0 = no dependents
  TRN*1*REQ-001*9876543210~            ← Trace number (for matching to 271)
  NM1*IL*1*DOE*JANE****MI*MEMBER123456~ ← IL = Insured/Subscriber
    DMG*D8*19850315*F~                 ← DOB and gender (for identity verification)
    DTP*291*D8*20260414~               ← Date of service inquiry
    EQ*30~                             ← Service type code 30 = Health Benefit Plan

SE*13*0001~

EQ Segment: Service Type Codes

The EQ (Eligibility or Benefit Inquiry) segment specifies what type of benefit information you are asking about. Using specific service type codes rather than the generic "30" (Health Benefit Plan) returns more precise information from payers that support service-specific responses:

The 271 Response: What Comes Back

The 271 uses the same loop hierarchy as the 270 but adds EB (Eligibility or Benefit Information) segments within the subscriber and dependent loops. Each EB segment describes one aspect of the patient's coverage — their deductible, their copay for a specific service type, whether a particular service is covered, and whether prior authorization is required.

ST*271*0001*005010X279A1~
BHT*0022*11*REQ-001*20260414*1431~    ← 11=Response

Loop 2000C — Subscriber response
  HL*3*2*22*0~
  TRN*2*REQ-001*9876543210~           ← Trace number matches 270 TRN
  NM1*IL*1*DOE*JANE****MI*MEMBER123456~
    DMG*D8*19850315*F~
    
  EB Segments — Benefit Details:
  
  EB*1**30**PPO~                      ← Active coverage, all services, PPO plan
  EB*C*IND*30**ANNUAL DEDUCTIBLE~     ← In-network deductible
    AMT*C1*2000.00~                   ← Deductible amount = $2,000
    AMT*D2*750.00~                    ← Deductible remaining = $750
  EB*A*IND*1**IN-NETWORK~             ← Coinsurance
    PCT*1*20~                         ← 20% coinsurance after deductible
  EB*B*IND*98**OFFICE VISIT~          ← Copay for office visits
    AMT*B6*30.00~                     ← $30 copay
  EB*1*IND*MH**MENTAL HEALTH~         ← Mental health covered
    MSG*PRIOR AUTHORIZATION REQUIRED~ ← PA required for mental health
  EB*G*IND*1~                        ← Out-of-pocket maximum
    AMT*G8*5000.00~                   ← OOP max = $5,000
    AMT*YU*1250.00~                   ← OOP remaining = $1,250

SE*22*0001~

EB Segment Deep Dive: Parsing Benefit Information

The EB (Eligibility or Benefit Information) segment is where the clinically and financially meaningful data lives in the 271. Understanding how to parse it correctly is essential for building useful eligibility displays in EHR and scheduling systems.

Critical EB01 Codes to Parse First

Before parsing any financial benefit data, always check for the EB01="1" (Active Coverage) segment. If EB01="6" (Inactive) appears, the patient has no active coverage — do not proceed with collecting deductible data as if coverage exists. The most common eligibility workflow mistake is parsing deductibles and copays from a 271 that also contains an EB01=6 inactive status segment.

Parsing In-Network vs. Out-of-Network Benefits

A complete 271 response for a PPO or HDHP typically includes two sets of EB segments for each benefit: one for in-network and one for out-of-network. They are distinguished by the IN (In Network) qualifier in the EB segment string. When parsing, always display both sets to front desk staff — patients asking "what is my copay" may have seen their out-of-network benefits advertised by their insurer when their plan has different in-network cost sharing.

Real-Time vs. Batch Eligibility: When to Use Each

Both real-time and batch 270/271 have important roles in a comprehensive eligibility workflow — they are complementary, not competing.

Best practice recommendation: Run batch eligibility 2–3 days before appointments to catch coverage changes (terminations, plan changes) and flag patients who need a follow-up call before their visit. Run real-time eligibility at check-in for all patients — deductible and remaining benefit amounts can change daily as the patient sees other providers.

Common 271 Rejection Reasons and What to Do

Not every 270 returns a clean eligibility response. When a payer cannot match the subscriber information, they return a 271 with an AAA (Request Validation) segment containing a rejection code. Understanding these codes allows your system to route rejections intelligently.

Integrating Eligibility into Scheduling and Check-In Workflows

The most impactful implementations treat eligibility verification not as a manual task but as an automated step in the appointment workflow — invisible to staff unless an exception requires intervention.

Trigger Points for Eligibility Checks

What to Surface in the EHR / PM System

Raw EB segment data is not useful to front desk staff. The eligibility integration layer should translate 271 data into these actionable display elements:

• Coverage status: Active / Inactive / Unknown — with the effective and termination dates
• Plan name and type (HMO/PPO/HDHP) from EB04
• Copay for today's visit service type (e.g., $30 for a standard office visit)
• Deductible status: individual met/remaining, family met/remaining, and whether calendar year reset is imminent
• Out-of-pocket maximum: individual and family remaining
• Prior authorization required flag — display prominently if PA is needed for the scheduled procedure
• Coverage limitations: visit limits (EB09/EB10) for physical therapy, mental health, etc.
• Coordination of Benefits indicator: is this plan primary or secondary?

The ROI of Pre-Visit Eligibility Verification

The financial case for real-time eligibility verification is well-documented. Here is how the math typically works for a mid-size physician practice:

For a practice seeing 100 patients per day with an average charge of $175, a 15% eligibility denial rate generates 15 denied claims daily — at $25 per rework, that is $375 per day, or $97,500 per year in rework costs alone. Reducing the denial rate to under 2% — achievable with real-time eligibility verification — generates $87,750 in annual savings from this one denial category.

The patient collections improvement is often larger: knowing the copay at check-in vs. sending a statement after the visit improves collection rates by 20–35 percentage points. For a practice with $1M in annual patient A/R, that improvement can exceed $200,000 in recovered revenue.

For context on how to handle the 835 remittance that follows successful claim adjudication, see our guide on EDI 835 electronic remittance advice.

Frequently Asked Questions