Creating incidents
In the base configuration, there are no required fields for creating any type of incident. All fields are optional.
The following sections provide additional information and examples of the various types of incidents you can create through the system APIs.
Dwelling incidents
A dwelling incident is an object that captures loss information about a place where people live.
In the base configuration, dwelling incidents can be used with policies of the following type:
- HOPHomeowners
A dwelling incident typically includes a primary child object called
location
, with fields that describe inherent qualities of the dwelling's
location, such as address
. The dwelling incident also contains additional
information specific to the loss, such as damagedAreaSize
and
severity
. You do not have to specify location
when you
create a dwelling incident. If you do want to specify location
, you can
either:
- Specify an existing location on the policy by providing its
policySystemId
. - Specify an existing location on the claim by providing its ClaimCenter
id
. - Create a new location by providing its attributes inline.
Unlike some other child objects, a location
cannot be created as a
referenced resource in the included
section and then specified by
refid
. A new location must be created as an inlined resources.
Example of creating a typical dwelling incident
In this example, the dwelling incident's location
is included, and it is
specified by policySystemId
.
POST /claims/{claimId}/dwelling-incidents
{
"data": {
"attributes": {
"description": "water from heavy rains leaked through the roof damaging walls and floor.",
"location" : {
"policySystemId" : "pcdwl:0001-1"
} ,
"yearsInHome" : 7
}
}
}
Fixed property incidents
A fixed property incident is an object that captures loss information about a fixed piece of property (such as a building).
In the base configuration, fixed property incidents can be used for a large range of policy types. These include:
- Business auto
- Businessowners
- Commercial package
- Commercial property
- Personal auto
This list is not exhaustive. For a complete list of policy types that are compatible with
fixed property incidents, refer to the Incident
typelist in Studio.
A fixed property incident typically includes a primary child object called
location
, with fields that describe inherent qualities of the property's
location, such as address
. The fixed property incident also contains
additional information specific to the loss, such as lossparty
and
severity
. You do not have to specify location
when you
create a fixed property incident. If you do want to specify location
, you can
either:
- Specify an existing location on the policy by providing its
policySystemId
. - Specify an existing location on the claim by providing its ClaimCenter
id
. - Create a new location by providing its attributes inline.
Unlike some other child objects, a location
cannot be created as a
referenced resource in the included
section and then specified by
refid
. A new location must be created as an inlined resources.
Example of creating a typical fixed property incident
In this example, the dwelling incident's location
is included, and it is
created as an inlined resource.
POST /claims/{claimId}/fixed-property-incidents
{
"data": {
"attributes": {
"location": {
"address": {
"addressLine1": "1313 Monroe Lane",
"city": "Pomona",
"country": "US",
"state": {
"code": "CA"
}
},
"primaryLocation": false
},
"severity" : {
"code" : "major-prop"
}
}
}
}
Property contents Incidents
A property contents incident is an object that captures loss information about personal items and valuables within a commercial or business property, such as furniture, computers, and jewelry.
In the base configuration, property contents incidents can be used for a range of policy types. These include:
- HOPHomeowners
- CommercialProperty
- BusinessOwners
This list is not exhaustive. For a complete list of policy types that are compatible with
property contents incidents, refer to the Incident
typelist in
Studio.
A property contents incident typically includes the primary child object
location
, with fields that describe the storage location of where
the personal property loss took place, such as address
. The property
contents incident also contains additional information specific to the loss, such as
lossparty
and severity
. You do not have to specify
location
when you create a property contents incident. If you do
want to specify location
, you can either:
- Specify an existing location on the policy by providing its
policySystemId
. - Specify an existing location on the claim by providing its
ClaimCenter
id. - Create a new location by providing its attributes inline.
severity
, but base configuration does not provide severity
typecodes for these subtypes. For more information on customizing typelists and
typecodes, see the Configuration Guide.The property contents incident uses the assessment-content-items
endpoint to capture loss information for the individual items contained within the
property.
Assessment content items typically include the description
, the
contentCategory
describing the type of item lost, as well as its
purchaseCost
, and replacementValue
. Assessment
content items can include the general high-level category for the items in a policy
called a contentsSchedule
. Such schedule terms include:
- Homeowners
- Office Furniture and Fixtures
- Information Systems
The contentSchedule
determines which contentCategory
can be applied to the line items, such as electronics
for Homeowners or
filecabinet
for Office Furniture and Fixtures. Neither field is
required, but if you do not include contentSchedule
in your POST
request payload, there are no restrictions to the contentCategory
line
items that you can use.
Refer to the ContentLineItemsSchedule
and
ContentLineItemCategory
typelists in Studio for details.
The contentSchedule
determines which contentCategory
can be applied to the line items, such as electronics
for Homeowners or
filecabinet
for Office Furniture and Fixtures. Neither field is
required, but if you do not include contentSchedule
in your POST
request payload, restricting contentCategory
line items is not
required.
ContentLineItemSchedule
and
ContentLineItemCategory
typelists in Studio for details.- In ClaimCenter, Personal Property line items use a notes field that is read
only; specific business rules fill the notes field with a comment regarding
the line item. In the Claim API, the corresponding request payload
attribute,
itemComment
, is editable. When using both ClaimCenter and the Claim UI, the potential for an overwrite of the notes field is liable to occur. - The description field for assessment content items in ClaimCenter is
required in its base configuration. The Claim API does not require this
field /
assessment-content-items
request payloads.
Example of creating a property contents incident with included assessment content items
In this example, the property contents incident location and the assessment line items are both created in a single POST operation. The property contents incident creates a third-party location inline. In the included section, the assessment summary line items are added for record players lost during a burglary of the property incident location.
POST claim/v1/claims/cc:S44U/property-contents-incidents/
{
"data": {
"attributes": {
"description": "Property Contents incident",
"location":{
"address": {
"addressLine1": "287 Kensington Rd. #1A",
"addressLine2": "Level 1",
"addressLine3": "Unit 1",
"city": "South Pasadena",
"country": "US",
"county": "Los Angeles County",
"postalCode": "91145",
"state": {
"code": "CA"
}
}
},
"lossParty": {
"code": "insured"
}
}
},
"included": {
"AssessmentContentItem": [
{
"attributes": {
"amountAfterLimit": {
"amount": "54.27",
"currency": "usd"
},
"contentCategory": {
"code": "collectibles"
},
"contentSchedule": {
"code": "homeowners"
},
"depreciationPercentage": "21.0",
"description": "Record player",
"itemComment": "Items stolen during burglary",
"numberOfItems": 2,
"purchaseCost": {
"amount": "1200.76",
"currency": "usd"
},
"replacementValue": {
"amount": "965.23",
"currency": "usd"
}
},
"method": "post",
"uri":"/claim/v1/claims/cc:S44U/property-contents-incidents/this/assessment-content-items/"
}
]
}
}
}
Injury incidents
An injury incident is an object that captures loss information about a single injury that a claimant suffered.
In the base configuration, injury incidents can be used for a large range of policy types. This includes:
- Business auto
- Businessowners
- Commercial package
- General liability
- Personal auto
This list is not exhaustive. For a complete list of policy types that are compatible with
fixed property incidents, refer to the Incident
typelist in Studio.
An injury incident typically includes a primary child object called
injuredPerson
, with fields that describe inherent qualities of the person,
such as firstName
and lastName
. The injury incident also
contains additional information specific to the injury, such as
ambulenceused
, primaryDoctor
, and
treatmentType
. You do not have to specify injuredPerson
when creating an injury incident. If you do want to specify injuredPerson
,
you can either:
- Specify an existing ClaimContact on the policy by providing its
policySystemId
. - Specify an existing ClaimContact on the claim by providing its ClaimCenter
id
. - Create a new ClaimContact in the
included
section and reference that ClaimContact byrefid
.
Example of creating a typical injury incident
In this example, the injury incident's injuredPerson
is provided, and it
is specified by ClaimCenter id
.
POST /claims/{claimId}/injury-incidents
{
"data": {
"attributes": {
"bodyParts": [
{
"primaryBodyPart": {
"code": "head"
}
}
],
"description": "Potential vision loss",
"detailedInjuryType": {
"code": "58"
},
"generalInjuryType": {
"code": "specific"
},
"injuredPerson": {
"id": "cc:102"
},
"lossParty": {
"code": "third_party"
},
"lostWages": true,
"severity": {
"code": "major-injury"
},
"treatmentType": {
"code": "hospital"
}
}
}
}
Living expenses incidents
A living expenses incident is an object that captures loss information about expenses incurred as a result of the loss of use of a property. (For example, staying in a hotel while a damaged home is repaired.)
In the base configuration, living expenses incidents can be used with policies of the following type:
- HOPHomeowners
Unlike other types of incidents, a living expense incident does not make use of a primary child object.
Example of creating a typical living expense incident
In this example, a living expense incident is created. There is no primary child object to reference or create.
POST /claims/{claimId}/living-expenses-incidents
{
"data": {
"attributes": {
"description": "7-day hotel stay during flood damage repair",
"lossParty" : {
"code" : "insured"
},
"startDate" : "2020-08-31T07:00:00.000Z"
}
}
}
Vehicle incidents
A vehicle incident is an object that captures loss information about a vehicle.
In the base configuration, vehicle incidents can be used with policies of the following type:
- Business auto
- Businessowners
- Personal auto
- Personal travel
A vehicle incident typically includes a primary child object called vehicle
,
with fields that describe inherent qualities of the vehicle, such as make
,
model
, and licenseplate
. The vehicle incident also
contains additional information specific to the loss, such as
airbagsdeployed
, collisionpoint
, and
driver
. You do not have to specify vehicle
when creating a
vehicle incident. If you do want to specify vehicle, you can either:
- Specify an existing vehicle on the policy by providing its
policySystemId
. - Specify an existing vehicle risk unit on the claim by providing its ClaimCenter
id
. - Create a new vehicle by providing its attributes inline.
Unlike some other child objects, a vehicle
cannot be created as a referenced
resource in the included
section and then specified by
refid
. A new vehicle must be created as an inlined resources.
Example of creating a typical vehicle incident
In this example, the vehicle incident's vehicle
is provided, and it is
created as an inlined resource.
POST /claims/{claimId}/vehicle-incidents
{
"data": {
"attributes": {
"collisionPoint": {
"code": "front"
},
"damageDescription": "Damage to bumper and front panels",
"driver": {
"id": "cc:102"
},
"severity": {
"code": "moderate-auto"
},
"vehicle": {
"licensePlate": "7FDG745",
"make": "Mercury",
"model": "Sable",
"state": {
"code": "CA",
"name": "California"
},
"vin": "6GYF54637HD645370",
"year": 1993
}
}
}
}
Other structure incidents
An other structure incident is an object that captures loss information about structures other than the main dwelling, such as a secondary building like a shed or artist’s studio, as well fence damage.
In the base configuration, other structure incidents can be used for the Homeowners
policy Coverage B - Other Structures
subtype. See the
CoverageType
typelist for the Homeowners Coverage B typecodes.
An other structure incident typically includes its primary child object
fencesDamaged
, as well as the description
, and
lossParty
.
severity
, but base configuration does not provide severity typecodes for these subtypes. For more information on customizing typelist and typecodes, see the Configuration Guide.
Example of creating a typical other structure incident
In this example, the fencesDamaged
attribute is included in the
other structure incident:
POST /claims/{claimId}/other-structure-incidents
{
"data": {
"attributes": {
"description": "Other structure incident",
"fencesDamaged": true,
"lossParty": {
"code": "insured"
}
}
}
}