834 File Layout:
Segments, Loops & Examples (EDI 834 Guide)

What is an 834 file? An 834 file (formally ASC X12N 834, version 005010X220A1) is the EDI standard for electronically transmitting healthcare benefit enrollment and maintenance data. Governed by HIPAA, it is used by employers, health plans, and government agencies to enroll members, update coverage, and terminate benefits. The file is structured in loops and segments, with the BGN (Beginning Segment) and INS (Member Level Detail) as its two most critical mandatory segments.

Key Takeaways

• The 834 file (ASC X12N 834, version 005010X220A1) is the HIPAA-governed EDI standard for healthcare benefit enrollment and maintenance.
• It is structured hierarchically: loops group related segments; segments contain individual data elements.
• The two most critical mandatory segments are BGN (Beginning Segment) and INS (Member Level Detail).
• 834 files are triggered by new enrollments, coverage changes, terminations, COBRA administration, plan year rollovers, and dependent verification.
• Automated tools like Integrate.io streamline 834 file extraction, transformation, validation, and loading, reducing manual processing errors.

The EDI 834 file, formally the ASC X12N 834 Benefit Enrollment and Maintenance transaction set, is the standard electronic format for transmitting healthcare enrollment and eligibility data between employers, health plans, and insurers. Governed by HIPAA and defined under ASC X12 version 005010X220A1, the 834 file is how healthcare organizations add members, update coverage, and process terminations without manual data entry.

834 enrollment files and 834 eligibility files help organizations update records, make changes to coverage, and communicate enrollment status between different yet related entities. Each entity can maintain accurate records and streamline administrative processes as a result.

In this guide, you will learn how the 834 file is structured, how to create an EDI 834 File Format Guide, and why it matters for healthcare organizations. For related healthcare file standards, see HL7 file integration and FHIR file integration.

What is EDI?

To properly understand 834 files, it is necessary to know the standards they are built upon: the Electronic Data Interchange (EDI). EDI is the computer-to-computer exchange of business documents in a standardized electronic format between business partners. Moving from paper-based document exchange to electronic gave organizations major benefits:

• Reduced costs: EDI eliminates paper, postage, and handling. It also lowers labor costs tied to processing errors and inefficient manual practices.
• Increased processing speeds: Automated document exchange accelerates business transactions and allows decision-makers to reach conclusions faster.
• Reduced errors: Minimizing manual data entry leads to more accurate and reliable information sharing between business partners.
• Improved partner relationships: Timely, accurate, and consistent communications enhance trust and foster productive collaboration.

EDI replaces postal mail, fax, and email with a standardized format for fast and accurate information sharing, regardless of the systems or software each business partner uses.

What is an 834 File?

The 834 file is an EDI document for electronically transmitting healthcare enrollment and eligibility data, known officially as the Benefit Enrollment and Maintenance transaction set. 834 files are commonly used by health plans, employers, and government agencies when sharing information about individuals' healthcare coverage.

The 834 file layout is defined by the Accredited Standards Committee X12 (ASC X12) and upheld by the American National Standards Institute (ANSI). Two key standards govern it:

• CMS HIPAA adopted standards (ASC X12): These certify that data is consistently formatted and understood across different systems, facilitating efficient and accurate data exchange in the healthcare industry.
• X12N: The ASC X12 subcommittee responsible for insurance industry EDI standards. The "N" stands for Insurance. For 834 files, the governing standard is ASC X12N 834, version 005010X220A1, adopted under HIPAA. This version superseded the 4010 standard and is the current required format for HIPAA-covered entities.

Together, these make up the ASC X12N 834 standard, which outlines the format, structure, and data elements used for Benefit Enrollment and Maintenance transaction sets.

What is an EDI 834 File Format Guide?

An 834 file format guide is a detailed document that outlines the structure, data elements, and specifications for creating and processing an EDI 834 transaction set. Because 834 files contain individuals' personal healthcare information, they require clear guidelines for protection, handling, and transmission.

The file format guide helps healthcare organizations, including health insurance companies, employers, third-party administrators, and healthcare providers, ensure this data is handled, stored, managed, and transmitted properly.

