Method of modifying a business rule while tracking the modifications

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention generally relates to modifying software. More particularly, the present invention relates to a system and method for viewing, editing and/or creating business rules using a graphical user interface.

[0003] 2. Description of the Related Art

[0004] Insurance companies have been processing and settling claims associated with bodily injury for a long time. The task of evaluating, analyzing or estimating the amount of damage associated with one or more types of bodily injuries, especially trauma-induced bodily injuries, can be very complex. Complexity in the evaluation process often arises out of the fact that concurrent expertise in legal, medical and insurance fields is often required to arrive at a particular decision involving a bodily injury claim.

[0005] Several factors can affect the estimated amount of the claim associated with a bodily injury. Every accident is different and every injury is unique. Arriving at a customized evaluation of a bodily injury claim, which is unique for a specific accident, injury, etc. is desirable. Applying across-the-board standards may tend to result in an inequitable solution for one or more parties involved. External environmental factors, such as the experience level of a claims adjuster, record of accomplishment of the legal professionals, post-injury quality of life for the injured party, etc., all may affect the valuation of a claim.

[0006] During the past several years, many insurance companies have been using computer-based and knowledge-based claim-processing systems to process, evaluate, analyze and estimate thousands of claims in what is believed to be a fair and consistent manner. A knowledge-based claim-processing system may include an expert system which utilizes and builds a knowledge base to assist the user in decision making. Such a system may allow the insurance companies to define new business rules and/or use previously defined rules, in real-time. The business rules are generally written by industry experts to evaluate legal, medical, insurance conditions before arriving at a valuation of a claim.

[0007] Often business rules of knowledge-based system may encode the formulas used in evaluating insurance claims in the insurance claim processing software's source code. Thus, for example, the calculation of trauma severity values may be hard-coded into the insurance claim processing software. When there is a new business requirement or a trauma severity calculation needs to be changed, it may be necessary to change the source code. Changing the source code in a large program may be very time consuming. Additionally, care should be used to ensure that a modification is made at each location where it is needed. For example, a particular parameter that needs to be changed may appear at multiple locations throughout the source code. In some cases, the need to change the source code may result in delaying the incorporation of the updated and/or new formulas until the next software system release date. At times, a change may be needed to meet special or unique requirement of a particular user. Such a change may require that the standard formulas be modified or customized for a specific application. For example, different zones or geographic areas in the United States may have different monetary values associated with trauma severity for the same type of injury.

[0008] In comparison, some systems have been developed that use databases of rule components. Such systems may typically require that a system administrator find a particular business rule component within a database table to make changes. While viewing a database entry, it may not be apparent what affect a change to the database entry may have. For example, a database entry may be referenced by a number of business rules. If only one business rule has been identified as needing to be changed, the system administrator may have difficulty determining how to best implement the change. If the administrator changes the database entry, other business rules may be unintentionally affected. Alternately, if the administrator creates a new database entry, the database may become unnecessarily large. Another concern may be that if a mistake is made in changing a database entry, it may not be apparent in the future how or why the entry was changed, or who made the change.

SUMMARY OF THE INVENTION

[0009] Embodiments disclosed herein provide systems and methods for creating, viewing and/or modifying business rules used by an insurance claim processing system.

[0010] A rule editor may provide a user with a graphical display of at least a portion of a business rule. The graphical display may include a representation of at least a portion of business rule source code or script. The display may include multiple windows or screens corresponding to various levels of user access privileges and/or various business rule components. In an embodiment, a system for viewing, editing and/or creating insurance claim processing business rules may also include a compiler. The compiler may transform business rule source code generated by a rule editor into business rule object code.

[0011] In an embodiment, a method of generating a graphical display of an insurance claim processing business rule may include providing a plurality of business rule components. For example, the business rule components may be provided as entries in one or more database tables. The method may include accessing a first business rule component. The first business rule component may include business rule structure information. A plurality of second business rule components may also be accessed. The second business rule components may include at least one program instruction. The plurality of second business rule components may be combined according to the business rule structure information to form a graphical display of at least a portion of at least one business rule. For example, combining business rule components may include joining two or more entries from two or more database tables.

[0012] In another embodiment, a method of generating a graphical display of an insurance claim processing business rule may include accessing at least one business rule template. At least one business rule template accessed may include at least one reference to at least one program instruction. Additionally, at least one business rule template accessed may include business rule structure information regarding at least one business rule. The method may further include accessing at least one program instruction. The accessed program instruction or instructions may include at least one program instruction referenced by an accessed business rule template. At least one accessed program instruction may be displayed to a user according to the business rule structure information of at least one accessed business rule template.

[0013] In certain embodiments, a method of generating a graphical display of an insurance claim processing business rule may also include accessing one or more additional business rule components (e.g., a business rule variable, a business rule parameter and/or a value of a business rule variable). The additional business rule component(s) may be combined with the previously accessed business rule components in the graphical display of a business rule. One or more business rule component accessed may be referenced by one or more previously accessed business rule components. For example, a first business rule component accessed may include references to one or more second business rule components. In another example, business rule structural information may be accessed (e.g., in a business rule template). The business rule structural information may include a number of references to business rule components and an arrangement of the business rule components to form a business rule.

[0014] A rule editor may also determine a user's access privileges in certain embodiments. In such embodiments, the rule editor may inhibit display of a business rule or a business rule component based on the user's access privileges.

[0015] In an embodiment, a rule editor may allow a user to modify an insurance claim processing business rule. A method of modifying an insurance claim processing business rule using a rule editor may include providing a memory including a plurality of business rule components. A graphical display of at least a portion of at least one business rule may be generated by combining a plurality of business rule components. The rule editor may be configured to receive input from a user. For example, the input received may include at least one modification to at least one business rule. The rule editor may modify at least one business rule component in the memory based on the user input. For example, the rule editor may generate one or more SQL commands that modify one or more business rule components.

[0016] In an embodiment, a method of modifying a business rule may include providing a plurality of database entries. Two or more of the database entries may be combinable to form source code for at least one business rule. Two or more database entries may be combined to form a display of at least a portion of at least one business rule. Input may be received from a user modifying the display of at least one business rule. At least one SQL command may be generated. At least one SQL command may modify at least one database entry.

[0017] In certain embodiments, the method may include determining at least one modification to at least one business rule component based on the received input. In an embodiment, after receiving input from the user, the method may store a log file entry in memory. The log file entry may include information regarding at least one modification received.

[0018] In certain embodiments, the method may include determining if the user is authorized to make the modification. For example, the method may include determining access privileges of the user. In such cases, the method may further inhibit display of at least one business rule or business rule component based on the user's access privileges.

[0019] In an embodiment, a method of modifying an insurance claim adjustment business rule may provide an audit trail. For example, the method may include providing a plurality of business rule components. A graphical display of at least a portion of at least one business rule may be generated by combining a plurality of business rule components. Input may be received from a user. The input may include at least one modification to at least one business rule component. The method may store at least one log file in memory. At least one log file stored may include a record of at least one modification to at least one business rule component.

[0020] In another embodiment, a method of providing an audit trail in a rule editor may include providing a plurality of database entries. Two or more of the database entries may be combinable to form source code for at least one business rule. Two or more database entries may be combined to form a display of at least a portion of at least one business rule. Input may be received from a user. The input may modify the display of at least one business rule. At least one log file entry may be generated and stored in memory.

[0021] In various embodiments, a log file entry may include, but is not limited to an identification of the user that input at least one modification, an identification of a time that at least one modification was input and/or an identification of a user that approved at least one modification. In an embodiment where the method includes determining the user's access privileges, the method may make the modification(s) input by the user to one or more business rule components stored in memory if the user has appropriate access privileges. Alternately, if the user does not have appropriate access privileges, the modification(s) may not be processed (e.g., made to a business rule component stored in memory).

[0022] In an embodiment, a rule editor may allow a user to create a new business rule. For example, a method of generating a business rule for an insurance claim processing system may include providing a graphical display to a user. The graphical display may be configured to combine a plurality of business rule components into a business rule display. Input may be received from the user specifying business rule structure information and at least one program instruction. The input received from the user may include selecting at least one business rule component from a display. The input received from the user may include entering at least one new business rule component. The business rule structure information and at least one program instruction may be stored in memory as business rule components. The business rule structure information and at least one program instruction may be combined in the rule editor to form at least a portion of at least one business rule. In an embodiment, the method may also include receiving input from the user specifying one or more business rule variables and/or one or more business rule parameters. The specified business rule variables and/or business rule parameters may be stored in memory as business rule components. Additionally, the specified business rule variables and/or business rule parameters may be combined with the business rule structure information and at least one program instruction in the rule editor to form the business rule.

[0023] In another embodiment, a method of generating a business rule for an insurance claim processing system may include providing a plurality of program instructions and a plurality of business rule variables. At least one program instruction may be selected in a graphical display. At least one business rule variable may also be selected in a graphical display. At least one selected program instruction and at least one selected business rule variable may be arranged in the graphical display to form a business rule. The business rule may be stored in a memory. In such an embodiment, the rule editor may determine business rule structure information based on the arrangement of the at least one program instruction and/or at least one business rule variable.

[0024] In an embodiment, a rule editor may provide a human language translation of at least one business rule component in a display of a business rule. A human language translation may include one or more words in a human language that substantially describe the meaning or effect of a business rule component. A human language translation may be context specific. In an example, a method of generating such a graphical display may include providing a plurality of business rule components. At least one human language translation of at least one business rule component may be provided. Additionally, business rule structure information may be provided. The business rule structure information may specify an arrangement of two or more business rule components to form at least one business rule. A graphical display of at least a portion of at least one business rule may be generated. At least one business rule component used to form the business rule in the graphical display may be represented by at least one corresponding human language translation.

[0025] In another example, a method of generating a graphical display may include providing a plurality of database entries. The plurality of database entries may include a plurality of business rule components. At least one database entry may include at least one reference to at least one other database entry. Additionally, at least one human language translation of at least business rule component may be provided. Two or more referenced business rule components may be accessed. At least one human language translation of at least one accessed business rule component may also be accessed. A graphical display of at least a portion of at least one business rule may be generated. The graphical display may include at least one human language translation of at least one business rule component.

[0026] In yet another example, a method of generating a graphical display may include providing a plurality of business rule parameters and at least one program instruction. At least one program instruction may reference at least one business rule parameter. At least one human language translation of at least one business rule parameter may be provided. At least one of the human language translations may include a meaning of at least one business rule parameter in the context of at least one program instruction. A graphical display including at least one program instruction may be generated. At least one program instruction in the display may include at least one human language translation of at least one referenced business rule parameter.

[0027] In some embodiments, two or more human language translations may be provided in a display. In such embodiments, two or more of the translations may be in different languages.

[0028] In certain embodiments, two or more business rules may share one or more business rule components. In such embodiments, a rule editor may identify linkages between two or more business rules and/or two or more business rule components. For example, a method of providing a graphical display of a business rule may include providing a plurality of business rule components. Two or more of the business rule components may be combinable to form a plurality of business rules. A graphical display of at least a portion of at least one business rule may be provided to a user. Input may be received from the user selecting a business rule component in the graphical display. The method may include determining one or more other business rule components or business rules that reference the selected business rule component. A list may be displayed to the user. The list may include business rule components or business rules that reference the selected business rule component.

[0029] In another example, a method may include providing a plurality of business rule templates and a plurality of business rule components. Two or more of the business rule components may be combinable to form at least one business rule. A graphical display of at least a portion of at least one business rule may be generated according to a first business rule template. Input may be received from a user selecting at least one business rule component in the graphical display. The method may include determining at least one second business rule template that references at least one selected business rule component. A graphical display may be generated. The graphical display may include an identification of at least one second business rule template.

[0030] Additional embodiments may include a computer memory medium or computer system configured to implement methods as described above. Additional embodiments may include implementing methods as described above on two or more computers connected by a network. For example, the network may include the Internet.

BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Other objects and advantages of the invention will become apparent upon reading the following detailed description and upon reference to the accompanying drawings in which:

[0032]FIG. 1<i>a </i>is a block diagram illustrating the architecture of one embodiment of an insurance claims processing system;

[0033]FIG. 1<i>b </i>illustrates one embodiment of a networked insurance claim processing system;

[0034]FIG. 1<i>c </i>is a block diagram illustrating the architecture of one embodiment of an insurance claims processing system;

[0035]FIG. 2 illustrates a structure for an insurance claims processing help database that may be used for context sensitive help and for searching for terms according to one embodiment of an insurance claim processing system;

[0036]FIG. 3 illustrates a table including document header information according to one embodiment of an insurance claim processing system;

[0037]FIG. 4 illustrates a table including document text information according to one embodiment of an insurance claim processing system;

[0038]FIG. 5 illustrates an index table including terms and codes and cross-references to other tables according to one embodiment of an insurance claim processing system;

[0039]FIG. 6<i>a </i>is a flow diagrams illustrating a method for generating the various tables in an insurance claims processing help database according to one embodiment of an insurance claim processing system;

[0040]FIGS. 6<i>b </i>through <b>6</b><i>h </i>are flow diagrams illustrating a mechanism for generating relevance values for occurrences in an insurance claims processing help database according to one embodiment of an insurance claims processing system;

[0041]FIGS. 7<i>a</i>-<b>7</b><i>c </i>are flow diagrams illustrating a mechanism for providing context-sensitive help according to one embodiment of an insurance claim processing system;

[0042]FIG. 8 illustrates a display screen showing multiple panes, wherein two of the panes comprise context sensitive help information, according to one embodiment of an insurance claim processing system;

[0043]FIG. 9 is a flow diagram illustrating a mechanism for searching for insurance claims processing terms according to one embodiment of an insurance claim processing system;

[0044]FIG. 10 illustrates a display screen showing multiple panes, wherein two of the panes comprise search results information, according to one embodiment of an insurance claim processing system;

[0045]FIG. 10<i>a </i>illustrates an alternate embodiment of a display screen showing multiple panes, wherein two or more of the panes comprise search results information.

[0046]FIG. 1I shows the display screen of FIG. 10, with one of the search results panes hidden to provide more display area for claims processing information, according to one embodiment of an insurance claim processing system;

[0047]FIG. 1<i>d </i>is a network diagram of an illustrative distributed computing environment which is suitable for implementing various embodiments;

[0048]FIG. 2<i>a</i>A is an illustration of an insurance claims processing server computer architecture according to one embodiment;

[0049]FIG. 2<i>b</i>A is an illustration of an insurance claims processing client computer architecture according to one embodiment;

[0050]FIG. 3<i>a</i>A is an illustration of an insurance claims processing server software architecture for a single client according to one embodiment;

[0051]FIG. 3<i>b</i>A is an illustration of an insurance claims processing server software architecture for multiple clients according to one embodiment;

[0052]FIG. 4A is an illustration of adapter software between a rules engine and a web server according to one embodiment;

[0053]FIG. 5A illustrates the transmission of data between a web server and a web browser according to one embodiment;

[0054]FIG. 6A illustrates an example of a browser-based user interface for the insurance claims processing system according to one embodiment;

[0055]FIG. 7A is a flowchart illustrating a method of developing a web-based insurance claims processing system according to one embodiment;

[0056]FIG. 8A is a flowchart illustrating a method of hosting a web-based insurance claims processing server with various pricing models according to one embodiment;

[0057]FIG. 9A is a flowchart illustrating a method of using a reset button provided by a web-based interface to a web-based insurance claims processing server according to one embodiment;

[0058]FIG. 2B illustrates a flow chart to generate a table of contents for processing an insurance claim according to one embodiment;

[0059]FIG. 3B illustrates detail of step <b>150</b>B in FIG. 2B;

[0060]FIG. 4B is a flowchart illustrating the use of a table of contents for processing an insurance claim according to one embodiment;

[0061]FIG. 5B illustrates a screen shot of a table of contents display screen according to a first embodiment;

[0062]FIG. 5Ba illustrates a screen shot of a table of contents display screen according to a second embodiment;

[0063]FIG. 6B illustrates exemplary properties and methods associated with a display screen object according to a first embodiment;

[0064]FIG. 6Ba illustrates exemplary properties and methods associated with a display screen object according to a second embodiment

[0065]FIG. 2C is a flow chart illustrating the process of identifying critical factors affecting the fair estimate value, included in an insurance claim consultation report, according to one embodiment;

[0066]FIG. 3C illustrates a table for storing injury codes, treatment codes and contributing factor values according to one embodiment;

[0067]FIG. 2D illustrates a flow chart to transform formula data to formulas for assessing bodily injury damages claims according to one embodiment;

[0068]FIG. 3D illustrates data elements of a formula table according to one embodiment;

[0069]FIG. 2E illustrates a flow chart to transform rules data to rules for assessing bodily injury damages claims according to one embodiment;

[0070]FIG. 3<i>a</i>E illustrates data elements of a rules data table according to one embodiment;

[0071]FIG. 3<i>b</i>E illustrates data elements of a template table according to one embodiment;

[0072]FIG. 3<i>c</i>E illustrates data elements of a line text table according to one embodiment;

[0073]FIG. 4E illustrates a block diagram of the transformation of rules data to rules for assessing bodily injury damages according to one embodiment;

[0074]FIG. 2F is a flowchart illustrating a method of generating messages associated with processing an insurance claim according to one embodiment;

[0075]FIG. 3F is a flowchart illustrating a method of using a messages table associated with processing an insurance claim according to one embodiment;

[0076]FIG. 4F is an exemplary diagram of a messages table in a database according to one embodiment;

[0077]FIG. 12 illustrates an embodiment of a block diagram of a rule editor and associated database tables;

[0078]FIG. 13 depicts an exemplary embodiment of a rule editor display screen showing a template tab;

[0079]FIG. 14 depicts an exemplary embodiment of a rule editor display screen showing a variable tab;

[0080]FIG. 15 depicts an exemplary embodiment of a rule editor display screen showing a parameter tab;

[0081]FIG. 16 depicts an exemplary embodiment of a method of providing a graphical interface of an insurance claim processing business rule;

[0082]FIG. 17 depicts an exemplary embodiment of a method of providing an interactive graphical interface of an insurance claim processing business rule;

[0083]FIG. 18 depicts an exemplary embodiment of a rule editor display screen showing an SQL tab;

[0084]FIG. 19 depicts an exemplary embodiment of a method of generating new insurance claim processing business rule using a rule editor;

[0085]FIG. 20 depicts an exemplary embodiment of a rule editor display screen showing a tables tab;

[0086]FIG. 21 depicts a first exemplary embodiment of a method of providing a display of business rule components that are related using a rule editor;

[0087]FIG. 22 depicts a second exemplary embodiment of a method of providing a display of business rule components that are related using a rule editor;

[0088]FIG. 23 depicts an exemplary embodiment of a method of tracking modifications to a business rule in a rule editor;

[0089]FIG. 24 depicts an exemplary embodiment of a rule editor display screen showing an audit tab;

[0090]FIG. 25 depicts an exemplary embodiment of a rule editor display screen showing a text tab; and

[0091]FIG. 26 depicts an exemplary embodiment of a method of providing a human language translation of at least one business rule component in a rule editor.

[0092] While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.

DETAILED DESCRIPTION OF SEVERAL EMBODIMENTS

