AU728124B3 - A claims system - Google Patents

Description

P/00/012 28/5/91 Regulation 3.2

AUSTRALIA

Patents Act 1990 COMPLETE SPECIFICATION PETTY PATENT

(ORIGINAL)

Name of Applicant: Actual Inventors: Address for Service: Invention Title: AUTO REPAIRS NATIONAL INFORMATION EXCHANGE PTY. LTD., A.C.N. 083 143 088, of 15 Council Street, Hawthorn, Victoria 3123, Australia Dennis Wayne SMART; Peter Desmond NOLAN; Ian Sydney GODDARD; John Maurice HOFFMAN; and Brett McLEAN DAVIES COLLISON CAVE, Patent Attorneys, of 1 Little Collins Street, Melbourne, Victoria 3000, Australia "A CLAIMS SYSTEM" The following statement is a full description of this invention, including the best method of performing it known to us: P:\OPER\DBV\24212..0 claims d-2 Nomber. 2(00 -2- A CLAIMS SYSTEM The present invention relates to a claims system and, in particular, to a system for managing an insurance claim and the relationships and transactions between people in the claims industry.

The claims industry deals with processing of insurance claims and over time has established distinct relationships and tasks for people in the industry. For most insurance claims, the people involved in processing a claim include a claimant, an insurer, an assessor and a repairer. Fleet owners and assistance centres, such as roadside assistance centres, may also be involved. At present, each person belongs to a separate industry segment, and each segment over time has developed its own procedures and databases for handling claims, generally without reference to or any attempt to become compatible with the procedures and databases used by other segments in the industry. This has hindered communication between the segments and lead to claim processing being relatively slow and inefficient. Communication between segments is also ad hoc, with individuals relying on standard methods of communication, such as telephone, facsimile and mail. The industry has many individual participants and a very large number of transactions which it needs to handle on a day to day basis, and there is considerable duplication of information between industry segments. Accordingly, it is desired to provide a system which is able to obviate the above difficulties or at least provide a useful alternative.

In accordance with the present invention there is provided a claim process executed by a claims system, including: receiving and processing identification data unique to a user; accessing role data for said user based on said identification data; T PAOPER)DBWUU24212-0X0imdoc2 No-,bm. 2000 -3generating an interface for said user based on said role data, said interface providing access to claim data for a claim and data on actions involved in. processing a claim; accessing a form for said user, in response to said user selecting one of said actions, said form including claim data depending on said role and a state of said actions; and receiving and processing data entered in said form by said user to change said state of said actions.

A preferred embodiment of the present invention is hereinafter described, by way of example, with reference to the accompanying drawings, wherein: Figure 1 is a block diagram of a preferred embodiment of a claims system; Figure 2 is a flow diagram of action modules executed by the claims system; and Figures 3 to 23 are interface pages generated by the claims system.

A claims system 2, as shown in Figure 1, includes a computer system 2 which functions as a server for a number of client computer systems 4. The clients 4 may be directly connected to the server 2, or may connect via a communications network, such as the Intemrnet 6. The server 2, in addition to its operating system, includes three basic components being a web server component 8 enabling it to deliver web pages to the clients 4, application servlets and scripts 10 and a database 12. The servlets and scripts 10 contain the programming logic which controls access by the clients 4 to the database 12 and generates web pages for the clients 4. The servlets and scripts 10 also control communication with other systems 14, such as "legacy" systems which may be maintained by users of the claims system. For example, the server 2 may be a Windows NTTM machine that uses Microsoft IISTM to provide the web server component 8, and Microsoft SQL Server 6.OTM to generate the database 12. The servlets and scripts 10 may include a number of active server pages (ASP) written in JscriptTM and other stored software components written using Java or The code for the database 12 and the servlets and scripts is written to generate the data structure and interfaces, and execute the procedures, described below. It will of course be understood that the components of the server 2 can be distributed over different systems in different locations, if desired.

-D I P:'OPER\DBW\24212-4) clams.doc-2 November. 2(X) -4- The following description of the claims system refers to a system which handles vehicle repair. As will be appreciated by those skilled in the art, the system can be adjusted to handle the processing of a claim for the repair of any insured item. Two versions of the vehicle repair system are described, one being a fleet model for owners of fleets of vehicles, the other being ~ik A1 Mj P \OPER\DBxV\IPro9500 .q9 30/3/00 a private model for owners of private vehicles.