The EDI 834 file consists of a series of segments and loops, each containing specific data elements. These segments include information about the sender, receiver, individual members, and their enrollment details.

An example 834 file format guide covers:

• Header segments
• Detail segments
• Trailer segments

Each segment captures specific pieces of information to ensure all necessary data is included in the transmission.

How an EDI 834 File Format Guide is Structured

A complete 834 file format guide should include:

1. An introduction to the EDI 834 file
2. Definitions of the various parts of the 834 file structure
3. Data element descriptions and definitions
4. 834 file implementation instructions
5. Compliance and validation information
6. Example files that illustrate a properly formatted 834 file

Introduction to EDI 834 File Format

The introduction familiarizes your team with what 834 files are, why they are needed, and how to work with them. It explains the objective and scope of an 834 transaction set.

834 transaction sets are used to:

• Enroll people into healthcare plans
• Update individual and/or family healthcare coverage
• Manage members' healthcare policy enrollment status

834 File Format Segment Glossary

This section should include a segment glossary that:

• Describes each segment and its purpose
• Explains which segments are mandatory and which are optional
• Lists the order in which segments appear
• Describes the data elements contained in each segment

Descriptions of the data elements outline what is found in each segment, such as name, demographic information, data type, length, and use. Include example information for each data element illustrating its correct formatting and usage.

834 File Layout Overview Table

The table below lists every loop and segment in sequence. This is the primary reference artifact for practitioners working with 834 files.

834 File Structure: Loops and Segments

The 834 file is organized hierarchically. Loops group related segments; segments contain individual data elements. Think of loops as categories and segments as the specific fields within each category.

834 File Loops

Loops are sequential labels that classify and sequence segments. Each loop organizes and groups related data elements hierarchically.

Loops are identified by sequential numbers:

• 1000: Header
• 2000: Member Detail
• 2100: Member Name
• 2200: Disability Information
• 2300: Health Coverage
• 2400: Member Reporting Categories

Every loop and segment has its own purpose and data elements. There are often nested loops (sub-loops) within primary loops. For example, the 1000 loop is the Header loop, which includes critical overview information about the transaction set.

Every transaction set has at least three parties: Payer, Payee, and Member(s). Loops include identifiers, names, contact information, date of birth, and other information that establishes the parties involved.

834 File Segments

The 834 file format contains various mandatory segments. Some entries within mandatory segments may be optional. The two most important mandatory segments are:

• Beginning Segment (BGN)
• Member Level Detail (INS)

834 File Delimiters Explained

Delimiters are the characters that separate data elements, segments, and sub-elements within an 834 file. They are defined in the ISA segment and cannot appear as data values anywhere else in the interchange.

The three delimiter types used in 834 files are:

• Element separator: pipe character "|"
• Segment terminator: tilde "~"
• Component (sub-element) separator: right brace "}"

A real ISA segment looks like this:

ISA|00| |00| |ZZ|SENDERID |ZZ|RECEIVERID |260101|1200|}|00501|000000001|0|P|>~

In this example, "|" separates elements, "~" terminates the segment, and "}" is the component separator. Consistent delimiter usage is required for successful file processing. Refer to the ISA segment in every file to confirm which delimiters are in use before parsing.

834 File Segment Attribute Reference

The tables below replace the image-based segment breakdowns from the original article. Each table lists the element reference number, format type, length, and requirement designator (M = Mandatory, O = Optional, X = Situational).

BGN: Beginning Segment

The Beginning Segment (BGN) is the first mandatory segment in every 834 transaction set. It defines the purpose of the transaction (original, re-submission, or informational), assigns a unique reference number, and records the creation date and time. The first four data elements are mandatory; the remaining five are optional.

INS: Member Level Detail

The Member Level Detail (INS) segment identifies each member's relationship to the subscriber, the type of maintenance being performed (add, change, or termination), and the reason for that maintenance.

• INS/01 indicates whether the member is the subscriber (Y) or a dependent (N).
• INS/03 carries the Maintenance Type Code: 021 for addition, 024 for termination, 001 for change, and 030 for audit.
• INS/05 carries the Benefit Status Code: A for active, C for COBRA.

