Insurance

Systems and methods for a graphical input display in an insurance processing system

Insurance Abstract
A graphical display in an insurance processing system is disclosed. The graphical display may include a human body representation. The human body representation may provide information to a user that is helpful in specifying insurance claim information. For example, the representation may provide information regarding body parts, information regarding injury codes, information regarding common injuries, information regarding common treatments and/or information regarding treatment codes. The representation may also be used to provide input into the insurance processing system. In some embodiments, menus may be provided on various graphical representations for inputting body parts, respective injuries, and treatments.

Insurance Claims
1. A method, comprising: providing a graphical display in an insurance claim processing system comprising at least one human body representation; selecting a body part on at least one human body representation; displaying input selection information related to the selected body part; and receiving an input selection via the displayed input selection information; wherein the input selection information comprises a listing of at least one subpart.

2. The method of claim 1, wherein the input selection information further comprises a listing of at least one injury for at least one subpart and the input selection comprises selecting an injury from the listing of at least one injury.

3. The method of claim 1, wherein the listing of at least one subpart appears for a body part when a user selects the body part.

4. The method of claim 3, wherein the listing of at least one injury for at least one subpart appears for the subpart when the subpart is selected from the listing of at least one subpart.

5. The method of claim 1, wherein the input selection information for the selected body part comprises a listing of at least one subpart and a listing of at least one injury.

6. The method of claim 5, wherein the input selection information for a listing of at least one injury further comprises a listing of at least one treatment.

7. The method of claim 6, wherein a listing of at least one treatment appears when an injury is selected from a listing of at least one injury.

8. The method of claim 1, wherein at least one human body representation comprises a representation of at least one of a human musculature, a human nervous system, a human skeletal system, and a human skin.

9. The method of claim 1, further comprising displaying a menu near the selected body part.

10. The method of claim 1, further comprising distinguishing the body part selected by at least one of highlighting, outlining, and circling the selected body part.

11. The method of claim 1, further comprising distinguishing a body part for which input selection has been received.

12. The method of claim 11, wherein an indicator used for a body part that is currently selected is different from a body part from which an input selection has been received.

13. The method of claim 1, further comprising displaying a more detailed view of a body part, in response to the body part being selected in the graphical display.

14. The method of claim 1, wherein the listing of at least one subpart appears in a popup menu.

15. The method of claim 14, further comprising displaying a popup menu of at least one injury type for a subpart when the subpart is selected.

16. The method of claim 1, wherein a subpart in the listing of at least one subpart is a node, wherein selecting the node displays a listing of at least one injury for the subpart.

17. The method of claim 1, further comprising displaying a listing of received input selections.

18. The method of claim 17, further comprising displaying an indicator next to a listing of a received input selection to indicate whether the input selection should be considered in a respective insurance claim.

19. The method of claim 1, further comprising displaying a listing of available human body representations.

20. The method of claim 19, further comprising displaying an indicator relative to a listing of a human body representation to indicate the human body representations that have had input selections entered.

21. A carrier medium comprising program instructions, wherein the program instructions are executable to implement a method of: providing a graphical display in an insurance claim processing system comprising at least one human body representation; selecting a body part on at least one human body representation; displaying input selection information related to the selected body part; and receiving an input selection via the displayed input selection information; wherein the input selection information comprises a listing of at least one subpart.

22. The carrier medium of claim 21, wherein the input selection information further comprises a listing of at least one injury for at least one subpart and the input selection comprises selecting an injury from the listing of at least one injury.

23. The carrier medium of claim 21, wherein the listing of at least one subpart appears for a body part when a user selects the body part.

24. The carrier medium of claim 23, wherein the listing of at least one injury for at least one subpart appears for the subpart when the subpart is selected from the listing of at least one subpart.

25. The carrier medium of claim 21, wherein the input selection information for the selected body part comprises a listing of at least one subpart and a listing of at least one injury.

26. The carrier medium of claim 25, wherein the input selection information for a listing of at least one injury further comprises a listing of at least one treatment.

27. The carrier medium of claim 26, wherein a listing of at least one treatment appears when an injury is selected from a listing of at least one injury.

28. The carrier medium of claim 21, wherein at least one human body representation comprises a representation of at least one of a human musculature, a human nervous system, a human skeletal system, and a human skin.

29. The carrier medium of claim 21, wherein the program instructions are further executable to implement displaying a menu near the selected body part.

30. The carrier medium of claim 21, wherein the program instructions are further executable to implement distinguishing the body part selected by at least one of highlighting, outlining, and circling the selected body part.

31. The carrier medium of claim 21, wherein the program instructions are further executable to implement distinguishing a body part for which input selection has been received.

32. The carrier medium of claim 31, wherein an indicator used for a body part that is currently selected is different from a body part from which an input selection has been received.

33. The carrier medium of claim 21, wherein the program instructions are further executable to implement displaying a more detailed view of a body part, in response to the body part being selected in the graphical display.

34. The carrier medium of claim 21, wherein the listing of at least one subpart appears in a popup menu.

