How to Read an EDI 270 File

Read a 270 in this sequence

1. Confirm the implementation. ST01 should identify transaction 270 and ST03 should identify 005010X279A1 for the implementation covered here. Preserve ST02 and match it to SE02.
2. Reconcile the envelopes. Retain ISA/IEA and GS/GE controls, counts, sender and receiver identifiers, and delimiters. These values identify the interchange; they are not member or inquiry numbers.
3. Read the BHT. BHT identifies the transaction purpose, reference, creation date, and time. BHT03 is especially useful when matching an inquiry to operational logs or its response.
4. Follow the HL tree. Start at information source level 20, move to information receiver level 21, and then read subscriber level 22 or dependent level 23. Use HL02 rather than physical proximity alone to find a record’s parent.
5. Identify each party. Read NM1 entity and identifier qualifiers before interpreting the name or identifier. The same segment name can describe a payer, provider, subscriber, or dependent.
6. Read the patient lookup context. Keep TRN, REF, NM1, DMG, INS, and subscriber context together. Preserve leading zeros in identifiers.
7. Interpret dates and requests. Read DTP01, DTP02, and DTP03 as a unit. Read EQ service types or procedure composites with their qualifiers and occurrence.
8. Match the response. Use trace, transaction, patient, and trading-partner controls to connect the 270 with the corresponding 271; do not treat the inquiry as an answer.

Useful reading rule: identify the active HL owner before interpreting any patient, date, or EQ segment. A correct field value attached to the wrong subscriber or dependent produces an incorrect business conclusion.

Reconstruct the source, receiver, and patient hierarchy

The 270 uses hierarchical levels so one transaction can carry one or more patient inquiries beneath organizational context. Read four HL elements together:

A subscriber can own an inquiry directly, or a dependent can appear beneath the subscriber and own a different inquiry. When exporting to a flat table, keep Patient Type, subscriber identifiers, patient identifiers, HL values, and Inquiry Number on each row. Otherwise, two EQ occurrences can look identical even though they belong to different patients.

NM1 identifies the party at the current hierarchy level. Read NM101 first: for example, its entity code distinguishes an information source from an information receiver or insured person. Then read the entity type, name components, identifier qualifier, and identifier. Never infer that every NM1 identifier is a member ID.

Read identifiers, dates, and EQ requests as qualified values

DTP03 alone is ambiguous. DTP01 states what the date means, and DTP02 tells whether the value is a single date or a range. Likewise, an EQ composite can contain several service-type values separated by the component delimiter, or it can carry a procedure composite whose meaning depends on its qualifier. Preserve delimiter structure and repeated occurrences until mapping is verified.

Read this synthetic EDI 270 example

This fictional excerpt comes from a parsed repository fixture and 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~

Lines 1–2: ST identifies a 270 under 005010X279A1; BHT supplies reference REF000001 and creation time. Lines 3–4: hierarchy 1 is the information source and NM1 identifies the synthetic plan. Lines 5–6: hierarchy 2 is its information-receiver child and NM1 identifies the synthetic clinic. Lines 7–10: hierarchy 3 belongs to that receiver and identifies the subscriber, trace, member identifier, and fictional demographics. Lines 11–12: DTP requests the applicable date and EQ contains service-type requests. Line 13: SE reports 13 segments from ST through SE and repeats transaction control 000000001.

Read a 270 in EDIFileConverter.com

1. Open the EDI workspace and add an authorized 270 with Browse files or drag and drop.
2. Keep Smart mapping (per file) selected and confirm the detected implementation is 005010X279A1.
3. Select Convert & Preview. Begin with File, Record Type, Patient Type, Inquiry Number, trace, subscriber, and patient identifiers.
4. Read the mapped date qualifier, format, and value columns together. Then review Service Type Codes, descriptions, procedure qualifier and code, and occurrence-specific context.
5. Select Open full editor to filter, sort, control visible columns, or apply a saved layout. Keep hierarchy and identifier columns visible when narrowing rows.
6. Open Validation Results to review enabled checks, or select Analysis to summarize inquiries, patient types, service types, dates, identifiers, and detail rows.
7. Use Download to export Excel, CSV, JSON, or XML only after confirming the selected fields retain enough context to reconstruct each inquiry.

Product limitation: editing converted rows does not rewrite the uploaded source EDI. Validation covers enabled checks and cannot determine whether a patient is eligible, what benefits are available, or whether a trading partner will accept the inquiry.

Common mistakes when reading a 270

Reading EQ as a coverage answer

EQ states what the sender asked about. It does not establish active coverage, benefit amounts, authorization, or payment. Find the corresponding 271 and read its response context.

Ignoring the dependent’s subscriber parent

A level-23 dependent relies on its level-22 subscriber context. Keep both patient and subscriber identifiers during conversion, filtering, and reconciliation.

Dropping qualifiers or component order

A date, identifier, or procedure value can change meaning when detached from its qualifier. Preserve DTP01–DTP03, REF01–REF02, and EQ composite structure until labels have been verified.

Allowing spreadsheets to coerce identifiers

Member, trace, control, and group values may contain leading zeros. Treat them as text; scientific notation or numeric conversion can break a 270-to-271 match.

Assuming adjacent rows share an owner

Physical order alone is not enough. Use HL01 and HL02 to reconstruct ownership, particularly when multiple subscribers or dependents appear in one transaction.

Treating enabled validation as a guarantee

Structural and data checks can identify supported issues, but companion guides can add requirements. “No issues found” means none were found by the enabled checks, not that a receiver will return eligibility information.

Frequently asked questions