Qualifying Life Event (QLE)

🚧

The Member Request workflow is now deprecated in favor of Member Snapshot

Qualifying Life Event

The QLE member request is used to make changes to existing employees, dependents and coverages due to a qualifying life event.

Create Qualifying Life Event Member Request

The Event Object

Each Qualifying Life Event requires an event parameter in the body which provides information about the type of the event as well as the date of its occurance. The schema for the event must follow this structure:

event_type*stringQualifying life event type. One of: adoption, change_to_full_time, change_to_part_time, classifications_change, court_order, death, dependent_open_enrollment, divorce, foster_care, immigration_status_change, legal_guardian, lost_coverage, marriage, medicare, moved, newborn, offline_change, rate_changed, rehire, reinstatement
event_date*stringISO-8601 date string for qualifying life event date

Event Types Available

ValueDescription
adoptionThis applies in the event that a member is looking to either add or remove coverage as a result of an adoption.
change_to_full_timeThis is often tied to benefit class or time status changes.
change_to_part_timeThis is often tied to a reduction of hours or a benefit class change.
court_orderThis is also sometimes known as QMCSO (qualified medical child support orders).
deathThis is applicable to employee, child, or spouse deaths and can be passed when adding or removing coverage due to death. Sending this is useful clarification in survivorship scenarios.
dependent_open_enrollmentThis refers to a case in which the dependent is removing themselves from another member's coverage and going through their own open enrollment.
divorceThis applies in the event that a member is looking to either add or remove coverage as a result of a divorce.
foster_careThis refers to a member adding a foster child to coverage.
immigration_status_changeThis can refer to a case in which the spouse obtains a green card and is then added to member's coverage.
legal_guardianThis is applicable when a member becomes a legal guardian for a child and adds the child to coverage.
lost_coverageThis is a catch-all for when a member is losing coverage not due to any other QLEs mentioned above. This is applicable when adding someone to coverage due to lost coverage elsewhere and also when removing them from coverage.
marriageThis applies in the event that a member is looking to either add or remove coverage as a result of a marriage.
medicareThis is applicable when a member gains medicare coverage or when member loses medicare coverage.
movedIn this scenario, an address change makes someone either eligible or ineligible for coverage.
newbornThis applies in the event that a member is looking to either add or remove coverage as a result of the birth of a child.
offline_changeA change made outside of conventional open enrollment or special enrollment periods.
rate_changedThis refers to a specific case in which a rate changes after the employee elects coverage. Some benefits administration platforms allow the employee to reselect coverage if they are dissatisfied with the new rates in these cases.
rehireNoyo currently makes no distinction between rehire and reinstatement cases. This code is applicable in both cases.
reinstatementCoverage is being resumed after a gap.

The QLE Coverages Object

The coverages array contains one entry for each carrier with which you would like to make changes to coverage. The carrier_id along with the schema of the carrier_config object will be provided by the Noyo team. You can reference the group carrier configuration resource to get additional carrier-specific data. The lines_of_coverage object allows the following keys:

KeyDescription
accidentAccident
addAccidental Death & Dismemberment
cancerCancer
critical_illnessCritical Illness
dentalDental
hospital_indemnityHospital Indemnity
lifeLife
ltdLong Term Disability
medicalMedical
stdShort Term Disability
visionVision

Signature Date

Within each entry in the coverages array you can optionally specify a signature_date. The signature_date is the date when the employee or employer signed for the change to be made. If a signature_date is not provided we will communicate the date the member request was received by the Noyo system as the signature_date to the carrier.

signature_datestringISO-8601 date string for signature date

Coverage Actions

Within each object inside of lines_of_coverage you may provide three different actions: adding_coverage, removing_coverage, and modifying_coverage. More information about each of these is below.

Adding Coverage

The adding_coverage action is used to add new coverage for a member with a carrier. You must provide an adding_coverage entry for each employee or dependent that is enrolling in coverage with the carrier. The plan_id field is optional in each action. If you do not specify a plan_id, we will try to automatically select an available plan for the member based on the current group plans. When the group has more than one eligible plan for a member, you will need to specify the plan_id in the request. Plan IDs can be retrieved using the group plans endpoint.

Adding medical, dental, vision, accident, cancer or hospital_indemnity coverage

Medical, dental, vision, accident, cancer and hospital indemnity coverage do not require any information beyond the member information and the selected plan.

