Creating test policies

The TestSupportPolicyPlugin class

At the beginning of the FNOL process, the user or service that is executing FNOL must identify the relevant policy. Once identified, ClaimCenter copies information about that policy to its own policy graph. These processes are referred to as policy search and policy retrieval. The details for how to execute these processes are specified by the IPolicySearchAdapter plugin.

The Test Util endpoints

In the base configuration, none of the API roles provide access to the endpoints in the Test Util API. Therefore, the only user who can create test policies is the super user su, who inherently has access to all endpoints.

You can configure the existing API roles to extend access to these endpoints to other users. For more information on configuring API roles, see the Cloud API Developer Guide.

Creating test policies

You can use the /test-util/v1/policies endpoint to create test policies. When you execute this endpoint, Cloud API takes the data specified in the payload and add it to the data in the TestSupportPolicyPlugin class. This allows you to reference test policies and their data in later calls that create claims and claim data.

There is no minimum data needed to create a test policy. If you create a policy with an empty request payload, the policy will have the following attributes:

• The policy currency will be set to the ClaimCenter default currency.
• The effective date will be set to the current date.
• The expiration date will be set to one year from the current date.
• The policy will be an unverified policy.

You can use the policies in the sample data as models for how to build test policies. To do this, identify the claim ID of a claim whose policy is an appropriate model. Then, execute a GET on any of the endpoints starting with /claims/{claimId}/policy to view how to structure data in a JSON payload. For a complete description of the data that can be specified in the request payload, refer to Swagger UI.

Use a unique policy number for each policy

When creating a test policy, Cloud API does not require that the policy number be unique from any existing policy numbers. However, if there are two or more policies with the same policy number, you will not be able to create a claim using that policy number. This is because the logic that creates claims will find multiple policies and will not be able to identify which policy to use.

Examples of test policy data

The following sections provide examples of some of the more frequently used fields. To access these examples compiled into a single payload, see Sample policy payload.

Common scalar fields

The following code block creates a policy that is effective from January 1, 2020 to January 1, 2021. Its policy number is FNOL-POLICY, and it is a verified policy.

{
  "data": {
    "attributes": {
      "effectiveDate": "2020-01-01T07:00:00.000Z",
      "expirationDate": "2021-01-01T07:00:00.000Z",
      "policyNumber": "FNOL-POLICY",
      "verifiedPolicy": true
    }
  }
}

Common typekey fields

The following code block creates a personal auto policy that is in force. (In other words, the policy has not been canceled.)

{
  "data": {
    "attributes": {
      "policyType": {
        "code": "PersonalAuto"
      },
      "status": {
        "code": "inforce"
      }
  }
}

Policy contacts

The following code block creates a policy where the insured is a person named Ray Newton who lives at 287 Kensington Rd. #1A, South Pasadena, CA. The ID in the Policy Administration for this contact is ab:0001-1.

When creating test policies, policy contacts are specified using request inclusion. For more information on this approach, see Request and response inclusion.

{
  "data": {
    "attributes": {
      "policyContacts": [
        {
          "contact": {
            "refid": "rayNewton"
          },
          "roles": [
            {
              "code": "insured"
            }
          ]
        }
      ]
    }
  },
  "included": {
    "Contact": [
      {
        "attributes": {
          "firstName": "Ray",
          "lastName": "Newton",
          "primaryAddress": {
            "addressLine1": "287 Kensington Rd. #1A",
            "city": "South Pasadena",
            "country": "US",
            "postalCode": "91145",
            "state": {
              "code": "CA"
            }
          },
          "subtype": {
            "code": "Person"
          },
          "policySystemId": "ab:0001-1"
        },
        "method": "post",
        "refid": "rayNewton",
        "uri": "/test-util/v1/contacts"
      }

    ]
  }
}

Policy locations

The following code block creates a policy location.

{
  "data": {
    "attributes": {
      "policyLocations": [
        {
          "address": {
            "addressLine1": "287 Kensington Rd. #1A",
            "city": "South Pasadena",
            "postalCode": "91145",
            "state": {
              "code": "CA"
            }
          }
        }
      ]
    }
  }
}

Policy-level coverages

The following code block creates a policy-level coverage. Note that the coverage has a coverage type (a typekey field), and two currency amount fields. A policy can also contain risk unit coverages, which are shown in the next section.

{
  "data": {
    "attributes": {
      "policyCoverages": [
        {
          "coverageType": {
            "code": "PALiabilityCov"
          },
          "incidentLimit": {
            "amount": "30000.00",
            "currency": "usd"
          },
          "exposureLimit": {
            "amount": "15000.00",
            "currency": "usd"
          }
        }
      ]
    }
  }
}

Risk units

A risk unit is something on a policy to which coverages are attached, such as a vehicle or a building. The following code block creates a risk unit. There are different types of risk units, depending on the policy's product type. Because the other examples are from a personal auto policy, this example is a vehicle risk unit.

Risk units typically include risk unit coverages (such as Collision coverage on a vehicle). For each coverage, you must specify a coverageType, which must be set to a value from the coverageType typelist. The coverage can also have coverage terms (such as a deductible). If you include coverage terms, each coverage term must have a covTermPattern (set to a code from the covTermPattern typelist) and a covTermSubtype (set to a code from the covTerm typelist). Additional fields may be necessary based on the type of coverage term. For example, coverage terms that are financial amounts require a financialAmount field.

{
  "data": {
    "attributes": {
      "vehicleRiskUnits": [
        {
          "RUNumber": 1,
          "vehicle": {
            "licensePlate": "1HGJ465",
            "make": "Saturn",
            "model": "SL",
            "policySystemId": "pcveh:0001-1",
            "state": {
              "code": "CA"
            },
            "vin": "1GV234TV347463345",
            "year": 1997
          },
          "coverages": [
            {
              "coverageType": {
                "code": "PACollisionCov"
              },
              "covTerms": [
                {
                  "covTermPattern": {
                    "code": "PACollDeductible"
                  },
                  "covTermSubtype": "FinancialCovTerm",
                  "financialAmount": {
                    "amount": "500.00",
                    "currency": "usd"
                  }
                }
              ],
              "incidentLimit": {
                "amount": "15000.00",
                "currency": "usd"
              }
            }
          ]
        }
      ]
    }
  }
}

Checking your work

ClaimCenter does not show data related to policies that are not associated with a claim. Therefore, there is no independent way to check your work for this tutorial, other than confirming that you get a response code and then attempting to create a claim using the policy.