Patent Application
20240028981
The present application generally relates to computer systems and more particularly to computer systems that are adapted to accurately and/or automatically evaluate resource requests for an enterprise.
An enterprise may enter into risk relationships with other parties and respond to resource request. For example, an insurer may arrange to issue insurance policies and provide payments when insurance claim requests satisfy certain requirements.
Note another enterprise 112 may also be wholly or partially responsible for responding to a resource request. For example, in the case of an automobile accident involving two vehicles the insurance companies representing both vehicles may be responsible for providing payments in response to insurance claims. As used herein, the phrase “insurance subrogation” may refer to a right held by an insurer carriers to legally pursue another party associated with an insurance loss to an insured (in order to recover at least some of the amount of the claim paid by the insurer). Typically, when an insurer receives a First Notice Of Loss (“FNOL”) about an insurance claim it may apply business rules to determine if there is “Potential Third-Party Involvement” when the claim is assigned to a claim handler in real time. The claim handler investigates whether subrogation is likely given the facts of the case and, if so, forwards information about the claim to a subrogation specialist. The subrogation specialist reviews the claim handler's investigation and asks the claim handler to obtain any missing information (or may directly request information from the involved parties). The specialist can then resolve the subrogation and secure any appropriate recoveries. Such an approach, however, can be a time-consuming process—especially when a substantial number of claims are received.
It would therefore be desirable to provide improved systems and methods to accurately and/or automatically perform resource request evaluations for an enterprise. Moreover, the results should be easy to access, understand, interpret, update, etc.
According to some embodiments, systems, methods, apparatus, computer program code and means are provided to accurately and/or automatically perform resource request evaluations for an enterprise in a way that provides fast, efficient, and useful results and that allows for flexibility and effectiveness when responding to those results.
Some embodiments are directed to a resource request evaluation system implemented via a back-end application computer server. A resource request data store contains electronic records connected to risk relationships with an enterprise (each record may represent a resource request and include a resource request identifier and request characteristics). A back-end application computer server retrieves request characteristics associated with a resource request for a first party. Based on the request characteristics and business rules, the server determines if the resource request for the first party should be immediately assigned to a request handler. If the request is not to be immediately assigned, the server arranges for the first party to answer a dynamic series of questions. Based on answers provided by the first party and a set of investigation rules, automatically determine if the resource request for the first party should be assigned to the request handler or to a specialist to investigate whether another enterprise may be responsible for responding to the resource request, the system utilizes a machine learning algorithm to evaluate resource requests currently assigned to the request handler to determine if any of those resource requests should instead be routed to the specialist. The resource request is then routed to a request handler or the specialist.
Some embodiments comprise: means for retrieving, by a computer processor of a back-end application computer server from a resource request data store, request characteristics associated with a resource request for a first party, wherein the resource request data store contains electronic records connected to risk relationships with an enterprise, and each electronic record represents a resource request and includes a resource request identifier and a plurality of request characteristics; based on the request characteristics and an initial set of business rules, means for automatically determining if the resource request for the first party should be immediately assigned to a request handler; if the resource request is not to be immediately assigned to the request handler, means for arranging for the first party to answer a dynamic series of questions about the resource request; based on answers provided by the first party and a set of investigation rules, means for automatically determining if the resource request for the first party should be assigned to the request handler or to a specialist to investigate whether another enterprise may be responsible for responding to the resource request; means for utilizing a machine learning algorithm to evaluate resource requests currently assigned to the request handler to automatically determine if any of those resource requests should instead be routed to the specialist; and means for routing the resource request to at least one of the request handler and the specialist.
In some embodiments, a communication device associated with a back-end application computer server exchanges information with remote devices in connection with an interactive graphical resource request evaluation interface. The information may be exchanged, for example, via public and/or proprietary communication networks.
A technical effect of some embodiments of the invention is an improved and computerized way to accurately and/or automatically perform resource request evaluations for an enterprise in a way that provides fast, efficient, and useful results. With these and other advantages and features that will become hereinafter apparent, a more complete understanding of the nature of the invention can be obtained by referring to the following detailed description and to the drawings appended hereto.
Before the various exemplary embodiments are described in further detail, it is to be understood that the present invention is not limited to the particular embodiments described. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of the claims of the present invention.
In the drawings, like reference numerals refer to like features of the systems and methods of the present invention. Accordingly, although certain descriptions may refer only to certain figures and reference numerals, it should be understood that such descriptions might be equally applicable to like reference numerals in other figures.
The present invention provides significant technical improvements to facilitate data availability, consistency, and analytics associated with a resource request evaluation system. The present invention is directed to more than merely a computer implementation of a routine or conventional activity previously known in the industry as it provides a specific advancement in the area of electronic record availability, consistency, and analysis by providing improvements in the operation of a computer system that uses machine learning and/or predictive models to implement a resource request evaluation. The present invention provides improvement beyond a mere generic computer implementation as it involves the novel ordered combination of system elements and processes to provide improvements in the speed at which such data can be made available and consistent results. Some embodiments of the present invention are directed to a system adapted to automatically determine resource request information, analyze electronic records, aggregate data from multiple sources including text mining, determine appropriate subrogation information, etc. Moreover, communication links and messages may be automatically established (e.g., to provide information to a claimant, claim handler, subrogation specialist), aggregated, formatted, exchanged, etc. to improve network performance (e.g., by reducing an amount of network messaging bandwidth and/or storage required to support resource request evaluation).
According to some embodiments, an enterprise may receive and evaluate resource requests. For example,
The back-end application computer server 250 and/or the other elements of the system 200 might be, for example, associated with a Personal Computer (“PC”), laptop computer, smartphone, an enterprise server, a server farm, and/or a database or similar storage devices. According to some embodiments, an “automated” back-end application computer server 250 (and/or other elements of the system 200) may facilitate the automated access and/or update of electronic records. As used herein, the term “automated” may refer to, for example, actions that can be performed with little (or no) intervention by a human.
As used herein, devices, including those associated with the back-end application computer server 250 and any other device described herein, may exchange information via any communication network which may be one or more of a Local Area Network (“LAN”), a Metropolitan Area Network (“MAN”), a Wide Area Network (“WAN”), a proprietary network, a Public Switched Telephone Network (“PSTN”), a Wireless Application Protocol (“WAP”) network, a Bluetooth network, a wireless LAN network, and/or an Internet Protocol (“IP”) network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks.
The back-end application computer server 250 may store information into and/or retrieve information from the resource request data store 220. The data store 220 may be locally stored or reside remote from the back-end application computer server 250. As will be described further below, the resource request data store 220 may be used by the back-end application computer server 250 in connection with a resource request evaluation. Although a single back-end application computer server 250 is shown in
In this way, embodiments may provide the potential for increased subrogation recovery due to specialization and reduce back and forth follow-ups between a claim handler and a subrogation specialist. Embodiments may also potentially reduce the number of customer contacts needed to investigate subrogation and give the enterprise greater control over process and/or quality consistency by utilizing specialists.
Note that the system 200 of
At S310, a computer processor of a back-end application computer server may retrieve (from a resource request data store) request characteristics associated with a resource request for a first party. The resource request data store may, for example, contain electronic records connected to risk relationships with an enterprise (e.g., insurance policies of an insurer), and each electronic record represents a resource request (e.g., a workers' compensation insurance claim) and includes a resource request identifier and a plurality of request characteristics (e.g., information about an insurance claim). Examples of resource request characteristics may include, for example, a first party identifier (e.g., a claimant name and communication link), a risk relationship identifier (e.g., an insurance policy number, and Claim Description Code (“CDC”), etc. The retrieval performed by the back-end application might be associated with the non-digital FNOL intake process or a digital FNOL intake process. Although some embodiments are described with respect to workers' compensation insurance, not that embodiments might instead be associated with automobile insurance, property insurance, group benefits insurance, general liability insurance, etc.
Based on the request characteristics and an initial set of business rules, at S320 the system may automatically determine if the resource request for the first party should be immediately assigned to a request handler. The initial set of business rules might be associated with, for example, a motor vehicle accident insurance claim, a slip or fall insurance claim, an insurance claim involving a third-party, an insurance claim involving machinery, etc.
At S330, if the resource request is not to be immediately assigned to the request handler, the system may arrange for the first party to answer a dynamic series of questions about the resource request. The series of questions may be “dynamically adjusted,” for example, based on request characteristics and answers provided by the first party (e.g., answering one question in a certain way might cause additional questions to be inserted into the series).
Based on answers provided by the first party and a set of investigation rules, at S340 the system may automatically determine if the resource request for the first party should be assigned to the request handler or to a specialist to investigate whether another enterprise may be responsible for responding to the resource request. In some embodiments, the set of investigation rules will categorize the resource request as either “likely subrogation,” “potential subrogation,” or “no subrogation.” In this case, a resource requests categorized as “likely subrogation” or “potential subrogation” might be routed to an insurance subrogation specialist.
At S350, the system may utilize a “machine learning” algorithm to evaluate resource requests currently assigned to the request handler to automatically determine if any of those resource requests should instead be routed to the specialist (e.g., as a “backstop” to identify some additional potential subrogation situations). As used herein, the phrase “machine learning” may refer to artificial intelligence techniques including methods that “learn” (leveraging data to improve performance for a given task). For example, a machine learning algorithm may build a model based on sample data (known as training data) to make predictions or decisions.
At S360, the resource request may be routed to at least one of the request handler and/or the specialist as appropriate. Moreover, in some embodiments, a communication port coupled to the back-end application computer server may facilitate an exchange of data with a remote resource request device to support an interactive graphical resource request display via a distributed communication network. According to some embodiments, interactive graphical resource request display may include a referral rate, a success rate, a recovery rate, an expense ratio, a subrogation rate, graphical trend information, etc.
If a FNOL is received via a digital intake process at 531 (e.g., a web page), a first workflow may evaluate a CDC assigned to the claim at 532. For example, if the If CDC=“Motor Vehicle Accident” (“MVA”), “Slip/Fall”, or “Machinery,” the system may present one or more subrogation investigation questions via the digital interface for the customer to answer at 533. Subrogation decision rules may be applied at 534 resulting in an outcome of “Likely Subrogation,” “Potential Subrogation,” or “No Subrogation.” If the outcome is “Potential Subrogation” or “Likely Subrogation” at 535, a subrogation screen may be created for a claim review display along with a trigger to refer the claim to an insurance subrogation specialist. The subrogation specialist may then review the answers and complete the investigation at 536. If a FNOL is received via a digital intake process at 541 (e.g., a web page), a second workflow may determine if there is a “Potential Third-Party” at 542 (and the CDC is not “MV,” “Slip/Fall,” or “Machinery”). If so, the system may trigger a referral to engage an insurance subrogation specialist at 542, and the subrogation specialist may then manually complete the subrogation investigation at 543.
A predictive model backstop may begin at 551 by executing a batch process on post-FNOL claims. If subrogation potential is identified and subrogation has not been previously flagged by business rules, the system may trigger a potential subrogation activity to an insurance subrogation specialist at 552. The subrogation specialist may then manually complete the subrogation investigation at 553.
According to some embodiments, the subrogation specialist asks an individual who reported a claim an appropriate question set (based on the CDC) via email. The system may evaluate the performance of the question set based on, for example, an average turn-around time for the question set, efficacy, system decision accuracy, specialist efficiency impacts, customer service impacts, potential subrogation leakage, etc. The system may then provide for an automatic refinement of the question set (by adjusting the ordering and/or phrasing of particular questions).
In some embodiments, a claim evaluation system may provide displays to monitor performance. For example,
According to some embodiments, machine learning and/or one or more predictive models may be used to evaluate claim subrogation based on prior events and claims. Features of some embodiments associated with a predictive model will now be described by first referring to
The computer system 700 includes a data storage module 702. In terms of its hardware the data storage module 702 may be conventional, and may be composed, for example, of one or more magnetic hard disk drives. A function performed by the data storage module 702 in the computer system 700 is to receive, store and provide access to both historical claim transaction data (reference numeral 704) and current claim transaction data (reference numeral 706). As described in more detail below, the historical claim transaction data 704 is employed to train a predictive model to provide an output that indicates potential subrogation, and the current claim transaction data 706 is thereafter analyzed by the predictive model. Moreover, as time goes by, and results become known from processing current claim transactions, at least some of the current claim transactions may be used to perform further training of the predictive model. Consequently, the predictive model may thereby adapt itself to changing event impacts and subrogation results.
Either the historical claim transaction data 704 or the current claim transaction data 706 might include, according to some embodiments, as determinate and indeterminate data. As used herein, “determinate data” refers to verifiable facts such as an employer; a claimant; a claim type (e.g., slip and fall); a date of loss, or date of report of claim, or policy date or other date; a time of day; a day of the week; a geographic location, an address or ZIP code; a policy number; etc.
As used herein, “indeterminate data” refers to data or other information that is not in a predetermined format and/or location in a data record or data form. Examples of indeterminate data include narrative speech or text, information in descriptive notes fields and signal characteristics in audible voice data files. Indeterminate data extracted from medical notes or accident reports might be associated with, for example, an amount of loss and/or details about damages.
The determinate data may come from one or more determinate data sources 708 that are included in the computer system 700 and are coupled to the data storage module 702. The determinate data may include “hard” data like a claimant's name, tax identifier umber, policy number, address; the date of loss; the date the claim was reported, etc. One possible source of the determinate data may be the insurance company's policy database (not separately indicated). Another possible source of determinate data may be from data entry by the insurance company's claims intake administrative personnel.
The indeterminate data may originate from one or more indeterminate data sources 710 and may be extracted from raw files or the like by one or more indeterminate data capture modules 712. Both the indeterminate data source(s) 710 and the indeterminate data capture module(s) 712 may be included in the computer system 700 and coupled directly or indirectly to the data storage module 702. Examples of the indeterminate data source(s) 710 may include data storage facilities for document images, for text files (e.g., claim handlers' notes), digitized recorded voice files (e.g., claimants' oral statements, witness interviews, claim handlers' oral notes, etc.), streams of video information, etc. Examples of the indeterminate data capture module(s) 712 may include one or more optical character readers, a speech recognition device (i.e., speech-to-text conversion), a computer or computers programmed to perform natural language processing, a computer or computers programmed to identify and extract information from narrative text files, a computer or computers programmed to detect key words in text files, and a computer or computers programmed to detect indeterminate data regarding an individual. For example, claim handlers' opinions may be extracted from their narrative text file notes.
The computer system 700 also may include a computer processor 714. The computer processor 714 may include one or more conventional microprocessors and may operate to execute programmed instructions to provide functionality as described herein. Among other functions, the computer processor 714 may store and retrieve historical claim transaction data 704 and current claim transaction data 706 in and from the data storage module 702. Thus, the computer processor 714 may be coupled to the data storage module 702.
The computer system 700 may further include a program memory 716 that is coupled to the computer processor 714. The program memory 716 may include one or more fixed storage devices, such as one or more hard disk drives, and one or more volatile storage devices, such as RAM devices. The program memory 716 may be at least partially integrated with the data storage module 702. The program memory 716 may store one or more application programs, an operating system, device drivers, etc., all of which may contain program instruction steps for execution by the computer processor 714.
The computer system 700 further includes a predictive model component 718. In certain practical embodiments of the computer system 700, the predictive model component 718 may effectively be implemented via the computer processor 714, one or more application programs stored in the program memory 716, and data stored as a result of training operations based on the historical claim transaction data 704 (and possibly also data received from a third-party reporting service). In some embodiments, data arising from model training may be stored in the data storage module 702, or in a separate data store (not separately shown). A function of the predictive model component 718 may be to determine appropriate simulation models, results, and/or scores (e.g., a rating indicating a likelihood of subrogation). The predictive model component may be directly or indirectly coupled to the data storage module 702.
The predictive model component 718 may operate generally in accordance with conventional principles for predictive models, except, as noted herein, for at least some of the types of data to which the predictive model component is applied. Those who are skilled in the art are generally familiar with programming of predictive models. It is within the abilities of those who are skilled in the art, if guided by the teachings of this disclosure, to program a predictive model to operate as described herein.
Still further, the computer system 700 includes a model training component 720. The model training component 720 may be coupled to the computer processor 714 (directly or indirectly) and may have the function of training the predictive model component 718 based on the historical claim transaction data 704 and/or information about subrogation events, incidents, and alerts. (As will be understood from previous discussion, the model training component 720 may further train the predictive model component 718 as further relevant data becomes available.) The model training component 720 may be embodied at least in part by the computer processor 714 and one or more application programs stored in the program memory 716. Thus, the training of the predictive model component 718 by the model training component 720 may occur in accordance with program instructions stored in the program memory 716 and executed by the computer processor 714.
In addition, the computer system 700 may include an output device 722. The output device 722 may be coupled to the computer processor 714. A function of the output device 722 may be to provide an output that is indicative of (as determined by the trained predictive model component 718) subrogation likelihood, events, insurance underwriting parameters, and recommendations. The output may be generated by the computer processor 714 in accordance with program instructions stored in the program memory 716 and executed by the computer processor 714. More specifically, the output may be generated by the computer processor 714 in response to applying the data for the current simulation to the trained predictive model component 718. The output may, for example, be a monetary estimate, a risk level, and/or likelihood within a predetermined range of numbers. In some embodiments, the output device may be implemented by a suitable program or program module executed by the computer processor 714 in response to operation of the predictive model component 718.
Still further, the computer system 700 may include a monitoring platform 724. The monitoring platform 724 may be implemented in some embodiments by a software module executed by the computer processor 714. The monitoring platform 724 may have the function of rendering a portion of the display on the output device 722. Thus, the monitoring platform 724 may be coupled, at least functionally, to the output device 722. In some embodiments, for example, the monitoring platform 724 may direct workflow by referring, to resource request platform 726, subrogation recommendations and/or alerts generated by the predictive model component 718 and found to be associated with various results or scores. In some embodiments, this data may be provided to a specialist 728 (e.g., via an automatically established communication link) who may investigate insurance claims as appropriate.
The embodiments described herein may be implemented using any number of different hardware configurations. For example,
The processor 1010 also communicates with a storage device 1030. The storage device 1030 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, mobile telephones, and/or semiconductor memory devices. The storage device 1030 stores a program 1015 and/or a resource request evaluation tool or application for controlling the processor 1010. The processor 1010 performs instructions of the program 1015, and thereby operates in accordance with any of the embodiments described herein. For example, the processor 1010 may retrieve request characteristics associated with a resource request for a first party. Based on the request characteristics and business rules, the processor 1010 may determine if the resource request for the first party should be immediately assigned to a request handler. If the request is not to be immediately assigned, the processor 1010 may arrange for the first party to answer a dynamic series of questions. Based on answers provided by the first party and a set of investigation rules, automatically determine if the resource request for the first party should be assigned to the request handler or to a specialist to investigate whether another enterprise may be responsible for responding to the resource request, the processor 1010 may utilize a machine learning algorithm to evaluate resource requests currently assigned to the request handler to determine if any of those resource requests should instead be routed to the specialist. The resource request may then be routed to a request handler or the specialist.
The program 1015 may be stored in a compressed, uncompiled and/or encrypted format. The program 1015 may furthermore include other program elements, such as an operating system, a database management system, and/or device drivers used by the processor 1010 to interface with peripheral devices.
As used herein, information may be “received” by or “transmitted” to, for example: (i) the apparatus 1000 from another device; or (ii) a software application or module within the apparatus 1000 from another software application, module, or any other source.
In some embodiments (such as shown in
Referring to
The workers' compensation claim identifier 1102 may be, for example, a unique alphanumeric code identifying a request from an employee who suffered a work-related injury or sickness. The claim description code 1104 may indicate how the injury occurred (e.g., in a motor vehicle accident, slip and fall, etc.). The employee identifier 1106 may identify the claimant and the answers 1108 may indicate how he or she responded to a dynamic series of subrogation related questions. The routing 1110 may indicate who received information about the claim for follow-up activities (e.g., a claim handler and/or subrogation specialist).
Thus, embodiments may provide an automated and efficient way to perform a resource request evaluations. This may lead to improved subrogation recovery rates for an enterprise, a better experience for then insured (e.g., by limiting interactions with the insurer), etc. The following illustrates various additional embodiments of the invention. These do not constitute a definition of all possible embodiments, and those skilled in the art will understand that the present invention is applicable to many other embodiments. Further, although the following embodiments are briefly described for clarity, those skilled in the art will understand how to make any changes, if necessary, to the above-described apparatus and methods to accommodate these and other embodiments and applications.
Although specific hardware and data configurations have been described herein, note that any number of other configurations may be provided in accordance with embodiments of the present invention (e.g., some of the information associated with the displays described herein might be implemented as a virtual or augmented reality display and/or the databases described herein may be combined or stored in external systems). Moreover, although embodiments have been described with respect to specific types of enterprises (e.g., an insurance company), embodiments may instead be associated with other types of enterprises in addition to and/or instead of those described herein (e.g., financial institutions, hospitals, etc.). Similarly, although certain types of resource request characteristics were described in connection some embodiments herein, other types of characteristics might be used instead of, or in addition to, those mentioned.
Note that the displays and devices illustrated herein are only provided as examples, and embodiments may be associated with any other types of interfaces. For example,
The present invention has been described in terms of several embodiments solely for the purpose of illustration. Persons skilled in the art will recognize from this description that the invention is not limited to the embodiments described but may be practiced with modifications and alterations limited only by the spirit and scope of the appended claims.
