Guidewire ClaimCenter Configuration

Kickstart Lessons
✓ Configuring the ClaimCenter User Interface
Pages and location groups
Pages contain or reference screens
• A page provides a framework that displays ClaimCenter screens and navigation
tools
• Referenced within a location group


✓ What is a location group?

Everything under one tab in the tab bar of the application.


✓ What is in a location group?

A location group contains a set of Location Refs, an actions menu, a tab bar, and
an info bar.


✓ What is a location ref?

• A link, within a Location Group, to a Page or to another Location Group
• Each item located beneath the Actions menu button is a Location Ref

✓ What is an actions menu?
A location group contains a set of location refs, an Actions Menu, a tab bar, and
an info bar.


✓ What is a tab bar?

A location group contains a set of location refs, an actions menu, a Tab Bar, and
an info bar.

✓ What is an info bar?
A location group contains a set of location refs, an actions menu, a tab bar, and
an Into Bar.


Configuring pages and location groups

✓ Page properties
• canEdit: conditions for the page to be editable (defaults to false)
• canVisit: conditions for the page to be available (defaults to true)
• startinEditMode: whether the page is in edit mode when a user navigates to it
(defaults to false)


✓ A page has one or more entry points

An entry point provides navigation reference to a page.
• Includes a signature (declaration of file name and required variables)
• If a PCF contains an entry point, the user can navigate to that location.

✓ Location groups containing other location groups



✓ Location refs
• The body of a location group is a list of location ref widgets
• A location ref can point to:
• A page
• Another location group


✓ Location group properties

• can Visit: conditions for the location group to be available (defaults to true)
• menuActions: name of the menu actions PCF for this location group
• infoBar: name of the info bar PCF for this location group.
• tabBar: name of the tab bar PCF for this location group.


✓ Location ref properties (1 of 2)

location*: designates the entry point for the location referred to, including any
required variables.

✓ Location ref properties (2 of 2)

label: Can include quantities using functions such as getDesktopCounts)


✓ Menu actions element
Contains a list of menu items.
• May be grouped in menu item sets


✓ Info bar element

Contains a series of info bar elements displayed in a horizontal row.
• Each defines a label, value, icon, and visibility


✓ Tab bar element

Contains a series of Tab elements displayed in a horizontal row.
• Each is defined by an action property, generally a "go" action leading to a
Location Group


✓ Forwards
Provide non-visual decision-making logic to route a navigation request base
information only available at request time.


✓ Tabs with dropdowns



Lines of Business
About the ClaimCenter line of business
(LOB) model
✓ What are lines of business?
• Insurers organize policies, coverages, and covered losses in a hierarchy
• This hierarchy impacts:
• How reporting is done
• Which coverages are displayed for a claim associated with a given policy type
• Which user interface elements capture information for a given exposure
• This hierarchy is known as the "line of business" (LOB) model
• In ClaimCenter, it has six levels
• Implemented as a special set of typelists

✓ Loss type
Highest-level category of loss.
• Ties together policies, coverages, and claims that deal with similar losses
• Useful for dynamic generation of User Interface and for reporting


✓ LOB (Line Of Business) code

A business categorization below Loss Type.
• More granular than loss type for reporting purposes
• Not commonly used as a determinant for claims handling


Example of above in CC Application :



✓ Policy type
A product (type of policy) offered by an insurer.
• A single policy type may be associated with multiple LOB Codes


Example of Policy Type in CC base Application



✓ Coverage type
Specification of the type of thing being. indemnified.


✓ Exposure type
Defines the information to gather about an exposure.



✓ Coverage subtype maps coverage type to exposure type

• ClaimCenter uses an additional layer of the Lines of Business to represent the
M:M mapping from Coverage Type to Exposure Type
• This layer is called Coverage Subtype
• Each Coverage Subtype is a single mapping between one coverage type and one
exposure type.
• Enables situations where the same coverage type maps to the same exposure type
under different circumstances


✓ System which determines each level

• Information about Loss Type, LOBCode, Policy Type, Coverage Type, and
CoverageSubtype are typically derived from the Policy Administration System (PAS)
• Information about Exposure Type and CoverageSubtype are unique to ClaimCenter
• Exposure Type is used to streamline gathering
information about a loss and has no PAS equivalent