[0093] In FIG. 1<i>a</i>, an embodiment of an insurance claims processing system <b>10</b> may include a computer system <b>20</b>. The term “computer system” as used herein generally includes the hardware and software components that in combination may execute one or more computer programs. The term is used broadly to encompass any device or series of interconnected devices having at least one processor which executes instructions from at least one memory medium. The computer programs may be implemented in software, hardware, or a combination of software and hardware. A computer system's hardware generally includes a processor, memory media, and Input/Output (I/O) devices. As used herein, the term “processor” generally describes the logic circuitry that responds to and processes the basic instructions that operate a computer system. The term “memory” is used synonymously with “memory medium” herein. The term “memory medium” is intended to include an installation medium, e.g., a CD-ROM, or floppy disks, a volatile computer system memory such as DRAM, SRAM, EDO RAM, Rambus RAM, etc., or a non-volatile memory such as optical storage or a magnetic medium, e.g., a hard drive. The memory medium may comprise other types of memory as well, or combinations thereof. In addition, the memory medium may be located in a first computer in which the programs are executed, or may be located in a second different computer which connects to the first computer over a network. In the latter instance, the second computer provides the program instructions to the first computer for execution. Also, the computer system may take various forms, including a personal computer system, mainframe computer system, workstation, network appliance, Internet appliance, personal digital assistant (PDA), television system or other device.

[0094] The memory medium preferably stores a software program or programs for processing insurance claims as described herein. The software program(s) may be implemented in any of various ways, including procedure-based techniques, component-based techniques, and/or object-oriented techniques, among others. For example, the software programs may be implemented using a rule-based development tool such as PLATINUM Aion™ available from Computer Associates International, Inc. In one embodiment, PLATINUM Aion™ may combine business rule and object-oriented technologies to create and maintain complex, knowledge-intensive applications. Software developed with PLATINUM Aion™ may employ an Aion™ programming language for automation of processes which may use hundreds or thousands of business rules from a knowledge base. An Aion™ inference engine may automatically determine which rules to execute, when, and in what order. In various other embodiments, the software program may be implemented using other technologies, languages, or methodologies, as desired. A central processing unit (CPU) executing code and data from the memory medium includes a means for creating and executing the software program or programs according to the methods, flowcharts, and/or block diagrams described below.

[0095] A computer system's software generally includes at least one operating system, a specialized software program that manages and provides services to other software programs on the computer system. Software may also include one or more programs to perform various tasks on the computer system and various forms of data to be used by the operating system or other programs on the computer system. The data may include but are not limited to databases, text files, and graphics files. A computer system's software generally is stored in non-volatile memory or on an installation medium. A program may be copied into a volatile memory when running on the computer system. Data may be read into volatile memory as the data is required by a program.

[0096] A server may be defined as a computer program that, when executed, provides services to other computer programs executing in the same or other computer systems. The computer system on which a server program is executing may also be referred to as a server, though it may contain a number of server and client programs. In the client/server model, a server is a program that awaits and fulfills requests from client programs in the same or other computer systems.

[0097] The insurance claims processing system <b>10</b> may further include a display screen <b>50</b> connected to the computer system <b>20</b> and an insurance database <b>40</b> residing on an internal or external storage. The database may also be referred to as a repository. As used herein, a “database” may include a collection of information from which a computer program may select a desired piece of data. As used herein, an “insurance database” is used as a synonym for a “database” when included in or coupled to an insurance claims processing system <b>10</b>. System <b>20</b> includes memory <b>30</b> configured to store computer programs for execution on system <b>20</b>, and a CPU (not shown) configured to execute instructions of computer programs residing on system <b>20</b>. Claims processing program <b>60</b>, also referred to as application program software <b>60</b>, may be stored in memory <b>30</b>. As used herein, an “insurance claims processing program” <b>60</b> may include a software program which is configured to conduct transactions regarding insurance claims, such as by estimating the value of the insurance claims, for example.

[0098] The insurance claims processing system <b>10</b> may be used by an Insurance Company for various embodiments of a system and method for processing insurance claims using a Table of Contents (TOC). As used herein, an “Insurance Company” (IC) includes a business organization that provides insurance products and/or services to customers. More particularly, the insurance products may pertain to providing insurance coverage for accidents and the trauma-induced bodily injuries that may result due to the accident. Examples of trauma-induced bodily injuries may include, but are not limited to: loss of limb(s); bone fractures; head, neck and/or spinal injury, etc.

[0099] In one embodiment, on receiving a trauma-induced bodily injury, a customer may file an insurance claim with his/her insurance organization to cover medical and other accident-related expenses. An IC may utilize a computer-based insurance claim processing system to process insurance claims. In one embodiment, the processing may include estimating a value associated with the filed insurance claim.

[0100] As used herein, an “IC business transaction” may be defined as a service of an IC. Examples of business transactions include, but are not limited to: insurance transactions such as filing of claims, payment of claims, application for insurance coverage, and customized benefits, etc. Business transactions may also include services related to customers, insurance providers, employers, insurance agents, investigators, etc.

[0101] As used herein, an “IC insurance claim processing system” includes a series of instructions executed by a computer system for processing an IC's business transactions. A claim processing system may include one or more processing tasks. A processing task may include a sequence of one or more processing steps or an ordered list or a structured list of one or more processing steps, associated with the business transaction to be processed by the claim processing system. In one embodiment, the sequence of steps may be fixed. In another embodiment the sequence of steps may be established dynamically, in real-time. In one embodiment, the sequence of one or more steps may include an initial step, a final step, one or more intermediary steps, etc. In one embodiment, an IC user may select steps to process an insurance claim in a sequential manner. In another embodiment, the IC user may select steps to process an insurance claim in a random or arbitrary manner. Examples of processing steps may include, but are not limited to: receiving an input from a user of the IC insurance claim processing system, reading a value from a database, updating a field in a database, displaying the results of a business transaction on a computer screen, etc.

[0102] In one embodiment, the insurance claim processing system utilizes object-oriented technology to process insurance claims. In another embodiment, processing of insurance claims may utilize traditional programming languages and databases to achieve the same result. Insurance objects may be defined to represent or model real-world business features of insurance products and services. Examples of insurance objects may include, but are not limited to, objects representing the following: an insurance claim; an accident report; a settlement; an estimated claim; IC service facilities, customers, and employees; business processes such as a new insurance application and calculation of a premium; interfaces to external insurance organizations; work tasks such as calculations, decisions, and assignments; temporal objects such as calendars, schedulers, and timers; and elemental data necessary to accomplish work tasks such as medical costs, risk factors, etc.

[0103] An insurance object may be represented on the computer screen by a graphical icon or by a display listing the properties of the insurance object in graphic and alphanumeric format. An insurance claim object may be configured to gather and evaluate data for processing a filed insurance claim and to automatically make decisions about the insurance claim. The one or more processing steps associated with the processing of an insurance claim may also be configured as one or more processing step objects. In one embodiment, a display screen may be associated with a processing step. The display screen may also be represented as an object. Each display screen object may include a property to point to a previous display and another property to point to a next display screen. Each property, e.g. the next display pointer on a display screen object, may be changed dynamically by using methods associated with the display screen object. One display screen object may serve as the starting point for processing insurance claims. In one embodiment, the starting point for processing insurance claims may include acquiring an insurance claim identification number from an IC system user.

[0104] In one embodiment, during the processing of an insurance claim, a business rule and/or an IC system user input may determine that the insurance claim processing needs the execution of additional steps or tasks to continue the processing of the claim. The IC system user may provide inputs to the insurance claims processing program <b>60</b> at any display screen associated with a step included in the Table of Contents (see FIG. 2B for a discussion of the generation of the Table of Contents according to one embodiment). The insurance claim processing software may dynamically modify the number of steps and/or the sequence of their execution to complete the claim processing transaction. An IC system user working at a client system may then iterate through the claim processing steps and arrive at an estimated value for the insurance claim.

[0105] In one embodiment, upon startup, the program <b>60</b> may provide a graphical user interface to display claims processing related information on display screen <b>50</b>. It may collect user inputs, entered by using user input devices <b>52</b>, and associated with insurance claims. It may process the user inputs, access an insurance database <b>40</b>, use the contents of the insurance database <b>40</b> to estimate the insurance claim, and store it in memory <b>30</b> and/or insurance database <b>40</b>. The program <b>60</b> may display a value of the estimated insurance claim on display screen <b>50</b>. A user may view the display of the estimated insurance claim on display screen <b>50</b>, and may interactively make modifications, additions, and deletions to the estimated insurance claim.

[0106] System <b>20</b> may also include one or more user input devices <b>52</b>, such as a keyboard, for entering data and commands into the insurance claim program <b>60</b>. It may also include one or more cursor control devices <b>54</b> such as a mouse for using a cursor to modify an insurance claim viewed on display screen <b>50</b>. In response to the updating of the estimated insurance claim, the insurance claim program <b>60</b> may store the updated insurance claim in the insurance database <b>40</b>.

[0107]FIG. 1<i>b </i>illustrates one embodiment of a networked system, configured for processing insurance claims. In this embodiment, the system is shown as a client/server system with the server systems and client systems connected by a network <b>62</b>. Network <b>62</b> may be a local area network or wide area network, and may include communications links including, but not limited to: Ethernet, token ring, internet, satellite, and modem. Insurance claims processing system <b>10</b> as illustrated in FIG. 1<i>a </i>may be connected to network <b>62</b>. The insurance claim processing system software and insurance database <b>40</b> may be distributed among the one or more servers <b>70</b> to provide a distributed processing system for insurance claim transactions. In other words, an insurance claim processing transaction being processed by the insurance claim processing system may be routed to any server based upon the workload distribution among servers <b>70</b> at the time of the transaction. Insurance claim processing system servers <b>70</b> may be located on a local area network or may be geographically dispersed in a wide area network.

[0108] One or more client systems <b>80</b> may also be connected to network <b>62</b>. Client systems <b>80</b> may reside at one or more claim processing units within the insurance company. In a wide area network, client systems <b>80</b> may be geographically dispersed. Client systems <b>80</b> may be used to access insurance claim processing system servers <b>70</b> and insurance database <b>40</b>. An insurance claim-processing employee may use a client system <b>80</b> to access the insurance claim processing system and execute insurance transactions. An employee may also use a client system <b>80</b> to enter insurance claim inputs into the insurance claim processing system. One or more printers <b>90</b> may also be connected to network <b>62</b> for printing documents associated with insurance claim transactions.

[0109] In FIG. 1<i>c</i>, an embodiment of an insurance claims processing system <b>10</b> may include a computer system <b>20</b>. In one embodiment, the insurance claims processing system may provide context-sensitive help for the processing steps. In one embodiment, the context-sensitive help for a step may be automatically invoked and displayed on display screen <b>50</b> when entering the step. In one embodiment, the user may interactively invoke context-sensitive help for the step by selecting one or more interface items on the display screen <b>50</b> with a cursor control device <b>54</b> such as a mouse. In one embodiment, the user may interactively invoke context-sensitive help for the step by using an input device <b>52</b>. For example, the user may select one or more keys or a combination of keys on a keyboard to activate context-sensitive help. The context-sensitive help for each processing step may be unique, although content may appear in the context-sensitive help for two or more processing steps.

[0110] In one embodiment, information for the context sensitive help may be accessed from help database <b>400</b>. Help database <b>400</b> may include one or more documents including information that may be useful to a user in performing the various processing steps associated with insurance claims processing. Help database <b>400</b> may also include one or more tables that provide access to the information in the documents. Each table may include a plurality of records or entries that may be used to locate help information about processing steps and/or the elements in processing steps in the one or more documents in the help database <b>400</b>.

[0111] In one embodiment, a search interface may be provided in the insurance claims processing system. A user may enter in the search interface one or more terms to be searched for in help database <b>400</b> for the insurance claims processing system. The user may then initiate the search for the one or more terms. The insurance claims processing system may then search the help database <b>400</b> for entries including at least one of the one or more terms. The insurance claims processing system may locate one or more entries in the help database <b>400</b> that include at least one of the one or more terms. The insurance claims processing system may then display information on display screen <b>50</b> from the located help database <b>400</b> entries.

[0112]FIG. 2 illustrates one embodiment of an insurance claims processing help database <b>400</b> that may be used for context sensitive help and for searching for terms in an insurance claim processing system. Help database may include one or more index tables <b>402</b>, one or more header tables <b>404</b>, one or more text tables <b>406</b>, and one or more documents <b>408</b>. One embodiment may include one index table <b>402</b>, one header table <b>404</b>, and one text table <b>406</b>. In another embodiment, the header table <b>404</b> and text table <b>406</b> may be combined into one master table comprising entries for header portions and text portions of the one or more documents <b>408</b>.

[0113] Index tables <b>402</b>, header tables <b>404</b>, and text tables <b>406</b> may each include one or more records or entries. The entries in index tables <b>402</b> may each include a field comprising one or more terms or codes that may be used as keys for locating entries in header tables <b>404</b> and/or text tables <b>406</b>. The entries in index tables <b>402</b> may each also include information for locating an entry in one of the one or more header tables <b>404</b> or text tables <b>406</b>. In one embodiment, an identification number may be used to identify each entry in the one or more header tables <b>404</b> and text tables <b>406</b>. The identification number may be referred to herein as an object ID. In one embodiment, each entry in the index tables <b>402</b> may include an object ID that identifies, and that may be used to locate, one entry in one of the header tables <b>404</b> or text tables <b>406</b>. In one embodiment, index tables <b>402</b> may include two or more entries that include the same object ID. In other words, two or more index table <b>402</b> entries may indicate, or point to, the same entry in a header table <b>404</b> or text table <b>406</b>. Each entry in index tables <b>402</b> may be referred to as an occurrence of the term or code included in the index table <b>402</b> entry in the help database <b>400</b>.

[0114] In one embodiment, each entry in the header tables <b>404</b> and text tables <b>406</b> may include a unique object ID that may be used to locate the entry. In one embodiment, each entry in the header tables <b>404</b> may include a field containing a header or a portion of a header from one of the one or more documents <b>408</b>. Alternatively, each entry in the header tables <b>404</b> may include information that may be used to locate a header or a portion of a header in one of the one or more documents <b>408</b>. In one embodiment, each entry in the text tables <b>404</b> may include a field containing a text section or a portion of a text section from one of the one or more documents <b>408</b>. Alternatively, each entry in the text tables <b>406</b> may include information that may be used to locate a text section or a portion of a text section in one of the one or more documents <b>408</b>.

[0115] An example of locating headers and text in documents <b>408</b> using index tables <b>402</b>, header tables <b>404</b> and text tables <b>406</b> follows. Index table may include index entries <b>410</b> and <b>412</b>. Index entry <b>410</b> may include a term or code included in a header of one of the documents <b>408</b>. Index entry <b>410</b> may include an object ID that may be used to locate header entry <b>414</b> in one of the header tables <b>404</b>. Header entry <b>414</b> may include a portion or all of header <b>418</b> from one of the one or more documents <b>408</b>. Alternatively, header entry <b>414</b> may include information that may be used to locate header <b>418</b> in one of the one or more documents <b>408</b>. If index entry <b>410</b> includes a term, then the term may appear one or more times in header <b>418</b> and/or in the portion of header <b>418</b> included in header entry <b>414</b>. If index entry <b>410</b> includes a code, then the code may indicate that the index table entry <b>410</b> refers to a particular header or portion of a header in its entirety (i.e., this is not an occurrence of a term). In one embodiment, codes may be used to identify headers or sections of text in documents <b>408</b>. In one embodiment, codes may be included as “hidden” text in one or more sections of documents <b>408</b>, and may be used in constructing header tables <b>404</b> and text tables <b>406</b>.

[0116] Index entry <b>412</b> may include a term or code included in a text section of one of the documents <b>408</b>. Index entry <b>412</b> may include an object ID that may be used to locate text entry <b>416</b> in one of the text tables <b>406</b>. Text entry <b>416</b> may include a portion or all of text section <b>420</b> from one of the one or more documents <b>408</b>. Alternatively, text entry <b>416</b> may include information that may be used to locate text <b>420</b> in one of the one or more documents <b>408</b>. If index entry <b>412</b> includes a term, then the term may appear one or more times in text section <b>420</b> and/or in the portion of text section <b>420</b> included in text entry <b>416</b>. If index entry <b>412</b> includes a code, then the code may indicate that the index table entry <b>412</b> refers to a particular text section or portion of a text section (i.e., this is not an occurrence of a term).

[0117] Embodiments of index tables <b>402</b>, header tables <b>404</b> and text tables <b>406</b> are further described in FIGS. 3, 4, and <b>5</b>, respectively.

[0118]FIG. 3 illustrates one embodiment of a table including header information from one or more documents <b>408</b> related to insurance claims processing. The header table <b>404</b> may include a plurality of records, also referred to as entries, with one entry for each header element from the one or more documents <b>408</b> to be included in a help database <b>400</b> for the insurance claims processing system. Each entry may comprise a plurality of fields, which also may be referred to as elements of the entry.

[0119] An entry may include an object identifier (object ID) <b>100</b> for the entry. In one embodiment, the object ID <b>100</b> for the entry may be unique in the help database <b>400</b>. In one embodiment, the object ID <b>100</b> may include information that may be used to identify the document that includes the header, and the location in the document of the header. For example, the object ID <b>100</b> of the first entry in the header table <b>404</b> of FIG. 3 may indicate that the entry is for the header of the first chapter of a first document included in the help database <b>400</b>, the object ID <b>100</b> of the second entry may indicate that the entry is for the header of the first section of the first chapter of the first document, and so on.

[0120] An entry may also include the object identifier of a parent entry (parent ID <b>102</b>) for the entry. For example, the parent ID <b>102</b> of the entries for the headers of several sections in the first chapter of a document may be the object ID <b>100</b> of the entry for the header of the chapter.

[0121] An entry in the header table <b>404</b> may also include information on the location in the document of the header. For example, byte count <b>104</b> may represent the byte (character) location in the document of the start of the header. For example, the header of the first entry in the header table <b>404</b> illustrated in FIG. 3 may start at the first byte of the document; the header of the second entry may start at the 26^thbyte of the document, etc.

[0122] In one embodiment, an entry in the header table <b>404</b> may also include the alphanumeric text of the header from the document in name field <b>106</b>. When the entry is located during context sensitive help or a search, the header text in name <b>106</b> may be read from the header table and displayed on the display screen for the user to view. In another embodiment, the entry may not store the actual text for the header, but may instead include information for locating the text for the header in the document. In this embodiment, when the entry is located, the actual text of the header may be read from the document itself and displayed for the user.

[0123] The order of the columns and rows in the header table <b>404</b> as illustrated in FIG. 3 is exemplary and is not intended to be limiting.

[0124]FIG. 4 illustrates one embodiment of a table including text information from one or more documents <b>408</b> related to insurance claims processing. The text table <b>406</b> may include a plurality of entries, with one entry for each text section from the one or more documents <b>408</b> to be included in the help database <b>400</b> for the insurance claims processing system. Each entry may comprise a plurality of fields, which also may be referred to as elements of the entry. In one embodiment, the fields may be substantially similar to the fields in embodiments of the header table <b>404</b> as illustrated in FIG. 3.

[0125] An entry may include an object identifier <b>110</b> (object ID), for the entry. In one embodiment, the object ID <b>110</b> for the entry may be unique in the help database <b>400</b>. In one embodiment, the object ID <b>110</b> may include information that may be used to identify the document including the text section and the location in the document of the text section. Object ID <b>110</b> may also include information to distinguish a text table <b>406</b> entry from a header table <b>404</b> entry. For example, a non-zero last digit in the object ID <b>110</b> may indicate that the entry is a text table <b>406</b> entry and not a header table <b>404</b> entry. The entry may also include the object identifier of a parent entry (parent ID <b>112</b>) for the entry. The parent ID <b>112</b> may point to an entry in the text table <b>406</b> as the parent of the entry. The entry may also include a text field <b>116</b> that may include some or all of the text from a section of one of the one or more documents <b>408</b> in the help database <b>400</b>. When the entry is located during context sensitive help or a search, the text in text field <b>116</b> may be read from the text table and displayed on the display screen for the user to view. Alternatively, the entry may not store the actual text, but may instead include information for locating the text in the document. In this case, when the entry is located, the actual text may be read from the document itself and displayed for the user.

[0126] The order of the columns and rows in the text table illustrated in FIG. 4 is exemplary and is not intended to be limiting.

