Using Events

Each member snapshot should include a block describing the event(s) associated with the member’s activities in your system. During onboarding, you’ll map your system’s member flows/options to Noyo’s events.

If we detect that a member snapshot contains changes to coverage and send those changes to the carrier, they’re more likely to be processed quickly and successfully if they are associated with an event. Though events are not always required, it’s best practice to send them any time you have them.

An event can be tied to a specific enrollment in the snapshot payload, which means it’s possible to send multiple events in a single snapshot. For instance, a snapshot could remove spousal coverage due to a divorce event at the same time that child coverage is added due to an adoption event. You should plan to include the last 60 days’ worth of events in each snapshot for a member, adding new events when they occur. Each event block includes an event date, reason, type, and id. See the member snapshot API reference for full detail. Importantly, the event date should always reflect the actual date of the relevant event. Sending other dates for events could cause denied coverage or unexpected coverage dates. See each event type below for details.

"events": [
    {
      "date": "2022-01-01",
      "id": "1",
      "reason": "open_enrollment",
      "type": "coverage"
    }
  ]

If multiple event reasons could be associated with a single enrollment for a member, select the single most relevant event (such as open_enrollment). This will rarely impact processing.

Events are required for all snapshots containing coverages with Beam Benefits and/or Principal Fianancial Group.

Open enrollment events

An open_enrollment reason is highly recommended for any member snapshots containing selections made on or around the group’s Open Enrollment period. Many carriers process open enrollments differently from other changes, and omitting this reason can cause major delays. For open_enrollment events, the event date is the effective date of the group’s Open Enrollment, not the date when the member elects coverage.

Termination events

Most event reasons can be sent with any valid snapshot payload. The only exception is termination events, where Noyo requires that an employment termination date is also included in the snapshot.

Event reasons

The following are the most common event reasons, but there is a wider variety available if you require them for your system (see the API reference for the full list).

Value	Description
`cobra_enrollment`	Used when enrolling members in COBRA coverage. See the COBRA section for more detail.
`cobra_termination`	Used when terminating members from COBRA coverage. See the COBRA section for more detail.
`demographic_change`	Used for demographic or employment data changes that do not impact coverage eligibility.
`new_hire`	Used for coverage decisions being made after being hired.
`open_enrollment`	Used for coverage decisions made during the group’s open enrollment.
`termination`	Used for most cases of employment termination. Voluntary/involuntary terminations are generally treated identically. In most cases of termination, the event date/termination date is equal to the last day of work for the member.
QLEs
`adoption`	Applies in the event that a member is looking to either add or remove coverage as a result of an adoption.
`change_to_full_time`	Often tied to benefit class or time status changes.
`change_to_part_time`	Often tied to a reduction of hours or a benefit class change.
`death`	Applicable to employee or dependent deaths and can be passed when adding or removing coverage due to death. Sending this is useful clarification in survivorship scenarios.
`disability_status_change`	Used when adding or removing coverage due to changes in disability status.
`divorce`	This applies in the event that a member is looking to either add or remove coverage as a result of a divorce.
`immigration_status_change`	Refer to cases in which the spouse becomes newly eligible for coverage (e.g., by obtaining legal resident status) and is then added to member’s coverage.
`lost_coverage`	Used when a member is losing coverage for a reason not otherwise specified in this list. For instance, when adding someone to coverage due to lost coverage elsewhere and also when removing them from coverage.
`marriage`	Applies in the event that a member is looking to either add or remove coverage as a result of a marriage.
`moved`	Most often used when an address change makes someone either eligible or ineligible for coverage.
`newborn`	Applies in the event that a member is looking to either add or remove coverage as a result of the birth of a child.
`rehire`	When member is being added back to coverage after being hired again at a company where they were previously employed. Many carriers will not issue coverage promptly if rehires are sent as generic new hires, see Special Cases for full details.
`reinstatement`	When a member is being added back to coverage as if they had never been terminated. Reinstatements differ from rehires, see Special Cases for full details.
`retirement`	Used to send coverage changes made in connection with retirement.

Intro

Groups

Members & Changes

Legacy

Open enrollment events

Termination events

Event reasons

​Open enrollment events

​Termination events

​Event reasons

Open enrollment events

Termination events

Event reasons