CN117480518A - Machine learning driven real-time data analysis - Google Patents

Abstract

A data processing system implementation for insurance claim analysis and arbitration: obtaining policy coverage information for each of a plurality of policies and policy claim information associated with a plurality of policy claims associated with an insured user, analyzing the policy claim information using first machine learning to obtain event related claim grouping information; analyzing the event-related claim grouping information and the normalized policy information using a second machine learning model to obtain coverage prediction information, the coverage prediction information including predictions for each of the one or more events; identifying respective ones of the plurality of insurance policies that may cover one or more claims associated with each event, the second machine learning model being trained using second training data formatted according to a standard pattern; and providing, via the network connection, the coverage prediction information to a computing device associated with the insured user.

Description

Machine learning driven real-time data analysis

Cross Reference to Related Applications

The present application claims the benefit of priority from U.S. patent application Ser. No. 17/228,975, filed on day 2021, month 4, and 13, and U.S. patent application Ser. No. 11,170,450, now issued on day 2021, month 11, and month 9, entitled "MACHINE-LEARNING DRIVEN REAL-TIME DATA ANALYSIS," and pending U.S. patent application Ser. No. 17/499,485, filed on day 2021, month 10, and entitled "MACHINE-LEARNING DRIVEN REAL-TIME DATA ANALYSIS," which are incorporated herein by reference in their entirety.

Background

Submission of insurance claims (insurance claima) can be a confusing and stressful process. The insured may be covered by a plurality of insurance policies, each insurance policy providing coverage for various types of claims, such as, but not limited to, medical insurance, dental insurance, accident insurance, hospital reimbursement insurance, and automotive insurance. Each of these policies may cover a variety of different types of claims, and the insured may not fully understand the details of the coverage provided by each of the policies or how the claims are submitted for reimbursement. Thus, the insured may miss the opportunity for a claim that would otherwise be reimbursed by one of the insurers (insurs). Accordingly, there is a need to provide improved systems and methods for solving the following technical problems: the insurance claims and policy information are automatically analyzed to identify insurance companies that may cover the insurance claims to improve the odds of the insurance claims.

Disclosure of Invention

An example data processing system according to the present disclosure may include: a processor; and a computer readable medium storing executable instructions. The instructions, when executed, cause a processor to perform operations comprising: obtaining electronic copies of a plurality of insurance policies associated with the insured users; analyzing the electronic copies of the plurality of policies to generate policy coverage information for each of the policies; converting the policy overlay information from a first format to a second format to generate standardized policy overlay information, the second format being associated with a standard schema for processing the policy and claim information; obtaining electronic copies of a plurality of insurance claims associated with an insured user; analyzing the electronic copies of the plurality of insurance claims to generate insurance claim information; converting the insurance claim information from the third format to a fourth format to generate normalized insurance claim information, the fourth format being associated with a standard pattern for processing insurance policies and claim information; providing normalized insurance claim information as input to the first machine learning model; analyzing the normalized insurance claim information using a first machine learning model to identify occurrences of a first type of event and a first set of insurance claims associated with the first type of event, wherein the first machine learning model is trained using first training data formatted according to a standard pattern to predict and output an indication of occurrences of the type of event requiring medical treatment based on the set of insurance claims associated with the insured user; providing as input to the second machine learning model a first set of insurance claims, an indication of occurrence of a first type of event, and normalized policy information; analyzing the first set of insurance claims, the indication of occurrence of the first type of event, and the normalized policy information using a second machine learning model trained using second training data formatted according to a standard pattern to identify one or more types of insurance policies in the normalized policy information that are likely to cover the first set of insurance claims, and predicting whether a corresponding policy of the plurality of insurance policies is likely to cover the first set of insurance claims by comparing the first set of insurance claims to the policy specifications of the corresponding policy; providing respective ones of the insurance policies output by the second machine learning model to the user interface module that will cover the first set of insurance claims; and causing a user interface to be presented on a display of a computing device associated with the insured user to direct the insured user to submit the first set of insurance claims to the insurance provider associated with the corresponding insurance policy.

An example method implemented in a data processing system for insurance claim analysis and arbitration, comprising: obtaining electronic copies of a plurality of insurance policies associated with the insured users; analyzing the electronic copies of the plurality of policies to generate policy coverage information for each of the policies; converting the policy overlay information from a first format to a second format to generate standardized policy overlay information, the second format being associated with a standard schema for processing the policy and claim information; obtaining electronic copies of a plurality of insurance claims associated with an insured user; analyzing the electronic copies of the plurality of insurance claims to generate insurance claim information; converting the insurance claim information from the third format to a fourth format to generate normalized insurance claim information, the fourth format being associated with a standard pattern for processing insurance policies and claim information; providing normalized insurance claim information as input to the first machine learning model; analyzing the normalized insurance claim information using a first machine learning model to identify occurrences of a first type of event and a first set of insurance claims associated with the first type of event, wherein the first machine learning model is trained using first training data formatted according to a standard pattern to predict and output an indication of occurrences of the type of event requiring medical treatment based on the set of insurance claims associated with the insured user; providing as input to the second machine learning model a first set of insurance claims, an indication of occurrence of a first type of event, and normalized policy information; analyzing the first set of insurance claims, the indication of occurrence of the first type of event, and the normalized policy information using a second machine learning model trained using second training data formatted according to a standard pattern to identify one or more types of insurance policies in the normalized policy information that are likely to cover the first set of insurance claims, and predicting whether a corresponding policy of the plurality of insurance policies is likely to cover the first set of insurance claims by comparing the first set of insurance claims to the policy specifications of the corresponding policy; providing respective ones of the insurance policies output by the second machine learning model to the user interface module that will cover the first set of insurance claims; and causing a user interface to be presented on a display of a computing device associated with the insured user to direct the insured user to submit the first set of insurance claims to the insurance provider associated with the corresponding insurance policy.

An example machine readable storage medium having instructions stored thereon that, when executed, cause a processor of a programmable device to: obtaining electronic copies of a plurality of insurance policies associated with the insured users; analyzing the electronic copies of the plurality of policies to generate policy coverage information for each of the policies; converting the policy overlay information from a first format to a second format to generate standardized policy overlay information, the second format being associated with a standard schema for processing the policy and claim information; obtaining electronic copies of a plurality of insurance claims associated with an insured user; analyzing the electronic copies of the plurality of insurance claims to generate insurance claim information; converting the insurance claim information from the third format to a fourth format to generate normalized insurance claim information, the fourth format being associated with a standard pattern for processing insurance policies and claim information; providing normalized insurance claim information as input to the first machine learning model; analyzing the normalized insurance claim information using a first machine learning model to identify occurrences of a first type of event and a first set of insurance claims associated with the first type of event, wherein the first machine learning model is trained using first training data formatted according to a standard pattern to predict and output an indication of occurrences of the type of event requiring medical treatment based on the set of insurance claims associated with the insured user; providing as input to the second machine learning model a first set of insurance claims, an indication of occurrence of a first type of event, and normalized policy information; analyzing the first set of insurance claims, the indication of occurrence of the first type of event, and the normalized policy information using a second machine learning model trained using second training data formatted according to a standard pattern to identify one or more types of insurance policies in the normalized policy information that are likely to cover the first set of insurance claims, and predicting whether a corresponding policy of the plurality of insurance policies is likely to cover the first set of insurance claims by comparing the first set of insurance claims to the policy specifications of the corresponding policy; providing respective ones of the insurance policies output by the second machine learning model to the user interface module that will cover the first set of insurance claims; and causing a user interface to be presented on a display of a computing device associated with the insured user to direct the insured user to submit the first set of insurance claims to the insurance provider associated with the corresponding insurance policy.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.

Drawings

The drawings depict one or more implementations consistent with the present teachings by way of example only and not by way of limitation. In the drawings, like reference numbers indicate identical or similar elements. Furthermore, it should be understood that the drawings are not necessarily drawn to scale.

FIG. 1 is a diagram illustrating an example computing environment in which the techniques disclosed herein may be implemented.

FIG. 2 is a diagram of an example architecture that may be used, at least in part, to implement the Claim Analysis and Arbitration System (CAAS) shown in FIG. 1.

Fig. 3 is a diagram illustrating an example architecture of CAAS that may be used to implement additional details of the CAAS shown in fig. 1 and 2.

Fig. 4 is a diagram illustrating an example architecture of CAAS that may be used to implement additional details of the CAAS shown in fig. 1-3.

5A, 5B, 5C, 5D, 5E, 5F, 5G, and 5H illustrate example user interfaces for linking a CAAS account to an insurance company account.

6A, 6B, 6C, 6D, 6E, and 6F illustrate example user interfaces for providing advice for submitting a claim.

FIG. 7 is a flow chart of an example process for claim analysis arbitration.

Fig. 8 is a block diagram illustrating an example software architecture, portions of which may be used in conjunction with the various hardware architectures described herein, which may implement any of the described features.

FIG. 9 is a block diagram illustrating components of an example machine configured to read instructions from a machine-readable medium and perform any of the features described herein.

Detailed Description

In the following detailed description, numerous specific details are set forth by way of examples in order to provide a thorough understanding of the relevant teachings. It will be apparent, however, that the present teachings may be practiced without these details. In other instances, well-known methods, procedures, components, and/or circuitry have been described at a relatively high-level, without detail, in order to avoid unnecessarily obscuring aspects of the present teachings.

