Computer system and method for work management

What is claimed is:

1. A work management system comprising: processing means, including a data bank into which data is written and from which data is read, said data bank storing information regarding an initial transaction, work source information, office staff information, policy information, information regarding dates of importance, in formation regarding work processing activities, staff case load information, and predetermined text data for preparing documents, the data bank including staff table means for storing, retrieving, displaying and modifying information about staff members who access the system, wherein said stored information includes: name, user ID, job title, supervisor, experience level, cost rate, diary rollover limit, scheduled vacation, payment authority, and staff functional and processing authority levels; at least one terminal means for communicating with said processing means and operable by at least one operator to produce requests and to enter information and/or retrieve information for writing and/or reading from said data bank; display means for displaying information that is entered and retrieved; first merging means operatively interacting with said processing means for reading out from said data bank selected information regarding work processing activities and selected office staff information and merging said read out work processing activities information and said read out office staff information to compile an activity log listing key work activities and a staff member associated with those activities; case summary means for automatically summarizing said initial transaction information; routing means for routing transaction information to a staff member for processing in response to input through one of said terminal means; and staff member electronic mailbox means for receiving said initial transaction summary and other electronic messages; assignment means for assigning a case to a particular staff member for processing in response to input through one of said terminal means; reassignment means for reassigning cases from a particular staff member to another staff member for processing, diary means for automatically and manually setting, storing and displaying dates for various activities associated with the processing of a case including means for manually overriding automatically set diary dates; activity log means for automatically recording information about transactions undertaken through the system in the processing of a case and for manually recording information and comments about other activities in the processing of a case including means for selectively displaying said recorded information and comments on said display means; inquiry means for selectively retrieving and displaying transaction information in response to input of at least one case number through one of said terminal means; system controller means for controlling an operator's movements within the system, wherein said system controller means verifies the availability of each requested function during a system session and verifies said operator's authority to access a system function prior to permitting such access; and security means comprising security level means for selectively limiting access to certain predetermined functions of the system in accordance with a preset security level associated with each authorization code.

2. A system according to claim 1, further comprising second merging means operatively interacting with said processing means for reaching out from said data bank selected information and predetermined text data and merging said read out information and said read out text data to compile final documents tailored to a case; and print means coupled to said processing means for printing said documents.

3. A system according to claim 2, further comprising directory means for selectively storing, retrieving and displaying information relating to individuals to be contacted during work processing.

4. A system according to claim 3, wherein information stored by said directory means is automatically selected by category and displayed if said second merge means is unable to compile a final document because of missing information.

5. A system according to claim 1, further comprising mailbox view means for displaying electronic messages on said display means.

6. A system according to claim 1, further comprising alert means for automatically generating and routing an alert message to a first staff member's electronic mailbox means when a predetermined criterion is breached by an operator.

7. A system according to claim 1, further comprising electronic mail means for creating and sending messages from one terminal means to another.

8. A system according to claim 1, further comprising search means for locating a case file which resulted from the input of said initial transaction information, wherein said search means requires input of at least one of the following:

a) a customer number;

b) a case number;

c) an customer's complete last name;

d) part of a customer's last name;

e) the phonetic equivalent of a customer's last name; or

f) date of initial transaction.

9. A system according to claim 1, further comprising interactive, online help means for providing assistance in using the work processing system.

10. A system according to claim 1, further comprising status change means for electronically reopening, partially reopening or closing the processing of a case.

11. A system according to claim 1, further comprising automatic numbering means to automatically assign a number to each new case for which processing is undertaken.

12. A system according to claim 1, further comprising security means for limiting access to the system to only those individuals with preselected authorization codes.

13. A system according to claim 1, further comprising windowing means for accessing and processing a plurality of different cases simultaneously at one terminal means.

14. A system according to claim 1, further comprising print queue management means for controlling the printing priority of documents.

15. A system according to claim 1, wherein said data bank stores information regarding customers.

16. A system according to claim 15, further comprising second merging means operatively interacting with said first processing means for reading out from said data bank initial transaction information and reading out customer information and merging said read out initial transaction information and said read out customer information to compile an individualized work processing record for each case to be processed.