35. The carrier medium of claim 34, wherein the program instructions are further executable to implement displaying a popup menu of at least one injury type for a subpart when the subpart is selected.

36. The carrier medium of claim 21, wherein a subpart in the listing of at least one subpart is a node, wherein selecting the node displays a listing of at least one injury for the subpart.

37. The carrier medium of claim 21, wherein the program instructions are further executable to implement displaying a listing of received input selections.

38. The carrier medium of claim 37, wherein the program instructions are further executable to implement displaying an indicator next to a listing of a received input selection to indicate whether the input selection should be considered in a respective insurance claim.

39. The carrier medium of claim 21, wherein the program instructions are further executable to implement displaying a listing of available human body representations.

40. The carrier medium of claim 39, wherein the program instructions are further executable to implement displaying an indicator relative to a listing of a human body representation to indicate the human body representations that have had input selections entered.

41. An insurance claim processing system, comprising: a CPU; a memory coupled to the CPU, wherein the memory comprises program instructions executable to implement: providing a graphical display in an insurance claim processing system comprising at least one human body representation; selecting a body part on at least one human body representation; displaying input selection information related to the selected body part; receiving an input selection via the displayed input selection information; and wherein the input selection information comprises a listing of at least one subpart.

42. The system of claim 41, wherein the input selection information further comprises a listing of at least one injury for at least one subpart and the input selection comprises selecting an injury from the listing of at least one injury.

43. The system of claim 41, wherein the listing of at least one subpart appears for a body part when a user selects the body part.

44. The system of claim 43, wherein the listing of at least one injury for at least one subpart appears for the subpart when the subpart is selected from the listing of at least one subpart.

45. The system of claim 41, wherein the input selection information for the selected body part comprises a listing of at least one subpart and a listing of at least one injury.

46. The system of claim 45, wherein the input selection information for a listing of at least one injury further comprises a listing of at least one treatment.

47. The system of claim 46, wherein a listing of at least one treatment appears when an injury is selected from a listing of at least one injury.

48. The system of claim 41, wherein at least one human body representation comprises a representation of at least one of a human musculature, a human nervous system, a human skeletal system, and a human skin.

49. The system of claim 41, wherein the program instructions are further executable to implement displaying a menu near the selected body part.

50. The system of claim 41, wherein the program instructions are further executable to implement distinguishing the body part selected by at least one of highlighting, outlining, and circling the selected body part.

51. The system of claim 41, wherein the program instructions are further executable to implement distinguishing a body part for which input selection has been received.

52. The system of claim 51, wherein an indicator used for a body part that is currently selected is different from a body part from which an input selection has been received.

53. The system of claim 41, wherein the program instructions are further executable to implement displaying a more detailed view of a body part, in response to the body part being selected in the graphical display.

54. The system of claim 41, wherein the listing of at least one subpart appears in a popup menu.

55. The system of claim 54, wherein the program instructions are further executable to implement displaying a popup menu of at least one injury type for a subpart when the subpart is selected.

56. The system of claim 41, wherein a subpart in the listing of at least one subpart is a node, wherein selecting the node displays a listing of at least one injury for the subpart.

57. The system of claim 41, wherein the program instructions are further executable to implement displaying a listing of received input selections.

58. The system of claim 57, wherein the program instructions are further executable to implement displaying an indicator next to a listing of a received input selection to indicate whether the input selection should be considered in a respective insurance claim.

59. The system of claim 41, wherein the program instructions are further executable to implement displaying a listing of available human body representations.

60. The system of claim 59, wherein the program instructions are further executable to implement displaying an indicator relative to a listing of a human body representation to indicate the human body representations that have had input selections entered.

61. A method, comprising: providing a graphical display in an insurance claim processing system comprising at least one human body representation; displaying a listing of at least one subpart associated with a body part on the human body representation; receiving input corresponding to at least one body part on the at least one human body representation; and highlighting at least one body part corresponding to the received input on at least one human body representation.

Insurance Description
web server.

[0300] 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 250A, 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.

[0301] In step 252A, 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 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.

[0302] In step 254A, 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.

[0303] 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.

[0304] 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.

[0305] 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 302A, 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.

[0306] In one embodiment, in step 304A, 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 306A, the second page of insurance claim assessment data, including the specialized navigation commands, may be displayed in the browser.

[0307] In step 308A, 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.

[0308] In step 310A, 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.

[0309] In one embodiment, the state of the "conversation" between the browser and the insurance claim processing server may be preserved by a COM component 66A, as discussed with reference to FIG. 5A. In step 312A, 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.

[0310] In step 314A, 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.

[0311] In step 316A, 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.

[0312] 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 100B, the user of an insurance claims processing system 10 may use a client system 80 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.

[0313] 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. 6B and 6Ba show a few examples of the properties and methods associated with a display screen object according to two different embodiments.

[0314] 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. 5B and 5Ba 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.

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

[0316] In step 130B, 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 60 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.

[0317] If the claim number is found in step 120B, the insurance claim processing software will generate a request to display the table of contents screen in step 140B. When the IC user has entered the claim definition data for a new claim number in step 130B, a request may be made to display the table of contents screen in step 140B. In step 150B, 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 160B, the newly generated TOC display is sent to the display screen 50 for display to the IC user.