The database 12 contains tables which are divided into two groups. The first group, being the principal tables, holds data on the claims, hereinafter referred to as jobs, and are referred to as the job, vehicle and quote tables.

The job table contains data on job registration, the vehicle, the incident, vehicle ownership, the insurance claim, the repairs required and payment status. The job table also contains data on job status and job association which defines access for user groups and relates the job to records in the quote table. The job status data is contained in a number of columns of the job table, and each column corresponds to a respective action of the claims system, as described in more detail below. An integer in the column is used to define the status of that action, such as 0 for action not required; 1 for action required, not done, not ready to be done; 2 for action required, not done, but ready to be done; and 3 for action done or completed. A date stamp is also provided for each job status column in order to mark the date when an action is done. The date is used for reporting purposes, and as described below, is displayed to users authorised to view completed forms. The job association columns of the job table specify which parties are associated with or related to the job, such as fleet, insurer, repairer and assistance centre, using identification codes for the parties, such as company identification (ID) codes.

The vehicle table contains all data on vehicles handled by the claims system, such as registration, make, model, year and owner. If desired, smaller tables can be used to hold mappings from index numbers used in HTML to actual character data for such fields as makes and models.

The quote table contains data on individual quotations and modifications to quotes. Data is also retained on quotation assessment and repair orders.

The second group of tables relate to the users, and there are five role tables which define and provide data on user groups. The role tables correspond to each role recognised by the system which a user can have. The roles and the role tables include repairer, fleet, insurer, P \OI'IE\DI\V\PP950 9 3011/3/00 -6assistance centre, and administration. Each role table contains data on companies and entities which belong to that role.

There is also a table of users which contains data for each user able to access the system.

The data includes contact information, user name, password, login audit information, access level, role and company or entity membership. Users belong to a company or entity and accordingly have a role defined in the table by an integer code, e.g. 2 for repairer, 3 for fleet, 4 for insurer, 5 for assistance centre, and 6 for administrator. A user is assigned or associated with a company by using a company identification code, which ID code is also used as entry data for one of the role tables. The roles for each user are also subdivided to further control access and execution of actions for each role. For example the fleet role is subdivided into driver and administration, with the latter having additional rights to authorise a claim form and use reports.

The insurer role is subdivided into assessor and administration with the latter having additional rights in relation to processing of a claim. The repairer role is subdivided into mechanic and administration, with the latter having additional access rights and approval authority.

The data held in the job and role tables defines the form of the interfaces and data which are generated for a user by the servlets and scripts 10, and in turn defines the actions which a user can execute on the claims system 2. Actions which can be executed by the system are as shown in Figure 2, and as will be apparent from the following description, the ability to execute an action depends on the user's role, relationship to a job, and the level of completion or status for other actions. By establishing and defining the relationships between the roles, jobs and the actions, the claims system is able to efficiently control the claim handling process for a large number of users and transactions.

The processing of an insurance claim is normally initiated by a first contact entity as shown in Figure 2, which may be either the insurer, fleet owner or repairer. A user associated with one of the entities accesses the claims system using a client system 4. A standard web browser, such as Microsoft Explorer T M or Netscape NavigatorTM, is used on the client system 4 to log on to the server 2 and begin a session with the claims system. The user logs on to the system by entering a username and password to begin execution of an authentication process (IER'I JlWaPP O0.0 301/3/00 -7which is managed by shared ASP scripts and a stored procedure of the applications 10. The username and password are checked against the user table, and if authentication is successful, the procedure returns role, company, company ID and access level data to an ASP script, which writes this information to an ASP session object for further reference during the session. The user is then logged on and a session established, and the user is directed to a home page defined by a unique home page template for each role. For example, Figures 3 to 8 show the pages generated for a user who has the role of an insurer. The roles each have a number of actions associated with them. The home page displays a menu bar 22 with at least five buttons 24 that are always visible on the page, being New Job, Current Jobs, Attention Needed, Completed Jobs, Final Jobs, and Reports. The buttons 24 provide links to pages, as described hereinafter, which give different views for jobs associated with the user. The default page is Attention Needed which is loaded when a user first logs on to the system, as shown in Figure 3. This provides a table with a list of jobs that need to be processed and which are associated with the company ID. The script for the page retrieves all jobs that have ajob service code of 2 and is associated to the logged in company ID. For each job number and other elements in the table, links are provided to other more detailed pages, as described below.

To initiate a new job, the user can select the New Job button to generate a page, as shown in Figure 4, which provides a form for the entry of details associated with the new job.

Fields which are populated already with data include the date of entry, being the current date, and list boxes filled with data from the database 12 provided for make, year, model, fleet company, insurance company and recommended repairer. The list box is populated from the database using index numbers for the form values and company IDs to access the database 12.

Before the form values are submitted to the server 2, Java script forwarded by the server 2 to the client system 4 confirms that all the required fields have been filled in. If this verification proves to be false, a display is provided to alert the user. Once the verification has been completed, then the field values are passed to an ASP script which deals with the translation of field values for importation into tables of the database 12. The claim is then registered on the system 2 and assigned a job number. The job then needs to be processed by executing the actions shown in Figure 2 and described below.

IP \OPIER\I)3W\PP9500 99 30/3/00 -8- Selecting the Current Jobs button causes generation of a page for the user, as shown in Figure 5, that provides a table of all jobs that have the logged in user's company ID associated with it and which are not yet completed. Selecting the Completed Jobs button generates a page which displays a table of all of the jobs associated with the company ID and which are completed, as shown in Figure 6. Selecting the Final jobs button produces a search page for the user which allows the user to enter data into fields, such as driver name, fleet company, and vehicle registration number in order to search for and display a particular job, as shown in Figure 7. Selecting the Reports button causes generation and display of tailored reports for the user on the claims handled by the user's company, as shown in Figure 8.

