How to Convert EDI 270 to CSV, Excel, JSON, or XML

What a converted 270 represents

An EDI 270 is a Health Care Eligibility Benefit Inquiry. Providers, practice-management systems, clearinghouses, and health plans use it to ask for eligibility or benefit information for a subscriber or dependent. The paired EDI 271 carries the response. A 270 is therefore a question, not proof of current coverage or a benefit determination.

The current mapper recognizes implementation 005010X279A1 and builds one canonical output row for each EQ inquiry. Parent information is repeated onto that row: information source, information receiver, subscriber, and—when present—dependent. This is materially different from flattening one row per segment because it preserves the business unit analysts usually need to count or reconcile: the requested eligibility service.

A single patient can have several EQ segments. One may request general health-plan coverage while another asks about a specific service type or procedure. Those inquiries become separate rows rather than being collapsed into a misleading comma-separated record.

From EQ and DTP to a readable inquiry row

This fictional extract is based on the repository’s parser-tested subscriber-and-dependent fixture. Identifiers intentionally contain leading zeroes.

ST*270*000000001*005010X279A1~
BHT*0022*13*REF000001*20260726*1030~
HL*3*2*22*0~
TRN*1*000000000001*1999999999*REF001~
NM1*IL*1*SAMPLE*ALICE****MI*000000000123~
DMG*D8*19800102*F~
EQ*30^47^98*HC:99213:25*IND*GP~
REF*G1*AUTH0001*AUTHORIZATION~
DTP*472*D8*20260726~

The NM1 segment identifies the subscriber and member ID. EQ01 repeats service-type codes—here general coverage, hospital, and professional physician visit. EQ02 adds a procedure composite, while EQ03 and EQ04 supply coverage-level and insurance-type context. The date value in DTP03 is interpreted as the inquiry date because DTP01 is 472; its D8 format is supplied by DTP02.

Fields worth checking first

Convert the 270 in the application

1. Open the converter. Visit the Client-Side EDI converter. Selected files are parsed in the browser tab without application-server upload.
2. Add the inquiry. Drag the file into Drag & drop EDI files or choose Browse files. The interface accepts common EDI and text extensions.
3. Use Smart mapping. Smart mapping (per file) detects ST01 270 with the 005010X279A1 implementation reference. Raw segments is useful for syntax inspection but does not create inquiry-aware fields.
4. Choose privacy options. If appropriate, enable De-identify PHI to obscure names, identifiers, and contact information in converted output. Decide whether your reconciliation workflow still needs a controlled linkage key.
5. Select Convert & Preview. Confirm the 270 output and review Data. Compare subscriber/dependent IDs, service types, and inquiry dates with a few source segments.

6. Review the mapped rows. Converted results shows one row per EQ occurrence. Use Summary for compact inquiry counts, patient levels, service types, procedures, dates, and request criteria.
7. Download the reviewed data. Open Download and choose Excel (.xlsx), CSV (.csv), JSON (.json), or XML (.xml). Converted-data edits flow into the download but do not rewrite the original 270.

Choose CSV, Excel, JSON, or XML for the next workflow

Interpret the output without inventing a response

The canonical 270 schema contains 227 public columns because a row may need envelope, hierarchy, source, receiver, subscriber, dependent, demographic, provider, EQ, amount, reference, and date context. Most rows are sparse. Blank dependent fields on a subscriber inquiry are expected.

For row counts, use each EQ occurrence as an inquiry detail—not automatically as a unique patient or transaction. Group by file and transaction control number first, then patient trace or identifier, Inquiry Number, service types, and requested dates. A subscriber with two EQ segments produces two rows; a dependent’s EQ produces another.

For a 270-to-271 comparison, identifiers and service-type requests are useful join context, but the response can repeat benefit information in a different hierarchy. Do not assume positional row-for-row correspondence.

Common 270 conversion and review mistakes

Counting EQ rows as unique patients

What you see: more output rows than people. Why: one person can request several services. Review: Patient Type, hierarchical IDs, Inquiry Number, and Service Type Codes. Correction: define a patient key separately from the inquiry-detail key.

Losing leading zeroes

What you see: member ID 000000000123 becomes 123. Why: spreadsheet type inference. Review: member, trace, policy, tax, and control identifiers. Correction: import or format those columns as text.

Reading a date without its qualifier

What you see: an inquiry date or range labeled incorrectly. Why: DTP03 meaning depends on DTP01 and DTP02. Review: Inquiry Date Qualifier, Description, Format, and Date/Range together. Correction: retain all four fields.

Assuming the file proves eligibility

What you see: a complete, valid-looking 270. Why it matters: it contains a request, not a payer’s response. Correction: locate the corresponding 271 and apply the relevant operational rules.

Treating unknown codes as parser failure

What you see: an “Unknown service type” description while the original code is preserved. Why: a code may be outside the local dictionary or trading-partner expectations. Correction: verify the raw value against applicable X12 and companion-guide sources before changing it.

Frequently asked questions