Techniques for machine learning driven insurance claim analysis and arbitration that provide a solution to the problem of determining whether an insurer associated with an insurance policy is likely to reimburse an insured for an insured life are described herein. The machine learning model may be trained to analyze policy information for policies associated with insurers, insurance claim information and prescription information submitted on behalf of the insurers, and output one or more predictions of whether a particular insurer associated with one of the policies will pay for the claim. The insured may have multiple insurance policies, each having a complex listing of the types of claims that the insurer can cover, and coverage limits that provide the conditions under which the insurer can cover such claims. The insured typically does not know the large number of coverage limits associated with each policy in the policy and may miss the opportunity for the insurer to reimburse for the claim because the claim is submitted to the wrong insurer or fails to submit a claim that the insured has access to coverage. The techniques provided herein may identify insurance policies that may reimburse a user for a claim by analyzing the policy documents to obtain coverage information including, but not limited to, the type of claim covered by each policy, the coverage limits provided by each policy, other information that may be used to determine whether an insurance company may cover a particular claim, or a combination thereof. The techniques described herein may also track the claims submitted by insurers over time, predict that the claims are relevant to a particular type of event using a machine learning model trained to analyze the claims, and group the claims into groups of claims predicted to be associated with a particular event. Examples of types of events that may be identified include, but are not limited to, car accidents, sports injuries, disease-related events, or other types of events that a machine learning model may be trained to identify that may be related to one or more specific types of claims. The set of claims can then be analyzed and predictions are generated that a particular insurance company may cover the claim or set of claims. In the event that a determination prediction cannot be made as to whether a particular insurer can reimburse the insured for a particular claim or claim set, the user may be presented with a set of dynamic questions to clarify whether the particular insurer can reimburse a particular claim or group of claims, or to clarify the distinction between multiple insurers that can reimburse a claim or claim set. The technical benefit of this approach is that the system can identify patterns of insurance claims over time and provide suggestions to the insured how to make the insurer reimburse for those claims. Thus, the odds of an insurance claim can be significantly improved as compared to the manual processing of the claim by an insured. Another technical benefit provided by the techniques described herein is that machine learning models may be trained using data that has been parsed and normalized to standard patterns. Furthermore, the data to be analyzed by the machine learning model may also be parsed and normalized. Thus, the description used by the format of the data received by the machine learning model is consistent with the training data used to train the model. Thus, the predictions provided by the model may be significantly improved over models that are not trained using such techniques. The techniques provided herein also provide for substantially real-time analysis of claim information from a combination of data sources, which may also significantly improve the predictions provided by the machine learning model, and provide suggestions to the user that are more likely to allow the user to optimize their equity use by using accurate and updated date information. These and other technical benefits of the technology disclosed herein will be apparent from the following discussion of example implementations.

The technology provided herein meets a long felt need for improved insurance claim analysis and arbitration to provide an insured person with means for optimizing their network usage. Furthermore, the solutions provided for this problem stem from computer technology to overcome problems arising in the field of computer systems, thereby providing substantially real-time analysis and arbitration of claims in a manner that accurately predicts which insurers might cover a particular set of claims.

FIG. 1 is a diagram illustrating an example computing environment 100 in which the techniques for insurance claim analysis and arbitration disclosed herein may be implemented. The computing environment 100 can include a Claim Analysis and Arbitration System (CAAS) 105, one or more client devices 115, one or more insurance company portals (portals) 125, one or more provider portals 135, and one or more third party data providers 130. The example implementation shown in fig. 1 includes three client devices 115a, 115b, and 115c, but the techniques described herein may be used with different numbers of client devices 115. Client devices 115a, 115b, and 115c may communicate with CAAS105, insurance company portal 125, provider portal 135, and/or third party data providers via network 120. CAAS105 may also communicate with client devices 115a, 115b, and 115c, insurance company portal 125, provider portal 135, and/or third party data provider 130 via network 120. Network 120 may include one or more wired and/or wireless public networks, private networks, or a combination thereof. Network 120 may be implemented at least in part by the internet.

Client devices 115a, 115b, and 115c may be used by insurers to access services provided by CAAS105, insurance information from insurer portal 125, and/or information from third party data provider 130. Client devices 115a, 115b, and 115c are each computing devices that may be implemented as portable electronic devices (e.g., mobile phones, tablet computers, laptop computers, portable digital assistant devices, portable game consoles, and/or other such devices). Client devices 115a, 115b, and 115c may also be implemented with computing devices having other form factors (e.g., desktop computers, in-vehicle computing systems, kiosks, point-of-sale systems, video game consoles, and/or other types of computing devices). Although the example implementation shown in fig. 1 includes three client devices, other implementations may include a different number of client devices. Client devices 115a, 115b, and 115c may be used to access applications and/or services provided by insurance carrier web portal 125 and/or CAAS 105.

The insurance provider may provide an insurance company web portal 125 as a means for the insured user to access his insurance policy information, make insurance policy payments, obtain new insurance policies, submit claims to existing insurance policies, and/or perform other actions related to managing the insured's insurance. The insured user may have insurance policies for multiple insurers and may therefore have to access multiple insurer portals 125 to obtain information about each of their insurance policies. Thus, the insured user must learn to navigate through multiple insurance portals, which may have significantly different layouts, in order to access their policy information, submit claims, and/or check the status of claims, or perform other actions related to their policy.

The service provider portal 135 may provide a means for doctors, dentists, optometrists, and/or other medical professionals to submit claims to insurance companies on behalf of insured users. The service provider portal 135 may provide a means for the provider to check the status of claims with insurance companies. Service provider portal 135 may also allow the provider to modify and/or re-submit claims.

The CAAS105 provides a cloud-based or web-based portal for accessing services provided by the CAAS 105. The CAAS105 may be configured to provide secure and delegated access to insurance claims for the insured users. CAAS105 may implement a claim Application Programming Interface (API) infrastructure that allows insured users to access their insurance claim data and provide various services, such as claim analysis and adjudication services, guidance for optimizing prescription rights, guidance for optimizing Medical Spending Account (MSA) use, guidance for proactive rights participation, services that may assist insurers in selecting combinations of insurance products that meet insured requirements, and/or other services related to optimizing coverage of insurance and utilization of insureds. In the services provided by the CAAS105, the CAAS105 provides substantially real-time claim analysis and arbitration. The CAAS105 may analyze the claim using one or more machine learning models that are trained to guide the user in submitting the claim to the appropriate insurance company and to provide other suggestions for optimizing use of the coverage provided to the user by their insurance policy. The CAAS105 may also respond to changes in the user's demographics and may provide policy combination suggestions that meet the user's changing needs. The following example implementations provide additional details describing these and other features of the CAAS 105.

The CAAS105 may be configured to collect insurance policy and claim information for the user from the insurance carrier web portal 125 to analyze the information included in the insurance policy information to obtain coverage information. The coverage information may include the type of claim covered by each policy, the limits of coverage provided by each policy, other information that may be used to determine whether an insurer may cover a particular claim, or a combination thereof. CAAS105 may be configured to implement a secure and authenticated set of pipelines configured to allow members to link their accounts to their insurance providers to obtain planning information, claim information, or both. CAAS105 may provide a user interface that provides a list of supported insurance companies. The user may select an insurance company from a list of supported insurance companies and the user interface directs the user to establish a connection of the user account with the insurance company. The user may securely provide authentication details that allow the CAAS105 to securely access policy information and/or claim information provided through the insurance carrier portal 125. The CAAS105 may access the policy information, claim information, or both, analyze the information, and convert the information to a unified and standardized schema for the information. The standardized information may be stored by the CAAS105 to provide various services to the user, as will be discussed in more detail with respect to the example implementations of the CAAS105 shown in fig. 2 and 3.

The third party data source 130 is an additional data source that may be accessed by the CAAS105 to obtain additional information for the user. The CAAS105 may be configured to use third party data to supplement information collected from the user. The CAAS105 may be configured to collect at least some demographic information from the user by presenting a dynamically generated set of questions to the user. Questions presented to the user may be dynamically selected based at least in part on the user's response to previous questions, responses to information included in the third party data, or a combination thereof. Third party information and/or information that may be collected from the user may include, but is not limited to, medical history of the user, past insurance consumption, financial profiles of the user (liabilities, assets, liabilities), credit history, family information, psychological characteristics, interests, professions, payroll, physical activities, and other information that may be used by CAAS105 to facilitate providing insurance plan suggestions to the user. The CAAS105 may query the third party data source 130 for information and may reformat the data into a standard schema that is used by the CAAS130 to store and analyze the data. The CAAS105 may also be configured to clarify data received from third party data sources, where the data includes information associated with a plurality of people that may or may not be users. Additional details of data disambiguation are provided in the examples below.

Fig. 5A-5H illustrate examples of a process in which the CAAS105 directs a user to link the user's account with respect to an insurance company to the user's CAAS account so that the CAAS105 may obtain insurance policy and claim information associated with the user from the insurance company portal 125. Fig. 5A shows a user interface 505 for starting a setup process for presenting information about an account setup process to a user. The user may click on the "continue" button to cause the CAAS105 to proceed to the user interface 510 shown in fig. 5B. The user interface 510 provides a list of insurers to which the CAAS105 has been configured to allow a user to link the CAAS account to a user account on the insurer system. The user may select an icon associated with a particular insurance company or type the name of the insurance company in a search field. Fig. 5C and 5D illustrate that the list of insurers may dynamically narrow as the user types in the search field. Fig. 5E shows an example of a user interface 515 that may be displayed for a selected insurance company. The user may provide their authentication credentials for the insurance company portal and click to submit. The CAAS105 will attempt to access the insurance company portal 125 using the provided authentication criteria. Fig. 5F and 5G illustrate an example two-factor authentication user interface 520 that may be used to further secure access to a user account on the insurance carrier web portal 125. Once the user has passed the authentication of the insurance company portal, a user interface 525 may be displayed to confirm that the account has been linked. The CAAS105 may then access claim information, policy information, and/or other information from the insurance carrier web portal 125.

Fig. 2 is a diagram of an example implementation of the CAAS105 shown in fig. 1, illustrating additional elements of the CAAS 105. The CAAS105 shown in fig. 2 includes three layers: (1) a raw data layer 205, (2) an event-based notification layer 250, and (3) an insight layer (insight layer) 290. The raw data layer 205 may be configured to obtain user's insurance data from various data sources, convert the data into a unified and standardized schema, and store the user data for analysis by the event-based notification layer 250 and/or the insight layer 290 to provide various insurance-related services to the user. Additional details of the function of each of these layers will be described in more detail in the examples below. In some implementations, the functionality of each of these layers may be grouped together into a different number of functional layers. Furthermore, in some implementations, the functionality of each of the layers may be implemented on separate servers, and the servers may be communicatively coupled via public and/or private network connections to allow the various components of the CAAS105 to exchange and analyze data.

The raw data layer 205 may include a data lake 210, plan metadata 215, census data store 220, health Savings Account (HSA) provider API 225, insurance plan quote API 230, prescription API 235, claims and insurance policy API 240, qualification API 245, and third party data API 280. The API provides a pipeline for obtaining data that CAAS105 may use to provide various insurance-related services. User data may be protected by secure and authenticated pipelines when accessing sensitive data. The CAAS105 may direct the user to establish authentication with an external data source to allow the CAAS105 to securely access the user data.

