> ## Documentation Index
> Fetch the complete documentation index at: https://docs.noyo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# COBRA

> COBRA Enrollments and Terminations

Many carriers have special handling for [COBRA](https://www.dol.gov/general/topic/health-plans/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.

<Warning>**Not all carriers are able to support COBRA enrollments via Noyo**<br />Before sending COBRA enrollments, check the carrier-specific documentation in the Noyo web application. Individual carriers may also have more detailed requirements for COBRA requests.</Warning>

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](/api-reference/snapshots/create-member-snapshot).

```json theme={"system"}
"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 `cobra_enrolled= 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.

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

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

### Re-enrolling in Active coverage (following a previous enrollment in COBRA)

* Omit the `cobra_details` element.
* The `enrolled_member.effective_start_date` field should reflect the start of the new active (non-COBRA) coverage period.
* The `enrolled_member.effective_end_date` field should be sent as `datemax` (`9999-12-31`).

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