id*uuidUnique identifier of the employee or dependent in Noyo
member_type*stringType of member adding coverage. One of: dependent, employee
plan_iduuidUnique identifier of the group plan in Noyo
prior_coverageobject
  • carrier_name*: Name of insurance carrier providing prior coverage
  • last_coverage_date*: ISO-8601 date string of the last day of coverage with the prior insurance carrier

Adding life, add, std, ltd or critical_illness coverage

Life, AD&D, STD, LTD and critical illness coverage also optionally accept volume parameter in dollars (e.g. $50,000 should be sent as 50000).

id*uuidUnique identifier of the employee or dependent in Noyo
member_type*stringType of member adding coverage. One of: dependent, employee
plan_iduuidUnique identifier of the group plan in Noyo
volumeΛ’integerElected volume for the type of coverage being selected
prior_coverageobject
  • carrier_name*: Name of insurance carrier providing prior coverage
  • last_coverage_date*: ISO-8601 date string of the last day of coverage with the prior insurance carrier

Removing Coverage

The removing_coverage action is used to remove coverage from a member with a carrier. The structure of the removing_coverage action is below:

id*uuidUnique identifier of the employee or dependent in Noyo
member_type*stringType of member removing coverage. One of: dependent, employee
plan_iduuidUnique identifier of the group plan in Noyo
reason*stringReason the member is removing or canceling coverage. One of: medi-cal, medicaid, no-coverage, other-cobra, other-employee-group, other-ind-off-exchange, other-ind-on-exchange, other-medicare, other-parent-group, other-spouse-group, retiree-coverage, tricare-coverage, va-coverage, voluntary-withdrawal

Modifying Coverage

The modifying_coverage action is used to make changes to an existing coverage for a member / plan combination, given that the member already has coverage on that plan with the carrier. For example, you can use the modifying_coverage action to change the volume of coverage for a member's existing life or disability plan, or provide a new carrier_config to remain on the same plan but move the member into a new subgroup or benefit class.

Modifying medical, dental, vision, accident, cancer or hospital_indemnity coverage

Medical, dental, vision, accident, cancer and hospital_indemnity coverage do not require any information beyond the member information and the selected plan.

id*uuidUnique identifier of the employee or dependent in Noyo
member_type*stringType of member modifying coverage. One of: dependent, employee
plan_iduuidUnique identifier of the group plan in Noyo

Modifying life, add, std, ltd and critical_illness coverage

Life, AD&D, STD, LTD and critical illness coverage also optionally accept volume parameter in dollars (e.g. $50,000 should be sent as 50000).

id*uuidUnique identifier of the employee or dependent in Noyo
member_type*stringType of member modifying coverage. One of: dependent, employee
plan_iduuidUnique identifier of the group plan in Noyo
volumeΛ’integerElected volume for the type of coverage being selected

Qualifying Life Event Member Request Result

Sample Request Result

{
    "dental": [{
        "member_id": "72af10df-a8b3-46f1-a114-ac36d4b8a6ea",
        "member_type": "employee",
        "individual_enrollment_id": "ff033377-59e2-40df-8206-8cec3a725411"
    }, {
        "member_id": "165d4537-be5f-4744-8a97-a5b10fcb75b1",
        "member_type": "dependent",
        "individual_enrollment_id": "ff033377-59e2-40df-8206-8cec3a725411"
    }],
    "vision": [{
        "member_id": "72af10df-a8b3-46f1-a114-ac36d4b8a6ea",
        "member_type": "employee",
        "individual_enrollment_id": "08f9e430-9686-4b07-9e2c-6b26b8133dc3"
    }, {
        "member_id": "165d4537-be5f-4744-8a97-a5b10fcb75b1",
        "member_type": "dependent",
        "individual_enrollment_id": "08f9e430-9686-4b07-9e2c-6b26b8133dc3"
    }]
}

Upon the successful completion of all the transactions in the qualifying life event member request, the status of the member request will be updated to completed and the result of the member request will be an object with a key for each coverage (e.g. dental, vision) and an array with the following:

member_id*uuidUnique identifier of the employee or dependent in Noyo
member_type*stringType of member for the member enrollment result. One of: dependent, employee
individual_enrollment_id*uuidUnique identifier of the individual enrollment in Noyo created by the member request

Qualifying Life Event Transactions

One or more qualifying life event transactions will created based on the requested changes in the coverages array. For some carriers, there may be a single transaction including all of the requested changes, while other carriers may require separate transactions for each action type (i.e. one transaction per action per carrier).

Qualifying Life Event Member Transaction completed Result

Upon the successful completion of the transaction, the status of the member transaction will be updated and the result of the member transaction will be in the same format as the member request result.