Support is limited to groups using UHG’s USP backend system. Groups with life, AD&D, and/or disability coverage are not eligible to be managed through Noyo.

StatusLive
APISnapshot
COBRANot supported
GeographiesAll
Group SizeAll
LinesDental, medical, vision
NameUnitedHealthcare
NetworkSync
New Group Connection TimeNot yet available
Noyo ID701ac9cf-56af-4cae-8549-5acfa851e173

Group connections

Create a group connection request to manage groups through the Noyo platform.

In the group_data object for the create endpoint, use the UHC group number as the carrier_group_id. The expected format is a 7-character alphanumeric string, e.g. “09Z6132”.

Sandbox testing

Test group connections with these IDs will asynchronously update with the corresponding status within 10 seconds of submission.

Test ID PatternResulting Status
989898noyo_review
767676waiting_on_carrier
545454action_required
323232unable_to_connect
212121carrier_authorization

Tracking group connection status

Group connection statuses are different for UHC. Because of how the group authorization process works (for more on this, see “Connection Basics” below), only the following statuses will be possible for group connections:

  • created: Each group connection will pass almost immediately through this status as we check for any preexisting authorization for the group.
  • carrier_authorization: We have received the group connection request and are waiting for an authorization notification from UHC.
  • completed: We have received the authorization notification and successfully created the group in our system. When that process is complete, the group connection moves to completed.
  • noyo_review: The group has been authorized and Noyo is actively resolving an issue with the group connection; no action is needed from you.

Carrier configurations

Dynamic config is recommended for all new Noyo integrations and makes carrier-specific config values no longer required.

Dynamic config is recommended for all new Noyo integrations and makes carrier-specific config values no longer required.

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.

UHC’s configuration includes details of available bill groups and populations, which are subdivisions of groups that are sometimes required as part of change requests (see the Member Configuration section).

Most other information in the group configuration isn’t required as part of any payloads to Noyo, but may be helpful for your own business purposes.