Once a user selects a particular job from one of the home page tables, the system generates ajob interface, as shown in Figure 9, which includes an action menu 26 that displays each relevant step or action which needs to be completed in order to process the claim. The status of each action is also indicated by an icon appearing next to the description of each action, the icon changing appearance to indicate the status. For example, for a completed action the status may be indicated by a tick and a red coloured icon, whereas an uncompleted action may be indicated by the absence of a tick and a different coloured icon. A white coloured icon can indicate an action to be completed by the user, with the remaining uncompleted icons being orange. The appearance of the icon also indicates which action page is being viewed by the user.

The menu 26 is also a navigation menu, where each item provides a link to an action page. The first page viewed, and the first item in the menu 26 represents the initial screen, as shown in Figure 9, which simply provides summary information for the job.

When an action is selected from one of the links in the menu 26, the user is presented with an action page, as shown in Figures 9 to 21. The action pages each consist of a HTML page displaying some data and containing a form, possibly with some fields already filled in with current values from the database 12. The user is then able to enter or edit data in the fields, and submit the data by selecting a submit button. Submitting the data by selecting the submit button triggers the script 10 to make the necessary alterations to the database 12 and, in particular, the job status record. The job status record is marked so that the current action has been completed successfully, i.e. status 3, and that further actions that depend on the current action are now 11%PER'IDI\ISOOl 99 .10/31;00 -9ready to be done, status 2, and appropriate adjustments are made by the script 10 to the icons in the menu 26. The pages shown in Figures 9 to 21, whilst displaying all of the relevant data fields, show pages for completed actions, and therefore the submit button and input and list boxes for the fields are not shown.

The actions each correspond to an ASP script or set of scripts forming an action module, and operate in conjunction with one or more stored SQL procedures of the database 12. The actions include, as shown in Figure 2, the following: First Contact 20 (for any user).

(ii) Claim Form 30 (for fleet operators).

(iii) Claim Approval 32 (for fleet operators).

(iv) Repair Quote 34 (for repairers).

Assessment 36 (for insurers).

(vi) Fleet Authority 38 (for fleet operators).

(vii) Assessor Authority 40 (for insurers).

(viii) Insurer Claim Number 42 (for insurers).

(ix) Repairer Progress 44 (for repairers).

Quote Modification 46 (for repairers).

(xi) Quote Modification Assessment 48 (for insurers).

(xii) Job Completion 50 (for repairers).

The actions each have the completion of some other action or actions as a precondition or prerequisite for their completion and each is only available to users of one role, with the exception being the First Contact action 20. Another exception is that the same action may be available to an insurer in the private model, but to a fleet manager in the fleet model. As described below, each of the action modules are able to receive http request parameters, read data from the database 12 including reading job status information from the job table, execute required calculations, send an http response to a client 4, and write data to the database 12 including writing job status information to the job table.

