2.5.121 Core Enhancements

Note: These release notes include all features available for this version of the system at the time this documentation was published. For information on new features and fixes patched back to this version after publication, please see the Release Notes_Addendum file.

New Company Lookup Data Source

A new Company Lookup has been introduced that specifically allows users to display company data within the claims module. A Data Source configuration of type Web Service can be created for each Company Type currently supported by the system, which includes:

  • Additional
  • Assured
  • Distributor
  • Insurer
  • Licensee

In order to successfully use this data source, each configuration must include a Filter specifying the Company Type to be queried. The Company Type can also be optionally displayed in the workflow. The lookup returns all active companies configured within the Licensee site that meet the filter criteria and to which the user has administrative access.

New Algorithm for Fuzzy Match Search Functions

The following two functions are supported to locate Approximate String Matches, commonly referred to as Fuzzy Matches, in Cross-Policy Data Configuration data sets.

  • $CrossPolicyFuzzyMatch
  • $CrossPolicyFuzzyMatchList

Previously, the system only supported the Q-gram Index search algorithm. While this remains the default search algorithm, the option to configure Soundex encoding to replace the Q-gram Index algorithm is now supported.

Soundex is a phonetic encoding method that typically increases system performance but exclusively supports Latin languages. Modifications to the Soundex encoding method have also been introduced to support numeric search values within the Bridge Specialty Suite.

When using Soundex, the syntax of the fuzzy match functions remains unchanged, including the tolerance value established in existing configurations. The Soundex results will, however, differ from those previously returned by the Q-gram Index.

Depending on the strength of the tolerance value configured within the function(s), the system returns the top 10 results from the corresponding quadrant: 0 - 0.24 match, 25 - 0.49 match, 50 - 0.74 match, and 1.00 for an exact match. Note that the tolerance value must be a decimal value, and not an integer value.

Note: Precise match percentages are not supported by the Soundex algorithm. Rather, results are automatically assigned the highest value applicable for the quadrant from which they were returned.

Example: If a particular result is a .68 match to the search criteria, the reported match percentage will be 0.74 because the result was returned from the 50 - 0.74 quadrant.

To support the Soundex option, the UseQGramFuzzySearch web site configuration key has been added, with the default value of "true." To use Soundex, change the value for this key to "false." The system will then use Soundex as the default search algorithm.

This has been merged back to 2.5.115.

Custom Workflow Events in the Claims Module

The ability to configure Custom Events in the claims module is now supported. This functionality enables the system to accommodate custom processing events outside of the core activities supported by the system by default.

Once a Custom Event is configured, a customized Action Button displays in the Screen Button Bar in the claims workflow. The availability of the Custom Event button is defined by user Security Role, claim Status/Sub-Status, as well as the optional evaluation of a Trigger. When a user executes the Custom Event by clicking the button, the claim automatically transitions into the defined Target Status.

To support this functionality, the Custom Events menu item has been added to the Workflow Container Menu. Clicking Custom Events opens the Event Configurations management page, through which events can be created, modified, deactivated, or reactivated as necessary.

As part of this enhancement, the Claim Sub-Status configuration option under the claims General Settings Menu has been removed. This configuration has been replaced by two Option Lists.

  1. The three core claim statuses (Notice of Intent, Open, and Closed) are now supported by the ClaimsStatusOption List maintained through the OWClaimCommon Standard Container. This is a core Option List and cannot be edited by the user. The contents of the OWClaimsCommon Standard Container are automatically shared down to all custom Workflow Containers that have Claims assigned as their Functional Area.
  2. All active custom Sub-Statuses that were previously configured through the General Settings Menu have been migrated to a customizable Option List in the custom Claims Workflow. Claim Sub-Statuses can be added, modified, and deleted as with any other custom Option List. Following each modification, the workflow must be published.

Note: Though accessible from all Workflow Containers, the Custom Events functionality is currently only supported for Workflow Containers that have Claims assigned as their Functional Area.

