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.
Go-live in as little as 30 minBrowser agentCustomer portal login
We map your process, volume, and exception paths, then recommend a practical first scope.
Building internally? Read the docs →
Overview
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.
How Asteroid runs this workflow
An approved ACA or ICHRA application packet arrives for its carrier, Asteroid keys the carrier's own portal from the enrollment record, and the confirmation ID lands back on the member's record, with a human approving before anything is submitted.
How it actually runs
An approved ACA or ICHRA application packet is ready for a selected carrier
Confirmation ID on the member's record
The submitted application's confirmation ID writes back to your enrollment tracker, so the audit trail exists before anyone needs it.
Field the record doesn't answer: The run reports the specific field with the portal's state attached, and a person supplies it or corrects the record once. Member applications never get invented data.
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
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
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
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.