Benefit Enrollment and Maintenance
The HIPAA X12 834 communicates enrollment, changes, and terminations of health plan coverage from an employer or sponsor to a payer.
In this guide
834 Benefit Enrollment moves from Employer / Sponsor / Benefits Administrator to Payer / Health Plan (Sponsor → Payer) via AS2, SFTP, API. The interactive diagram below traces every business and technical step the message passes through — press Play Flow to watch it travel, or click any step for detail.
How it works
How 834 Benefit Enrollment Works
Sender
Employer / Sponsor / Benefits Administrator
Receiver
Payer / Health Plan
Direction
Sponsor → Payer
Standard
ANSI ASC X12
Version
005010X220
Transport
AS2 / SFTP / API
Business Purpose
Healthcare
Sender — Employer / Sponsor / Benefits Administrator
EDI Transmission
834
Benefit Enrollment and Maintenance
ANSI ASC X12 005010X220
Receiver — Payer / Health Plan
Related transaction flows
Need help understanding this EDI flow?
Ask EDI AI →834 Benefit Enrollment workflow. Steps: Capture Enrollment Event, Generate 834 File, Send to Payer, Payer Receives File, Apply Membership Changes, Coverage Goes Live. Transmitted from Employer / Sponsor / Benefits Administrator to Payer / Health Plan via AS2, SFTP, API, following ANSI ASC X12 005010X220.
Overview
Keeps a payer's membership records synchronized with an employer's HR/benefits system, ensuring the right people have the right coverage.
Sender
Employer / Sponsor / Benefits Administrator
Receiver
Payer / Health Plan
Direction
Sponsor → Payer
Standard / Version
ANSI ASC X12 005010X220
Segment structure
Key segments that make up this transaction set:
| Segment | Name | Purpose |
|---|---|---|
| BGN | Beginning Segment | Transaction date and reference number. |
| INS | Member Level Detail | Identifies the member and the maintenance type (add/change/term). |
| HD | Health Coverage | Plan and coverage level being enrolled. |
| DTP | Date or Time Period | Coverage effective or termination date. |
Interactive example
Click any segment below to see its business meaning.
ST
This is an envelope or control segment. Select a highlighted segment on the left (shown in green) for a full business explanation.
View raw EDI
ST*834*0001*005010X220~
BGN*00*ENR-3390*20230920*0800~
INS*Y*18*030*XN*A~
REF*0F*W123456789~
NM1*IL*1*DOE*JANE~
DTP*336*D8*19850612~
HD*030**HLT*Gold PPO Plan~
DTP*348*D8*20231001~
SE*8*0001~Mapping example
A representative field-level mapping from a common source system into this transaction:
| Source | Source Field | Target Field |
|---|---|---|
| HRIS Benefits Record | employee.plan_code | HD04 (Plan Coverage Description) |
| HRIS Benefits Record | employee.coverage_effective_date | DTP*348 (Coverage Effective Date) |
| HRIS Benefits Record | employee.event_type | INS03 (Maintenance Type Code) |
Validation rules
- Every member record must include a unique subscriber ID persistent across enrollment periods.
- Termination records (maintenance type 024) must include a termination date via DTP*349.
- Dependent records must reference a valid subscriber via the same member's INS segment grouping.
Common errors & troubleshooting
Member shows active in payer system after termination
Cause: 834 termination record was sent without the required DTP*349 termination date.
Fix: Enforce a validation rule requiring a termination date whenever INS03 = 024.
Duplicate member records created
Cause: Subscriber ID format changed between HR system migrations, breaking the match key at the payer.
Fix: Establish a stable, unique member identifier that survives system migrations, and communicate any changes in advance.
Frequently asked questions
Commonly nightly or weekly as a full or change-only ('delta') file, though real-time 834 transactions are increasingly used for immediate enrollment changes.
Still have questions about 834?
Ask EDI AI →