Open Enrollment & Renewals
This page describes how to transition a given employer to a new plan year
Last updated
Was this helpful?
This page describes how to transition a given employer to a new plan year
Last updated
Was this helpful?
Was this helpful?
Near the end of the plan year or policy contract, an employer will choose to either continue with the same carrier, same plans, or make changes.
There are five common renewal scenarios:
Renewing As Is
No material changes to Carrier, Plan Options, or structure. This should be a lower-effort, quick renewal. In this case the coverage period can be placed into Production rapidly after initial QA.
Structure Changes
Dependent on the Carrier and nature of the structure changes, there could be No Testing Needed. In this case the coverage period can be placed into Production rapidly after initial QA.
If Carrier Testing is needed, a full workflow will be completed for the Group Setup. This could mean a small delay on the coverage period being placed back into Production.
Moving Carriers
This scenario is treated as a fully new connection. This means that a full workflow will be completed for the Group Setup. This could mean a small delay on the coverage period being placed back into Production.
Expire at End of Plan Year
The employer is not renewing with a supported Carrier. This coverage period will be marked as Expired at the end of the plan year
Given a previously created coverage period,
If today's date is approaching the Coverage Period End Date,
Then the Platform user should evaluate whether an employer is Renewing.
In the Platform system, a user should evaluate whether there are Changes to Plans, Carriers, or billing structure elements. If present, these changes could mean some additional set-up steps need to be taken by the Ideon Operations team.
Identify:
Renewing Employer
Changes to Carrier
Changes to Plan Options
Changes to Billing structure
Based on what we identified in Step 1, we might be able to re-use some of the Platform system elements.
This will generate a new Coverage Period Id that can be associated with the new plan year's Plan Options and Qualifiying Life Events.
Example
An employer named SweetData, Inc. is currently being transmitted on a guardian coverage period.
As we approach the end date of the coverage period, a new coverage period is created. The carrier_group_number is likely unchanged, while the waiting period and coverage start date could change.
Create Coverage Period
{
"coverage_period": {
"external_identifier": "Test_CP_1",
"waiting_period": {
"coverage_start": "first_of_following_month",
"waiting_period": "30_days"
},
"coverage_start_date": "2024-11-01",
"carrier_name": "guardian",
"carrier_group_number": "34352"
}
}
A new call to Complete Set-up will alert the Operations team of a new coverage period.
Based on what we identified in Step 1, we might be able to re-use some of the Platform system elements.
If Plan Options are created in your Platform system, and these are not changing:
you can call the API again for that same information
use the new coverage period id - and generate a new instance of that same plan.
This requires one POST request per plan option to create that new UUID.
An easy way to identify plan options is to use an External Identifier value.
This same External Identifier value can be associated with a plan on the Current coverage period, and the same "option" on the New coverage period.
Example
An employer is adding Dental and keeping the same two Medical Options, and one Vision Option as the last plan year
The Platform system should call the API four times, to create four plan ids
Dental -> new, this was created in the Platform system for this year
Medical 1 -> renewing, the plan option already exists in the Platform system, but a POST request is needed to create a new Id for this coming plan year.
Medical 2 -> renewing, the plan option already exists in the Platform system, but a POST request is needed to create a new Id for this coming plan year.
Vision -> renewing, the plan option already exists in the Platform system, but a POST request is needed to create a new Id for this coming plan year.
Request
Dental
POST to coverage_period/{id} where id is the New Year CP
{
"plan": {
"external_identifier": "dental_1_plan", <- new this year
"description": "$50 Ded / $1500 Annual Max / $1000 Ortho", <- new this year
"product_line": "dental",
"product_type": "preferred_provider_organization",
"premium_level": "base"
}
}
Medical 1
POST to coverage_period/{id} where id is the New Year CP
{
"plan": {
"external_identifier": "medical_1_plan", <- same as last year
"description": "Gold-$0-$8950 (w/o Rx Ded)", <- same as last year
"product_line": "medical",
"product_type": "preferred_provider_organization"
}
}
Medical 2
POST to coverage_period/{id} where id is the New Year CP
{
"plan": {
"external_identifier": "medical_2_plan", <- same as last year
"description": "Platinum-$0-$8950 (w/o Rx Ded)", <- same as last year
"product_line": "medical",
"product_type": "health_maintenance_organization"
}
}
Vision
POST to coverage_period/{id} where id is the New Year CP
{
"plan": {
"external_identifier": "vision_1_plan", <- same as last year
"description": "Vision Option 1", <- same as last year
"product_line": "vision",
"product_type": "preferred_provider_organization",
"premium_level": "base"
}
}
Workflow tasks are created for Ideon's Operations team. These guide us to gather the required documentation and complete testing with the Carrier
We preform tasks relevant to the following:
Initial QA - Confirm coverages and completeness
Gather Account Structure and SFTP - Fetch carrier and group specific information
Configuration and QA - Apply and QA group specific information
Final QA - Holistic QA and step to evaluate accuracy
A group might be paused at Initial QA if it lacks coverages for the plan year, which is common at Open Enrollment. The Ideon Operations team will take the coverage period as far into the workflow as possible and then await OE members and coverages. These can be added progressively during OE, or right after OE elections are closed.
In the Platform system, member elections might not be available until after the Open Enrollment election period has ended.
Gather election and demographic data keeping in mind the following:
Employees can retract coverages that were elected during the OE period, until it has ended. That could result in a correction needed, when a member election is sent but the member has since retracted. See the Termination Never Effective Scenario guide for more details.
Employees that are not changing elections still need a new QLE with the correct Ids for the new plan year, or they could be omitted.
This QLE can be the same as last year but with the equivalent plan ids, and a new start coverage date, if applicable.
Employees that are ending elections at the end of the plan year can be sent:
As a waiver in the new plan year ("I am waiving coverages this year")
As an end dated coverage for the new plan year ("I ended coverages last year")
As an end dated coverage on the previous plan year ("I ended coverages at the end of this year")
This member would then not be present at all on the new coverage period.
When members and elections are available, use the POST endpoints to create new subscribers, or add a New QLE to existing ones. The components you use should be the one identified and created in the Steps above.
In this example. the member is electing Basic Life /AD&D and Disability coverages.
If you don't have the current member data and id for the subscriber, use a GET call on the Group retrieve the latest subscriber data for that Group
subscriber_id -this refers to the id of the created subscriber
coverage_period_id - this refers to the id of the created coverage period
This is the link between the carrier and the subscriber
dental_plan_id - this refers to the id of the created plan, in this case the New Coverage Period's Dental Plan
medical_1_plan_id - this refers to the id of the created plan, in this case the New Coverage Period's equivalent "Medical 1". This is the new id for the same plan in the platform system.
vision_plan_id - this refers to the id of the created plan, in this case a Vision Plan
today - is the date that the Platform system is generating the event
first_of_current_month - this refers to a placeholder, The first of day of the current calendar month. This is commonly the start of the policy for a new coverage period QLE (first or specific date of the month.
This would be created by sending a POST request to subscriber/{{id}}/qualifying_life_events
POST subscribers/{{subscriber_id}}/qualifying_life_events
{
"qualifying_life_event": {
"event": "newly_eligible",
"date": "{{today}}",
"eligibility_start_date": "{{first_of_current_month}}",
"coverage_period_id": "{{coverage_period_id}}", <- NEW coverage period id
"plan_elections": {
"dental": {
"plan_id": "{{dental_plan_id}}", <- NEW plan and plan id
"type": "election",
"coverages": [
{
"member_id": "{{subscriber_id}}",
"status": "employer_sponsored",
"start_date": "{{first_of_current_month}}"
}
]
},
"medical": {
"plan_id": "{{medical_1_plan_id}}", <- Same plan, NEW plan id
"type": "election",
"coverages": [
{
"member_id": "{{subscriber_id}}",
"status": "employer_sponsored",
"start_date": "{{first_of_current_month}}"
}
]
},
"vision": {
"plan_id": "{{vision_plan_id}}", <- Same plan, NEW plan id
"type": "election",
"coverages": [
{
"member_id": "{{subscriber_1_id}}",
"status": "employer_sponsored",
"start_date": "{{first_of_current_month}}"
}
]
}
}
}
}When Ideon receives this Subscriber coverage, we identify whether the member was previously enrolled by our system.
In Test: Transmit the member to Ideon as well as in your current administration method. This is to ensure that both systems know the member's status and won't delay an enrollment for the member.
In Production: Transmit the member to Ideon. We will:
send an API request to enroll or rehire the member
Store the members coverages but not re-enroll
send the member on the next File Delivery to the Carrier (within 7 business days)