[0127]FIG. 5 illustrates one embodiment of an index table <b>402</b> for locating terms and/or codes for context-sensitive help and for interactively searching for terms in the help database <b>400</b>. Each entry in the index table <b>402</b> may represent an occurrence of a term or code in the one or more documents <b>408</b> included in the help database <b>400</b> for the insurance claims processing system. Examples of documents that may be included in the help database <b>400</b> for the insurance claims processing system include, but are not limited to: medical journals, textbooks and/or manuals, insurance claims processing manuals or guidebooks, medical glossaries and/or dictionaries, and documents including context sensitive help entries for the insurance claims processing steps, and elements of the steps, in the insurance claims processing system.

[0128] An entry in the index table <b>402</b> may include an object ID <b>140</b>. The object ID <b>140</b> may indicate a unique entry in a help information table in the help database. In one embodiment, the help database may include one or more header tables <b>404</b> as illustrated in FIG. 3 and one or more text tables <b>406</b> as illustrated in FIG. 4.

[0129] An entry in the index table may also include a term field <b>142</b>. In one embodiment, term field <b>142</b> may include one or more terms located in the one or more documents <b>408</b> in the help database <b>400</b>. In one embodiment, term field <b>142</b> may include a code representing a step or page in the insurance claims processing system or an element in a step in the insurance claims processing system. The codes may be used in invoking context-sensitive help in the insurance claims processing system. One embodiment may include one or more entries with one or more terms in term field <b>142</b> and one or more entries with codes in term field <b>142</b>.

[0130] An entry in the index table <b>402</b> may also include a Soundex field <b>144</b>. Soundex is a commonly used algorithm for encoding words so that similar sounding words encode the same. In one embodiment, the first letter of a word to be converted to a Soundex equivalent may be copied unchanged, and then subsequent letters may be encoded as follows: <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="105PT" align="center" /><thead><row>&lt;entry /&gt;&lt;entry /&gt;</row><row>&lt;entry /&gt;<entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row>&lt;entry /&gt;<entry>b, f, p, v</entry><entry>−&gt; “1”</entry></row><row>&lt;entry /&gt;<entry>c, g, j, k, q, s, x, z, ç</entry><entry>−&gt; “2”</entry></row><row>&lt;entry /&gt;<entry>d, t</entry><entry>−&gt; “3”</entry></row><row>&lt;entry /&gt;<entry>l</entry><entry>−&gt; “4”</entry></row><row>&lt;entry /&gt;<entry>m, n, ñ</entry><entry>−&gt; “5”</entry></row><row>&lt;entry /&gt;<entry>r</entry><entry>−&gt; “6”</entry></row><row>&lt;entry /&gt;<entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0131] Other characters may be ignored and repeated characters may be encoded as though they were a single character. Encoding may stop when the resulting string is four characters long, adding trailing “0”s if it is shorter. As an example, “SMITH” or “SMYTHE” may both be encoded as “S530”. The Soundex equivalent may be used for locating entries in index table when a user mistypes or misspells a word when initiating a search. In one embodiment, codes for steps and step elements are not given a Soundex equivalent, as a Soundex equivalent of a code is not generally useful.

[0132] Columns <b>146</b>, <b>148</b>, and <b>150</b> may be used during calculation of the relevance of an entry. For each entry in the index table <b>402</b>, column <b>146</b> may indicate the position of the term or code in the text section or header in which this occurrence of the term or code appears. Column <b>148</b> may indicate the total count of words in the text section or header. For example, in the first entry of the index table <b>402</b> as illustrated in FIG. 5, the position column <b>146</b> indicates that the term “System” appears as the fifth word of the 54 words (from the total words column <b>148</b>) in the text section indicated by the object ID column <b>140</b>. Examining the second entry, the term “System” appears again as the ninth word of the same text section.

[0133] In one embodiment, the word count column <b>150</b> may be used with entries for headers in calculating the relevance value <b>152</b>. Different information and methods may be used for calculating the relevance of occurrences of terms and codes appearing in headers than the information and methods used to calculate the relevance for terms and codes appearing in text sections. In calculating the relevance for headers, the percent of the total word count indicated in column <b>150</b> may be used as part of the calculation. The word count <b>150</b> indicates how many words make up the one or more words (or words represented by a code) as represented in column <b>142</b>. For example, in the header entry in the seventh row of the index table as illustrated in FIG. 5, the term “Anatomy” is in the third position (as indicated by column <b>146</b>) of three words (as indicated by column <b>148</b>) and includes one word. Thus, when calculating the relevance, “Anatomy” is approximately 33% of the header.

[0134] The last column of the index table <b>402</b> illustrated in FIG. 5 may hold a calculated relevance <b>152</b> for the occurrence. The relevance may be calculated in advance for all occurrences. Alternatively, the relevance for occurrences may not be calculated in advance and stored in the index table <b>402</b>, but instead may be calculated dynamically as needed. In one embodiment, columns <b>146</b>, <b>148</b>, and <b>150</b> may not be stored in the index table <b>402</b>. Instead, the information may be used to calculate the relevance and then discarded. One embodiment of the index table <b>402</b> may include only an object ID <b>140</b>, a term <b>142</b>, and a relevance value <b>152</b>. Another embodiment of an index table <b>402</b> may only include an object ID <b>140</b> and a term <b>142</b>, and the relevance may be calculated dynamically.

[0135] In one embodiment, occurrences in headers may be considered of higher relevance than occurrences in text sections. Therefore, different methods may be applied to calculate the relevance of occurrences in headers than are applied to calculate the relevance of occurrences in text sections. In one embodiment, relevance values may be scaled to be between 0.0 and 1.0, with 1.0 being the highest relevance. In one embodiment, the relevance may be calculated so that a relevance value of 0.0 does not occur. Note that any scale may be used for the relevance calculation, as it may be the ordering of the relevance values that is useful, and not necessarily the scale on which the relevance values are calculated.

[0136] In one embodiment, a maximum relevance value may be provided for occurrences in text sections. This maximum value may be applied as a weight or scaling factor during the relevance calculation. In one embodiment, the maximum relevance value for occurrences in text sections may also serve as the minimum value for occurrences in headers. In this embodiment, header occurrences may always have at least as high a relevance value as the highest relevance text occurrences. In another embodiment, header occurrences may always have a higher relevance value than the highest relevance text occurrences.

[0137] The following is an example of using the tables in FIGS. 3, 4 and <b>5</b> for context-sensitive help in an insurance claims processing system. A user of the insurance claims processing system may begin processing of an insurance claim. The system may enter the first step in the processing of the claim. The first step may be displayed in a “page” on the display screen for the user. Information about the first step and the display page for the first step may be stored in the computer executing the insurance claims processing system. In this information, a code for the step, which may also be viewed as a code for the page, may be stored. When the step is entered, the code may be read from the information, and the context-sensitive help system may search the index table <b>402</b> for one or more entries with a code in term field <b>142</b> matching the code for the step. Upon locating the one or more entries in the index table <b>402</b>, the context-sensitive help system may locate one or more entries in the header tables <b>404</b> and/or text tables <b>406</b> in the help database <b>400</b> corresponding to the object IDs <b>140</b> in the entries in the index table <b>402</b>. The header and text from the located one or more entries in the header tables <b>404</b> and/or text tables <b>406</b> may then be displayed as help information items on the display screen for the user. There may be one help information item displayed for each located entry in the index table <b>402</b>. In one embodiment, the help information items may be displayed in an order of relevance using the relevance values <b>152</b> for the located entries in the index table <b>402</b>.

[0138] Elements within a step may also be given a code, and the code may be included in one or more entries in the index table <b>402</b>. When a step in insurance claims processing is entered, one or more codes for one or elements of the step may also be read from stored information about the step. Occurrences of help information for the one or more codes may be searched for, ranked by relevance, and displayed similarly to, and along with, the code for the step as described above.

[0139] The order of the columns and rows in the index table <b>402</b> illustrated in FIG. 5 is exemplary and is not intended to be limiting.

[0140]FIG. 6<i>a </i>is a flow diagram illustrating one embodiment of a mechanism for generating an insurance claims processing help database <b>400</b>. In step <b>430</b>, one or more documents may be processed into header tables <b>404</b> and text tables <b>406</b>. In one embodiment, one entry is added to a header table <b>404</b> for each header in the one or more documents <b>408</b> in the help database <b>400</b>. In one embodiment, one entry may be added to a text table <b>406</b> for each text section in the one or more documents <b>408</b> in the help database <b>400</b>. An object ID may be assigned to each entry added to a header table <b>404</b> or text table <b>406</b>. A parent ID of each entry may also be identified. The number of bytes in the section of text or header for the entry may also be determined. In one embodiment, the entry for each occurrence may include the object ID, parent ID, byte count and text section for text table <b>406</b> entries or header text for header table <b>404</b> entries.

[0141] In step <b>432</b>, one or more index tables <b>402</b> may be generated. In one embodiment, a plurality of terms may be searched for in the header text of the entries in the one or more header tables <b>404</b> and in the text section of the entries in the one or more text tables <b>406</b>. Each located occurrence of each term may be recorded as an entry in an index table <b>402</b>. In one embodiment, one or more codes may be associated with headers and/or text sections in the one or more documents, and the one or more codes may be searched for in the header tables <b>404</b> and text tables <b>406</b>. Each located occurrence of each code may be recorded as an entry in an index table <b>402</b>. In one embodiment, a code may be used to identify a particular section of text or header in the one or more documents <b>408</b>. For example, a code may be used to identify a section of text that may be displayed as the context sensitive help for a step in the insurance claims processing step. In one embodiment, an entry may be added to the index table for each occurrence of a term or code located in the name field <b>106</b> of an entry in a header table <b>404</b> or in the text field <b>116</b> of an entry in a text table <b>406</b>. In step <b>434</b>, the object ID of the header table <b>404</b> entry or text table <b>406</b> entry where each occurrence was located may be inserted in the object ID field <b>140</b> of the index table <b>402</b> entry for the occurrence.

[0142] In step <b>436</b>, one or more other fields may be added to the entries in the index table <b>402</b>. In one embodiment, a Soundex equivalent <b>144</b> may be added to entries that include a term in the term field <b>142</b>. In one embodiment, a Soundex equivalent <b>144</b> may not be added for entries with a code in the term field <b>142</b>. In one embodiment, for each entry in the index table <b>402</b>, the position of the term or code in the text section or header in which this occurrence of the term or code appears may be entered in a position field <b>146</b>. In one embodiment, the total count of words in the text section or header may be entered in a total words field <b>148</b>. In one embodiment, for each header table <b>404</b> entry in the index table <b>402</b>, a word count <b>150</b> may be entered that indicates the number of words in the term <b>142</b> for this occurrence. In one embodiment, for occurrences in text tables <b>406</b>, a word count of zero may be entered.

[0143] In step <b>438</b>, the relevance value <b>152</b> for each occurrence may be calculated and entered in index table <b>402</b>. In one embodiment, the relevance value <b>152</b> for each occurrence may be calculated up front, when the help database tables are generated. In another embodiment, the relevance value <b>152</b> for an occurrence may be calculated dynamically when the occurrence is located for display in the insurance claims processing system. In this embodiment, the index table <b>402</b> may not include a relevance value <b>152</b> for each occurrence.

[0144]FIGS. 6<i>b </i>through <b>6</b><i>h </i>expand on step <b>438</b> of FIG. 6<i>a </i>and further describe several embodiments of a mechanism for calculating the relevance values <b>152</b> of occurrences in the help database. In FIG. 6<i>b</i>, the relevance values <b>152</b> for occurrences in text sections of the one or more documents may be calculated in step <b>450</b>. In step <b>452</b>, the relevance values <b>152</b> for occurrences in headers of the one or more documents may be calculated. In one embodiment, a different mechanism may be used to calculate the relevance values <b>152</b> for occurrences in headers than the mechanism used to calculate the relevance values <b>152</b> for occurrences in text sections.

[0145]FIG. 6<i>c </i>expands on step <b>450</b> of FIG. 6<i>b </i>and further describes one embodiment of a mechanism for calculating relevance values <b>152</b> for occurrences in text sections of the one or more documents in the help database. In step <b>460</b>, the position <b>146</b> of the occurrence in the text section may be subtracted from the total words <b>148</b> for the text section. In one embodiment, the words in the text section may be numbered in a sequence from a first word to a last word. In one embodiment, the first word may be numbered as word 0, and the last word as word (N−1), where N is the total number of words in the text section. In another embodiment, the first word may be numbered as word 1, and the last word as word N, where N is the total number of words in the text section. In this embodiment, in step <b>462</b>, the results of step <b>460</b> may be incremented by one, which may be effective to prevent the relevance value from being zero. For example, applying step <b>460</b> to word 10 in a section with 10 words produces (10−10)=0. Incrementing by one thus may assure that a relevance of zero is not produced. One skilled in the art will recognize that there may be various other methods for assuring that a relevance of zero is not produced. In yet another embodiment, the words may be numbered in reverse order, with the first word in the text section being numbered as word N, and the last word as word 1. In this embodiment, steps <b>460</b> and <b>462</b> may not be performed.

[0146] In step <b>464</b>, the results of step <b>462</b>, or the results of step <b>460</b> in embodiments in which step <b>462</b> is not performed, may be divided by the total words <b>148</b> for the text section to produce a ratio R1 that may represent the relevance value <b>152</b> for the text occurrence. In embodiments where steps <b>460</b> and <b>462</b> are not performed, in step <b>464</b>, the word number of the term in the text section may be divided by the total words <b>148</b> to produce the ratio R1. In one embodiment, the ratio R1 may be in the range (0&lt;R1&lt;=1.0). In one embodiment, occurrences in headers may be considered more relevant than occurrences in text sections. In this embodiment, in step <b>466</b>, R1 may be multiplied by a first scaling factor S1 to lower the relevance values of text section occurrences in relation to occurrences in headers. For example, a scaling factor S1 of 0.33 may be applied to R1. Thus, in on embodiment, after step <b>466</b>, R may be in the range (0&lt;R1&lt;=S1).

[0147] In one embodiment, in step <b>467</b>, the output of step <b>466</b>, or the output of step <b>464</b> in embodiments where step <b>466</b> is not performed, may be rounded to a number of significant digits. Various rounding methods may be used including rounding up, rounding down, and rounding to the nearest value. For example, if two significant digits are desired, the results may be rounded to produce results in the range (0.01-1.00) inclusive. In step <b>468</b>, the results are output as the relevance value <b>152</b> for the occurrence in the text section. In one embodiment, the output relevance value <b>152</b> may be written to the index table <b>142</b>.

[0148] The following is an example of applying one embodiment of a mechanism for calculating the relevance value for a text occurrence and is not intended to be limiting in any way. The first row of the index table <b>402</b> as illustrated in FIG. 5 shows that the term “System” appears as the fifth of 54 words in a text section. A first scaling factor S1 of 0.33 is to be applied and the results rounded to two significant digits. Applying the steps of FIG. 6<i>c</i>: <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="126PT" align="left" /><thead><row>&lt;entry /&gt;&lt;entry /&gt;</row><row>&lt;entry /&gt;<entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row>&lt;entry /&gt;<entry>Step 460:</entry><entry>54 − 5 = 49</entry></row><row>&lt;entry /&gt;<entry>Step 462:</entry><entry>49 + 1 = 50</entry></row><row>&lt;entry /&gt;<entry>Step 464:</entry><entry>50/54 = @ 0.925925</entry></row><row>&lt;entry /&gt;<entry>Step 466:</entry><entry>0.925925 * 0.33 = 0.30555525</entry></row><row>&lt;entry /&gt;<entry>Step 467:</entry><entry>Round (0.30555525) = 0.31</entry></row><row>&lt;entry /&gt;<entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0149]FIG. 6<i>d </i>expands on step <b>452</b> of FIG. 6<i>b </i>and further describes one embodiment of a mechanism for calculating relevance values <b>152</b> for occurrences in headers of the one or more documents in the help database. In step <b>470</b>, a first relevance value based on the position of the term in the header may be calculated. In step <b>472</b>, a second relevance value based on the percentage of the header the term occupies may be calculated. In step <b>474</b>, the positional and percentage relevance values may be combined. In one embodiment, occurrences in headers may be considered more relevant than occurrences in text sections. In this embodiment, in step <b>476</b>, the relevance value may be adjusted using a first scaling factor to adjust the relevance value in relation to the relevance values of occurrences in text sections. In one embodiment, in step <b>477</b>, the output of step <b>476</b>, or the output of step <b>474</b> in embodiments where step <b>476</b> is not performed, may be rounded to a number of significant digits substantially similarly to the rounding method used in step <b>467</b> of FIG. 6<i>c</i>. In step <b>478</b>, the results may be output as the relevance value <b>152</b> for the occurrence in the header. In one embodiment, the output relevance value <b>152</b> may be written to the index table <b>142</b>.

[0150]FIG. 6<i>e </i>expands on step <b>470</b> of FIG. 6<i>d</i>, illustrating one embodiment of a mechanism for calculating the positional relevance of an occurrence in a header. In one embodiment, this mechanism may be substantially similar to the mechanism described in steps <b>460</b> to <b>464</b> of FIG. 6<i>c</i>. In step <b>480</b> of FIG. 6<i>e</i>, the position <b>146</b> of the occurrence in the header may be subtracted from the total words <b>148</b> for the occurrence. In one embodiment, in step <b>482</b>, the results of step <b>480</b> may be incremented by one, which may be effective to prevent the relevance value from being zero. One skilled in the art will recognize that there may be various other methods for assuring that a relevance of zero is not produced. In step <b>484</b>, the results of step <b>482</b>, or the results of step <b>480</b> in embodiments in which step <b>482</b> is not performed, may be divided by the total words <b>148</b> for the occurrence to produce a ratio R2 that may represent the relevance value <b>152</b> for the header occurrence. The ratio R2 may be in the range (0&lt;R2&lt;=1).

[0151]FIG. 6<i>f </i>expands on step <b>472</b> of FIG. 6<i>d</i>, illustrating one embodiment of a mechanism for calculating the percentage relevance of an occurrence in a header. In one embodiment, a term may include one or more words. In step <b>486</b>, the number of words <b>150</b> in the term <b>142</b> may be divided by the total number of words <b>148</b> in the header to produce the percentage of the header occupied by the term. For example, if a term comprises two words, and a header where an occurrence of the term is found comprises three words, then the percentage relevance may be calculated as ⅔=0.667.

[0152]FIG. 6<i>g </i>expands on step <b>474</b> of FIG. 6<i>d </i>and illustrates one embodiment of a mechanism for combining the positional relevance as calculated in FIG. 6<i>e </i>and the percentage relevance as calculated in FIG. 6<i>f </i>for an occurrence in a header. In one embodiment, the positional relevance may be multiplied by a second scaling factor S2 in step <b>490</b>. In step <b>492</b>, the percentage relevance may be multiplied by (1−S2). In one embodiment, the percentage relevance may be considered more important than the positional relevance, and thus the percentage relevance may be given a larger weight than the positional relevance. For example, S2 may be assigned a value of 0.33, and the positional relevance multiplied by S2. The percentage relevance may then be multiplied by (1−S2)=0.67. In step <b>494</b>, the scaled position and percentage relevance values may be added to produce the relevance value for the occurrence in the header.

[0153] In one embodiment, occurrences in headers may be considered more relevant than occurrences in text sections. FIG. 6<i>h </i>expands on step <b>476</b> of FIG. 6<i>d </i>and illustrates one embodiment of a mechanism for adjusting the header relevance value in relation to the relevance values of occurrences in text sections. In step <b>496</b>, the header relevance value results of step <b>494</b> may be multiplied by (1−S1), where S1 is the first scaling factor as described in step <b>466</b> of FIG. 6<i>c</i>. For example, if S1=0.33, then the combined relevance value may be multiplied by (1−0.33)=0.67. In one embodiment, the scaled header relevance value may then be adjusted by adding the first scaling factor S1 to the header relevance value, so that the minimum header relevance value is higher than the maximum text section relevance value. For example, if S1=0.33, then the maximum text section relevance value may be 0.33. By applying step <b>498</b>, the minimum header relevance value may be 0.34. In one embodiment, after performing steps <b>496</b> and <b>498</b>, a header relevance value R3 may be within the range ((S1+1)&lt;=R&lt;=1.0).