Configuring the LOB model

✓ Line of Business model is implemented using typelists
• ClaimCenter manages the LOB model through a series of six interconnected
typelists
• Typecodes in each typelist reference typecodes in the typelists above and below
it
• For example, the "PersonalAuto" policy typecode references one parent LOB code
("PersonalAutoLine") and thirty-six child coverage typecodes (such as
"PACollisionCov" and "PAComprehensiveCov")


✓ LOB typelists have children and parents

• Each element in an LOB typelist has a
Children node
• Displays its relationships with elements in the next node down
• Exposure Type has no next node down, so no Children node
• Each element also has a Parents node
• Displays its relationships with elements in the next node up
• Loss Type has no next node up, so no
Parents node


✓ "Other Categories" node

Some Line of Business typelists are associated with "other" typelists
• These may be "incoming" or "outgoing"
• For example, LOBCode, Policy Type, Coverage Type, and CoverageSubtype are all
associated with the SourceSystem typelist
• These "other" typelists are also listed in the Incoming Categories and Outgoing
Categories tabs of the Line of Business typelists

✓ Adding to the line of business model

• When you add an item to the Line of Business model, it is best to start with the
Parent for the new item
• Exception: If you add a Loss Type, there is no Parent
• Failing to link a new item to a parent node will prevent the ClaimCenter server
from starting
• Work downward through the Child nodes until you link to an existing item or there
are no more changes
• Exception: When you add an Exposure Type; there is no Child...
• ...However, every Exposure Type must be associated with one and only one Incident


✓ Common typelists external to the LOB model



✓ Removing typecodes from the line of business model

• You can remove connections in the M:M relationships between typecodes
• Guidewire recommends to not delete typecodes from the model
• Can result in inconsistencies which will prevent the server from starting
• If you are not using a typecode at all, you can retire it
• Can do this even if you have used it in the past


Configuring Claim Intake






✓ Wizard and Wizard Step Structure

• Two levels of configuration:
• Wizard level
• Entry point and navigation to wizard
• Permissions to visit and edit
• Wizard step level
• Screen that a step renders
• Step logic (visibility, editability, next step)
• Step order .
• Independent steps


✓ Wizard Entry Points

• Provide name and signature for navigation widgets to call the location

• Each object expected in the signature of each entry point must be declared on the
variables tab


✓ Navigating to a wizard
Calling the wizard, for example from a tab bar, uses the Wizard's "go" method.
• Syntax:
EntryPointOfLocation.govariablesToPass)


✓ Mode property
• Some PCs have modes
• Different "versions" of the "same" object
• Differentiated by a suffix added to the object name after a dot

• PCF modes are specified by the mode property in the parent object
• Must be a text value that matches one of the suffixes for that object
• Often implemented using a typekey property of the parent's root object.


✓ Shared Section Mode
When a panel set or an input set has modes, any ref that displays it will always
have a Shared Section Mode widget at the top.
• This widget cannot be added manually
• This widget cannot be moved


✓ Order of wizard steps

Determined by order in which they appear in the wizard PCF file.


Writing Gosu rules

Introducing Gosu rules
✓ Gosu rules
• Gosu rules are part of the Guidewire Platform capabilities
• Written in Gosu (an open-source programming language)
• ClaimCenter Gosu rules execute business logic required for claims processing


Rule Sets
• Gosu rules are organized into rule sets
• Rule sets are categorized by the event type that triggers the event-specific
rules
• These are rule set categories
• Rule sets contain Gosu rules:


✓ Rule Sets hierarchy

Gosu Rules can have "child rules"
• Child rules are only processed if their parent rule's Condition evaluates as True
✓ Triggering Events
• The base ClaimCenter configuration includes Gosu Rules triggered by seventeen
distinct types of events
• In this lesson we discuss Exception rules and Preupdate rules
• In later lessons we discuss Assignment rules and Validation rules

✓ Rule structure (1 of 2)
Rules have three parts:
1. An optional "uses" clause, which imports external functionality
2. A condition which evaluates as true or false (continued)

✓ Rule structure (2 of 2)
Rules have three parts:
3. An action which is performed only if the condition evaluates as true
• Condition and action are written in Gosu
• The condition has one parameter:
• The entity on which the rule is called
• The action has two parameters:
• The entity on which the rule is called
• An instance of gw.rules. Action, which is used for functions such as exiting
rules or rulesets in a useful way