[0318] FIG. 3B illustrates one embodiment of a program or method to build a table of contents display. In step 152B, 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.

[0319] In step 154B, the insurance claim processing software 60 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.

[0320] In step 156B, 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.

[0321] In step 158B, 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.

[0322] In step 159B, 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.

[0323] 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 500B, 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 50 coupled to a computer system 10. 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.

[0324] 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.

[0325] In step 510B, 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 520B, 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 530B, the entered information may be stored in a memory.

[0326] In step 540B, 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.

[0327] In step 550B, 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 560B, the selected step may then be displayed in response to the user selecting the selected step in the table of contents. In step 570B, in one embodiment, the entered information in the selected step may be modified and stored after selecting the step in the table of contents.

[0328] 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.

[0329] 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.

[0330] 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.

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

[0332] FIG. 6B and 6Ba illustrate exemplary properties and methods associated with a display screen object according to two embodiments.

[0333] 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 100C, the user of an insurance claims processing system 10 may use a client system 80 to initially configure, define, set up the insurance claim processing system 10. This includes installing and executing the insurance claim processing software or program 60 as well as the insurance database 40. The insurance database 40 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.

[0334] In step 110C, 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.

[0335] 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.

[0336] In step 120C, 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.TM. 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.

[0337] In step 130C, 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) 330C and a column for contributing factor values 350. 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.

[0338] In step 140C, the table may be sorted by the contributing factor values to generate a sorted table of contributing factor values 350C and corresponding insurance codes 330C. The table may be sorted by contributing factor value 350C 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.

[0339] 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 100D, the user or the administrator of the insurance claim processing system 20 provides a rules engine, which is capable of processing rules and operating on formulas associated with assessing bodily injury damages claims.

[0340] 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 selected and executed for processing a specific bodily injury damages claim.

[0341] In step 110D, the user or the administrator of the insurance claim processing system 20 provides a database 40, 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 40 may be an object-oriented database.

[0342] In one embodiment, the database 40 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.

[0343] 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 300D, a sequence number 310D, a section description, a page identifier, a prompt identifier, an answer identifier, a mathematical function or operation 320D, a numeric value 330D, and other suitable elements.

[0344] In step 130D, 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 60. 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.

[0345] In step 140D, 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.

[0346] 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.

[0347] Although not explicitly shown, Steps 130D and 140D 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 60 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.

[0348] 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 20 may update the data entries stored in the formulas data table. By executing steps 130D and 140D, the instances of the formulas class may be automatically updated to reflect the changes.

[0349] 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 20 may add a new instance of the formulas class and update the database 40. By executing steps 130D and 140D, the formulas may be automatically customized to reflect the new changes.

[0350] 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.

[0351] 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 100E, the user or the administrator of the insurance claim processing system 20 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 10, such as the insurance claims processing program 60, as shown in FIG. 1a.

[0352] In step 110E, the user or the administrator of the insurance claim processing system 20 provides a database 40, 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 40 may be an object-oriented database.

[0353] In one embodiment, the database 40 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. 3aE 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.

[0354] 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. 3aE 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. 3aE may include, but not be limited to, columns such as an injury code 300E, an adjustment type, an adjustment amount 310E, a rule style 330E, a rule name 320E, etc.

[0355] Other types of tables stored in the database 40, in one embodiment, may include a LineText table as shown by way of example in FIG. 3cE and a Template table as shown by way of example in FIG. 3bE. 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.

[0356] In step 130E 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 60. The contents of each row are read one at a time.

[0357] In step 140E, 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.

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

[0359] IFMATCH Col#1 WITH Col#2=Col#3 THEN Col#4=Col#5

[0360] 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. 3aE 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 370E field of the LineText table shown in FIG. 3cE using Line_TextID 360E as a location reference obtained from the Template table shown in FIG. 3bE.

[0361] Although not explicitly shown, Steps 130E and 140E 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 60 may print a consultation report, which summarizes an assessment for the bodily injuries claim.

[0362] 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 20 may update the data entries stored in the rules data table. By executing steps 130E and 140E, the rules may be automatically updated to reflect the changes.

[0363] 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 20 may add a new entry to the rule style and rule name table and update the database 40. By executing steps 130E and 140E, the rules may be automatically customized to reflect the new changes.

[0364] FIGS. 3aE, 3bE and 3cE 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 tables. 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. 3aE, 3bE, and 3cE are for purposes of example only and are not intended to be limiting.

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

[0366] 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 100F, the user of insurance claims processing system 10 may use a client system 80 to initially configure, set up, install and store the software associated with the insurance claims processing system, including all the messages.

[0367] 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 300F and a message code identifier 310F. The combination of a specific message section and a specific message code identifier uniquely specifies or selects the message text 320F from the message table.

[0368] 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.

[0369] In step 110F, the application program software executing in the insurance claims processing system 10 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.

[0370] In step 120F, 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.

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