[0154] The following is an example of applying one embodiment of a mechanism for calculating the relevance value for a header occurrence and is not intended to be limiting in any way. The eighth row of the index table <b>402</b> as illustrated in FIG. 5 shows that the term “Anatomy” appears as the second of five words in a header. A first scaling factor S1=0.33 and a second scaling factor S2=0.3 are to be used, and the results rounded to two significant digits. Applying the steps of FIGS. 6<i>d</i>-<b>6</b><i>h</i>: <tables id="TABLE-US-00003" num="3"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="91PT" align="left" /><colspec colname="2" colwidth="105PT" align="left" /><thead><row>&lt;entry /&gt;&lt;entry /&gt;</row><row>&lt;entry /&gt;<entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row>&lt;entry /&gt;<entry>Step 470 (FIG. 6e):</entry>&lt;entry /&gt;</row><row>&lt;entry /&gt;<entry>Step 480:</entry><entry>5 − 2 = 3</entry></row><row>&lt;entry /&gt;<entry>Step 482:</entry><entry>3 + 1 = 4</entry></row><row>&lt;entry /&gt;<entry>Step 484:</entry><entry>4/5 = 0.8</entry></row><row>&lt;entry /&gt;<entry>Step 472 (FIG. 6f):</entry></row><row>&lt;entry /&gt;<entry>Step 486:</entry><entry>1/5 = 0.2</entry></row><row>&lt;entry /&gt;<entry>Step 474 (FIG. 6g):</entry></row><row>&lt;entry /&gt;<entry>Step 490:</entry><entry>0.8 * 0.3 = 0.24</entry></row><row>&lt;entry /&gt;<entry>Step 492:</entry><entry>0.2 * (1.0 − 0.3) = 0.14</entry></row><row>&lt;entry /&gt;<entry>Step 494:</entry><entry>0.24 + 0.14 = 0.38</entry></row><row>&lt;entry /&gt;<entry>Step 476:</entry></row><row>&lt;entry /&gt;<entry>Step 496:</entry><entry>0.38 * (1.0 − 0.33) = 0.2546</entry></row><row>&lt;entry /&gt;<entry>Step 498:</entry><entry>0.2546 + 0.33 = 0.5846</entry></row><row>&lt;entry /&gt;<entry>Step 477:</entry></row><row>&lt;entry /&gt;<entry>Round (0.5846) = 0.58</entry></row><row>&lt;entry /&gt;<entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0155]FIGS. 7<i>a </i>through <b>7</b><i>c </i>are flow diagrams describing embodiments of a mechanism for providing context-sensitive help in an insurance claims processing system. FIG. 7<i>a </i>illustrates a high-level view of the entire process, while FIGS. 7<i>b </i>and <b>7</b><i>c </i>give more detail of various steps of FIG. 7<i>a. </i>

[0156] In FIG. 7<i>a</i>, a user may initiate processing of an insurance claim in the insurance claims processing system in step <b>300</b>. The insurance claims processing may begin at a first processing step, and may continue through a number of processing steps until the insurance claim has been processed. A next processing step may be determined by the user input at a current processing step. Each processing step may be displayed to the user in one or more pages on a computer display screen.

[0157] In step <b>302</b>, the claims processing system may enter a processing step and display a page for the processing step. In step <b>304</b>, the context-sensitive help for the page may be invoked. Context-sensitive help for each processing step may be unique, although content may appear in the context-sensitive help for two or more processing steps. Context-sensitive help may also be unique for each of the one or more pages within a processing step. In step <b>306</b>, the page for the processing step may be displayed along with the context-sensitive help for the page. In one embodiment, the context-sensitive help for the page may instead replace the display of the page for the processing step. In one embodiment, the displayed page may occupy substantially the entire display screen on the display device. In another embodiment that supports windows, the page may be displayed in a window on the display screen. In one embodiment, the page may be divided into two or more panes, the context-sensitive help may be displayed in one or more panes on the page, and the processing step contents may appear in one or more panes on the page.

[0158]FIG. 7<i>b </i>illustrates step <b>304</b> of FIG. 7<i>a </i>in more detail. In step <b>304</b> of FIG. 7<i>a</i>, the context-sensitive help for the page is invoked. In step <b>308</b>, items to be searched for in the context-sensitive help system may be determined. In one embodiment, each page in the insurance claims processing system may have a unique code, which may be referred to as a page ID. The page ID for the invoked page may be read. In one embodiment, the page ID may be stored with information describing the page that is read by the claims processing system prior to displaying the page. The information may describe the format and contents of the page. Alternatively, the page ID may be “hardcoded” into the code of the claims processing system.

[0159] The page may include one or more elements that have associated codes. The codes for the one or more elements on the page may also be read. In one embodiment, the elements on the page may be system-supplied “answers” to questions posed to the user during the claims processing. In one embodiment, the answers may be classifications for injuries, anatomical regions, etc. used during injury claims processing. In another embodiment, instead of reading codes for the elements, the text of the elements may be read.

[0160] In step <b>310</b>, the insurance claims processing system may search one or more index tables as illustrated in FIG. 6 for entries including the page ID that may be used to locate help entries for the page in one or more help tables as illustrated in FIGS. 4 and 5. The index table may also be searched for entries for the elements of the page. In one <b>10</b> embodiment, a code for an element is used to search the one or more index tables for entries. In another embodiment, the text of the elements is used to search the one or more index tables for entries.

[0161] In step <b>312</b>, one or more entries may be located in the one or more index tables. In one embodiment, there will be at least one entry located for the page ID in the one or more index tables. In one embodiment, if elements of the page have an associated code, there will be at least one entry located for each code in the one or more index tables. In one embodiment, each entry in the one or more index tables may indicate an occurrence in the one or more documents included in the help database for the insurance claims <b>20</b> processing system of the page ID, code, or term included in the index table entry.

[0162] In step <b>314</b>, entries may be located in one or more help tables using information from the entries located in the one or more index tables for the page ID and any elements of the page. The help tables may be substantially similar to the tables illustrated in FIGS. 254 and 5. In one embodiment, each entry in an index table includes an object ID. The one or more help tables may be searched for occurrences of the object ID in each located entry. In one embodiment, the object ID may include information used to determine which help table the object ID is found in. For example, the last two digits of the object ID may indicate if the object ID is an entry for a header table similar to the one illustrated in FIG. 4 or for a text table similar to the one illustrated in FIG. 5. In one embodiment, there may be one entry in the help tables for each object ID. In one embodiment, a particular object ID may be included in one or more entries in an index table.

[0163]FIG. 7<i>c </i>illustrates step <b>306</b> of FIG. 7<i>a </i>in more detail. In step <b>306</b> of FIG. 7<i>a</i>, the context-sensitive help for the page may be displayed. In step <b>320</b> of FIG. 7<i>c</i>, the located help table entries may be ranked by relevance. In one embodiment, the entries in the index table may include a relevance value. The located help table entries may be ranked from highest relevance to lowest relevance. Entries with the same relevance may be ranked by any of several methods, including, but not limited to: alphabetic ranking and order of appearance in the index table. In one embodiment, the located help table entries may be listed without ranking for relevance. In one embodiment, any entries found for the page code may be displayed at the top of the list regardless of the relevance ranking of the entry. Entries for other codes in the page may then be ranked below the page code entry or entries in order of relevance. In one embodiment, when there is more than one term being searched for, located entries may be first ranked on the number of search terms the entries include. A header or text section of a document may include one or more occurrences of the page ID, codes, or terms being searched for. Entries that include more search terms may be ranked higher than entries with fewer search terms. The entries within the ranking categories may then be ranked by relevance within the category. Thus, entries with lower relevance, but more search terms, may appear higher in the overall ranking than entries with higher relevance, but fewer search terms.

[0164] In step <b>322</b>, information from the located help table entries may be displayed. In one embodiment, the entries may be displayed in the order of relevance as determined in step <b>320</b>. The help table entries may include portions of text from one or more documents related to insurance claims processing. Some help table entries may include section headers from the one or more documents. Some help table entries may include text from the bodies of sections of the one or more documents. Some help entries may include glossary information from the one or more documents. Other entries may include text from other portions of the one or more documents. In one embodiment, the relevance value may also be displayed.

[0165] In step <b>324</b>, information describing the location of the displayed portions of text in the one or more documents may be displayed. This information may allow the user to look up (electronically or manually) located occurrences in the one or more documents. The location information may include, but is not limited to: document title, chapter title, and/or number, chapter or section header, section number and/or title, page number, number of occurrences in the section, etc.

[0166] In one embodiment, the page display may be split into sections, or panes. In one embodiment, the information from the located help table entries may be displayed in a first pane; the information describing the location in the one or more documents of displayed portions of text may be displayed in a second pane; and the step information may be displayed in a third pane. In one embodiment, separate windows may be used to display the information from the located help table entries, the locations in the one or more documents, and the step information.

[0167]FIG. 8 illustrates one embodiment of a display screen <b>200</b> showing multiple panes, wherein two of the panes comprise context sensitive help information for a step and the elements of the step. In this embodiment, pane <b>202</b> may display a step in the processing of an insurance claim. One or more step elements <b>203</b> may be displayed in pane <b>202</b>. One or more context sensitive help occurrences for the step may be displayed in pane <b>230</b>. One or more context sensitive help occurrences for the elements in the step may also be displayed in pane <b>230</b>. Locations for the context sensitive help occurrences displayed in pane <b>230</b> may be displayed in pane <b>232</b>. In one embodiment, a location may be displayed as a chapter hierarchy of the document in which the occurrence is found.

[0168]FIG. 9 is a flow diagram illustrating one embodiment of a mechanism for searching for insurance claims processing terms. In one embodiment, the search mechanism may use the same one or more index tables and one or more help tables as are used in the mechanism for providing context sensitive help as described in FIGS. 7<i>a</i>-<b>7</b><i>c. </i>

[0169] A user may first initiate processing of an insurance claim in the insurance claims processing system. The insurance claims processing may begin at a first processing step, and may continue through a number of processing steps until the insurance claim has been processed. A next processing step may be determined by the user input at a current processing step. Each processing step may be displayed to the user in one or more pages on a computer display screen. The claims processing system may enter a processing step and display a page for the processing step.

[0170] A search interface may be presented to the user on the display screen. In one embodiment, the search interface may be displayed in response to user action. For example, the user may activate a button or menu item to cause the system to display the search interface. The search interface may be presented in any of various forms. For example, a text entry box may be displayed that accepts one or more terms or phrases to be searched for, and a button may be displayed that initiates a search when activated by the user. The text entry box may also accept special characters, for example, quotation marks around a group of terms that are to be searched for as a phrase. The text entry box may also accept logical operators; for example, an AND operator may be entered between two terms to indicate that help table entries are to be searched for that include both terms.

[0171] In step <b>350</b>, the user may enter in the search interface one or more terms to be searched for in the help database for the insurance claims processing system. The user may then initiate the search for the one or more terms. In step <b>352</b>, the insurance claims processing system may search the one or more index tables for entries including at least one of the one or more terms.

[0172] In step <b>354</b>, one or more entries may be found in the one or more index tables that include at least one of the one or more terms. In step <b>356</b>, the located entries in the index table may be used to locate help entries in the one or more help tables that include at least one of the one or more terms. In one embodiment, each entry in an index table includes an object ID. The one or more help tables may be searched for occurrences of the object ID from each of the located entries.

[0173] In step <b>358</b>, the located help table entries may be ranked by relevance. In one embodiment, the entries in the index table may include a relevance value. The located help table entries may be ranked from highest relevance to lowest relevance. Entries with the same relevance may be ranked by any of several methods, including, but not limited to: alphabetic ranking and order of appearance in the index table.

[0174] In one embodiment, more than one term may be searched for, and located entries may be first ranked on the number of search terms the entries include. Entries that include more search terms may be ranked higher than entries with fewer search terms. For example, if the user enters three terms to be searched for, entries that include all three of the search terms may be ranked first, then entries that include two of the search terms, and finally entries that include just one of the search terms. The entries within the ranking categories may then be ranked by relevance within the category. Thus, entries with lower relevance, but more search terms, may appear higher in the overall ranking than entries with higher relevance, but fewer search terms.

[0175] In one embodiment, if there is more than one term being searched for, occurrences including more than one of the search terms may be listed once, rather than listing the occurrence for each search term included in the occurrence. A relevance value of occurrences including more than one search term may be calculated from the relevance value of each of the terms included in the occurrence. For example, if a search is initiated for the terms “Anatomy” and “Body,” and the index table <b>402</b> illustrated in FIG. 5 is searched, the term “Anatomy” will be located in the third entry in the table, and the term “Body” in the fourth entry. The third and fourth entries have the same object ID <b>140</b>, indicating that these occurrences are from the same text section. In one embodiment, only one occurrence may be displayed on the display screen for the text section entry in text table <b>406</b> indicated by the object ID <b>140</b> of entries two and three in index table <b>402</b>. In one embodiment, the relevance value for an occurrence including more than one term may be calculated using the following method:

Relevance Value=5 um of Occurrence Relevance Values/Number of Occurrences

[0176] Applying this method to the relevance values <b>152</b> of the third and fourth entries in index table <b>402</b>:

(0.28+0.25)/2=0.265

[0177] In one embodiment, the calculated relevance value for the occurrence including the two search terms (0.265) may then be rounded to 0.27. In one embodiment, the calculated relevance value may then be used in ranking the occurrence including two terms against other occurrences including two terms.

[0178] In step <b>360</b>, information from the located help table entries may be displayed. In one embodiment, the entries may be displayed in the order of relevance as determined in step <b>358</b>. The help table entries may include portions of text from one or more documents related to insurance claims processing that include one or more of the one or more search terms. Some help table entries may include section headers from the one or more documents. Some help table entries may include text from the bodies of sections of the one or more documents. Some help entries may include glossary information from the one or more documents. Other entries may include text from other portions of the one or more documents. In one embodiment, the relevance value may also be displayed.

[0179] In step <b>362</b>, information describing the location of the displayed portions of text in the one or more documents may be displayed. This information may allow the user to look up (electronically or manually) located occurrences in the one or more documents. The location information may include, but is not limited to: document title, chapter title, and/or number, chapter or section header, section number and/or title, page number, number of occurrences in the section, etc.

[0180] In one embodiment, the page display may be split into sections, or panes. In one embodiment, the information from the located help table entries may be displayed in a first pane; the information describing the location in the one or more documents of displayed portions of text may be displayed in a second pane; and the step information may be displayed in a third pane. In one embodiment, separate windows may be used to display the information from the located help table entries, the locations in the one or more documents, and the step information.

[0181]FIGS. 10 and 10<i>a </i>illustrates embodiments of a display screen <b>200</b> showing multiple panes, wherein two or more of the panes comprise search results information. Referring to FIG. 10 for a description of display screen <b>200</b>, pane <b>202</b> may display a page for a step in the processing of an insurance claim. The search term “cuboid” <b>208</b> has been previously entered by the user, and a search was initiated and completed.

[0182] In pane <b>204</b>, occurrences of the search terms (located entries in the one or more help tables) may be displayed. Column <b>210</b> of pane <b>204</b> may display a location where the term is found. In one embodiment, a portion or all of a text section or a portion or all of a header from a document may be displayed in column <b>210</b>. Column <b>212</b> may display a portion or all of a chapter or section title of the document where the occurrence is located. Column <b>214</b> may list the search term(s) that appear in the occurrence. In this example, only one term <b>208</b> was entered. If multiple search terms are entered, then all search terms that appear in a listed occurrence may be listed in column <b>214</b>. Column <b>216</b> may display the number of search terms found in the occurrence. Column <b>218</b> may display the relevance value for the entries. In this example, all displayed entries have the same relevance value (1). Other embodiments may include more or fewer columns displaying the same or other information about the occurrences. In one embodiment, not all located entries may be displayed in pane <b>204</b>. An interface item or items may be provided to the user to display other located entries. Interface items may be items displayed graphically on the screen (for example, icons) and selectable using input/output devices such as a mouse, joystick, or arrow keys on a keyboard. Interface items may also be keyboard selections such as function keys or key combinations. For example, a button may be provided that allows the user to scroll down the list of located entries in pane <b>204</b>.

[0183] In pane <b>206</b>, information about the location of the occurrences in pane <b>204</b> may be displayed. Column <b>220</b> may display chapter numbers and/or chapter headers from the one or more documents in the help database that include one or more of the located occurrences displayed in pane <b>204</b>. In one embodiment, there may be one entry in pane <b>206</b> for each entry in pane <b>204</b>. Alternatively, there may be one entry in pane <b>206</b> for each chapter that includes at least one of the occurrences displayed in pane <b>204</b>. An interface item or items may be provided to allow the user to display entries not currently displayed in pane <b>206</b>.

[0184]FIG. 11 shows the display screen <b>200</b> of FIG. 10, with one of the search results panes (pane <b>204</b>) hidden to provide more display area for claims processing information. In this embodiment, pane <b>206</b> is moved nearer to the top of the display screen than in the display screen illustrated in FIG. 10. Pane <b>202</b> displays the page for a step in the processing of an insurance claim. Pane <b>202</b> has been expanded to provide more lines for displaying the elements of the step than in the display screen illustrated in FIG. 10. Thus, in this example, pane <b>202</b> of FIG. 11 displays the step element “Injury Description” <b>220</b> which was hidden in pane <b>202</b> of FIG. 10.

[0185] An interface item or items may be provided to the user for hiding or showing one or more panes displaying portions of the search results or context-sensitive help. Interface items may be items displayed graphically on the screen (for example, icons) selectable using input/output devices such as a mouse, joystick, or arrow keys on a keyboard. Interface items may also be keyboard selections such as function keys or key combinations. For example, a function key or key combination may be provided to toggle between hiding and showing pane <b>204</b>.

[0186] The example illustrated in FIG. 11 is of a display with search results. In one embodiment, the hiding and showing of panes as described above may be applied to displays with panes displaying context-sensitive help for a step.

[0187] The ability to hide portions of search results or context-sensitive help may be useful in insurance claims processing systems with displays that have a limited amount of display space. For example, displays on some terminals may be limited to 24 lines of text. If the search results are displayed in two panes each using eight lines, hiding one of the panes may double the display space for the step elements from eight to sixteen lines.

[0188]FIG. 1<i>d </i>is a network diagram of an illustrative distributed computing environment which is suitable for implementing various embodiments. The distributed computing environment may include various server systems <b>70</b>A and client systems <b>80</b>A connected by a network <b>55</b>A. Other networkable devices such as printers <b>90</b>A may also be connected to the network <b>55</b>A. The servers <b>70</b>A, clients <b>80</b>A, and other devices may be geographically dispersed. A single computer system may serve as both a server and client.

[0189] The network <b>55</b>A may be a local area network or wide area network, and may include communications links including, but not limited to: Ethernet, token ring, Internet, satellite, wireless, telephone, cable, DSL, and other suitable pathways. As used 5 herein, “the Internet” includes one or more substantially global networks which are generally accessible by the public (i.e., they are not proprietary or not largely characterized by controlled access). Various sources of data on the Internet may be accessed through protocols such as HTTP (HyperText Transport Protocol), HTTPS (Secure HyperText Transport Protocol), FTP (File Transfer Protocol), Telnet, NNTP (Network News Transport Protocol), SMTP (Simple Mail Transfer Protocol), and other suitable protocols. Transmission of data over the Internet is typically achieved through the use of TCP/IP (Transmission Control Protocol/Internet Protocol) packets.