The data lake 210 may be used to store raw user data, raw claim data, and raw policy data that have been obtained from one or more external data sources (e.g., without limitation, the insurance company web portal 125 and the third party data provider 130). As used herein, raw data refers to a raw data format in which data is obtained from an external data source. The format of the raw data may depend on the type of data and the external data source from which the data is obtained. The raw data may remain in the data lake 210 and the data lake 210 may be processed into standard patterns by one or more parsing engines of the CAAS 105. The standard schema defines a set of logical data structures that may be used by CAAS105 to store and analyze data. FIG. 3, discussed in more detail below, includes two parsing engines, namely, an insurance policy parsing engine 315 for parsing data and a claims and prescription parsing engine 320. Although the example shown in fig. 3 includes two separate parsing engines, the functionality of the parsing engines may be combined into a single parsing engine or into more than the two parsing engines shown in fig. 3. The normalized policy data may be stored in the plan metadata 215.

The policy data may include coverage information including, but not limited to, the type of claim covered by each policy, the limits of coverage provided by each policy, and other information that may be used to determine whether an insurance company may cover a particular claim for a user. Census data 220 may include demographic information collected from the user by CAAS105, information about the user obtained from third party data sources 130, information obtained from insurance carrier web portal 125, and/or other information about the user that may be used by CAAS105 to provide suggestions to the user about insurance-related issues. User-related data obtained from these various sources may be formatted into standard patterns by one or more parsing engines of CAAS105 and stored in census data 220.

The raw data layer 205 shown in FIG. 2 includes six API units configured to implement APIs to access data from various sources. Some implementations of the raw data layer 205 of the CAAS105 may include different numbers of APIs for accessing data from various data sources. The type of data source accessed and processed by the raw data layer may depend, at least in part, on the functionality provided by the insight layer 290 discussed in more detail in the examples below.

The claims and insurance policy API 240 is configured to obtain insurance policy information and/or insurance claim information from the insurance company via the insurance company portal 125. As discussed in the previous examples, CAAS105 may be configured to provide a user interface that directs users to link their accounts with CAAS105 to their accounts with their insurers. The claims and insurance policy API 240 can be configured to retrieve insurance policy information and/or claim information from each insurance company and store the raw data in the data lake 210. The policy information may be converted to standard mode by the policy resolution engine 315 and the claim information may be converted to standard mode by the claim and prescription resolution engine 320 shown in fig. 3.

The user's policy information may be kept up-to-date in substantially real-time. The claims and policy API 240 may be configured to periodically check for updates to the user's policy information. The claims and policy API 240 can also check for updates to the user's policy information in response to a request from the event-based notification layer 250 or the insight layer 290. In some implementations, the claims and policy API 240 can receive updates to claim information and/or policy information from an insurance company in response to changes or updates to the policy, or in response to submitting a claim to the insurance company for reimbursement.

The HSA provider API 225 may be configured to obtain information from one or more HSA providers. The HSA provider API 225 may obtain information associated with the HSA account of the user (e.g., without limitation, current balance, historical reimbursement information for claims reimbursed by the HSA account, and/or other information associated with the use of the HSA account). The CAAS105 may use the HSA account information to build a historical model of the number and type of claims submitted by the user for reimbursement and predict suggested future dials for the HSA based on historical usage. The CAAS105 may also consider HSA account information when analyzing the user's insurance coverage and recommending coverage that is tailored to the user's needs.

The prescription API 235 may be configured to obtain prescription price information from a drug equity manager (PBM). Information about prescriptions that a user has been prescribed can be obtained directly from the user and/or determined based on claim information obtained from the insurance provider via the claim and insurance policy API 240. The prescription price information may be used by the prescription equity guide unit 265.

The insurance plan offer API 230 may be configured to obtain offers for insurance coverage from insurance companies that may be used by the CAAS105 to create a comprehensive combination of insurance policies for a user based at least in part on the user's predicted insurance consumption. The insurance plan quote API 230 may be configured to submit quote requests to insurance companies for medical insurance, dental insurance, accident insurance, hospital reimbursement insurance, automotive insurance, and/or other types of insurance. The insurance combination planning unit 275 may use the quotation information to construct a comprehensive insurance plan for the user based on the user's needs. Insurance composition planning unit 275 may determine the needs of the user based on user data including, but not limited to, the user's medical history, past insurance consumption, the user's financial profile (liabilities, assets, liabilities), family information, psychological characteristics, interests, professions, payroll, physical activity, and/or other information that may be used to infer the needs of the user.

The qualification API 245 may be configured to verify the registration of a user with an insurance company. The API 245 may be used to determine whether a user is covered by a particular policy and whether the user is entitled to certain types of claims reimbursed by the insurer. The CAAS105 may utilize the entitlement information to determine whether a particular claim or type of claim may be covered by a particular insurer. The qualification information may be accessed in substantially real-time such that the recommendation provided by the CAAS105 is based on the current registration status of the user.

The third party data API 280 may be configured to submit a query for third party data to the third party data provider 130. Third party data sources may include, but are not limited to, medical history data, financial profile information, credit history information, marital status information, and/or family information, profession, payroll, and/or other sources of information that may be used by CAAS105 to provide various recommendations to a user. The third party data API 280 may be used by various components of the CAAS105 to query various data sources of third party data.

The event-based notification layer 250 may utilize conditional logic, machine learning models, and/or artificial intelligence systems to analyze data obtained and/or generated by the raw data layer 205. The event-based notification layer 250 may be configured to analyze data from the raw data layer 205 to support the functionality of the services provided by the insight layer 290. The event-based notification layer 250 may utilize one or more machine learning models to analyze the data maintained by the raw data layer 205. The event-based notification layer 250 can implement the elements of the claim qualification engine 325 shown in fig. 3 and 4.

The insight layer 290 can provide various services to the user based upon analysis of the data by the event-based notification layer 250. The insight layer 290 includes a claim concierge unit (claims concierge unit) 255, a payout account guide unit 260, a prescription equity guide unit 265, an active equity participation unit 270, and an insurance combination planning unit 275.

The claim concierge unit 255 may be configured to analyze the claim data and provide advice to the user to submit the claim to the insurance company. The claim concierge unit 255 may be configured to automatically analyze the claim data to identify claims that may be paid by the insurance company. The claim concierge unit 255 may also provide advice in response to a request from a user to analyze one or more pending insurance claims. Additional features of the claim concierge unit 255 are shown in the examples below.

The payout account guide unit 260 may provide guidance to the user to optimize the MSA's funding based on previous health plan consumption and to utilize the MSA funds to reimburse medical claim fees. The prescription equity guidance unit 265 may provide guidance to a user for providing prescription price guidance to the user, including providing prices for prescription medications to a pharmacy located near the user.

The active equity participation unit 270 may provide suggestions to the user to optimize the use of the equity of the user. The active equity participation unit 270 may be configured to provide meaningful and operational notifications to encourage users to participate in equities provided by the user's insurance policy. The active equity participation unit 270 may consider the personal financial condition of the user when making suggestions to the user regarding the use of the user's equity.

The insurance combination planning unit 275 may provide suggestions to the user for constructing insurance combinations that take into account the demographics of the user, the risk aversion of the user, and the needs of the user.

FIG. 3 is a diagram illustrating an example implementation of the claim qualification engine 325 that may be implemented by the CAAS 105. The implementation shown in FIG. 3 may be configured to map a user's insurance claim to a user's policy. The CAAS105 can utilize one or more machine learning models trained to analyze insurance claims to guide users in submitting claims to appropriate insurance companies.

The policy information 305 may include a plurality of policies (e.g., without limitation, medical policies, dental policies, accident policies, disability policies, critical illness policies, automobile policies, and/or other types of policies). The policy information 305 may be obtained through the claims and policy API 240 of the raw data layer 205 shown in FIG. 2. An electronic copy of the policy may be obtained from the insurers in a portable file format (PDF) or another electronic format supported by each insurer. Insurance companies may support different electronic file formats and the layout of policy information provided by each insurance company may be different. The policy information obtained from the insurance company may be stored in the data lake 210 of the raw data layer 205. The policy resolution engine 315 may be configured to analyze raw policy data obtained from an insurance company and convert the policy information into a standard schema. The normalized information may be stored in the plan metadata 215. The plan metadata may include coverage information, policy restrictions, deductible information, and/or other information that may be used by the CAAS105 to determine whether a particular insurance company may make reimbursements to policy holders for one or more claims of a particular type.

The policy resolution engine 315 may be configured to map policy coverage information extracted from a policy to standardized coverage information using fuzzy matching techniques. Insurance companies may use slightly different languages to describe the coverage provided. The policy resolution engine 315 may be configured to map policy coverage information with a standardized set of policy coverage descriptions maintained by the CAAS 105. The standardized insurance coverage description may include a description of the type of coverage that may be provided by the insurance company. The policy resolution engine 315 may be configured to perform probabilistic data matching of coverage information provided in the policy with the standardized coverage description. The policy resolution engine 315 may be configured to select the normalized description associated with the highest probability of matching the policy coverage description. The matched normalized description may be stored in the plan metadata 215 along with the policy information and may be used by the claim qualification engine 325 to determine whether the user has a policy that may cover the claim.

Mapping policy coverage information to standard descriptions may provide significant technical benefits by improving predictions provided by a machine learning model used by the claim qualification engine 325. The machine learning model can be trained using training data that includes the same standard insurance coverage descriptions that will be used by the claim qualification engine 325 to determine whether a particular claim is likely to be covered by the user's insurance policy. Thus, the machine learning model may be presented with insurance policy coverage data for analysis that utilizes descriptions consistent with the coverage descriptions included in the training data for training the model.

The claim and prescription information 310 can include substantially real-time information from medical claim feeds and prescription feeds. The medical claim information indicates insurance claims that users have submitted or have submitted on their behalf for reimbursement. The prescription information represents a prescription that has been issued to the user and submitted to the insurance company for reimbursement. Claim and/or prescription information may be obtained through the claim and insurance policy API 240 shown in fig. 2 and the data stored in the data lake 210. Claims and prescription information obtained from each of the insurers may be in different electronic formats and/or layouts. The claims and prescription information can be processed by the claims and analysis engine 320 to convert the claims and prescription information into standard patterns utilized by the CAAS 105. Claims and prescription information in the standardized schema may be stored with the plan metadata 215.