[0372] 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 200F, 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.

[0373] In step 210F, 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.

[0374] In step 220F, 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.

[0375] In step 230F, 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.

[0376] 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.

[0377] 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.

[0378] 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 300F, message code identifier 310F, and message text 320F. 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.

[0379] 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. 3aE, 3bE, 3cE, and 4F). 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.

[0380] 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.

[0381] 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. 3aE). 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.

[0382] 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.

[0383] 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.

[0384] 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 1200 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 1200 may combine business rules stored in one or more template tables 1202, one or more line text tables 1204, one or more knowledge tables 1206 and/or one or more text tables 1208 to form a display of at least a portion of at least one business rule. In such an embodiment, template table 1202 may include one or more business rule templates. Line text table 1204 may include one or more program instructions. Knowledge table 1206 may include one or more values for one or more business rule parameters. Text table 1208 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 1200 may combine the business rule components and a transformation method 1210 may compile the source code. Alternately, a transformation method may be incorporated into rule editor 1200.

[0385] In step 1605 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 1610, 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 1615, 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 1615 may include arranging the program instructions as specified in the business rule structure information, as described with reference to FIGS. 3aE, 3bE and 3cE. 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 1620. Based on the user's access privileges some information may be inhibited from being displayed.

[0386] 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 1300. Each tab of rule editor display 1300 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.

[0387] In an embodiment, a user may access a display of a business rule template by selecting Template tab 1306. In such an embodiment, the user may specify a template to be displayed by selecting a template from template selection field 1302. The user may specify a particular business rule to display by selecting the business rule in business rule field 1304. The specified business rule may be displayed in rule display 1308. Rule display 1308 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 1310) is depicted as being a function of "variable 1" and "parameter 1". Likewise, program instruction 3 (1318) is depicted a being a function of "parameter 2". In addition, program instruction 4 (1320) is depicted as being a function of "variable 2" and "parameter 3". In various embodiments, rule display 1308 under template tab 1306 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 1308. In some embodiments, a template may be used to form a number of different business rules. In such embodiments, rule display 1308 may not include data particular to an individual business rule. Rather, rule display 1308 may include information pertaining to all business rules formed using the template. For example, an identifying descriptor may be displayed for "parameter 1" and/or "variable 1" 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 1312, 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 1314, parameters specific to the selected business rule may also be filled in to the program instructions, as depicted in FIG. 15.

[0388] In addition to allowing the user to view business rule source code, rule editor 1200 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 1410 refers to a "variable 1". The user may modify program instruction 1410 in the rule editor to refer to a "variable 2". In such embodiments, a database table entry corresponding to program instruction 1410 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.

[0389] FIG. 17 depicts an embodiment of a method of modifying a business rule in a rule editor. Step 1705 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 1710. At step 1715, 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 1720. 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 1725 (depicted in dotted lines to indicate that this step may not always be present).

[0390] 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 1328, the user may be presented with an SQL command entry field 1802, as depicted in FIG. 18. SQL command entry field 1802 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 1802 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 1802 may be restricted based on the access privileges of the user.

[0391] 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).

[0392] 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.

[0393] FIG. 19 depicts an exemplary embodiment of a method of creating a new business rule in a rule editor. At step 1905, 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 1910, 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 1920. 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.

[0394] 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.

[0395] 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 2105, 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 2110. At least one business rule component may be selected in the graphical display in step 2115. One or more business rule components that reference the selected business rule component may be determined in step 2120. The one or more business rule components determined to reference the selected business rule may be displayed to the user at step 2125.

[0396] 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 2205, a plurality of business rule templates may be provided. At step 2210, 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 2215. At step 2220, 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 2225. A graphical display that identifies at least one of the second business rule templates may be generated at step 2230.

[0397] 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 1302. Additionally, "rule 1" has been specified in rule selection field 1304. Thus, the business rule displayed in rule display 1308 is business rule #1. Within rule display field 1308, program instruction 2 (1502) 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 1504. Linkages field 1506 displays a list of all of the business rule templates that use or refer to program instruction 2.

[0398] 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 1326 view. Tables tab 1326 may include table selection field 2002. Table selection field 2002 may allow a user to specify a database table to be viewed in display field 2006. Additionally, tables tab 1326 may include a selection criteria field 2004. Selection criteria field 2004 may allow the user to specify one or more criteria which may be used to constrain the table display. For example, selection criteria field 2004 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 2006. In another example, selection criteria field 2004 may be used to specify a sort order in which to display the database table. During use, display field 2006 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.

[0399] 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.

[0400] FIG. 23 depicts an embodiment of a method of tracking changes made to one or more business rule components. In step 2305, a plurality of business rule components may be provided in a memory. At step 2310, 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 2315. A record of one or more modifications input may be stored in a log file in a memory at step 2320. 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.

