​

Group connections

Create a group connection request to manage Guardian groups through Noyo.

In the group_data object for the create endpoint, use Guardian’s group policy ID for the carrier_group_id. The format expected is an 8-digit string.

​

Sandbox testing

You may use the following special Guardian group number carrier_group_ids in order to simulate different group connection statuses. If you use a group number listed below, the group connection will asynchronously update with the corresponding status within 10 seconds of submission. Only these three characters are evaluated to figure out the target status (e.g. 989 means noyo_review). Since group connections should be unique by a carrier ID and carrier group ID combination, you may use the final characters to iterate and test this interaction further.

​

Carrier configurations

Group, plan, and member configurations are where Noyo shares and receives details that are unique to a carrier. Every other part of Noyo’s payloads are standardized, but the configurations hold the unique fields and classifications that change from connection to connection. As part of preparing to connect to a new carrier, you need to understand the contents of each configuration and be sure your system is able to send the required data for each member.

​

Get the group configuration from Noyo

The group carrier configuration endpoint returns information about how the group is labeled and categorized within the carrier’s system. You can also see this data in the Command Center on a group’s detail page by clicking one of their carrier connections.

Groups that have Guardian coverage will be configured with a master_agreement_number string, which is the primary group identifier with Guardian, along with a list of one or more bill_groups and one or more benefit_classes to categorize employees enrolling in coverage.

{
    "group_id": "da8d32cc-ce9d-4cf3-9360-733ee0023f1f",
    "carrier_id": "c699414d-fd1c-4de4-86f0-66dfff2276c4",
    "configuration": {
        "benefit_classes": [
            {
                "benefit_subclass_identifier": "",
                "benefit_class_identifier": "0001",
                "benefit_class_name": "ALL ELIGIBLE EMPLOYEES"
            }
        ],
        "master_agreement_number": "00112233",
        "bill_groups": [
            {
                "bill_subgroup_identifier": "",
                "bill_group_identifier": "0000",
                "bill_group_name": "MyGroup"
            }
        ]
    }
}

​

Get the plan configuration from Noyo

The details in the plan configuration should be used to map each Noyo plan to the corresponding plan in your own system. Importantly, each plan configuration has details about which populations are connected to an individual plan. Groups with multiple populations may link a plan with one or more of them.

Some Guardian plans are only available for employees in certain benefit classes. Guardian plans will include a plan_configuration block with a benefit_class_identifiers field containing a list of string identifiers. The benefit class identifiers will match the benefit classes in the Group Carrier Configuration explained in the section above, and describe which benefit classes are eligible to enroll in the plan.

​

Send the member configuration to Noyo

Each member snapshot sent to Noyo can contain a configuration section. Depending on each carrier’s requirements, you may need to use this section to include carrier-specific identifiers like classes, subdivisions, or bill groups. These go in the coverage block’s carrier_config section and ensure that members are enrolled in the correct coverages. Member snapshots missing a carrier_config section or with incorrect config data will result in a 422 error.

Requests and snapshots to enroll in Guardian coverage may include optional benefit_class_identifier, benefit_subclass_identifier, bill_group_identifier, bill_subgroup_identifier matching the corresponding values in the group carrier configuration, respectively. If the caller omits either of these values, Noyo will attempt to resolve the correct bill group and benefit class in cases where only one option is available for the employee.

Work_location_text is an optional field used to specify additional group configuration details for certain large and complex groups. Most partners will not need to send work_location_text in any circumstance. Guardian will only store the first 8 characters of any input.

{
    "benefit_class_identifier": "0001",
    "benefit_subclass_identifier": "0001-01",
    "bill_group_identifier": "0000",
    "bill_subgroup_identifier": "0000",
    "work_location_text": "ABCD1234"
}

​

Carrier-specific requirements

​

Required fields

• Guardian stores up to 30 characters of the first, middle, and last name combination for each member
• An SSN is required for all employees, while dependent SSNs are optional.
• Address line 1 must be present (snapshots with a blank or null value will fail)
• State and ZIP code must match
• Enrollments in life, AD&D, disability, or critical illness coverage must contain volume amounts.

​

Validations

Noyo will validate the following based on the carrier_config:

• The bill group and subgroup specified are valid for the group
• The benefit class and subclass specified are valid for the group
• The provided benefit class identifiers are valid for the plans specified in the relevant coverages

​

Benefit class changes

By default, Guardian applies any requested benefit class changes as of the date the request is received. If partners wish to change benefit classes as of any other date, send a snapshot with event type = benefit_class_change and an event date matching the desired effective date in the new benefit class.