17. A system according to claim 1, further comprising modification means for altering said information regarding an initial transaction after said information has been stored in said data bank.

18. A system according to claim 1, wherein said information regarding an initial transaction is electronically transmitted to said first processing means from a remote location and stored in said data bank.

19. A system according to claim 1, further comprising text processing means for creating, displaying, modifying and storing customized documents having at least one blank input field, wherein said blank input fields are coded for use by said second merging means to merge said read out information and customized document data in accordance with said blank input field codes to compile final documents.

20. A system according to claim 19, wherein said compiled final documents are transmitted to print queue means to permit review of said compiled documents and their characteristics prior to printing.

21. A system according to claim 1, further comprising report means for generating and formatting reports based on information stored on said data bank, wherein said reports may comprise sums, summaries and lists of any of said information stored on said data bank and may be formatted in any preferred manner.

22. A system according to claim 1, further comprising: a plurality of generic field generators for receiving alphanumeric, numeric and date input information produced at a terminal means and storing said input information for said generic fields locally in said data bank; label creation means for creating and assigning text labels to said generic fields; and programming means for arranging at least some of said generic fields into at least one specialized input screen for display at said terminal means.

Description Submit all comments and votes

TABLE OF CONTENTS

A. FIELD OF THE INVENTION

B. BACKGROUND OF THE INVENTION

C. OBJECTS OF THE INVENTION

D. SUMMARY OF THE INVENTION

E. DESCRIPTION OF THE DRAWINGS

F. GENERAL DESCRIPTION

G. DETAILED DESCRIPTION

1. System Security

2. System Controller

3. Menu Screens

4. The Loss Processing Transaction

5. Routing and Assigning Claims

6. Modifying or Augmenting the Loss Processing Transaction Information

7. Review of Claim Files

8. Transfer of Claims Between Claims Offices

9. Staff Tables

10. Directory Tables

11. Info Search

12. Activity Log

13. Claim Reassignment

14. Claim Status Changes

15. Text Processing

16. Print Queues

17. Payments

18. Windowing

19. Mailboxes

20. The Diary Function

21. Ad Hoc Reporting

22. Local Data

23. Work Management System

H. CLAIMS

A. FIELD OF THE INVENTION

This invention relates to computer systems and methods, and more particularly to such systems and methods for work management and the like.

B. BACKGROUND OF THE INVENTION

The processing and tracking of work in process in most environments is virtually non-existent or intensely manual. By way of example, the processing and tracking of damage loss claims has been a time-consuming, mostly manual process requiring multitudes of paper records. As such, claim processing and tracking is expensive, complex and relatively unreliable in maintaining the collected information.

