API Validations

This page contains a list of current synchronous API error messages. These display as results from a failed request, and result in no resource being created at Ideon.

Table

Message Text
How to resolve

The plan id '{plan_id}' does not belong to coverage period '{coverage_period_id}'

The plan ids in the QLE don't align with coverage period, or the product lines that they have.

Example 1 :

  • Creating a QLE for coverage period id 456, the body of the request has plan_id 22.

  • plan_id 22 was created under coverage period 123 and not 456.

How to resolve:

  • update either the plan_id value or the coverage_period_id to preform the intended action

must have {product_line} plan for {product_line} election but got {plan_product_line} plan {plan_id}

The product_line that is associated with the plan id in the QLE doesn't align with the product_line on the created plan.

Example 1 :

  • Creating a QLE with plan elections for plan_id 22 - using the value voluntary_life

  • plan_id 22 was created as a dental plan

How to resolve:

  • update either:

    • the plan_id value

    • the product_line

  • or create a new plan with the expected product_line + product_type values

A full mapping guide of plan product lines and election product lines can be found here.

all members must be related to the subscriber, {member_ids} are related to a different subscriber

One or more of the dependent member ids used in the QLE is not related to the subscriber id used.

all members must exist, the following do not refer to existing members: {member_ids}

One or more of the dependent member ids used doesn't yet exist.

It may also be another system uuid or internal id.

all members must be specified once for {product_line}; duplicate(s) {member_ids}

One or more of the products in the plan_elections has a duplicated member id.

Example 1 :

  • Creating a QLE with plan elections for long_term_disability , listing member ids:

    • subscriber 23

    • dependent 11

    • dependent 12

    • dependent 11

  • in this case we would raise an error

    • all members must be specified once for long_term_disability; duplicate(s) dependent 11

To resolve this, only list a single election for the given member, under that product line

missing {pluralized_plan_elections} for {missing_product_lines}

This validation occurs when:

  • you attempt to create a QLE

  • the previous QLE contained a product line

  • that product line is no longer present in the new QLE

In order for us to properly communicate changes to a carrier, we can't have elections drop off without "closing the loop".

Once you tell us about a coverage, we must know about it in future QLEs too, until you end-date the coverage and successfully send that information to Ideon

You can prevent this by:

  • validating that each product line's election is delivered

  • enabling/ensuring that all product lines continue to send alongside new elections, new members, and changes

{product_line} coverages require a coverage for subscriber, member id {member_id}, but only saw coverages for {perceived_member_ids}

This validation occurs when:

  • you attempt to create a QLE

  • a dependent is electing coverage without a subscriber

  • Exception:

    • event is "cobra", in which a dependent can elect coverage without a subscriber.

  • A subscriber must be covered under a product line in order for a dependent to elect the product.

You can prevent this by:

  • validating that each dependent member is

    • affliated with a subscriber

    • end-dated or sent as cobra if their employee ends all coverages

{product_line} election has end_date {end_date}, which is more than one day before start_date {start_date}

This validation occurs when:

  • A coverage ends before its start date

  • Exception:

    • A coverage ends one day before it begins. This is considered a "Term Never Effective" and communicates to us & the carrier that a coverage was added in error, and should be removed and considered invalid.

You can prevent this by:

  • validating this condition and tracking occurrences

  • prevent invalid QLE creation by validating user inputs or invalid data

    • e.g. cannot enter end date before start date

    • explicit support for termination never effective scenarios

{product_line} election has dependent ({dependent_uuid}) coverage starting {dependent_start_date}, but dependent coverage must start on or after subscriber ({subscriber_uuid}) {product_line} coverage start date of {subscriber_start_date}

This validation occurs when:

  • one or more dependents on the QLE have invalid coverage dates where:

    • their coverage must start after or same day as a subscriber

    • and must end before a subscriber's coverage

You can prevent this by:

  • validating user input and calculated end dates

  • ensuring the correct and current coverages are being sent, for the correct benefit_status

{product_line} election has dependent ({dependent_uuid}) coverage continuing, but dependent coverage must end before or on subscriber ({subscriber_uuid}) {product_line} coverage end date of {subscriber_end_date}

This is an alternative validation message for a similar condition to above.

One or more dependents on the QLE have invalid coverage dates where:

  • a subscriber is given an end date, but not dependent;

  • a dependent has a coverage end date that is after their subscriber's end date

You can prevent this by

  • validating user input and calculated end dates

  • ensuring the correct and current coverages are being sent, for the correct benefit_status

{product_line} coverages for plan {plan_uuid} require a volume

This validation occurs when:

  • the plan elections product lines are one of:

    • voluntary_life

    • voluntary_accidental_death_dismemberment

    • voluntary_life_accidental_death_dismemberment

    • critical_illness

  • the created plan, refered to in the plan_id is voluntary =true

  • You might also receive "invalid valid for ____"-style errors for this condition