The claim and prescription resolution engine 320 can be configured to map the claim and prescription information 310 to a standardized claim and prescription description using fuzzy matching techniques before the claim qualification engine 325 analyzes the claim and prescription information. The medical provider may use inconsistent languages to describe the procedures performed. One medical provider may describe the same process in a slightly different way than another provider. Such inconsistencies in the descriptions of the processes performed may determine whether a particular policy covers a particular claim or prescription. The standardized set of claim and prescription descriptions may provide a consistent set of descriptions associated with the claim and prescription. The claim and prescription resolution engine 320 can be configured to perform probabilistic data matching of the claim and prescription information 310 with the normalized claim and prescription descriptions. The claims and prescription resolution engine 320 can be configured to select a normalized description that is associated with the highest probability of matching a description of the claim and/or procedure performed in the prescription and/or other information included on behalf of the user submitted to the insurance company.

The normalized description that matches the claim may be stored with the claim information in the planning metadata 215 associated with the claim. The claim qualification engine 325 can also use the normalized description to determine whether the user has an insurance policy that may cover the claim. Mapping claims and prescription information to standard descriptions provides the technical benefit of improving the predictions provided by the machine learning model used by the claims qualification engine 325. The machine learning model can be trained using training data that includes the same standard claims and/or prescription descriptions that will be used by the claim qualification engine 325 to determine whether a particular claim or prescription is likely to be covered by the user's policy. Thus, claim and prescription descriptions are presented to the machine learning model for analysis with descriptions consistent with the claim and prescription descriptions included in the training data used to train the model.

If the probability that the normalized description matches a particular claim is less than a predetermined threshold, the claim and prescription resolution engine 320 can flag the claim for additional processing. The user may be prompted to provide additional information that may be used to help clarify the claim and/or to request that a different description of the claim be provided. Normalizing the description of the claim may increase the likelihood that the claim qualification engine 325 can find a matching policy that can cover the claim.

The normalized policy cover information and the normalized claim and prescription information may be provided to the claim qualification engine 325 for analysis. The claim engine can be configured to track multiple insurance claims over a period of time and make predictions of the claims as to specific events and group the claims accordingly. The claim qualification engine 325 can use one or more machine learning models that are trained to group insurance claims by event type. For example, the machine learning model may be configured to group insurance claims by event type, such as, but not limited to, car accidents, sports injuries, disease related events, or the machine learning model may be trained to identify other types of events that may be related to one or more claims of a particular type. One or more machine learning models can generate predictions regarding a group of insurance claims associated with a particular type of event. The claim qualification engine 325 can be configured to analyze a group of insurance claims using one or more machine learning models configured to generate predictions of whether a particular insurance company for which a user has an insurance policy is likely to cover a particular claim or group of claims.

One or more machine learning models can associate confidence levels with predictions of whether a particular insurer can cover a claim or group of claims, and the claim qualification engine 325 can perform different actions in response to the confidence levels associated with the predictions. In response to the claim engine 325 having a low confidence in the prediction, the claim engine may provide an indication that no recommendation was made to the member in operation 340. In response to the claim engine 325 having a medium confidence level, the claim engine 325 may be configured to present the dynamically generated question to the user in operation 335. The response to the dynamically generated questions may be used to clarify whether a particular insurer may cover a particular claim or group of claims and/or to clarify the distinction between insurers to determine whether an insurer is more likely to cover a claim or group of claims. In response to the claim engine 325 having a high confidence level, the claim engine 325 may be configured to direct the user to submit the claim or group of claims to an insurer predicted to cover the claim in operation 330. The low, medium, and high confidence levels may be determined by determining whether the confidence level is associated with a prediction having a particular confidence level range. These ranges can be configured by an administrator of the system to configure how the claims engine 325 handles predictions made by one or more machine learning models to predict whether a particular insurance company can cover a claim or collection of claims.

FIG. 4 is a diagram illustrating an example implementation of the claim qualification engine 325. The claim qualification engine 325 can include a submission recommendation unit 405, a claim grouping machine learning model 410, an coverage prediction model 415, a disambiguation unit (disambiguation unit) 425, a claim submission assistance unit 420, and a model update unit 430. The claim qualification engine 325 can analyze the insurance claims and policy information and present recommendations to the user, recommending the particular insurance company to which the claims can be submitted. Recommendations may be generated as needed in response to requests from users, in response to the CAAS105 detecting that a new claim has been submitted for users, in response to receiving notification that one or more claims have been denied by an insurer, and/or in response to other events that may trigger the CAAS105 to analyze pending claims for users. For example, the CAAS105 may receive an interpretation of Equity (EOB) from an insurer indicating that the insurer is not covering one or more claims and/or is not covering one or more claims entirely. Claims that have been denied by an insurance company may be denied for a variety of reasons, including, but not limited to, the user not being entitled to coverage by the claim specified by his insurance policy, the user having reached the policy limit for such claims, or other reasons. The claim may be paid only in part by the insurer due to coverage restrictions, insurance co-payment, or other reasons. The CAAS105 can identify another insurance company that can pay the claim and direct the user to submit the claim to the other insurance company.

The submission recommendation unit may be configured to obtain claim and policy information 440 to analyze to predict insurance companies that may cover the claim. The claims and policy information 440 includes standardized policy coverage information output by the policy resolution engine 315. Claim and policy information 440 can also include claim and prescription information in standard patterns output by the claim and resolution engine 320.

The submission recommendation unit 405 may first analyze the claims and/or prescription information to group the claims into groups of claims predicted to be associated with a particular type of event. Claims associated with various types of events may be identified, such as, but not limited to, car accidents, sports injuries, disease-related events, or other types of events that may typically be associated with certain types of claim sets. The submission recommendation unit 405 may be configured to provide claim information to the claim grouping model 410 to obtain predictions about logical groupings of claims. The claim grouping model 410 can be one or more machine learning models that have been trained to identify patterns in insurance claims and group the insurance claims according to these events. Insurance claims associated with a particular event may be submitted together or may be submitted over a period of time. In examples illustrating this concept, a user experiencing a sports-related injury may submit a claim for emergency services, prescriptions, physical treatments, and/or other treatments or services related to the injury. Claims may be submitted for emergency services provided when injury occurs, while other claims may be submitted for physical therapy and/or other therapies following initial therapy by the emergency services.

The claim grouping model 410 can be trained to identify patterns in insurance claims associated with such injuries over time, and to group the claims as related to athletic injuries. In another example, a user experiencing an automobile accident may have claims related to emergency services and hospitalization and claims for damage to their automobile. These examples illustrate several possible patterns in claims that a model may identify, but without limiting the model to only identify these particular patterns.

The claim grouping model 410 can be initially trained using training data that has been manually labeled to associate certain types of claims with certain types of events. The training data may also represent patterns in insurance claims. Training of the claim grouping model 410 can be further refined by providing feedback regarding predictions generated by the claim grouping model 410. In some implementations, the claim qualification engine 325 can include more than one claim grouping model 410, and predictions from one of the models having the highest confidence rating associated with the predictions.

The submission recommendation unit 405 may be configured to provide the coverage prediction model 415 with an indication of the claim packet predictions from the claim packet information and the event types predicted by the claim packet model 410, as well as the policy information. The coverage prediction model 415 may be trained to analyze the set of claims and the policy information to provide predictions as to which insurers may cover the claims. The coverage prediction model 415 may be initially trained using manually-labeled training data that associates certain types of claims with certain insurance policy specifications. The coverage prediction model 415 can identify insurance policies that are likely to cover a claim or group of claims based on the event types predicted by the claim grouping model 410. One or more insurance policies of a particular type may cover certain types of events. For example, medical claims directed to injuries related to a car crash may be covered by a car insurance policy and/or a medical insurance policy. Other types of events may be associated with other types of claims that may be covered by other types of insurance policies. The coverage prediction model 415 may be configured to identify types of insurance policies that are likely to cover claims associated with the identified event, identify those types of insurance policies in the policy information, and determine whether the identified insurance policies are likely to cover claims by comparing the policy specifications to the claim information. Training of the overlay prediction model 415 may also be further refined by providing feedback regarding predictions generated by the model. The coverage prediction model 415 may be trained to take into account the coverage limits and how much of the claim limits the user has used when making the recommendation. If policy limits with the first insurer's policy have been reached, the coverage prediction model 415 may provide predictions that the first insurer may not cover the claim or that the second insurer (if available) may cover the claim based on the policy held by the insured.

The coverage prediction model 415 can provide coverage predictions for a group of claims that include a confidence score that represents the confidence of the model in the predictions. The submit recommendation unit 405 may be configured to perform various actions in response to the confidence score. As discussed with respect to FIG. 2, predictions may be assigned high, medium, or low confidence scores by the claim qualification engine 325. The commit recommendation unit 405 may be configured to assign a confidence level to the prediction provided by the overlay prediction model 415 by comparing the confidence level to a set of thresholds including a first threshold and a second threshold. The first threshold is higher than the second threshold. A confidence score above the first threshold indicates a high confidence level for the prediction. Confidence scores below the first threshold but above the second threshold indicate a predicted mid-set confidence level. Confidence scores below the second threshold indicate a low confidence level for the prediction.

For predictions with low confidence levels, the commit recommendation unit 405 may discard the prediction. The submit recommendation unit 405 may also notify the user that the CAAS105 cannot identify an insurance policy associated with the user that will cover the claim or group of claims. The submission recommendation unit 405 may include recommendations for modifying the claim and re-submitting the claim to the user such that the claim may be covered by an insurance company associated with at least one of the user's insurance policies. The submission recommendation unit 405 may also include information regarding why the claim or group of claims is unlikely to be covered by one of the insurance policies associated with the user. For example, the submission recommendation unit 405 may indicate that the user may have reached their policy restrictions regarding the type of claim or claims being submitted. The submission recommendation unit 405 may include other types of information for claims that may have been rejected for other reasons.

For predictions with a medium confidence level, the submission recommendation unit 405 may attempt to obtain additional information that may help make it clear whether an insurer may cover a particular claim or group of claims and/or make it clear to which insurers to submit the claim. The disambiguation unit 425 may provide a user interface that may be displayed to a user for presenting a set of dynamic questions that attempt to collect additional information from the user that may be used by the recommendation unit 405 to make clear whether a particular insurance company may cover a claim or claim set or to make clear an insurance company that may cover a claim or claim set. Dynamic problems can be used to further clarify aspects of claims that may be obscured when interpreted by a model.

