Incidents

Assessment content items

Custom incidents can make use of assessment content items. An assessment content item is an individual item covered by the policy. Assessment content items are useful when you want to cover some large container object (such as a house), but you also want to track the contents of the container individual (such as tracking each piece of fine jewelry in a house).

For example, in the base configuration, a baggage incident is a "container object" that captures loss information about a piece of baggage that was lost or damaged during a covered trip. The policy may also cover individual items within the baggage. If they do, each covered item within the baggage is an assessment content item.

There are typically five endpoints for an incident's assessment content items: a collection GET, an element GET, a POST, a PATCH, and a DELETE. These endpoints are child endpoints with a specific incident as the parent. For example, assessment content items for baggage incidents have the following endpoints:

• GET /claim/v1/claims/{claimId}/baggageincidents/{incidentId}/assessment-content-items
• POST /claim/v1/claims/{claimId}/baggageincidents/{incidentId}/assessment-content-items
• GET /claim/v1/claims/{claimId}/baggageincidents/{incidentId}/assessment-contentitems/{assessmentContentItemId}
• PATCH /claim/v1/claims/{claimId}/baggageincidents/{incidentId}/assessment-contentitems/{assessmentContentItemId}
• DELETE /claim/v1/claims/{claimId}/baggageincidents/{incidentId}/assessment-contentitems/{assessmentContentItemId}

Additional accessible fields filters

Incidents can store information about third parties. For example, a claim that involves a collision with another driver will have incident information about the third-party driver's vehicle. Third-party information ought to be accessible to some types of caller, such as claims adjusters. But it ought to be inaccessible to other types of callers, such as producers.

In these situations, the fields a caller can access is not an "all or nothing" decision, but rather a "all or limited set only" decision. Furthermore, the choice of "all fields" or "a limited set of fields only" depends on the business relationship that the caller has with the data. This type of restriction is implemented through an "additional accessible fields filter". An additional accessible fields filter is an expression that evaluates the business relationship the caller has with a given resource. This evaluation may add restrictions that limit the caller to a specific subset of fields.

When you create a custom incident type, the REST endpoint generator automatically creates some additional accessible fields filter logic. However, this information is incomplete. For each custom incident type, you must do one of the following:

• If the incident stores third-party information that is accessible only for callers with a specific business relationship, you must complete the configuration started by the REST endpoint generator.
• If the incident does not store any third-party information that is accessible only for callers with a specific business relationship, you must remove the configuration added by the REST endpoint generator.

For information on how to remove or complete the configuration, see one of the following:

• For incidents that do not have a damageable: Additional work for the incident endpoints
• For incidents that do have a damageable: Additional work for the incident endpoints

For more information on additional accessible fields filters in general, see Resource access files: additional accessible fields filters.