Note that Guardian only allows a family to have one benefit class at a time. Any snapshots that include more than one benefit class for the same time period will be rejected.

​

Coverage start dates

To move the start date of any coverage later in time, you must first cancel the member’s previous coverage and then send a new coverage with a new start date. Sending the same coverage as before with a later start date will not result in a coverage date change.

Moving any coverage start date earlier in time does not have the same requirements, and can be done simply by sending the earlier date.

​

COBRA

Guardian supports COBRA enrollment changes through Noyo in some scenarios; contact your customer experience manager to learn more. To send COBRA requests, follow the generic guidelines in our documentation.

​

Connection Basics

​

Getting groups connected

To get a new or existing group connected to Noyo, simply request a group connection by sending the group name and policy ID as defined in the Technical Spec.

As with all other Sync carriers, we process a group connection by pulling all plan, member, and group structure data from Guardian to populate our system.

If at any point we encounter an issue connecting the group, Noyo will work with Guardian to resolve the issue. We may contact you if your input is needed.

​

Groups are considered fully connected when:

• Noyo returns the connection status as “completed.”
• You’ve linked Noyo’s IDs for account structure information, plans, members, and coverages to your own, and established an account structure mapping process.
• You’ve deactivated previous forms of data exchange and are ready to send all enrollment changes through Noyo.

​

Processing member changes

Each member snapshot is broken into one or more individual “transactions.” Our integrations with API-enabled Sync carriers generally result in 90% of member transactions arriving at the carrier within 10 minutes of being sent to Noyo, and 95% of transactions being confirmed by Noyo within 4 business days of original receipt.

​

Round-trip confirmation

As with other Sync carriers, Noyo is able to read data directly from Guardian’s system. Noyo monitors each transaction with round-trip confirmation, which triggers a check in the carrier’s system after the change is sent and again on the change’s effective date to ensure that enrollments go through as expected.

Use the Tracking API to see the results of round-trip confirmation and get a granular view of how each change is being processed.

​

Managed changes

Our goal is to confirm all member changes within 4 business days. However, some transactions cannot be confirmed automatically after being submitted through our API because special handling is required. We call these “managed” transactions and they may have longer confirmation timelines.

Types of managed changes:

• Date of hire changes Adjusting the date of hire after it has been set.
• Late entrant enrollments Adding an EOI-applicable benefit more than 31 days after the waiting period.
• EOI suppression Any change for a group coded “EOI Suppression,” where all EOI is manually reviewed before a notice is generated. This is most common for groups with more than 1,000 members.
• Waiving non-contributory benefits Changes that represent a waiver of mandatory non-contributory benefits (employer-paid benefits are auto-enrolled).
• Coverage volume mismatch Any member snapshot containing two different coverage volumes for linked voluntary life and AD&D plans.
• Texas MDG(HMO) Changing to or from Texas MDG(HMO) plans.
• Redetermination Changes related to redetermined coverage for groups with multiple redetermination dates. (For example, a group can have STD with immediate redetermination of volume, but LTD with annual redetermination.)
• Similar dependents Enrollment of multiple dependents with the same first name and relationship.

​

Retroactive changes

Snapshots requesting an effective date greater than 90 days (3 months) before the date Guardian receives the change are manually reviewed by the Guardian team and may be rejected. If they are accepted, they will be processed according to these rules:

• Employer-paid coverages will be enrolled up to 180 days retroactively
• Employee-paid coverages will be enrolled up to 90 days retroactively
• All terminations will be dated up to 90 days retroactively

​

Other scenarios

• When one dependent-child is covered by voluntary life and/or AD&D coverage, Guardian automatically enrolls all other dependent-child(ren) in the same coverages.
• When a member enrolls their dependent-child(ren) in any coverage, they are assumed to be covered until age 26, per ACA guidelines. However, Guardian requires members to submit a form that verifies a dependent-child is a full-time student at age 20 for their coverage to continue until age 26. Depending on the status of this form, Guardian may return different end dates for dependent coverage.
• EOI may be required for Voluntary Life/ADD coverages, Voluntary LTD/STD, LTD/STD, and Critical Illness coverage.

​

Open enrollment

You can send the group’s plan-level renewal decisions to Noyo once they’ve been officially communicated to Guardian. Noyo will check Guardian’s system daily until the new plans are available to ensure that they are installed correctly.

When the plans in Guardian’s system match the expectations you submitted, the renewal decision status will move to “ready” and you will be able to send member snapshots with each member’s open enrollment elections for the new plan year.

There are no blackout periods with Guardian, so you can also send current year changes at any point during open enrollment.