What does the Build Eligibility Inquiry/Response EDI (X12 270/271) skill do?

Build an ASC X12N 270 eligibility/benefit inquiry and parse the 271 response (005010X279A1) — source/receiver/subscriber/dependent hierarchy, NPI and member matching via DMG, EQ service-type codes, TRN trace round-trip, EB eligibility/benefit and AAA reject parsing, and a worked 270/271 example

How do I run the Build Eligibility Inquiry/Response EDI (X12 270/271) skill?

Copy the skill and paste it into your own Claude or ChatGPT, then provide your source data. FinchContext skills run inside your own AI assistant, so your financial data never leaves your control.

Which region does the Build Eligibility Inquiry/Response EDI (X12 270/271) skill cover?

United States. It targets the local tax authority / e-invoicing format described on this page.

Build Eligibility Inquiry/Response EDI (X12 270/271)

Skill: Convert a member lookup into an X12 270 inquiry and parse the 271 response

Region: United States Category: Health Care EDI (HIPAA X12 5010) Does: Builds the ASC X12N 270 Health Care Eligibility Benefit Inquiry a provider sends to verify a patient's coverage, and parses the matching 271 Response the payer returns — the HIPAA-mandated real-time/batch eligibility-and-benefit check done before service. Spec: ASC X12 005010 — 270/271 005010X279A1

270 (inquiry) and 271 (response) are a paired HIPAA transaction governed by a single X12 TR3. They are commonly exchanged real-time (synchronous, often via a CORE-compliant connection) as well as batch. The loop/segment IDs below are the 5010 structure; the TR3 and payer companion guide are authoritative. The 271 is parsed, not authored by the provider.

Transaction envelope (270)

ISA / GS (FG = HS for 270 / HB for 271, version 005010X279A1) / ST (270)
  BHT  Beginning of Hierarchical Transaction
  ... hierarchical loops: Information Source → Receiver → Subscriber [→ Dependent] ...
SE / GE / IEA

The 271 mirrors the same hierarchy and echoes the inquiry, adding eligibility/benefit (EB) segments.

Hierarchical loop structure

2000A  Information SOURCE (the payer)        HL·20
  2100A NM1·PR  Payer name + payer ID
2000B  Information RECEIVER (provider)       HL·21
  2100B NM1·1P  Provider name + NPI
    2000C Subscriber                          HL·22
      2100C NM1·IL  Subscriber name + member ID; DMG; DTP
      2110C EQ      ELIGIBILITY/BENEFIT INQUIRY  (service type code)  [270]
      2110C EB      ELIGIBILITY/BENEFIT INFO     (coverage details)   [271]
      2000D Dependent (only if patient ≠ subscriber)   HL·23
        2100D NM1·IL dependent; DMG
        2110D EQ / EB

Key segments

Segment	270 / 271	Carries
`BHT`	both	purpose (`13` request / `11` response), reference, timestamp
`HL`	both	hierarchical level (20 source, 21 receiver, 22 subscriber, 23 dependent)
`NM1`	both	entity by role — `PR` payer, `1P` provider, `IL` subscriber
`TRN`	both	trace number — echoed in the 271 to match the 270
`DMG`	both	date of birth, gender (used to match the member)
`DTP`	both	eligibility / service date (`291` plan, `307` eligibility)
`EQ`	270	service type code being asked about (e.g. `30` health benefit plan coverage, `1` medical care)
`EB`	271	eligibility/benefit: coverage status, service type, plan, in/out-of-network, amounts
`MSG`/`III`/`AAA`	271	free-form message / additional info / error/reject reason

Data rules

A generic inquiry uses EQ service type code 30 ("Health Benefit Plan Coverage") to ask "is this member active?"; specific codes (e.g. 1 medical, 35 dental, 88 pharmacy, 98 office visit) ask about a benefit category.
Member matching relies on the subscriber NM1·IL member ID plus DMG (DOB) and name — payers apply their own search keys; insufficient/mismatched data returns an AAA reject with a follow-up action code.
The 271 EB carries the answer: EB01 eligibility/benefit code (1 active, 6 inactive, I non-covered, C deductible, B co-pay, A co-insurance…), service type, coverage level, time period, and EB07 monetary amount where applicable; benefit-specific EB loops convey deductible/copay/coinsurance and network status.
TRN must round-trip: the trace sent in the 270 is returned in the 271 so the provider can match request↔response.
Envelope control numbers must match trailers; SE segment count must be exact.

Worked example

270 inquiry — is member active? (skeleton):

ST*270*0001*005010X279A1~
BHT*0022*13*REF270001*20250531*1200~
HL*1**20*1~
NM1*PR*2*BCBS*****PI*PAYERID~                Information source (payer)
HL*2*1*21*1~
NM1*1P*2*FAMILY CLINIC*****XX*1234567893~   Receiver (provider, NPI)
HL*3*2*22*0~
TRN*1*93175-012547*9877281234~              Trace number
NM1*IL*1*DOE*JANE****MI*MEMBER123~          Subscriber + member ID
DMG*D8*19850115*F~
DTP*291*D8*20250531~                         Eligibility date
EQ*30~                                        Service type: health benefit plan coverage
SE*13*0001~

271 response (parsed): TRN echoes 93175-012547; EB*1**30**GOLD PPO~ → member active under plan "GOLD PPO"; subsequent EB loops report deductible (EB*C), copay (EB*B*...*30**...*27~), and in-network status → drive the front-desk benefit display.

Validation checklist

Version 005010X279A1; correct functional group code (HS 270 / HB 271); payer companion guide checked
Hierarchy built source→receiver→subscriber(→dependent); HL parent pointers correct
Provider NPI (NM1·1P) and payer ID (NM1·PR) present; subscriber member ID + DMG for matching
TRN trace set on the 270 and matched on the 271
EQ service type code(s) appropriate (generic 30 vs specific benefit codes)
271 parsed: EB eligibility/benefit codes, plan, network status, and amounts mapped; AAA rejects handled
Eligibility date (DTP) present; dependent loop used only when patient ≠ subscriber
Envelope control numbers match trailers; SE count exact; passes 5010 validation

Last updated: 2026-05-31 — verify loop/segment usage, service-type and eligibility/benefit code sets, and real-time/CORE connectivity rules against the current ASC X12 005010X279A1 (270/271) TR3 and the payer companion guide before use.