Open Enrollment & Renewals

This page describes how to transition a given employer to a new plan year

Checklist

Components

  1. Identify Renewing Employer

  2. Identify Changes to Carriers, Plans

  3. Create New Coverage Period

  4. Create New Plan Ids

  5. Ideon Group Setup

  6. Identify OE Members and Coverages

  7. Create OE Elections

  8. Carrier Transmission

Identify Renewing Employer

Description

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

Identify Changes to Carriers, Plans

Description

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:

  1. Renewing Employer

  2. Changes to Carrier

  3. Changes to Plan Options

  4. Changes to Billing structure

Create New Coverage Period

Description

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.

Request

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.

Create New Plan Ids

Description

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"
        
    }
}

Ideon Group Setup

Description

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.

Identify OE Members and Coverages

Description

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 can change coverages, resulting in more than one QLE sent to Ideon. If a member changes coverages after an election has been sent, a new QLE would be needed to "supersede" that unsent coverage.

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.

Create OE Elections

Description

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

Request

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}}"
                    }
                ]
            }
        }
    }
}

Carrier Transmission

Description

  • 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)

PreviousTermination Never EffectiveNextICHRA Management

Last updated

Was this helpful?