Creating new ClaimContacts

For each claim, ClaimCenter automatically creates ClaimContacts for contacts listed on the policy (such as the insured). In addition to these contacts, you can create a ClaimContact who:

  • Is listed in ContactManager (such as a vendor who is known to the insurer and who provides service for multiple claims)
  • Is not listed in any other system (such as a third-party claimant, witness, or a vendor who is not yet known to the insurer)

Use the following endpoint to create a new ClaimContact:

  • POST /claim/v1/claims/{claimId}/contacts

Minimum creation criteria

When you create a ClaimContact, you must specify the following:

  • contactSubtype (a subtype of Contact)
  • Either:
    • lastName (for ClaimContacts whose subtype is Person or one of its subtypes)
    • name (for ClaimContacts whose subtype is Company or one of its subtype)
  • At least one ClaimContact role
    • Note that the syntax of the request depends on whether the role is reserved or non-reserved

Creating a new ClaimContact with a reserved role

When you create a ClaimContact that has a reserved role, you must call two endpoints: one that POSTs or PATCHes the claim, and one that creates the ClaimContact. You can do this using either request inclusion or composite requests. For more information on request inclusion, see Request and response inclusion and Composite requests.

Reserved roles set from a field

In some cases, a reserved role is set through a field on the claim or one of its child objects.

For example, the reporter role is set from the Claim's reporter field. To create a new contact with the role of reporter, you must do the following:

  • POST the new contact.
  • PATCH the claim to assign the reporter role to the new contact.

The order in which the commands are executed depends on whether you are using request inclusion or a composite request.

The following is an example of adding the role of reporter to a new contact for an existing claim using request inclusion. The claim is the parent object, so it appears in the payload first.

Command

PATCH /claim/v1/claims/cc:402

Request

{
  "data": {
    "attributes": {
      "reporter": {
        "refid": "newContact"
      }
    }
  },
  "included": {
    "ClaimContact": [
      {
        "refid": "newContact",
        "attributes": {
            "contactSubtype": "Person",
            "firstName": "Carol",
            "lastName": "Daniels"
        },
        "method": "post",
        "uri": "/claim/v1/claims/cc:402/contacts"
      }   
    ]
  }
}

The following is an example of adding the role of reporter to a new contact for an existing claim using a composite request. The contact is created first so that its ID can be used when setting the reporter field on the claim.

Command

POST /rest/composite/v1/composite
Request
{
  "requests": [   
    {
      "method": "post",
      "uri": "/claim/v1/claims/cc:402/contacts",
      "body": {
        "data": {
          "attributes": {
            "contactSubtype": "Person",
            "firstName": "Carol",
            "lastName": "Daniels"
          }
        }
      },
      "vars": [
        {
          "name": "newContactId",
          "path": "$.data.attributes.id"
        }
      ]
    },
    {
      "method": "patch",
      "uri": "/claim/v1/claims/cc:402",
      "body": {
        "data": {
          "attributes": {
            "reporter": "${newContactId}"
          }
        }
      }
    }
  ]
}

Reserved roles that are set from an array

In some cases, a reserved role is set through an array on the claim or one of its child objects.

For example, the witness role is set from the Claim's witnesses array. To create a new contact with the role of witness, you must do the following:

  • POST the new contact.
  • PATCH the claim to assign the new contact to the witnesses array

The order in which the commands are executed depends on whether you are using request inclusion or a composite request.

Keep in mind that, within Cloud API, PATCHing an array does not add new members to the existing members. It replaces the existing members with the new members. If you want to add members to an array, you must first determine the existing members, and then specify an array with those members and the ones you wish to add. For more information, see PATCHes.

The following is an example of adding the role of witness to a new contact for an existing claim using request inclusion. The claim is the parent object, so it appears in the payload first.

Command

PATCH /claim/v1/claims/cc:402

Request

{
  "data": {
    "attributes": {
      "witnesses": [
        {
          "contact": {
            "id": "newContact"
          }
        }
      ]
    }
  },
  "included": {
    "ClaimContact": [
      {
        "refid": "newContact",
        "attributes": {
            "contactSubtype": "Person",
            "firstName": "Matt",
            "lastName": "Capaldi"
        },
        "method": "post",
        "uri": "/claim/v1/claims/cc:402/contacts"
      }   
    ]
  }
}

The following is an example of adding the role of witness to a new contact for an existing claim using a composite request. The contact is created first so that its ID can be used when adding the contact to the witnesses araay on the claim.

Command

POST /rest/composite/v1/composite
Request
{
  "requests": [   
    {
      "method": "post",
      "uri": "/claim/v1/claims/cc:402/contacts",
      "body": {
        "data": {
          "attributes": {
            "contactSubtype": "Person",
            "firstName": "Matt",
            "lastName": "Capaldi"
          }
        }
      },
      "vars": [
        {
          "name": "newContactId",
          "path": "$.data.attributes.id"
        }
      ]
    },
    {
      "method": "patch",
      "uri": "/claim/v1/claims/cc:402",
      "body": {
        "data": {
          "attributes": {
            "witnesses": [
              {
                "contact": {
                  "id": "${newContact}"
                }
              }
            ]
          }
        }
      }
    }
  ]
}

Creating a new ClaimContact with a non-reserved role

A non-reserved role is a role that can be set on a ClaimContact explicitly. Every role that is not listed in the ReservedContactRoles.yaml file is a non-reserved role. For example, alternate contact is a non-reserved role. A claim can have any number of alternate contacts, and this type of ClaimContact is not managed by an array on Claim.

To assign a non-reserved role to a ClaimContact, you must modify the ClaimContact's editableRoles array.

JSON syntax for the editableRoles array

When POSTing or PATCHing a ClaimContact, every member of the editableRoles array must include three pieces of information:

  • The role's code
  • The type of object on which the ClaimContact has this role
  • The ID of the object on which the ClaimContact has this role

The syntax used to specify this is:

"editableroles": [
  {
    "role": {
      "code": "<roleCode>"
    },
    "relatedTo": {
      "type": "<parentObjectType>",
      "id": "<parentObjectId>"
    }
  },
  ... <additionalRoles>

Example

For example, the following request PATCHes Claim cc:610 so that ClaimContact cc:777 has the alternate contact role (whose code is altcontact) on the claim itself.

Command

PATCH http://localhost:8080/cc/rest/claim/v1/claims/cc:610/contacts/cc:777

Request body

{
  "data": {
    "attributes": {
      "editableRoles": [
        {
          "role": {
            "code": "altcontact"
          },
          "relatedTo": {
            "type": "Claim",
            "id": "cc:610"
          }
        }
      ]
    }
  }
}

Similarly, the following request PATCHes claim cc:610 so that ClaimContact cc:208 has the owner role (whose code is incidentowner) on the vehicle incident whose ID is cc:102. (In other words, ClaimContact cc:208 is specified as the owner of the vehicle from vehicle incident cc:102.)

Command

PATCH http://localhost:8080/cc/rest/claim/v1/claims/cc:610/contacts/cc:208

Request body

{
  "data": {
    "attributes": {
      "editableRoles": [
        {
          "role": {
            "code": "incidentowner"
          },
          "relatedTo": {
            "type": "vehicleIncident",
            "id": "cc:102"
          }
        }
      ]
    }
  }
}