# API Validations

### Table

<table><thead><tr><th width="267.38226318359375">Message Text</th><th width="428.934814453125">How to resolve</th></tr></thead><tbody><tr><td>The plan id '{plan_id}' does not belong to coverage period '{coverage_period_id}'</td><td><p>The plan ids in the QLE don't align with coverage period, or the product lines that they have. </p><p></p><p><mark style="color:purple;">Example 1</mark> : </p><ul><li>Creating a QLE for coverage period id 456, the body of the request has plan_id 22.</li><li>plan_id 22 was created under coverage period 123 and not 456. </li></ul><p><mark style="color:green;">How to resolve</mark>:  </p><ul><li>update either the <code>plan_id</code> value or the <code>coverage_period_id</code> to preform the intended action</li></ul></td></tr><tr><td>must have {product_line} plan for {product_line} election but got {plan_product_line} plan {plan_id}</td><td><p></p><p>The product_line that is associated with the plan id in the QLE doesn't align with the product_line on the created plan.</p><p></p><p><mark style="color:purple;">Example 1</mark> : </p><ul><li>Creating a QLE with plan elections for plan_id 22 - using the value <code>voluntary_life</code> </li><li>plan_id 22 was created as a <code>dental</code> plan</li></ul><p></p><p></p><p><mark style="color:green;">How to resolve</mark>:  </p><ul><li><p>update either:</p><ul><li>the <code>plan_id</code> value</li><li>the <code>product_line</code> </li></ul></li><li>or create a new plan with the expected <code>product_line</code> + <code>product_type</code> values</li></ul><p></p><p>A full mapping guide of plan product lines and election product lines can be found <a href="mapping-guides/qualifying-life-events/product-line-product-type-mapping">here</a>.</p></td></tr><tr><td>all members must be related to the subscriber, {member_ids} are related to a different subscriber</td><td>One or more of the dependent member ids used in the QLE is not related to the subscriber id used.</td></tr><tr><td>all members must exist, the following do not refer to existing members: {member_ids}</td><td><p>One or more of the dependent member ids used doesn't yet exist. </p><p></p><p>It may also be another system uuid or internal id.</p></td></tr><tr><td>all members must be specified once for {product_line}; duplicate(s) {member_ids}</td><td><p>One or more of the products in the plan_elections has a duplicated member id. </p><p></p><p><mark style="color:purple;">Example 1</mark> : </p><ul><li><p>Creating a QLE with plan elections for <code>long_term_disability</code> , listing member ids:</p><ul><li>subscriber 23</li><li>dependent 11</li><li>dependent 12</li><li>dependent 11</li></ul></li><li><p>in this case we would raise an error </p><ul><li>all members must be specified once for <code>long_term_disability</code>; duplicate(s) dependent 11</li></ul></li></ul><p><mark style="color:green;">To resolve this</mark>, only list a single election for the given member, under that product line</p></td></tr><tr><td>missing {pluralized_plan_elections} for {missing_product_lines}</td><td><p>This validation occurs when:</p><ul><li>you attempt to create a QLE</li><li>the previous QLE contained a product line </li><li>that product line is no longer present in the new QLE</li></ul><p></p><p>For us to properly communicate changes to a carrier, we can't have elections drop off without "closing the loop". </p><p></p><p>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</p><p> </p><p><mark style="color:green;">You can prevent this by:</mark> </p><ul><li>validating that each product line's election is delivered</li><li>enabling/ensuring that all product lines continue to send <em>alongside new elections, new members, and changes</em> </li></ul></td></tr><tr><td>{product_line} coverages require a coverage for subscriber, member id {member_id}, but only saw coverages for {perceived_member_ids}</td><td><p>This validation occurs when:</p><ul><li>you attempt to create a QLE</li><li>a dependent is electing coverage without a subscriber</li><li><p><em><strong>Exception:</strong></em></p><ul><li><em><strong>event is "cobra", in which a dependent can elect coverage without a subscriber.</strong></em> </li></ul></li><li>A subscriber must be covered under a product line in order for a dependent to elect the product.</li></ul><p></p><p><mark style="color:green;">You can prevent this by:</mark> </p><ul><li><p>validating that each dependent member is</p><ul><li>affiliated with a subscriber</li><li>end-dated or sent as <code>cobra</code> if their employee ends all coverages</li></ul></li></ul></td></tr><tr><td>{product_line} election has end_date {end_date}, which is more than one day before start_date {start_date}</td><td><p>This validation occurs when: </p><ul><li>A coverage ends before its start date</li><li><p><em>Exception:</em> </p><ul><li><p><em>A coverage ends one day before it begins. This is considered a "Term Never Effective" and communicates to us &#x26; the carrier that a coverage was added in error, and should be removed and considered invalid.</em> </p><ul><li><em>See:</em> <a href="scenarios/termination-never-effective"><em>Termination Never Effective</em> </a></li></ul></li></ul></li></ul><p></p><p><mark style="color:green;">You can prevent this by:</mark> </p><ul><li>validating this condition and tracking occurrences</li><li><p>prevent invalid QLE creation by validating user inputs or invalid data </p><ul><li>e.g. <code>cannot enter end date before start date</code> </li><li>explicit support for termination never effective scenarios</li></ul></li></ul></td></tr><tr><td>{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}</td><td><p>This validation occurs when: </p><ul><li><p>one or more dependents on the QLE have invalid coverage dates where:</p><ul><li>their coverage must start after or same day as a subscriber </li><li>and must end before a subscriber's coverage </li></ul></li></ul><p></p><p><mark style="color:green;">You can prevent this by:</mark> </p><ul><li>validating user input and calculated end dates</li><li>ensuring the correct and current coverages are being sent, for the correct <code>benefit_status</code></li></ul></td></tr><tr><td>{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}</td><td><p>This is an alternative validation message for a similar condition to above. </p><p>One or more dependents on the QLE have invalid coverage dates where:</p><ul><li>a subscriber is given an end date, but not dependent; </li><li>a dependent has a coverage end date that is after their subscriber's end date</li></ul><p><mark style="color:green;">You can prevent this by</mark></p><ul><li>validating user input and calculated end dates</li><li>ensuring the correct and current coverages are being sent, for the correct <code>benefit_status</code></li></ul></td></tr><tr><td>{product_line} coverages for plan {plan_uuid} require a volume</td><td><p>This validation occurs when: </p><ul><li><p> the plan elections product lines are one of:</p><ul><li>voluntary_life</li><li>voluntary_accidental_death_dismemberment</li><li>voluntary_life_accidental_death_dismemberment</li><li>critical_illness</li></ul></li><li>the created plan, refered to in the <code>plan_id</code> is <code>voluntary</code> =<code>true</code></li><li><em>You might also receive "invalid valid for ____"-style errors for this condition</em></li></ul><p><mark style="color:green;">You can prevent this by:</mark> </p><ul><li>ensuring that user's provide a value or your system selects one for <code>volume</code></li><li>monitor and restrict changes to the <code>voluntary</code> value on plans - <em><strong>this value cannot be updated without recreating a plan, fetching the new plan_id, and creating new QLEs with the correct plan_id</strong></em> </li></ul></td></tr><tr><td>{product_line} coverage was previously end dated and cannot be waived</td><td><p>This validation occurs when: </p><ul><li> sending election type of <code>waiver</code></li><li> but the previous coverages have been end dated</li><li><strong>A coverage cannot be dropped off, or replaced with a waiver, even if they have been end dated</strong>.</li></ul><p></p><p><mark style="color:green;">You can prevent this by</mark>:  </p><ul><li>adjusting your system to monitor and "close" end dated coverages, in some way restricting waivers from being sent to these coverages</li></ul></td></tr><tr><td>The qualifying life event date for new hires must be the employment start date</td><td><p>This validation occurs when: </p><ul><li>event is <code>new_hire</code></li><li><code>date</code> value does not match the subscriber's <code>employment_details.start_date</code>  value</li></ul><p>For a "new_hire" event, the date of the QLE provided must be the same date given as the subscriber's employment start date</p><p></p><p><mark style="color:green;">You can prevent this by</mark>:  </p><ul><li>adjusting the conditions that create a <code>new_hire</code> event</li><li>adjusting the <code>date</code>provided to be that of the "hiring" event for the member</li><li>adjusting the <code>employment_details.start_date</code> to the correct date for the member</li></ul></td></tr><tr><td>when providing cobra and employer_sponsored coverages one set or both must include end_date </td><td><p>This validation occurs when: </p><ul><li>providing cobra and employer sponsored coverages on the same QLE</li><li>and both set of coverages are active/ non-end dated</li></ul><p><mark style="color:purple;">If a QLE provides <code>cobra</code> and <code>employer_sponsored</code> coverages, one or both must be end dated</mark></p><p></p><p><mark style="color:green;">You can prevent this by</mark>:  </p><ul><li>tracking the delivery of <code>cobra</code> and <code>employer_sponsored</code> coverage</li><li>excluding active <code>cobra</code> coverage until the delivery/creation of the <code>employer_sponsored</code> coverage end dates </li><li>excluding rehired <code>employer_sponsored</code> coverage until the delivery/creation of the <code>cobra</code> coverage end dates</li></ul></td></tr><tr><td>QLE invalid - Coverage Period in "Expired" state</td><td><p>This validation occurs when: </p><ul><li>you attempt to create a QLE</li><li>coverage period is in state <code>expired</code></li></ul><p><mark style="color:purple;">We only accept updates to coverage periods that are - or will be - transmitted to the carrier</mark></p><p></p><p><mark style="color:green;">You can prevent this by</mark>:  </p><ul><li>fetch the most current state for a coverage period before you attempt QLE creation </li><li>enforcing that users and system pipelines only create QLEs for non-expired states</li></ul></td></tr><tr><td>You may not modify this QLE because it has been superseded by the following QLE(s): {uuids}</td><td><p>This validation occurs when: </p><ul><li>a PUT to a QLE is attempted</li><li>the QLE in a "supereseded" state, i.e. it is old and not-most-current</li></ul><p><mark style="color:green;">You can prevent this by</mark>:  </p><ul><li>enforcing that users and system pipelines only create new QLEs (preferred) </li><li>Or only update <em><strong>current</strong></em> QLEs </li></ul></td></tr><tr><td>plan_id is required for {product_line} coverage for member {member_id}</td><td><p>This validation occurs when: </p><ul><li>a coverage is given, but no plan id is provided that tells us what plan it is for</li></ul><p><mark style="color:green;">You can prevent this by</mark>:  </p><ul><li>adjusting your system to ensure a plan relationship/ assignment before attempting to creating a QLE</li></ul></td></tr><tr><td>All coverages with benefit status {benefit_status} for product line {product_line} must be for the same plan</td><td><p>This validation occurs when:</p><ul><li><p>the plan election is for:</p><ul><li>medical</li><li>dental</li><li>vision </li></ul></li><li><p>All members in the same <code>benefit_status</code> (employer_sponsored, cobra) within that covered family, are not in the same plan, for that product line</p><ul><li>These products require you to assign everyone to the same plan for a given covered family</li></ul></li></ul><p><mark style="color:green;">You can prevent this by</mark>:  </p><ul><li>adjusting system logic to validate created plans and their assignees </li></ul></td></tr><tr><td>plan_id cannot be in both the {product_line} plan election and the {product_line} coverages</td><td><p>This validation occurs if: </p><ul><li> a <code>plan_id</code> exists in two or more plan_election blocks, in the same QLE</li></ul><p><mark style="color:green;">You can prevent this by</mark>:  </p><ul><li><p>enforcing a singular plan to product line relationship</p><ul><li>a member should elect only one option under a given product line</li><li>a given plan option should only exist under 1 product line label</li></ul></li></ul></td></tr><tr><td>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.</td><td><p>If your created <code>plan</code> has a waiting_period specified, it applies to the qualifying life events and elections.</p><p></p><p><mark style="color:green;">To resolve this error, you can</mark>:</p><ul><li>adjust or recreate a new <code>plan</code> to correct the waiting period</li><li>adjust the event <code>date</code> or <code>event</code> type on the QLE, to accurately reflect the event and date</li><li>adjust or correct the plan elections <code>start_date</code></li></ul><p></p><p>For New Hires, this error occurs when the start date specified on the QLE is before the event <code>date</code>+ plan <code>waiting_period</code></p></td></tr><tr><td>For births, the date of the qualifying life event must be the birth date of the newly added dependent(s)</td><td><p>This validation occurs when: </p><ul><li> the <code>event</code> value is birth </li><li>and the <code>date</code> value in the QLE which denotes the day of the birth event, does not match the <code>birth_date</code> of the new dependent</li></ul><p><mark style="color:green;">You can prevent this by</mark>:  </p><ul><li><p>adjusting the <code>event</code> value</p><ul><li>send <code>newly_eligible</code> or other</li></ul></li><li><p>adjusting the <code>date</code> value</p><ul><li>send the correct event date</li></ul></li><li><p>adjusting the <code>birth_date</code> value</p><ul><li>send the correct <code>birth_date</code></li></ul></li></ul></td></tr><tr><td>For births, the coverage start_date for newly added dependents must be within 31 days of their birth date</td><td><p>This validation occurs when: </p><ul><li> the <code>event</code> value is birth </li><li>and the coverages <code>start_date</code> value in the QLE - for the new dependent - is greater than 31 days from their <code>birth_date</code>. </li></ul><p></p><p><mark style="color:green;">You can prevent this by</mark>:  </p><ul><li><p>adjusting the <code>event</code> value</p><ul><li>send <code>newly_eligible</code>  or other</li></ul></li><li><p>adjusting the <code>date</code> value</p><ul><li>send the correct event date</li></ul></li><li><p>adjusting the <code>birth_date</code> value</p><ul><li>send the correct <code>birth_date</code></li></ul></li></ul></td></tr></tbody></table>
