The Policy Data Model
This chapter introduces the main concepts for policy and claims presentment. It discusses:
The policy data model.
Insured items.
Claims
First notice of loss (FNOL)
Claims submission
Claims management
The Policy Data Model
A policy is an insurance contract that states what is being insured, by whom, and for how much. It contains data that both the policyholder and the insurance company need to understand what the policyholder is insured for, the insured item, what coverages apply, for how long the insurance is effective, and how much the policyholder agrees to pay in premiums. In Policy and Claims Presentment, an insurance policy is a type of financial account.
A financial account represents a holding by the customer of a product that an insurance company provides. The financial account presents information from various legacy systems in a consistent interface. The financial account maps to the product, inheriting the terms and conditions from the product that the customer purchased.
The legacy administration systems create the financial account record and its sub-records as a policy. These accounts are not created in the PeopleSoft Enterprise CRM system. The Product Sales functionality queues up a transaction to the legacy system, which starts the process of creating a new account header record for the policy and its sub-records; the legacy system performs the actual creation of these records, and a message comes back from the legacy system to create the data structure in the PeopleSoft Enterprise CRM system.
Each financial account record represents one policy. If a business contact has two policies, there will be one financial account instance in the database for each. You can attach coverage at several levels in the data model. Coverage can be at either the policy or the covered asset level.
Use the Financial Account pages to view general account information, insurance account details, and policy information. Use the View Policy pages to view covered assets, including coverages, deductibles, limits, and options.
Insured Items
This section provides an overview of insured items and discusses:
Covered assets in property and casualty (P&C).
Policy changes.
Insured items, or covered assets, are related to a policy as the specific thing insured against loss. Policies may be written for many insured items, or for only one. For example, usually, a life policy has one insured item for a person's life while a household policy insures many items. Some companies write a car insurance policy that includes many vehicles, while other companies create a one-to-one policy to insured items. For group policies, there are many insured items.
Insured items can be a person, a place, or a thing. You must collect specific information regarding the item that is to be insured. This data includes the specific attributes that make up the item to avoid confusion regarding what or who is insured, and so you can price the policy accurately. Based on the type of insured item, you may need different types of information.
Each insurance policy has at least one covered asset. In property and casualty (P&C) lines of business, these assets are the items that the policy insures. In life or health policies, the covered asset is the insured person or persons. Covered assets can be of different types, and each can have different attributes. For example, when a car is insured, you must capture the vehicle identification number (VIN), whereas when a person is insured, you must capture the social security number. You can view a given policy's details, such as insured items for P&C, coverage, dollar limits, deductibles, options, and exclusions. The data elements that appear depend on the policy type.
Covered Assets in P&C
For P&C, insured items are assets. These assets may include a car, a boat, a home, a wine collection, and so on. Assets have a value, and the purpose of insuring them is to protect the use or enjoyment of the asset. Covered assets are insured against loss by the policy.
Generally, P&C covered assets or insured items include:
Personal vehicles, including cars, minivans, pickup trucks, and sport utility vehicles.
Commercial vehicles, including trucks, commercial vans, tractors, and combines.
Boats, including sail, motor, and yachts.
Commercial boats, including fishing boats.
Mobile homes.
Personal real estate, including single-family dwellings such as apartments, condominiums, townhouses, houses, duplexes, triplexes, and four-unit or fewer apartments where the owner also lives.
Commercial real estate, including major apartment buildings, office buildings, commercial stores, shopping centers, and undeveloped, raw land.
Personal property, including art work, jewelry, furs, computers, and wine collections.
Commercial property, including equipment, machinery, and aircraft.
Insured items share some common characteristics. Each item:
Is either owned or leased for use and is associated in some way to a business contact as owner, primary user, or lessor.
Is related to insurance policies (a type of financial contract).
Has a dollar value.
Has a location or primary location.
For example, a boat is moored at an address, a car is garaged at an address, a house has an address, an apartment building has an address, equipment is located in a primary location (an address or maybe a site), and personal property is either at one's home or in a safe deposit box, both of which would have an address or location.
Has attributes that are necessary to describe the item for authentication.
For example, the VIN, make, model, type, and year uniquely describe a car. A home's particular location, address, or housing tract number in the county records uniquely authenticates a house (title insurance information). The name of the producer, vineyard, or estate name; country of origin; and the year of vintage authenticate a bottle of wine.
Can have additional attributes to provide more detail to the description.
For example, attributes that may be related to risk, help the insurance company determine ratings or assess risk.
Policy Changes
An insurance policyholder may request a change to the policy. The PeopleSoft Enterprise CRM system captures all of the modification information and transmits it to the legacy system. Modifications to the policy may or may not require a quote, depending on the requested change. For example, changing the beneficiary on a life insurance policy does not require a quote because it does not impact the premium; however, a change in coverage on an automobile policy does require a quote because the premium may change. If a quote is required because of the requested change, the system returns the quote that the legacy system generates. If the user chooses to continue with the new quote, a message is sent to legacy system requesting the modification. The actual modification takes place in the legacy system.
Modification options are product-specific. The owner of an auto insurance policy may want to add a driver to the policy; however, this is not an option for a life insurance policy. Each modification is set up as an action type, and the actions are linked to the product itself. When you link the action to the product, that modification option becomes available to the policyholder. Set up the allowable actions in the Action component (for example, adding a driver is a valid action that can be linked to auto insurance product).
This diagram illustrates the process flow for policy changes, such as user requests, application form and quote information publishing:
Policy change process flow
Claims
In Policy and Claims Presentment, self-service users and customer service representatives can file claims. The first notice of loss initiates the claims process by capturing the event information that eventually triggers a business project. At the end of the business project, a message is sent to the legacy system with all of the captured information.
The legacy system creates, stores, and maintains claim details. Each claim has a header and a detail section. The claim header is stored in the PeopleSoft Enterprise CRM system and is created by an asynchronous message from the legacy system to the PeopleSoft Enterprise CRM system. Claim details can be either fetched from the legacy system on request using synchronous messaging or stored in the PeopleSoft Enterprise CRM system using asynchronous messaging functionality.
The customer service representative can view the FNOL, claim header, and claim details.
This diagram illustrates the process flow for a claim, beginning with the FNOL and ending with the creation of the claim in the CRM system:
Claims process flow
First Notice of Loss
The FNOL initiates the claims process. A policy owner can create a FNOL using a customer care transaction, or a customer service representative can do so through the 360-Degree View.
For the FNOL transaction option to be available, you must associate an action of First Notice of Loss (code FNOL) with the product of the policy for all of the set IDs. If you do not, you cannot launch a claim. You establish association between the policy type and the mechanism application form or branch script in the product action definition. Each action is also set ID driven; for each set ID, you must associate this action code with the product.
A FNOL results in one or more claims and the Claim Header enterprise integration point (EIP) establishes the relationship between the FNOL and claims.
This diagram illustrates the FNOL process, in which the CSR enters the customer information into the system and the customer's policy information and status is displayed and verified:
FNOL process
See Also
Understanding Enterprise Integration Points for Policy and Claims Presentment
Claims Submission
Claims processing takes place in the legacy system; Policy and Claims Presentment gathers claims data through the FNOL process and triggers a business project before data is sent to the legacy system.
This section discusses:
FNOL business projects.
FNOL business project modifications.
FNOL Business Projects
Once a FNOL is created, a business project is instantiated. You may have many procedural tasks to be performed before submitting FNOL for claim processing. The business project RBI_BP_FNOL is targeted for this purpose.
Policy and Claims Presentment supplies the business project as system data. The business project is triggered when the FNOL is created. Use standard Active Analytics Framework to instantiate business projects. The delivered business project contains at least one manual task that must be completed before publishing the FNOL message to claims administration. You can add or modify steps and phases to meet your business needs. However, the delivered step that publishes the message must be the business project's last step.
Note. The FNOL business project is delivered disabled and must be enabled to initiate the FNOL process and publish the message.
See Also
Business Project Modifications
You can add logic to the Active Analytics Framework (AAF) as needed for the implementation:
Define the business project.
Define the AAF to identify the condition on which the business project will be instantiated.
Policy and Claims Presentment delivers a simplified AAF rule to initiate the business project upon save.
Use a PeopleSoft Application Engine program to publish the message.
This program publishes the message with data from the branch script or application form and the policy number to the third-party system.
Claims Management
Once the FNOL data has been submitted to the legacy system and a claim has been processed, the customer service representative can access the claim header and claim details. All claims processing and administration takes place in the legacy system. The claim header is stored in PeopleSoft Enterprise CRM; claim details are either retrieved from the legacy system through the use of synchronous messaging or stored in PeopleSoft Enterprise CRM system using an asynchronous message.