Topics on this page

BriteClaims environment setup guide

This guide walks administrators through setting up BriteClaims. BriteClaims is built to be as configurable as possible straight out of the box. 

Configuration questionnaires and requirements gathering 

Complete the configuration questionnaire to determine client requirements. For more context and sample configurations for the questionnaire, please refer to BriteClaims questionnaire, requirements and sample configurations.

Checklist to start

Before you start, you need:

  • Properly configured Lines and Policies systems.
  • Access to the AWS console
    • Please note that in the near future, all of BriteClaims will be configured via the UI. 
  • Access to the BriteClaims Django Administration dashboard.

Set up the database and run migrations

To set up the database and run migrations, you need to run this command in the ManageLambda function in the AWS console.

{
  "manage": {
    "name": "reset_db",
    "options": {
      "noinput": false
    }
  }
}
{
  "manage": {
    "name": "migrate"
  }
}

Set up the BriteClaims environment in AWS

The BriteClaims environment in AWS is set up by the Cloud team. Contact #cloud-int to deploy BriteClaims on a new site. 

Set up the initial default/system data

To set up the initial default data, you need to run the following command in the ManageLambda function in the AWS console:

{
  "manage": {
    "name": "seed",
    "options": {
      "clean": true,
      "britepolicies": true
    }
  }
}

This will set up the base configurations you need to start importing relevant lines. 

Configure the import configurations

To configure the import configurations:

  1. Go to the BriteClaims Django Administration dashboard.
  2. Scroll to the Integrations section, and select Add next to Import Configurations.
Figure 1: Django Admin options

3. On the Add Import Configuration screen, type the product label in the Product Label box. Make sure the Product Label matches the line of business (LOB) label you want to import.

Figure 2: Personal Auto screenshot

4. Select the default group under the Default Group.

5. Select the line import settings from the Available Line Import settings. Select the left and right arrows to move settings between the Available line import settings and Chosen line import settings boxes.

6. Select Save

Figure 3: Add import configuration screen.

Import Lines configuration into BriteClaims

Run the import line command in the AWS console (similar to the initial data command):

{
  "manage": {
    "name": "import_lines",
    "args":[
        "--lines",
        "Personal Auto"
    ]
  }
}

Note: The lines option needs to match the LOB that you’re importing and the import configuration’s Product Label.

Refresh Lines configuration into BriteClaims 

To refresh Lines configuration into Claims:

  1. Select Claims in the BriteCore menu. 
Figure 3: Claims icon in the BriteCore menu.
  1. Select System Admin.
  2. In the System Admin menu, select Products Maintenance.
Figure 4: System Admin
  1. On the Products Maintenance screen, select the ellipsis of the relevant line for more options, and then select Refresh
Figure 5: Products Maintenance screen.
  1. In the Refresh line data confirmation dialog box, select Yes.

Note: You must wait for the line configurations to import in the background.

Alternatively, you can run the import line command in the AWS console (similar to the initial data command):

{
  "manage": {
    "name": "import_lines",
    "args":[
        "--lines",
        "Homeowners"
    ]
  }
}

Note: The lines option needs to match both the LOB you’re importing and the import configuration’s Product Label.

Generate default FNOL and Claim view configurations (optional)

Set up risk type groups

  1. Go to the BriteClaims Django Administration dashboard.
  2. Go to the Risk section, and select Add next to Risk type groups.
Figure 6: Risk type groups.

3. Add a risk group that make sense for the LOB. For example, it makes sense to group risk types under Vehicle for Personal Auto.

Figure 7: Add risk type group.

4. Go to each risk type you want to include with this group and select the risk type group. When you do this, you enable that risk type to be added in the FNOL and in the claim file.

Figure 8: Select risk type to change.
Figure 9: Add risk type details.

Set up damages

You can add damages if that makes sense for the particular LOB.

To add damages:

  1. Go to the BriteClaims Django Administration dashboard.
  2. Go to the Risk section, and select Add next to Damage type.
  3. Add damage type.
