Mapping Plans and Account Structures

If you'd like to manage enrollments for a group that's connected to Noyo, you'll need to map your plans and account structures to the ones Noyo found at the carrier so that both systems are speaking the same language. It's common for groups and plans to have different names between your system and the carrier, so this step helps Noyo establish a link.

This process may be familiar from configuring an EDI file, where each member is assigned the right benefit class or division based on the rules for the group and sent with the correct plan identifiers so they will be enrolled in the right coverages.

When you connect a group to Noyo, they will have their own unique account structure and plan options. Small groups will usually have just one account structure option and plan available for all employees, while larger groups could have complicated rules to categorize each employee and determine which plans they can choose.

🚧

Some carriers define a single account structure category (e.g. benefit classes), while others may define several (e.g. benefit classes, benefit subclasses, and bill groups).

Since Noyo doesn’t have access to your view of the group, you will read Noyo’s data and decide how the two systems line up, or if there is a mismatch or missing option that needs to be updated at the carrier. This process is the same across all carriers in the Noyo Network, though the data may take longer to appear in Noyo's system for Send carriers.

Step 1. Get the Group’s Carrier Configurations

Use the group_id to get the account structure details for the group from our Group Carrier Configuration endpoints. This is an example for a group with coverage at Guardian:

curl -X GET  
 --header "Authorization: Bearer \<ACCESS_TOKEN>"  
 <https://fulfillment.noyo.com/api/v1/groups/47c07963-2e34-4da2-86b4-cbc3c57111c1/carrier_configurations>  
Sample response:

\[  
    {  
        "group_id": "47c07963-2e34-4da2-86b4-cbc3c57111c1",  
        "carrier_id": "c699414d-fd1c-4de4-86f0-66dfff2276c4",  
        "carrier_group_id": "00110011",  
        "configuration": {  
            "bill_groups": [  
                {  
                    "bill_group_name": "All Members",  
                    "bill_group_identifier": "0000",  
                    "bill_subgroup_identifier": ""  
                }  
            ],  
            "benefit_classes": [  
                {  
                    "benefit_class_name": "All CA Employees",  
                    "benefit_class_identifier": "0001",  
                    "benefit_subclass_identifier": ""  
                },  
                {  
                    "benefit_class_name": "All Other Employees",  
                    "benefit_class_identifier": "0002",  
                    "benefit_subclass_identifier": ""  
                }  
            ],  
            "master_agreement_number": "00110011"  
        }  
    }  
]

Noyo will return basic details about each account structure category and option, with a free text description from the carrier (“All Members”, “Executives”) and a unique ID that Noyo would send to the carrier when enrolling a member or updating their coverage.

Often for complex or large groups, you will need to classify members (for example, which job title qualifies someone for the “Executives'' subclass or which employees are in the “Sales'' division). It’s very possible you already have some process for the broker or group admin to set up and run these rules in your system. Our team will get into more detail on these scenarios as you start testing more complicated groups.

Step 2. Get the Group’s Plans

Use the group_id to get the list of plans for the group from our Group Plans endpoints:

curl -X GET  
 --header "Authorization: Bearer \<ACCESS_TOKEN>"  
 <https://fulfillment.noyo.com/api/v1/groups/47c07963-2e34-4da2-86b4-cbc3c57111c1/plans>

Sample response:

\[  
    {  
        "id": "4bf04f73-0aad-48ac-b28a-e5f4def7c5e9",  
        "version": "e91b3060-7795-48e3-b0f6-26bd9825593d",  
        "created": 1557329939,  
        "modified": 1557332412,  
        "group_enrollment_id": "caf59ba1-88a3-4db6-9703-fd6562c664a9",  
        "carrier_id": "c699414d-fd1c-4de4-86f0-66dfff2276c4",  
        "line_of_coverage": "dental",  
        "name": "Dental - SmileDirect Plus",  
        "code": "",  
        "effective_start_date": "2020-01-01",  
        "effective_end_date": "9999-12-31",  
        "plan_type": "ppo",  
        "network": "",  
        "voluntary": false,  
        "status": "active",  
        "eligible_member_type": ["all"],  
        "waiting_periods": [  
            {  
                "waiting_period_unit": "day",  
                "waiting_period_amount": 30,  
                "waiting_period_rule": "first_of_month_after_event",  
                "waiting_period_coinciding": true,  
                "waiting_period_enrollment_type": "new_member"  
            },  
            {  
                "waiting_period_rule": "first_of_month_after_event",  
                "waiting_period_coinciding": true,  
                "waiting_period_enrollment_type": "current_member"  
            }  
        ],  
        "termination_policy": "end_of_month",  
        "cobra_rules": {  
            "eligible": true  
        },  
        "plan_configuration": {  
            "benefit_class_identifiers": ["0001", "0002"]  
        }  
    }  
]

Noyo will return basic details and benefit information for each plan, including a unique ID for the plan and its effective start and end dates. You can use the line of coverage (dental/vision), plan name, plan type (HMO or PPO, basic or voluntary) and other fields in the API response to match each plan with the corresponding benefit in your system.

Step 3. Create a link between records

You’ll need to define a process to review the data between our two systems, make any matching decisions and store the correct IDs on your side. This might involve writing an algorithm to link records automatically or creating a page in your internal tools to view and edit stored identifiers. It might also involve creating a new column in your database to store these identifiers, or tagging records with a custom field. This process is needed when the initial group connection finishes, or any time the group enters their renewal window and makes a change to their account structure or decides to add or remove a plan.