Open Enrollment
For benefits software, ben-admin platforms, and HR solutions

Let’s make open enrollment easier

See step-by-step how Noyo powers seamless carrier connections and real-time transparency.

wave

Activate a fast, reliable process that puts your team in control, no files or blackout periods

Automatically keep data up to date as carriers make changes behind the scenes.

Get daily status updates about renewal decisions, and catch any issues early.

Know exactly when open enrollment can begin for each group.

Automate the flurry of changes with no blackout periods ever.

The Noyo open enrollment experience

Managing open enrollment with Noyo is simple: submit and track changes via API. No more waiting in the dark or last-minute surprises that disrupt coverage. Replace blackout dates and confusing change windows with hands-free automation and data you can trust.
Your groups make
renewal selections
outside of Noyo
Inform Noyo of group
renewal decisions via API

Noyo monitors the carrier
to confirm plan changes

Noyo tells you exactly
when enrollment can
begin

Use the Noyo API to
process and confirm
member enrollments

Step 1: Group shops for renewal options and makes a selection

Renewal plan decisions are communicated to the carrier directly, outside of Noyo.

Step 2: Inform Noyo of your group’s renewal decisions via API

Send renewal decision details for each group using Noyo’s Renewal Readiness APIs.

Because renewal decisions for each group are communicated directly to the carrier and configured outside of view of the Noyo system, Noyo needs to know what plan decisions you expect ie what “readiness to enroll” looks like for each group at the carrier.

Renewal Readiness APIs are a simple way for benefits software platforms to tell Noyo about the expected renewal decisions for a group so that Noyo can persistently check the carrier system and confirm exactly when member enrollment for the new plan year can begin.

Step 3: Noyo detects when the carrier has processed plan-level changes

Noyo checks the carrier system daily to detect when renewal decisions have been applied. If Noyo detects a change at the carrier, the group’s data will be refreshed and status updated accordingly.

Step 4: Poll the Noyo API for “readiness” status of each group

Current status is available via Renewal Readiness APIs, and is updated as group level changes are detected (e.g., plan names, renewal date, etc.). Noyo surfaces any differences between what platforms expect and what the data at the carrier shows.

Step 5: Submit member enrollment decisions via API

As soon as the “readiness” status is ready, you’ll submit open enrollment member requests to get members enrolled.

  • The window for accepting open enrollment changes is generally open from 30 days before the new effective date through 30 days after. Some Noyo carriers open 60 days ahead.
  • Unlike EDI, platforms can send current plan year changes (eg new hire, QLE, termination, or demographic changes) as normal via API, even while the group’s open enrollment window is open!
  • All transaction statuses for current year and new plan year changes can be monitored in the Noyo dashboard, and they have the added protection of Noyo round-trip confirmation. Noyo validates every member change when sent and confirms correct completion on the effective date, directly in the carrier system.
Step 1: Group shops for renewal options and makes a selection

Renewal plan decisions are communicated to the carrier directly, outside of Noyo.

Step 2: Inform Noyo of your group’s renewal decisions via API

Send renewal decision details for each group using Noyo’s Renewal Readiness APIs.

Because renewal decisions for each group are communicated directly to the carrier and configured outside of view of the Noyo system, Noyo needs to know what plan decisions you expect ie what “readiness to enroll” looks like for each group at the carrier.

Renewal Readiness APIs are a simple way for benefits software platforms to tell Noyo about the expected renewal decisions for a group so that Noyo can persistently check the carrier system and confirm exactly when member enrollment for the new plan year can begin.

Step 3: Noyo detects when the carrier has processed plan-level changes

Noyo checks the carrier system daily to detect when renewal decisions have been applied. If Noyo detects a change at the carrier, the group’s data will be refreshed and status updated accordingly.

Step 4: Poll the Noyo API for “readiness” status of each group

Current status is available via Renewal Readiness APIs, and is updated as group level changes are detected (e.g., plan names, renewal date, etc.). Noyo surfaces any differences between what platforms expect and what the data at the carrier shows.

Step 5: Submit member enrollment decisions via API

As soon as the “readiness” status is ready, you’ll submit open enrollment member requests to get members enrolled.

  • The window for accepting open enrollment changes is generally open from 30 days before the new effective date through 30 days after. Some Noyo carriers open 60 days ahead.
  • Unlike EDI, platforms can send current plan year changes (eg new hire, QLE, termination, or demographic changes) as normal via API, even while the group’s open enrollment window is open!
  • All transaction statuses for current year and new plan year changes can be monitored in the Noyo dashboard, and they have the added protection of Noyo round-trip confirmation. Noyo validates every member change when sent and confirms correct completion on the effective date, directly in the carrier system.
Step 1: Group shops for renewal options and makes a selection

Renewal plan decisions are communicated to the carrier directly, outside of Noyo.

Step 2: Inform Noyo of your group’s renewal decisions via API

Send renewal decision details for each group using Noyo’s Renewal Readiness APIs.

Because renewal decisions for each group are communicated directly to the carrier and configured outside of view of the Noyo system, Noyo needs to know what plan decisions you expect ie what “readiness to enroll” looks like for each group at the carrier.

