Tell us how to handle any active coverages not included in a snapshot.
omitted_coverage_handling
block to member snapshots that gives you the power to specify our system’s behavior.
You can tell our system how to handle omitted coverages by passing one of the following values in the new policy
field:
Value | Description |
---|---|
reject | This is the default behavior if no other behavior is specified. Snapshots with omitted coverages will continue to be canceled. |
continue | Noyo will behave as if these coverages were included in the snapshot, and take no action to terminate them at the carrier. |
terminate | This will create a termination transaction for the omitted coverage using the end date specified by the termination_rule . |
Reject
policy
of reject
will replicate the default behavior of member snapshots, where the member’s changes or the entire snapshot are rejected with information about the missing coverage. The failure will not be returned as an API (4xx) error, but will be included in the snapshot fulfillment summary.
Continue
on omissionpolicy
of continue
allows you to keep sending member snapshots with the member’s current coverages without making explicit changes to any that are omitted. Noyo will return warnings for specific coverages or members missing from the snapshot, so you’ll be alerted to omitted coverages and can pass these warnings along to Operational or client-facing teams who can resolve issues.
Typically, this will result in no changes to the omitted coverages; however, in scenarios that impact all coverages for the family (such as changing from one division or subgroup to another), these coverages will be included as part of the change.
Terminate
on omissionpolicy
of terminate
allows you to terminate any unexpected coverages found at the carrier. This policy requires that a termination_rule
also be passed so we can calculate a termination date for the omitted coverage.
Value | Description |
---|---|
end_of_current_month | The last day of the current month. If sent on July 4, this would create a termination date of July 31st. |
end_of_prior_month | The last day of the previous month. If sent on July 4, this would create a termination date of June 30th. |
custom | This allows a custom termination date to be sent. It requires including the effective_end_date field, which accepts a date format of yyyy-mm-dd . |