Exception rules
Exception rules
Exception rules define actions taken if an object is in a specified state.
• An activity is escalated
• An object either:
• Has had significant activity since the last time the exception rules were run, or
• Has had no significant activity for a long time (defined by the
IdleClaimThresholdDays Parameter)

✓ Activity escalation rules

• Specify what actions to take when an activity is escalated
• Batch process activityes runs every 30 minutes (by default)
• Detects activities where the Escalation Date is in the past, but the Activity has
not yet been escalated
• Escalates these activities
• ClaimCenter then runs escalation rules for the activities that have been
escalated

✓ Claim exception rules

• Specify what actions to take if a claim is
• Recently updated
• Not updated for too long a period
• Batch process claimexception looks for recently updated claims
• Runs daily at (by default) 2 am
• Batch process idleclaimexception looks for claims untouched for (by default) 7
days
• Runs (by default) Sundays at noon
• Both processes add claims to the ClaimException table

✓ Group exception rules

• Look for groups that "need attention" and perform appropriate action on them
• Batch process groupexception runs (by default) every day at 4 am
• Identifies groups that
• Have been changed
• Have not been inspected for a (definable) period of time
• Runs Group Exception rules against these groups

✓ User exception rules

• Look for users that "need attention" and perform appropriate actions on them
• Batch process userexception runs (by default) every day at 3 am
• Identifies users that have been changed
• Runs User Exception rules against these users

Preupdate rules
Preupdate rules
• Fire whenever an object (of certain types) is ready for submission to the
database
• Perform domain logic or processing that must be completed before the object is
committed
• Example: A contact preupdate rule might say:
• When saving a contact (trigger),
• If the contact's address has changed (condition),
• Then change the address on any checks scheduled for this contact (action)


Writing Assignment Rules

Assignment in ClaimCenter
✓ What can be assigned?
• In the base configuration, ClaimCenter assigns:
• Claims
• Exposures
• Matters
• Subrogations
• Service Requests
• Activities
• To:
• Groups
• Users


✓ Queues
• Are places for unassigned activities to "wait" until they are assigned
• Every group in the organization can have one or more associated queues
• Queues can be "shared" by creating the queue on a parent group and making it
visible to all child groups
• Activities assigned to the group, but not to a specific user, can be placed in
the queue
• Group supervisor can assign activities from the queue to subordinates
• Group members can assign activities from the queue to themselves
• Only activities can be placed in a queue

✓ Assignment rule sets

• For each assignable entity there are two rule sets:
• Global<Entity>AssignmentRules
• Run first
• Assign entity to group
• May assign entity to a user
• DefaultGroup<Entity>AssignmentRules
• Run if Global rules do not assign entity to a user
• Assign entity to user


✓ Assignment flow


✓ Default owner assignment



✓ CCAssignable delegate (1 of 2)
• To be assignable, an entity must implement the CCAssignable delegate
• All assignable objects in the base application implement CCAssignable
• Grants access to CurrentAssignment (continued)

✓ CCAssignable delegate (2 of 2)
• Provides most of the methods used for assigning to groups and users
• Has fields that track
• Assignment status
• Current assignee (queue or user and group)
• Previous assignee (queue or user and group)
• User who last assigned the entity
• Time when the entity was last assigned

✓ Assignment in the Ul
• Most assignment is done automatically
• Some screens allow users to manually assign entities
• Allows them to choose a specific user/group and assign object directly without
invoking rules

Configuring assignment rules

✓ Assignment methods
• Assign entities to groups and users using provided methods
• Are provided by CurrentAssignment
• For example,
activity.CurrentAssignment.assignGroup (activity.Claim.AssignedGroup) attempts to
assign an activity to a group.
• Return a Boolean value
• True if assignment was successful
• False if appropriate group/user could not be assigned by this rule

✓ actions.exit) method
• Ends the execution of the rule set
• Should be executed when assignment is successful:
if (assignMethod) {
actions.exit()
}


✓ Commonly-used assignment methods