{
   "group_id":"de7e3009-836e-4a05-b91b-6efd21b21570",
   "carrier_id":"ff0b7d90-bc05-4ac6-bafc-edb512df67b7",
   "carrier_group_id":"1245346",
   "configuration":{
{

   "group_number": "1245346",
   "source_system_code": "USP",
   "customer_type_description": "schools and educational services, not elsewhere classified",
   "market_segment_code": "01",
   "market_segment_description": "Small Group",
   "erisa_indicator": true,
   "small_business_indicator": true,
   "max_enroll_spouse_limit": 1,
   "contract_identifier": "330303",
   "contract_description": "FauxYo, Inc.",
   "contract_effective_start_date": "2023-01-01",
   "contract_termination_date": "2023-12-31",
   "bill_groups": [
       {
           "bill_group_id": "14776117",
           "bill_group_description": "HSA SINGLE - LOW PLAN",
           "bill_group_details": [
               {
                   "detail_id": "14735505",
                   "effective_date": "2023-01-01",
                   "expiration_date": "2023-12-31",
                   "plan_bill_option": "listBill",
                   "contract_option_types": [
                       {
                           "contract_option_type": "Medical",
                           "product_type": "Coverage"
                       }
                   ]
               }
           ],
           "bill_group_reference_id": "299474",
           "effective_date": "2023-01-01",
           "expiration_date": "2023-12-31"
       }
   ],
   "populations": [
       {
           "population_id": "9444859",
           "external_population_id": "DOCTORS",
           "population_name": "DOCTORS",
           "effective_date": "2023-01-01",
           "expiration_date": "9999-12-31",
           "member_group_population_types": [
               {
                   "population_type": "COVERAGE"
               }
           ]
       }
   ],
}
}

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.

Most other information in the group configuration isn’t required as part of any payloads to Noyo, but may be helpful for your own business purposes.

{
    "contract_option_identifier": "96571819",
    "contract_option_description": "Calendar Option - Dental",
    "contract_option_cancellation_reason_description": "Other",
    "contract_option_status": "Active",
    "contract_option_renewal_contract_length": "12 Months",
    "contract_option_requires_active_reenrollment": false,
    "next_renewal_date": "2024-10-01",
    "auto_assumed_renewal": false,
    "dependent_only": false,
    "plan_year_month": "01",
    "run_out_date": null,
    "split_family_elections": false,
    "situs_state": "CT",
    "rating_zip_code": "06880",
    "populations": [
        {
            "population_id": "9444859",
            "insuring_rule": {
                "eoi_details": [],
                "child_max_age_limit": "26",
                "child_over_age_drop_rule": "Last_Day_of_Plan_Year",
                "student_max_age_limit": "26",
                "maximum_children_rated": null,
                "age_child_rates_as_individual": null,
                "waiting_period_duration": "0",
                "waiting_period_type": "Days",
                "entry_date_rule": "Date_of_Event",
                "termination_rule": "Date_of_Event",
                "rehire_period": null
            }
        }
    ],
    "insuring_rule": {
        "eoi_details": [],
        "child_max_age_limit": "26",
        "child_over_age_drop_rule": "Last_Day_of_Plan_Year",
        "student_max_age_limit": "26",
        "maximum_children_rated": null,
        "age_child_rates_as_individual": null,
        "waiting_period_duration": "0",
        "waiting_period_type": "Days",
        "entry_date_rule": "Date_of_Event",
        "termination_rule": "Date_of_Event",
        "rehire_period": null
    },
    "enrollment_plan_id": "10303561",
    "coverage_type_description": "P7977",
    "coc_year": null,
    "plan_code": "P7977",
    "benefit_plan_id": "P7977",
    "rx_plan_code": null,
    "pcp_required": false,
    "hsa_compatible": null,
    "plan_type_code": "PPO",
    "tied_plan_code": null,
    "product_brand": "UHC",
    "employer_contribution_period": "Monthly",
    "employer_contribution_for_subscriber": "75.00",
    "employer_contribution_for_dependent": "0.00",
    "contribution_type": "Percentage",
    "funding_arrangement_code": "01",
    "funding_arrangement_definition": "FullyInsured",
    "revenue_arrangement_code": "01",
    "revenue_arrangement_definition": "FullyInsured",
    "benefit_options": null,
    "plan_rates": {
        "rates": [
            {
                "billing_calc_method": "FamilyUnit-Based",
                "unit_schedule_id": "4T_SUB_CPLE_PRNT-CHILDRN_FAM",
                "plan_tier_band_type": "EMPLOYEE-SPOUSE",
                "plan_tier_band_from_age": "",
                "plan_tier_band_to_age": "",
                "plan_tier_band_ovrd_rate_amount": "109.8"
            }
        ],
        "billing_assign_use_type": "Non-COBRA",
        "bill_item_type": "PREMIUM"
    },
    "provider_details": [
        {
            "provider_url": "https://a.provider.example.url.com",
            "url_type": "Options PPO 30"
        }
    ],
    "policy_id": null
}

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.

Each member can be associated with UHC-defined populations and bill groups, which can be sent as part of the member configuration in a snapshot. For groups which offer more than one population or bill group option, include the desired values in the carrier configuration of each request as shown.

{
    "population_id": "9444859",
    "bill_group_id": "14776117"
}

In simple cases where it’s possible for Noyo to infer the correct population or bill group for a request, it’s not required to include them. This is true only when a single population or bill group is available for a given enrollment. Otherwise, requests without a required population or bill group will be rejected. For simplicity and to prevent any unexpectedly rejected requests, Noyo recommends that these values are included at all times.


Connection Basics

UHC backend systems

Noyo can support groups using UHG’s USP backend systems. Most small groups with medical, dental, and/or vision coverage use this system. Brokers can identify the backend system for each group via UHC’s online security marketplace portal. There is no universal rule for which groups are administered with which system, but the currently supported system administers most small groups and many larger groups.

UHC has other backend systems which will be supported by Noyo in later 2024/early 2025. Contact your Noyo Customer Experience Manager for the latest timelines.

Getting groups connected

Group authorization

There are no differences in the Noyo group connection flow for UHC compared to other carriers, but before a group can be successfully connected to Noyo its broker must also authorize the connection using the UnitedHealthcare API Connect Marketplace. Brokers must use the API Connect Marketplace to select groups for connection and send authorization forms to group administrators. When the administrator signs the electronic authorization form, brokers are allowed to “connect” the group.

Brokers may not be familiar with the UHC marketplace, so Noyo can help you design the appropriate training and workflows for your system. UHC also provides two PDF guides to help with broker training, which you can download from the Documentation sidebar at left:

  • User flow for the API Connect Marketplace
  • Guide for creating a OneHealthcare ID

We recommend including the link to the API Connect Marketplace (https://acm-marketplace.optum.com) in your platform’s existing broker flow for connecting groups to Noyo. Best practice is for the broker to trigger a group connection request to Noyo and then be directed to the marketplace.

The marketplace URL should also be available to brokers after the group is connected, in case they need to manage the authorization. Once logged in to the UHC portal, a broker can manage any group they administer.

When the broker has completed authorization for a group, Noyo automatically receives authentication details from UHC that enable us to instantly complete any open connection request. We recommend sending Noyo a group connection request at the same time as the broker requests authorization for a group, since this allows Noyo to track upcoming connections. Any requests sent to Noyo after we’ve received the authorization from UHC will still complete successfully.

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 UHC’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.

Any issues that are surfaced during one of the round trip confirmation checks will appear in the Discrepancy Triage tool in the Command Center. You can always get the current status of a given transaction with the Transaction Status Detail endpoint, or you can get granular detail on what’s in-flight with our Tracking API.

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

  • SSN Changes Adding, removing, or adjusting a member’s social security number.

Unsupported changes

Some types of changes cannot be handled through the Noyo API and must be communicated directly to UHC.

  • Changes which break retro rules Changes that are too far backdated (generally >60 days) will not be processed by UHC. These must be submitted directly through the UHC portal by the group’s administrator. (Note that only the backdated portion of a request won’t be honored. So, if a demographic change and a rulebreaking start date change are submitted at the same time, the demographic change will still be processed.)

Was this page helpful?