Send Annual Enrollments

This page describes how to add one or many new subscribers for a given ICHRA election

Checklist

• Create a Group

• Create Members

  • Store Member Id(s) and Check Status

• Create Coverage Period, Plans

• Determine Event in Platform System

• Map Elections

• Send QLE Request(s)

  • Store QLE Id(s) and Check Status

• Carrier Transmission

• Error Reporting

Gather Elections after Plan Selection

Individuals that are offered an ICHRA will browse plans and select which plan and family members are covered.

Within a individual's covered family, all family members might be covered under the same plan. In specific cases, family members who generally would be dependent children can elect Child-Only or individual coverage in another plan. This is often due to the dependent child member living out-of-state before the age of 26.

Create a Group

Description

In the Platform system, elections begin for a given set of members. A user or process identifies these elections and creates a group in the Ideon system.

Create Members

Send Subscriber Demographics

Member information can be added at this time, or later after elections occur, as subscribers and dependents are primarily related to the group object.

If sending at the time of election:

• confirm if a member was created in Ideon's system for this Group,

• If a subscriber is needed, we would expect a POST request to create a new subscriber before creating a qualifying_life_event request.

Request:

Create Subscriber
{
    "subscriber": {
        "external_identifier": "Subscriber1",
        "location_id": "{{primary_location_id}}",
        "first_name": "Employee Three",
        "last_name": "Ideonu",
        "birth_date": "1991-05-30",
        "gender": "male",
        "social_security_number": "{{ssn}}",
        "employment_details": {
            "start_date": "2024-08-15",
            "status": "full_time"
        },
        "dependents": [
        ],
        "residential_address": {
            "address_line_1": "34 B Street",
            "address_line_2": "#14",
            "city": "Winchester",
            "fips_county_code": "32111" ## Include County for most accurate validations
            "state": "VA",
            "zip": "22603"
        },
        "mailing_address": {            ## Send Mail Add. if Different from Res. Add
            "address_line_1": "41 W 15th St",
            "city": "Melville",
            "fips_county_code": "32111"
            "state": "MA",
            "zip": "44603"
        },
        "phone_numbers":[{          ## Send all/any communication if present and valid
        	"type": "work",
        	"contact": "7777777777"
        },
        {
        	"type": "home",
        	"contact": "7777777777"
        },
        {
        	"type": "fax",
        	"contact": "7777777777"
        }],
    	"emails":[{
        	"type": "work",
        	"contact": "[e-mail]"
        }]
    }
}

Store Member Id(s) and Check Status

In order to refer to this subscriber later, and send coverages, your system should save the successful response body and store the id associated with the subscriber.

Check the Status of the request to determine if you received an Error on formatting or content of the request - an error that requires you to update the request body content or format is generally listed as Status 422

• Save and analyze response

• Confirm Success Status

  • If Failure, Store and Address this Failure

  • Once addressed, Retry the Request

• Store the Response payload, particularly the id for later use

Create a Coverage Period, Plans

As elections begin to come in for a given group and subscribers , several more objects can be created:

• a coverage period

• a set of plans

A process would create a coverage period which includes the carrier and time period in which these elections are effective. Individual coverage dates are provided in each election.

As elections are created, each unique HIOS Id will need a corresponding plan created. This is primarily related to the coverage period, as the plans are carrier-specific.

We will require that each plan has a plan_identifier present. This is formatted as a HIOS Id - 12345NY0010011 (or suffixed 12345NY0010011-01 ,etc.) - which is the identifier explicitly and unqiuely tied to this plan option at the Carrier.

Example 1 - So far, one Medical Carrier has been elected across the members:

• Anthem - 4 plan options were elected across subscribers:

  • 41046NY0020015 Silver

  • 41046NY0020016 Bronze

  • 41046NY0010016 Gold

  • 41046NY0020022 Platinum

Each of these options above would be created as a plan in Ideon using a POST to coverage_peroids/{id}/plans

• The description would be the plan marketing name

• The plan_identifier would match the HIOS Id - i.e., 41046NY0020015

• We would anticipate a platform to create:

  • One Group,

  • One Coverage Period, and

  • Four Plans for the example above

Example 2 - During elections, two Medical Carriers were elected by the members:

• Medical with kaiser

  • 40513CA0380003 Silver

  • 40513CA0380004 Bronze

• Medical and Anthem

  • 41046NY0020015 Silver

  • 41046NY0020016 Bronze

  • 41046NY0010016 Gold

  • 41046NY0020022 Platinum

Each of these options above would be created as a plan in Ideon using a POST to coverage_peroids/{id}/plans

• The description would be the plan marketing name

• The plan_identifier would match the HIOS Id - i.e., 41046NY0020015

• We would anticipate a platform to create:

  • One Group,

  • Two Coverage Periods,

    • one with kaiser

    • one with anthem,

  • a set of 2 and 4 plans on those Coverage Periods, respectively

A detailed description per endpoint can be found in Enrollment API Features and our Mapping Guides.

Map Elections

Description

Given an employee and their family members,

If that member selects benefits for a given HIOS Id,

Then the platform should:

• confirm whether the coverage period has been created

• confirm whether the HIOS Id/plan option exists in that coverage period

• create a plan with corresponding plan_identifier

Then the Platforms system should create qualifying_life_events for each set of coverages with a Carrier.

• If not stored as an association, fetch the created plan uuids by using a GET request to coverage_periods/id

• Otherwise map the elected options to a request, using the id per plan to represent the elected option in your system

Send Qualifying Life Event Request(s)

Description

In this example. the member is electing Medical coverage for an Anthem Plan

If desired, 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

• plan_id - this refers to an id, of a plan option created in the Ideon system. This corresponds to a single plan option.

  • 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 First of this month, Same Day, or First of the Next Month for new hires.

This would be created by sending a POST request to subscriber/{{id}}/qualifying_life_events

Pass an Enrollment Using am and Premium Amount

POST subscribers/{{subscriber_id}}/qualifying_life_events
{
    "qualifying_life_event": {
        "event": "open_enrollment",
        "date": "{{today}}",
        "eligibility_start_date": "{{first_of_current_month}}",
        "coverage_period_id": "{{coverage_period_id}}",
        "plan_elections": {
            "medical": {
                "plan_id": "{{uuid_of_plan_election}}", ## our reference to plan
                "type": "election",
                "policy_premium_amount": 45123, ## optional
                "coverages": [
                    {
                        "member_id": "{{subscriber_id}}",
                        "status": "employer_sponsored",
                        "start_date": "{{first_of_current_month}}"
                    }
                ]
            }
        }
    }
}

Store QLE Id(s) and Check Status

In order to confirm the status of this QLE and the easily refer to this exact request later, your system should save the successful response body and store the id associated with each QLE.

Check the Status of the request to determine if you received an Error on formatting or content of the request - an error that requires you to update the request body content or format is generally listed as Status 422

• Save and analyze response

• Confirm Success Status

  • If Failure, Store and Address this Failure

  • Once addressed, Retry the Request

• Store the Response payload, particularly the id for later use