✓ Dynamic assignment
• Is an advanced topic
• Offers two methods:
•assignGroupDynamically(dynamicGroupAssignmentStrategy)
•assignUserDynamically(dynamicUserAssignmentStrategy)
• The argument of these methods must implement an interface, respectively
• DynamicGroupAssignmentStrategy
• DynamicUserAssignmentStrategy
Writing Claim and Exposure Validation Rules
Validating entities in ClaimCenter
✓ How ClaimCenter validates data
• Two ways:
• Validation by field ensures that data is of valid type, range, and so on
• Validation by rules manages and enforces object maturity
• Both occur when an object is updated


✓ Validation by fields
• Widgets enforce data type
• Validation expressions ensure that data is of correct format, range, and so on
• Warning and error messages appear on the current screen


✓ What can be validated

• Any entity that utilizes the Validatable delegate
• Provides two interfaces, ValidatableInternalMethods and ValidatablePublicMethods
• There are several Validatable entities in the ClaimCenter base configuration


✓ Validation by rules
• Rules prevent values from being saved which are inappropriate to the entity's
current maturity level
• Use "reject" methods to provide warning and error messages to the user
• Warning and error messages appear in a Validation Results worksheet in the lower
part of the screen


✓ ValidationLevel
• Typelist that provides a set of maturity levels for claims and exposures
• The base configuration provides five validation levels
• In order, they are:
• loadsave - entity loaded from an external
FNOL system*
• newloss - entity newly entered by an agent*
• iso - entity ready to send to ISO (the Insurance
Services Office) (fraud prevention)
• external - entity ready to send to external systems
• payment - entity is ready for payment to claimants*
* These three validation levels are "final" and cannot be edited or deleted.

✓ How ClaimCenter uses validation levels

• Validatable entities have an actual or implied ValidationLevel
• Entities are validated whenever a user or process attempts to save them
• Validates minimum data completeness and correctness at each maturity level
• Ensures that entities do not move "backwards" through the process
• Entities are promoted through the Validation Levels
• Prevents save if changes do not meet standards for the current level of
validation

✓ Related objects can trigger validation

• Updating some objects with a foreign key (child) relationship to a Validatable
object can cause the object to be validated
• Caused by a property, triggers Validation, on the array that implements the
parent relationship


✓ Errors and warnings

• Errors prevent an object from being promoted to and saved at a given level, and
display an explanatory message
• Warnings permit promotion and saving, but display a cautionary message


Configuring validation
✓ entity.reject methods
Can be used for both warnings and errors.


✓ entity.reject() method
• Syntax:
• entity.reject(errorLevel, errorMessage,warnLevel, warnMessage)
• Parameters:
• errorLevel = validation level to display an error message
• errorMessage = error message to display
• warLevel = validation level to display a warning message
• warMessage = warning message to display
• Either errorLevel and errorMessage, or warnLevel and warMessage, must be
non-null
• Both pairs can be non-null
• errorLevel should be a higher maturity level than warnLevel

✓ entity.rejectField method
Indicates a problem with a particular field, displays a warning or error message
and highlights the field in the Ul
• Syntax:
entity.rejectField(strRelativeFieldPath,
errorLevel, errorMessage, warnLevel, warnMessage)
New Parameter:
• strRelativeFieldPath = the path from the root object of this rule to the field
failing validation


entity.rejectSubField) method
• Highlights fields on related objects (such as those on an array or a foreign key)
• May require navigation to a page for the related object field (which will be
highlighted)
• If so, a link will be available in the Validation Results worksheet
• Syntax:
entity.rejectSubField(relatedObject, strRelativeFieldPath,errorLevel,
errorMessage,warnLevel, warnMessage)
• New Parameter:
• related Object - the sub-object on which the reject field is found

✓ Validation rules
• Most of the logic is usually in the condition clause
• Selects entities that should be rejected
• You can put additional logic into the action clause


Claim setup rules

Claim Setup
The intake process: automated claim setup


Automated claim setup

• A series of rules designed to:
• Execute any work required for generating the claim, which can be done
automatically
• Example: Generating a list of activities to complete
• Ensure that the claim is ready for adjudication
• Sometimes referred to as SAW:
• Segment
• Assign
• Workplan

Claim setup rules