[0190]FIG. 2<i>a</i>A is an illustration of an insurance claims processing server computer architecture according to one embodiment. FIG. 2<i>b</i>A is an illustration of an insurance claims processing client computer architecture according to one embodiment. The insurance claims processing server <b>70</b>A may include a computer system <b>20</b><i>a</i>A with a memory <b>30</b><i>a</i>A. The insurance claims processing client <b>80</b>A may include a computer system <b>20</b><i>b</i>A with a memory <b>30</b><i>b</i>A.

[0191] The insurance claims processing server <b>70</b>A may further include a display device <b>50</b><i>a</i>A connected to the computer system <b>20</b><i>a</i>A and an insurance database <b>40</b>A residing on an internal or external storage. Computer system <b>20</b><i>a</i>A may include memory <b>30</b><i>a</i>A configured to store computer programs for execution on the computer system <b>20</b><i>a</i>A and a central processing unit (or CPU, not shown) configured to execute instructions of computer programs residing on the computer system <b>20</b><i>a</i>A. Insurance claims processing server software <b>60</b>A may be stored in the memory <b>30</b><i>a</i>A.

[0192] The insurance claims processing client <b>80</b>A may further include a display device <b>50</b><i>b</i>A connected to the computer system <b>20</b><i>b</i>A. Computer system <b>20</b><i>b</i>A includes memory <b>30</b><i>b</i>A configured to store computer programs for execution on the computer system <b>20</b><i>b</i>A and a central processing unit (or CPU, not shown) configured to execute instructions of computer programs residing on the computer system <b>20</b><i>b</i>A. Insurance claims processing client software <b>68</b>A, such as web browser software, may be stored in the memory <b>30</b><i>b</i>A.

[0193] The insurance claims processing server <b>70</b>A may be connected to network <b>55</b>A. The insurance claims processing server software <b>60</b>A and insurance database <b>40</b>A may be distributed among the one or more servers <b>70</b>A to provide a distributed processing system for insurance claim transactions. In other words, an insurance claim processing transaction being processed by the insurance claim processing system may be routed to any server based upon the workload distribution among servers <b>70</b>A at the time of the transaction. Insurance claim processing system servers <b>70</b>A may be located on a local area network or may be geographically dispersed in a wide area network.

[0194] One or more clients <b>80</b>A may also be connected to network <b>55</b>A. Clients <b>80</b>A may reside at one or more claim processing units within the insurance company. In a wide area network, clients <b>80</b>A may be geographically dispersed. Clients <b>80</b>A may be used to access one or more insurance claim processing system servers <b>70</b>A and associated insurance databases <b>40</b>A. An insurance claim processing employee may use a client <b>80</b>A to access the insurance claim processing system and execute insurance transactions. An employee may also use a client <b>80</b>A to enter insurance claim inputs into the insurance claim processing system. As shown in FIG. 1<i>d</i>, one or more printers <b>90</b>A may also be connected to network <b>55</b>A for printing documents associated with insurance claim transactions.

[0195] Systems <b>20</b><i>a</i>A and <b>20</b><i>b</i>A may also include one or more users input devices <b>52</b><i>a</i>A and <b>52</b><i>b</i>A, such as a keyboard, for entering data and commands into the insurance claim program <b>60</b>A. It may also include one or more cursor control devices <b>54</b><i>a</i>A and <b>54</b><i>b</i>A such as a mouse for using a cursor to modify an insurance claim viewed on display screen <b>50</b><i>a</i>A and/or <b>50</b><i>b</i>A. In response to the updating of the estimated insurance claim, the insurance claim server software <b>60</b>A may store the updated insurance claim in the insurance database <b>40</b>A.

[0196] The insurance claims processing server <b>70</b>A and client <b>80</b>A may be used by an Insurance Company for various embodiments of a system and method for processing insurance claims.

[0197]FIG. 3<i>a</i>A is an illustration of an insurance claims processing server software <b>60</b>A architecture for a single client according to one embodiment. The server software <b>60</b>A may include an insurance processing rules engine <b>61</b>A. As used herein, a “rules engine” may include an expert system which is operable to produce an output as a function of a plurality of rules. A rules engine, in one embodiment, may include an expert computer system which utilizes and builds a knowledge base developed in the form of business rules and/or formulas to assist the user in decision-making. In one embodiment, the rules engine <b>61</b>A is operable to generate insurance claim assessment questions to be displayed to a user during an insurance claim consultation session. The rules engine <b>61</b>A may also be operable to estimate a value of an insurance claim as a function of insurance claim assessment data entered by a user in response to the insurance claim assessment questions. In one embodiment, the insurance claim may include a bodily injury claim, the insurance claim assessment questions may include bodily injury claim assessment questions, the insurance claim assessment data may include bodily injuries and treatments thereof.

[0198] In one embodiment, the rules engine <b>61</b>A is capable of processing rules associated with assessing bodily injury damages claims. A rules engine <b>61</b>A, in one embodiment, comprises an expert computer system which utilizes and builds a knowledge base developed in the form of business rules to assist the user in decision-making. It allows insurance companies to capture the knowledge base of their experts by defining business rules. Once created, the expertise may be used in processing many transactions, including assessing bodily injury damages claims. The business rules enable claim-processing professionals to be assisted by industry experts to evaluate legal, medical, insurance conditions before arriving at a valuation of an insurance claim.

[0199] In various embodiments, the rules engine <b>61</b>A may be implemented and executed on various computing platforms such as personal computers and mainframes. The rules engine <b>61</b>A may comprise a rules engine executable file on these platforms. In various embodiments, the rules engine may be accessed through various user interfaces, such as a graphical user interface for a rules engine <b>61</b>A which is executable on a Microsoft™ Windows™-based server <b>70</b>A. In one embodiment, the rules engine <b>61</b>A may be developed using a commercial rule-based development tool such as PLATINUM Aion™, which is available from Computer Associates International, Inc. In one embodiment, the rules may be customized to meet the requirements of a particular insurance company.

[0200] Business rules, often referred to simply as rules, may include executable computer program instructions. The rules include computer commands or logical instructions to achieve a certain function. For example, rules may guide an assessment or estimate of bodily injury general damages. In one embodiment, a rule may include a premise followed by one or more resulting actions. For example, in one embodiment, a business rule may state “If patient requires hospitalization after emergency care treatment then the trauma severity level should be classified as major.” In this case, the premise is “patient requires hospitalization after emergency care treatment.” The resulting action is “trauma severity level should be classified as major.” In one embodiment, the insurance claim processing server <b>70</b>A may include several thousand business rules. The rules may be executed or fired, under the control of the insurance claim processing software, based on certain events, user inputs, etc. Only pertinent rules, i.e., a subset of all the available rules, are typically selected and executed for processing a specific bodily injury damages claim. On execution of the plurality of rules which are applicable to a specific bodily injury claim consultation session, the insurance claim processing server software <b>60</b>A may generate a consultation report which summarizes an assessment and/or estimate of the bodily injuries claim.

[0201] The rules may be stored in and retrieved from an insurance database <b>40</b>A. The type of information stored and/or retrieved may include, but not be limited to, business objects, tables, rules, software source code, executable software, etc. In one embodiment, the database may include a relational database. In another embodiment, the database <b>40</b> may include an object-oriented database.

[0202] In one embodiment, the insurance claims processing server software <b>60</b>A may include adapter software <b>62</b>A which may provide access to the rules engine for one or more other computer-based applications or subsystems, such as an internet information server <b>64</b>A. In one embodiment, the adapter software <b>62</b>A provides an application programming interface (API) to the rules engine <b>61</b>A. The adapter software <b>62</b>A is discussed in greater detail with reference to FIG. 4A.

[0203] In one embodiment, the insurance claims processing server software <b>60</b>A may include a web server such as an internet information server (IIS) <b>64</b>A. As used herein, a “web server” includes a system for supplying clients with access to web pages, such as by sending the pages to clients via an appropriate protocol. In one embodiment, a web server may also be operable to generate the web pages dynamically. As used herein, a “web page” includes a block of information which is configured to be displayed by a web browser <b>68</b>A. As used herein, a “web browser” or “browser software” includes software which is configured to receive and display web pages. Examples of web browsers include Internet Explorer™ available from Microsoft™ Corporation and Netscape Navigator™ available from Netscape Communications Corporation. Typically, a web page is configured to be displayed in a single window in a web browser, wherein the window may be scrolled to view off-screen elements of the web page. Web pages may include various combinations of text, graphics, audio content, video content, and other multimedia content. A web page is often encoded in a language such as HTML (HyperText Markup Language). Web pages may be viewed in a browser on the same computer system on which the server <b>64</b>A or web pages reside. Web pages may also be transmitted to a client computer system over a network <b>55</b>A, such as via the HyperText Transport Protocol (HTTP) <b>56</b>. Where the network <b>55</b>A includes the Internet, the web pages may be transmitted via standard protocols such as TCP/IP.

[0204] In one embodiment, the internet information server (IIS) <b>64</b>A may include a commercial product such as Microsoft™ Internet Information Server available from Microsoft™ Corporation. In one embodiment, the server <b>64</b>A may include an active server pages (ASP) controller <b>65</b>A which is operable to generate web pages dynamically. In other words, the web pages delivered by the internet information server <b>64</b>A may be built in real time by the ASP controller <b>65</b>A upon a request for a page by a browser <b>68</b>A. Active server pages may include dynamic web pages which are created, for example, by blending HTML and server-side scripting. Active server pages may be dynamically constructed to include insurance claim assessment questions and other user interface elements by starting from a template.

[0205] The web server <b>64</b>A may be configured to generate a plurality of web pages comprising the insurance claim assessment questions. The web browser <b>68</b>A may then be configured to display the plurality of web pages comprising the insurance claim assessment questions. The web browser <b>68</b>A may then be configured to receive insurance claim assessment data entered by a user in response to the insurance claim assessment questions during an insurance claim consultation session and send the insurance claim assessment data to the web server <b>64</b>A. In one embodiment, the web server <b>64</b>A is further configured to receive the insurance claim assessment data from the web browser <b>68</b>A and send the insurance claim assessment data to the rules engine <b>61</b>A. The rules engine <b>61</b>A may be further configured to generate and send the estimate of the value of the insurance claim to the web browser <b>68</b>A through the web server <b>64</b>A. The web browser <b>68</b>A may be further configured to display the estimate of the value of the insurance claim received from the rules engine <b>61</b>A through the web server <b>68</b>A.

[0206] In one embodiment, the web server <b>64</b>A and web browser <b>68</b>A may be located on separate computer systems which are communicatively coupled through a network <b>55</b>A. In another embodiment, the web server <b>64</b>A and web browser <b>68</b>A may be located and executed on a single computer system.

[0207] HTTP is considered to be a stateless internet access protocol. In other words, each request from a web browser <b>68</b>A to a web server <b>64</b>A is essentially a request-response interaction. Therefore, when a web browser <b>68</b>A requests a web page, for example, the web server <b>64</b>A may complete the interaction between the two by sending the page to the browser <b>68</b>A. However, a consultation session conducted by a user through a web browser <b>68</b>A which communicates with the rules engine <b>61</b>A may include many successive interactions through the web server <b>64</b>A. It would tend to be inefficient to start a rules engine executable file for each of the many interactions that may take place during a single consultation session.

[0208] Therefore, IIS sessions may be used to maintain resources and state for each of a plurality of users. FIG. 3<i>b</i>A is an illustration of an insurance claims processing server software architecture for multiple clients <b>68</b><i>a</i>A, <b>68</b><i>b</i>A, <b>68</b><i>c</i>A according to one embodiment. The first time a user connects to a suitable web site provided by the server <b>64</b>A, a rules engine may be executed or started for that particular user and then “held” in an IIS session for that user. FIG. 3<i>b</i>A illustrates an example including three browsers <b>68</b><i>a</i>A, <b>68</b><i>b</i>A, <b>68</b><i>c</i>A which correspond to and communicate with respective rules engines <b>61</b><i>a</i>A, <b>61</b><i>b</i>A, <b>61</b><i>c</i>A. Each IIS session may include an individual ASP controller <b>65</b><i>a</i>A, <b>65</b><i>b</i>A, <b>65</b><i>c</i>A. Each rules engine <b>61</b><i>a</i>A, <b>61</b><i>b</i>A, <b>61</b><i>c</i>A may therefore be linked to its corresponding ASP controller <b>65</b><i>a</i>A, <b>65</b><i>b</i>A, <b>65</b><i>c</i>A through individual adapter software <b>62</b><i>a</i>A, <b>62</b><i>b</i>A, <b>62</b><i>c</i>A.

[0209]FIG. 4A is an illustration of adapter software between a rules engine and a web server according to one embodiment. The adapter software <b>62</b>A may include one or more components which permit software such as applications or other components to communicate with the rules engine <b>61</b>A. For example, the adapter software may provide methods to start and communicate with a rules engine executable file <b>61</b>A.

[0210] As used herein, a component is a software object which includes definitions of method of communication for that software object. Typically, components are implemented according to a component architecture specification such as the Component Object Model (COM) or Distributed Component Object Model (DCOM) promulgated by Microsoft™. The component architecture specification for COM enables applications and components which follow the specification to pass data, commands, and other information back and forth. A COM interface may be said to “wrap” an object, server, or other piece of software if that COM interface defines methods of interaction or communication with that object, server, or piece of software.

[0211] In one embodiment, the adapter software <b>62</b>A may include one or more COM components <b>63</b><i>b</i>A and a dynamic link library (DLL) <b>63</b><i>a</i>A. As used herein, a DLL may include a library of executable functions or data that can be used by an application such as a Microsoft™ Windows™-based application. Typically, a DLL provides one or more particular functions, and a program may access those functions by creating either a static or dynamic link to the DLL. A static link remains constant during program execution, while a dynamic link is created by the program as needed. In one embodiment, the DLL <b>63</b><i>a</i>A may provide a lower-level interface to the functions and methods of the rules engine <b>61</b>A. For example, the DLL <b>63</b><i>a</i>A may take advantage of published protocols for accessing a rules engine implemented with a commercial system such as PLATINUM Aion™. In one embodiment, the DLL <b>63</b><i>a</i>A may be provided by the supplier of the commercial system for developing a rules engine.

[0212] The COM component(s) <b>63</b><i>b</i>A may then provide a higher-level interface to the DLL <b>63</b><i>a</i>A, which in turn may provide an interface to the rules engine <b>61</b>A. In other words, the “business intelligence” may be confined to the rules engine <b>61</b>A and DLL <b>63</b><i>a</i>A, and the COM component(s) <b>63</b><i>b</i>A may expose an interface which permits other pieces of software to convert data, requests, and other parameters to function calls provided by the DLL <b>63</b><i>a</i>A. In one embodiment, the COM component(s) <b>63</b><i>b</i>A may include methods including, but not limited to, the following: setListParameter, setSingleParameter, getNextMessage, lastErrorMessage, sendMessage, terminateSession, transactMessage, getListParameter, getSingleParameter, startServerSession, and startRefsysSession. Appropriate parameters may be defined for each method.

[0213]FIG. 5A illustrates the transmission of data between a web server and a web browser according to one embodiment. Each ASP controller <b>65</b>A may be a web-specific COM component or components that may run in a process space associated with the IIS <b>64</b>A. These components may be operable to start, stop, and send data <b>69</b>A (such as insurance claim consultation data entered in response to insurance claim consultation questions) to the rules engine <b>61</b>A. These components may also be operable to receive data (such as insurance claim consultation questions and elements of the user interface) from the rules engine <b>61</b>A for inclusion in one or more web pages <b>67</b>A. Generally, these components are configured to translate data between HTML on the IIS <b>64</b>A side and the interface exposed by COM components <b>63</b><i>b</i>A on the other side. These components may include functionality such as data validation (e.g., determining if datatypes of entered data are valid). The components may also ensure that the state of the interactions or “conversation” between a rules engine and a browser is preserved, as discussed in greater detail with respect to FIG. 4<i>b</i>A and FIG. 9A.

[0214] In one embodiment, the ASP controller <b>65</b>A may include at least two COM components: one which handles interactions between a web browser <b>68</b> and the rules engine executable file, and another which handles interactions between the web browser <b>68</b>A and a reference system or help system executable file. The reference system executable file may provide the user with detailed assistance in conducting an insurance claim consultation session.

[0215] In one embodiment, the COM component(s) for accessing the reference system may include methods including, but not limited to, the following: addedRefsysID, initializeContentsGraphs, startSessionIfNecessary, MemberOftrueHierarchylds, lastSearchText, lastSelectedChapterObjectId, terminateSession, getFirstMessage, pageHasError, getListParameter, chapterWasSelected, writeRefsysContents, writeContextContents, writeSearchResults, writeHelpTextAsHTML, contextHelpWasSelected, isSessionStarted, searchHitWasSelected, mergeLostBoys, searchWasSelected, and iisSessionId. Appropriate parameters may be defined for each method.

[0216] In one embodiment, the COM component(s) for accessing the rules engine <b>61</b>A may include methods including, but not limited to, the following: terminateSession, startSessionIfNecessary, writePredisplayHtml, handleExitProcessing, getFirstMessage, pageToShow, errorMessage, pageHasError, pageWasPosted, doPageTransaction, getSingleParameter, getListParameter, getListParameterNoTrim, debugIt, formatAdsDate, hasSaveButton, hasBackButton, hasNextButton, hasContentsButton, hasCommentsButton, hasUnknownButton, hasReportButton, claimKeyFormat, statusMessage, iisSessionId, and isSessionStarted. Appropriate parameters may be defined for each method.

[0217]FIG. 6A illustrates an example of a browser-based user interface for the insurance claims processing system according to one embodiment. The browser window <b>100</b>A may be displayed in a display device <b>50</b><i>b</i>A coupled to a client computer system. Typically, a web browser includes a set of standard navigation commands. As shown in FIG. 6A, examples of these commands may include “back” <b>110</b>A to move to the previously visited page, “forward” <b>112</b>A to move to the page previously visited before selecting “back,” “reload” <b>114</b>A to obtain and redisplay the current page from the server, and “home” <b>116</b>A to move to a previously designated home page. These standard navigation commands may be made available to the user as menu items and/or as buttons or other GUI elements. A button may be “pushed,” often by a mouse click or appropriate keyboard key, to initiate the command supplied by the button.

[0218] The browser page <b>104</b>A may include an active server page or other HTML-encoded page supplied by the web server <b>64</b>A. The page <b>104</b>A may include one or more specialized navigation commands. In one embodiment, these specialized navigation commands may be displayed as buttons or other GUI elements. In one embodiment, the specialized navigation commands may include, for example, “save” <b>120</b>A to save the status of a consultation session, “help” <b>122</b>A to access a reference system for insurance claim processing, “exit” <b>124</b>A to safely exit the insurance claim consultation session, “back” <b>130</b>A to safely move to a previous page of the insurance claim consultation session, and “reset” <b>132</b>A to reset the proper state of the browser page <b>104</b>A. The reset command is further described with reference to FIG. 9A.

[0219] Insurance claim assessment data and/or insurance claim assessment questions <b>140</b>A may also be displayed in the browser page <b>104</b>A. For example, for a given step in the insurance claim consultation session, one or more questions may be asked regarding bodily injuries and/or treatments thereof. A set of acceptable answers (i.e., insurance claim assessment data) may be supplied to the user, such as with a menu or series of check boxes. The user may then select from the possible answers and enter the insurance claim assessment data. The set of acceptable answers may be dynamically generated by the rules engine based upon answers to previous questions.