This has been merged back to 2.5.118.

Restrict Access to Banking Information in the Claims Module

A new security right titled ViewClaimPartyPayeeInformation has been introduced to control access to the banking information contained within the Claim Parties window. Now, the Payee Information panel and the Bank Information panels are only visible to users who have been assigned the ViewClaimPartyPayeeInformation security right. The ability to navigate to the Party Information, Payee Information, and Bank Information tabs in the Payment Management for claim payments in Paid status is similarly controlled by the ViewClaimPartyPayeeInformation security right, which is assigned to the Adjuster and Adjuster Supervisor security roles by default.

As part of this enhancement, additional work was completed to hide all Party General Purpose Fields within the Company Information, Payee Information, and Bank Information panels in the Claim Parties window when a corresponding custom label has not been assigned. The purpose of this enhancement is to clear the panels from unnecessary fields that are not being used in the current configuration.

Attach Multiple Claim Parties of the Same Party Role

Previously, only a single Claim Party of each Party Role could be attached to a single claim. There are, however, valid business scenarios where multiple parties of the same Party Role need to be attached. The system now addresses this need.

A new core grid has been introduced to the OWClaimCommon Standard Container to hold the data relevant to each party company. This grid is contained within the newly introduced Claim Parties screen. Each field in the Claim Party grid is furthermore accessible through newly introduced placeholders, making this data available for use in Calculated Fields, Document Templates and Email Templates typically configured to summarize individual claim records.

This has been patched back to 2.5.118.

Deleting a Claim

The option to delete a claim in the claims module is now supported. This action is accessible through the Delete Claim option that has been added to the Claim Actions widget. Note that a claim can only be successfully deleted if it meets the following criteria.

  • The claim does not have any payments associated with it, or existing payments have been deleted.
  • The claim is not associated to a Reserve amount that is greater than zero.

When deleting a claim, any links to Associated Claims are deleted. With the exception of Notes & Tasks, all other resources associated to a deleted claim (such as Attachments, Documents, and E-mails) are also deleted. Even after a claim has been deleted, associated Notes & Tasks may still be accessible through downstream systems such as Client Center and/or SmartView.

Note: Access to the Delete Claim option in the Claim Actions widget is controlled by the DeleteClaim security right. This security right is assigned to the Adjuster and Adjuster Supervisor roles by default.

This has been merged back to 2.5.118.

Custom Note/Task Categories in the Claims Module

The ability to create custom Note/Task Categories in the claims module is now supported. This matches the existing functionality available in the policy module.

To create Categories for Notes/Tasks in the claims module, navigate to the custom Workflow Container that has Claims designated as the Functional Area and create a new Option List with the following settings.

  • Name: Claims Note Categories
  • Type: Static
  • Resource Type: NoteType

Categories can be added, modified, and deleted as with any other custom Option List. Following each modification, the workflow must be published.

The Note / Task Categories are persisted in Client Center and SmartView.

Custom Sequence Numbering in the Claims Module

The ability to create and manage custom Sequence Numbers in the claims module is now supported. This feature creates unique and sequential Incident Numbers for each First Notice of Loss (FNOL). These numbers can be accessed within the claims submission form using the GetAndIncrementSequenceNumber function. Every time the function retrieves one of these numbers, it returns its current value, and then increments it by 1. To access this feature, navigate to the Product Design dropdown menu and select Sequence Numbers.

Note: The following Security Rights manage access to the Sequence Number page and related actions.

  • ViewProduct
  • CreateProduct
  • EditProduct
  • DeleteProduct

Separate Deductible Invoicing

Previously, the billing module only supported a single billing cycle for all billable charges. Now, the system supports separate invoicing for deductible charges. This provides greater flexibility for the collection of deductible payments in the event of an insured loss.