[0401] 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 1302 and 1304, as previously described. The user may select audit tab 1330 to view log file entries related to changes made to the selected business rule template or business rule. For example, a log file entry 2404 may include a description of a modification made 2406. 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 2404 may also include a time and/or date stamp 2408 indicating when the modification was input, stored in memory and/or approved. Log file entry 2404 may also include an identification of the user that input the modification 2410 and/or a user that approved the modification 2412. Log file entry 2404 may also include a description of the reason a change was made 2414. Additionally, log file entry 2404 may include an identification of one or more business rule components changed and/or one or more database tables changed.

[0402] 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 1316 selected. If a user selects text tab 1316 one or more business rule components may be replaced by one or more corresponding human language translations. Thus, lines 2510, 2622, 2518, 2520, and 2524 may be related to lines 1310, 1322, 1318, 1320, and 1324 of FIG. 13. Forexample, line 2510 maybe the same as line 1310 except that program instruction 1 and parameter 1 have been replaced in the display with human language translations. Similarly, program instruction 2 of line 1322, program instruction 3 and parameter 2 of line 1318, program instruction 4 and parameter 3 of line 1320, and program instruction 5 of line 1324 have been replaced by human language translations in lines 2522, 2518, 2520, and 2524, 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.

[0403] FIG. 26 depicts an embodiment of a method of providing a graphical display including at least one human language translation. At step 2605, 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 2610. 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 2615. 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 2620, 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 human language translations of business rule components may be displayed in place of the business rule components.

[0404] In certain embodiments, an insurance claim processing system may include a graphical display 2700 for input and display of information as depicted in FIG. 27. In such embodiments, graphical display 2700 may include a human body representation 2702. For example, human body representation 2702 may include a photograph, graphic image and/or a silhouette of a human body. Representation 2702 may depict at least a number of major body parts 2704 (e.g., torso, head, arms and legs). In certain embodiments, representation 2702 may further include minor body parts/subparts 2706 (e.g., neck, fingers, toes, etc.) and/or portions of specific anatomical systems (e.g., bones of the skeletal system as depicted in FIGS. 30 and 31). Human body representation 2702 may include a number of different views that may be displayed simultaneously, individually or in groups. For example, FIG. 27 includes a depiction of a skin layer of a male 2708, FIG. 28 includes a depiction of a skin layer of a female 2802, FIG. 29 includes a depiction of a muscular layer 2902 and FIG. 30 includes a depiction of a skeletal layer 3004. Each view (or layer) may include at least one anatomical system. Additionally, individual organs associated with an anatomical system may be depicted. If all of the available layers are not depicted simultaneously, the user may be able to select a layer to view. For example, a layer selection mechanism 2710 may be provided.

[0405] In an embodiment, a human body representation may provide a user with descriptive information about various body parts. For example, referring to FIG. 29, when the user selects a body part 2904, the graphic display may present information describing the body part (e.g., name, major functions, components, etc.) in a description field 2908. In certain embodiments, insurance related information may be provided in description field 2908 or in another description field (e.g., input field 2910) when a body part is selected. For example, injuries common to selected body part 2904 may be displayed. In such a case, the injury information may include one or more injury codes associated with selected body part 2904. In another example, the insurance related information may include one or more common medical treatments associated with the selected body part. An example of a human body representation including a number of layers is available from A.D.A.M. Inc. of Atlanta, Ga.

[0406] In various embodiments, the body part or body parts of interest may be selected using various selection methods. For example, a "hover" method may allow a user to select a body part using a cursor-positioning device. Similarly, a user may position a pointer 2906 over a body part of interest using a cursor-positioning device (e.g., a mouse, joystick, trackball, etc.) and depress a select button to select a body part. The user may also be provided with one or more input fields 2910. In such a case, the user may provide input via one or more input fields 2910 to select a body part of interest. Additionally, in embodiments where the user is provided with one or more input fields 2910, input fields 2910 may be populated with data as the user makes selections in graphical display 2700. For example, if a user selects a fracture to the upper arm in graphical display 2700, one or more input fields 2910 may be populated with data reflecting the selected information. Populating the input fields may provide a double check to reduce the likelihood of input errors. Additionally, populating the input fields may assist in familiarizing users with various insurance related codes (e.g., injury codes, treatment codes, etc.). In any of these cases, the selected body part may be highlighted in graphical display 2700. As used herein, "highlighting" refers to modifying the display to provide a visual indication that an area has been selected. For example, highlighting may include, but is not limited to: changing the color, changing the brightness, changing the location and/or outlining the selected body part.

[0407] In an embodiment, upon selection of a body part(s) the user may be provided with a menu including one or more input selections related to the selected body part. For example, the menu may provide a selection of subparts of the selected body part. A "subpart" of a body part may refer to a body part or system within the selected body part. For example, as depicted in FIG. 30, the user may select spine 3002 from a skeletal layer 3004. Menu 3006 may be changed to include relatively broad selections associated with spine 3002, such as central nervous system or spinal column. Alternately, the menu may include more detailed selections such as individual bones of the spine, individual bones of the skull and/or individual portions of the central nervous system. In another example, menu 3006, provided when a body part is selected, may include a selection of input data related to the selected body part such as common injuries, injury codes, common medical treatments and/or treatment codes associated with the selected body part. In such a case, the user may select one or more menu selections to provide input to the insurance claim processing system regarding injuries suffered and/or treatments provided. In an embodiment, a number of menu lists may be presented to the user in series to allow selection of both a subpart and insurance information (e.g., injury codes, treatment codes, etc.). Such menu lists may be arranged to minimize the number of menus that a user must go through in order to provide desired input.