[0220]FIG. 7A is a flowchart illustrating a method of developing a web-based insurance claims processing system according to one embodiment. The steps shown in FIG. 7A may be performed in various orders according to various embodiments. In step <b>200</b>A, a rules engine may be developed or otherwise provided. As discussed with reference to FIG. 3<i>a</i>A, the rules engine may be configured to estimate a value of an insurance claim as a function of insurance claim assessment data entered by a user in response to insurance <b>10</b> claim assessment questions.

[0221] In step <b>202</b>A, the rules engine may be wrapped with a component interface in accordance with a component architecture specification. Component interfaces are discussed in greater detail with reference to FIGS. 4A and 5A. The component interface may include one or more definitions of methods of communication or other access to the rules engine, such as by a web server. The component architecture specification may include a Component Object Model (COM) specification.

[0222] In step <b>204</b>A, a web server may be provided, wherein the web server is configured to generate a plurality of web pages which are viewable by a web browser. The methods of communication in the component interfaces may be operable to transmit the insurance claim assessment data from the web server to the rules engine and operable to transmit the insurance claim assessment questions from the rules engine to the web server.

[0223]FIG. 8A is a flowchart illustrating a method of hosting a web-based insurance claims processing server with various pricing models according to one embodiment. In step <b>250</b>A, an insurance claim processing server may be hosted. As used herein, “hosting” may include installing, maintaining, and/or otherwise providing client access to a server. The insurance claim processing server may be configured to estimate a value of an insurance claim as a function of insurance claim assessment data entered by a user during an insurance claim consultation session. In one embodiment, the insurance claim processing server may include a rules engine and a web server, and the client software may include a web browser. The web server may be operable to generate web pages and receive responses and requests from the web browser to enable communication between the rules engine and the web browser.

[0224] In step <b>252</b>A, client software such as a web browser may be provided to a user such as an insurance company. In one embodiment, the client software may include commercial, off-the-shelf web browser software which may already be in use by an insurance company and its employees who seek to access to the insurance claim processing server. The client software may be operable to receive the insurance claim assessment data entered by the user and send the insurance claim assessment data across a network to the insurance claim processing server. The insurance claim processing server may be operable to send the estimate of the value of the insurance claim to the client software across the network. In one embodiment, the network may include the Internet.

[0225] In step <b>254</b>A, the user may be charged for access to the insurance claim processing server through client software according to a pricing model. Various pricing models may be used with various embodiments of the hosting system and method. The pricing model may include a fee for each of a plurality of insurance claim consultation sessions conducted by the user. The pricing model may include a fee for each fixed period of access time of access by the user to the insurance claim processing server through the client software. For example, the fixed period of access time may include an hourly multiple, a weekly multiple, a monthly multiple, a yearly multiple, or a multiple of minutes. The pricing model may include a fee which varies directly with an amount of time spent accessing the insurance claim consultation session through the client software.

[0226] The user may include an insurance organization having a particular size, and the pricing model varies according to the size of the user. The size of the user may include a function of a quantity of employees of the user, a function of revenue of the user over a period of time, and/or a function of a quantity of consultation sessions conducted by the user over a period of time. The pricing model may include a pricing discount given to the user after a particular quantity of insurance claim consultation sessions conducted by the user in a particular period of time. The insurance claim consultation session may include one or more insurance claim consultation transactions, and the pricing model may include a fee for each of a plurality of insurance claim consultation transactions conducted by the user during one or more insurance claim consultation sessions.

[0227] The method may further include charging additional users for access to the insurance claim processing server through client software according to a same or different pricing model.

[0228]FIG. 9A is a flowchart illustrating a method of using a reset button provided by a web-based interface to a web-based insurance claims processing server according to one embodiment. In step <b>302</b>A, a first page of insurance claim assessment data may be displayed in a browser program executing on a computer system. The browser program may include a web browser program which is operable to read and display web pages. The computer system which executes the browser program may include a client computer system which is communicatively coupled to a server computer system. The server computer system may be operable to generate and send a plurality of pages of insurance claim assessment data to the client computer system.

[0229] In one embodiment, in step <b>304</b>A, one of the specialized navigation commands, such as a forward command, may be selected to advance to a second page of insurance claim assessment data. In another embodiment, the user may advance to the second page by hitting “return” or otherwise instructing the insurance claim processing server to provide a next page in a consultation session. In step <b>306</b>A, the second page of insurance claim assessment data, including the specialized navigation commands, may be displayed in the browser.

[0230] In step <b>308</b>A, after the second page of insurance claim assessment data is displayed, one of the standard navigation commands, such as the “back” command or button available in a toolbar or menu in a web browser, may be selected to move back to the first page of insurance claim assessment data. The first page of insurance claim assessment data may then be redisplayed.

[0231] In step <b>310</b>A, the user may attempt to perform an insurance claim assessment task on the redisplayed first page of insurance claim assessment data. For example, the user may attempt to save a status of an insurance claim consultation by pressing a “save” button in the specialized buttons. The insurance claim consultation may include an interactive determination of an estimate of a value of an insurance claim through the entry of insurance claim assessment data in response to insurance claim assessment questions. The insurance claim assessment task may include selecting one of the other specialized navigation buttons provided as the user interface by insurance claim processing server. The insurance claim assessment task may also include entering new or modifying existing insurance claim assessment data. Insurance claim assessment data may include information relevant to an estimate of a value of an insurance claim, such as bodily injuries and treatments thereof. The insurance claim assessment data may include bodily injury claim assessment data, and the insurance claim assessment task may include a bodily injury claim assessment task.

[0232] In one embodiment, the state of the “conversation” between the browser and the insurance claim processing server may be preserved by a COM component <b>66</b>A, as discussed with reference to FIG. 5A. In step <b>312</b>A, therefore, a navigation error may be generated as a result of the attempting to perform an insurance claim assessment task on the first page, when the second page is the “correct” page in the conversation. In one embodiment, a navigation error message may be generated and displayed to the user as a result of the generating the navigation error. The navigation error message may include an instruction to select a reset command, wherein the reset command is one of the specialized navigation commands.

[0233] In step <b>314</b>A, the user may select the reset command after viewing the navigation error message. In one embodiment, the insurance claim processing server may automatically perform a reset function without user intervention as a result of the navigation error.

[0234] In step <b>316</b>A, the second page (i.e., the “correct” page) of insurance claim assessment data may then be redisplayed. The user may then perform a second insurance claim assessment task on the redisplayed second page of insurance claim assessment data.

[0235]FIG. 2B is a flow chart illustrating the generation of a table of contents for processing an insurance claim according to one embodiment. In step <b>100</b>B, the user of an insurance claims processing system <b>10</b> may use a client system <b>80</b> to initially configure, or set up, all the display screens associated with the insurance claims processing business process. A display screen may be associated with a step included in processing insurance claims. In one embodiment, the business process for processing the insurance claims may utilize an applicable subset of all display screens. The inclusion or exclusion of a display screen in a table of contents display screen may be based on business rules, user inputs, etc. In another embodiment, the business process for processing the insurance claims may utilize all display screens.

[0236] In one embodiment, the configuration of each of the display screens involves defining the properties of the display screen object such as previous display screen pointer, next display screen pointer, source for data displayed, etc. Additionally, each display screen configuration may require specifying one or more user input fields, defining business rules associated with the processing of data for the display screen, etc. The configuration of the display screen object may include invocation of methods such as Load_Screen, Display_Screen, Validate_Screen, Save_Screen, Process_Screen, etc. In one embodiment, a registry is maintained for all display screen objects. FIGS. <b>6</b>B and <b>6</b>Ba show a few examples of the properties and methods associated with a display screen object according to two different embodiments.

[0237] In one embodiment, the table of contents (TOC) is a display screen, window, or subset of a screen which shows a roadmap, including one or more applicable steps, for processing an insurance claim. FIGS. <b>5</b>B and <b>5</b>Ba depict alternate embodiments of a TOC display screen. The table of contents may include one or more steps required to process insurance claims. Each step has an associated display screen. The table of contents display screen and each step display screen may be configured as an object. The number of steps included in the table of contents may be dynamically and automatically modified in real-time based on business rules, user inputs, etc. The display screen object for the table of contents includes one or more display screen objects, representing intermediary steps, selected from all display screen objects. Each display screen object may include a property, such as Display_In_TOC, which enables the display screen object and corresponding step to be included in the TOC.

[0238] In step <b>110</b>B, the user of the insurance claims processing system <b>10</b> may initiate the insurance claim processing by specifying a claim number. The claim number may then be received by the insurance claim processing system <b>10</b>. In step <b>120</b>B, a determination may be made as to whether the specified claim number exists in the insurance claims processing system <b>10</b>, such as in the insurance database <b>40</b>. If it is determined that the specified claim number is a new claim number, then program control is passed on to step <b>130</b>B. If a matching record is found in the insurance database <b>40</b> for the specified claim number, then program control is passed on to step <b>150</b>B.

[0239] In step <b>130</b>B, the IC user may set up the claim definition data for a new claim. The setting up of the claim definition data may include providing user inputs through one or more display screens, as defined in the registry for the claim definition data display screen object. Examples of claim definition data provided by the IC user may include, but are not limited to, claimant demographic data such as name, age, address, phone number, etc., injury code information such as neck, spine, arm, etc., and treatment code information such as emergency care, hospital, outpatient, physical therapy, etc. As the IC user steps through one or more display screens to enter claim definition data, the insurance claim processing software <b>60</b> may dynamically modify the properties of the display screen objects by using appropriate methods. For example, as an IC user enters and injury code for a neck injury, all relevant and associated display screens will be automatically displayed by using the registry for the display screen object and specific properties such as next display screen and previous display screen of the display screen object. On completing the entry of the relevant inputs associated with the definition of the claim, the IC user may submit a request to display the table of contents screen.

[0240] If the claim number is found in step <b>120</b>B, the insurance claim processing software will generate a request to display the table of contents screen in step <b>140</b>B. When the IC user has entered the claim definition data for a new claim number in step <b>130</b>B, a request may be made to display the table of contents screen in step <b>140</b>B. In step <b>150</b>B, in response to a request to display the table of contents (TOC) display screen, the insurance claim processing software executes a function or method to generate the TOC display screen. In one embodiment, executing the function to generate the table of contents may include invoking a Create_TOC_Entry method for the TOC display screen object. FIG. 3B describes in further detail a flowchart for a function or method to generate the table of contents. In step <b>160</b>B, the newly generated TOC display is sent to the display screen <b>50</b> for display to the IC user.

[0241]FIG. 3B illustrates one embodiment of a program or method to build a table of contents display. In step <b>152</b>B, the insurance claim processing software, in one embodiment, executes a Create_TOC_Entry method for all display screen objects which have a “True” entry in a Display_—In_TOC property field.

[0242] In step <b>154</b>B, the insurance claim processing software <b>60</b> verifies that each display screen object has been validated, such as by checking that a Valid_Screen method has been invoked successfully. In one embodiment, the Function Re_Evaluate_All is called prior to displaying the TOC and it validates all pages. This validation process may choose to remove screens from the process because they are no longer appropriate.

[0243] In step <b>156</b>B, a determination is made as to whether the previous screen pointer for the current display screen object is present or is not present. If no previous screen pointer is present, then that display screen object is included in the TOC display screen.

[0244] In step <b>158</b>B, if a previous screen pointer is present and if the source of data property field indicates that the data was entered by a user, then the display screen object is included in the TOC display screen.

[0245] In step <b>159</b>B, the list of display screen objects included with the TOC is returned to the calling function. In one embodiment, the screens are then displayed based on individual logic in their Create_TOC_Entry function. In many cases, this is default behavior. But, in some cases, such as “Conditional Pages,” their Create_TOC_Entry logic may choose not to show them because their conditions are not met.

[0246]FIG. 4B is a flowchart which further illustrates the use of a table of contents for processing an insurance claim according to one embodiment. In step <b>500</b>B, the processing of the insurance claim may be initiated by initiating a first step, wherein the processing of the insurance claim includes a plurality of steps. The steps may include screens displayed on the display device <b>50</b> coupled to a computer system <b>10</b>. The insurance claim may include a bodily injury claim, and processing the insurance claim to estimate the value of the insurance claim may include processing the bodily injury claim to estimate a bodily injury general damages value. The steps may include steps for entry of information relevant to the estimate of the value of the insurance claim. The information may include, for example, bodily injury treatment information and/or bodily injury damages information.

[0247] In one embodiment, for example, the first step may include the user entering a claim identification number as discussed with reference to FIG. 2B. In another embodiment, entering the claim identification number may already have taken place, and the “first step” may actually include a step such as the entry of an injury code or treatment code during the consultation session.

[0248] In step <b>510</b>B, one or more of the steps in the processing of the insurance claim may be proceeded through to arrive at an intermediary step. For example, the user may enter injury and/or treatment data in response to questions presented in one or more steps. In step <b>520</b>B, the intermediary step may then be displayed. As used herein, the intermediary step is any step between the first and final steps in the plurality of steps of processing the insurance claim. Proceeding through one or more of the steps in the processing of the insurance claim may include entering information relevant to the estimate of the value of the insurance claim in the one or more of the steps. In step <b>530</b>B, the entered information may be stored in a memory.

[0249] In step <b>540</b>B, a table of contents may be displayed upon the entry of an appropriate command by the user. For example, the user may select a GUI element such as a button or hit a designated keyboard key to display the table of contents. The table of contents may be generated according to the method discussed with reference to FIG. 3B. The table of contents may include an ordered list of the steps associated with the processing of the insurance claim, and the ordered list of steps may include the first step, the intermediary step, and any steps in between the first step and the intermediary step. Therefore, the table of contents may essentially show a “roadmap” of the business process for processing insurance claims. The ordered list of steps may be dynamically modifiable in response to the entry of information in a step. In other words, steps may be added to or deleted from said dynamically modifiable ordered list of steps in response to the entry of information. In various embodiments, the table of contents may be shown as a display screen, window, or other subset of a screen.

[0250] In step <b>550</b>B, the user may be permitted to select one of the steps from the ordered list of steps associated with the processing of the insurance claim in the table of contents. In step <b>560</b>B, the selected step may then be displayed in response to the user selecting the selected step in the table of contents. In step <b>570</b>B, in one embodiment, the entered information in the selected step may be modified and stored after selecting the step in the table of contents.

[0251] After displaying the selected step, the intermediary step may be redisplayed upon entry of an appropriate command by the user. In one embodiment, in other words, the user may go back to the previously displayed step, either through the table of contents or through entry of a suitable “back” command. The processing of the insurance claim may be continued after redisplaying the intermediary step by permitting the user to enter additional information relevant to the estimate of the value of the insurance claim.

[0252] The ordered list of steps in the table of contents may include a final step. In one embodiment, the final step may be selected at any time from the table of contents. The final step may include a consultation report concerning an estimate of the value of the insurance claim. The consultation report may include information related to the estimate of the value of the insurance claim, wherein the estimate may be calculated based on information entered in the first step and in any steps in between the first step and the intermediary step.

[0253] In one embodiment, all or substantially all of the steps associated with using the table of contents may be executed within a single session of an application program executing on a computer system. Therefore, the user of the system need not exit the system and restart from the beginning in order to go back to a previously encountered step.

[0254] FIGS. <b>5</b>B and <b>5</b>Ba depict screen shots which illustrate an example of a table of contents display screen according to two embodiments.

[0255] FIGS. <b>6</b>B and <b>6</b>Ba illustrate exemplary properties and methods associated with a display screen object according to two embodiments.

[0256]FIG. 2C is a flowchart illustrating a method for identifying one or more contributing factors relevant to an estimate of a value of an insurance claim according to one embodiment. In step <b>100</b>C, the user of an insurance claims processing system <b>10</b> may use a client system <b>80</b> to initially configure, define, set up the insurance claim processing system <b>10</b>. This includes installing and executing the insurance claim processing software or program <b>60</b> as well as the insurance database <b>40</b>. The insurance database <b>40</b> may include data for various insurance codes related to injuries and/or treatments. In one embodiment, insurance codes may include injury codes and treatment codes.

[0257] In step <b>110</b>C, one or more insurance codes which are relevant to the value of the insurance claim may be specified in an insurance claims processing program executable on a computer system. Each insurance code may be considered a contributing factor to the estimated value of the insurance claim. These insurance codes may be entered by a user during a consultation session in which a claimant reports his or her injuries and/or treatments for a particular insurance claim. In specifying the one or more insurance codes, a claim number for the insurance claim may be specified, and the one or more insurance codes may be associated with the claim number. The insurance codes may include one or more injury codes, wherein each injury code specifies a bodily injury incurred by the claimant. The insurance codes may include one or more treatment codes, wherein each treatment code specifies a treatment for at least one of the bodily injuries incurred by the claimant.

[0258] A consultation report typically includes an estimated value or range of estimated values for each bodily injury claim. In determining the range of fair estimate value, the insurance claims processing system typically uses contributing factor values, along with regional factors such as cost of living, etc. to arrive at a monetary estimate. Contributing factor values due to bodily injury, in one embodiment, are generally directly proportional to the level of trauma experienced during and after the bodily injury. The insurance claims processing system may be operable to calculate a numeric value for an insurance code wherein, for example, the claimant is in a coma and is on life support system because of a bodily injury. Treatment received for the bodily injury, such as hospitalization, surgery, physical therapy, etc. may contribute to decrease the trauma and hence may result in a decrease of the estimated value. In one embodiment, the contributing factors associated with the treatment code may therefore have a negative value.

[0259] In step <b>120</b>C, one or more contributing factor values may be determined. Each of the contributing factor values corresponds to one of the insurance codes, and each of the contributing factor values measures an estimated impact of the corresponding insurance code on the value of the insurance claim. The insurance claim may include a bodily injury claim, and the contributing factor values may be relevant to an estimate of a bodily injury general damages value of the bodily injury claim. Each of the one or more contributing factor values may include a numeric value. In one embodiment, determining the one or more contributing factor values may include calculating the one or more contributing factor values as a function of one or more business rules. In other words, a rules engine or other expert system may be configured to calculate dynamically the amount that each insurance code adds to or subtracts from the estimate of the value of the insurance claim. This amount contributed by one insurance code may be dependent on the amounts contributed by other specified insurance codes. In one embodiment, the expert system may be developed using the PLATINUM Aion™ rule-based development environment available from Computer Associates International, Inc. In one embodiment, this determination of the contributing factor values may take place after substantially all of the insurance codes have been entered and when a consultation report is desired to be displayed.

[0260] In step <b>130</b>C, each of the one or more insurance codes and the corresponding contributing factor values may be stored in a table. An example of such a table is illustrated in FIG. 3C. FIG. 3C shows a table with a column for the insurance codes (e.g., injury codes and treatment codes) <b>330</b>C and a column for contributing factor values <b>350</b>. The values shown are for purposes of example only and are not intended to be limiting. The table may include one or more rows, wherein each row of the table includes one of the insurance codes and the corresponding contributing factor value. In one embodiment, the table may be implemented as a table in a relational database. In one embodiment, the table may be implemented in accordance with object-oriented techniques of software design.

[0261] In step <b>140</b>C, the table may be sorted by the contributing factor values to generate a sorted table of contributing factor values <b>350</b>C and corresponding insurance codes <b>330</b>C. The table may be sorted by contributing factor value <b>350</b>C in ascending or descending order. A set of contributing factors (i.e., insurance codes) from the sorted table which meet one or more selection criteria may be identified and reported. The set of contributing factors may be included in a consultation report which may be printed and/or displayed on a display device. The selection criteria may include a selection of the largest positive of the one or more contributing factor values up to a certain quantity, such as five. Therefore, identifying and reporting the set of contributing factors from the sorted table may include identifying and reporting a sorted set of the largest contributing factor values up to the certain quantity. In one embodiment, each contributing factor value in the sorted set of the largest positive contributing factor values adds to the estimate of the value of the insurance claim. The selection criteria may include the largest negative of the one or more contributing factor values up to a certain quantity, such as five. Therefore, identifying and reporting the set of contributing factors from the sorted table may include identifying and reporting a sorted set of the largest negative contributing factor values up to the certain quantity. Each contributing factor value in the sorted set of the largest negative contributing factor values subtracts from the estimate of the value of the insurance claim.