You can prevent this by:

  • ensuring that user's provide a value or your system selects one for volume

  • monitor and restrict changes to the voluntary value on plans - this value cannot be updated without recreating a plan, fetching the new plan_id, and creating new QLEs with the correct plan_id

{product_line} coverage was previously end dated and cannot be waived

This validation occurs when:

  • sending election type of waiver

  • but the previous coverages have been end dated

  • A coverage cannot be dropped off, or replaced with a waiver, even if they have been end dated.

You can prevent this by:

  • adjusting your system to monitor and "close" end dated coverages, in some way restricting waivers from being sent to these coverages

The qualifying life event date for new hires must be the employment start date

This validation occurs when:

  • event is new_hire

  • date value does not match the subscriber's employment_details.start_date value

For a "new_hire" event, the date of the QLE provided must be the same date given as the subscriber's employment start date

You can prevent this by:

  • adjusting the conditions that create a new_hire event

  • adjusting the dateprovided to be that of the "hiring" event for the member

  • adjusting the employment_details.start_date to the correct date for the member

when providing cobra and employer_sponsored coverages one set or both must include end_date

This validation occurs when:

  • providing cobra and employer sponsored coverages on the same QLE

  • and both set of coverages are active/ non-end dated

If a QLE provides cobra and employer_sponsored coverages, one or both must be end dated

You can prevent this by:

  • tracking the delivery of cobra and employer_sponsored coverage

  • excluding active cobra coverage until the delivery/creation of the employer_sponsored coverage end dates

  • excluding rehired employer_sponsored coverage until the delivery/creation of the cobra coverage end dates

QLE invalid - Coverage Period in "Expired" state

This validation occurs when:

  • you attempt to create a QLE

  • coverage period is in state expired

We only accept updates to coverage periods that are - or will be - transmitted to the carrier

You can prevent this by:

  • fetch the most current state for a coverage period before you attempt QLE creation

  • enforcing that users and system pipelines only create QLEs for non-expired states

You may not modify this QLE because it has been superseded by the following QLE(s): {uuids}

This validation occurs when:

  • a PUT to a QLE is attempted

  • the QLE in a "supereseded" state, i.e. it is old and not-most-current

You can prevent this by:

  • enforcing that users and system pipelines only create new QLEs (preferred)

  • Or only update current QLEs

plan_id is required for {product_line} coverage for member {member_id}

This validation occurs when:

  • a coverage is given, but no plan id is provided that tells us what plan it is for

You can prevent this by:

  • adjusting your system to ensure a plan relationship/ assignment before attempting to creating a QLE

All coverages with benefit status {benefit_status} for product line {product_line} must be for the same plan

This validation occurs when:

  • the plan election is for:

    • medical

    • dental

    • vision

  • All members in the same benefit_status (employer_sponsored, cobra) within that covered family, are not in the same plan, for that product line

    • These products require you to assign everyone to the same plan for a given covered family

You can prevent this by:

  • adjusting system logic to validate created plans and their assignees

plan_id cannot be in both the {product_line} plan election and the {product_line} coverages

This validation occurs if:

  • a plan_id exists in two or more plan_election blocks, in the same QLE

You can prevent this by:

  • enforcing a singular plan to product line relationship

    • a member should elect only one option under a given product line

    • a given plan option should only exist under 1 product line label

All coverages must start on {start_date} because the qualifying life event occurred on {event_date} and is subject to this plan's waiting period.

If your created plan has a waiting_period specified, it applies to the qualifying life events and elections.

To resolve this error, you can:

  • adjust or recreate a new plan to correct the waiting period

  • adjust the event date or event type on the QLE, to accurately reflect the event and date

  • adjust or correct the plan elections start_date

For New Hires, this error occurs when the start date specified on the QLE is before the event date+ plan waiting_period

For births, the date of the qualifying life event must be the birth date of the newly added dependent(s)

This validation occurs when:

  • the event value is birth

  • and the date value in the QLE which denotes the day of the birth event, does not match the birth_date of the new dependent

You can prevent this by:

  • adjusting the event value

    • send newly_eligible or other

  • adjusting the date value

    • send the correct event date

  • adjusting the birth_date value

    • send the correct birth_date

For births, the coverage start_date for newly added dependents must be within 31 days of their birth date

This validation occurs when:

  • the event value is birth

  • and the coverages start_date value in the QLE - for the new dependent - is greater than 31 days from their birth_date.

You can prevent this by:

  • adjusting the event value

    • send newly_eligible or other

  • adjusting the date value

    • send the correct event date

  • adjusting the birth_date value

    • send the correct birth_date

PreviousScenario: Coverage Start DateNextDiscrepancy Standard Messages

Last updated

Was this helpful?