U.S. patent application number 13/118266 was filed with the patent office on 2012-02-02 for system and method of administering, tracking and managing of claims processing.
Invention is credited to Anthony Aquila, Patrick Cole, Frederick C. Fisher, David Griffin, Christian Hassold, Thomas Lyons, Mike Marsh, Carlos Portal, Edward L. Schrenk.
Application Number | 20120029946 13/118266 |
Document ID | / |
Family ID | 22716398 |
Filed Date | 2012-02-02 |
United States Patent
Application |
20120029946 |
Kind Code |
A1 |
Aquila; Anthony ; et
al. |
February 2, 2012 |
SYSTEM AND METHOD OF ADMINISTERING, TRACKING AND MANAGING OF CLAIMS
PROCESSING
Abstract
A system and method of administering, tracking and managing of
claims processing.
Inventors: |
Aquila; Anthony; (US)
; Schrenk; Edward L.; (US) ; Cole; Patrick;
(US) ; Lyons; Thomas; (US) ; Griffin;
David; (US) ; Marsh; Mike; (US) ;
Hassold; Christian; (US) ; Fisher; Frederick C.;
(US) ; Portal; Carlos; (US) |
Family ID: |
22716398 |
Appl. No.: |
13/118266 |
Filed: |
May 27, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09825604 |
Apr 3, 2001 |
7953615 |
|
|
13118266 |
|
|
|
|
60194128 |
Apr 3, 2000 |
|
|
|
Current U.S.
Class: |
705/4 |
Current CPC
Class: |
G06Q 10/10 20130101;
G06Q 40/08 20130101; G06Q 40/02 20130101 |
Class at
Publication: |
705/4 |
International
Class: |
G06Q 40/00 20060101
G06Q040/00 |
Claims
1. A computer-implemented method of collecting customer
satisfaction information and generating a customer satisfaction
index score, the method comprising: providing a customer with a
customer satisfaction survey regarding a service provider that has
provided service to the customer, the survey containing a plurality
of questions, the survey being stored on a computer system;
receiving answers to the plurality of questions; generating a
customer satisfaction index score for the service provider
responsive to the received answers; and transmitting the customer
satisfaction index score to a system that assigns an insurance
claim to an assignee, the system using the customer satisfaction
index score to determine a potential assignee to whom to assign the
insurance claim.
2. The method of claim 1, further comprising notifying one of the
service provider and an insurance carrier of the receipt of
customer satisfaction information regarding the service provider
that will negatively affect the service provider's customer
satisfaction index score.
3. A computer-implemented method of collecting customer
satisfaction information and generating a composite customer
satisfaction index score, the method comprising: collecting
customer satisfaction information regarding a service provider from
a first user according to the method of claim 1; collecting
additional customer satisfaction information regarding the service
provider from a second user according to the method of claim 1; and
generating a composite customer satisfaction index score for the
service provider based on the customer satisfaction information
from the first user and the customer satisfaction information from
the second user.
Description
I. REFERENCE TO RELATED APPLICATION
[0001] This application is a divisional of and claims the benefit
of U.S. patent application Ser. No. 09/825,604, filed Apr. 3, 2001,
now U.S. Pat. No. 7,953,615, which claims priority under 35 U.S.C.
.sctn.119 (e) to U.S. Provisional Application Ser. No. 60/194,128,
filed Apr. 3, 2000, each of which is incorporated herein by
reference in their respective entirety.
II. BACKGROUND
[0002] 1. Field of the Invention
[0003] The present invention relates to insurance claim processing
systems in general, and more particularly to administering,
tracking and managing insurance claim processing systems.
[0004] 2. Description of the Background Art
[0005] Processing, tracking and releasing funds for claims made
upon insurance policies and similar risk shifting mechanisms has
traditionally been a time intensive and resource intensive process.
Traditionally, there are six major steps involved in the processing
of claims: initial claims processing, loss appraisal, claims
adjusting, satisfying the claim, settlement and payment, and
management and analysis.
[0006] Initial claims processing includes receiving initial claim
data associated with a newly asserted claim, initial assessment of
damages and tasks required to fulfill the claim, and assignment of
those tasks to appropriate service providers.
[0007] The claims process starts with the notification by the
insured or claimant that an accident has occurred. Currently, this
notification is typically completed by phone to the carrier's first
report unit or to an agent. The carrier then verifies policy
coverage, creates a claim file and assigns the claim to an adjuster
and an appraisal resource or directly to a service provider.
Generally, the client must exchange several phone calls with the
various commercial participants to schedule a damage estimate,
select a repair facility and make car rental arrangements, if
applicable. In addition, these processes are paper intensive
because legacy claims systems do not support imaging and relevant
documents such as estimates, photos, police reports and tow bills
that arrive regularly by fax and mail throughout the life of the
claim file.
[0008] Automated initial claim capture systems are known. However,
while relieving some of the burden on an insurance carrier's
resources, traditional automated initial claim capture systems are
not flexible. Claimants are forced through standardized questions
in standardized formats that often do not fit well with their
needs. Also, these systems are not configurable to use by a
commercial participant or a claimant, nor do they are unable to
fully facilitate the capture of supplemental information in
addition to initial claim data and can thus be inaccurate.
Moreover, initial claim capture systems usually connect directly to
an insurance company's proprietary software or interface. An agent
who deals with multiple insurance companies may need multiple
systems or pieces of software.
[0009] Initial claim processing also involves determining the
importance of a given claim, in what order it should be addressed,
what tasks need to be fulfilled to address the claims and what
specific parties those tasks should be assigned to. Traditionally,
a claims adjuster, who must fulfill each of these steps, handles
this process. The process is labor intensive, requires a fair
amount of familiarity with the situations similar to the one at
hand, and can be subjective, the combination of which results in
expense to the insurance company, potential error and
inconsistencies.
[0010] Loss appraisal involves loss assessment and related
activities. In most automobile insurance claims, the damage
assessment is developed using computerized damage estimating
software. However, conventional computerized estimating platforms
utilize incompatible proprietary data and communications formats.
Most carriers lack the ability to electronically integrate data
from multiple systems, and therefore encourage or require their
affiliated repair facilities members to use a specific estimating
platform so that the data generated can be analyzed and compared to
the results of other estimating resources used by an insurance
carrier. In order to communicate with different carriers, repair
facilities must often purchase multiple estimating and
photo-imaging systems, creating redundant costs and expenses and
lost time from having to re-enter data into different proprietary
systems.
[0011] Claims adjusting involves determining the fair claim
settlement amount. Claims adjusting includes investigating the
facts related to the claim and negotiating the cost of services to
fulfill the claim with other commercial participants and/or
settlement negotiations with the client. Traditionally, this
process is handled by a claim adjuster, and requires data from a
wide and disparate variety of internal and external sources,
including computerized and paper-based systems. This problem causes
frequent delays as key participants cannot be reached and as
required documents are mailed or sent by expensive overnight
delivery services.
[0012] Satisfying the claim involves completing the services that
are required to recompense the loss. The traditional process
involves a variety of delays while service providers await approval
of adjusters for initial and supplemental costs. During the typical
process, the consumer or suppliers to the service provider contacts
the carrier or the service provider numerous times by phone. These
calls disrupt the normal flow of work for the recipients and add
costs and delays to the process. In addition, administrative
overhead for repair facilities is high as they must rely on phone
and fax to communicate with insurers, suppliers, and consumers.
[0013] Settlement and payment involves delivery of the repaired
vehicle in the case of repairable damage and payments either
directly to the insured or to service providers. In the traditional
process, carriers are required to produce multiple checks to a
variety of service providers based on manual invoicing methods.
Service providers may have to provide their services to the
consumer before receiving payment for the work from the carriers
and must wait extended periods for final payment. The movement,
tracking of numerous payments, often in the form of checks, and the
delays commonly involved, are additional problems faced in claims
processing.
[0014] Management and analysis involves management oversight of the
process by commercial participants. Analysis of settlement cycle
times, repair costs, revenue, margins, and consumer satisfaction
are just a few examples of the business metrics utilized by the
Commercial Participants. Gathering and processing of sufficient
claim related data such as customer surveys traditionally requires
a great amount of resources in the form of time and staff to track
down answers, data, and analyze what is gathered. Data gathering
traditionally yields a small amount of data making analysis less
accurate, and any analysis that is conducted is usually on aging or
outdated information.
[0015] As each of these processes presents difficulties,
complexities to systems and processes which seek to address them,
the combination of these processes, each of which needs to be
addressed in claims processing, provides even deeper inefficiencies
that have yet to be adequately addressed. Traditional claim
management systems are each focused on a single or a few of these
steps involved in processing claims, and often require the
redundant re-collection, re-entry or re-formatting of collected
information and data to cater to the specific needs of each of the
processes involved. For a paper based claim file management system,
information is limited to the number of physical copies of the
material available, which are static and costly to move and store.
In addition, bottlenecks are created when files are kept, for
example by a claims adjuster who cannot be reached. For electronic
claim management systems, proprietary systems, formats and
communication methods similarly require redundant effort in the
need to re-enter or reformat data to cater to each system involved
in the process. Traditionally, there does not exist a centralized
claim processing or storage system. Traditionally, claims
processing is people intensive, requiring human involvement for
phone calls, data collection and data entry, often requiring
several days, and considerable inconvenience to the client while
adding significantly to the insurance carrier's costs of adjusting
the losses under claims.
[0016] Accordingly, there is a need for an automated system for
administering, tracking and managing claims processing.
III. SUMMARY OF THE INVENTION
[0017] The present invention provides a centralized system and
methods of administering, tracking and managing claims processing.
More particularly, the system and method processes, tracks and
releases funds for claims made upon insurance policies and similar
risk shifting mechanisms including but not limited to self
insurance, indemnity provisions and surety and performance bonds.
The invention is composed of sub-systems that can operate on a
standalone basis or in conjunction with one or more sub-systems of
the invention. The sub-systems include:
[0018] The user interface and claim management sub-system
(Deskview) allows a user to access, view, add, and edit claim data.
Deskview also serves as a portal point to other sub-systems.
[0019] The first notice of loss sub-system (FNOL) captures initial
claim data directly from a consumer using client software. In
another embodiment, FNOL captures initial claim data through a
commercial participant. FNOL presents the user, the consumer of the
commercial participant, with tailored questions, where the
presentation format varies depending on the type of user. Also
questions subsequent to certain gateway questions presented to the
user vary according to the user's answers to the gateway questions.
The claim data captured can be transmitted to and stored in the
eclaim database, or insurance carrier system.
[0020] The triage sub-system receives claim data and determines the
severity and priority of the claim according to business rules
established by an insurance carrier. Next, the triage sub-system
determines the type or type(s) of assignees to assign a claim to
according to business rules established by an insurance
carrier.
[0021] The assignment sub-system receives the claim from the triage
sub-system, identifies the assignee most qualified for the
assignment according to insurance carrier business rules, makes the
assignment, records that the assignment has been made, and notifies
the assignee.
[0022] The vendor connection and assignment management system
(Connection) does not reside on the application layer, but is
stored and operates on the vendor's I/O device 1, and serves as a
communication and management system for vendors, particularly
service providers such as repair facilities and independent
adjusters. In one embodiment, Connection resides and operates on
internal system.
[0023] The audit sub-system applies insurance carrier specific
business rules, government regulations, and comprehensive trending
analysis to detect and rectify any inconsistencies and irregular
processing of claims, by auditing internal processes or user or
service providers submitted data.
[0024] The automated payment system (APS) automates the process of
fulfilling payments required to fulfill an asserted claim.
[0025] The customer satisfaction index collection sub-system (CSI
sub-system) automates the gathering of satisfaction data from a
policyholder or consumer to generate a Customer Satisfaction Index
(CSI) for the service providers.
[0026] The reporting sub-system summarizes and formats data stored
eclaim file or the insurance carrier system based on a number of
criteria to generate various reports.
IV. BRIEF DESCRIPTION OF THE DRAWINGS
[0027] FIG. 1 is a block diagram of physical communication
components and system architecture of a system of administering,
tracking and managing insurance claim processing according to the
invention;
[0028] FIG. 2 is a block diagram of logical components that
components of a system of administering, tracking and managing
insurance claim processing;
[0029] FIG. 3 is a block diagram of a data flow relationship
between participants and sub-systems of a system of administering,
tracking and managing insurance claim processing;
[0030] FIG. 4 is a flow diagram of a process of administering,
tracking and managing insurance claim processing;
[0031] FIG. 5A is a flow diagram of the process of capturing
initial claim data;
[0032] FIG. 5B a flow diagram of a commercial participant's process
of capturing initial claim data;
[0033] FIG. 6 is a table containing examples of the question groups
and particular question fields a user may be asked to complete in a
process of capturing initial claim data;
[0034] FIG. 7A is a screenshot of a gateway question presented to a
user in an initial claim capture system;
[0035] FIG. 7B is a screenshot of questions presented subsequent
and in response to an answer to a gateway question in an initial
claim capture system;
[0036] FIG. 8 is a screenshot of an interactive user interface,
which allows a user to represent a damaged vehicle through varying
the degree and location of damage to a representative vehicle
graphic;
[0037] FIG. 9A is a business object model for a first notice of
loss sub-system;
[0038] FIG. 9B are the object attributes of the objects of the
business object model of FIG. 9A;
[0039] FIG. 10 is a block diagram of the types of assignees the
triage and assignment sub-systems can make assignments to;
[0040] FIG. 11 is a flow diagram of a process of triage and
assignment in accordance with the present invention;
[0041] FIG. 12A is a screen shot of a list of claims;
[0042] FIG. 12B is a screen shot of the details of a claim;
[0043] FIG. 12C is a screen shot of a vendor search function that
is driven by user selected criteria;
[0044] FIG. 12D is a screen shot of a list of vendors;
[0045] FIG. 12E is a screen shot of a vendor's details;
[0046] FIG. 12F is a screen shot of a record of assignment;
[0047] FIG. 13 is a chart that represents data fields received or
retrieved by the triage and assignment sub-systems;
[0048] FIG. 14 is a list of data field and attributes that an
assignment sub-system transmits an assignee as part of an
assignment;
[0049] FIG. 15 is a business object model for an assignment
sub-system;
[0050] FIG. 16 is a screen shot of a main screen of a vendor
connection and assignment management system;
[0051] FIG. 17 is a screen shot of a digital photo displayed
through a Connection system;
[0052] FIG. 18 is a flow diagram of an audit process;
[0053] FIG. 19 is a block diagram of the systems and sub-systems
that transmit, store, or retrieve claim data from an electron claim
file repository;
[0054] FIGS. 20A and B provide a business object model for an
electronic claim file repository;
[0055] FIG. 20B is a business object model for an electronic claim
file repository;
[0056] FIG. 21 is a business object model for an electronic claim
file repository;
[0057] FIG. 22 is a business object model for an electronic claim
file repository;
[0058] FIG. 23 is a block diagram of the systems, sub-systems and
database that interface with a user interface and claim manager
sub-system;
[0059] FIG. 24A is a screenshot of a user interface and claim
management system viewing and editing claim data feature;
[0060] FIG. 24B is a screenshot of a user interface and claim
management system viewing and editing digital images feature;
[0061] FIG. 25 is a screenshot of a user interface and claim
management system navigation feature;
[0062] FIG. 26 is a block diagram of the participants in an
automated payment process;
[0063] FIG. 27 is a flow diagram of a process of automating claim
payments;
[0064] FIG. 28 is a screenshot of an example of canned or standard
reports generated by a reporting sub-system;
[0065] FIG. 29 is a screenshot of a report generated by a reporting
sub-system that is indexed by region and by the states within each
region;
[0066] FIG. 30 is a screen shot of date elements generated by a
report sub-system exported to a Microsoft Excel software
program.
V. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
[0067] 1. General Overview
[0068] The present invention provides system and methods of
administering, tracking and managing claims processing. More
particularly, the system and method processes, tracks and releases
funds for claims made upon insurance policies and similar risk
shifting mechanisms including but not limited to self insurance,
indemnity provisions and surety and performance bonds.
[0069] a. System Architecture
[0070] A system architecture for practicing the methods of the
invention is shown in FIG. 1. The elements depicted on FIG. 1
include the computer systems, network connections and other
communication devices that constitute the preferred physical
embodiments to implement the described embodiment of the invention.
It is understood, however, that the system is not limited to the
mentioned devices and additional and alternative devices may be
supported by the system.
[0071] As shown in FIG. 1, a user (e.g., an insurance policy
holder, a consumer claimant, an insurance carrier internal
adjuster, an independent adjuster, a rental provider, or a repair
facility) interacts with the system 30 through input/output devices
1 ("I/O devices"). These I/O devices include but are not limited to
personal computer 2, wireless device 5, embedded device 10 and
telephone 15.
[0072] Personal computer 2 may be an IBM compatible computer, a
Macintosh computer or any other system capable of running Client
Software such as a Web Browser, although other client software may
also be used as appropriate to the system. Personal computer 2
preferably runs a Web Browser such as Netscape's Navigator or
Microsoft's Internet Explorer to communicate information to and
from system 30. Personal computer 2 is connected to a communication
network 25, such as the Internet, using a fast connection, such as
DSL, cable modem, wireless, modem, etc. Personal computer 2
preferably includes an output device, such as a monitor or other
display and a speaker or printer (i.e., printer device 3). Personal
computer 2 also includes an input such as a keyboard or pointing
device (e.g., mouse, track ball, pen device, microphone, joy stick,
game pad, satellite dish, scanner or the like) or both to enable
information to be input to the system.
[0073] Wireless device 5 may include but is not limited to a
communication device, including a telecommunication device or
wireless Internet devices that a user carries and uses to enter and
obtain information pertinent to the process. The wireless
infrastructure that connects the device with the communication
network 25 uses existing wireless signal receiving systems 20 such
as, for example, the communication methods used by 3Com's Palm
Pilot VII.
[0074] Embedded device 10 may include but is not limited to a
communication device embedded in the insured object, such as a
vehicle or a home, that is capable of detecting, recording and
transmitting to system 30 the information on the casualty that
initiates a claim. Embedded device 10 preferably communicates the
casualty information through wireless signal receiving systems 20
using a wireless device. Embedded device 10 may also transmit the
casualty information through other communication lines such as
telephone 15.
[0075] Personal computer 2, wireless device 5 and embedded device
10 transmit requests and responses to system 30 through
communication network 25 using standard protocols, such as XML,
HTTP or the like. It is understood, however, that the system 30 is
not limited to the mentioned standard protocols and alternative
standard protocols may be supported by the system 30.
[0076] When telephone 15 is used as an interface to system 30,
telephone 15 transmits a number to telephony server 41. Telephony
server 41 includes the necessary software to recognize speech and
convert it to a standard text format such as XML or the like that
can be sent to Web server 45. Telephony server 41 can also be
outside of system 30.
[0077] The messages sent and received by the I/O devices 1
preferably use standard protocols when they are received by load
balancers 40 and web servers 45. The preferred standard protocols
include but are not limited to HTTP and XML protocols which are
capable of being encrypted by Secure Socket Layer (SSL), Virtual
Network Protocol (VPN) or similar encryption systems.
[0078] Preferably, the computer systems in system 30 offer the
highest performance, scalability and reliability. In one
embodiment, the platform used is Sun Microsystems hardware running
the Solaris operating system.
[0079] Standard encryption mechanisms are used to ensure the
confidentiality of data. When confidential data is transported
between I/O devices 1 and system 30 or between external partner
systems 62 and system 30, encryption systems (i.e., SSL or VPN or
the like) may be used to protect the data.
[0080] Firewalls 35, 60, 69, 79 and 93 ("firewalls") are
specialized hardware and/or software components that filter
requests traveling in and out of systems 30, 65, 75 and 90
respectively. Certain input/output devices can also include
firewalls (not shown).
[0081] Firewall 35 is configured to accept only certain user
request types, preventing undesired requests from being forwarded
from communication network 25 to system 30.
[0082] Web servers 45, 66 and 76 include, but are not limited, to
servers running a Web server application. In one embodiment, such
servers are provided by Netscape Enterprise, Apache software.
[0083] Firewall 35 sends requests to load balancer 40, which
distributes such requests to one of the Web servers 45 in a Web
Server farm. Web server 45 then forwards the request to application
server 50 where a software application performs the appropriate
business logic to satisfy the request. As part of the required
business logic, the application accesses data stored in database
server 55.
[0084] Database server 55 runs a relational database management
system (RDBMS). In one embodiment, the RDMS software Oracle 8i is
used. The RDBMS software running in server 55 manipulates the data
and sends the appropriate information to application server 50.
[0085] Application server 50 may be, but is not limited to, a Java
based server providing scalability and reliability to the
application. The application runs on top of Application Server
Software, in one embodiment, BEA's WebLogic software.
[0086] The information required to complete the response to the
request may not only require data from database server 55, but also
data from one of the external partner systems 62. In one
embodiment, the application server 50 sends a request to one of the
external partner systems 62 via a secure communications medium 61,
such as, privately leased lines or the like. These external partner
systems 62 include insurance carrier system 65 or systems, vendor
system 75 or systems, trustee bank system 90 or systems. A
preferred format for the sent request is standard XML format,
although other formats may be supported by system 30. A computer
running the Adapter software running in Systems 67, 77, 86 or 91
translates the XML request to the format required by the insurer's
system, such as Legacy systems 68, 78 or 92 Once legacy systems 68,
78 or 92 respectively retrieve or update the data inside their data
stores, information is sent back to adapter 67, 77, 86 or 9, which
translates the message to XML and sends it back to application
server 50.
[0087] Legacy systems 68, 78, 87 or 92 include but are not limited
to existing systems that the external partners use to store and
process the data they use to perform their business. It is
understood that insurer systems other than Legacy systems may be
used.
[0088] Application server 50 builds a response preferably in HTML
or XML formats and sends it back to the I/O devices 1 that
initiated the request. For example, in the case of a personal
computer 2, the message transmitted to a Web Browser uses the HTML
protocol. In the case of the embedded device 10 and wireless device
5, the message is in XML format. In the case of telephone 15, the
message is an XML message ready to be converted into audible speech
by telephony server 41.
[0089] b. Logical Components
[0090] FIG. 2 depicts the logical components that comprise the
application software used to implement the present invention. In
one embodiment, the application is designed using an Object
Oriented and multi-tier approach to provide flexibility and ease of
integration with external partner systems 62 and also to allow
future modifications to the system 30. It should be understood,
however, that the system 30 is not limited to the mentioned logical
components and additional and alternative logical components may be
supported by the system 30.
[0091] As shown in FIG. 2, the system 30 uses various user
interfaces 204, including client software 205, voice based
interface 207 and wireless interface 209. This layer corresponds to
the I/O devices 1 in FIG. 1.
[0092] The client software 205 runs in a client machine such as
personal computer 2 and has all the display and communication logic
necessary to send and receive messages to and from the system 30
via a communications network 25. In a preferred embodiment, the
client software 205 is a Web Browser. In a preferred embodiment,
the client software 205 is the user interface and claim management
sub-system (Deskview) sub-system 200, described below. The voice
based interface 207 enables a user using telephone 15 to
communicate with system 30.
[0093] The wireless interface 209 enables a user using a wireless
device 5 to communicate with system 30. Wireless interface 209 is
also used by a user using an embedded device 10.
[0094] The application layer 213 may be hosted in Application
Servers 50. All communications between the application layer 213
and the external partner systems 62 are accomplished using
enterprise application interface 217 software ("EAI" or "EAI
Software"). The EAI software 217 manages message delivery and
transaction integrity. Such EAI software may be purchased from
Active Software or the like. The data to be communicated is
converted into a standard format such as XML or the like by EAI
217. Adapter software 203 (residing in adapter machines 67, 77, 86
and 91 in FIG. 1) can convert the standard format to the format
required by external partner system 62.
[0095] The data layer 219 provides the ability to store, update and
access data in an efficient and organized manner. In one
embodiment, the functionality of data layer 219 is provided by a
Relational Database such as Oracle 8i.
[0096] The electronic claim file repository (Eclaim database) 280
is a central repository for claim related and transactional data.
In one embodiment, claim data including administrative information
related to insurance policies, policy holders (such as name,
address, policy information, and transactions), consumers, and
other users (e.g., insurance carriers, and vendors), as well as
estimates, digital images, supplements, status of tasks related to
the claim, and reports, is stored in the Eclaim database 280. The
Eclaim database 280 is more fully described below.
[0097] The directory 290 is a database storing industry data on
businesses participating in a given industry. In one embodiment,
data on service providers (e.g., independent appraisers, repair
facilities, car rental facilities, towing providers, and glass
repair providers) and supplier is stored in this database. In one
embodiment, data on service providers includes name, service(s)
provided, location, and hours of operation. In another embodiment,
customer satisfaction index (CSI) data generated by consumers'
questions and answers provided in response to a customer
satisfaction survey, as well as other CSI information on the
service provider, supplier and other business providing service for
a given industry.
[0098] Application layer 213 comprises several sub-systems
including application software programs for performing various
functions within an application server 50. In one embodiment, the
application layer 213 includes user authentication sub-system 215,
EAI 217, Deskview sub-system 200, first notice of loss sub-system
(FNOL) 210, triage sub-system 220, assignment sub-system 230, audit
sub-system 240, automated payment sub-system 250, CSI collection
sub-system 260 (CSI), reports sub-system 270.
[0099] The user authentication sub-system 215 provides security
control to the system 30. The user authentication sub-system 215
requires a user to provide a valid user id and password
combination. For new users, the user authentication sub-system 215
registers the user, determines the user's level of access according
to insurance carrier business rules (e.g., security tables), then
stores the user authentication profile information (user id,
password, level of access) on data layer 219. In another
embodiment, user authentication information is stored on the
external partner systems 62. Subsequently, each user who wishes to
access the system must first be authenticated by the user
authentication sub-system 215, which then determines what
functional sub-systems of the system 30 the user is authorized to
access and utilize, what data stored in the data layer 219 the user
is authorized to access and to what degree the user can edit or add
to that data.
[0100] The user interface and claim management sub-system
(Deskview) 200 allows a user to access, view, add, and edit claim
data. Deskview 200 also serves as a portal point to other
sub-systems.
[0101] The first notice of loss sub-system (FNOL) 210 captures
initial claim data directly from a consumer using client software
205. In another embodiment, FNOL 210 captures initial claim data
through a commercial participant. FNOL 210 presents the user, the
consumer of the commercial participant, with tailored questions,
where the presentation format varies depending on the type of user.
Also questions subsequent to certain gateway questions presented to
the user vary according to the user's answers to the gateway
questions. The claim data captured can be transmitted to and stored
in the eclaim database 280, or insurance carrier system 65.
[0102] The triage sub-system 220 receives claim data and determines
the severity and priority of the claim according to business rules
established by an insurance carrier.
[0103] Next, the triage sub-system determines the type or type(s)
of assignees to assign a claim to according to business rules
established by an insurance carrier.
[0104] The assignment sub-system 230 receives the claim from the
triage sub-system 220, identifies the assignee most qualified for
the assignment according to insurance carrier business rules, makes
the assignment, records that the assignment has been made, and
notifies the assignee.
[0105] The vendor connection and assignment management system
(Connection) 300 (Connection) does not reside on the application
layer 213, but is stored and operates on the vendor's I/O device 1,
and serves as a communication and management system for vendors,
particularly service providers such as repair facilities and
independent adjusters. In one embodiment, Connection 300 resides
and operates on internal system 201.
[0106] The audit sub-system 240 applies insurance carrier specific
business rules, government regulations, and comprehensive trending
analysis to detect and rectify any inconsistencies and irregular
processing of claims, by auditing internal processes or user or
service providers submitted data.
[0107] The automated payment system (APS) 250 automates the process
of fulfilling payments required to fulfill an asserted claim.
[0108] CSI sub-system 260 automates the gathering of satisfaction
data from a policy holder or consumer to generate a Customer
Satisfaction Index (CSI) for the service providers.
[0109] The reporting sub-system 270 summarizes and formats 459 data
stored in the eclaim file 280 or the insurance carrier system 65
based on a number of criteria to generate various reports. Examples
of reports generated by the reporting sub-system 270 are cycle
times, conversion ratios, and current assignments outstanding.
Reports can be generated upon each request or can be pre-generated
and retrieved from storage in the eclaim database 280 or the
directory database 290.
[0110] In a preferred embodiment, system 30 is replicated in
different locations and data is synchronized between the different
locations to provide the highest level of reliability.
[0111] c. Data Flow Relationship and Overall Process
[0112] FIG. 3 is a block diagram of the data flow relationship
between participants and sub-systems of a system of administering,
tracking and managing insurance claim processing. FIG. 4 is a flow
diagram of a process of administering, tracking and managing
insurance claim processing.
[0113] The first notice of loss (FNOL) 210 captures initial claim
data directly from a consumer using client software 205 using, for
example, the embedded device, wireless device, PC or telephone of
FIG. 1. In another embodiment, FNOL captures initial claim data
through a commercial participant, such as an insurance company call
center. First, FNOL 210 receives 401 notice of loss from the user
or other sources. Next, FNOL 210 validates 403 the insurance policy
under which the claim is being asserted. FNOL 210 presents the
user, the consumer of the commercial participant, with tailored
questions, where the presentation format varies depending on the
type of user. Also questions subsequent to certain gateway
questions presented to the user vary according to the user's
answers to the gateway questions. The user then fills out and
submits 405 answers to the questions with which he is presented.
FNOL 210 determines if the submitted questionnaire is complete and
the answers submitted valid, and creates 407 a new claim record for
that claim. The claim data captured can be transmitted to and
stored in the eclaim database 280, or insurance carrier system
65.
[0114] The triage sub-system 220 receives claim data and determines
scores 409 the claim according to insurance carrier business rules.
The score is then used to determine the severity and priority of
the claim according to business rules. Next, the triage sub-system
classes 411 the claim according to business rules. The score and/or
class of the claim are then used to determine 413 the type or
type(s) of assignees to assign a claim to according to business
rules.
[0115] The assignment sub-system 230 receives the claim from the
triage sub-system 220, checks the profiles 415, which are stored in
the directory database 290, of assignees of the determined type
against profile preferences established in business rules. Next,
the status of the assignees that meet the profile requirement is
checked 417. The assignee that is of the determined type, meets the
profile requirements, and has capacity to complete the assignment
is identified and the assignment is made to that assignee. The
assignee is then notified and the assignment is recorded.
[0116] Connection 300 retrieves 421 claim data associated with an
assignment. Next, Connection 300 requests an estimate from an
estimate system and receives 423 an estimate with estimate details
from the estimating system. Alternatively, a human may provide an
estimate to connection 300. Subsequently, Connection 300 submits
the estimate to the system 30, which stores the estimate in the
eclaim database 280.
[0117] The audit sub-system 240 applies insurance carrier specific
business rules, government regulations, and comprehensive trending
analysis to detect and rectify any inconsistencies and irregular
processing of claims, by auditing internal processes or user or
service providers submitted data. The audit sub-system 240 can
review 427 an estimate made and determine if it is unreasonable or
if there is a potential for fraud. If the estimate is approved 433,
the assignee is notified and service 435 of the assignment begins.
If the audit sub-system 240 determines that the estimate is
unreasonable, the audit sub-system 240 notifies an insurance
carrier adjuster to review to the estimate.
[0118] The adjuster determines whether to approve 431 the estimate.
If the estimate is not approved, the adjuster contacts the service
provider to determine a reasonable estimate and a new estimate is
submitted 425.
[0119] Once the estimate has been approved 433, and after the
service starts 435, the automated payment system 250 is
employed.
[0120] The automated payment system (APS) automates the process of
fulfilling payments required to fulfill an asserted claim by an
insurance company. APS receives payment requests made, validates
the claim under which the request is made, validates the request
and automates payment. In the case of reception of an estimate, APS
may make progress payments according to insurance carrier business
rules. At step 437, APS determines if the service provider is a
trusted trading partner. In one embodiment, this is done by using
the service provider specific data from the system 30.about.s
service provider directory database 290 or on the eclaim database
280. If the service provider is trusted, and the business rules
authorize progress payments, the APS directs that Trust/Bank system
90 to release portions of payment outstanding of the total claim on
a continuum that is stipulated by the business rules to match the
progress of the service. When the service provider is not trusted,
payment is reserved until services are completed.
[0121] Once services are completed 451, APS requests the consumer
complete a certificate of satisfaction through use of and I/O
device 1. Once the certificate of satisfaction is received, APS
notifies the Trustee Bank system 90 to release the remaining
balance of the payment amount to the vendor. If the vendor is
trusted, any remaining amount is paid. If the vendor is not
trusted, the full amount is paid. The financial record stored on
the eclaim database 280 or the insurance carrier system 65, and the
account on the Trust/Bank system 90 are updated to reflect this
payment.
[0122] CSI sub-system 260 uses both structured questions with
predefined possible answers including multiple choice answers and
unstructured questions to be answered using free text gathered from
a policy holder or consumer to generate a Customer Satisfaction
Index (CSI) for the service providers. The CSI is stored into the
directory database 290. When the claim services are completed, the
consumer completes the consumer satisfaction survey via a client
software 205 interface or a voice based interface 207. Preferably,
the consumer uses his or her I/O Device 1 to review the customer
satisfaction survey questions stored in the eclaim database 280 and
are retrieved by the CSI sub-system 260. Alternatively, the
consumer completes a paper version of the survey and sends that to
a data entry group that uses I/O devices 1 to forward the responses
to the CSI sub-system for storage in the eclaim database 280.
[0123] The results of the consumer satisfaction survey are
retrieved from the eclaim database 280 compiled by the CSI
sub-system 260. The CSI sub-system uses an algorithm to generate a
composite index for the survey and updates the overall index for
that service provider in an entry to industry directory database
290 incorporating the new result. The resulting overall CSI index
for a given vendor can be displayed with the profile of the
assignee the next time the service provider's data in industry
directory database 290 is accessed from the system 30, particularly
the assignment sub-system 230.
[0124] Finally, the reporting sub-system 270 summarizes and formats
459 data stored in the eclaim database 280 or the insurance carrier
system 65 based on a number of criteria to generate various
reports. Various users arc able to view these reports through a
client software 205 interface. In one embodiment, the reporting
sub-system 270 utilizes software provided by Crystal reports and
the like to facilitate the creation of the reports. In a preferred
embodiment, the originating database (eclaim database 270, the
directory database, or the insurance carrier system 65 database)
that the reports are generated from is replicated and the reports
are generated from that replicated mirror database so as not to
burden the originating databases.
[0125] d. General Principles: Variable Automation, Standalone or in
Conjunction with Other Sub-systems, and Business Rules and Rules
Based Systems, and Communication with Other Parties.
[0126] (1) Variable Automation
[0127] In one embodiment, each of the sub-systems automates claims
processing tasks to a variable degree depending on business rules.
Business rules can require that, in response to certain data
conditions, a claims processing task be turned over to a human
participant such as an insurance adjuster. For example, if the
audit sub-system 240 determines through comparison with actuarial
analysis of stored claim data on past claims that a claim submitted
or an estimate submitted is likely fraudulent, the audit sub-system
240 would notify a Special Investigating Unit (SIU) of the
potential fraud and assign the task of estimate review to the SIU.
Even in a fully automated mode of operation, according to insurance
carrier business rules, the sub-systems enable human intervention
and exception handling for certain circumstances.
[0128] (2) Operation as Standalone Systems or in Conjunction with
Other Sub-Systems
[0129] In one embodiment, the sub-systems of the system 30 operate
in conjunction with one or more sub-systems and one or more of the
databases of the system. In an alternate embodiment, each
sub-system can operate on a standalone basis in conjunction with
one or more insurance earner systems 65.
[0130] (3) Business Rules and Rules Engines
[0131] Business rules utilized by sub-systems of the system 30 are
designated and/or approved by the insurance carrier and can be
updated and modified. In one embodiment, the business rules applied
by sub-systems described above are stored in the data layer 219. In
another embodiment, each set of business rules utilized by each
sub-system of the system 30 are incorporated into the sub-systems
at the application layer 213 and comprise a business rules engine
component of each sub-system. The general concept of business rules
will be known to persons of ordinary skill in the art. The specific
rules used to accomplish the functionality described herein,
contain content specific to implementation of this invention. In
one embodiment, business rules incorporated in business rules
engines are also designated or approved by the insurance carrier
and can be updated and modified.
[0132] (4) Transmission of Data to Other Parties
[0133] Sub-systems communicate with other parties (e.g., insurance
carriers, vendors, policy holders, consumers) providing a variable
degree of information (e.g., administrative information, if and who
the claim has been assigned to, status of each step in the
process). Information transmitted can be sent directly via mail,
fax, phone, email, or page or in other means that can be accessed
through I/O devices. In one embodiment, sub-systems or systems of
the invention can communicate to parties indirectly, through
posting data to a website or transmission of the data to the eclaim
database 280 coupled with notification to the intended receiving
party that the data is stored on a website or the eclaim database
280 along with sufficient access and reference to enable that party
to locate and retrieve the data. For example, assignment can post
data on who a claim has been assigned to a website or the eclaim
database 280, and then provide notification and access and
retrieval information to a policy holder, for instance, such that
the policy holder can retrieve that information and related
information without the need to contact the insurance carrier or
the system 30 directly through phone calls or other means. In
another example, APS can periodically post the status of payments
to a website and eclaim database 280, and notify a payee that the
status of their payment request is posted on a website or the
eclaim database 280 with access and retrieval information.
Subsequently, payees can have direct access to the updated status
information at their convenience.
[0134] 2. The First Notice of Loss Sub-System (FNOL)
[0135] a. General
[0136] The first notice of loss sub-system (FNOL) 210 captures
initial claims data. As shown in FIG. 3, FNOL 210 may be
implemented in conjunction with other sub-systems and databases of
the system 30. However, in an alternate embodiment, FNOL 210 can
operate on a standalone basis in conjunction with a single or
multiple insurance carrier systems 65.
[0137] FNOL 210 can be implemented to allow an user, for example, a
consumer, i.e., any individual who is not a policyholder and is not
acting on behalf of a commercial participant (e.g., a claimant
claiming damages under an insurance policy caused by a policy
holder), a policy holder, i.e., any individual who has a policy
with the insurance carrier involved, and a commercial participant,
i.e., a party acting on behalf of the insurance carrier involved
(e.g., a call center representative, an insurance agent, or an
insurance adjuster) to input initial loss information over a web
based channel. In one embodiment, the web-based channel is
available 24 hours a day.
[0138] b. Process
[0139] Referring to FIG. 5A, a flow diagram of the process of
capturing initial claim data, in step 502, the user initiates the
claims process using an I/O device 1. In one embodiment, the
process is initiated via an insurance carrier's system 65. In
another, the user connects to the insurance carrier's website and
begins to file a claim of loss based on insurance earner rules.
Next, the consumer selects 504 to submit a new claim loss, which
interfaces the user to FNOL. FNOL 210 can be branded for that
insurance carrier. In another embodiment, a user can directly
connect to FNOL 210 in the application layer 213 and initiate the
process of capturing initial claim data.
[0140] In step 506, the user completes an initial set of questions
geared to determining whether the user's claim is being made under
a valid insurance policy. The user is asked to supply required data
elements such as name of the user, relationship to claim, policy
number, and date of loss.
[0141] In step 508, FNOL 210 will verify if the policy is valid. In
one embodiment, this is done by accessing the insurance carrier's
system 65 to retrieve the policy profile information including
policy and coverage data and then comparing it with the data
entered. In another embodiment, the policy profile information
necessary to validate the user's claim is stored on the eclaim
database 280. If the policy information necessary to validate the
user's claim is stored on the insurance carrier system 65 and FNOL
210 is unable to connect with the insurance carrier system 65 to
confirm and potentially retrieve the necessary insurance policy
information, FNOL 210 can continue to capture claim information,
store the claim information received, but will not be able to
complete the transaction nor assign a claim number until FNOL 210
is able to connect to the insurance carrier system 65 to confirm
that the policy information matches a valid insurance policy.
[0142] If the policy is not valid (e.g., there is no record of the
insurance policy being asserted or the date of the loss is outside
of the policy coverage period), an error message will be returned
to the user and the user will be given additional opportunities to
enter valid policy information. For example, the policy information
may have been entered incorrectly and no matching policy exists. If
valid policy information is still not entered after a set number of
attempts, e.g., 5, the user will be informed that an error has
occurred, that the user should contact the insurance carrier, and
will be given 510 the insurance carrier's contact information. FNOL
210 also determines if the policy information entered violates
insurance carrier business rules and automatically implements
actions stored to handle such violation (e.g., if the date of loss
is outside of the policy period, then FNOL 210 communicates to the
user that the user should contact the insurance carrier and
provides the insurance carrier's contact information). In one
embodiment, after the claim is initiated the consumer is asked to
identify what type of loss they wish to report (e.g., automobile,
life, renters, health, and homeowners). This information will help
to funnel off claims that are not be appropriate to report through
FNOL 210 and may help with the triage sub-system 220 and assignment
sub-system 230 described more fully below.
[0143] If the policy information entered in step 508 is valid, the
user is presented with a second set of questions to fill out and
submit. In one embodiment, certain policy data that relate to
insured vehicles, drivers, and coverage, which are stored on the
insurance carrier's system is retrieved and used to pre-populate
corresponding data fields within the second set of questions the
user is presented with.
[0144] FIG. 6 is a table containing examples of question group
fields (questions sets) and particular question fields a user may
be asked to complete. Certain questions can be designated as
mandatory fields according to insurance carrier business rules.
[0145] At any time after an authenticated user has accessed FNOL
210, the authenticated user may save the information added for the
loss to that point as unfinished. This saves the information
entered so that the user can come back to it at a later point and
finish. Once the user chooses to save an incomplete set of initial
claim data, notification is sent back to them that the save was
successful, and information necessary to retrieve their saved claim
at a later time is provided. Additionally, a warning should be
displayed that any information saved as unfinished will be purged
from the system in 7 days and that no notices have been or will be
sent to the carrier about this loss unless it is completed.
[0146] Next, after all question sets have been completed and a user
believes that all the information about the loss has been entered,
the user submits 512 the entire set of answers to FNOL 210. FNOL
210 then determines 514 if at the very least, the mandatory fields
are answered and filled with valid information. In the case of
missing or invalid information, the insurance carrier system 65 is
able to designate how FNOL 210 will respond. Examples of potential
responses: if the user leaves one or more required fields
blank--the user will be reminded to complete the fields marked as
required before proceeding, if the user inputs invalid information
into a required field--message will display listing the fields that
are in error along with valid formatting for each field, and if the
user experiences either of the above errors and is unable to
correct them. After the third attempt, an additional message will
be displayed 510 directing the user to contact the insurance
carrier and offering the insurance carrier's contact information.
If all mandatory fields are completed with valid information, FNOL
210 stores 516 the complete set of initial claim data on the eclaim
database 280 and may assign it a claim number. In one embodiment,
after a user completes, and submits each set of questions, FNOL 210
determines if at the very least, the mandatory fields have been
answered and are filled with valid information. If mandatory fields
have not been satisfactorily completed FNOL 210 responds according
the business rules.
[0147] Next, the complete set of initial claim data and the claim
number, if assigned, is transmitted 520 to the insurance carrier
system 65. Also, if FNOL 210 assigned a claim number, it is
transmitted 518 to the consumer or policy holder. The insurance
carrier system 65 then stores the set of initial claim data, and
may assign it a claim number, if FNOL 210 had not previously. If a
claim number has not been assigned previously by FNOL 210, the
insurance carrier system 65 assigns 522 the claim a claim number,
attaches the claim number to the claim data, and transmits the
claim number to the consumer or policy holder and to the eclaim
database 280. The eclaim database 280 then attaches the claim
number to the set of initial claim data.
[0148] In another embodiment the set of initial claim data is
stored solely on the eclaim database 280. The insurance earner is
transmitted notice that a new claim has been filed and captured,
and sufficient claim identification information such that the
insurance carrier system 65 or insurance carrier representatives
can access the claim data stored in the eclaim database. In one
embodiment, notice and the claim identification information are
transmitted via email or fax.
[0149] In another embodiment, FNOL 210 transmits the complete set
of initial claim data and the claim number, if assigned, to the
insurance carrier system 65.
[0150] c. Varying Presentation Layers and Questions Presented by
User Type
[0151] In one embodiment, FNOL 210 presents distinct user
interfaces to user according to type of user. A different user
interface is presented to and utilized by commercial participants,
e.g., agencies or call centers (carrier operated or outsourced) as
compared with policy holders and consumers. The user interface is
tailored to the user type, with the interface for commercial
application provides increased functionality over the one for
consumers.
[0152] For example, whereas a user who is a consumer or policy
holder may be presented a series of questions and answers over a
larger number of spaces with a greater deal of explanation into how
to answer each question, the commercial user is presented with
fewer question and answer sets and may instead be presented a
greater amount of designated fields and a greater density of
questions or fields.
[0153] FIG. 5B a flow diagram of a commercial participant's process
of capturing initial claim data. A commercial participant logs 524
into a website using an I/O device 1. The commercial participant
selects 526 FNOL 210 option to capture or report initial claim
data. The commercial participant than selects 530 an insurance
carrier the claim is being filed under and enters policy
information. If policy information is invalid a warning is
displayed 536 to the user. If the policy information is valid FNOL
210 determines 538 if there are any duplicate claims filed. If
there are potential duplicate claims filed, FNOL 210 displays 540
summary details of the potential duplicates. For either case of a
claim being filed under an invalid policy or if duplicate claims
have been potentially filed, FNOL 210 provides suggestions to the
user as to how to proceed based on insurance carrier rules, which
could include proceeding to collect the initial claim data, or to
terminate the claim data capture process and refer the situation to
an insurance carrier adjuster or customer service center. The
subsequent steps are similar to the process of capturing initial
claim data implemented for a non-commercial participant.
[0154] d. Gateway Questions
[0155] FIG. 7A is a screenshot of a gateway question presented to a
user via his browser in an initial claim capture system.
[0156] FIG. 7B is a screenshot of questions presented subsequent
and in response to an answer to a gateway question in an initial
claim capture system.
[0157] In one embodiment, FNOL 210 presents the user with gateway
questions, the answers to these gateway questions determine whether
and what subsequent questions will be presented to the user. For
example, has anyone been injured in the accident? Were any other
persons involved (e.g., witnesses, pedestrians, bicycle riders)? If
the answer is no, another gateway question may be presented. If the
answer is yes, the user is presented with additional questions
related to that gateway subject. Another example, an automobile
claim will have questions relating to bodily injury. If the
consumer answers in the affirmative, there will be additional
questions to provide detail about the injured parties and the
sustained injuries.
[0158] e. Attachment of Digital Photographs and Images
[0159] In one embodiment, a user attaches digital photographs,
scanned images, or documents to the claim questionnaire submitted.
Digital images stored in standard digital formats and scanned
images scanned by a TWAIN-compliant scanner can be attached to a
questionnaire submitted through FNOL 210. For example, a photo of a
damages car can be attached.
[0160] f. Interactive Graphical Depiction of Damage
[0161] FIG. 8 is a screenshot of an interactive user interface,
which allows a user to represent a damaged vehicle through varying
the degree and location of damage to a representative vehicle
graphic.
[0162] In one embodiment, FNOL 210 interactively questions user to
graphically represent the degree of damage a vehicle has sustained.
Through a series of questions separated by feedback graphical
representations of the user's answers, FNOL 210 assists the user in
creating an accurate graphical depiction of a damaged vehicle. FNOL
210 presents a user with a question as to what damage, the location
of damage, and the degree of damage a vehicle has sustained. In
addition, FNOL 210 provides guidelines, in the form of text or in
the form of representative graphics or digital photographs or
images as examples of types and degree of damage according to
location and severity. In a further embodiment, graphics or digital
images can be produced which match or are similar to the make and
model of the vehicle whose damage is being graphically represented.
Graphics can be two-dimensional or three-dimensional.
[0163] For example, if the user selects moderate front end damage
to a vehicle, FNOL 210 would alter a graphic of a vehicle to
represent moderate front end damage. Subsequently, if the user did
not find the graphical representation to be accurate, he could
change alter his selection of damage location and degree and would
be presented with a new depiction of his selection. When the user
finds the depiction to be accurate, the graphical depiction is
stored along with other claim data. For example, FIG. 8 is an
interactive user interface to varying the degree of damage to a
representative vehicle graphic. The vehicle graphic starts in an
undamaged state, but changes as and according to the user's input
as to the location and degree of damage. Each user submission of
location and degree of damage changes the graphic, until the user
is satisfied with the depiction and submits the depiction.
[0164] In another embodiment, user described damage is matched with
a digital library with images of damaged vehicles. Images that are
determined to resemble the damage reported by the user are
retrieved and presented to the user for comparison. If available,
vehicle make and model criteria can be searched and matched to
return digital images of damage vehicles of the same make, model
and potentially year as the vehicle the user is attempting to
describe. In another embodiment, the user is presented with slide
bars to represent the degree of damage and can control the location
of the damage by the reporting the angle from which the vehicle was
damaged (e.g., one o'clock, 12 o'clock).
[0165] FIG. 9A is a business object model (BOM) for an
implementation of a FNOL 210, which with FIG. 9B, which is a list
of object attributes for a the business object model of FIG. 9A,
provides an explanation of and relationship between the objects
used in a preferred implementation of the invention.
[0166] 3. Triage Sub-System and Assignment Sub-System
[0167] a. General
[0168] The triage sub-system 220 and assignment sub-systems 230
automate, to a variable degree (e.g., full automation vs. limited
automation that requires user interaction to complete the process),
the process of identifying tasks that need to be completed to
fulfill an insurance claim, determining which type of assignees,
e.g., a service provider, vendor, internal work group or individual
assignee are necessary to fulfill the claim, determining which
individual assignee is most well suited to fulfilling each specific
task and assigning each assignee a task, for processing and/or
review. The types of assignments available include: appraisal,
estimate, estimate review, repair, rental, or towing assignments.
The triage sub-system 220 and the assignment sub-system 230 provide
a variety of users within carrier claim staff (i.e., adjuster,
Claims Clerk, estimate reviewer) or consolidators with an efficient
method of delegating work assignments electronically. In another
embodiment (described below), the triage and assignment process is
fully automated.
[0169] In one embodiment, as shown in FIG. 3, the triage and
assignment sub-systems are implemented in conjunction with other
sub-systems of the system 30, for example, the eclaim database 280,
FNOL 210, and Deskview 100. However, in another embodiment, the
triage and assignment sub-system 230s operate in combination or on
a standalone basis in conjunction with a single or multiple
insurance carrier systems 65.
[0170] FIG. 10 is a block diagram of the types of assignees the
triage sub-system 220 and assignment sub-system 230 can make
assignments to.
[0171] The triage sub-system 220 assigns a priority order to claims
on the basis of where funds and resources can be best used or are
most needed, as well as a class of the claim, so that the claim can
be accurately assigned. The assignment sub-system 230 appoints
responsibility for a claim or a portion of a claim to an assignee
(e.g., a Repair Facility, an Independent Adjusting Firm, a work
group within an Insurance Carrier, a specific adjuster or a
combination of assignees).
[0172] b. Process
[0173] FIG. 11 is a flow diagram of a process of triage and
assignment in accordance with the present invention. FIG. 13 is a
chart that represents data fields received or retrieved by the
triage and assignment sub-systems. First, the triage sub-system 220
receives 1101 or retrieves an insurance claim record, similar to
the example in FIG. 13, that contains data elements from either the
eclaim database 280 or from the insurance carrier system 65.
[0174] i. Scoring Claim Data
[0175] Next, the triage sub-system 220 scores 1103 the insurance
claim by retrieving and applying a set of the insurance carrier's
business rules, which can be seen as an insurance carrier scoring
table, stored on the insurance carrier system, to the claim data.
Scoring simply assigns different aspects or elements of the claim
according to the insurance carrier's business rules, and then sums
the numeric values associated with different aspects of a claim.
Scoring sets the priority of the claim and may weigh such factors
as: [0176] Reported by person/relation [0177] Reported on date
[0178] Loss type [0179] Date of loss [0180] Time of loss [0181]
Loss location (state, city, zip & county) [0182] Number of
vehicles involved [0183] Number of parties involved [0184] Types of
parties involved [0185] Location of parties [0186] Loss description
[0187] Damage to vehicle [0188] Location of vehicle [0189] Vehicle
drivability [0190] Damage to other property [0191] Location of
property [0192] Property livability [0193] Injuries involved [0194]
Types of medical treatment [0195] Type of policy [0196] Type of
coverage [0197] Repair partners chosen [0198] Amount of damages
[0199] Policy information [0200] Agency information [0201]
Regulatory conditions
[0202] These factors are scored according to an insurance carrier's
business rules via a rules based system. Examples of the
application of the business rules to the claim elements are: [0203]
A point could be added for each vehicle involved in a claim. [0204]
A point could be added if there is damage to something other than a
vehicle. [0205] A point could be added for each non-injured person
involved. [0206] Several points could be added for each person
involved. [0207] Points could be added for different types of
claims Collision with a fixed object might get one point where
Collision with another vehicle by rear ending it might get two and
Collision with another vehicle in an intersection might get five.
[0208] Multiple points could be added if a bicyclist or pedestrian
was involved. [0209] Multiple points could be added if the claim is
from a more complex policy type that requires more coverage
investigation. [0210] Points could be added if the car was a
theft.
[0211] In addition, factors such as damage to vehicles, damage to
property, or physical injuries may have an associated severity
weighting that will contribute to the score that element receives.
Next, the score assigned for each element of the claim are
summed.
[0212] The summed score is used to determine 1105 the severity and
priority of the claim according to the insurance carrier business
rules. For example, a claim that receives a high summed score
likely represents a complex, high damage and high cost claim.
Determining the severity also will apply to determining the type of
assignee the claim will be assigned to. For example, a claim with
an extremely low score (under 5) might qualify to be handled
completely by a repair facility without an adjuster needing to be
assigned. One that scores under 20 might go to a fairly new
adjuster. A claim that scored over 50 might only go to a seasoned
specialists. In addition to scores, there could be additional rules
that even if the score only amounts to 3 but there was an injury,
the system would have to assign an adjuster in addition to the
repair facility, since the repairer cannot handle the injury.
[0213] The summed score and the severity can be used to determine
the priority of a claim, i.e., the order in which it is processed
relative to other claims. The priority and order of processing of a
claim can differ according to insurance carrier business rules. For
example, some insurance carriers may prioritize the processing of
low scored claims that have low severity because low scored claims
are usually less complex and are able to be turned over quickly. In
contrast, some carriers may do the opposite and prioritize the
processing of high scored claims that have high severity because
they high severity claims may require more attention.
[0214] ii. Classing a Claim
[0215] Next, the claim is classed 1107. Classing puts a claim,
based on alphanumeric strings of values for specific fields in the
claim (e.g., the fields that hold the year, make, model data for a
vehicle), through a series of tests that are set by the business
rules to determine a "class" of claim. Once the class of the claim
is determined, the designated class is then used to determine,
through application of insurance carrier's business rules, which
type or types of assignees to assignee the claim. For example, the
triage sub-system 220 220 might receive claim data for a claim on a
1999 BMW 750. An insurance carrier rule may be to class all claims
filed on BMW 750's that are a model year of greater than or equal
to 1997 as a "new luxury car" class. This class, the "new luxury
car class" may then have a business rule that requires all "new
luxury car" class claims to have an independent or internal
adjuster assigned to the claim.
[0216] Once the score and the class of a particular set of claim
data are determined the score and the class, in conjunction,
through the application of the insurance carrier business rules,
are used to determine 1109 the type or types of assignees that are
necessary to fulfill the claim. The types of assignees can be
determined by tests as simple as any individual data value that
returns a class or score above a certain limit set by a carrier, a
combination of class and score that is beyond a certain threshold,
up to combinations of multiple value scores and classes that fall
inside or outside of parameters. Some insurance company business
rules are very simple tests and have a limited number of
corresponding types of assignees to assign the claim to. Other
business rules will designate elaborate tests in order to classify
new claims and many potential assignees.
[0217] Also, where the score and class can be used in conjunction
to determine the type of assignee to assign a claim to, certain
"class" designations may be weighted higher and overrule a score
designation that would normally result in a certain type of
assignee being flagged. For example, an insurance carrier business
rule may be that an internal adjuster will always handle a
particular class of claims (for example, all claims involving a
1999 Ford Explorer). So, if this "class" of claims is detected by
the triage sub-system 220 220, the claim could be directed to the
internal adjusting staff as opposed to the repair provider
regardless of the total score of the claim.
[0218] As another example, the class of "Non listed driver" is
applied any time a driver for the insured vehicle is indicated that
is not listed on the policy, and the class of "Single Car
accident/Late night accident" is applied anytime two circumstances
occur on the same claim: the loss involved only the insured vehicle
and the time of loss was between midnight and 6:00 am.
[0219] Using these examples, the separate score of either of the
two examples listed above could easily be low, indicating that
these claims might qualify for automated adjusting by directing the
claim to a repair facility and then automatically paying the
estimate. However, each of these classes of claims represents a
significant exposure to the insurance carrier in terms of the
claimant not having coverage for the loss or from an underwriting
aspect. Therefore, a claim been designated as either class might be
directed internally to a non-automated process no matter how low
the claims score.
[0220] In another embodiment, what type or types of assignees that
a claim will be assigned to can be determined by the triage
sub-system 220 through the application of business rules to the
claim data without the process of scoring and classing. For
example, the triage sub-system 220 can identify what basic type of
assignee to assign the claim to through the application of the
insurance carrier's business rules and policy information stored on
the insurance carrier's policy database as applied to the insurance
data. For example, claim data received by the triage sub-system 220
may reveal a claim involving damage to the insured vehicle that is
drivable, while insurance claim policy information retrieved from
the insurance carrier's policy database reveals the claimant has
collision coverage and rental reimbursement coverage. The triage
sub-system 220 can then identify that there is a need for a Repair
Facility and Rental Company. If, for example, the car also is not
drivable, the triage sub-system 220 also identifies that a towing
company may be needed. Determining which types of assignees to
assign a claim to and the class of a claim are parallel to
determining the types of tasks need to fulfilled to satisfy a
claim. In one embodiment, the triage sub-system 220 determines
specific tasks that are required to satisfy the claim and
determines a type or types of assignees to assign each of those
tasks to.
[0221] c. Assignment
[0222] The assignment sub-system 230 is utilized after the triage
process identifies the type or types of assignee(s) that is need to
fulfill the claim.
[0223] i. Profile Matching
[0224] First, the assignment sub-system 230 checks 1111 the profile
of assignees of the type designated by the triage sub-system 220.
The assignment sub-system 230 checks the profiles of assignees to
match insurance claim data (e.g., owner address or vehicle
location) to a group of specific potential assignees of the
determined type according to insurance carrier business. Assignee
profile information (e.g., name, function, address, customer
satisfaction index (CSI) score, and rates charged) is stored in the
directory database 290, which contains profile information on
potential assignees. In an alternate embodiment, assignee profile
information is stored on an external database, such as an insurance
carrier system 65 database, accessible to the assignment sub-system
230. In One embodiment, the CSI score is one component in an
assignee's profile is generated by and provided by the CSI
sub-system 260.
[0225] The assignment sub-system receives the profiles for each
type of assignee designated by the triage sub-system 220 to which
to assign the claim. Specific claim data elements from the claim
record will be checked with profile data for each assignee that the
insurance carrier has selected as assignment criteria in accordance
with insurance carrier business rules. Those assignees of the
specific type that match the profile will be selected.
[0226] As a specific example, a business rule may be that only
assignees of a given type who are within 50 miles of the vehicle
location may be assigned a repair assignment. The assignment
sub-system 230 then retrieves the vehicle location, which is piece
of claim data and matches that with the store location for
assignees of the given type according to the business rule of being
within 50 miles of the vehicle. All assignees that match those
criteria are retrieved. As a further example, to differentiate
between assignees of the given type who meet the first business
rule, the potential assignees that are retrieved can be ranked or
can be further narrowed down based on CSI score, average rates, and
average cycle times, which are generated by the reports sub-system
270 and added to the assignee profile in the directory database
290.
[0227] (1) The Directory Database
[0228] The directory database 290 can be grouped by type of
assignees (e.g., repair facilities, independent appraisers, rental
providers) and contain standard administrative information such as
assignee names, addresses, and phone numbers. In one embodiment,
the directory data is retrieved from electronic yellow pages. In
one embodiment, in addition to administrative information, the
directory database 290 stores information such as maps to the
assignee location, work rates, as well as such information as CSI
index scores, status/capacity to work, which can be updated by the
assignee or estimated using reports such as cycle time and the
number of assignments currently made to the assignee as are
generated by the reports sub-system 270 and also stored to the
assignee profile. Reports generated by the reports sub-system that
are vendor specific (e.g., a particular vendor's cycle time
(average time to complete an assignment) or an the aggregate number
of assignments a particular vendor has be assigned over a
particular period of time) are stored in the directory database
290. In one embodiment, vendor specific data such as vendor
specific reports are linked to the eclaim database 280. In one
embodiment, the directory database 280 interfaces with insurance
carrier systems 65.
[0229] ii. Check Status
[0230] Next, taking the assignees whose profiles meet the
assignment criteria set by the insurance carrier business rules,
the assignment sub-system 230 accesses the status or
schedule/workload of each potential assignee stored in the
directory database 290 to determine 1113 the current status or
capacity of a given assignee.
[0231] In one embodiment, capacity can be determined by the
assignment system by reviewing data such as history, cycle time,
and the amount of assignments assigned to a given assignee
generated by the reports sub-system 270 and stored in association
with each assignee profile in the directory database 290. In
another embodiment, the assignment sub-system 230 can retrieve
currently updated copies of a potential assignee's schedule. In one
embodiment, status data from assignees' calendar systems such as
Outlook are imported into the assignee profile. In one embodiment,
for internal insurance carrier and field staff, the assignment
sub-system 230 receives data directly from the insurance carrier
system 65 regarding each staff adjuster's status.
[0232] iii. Identify Specific Assignee(s)
[0233] The assignment sub-system 230 then determines 1115
algorithmically, according to insurance carrier business rules
which assignee has the greatest capacity to accept the assignment,
and assignees the particular task to that assignee.
[0234] Assignment can be made to a carrier, any internal entity
within a carrier (department, unit, manager, adjuster), an external
adjusting source (Independent adjuster), or a vendor or to more
than one of these. There could be multiple assignments on a single
claim depending upon carrier specifications. One assignment could
be to a vendor (such as a repair facility) for a damage estimate,
while another could be to an Special Investigation Unit
investigator to investigate a potential case of fraud in the
initial claim, while yet another could be made to an internal
bodily injury adjuster.
[0235] In certain circumstances (e.g., selection of repair facility
or rental provider) whether for legal reasons (e.g., anti-steering
regulations) or efficiency concerns, before an assignment can be
made, the assignment sub-system must obtain authorization of the
selection of assignee from the policy holder or consumer who filed
the claim.
[0236] Authorization can be obtained through notifying the policy
holder or consumer of a recommended assignee or a list of
recommended assignees, and receipt of selection of assignee or
authorization to choose the assignee determined by the assignment
sub-system 230. Notification and authorization capture could be
implemented electronically (e.g., through email), through verbal
communication confirmation received by an insurance carrier
representative (e.g., a call center representative or insurance
carrier adjuster operating a semi-automated assignment sub-system
230), or through any I/O device 1.
[0237] iv. Notification, Updating the Databases, and Logging the
Transaction Record.
[0238] Next, the assignment sub-system 230 notifies 1117 the
assignee that the assignment has been made. In one embodiment, all
transmissions to an assignee are via the notification method (e.g.,
an Connection 300, email, fax, mail, phone) established in the
profile for that assignee.
[0239] In one embodiment, the assignment sub-system a claim file,
similar to the example in FIG. 14, containing insurance claim
information and details of the assignment are transmitted to the
assignee. In another embodiment, with notification of assignment
the selected assignee is transmitted sufficient data, such as a
user id and password to access claim data related to the assignment
stored in the eclaim database 280.
[0240] Once the assignments have been identified and the assignees
have been notified, if the assignment sub-system 230 the eclaim
database 280 is updated 1119 with details of the assignment (e.g.,
the claim data, which assignee(s) the claim was assigned to). In
one embodiment, a link is provided to the assignee profile stored
in the directory database 290 from the assignment details updated
to the eclaim database 280. In another embodiment, once the
assignments have been identified and the assignees have been
notified, the insurance earner system 65 is updated with claim
information and details of the assignment to reflect the
assignment. In another embodiment, once the assignment has been
made the insurance carrier system 65 is notified of the assignment
and provided with sufficient information to access claim data that
relate to the claim and reflect the assignment.
[0241] In one embodiment, an entry of the assignment is logged in
the transaction record stored of the eclaim database 280 in
association with the insurance claim.
[0242] v. Updating the Business Rules, Profiles, and Status
[0243] The business rules are updateable by the insurance carrier
system 65. The assignee profiles, including status can be updated
by the assignee, a systems administrator, or automatically
periodically by the system 30. For example, status can be
automatically retrieved from an assignee system when an assignee
submits an estimate to the system 30.
[0244] vi. Automation
[0245] While the triage sub-system 220 and assignment sub-system
230 can fully automate the process of assigning claims according to
insurance carrier business rules, these sub-systems can function at
variable levels to provide variable levels of automation. For
example, claims that score low can be fully automated, however when
a claim receives a score above a certain threshold or a particular
class is assigned to the claim by the triage sub-system 220, a
human participant such as an insurance adjuster may be notified and
passed the task of determine and making the final assignments. In
an example where a human participant such as an insurance adjuster
ultimately decides which assignee to assign a claim to, the triage
sub-systems 220 may still score and class the claim to provide the
adjustor with a processed score and class of the claim which can
serve as an automated reference point, as well as suggested types
of assignees to assign the claim to. The assignment sub-system 230
would apply the business rules to provide a list of suggested
assignees that fit a certain profile and have sufficient capacity
to process the assignment, while the adjuster could then choose to
pick from the suggested list or choose an assignee that has not
been pre-selected by the assignment sub-system 230.
[0246] FIG. 12A is a screen shot of a list of claims that a human
participant needs to assign. FIG. 12B is a screen shot of the
details of a claim. FIG. 12C is a screen shot of an assignee search
function that is driven by user-selected criteria. FIG. 12D is a
screen shot of a list of potential assignees. FIG. 12E is a screen
shot of a potential assignee's details. FIG. 12F is a screen shot
of a record of assignment. FIG. 12A-F demonstrates how, in one
embodiment, the triage and assignment process is lightly
automated.
[0247] FIG. 15 is a business object model for an assignment
sub-system 230. This BOM provides an explanation of and
relationship between the objects used in a preferred implementation
of the invention.
[0248] 4. Vendor Connection and Assignment Management System
(Connection):
[0249] a. General
[0250] The vendor connection and assignment management system
(Connection) 300 is an open (i.e., able to communicate with various
systems, e.g., insurance carrier systems 65, estimate systems, and
system 30 sub-systems, over a non-proprietary format and
communication medium) claim related task management, and claim data
management and communication system designed for utilization by
vendors, particularly repair facilities, independent appraisers and
insurance carriers.
[0251] Connection 300 retrieves claim data, which can be related to
an assignment, manages and is able to transmit claim data, which
can be repair related, and estimate information to vendors (e.g.,
repair facilities and independent adjusters), insurance carrier
systems 65, suppliers of parts and materials, vehicle owners, and
to the eclaim database 280.
[0252] b. Functionality of the Connection System
[0253] Each of the functions of Connection 300 described below can
operate in conjunction with the rest of the functions described
below or independently.
[0254] i. Receipt and Management of Claim Data
[0255] A user can utilize Connection 300 to receive and process
claim data from an insurance carrier system 65 or the system 30. In
one embodiment, Connection 300 retrieves data from the eclaim
database 280 in response to a notification of an assignment from
the assignment sub-system 230. The claim data retrieved can be
stored locally on the user computer 2 or other I/O device 1.
Connection 300 then allows a user to view and manage the claim data
in various presentation formats. For example, FIG. 16 is a screen
shot of a main screen of an implementation of the Connection 300
system, which is exemplary of a data format that Connection 300 can
present claim data to a user. In the screen shot of FIG. 16,
assignments outstanding are presented to the user. In addition to
administrative claim data (e.g., an assignment's claim number, date
of loss, and claimant information management), Connection 300
allows the user to view already attached digital images (e.g.,
digital photographs, and scanned images) or other digital formatted
documents. FIG. 17 is a screen shot of a digital photo displayed by
Connection 300. In one embodiment, Connection 300 can retrieves
reports, which may be generated by the reporting sub-system 270,
and stored in the directory database 290.
[0256] ii. Adding Data
[0257] In addition to being able to view initial claim data
associated with an assignment, Connection 300 allows the user to
append additional information such as digital images to initial
claim data. Digital photos, and scanned images of, for example,
photographs, and documents such as tow bills, parts invoices and
police reports can be associated with the initial claim data.
Connection 300 supports digital images from any commercially
available digital camera or TWAIN-compliant scanner. In one
embodiment, Connection 300 allows the user to print electronic
documents to a print driver sub-component of Connection 300, which
will attach a digital image of the document to the inbox for that
claim. Digital images retrieved or added through Connection 300 are
watermarked for protection such that any alteration of the image
will negate the watermark.
[0258] iii. Editing Claim Data
[0259] Initial claim data and data added to the initial claim data
can be viewed and edited through Connection 300. In addition to
enabling the user to edit stored digital text, Connection 300 can
be used to rotate, crop, enlarge, invert and enhance digital
images.
[0260] iv. Communication with Estimating Systems
[0261] Connection 300 transmits claim data to estimating systems
(e.g., Comp-Est, Shoplink, Ultramate, and Pathways) and can
retrieve and add detailed estimates provided from estimating
systems to claim data. From estimate data retrieved from an
estimating system, Connection 300 can create an electronic quote
request for specific parts and types of parts (e.g., OEM, salvage,
aftermarket, or glass) and transmit that request to an appropriate
vendor.
[0262] v. Claims Folder
[0263] In one embodiment, initial claim data and subsequent edits
of the initial claim data added to the initial claim data are
associated and stored in a fashion that all data relating to a
certain assignment can be easily retrieved. The relational storage
and retrieval of claim data associated with a single assignment or
claim can be envisioned as the creation of a claim folder for each
assignment or claim.
[0264] vi. Transmission of Claim Data in an Open Format and Through
Open Communication Standards.
[0265] Connection 300 stores received, added and edited data,
including digital images, in an open format that is readable by
various estimating systems and insurance carrier systems 65. In
addition, Connection 300 transmits claim data to insurance
carriers, parts and materials vendors, vehicle owners and other
parties involved in the claims process through open
(non-proprietary) communication standards (i.e., standard Internet
protocols) that allow parties, including proprietary and legacy
systems to receive the data. In one embodiment, Connection 300
communicates with other parties involved in the claims process
through the communication network 25.
[0266] Connection 300 can communicate to parties indirectly,
through posting data to a website or transmission of the data to
the eclaim database 280 coupled with notification to the intended
receiving party that the data is stored on a website or the eclaim
database 280 along with sufficient reference and authorization
information, if necessary, that the party is able to locate and
retrieve the data. For example, a repair facility can utilize
Connection 300 to periodically post repair status and expected date
of completion information or other claim information (e.g.,
administrative information, or status/capacity to fill additional
assignments) to a website or the eclaim database 280, then can
notify a vehicle owner that the vehicle owner can retrieve repair
status or other data relating to their vehicle from the website or
the eclaim database 280. The vehicle owner will no longer need to
directly contact the repair facility to determine the status of the
repair.
[0267] 5. Audit Sub-System
[0268] a. General
[0269] The audit sub-system 240 periodically reviews stored claim
data applies insurance carrier established and editable business
rules to determine if any pieces of claim data do not meet the
criteria set by the business rules. If any pieces of claim data do
not meet insurance carrier criteria, the audit sub-system 240 can
automatically direct an action set by the business rules to resolve
the violation, or notify a human participant such as an insurance
carrier adjuster, of the failure. The audit sub-system 240 is able
to detect and direct resolution of claim processing that was
incorrect, processes that need to be conducted but were not,
unreasonable estimates, and potentially fraudulent
transactions.
[0270] As audit sub-system 240 finds situations that match the
rules established by a particular insurance carrier, it will act
upon those findings accordingly. According to certain business
rules, the audit sub-system 240 can remove claims from the
automated process and refer them back to the insurance carrier for
personal attention or could continue through the automated process
with notification going back to the carrier for informative
purposes. The audit process could be a matter of finding certain
flags, running the information past another database and then,
based on those findings, either continuing on with the process or
referring it back to the insurance carrier. The audit sub-system
240 could also be set to notify a carrier whenever certain trends
are detected. For example, if a certain repair facility's average
cost per estimate had increased more than a certain % in a certain
amount a time, a notification could be sent to the carrier for them
to further investigate the causes. Again, the audit sub-system 240
looks for exceptions to the standard, accepted procedures or
practices that the insurance carrier has established in the form of
business rules.
[0271] b. Process
[0272] FIG. 18 is a flow diagram of an audit process. The audit
sub-system 240 retrieves 1801 claim data from the eclaim database
280, the insurance carrier system 65 or vendor systems 75 at
variable instances set according to business rules. For example, a
business rule may be that after each submission and capture of a
new claim, the claim data must be audited by the audit sub-system
240. In another example, a business rule requires the audit
sub-system 240 to review and audit each estimate submitted by a
vendor. In one embodiment, the audit sub-system 240 and the
automated audit process can be initiated by a human participant
such as a insurance carrier appraiser after a certain amount of
human auditing has already taken place. In one embodiment, claim
data can be sent directly to the audit sub-system 240 directly.
[0273] i. Business Rules and Statutory Regulations
[0274] The audit sub-system 240 processes 1803 retrieved or
received claim related data according to business rules designated
by an insurance carrier. Business rules are editable and updateable
at the direction of the insurance carrier. Through application of
insurance carrier business rules to the claims data, the audit
sub-system 240 determines 1805 if any business rules are violated.
For example, if a business rule is that only used parts should be
used to the repair vehicles made in 1995 or earlier, and an
estimate submitted by a repair facility references to use of new
parts for repair of a 1990 vehicle, the audit sub-system 240 would
automatically detect that the repair facility's estimate had
violated a business rule.
[0275] In one embodiment, the audit sub-system 240 determines if
statutory regulations are satisfied in the processing of the claim
thus far. The audit sub-system 240 applies statutory regulations to
claim data in a similar fashion to the application of insurance
carrier business rules. For example, certain state regulations
mandate that certain notifications need to be sent to consumers,
while another imposes cycle time limitations on addressing a filed
claim. The audit sub-system 240 determines if notifications have
been sent and automates the process of sending the notifications if
they have not been sent. Also, in the case of statutory regulated
deadlines, the audit sub-system 240 generates reminders to
responsible parties that a task must be completed by a mandated
deadline. The audit sub-system 240 is provided a list of statutory
regulations that apply to the claim process the audit sub-system
240 is auditing. Statutory regulations can be edited and updated to
reflect changes in the law.
[0276] ii. Violations
[0277] If no business rule or statutory regulation has been
violated, the audit process terminates 1809. If a business rule or
statutory regulation violation is detected, the audit sub-system
240 applies business rules to process the violation. The audit
sub-system 240 can directly notify third parties involved (e.g.,
vendors or policy holders) of the violation with explanation as to
reason for violation and proposed courses of action. For example,
if an estimate submitted by a repair facility provides insufficient
or invalid information, the audit sub-system 240 would detect the
violation and notify the repair facility to complete or provide
additional valid information. Violations resolution is governed by
business rules and can require that the audit sub-system 240 notify
and transfer the audit process to a human participant such as an
insurance carrier appraiser. For example, if instead of determining
that an estimate submitted by a repair facility violates business
rules by failing to submit sufficient or valid information, the
audit sub-system 240 determines that the estimate contains
sufficient and valid information, but is unreasonably high, the
audit sub-system 240 would assign the audit process to an human
participant such as an insurance carrier adjuster to conduct an
additional audit, and if the estimate is still found unreasonable,
to negotiate with the repair facility to change the estimate. In an
alternate embodiment, in the previous example, the audit sub-system
240 could automatically notify the repair facility that their
estimate was denied, that it was unreasonable, and with sufficient
details of denial such that the repair facility can attempt to make
a more reasonable estimate.
[0278] In another example, audit sub-system 240 determined
potential cases of fraud, through application of business rules,
would be transferred to a special investigating unit for further
processing. In one embodiment, fraud detection is determined by a
fraud detection system separate form the audit sub-system 240.
[0279] iii. Trending Analysis
[0280] In one embodiment, the audit sub-system 240 applies trending
analysis to claim data to determine if the claim data falls outside
of normal boundaries. For example, instead or in addition to
applying a business rule that lists circumstances (e.g., the cost
of a hood is within a certain range) in estimates that would result
in the estimate being determined unreasonable, the audit sub-system
240 can apply trending analysis data that can be stored in the
eclaim database 280 or generated by the reporting sub-system 270.
For example, the reporting sub-system could determine how much the
last 100 repair facilities charged for the repair of the left front
door of a specific vehicle make, model and year. If claim data of a
newly submit estimate for a comparable task is retrieved by the
audit sub-system 240, the audit sub-system 240 applies the report
to determine if the estimate is unreasonable for falling outside of
the ranges.
[0281] iv. Notification of Audit Findings and Logging the Audit
[0282] Upon termination of the audit process, either through no
violation of business rules or statutory regulations being found,
or if a violation was found, the audit sub-system 240 rectifying
the violation according to business rules, the audit sub-system 240
notifies the sub-system or systems that it operates directly in
conjunction with (e.g., the eclaim database 280 and the insurance
carrier system 65) of the result of the audit process and logs an
entry of the decision and details related to the decision to those
system(s). In one embodiment, the audit sub-system 240 notifies a
third party (e.g., a vendor or a policy holder or consumer) that
does not interact directly with the audit sub-system 240 of the
audit sub-system 240s conclusion. For example, if the audit
sub-system 240 audits an estimate submitted by a repair facility
and determines does not approve the estimate, the audit sub-system
240 notifies the repair facility that the estimate was denied.
[0283] 6. Electronic Claim File Repository (Eclaim Database)
[0284] a. General
[0285] FIG. 19 is a block diagram of the systems and sub-systems
that transmit, store, or retrieve claim data, from an electron
claim file repository. The electronic claim file repository (eclaim
database) 280 is a central relational database where claim related
and transactional data is received, stored and exists to be
accessed by systems and sub-systems. Claim data stored in the
eclaim file is in an open data format that is readable by various
sub-systems and systems. Any number of systems or sub-systems,
ranging from one to all of the systems and sub-systems that
interact with system 30, are able to interface with the eclaim
database 280.
[0286] Claim data, including administrative information related to
insurance policies, policy holders (such as name, address, policy
information, and transactions), consumers, and other users (e.g.,
insurance carriers, and vendors), as well as assignments,
estimates, digital images, supplements, status of tasks related to
the claim, transaction logs and entries, parts lists, warranties,
payment information, and reports is stored in the eclaim database
280. In one embodiment, instead of storing detailed vendor related
administrative and other data (e.g., CSI) in the eclaim database
280, detailed vendor related claim data is stored in the directory
database 290 which is linked to general vendor claim data that is
stored on the eclaim database 280. Certain claim data is stored in
a format that cannot be edited based on governmental regulatory
requirements or due to business rules. For example, initial claim
data captured by FNOL 210 or receiving and stored in the eclaim
database 280 from insurance carrier systems 65 are frozen so as to
prevent fraud. In another example, digital scanned images of legal
documents are stored in an uneditable format. However, in one
embodiment, copies of this data, which are labeled as copies and
not originals, are made and can be edited or manipulated and added
to the virtual claim file containing the original data.
[0287] In one embodiment, claim data is associated and stored in a
fashion that all data relating to a certain claim can be easily
retrieved. The relational storage and retrieval of claim data
associated with a single claim can be envisioned as the creation of
virtual claim folders or files for each claim. In one embodiment, a
unique claim number, usually represented by an alphanumeric data
field, is assigned to each claim that is stored in the eclaim
database 280. All pieces of claim data related to that claim are
marked with the unique claim number and can thus be associated with
other claim data related to the single claim. Furthermore, the data
elements that make up a claim can be grouped into claim segments
within the overall claim through the assignment of an unique
identifier that is attached to all claim data of the claim segment.
These claim segments (suffixes) could represent a particular
coverage type, claimant, vehicle or individual associated to a
particular claim.
[0288] In one embodiment, the eclaim database 280 is segregated
into segments designated to store claim data related to a specific
insurance carrier.
[0289] Access to the eclaim database 280 is governed by the user
authentication sub-system 211, with various parties having variable
degrees or levels of access to claim data stored on the eclaim
database 280.
[0290] The eclaim database 280 can be regularly updated through a
feed of data received from the systems or sub-systems that interact
with it. In one embodiment, the eclaim database 280 imports or
pulls claim related data from systems or sub-systems. The eclaim
database 280 receives automated data imports (e.g., status data of
work related to a claim) from other systems and sub-systems.
[0291] FIGS. 20A and B provide a business object model for the
eclaim database 280, which outlines the relationship between claim
related data stored in the eclaim database 280. FIG. 21 is a
business object model, which outlines the relationship between an
insurance carrier or vendor and the data attributes and elements
associated to it that are stored in the eclaim database 280. FIG.
22 is a business object model, which is linked to the business
object models of FIG. 20A, FIG. 20B and FIG. 21, and outlines the
user roles and relationships to data described in the business
object models of FIG. 20A, FIG. 20B and FIG. 21
[0292] 7. User Interface and Claim Manager Sub-System
(Deskview)
[0293] a. General
[0294] FIG. 23 is a block diagram of the systems, sub-systems and
database that interface with a user interface and claim manager
sub-system. The user interface and claim manager sub-system
(`Deskview) 200 is a user interface and claim management system,
which interfaces with and can be utilized to access, view, edit,
and add claim data stored in the eclaim database 280. Deskview 200
also acts as a portal point from which other sub-systems of system
30 can be accessed and utilized.
[0295] b. Features
[0296] i. Retrieve, View, Edit, and Add Claim Data
[0297] FIG. 24A is a screenshot of a user interface and claim
management system viewing and editing claim data feature. Deskview
200 allows a user to search for and view claim data associated with
a single claim, the claim data being linked and retrievable such
that the user is presented with an integrated virtual claim file of
claim data associated with a claim. Claim data can be presented to
a user through Deskview 200 in a general, high-level, summary
format as well as various degrees of more detailed formats to allow
the user to decide what degree to drill down into the details of a
claim. In one embodiment, Deskview 200 also provides an interface
with the directory database 290.
[0298] Claim data accessible via Deskview 200 include the severity
of claims, vehicle damage, cycle time for claim processing, repair
status updates, estimates, basic management reports, attached
digital images, and transaction logs. Examples of filters, which
can be used individually or in combination to present claim files
in an organize format include region, company, claim office, date
claim received/reported. Examples of search criteria, which can be
used individually or in combination to retrieve specific claims,
include claim number, policy number, claimant name, insured name,
data of loss, and adjuster ID. In one embodiment, claim data
related to a claim is automatically presented to the user upon
entry to Deskview 200 according to business rules. For example, an
adjuster may be automatically presented with all the claims that
assigned to him for review and processing upon accessing Deskview
200.
[0299] In addition, Deskview 200 allows the user to change or edit
or manipulate claim data such as administrative information and
digital images to the virtual claim file. FIG. 24B is a screenshot
of a user interface and claim management system viewing and editing
digital images feature. Claim data such as administrative
information and digital images can be appended to the virtual claim
file as well. For example, a user utilizing Deskview 200 can enter
notes concerning the claim or link emails and other documents to
the other claim related data that compose a virtual claim file.
Certain claim data is stored in a format that cannot be edited
based on governmental regulatory requirements or due to business
rules. For example, initial claim data captured by FNOL 210 or
receiving and stored in the eclaim database 280 from insurance
carrier systems 65 are frozen so as to prevent fraud. However, in
one embodiment, copies of this data, which are labeled as copies
and not originals, are made and can be edited or manipulated and
added to the virtual claim file containing the original data.
[0300] In one embodiment, claim data stored, for example status or
capacity of a given vendor to fulfill an assignment, in the
directory database 290 can be accessed, edited and added to using
Deskview 200. In one embodiment, claim data stored eclaim database
290 links to more detailed claim data stored in the directory
database 290. For example, a vendor's general information can be
stored on the eclaim database 280, while more detailed vendor
administrative information stored on the directory database 290 is
linked to the general data. In another embodiment, claim data
stored in insurance carrier systems 65 can be accessed, edited and
added to using Deskview 200.
[0301] Access and the degree to which a user can view, edit, or add
to claim data stored in the eclaim file 280 is governed by the
authentication sub-system 215. Deskview 200 utilizes the data
relationships outlined in the business object models of FIGS. 20A,
20B, 21, 22 to display, edit, or add claim data to claim data
stored in the eclaim database 280 and the directory database
290.
[0302] ii. Portal, Navigation Point
[0303] FIG. 25 is a screenshot of a user interface and claim
management system navigation feature. Desk view 200 is also the
point at which a users log into the system 30, and can navigate to
other sub-systems of the system 30 through use of links or buttons.
Which sub-systems a user is able to access via Deskview 200 is
governed by the authentication sub-system 215. The navigation
buttons or links presented to a user through Deskview 200 are
consistent with the sub-systems the user is able to access. In an
example of the utilization of the navigation feature of Deskview
200, a user such as an insurance adjuster may enter the system 30
through Deskview 200, have claims assigned to automatically
presented upon entering Deskview 200, view the claim in detail,
then decide what function needs to be performed on the claim, e.g.,
triage and assignment, audit, or payment. The user could then
select the function, through utilization of navigation buttons, he
wishes to process the claim with and be transferred to the
sub-system or system that governs the selected process. As a
specific example, a user may wish to determine a repair facility's
cycle time and rate at which they convert an assignment into an
estimate before assigning the claim. The user can access the
reports sub-system 270 through use of the navigation buttons stored
on Deskview 200, then directly utilize the reports sub-system to
generate the desired report or reports.
[0304] 8. Automated Payment System:
[0305] a. General
[0306] FIG. 26 is a block diagram of the participants in an
automated payment process. The circled numbers represents the order
in which the process flows in the described embodiment.
[0307] The Automated Payment System 250 (APS) automates the process
of fulfilling payment requests made under insurance claims. APS 250
receives invoices (payment requests) from vendors, automatically
approves payments according to the insurance carrier business
rules, disburses payments to vendors via a trustee bank 2603 using
ACH (Automated Clearing House) methods, where possible, tracks the
transaction, and provides reconciliation and accounting details to
the Insurance Carrier systems. For automobile line of insurance,
examples of vendors who provide invoices and receive payment are
Repair Facilities, Independent Appraisers, Rental Agencies, Towing
Facilities, Salvage Companies, Storage Facilities, and Parts
Suppliers, Auto Glass Suppliers, and even policy holders or
claimants who have incurred pre-paid costs covered under the
insurance policy. For the movement of funds, the insurance
carrier's bank 2601 will fund the trustee bank's 2603 escrow
account; and the trustee bank 2603 will pay the payee 2605 or fund
the vendor's (payee) bank.
[0308] The APS 250 receives an invoice or estimate directly from
the vendor in electronic form, automatically approves payments
based on the carrier's payment rules, aggregate payments for
vendors, automatically disburses payments via the claims payment
clearing house in the form of the trustee bank 2603, and
automatically reconciles the loss and the payment to the carrier's
internal systems.
[0309] The APS 250 will also support customer service for carrier
and vendor queries.
[0310] b. Process
[0311] FIG. 27 is a flow diagram of a process of automating claim
payments from the prospective of an automated processing system.
First, the APS 250 receives 2701 an electronic payment request
based on a fee estimate or an invoice for work already completed.
In one embodiment, the electronic payment request contains: (1)
information about the insurance claim the request is being made
under, (2) the requestor's profile information (e.g., name,
address, phone number, email address, payment preference (e.g.,
ACH, wire transfer, check), ACH data, if any.), and (3) information
about the request being made including work done, or to be done,
amounts requested for tasks completed or on amounts requested based
on estimated cost for tasks to be completed.
[0312] In an alternate embodiment, the payment request will have
sufficient reference information to allow the APS 250 to retrieve
information such as details of the claim the request is being made
under and the requestor's profile information from the eclaim
database 280, directory database 290, or insurance claim system 65.
For example, the electronic payment request might have an eclaim
database 280 user identification and password, along with an
identification number that represents the claim. These
identification numbers that will allow the APS 250 to access the
eclaim database 280 and retrieve claim data for the particular
claim the request is being made under. In one embodiment, a
progress payment request can be made for a partially completed
task.
[0313] In one embodiment, once the payment request is received, APS
notifies the eclaim database 280 and the insurance carrier system
65 of the request for payment and periodically updates the database
and system with the payment status of the request.
[0314] Next, the APS 250 determines 2703 if the payment request is
being made under a valid insurance policy. In one embodiment,
policy information can be stored and retrieved from the eclaim
database 280. In another embodiment, policy information is stored
on the insurance carrier system 65.
[0315] Once the insurance policy is validated, the APS 250
validates 2705 the payee by determining if the payee 2605 profile
information is stored in the directory database 290. If the payee
2605 profile information is not stored in the directory database
290, the APS 250 adds the payee 2605 profile information provided
in the payment request to the directory database 290. Insufficient
profile information will cause the APS 250 to notify the payee 2605
to complete the information. After a set number of notifications to
the payee 2605 of insufficient profile information have not
produced a complete set of profile information the APS 250 will
notify the payee 2605 contact the insurance carrier after a.
[0316] i. Validating a Payment Request
[0317] Next, the APS 250 validates 2707 the payment request by
applying the insurance carrier specific business rules to the
payment request. For example, a business rule may be that Direct
Repair Program (DRP) members are entitled to pre-approval status
for claims under $500. The APS 250 would then retrieve insurance
carrier vendor (payee 2605) profiles, which are setup and
maintained on the directory database 290 and determine if the
vendor, e.g., a repair shop, is a DRP member. If the vendor is
determined to be a DRP member and the claim is under $500, the APS
250 would automatically approve the repair payment, without any
intervention from a Claims Adjuster.
[0318] In the case of progress payment requests, the APS 250 can
determine based on the insurance carrier's business rules if the
request matches a progress milestone or fulfills some other
criteria. In one embodiment, progress payments may be processed
automatically without requiring the payee 2605 to make a payment
request. For example, a business rule may allow APS to
automatically pay a DRP member whose has a fast average cycle time
of repairs a portion of repair tees proportionate to the time since
the assignment was made and the current date. For example a DRP who
has shown, on average, that a certain task assigned to it requires
ten days for the to complete, would be paid 50% of the estimated
repair fees five days after the assignment was made.
[0319] In one embodiment, if a payment request is not approved by
the Insurance Carrier business rules, the APS 250 can direct the
requesting party to resubmit the request or contact an insurance
carrier representative. In alternate embodiment, for payment
requests that are not approved by the APS 250 through application
of the insurance carrier business rules, the APS 250 notifies
Insurance Carrier personnel to intervene and manually approve
invoices not adhering to Insurance Carrier's pre-defined business
rules. In another embodiment, instead of applying the insurance
carrier specific business rules to the invoice information
directly, the APS 250 directs the received invoice to the audit
sub-system 260, described above and in more detail below, for
validation and approval.
[0320] In one embodiment, once the APS approves a payment request
to pay an invoice for certain work completed (e.g., automobile
repair), the APS requires confirmation of satisfaction from the
policy holder or consumer who made the claim. Confirmation can be
received in many forms. In one embodiment, the policy holder or
consumer utilizes an I/O device 1 at the vendor site upon review of
the services. For example, a policy holder could be proved with a
dial-in phone number which will prompt the policy holder through a
confirmation authorization process. In another example, the policy
holder uses the vendor's computer 2 to log onto a website and
confirm that the policy holder is satisfied.
[0321] ii. Funding Request Sent
[0322] Once the APS 250 approves a payment requests and for certain
circumstances receives 2709 confirmation of satisfaction, APS
notifies the insurance carrier system 65 to authorize the insurance
carrier bank 2601 to fund the trustee bank. In one embodiment APS
250 accumulates the insurance carrier's approved payments in a
queue until the scheduled payment date. On or before the payment
date, the APS 250 aggregates all approved payments for each payee
2605 within carrier. APS creates a aggregate or bundled funding
request and transmits the funding request to the insurance carrier
system 65. In another embodiment, APS transmits a funding request
to the insurance carrier system 65 for each approved payment
request.
[0323] Payment information, which includes the payee's profile
(e.g., name, address, email address, phone number, and ACH
information, if the payee 2605 is to be paid via ACH), amount of to
be paid, and payment execution date are transmitted to trustee bank
2603 and the Insurance Carrier's Claims and Accounting systems
within the Insurance Carrier system 65.
[0324] iii. Insurance Carrier Bank Funds Trustee Bank Escrow
Account
[0325] After the insurance carrier receives the funding request, it
directs its bank 2601 to transfer an amount equal to the total
funding request to the trustee bank. In one embodiment, the
carrier's bank transfers the necessary funds through a wire
transfer or through ACH on the day the funding request is
transmitted from the APS 250 to the Insurance Carrier's bank. In an
alternate embodiment, funding requests can be made prior to the
payment date, and funds can be transferred to the trustee bank 2603
before the payment date.
[0326] APS 250 requests policy holder or consumer to recognize the
assignment has been fulfilled.
[0327] iv. Clearing House Receives Payment Execution Order from
APS
[0328] APS 250, based on insurance carrier business rules,
determines payment execution dates. The APS 250 directs 2713 the
trustee bank 2603 to execute a single or batch of payments to
fulfill a single or multiple payment requests on the payment
execution date, which can be the same date APS places to order to
execute or can be a date different from the date APS places to
order to execute. The trustee bank 2603 executes orders that it has
previously received payment information for, and for which the
trustee bank 2603 has received sufficient funds to cover the
disbursement from the insurance carrier bank 2601 prior to the
payment execution date of the order. In another embodiment, if the
trustee bank 2603 does not receive funds matching the execution
amount, the trustee bank 2603 may still execute payment execution
orders based on previously received funds that are sufficient to
cover the disbursement or through drawing down on an insurance
carrier's line of credit, which is not, nor will be overdrawn by
the execution of the payment(s) with the trustee bank 2603, if an
insurance carrier has such a line of credit with the trustee bank
2603.
[0329] v. Payment Execution
[0330] Next, payments, individual or aggregated, are made to each
payee 2605 via ACH, wire, or check from the trustee bank 2603 on
the established payment date. In an alternate embodiment, payments
are made in the form of authorization information to directly debit
an insurance carrier bank account for the amount owed the payee
(e.g., a credit card number with which the payee can debit the
amount owed). In one embodiment, the insurance carrier system 65 is
enabled to view account status of the bank account open for payees
to draw on and audit the debits to the account. In one embodiment,
the insurance carrier views the account status over the Internet.
This audit feature allows the insurance carrier to detect
inaccuracies in debits, particularly debits of amounts in access of
those authorized.
[0331] vi. Reporting
[0332] The trustee bank 2603 provides electronic notification to
the APS 250 that payment has been made to the payees 2605. APS
notifies 2715 the payee 2605 that payment has been executed. Once
the payments have been made and the payees 2605 have been notified,
the APS 250 updates 2715 the eclaim database 280 with the details
of the payment. In another embodiment, once the payments have been
made and the payee 2605s have been notified, the insurance carrier
system 65 is updated with payment details to reflect the payment.
In one embodiment, an entry of the payment is logged in the
transaction record stored of the eclaim database 280.
[0333] vii. Account Structure of the Trustee Bank
[0334] In one embodiment, the account structure of the trustee bank
2603 will be an omnibus escrow account where each carrier's funds
are tracked via sub-accounting. The trustee bank 2603 maintains
custody of funds until disbursement and provides payment support
services (customer service). In an alternate embodiment, each
insurance carrier would open a separate escrow account within the
clearinghouse.
[0335] viii. Payment Aggregation by the Clearing House
[0336] In one embodiment, an individual payment is sent to a payee
2605 for each payment request made and validated. In an alternate
embodiment, payments to payees 2605s with multiple payment requests
that are validated are aggregated into a single payment. In one
embodiment, multiple payments from a single insurance carrier to a
single payee 2605 are aggregated into a single payment. In an
alternate embodiment, payments to the same payee 2605 are
aggregated across all carriers participating in the clearing house.
Individual payee 2605s are uniquely identified by a payee 2605
code. In yet another embodiment, the APS 250 aggregates payments at
both levels: multiple payments from a single carrier to a single
payee 2605, and payments from several carriers to a single payee
2605 are aggregated into one payment.
[0337] ix. Payee/Payor Inquiry to Clearing House
[0338] In one embodiment, the trustee bank will provide customer
service via the telephone. Payees 2605 or payors who have questions
regarding lost, destroyed checks can contact a 1 800 number for
customer service. Additionally, customers who have questions
regarding ACH payments can contact the customer service number as
well. The clearinghouse will only answer questions regarding
payments it has executed based on the APS 250 instructions. Any
questions regarding claims, invoice amounts, etc. will be directed
to the APS 250 system or the specific Insurance Carrier
(Payor).
[0339] x. Reconciliation
[0340] In one embodiment, APS 250 tracks payments by insurance
carrier, claim number, payee 2605 and amount. For aggregated
payments, sufficient individualized information is provided the
payee 2605 such that the aggregate payments can be decomposed into
claim-level or job-specific detail. In another embodiment, after an
aggregate payment has been made and APS 250 transmits notification
of the payment to the payee 2605, APS 250 provides the payee 2605
with sufficient information to access, view and retrieve payment
data stored on the eclaim database 280 to allow the payee to
decompose the aggregate payment.
[0341] APS 250 provides information to the insurance carrier system
65 to allow the claim and accounting information systems of the
insurance system 65 to ensure the payments balance, close the
claim, and update the insurance earner database. In an alternate
embodiment, the insurance carrier system 65 is provided access to
and retrieval information to retrieve payment information from the
eclaim database 180.
[0342] 9. The Customer Satisfaction Index Collection Sub-System
(CSI Sub-System)
[0343] a. General
[0344] CSI sub-system 260 generates questionnaires to gather
customer satisfaction data from customers (e.g., policy holders or
consumers), gathers the customer satisfaction data, and then use
the data gathered to generate a customer satisfaction index (CSI)
score for each survey and an aggregate CSI score from the
individual CSI scores for each commercial participant (e.g.,
service providers, insurance carrier staff who have handled a
policy holder claim, the insurance carrier.) which can be stored
and later utilized in ranking the commercial participant. In one
embodiment, data of user satisfaction of processes, sub-systems and
systems described above is also gathered. The survey data gathered
from policy holders and consumers are stored in the eclaim database
280, while the calculated aggregate CSI is stored into the
directory database 290 in association with the party whose work is
being scored. In one embodiment, incentives such as discounts on
repairs are provided to customers to retrieve satisfaction data
from them.
[0345] b. Process
[0346] i. Generation of a Customer Service Questionnaire
[0347] The CSI sub-system generates general customer service
questionnaires that stored on the eclaim database 280.
Questionnaires include both structured questions with predefined
possible answers including multiple choice answers and unstructured
questions to be answered using free text. Commercial participant
can add ad-hoc questions to the standard survey questions.
[0348] ii. Gathering Customer Satisfaction Data
[0349] The CSI sub-system directs gathering of customer
satisfaction data in a number of methods. First, when claim
services are completed, the consumer completes the consumer
satisfaction survey via a client software 205 interface or a voice
based interface 207. Preferably, the consumer uses his or her I/O
Device 1 to review the customer satisfaction survey questions
stored in the eclaim database 280. In another embodiment, the CSI
sub-system emails customers a message asking them to provide
feedback. The email contains a hyperlink to a survey form located
at a website. In another embodiment, the consumer completes a paper
version of the survey and sends that to a data entry group that
uses I/O devices 1 to forward the responses to the CSI sub-system
for storage in the eclaim database 280.
[0350] In another implementation, a call center is employed to
contact customers directly with survey questions, the call center
staff filling out the CSI survey questions as they are answered by
the customer. The CSI sub-system can create interview scripts
stored on the eclaim database 280 to be used by call center staff.
The CSI sub-system can also generate calling lists from customer
data stored on the eclaim database 280 or retrieves call lists
stored on the eclaim database. In one embodiment, the CSI
sub-system removes numbers from the call list based on transaction
entry that shows that a particular customer had already completed
the survey. In another embodiment, the CSI sub-system de-duplicates
phone numbers listed on the eclaim database to prevent the same
number from being inadvertently called twice.
[0351] iii. Generating a Customer Satisfaction Customer
Satisfaction Data and Report Generation:
[0352] The results of the consumer satisfaction surveys are
retrieved from the eclaim database 280 compiled by the CSI
sub-system. The CSI sub-system utilizes an algorithm to generate a
composite index score for each survey. The CSI sub-system then
updates the overall CSI index score for that service provider in an
entry to industry directory database 290 incorporating the new
result. The resulting overall CSI index for a given vendor can be
displayed with the profile of the assignee the next time the
service provider's data in industry directory database 290 is
accessed from the system 30, particularly by the assignment
sub-system 230.
[0353] If a designated client receives a satisfaction score below a
pre-defined threshold, the CSI sub-system automatically notifies
the client of the low score according to client designated
notification preferences. This automatic notification allows the
client to determine the reason for the low score and attempt to
rectify instances of low customer satisfactions or change methods
that produce low customer satisfaction.
[0354] The commercial participant can view their customer
satisfaction data (e.g., stored answered surveys, individual CSI
index scores generated for each survey, and aggregate CSI index
score generated for the commercial participant) stored on the
eclaim database 280 or the directory database 290. In one
embodiment, customer satisfaction data is added to the eclaim
database 280 as soon as retrieved (which can be many times in a
day), thus, commercial participants can review customer
satisfaction in a near real-time fashion.
[0355] In addition, customer satisfaction reports can be generated
by the reports sub-system 270 for the survey data. Reports can be
generated daily, weekly, monthly, quarterly, and yearly reports on
customer satisfaction and include reports that aggregate industry
ratings for benchmarking (comparison with the performance of other
commercial participants) and graphical reports.
[0356] 10. Reporting Sub-System
[0357] a. General
[0358] The reporting sub-system 270 summarizes and formats data
stored in the eclaim database 280 or the insurance carrier system
65, based on a number of criteria, to generate various reports.
Examples of reports generated by the reporting sub-system 270 are
cycle times, conversion ratios, and current assignments
outstanding. In one embodiment, the reporting sub-system 270
generates reports from data stored in the directory database 290.
The reporting sub-system 270 can generate upon request or
pre-generate and store reports to be retrieved later. In one
embodiment, once a report is generated it can be stored in the
directory database 290, if specific to a vendor(s), or is stored in
the eclaim database 280, if not specifically related to a
vendor(s).
[0359] The reporting sub-system analyzes stored claim data elements
(e.g., severity of claims, vehicle damage), estimates, detailed
estimate data, transaction logs and other key performance measures
to produce an aggregate view of transactions (e.g., counts,
averages, users, business units, geographical designations or
average cycle times).
[0360] b. Types of Reports
[0361] i. Canned Reports
[0362] FIG. 28 is a screenshot of an example of canned or standard
reports that a reporting sub-system can generate and a user can
select. The reporting sub-system produces canned reports, reports
whose criteria and data elements are pre-selected and static. A
user can select from canned reports, but is unable to designate how
the data of the report is presented. In one embodiment, the user
can select the time frame (e.g., for the month of March, for the
first quarter, for the year of 2001) of a canned report.
[0363] Examples of canned or set operational reports generated from
transaction logs data include the number of assignments made by
adjuster per month, and the number of claims received by FNOL 210
per month. Examples of canned reports generated from transactional
claim data include cycle time (calculated from the start and
completion of a process), number of estimates, damage by vehicle
type, average appraisal fee, OEM part usage.
[0364] ii. Customized Reports
[0365] In another embodiment, the reporting sub-system supports the
generation of customized reports that match user selected criteria
to produced focused results. The reporting sub-system is able
generate reports indexed by activity within a specific time range,
by activity within a geographical region, and by vehicle type. FIG.
29 is a screenshot of a report generated by a reporting sub-system
that is indexed by region and by state within each region. In one
embodiment, the reporting sub-system 270 allows a user to drill
down and view the specific details of customized reports (e.g., the
number of assignments can be presented in a per day, per adjuster,
per week, per month, per quarterly and per year format, or by
adjuster, by service office, by region, and by insurance carrier).
In one embodiment, customized reports are generated by third party
systems.
[0366] Reports can be generated to analyze and compare trends in
the processing of claims. For example, the average estimate for a
certain type of repair over a current quarter, the month prior to
the current quarter, the quarter prior to the current quarter, and
the year prior to the current quarter. These trend-analyzing
reports can provide an insurance carrier with data to determine if
subsequent estimates for similar types of repair are reasonable or
even potentially fraudulent. Reports can be generated real time at
the point of request or at set times with the results being stored
in the eclaim database 280, the directory database 290, or the
insurance carrier system 65.
[0367] FIG. 30 is a screen shot of date elements generated by a
report sub-system exported to a Microsoft Excel software program.
In one embodiment, the details of each report generated can be
drilled down to and the reports as well as the details of each
report can be exported to other systems (e.g., via email or through
posting on a webpage). In one embodiment, data elements that
compose the reports can be downloaded to Microsoft Access and Excel
software.
[0368] In a preferred embodiment, the data from originating
database (i.e., the eclaim database 270, the directory database, or
the insurance carrier system 65 database) that the reports are
generated from is replicated and stored in a more efficient format
for reporting analysis, and the reports are generated from that
replicated mirror database so as not to burden the originating
databases.
[0369] It should be noted that at least one described embodiment
operates in an automated fashion with no human intervention. Other
embodiments may operate with varying degrees of human intervention
for, as an example, escalation of difficult claims or human
estimation input.
[0370] One example of a semi-automated process that employs
sub-systems of the inventions:
[0371] After FNOL 210 captures a new claim and stores the claim
data in the eclaim database 280, the claim is automatically
assigned by the triage and assignment sub-systems 220/230 to an
insurance carrier adjuster. Once the assignments are made, the
assignment sub-system 230 sends a notification message of the
assignment via email to the adjuster and logs to the eclaim
database 280 that the email was sent and the assignment was
made.
[0372] Next, when an insurance carrier adjuster logs on to the
system 30 via Deskview 200, he is first authenticated by the user
authentication system 215. Next, a message appears on Deskview 200
displaying the number of new claims the adjuster has been assigned
to further assign. The adjuster then uses Deskview 200 to view a
queue containing their respective assignments, by way of Deskview's
200 search engine type functionality. Assignments are sorted by
date displaying the most recent assignment first.
[0373] The adjuster then selects the specific claim (or suffix) and
searches the directory database 290 to find a vendor (e.g., class
shop, independent appraisal and or staff adjuster) within a certain
radius or other specific search criteria. The adjuster then selects
the appropriate vendor and fills out a work request form. The work
request form is pre-filled with data already collected and adjuster
adds additional notes or instructions using Deskview 200. The work
request form is sent via email, fax or other communication methods
to the vendors (assignees). The system 30 logs the transaction and
updates the eClaim database 280.
[0374] The vendors (assignees) acknowledge the receipt of the fax
or email assignment via a fax back or reply email. If a fax was
received, the adjuster could scan the fax and attach the digital
image to the virtual claim file, which exists in the eclaim
database 280 for the particular claim. The system 30 can
automatically log receipt of email to the eclaim 280. Internal
assignees would be automatically updated once logged into the
system and the claim or suffix is selected. Details of the
assignment and claim data stored in the eclaim database 280 can be
sent directly to the assignee. Alternatively, the assignee can
retrieve claim data related to the assignment directly using
Connection 300.
[0375] Changes of status of work completed on the claim can be sent
directly from a vendor to the system 30 via email or through
Connection 300. Updates of status of work on the claim are logged
by the system 30 to the eclaim database 280.
[0376] It should also be noted that, in the described embodiment,
most of the described subsystems are located centrally and accessed
via the web or other network. Alternately, one or more subsystems
could be located elsewhere, such as at a distributed site or could
be accessed from a redirected web site, or an ASP web site.
* * * * *