[0262]FIG. 2D illustrates one embodiment of a method to transform formula data to formulas for assessing bodily injury damages claims according to one embodiment. In step <b>100</b>D, the user or the administrator of the insurance claim processing system <b>20</b> provides a rules engine, which is capable of processing rules and operating on formulas associated with assessing bodily injury damages claims.

[0263] Business rules, often referred to simply as rules, may include executable computer program instructions. The business rules may invoke, operate or execute formulas to calculate trauma severity values associated with personal bodily injury claims. In one embodiment, the formulas include computer commands or logical instructions to achieve a certain mathematical function, e.g., assess trauma severity value for a spinal injury. Each formula, in one embodiment, may include a function operating on one or more inputs to compute one or more outputs. In another embodiment, the formulas may include a plurality of functions operating on one or more inputs to compute one or more outputs. In one embodiment, the function may be mathematical such as add, subtract, divide, etc. In another embodiment, the function may be based on custom algorithms, for example an algorithm to calculate phantom pain associated with bodily injuries. In one embodiment, the insurance claim processing system may include several formula types, wherein each formula may be specified by a unique function. The formulas may be invoked, operated, executed or fired, under the control of the business rules. Only the pertinent formulas, e.g., a subset of all the available formulas, are typically be selected and executed for processing a specific bodily injury damages claim.

[0264] In step <b>110</b>D, the user or the administrator of the insurance claim processing system <b>20</b> provides a database <b>40</b>, which is external to the rules engine, and is capable of storing and/or retrieving information associated with insurance claim processing. As used herein, the term “external” means that the database is separate from the rules engine. The type of information stored and/or retrieved may include, but not be limited to, business objects, tables, formulas, software source code, executable software, etc. In one embodiment, the database may be relational. In another embodiment, the database <b>40</b> may be an object-oriented database.

[0265] In one embodiment, the database <b>40</b> may include a plurality of tables, which may be accessed by a translator program, also referred to as an application program, to transform, create, generate, or instantiate the data stored in the tables into formulas. In one embodiment, the database may include a plurality of knowledge bases often storing knowledge data in the form of tables. Knowledge-bases may include, but not be limited to, data, tables, program instructions, business rules, objects, etc. The data stored in the knowledge bases may also be in the form of objects. In another embodiment, the translator program may transform data stored in tables into static instances of an object class. In one embodiment, for example, the formula data table shown by way of example in FIG. 3D includes data structured in a tabular format, i.e., a table with several rows and columns. In one embodiment, the Formulas class of objects may include static instances wherein each static instance is a direct representation of a row of data in the formula data table. Thus, the formula data table may include all the relevant information necessary to transform each row of the formula data table into a static instance of the Formula object class.

[0266] In one embodiment, the entire set of business formulas may be grouped or classified into a plurality of formula types. Each formula may have a common construction style, e.g., a function operating on one or more inputs to compute one or more outputs. In one embodiment, there may be several hundred pre-defined formula types. New formula types to meet user requirement may also be created and added to the existing formula type list or table. Data included in the example formulas data table shown in FIG. 3D may typically include information necessary to create a static instance of the Formula object class. The formula data may include a plurality of entries in a table in a database, and the formula data may include a formula identifier <b>300</b>D, a sequence number <b>310</b>D, a section description, a page identifier, a prompt identifier, an answer identifier, a mathematical function or operation <b>320</b>D, a numeric value <b>330</b>D, and other suitable elements.

[0267] In step <b>130</b>D, the translator program initiates the transformation of data stored in the formula data table to formulas i.e. the creation of static instances of the Formula object class, by reading the formula data. In one embodiment, methods such as KBOpen and ControlLoad may be used to open and load the formulas data table. Every knowledge base table has a corresponding object class name in the insurance claim-processing program <b>60</b>. For example, the formula data knowledge base table may have a corresponding formula object class. The contents of each row are read one row at a time.

[0268] In step <b>140</b>D, data entry in each column of the formulas data table is used to transform, or create an instance of the formula class object in the formulas knowledge base. The ControlLoad function determines which set of instances of the Formula class must first be deleted using DeleteInstances (‘Formulas’) and recreated via Class(Formulas).Load function.

[0269] Once created, the instance of the formulas class in the formulas knowledge-base may be invoked, operated, or executed by the business rules by using the calculate method with FormulaID and the sequence number as the parameters. In one embodiment, the calculate method gathers all of the static instances with a specified FormulaID along with a sequence number. The calculate method then interprets the operations and controls how the formula is executed. The resulting output value is used to calculate the trauma severity value.

[0270] Although not explicitly shown, Steps <b>130</b>D and <b>140</b>D may be repeated, in one embodiment, to read all rows of the formulas data table and transform the data to as many instances of the formulas class. On invocation or execution of the static instance, the insurance claim processing software <b>60</b> may compute a trauma severity value applicable to a specific bodily injury claim consultation transaction, and print a consultation report, which summarizes an assessment or estimate of the bodily injury general damages claim.

[0271] In one embodiment, the task of updating, modifying, or revising the formulas may be simplified. To update a formula, the user or the administrator of the insurance claim processing system <b>20</b> may update the data entries stored in the formulas data table. By executing steps <b>130</b>D and <b>140</b>D, the instances of the formulas class may be automatically updated to reflect the changes.

[0272] In another embodiment, the task of customizing of formulas to meet specific user requirements may also be simplified. The customizing of formula data in response to business requirements results in customized formulas. To add a new formula type, the user or the administrator of the insurance claim processing system <b>20</b> may add a new instance of the formulas class and update the database <b>40</b>. By executing steps <b>130</b>D and <b>140</b>D, the formulas may be automatically customized to reflect the new changes.

[0273]FIG. 3D illustrate the tabular structure of the formula data table according to one embodiment. For purposes of example, four columns are illustrated for the table. In one embodiment, the table may comprise fewer or more columns. In one embodiment, the formula data table may be implemented in any number of ways, such as a relational database, in a variety of commercially available database management systems. The formula data table may have as many rows as may be supported by the database management system in which it is implemented. The formula data table may be accessed (e.g., searched, written to, read from, etc.) through a programming interface or standard access mechanism (e.g., SQL) which is supported by the database management system in which the formula data table is implemented.

[0274]FIG. 2E illustrates one embodiment of a method to transform rules data to rules for assessing bodily injury damages claims according to one embodiment. In step <b>100</b>E, the user or the administrator of the insurance claim processing system <b>20</b> provides a rules engine, which is capable of processing rules associated with assessing bodily injury damages claims. The rules engine may be included as part of the insurance claims processing system <b>10</b>, such as the insurance claims processing program <b>60</b>, as shown in FIG. 1<i>a. </i>

[0275] In step <b>110</b>E, the user or the administrator of the insurance claim processing system <b>20</b> provides a database <b>40</b>, which is external to the rules engine, and is capable of storing and/or retrieving information associated with insurance claim processing. The type of information stored and/or retrieved may include, but not be limited to, business objects, tables, rules, software source code, executable software, etc. In one embodiment, the database may be relational. In another embodiment, the database <b>40</b> may be an object-oriented database.

[0276] In one embodiment, the database <b>40</b> may include a plurality of tables, often referred to as knowledge-bases, which may be accessed by a translator program or other application program to transform, create or generate the data stored in the tables into rules. In another embodiment, the application program may transform data stored in tables into static instances of an object class. In one embodiment, for example, the rules data table as shown by way of example in FIG. 3<i>a</i>E includes data structured in a tabular format, i.e., a table with several rows and columns. The rules data table includes all the relevant information necessary to transform each row of the rules data table into an equivalent business rule.

[0277] The entire set of business rules may be grouped or classified into a plurality of rule styles. Each rule style may have a common construction style, i.e., the syntax for the rule premise and the resulting rule action may be common. In one embodiment, there may be several hundred pre-defined rules styles. New rule styles to meet user requirement may also be created and added to the existing rule style list or table. Data included in the rules data table shown in FIG. 3<i>a</i>E may typically include information necessary to construct the rule premise and the resulting one or more rule actions. In one embodiment, the rules data table shown in FIG. 3<i>a</i>E may include, but not be limited to, columns such as an injury code <b>300</b>E, an adjustment type, an adjustment amount <b>310</b>E, a rule style <b>330</b>E, a rule name <b>320</b>E, etc.

[0278] Other types of tables stored in the database <b>40</b>, in one embodiment, may include a LineText table as shown by way of example in FIG. 3<i>c</i>E and a Template table as shown by way of example in FIG. 3<i>b</i>E. The LineText table may store lines or other elements of text which may be used to generate the rules. The Template table may include information which may be used by the application program to read each row of data from the rules data table and transform, create or generate the rules data into a rule. In one embodiment, every rule style may have an entry in the Template table. The location to store the transformed rule, the name of the rules data table, the name of the rule style, an identifier for the line text, etc. may also be included in the Template table, in one embodiment.

[0279] In step <b>130</b>E of FIG. 2E, the application program initiates the transformation of data stored in the rules data table to rules by reading the rules data. In one embodiment, the KBOpen and the ControlLoad methods may be used to open and load the rules data knowledge base table. In one embodiment, every knowledge base table has a corresponding object class name in the insurance claim-processing program <b>60</b>. The contents of each row are read one at a time.

[0280] In step <b>140</b>E, data entries in each column of the rules data table are used to transform, create, or construct the rules. Entries for columns like rules style and rules name in the rules data table may be used as a key to find a matching record in the Template table. Other data stored in the columns of the rules data may be used to build the rule premise and/or the resulting one or more rules action.

[0281] The specific syntax used to construct the rule is specified in the Template for a given rule style <b>330</b>E and a rule name <b>320</b>E. For example, in one embodiment, rule style RS000 and rule name RN000 may specify:

IFMATCH Col#1 WITH Col#2=Col#3 THEN Col#4=Col#5

[0282] where Col#1 through Col#5 entries may be read from data stored in columns 1 through 5 of the rules data table shown in FIG. 3<i>a</i>E and where rule style=RS000 and rule name=RN000. The text string corresponding to the above transformed rule may be stored in the Line_Text <b>370</b>E field of the LineText table shown in FIG. 3<i>c</i>E using Line_TextID <b>360</b>E as a location reference obtained from the Template table shown in FIG. 3<i>b</i>E.

[0283] Although not explicitly shown, Steps <b>130</b>E and <b>140</b>E may be repeated, in one embodiment, to read all rows of the rules data knowledge base table and transform the data to a plurality of rules. On execution of the plurality of rules, applicable to a specific bodily injury claim consultation transaction, the insurance claim processing software <b>60</b> may print a consultation report, which summarizes an assessment for the bodily injuries claim.

[0284] In one embodiment, the task of updating, modifying or revising of rules may be simplified. To update a business rule, the user or the administrator of the insurance claim processing system <b>20</b> may update the data entries stored in the rules data table. By executing steps <b>130</b>E and <b>140</b>E, the rules may be automatically updated to reflect the changes.

[0285] In another embodiment, the task of customizing of rules to meet specific user requirements may also be simplified. To add a new business rule or structurally modify an existing rule, the user or the administrator of the insurance claim processing system <b>20</b> may add a new entry to the rule style and rule name table and update the database <b>40</b>. By executing steps <b>130</b>E and <b>140</b>E, the rules may be automatically customized to reflect the new changes.

[0286]FIGS. 3<i>a</i>E, <b>3</b><i>b</i>E and <b>3</b><i>c</i>E illustrate the tabular structure of the Rules data Table, Template Table and Line Text Table according to one embodiment. Only four columns are illustrated for each of the table. In one embodiment, each of the tables may comprise more or fewer columns. In one embodiment, the tables may be implemented in any number of ways, such as a relational database, in a variety of commercially available database management systems. The tables may have as many rows as may be supported by the database management system in which they are implemented. The tables may be accessed (e.g., searched, written to, read from, etc.) through a programming interface or standard access mechanism (e.g., SQL) which is supported by the database management system in which the tables are implemented. The data shown in the various tables in FIGS. 3<i>a</i>E, <b>3</b><i>b</i>E, and <b>3</b><i>c</i>E are for purposes of example only and are not intended to be limiting.

[0287] In FIG. 4E, an embodiment of the transformation of rules data to rules may include a knowledge table <b>400</b>E. In one embodiment, the knowledge table may be a rules data table as shown in FIG. 3<i>a</i>E. In one embodiment, the knowledge table <b>400</b>E includes data necessary to transform, build, create, define, or generate rules based on a specified rule structure. The transformation method <b>420</b>E (as discussed in greater detail with reference to FIG. 2E) orchestrates the combining of the data from the knowledge table <b>400</b>E and the rule syntax specified in the Template table <b>440</b>E. The transformation method <b>420</b>E may save the rule as text in an associated knowledge base or insurance database.

[0288]FIG. 2F is a flowchart illustrating the generation of a message for processing an insurance claim by an insurance claim processing system, according to one embodiment. In step <b>100</b>F, the user of insurance claims processing system <b>10</b> may use a client system <b>80</b> to initially configure, set up, install and store the software associated with the insurance claims processing system, including all the messages.

[0289] In one embodiment, a message may be defined by a message code and a corresponding message text and both the message code as well as the message text stored in a message table. In another embodiment, as shown in FIG. 4F, the message code may further include a message section <b>300</b>F and a message code identifier <b>310</b>F. The combination of a specific message section and a specific message code identifier uniquely specifies or selects the message text <b>320</b>F from the message table.

[0290] The initial configuration may include specifying or selecting a country and/or a language for the installation. In one embodiment, the selection of a language and/or a country may automatically select a corresponding message text stored in a database. In another embodiment, the user may modify the message text during the installation process.

[0291] In step <b>110</b>F, the application program software executing in the insurance claims processing system <b>10</b> may initiate a request to display a message. This may be in response to the execution of code in another portion of the application program software, in response to a previous user input and/or in response to the execution of a business rule.

[0292] In step <b>120</b>F, the request to retrieve message text is processed further. In one embodiment, the request may be further processed by another portion of the application program software by invoking the GetMessageText method of the Message object, and including values for MsgSectionIn and MsgCodeIn arguments associated with the GetMessageText method. In another embodiment, the processing of the request may include executing software of a subroutine function to retrieve a corresponding message text for a given message code passed along by the requesting program as an input. The message text may be retrieved from a database, in one embodiment or from an object repository in another embodiment.

[0293] In step <b>130</b>F, the message text corresponding to a specified message code is received from step <b>120</b>F. In step <b>140</b>F, the requested message text is sent to the requesting program for display.

[0294]FIG. 3F is a flowchart illustrating a method of using a messages table associated with processing an insurance claim according to one embodiment. In step <b>200</b>F, an insurance claims processing program may generate a request to display a message, wherein the request may include a requested message code. Each message code may include a sequence of alphanumeric values, wherein each sequence is unique relative to the other sequences. In one embodiment, each message code may include a message section and a message code identifier, as further illustrated in FIG. 4F.

[0295] In step <b>210</b>F, a messages table in a database may be searched for a matching entry which matches the requested message code. The table may store a plurality of entries including the matching entry, wherein each entry in the table may include a message code and a corresponding message text. The database may be implemented, for example, as a relational database or an object-oriented database.

[0296] In step <b>220</b>F, the matching entry may be retrieved from the table in response to said searching the table for the matching entry which matches the requested message code, wherein the matching entry comprises a matching message text.

[0297] In step <b>230</b>F, the matching message text corresponding to the requested message code may be displayed by the insurance claims processing program on a display device coupled to a computer system. The message text may be configured to assist a user in processing an insurance claim using the insurance claims processing program.

[0298] In various embodiments, the message text of each entry in the table may be specified during an installation of the insurance claims processing program on a computer system and/or during an installation of the table on a computer system. The message text of each entry in the table in the database may be updated by re-installing the table on the computer system without re-installing the insurance claims processing program on the computer system. The message text of one or more entries in the table may be customized for a particular insurance organization during an installation of the insurance claims processing program on a computer system. Additionally, the message text of one or more entries in the table may be localized for use in a particular geographical location.

[0299] In one embodiment, the insurance claim may include a bodily injury claim, and processing the insurance claim may include processing the bodily injury claim to estimate a bodily injury general damages value. The requested message text may include information relevant to an estimate of a value of the insurance claim. The requested message code may include an injury code which identifies a specific bodily injury, and the requested message text may include a name of the specific bodily injury. The requested message code may include a treatment code which identifies a specific injury treatment, and the requested message text may include a name of the specific injury treatment.

[0300]FIG. 4F is an exemplary diagram of a messages table in a database according to one embodiment. In one embodiment, the messages table may include columns such as message section <b>300</b>F, message code identifier <b>310</b>F, and message text <b>320</b>F. In one embodiment, the messages table may be implemented in any number of ways, such as a relational database, in a variety of commercially available database management systems. The messages table may have as many rows as may be supported by the database management system in which it is implemented. The messages table may be accessed (e.g., searched, written to, read from, etc.) through a programming interface or standard access mechanism (e.g., SQL) which is supported by the database management system in which the messages table is implemented.

[0301] Additional Improvements

[0302] In an embodiment, executable program code used to form at least portions of an insurance claim processing system may be generated from a plurality of business rule components. As used herein, a “business rule component” may refer to a portion of a business rule. In general, business rule components may include templates, program instructions, variables and/or parameters. The business rule components may be stored in one or more database tables (such as are described with reference to FIGS. 3<i>a</i>E, <b>3</b><i>b</i>E, <b>3</b><i>c</i>E, and <b>4</b>F). For example, program code defining one or more business rules used in the system may be formed from at least two business rule components. Each business rule component may be an entry in a database table. In such an embodiment, two or more entries in at least one database table may be combined to form source code for the one or more business rules. The source code may be compiled to form executable code. As used herein, “compiling” refers to transforming from source code (e.g., program instructions, data, etc. provided by a programmer) into computer-executable code. In other embodiments, the source code may include one or more executable script program instructions. As used herein, a “script” refers to a computer-executable program code that does not require a compiling step to be executable on a computer system.

[0303] In an embodiment, one or more database tables used to form business rules may include at least one table having entries that correspond to business rule templates. As used herein, a “business rule template” may refer to a business rule component that includes business rule structure information. As used herein, “business rule structure information” may refer to data specifying a general outline or arrangement of one or more business rules. Business rule structure information may include references to one or more other business rule components. For example, business rule structure information may refer one or more program instructions, one or more business rule variables, and/or one or more business rule parameters. In embodiments described herein, one or more business rule components may be contained in one or more database tables. As used herein, a first business rule component may be said to “refer” to a second business rule component if either the first business rule component or the second business rule component may be used to determine (e.g., access, identify, find the value of, etc.) the other business rule component. Additionally, a first business rule component may be said to “refer” to a second business rule component if either the first business rule component or the second business rule component is associated with data (e.g., a database key) that may be used to determine (e.g., access, identify, find the value of, etc.) the other business rule component.

[0304] In an embodiment, one or more database tables used to form business rules may include at least one table having entries that correspond to business rule program instructions (as described with reference to FIG. 3<i>a</i>E). As used herein, a “program instruction” may refer to a computer-executable command. As used herein, one or more program instructions may be combined to form a “program code.” A business rule program instruction may include references to one or more other database table entries. For example, a business rule program instruction may refer to one or more other program instructions, one or more business rule variables, and/or one or more business rule parameters.

[0305] In an embodiment, one or more database tables used to form business rules may include at least one table having entries that correspond to business rule variables. As used herein, a “business rule variable” may refer to a business rule component that represents a variable in the business rule program code. A business rule variable may include references to one or more other business rule components. For example, a business rule variable may refer to one or more other business rule variables and/or one or more business rule parameters.