To support this enhancement, the Deductible Billing Settings panel has been introduced to the General Settings - Billing page for Billing Entities. This panel contains a single field of control type Textbox (Integer) labeled Invoice Due (in days), through which the user can assign how many days prior to the deductible charge(s) being due that the deductible invoice should be issued to the client. If this field is empty, the system considers the value to be set at zero. Note that a single deductible invoice per claim is generated, regardless of the Separate Invoices by setting configured for the Bill to Party. All other charge types, including Billing Adjustments, Claim Payments, and Premium charges continue to follow the settings configured in the Billing Settings panel for the Bill to Party.

To help manage deductible invoicing, the Billing Documents page in the Billing Entities Menu has also been enhanced with the addition of Deductible as an option for the Invoice Document Content setting. Users can subsequently create a Billing Document unique to deductible invoicing. A number of placeholders have also been introduced to capture information deriving from deductible invoicing and payments in documents and e-mails.

Associate Bill to Parties with Multiple Billing Entities

Each Billing Entity has a single managing Licensee Office, as well as one or more Bill to Parties.

There are business scenarios that require more than one Licensee Office to access the same Bill to Party records. Prior to this enhancement, this action was blocked by the system. The ability for an individual Bill to Party to be shared between multiple Billing Entities is now permitted.

Note: Bill to Parties of type Assured have the ability to access their own Bill to Party page in the billing module. However, once an individual Bill to Party has been assigned under multiple Billing Entities this functionality is no longer supported.

Insurity Common Security (ICS) Implemented for Bridge Specialty Suite

The Insurity Common Security (ICS) component has been introduced to the Bridge Specialty Suite. ICS is a common user management component that will work with all of Insurity's applications. This common component allows for users from one system to access another one of Insurity's applications. This eliminates the need to have multiple system login IDs. Once logged into the system using a valid user login and password combination, users can navigate multiple systems. Note that this common component is being implemented in phases and at this time, is only available in the Bridge Specialty Suite.

While administrative users working in the Bridge Specialty Suite will still be able to manage Security Roles and Security Rights in the system, please note that all user Security Roles and Security Rights that were previously stored in the Bridge Specialty Suite database have been migrated to the ICS database.

ICS utilizes the concept of an Administrative Group rather than Security Roles. Any users who previously held one of the following Security Rights will have this group added to their User Account.

  • ConfigureSingleSignOnUser
  • ViewAssignableSecurityRoles
  • EditAssignableSecurityRoles
  • ViewUsersAndRolesReport
  • ConfigureUserAuthentication
  • ViewUser
  • CreateUser
  • EditUser
  • DeleteUser
  • ViewRole
  • CreateRole
  • EditRole
  • DeleteRole
  • ViewMockup
  • ViewAssured
  • EditAssured
  • CreateAssured
  • DeleteAssured
  • ViewAssuredIndividual
  • EditAssuredIndividual
  • CreateAssuredIndividual
  • DeleteAssuredIndividual

Users who are assigned a Security Role containing one of the above rights automatically have the ICS Administrative Group added to their account in the ICS database. The action of adding one of these rights to an existing Security Role that did not previously contain a qualifying Security Right does not, however, automatically grant the Administrative Group to the user. In order to mitigate this, the Security Role must first be removed from the user, updated, and then re-added to the user's account for the Administrative Group to take effect.

It is important to note that the Assignable Roles feature on the User Information page has been removed with the introduction of ICS. If the previous functionality is required, users will have to create a secondary Administrative account for the specified user.

Policy Term Contractions

During the course of a policy term, a significant change in circumstance can occur that requires the policy to be shortened, or "contracted", prior to the Valid Until date. Such a change may be required, for example, from a merger or acquisition, or a significant change in the Terms and Conditions. This type of Endorsement transaction is commonly referred to as a Policy Term Contraction.

Behavior

When the Allow Endorsement Contractions feature is enabled for a Master Cover/Product, users with the newly introduced CreateEndorsementContraction security right will have the Contract link visible in the Actions widget.