Renewal Readiness APIs are a simple way for benefits software platforms to tell Noyo about the expected renewal decisions for a group so that Noyo can persistently check the carrier system and confirm exactly when member enrollment for the new plan year can begin.

Step 3: Noyo detects when the carrier has processed plan-level changes

Noyo checks the carrier system daily to detect when renewal decisions have been applied. If Noyo detects a change at the carrier, the group’s data will be refreshed and status updated accordingly.

Step 4: Poll the Noyo API for “readiness” status of each group

Current status is available via Renewal Readiness APIs, and is updated as group level changes are detected (e.g., plan names, renewal date, etc.). Noyo surfaces any differences between what platforms expect and what the data at the carrier shows.

Step 5: Submit member enrollment decisions via API

As soon as the “readiness” status is ready, you’ll submit open enrollment member requests to get members enrolled.

  • The window for accepting open enrollment changes is generally open from 30 days before the new effective date through 30 days after. Some Noyo carriers open 60 days ahead.
  • Unlike EDI, platforms can send current plan year changes (eg new hire, QLE, termination, or demographic changes) as normal via API, even while the group’s open enrollment window is open!
  • All transaction statuses for current year and new plan year changes can be monitored in the Noyo dashboard, and they have the added protection of Noyo round-trip confirmation. Noyo validates every member change when sent and confirms correct completion on the effective date, directly in the carrier system.

How does renewal readiness work?

Noyo has made it easy to submit renewal decisions for a group and know exactly when open enrollment can begin.
Open Enrollment Flowchart
Step 1

Platforms send a request to POST /api/v1/groups/:group_id/renewal_decisions with group_id, renewal_date, carrier_id, and any details on lines_of_coverage.

Step 2

A valid POST request will prompt Noyo to pull data from the carrier system and return a status of submitted, meaning our system is checking data at the carrier.

Step 3

Within 4 days of initial request, Noyo checks to see if the carrier has the matching information submitted in the renewal decision and updates the request status.

  • a. ready: If Noyo finds that all plans exist in the carrier and match the platform’s expectations, then Noyo sets the status to ready and applies a full data refresh for the group. Platforms can immediately submit open enrollment member requests to get members enrolled.
  • b. not_ready: If Noyo finds that there are differences between the carrier and the platform’s renewal decision, then we set the status to not_ready, create issues to track the differences found, and apply a full data refresh for the group.
Step 4

Platform polls the Noyo API to receive daily status updates for renewal decisions for each group.

Step 5

Every day until 30 days after the renewal date, Noyo checks the carrier for any changes to the group’s renewal decision. This is done regardless of the status of the group’s renewal decision. If there is a change, Noyo updates the status and issue fields accordingly and refreshes data for the group.

Step 1

Platforms send a request to POST /api/v1/groups/:group_id/renewal_decisions with group_id, renewal_date, carrier_id, and any details on lines_of_coverage.

Step 2

A valid POST request will prompt Noyo to pull data from the carrier system and return a status of submitted, meaning our system is checking data at the carrier.

Step 3

Within 4 days of initial request, Noyo checks to see if the carrier has the matching information submitted in the renewal decision and updates the request status.

  • a. ready: If Noyo finds that all plans exist in the carrier and match the platform’s expectations, then Noyo sets the status to ready and applies a full data refresh for the group. Platforms can immediately submit open enrollment member requests to get members enrolled.
  • b. not_ready: If Noyo finds that there are differences between the carrier and the platform’s renewal decision, then we set the status to not_ready, create issues to track the differences found, and apply a full data refresh for the group.
Step 4

Platform polls the Noyo API to receive daily status updates for renewal decisions for each group.

Step 5

Every day until 30 days after the renewal date, Noyo checks the carrier for any changes to the group’s renewal decision. This is done regardless of the status of the group’s renewal decision. If there is a change, Noyo updates the status and issue fields accordingly and refreshes data for the group.

Step 1

Platforms send a request to POST /api/v1/groups/:group_id/renewal_decisions with group_id, renewal_date, carrier_id, and any details on lines_of_coverage.

Step 2

A valid POST request will prompt Noyo to pull data from the carrier system and return a status of submitted, meaning our system is checking data at the carrier.

Step 3

Within 4 days of initial request, Noyo checks to see if the carrier has the matching information submitted in the renewal decision and updates the request status.

  • a. ready: If Noyo finds that all plans exist in the carrier and match the platform’s expectations, then Noyo sets the status to ready and applies a full data refresh for the group. Platforms can immediately submit open enrollment member requests to get members enrolled.
  • b. not_ready: If Noyo finds that there are differences between the carrier and the platform’s renewal decision, then we set the status to not_ready, create issues to track the differences found, and apply a full data refresh for the group.
Step 4

Platform polls the Noyo API to receive daily status updates for renewal decisions for each group.

Step 5

Every day until 30 days after the renewal date, Noyo checks the carrier for any changes to the group’s renewal decision. This is done regardless of the status of the group’s renewal decision. If there is a change, Noyo updates the status and issue fields accordingly and refreshes data for the group.

Download PDF
See all Noyo use cases