# Add a New Subscriber and Domestic Partner ## Checklist * [ ] Determine Event in Platform System * [ ] Map Elections * [ ] Send Subscriber Demographics * [ ] Store Member Id(s) and Check Status * [ ] Send QLE Request(s) * [ ] Store QLE Id(s) and Check Status * [ ] Carrier Transmission * [ ] Error Reporting {% hint style="info" %} This is a variant of [Add a New Subscriber and Family](https://ideonapi.gitbook.io/enrollment/implementation-resources/scenarios/add-a-new-subscriber-and-family). The distinguishing factor is creating a Dependent with the `"subscriber_relationship"` value of `"registered_domestic_partner"`. {% endhint %} ## Components 1. [Determine Event in Platform System](#determine-event-in-platform-system) 2. [Map Elections](#map-elections) 3. [Send Subscriber Demographics](#send-subscriber-demographics) * [Store Member Id(s) and Check Status](#store-member-id-s-and-check-status) 4. [Send QLE Request(s)](#send-qualifying-life-event-request-s) * [Store QLE Id(s) and Check Status ](#store-qle-id-s-and-check-status) 5. [Carrier Transmission](#carrier-transmission) 6. [Error Reporting](#error-reporting) ### Determine Event in Platform System #### Description In the Platform system, a user or process has identified a New Hire or a member newly electing benefits as they are now eligible. This includes a dependent. #### Example 1 * A member is hired and that member elects benefits, starting the first of the next month. * A request is created for the member and for each set of coverages with a Carrier * These requests are sent to Ideon in real-time. #### Example 2 * A member is hired, and that member is not eligible for any benefits. * The nature of that employee's work changes, and they are now eligible for several benefits * A request is created for the member and for each set of coverages with a Carrier * These requests are sent to Ideon in real-time. ### Map Elections #### Description Given an employee and their registered domestic partner, If that member selects benefits for one or more carriers, which have a `coverage_period` with Ideon 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 plan id to represent the elected plan option in your system Example 1 - One Carrier: * `Basic Life and AD&D`, `Short Term Disability` , and `Long Term Disability` with `guardian` * This will be represented with **one** POST request to `subscriber/{{id}}/qualifying_life_events` , using a subscriber `id` , and including three product lines under a single Coverage Period [Request](#request) Example 2 - Multiple Carriers: * `Medical` with `kaiser` * `Dental` and `Vision` on `cigna` * `Accident`, `Critical Illness` and `Hospital Indemnity` with `voya` * This will be represented with **three** POST requests to `subscriber/{{id}}/qualifying_life_events` , all using that same subscriber `id` but for different Coverage Periods and product lines in the request body Requests {% hint style="info" %} Mapping these options can be tricky depending on **How** your system represents Plan Options to it's users. If your system splits-out a given "plan option" with the carrier by Covered Member Type, Coverage Tier, Classification, etc. you might have **many** Plan Options created in your system. To reduce set-up time and the complexity of the configuration, we prefer these to be mapped "down" to base plan options in the Ideon system. However, we can accommodate these split plan options in set-up if needed. {% endhint %} ### Send Subscriber Demographics #### Description Given a newly hired or eligible member that does not exist in Ideon's system for this Group, we would expect a POST request to create a new subscriber. Class, Subgroup, and Dependents might not be present on the subscriber you are creating. In the example below, a Subscriber is created with Three Child Dependents, and includes a Class assignment, and subgroup assignment. Request: ```json Create Subscriber { "subscriber": { "external_identifier": "Subscriber1", "location_id": "{{primary_location_id}}", "first_name": "Jason", "last_name": "Ideonu", "birth_date": "1990-05-30", "gender": "male", "social_security_number": "{{ssn}}", "employment_details": { "start_date": "{{first_of_current_month}}", "status": "full_time", "annual_earnings": 10000000, "earnings_effective_date": "{{first_of_current_month}}", "wage_frequency": "weekly", "compensation": "salary", "hours_per_week": 40 }, "class": { "employment_classification_id": "{{class_1_id}}", "effective_date": "{{first_of_current_month}}" }, "subgroup": { "employment_classification_id": "{{subgroup_1_id}}", "effective_date": "{{first_of_current_month}}" }, "dependents": [ { "external_identifier": "partner_sub_1", "first_name": "Brian", "last_name": "Partnero", "birth_date": "1991-01-10", "gender": "male", "subscriber_relationship": "registered_domestic_partner" } ], "residential_address": { "address_line_1": "34 B Street", "city": "Winchester", "state": "VA", "zip": "22603" }, "mailing_address": { "address_line_1": "34 B Street", "city": "Winchester", "state": "VA", "zip": "22603" }, "phone_numbers":[{ "type": "work", "contact": "7777777777" }, { "type": "home", "contact": "7777777777" }, { "type": "fax", "contact": "7777777777" }], "emails":[{ "type": "work", "contact": "be_square@gmail.com" }] } } ``` #### Store Member Id(s) and Check Status In order to refer to this subscriber and dependents later, and send coverages, your system should save the successful response body and store the `id` associated with each subscriber and each dependent. 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 ### Send Qualifying Life Event Request(s) #### Description In this example. the member is electing Basic Life /AD\&D and Disability coverages. If you don't have the current member data and id for the subscriber, 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 * `voluntary_life_accidental_death_dismemberment` - this refers to the `id` of the created plan, in this case a Voluntary Life Add Plan that is offered to ALL family members. * `basic_life_add_plan_id` - this refers to the `id` of the created plan, in this case a Basic Life Add Plan * `std_plan_id` - this refers to the `id` of the created plan, in this case a Short Term Disability Plan * `ltd_plan_id` - this refers to the `id` of the created plan, in this case a Long Term Disability Plan * `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` #### Request ```json POST subscribers/{{subscriber_id}}/qualifying_life_events { "qualifying_life_event": { "event": "new_hire", "date": "{{today}}", "eligibility_start_date": "{{first_of_current_month}}", "coverage_period_id": "{{coverage_period_id}}", "plan_elections": { "voluntary_life_accidental_death_dismemberment": { "plan_id": "{{voluntary_life_add_plan_id}}", "type": "election", "coverages": [ { "member_id": "{{subscriber_id}}", "status": "employer_sponsored", "start_date": "{{first_of_current_month}}", "volume": 10000000 }, { "member_id": "{{partner_1_id}}", "status": "employer_sponsored", "start_date": "{{first_of_current_month}}", "volume": 2000000 } ] }, "life_accidental_death_dismemberment": { "plan_id": "{{basic_life_add_plan_id}}", "type": "election", "coverages": [ { "member_id": "{{subscriber_id}}", "status": "employer_sponsored", "start_date": "{{first_of_current_month}}", "volume": 10000000 } ] }, "short_term_disability": { "plan_id": "{{std_plan_id}}", "type": "election", "coverages": [ { "member_id": "{{subscriber_id}}", "status": "employer_sponsored", "start_date": "{{first_of_current_month}}", "volume": 34500 } ] }, "long_term_disability": { "plan_id": "{{ltd_plan_id}}", "type": "election", "coverages": [ { "member_id": "{{subscriber_1_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 ### Carrier Transmission #### Description * When Ideon receives this Subscriber and Partner coverage, we identify whether the member was previously enrolled by our system. * In Test: Transmit the member to Ideon as well as in your current administration method. This is to ensure that both systems know the member's status and won't delay an enrollment for the member. * In Production: Transmit the member to Ideon. We will: * send an API request to enroll or rehire the member * Store the members coverages but not re-enroll * send the member on the next File Delivery to the Carrier (within 7 business days) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ideonapi.gitbook.io/enrollment/implementation-resources/scenarios/add-a-new-subscriber-and-domestic-partner.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.