Note: There is no event code to specifically establish a subscriber's disenrollment due to termination for gross misconduct. In these cases, update INS/08 Employment Status Code to TE for Terminated. The Benefit Status Code will automatically update to Inactive.

NM1: Member Name

The NM1 segment carries the member's name and identification information.

HD: Health Coverage

The HD segment identifies the specific health coverage being enrolled, changed, or terminated.

List of Standards

A standards reference list should follow the introduction in any 834 file format guide. This reference explains the standards that govern EDI 834 files, including ASC X12N and HIPAA compliance requirements for EDI transactions.

834 File Transaction Examples

The following examples show real transaction code patterns for the most common 834 scenarios. Each example uses pipe (|) as the element separator and tilde ~) as the segment terminator.

Example 1: 021 Add (New Active Enrollment)

A new employee is added to the health plan. INS/03 = 021 (Addition), INS/05 = A (Active). The DTP segment with qualifier 348 carries the coverage begin date.

ISA|00| |00| |ZZ|EMPLOYER001 |ZZ|HEALTHPLAN001 |260101|0900|}|00501|000000001|0|P|>~
GS|BE|EMPLOYER001|HEALTHPLAN001|20260101|0900|1|X|005010X220A1~
ST|834|0001~
BGN|00|REF12345|20260101|0900||||2~
N1|P5|ACME CORPORATION|FI|123456789~
N1|IN|BLUE HEALTH PLAN|XV|987654321~
INS|Y|18|021|AC|A|||FT~
REF|0F|EMP001~
REF|1L|POL123~
DTP|356|D8|20260101~
DTP|348|D8|20260101~
NM1|IL|1|SMITH|JOHN|A||~
N3|123 MAIN STREET~
N4|ANYTOWN|MI|48001~
DMG|D8|19800515|M~
HD|021||HLT|GOLD-PPO|EMP~
DTP|348|D8|20260101~
SE|16|0001~
GE|1|1~
IEA|1|000000001~

Example 2: 024 Term (Termination of Coverage)

An employee leaves the company. INS/03 = 024 (Termination), INS/04 = 1A (Voluntary Withdrawal). The DTP segment with qualifier 349 carries the coverage end date.

INS|Y|18|024|1A|A|||TE~
REF|0F|EMP001~
DTP|356|D8|20260630~
DTP|349|D8|20260630~
NM1|IL|1|SMITH|JOHN|A||~
HD|024||HLT|GOLD-PPO|EMP~
DTP|349|D8|20260630~

Example 3: COBRA Enrollment (021 Add, with Paid-Through Date)

An employee elects COBRA continuation coverage. INS/05 = C (COBRA). DTP qualifier 543 carries the paid-through date, confirming COBRA coverage is active.

INS|Y|18|021|10|C|||TE~
REF|0F|EMP001~
DTP|356|D8|20260701~
DTP|348|D8|20260701~
DTP|543|D8|20260731~
NM1|IL|1|SMITH|JOHN|A||~
HD|021||HLT|GOLD-PPO|COBRA~
DTP|348|D8|20260701~

Example 4: COBRA Enrollment (021 Add, without Paid-Through Date)

When the 543 paid-through date is absent, the system cannot confirm COBRA payment has been received. The enrollment record is created but coverage is not activated until payment is confirmed.

INS|Y|18|021|10|C|||TE~
REF|0F|EMP001~
DTP|356|D8|20260701~
DTP|348|D8|20260701~
NM1|IL|1|SMITH|JOHN|A||~
HD|021||HLT|GOLD-PPO|COBRA~
DTP|348|D8|20260701~

834 File Format Guide: Guidelines for Implementation

Your 834 file format guide transitions here to practical implementation:

• How to create 834 files
• How to handle errors
• How to validate and maintain compliance
• Sample files to illustrate how the 834 file works in practice

How to Create 834 Files

Include step-by-step instructions for how users in your organization should create 834 files. Cover:

• Data mapping
• Data validation
• File structure
• Compliance checks
• Error reporting

How to Map Data in an 834 File