The disambiguation unit 425 may identify additional data that may be helpful in determining whether a particular insurer will cover a particular claim. For example, a user may have a supplemental accident policy that covers medical costs associated with certain types of accidental injuries. The submit recommendation unit 405 may override the confidence level in the predictive assignment of the claim of the user with the unexpected policy. In an attempt to make a more explicit prediction of whether the incident policy may cover a claim of the user, the disambiguation unit 425 may be configured to request additional details related to the claim, which may indicate whether the incident policy may cover the claim.

In one example, the disambiguation unit 425 can present questions to the user to determine whether the claim is associated with an intent injury, the type of incident that occurred, and/or information related to the person that determines whether the claim is for coverage by the policy. The disambiguation unit 425 may update the claim information with additional information obtained from the user, and the claim may be re-submitted to the overlay prediction model 415 to obtain a new prediction. The process of obtaining additional information and re-submitting the claim to the overlay prediction model 415 may be an iterative process. These steps may be repeated until predictions are obtained with a confidence level high enough to make an assertion as to whether the claim is likely to be covered by the insurer. Examples of such dynamic issues are used to make it clear whether an insurer can pay a particular claim, as shown in fig. 6A-6F, discussed in detail below.

In another example, the disambiguation unit 425 may query the user for questions that may help clarify the distinction between more than one insurer. The coverage prediction model 415 may predict with moderate certainty that both the first insurer and the second insurer may potentially cover a particular claim. The first insurance company may be an automobile insurance provider that provides insurance policies including hospitality coverage related to automobile accidents. The second insurance company may be a medical insurance provider whose insurance policy covers hospitalization for certain diseases. The disambiguation unit 415 may obtain additional information about one or more claims from the user and re-submit the claims to the overlay prediction model 415 to obtain new predictions. For example, the disambiguation unit 425 may present questions to the user regarding whether the claim is associated with an automobile accident, whether the claim is for the user or for other people, and/or other information that may assist the disambiguation unit 425 in making a determination as to whether the automobile policy or the medical policy may cover the claim. This process may be repeated until the disambiguation unit 425 can obtain a prediction that one of the insurers is likely to cover the claim or that no insurer is likely to cover the claim.

For claims with high confidence levels, the submission recommendation unit 405 may present a claim submission recommendation to the user via the claim submission assistance unit 420. The claim submission aid 420 may present a summary of the claim to be submitted, an indication of the payer to whom the claim is to be submitted, information indicating how much the insurer can pay, and an indication for submitting the claim when the claim submission aid 420 may not be able to submit the claim electronically. The claim submission aid 420 may aid the user in filling in claim forms and/or pre-filling in claim forms that are required to submit claims that may not be submitted electronically. The user may print the claim form and submit a physical copy of the claim form to his insurance company for processing.

The model update unit 430 can be configured to provide feedback to the claim grouping model 410 and the coverage prediction model 415 to improve training of the model. The model update unit 430 may receive feedback directly from the user and/or from the claim submission assistance unit 420. Feedback from the user may be obtained from the claim submission aid 420 in response to the claim grouping information presented by the claim submission aid 420 and the insurer information to which the claim submission aid 420 recommends submitting a claim for reimbursement. The user may indicate that the predictions for the claim groupings are incorrect. The user interface can provide the user with a means for providing an indication of the type of event with which the claim should be associated. The claim submission aid 420 can also receive responses from the insurer that one or more claims submitted to the insurer have been denied. The claim submission aid 420 may obtain an EOB or other indication that one or more claims have been denied by the insurer. The model update unit 430 may be configured to identify the reason why the claim has been rejected. The model update unit 430 may update the coverage prediction model in response to the claim being denied to further fine tune the performance of the coverage prediction model 415.

Fig. 6A-6F are diagrams illustrating an example user interface of CAAS 105. The user interfaces shown in fig. 6A-6F may be rendered by a browser application or native application installed on a client device (e.g., client devices 115a-115c shown in fig. 1). CAAS105 may be configured to provide content that may be rendered by a web browser installed on a client device. The CAAS105 may also be configured to provide content to a local application installed on a client device configured to render content received from the CAAS105 to allow a user to interact with the content, as well as to receive requests for data and/or to perform various operations on data maintained by the CAAS 105.

Fig. 6A is a diagram of a claims summary user interface 605. The claim overview user interface 605 may be implemented by the claim concierge unit 255 of the insight layer 290 of the CAAS 105. The claim overview user interface 605 includes a notification pane 625, a claim details pane 630, and a claim analysis pane 635. An example implementation of the claims summary interface shown in fig. 6A illustrates one possible implementation of such an interface. Other implementations may present additional information to the user instead of or in addition to the information provided in this example.

The claim details pane 630 provides details of the claim that was recently submitted to one or more insurers on behalf of the insured. The claim details can indicate the person covered (e.g., family member of the insured user), the particular service performed, what service was performed, co-payment information, insurer information for the insurer to whom the claim was made, and/or other information related to the insurer's insurance policy claim. Claim information may be obtained from the planning metadata 215, the data lake 210, and/or another persistent data storage area of the original data layer 205 of the CAAS 105. The claim details pane 630 can be configured to enable a user to obtain additional information for a claim by clicking on a link or other user interface component that can be clicked on or otherwise activated by the user.

Claim analysis pane 635 can present information reporting various aspects of the user's insurance plan usage. The analysis may include information regarding various policy types, co-payment, and other self-payment fees for the user, and/or other information related to the user's use of their policy. The claim analysis pane 635 can be configured to enable a user to obtain additional information about various elements of the analysis data by clicking on a link or other user interface component that can be clicked on or otherwise activated by the user.

The notification pane 625 may be used to present informational messages to the user regarding their account information, insurance policy information, claim information, or a combination thereof. The notification pane 625 may also include links, buttons, or other elements for activating functions associated with content presented in the notification pane 625. In the implementation shown in fig. 6A, the notification pane 625 shows a message indicating that the user may be able to submit a claim to her insurer.

Fig. 6B illustrates a user interface 610 that may be displayed in response to a user clicking or otherwise activating a link, button, or other element for activating a function associated with content presented in the notification pane 625. The user interface 610 shows details of claims that the CAAS105 has identified as potentially covered by the user's policy. The CAAS105 may be configured to automatically analyze unpaid claims and/or claims that the user has not been fully reimbursed to determine whether any insurance policies of the user may cover those claims. In other implementations, the user may select a claim that the user wishes the CAAS105 to analyze and present a suggestion for submitting the claim to the insurer. The user may click a "start" button to indicate to the CAAS105 that the user wishes to be guided in submitting the claim.

FIG. 6C shows a user interface 615 that provides details of a claim. The user may view information about the providers that provided the services associated with the claims, the dates of these services, the fees the insurer has paid, co-paid information paid by the user, and/or other information. In the example shown in fig. 6C, the user's medical insurance covers a large portion of the claim fees, but the user is still required to pay a portion of the fees. In other implementations, the claim may have been denied and the insurer may not pay any fees. In other implementations, the claim may not have been submitted to the insurance company. The user may click the "back" button to return to the user interface 610 or the "next" button to advance to the user interface 620 shown in fig. 6D.

The example user interface 620 shown in fig. 6D-6F presents a series of questions to the user to gather additional information from the user that can be used to make clear whether a particular insurance company can pay a particular claim or make clear the distinction between two insurance companies. User interface 620 may present a question to a user and be configured to receive user input responsive to the question. Questions may be presented by the disambiguation unit 425 and the collected information may be used to update claim information maintained by the CAAS 105. The submission recommendation unit 405 of the claim qualification engine 325 can process the claim to obtain a prediction of whether one of the user's insurance policies is likely to cover the claim. If the claim qualification engine 325 predicts that the claim can be covered by an insurance policy, the user interface 620 can guide the user through the step of submitting the claim to the insurance company.

FIG. 7 is a flow chart of an example process 700 for insurance claim analysis and arbitration. The process 700 may be implemented by the CAAS105 discussed in the previous example.

Process 700 may include an operation 705 of obtaining electronic copies of a plurality of insurance policies associated with an insured user. As discussed in the previous examples, the raw data layer 205 of CAAS105 may obtain an electronic copy of the insurance provider document from the insurance company via the insurance company portal 125. The raw policy data may be stored in a data lake 210 of the raw data layer. The raw policy data may be received in a Portable Document Format (PDF), a text file, a scanned image of a policy document, or other electronic format.

Process 700 may include an operation 710 of analyzing the electronic copies of the plurality of policies to generate policy coverage information for each of the policies. The policy resolution engine 315 may be configured to analyze the electronic copies of the plurality of policies and extract policy coverage information from the electronic copies of the policies. If the electronic copy is not in a text-based format, the policy resolution engine 315 may be configured to perform optical character recognition on the electronic copy of the policy. The policy resolution engine 315 may also be configured to parse electronic copies of documents to extract text specifications for policies and reformat the policies into standard patterns for use by the CAAS 105. Different insurance companies may have different formats for their insurance policies and the policy resolution engine 315 may map data from these formats to the standard patterns used by the CAAS 105. Normalizing the policy data to such a normalized pattern may facilitate training of a machine learning model for analyzing the policy data, as the model need not identify many possible ways in which an insurance company may organize the policy data in the policy. As discussed in the previous examples, the policy resolution engine 315 may also be configured to normalize the policy overlay information included in the policy in addition to the format of the policy overlay information. The policy resolution engine 315 may be configured to use fuzzy matching to match the normalized description of the policy coverage specification with the coverage information contained in the policy. The insurance company may not use a different language to describe the same type of coverage provided by the policy specifications. By normalizing the description of the policy specifications, the machine learning model used by the CAAS105 may be more likely to correctly predict whether a particular policy may cover a particular insurance claim.

The process 700 can include an operation 715 of obtaining electronic copies of a plurality of insurance claims associated with an insured user. The raw data layer 205 of the CAAS105 may obtain electronic insurance claim information from the insurance company via the claim and policy API 240. Claim data may be obtained from the insurance company in substantially real-time via the insurance company portal 125. The claim data may include information related to processes performed for the insured party and/or prescription information for the insured party. Claim information and prescription information may be submitted to the insurance company via a service provider portal 135, which service provider portal 135 may provide a means for doctors, dentists, optometrists, and/or other medical professionals to submit claims to the insurance company on behalf of the insured user. Claims may be submitted on behalf of an insured user and/or other parties covered by an insurance policy.