[0306] In an embodiment, one or more database tables used to form business rules may include at least one table having entries that correspond to business rule parameters. As used herein, a “business rule parameter” may refer to a business rule component that represents a fixed value in the business rule source code. The value represented by a business rule parameter may be specific to a given business rule, business rule variable, business rule program instruction and/or business rule template. For example, two or more business rules may be formed using the same business rule template, the same program instructions, the same business rule variables, and one or more different business rule parameters.

[0307] In an embodiment, business components may be combined in a transformation method, as described with reference to FIG. 2E. In another embodiment, two or more business rule components may be combined in a rule editor, generally referenced by numeral <b>1200</b> in FIG. 12. As used herein, a “rule editor” may refer to a computer-executable program that combines business rule components to form a graphical display of at least a portion of at least one business rule. For example, in the embodiment depicted in FIG. 12, rule editor <b>1200</b> may combine business rules stored in one or more template tables <b>1202</b>, one or more line text tables <b>1204</b>, one or more knowledge tables <b>1206</b> and/or one or more text tables <b>1208</b> to form a display of at least a portion of at least one business rule. In such an embodiment, template table <b>1202</b> may include one or more business rule templates. Line text table <b>1204</b> may include one or more program instructions. Knowledge table <b>1206</b> may include one or more values for one or more business rule parameters. Text table <b>1208</b> may include one or more human language translations of one or more other business rule components. An advantage of such embodiments may be that viewing source code may be simplified as compared to embodiments where a user views individual component entries in one or more database tables. FIG. 16 depicts an embodiment of a method of generating a graphical display of at least a portion of at least one business rule in a rule editor. In certain embodiments, rule editor <b>1200</b> may combine the business rule components and a transformation method <b>1210</b> may compile the source code. Alternately, a transformation method may be incorporated into rule editor <b>1200</b>.

[0308] In step <b>1605</b> of FIG. 16, at least one first business rule component may be accessed. At least one first business rule accessed may include business rule structure information. For example, at least one first business rule accessed may include a business rule template. At step <b>1610</b>, a plurality of second business rule components may be accessed. For example, the second business rule components may include program instructions, business rule variables and/or business rule parameters. In certain embodiments, the first and/or second business rule components may be stored as entries in one or more database tables. At step <b>1615</b>, a number of the second business rule components accessed may be arranged in the graphical display as directed by the structure information. For example, if the structure information includes an equation listing several variables in a given order, the variables may be displayed in the rule editor as directed by the equation. In another example, the plurality of second business rule components may include two or more program instructions. Step <b>1615</b> may include arranging the program instructions as specified in the business rule structure information, as described with reference to FIGS. 3<i>a</i>E, <b>3</b><i>b</i>E and <b>3</b><i>c</i>E. In certain embodiments, a method of generating a graphical display of at least a portion of at least one business rule in a rule editor may also include determining access privileges of the user, as depicted in step <b>1620</b>. Based on the user's access privileges some information may be inhibited from being displayed.

[0309] A graphical display of a rule editor may include multiple views of at least a portion of at least one business rule. In an embodiment, a plurality of views may be displayed as tabs in a display window. For example, an exemplary embodiment of a graphical display of a rule editor is depicted in FIG. 13 and generally referenced by numeral <b>1300</b>. Each tab of rule editor display <b>1300</b> may correspond to a business rule component and/or a level of access privileges. In such embodiments, only users having appropriate access privileges may view and/or modify information in certain tabs. For example, the rule editor may be configured to allow users to view information on all of the tabs. However, only users having special access privileges may be permitted to modify the information. Alternately, a user's access privileges may also be used to inhibit display of certain information or tabs. In another example, users having a first level of access privileges may modify business rule parameters in the rule editor, but may not change other data. In such cases, users having a second level of access privileges may be allowed to modify business rule variables, templates and/or program instructions, but may not be allowed to modify values of business rule parameters. Users having a third level of access privileges may be allowed to modify any business rule component. In each of the example cases, modifications to database tables based on user modifications in the graphical display may be made immediately or stored in memory until approved.

[0310] In an embodiment, a user may access a display of a business rule template by selecting Template tab <b>1306</b>. In such an embodiment, the user may specify a template to be displayed by selecting a template from template selection field <b>1302</b>. The user may specify a particular business rule to display by selecting the business rule in business rule field <b>1304</b>. The specified business rule may be displayed in rule display <b>1308</b>. Rule display <b>1308</b> may include a display of a plurality of program instructions (e.g., “program instruction 1”, “program instruction 2”, etc.). The program instructions may be arranged sequentially in the order of execution of the instructions, as is common to computer program code. A program instruction may refer to one or more business rule variables and/or one or more business rule parameters. For example, program instruction 1 (referenced by numeral <b>1310</b>) is depicted as being a function of “variable 1” and “parameter 1”. Likewise, program instruction 3 (<b>1318</b>) is depicted a being a function of “parameter 2”. In addition, program instruction 4 (<b>1320</b>) is depicted as being a function of “variable 2” and “parameter 3”. In various embodiments, rule display <b>1308</b> under template tab <b>1306</b> may include data specific to the selected business rule. For example, a value of a business rule parameter may be specific to an individual business rule. The value of the parameter may be displayed in rule display <b>1308</b>. In some embodiments, a template may be used to form a number of different business rules. In such embodiments, rule display <b>1308</b> may not include data particular to an individual business rule. Rather, rule display <b>1308</b> may include information pertaining to all business rules formed using the template. For example, an identifying descriptor may be displayed for “parameter <b>1</b>” and/or “variable <b>1</b>” rather than a particular value. In an embodiment, information specific to a selected business rule may be displayed by selecting the appropriate tab. For example, if the user selects variables tab <b>1312</b>, variables specific to the selected business rule may be filled into the program instructions, as depicted in FIG. 14. If the user selects parameters tab <b>1314</b>, parameters specific to the selected business rule may also be filled in to the program instructions, as depicted in FIG. 15.

[0311] In addition to allowing the user to view business rule source code, rule editor <b>1200</b> may allow the user to modify business rule components. In certain embodiments, modifications made in the rule editor may modify one or more database table entries. For example, in FIG. 14 program instruction <b>1410</b> refers to a “variable 1”. The user may modify program instruction <b>1410</b> in the rule editor to refer to a “variable 2”. In such embodiments, a database table entry corresponding to program instruction <b>1410</b> may be changed to include a reference to the variable 2. In other embodiments, changes made by the user may be stored in a memory without being made to a database table. An advantage of such embodiments may be that the changes stored in memory may be verified and/or approved by another user before changes are made to a database table. In certain embodiments, a rule editor may determine a user's access privileges before or during display of a business rule. The user's access privileges may be used to determine portions of the business rule that the user may change. In addition, the user's access privileges may be used to determine whether changes made by the user are made in one or more database tables or stored in memory for verification by another user. An advantage of such embodiments may be that business rules may be modified by users without substantial programming experience without fear of contaminating the one or more business rule database tables, since experienced programmers may be used to verify entries and/or changes.

[0312]FIG. 17 depicts an embodiment of a method of modifying a business rule in a rule editor. Step <b>1705</b> states that a plurality of business rule components may be provided in a memory of a computer. For example, business rule components may be provided as entries in one or more database tables. The business rule components may include, but are not limited to: business rule templates, program instructions, business rule variables and/or business rule parameters. A plurality of business rule components may be combined in a graphical display to form a display of at least a portion of at least one business rule in step <b>1710</b>. At step <b>1715</b>, input may be received including one or more modifications to at least the displayed business rule. For example, the input may be received from a user or another computer. At least one business rule component may be modified in the memory of the computer based on the one or more modifications input at step <b>1720</b>. For example, one or more SQL commands may be generated to modify one or more database entries. As used herein, “SQL” is a generic term that refers to a programming interface or standard access mechanism usable to access, modify and/or otherwise interact with a database table. The term is not intended to refer exclusively to query languages that meet certain established standards for structured query languages. Rather, the term is intended to refer broadly to any computer executable method usable to access and/or modify database tables. As used herein, an “SQL command” refers to an individual program instruction that is executable to access, modify and/or otherwise interact with a database table. Additionally, in certain embodiments, one or more log file entries may be generated and stored in memory, as shown in step <b>1725</b> (depicted in dotted lines to indicate that this step may not always be present).

[0313] In an embodiment, a rule editor display may allow a user to interact with one or more database tables directly using SQL commands. For example, by selecting SQL tab <b>1328</b>, the user may be presented with an SQL command entry field <b>1802</b>, as depicted in FIG. 18. SQL command entry field <b>1802</b> may allow the user to execute a full range of SQL commands supported by the database management system in which the database tables are implemented. Alternately, SQL command entry field <b>1802</b> may allow the user to execute only a restricted set of SQL commands. In some embodiments, SQL commands that may be executed from SQL command field <b>1802</b> may be restricted based on the access privileges of the user.

[0314] In certain embodiments, a method of modifying a business rule in a rule editor may include determining what changes a user has input. For example, the user may make changes to a business rule in a graphical display of at least a portion of the business rule. The rule editor may compare the content of the graphical display to components of the business rule stored in memory to determine what changes the user has made. For example, the rule editor may determine what changes the user has input if one or more trigger events occur. Trigger events may include making a new selection (e.g. selecting a new business rule component, business rule, tab, etc.). Trigger events may also include closing the rule editor, activating a “save changes” feature or another keystroke or mouse movement. Trigger events may also include passing of a determined period of time (e.g., 5 minutes).

[0315] In an embodiment, a rule editor may provide a user with a listing of business rule components contained in one or more database tables. In such embodiments, the user may select two or more of the business rule components and combine the two or more components in the graphical display to form a new business rule. Alternately, the user may create one or more new business rule components in the graphical display. For example, the user may enter one or more new lines of program instruction. In another example, a new business rule template may be created by specifying an order of program instructions, business rule variables and/or business rule parameters in a business rule. The one or more new business rule components may be saved in one or more database tables. The one or more new business rule components may be combined with one another and/or with previously existing business rule components to form a new business rule.

[0316]FIG. 19 depicts an exemplary embodiment of a method of creating a new business rule in a rule editor. At step <b>1905</b>, a graphical display may be provided. The graphical display may be configured to combine a plurality of business rule components to create a display of at least a portion of a business rule. At step <b>1910</b>, business rule structure information may be determined. For example, a user may select a predefined business rule template. In another example, the user may input (e.g., type) business rule structure information into the rule editor. The rule editor may determine structure information based on the input received. In yet another embodiment, business rule structure information may be determined based on other input. For example, a user may select and arrange one or more business rule components in the graphical display. Business rule structure information may be determined based on the selection and arrangement of the business rule components. For example, the user may specify one or more program instructions. The user may further specify one or more parameters. The user may specify other information as well, such as, but not limited to one or more business rule variables to be included in a specified relationship to one or more program instructions. The new business rule may be stored in a memory associated with a computer system at step <b>1920</b>. For example, the business rule structure information may be stored in the memory with one or more references to business rule program instructions, business rule variables, business rule parameters and/or business rule translations. In an embodiment, the business rule components may be stored as entries in one or more database tables. In embodiments where the business rule structure information and/or program instructions have been selected from a list of predefined business rule components, one or more of the business rule components may be saved as references to the predefined business rule component.

[0317] In some embodiments, a rule component may be used by more than one business rule. For example, a business rule template may define the structure of a business rule. The business rule template may be used with different combinations of business rule program instructions, business rule variables and/or business rule parameters to form different business rules. In another example, a business rule program instruction may be used with different combinations of business rule templates, business rule variables and/or business rule parameters to form different business rules. In such embodiments, a rule editor may display a listing of business rules and/or business rule components that may be affected by changes to one or more selected business rule components.

[0318]FIG. 21 depicts an embodiment of a method of displaying a listing of business rule components related to a selected business rule component. The business rule components may be related in such a manner that a change made to the selected business rule component may affect the listed business rule components. At step <b>2105</b>, a plurality of business rule components may be provided. The business rule components may include business rule templates, program instructions, business rule variables and/or business rule parameters. A plurality of business rules may be formed by combining a number of the business rule components. At least a portion of at least one business rule may be display to a user at step <b>2110</b>. At least one business rule component may be selected in the graphical display in step <b>2115</b>. One or more business rule components that reference the selected business rule component may be determined in step <b>2120</b>. The one or more business rule components determined to reference the selected business rule may be displayed to the user at step <b>2125</b>.

[0319]FIG. 22 depicts an embodiment of a method of generating a graphical display including at least one business rule template that is related to a selected business rule component. At step <b>2205</b>, a plurality of business rule templates may be provided. At step <b>2210</b>, a plurality of business rule components may be provided. A first business rule template may be used to generate a graphical display of at least a portion of at least one business rule in step <b>2215</b>. At step <b>2220</b>, one or more business rule components may be selected in the graphical display. One or more second business rule templates that use the selected business rule component may be determined at step <b>2225</b>. A graphical display that identifies at least one of the second business rule templates may be generated at step <b>2230</b>.

[0320] Referring back to FIG. 15, an embodiment of a display screen including a list of business rule components related to a selected business rule component is depicted. In FIG. 15, “template 1” has been selected in template selection field <b>1302</b>. Additionally, “rule 1” has been specified in rule selection field <b>1304</b>. Thus, the business rule displayed in rule display <b>1308</b> is business rule #1. Within rule display field <b>1308</b>, program instruction 2 (<b>1502</b>) has been selected as indicated by the dotted line surrounding program instruction 2. Thus, program instruction 2 is shown to be the selected business rule component in selected component field <b>1504</b>. Linkages field <b>1506</b> displays a list of all of the business rule templates that use or refer to program instruction 2.

[0321] In an embodiment, the relationships between various business rule components may also be viewed in a database table view. For example, FIG. 20 depicts an embodiment of a Tables tab <b>1326</b> view. Tables tab <b>1326</b> may include table selection field <b>2002</b>. Table selection field <b>2002</b> may allow a user to specify a database table to be viewed in display field <b>2006</b>. Additionally, tables tab <b>1326</b> may include a selection criteria field <b>2004</b>. Selection criteria field <b>2004</b> may allow the user to specify one or more criteria which may be used to constrain the table display. For example, selection criteria field <b>2004</b> may be used to specify one or more search criteria. In such a case, only those database records including specified search criteria may be displayed in display field <b>2006</b>. In another example, selection criteria field <b>2004</b> may be used to specify a sort order in which to display the database table. During use, display field <b>2006</b> may display at least a portion of the contents of a database table. An advantage of displaying database table contents to a user may be that viewing the database table information without modification by the rule editor may allow for increased flexibility in troubleshooting.

[0322] In certain embodiments, a rule editor may save at least one log file of changes made. In various embodiments, a log file may include but is not limited to a listing or description of at least one change made; an identification of a user that made the change; if appropriate, an identification of a user that verified or approved the change; and a time and/or date stamp.

[0323]FIG. 23 depicts an embodiment of a method of tracking changes made to one or more business rule components. In step <b>2305</b>, a plurality of business rule components may be provided in a memory. At step <b>2310</b>, a graphical display of at least a portion of at least one business rule may be generated by combining a plurality of the provided business rule components. The graphical display may be viewed by a user. The user may determine one or more changes to be made to at least the displayed business rule. Input may be received specifying one or more modifications to at least a portion of at least one business rule at step <b>2315</b>. A record of one or more modifications input may be stored in a log file in a memory at step <b>2320</b>. In an embodiment, one or more modifications may be made to one or more business rule components in memory based on the input. Alternately, in some embodiments, the modifications may be stored in memory pending approval by a user having appropriate access privileges.

[0324] An exemplary embodiment of a rule editor window that includes information related to changes made to one or more business rules is depicted in FIG. 24. A user may specify a business rule template and/or a business rule using selection fields <b>1302</b> and <b>1304</b>, as previously described. The user may select audit tab <b>1330</b> to view log file entries related to changes made to the selected business rule template or business rule. For example, a log file entry <b>2404</b> may include a description of a modification made <b>2406</b>. The description may include a user input description of the modification or a computer generated description of the modification. For example, the description may include a copy of one or more business rule components before the modification and a corresponding copy of the one or more business rules including the modification. Log file entry <b>2404</b> may also include a time and/or date stamp <b>2408</b> indicating when the modification was input, stored in memory and/or approved. Log file entry <b>2404</b> may also include an identification of the user that input the modification <b>2410</b> and/or a user that approved the modification <b>2412</b>. Log file entry <b>2404</b> may also include a description of the reason a change was made <b>2414</b>. Additionally, log file entry <b>2404</b> may include an identification of one or more business rule components changed and/or one or more database tables changed.

[0325] In certain embodiments, one or more database tables may include at least one human language translation of at least one business rule component. As used herein, a “human language translation” may refer to an approximate interpretation, explanation, and/or paraphrasing into a human language of the purpose, meaning and/or effect of a business rule component. For example, the human language may be English. For example, the translation may be a simplified description of the effect of the business rule component. In such embodiments, a rule editor may be configured to access at least one human language translation of a business rule component. The rule editor may access and display at least one human language translation in response to a request by the user. In some embodiments, the rule editor may be configured to display at least a portion of a business rule with one or more human language translations substituted into the business rule in place of one or more corresponding business rule components. For example, FIG. 25 depicts a display screen with text tab <b>1316</b> selected. If a user selects text tab <b>1316</b> one or more business rule components may be replaced by one or more corresponding human language translations. Thus, lines <b>2510</b>, <b>2622</b>, <b>2518</b>, <b>2520</b>, and <b>2524</b> may be related to lines <b>1310</b>, <b>1322</b>, <b>1318</b>, <b>1320</b>, and <b>1324</b> of FIG. 13. For example, line <b>2510</b> may be the same as line <b>1310</b> except that program instruction 1 and parameter 1 have been replaced in the display with human language translations. Similarly, program instruction 2 of line <b>1322</b>, program instruction 3 and parameter 2 of line <b>1318</b>, program instruction 4 and parameter 3 of line <b>1320</b>, and program instruction 5 of line <b>1324</b> have been replaced by human language translations in lines <b>2522</b>, <b>2518</b>, <b>2520</b>, and <b>2524</b>, respectively. In other embodiments, human language translations may be substituted for different business rule components. For example, only program instructions may be translated. In another example, only business rule parameters may be translated. An advantage of providing at least one human language translation of a business rule component may be that a user may be better able to understand a business rule or business rule component based on a human language translation than based on one or more lines of source code. For example, such embodiments may be advantageous if users that create, modify and/or approve business rules are not experienced programmers. In an embodiment, a plurality of human language translations of one or more business rule components may be provided. An advantage of providing multiple languages may be that two or more users that prefer different languages may view, create, modify and/or approve business rules.

[0326]FIG. 26 depicts an embodiment of a method of providing a graphical display including at least one human language translation. At step <b>2605</b>, a plurality of business rule components may be provided. For example, the business rule components may include business rule templates, program instructions, business rule variables and/or business rule parameters. At least one human language translation of at least one business rule component may be provided at step <b>2610</b>. Business rule structure information that specifies an arrangement of two or more business rule components to form a business rule may be provided at step <b>2615</b>. For example, a business rule template may be provided. The business rule template may include references to two or more business rule components and an arrangement of the referenced components to form a business rule. At step <b>2620</b>, a graphical display of at least a portion of at least one business rule may be generated. The graphical display may include at least one human language translation of at least one business rule component. For example, in generating the graphical display a human language translations of a business rule components may be displayed in place of the business rule components.

[0327] Various embodiments further include receiving or storing instructions and/or data implemented in accordance with the description herein upon a carrier medium. Suitable carrier media include memory media or storage media such as magnetic or optical media, e.g., disk or CD-ROM, as well as transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as networks and/or a wireless link.

[0328] Although the system and method of the present invention have been described in connection with several embodiments, the invention is not intended to be limited to the specific forms set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the spirit and scope of the invention as defined by the appended claims.