To map data from an 834 file, users need to understand how segments and data elements are structured, including:

• Headers
• Trailers
• Individual data segments: Insured Individual (INS), Reference Identification (REF), Date or Time Period (DTP)

A healthcare data integration platform like Integrate.io can help with any EDI data mapping project. The platform extracts and transforms your data in alignment with the requirements of your target system. After your clean, transformed data is loaded, you verify that all vital information, such as insurance plan coverage dates, insurance plan identifiers, and personal health information (PHI), was accurately translated into your target system.

For more on protecting sensitive healthcare data, see Integrate.io PII and PHI Transformations.

How to Validate and Maintain 834 File Compliance

Validating an 834 file and maintaining compliance are closely related. The steps below cover both.

1. Check headers and trailers. Verify that ISA, GS, ST, SE, GE, and IEA segments are all present and in the correct order. Mandatory segments like INS must be present.

2. Verify loop structure. All loops must have correct start and end points. Relevant segments must be contained within their corresponding loop.

3. Check data element compliance. Each element must be the correct data type, appropriate length, and meet formatting requirements. Cross-reference critical fields (member IDs, plan codes, dates) against internal databases.

4. Validate delimiters. Confirm consistent use of element separators, segment terminators, and sub-element separators as defined in the ISA segment.

5. Check business rule compliance. Verify eligibility criteria, enrollment periods, and coverage details against health plan and regulatory requirements. Confirm files meet Health Insurance Portability and Accountability Act (HIPAA) requirements for electronic transactions.

6. Run an EDI validation program. Generate a compliance report. Review it for discrepancies and make corrections before further processing.

7. Audit and document. Maintain detailed records of validation checks, compliance reports, errors discovered, and corrections made. This documentation trail supports regulatory audits.

For EDI compliance requirements and best practices, see our full guide.

At the end of your guide, provide users with example 834 files that display the ANSI 834 file layout reference and its contents. A 834 file format sample (eMedNY) is also a useful reference for illustrating correct formatting.

Recommended Reading: HIPAA compliance checklist

Benefits of an 834 File Format Guide

Organizations that work with personally identifiable information (PII) face stringent legal and regulatory requirements. An organization-specific 834 file format guide offers multiple benefits:

• Consistent, standardized data formatting and exchange between disparate systems, platforms, and organizations
• Increased accuracy of enrollment data through clear, step-by-step guidelines with example formatting
• Improved compliance with laws and regulations, including HIPAA
• Assurance of standardized, secure data transmission
• Streamlined creation, validation, and transmission of 834 data files, saving time and reducing administrative burden

EDI 834 File Common Use Cases

834 files are not accessed every day. They are created or updated only in specific scenarios:

• New enrollments: A health insurance provider receives an 834 file from an employer or plan sponsor with information about new employees who need to be enrolled in the healthcare plan.
• Changes in coverage: Employees may need to update healthcare coverage during open enrollment periods or due to life events like marriage, childbirth, or divorce.
• Termination of coverage: When an employee leaves a company or cancels their healthcare plan, the employer sends an 834 file to the insurance provider to terminate coverage.
• COBRA benefits administration: The Consolidated Omnibus Budget Reconciliation Act (COBRA) allows employees who lose their jobs to continue healthcare coverage for a limited time.
• Plan year rollovers: At the end of a plan year, many organizations renew or roll over employees' healthcare coverage into the new plan year.
• Dependent verification: Employers often require verification of dependents' eligibility for coverage.

For a detailed look at HIPAA-compliant member and eligibility file ingestion, see our dedicated guide.

EDI Challenges: Best Practices When Handling 834 Files

Handling 834 files presents several challenges: ensuring data accuracy, maintaining regulatory compliance, and managing large volumes of data.

The most common failure points are:

• Missing mandatory segments (especially INS and BGN)
• Inconsistent delimiters across files from different trading partners
• Mismatched control numbers between ISA/GS/ST and their corresponding trailers
• Member IDs that do not match internal database records

To address these specifically:

