Special Cases
Some types of changes can require special handling
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 arehire_date
. Thehire_date
should reflect the member’s original hire date, while therehire_date
should reflect their new, most recent hire date.
Updated about 2 months ago