> ## 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.
# Inferred Plan Switching
> How Noyo automatically handles plan switches when existing coverage is omitted from a snapshot
When a member snapshot omits an existing active coverage but includes a different active coverage for the same line, Noyo can automatically detect that a plan switch occurred. This is called **inferred plan switching**. Instead of rejecting the snapshot, Noyo handles the old coverage automatically.
## When does inferred plan switching apply?
Inferred plan switching applies when all of the following are true:
1. An active coverage exists in Noyo for a member
2. That coverage is **not included** in the incoming snapshot
3. The snapshot **does include** a different active coverage for the same line of coverage and member
## How Noyo matches coverages
For Noyo to infer a plan switch, the new coverage in the snapshot must match the existing coverage on:
* **Individual**: Same member (employee or specific dependent)
* **Line of coverage**: Same line (e.g., both `medical`, both `dental`)
* **Overlapping effective dates**: The coverage periods must share at least one day in common. Since active coverages typically use `9999-12-31` as the `effective_end_date`, this condition is met in most plan switch scenarios. However, if there is a gap between the old coverage's end date and the new coverage's start date (e.g., old ends `2024-06-30` and new starts `2025-01-01`), Noyo will not treat it as a plan switch.
The new and old coverages do not need to be from the same carrier.
### Plan type matching
For **medical**, **dental**, and **vision**, any plan type can switch to any other (e.g., HMO to PPO).
For all other lines of coverage — `life`, `add`, `std`, `ltd`, `accident`, `critical_illness`, `cancer`, `health_fund`, `hospital_indemnity`, `pharmacy`, `wellness` — plan types must match. For example, basic life cannot switch to voluntary life.
If multiple possible matches are found for a single omitted coverage, Noyo will not infer a plan switch and the coverage will be treated as missing. Ensure that only one active coverage per line of coverage per member is included in the snapshot.
## How the old coverage is handled
The action Noyo takes on the old coverage depends on the timing of the new coverage relative to the old.
### Terminated when the new coverage starts later
If the new coverage starts **after** the old coverage's start date, the old coverage is terminated with an `effective_end_date` set to one day before the new coverage's `effective_start_date`.
**Example:** An employee is switching dental plans during open enrollment.
* Old dental plan: `effective_start_date` of `2024-01-01`
* New dental plan: `effective_start_date` of `2025-01-01`
* **Result:** Old dental plan is terminated with an `effective_end_date` of `2024-12-31`
### Waived/canceled when the new coverage starts at the same time or earlier
If the new coverage starts **on or before** the old coverage's start date, the old coverage is waived/canceled as if it never took effect.
**Example:** A member's upcoming dental coverage is being replaced before it starts.
* Old dental plan: `effective_start_date` of `2025-01-01`
* New dental plan: `effective_start_date` of `2025-01-01`
* **Result:** Old dental plan is waived/canceled
## Snapshot warnings
When Noyo infers a plan switch, the snapshot response will include an `InferredPlanSwitchWarning` indicating which coverage was terminated or waived/canceled and the resulting end date. You can use these warnings to confirm that the inferred behavior matches your expectations.
## Open enrollment example
An employee is currently enrolled in Dental Plan A (started `2024-01-01`) and you want to switch them to Dental Plan B for the new plan year. With inferred plan switching, you only need to send the new plan:
```json [expandable] theme={"system"}
{
"snapshot_mode": "current_open",
"employee": {},
"dependents": [],
"coverages": [
{
"carrier_id": "2d370e0e-fd73-45e0-8828-796d2cacaeef",
"line_of_coverage": "dental",
"plan_id": "40fdcb25-0fb3-43db-8dda-28180692854d",
"enrolled_members": [
{
"individual_id": "52b8ff36-388a-4faf-bc42-df446f13b89a",
"individual_type": "employee",
"effective_start_date": "2025-01-01",
"effective_end_date": "9999-12-31",
"event_id": "2001",
"latest_change_effective_date": "2024-11-15"
}
]
}
],
"events": [
{
"id": "2001",
"date": "2025-01-01",
"type": "coverage",
"reason": "open_enrollment"
}
]
}
```
Noyo will automatically terminate the member's enrollment in Dental Plan A with an `effective_end_date` of `2024-12-31` and process the new enrollment in Dental Plan B.
## Inferred vs. explicit plan switching
You can always [explicitly switch plans](/examples/switch-plans) by including both the old coverage (with a termination end date) and the new coverage in the same snapshot. Inferred plan switching provides an alternative when your system does not track or send the old coverage.
| Aspect | Explicit plan switch | Inferred plan switch |
| :----------------------------- | :-------------------------------- | :------------------------------------------------- |
| Old coverage in snapshot? | Yes, with an `effective_end_date` | No |
| New coverage in snapshot? | Yes | Yes |
| Control over termination date? | Full control | Automatically set to one day before new start date |
If you include the old coverage with an explicit termination date, Noyo will use your specified date and inferred plan switching will not apply.
## Relationship to omitted coverage handling
Inferred plan switching and [omitted coverage handling](/docs/members/using-snapshots/omitted-coverage-handling) both address active coverages missing from a snapshot, but they serve different purposes:
* **Inferred plan switching** handles cases where a replacement coverage is present
* **Omitted coverage handling** handles cases where no replacement is present
Inferred plan switching is always evaluated first. If a match is found, the coverage is handled as a plan switch. Any remaining missing coverages are then subject to your `omitted_coverage_handling` policy (`reject`, `continue`, or `terminate`).
Code example
Read more
Read more
Read more