Whilst the data for each action can only be entered or edited by a user having the 1:IW:1 lq RDIM W[1I9 00 99 ,01ll3/O00 required role, once an action is completed, all of its details on the action page can be viewed by the other users.

The First Contact action 20, as described previously with reference to Figure 4, may be executed by one of four user roles, fleet, repairer, assistance or insurer, as shown in Figure 2, to initialise a job. When completed the details appear on the action page, as shown in Figure The user inputs basic vehicle and driver details and selects the fleet company, recommended repairer and assessing company from the lists provided by the database 12. The form of the completed fields is then submitted to the database 12 and the job initialised with a job number.

The Claim Form, Repairer Quote and Insurer Claim Number actions 30, 32 and 34 can then be completed.

The Claim Form action 30 in a fleet model is completed by a user who has a fleet role, i.e. the fleet manager. In the private model, the Claim Form action 31 is completed by the user having the role of insurer, i.e. the representative of an insurance company. The database provides the driver name and car details for the job, and the user inputs that information regarding the accident into the claim form, as shown in Figure 11. On completion of the details, the form is submitted to the database and a notification sent to the appropriate user to advise that the Claim Form Approval action 32 now needs to be completed. Notifications are sent as electronic messages or e-mail by the system.

The Claim Form Approval action 32 is executed by a user having a fleet role, and is also indicated in the user table as being an administrator or supervisor. The supervisor is able to view the claim form on the approval action page, and then approve the job or claim, as shown in Figure 12. Once the claim approval action has been completed and the details submitted to the database 12, notification is sent to the insurance or assessor company, having a role of insurer, to complete the Assess Quotation action 36. A precondition of the Assess Quotation action 36 is also that the Repairer Quote action 34 has been completed.

The Repairer Quote action 34 can only be executed by a user with a repairer role and is completed to provide basic information on the expected cost of the repair and the assessment P:A0OPER\DBW\242 12-0 lims.doc-2 No-bmer. 24X) -11and repair schedule. The user in addition to being able to enter this basic information can also attach digital images of the damaged vehicle, and if desired, scan copies of documents, such as third party quotes. All of the information and images submitted by the user are stored in the database 12. Submission of the images is particularly advantageous, as these can be reviewed by other users as desired, when executing other actions.

Completion of the Repairer Quote action 34, as shown in Figure 13, causes notification messages to be sent to the insurer or assessor company in order to attend to the Assess Quotation action 36.

The Repairer Quote action 34 can also be completed by importing the required data into the claim system from a legacy system operated by the repairer. A controlled open file format can be used with software of the repairer's system to allow the repairer to enter the required data into a file defined by the file format for the claim system. On initiation of the Repairer Quote action 34 the repairer can then simply attach the file or import the data from the file to complete the action.

The Assess Quotation action 36 can only be completed by a user who has the role of insurer, which includes vehicle assessors. The assessor reviews the repair quote provided by the repairer and would normally have previously made arrangements to view the damaged vehicle. Alternatively the assessor can simply assess the quote on the basis of the images stored in the database. The assessor can accept the amount quoted by the repairer by simply selecting Accept and Authorised in the status field of the action page, as shown in Figure 14. If however the assessor disagrees with the repairer's quote, the assessor needs to contact the repairer to agree the cost of the repair, and insert the agreed amount in the assessed amount field. Communication between the assessor and repairer can be by e-mail, as supported by the claims system. The assessor may also decide to simply write off the vehicle and thereby terminate or complete the job by selecting write off in the status box, which completes the job at step 37, as shown in Figure 2. Completion of the Assess Quotation action, except where a write off occurs, will send a notification to the fleet company to execute the Fleet Authority action 38.

P:\OPERM)BW2422I24X) limj.dom-2 Novcmbcr. 2000 1A- The Fleet Authority action 38 is to be executed by a user who has a fleet role and requires a decision by the fleet company as to whether the repair is to proceed, and the appropriate authorisation be provided. The fleet company can either accept for the repair to proceed and thereby provide an order number to track the job, or simply select no order in the provide order field, as shown in Figure 15, which also causes the job to terminate at step 39, as for a write off. If an order number is provided, as shown in Figure 15, then the insurer is notified to execute the Assess Authority action The Assess Authority action 40 is executed by a user with an insurer role and they must P )'V1IR\DBM\PP9500 90 30/01 -12provide final authority for the repair to commence. At this point, the insurance company accepts liability for the information completed in the claim form, compares it to the actual damage to the vehicle and acknowledges that the quoted repair cost is reasonable. On giving authority, as shown in Figure 16, a notification is sent to the repairer to commence the repair and execute the Repair Progress action 44.