The process 700 can include an operation 720 of analyzing the electronic copies of the plurality of insurance claims to generate insurance claim information. The policy resolution engine 315 of the CAAS105 may be configured to use fuzzy matching to match the normalized descriptions of the performed processes and/or other information included in the claims. The same process may be described in an inconsistent manner by the medical provider providing the service, which may make it more difficult to determine whether the insured user has an insurance policy covering the claim. By normalizing the description of the claim, the machine learning model used by the CAAS105 may be more likely to correctly predict whether a particular policy may cover the claim.

The process 700 can include an operation 725 of providing the generated insurance claim information as input to the first machine learning model; and an operation 730 of analyzing the insurance claim information using a first machine learning model to identify occurrences of the first type of event and a first set of insurance claims associated with the first type of event, wherein the first machine learning model is trained to predict and output occurrences of events of the type requiring medical treatment based on the set of insurance claims associated with the insured user; and an operation 735 of providing, as input to the second machine learning model, an indication of occurrence of the first set of insurance claims and the first type of events output from the first machine learning model, the policy information, and the first indication. The claim engine 325 can be configured to analyze the insurance claim information using one or more machine learning models. As shown in fig. 4, the claim qualification engine 325 can submit a plurality of claims to the claim grouping model 410 to obtain predictions, wherein the group of claims can be analyzed to determine whether the claim indicates a particular event, such as, but not limited to, a sports injury or an automobile accident that may result in a medical claim for the insured user. The output of the claim grouping model 410 can be provided as an input to the coverage prediction model 415.

Process 700 may include operation 740: the first set of insurance claims, the policy information, and the indications of the first type of events are analyzed using a second machine learning model to obtain predictions of whether respective ones of the plurality of policies will cover the first set of insurance claims by identifying one or more types of policies in the policy information that may cover the first set of insurance claims, and predicting that the respective ones of the plurality of policies may cover the first set of insurance claims by comparing the first set of insurance claims to policy specifications for the respective policies. As shown in FIG. 4, the claim qualification engine 325 can use the coverage prediction model 415 to analyze the insurance claim information to obtain predictions of whether a particular insurance company is likely to cover a set of insurance claims. The model can analyze insurance policies associated with the plurality of insurance companies and provide predictions of the most likely insurance companies of the plurality of insurance companies to cover the set of claims.

The process 700 may include an operation 745 of providing a corresponding policy of the policies output by the second machine learning model that will cover the first set of insurance claims to the user interface module; and an operation 750 of causing the user interface to be presented on a display of a computing device associated with the insured user to direct the insured user to submit the first set of insurance claims to an insurance provider associated with the corresponding insurance policy. The CAAS105 may implement a user interface module that may be configured to present a user interface for providing suggestions for submitting claims to a particular insurance company based on predictions of the coverage prediction model 415. The CAAS105 may present a user interface that directs a user to enter information for a claim and submit the claim to the insurance company online via the insurance carrier portal 125. In other instances, CAAS105 may direct the insured user to fill out forms that may be submitted to the insurer by the insured user. CAAS105 may assist the user by pre-filling in at least a portion of the information included on the form and the insured user may print a copy of the form to provide to the insurer. The CAAS105 may store information in the raw data layer 205 that indicates the data format required to submit data to each of the insurers, and may include one or more formatting engines (not shown) configured to format the data stored in a standard mode into the data format desired by the insurer to whom claims are being submitted.

Detailed examples of the systems, devices, and techniques described in connection with fig. 1-7 are presented herein to illustrate the present disclosure and its benefits. Such use examples should not be construed as limiting the logical process embodiments of the present disclosure, nor should variations in the user interface methods according to those described herein be considered to be outside the scope of the present disclosure. It should be understood that reference to a display or presentation item (e.g., without limitation, presenting an image on a display device, presenting audio and/or vibrating a device via one or more speakers) includes issuing instructions, commands and/or signals that cause or reasonably expect to cause the device or system to display or present the item. In some embodiments, the various features described in fig. 1-7 are implemented in respective modules, which may also be referred to and/or comprise logic, components, units, and/or mechanisms. The modules may constitute software modules (e.g., code embodied on a machine-readable medium) or hardware modules.

In some examples, the hardware modules may be implemented mechanically, electronically, or any suitable combination thereof. For example, a hardware module may include dedicated circuitry or logic configured to perform certain operations. For example, the hardware modules may include special purpose processors (e.g., field Programmable Gate Arrays (FPGAs) or Application Specific Integrated Circuits (ASICs)). A hardware module may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations, and may include portions of machine-readable medium data and/or instructions for such configuration. For example, a hardware module may include software contained within a programmable processor configured to execute a set of software instructions. It will be appreciated that decisions to implement the hardware modules mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost, time, support, and engineering considerations.

Thus, the phrase "hardware module" should be understood to include tangible entities capable of performing certain operations, and may be configured or arranged in some physical manner, i.e., physically constructed, permanently configured (e.g., hardwired), and/or temporarily configured (e.g., programmed) as entities that operate in some manner or perform certain operations described herein. As used herein, "hardware-implemented module" refers to a hardware module. Considering an example in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one time. For example, where the hardware modules include programmable processors configured by software to become special purpose processors, the programmable processors may be configured at different times as respectively different special purpose processors (e.g., including different hardware modules). The software may configure one or more processors accordingly, e.g., to constitute a particular hardware module at one time and to constitute a different hardware module at a different time. A hardware module implemented using one or more processors may be referred to as "processor-implemented" or "computer-implemented".

A hardware module may provide information to and receive information from other hardware modules. Thus, the described hardware modules may be considered to be communicatively coupled. In the case where there are multiple hardware modules at the same time, communication may be achieved by signal transmission (e.g., through appropriate circuitry and buses) between two or more of the hardware modules. In embodiments in which multiple hardware modules are configured or instantiated at different times, communication between such hardware modules may be implemented, for example, through storage and retrieval of information in memory devices accessible to the multiple hardware modules. For example, one hardware module may perform operations and store output in a memory device, and then another hardware module may access the memory device to retrieve and process the stored output.

In some examples, at least some of the operations of the method may be performed by one or more processors or processor-implemented modules. In addition, one or more processors may also be operative to support performance of related operations in a "cloud computing" environment or as "software as a service" (SaaS). For example, at least some of the operations may be performed by and/or among multiple computers (as examples of machines including processors), which may be accessed via a network (e.g., the internet) and/or via one or more software interfaces (e.g., application Program Interfaces (APIs)). The performance of some of the operations may be distributed among processors, residing not only within a single machine, but also across several machines. The processor or processor-implemented module may be in a single geographic location (e.g., within a home or office environment, or in a server farm), or may be distributed across multiple geographic locations.

Fig. 8 is a block diagram 800 illustrating an example software architecture 802, portions of which may be used in conjunction with the various hardware architectures described herein, which may implement any of the features described above. FIG. 8 is a non-limiting example of a software architecture, and it will be appreciated that many other architectures can be implemented to facilitate the functionality described herein. The software architecture 802 may execute on hardware, such as the machine 900 of fig. 9, the machine 900 including a processor 910, memory 930, and input/output (I/O) components 950, among others. A representative hardware layer 804 is shown that can represent, for example, the machine 900 of fig. 9. The representative hardware layer 804 includes a processing unit 806 and associated executable instructions 808. Executable instructions 808 represent executable instructions of software architecture 802, including implementations of the methods, modules, etc. described herein. The hardware layer 804 also includes a memory/storage device 810 that also includes executable instructions 808 and accompanying data. The hardware layer 804 may also include other hardware modules 812. The instructions 808 maintained by the processing unit 806 may be part of the instructions 808 maintained by the memory/storage 810.

The example software architecture 802 may be conceptualized as layers, each providing various functions. For example, the software architecture 802 may include layers and components, such as an Operating System (OS) 814, libraries 816, frameworks 818, applications 820, and a presentation layer 844. Operationally, the application 820 and/or other components within the layers may call API calls 824 to other layers and receive corresponding results 826. The layers shown are representative in nature and other software architectures may include additional or different layers. For example, some mobile or dedicated operating systems may not provide framework/middleware 818.

OS 814 may manage hardware resources and provide common services. For example, OS 814 may include kernel 828, services 830, and drivers 832. The kernel 828 may serve as an abstraction layer between the hardware layer 804 and other software layers. For example, the kernel 828 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and the like. The service 830 may provide other common services for other software layers. The driver 832 may be responsible for controlling the underlying hardware layer 804 or interfacing with the underlying hardware layer 804. For example, depending on the hardware and/or software configuration, drivers 832 may include a display driver, a camera driver, a memory/storage device driver, a peripheral device driver (e.g., via a Universal Serial Bus (USB)), a network and/or wireless communication driver, an audio driver, and so forth.

Library 816 may provide a common infrastructure that may be used by applications 820 and/or other components and/or layers. Rather than interacting directly with OS 814, library 816 typically provides functionality that is used by other software modules to perform tasks. Library 816 may include a system library 834 (e.g., a C-standard library) that may provide functions such as memory allocation, string manipulation, file manipulation, and the like. In addition, libraries 816 may include API libraries 836, such as media libraries (e.g., to support presentation and manipulation of image, sound, and/or video data formats), graphics libraries (e.g., openGL libraries for rendering 2D and 3D graphics on a display), database libraries (e.g., SQLite or other relational database functions), and web libraries (e.g., webKit, which may provide web browsing functionality). The library 816 may also include a variety of other libraries 838 to provide many functions for the applications 820 and other software modules.

Framework 818 (sometimes referred to as middleware) provides a higher level common infrastructure that can be used by applications 820 and/or other software modules. For example, the framework 818 can provide various Graphical User Interface (GUI) functions, advanced resource management, or advanced location services. Framework 818 can provide a wide variety of other APIs for applications 820 and/or other software modules.

The applications 820 include built-in applications 840 and/or third party applications 842. Examples of built-in applications 840 may include, but are not limited to, a contact application, a browser application, a location application, a media application, a messaging application, and/or a gaming application. Third party applications 842 may include any application developed by an entity other than the vendor of a particular platform. The application 820 may create a user interface to interact with a user using functionality available via the OS 814, library 816, framework 818, and presentation layer 844.

Some software architectures use virtual machines, as illustrated by virtual machine 848. Virtual machine 848 provides an execution environment in which applications/modules may execute as if they were executing on a hardware machine (e.g., machine 900 of fig. 9). Virtual machine 848 may be hosted by a host OS (e.g., OS 814) or hypervisor, and may have a virtual machine monitor 846, which virtual machine monitor 846 manages the operation of virtual machine 848 and interoperation with a host operating system. Software architecture that may differ from software architecture 802 external to the virtual machine executes within virtual machine 848 (e.g., OS 850, library 852, framework 854, applications 856, and/or presentation layer 858).

