X12 transaction guide · Healthcare and insurance

EDI 270 Eligibility, Coverage or Benefit Inquiry

The X12 document providers and others use to ask a health plan or insurer about a person's eligibility, coverage or benefits.

Sent by
Healthcare provider, clearinghouse or other information receiver
Received by
Health plan, insurer or other payer
Standard
ANSI ASC X12

What is an EDI 270?

The EDI 270 Eligibility, Coverage or Benefit Inquiry is the ANSI X12 transaction set used to ask about the eligibility, coverage or benefits associated with a benefit plan, employer, plan sponsor, subscriber or dependent. The standard is designed for all lines of insurance, though it is most widely used in healthcare.

In the United States, HIPAA designates the 270 and its reply, the 271, as the standard for electronic eligibility checks in healthcare, using version 5010 implementation guides. Providers send 270s before or at a visit to confirm coverage and reduce denied claims.

How the EDI 270 worksDiagram of the EDI 270 Eligibility, Coverage or Benefit Inquiry. Healthcare provider, clearinghouse or other information receiver sends it to health plan, insurer or other payer. It usually starts the exchange. It is usually followed by 271 and 999. Inside the ISA, GS and ST envelopes, X12 release 008010 requires, in the heading: BHT (Beginning of Hierarchical Transaction) and detail: the required 2000 loop with HL (Hierarchical Level) and the required 2100 loop with NM1 (Individual or Organizational Name). 1 optional loops are listed by their first segment.How the EDI 270 worksEligibility, Coverage or Benefit Inquiry: who sends it, where it fits and what the standard marks required1 WHERE IT FITSUSUALLY FOLLOWSStarts the exchangeEDI 270SENDERHealthcare provider,clearinghouse or otherinformation receiverRECEIVERHealth plan, insurer orother payer997 or 999 acknowledgment back, if the partners agreeUSUALLY FOLLOWED BY271Eligibility, Coverage orBenefit Information999ImplementationAcknowledgment2 WHAT X12 RELEASE 008010 REQUIRESInterchange: sender and receiver IDsISA … IEAFunctional group, ID code HSGS … GETransaction set 270ST … SEHEADINGBHTBeginning of Hierarchical TransactionDETAILRequired loop 2000 · repeats many timesHLHierarchical LevelRequired loop 2100 · repeats many timesNM1Individual or Organizational Name+ 1 optional loop, starting with:EQBlue box: required loop. Optional loops are listed by the segment that starts them; when a loop is used, that first segment is required. Optional segmentsoutside loops are not drawn.Structure: required segments and loops in the X12 008010 listing for the 270. Your trading partner's implementation guide adds its own requirements.
How the EDI 270 worksDiagram of the EDI 270 Eligibility, Coverage or Benefit Inquiry. Healthcare provider, clearinghouse or other information receiver sends it to health plan, insurer or other payer. It usually starts the exchange. It is usually followed by 271 and 999. Inside the ISA, GS and ST envelopes, X12 release 008010 requires, in the heading: BHT (Beginning of Hierarchical Transaction) and detail: the required 2000 loop with HL (Hierarchical Level) and the required 2100 loop with NM1 (Individual or Organizational Name). 1 optional loops are listed by their first segment.How the EDI 270 worksEligibility, Coverage or Benefit Inquiry: whosends it, where it fits and what the standardmarks required1 WHERE IT FITSUSUALLY FOLLOWSStarts the exchangeEDI 270SENDERHealthcareprovider,clearinghouse orotherinformationreceiverRECEIVERHealth plan,insurer or otherpayer997 or 999 acknowledgment back, if the partnersagreeUSUALLY FOLLOWED BY271Eligibility, Coverage or BenefitInformation999Implementation Acknowledgment2 WHAT X12 RELEASE 008010 REQUIRESInterchange: sender and receiver IDs (ISA… IEA)Functional group, ID code HS (GS … GE)Transaction set 270 (ST … SE)HEADINGBHTBeginning of HierarchicalTransactionDETAILRequired loop 2000 · repeatsmany timesHLHierarchical LevelRequired loop 2100 · repeatsmany timesNM1Individual orOrganizational Name+ 1 optional loop, starting with:EQBlue box: required loop. Optional loops are listedby the segment that starts them; when a loop isused, that first segment is required. Optionalsegments outside loops are not drawn.Structure: required segments and loops in the X12008010 listing for the 270. Your trading partner'simplementation guide adds its own requirements.

How to read this diagram: the top row shows who sends the 270, to whom, and which documents usually come before and after it. The lower part shows what X12 release 008010 itself requires: the envelopes around the 270 and the segments and loops the standard marks as required, area by area. Optional loops are listed by the segment that starts them rather than drawn in full. This is the standard's minimum, not a trading partner's requirement: each partner's implementation guide usually makes some optional loops mandatory, restricts the codes and may use a different release.

Expand diagram Download SVG

When it is used

  • Checking a patient's coverage before an appointment
  • Confirming benefits for a specific type of service
  • Batch eligibility checks for upcoming visits

Where it fits in the document flow

This document 270 Eligibility, Coverage or Benefit Inquiry

Structure

Mandatory segments in the 270 (X12 release 008010)

The segments X12 release 008010 marks as mandatory at their level, in order. Segments inside optional loops are needed only when the loop is used. This is the standard's requirement, not your trading partner's: each partner's implementation guide names the release it uses, adds the optional segments it requires and restricts the values. The requirement status comes from one published X12 reference listing and has not been checked against a second source.

  • ST
  • BHT
  • HL
  • NM1
  • EQ
  • SE

Practical example

The 270 in practice

The day before appointments, a clinic's practice management system sends a 270 for each scheduled patient to their health plans through a clearinghouse. The 271 replies show active coverage and copay amounts for most patients and an inactive policy for one, so the front desk contacts that patient before the visit.

Implementation

Implementation considerations for the 270

  • Follow the HIPAA implementation guide and each payer's companion guide for required data.
  • Collect accurate subscriber identifiers and demographics to avoid failed matches.
  • Protect the data as health information under HIPAA privacy and security rules.

Need help with the EDI 270?

ECOM maps, tests and monitors X12 documents for your trading partners and integrates them with your ERP.