• Series of rules executed to complete claim setup
• Some are exclusive to setup
• Some are used outside of setup
• For most of these rules, there are both claim-• Purpose
• "Segment" the object (identify high-level strategy for processing object)
• Examples
• In workers' comp claim, if injury severity is
"fatal", segment exposure as "complex"
• In auto claim, if auto damage is only
"broken windshield", segment claim as
"simple - glass"
• Exposure-level rules execute before claim-level ruleslevel and exposure-level
rules
• In most cases, claim-level rules run before exposure-level rules


✓ Exposures in claim setup

• Can exist at the start of setup
• Created during new claim wizard
• Imported with imported claim
• Can be created during setup
• Typically, in Presetup rules
• May not be present at all
• If no exposures exist, exposure-level rules are skipped


✓ Loaded rules
• Executed only for imported claims and exposures
• Purpose
• Execute actions related to import
• Example
• Log information about every claim received via FNOL import




✓ Presetup rules
• Purpose
• Execute actions that must occur at beginning of setup process, particularly
before segmentation
• Examples
• Create "automated" exposures where need for exposure can be inferred
• Example: If loss cause is "collision with vehicle", create vehicle collision
exposure
• Set deductible status to "unpaid"
 ✓ Segmentation rules
• Purpose
• "Segment" the object (identify high-level strategy for processing object)
• Examples
• In workers' comp claim, if injury severity is
"fatal", segment exposure as "complex"
• In auto claim, if auto damage is only "broken windshield", segment claim as
"simple - glass"
• Exposure-level rules execute before claim-level rules

✓ Assignment rules
• Purpose
• Assign claim to group and user
• Assign each exposure to group and user
• Examples
• Assign workers' comp claim with segment
"complex" to national "complex WC" group
• Assign auto claims with segment "simple - auto glass" to auto glass group in same
region as insured's address

✓ Segmentation versus assignment

Segmentation
• Determines the strategy for processing the object
• Is done only for claims and exposures
• Sets a single field on the object to a value from a predefined list
• Is only done once for a given object

✓ Assignment
• Determines the group and owner of the object
• Is done for several object types
• Associates (foreign key) object with group and user
• May occur many times for a given object

✓ Workplan rules
• Purpose
• Create initial claim workplan (list of activities for claim and each exposure)
• Examples
• Create "contact insured" activity
• If claim is Workers' Compensation, create special "claim_acceptance" activity
• If claim is auto, create "scene_inspection" activity
• For each activity created: presetup, assignment, and postsetup rules are executed

✓ Postsetup rules
• Purpose
• Execute actions that must be done at the end of claim setup
• Examples
• If a Fraud Review activity was created, set the Claim SIU (Special Investigations
Unit)
Status field to "Under Investigation"
• If a matter is created, set the Claim's Litigation Status field to "In
litigation"

✓ Initial reserve rules

• Purpose
• Set initial reserves for existing exposures
• Example
• For low-complexity collision exposures, always set reserve to $1000
• No claim-level initial reserve rules - exposure only

✓ Preupdate and validation rules

