EDI 834 Eligibility File: What It Is, Format, and Examples

Overview of EDI 834 Eligibility File

The EDI 834 eligibility file—formally the Benefit Enrollment and Maintenance 834—transmits Health Plan Enrollment data from a plan sponsor (such as an employer, union, or benefits administrator) to an insurer or third‑party administrator. You use it to add, change, terminate, or reinstate coverage for members and their dependents.

Typical use cases include new hires, open enrollment changes, qualifying life events, COBRA elections, and periodic eligibility maintenance. Each transmission carries Subscriber Information and Dependent Enrollment details so the payer can update systems, issue ID cards, and bill accurately.

Understanding X12 5010 Standard

The 834 is defined by the ASC X12 standard, version X12 5010 (most implementations follow the 005010X220A1 guide). This standard specifies the file’s grammar—segments, elements, loops, codes, and control envelopes—so trading partners exchange consistent, machine‑readable data.

Structure flows from outer envelopes (interchange and functional group) to the transaction set (ST/SE) and then to hierarchical loops that hold sponsor, payer, member, and coverage information. Conformance to X12 5010 ensures your 834s can be validated, acknowledged, and processed reliably.

Key Segments and Data Elements

Envelope and control

• ISA/IEA: Interchange envelope identifying sender, receiver, date/time, and control numbers.
• GS/GE: Functional group for enrollment transactions, including version (e.g., 005010X220A1).
• ST/SE: Transaction set wrapper for a single 834 payload.

Transaction header

• BGN: Beginning segment with transaction type, reference number, and timestamp.
• REF and DTP: Transaction‑level identifiers (e.g., group/policy) and process dates.

Sponsor and payer identification

• N1 loops: 1000A (Sponsor) and 1000B (Payer) name, identification number, and qualifiers.

Member‑level detail

• INS: Member indicator, Individual Relationship Code, Maintenance Type Code, Maintenance Reason, and Benefit Status Code.
• REF: Member identifiers (e.g., Subscriber Number), internal IDs, or group numbers.
• NM1/N3/N4/PER: Member name, address, and contact details.
• DMG: Demographics such as birth date and sex.
• DTP: Eligibility begin/end or event dates at the member level.

Coverage‑level detail

• HD: Coverage action, insurance line (e.g., HLT, DEN, VIS), and coverage level (e.g., EMP, ESP, ECH, FAM).
• REF: Plan or product identifiers and options.
• DTP: Coverage effective and termination dates (e.g., qualifiers 348/349).

Member Enrollment Details

Subscriber Information

The subscriber is the primary insured person. In the 834, you identify the subscriber with INS using an Individual Relationship Code of 18 (Self). You include their Member ID in REF (often code 0F), name in NM1, address in N3/N4, demographics in DMG, and eligibility dates in DTP. Their coverage elections are sent in HD with plan references and effective dates.

Dependent Enrollment

Dependents (spouse, child, etc.) are sent in their own member loops, tied to the subscriber by your trading partner’s agreed identifier strategy. You use the appropriate Individual Relationship Code (for example, 01 for Spouse, 19 for Child) and mirror the same structure: REF for IDs, NM1 for the dependent’s name, DMG for DOB/sex, and HD/DTP for selected benefits and dates.

Dates and identifiers that drive processing

• DTP 356: Member eligibility begin date; DTP 357: eligibility end (if applicable).
• DTP 348/349: Coverage effective and termination at the plan option level.
• REF 0F: Subscriber Number; REF 1L: Group or policy number; additional REF codes may carry internal keys.

Health Plan Coverage Information

Coverage is detailed with HD segments per benefit line. You specify the insurance line code (e.g., HLT for medical, DEN for dental, VIS for vision), the coverage level (EMP employee‑only, ESP employee+spouse, ECH employee+children, FAM family), and any plan option references. Pair each HD with DTP dates to show when the benefit starts or ends.

If a member holds multiple benefits, you send one HD/DTP set per line of coverage. This granularity lets payers price premiums correctly and maintain accurate Benefit Status Code values at both member and plan levels.

