HIPAA 834 EDI File Format Example: Enrollment File with Segment-by-Segment Breakdown

ANSI 834 EDI File Format Overview

The 834 is the HIPAA-mandated X12 Transaction Set used for Benefit Enrollment and Maintenance. Sponsors (employers) send it to payers (health plans) to add, change, reinstate, or terminate member coverage. You use it to communicate enrollment events clearly and consistently across systems.

Most trading partners in healthcare use ANSI 834A Version 5010, commonly referenced as 005010X220A1. While the base standard defines the core requirements, each payer typically refines usage through Companion Guides that specify situational rules and code lists you must follow.

An 834 file is transmitted inside X12 envelopes (ISA/IEA and GS/GE) and contains one or more ST/SE transaction sets. Within each transaction set, segments describe the file header, sponsor and payer details, and each member’s demographic and coverage data.

HIPAA Compliance Requirements

Because 834 files carry protected health information (PHI), you must safeguard them under HIPAA. In practice, that means securing transport (for example, SFTP or AS2 with encryption), enforcing role-based access, auditing file access, and retaining records per policy and regulation.

Use the 5010 implementation guide (834 005010X220A1) as your primary technical reference and your trading partner’s Companion Guides for operational specifics. Validate data against these guides, keep only the minimum necessary PHI, and ensure error handling that prevents misrouted or partial enrollments.

Establish trading partner agreements that define timing, acknowledgments, recovery procedures, and acceptable codes. These agreements reduce ambiguity and help you meet HIPAA’s administrative safeguard expectations.

Structure and Segments of 834 File

Envelope and Transaction Set

• ISA/IEA: Interchange envelope defines global separators and interchange control numbers.
• GS/GE: Functional group for benefit enrollment (functional identifier code “BE”).
• ST/SE: Transaction Set boundaries for the 834; ST03 often carries the implementation reference (e.g., 005010X220A1).

Header and File-Level Segments

• BGN Segment: Identifies the file. BGN01 is the Transaction Set Purpose Code (e.g., 00=Original, 15=Reissue), BGN02 is the control/reference number, BGN03/04 are file date/time. The BGN Segment anchors the file’s intent.
• REF/DTP at header: Often used for group identifiers, plan years, or file effective dates depending on the Companion Guide.
• 1000A/1000B N1 Loops: 1000A (Sponsor—often the employer), 1000B (Payer—health plan or TPA). These carry names and identifiers used downstream for processing.

Member-Level Detail

• Loop 2000 Employee Level: Starts each member with the INS Segment. INS01 indicates subscriber/dependent status response (Y/N), INS02 is the Individual Relationship Code (e.g., 18=Self), INS03 is the Maintenance Type Code (e.g., 021=Addition, 024=Cancellation), and INS04 may carry the Maintenance Reason Code (e.g., XN=New Enrollment). Additional REF and DTP segments convey member IDs and event dates.
• Loop 2100A Member Name: NM1, plus PER (contact), N3/N4 (address), and DMG (DOB, gender) segments. Optional 2100 loops can identify employers, schools, or responsible parties when needed.
• Loop 2300 Health Coverage: HD conveys coverage action/type (e.g., 030=Addition) and product type (e.g., HLT for health). DTP gives coverage effective/termination dates. REF may carry plan IDs or sub-plan identifiers.
• Loop 2310 (when used): Provider information such as primary care provider assignment, depending on the payer’s rules.

Loop Hierarchies in 834 Transactions

The 834 organizes data into predictable loop hierarchies. Understanding these loops helps you map fields, troubleshoot errors, and reconcile enrollments with payroll or HR systems.

• 1000A Sponsor Name: Employer or plan sponsor details for context and routing.
• 1000B Payer: The insurer or TPA that receives and processes the enrollment.
• 2000 Member Level (Employee/Dependent): Begins with the INS Segment and governs all member-specific segments that follow.
• 2100A Member Name and Demographics: Name, address, contact, and demographic data elements necessary to uniquely identify the member.
• 2300 Health Coverage: Plan elections, coverage levels, and effective dates that drive eligibility and billing.
• 2310 Provider (optional): PCP assignments or provider identifiers when supported.

Always verify which optional loops are required by your trading partner’s Companion Guides, as usage varies by payer and line of business.

Segment Delimiters and Syntax

X12 syntax uses three primary separators that appear throughout the file: the element separator (commonly an asterisk *), the component (sub-element) separator (often a colon :), and the segment terminator (commonly a tilde ~). The segment terminator ends each segment, while the element separator divides data elements and the component separator splits composite elements.

In ANSI 834A Version 5010, the repetition separator is defined in ISA11, the element separator is the first character after “ISA,” and the component element separator appears in ISA16. Choose characters that do not conflict with your data, and ensure your parser honors the chosen separators from the ISA segment.

Avoid trailing empty elements unless required by the guide, escape or replace delimiter characters that may appear in free text, and confirm that control numbers in ISA/IEA and GS/GE pairs reconcile correctly.

Example 834 Enrollment File Analysis

Below is a concise, illustrative enrollment file snippet using common delimiters (* element, : component, ~ segment terminator). Values are examples; follow your Companion Guides for exact codes and situational rules.

