COBRA Enrollments and Terminations

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.

"cobra_details": {
                "cobra_enrolled": True,
                "qualifying_event_reason": "termination_of_employment",
                "qualifying_event_date": "2023-11-15",
                "eligibility_start_date": "2023-12-01",
                "eligibility_end_date": "2025-05-31"
            }

To ensure a carrier is able to process your COBRA requests correctly, all COBRA enrollments must be sent with the cobra_enrolled field = true , an eligibility_start_date, and an eligibility_end_date.

Noyo recommends always including the qualifying_event_reason and qualifying_event_date when available, as some carriers may request it.

When enrolling a member in COBRA coverage:

• The cobra_details.eligibility_start_date field 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.
• The cobra_details.eligibility_end_date should reflect the final day of the member’s maximum COBRA-eligible period (usually 18 months).
• The enrolled_member.effective_start_date field should reflect the start date prior to COBRA coverage unless otherwise indicated by carrier requirements.
• The enrolled_member.effective_end_date field should be sent as datemax (9999-12-31).
• The enrolled_member.latest_change_effective_date field should reflect the member's first day of COBRA coverage.

When terminating a member from COBRA coverage:

• The cobra_details.cobra_enrolled field should remain = true.
• The enrolled_member.effective_end_date field should reflect the last day of the member's COBRA coverage.
• The cobra_details.eligibility_end_date field should be updated if the member is no longer eligible for COBRA.

Other COBRA requirements and notes

• 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.

Evidence of Insurability (EOI)

EOI may be required before carriers will approve certain coverages or changes to coverage. Typically, the carrier will reach out directly to employees if EOI is needed, and employees can submit paperwork through their ben-admin platform or the carrier’s portal.

In Noyo, a coverage change or election that is pending EOI will appear as a discrepancy, either because the requested coverage is missing, the employee is missing altogether (if the affected coverage was their only line), or the volume amount is different between the ben-admin’s and carrier’s system. These discrepancies will be tagged with an “EOI scenario” note that is visible in the Command Center.

When EOI has been accepted by the carrier and their system is updated, the next data sync will pull in the new coverage or amount and the discrepancy will automatically resolve.

There are some cases where the carrier does not approve the EOI or accepts one part of the request but not another. We are currently building handling for these scenarios, and questions about EOI can be sent to our Support team in the meantime.

Primary Care Provider Data

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.

"primary_care_providers": [
	{
	 "entity_identifier_code": "PCP",
	 "entity_type": "person",
	 "identification_code_type": "NPI",
	 "identification_code": "1234567890",
	 "last_name_org": "McCoy",
	 "first_name": "Leonard",
	 "middle_name": "H",
	 "patient_relationship_code": "unknown"
	}
]

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 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_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.