> ## Documentation Index
> Fetch the complete documentation index at: https://docs.noyo.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Qualifying Life Event (QLE)
The Member Request workflow is now deprecated in favor of [Member
Snapshot](/docs/members/using-snapshots/using-snapshots)
## Qualifying Life Event
The QLE member request is used to make changes to existing employees, dependents and coverages due to a qualifying life event.
[using snapshots](/docs/members/using-snapshots/using-snapshots)
[Qualifying life event member request](/api-reference/requests/qualifyinglifeeventmemberrequest)
### 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`\* | string | Qualifying 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`\* | string | ISO-8601 date string for qualifying life event date |
### Event Types Available
| Value | Description |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `adoption` | This applies in the event that a member is looking to either add or remove coverage as a result of an adoption. |
| `change_to_full_time` | This is often tied to benefit class or time status changes. |
| `change_to_part_time` | This is often tied to a reduction of hours or a benefit class change. |
| `court_order` | This is also sometimes known as QMCSO (qualified medical child support orders). |
| `death` | This 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_enrollment` | This refers to a case in which the dependent is removing themselves from another member's coverage and going through their own open enrollment. |
| `divorce` | This applies in the event that a member is looking to either add or remove coverage as a result of a divorce. |
| `foster_care` | This refers to a member adding a foster child to coverage. |
| `immigration_status_change` | This can refer to a case in which the spouse obtains a green card and is then added to member's coverage. |
| `legal_guardian` | This is applicable when a member becomes a legal guardian for a child and adds the child to coverage. |
| `lost_coverage` | This 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. |
| `marriage` | This applies in the event that a member is looking to either add or remove coverage as a result of a marriage. |
| `medicare` | This is applicable when a member gains medicare coverage or when member loses medicare coverage. |
| `moved` | In this scenario, an address change makes someone either eligible or ineligible for coverage. |
| `newborn` | This 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_change` | A change made outside of conventional open enrollment or special enrollment periods. |
| `rate_changed` | This 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. |
| `rehire` | Noyo currently makes no distinction between rehire and reinstatement cases. This code is applicable in both cases. |
| `reinstatement` | Coverage 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 [Get carrier configuration by group list](/api-reference/groups/configurations/get-carrier-configuration-by-group-list) to get additional carrier-specific data. The `lines_of_coverage` object allows the following keys:
| Key | Description |
| -------------------- | -------------------------------- |
| `accident` | Accident |
| `add` | Accidental Death & Dismemberment |
| `cancer` | Cancer |
| `critical_illness` | Critical Illness |
| `dental` | Dental |
| `hospital_indemnity` | Hospital Indemnity |
| `life` | Life |
| `ltd` | Long Term Disability |
| `medical` | Medical |
| `std` | Short Term Disability |
| `vision` | Vision |
### 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_date` | string | ISO-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 [Get group plan list](/api-reference/groups/plans/get-group-plan-list) 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.
### 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`).
| Field | Type | Description |
| :--------------- | :------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `id` | uuid | Unique identifier for the coverage |
| `member_type` | string | Type of member adding coverage. One of: `dependent`, `employee` |
| `plan_id` | uuid | Unique identifier of the group plan in Noyo |
| `volume` | integer | Elected volume for the type of coverage being selected |
| `prior_coverage` | object | - `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`\* | uuid | Unique identifier of the employee or dependent in Noyo |
| `member_type`\* | string | Type of member removing coverage. One of: `dependent`, `employee` |
| `plan_id` | uuid | Unique identifier of the group plan in Noyo |
| `reason`\* | string | Reason 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`\* | uuid | Unique identifier of the employee or dependent in Noyo |
| `member_type`\* | string | Type of member modifying coverage. One of: `dependent`, `employee` |
| `plan_id` | uuid | Unique 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`\* | uuid | Unique identifier of the employee or dependent in Noyo |
| `member_type`\* | string | Type of member modifying coverage. One of: `dependent`, `employee` |
| `plan_id` | uuid | Unique identifier of the group plan in Noyo |
| `volume`ΛΆ | integer | Elected volume for the type of coverage being selected |
### Qualifying Life Event Member Request Result
> Sample Request Result
```json theme={"system"}
{
"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`\* | uuid | Unique identifier of the employee or dependent in Noyo |
| `member_type`\* | string | Type of member for the member enrollment result. One of: `dependent`, `employee` |
| `individual_enrollment_id`\* | uuid | Unique 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](#qualifying-life-event-member-request-result).