Figure 10: Add damage type.

4. Scroll down and select/add the attributes needed to describe the damage.

Figure 11: Add attributes.

5. Now go to each risk type you want to have damage and select the damage type.

Figure 12: Add damage and damage type.

Add the risk group to the Product

On the same screen above, add the risk groups to the product:

Figure 13: Add the risk group to a product.

Generate Config

After you have completed the steps above, you can now auto generate the minimal default views.

This will:

  • Set up FNOL steps.
  • Add risk forms (all fields in a simple list).
  • Add damage forms.
  • Set up default display view.
{
  "manage": {
    "name": "generate_config",
    "option":{
        "line": "Personal Auto"
    }
  }
}

Warning: This will override any existing configurations for this LOB.

Optional: Override default field validation settings

Sometimes you can have a complex line and policy system that may create issues with the claim system field validator.

In Lines, the fields and values to be imported are taken from:

  1. Policy information
  2. Risk type(s)
Figure 14: View Products.

Each field is matched to a data type:

  • Boolean
  • Number
  • String
  • Option Selection – Enum
  • Date – Date and Datetime
Figure 15: Type options.

See Figure 16 for an example of a line field, where siteAddressLatitude is a number type field.

Figure 16: Edit Data Field screen.

The reference name of a line field is used in the claim system as External Name.

The draft line configuration has no versioning, so it’s important to be aware that there might be changes in the line configuration that are used by a policy, but aren’t captured in time by the claim system. This can create validation issues. 

Depending on how the policy is set up, it is possible the policy may:

  1. Use a special date/time format, such as %m/%d/%Y %H:%M:%S %z.
  2. Have a number stored as a string.

Instead of honoring the data type set in the line system, a snapshot of the policy revision is attached to a claim file during the creation of a first notice of loss (FNOL) if a policy is linked to the claim file.

The claim system processes the policy revision during the creation of a FNOL. Processing policy revision information includes data validation on each risk field extracted from the policy revision.

The validation of these risk fields matches with the risk type fields configured in the line system. Each field is matched to a data type:

The validator contains opinionated default settings that may reject a policy risk field value. For example:

  1. String
    1. Allow blank.
  2. Decimal
    1. Total of digits is set to a maximum of 14.
    2. Decimal places are set to a maximum of 2.

We may override the validator opinionated default settings if we get the following errors:

  1. Datetime has the wrong format.
    1. Use this format instead: YYYY-MM-DDThh:mm[:ss[.uuuuuu]][+HH:MM|-HH:MM|Z].
  2. Ensure that there are no more than 14 digits.

To review the policy revision data that failed the validation, make an API call to the following endpoint.

GET /api/policies/risks/?filter[revision_id]=<POLICY_REVISION_ID>

Alternatively, we can review the fields configured in the line system based on their data type.

You can manually override the validation settings using the Claims Django Administration interface.

  1. Go to the Claims Django Administration dashboard.
  2. Select Integrations, and select Import Settings.
Figure 17: Integrations options.
  1. Select Add Import Setting.
Figure 18: Select import setting to change screen.
  1.  Type the following text in the respective fields:
    1. Type: Direct kwargs
    2. Relation: Attributes
    3. External name: The reference name of a line field.
    4. Direct kwargs:
# Example: Number Format
{  "kwargs": { "max_digits": 32, "decimal_places": 8}}
# Example: Date Format
{  "kwargs": { "input_formats": ["%m/%d/%Y %H:%M:%S %z​​", "%Y-%m-%d"]}}

Important: If you want to remove an import setting after the lines configuration has been refreshed, you first need to refresh the lines configuration again with the import setting’s kwargs set to the {} value. Otherwise, the previously set kwargs content will remain in the relevant attribute.

  1. Select Save
Figure 19: Add import setting screen.
  1. Go to Integrations, and then Import Configurations.
Figure 20: Import configurations.
  1. Select the line you’re currently editing.
  2. Select one or more import settings to be linked to the import configuration, then select the arrow to move from Available line import settings to Chosen line import settings.
  3. Select Save.