Fig. 9 is a block diagram illustrating components of an example machine 900, the example machine 900 configured to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any of the features described herein. The example machine 900 is in the form of a computer system in which instructions 916 (e.g., in the form of software components) for causing the machine 900 to perform any one of the features described herein may be executed. Accordingly, the instructions 916 may be used to implement the modules or components described herein. The instructions 916 cause the un-programmed and/or un-configured machine 900 to operate as a specific machine configured to perform the described features. The machine 900 may be configured to operate as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine 900 may operate in the capacity of a server machine or a client machine in server-client network environment, or as a node in a peer-to-peer or distributed network environment. The machine 900 may be embodied as, for example, a server computer, a client computer, a Personal Computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a gaming and/or entertainment system, a smart phone, a mobile device, a wearable device (e.g., a smartwatch), and an internet of things (IoT) device. Furthermore, while only a single machine 900 is illustrated, the term "machine" includes a series of machines that individually or jointly execute the instructions 916.

Machine 900 may include a processor 910, a memory 930, and an I/O component 950, which may be communicatively coupled via, for example, bus 902. Bus 902 may include a plurality of buses coupling the various elements of machine 900 via various bus techniques and protocols. In an example, the processor 910 (including, for example, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an ASIC, or suitable combination thereof) may include one or more processors 912 a-912 n, which may execute instructions 916 and process data. In some examples, one or more processors 910 may execute instructions provided or identified by one or more other processors 910. The term "processor" includes multi-core processors, which include cores that can execute instructions simultaneously. Although fig. 9 shows multiple processors, machine 900 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors each with a single core, multiple processors each with multiple cores, or any combination thereof. In some examples, machine 900 may include multiple processors distributed among multiple machines.

Memory/storage 930 may include a main memory 932, a static memory 934, or other memory and storage unit 936, both of which processor 910 may access, for example, via bus 902. The storage unit 936 and the memories 932, 934 store instructions 916 embodying any one or more of the functions described herein. Memory/storage 930 may also store temporary, intermediate, and/or long-term data for processor 910. The instructions 916 may also reside, completely or partially, within the memories 932, 934, within the storage unit 936, within at least one of the processors 910 (e.g., within a command buffer or cache), within a memory of at least one of the I/O components 950, or any suitable combination thereof, during execution thereof. Accordingly, memory 932, 934, storage 936, memory in processor 910, and memory in I/O component 950 are examples of machine-readable media.

As used herein, a "machine-readable medium" refers to a device capable of temporarily or permanently storing instructions and data that cause the machine 900 to operate in a particular manner, and may include, but is not limited to, random Access Memory (RAM), read Only Memory (ROM), buffer memory, flash memory, optical storage media, magnetic storage media and devices, cache memory, network-accessible or cloud storage, other types of storage, and/or any suitable combination thereof. The term "machine-readable medium" applies to a single medium or a combination of multiple media for storing instructions (e.g., instructions 916) for execution by the machine 900 such that the instructions, when executed by the one or more processors 910 of the machine 900, cause the machine 900 to perform one or more of the features described herein. Thus, a "machine-readable medium" may refer to a single storage device, as well as a "cloud-based" storage system or storage network that includes multiple storage apparatuses or devices. The term "machine-readable medium" does not include signals themselves.

The I/O component 950 can include a wide variety of hardware components adapted to receive input, provide output, generate output, send information, exchange information, capture measurements, and the like. The particular I/O components 950 included in a particular machine will depend on the type and/or function of the machine. For example, a mobile device such as a mobile phone may include a touch input device, while a headless server or IoT device may not include such a touch input device. The particular example of an I/O component shown in FIG. 9 is in no way limiting, and other types of components may be included in machine 900. The grouping of I/O components 950 is merely to simplify the discussion and the grouping is in no way limiting. In various examples, the I/O components 950 can include user output components 952 and user input components 954. The user output component 952 may include, for example, a display component (e.g., a Liquid Crystal Display (LCD) or projector), an acoustic component (e.g., a speaker), a haptic component (e.g., a vibration motor or force feedback device), and/or other signal generator for displaying information. User input components 954 may include, for example, alphanumeric input components (e.g., a keyboard or a touch screen), a pointing component (e.g., a mouse device, a touchpad, or another pointing instrument), and/or a tactile input component (e.g., a physical button or touch screen that provides a location and/or force of a touch or touch gesture) configured to receive various user inputs (e.g., user commands and/or selections).

In some examples, I/O components 950 may include a biometric component 956, a motion component 958, an environmental component 960, and/or a location component 962, as well as a series of other physical sensor components. The biometric component 956 can include, for example, components for detecting body expressions (e.g., facial expressions, acoustic expressions, hand or body gestures, or eye tracking), measuring biological signals (e.g., heart rate or brain waves), and identifying a person (e.g., via voice, retinal, fingerprint, and/or facial based identification). Motion component 958 may include, for example, an acceleration sensor (e.g., accelerometer) and a rotation sensor (e.g., gyroscope). The environmental components 960 may include, for example, lighting sensors, temperature sensors, humidity sensors, pressure sensors (e.g., barometers), acoustic sensors (e.g., microphones for detecting environmental noise), proximity sensors (e.g., infrared sensing of nearby objects), and/or other components that may provide an indication, measurement, or signal corresponding to the surrounding physical environment. The location component 962 may include, for example, a location sensor (e.g., a Global Positioning System (GPS) receiver), a height sensor (e.g., a barometric pressure sensor from which a height may be derived), and/or an orientation sensor (e.g., a magnetometer).

The I/O components 950 may include a communication component 964, which communication component 964 implements various techniques operable to couple the machine 900 to the network 970 and/or device 980 via respective communication couplings 972 and 982. The communication component 964 can include one or more network interface components or other suitable devices that interface with the network 970. The communication component 964 can include, for example, components adapted to provide wired communication, wireless communication, cellular communication, near Field Communication (NFC), bluetooth communication, wi-Fi, and/or communication via other modalities. Device 980 may include other machines or various peripheral devices (e.g., via a USB coupling).

In some examples, communication component 964 can detect the identifier or include components adapted to detect the identifier. For example, the communication component 964 can include a Radio Frequency Identification (RFID) tag reader, an NFC detector, an optical sensor (e.g., a one-or multi-dimensional bar code, or other optical code), and/or an acoustic detector (e.g., a microphone for identifying the marked audio signal). In some examples, the location information may be determined based on information from the communication component 962, such as, but not limited to, geographic location via an Internet Protocol (IP) address, location identified and/or signal triangulated via Wi-Fi, cellular, NFC, bluetooth, or other wireless station.

While various embodiments have been described, the description is intended to be exemplary, rather than limiting, and it is understood that many more embodiments and implementations are possible within the scope of the embodiments. Although many possible combinations of features are shown in the drawings and discussed in this detailed description, many other combinations of the disclosed features are possible. Any feature of any embodiment may be used in combination with or in place of any other feature or element in any other embodiment, unless specifically limited. Thus, it will be appreciated that any of the features shown and/or discussed in this disclosure may be implemented together in any suitable combination. The embodiments are therefore not to be restricted except in light of the attached claims and their equivalents. Further, various modifications and changes may be made within the scope of the appended claims.

While the foregoing has described what are considered to be the best mode and/or other examples, it is understood that various modifications may be made therein and that the subject matter disclosed herein may be implemented in various forms and examples, and that these teachings may be applied in numerous applications, only some of which are described herein. It is intended by the appended claims to claim any and all applications, modifications, and variations that fall within the true scope of the present teachings.

Unless otherwise indicated, all measurements, values, ratings, positions, amplitudes, sizes, and other specifications set forth in the appended claims are approximate, and not exact. They are intended to have a reasonable scope consistent with the functions they relate to and the habits in the field to which they relate.

The scope of protection is limited only by the claims that follow. This range is intended and should be construed as the range consistent with the normal meaning of the language used in the claims in light of this specification and the following prosecution history, and includes all structural and functional equivalents. None of the claims, however, are intended to include subject matter that is not in compliance with patent statutes 101, 102, or 103, nor should it be interpreted in such a manner. It is hereby stated that no such subject matter is intended to be included.

Nothing described or illustrated is intended or should be construed as causing any element, step, feature, purpose, benefit, advantage, or equivalent to be dedicated to the public regardless of whether or not it is recited in the claims.

It will be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein. Relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element that is preceded by "a" or "an" does not exclude the presence of additional identical elements in a process, method, article or apparatus that comprises the element.

The Abstract of the disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing detailed description, it can be seen that various features are grouped together in various examples for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed features require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed example. Thus, the following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate claimed subject matter.

Claims (20)

1. A data processing system, comprising:

a processor; and

a computer-readable medium storing executable instructions that, when executed, cause the processor to perform operations comprising:

obtaining electronic copies of a plurality of insurance policies associated with the insured users;

analyzing the electronic copies of the plurality of policies to generate policy coverage information for each of the policies;

Converting the policy overlay information from a first format to a second format to generate standardized policy overlay information, the second format being associated with a standard schema for processing policies and claim information;

obtaining electronic copies of a plurality of insurance claims associated with the insured user;

analyzing the electronic copies of the plurality of insurance claims to generate insurance claim information;

converting the insurance claim information from a third format to a fourth format to generate standardized insurance claim information, the fourth format being associated with the standard pattern for processing insurance policies and claim information;

providing the normalized insurance claim information as input to a first machine learning model;

analyzing the normalized insurance claim information using the first machine learning model to identify occurrences of a first type of event and a first set of insurance claims associated with the first type of event, wherein the first machine learning model is trained using first training data formatted according to the standard pattern to predict and output an indication of occurrences of events of a type requiring medical treatment based on a set of insurance claims associated with the insured user;

Providing the first set of insurance claims, an indication of occurrence of the first type of event, and normalized policy information as inputs to a second machine learning model;

analyzing the first set of insurance claims, an indication of occurrence of the first type of event, and the normalized insurance policy information using the second machine learning model to obtain predictions of whether respective ones of the plurality of insurance policies will cover the first set of insurance claims, the second machine learning model being trained using second training data formatted according to the standard pattern, the second machine learning model being trained to identify one or more types of insurance policies in the normalized insurance policy information that can cover the first set of insurance claims, and predicting that the respective insurance policies can cover the first set of insurance claims by comparing the first set of insurance claims to policy specifications for the respective insurance policies;