• Executed for all objects (including claims and
exposures, whenever the object is created or changed
Preupdate rules
• Make changes or additions to object before validating and saving
• Validation rules
• Execute only if the object is Validatable
• Reject object if data is not correct and/or complete

✓ Preupdate and validation rule examples

• Preupdate example: Lo
• Create SIU review activity if changes to claim cause it to cross fraud detection
threshold
• Validation example:
• Reject creation of claim if the loss date is in the future

✓ Claim setup rules review

• Unless otherwise noted:
• Rules at both claim level and exposure level
• Claim-level rules run first
• Some are Unique to setup
• Some are Used outside setup
• This lesson discusses:
• Presetup
• Segmentation


Presetup rules
✓ Presetup rules
• Five entities have presetup rule sets
• Executed whenever object of that type is created
• During claim setup:
• Claim presetup rules are run
• Exposure and activity presetup are run for each exposure and activity created
during setup


Segmentation rules



Exposure and activity setup
✓ Exposure and activity setup
• Claim setup only occurs at the time a claim is created
• Only once at the start of the claims process
• Exposure and Activity setup occurs upon Exposure and Activity creation
• May occur multiple times during the claims process

✓ Exposure setup rules

• After claim setup, when an exposure is created, this series of rules is executed
• All are exposure-level (except the activity rules)

✓ Activity setup rules

• After claim setup, when an activity is created, this series of rules is executed
• All are activity-level
• Note that activities are not segmented, have no workplan, and no reserves

Configuring Claim Contacts

Contacts and roles
Contacts: review
A contact is any person, company, or place related to a claim.


✓ Roles
• Every contact associated with a claim has one or more roles that identify its
relationship to the claim
• Examples: Doctor, Witness, Claimant, Adjuster, Judge, Hospital, Repair Shop...
• Contacts on multiple claims may have different roles on each claim
• The contact's role is specific to the claim




Configuring contacts and roles

✓ Configuring contact roles
The ContactRole typelist lists all contact roles.


✓ Configuring contact role categories

The ContactRoleCategory typelist enables filtering on the contacts list view.


✓ Categorizing roles
Each typecode in the ContactRoleCategory typelist is associated with one or more
typecode in the ContactRole (category) typelist.
• These determine which roles appear in which filter in the Contacts screen

✓ Configuring contact role type constraints

Contact role constraints are configured in entityroleconstraints-config.xml.


✓ Configuring entity role constraints

Entity role constraints are also, configured in entityroleconstraints-config.xml.

Displaying claim contacts in the Ul



✓ Types of claim contact widget

Two types:
• Claim Contact Cell - used in list views
• Claim Contact Input - used in detail views


Essentials Lessons
Configuring ClaimCenter Financials
Part 1 Transactions
ClaimCenter financials model
✓ Objects that implement ClaimCenter financials
Exposures track payment from coverage to claimant.
• A reserve line is money set aside for exposure payments
• Reserve transactions typically add money to it
• Payment transactions move money to checks
• Checks transfer money from carrier to payee
• "Check" is a ClaimCenter concept that may include electronic fund transfers as
well as physical checks


✓ Transactions
Transactions modify amount of money in reserve line.
• Four types of transactions
• Reserve transaction - modifies the amount of money available for the reserve line
• Payment transaction - moves money from a reserve line to a payment to a claimant
or other party
• Recovery reserve transaction - denotes money which the carrier expects to get
from subrogation or salvage
• Recovery transaction - denotes money which has been collected from subrogation or
salvage

✓ Transaction model: Transaction and TransactionSet

• The transaction model is heavily subtyped
• The top level entities are TransactionSet and Transaction


✓ Transaction model: Reserve and ReserveSet

Are subtypes of Transaction and TransactionSet.


✓ Transaction model: Payment and CheckSet

Are subtypes of Transaction and TransactionSet.


✓ Controlling financial behavior

Certain financial behaviors are controlled by parameters in config.xml.


✓ Some financial behaviors controlled by config.xml

• Multiple line items {are | are not) allowed in a transaction.
• Multiple payments {are | are not}; allowed per check.
• Authority limits {are | are not}; checked automatically
• Users {cannot | can} submit payments that exceed available reserves {. | up to
the PaymentsExceedReserves authority limit.}
• Payments above {500} are logged.
• When final payment is made, exposure {is | is not; automatically closed.
• When final payment closed on the last open exposure, claim {is | is not}
automatically closed.
Default values in green bold.
Other possible values in red italics

Transaction pre-update rules

✓ Transaction rules
Eight rule set categories are triggered when a transaction is created ("transaction
event").
• Which rules get executed and order of execution varies based on the type of
transaction and type of activity (creation, modification, approval)


✓ Transaction pre-update rules

Perform required tasks prior to
committing a transaction set or check set to the database.

✓ Claim financial measures

• Various measures used by insurers to describe and act on a claim
• The base application measures:
Total Reserves = all approved reserves
Open Reserves = Total Reserves - Past Payments
Remaining Reserves = Open Reserves - Future Payments
Available Reserves = Remaining Reserves - Pending Approval Payments
Total Incurred Gross = Open Reserves + Past Payments
Net Total Incurred = Total Incurred Gross- Recoveries

✓ Financial calculations
• Transaction rules need to reference financial measures
• Accomplished through financial calculations library methods
• Implemented using FinancialsCalculations methods
• Each method returns an object which can be used to retrieve financial measures -
essentially, a specialized calculator

✓ FinancialCalculations methods
Commonly used syntax:
.withClaim(Claim).Amount
withExposure(Exposure).Amount
-withCostType(CostType).Amount
-withCostCategory(CostCategory).
Amount