Figure 21: Change import configuration screen.
  1. Refresh the line configurations in the claim system.

Verify the BriteClaims integrations 

Verify the BriteClaims environment is connected to Policies (not policy-mock). 

To set up the integrations, you first need to deselect the policy-mock integration: 

  1. Go to the Claims Django Admin dashboard.
  2. Select Integrations.
  3. On the Integrations administration screen, select External service gateways.
  4. On the Select external service gateway to change screen, select policies:policy-mock (default).
  5. Scroll down to the Is default checkbox and deselect it.
  6. Select Save

Then, set BritePolicies as the default: 

  1. Go to the Claims Django Admin dashboard.
  2. Select Integrations.
  3. On the Integrations administration screen, select External service gateways.
  4. On the Select external service gateway to change screen, select policies:britepolicies (default).
  5. Scroll down to the Is default checkbox and deselect it.
  6. Select Save

The other integrations are usually set up by default. 

Deploy rules

To learn more Rules in BriteClaims, refer to Manage rules for BriteClaims.

Rules for BriteClaims include:

Deploy Docs

Have sample document templates for a specific LOB/Product for:

  • The Attachments section of the claim for forms/letters.
  • Email notifications.

Refer to our BriteDocs configuration documentation for information about deploying and generating new documents.

Permissions

Set up user groups

Refer to Assign BriteClaims access permissions to learn more about setting up user groups for BriteClaims.

Set up user roles

Refer to Establish user roles for BriteClaims to learn more about setting up user roles in BriteClaims.

Access permissions

Permissions is very granular; it completely governs what a user can see and do when in the claims system. The following roles will be available out of the box. Each of these roles is intended to be used in the following manner: 

  • BriteCore Admin: Has full access rights to the entire system to help and aid users with their work.

Note: BriteCore administrators can only be assigned to current BriteCore staff.

  • Claims Finance: This user has read-only access to every claim except for medically sensitive information. In addition, this role can:
    • Approve new vendors.
    • Manually add check numbers to payments.
    • Manually clear payments.
  • BriteCore Agent: BriteCore agents will be able to:
    • Submit FNOLs.
    • Search claims from the home page.
    • Only view claims that are associated with their own policy book of business.
    • Agents won’t be able to enter a claim file—the information provided about a claim should be sufficient for agents not to need to enter the claim.
  • FNOL Artist: This role isn’t configured out of the box. It was intended to be a role that could submit only FNOLs. 
  • Claims Assistant: This role is typically administrative to help other adjusters. For the MVP definition, Claims Assistants will also manage lighter claims and therefore have many of the same privileges as an Adjuster.
  • Claims Adjuster
    • This role can:
      • Submit claims via FNOL.
      • Manage claims through the full lifecycle to close.
      • Manage claim financials.
      • Manage parties.
      • Manage vehicles and damaged properties.
      • Manage detailed injury information.
    • This role can’t:
      • Reopen claims and exposures.
      • Check Refused to Provide checkboxes on the Party Detail screen for SSN, date of birth, and gender.
  • Claims Supervisor: This role can do everything the Claims Adjuster can do. In addition, they can reopen claims and exposures, and also check Refused to Provide checkboxes on the Party Detail screen for SSN, date of birth, and gender.
  • Claims Manager: This role is intended to be limited in scope and for read-only users. However, in MPV, the Claims Manager can do everything the Supervisor can do. The difference between these two roles is their financial authority limits, which aren’t governed by permission rules. 
  • Claims – Read Only All: This role can be used by internal staff, such as underwriters. This role can also be used by auditors.
  • Claims – Read Only – Not Med: This role restricts the viewing of medically sensitive information and SSN/DOB masking.

Functionality available in the claims system globally, but not within the context of a claim file, is just role-based.

Functionality available inside a claim file is based on a user’s role and the claim or exposure status. 

Set up automated tests

The BriteClaims Automated Regression Testpack can be set up to run against the environment.