834 enrollment inbound

Outcome

The 834 file from a payer's enrollment vendor is received, parsed, diffed against the current roster, and applied to member records — with clear reporting on adds, terminations, and changes.

Prerequisites

Scope	What it lets you do
edi.transaction.read	View the inbound transactions
ingestion.member.write	Apply roster changes

A trading partner with 834 inbound capability and an enrollment-feed mapping that defines how INS segments translate to your member / coverage records. See 2.4 — Capabilities.

What 834 carries

The 834 — Benefit Enrollment & Maintenance — is how payers (or their enrollment brokers) push roster changes:

Action	What the 834 says
Add	New member enrolled in this plan.
Cancel / terminate	Member is leaving the plan.
Change	Demographics, plan, or coverage tier change.
Reinstatement	Previously-terminated member re-enrolling.
Audit	Full snapshot — used for reconciliation, not changes.

A single 834 file can carry thousands of members; large state Medicaid agencies push monthly audit files alongside daily delta files.

834 anatomy

Source: packages/x12/src/inbound/enrollment-834.ts. Implementation convention: 005010X220A1.

ISA → GS → ST*834 → BGN
  REF*38 (master policy number)
  DTP*303 (master policy effective date)
  Loop 1000A — Sponsor Name
    N1*P5 (sponsor)
  Loop 1000B — Payer
    N1*IN (payer)
  Loop 2000 — Member Detail
    INS (member action: 021 add, 024 cancel, etc.)
    REF*0F (subscriber number)
    REF*1L (group/policy number)
    DTP*356 (eligibility begin)
    DTP*357 (eligibility end)
    Loop 2100A — Member Name
      NM1*IL
      PER (contact)
      N3 (address)
      N4 (city/state/zip)
      DMG (DOB, gender)
    Loop 2100B — Incorrect Member Name (when a change corrects prior data)
    Loop 2300 — Health Coverage
      HD (coverage type)
      DTP*348 / *349 (coverage begin/end)
      AMT*B9 (premium amount)
SE → GE → IEA

INS segment — the action key

INS carries the action code — read this first to know what the member record needs:

INS01	Meaning
Y	Subscriber
N	Dependent

INS03 Maintenance Type Code	Meaning
001	Change
021	Addition
024	Cancellation or termination
025	Reinstatement
030	Audit or compare

INS04 Maintenance Reason Code	Common values
01	Divorce
02	Birth
03	Death
07	Termination of benefits
08	Retirement
09	Termination of employment
14	Voluntary withdrawal
15	Primary care provider change
28	Initial enrollment
33	Marriage
41	Plan change
EC	Member benefit selection

Steps to process an inbound 834

The flow is automated — but the operator should know it well enough to recognize when something is off.

1. The partner's transport delivers the 834 file (SFTP poll picks it up; AS2 partner pushes it; REAL_TIME does not apply for 834).

2. The gateway parses the envelope and acknowledges with 999 if the partner expects one. Most 834 partners do.

3. parseEnrollment834() walks the loops producing one ParsedEnrollmentMember record per INS segment.

4. The enrollment-feed mapping (configured per feed in the rcm-app ingestion admin) projects each parsed record onto the canonical member / coverage shape.

5. The diff stage compares the projected record against the current member state. For each:

   • New member → create.
   • Terminated → set coverage effective_to.
   • Changed → update demographics / coverage with the audit row.
   • Audit-only — no change action; reconciliation report only.

6. The sweep concludes with a per-batch report: total members, adds, terminations, changes, no-ops. Visible at /transactions/:id for the 834 file.

Audit files vs delta files

A typical state Medicaid 834 cadence:

Audit-only files (INS03 = 030) do not trigger updates by default. The platform produces a reconciliation report that flags any member who appears differently in the audit than in our roster — the operator reviews and decides whether to apply.

Validation

Check	Expected
Inbound transaction record appears with tx_type = 834	Yes.
Per-batch report aligns with the 834's own counts	Yes — the partner usually publishes adds/terms/changes counts in their delivery email; we should match.
Reinstatements (INS03 = 025) reopen prior coverage rather than creating new	Yes — the mapping is idempotent.
Audit-only file does not silently rewrite roster	Correct — audit files produce a report, not changes.

Troubleshooting

Symptom	Cause	Fix
834 parses but no members updated	Mapping not bound, or mapping projects to an unused field	Confirm the feed has an active mapping; check the mapping's target columns.
Reconciliation report shows large drift	Last 834 was missed	Re-fetch the missing file via 8.2 — Replay & retry; apply manually.
New member created with wrong subscriber	Mapping mis-projects INS01	Edit the mapping to honor INS01 = Y for subscriber, INS01 = N for dependent.
Termination does not propagate to claims	Coverage effective_to updated but claims using stale coverage already submitted	The platform does not retroactively recall claims; coordinate with the billing team.

Next

5.1 — 278 request