• Validate ISA/GS/ST control number matching before processing. Mismatched control numbers cause interchange rejection.
• Verify mandatory segment presence using an EDI validation program. Missing INS segments will cause member records to fail silently.
• Confirm delimiter consistency across all files in a batch. A single file with non-standard delimiters can corrupt an entire interchange.
• Cross-reference member IDs against your internal databases before loading. Unmatched IDs create orphaned records that require manual remediation.
• Regularly update systems to comply with the latest EDI 834 specification (005010X220A1).

Integrate.io automates extraction, transformation, validation, and loading for 834 files, reducing manual processing and the risk of errors at each step.

Partner with Integrate.io for Streamlined EDI 834 File Processing

Integrate.io offers comprehensive EDI integration solutions for automating the processing of EDI 834 files. The platform provides tools for data transformation, validation, and integration, making it easier for your team to manage 834 files at scale.

With Integrate.io, healthcare providers, insurers, and third-party healthcare trading partners can build secure, scalable healthcare data pipelines and streamline the data exchange process. For a broader view of what is possible, see our overview of healthcare data pipelines.

See for yourself with a free, 14-day trial of the Integrate.io platform. If you have a unique use case, schedule a demo for a one-on-one walkthrough with a Solutions Engineer who will show you in real time how Integrate.io can simplify your organization's EDI workload.

Additional Resource: of an 834 File Formatting Guide | Veterans Affairs

Frequently Asked Questions About 834 Files

What is an 834 file in healthcare?

An 834 file is the EDI standard (ASC X12N 834, version 005010X220A1) for electronically transmitting healthcare benefit enrollment and maintenance data. It is used by employers, health plans, and government agencies to enroll members, update coverage, and process terminations. The file is governed by HIPAA and follows the ASC X12 005010X220A1 implementation guide.

What are the mandatory segments in an 834 file?

Every 834 file must include the ISA (Interchange Control Header), GS (Functional Group Header), ST (Transaction Set Header), BGN (Beginning Segment), INS (Member Level Detail), and their corresponding trailers: SE, GE, and IEA. The INS segment is mandatory for every member record in the transaction set.

What is the BGN segment in an 834 file?

The BGN (Beginning Segment) is the first mandatory segment in every 834 transaction set. It defines the purpose of the transaction (original, re-submission, or informational), assigns a unique reference number, and records the creation date and time. BGN/01 through BGN/04 are mandatory; BGN/05 through BGN/09 are optional.

What is the INS segment in an 834 file?

The INS (Member Level Detail) segment identifies each member's relationship to the subscriber, the type of maintenance being performed, and the reason for it. INS/01 indicates subscriber (Y) or dependent (N). INS/03 carries the Maintenance Type Code: 021 for addition, 024 for termination, 001 for change. INS/05 carries the Benefit Status Code: A for active, C for COBRA.

How do I validate an 834 file?

Validate an 834 file by: (1) checking that ISA, GS, ST, SE, GE, and IEA segments are present and in the correct order; (2) verifying loop structure and mandatory segment presence; (3) confirming each data element is the correct type and length; (4) validating delimiter consistency against the ISA segment definition; and (5) running an EDI validation program to generate a compliance report before processing.

What is the difference between an 834 enrollment file and an 834 eligibility file?

Both use the 834 format, but they serve different purposes. An 834 enrollment file initiates or changes a member's coverage (add, change, terminate). An 834 eligibility file confirms a member's current coverage status for verification purposes. The distinction lies in the Maintenance Type Code in the INS/03 element and how the receiving system processes the transaction.

What HIPAA standard governs 834 files?

834 files are governed by HIPAA's Administrative Simplification provisions, which require covered entities to use the ASC X12N 834 transaction set for benefit enrollment and maintenance. The current required version is 005010X220A1, which superseded the 4010 standard. Compliance is enforced by the Department of Health and Human Services (HHS).

What triggers an 834 file transaction?

An 834 file transaction is triggered by: new employee enrollment, changes in coverage due to life events (marriage, childbirth, divorce), termination of employment, COBRA election, plan year rollover, or dependent verification. Each of these events requires a new or updated 834 file to be transmitted from the employer or plan sponsor to the health plan.