ISA*00*          *00*          *ZZ*SENDERID      *ZZ*RECEIVERID    *251107*1430*^*00501*000000905*0*T*:~
GS*BE*SENDERID*RECEIVERID*20251107*1430*1*X*005010X220A1~
ST*834*0001*005010X220A1~
BGN*00*123456*20251107*1430~
REF*38*GROUP123~
DTP*007*D8*20251101~
N1*P5*ACME EMPLOYER~
N1*IN*ALPHA HEALTH PLAN~
INS*Y*18*021*XN*A*E**FT~
REF*0F*123456789~
DTP*336*D8*20251101~
NM1*IL*1*DOE*JOHN****34*123456789~
PER*IP*JOHN DOE*HP*5551234567~
N3*100 MAIN ST~
N4*ANYTOWN*CA*90210~
DMG*D8*19860115*M~
HD*030**HLT*PLAN123****EMP~
DTP*348*D8*20251101~
REF*1L*SUBPLAN01~
SE*18*0001~
GE*1*1~
IEA*1*000000905~

Segment-by-segment breakdown

• ISA/IEA: Interchange envelope; defines separators (^ is the repetition separator in ISA11, : is the component separator in ISA16). Control numbers 000000905 must match between ISA and IEA.
• GS/GE: Functional group for Benefit Enrollment (BE). GS06/GE02 group control numbers must match.
• ST/SE: Transaction Set 834. ST02 (0001) matches SE02; SE01 reports the count of segments from ST to SE inclusive (18 here).
• BGN: File header. BGN01=00 (Original), BGN02=123456 (file reference), BGN03/04 are file date/time. This BGN Segment tells the receiver what kind of file this is.
• REF (38): Group or contract number at the file level, aligning the file to a specific group policy.
• DTP (007): Effective date for the file/reporting period (format qualifier D8 = CCYYMMDD).
• N1*P5 and N1*IN: 1000A Sponsor (employer) and 1000B Payer (insurer/TPA) identifiers used for routing and reporting.
• INS: Starts Loop 2000 Employee Level. INS01=Y (subscriber), INS02=18 (self), INS03=021 (addition), INS04=XN (new enrollment). Later elements describe student/marital status depending on usage.
• REF (0F): Member’s subscriber identifier used by the payer; often required for matching.
• DTP (336): Employment or eligibility date relevant to the enrollment event.
• NM1*IL: Member name (Individual). NM108/109 carry ID qualifier and identifier when used.
• PER*IP: Member contact info, such as phone (HP) or email (EM), for outreach.
• N3/N4: Street address and city/state/ZIP for correspondence and eligibility.
• DMG: Demographics—birth date and gender—needed for eligibility and rating.
• HD: Loop 2300 Health Coverage. HD01=030 (addition), HD03=HLT (health product type), HD04=PLAN123 (plan identifier), and HD09=EMP (coverage level or tier, per guide).
• DTP (348): Coverage effective date for the plan election.
• REF (1L): Sub-plan or class identifier, often used for benefit option tracking.

When validating, confirm: (1) envelope control numbers match, (2) SE01 counts are correct, (3) required segments per Companion Guides exist, (4) dates align with event logic, and (5) each dependent ties to the correct subscriber via INS02 and related identifiers.

Tools and Resources for 834 File Handling

You can streamline mapping, validation, and troubleshooting with purpose-built EDI utilities. Look for features like X12 schema validation for 005010X220A1, loop/segment navigation, delimiter detection, and side-by-side map testing to speed onboarding with new payers.

• EDI Notepad-style viewers/editors: Read, pretty-print, and validate 834 Transaction Sets, highlight bad counts, and display loops (1000/2000/2100/2300) for quick diagnostics.
• Translators/Mappers: Convert between 834 and internal HRIS schemas, enforce Companion Guides, and generate acknowledgments (999/TA1) for robust trading partner workflows.
• Automated QA: Linting rules for BGN/INS/HD logic, date coherency checks (e.g., coverage start ≤ termination), and segment presence by scenario (add, change, cancel).
• Operational tooling: Secure transport (AS2/SFTP), retries, reconciliation dashboards, and exception queues to protect PHI and maintain SLAs.

Conclusion

The 834 Transaction Set in ANSI 834A Version 5010 provides a precise, loop-driven model for enrollment data. Mastering the BGN Segment, INS Segment, HD coverage details, and the Loop 2000 Employee Level structure—while adhering to Companion Guides—lets you produce compliant, accurate files that payers can process without delays.

FAQs.

What is the purpose of the HIPAA 834 file?

The 834 communicates Benefit Enrollment and Maintenance information from a sponsor (employer) to a payer (insurer/TPA). It adds, changes, reinstates, or terminates member coverage using a standardized X12 Transaction Set so eligibility and billing systems can process enrollments reliably.

How are segments structured within an 834 transaction set?

Each segment is a line ending with a segment terminator (commonly ~). Elements inside the segment are separated by an element separator (often *), and composite elements use a component separator (often :). The transaction set begins with ST and ends with SE, with control counts and identifiers ensuring integrity.

What are the key loops in the 834 EDI file format?

Core loops include 1000A (Sponsor) and 1000B (Payer), Loop 2000 (Member Level with the INS Segment), Loop 2100A (Member name, address, demographics), Loop 2300 (Health Coverage using HD/DTP), and optionally Loop 2310 (Provider). Companion Guides specify which loops are required for your partner.

How can EDINotepad assist with 834 files?

EDINotepad-style tools help you open and validate ANSI 834A Version 5010 files, navigate loops, view segment hierarchies, verify counts in ST/SE and GS/GE, and spot delimiter or syntax errors. They also speed troubleshooting by highlighting missing required elements per implementation rules and Companion Guides.