The Repair Progress action 44 also has another prerequisite action, being the Insurer Claim Number action 42. For the repair to commence, the user having the role of insurer, must complete the action 42 in order to provide the claims system with a claim number to track the job for the insurer. On completion, a notification is sent to the repairer to commence repairs and also notification is sent to the fleet company to advise of the claim number. The fields involved are shown in Figure 17.

In the private model, the actions required to be executed in order to commence a repair are reduced. After completion of the Claim Form action 31, notifications can be sent to selected repairers to place the repair out for tender, by executing a Call for Tender action 52. This action 52 would normally be carried out by an insurer. The repairers are then required to execute a Repairer Quote action 54, similar to the Repairer Quote action 34 for the fleet model. The quotes are then assessed using an Assess Quote action 56, similar to the Assess Quotation action 36 for the fleet model. On completion of the Assess Quote action 56, notification is sent to the selected repairer to commence repairs, and begin execution of the Repair Progress action 44.

The Repair Progress action 44 can only be executed by a user who has the role of repairer. The action module 44 allows the repairer to continually update the estimated completion date and advise in a comments field of any aspects concerning the vehicle repair.

The action page generated for users is particularly useful as it provides all users with an update on the progress of the repair, as shown in Figure 18.

If desired, a repairer is able to select and execute a Quote Modification action 46, as shown in Figure 20, which also shows how the menu 26 varies depending on a user's role. The action page allows the repairer to enter in the variation amount and the reason for the variation.

1 I 014: RA) \V\fl'1)5 i) i )'099 13 A notification is then sent to the insurer in order to execute an Assess Quote Modification action 48.

The Assess Quote Modification action 48 can only be completed by a user who has an insurer or assessor role, and the insurer reviews the details of the repair quote modification provided by the database 12 and is able to accept or reject the modification by completing the fields, as shown in Figure 21. On accepting the modification, the fleet company and any other relevant parties are notified.

Once the repairs have been completed, the repairer is able to execute a Job Completion action 50 to complete details in relation to the completed repair. Once the repairer has entered and completed all of the fields in the action page for the module 50 as shown in Figure 19, the fleet is notified, and the insurance company is also notified and provided with an invoice for the repair. In the private model, an additional action 58 can be included to provide advice on the status of the payment, which will be executed by the insurer for the repairer.

I

As will be apparent from the above, users are able to track the progress of a job by selecting jobs from their home page, such as shown in Figures 3 and 5. Once a job has been selected and the details reviewed by one of the action pages, the user can return to the Attention Needed page using a browser on the client 4, and the menu 26 for that recently viewed job will remain in the left hand frame, as shown in Figure 22.

The reports which users are able to generate will vary depending on their roles and their specified requirements. For example, an insurer may wish to have a report of comparisons of average claim costs per month, as shown in Figure 8, whereas a repairer may wish to have a comparison of total job time in days, as shown in Figure 23.

The claims system described above accordingly coordinates all relationships between industry segments and users involved in the processing of an insurance claim. The system prevents the duplication of data by establishing a database that is accessible by a large number of users, who may have client systems in various locations, and is also able to handle a large S' (o)I'ER\Di[\\'Pjsil 14number of transactions. The system brings together different industry segments and users in those segments, and is able to significantly reduce transaction costs and response times by providing a central system for information exchange and communication between users, whilst controlling claim processing. While centralising control, the system advantageously enables users to access the system easily from a variety of distributed locations, as all that is required is a client system 4 that can connect to the Internet with a standard web browser.

Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as hereinbefore described with reference to the accompanying drawings.

Claims (3)

1. A claim process executed by a claims system, including: receiving and processing identification data unique to a user; accessing role data for said user based on said identification data; generating an interface for said user based on said role data, said interface providing access to claim data for a claim and data on actions involved in processing a claim; accessing a form for said user, in response to said user selecting one of said actions, said form including claim data depending on said role and a state of said actions; and receiving and processing data entered in said form by said user to change said state of said actions.

2. A claim process executed by a claims system as claimed in claim 1, wherein role data represents a role of at least one of insurer, assessor and repairer.

3. A claim process executed by a claims system as claimed in claim 1 or 2, wherein said interface is provided over a communications network, such as the Intemrnet, and said process manages steps to complete repair of an insured vehicle with input from a plurality of said user having different roles of at least insurer, assessor and repairer in distributed locations. DATED this 2 d day of November 2000 -T Q7 Auto Repairs National Information Exchange Pty Ltd By its Patent Attorneys DAVIES COLLISON CAVE