[0408] In an embodiment, additional graphical elements may be provided in graphical display 2700 when a body part is selected. For example, when the user selects spine 3002 (as shown in FIG. 30), graphical display 2700 may be changed to show a detailed view 3102 of the spine (as depicted in FIG. 31). The additional graphical elements may replace or supplement one or more human body representations in the display screen. In certain embodiments, a photograph including a selected body part may be included in the graphical display. In certain embodiments, a more detailed graphic depiction of the selected body part may be provided. For example, the display may zoom in on the selected body part as depicted in FIG. 31. Additionally, one or more additional graphical elements may include alternate views of the selected body part. For example, the body part may be rotated in one or more additional graphical elements. If the user has provided information identifying an injury or injury code, a graphic element may depict an example of the injury. For example, a photograph of a patient having the identified injury may be displayed. If the injury is relatively localized, the graphical element depicting the injury may depict the injury as it may affect the selected body part. Similarly, if a treatment is identified and related to a particular body part, a graphical element depicting the treatment as it applies to the particular body part may be displayed.

[0409] FIG. 32 illustrates a screenshot of an embodiment for input and display of information for an insurance claim. In some embodiments, a user may select from a displayed listing 3204 of available anatomical systems. For example, a user may select a skeletal view 3203 from the list. The user may move a selection indicator, such as a mouse pointer, on the screen, or in some other way select an anatomical system. In some embodiments, the anatomical system may be selected when a mouse pointer is moved over an anatomical system name or if the user clicks on the anatomical system name (e.g., skeletal view 3203). In some embodiments, the human body representation 3202 may switch to the selected representation (e.g., a skeletal representation 3202) when the user selects the desired anatomical system from the list.

[0410] A user may select a body part on the human body representation 3202, e.g., by moving a mouse pointer on the screen over the body part or moving a mobile highlighted region over the body part using arrow keys on a keyboard. Other ways of selecting a body part may also be used. In some embodiments, the selected body part may be distinguished by highlighting (e.g., in yellow) when it is selected. In some embodiments, different highlighting colors may be used for different body parts (e.g., subparts of the spine may be highlighted in blue). In some embodiments, the selected body part may be outlined or circled in addition to or instead of highlighting.

[0411] In various embodiments, a name of the selected body part may be displayed in a structure name box 3201. For example, if a user moves a mouse pointer over the ribs on the representation 3202, "Ribs" may be displayed in the structure name box 3201. Other ways of indicating the body part name may also be used. In addition, other information may also be displayed in the structure name box 3201 or displayed in some other way relative to the body part location.

[0412] In an embodiment, as seen in FIG. 32, a user may select a right shoulder 3205. In some embodiments, the user may click on the right shoulder 3205 or move a mouse cursor over the right shoulder 3205. In some embodiments, an injury 3211 for the selected body part may be entered by the user in an injury text box 3217 or using a menu (not shown). In some embodiments, a user may use abbreviations for injuries 3209, as listed on a screen, when entering injuries for the selected body part. In some embodiments, injuries for body parts in the skeletal representation 3202 may include dislocation, disc injury, fracture, fracture/dislocation, and subluxation. In some embodiments, a part may be selected on the skeletal representation 3202 that does not correspond to a bone (e.g., an elbow). In addition, injuries not related to the displayed representation may also be entered. For example, injuries, such as a muscle sprain, not related to the displayed skeletal representation 3202 may be entered.

[0413] In some embodiments, if an injury is entered for a body part, the body part may be designated as an injured body part. For example, an injured body part may be highlighted in red on the skeletal representation 3202. In some embodiments, different types of injured body parts may be highlighted in different colors (e.g., injured parts of the spine may be highlighted in orange). In some embodiments, a user may select which colors to use for highlighting different body parts. In some embodiments, different degrees of injury may also be designated in different ways.

[0414] In various embodiments, an injury code 3215 may be entered to represent an injury or information related to an injury for a body part in the representation. In some embodiments, the injury code may be automatically displayed based on an entered injury without a user having to separately enter the injury code 3215. In some embodiments, a check box 3213, or some other indicator, may be provided next to the displayed listing of the injury. In some embodiments, the check box 3213 may be used to indicate whether the injury has been verified. In some embodiments, the check box 3213 may be unchecked to remove an injury from consideration in an insurance claim (e.g., in calculating damages). In some embodiments, the injury may remain listed (even though not considered, i.e., checked) in the insurance claim and may be rechecked to add the injury to the claim. For example, if an injury has not been confirmed, the injury may be entered, unselected, and then selected when confirmed (e.g., by a doctor). In some embodiments, the injury may not be checked when the injury is first entered.

