Member Enrollment

Individual ACA and ICHRA Application Submission on Carrier Portals

Submit individual ACA and ICHRA applications directly on carrier broker portals: enrollment data keyed from your system of record, SEP documents uploaded, a human approving before submission, and the confirmation ID written back where your ops team actually looks.

This workflowCarrier broker portals
StatusAvailable today
AccessBrowser agent
AuthCustomer portal login

Overview

What this workflow does

Some plans don’t route through a marketplace; the application happens on the carrier’s own broker portal, and every carrier’s portal is different. This workflow runs that submission: an agent collects the member’s enrollment record from your admin system, signs in to the carrier’s portal, keys the application, uploads the SEP documentation the enrollment depends on, and pauses for a human to approve before anything is submitted. After submission it captures the carrier’s confirmation ID and records it back on the member’s record.

In production this runs as a fleet, one agent per carrier portal, currently spanning eight carriers for a single ICHRA administrator, because that’s the honest shape of the problem: the workflow is identical, the portals are dialects, and each dialect is scoped once and then reused for every member enrolling with that carrier.

Step by step

How it actually runs

  1. 01Collect the member’s enrollment data and SEP documents from your admin system.
  2. 02Sign in to the carrier’s broker portal with credentials from an agent profile.
  3. 03Key the application from the enrollment record only. A required field the record doesn’t cover is a named failure, never an improvised answer.
  4. 04Upload the SEP documentation and confirm the portal accepted it.
  5. 05Pause for human approval, submit, capture the confirmation ID, and write it back to the member’s record.

An application without a confirmation ID recorded didn’t happen.

The step manual enrollment ops always skips is the last one: writing the carrier’s confirmation back to the system of record. It feels optional because the application went through; it becomes the whole problem three weeks later when a member has no coverage and nobody can prove what was submitted where. Agents don’t get bored on step five. The write-back is part of the workflow, so the audit trail exists before anyone needs it.

At scale

One workflow, a fleet of carrier portals

This fleet is the carrier-direct lane of a production enrollment pipeline: marketplace enrollment covers the EDE lane, and both hand off to binder payment to activate the policy. Each new carrier is one more portal build against the same workflow, which is how the fleet grew to eight. Category view: the member-enrollment library.

Human in the loop

What escalates to a human

Every application runs on HIPAA-compliant, SOC 2 Type II infrastructure under a BAA, and each execution’s audit trail shows every field keyed and every document uploaded. Posture in full on the security page.

Submission itself.

A human approves the completed application before the agent submits it.

A field the enrollment record doesn’t answer.

Reported by name; member applications never get invented data.

Portal-side surprises.

An identity check, a changed form, an error the rules don’t cover: the run stops with the portal’s exact state attached.

Questions

Frequently asked questions

As eight agents sharing one workflow. The steps, guardrails, and outputs are identical; the portal navigation is scoped per carrier once, then reused for every application to that carrier.

Eight carrier portals is eight sets of logins someone’s new hire was going to learn. The member-enrollment library covers what that job becomes instead.

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.