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
Value | Description |
---|---|
adoption | Applies in the event that a member is looking to either add or remove coverage as a result of an adoption. |
benefit_class_change | Attached to requests attempting to move a member from one benefit class to another. |
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. |
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. |
court_order | Used when coverage changes are required due to court order. Also sometimes known as QMCSO (qualified medical child support orders). |
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. |
dependent_open_enrollment | Refers to a case in which the dependent is removing themselves from another member's coverage and going through their own open enrollment. |
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. |
eligibility_change | Used for more generic scenarios of a member's eligibility changing. It's better to use more detailed event reasons if you're able. |
foster_care | Refers to a member adding a foster child to coverage. |
immigration_status_change | Refer 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_change | Used in cases where a member is beginning or ending a leave of absence, often with an associated change in coverage. |
legal_guardian | Applicable when a member becomes a legal guardian for a child and adds the child to coverage. |
lost_coverage | Catch-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. |
marriage | Applies in the event that a member is looking to either add or remove coverage as a result of a marriage. |
medicare | Applicable when a member is modifying their other coverage due to gaining or losing medicare coverage. |
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. |
new_hire | Used with all members making coverage decisions after being hired. |
offline_change | A change made outside of conventional open enrollment or special enrollment periods. |
open_enrollment | Used with all members making coverage decisions during their group's open enrollment. |
rate_changed | Used 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. |
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. |
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. |
Updated 2 months ago