[0415] In various embodiments, multiple body parts may be selected in the skeletal representation 3202. For example, the hand 3207 may be selected to indicate an injury to a little finger and the right shoulder 3205 may be selected to indicate an injury for the right shoulder 3205. In some embodiments, general notes about a selected body part may also be included. For example, a complaint may be entered for a body part (e.g., if pain is indicated in a body part, but an injury has not been identified).

[0416] As seen in FIG. 33, a spine 3301 in the skeletal representation 3202 may be selected. In some embodiments, information, including the body part name and additional information about the body part, may be displayed relative to the selected body part. For example, in some embodiments, the body part name and information may be displayed in a structure name box 3303. Other locations may also be used. FIG. 34 shows another example in which a left navicular 3401 and a right femur 3409 has been selected. Respective injuries 3405 and 3407 may be entered for the selected navicular and femur. In some embodiments, different highlighting or indicators may be used for a body part that is currently selected and body parts that have been previously selected and had a respective injury entered. For example, different color shading, outlining, circling, etc. may be used for different types of indicators.

[0417] FIG. 35 illustrates a screen shot of an embodiment for inputting and displaying information about a spine. In some embodiments, spine 3509 may be on the listing of anatomical systems to display. Other body parts may also be put onto the listing. In some embodiments, an indicator 3511 may be displayed relative to an anatomical system listed to indicate that input information relative to the anatomical system has been received. For example, a check mark may be displayed next to "Skeletal" in the listing of anatomical systems to indicate that the user has input information relative to skeletal injuries.

[0418] In some embodiments, a body part of the anatomical system may be selected (e.g., by a mouse pointer, etc.) and an input menu may be displayed near the selected body part. For example, the T10 vertebrae may be selected and a menu 3507 may be displayed. In some embodiments, the menu may display body parts and/or subparts relative to the selected region. In one embodiment, "T10" 3505 may be displayed as the relevant body part highlighted. In some embodiments, a user may want to select a body part from the menu and a further listing of relevant injuries (e.g., fracture 3503) may be displayed. Other information may be displayed in the menu in place of or in addition to the listing of injuries. In some embodiments, a user may select an injury from the listing and the injury may be considered in the insurance claim. In some embodiments, injury 3513 may be listed. Further menus (e.g., listings of treatments for injuries) may also be displayed. In some embodiments, each of the body parts and injuries relative to the body parts may be displayed at the same time. In some embodiments, each level of the menu may only become visible as respective parts of the superceding menu are selected (e.g., the injuries for a body part may be displayed after the body part is selected). In some embodiments, the body parts and/or subparts may be nodes such that when a node is selected, further information (e.g., injuries) are listed relative to the node. In some embodiments, a scroll bar 3515 and/or close mechanism 3517 may be included with the menu. In various embodiments, the menu may be a popup menu 3507. In some embodiments, separate popup menus may be used for body parts and injuries. In some embodiments, body parts and injuries may be listed on the same popup menu 3507. In some embodiments, injuries may be listed under respective body parts on the popup menu. For example, after a body part has been selected, respective injuries may be displayed beneath the body part on the menu. In some embodiments, the popup menus may disappear after an injury is selected, after a user clicks off of the popup menu, or after a close mechanism 3517 on the popup menu is selected. In some embodiments, body parts and respective injuries may be displayed on a different part of the screen. For example, a fixed screen box (not shown) may be used to display body parts and injuries respective to a body part highlighted. In addition to body parts and injuries, in some embodiments, additional information and selections may be displayed. For example, respective treatments may be displayed under each injury. In some embodiments, when a user selects an injury from the menu, possible treatments for the injury may be displayed relative to the injury selected. The user may then select from the displayed treatments.

[0419] FIG. 36 illustrates a screen shot of an embodiment for inputting and displaying information relative to human skin. In some embodiments, a skin representation 3607 may be displayed when skin is selected from a listing of available representations. In an embodiment, a chest 3601 may be selected and highlighted. The structure name box may display "Chest" 3605 indicating the name of the selected region. In some embodiments, injuries associated with the skin representation 3607 may include amputation, concussion, crush, extensive soft-tissue, de-gloving, contusion, soft-tissue, whiplash, laceration, penetration, and superficial. Other injuries may also be included (e.g., a closed head injury).

[0420] FIG. 37 illustrates a screen shot of an embodiment for entering information relative to an abdomen region 3701. In some embodiments, a menu 3707 (e.g., a popup menu) may be displayed with body parts and subparts (e.g., diaphragm 3709). Injuries (e.g., contusion 3711 and laceration 3713) may be listed relative to the body parts in the menu to allow a user to select the appropriate injury. Other information may also be listed (e.g., types of treatments may be listed under each injury).

[0421] FIG. 38 illustrates a screen shot of an embodiment for inputting information relative to a muscular representation 3802. "Muscular" 3803 may be selected from a listing of human body representations available and a muscular representation 3802 may be displayed. In some embodiments, because no information was entered relative to the skin representation, a check may not be placed next to the skin representation in the listing. This may assist an adjuster in remembering to go back to the skin representation to further input information. In some embodiments, when the chest region 3801 is selected, relative body parts and subparts (e.g., back, intercostals joint, left sterno clavicular and right sterno clavicular) may be listed in a menu displayed relative to the chest region 3801. A user may select a body part, such as the left sterno clavicular 3807, and relative injuries may be displayed. For example, sprain 3809 may be selected from a drop down list for the left sterno clavicular 3807.