When a Policy Term Contraction is initiated, the system defaults the Contraction Date to the current system date. If the option to Prompt for Endorsement Effective Date is checked, upon clicking Contract, the user is prompted to enter the Contraction Date manually in the field provided in the modal. This will override the default Contraction Date. If the Policy Term Contraction is confirmed, the transaction transitions into Incomplete status.

Policy Term Contractions are categorized as Endorsements, with a sub-type of Contraction, therefore as with standard Endorsement transactions, upon Calculate Quote for a Policy Term Contraction the system applies the Limits, Deductibles, and Insuring Conditions configured in the Master Cover. Additionally, all Validation Rules typically evaluated under the Calculate Quote action are executed and, if all pass, the transaction transitions into Quoted status.

Unlike standard Endorsements, however, the Premium, Commission, and Tax refund amounts are calculated similar to Cancellation transactions that follow the default prorating refund method. The system identifies all applicable Coverage Types valid as of the Contraction Date and pro-rates the appropriate refund amounts as of the Contraction Date.

Users with the EditPremium security right can override the Premium and Tax refund amounts for Policy Term Contractions through the Quote Summary window. The Commission amounts can be overridden by editing them in the Distributor Commission grid in the OWPolicy Common container. Note that override values will be lost if any change is made to the transaction that causes it to transition into Incomplete status or if the user re-quotes the transaction.

Once the Policy Term Contraction is Bound, if the policy term is set to inclusive, the current term is valid until one day prior to the Contraction Date. If applicable, the Renewal transaction is effective as of the Contraction Date. If the policy term is set to exclusive, the current policy term is valid until the Contraction Date, and if applicable, the Renewal transaction date is effective as of the Contraction Date.

Configuration

To enable Policy Term Contractions, navigate to the Policy Settings page in the Master Cover and check the Allow Endorsement Contractions checkbox in the Endorsement and Adjustment Settings panel. A second field, Set Endorsement Contraction Date to, is displayed with two options: Default, which defaults the Contraction Date to the current system date, and Field Value, through which a field can be selected to set the Contraction Date. Additionally, the following settings on the Endorsement and Adjustment Settings panel have been updated to account for Endorsement Contractions; Allow Out of Sequence Endorsements (OOSE), Restrict Endorsements to Last Policy Transaction, and Endorsement Source Transaction.

An additional setting, Prompt for Endorsement Effective Date, permits the user to set the default Contraction Date through the UI upon creation of the contraction. When this setting is checked in the Endorsement and Adjustment Settings panel, and upon clicking the Contract link in the Actions Widget, a modal window will prompt the user to enter the Contraction Date before creating the Endorsement Contraction.

To assist users in managing Policy Term Contractions the IsEndorsementContraction() function has been introduced. The IsEndorsementContraction() function determines whether the transaction is an Endorsement of type Contraction. This can be used to conditionally drive system behaviors. Examples of such behaviors include, but are not limited to, making fields or panels read-only or generating specific Document or E-mail configurations for Policy Term Contraction transactions.

Notes:  

A Policy Term Contraction cannot be performed if there is a future policy term. Exceptions to this rule are policy terms in Declined or Void status. If there is a future policy term in Lost status, it must be deleted.

If there is a Renewal in a subsequent term that is in progress, the system will block the Endorsement Contraction from binding.

In the event that a policy term is contracted, the system logic for subsequent Replacement renewal terms has been updated to reflect the updated Effective Date immediately following the Valid Until Date of the contracted policy term.

Neither the Client nor the Distributor can be changed for a Policy Term Contraction.

Once Contracted, Out of Sequence changes are blocked by the system for the Policy Term Contraction.

If the Program Policies feature has been enabled for the governing Master Cover, the system verifies that all linked Parent and Child policy terms continue to overlap by a minimum of one day. If this verification returns as 'false' and the Policy Term Contraction would invalidate the Parent / Child link, an error message is returned and the user is prevented from completing the Policy Term Contraction.

  • For details on the master cover settings, see the Policy Settings section.
  • For details on the policy contraction action, see the Actions Widget section.