In a typical prior art claim processing system, a claims office receives an initial notice of a loss from an insured, a claimant, a customer or an agent. The loss notification is received by mail, telephone, or in-person. By way of example, when a notice of loss is received by mail in the claims office, it is sorted into the appropriate line of insurance business (e.g. workers' compensation, automobile, property/liability, fidelity/surety etc.)(See FIG. 1). Loss notices are then delivered to one or more assistant managers and/or unit supervisors who review the notices and determine which claim "handler" actually will work on the claim(s). The supervisor also determines a diary date which is recorded on the original file to check on the status of the claim and the assigned handler's progress. The supervisor then sends a copy of the notice to that handler and calculates and notes the specific reserves to be set aside for the claim.

The original notice is given to a clerk for manual issuance of a claim number from a Register Book and for input into FOCS. (FOCS is a computer based claim recording system which relies on a mainframe computer located at a remote location to record the notice of loss. The FOCS system is used to record only actual claims and to issue certain payments. No claim adjustment support is provided to assist a claim handler in the progress of a claim to conclusion. The purpose of FOCS is essentially to assist in the maintainenance of corporate financial records.) After the notice of loss information has been input into FOCS, a file is prepared and filed.

On a daily basis, clerks search all "open" files for claims with a diary date matching the day's date (See FIG. 2). All applicable files are removed and given to the appropriate claim handler or supervisor. After the necessary action is taken the files are refiled and any new diary dates noted.

When a claimant or insured calls to check on the status of a claim the handler, supervisor or clerk must again retrieve the file from wherever it is filed (See FIG. 3). The file is reviewed as necessary and then left for a clerk for refiling. At any time while the file is not properly filed, no correspondence received or other document can be placed in the file without undertaking a search for the file.

During the time the claim is "open", key events must be recorded in an Activity Log to provide an audit trail. (The Activity Log is one or more preprinted sheets of paper which are affixed to the inside of the claim file.) As these key activities occur, the claim handler is obligated to record them in the Activity Log. If the file is not located immediately, it becomes likely that the key event(s) will be recorded inaccurately or not at all.

When work on the claim has been completed, the handler requests that the file be closed. (See FIG. 4). A closure statement is input into the FOCS system to update the corporate record and the file is stamped closed and filed in a "closed" file bank. After a specific retention period all files are put in dead storage and then eventually destroyed.

As can be clearly seen, the prior art claim processing system, like most work processing systems, requires that the file be available for virtually every activity. Thus, when files are not found in their normal location, problems arise. Still further, recording of specific key events in the Activity Log and the maintenance of diary dates depends on human diligence. As such, many things which should be done or recorded never get completed in a timely manner.

C. OBJECTS OF THE INVENTION

Accordingly it is an object of the present invention to provide a system and method for alleviating the foregoing problems and improving upon the prior systems and methods.

It is another object of the present invention to reduce the time to respond to telephone inquiries about work in process.

It is a further object to automatically and securely maintain a record of the activities of staff members in work processing.

It is yet another object to minimize the time to prepare and complete forms, letters, reports and checks in processing work.

It is a still further object to reduce paper intensity in the maintenance of records in processing work.

D. SUMMARY OF THE INVENTION

In accordance with the present invention, there is provided a system and method for substantially automating work management. To illustrate the capabilities of this system and method, reference is made to the processing of claims. This reference should not be construed as a limitation on the application of this system to other work environments.

In one preferred embodiment of the present invention supervisors and other staff members are provided with the ability to maintain an accurate record of all activities undertaken in the processing of a claim and the further ability to quickly and easily access the complete claim file at any time. In practice, the processing of a claim begins with the receipt of a notice of a loss from an insured, a claimant, a customer or an agent. These loss notices are received by mail, telephone, in person or electronically. The information from these notices is keyed into a local computer where a separate electronic file or record is created for each loss. (When the notice is transmitted to a claim office electronically it is put in the form of information which can be used to prefill fields in an Initial Input or Loss Processing transaction. This greatly cuts down on input time.)

In a preferred embodiment of the present system and method, an operator accesses the local computer through a terminal where he requests (usually through a displayed menu) a series of input screens called the Loss Processing Transaction ("LPT"). These screens, which comprise the LPT, each have a number of empty fields preceded by descriptive prompts. Information is input into the local computer, in accordance with the descriptive prompt, from the notice of loss. A separate series of LPT screens is available for each line of insurance business (e.g. workmen's compensation, automobile, property/liability, fidelity/surety, etc.). Thus, the particular LPT screens which are displayed to the input operator are formatted according to the particular line of business which is the subject of the claim.

The LPT is designed to capture information relevant to claim recording and to the loss adjustment process. All data relating to a claim which is collected, is stored in a locally supported database adapted to interface with a remotely located host computer ("Host") and its databases. The Host computer preferably maintains policy information and other information, used in the loss adjustment process, that is also employed in the regular activities of the company.

If, for example, the claim is related to an automobile, a variety of relevant information is input from the notice of loss and other sources (e.g. the insured's policy, police reports, interviews, etc.), including: information about the insured, information about the insured's policy, information regarding special procedures to be undertaken in the processing of the claim, a description of the accident, a description of any physical or property damage, information regarding any injured party, information about witnesses and/or passengers and any other relevant comments. All this information need not be input into the claim file created with the LPT immediately; it may be added subsequently as more details are uncovered during the investigation of the loss.

Prior to inputting the notice of loss information, the insured's policy information is verified by extracting such information from the local computer's databases or by interfacing with the Host and its databases, depending on where the policy information resides. This information "prefills" certain fields in the LPT thereby minimizing operator input.

Once the information requested in the LPT is input, and stored in a local database, the transaction is normally "routed", by the input operator, to a supervisor to access and review the file ("routing" generates a brief message to another staff member's "mailbox"). When a claim is routed to a supervisor, the message generated to the supervisor's "mailbox" (discussed in detail below) is a brief summary of the claim transaction. After reviewing the claim, the supervisor electronically assigns it to a particular staff member, sets at least one due date ("diary" date) for review of the progress of the claim and sets aside reserves (based on his experience and calculations) to cover the expected cost of the claim. The electronic assignment transmits a claim summary message to the assigned handler's "mailbox" in the same way the claim was originally "routed" to the supervisor.

When the claim is assigned and routed to a claim handler, an automatic numbering facility assigns the next available, appropriate number(s) to the claim(s). This facility eliminates the extra, manual step of ascertaining the next unused number(s) and recording it on the claim file and elsewhere.

The assignment of diary dates for the supervisor is done either manually or automatically. Automatic dates are calculated and set by the system based on the type of claim and the handler's experience. Manual dates are set to override or augment the automatic dates set by the system. Dates also may be set in the "diary" by the claim handler or any other staff member with appropriate authority.

Individual claim files are accessible directly by selecting a particular diary entry. When the claim is accessed from the diary in this manner an "Activity Log" associated with the particular claim is displayed. This permits the handler or supervisor to find out the most recent activity undertaken or to see particular instructions which should be followed. If a diary entry is not accessed or "rediaried" as of its date, it will "rollover" to the succeeding day until it is accessed and rediaried. This prevents dates from being missed due to an unexpected absence or illness. If a diary date rolls over too many times an "alert" message is generated to the handler's supervisor.

The diary also acts as a work load monitor because the number of claims which should be "diaried" for any given day is limited. If a supervisor/manager attempts to set a diary date on a new claim for a particular handler when the diary listing for that handler already has the maximum number of claims to be reviewed for that day, a message is displayed to the supervisor (Despite the message, the supervisor can still assign the diary date, if he desires). In this way, work can be more efficiently distributed throughout an office and one particular handler should not be overburdened.

When an LPT is used to input a notice for a new claim, an electronic Activity Log is automatically created along with the new claim file or at the time of the first activity. An Activity Log is essentially an overview of key activities associated with the loss adjustment process (e.g. payments, interviews, correspondence, etc.). Comments are electronically entered into the log to document these activities through normal keyboard entry or automatically when a system driven activity is undertaken. The date and the operator's initials are automatically entered into the log with the entry. Entries into the log are readily accessible for review by an operator and are displayed in reverse chronological order so that the most recent entries appear first.

Whenever certain functions within the system are accessed, and activities undertaken therefrom (e.g. text processing or payments), entries are automatically made to the Activity Log for that claim. The entries summarize the activity without conscious effort by the operator. Each entry consists of the date, the operator, the activity and the specifics associated with that activity (e.g. check issued for $500.00 to John Doe, etc.). The extra steps which would be required to locate the log, recall the specifics of the activity, and make a manual entry are eliminated. A handler's memory is not involved at all and the log will thus be accurate and up-to-date. Still further, the log serves as an audit trail because the Activity Log entries, once made, are secure and cannot be changed.

In a preferred embodiment of the present invention, text processing is also included within the system. This provides automatic/semi-automatic generation of forms and letters tailored to the particular office and the particular claim. In practice, the text processing function is selected and a form or letter then chosen. Most of the pre-prepared forms and letters have blank fields embedded in them to make them specific to the appropriate claim. The system automatically attempts to fill in these blank fields from information previously entered and stored in the claim database. This saves time because the operator does not need to locate the basic claim information in a paper file or even key it in. If all the necessary information to complete the document is not available from the claim file, the operator is prompted to provide it manually. When all the required fields in the document have been filled, the document's text data is sent to a print queue where it is held until released to a printer. The documents are precoded to apprise the system and an output operator (an individual in charge of the printing of forms, letter and/or checks) of the proper paper on which the correspondence is to be printed and the number of copies to be generated.

It is also preferred that an automatic payment function be included in the system. There are typically four types of payments which can be made: closing payments, repetitive payments, partial payments and reopen/close payments (these payment types will be discussed in more detail in the Detailed Description). Checks may be automatically issued for any of the three types of payments upon selection by the claim handler. The empty fields on the various payment screens are prefilled from information previously entered into the claim file (database). If insufficient information is available in the claim file to print a check, the operator is prompted to manually input the missing information in the appropriate fields.

If the requested amount of a check exceeds the specific monetary authority of the person authorizing the request the check request is automatically routed to a supervisor for approval. Thus, all checks which are finally printed have been duly authorized.

There are two ways checks can be automatically issued. With the first method the check request is sent from the local computer to the Host computer where it is processed. The Host assigns a check number and sends a check printing command to a check printing queue for printing on a check printer located in the local office. With this method the local system is only involved in the front end of the transaction. The rest of the check transaction is handled by the Host computer.

With the second method the check request is processed by the local computer which debits the local office's account in real time. (With the first method the corporate account is debited off-hours after all checks have been issued for a given day). The assignment of check numbers occurs locally and the check printing command is issued by the local computer. The Host is typically apprised of the check transactions via batch uploading from the local computer at various intervals.

As indicated above, all payments generate an entry to the Activity Log including: amount, requester, nature of benefit, payee name and check number. This happens automatically without any effort on the part of an operator.

In a preferred embodiment of the present invention, an interactive Help system is available. The Help system is generally invoked from any screen, during any operation of the system, throughout the processing of a claim. It is activated by actuating one or more "function" keys at a terminal (i.e. separate keys which do not normally generate alphanumeric characters on the display screen). The Help function initially displays transaction and/or field specific codes which are used for filling in data fields within the various screens. Actuating still other function keys provides an explanation as to how to select and move between modules and operations within the system and accomplish various transactions or activities. The Help function is used to assist an operator in the proper input of information and the manipulation of screens and functions.

An "Info Search" feature, in a preferred embodiment of the invention, permits any operator to check on the status of a claim based on only minimal information, such as: the insured's last name, the claimant's last name, the insured's policy number or the claim number. (When a claim file is created this "minimal information" is automatically entered as a record into a separate Info Search file for this purpose.) This feature is particularly valuable when an insured or a claimant telephones to check on the status of a claim. With the Info Search feature, it is not necessary to physically retrieve a paper file which may or may not be complete. Rather, the operator who receives the telephone call simply accesses Info Search function and inputs the appropriate name (full name, partial name or phonetic equivalent) and/or number to locate the electronic Info Search record containing the "minimal information". If the caller needs more detailed information, the complete claim file may be accessed, including its up-to-date Activity Log. From this an operator can quickly and easily provide the caller with a complete status report. Correspondingly, with a minimum of effort, the Activity Log may be updated to include any information imparted during the telephone call.

Directory Tables, which are included in a preferred embodiment of the present invention, function, in part, as an online telephone/address book. Any name, telephone number, address and tax code may be keyboard entered and stored in the Directory Tables. These entries are then accessible by name and can include attorneys, claimants, doctors, state agencies, etc. The Directory Tables are not claim specific and are shared by the entire office. These tables are also integrated with other system functions (e.g. Text Processing, Payments, LPT, etc.) to prefill information into their respective data fields, as necessary.

A Staff Table function provides, online, a record for each member of the claim staff. Each record includes the current title, diary limit, authority level and supervisor of the staff member as well as the maximum case load of that member. The Staff Table function is integrated with virtually every other system function. The information contained in the various Staff Table records (referred to hereinafter as "the Staff Tables") is used to verify and prefill various data fields in other system functions. The authority level, diary limit and caseload limits of each staff member are set by supervisors with appropriate authority and entered into the Staff Tables. These records can be modified, deleted or added as necessary.

Statistics regarding claim assignments are stored and monitored to determine individual and office-wide performance through a caseload monitoring function. This function allows a supervisor to assess the general nature of an individual's work load and to examine a staff member's progress on groups of claims. This feature assists the supervisors in assigning claims to particular handlers and making more efficient use of the staff.

A windowing function also is provided in a preferred embodiment of the present invention. The windowing function permits an operator to work on more than one claim by opening a "window" into other claim files while still others are being processed. (The operator can only enter data into one claim file at a time, but can switch back and forth between the various files.) This feature also allows the operator to access a second function, such as the Activity Log, and enter new information while in the middle of performing some other task (e.g. reviewing a diary). Lastly, this feature may be used to access information from the Host computer without foregoing operations undertake using the local computer. This is particularly useful when investigating the details of a policy where policy information is stored on the Host.

Just as claims can be assigned to a particular handler, they can be reassigned as well. In a preferred embodiment of the present invention, the system is capable of reassigning one or all of an individual's claims to one or more handlers or supervisor. This is helpful, for example, when a handler or supervisor is ill for an extended period of time or leaves the office permanently. The reassignment is done electronically so that the reassigned claims are passed to the new handler intact. The notice of reassignment is sent to the new handler's or supervisor's "mailbox."

As indicated above, when a claim is routed electronically from one person to another, a summary of the claim, in message form, is sent to a person's "mailbox". The mailbox, of the present invention, is analogous to an electronic in and out box. When a supervisor assigns or reassigns a claim to a handler a message appears on the handler's mailbox screen indicating that he has an assignment. Assignments are viewed through the handler's mailbox, but the complete file may be accessed to determine the actual steps to be taken.

The mailbox screen also indicates to a supervisor whether any alerts have been generated (e.g. authority level exceeded for check issuance, etc.). This enables a supervisor to pinpoint certain office problems automatically.

A number of print queue managers are also provided to allow an output operator to monitor the flow of reports, forms, letters and checks to be printed. This is helpful when a number of lengthy or specialized print jobs have created a backlog at the time that a top priority print job is sent to the printer. The print queue managers enable an output operator to shift the print jobs in the print queue to accommodate those with higher priority. The print queue managers also display any special printing information, such as number of copies, type of paper, etc.

A specialized feature, which is part of a preferred embodiment of the present invention is referred to generally as "local data." The local data feature includes a screen or set of screens which have been generically formatted to accommodate database fields of numeric, date and alphanumeric data. (A set of these screens is available for input and display for each claim). The particular display configuration of the screen or screens is selectable by the individual claims office. The purpose of the local data feature is to permit each claims office to design its own display screens to accommodate specialized information which the office desires to maintain. This information primarily is of the type needed to complete specific state agency filing requirements, but it may be used simply for statistical purposes or customer needs. The data input through the customized screens created with the local data function is intended to be kept locally in the claims office and not communicated to the Host.

In a preferred embodiment of the present invention an Ad Hoc Reporting function is provided. This function relies on a standard database query to extract information from any system database. The Reporting function may be employed to extract any combination of data required and to output the data in a user designed format. For example, this function can be used to determine all office payments for any given time period.

The Local Data function provides each office with the same number of generic numeric, date and alphanumeric fields (each of which is also of a predetermined length) to arrange into customized screens. Once these fields have been arranged into a particular display format for use in a local office, they can only be modified by an operator with the proper level of authority. Any number of these fields can be employed and there is no requirement that all/any of them be used. Since the fields are generic, they can be used in any format to store any information desired by the local claims office as long as the information conforms to the field designations. The Local Data function is integrated with Text processing such that customized forms and letter can be generated which rely on the information input through a Local Data screen or field. Since the information input through Local Data is maintained on a local database it is also available for extraction through the Ad Hoc Reporting function.

As can be clearly seen, the present invention yields substantial improvements over prior systems. Other features and advantages of the invention are set forth in the following description and drawings.

E. DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow chart depicting the manual steps undertaken when a notice of loss is received in a prior art claims office.

FIG. 2 is a flow chart depicting the manual steps associated with the use of claim diary in a prior art claims office.

FIG. 3 is a flow chart depicting the manual steps associated with the receipt of a claim status inquiry in a prior art claims office.

FIG. 4 is a flow chart depicting the manual steps associated with the "closing" of a claim file in a prior art claims office.

FIG. 5 is a schematic diagram of a work management system constructed in accordance with a preferred embodiment of the present invention;

FIG. 6 is an explanatory diagram depicting the construction of an Action Diagram;

FIG. 7 is an Action Diagram illustrating the computer program and operative steps of the System Controller; and

FIG. 8 is a block diagram depicting the interrelationship of the system functions.

F. GENERAL DESCRIPTION

FIG. 5 illustrates schematically a portion 20 of the system of the invention. The system portion 20 includes local data processing equipment at a first station 32, Host data processing equipment at a second station 30 and two separate sets of display input/output equipment at two other stations 34 and 36. (Although only two display input/output stations 34 and 36 are shown in FIG. 5, it should be understood that it is preferred to use more stations than two.)

In a preferred embodiment of the invention the Host data processing station 30 is located at a remote location. The local data processing station 32, output printing equipment 48 and 52, and the display input/output equipment 50 are all located in the claims office. (Some display input/output equipment 50 may be located at remote stations 34. Communication between the local data processing station 32 and this remote display input/output equipment 50 occurs via the modem 60.)

The data processing equipment located at the claims office includes a computer CPU 38. The computer is preferably a moderately high-speed, high-capacity computer such as a Wang VS, however, the computer can be any general purpose digital computer having sufficient speed and capacity for processing data in the system.

Also located at the claims office is a plurality of input/output devices 50, each comprising a keyboard and a display screen which are used for programming purposes as well as data input and review. The output printing equipment 48 is used to print out checks, forms, reports and various types of correspondence.

A modem 60 is used for sending and receiving data over telephone lines 64 to a modem 66 provided at the Host computer 62.

When a notice of loss is received in a claims office, an operator inputs the information received in that notice through the keyboard 68. The information is then transmitted over intraoffice lines 56 to the local computer 38 which stores the information on a disk at a disk drive 42. Information regarding the claims file which is created is routed through the intraoffice lines 56 to the electronic "mailbox" of a supervisor for review.

Typically, the supervisor reviews the newly created file on his display screen 70 and through his keyboard 68 assigns a claim handler to it and sets aside reserves. The supervisor then routes the claim (in the form of a claim summary message) to the designated handler's "mailbox" through the intraoffice lines 56.

As the claim handler processes the claim he normally accesses various functions in the system including the diary, the Activity Log, the payment transaction, etc. Each function is accessed through a keyboard 68 and consists of numerous preformatted screens which are displayed on a display screen 70. The functions are preprogrammed and run on the local computer 38. The information input in response to prompts in the functions' preformatted screens is stored in the local computer 38.

When a form, letter or check needs to be prepared, the appropriate function is accessed through a keyboard 68, the preformatted screens associated with the function are displayed on a display screen 70 and any necessary information input through a keyboard. The output to be printed is routed through intraoffice lines 56 to a local printer 48 or 52 where it goes into a print queue. (Print queue managers are available to control the printing priority). Upon exiting the print queue, the output is printed by the local printer 48 or 52 reviewed and sent out.

As mentioned above, the Host computer 62 interfaces with the local computer 38. In practice, the Host computer 62 communicates with the local computer 78 through its modem 66, the phone lines 64 and the local modem 60. In response to a request from the Host computer 62, the local computer 38 copies certain information stored in the local database and uploads it to the Host computer 62 and vice versa. This information then resides in both the Host computer 62 and the local computer 38. It is not removed from the local computer's storage facility 42 or 46.

Other valuable features of the invention will be discussed in the more detailed description which follows.

G. DETAILED DESCRIPTION

As indicated in the previous section, reference is made to the processing of claims to illustrate the features and capabilities of the system and method of the present invention. It should be understood that this is a description of only on preferred embodiment and other embodiments may be accordingly prepared by one of skill in the art.

1.