COBRA

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.

To ensure a carrier is able to process your COBRA requests correctly, requests should obey the following guidelines:

• All COBRA enrollments must be sent with the cobra_enrolled field = true
• Members should not have simultaneously active COBRA and non-COBRA coverage at the same carrier.
• The start date for COBRA coverage should be the first day without non-COBRA coverage. For example, if a member’s regular coverage ends 11/30, the COBRA coverage would start on 12/1.

Not all carrier partners are able to support COBRA enrollments via Noyo, so be sure to check your carrier-specific documentation to be sure a carrier qualifies. Individual carriers may also have more detailed requirements for COBRA requests.

Rehires and Reinstatements

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 effective start date of their most recent coverages, and not the start date of their previous 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_date and a rehire_date. The hire_date should reflect the member’s original hire date, while the rehire_date should reflect their new, most recent hire date.