Member Enrollment
Member Enrollment

End-to-End Marketplace Enrollment on EDE Platforms

Run an ACA marketplace enrollment from application to active policy on an enhanced direct enrollment platform: eligibility questions answered from your member data, plan selected per your inputs, application submitted, and the handoff to the first premium payment made without a person carrying the case between systems.

Go-live in as little as 30 minBrowser agentCustomer portal login

See it run on your systems.

We map your process, volume, and exception paths, then recommend a practical first scope.

Scope this workflowSee how it works ↓

Building internally? Read the docs →

Overview

What this workflow does

Enhanced direct enrollment platforms exist so brokers and ICHRA administrators don’t have to send members to the federal marketplace, but the platform still has to be driven: member demographics, income and household questions, SEP evidence, plan selection, submission. This workflow drives it. An agent takes the member’s enrollment data from your system of record, completes the marketplace application on the EDE platform, and captures the confirmation, treating every question it can’t answer from your data as a named stop, not a guess about someone’s household income.

Enrollment isn’t finished at submission, and this workflow doesn’t pretend it is. The output is a live case ready for the step that actually activates coverage, the binder payment, which runs as its own workflow with its own, much stricter, guardrails.

How Asteroid runs this workflow

From an approved application to a submitted marketplace enrollment

A complete marketplace application and plan selection arrive from your admin system, Asteroid drives the EDE platform through eligibility to submission, and the confirmation writes back to your CRM, with every question your data can't answer stopped for a person instead of guessed.

EDE platformsInsurance CRMs

How it actually runs

  1. 01Pull the member’s enrollment data from your admin system: demographics, household, income figures, plan choice, SEP circumstances.
  2. 02Sign in to the EDE platform with credentials from an agent profile and start or resume the member’s application.
  3. 03Complete the application from your data only. Eligibility and household questions your data doesn’t answer stop the run by name; nothing about a member’s income is ever assumed.
  4. 04Attach SEP documentation where the enrollment requires it.
  5. 05Submit, capture the confirmation and enrollment identifiers, and write them back to your system of record, queued for binder payment.

A complete marketplace application and approved plan selection arrive from your admin system

  6. Enrollment status back in your CRM

    The submitted enrollment, its eligibility and plan details, and the confirmation evidence write back to your system of record, queued for binder payment.

Question the member data can't answer: The run stops with the exact question named (income, household, and SEP qualification are never inferred), and your staff resolve it once, with the case ready to resume.

An application isn’t coverage. The gap between them is where members fall.

Enrollment ops measures applications submitted; members experience policies activated, and between the two sits an unpaid binder, an unanswered eligibility question, a case someone meant to come back to. Running enrollment as agents closes the gap structurally: submission automatically queues the payment, and every stall in between is a named exception in a queue, not a browser tab someone closed on Friday.

At scale

The front half of a production pipeline

This is the front half of an enrollment pipeline running in production for ICHRA administration: application here, first premium paid on the carrier’s portal behind a human gate, and carrier-direct applications for the plans that don’t route through the marketplace at all. The category view is the member-enrollment library. Upstream of it all, lead-queue administration is what turns an opted-in member into an application entering this pipeline.

Book a demo, watch an enrollment run end to end

Human in the loop

What escalates to a human

Enrollment data is PHI and is treated that way: HIPAA-compliant infrastructure, SOC 2 Type II, a BAA, and zero-data-retention agreements with sub-processors, so no member’s application trains anything. Details on the security page.

Any eligibility or household question the member data doesn’t answer.

Income, household composition, and SEP qualification are never inferred.

Identity or data mismatches.

If the platform’s records disagree with your inputs, the discrepancy is reported verbatim.

The payment step.

Activating money never runs unattended; it’s a separate workflow with a human gate.

Questions

Frequently asked questions

The workflow shape stays fixed: pull the member's enrollment record from your admin system, complete the EDE application, submit, write confirmation identifiers back. What gets configured is your side of it: which fields in your system of record map to the platform's demographic, household, and income questions, when SEP documentation attaches, and where confirmations land. Your team keeps working from the same admin system; the agent is scoped to your enrollment data shape and your review rules, not the other way around.

Every enrollment a person carries between the admin system, the marketplace, and the carrier is a case that can stall in three places. The member-enrollment library is the full pipeline.

Book a demoMap this workflow

Disclaimer

Third-party names, including government agencies and registries, are used only to identify systems commonly involved in healthcare operations workflows. Asteroid is not affiliated with, endorsed by, sponsored by, or certified by those third parties unless expressly stated. Workflow availability depends on customer authorization, account permissions, configuration, and applicable system terms.