Many carriers have special handling for COBRA enrollments or modifications, and it’s important that requests to Noyo are properly flagged as relating to COBRA members. It's best practice to provide all COBRA details whenever a request includes a member enrolled in COBRA.
Not all carriers are able to support COBRA enrollments via Noyo.
Before sending COBRA enrollments, check the carrier-specific documentation in the Command Center. Individual carriers may also have more detailed requirements for COBRA requests.
Each member snapshot should contain a
cobra_details block, as shown below. Full details for COBRA submissions can be found in the Member Snapshot API Reference.
To ensure a carrier is able to process your COBRA requests correctly, all COBRA enrollments must be sent with the
= true and a
cobra_eligibility_start_datefield should be the first day without regular coverage, as COBRA coverage must be continuous with regular coverage. For example, if a member’s regular coverage ends 11/30, the COBRA coverage would start on 12/1.
enrolled_member.effective_start_datefield should reflect the original start date of the member’s coverage unless otherwise indicated by carrier requirements.
enrolled_member.effective_end_datefield should be empty if a termination was previously sent, but a previous termination is not required.
enrolled_member.effective_end_datefield should reflect the COBRA end date.
cobra_eligibility_end_dateis optional, and may reflect the final day of the member’s maximum COBRA-eligible period (usually 18 months) or be updated to reflect an earlier date if the member ends COBRA coverage earlier.
- Some carriers may require the COBRA QLE date. Unless otherwise indicated by carrier requirements, this will be the date that the member experienced their COBRA-qualifying event, which may fall prior to their last day of active coverage as an employee. For example, a member may experience a COBRA-qualifying event the day they end their employment or move from full-time to part-time, but their coverage as an active employee may remain through the end of the month.
- Members cannot be simultaneously enrolled in COBRA and non-COBRA for the same coverage. Member snapshots that attempt to add overlapping coverage for a member will be rejected.
- In the case that not all family members are enrolled in COBRA but all changes are being communicated within the same member snapshot, active (non-COBRA) coverage and COBRA coverage should be sent as two separate coverage blocks.
Many carriers have special handling for cases where members were removed from coverage and then re-added. This can happen after a mistake is corrected, a member is rehired, or a formerly active member opts back into coverage via open enrollment or qualifying life event.
To be sure that all carriers have enough information to process rehires/reinstatements accurately, requests must follow these guidelines:
- For all reinstated and rehired members, coverages in the snapshot should include the new effective start date of their most recent coverages, and not the start date of any previously terminated coverages. This applies even if the members are intended to be enrolled without any gap between old coverage and new, and even if the new coverage is meant to correct a mistaken termination. For example, a member whose coverage was mistakenly terminated as of June 30th must have the reinstated coverage sent beginning July 1. Sending an earlier start date may cause requests to be rejected by the carrier.
- For rehired members only, the first request meant to re-enroll the member must include an event reason of rehire. The event date must also be equal to the member’s rehire date. For that first request and all future requests, rehired members must always have both a
hire_dateshould reflect the member’s original hire date, while the
rehire_dateshould reflect their new, most recent hire date.
Primary Care Provider (PCP) information is often required by carriers for enrollment in medical and dental HMO plans. These plans route all care through a single primary care provider, and carriers sometimes require details of that provider before they will issue coverage.
Please note that some carriers do not accept changes to PCP data sent by the employer group following initial enrollment, and instead require all PCP changes to be submitted by the member directly. In these cases, you can still send PCP information to Noyo but the data will not be updated in the carrier’s system.
If you are managing groups with HMO plans through Noyo, be sure to check carrier-specific documentation in the Command Center for additional requirements around PCP information. In general, it’s a best practice to provide PCP information for members enrolled in these plans whenever it’s available.
When needed, PCP data can be sent in the
primary_care_providers block as shown below. See the full details of PCP data payloads in the Member Snapshot API Reference.
Updated 29 days ago