providing the corresponding ones of the insurance policies output by the second machine learning model that will cover the first set of insurance claims to a user interface module; and

Causing a user interface to be presented on a display of a computing device associated with the insured user to direct the insured user to submit the first set of insurance claims to an insurance provider associated with the corresponding insurance policy.

2. The data processing system of claim 1, wherein the plurality of insurance claims includes a first insurance claim, and wherein to analyze the electronic copies of the plurality of insurance claims to generate the insurance claim information, the computer-readable medium includes instructions configured to cause the processor to:

performing fuzzy matching on information associated with the first insurance claim and a set of criteria of claim descriptions to identify a first criteria description for the first insurance claim; and

the first criteria description is added to the insurance claim information.

3. The data processing system of claim 1, wherein the computer-readable medium comprises instructions configured to cause the processor to:

the insurance claim information is analyzed using the first machine learning model to identify occurrences of a second type of event and a second set of insurance claims associated with the second type of event.

4. The data processing system of claim 3, wherein the computer readable medium comprises instructions configured to cause the processor to:

analyzing, using the second machine learning model, the second set of insurance claims, the policy information, and the indications of the second type of event to obtain a second prediction of whether the respective policy of the plurality of policies will cover the second insurance claim; and

responsive to the first machine learning model predicting that the respective insurance policy will cover the second set of insurance claims, presenting the user interface providing guidance to the user for submitting the second set of insurance claims to a second insurance provider associated with the respective insurance policy.

5. The data processing system of claim 4, wherein the computer-readable medium comprises instructions configured to cause the processor to:

in response to a confidence score associated with the second prediction being less than a first threshold, dynamically generating a set of questions to obtain additional information associated with at least one insurance claim of the first set of insurance claims, the additional information capable of increasing the confidence score associated with the second prediction; and

User response information associated with the dynamically generated problem set is obtained.

6. The data processing system of claim 5, wherein the computer-readable medium comprises instructions configured to cause the processor to:

analyzing a first set of claims, the normalized policy coverage information, and the user response information using the first machine learning model to obtain a third prediction of whether the first set of claims can be covered by the respective policy of the plurality of policies.

7. The data processing system of claim 6, wherein the computer-readable medium comprises instructions configured to cause the processor to:

responsive to the second machine learning model predicting that the respective insurance policy will cover the first set of insurance claims, presenting the user interface providing guidance to the user for submitting the first set of insurance claims to a second insurance provider associated with the respective insurance policy.

8. A method implemented in a data processing system for insurance claim analysis and arbitration, the method comprising:

Obtaining electronic copies of a plurality of insurance policies associated with the insured users;

analyzing the electronic copies of the plurality of policies to generate policy coverage information for each of the policies;

converting the policy overlay information from a first format to a second format to generate standardized policy overlay information, the second format being associated with a standard schema for processing policies and claim information;

obtaining electronic copies of a plurality of insurance claims associated with the insured user;

analyzing the electronic copies of the plurality of insurance claims to generate insurance claim information;

converting the insurance claim information from a third format to a fourth format to generate standardized insurance claim information, the fourth format being associated with the standard pattern for processing insurance policies and claim information;

providing the normalized insurance claim information as input to a first machine learning model;

analyzing the normalized insurance claim information using the first machine learning model to identify occurrences of a first type of event and a first set of insurance claims associated with the first type of event, wherein the first machine learning model is trained using first training data formatted according to the standard pattern to predict and output an indication of occurrences of events of a type requiring medical treatment based on a set of insurance claims associated with the insured user;

Providing the first set of insurance claims, an indication of occurrence of the first type of event, and normalized policy information as inputs to a second machine learning model;

analyzing the first set of insurance claims, an indication of occurrence of the first type of event, and the normalized insurance policy information using the second machine learning model to obtain predictions of whether respective ones of the plurality of insurance policies will cover the first set of insurance claims, the second machine learning model being trained using second training data formatted according to the standard pattern, the second machine learning model being trained to identify one or more types of insurance policies in the normalized insurance policy information that can cover the first set of insurance claims, and predicting that the respective insurance policies can cover the first set of insurance claims by comparing the first set of insurance claims to policy specifications for the respective insurance policies;

providing the corresponding ones of the insurance policies output by the second machine learning model that will cover the first set of insurance claims to a user interface module; and

Causing a user interface to be presented on a display of a computing device associated with the insured user to direct the insured user to submit the first set of insurance claims to an insurance provider associated with the corresponding insurance policy.

9. The method of claim 8, wherein the plurality of insurance claims includes a first insurance claim, and wherein analyzing the electronic copy of the first insurance claim data to generate the claim information further includes:

performing fuzzy matching on information associated with the first insurance claim and a set of criteria of claim descriptions to identify a first criteria description for the first insurance claim; and

the first criteria description is added to the insurance claim information.

10. The method of claim 8, further comprising:

the insurance claim information is analyzed using the first machine learning model to identify occurrences of a second type of event and a second set of insurance claims associated with the second type of event.

11. The method of claim 10, further comprising:

analyzing, using the second machine learning model, the second set of insurance claims, the policy information, and the indications of the second type of event to obtain a second prediction of whether the respective policy of the plurality of policies will cover the second insurance claim; and

Responsive to the first machine learning model predicting that the respective insurance policy will cover the second set of insurance claims, presenting the user interface providing guidance to the user for submitting the second set of insurance claims to a second insurance provider associated with the respective insurance policy.

12. The method of claim 11, further comprising:

in response to a confidence score associated with the second prediction being less than a first threshold, dynamically generating a set of questions to obtain additional information associated with at least one insurance claim of the first set of insurance claims, the additional information capable of increasing the confidence score associated with the second prediction; and

user response information associated with the dynamically generated problem set is obtained.

13. The method of claim 12, further comprising:

analyzing a first set of claims, the normalized policy coverage information, and the user response information using the first machine learning model to obtain a third prediction of whether the first set of claims can be covered by the respective policy of the plurality of policies.

14. The method of claim 13, further comprising:

Responsive to the second machine learning model predicting that the respective insurance policy will cover the first set of insurance claims, presenting the user interface providing guidance to the user for submitting the first set of insurance claims to a second insurance provider associated with the respective insurance policy.

15. A machine-readable medium having instructions stored thereon that, when executed, cause a processor of a programmable device to:

obtaining electronic copies of a plurality of insurance policies associated with the insured users;

analyzing the electronic copies of the plurality of policies to generate policy coverage information for each of the policies;

converting the policy overlay information from a first format to a second format to generate standardized policy overlay information, the second format being associated with a standard schema for processing policies and claim information;

obtaining electronic copies of a plurality of insurance claims associated with the insured user;

analyzing the electronic copies of the plurality of insurance claims to generate insurance claim information;

converting the insurance claim information from a third format to a fourth format to generate standardized insurance claim information, the fourth format being associated with the standard pattern for processing insurance policies and claim information;

Providing the normalized insurance claim information as input to a first machine learning model;

analyzing the normalized insurance claim information using the first machine learning model to identify occurrences of a first type of event and a first set of insurance claims associated with the first type of event, wherein the first machine learning model is trained using first training data formatted according to the standard pattern to predict and output an indication of occurrences of events of a type requiring medical treatment based on a set of insurance claims associated with the insured user;

providing the first set of insurance claims, an indication of occurrence of the first type of event, and normalized policy information as inputs to a second machine learning model;

analyzing the first set of insurance claims, an indication of occurrence of the first type of event, and the normalized insurance policy information using the second machine learning model to obtain predictions of whether respective ones of the plurality of insurance policies will cover the first set of insurance claims, the second machine learning model being trained using second training data formatted according to the standard pattern, the second machine learning model being trained to identify one or more types of insurance policies in the normalized insurance policy information that can cover the first set of insurance claims, and predicting that the respective insurance policies can cover the first set of insurance claims by comparing the first set of insurance claims to policy specifications for the respective insurance policies;

Providing the corresponding ones of the insurance policies output by the second machine learning model that will cover the first set of insurance claims to a user interface module; and

causing a user interface to be presented on a display of a computing device associated with the insured user to direct the insured user to submit the first set of insurance claims to an insurance provider associated with the corresponding insurance policy.

16. The machine-readable medium of claim 15, wherein the plurality of insurance claims includes a first insurance claim, and wherein to analyze the electronic copies of the plurality of insurance claims to generate the insurance claim information, the machine-readable storage medium includes instructions configured to cause the processor to:

performing fuzzy matching on information associated with the first insurance claim and a set of criteria of claim descriptions to identify a first criteria description for the first insurance claim; and

the first criteria description is added to the insurance claim information.

17. The machine-readable medium of claim 15, wherein the machine-readable storage medium comprises instructions configured to cause the processor to:

The insurance claim information is analyzed using the first machine learning model to identify occurrences of a second type of event and a second set of insurance claims associated with the second type of event.

18. The machine-readable medium of claim 17, wherein the machine-readable storage medium comprises instructions configured to cause the processor to:

analyzing, using the second machine learning model, the second set of insurance claims, the policy information, and the indications of the second type of event to obtain a second prediction of whether the respective policy of the plurality of policies will cover the second insurance claim; and

responsive to the first machine learning model predicting that the respective insurance policy will cover the second set of insurance claims, presenting the user interface providing guidance to the user for submitting the second set of insurance claims to a second insurance provider associated with the respective insurance policy.

19. The machine-readable medium of claim 18, wherein the machine-readable storage medium comprises instructions configured to cause the processor to:

In response to a confidence score associated with the second prediction being less than a first threshold, dynamically generating a set of questions to obtain additional information associated with at least one insurance claim of the first set of insurance claims, the additional information capable of increasing the confidence score associated with the second prediction; and

user response information associated with the dynamically generated problem set is obtained.

20. The machine-readable medium of claim 19, wherein the machine-readable storage medium comprises instructions configured to cause the processor to:

analyzing a first set of claims, the normalized policy coverage information, and the user response information using the first machine learning model to obtain a third prediction of whether the first set of claims can be covered by the respective policy of the plurality of policies; and

responsive to the second machine learning model predicting that the respective insurance policy will cover the first set of insurance claims, presenting the user interface providing guidance to the user for submitting the first set of insurance claims to a second insurance provider associated with the respective insurance policy.