X12 270/271 EQ Segment Guide: Fields, Format, and Testing Gotchas
EQ looks like the smallest segment in a 270 request, but it's the one that actually shapes the whole 271 response — ask with the wrong service type code, or ask too narrowly, and the payer answers a question nobody meant to ask while the coverage detail a front desk actually needed never shows up.
EQ (Subscriber/Dependent Eligibility or Benefit Inquiry) is the segment in a 270 request that tells the payer what kind of coverage information is being asked for. EQ01 carries a service type code — general plan coverage, pharmacy, a physician office visit, and dozens of others — and the payer builds its 271 response around whatever EQ01 asked for.
The elements that actually matter in practice
Example
A 270 inquiry asking for general health benefit plan coverage rather than any one narrow service category. Synthetic eligibility data.
Where this trips people up
A lot of eligibility test suites hardcode EQ01 = 30 because it's the broadest, safest-looking request, and then never exercise what happens when a real front-end sends 88 or 98 instead. That gap stays invisible until a pharmacy or specialist workflow goes live and the 271 response comes back scoped to a service type the downstream system never learned to parse — the transaction is valid, the response is valid, and the integration still shows the wrong benefit screen.