The FNOL process in Cloud API

The following diagram illustrates the FNOL process as executed through Cloud API:

Prior to making any Cloud API call to ClaimCenter:

1. The caller application queries the Policy Administration System for information on the relevant policy and its contacts, covered items, and coverages.

To execute the FNOL process with ClaimCenter:

2A. The caller application executes a POST /claims with a payload that describes the claim. If the call is successful, ClaimCenter saves a draft claim to the database with a draft claim number. The response object returned to the caller application includes the claim's id and its draft claim number.

2B. During the creation of the draft claim, ClaimCenter retrieves information about the policy from the PAS and copies it into the ClaimCenter policy graph.

3. Optionally, the caller application can execute a PATCH /claims/{claimID} one or more times. This may be appropriate when you want to create a draft claim before you have all of the information needed to submit it, and you later want to update that claim with additional information.

4A. The caller application executes a POST /claims/{claimId}/submit. If the call is successful, ClaimCenter promotes the claim to being open and assigns it an open claim number. The response object returned to the caller application includes the open claim number.

4B. As part of the process to promote the claim, ClaimCenter executes the automated claim setup rules. These rules can segment the claim, assign the claim, and create and assign activities for the claim.

The entire process always consists of at least two Cloud API calls to ClaimCenter:

• A POST /claims that creates a draft claim
• A POST /submit that submits the claim and promotes it to being open.

You cannot create a claim without a policy, and every policy belongs uniquely to one claim. (If two of more claims are based on the same policy, each has its own copy of the policy.)

There are three use cases for how FNOL can be executed through Cloud API. Each use case involves policies in a different state.

Claims with Test Util API policies

The Test Util API is an API that provides functionality to facilitate testing during development. You can use the Test Util API to create and test policies. Test Util API policies are appropriate for development environments that are not connected to a PAS.

You cannot PATCH a Test Util API policy. Because the policy reflects test data, the expectation is that it is created correctly in the initial POST.

To create an open claim with a Test Util API policy, you must execute the following calls:

1. POST /test-util/v1/policies to create the test policy.
2. POST /claims/v1/claim to create the draft claim.
3. POST /claims/v1/{claimId}/submit to submit the draft claim, thereby converting it to an open claim.

Claims with verified policies

You can create claims with verified policies. This approach requires an environment connected to a PAS.

There is current no endpoint to PATCH a verified policy.

To create an open claim with a verified policy, you must execute the following calls:

1. POST /claims/v1/claim to create the draft claim. The policy is automatically copied over from the PAS as part of the processing of this call.
2. POST /claims/v1/{claimId}/submit to submit the draft claim, thereby converting it to an open claim.

Note: In ClaimCenter, the New Claim Wizard permits the creation of a claim using a verified policy that is not in effect as of the claim's loss date. This type of claim cannot reach the end of the adjudication process unless the coverage is somehow verified. But, it can be created. In contrast, Cloud API does not permit the creation of claims using a verified policy if the policy is not in force as of the claim's loss date.

Claims with unverified policies

You can create claims with unverified policies. This approach can be done in either a test or production system. The policy is based on information provided by the call, so it does not require an environment connected to a PAS. However, you typically cannot make payments on a claim while the claim's policy is still unverified.

You can PATCH an unverified policy. However, there is currently no endpoint to refresh an unverified policy, which is the action that converts an unverified policy into a verified policy.

Claims with unverified policies can only be created in a composite request. Thus, to create an open claim with a unverified policy, you must execute the following call:

1. POST /composite/v1/composite to create a composite request with the following subrequests:
   1. POST /claim/v1/unverified-policies to create an unverified policy.
   2. POST /claims/v1/claim to create the draft claim.
   3. POST /claims/v1/{claimId}/submit to submit the draft claim, thereby converting it to an open claim.

To view an example of a payload that creates and submits a claim with an unverified policy in a composite request, see Sample composite claim payload.

You cannot have a single composite request operate on more than one claim.

Claims with unverified policies can only be created in a composite request.

You can cancel a draft claim through Cloud API. This is done using the /claim/{claimId}/cancel endpoint. This has the same effect as when a user clicks the Cancel button in the New Claim Wizard.

You cannot cancel a claim after it has been submitted and therefore promoted to being an open claim. Once a claim has been submitted, the only way to discontinue processing of it is to close it.

In the base configuration, some lines of business let you create claims in different "modes". For example, for personal auto, you can create a "regular" claim, a "quick" claim, or a "first and final" claim. These modes are distinctions that exist primarily in the user interface. Each mode may require a greater or lesser amount of information, and some modes may assist in executing tasks beyond simply reporting the claim. But from a technical standpoint, the claims created in each mode are not fundamentally different from one another.

Thus, Cloud API does not have an analog for "modes". When you create a claim through Cloud API, as long as you provide the minimum required information, you can provide whatever amount of information is appropriate for the use case.