[0422] FIG. 39 illustrates a flowchart of an embodiment for receiving input selection information for a selected body part. For example, a graphical user interface may be used to receive information relative to a human body representation.

[0423] At 3901, a graphical display in an insurance claim processing system may display a human body representation. In some embodiments, multiple representations including skeletal, muscular, and skin representations may be available. In some embodiments, a user may select a representation to be displayed by selecting a representation from a list of available representations.

[0424] At 3903, a body part on at least one human body representation may be selected. For example, a right shoulder may be selected. In some embodiments, the selected body part may be visibly distinguished from the other body parts in the representation (e.g., by being highlighted).

[0425] At 3905, input selection information related to the selected body part may be displayed. For example, a listing of possible injuries for the selected body part may be listed in a menu placed relative to the body part. In some embodiments, information relative to the body part may be displayed in a separate graphical box on a display. Other placements of information may also be used.

[0426] At 3907, an input selection may be received via displayed input selection information. For example, a user may select an injury from a menu displayed relative to the selected body part. In some embodiments, a user may type the information related to an injury.

[0427] FIG. 40 illustrates a flowchart of an embodiment for highlighting a selected body part and receiving related input. In some embodiments, a graphical user interface may be used to receive information relative to a highlighted body part in a displayed human body representation.

[0428] At 4001, a graphical display may be provided in an insurance claim processing system to display a human body representation. In some embodiments, an input field may also be displayed. For example, the input field may be a graphical box for typing in input related to the human body representation. In some embodiments, input may be entered through a menu of input selections. For example, a menu may appear for a body part when a mouse cursor moves over the body part.

[0429] At 4003, a listing of subparts associated with a body part may be displayed. For example, a menu of related subparts may be displayed for a body part when a mouse cursor is moved over the body part. In some embodiments, a user may click on the body part for the menu of related subparts to be displayed. In some embodiments, a more detailed view of the body part selected may be displayed when the user selects the body part.

[0430] At 4005, a listing of injuries for the subparts may be displayed. In some embodiments, a listing of injuries for a subpart may be displayed under the corresponding subpart when a subpart is selected in a menu of subparts. In some embodiments, the injuries may be displayed automatically under the subparts in the menu. In some embodiments, a separate menu of injuries may be displayed for the subparts.

[0431] At 4007, input may be received. In some embodiments, the input received may relate to a body part (e.g., the received input may correspond to an injury to a body part). In some embodiments, the input may be typed into an input field (e.g., a graphical box). In some embodiments, an input selection may be selected from a menu. For example, the input may be an injury selection from a listing of injuries.

[0432] At 4009, a body part may be highlighted on the human body representation corresponding to the received input. For example, if an injury is input for a right shoulder, the right shoulder may be highlighted. In some embodiments, body parts for which input has been received may be highlighted a different color than body parts for which input has not been received (e.g., body parts that are selected but have not yet had input entered).

[0433] In some embodiments, extensible markup language (XML) documents may be used to create a graphic injury display (GID) as shown in FIGS. 32-38. For example text for view selectors (e.g., representation names in a listing of available human body representations) may be retrieved using information from an XML document. A display order attribute may be included in the XML document for each view element (e.g., parts of the display) to determine the order of placement of the view selectors on the GID. In some embodiments, each view may have an identifier by which it may be referenced. For example, in some embodiments, selected body parts ("hotspots") may have a unique identifier to indicate they should be highlighted in the GID.

[0434] 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.

[0435] In this patent, certain U.S. patents, U.S. patent applications, and other materials (e.g., articles) have been incorporated by reference. The text of such U.S. patents, U.S. patent applications, and other materials is, however, only incorporated by reference to the extent that no conflict exists between such text and the other statements and drawings set forth herein. In the event of such conflict, then any such conflicting text in such incorporated by reference U.S. patents, U.S. patent applications, and other materials is specifically not incorporated by reference in this patent.

[0436] 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.


20050091085 Method for evaluating the value of group and individual insurance products
20050086085 Methods of offering and providing a variable life insurance product
20050086084 Method of administrating insurance coverage for multi tasks building projects
20050075911 Method for producing, selling, and delivering data required by mortgage lenders and servicers to comply with flood insurance monitoring requirements
20050071203 Insurance marketplace
20050071202 System of charging for automobile insurance
20050071201 Method of providing insurance coverage as a security deposit guarantee
20050060208 Method for optimizing insurance estimates utilizing Monte Carlo simulation
20050060207 Claims paid insurance
20050060205 Systems and methods for a graphical input display in an insurance processing system
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Home | Latest Patent | Glasses USA | Trade USA | php | Science | Glasses | Desiccant | Eyeglasses
Copyright © 2004 - 2015 Insurance All rights reserved. | Site Map | Privacy Policy