Using Event Reasons

Increase accuracy and carrier processing times

Each member snapshot should include an event block describing any event associated with the requested change. During onboarding, you’ll map your system’s event reasons to Noyo’s list below. This list is also included in the API spec for the member snapshot endpoint.

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

Each event block includes an event date, reason, type, and id. See the member snaphot API reference for full detail.

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

While events are not explicitly required for every snapshot, it is a best practice to provide them every time. Noyo provides event data to carrier partners wherever possible, and including events with all snapshots will improve the speed and success rate of processing.

🚧

Open enrollment events

An open_enrollment reason is highly recommended for any OE changes. 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).

For some carrier connections, Noyo does enforce a requirement for event reason; this detail is provided in the technical documentation for each individual carrier.

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.

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.

See the API reference for full technical details of event payloads.

Available event reasons

ValueDescription
adoptionApplies in the event that a member is looking to either add or remove coverage as a result of an adoption.
benefit_class_changeAttached to requests attempting to move a member from one benefit class to another.
change_to_full_timeOften tied to benefit class or time status changes.
change_to_part_timeOften tied to a reduction of hours or a benefit class change.
cobra_enrollmentUsed when enrolling members in COBRA coverage. See the COBRA section for more detail.
cobra_terminationUsed when terminating members from COBRA coverage. See the COBRA section for more detail.
court_orderUsed when coverage changes are required due to court order. Also sometimes known as QMCSO (qualified medical child support orders).
deathApplicable 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.
dependent_open_enrollmentRefers to a case in which the dependent is removing themselves from another member's coverage and going through their own open enrollment.
disability_status_changeUsed when adding or removing coverage due to changes in disability status.
divorceThis applies in the event that a member is looking to either add or remove coverage as a result of a divorce.
eligibility_changeUsed for more generic scenarios of a member's eligibility changing. It's better to use more detailed
foster_careRefers to a member adding a foster child to coverage.
immigration_status_changeRefer to cases in which the spouse becomes newly eligible for coverage (eg by obtaining legal resident status) and is then added to member's coverage.
leave_status_changeUsed in cases where a member is beginning or ending a leave of absence, often with an associated change in coverage.
legal_guardianApplicable when a member becomes a legal guardian for a child and adds the child to coverage.
lost_coverageCatch-all for when a member is losing coverage not due to any other specific event types in the list. For instance, applicable when adding someone to coverage due to lost coverage elsewhere and also when removing them from coverage.
marriageApplies in the event that a member is looking to either add or remove coverage as a result of a marriage.
medicareApplicable when a member is modifying their other coverage due to gaining or losing medicare coverage.
movedMost often used when an address change makes someone either eligible or ineligible for coverage.
newbornApplies in the event that a member is looking to either add or remove coverage as a result of the birth of a child.
new_hireUsed with all members making coverage decisions after being hired.
offline_changeA change made outside of conventional open enrollment or special enrollment periods.
open_enrollmentUsed with all members making coverage decisions during their group's open enrollment.
rate_changedUsed for cases in which a rate changes after the employee elects coverage. Some benefits administration platforms allow the employee to reselect coverage if they are dissatisfied with the new rates in these cases.
rehireWhen 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.
reinstatementWhen 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.
retirementUsed to send coverage changes made in connection with retirement.
terminationUsed 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.

What’s Next

Learn what happens in the lifecycle of each member snapshot