Maintenance and Benefit Codes

Maintenance Type Code

This code communicates what action you want applied. Common values include 021 (Add), 001 (Change), 024 (Cancel/Terminate), 025 (Reinstate), 026 (Correction), and 030 (Audit/Compare). You’ll see it on INS (member‑level action) and often on HD (coverage‑level action).

Individual Relationship Code

This describes how the member relates to the subscriber: 18 (Self), 01 (Spouse), 19 (Child). Additional codes exist for other family relationships; use only those your trading partner supports.

Benefit Status Code

Indicates current status of benefits: A (Active), T (Terminated), C (COBRA). Payers use this with effective dates to keep eligibility accurate for claims and billing.

Maintenance Reason Code

Optionally explains why the change is occurring (for example, marriage, birth, rehire). Trading partners agree on which reasons to send and when they are required.

Examples of 834 File Structure

Interchange and group headers (skeleton)

ISA*00*          *00*          *ZZ*SENDERID       *ZZ*RECEIVERID     *260220*1200*^*00501*000000905*0*T*:~
GS*BE*SENDERID*RECEIVERID*20260220*1200*1*X*005010X220A1~

Example A: New hire — add subscriber with employee‑only medical

ST*834*0001*005010X220A1~
BGN*00*ENR000001*20260220*120000*ET***4~
N1*P5*ACME EMPLOYER*FI*123456789~
N1*IN*ALPHA HEALTH PLAN*FI*987654321~
INS*Y*18*021**A~
REF*0F*SBR123456~
REF*1L*GRP100~
DTP*356*D8*20260201~
NM1*IL*1*DOE*JANE****MI*ABC1234567~
N3*123 MAIN ST~
N4*SEATTLE*WA*98101~
DMG*D8*19900115*F~
HD*021**HLT*EMP~
REF*1L*MED-PLN-A~
DTP*348*D8*20260201~
SE*16*0001~

Example B: Terminate subscriber’s medical coverage

ST*834*0002*005010X220A1~
BGN*00*ENR000002*20260220*120100*ET***4~
N1*P5*ACME EMPLOYER*FI*123456789~
N1*IN*ALPHA HEALTH PLAN*FI*987654321~
INS*Y*18*024**T~
REF*0F*SBR123456~
NM1*IL*1*DOE*JANE****MI*ABC1234567~
HD*024**HLT*EMP~
REF*1L*MED-PLN-A~
DTP*349*D8*20260331~
SE*12*0002~

Example C: Add dependent child to subscriber

ST*834*0003*005010X220A1~
BGN*00*ENR000003*20260220*120200*ET***4~
N1*P5*ACME EMPLOYER*FI*123456789~
N1*IN*ALPHA HEALTH PLAN*FI*987654321~
INS*N*19*021**A~
REF*0F*SBR123456-01~
DTP*356*D8*20260201~
NM1*IL*1*DOE*CHRIS****MI*ABC1234567-01~
DMG*D8*20180312*M~
HD*021**HLT*ECH~
REF*1L*MED-PLN-A~
DTP*348*D8*20260201~
SE*14*0003~

FAQs

What is the purpose of an EDI 834 eligibility file?

An EDI 834 eligibility file communicates Health Plan Enrollment changes—adds, updates, terminations, and reinstatements—for subscribers and dependents so payers can keep eligibility, billing, and ID cards accurate.

How is the X12 5010 standard used in the 834 file?

X12 5010 defines the structure, segments, elements, and codes (such as Maintenance Type Code, Individual Relationship Code, and Benefit Status Code) so trading partners can validate and process the same 834 data consistently.

What key data elements are included in an 834 file?

Core elements include BGN (transaction header), sponsor/payer N1 loops, member INS with action and relationship, REF identifiers, NM1 name, DMG demographics, N3/N4 address, and HD/DTP for plan elections and effective dates.

How do insurers use the information from an 834 file?

Insurers load Subscriber Information and Dependent Enrollment details into their eligibility systems to activate coverage, calculate premiums, generate ID cards, support claims adjudication, and manage COBRA or other benefit statuses.