What Is an EDI 270 Eligibility Inquiry?

Where the EDI 270 fits in eligibility verification

A provider office, hospital, pharmacy, clearinghouse, or another authorized information receiver sends a 270 to a health plan or other information source. The inquiry supplies patient-identification and service-request context. The receiver evaluates that request and commonly returns an EDI 271 Health Care Eligibility Benefit Response.

A 270 can support workflows such as checking whether the receiver can locate a member, asking for general health-plan coverage, or requesting information associated with particular service categories. It does not itself carry the payer’s answer. Teams must pair the inquiry with the returned 271 and preserve trace and patient controls if they want to reconcile the exchange.

Eligibility information can change, and trading partners may impose companion-guide requirements beyond the base implementation. A structurally complete inquiry is not a guarantee that a receiver will locate the member, return a specific benefit, authorize care, or pay a future claim.

Participants and hierarchy in a 270

The 270 is hierarchical. Each HL segment establishes a level and points to its parent, allowing one transaction to represent the organizations and people involved without repeating all context for every request.

HL01 is the level identifier, HL02 points to the parent, HL03 carries the level code, and HL04 indicates whether child levels follow. The surrounding NM1, TRN, DMG, INS, REF, DTP, and EQ segments then describe the participant and request at that level. Flattening these segments without retaining hierarchy can attach a dependent request to the wrong subscriber.

What information an EDI 270 may contain

The envelope and transaction controls identify the sender, receiver, version, and transaction. Within the eligibility inquiry, several segments carry the operational meaning:

REF, PRV, AMT, and III can add identifiers, provider context, amount context, or additional inquiry information when applicable. PRV02 controls PRV03 meaning, and taxonomy terminology applies only when PRV02 is PXC. Their presence and usage depend on the transaction context and trading-partner rules; no single short example represents every valid 270.

Synthetic EDI 270 example

This fictional excerpt comes from the repository’s parsed 005010X279A1 test fixture. It contains no real protected health information:

ST*270*000000001*005010X279A1~
BHT*0022*13*REF000001*20260726*1030~
HL*1**20*1~
NM1*PR*2*SYNTHETIC HEALTH PLAN*****PI*PAYER001~
HL*2*1*21*1~
NM1*1P*2*SYNTHETIC CLINIC*****XX*1234567893~
HL*3*2*22*0~
TRN*1*000000000001*1999999999*REF001~
NM1*IL*1*SAMPLE*ALICE****MI*000000000123~
DMG*D8*19800102*F~
DTP*291*D8*20260726~
EQ*30^47^98~
SE*13*000000001~

ST declares transaction 270 and implementation 005010X279A1. BHT identifies this eligibility inquiry and its creation time. The HL segments move from the information source to the receiver and then the subscriber. NM1 identifies each participant; TRN provides a trace; DMG supplies fictional demographic lookup context; DTP requests information for a particular date; and EQ asks about service types represented by the composite values. This example illustrates relationships and is not a substitute for an implementation guide or a trading partner’s companion guide.

EDI 270 compared with 271, 834, and 837

How to review a 270 in EDIFileConverter.com

1. Open the EDI workspace and add an authorized file with Browse files or drag and drop.
2. Keep Smart mapping (per file) selected and confirm that the detected implementation is 005010X279A1.
3. Select Convert & Preview to inspect labeled subscriber, dependent, date, trace, and requested-service fields.
4. Select Open full editor when you need filters, sorting, column controls, saved layouts, or converted-data review.
5. Open Validation Results to review enabled structural, required-data, format, code, and consistency checks. “No issues found” applies only to those enabled checks.
6. Select Analysis to review inquiry counts, patient mix, requested service types, date coverage, identifiers, and detail rows.
7. Use Download to export Excel, CSV, JSON, or XML after confirming the fields needed to reconstruct hierarchy remain included.

Important limitation: editing converted values does not rewrite the uploaded source EDI. The validator checks supported rules but does not determine whether a patient is eligible or what benefits are available. Trading partners may apply additional requirements.

Common EDI 270 mistakes and interpretation risks

Confusing the inquiry with the response

Seeing a service type in EQ means that information was requested. It does not mean the service is covered. Review the matched EDI 271 and its benefit or rejection context.

Losing subscriber and dependent hierarchy

A dependent level relies on its subscriber parent. Keep HL identifiers, patient type, subscriber identifiers, patient identifiers, and trace values together when converting or joining data.

Dropping leading zeros from identifiers

Spreadsheet software can coerce trace, member, group, and control values into numbers. Import them as text and verify the exported result before using it for reconciliation.

Reading a date without its qualifier and format

DTP03 is only the value. Retain DTP01 and DTP02 so a single date and a range are interpreted correctly and so the business meaning is not guessed.

Sending insufficient or inconsistent lookup data

A receiver needs appropriate patient and subscriber context. Review missing identifier pairs, demographic combinations, patient trace values, and the current hierarchy. Correct only against authorized source information and the relevant companion guide.

Assuming base validation guarantees a successful response

Envelope counts and required structures can be correct while a receiver applies additional business rules. Validation reduces avoidable defects but cannot guarantee matching, returned benefits, authorization, or payment.

Frequently asked questions