CN117480519A - Machine learning driven data analysis based on demographics, risk and demand - Google Patents

Abstract

A data processing system implementation for recommending insurance plans: obtaining an electronic copy of demographic information associated with a user; analyzing demographic information with a first machine learning model to recommend policy packages based on the demographic information, wherein the first machine learning model is configured to group insured persons having similar demographics into clusters and to generate policy packages based on predicted medical insurance consumption associated with a respective group to which the model predicts the first user belongs; customizing the recommended policy package based on demographic information associated with the user to generate a customized policy package; generating an insurance recommendation report presenting the customized insurance policy package to the user; and causing a user interface of a display of a computing device associated with the user to present the insurance recommendation report.

Description

Machine learning driven data analysis based on demographics, risk and demand

Cross Reference to Related Applications

The present application claims priority from U.S. patent application Ser. No. 17/229,020, filed on 13 at 4 months 2021, U.S. patent application Ser. No. 11,113,770, now issued on 7 at 9 months 2021, entitled "Machine-Learning Driven Data Analysis Based on Demographics, risk, and Need", and from pending U.S. patent application Ser. No. 17/401,596, filed on 13 at 8 months 2021, entitled "Machine-Learning Driven Data Analysis Based on Demographics, risk, and Need", which are incorporated herein by reference in their entirety.

Background

Determining how much and what type of insurance coverage an individual needs can be a confusing and stressful process. The insurance plan may include multiple types of insurance policies that provide 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. The amount and type of coverage applicable for a particular individual may vary significantly based on the individual needs of that individual. Furthermore, coverage can be extended to family members, which can further complicate the decision making process. Thus, an individual may select a plan that may not adequately meet the needs of the insured life. Accordingly, there is a need to provide improved systems and methods for solving the following technical problems: automatically analyzing the user's insurance needs and providing advice to assist the user in establishing an insurance plan that meets the user's needs.

Disclosure of Invention

An example data processing system according to the present disclosure may include: a processor; and a computer readable storage medium storing executable instructions. The instructions, when executed, cause the processor to perform operations comprising: obtaining an electronic copy of demographic information associated with the user, wherein the demographic information includes first demographic information provided by the user, demographic information obtained from one or more third party data sources, or both; providing first demographic information as input to a first machine learning model; analyzing the first demographic information with a first machine learning model, wherein the first machine learning model is trained to divide people into clusters of people with similar demographics, wherein the first machine learning model is configured to analyze the first demographic information associated with the user to predict and output the clusters associated with the user, and to output predicted healthcare expense information associated with the predicted clusters; providing the predicted medical expenditure information to a recommendation engine to generate a comprehensive insurance plan including a plurality of insurance policies for the user based on the predicted medical expenditure information; customizing the comprehensive insurance plan based on the first demographic information associated with the user to generate a customized insurance policy package (bundle of insurance policies); generating an insurance recommendation report presenting the customized insurance policy package to the user; and causing a user interface of a display of a computing device associated with the user to present the insurance recommendation report.

An example method implemented in a data processing system for recommending an insurance plan includes: obtaining an electronic copy of demographic information associated with the user, wherein the demographic information includes first demographic information provided by the user, demographic information obtained from one or more third party data sources, or both; providing first demographic information as input to a first machine learning model; analyzing the first demographic information with a first machine learning model, wherein the first machine learning model is trained to divide people into clusters of people with similar demographics, wherein the first machine learning model is configured to analyze the first demographic information associated with the user to predict and output the clusters associated with the user, and to output predicted healthcare expense information associated with the predicted clusters; providing the predicted medical expenditure information to a recommendation engine to generate a comprehensive insurance plan including a plurality of insurance policies for the user based on the predicted medical expenditure information; customizing the composite insurance plan based on first demographic information associated with the user to generate a customized insurance policy package; generating an insurance recommendation report presenting the customized insurance policy package to the user; and causing a user interface of a display of a computing device associated with the user to present the insurance recommendation report.

An example computer-readable storage medium having instructions stored thereon that, when executed, cause a processor of a programmable device to: obtaining an electronic copy of demographic information associated with the user, wherein the demographic information includes first demographic information provided by the user, demographic information obtained from one or more third party data sources, or both; providing first demographic information as input to a first machine learning model; analyzing the first demographic information with a first machine learning model, wherein the first machine learning model is trained to divide people into clusters of people with similar demographics, wherein the first machine learning model is configured to analyze the first demographic information associated with the user to predict and output the clusters associated with the user, and to output predicted healthcare expense information associated with the predicted clusters; providing the predicted medical expenditure information to a recommendation engine to generate a comprehensive insurance plan including a plurality of insurance policies for the user based on the predicted medical expenditure information; customizing the composite insurance plan based on first demographic information associated with the user to generate a customized insurance policy package; generating an insurance recommendation report presenting the customized insurance policy package to the user; and causing a user interface of a display of a computing device associated with the user to present the insurance recommendation report.

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, 6F, and 6G illustrate example user interfaces for presenting a insurance bundle recommendation.

FIG. 7 is a flow chart of an example process for recommending an integrated policy package.

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.

FIG. 10 is a diagram of an example insurance recommendation report.

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 recommendations of health and insurance plans, including insurance policy packages based on personal demographics, risk, and demand, are described herein. Establishing a comprehensive insurance plan that adequately meets the needs of the insured life is a complex process. The program may include a package of insurance policies, each having a complex listing of the types of claims that the insurance company may cover and coverage limits that provide conditions under which the insurance company may cover such claims. To further complicate the process of selecting the appropriate plan, the insured may need to consider the needs of the family members that will also be covered by the insurance plan. Furthermore, the insured must consider the costs associated with each type of coverage to ensure that the selected plan meets the financial needs of the user. Understanding how multiple insurance policies are combined to meet these needs is a confusing and error-prone process. The technology provided herein provides a solution to this problem by analyzing the user's demographic information, the user's risk aversion, and the user's insurance needs using one or more machine learning models to provide suggestions for insurance plans. One or more machine learning models may be trained using demographics for an insured crowd to divide the insured crowd into clusters of users with similar demographics. The one or more models may predict an estimated medical expenditure of the insured user by predicting a cluster to which the user belongs based on the demographics of the user and providing the predicted medical expenditure of the cluster. The predicted medical payout of the cluster may include the amount and type of money typically spent in the claim being filed. The predicted medical costs may then be used to create a comprehensive insurance plan for the user that includes the recommended insurance policy packages based on the predicted medical costs. The recommended policy package may be customized for the user based on the user's demographic information, the user's risk liability, and the user's needs. A technical benefit of this approach is that the machine learning model may identify patterns in the user's insurance consumption and demographic information to recommend comprehensive insurance plans that may not be obvious to the user. The insurance packages may be presented to the user using dynamically generated scenes that support making recommendations using data associated with the user. A technical benefit of this approach is that the user can easily understand the reasons why each of the policies in the policy package was recommended. 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 information from a combination of data sources, which may also significantly improve predictions provided by machine learning models, and provide recommendations to users that are more likely to be provided for the needs of the user. These and other technical benefits of the technology disclosed herein will be apparent from the following discussion of example implementations. Furthermore, the techniques provided herein satisfy a long felt need for improving recommendations that may be made to users to select a policy package that covers the user's complex and variable needs. Furthermore, the solutions provided to this problem have been rooted in computer technology to overcome the problems occurring in the field of computer systems, providing a substantially real-time analysis of demographics, risk and need to provide suggestions to the user that are appropriate to their current needs.

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 packages 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. CAAS105 may also respond to changes in the user's demographics and may provide insurance package 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 provider 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 provider 130 for information and may reformat the data into a standard schema that is used by the CAAS105 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, a plan metadata data store 215, a census data store 220, a Health Savings Account (HSA) provider API 225, an insurance plan quote API 230, a prescription API 235, a claims and insurance policy API 240, a qualification API 245, and a 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 raw data 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 provider 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 insurance package 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 may implement the elements of the package recommendation 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 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 dialing of the MSA based on previous health plan consumption and to utilize the MSA funds to reimburse medical claim costs. 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 composition planning unit 275 may provide advice to the user for constructing a insurance package taking into account the demographics of the user, the risk aversion of the user and the needs of the user. Additional details of insurance combination planning unit 275 are shown in fig. 3, 4, 6A-6G, and 7.

Fig. 3 is a diagram illustrating an example implementation of package recommendation engine 325 that may be implemented by CAAS 105. The package recommendation engine 325 may be configured to provide machine-learning driven recommendations for the integrated insurance plan based on the user's personal demographics, the user's risk of disliked, and the user's coverage needs. The package recommendation engine 325 may be implemented in part by the raw data layer 205, the event-based notification layer 250, and the insight layer 290.

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 package recommendation engine 325 may use this information to obtain information about the user's current insurance coverage and to obtain information about claims previously made for the user's insurance policy. Past claim information may be used by package recommendation engine 325 to predict future claim consumption by a user based on a demographic cluster to which the predicted user belongs. The predicted consumption information may be used to generate a composite insurance plan for the user that includes recommendations for a package of insurance 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, claim-free information (deductible information), claim 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 information may also be used by package recommendation engine 325 to provide guidance to the user regarding the user's current insurance coverage and the coverage provided by the recommended plan.

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 package recommendation engine 325 to determine whether the user has a policy that may cover the claim.

The policy resolution engine 315 may also be configured to receive the planned quotation information from the insurance quotation unit 335. The insurance quotation unit 335 may be configured to obtain policy quotations from the insurance company via the insurance plan quotation API 230. The insurance plan quote API 230 may be configured to request, via the insurance portal 125, policy information and quotes for purchasing coverage from the insurance company in response to a query from one or more elements of the CAAS 105. For example, package recommendation unit 325 may be configured to request policy information for one or more types of policies that may be included in a policy package to be recommended to a user. The policy resolution engine 315 may resolve the policy information in a similar manner as described above to normalize the policy information received with the quote. The raw policy data may be stored in the data lake 210 and the normalized policy information may be stored in the insurance policy data 215. Information associated with the offers may be stored and used to generate insurance plan recommendations for the user. Because the availability of the insurance plan and the offered quotation can change over time, information associated with the quotation can be discarded after a threshold period of time has elapsed.

Mapping policy coverage information to standard descriptions may provide significant technical benefits by improving the predictions provided by the machine learning model used by package recommendation engine 325. The machine learning model may be trained using training data that includes the same standard insurance coverage descriptions that will be used by the package recommendation 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 use fuzzy matching techniques to map the claim and prescription information 310 to the standardized claim and prescription descriptions before the package recommendation 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 that may be 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 package recommendation 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 package recommendation engine 325. The machine learning model may be trained using training data that includes the same standard claims and/or prescription descriptions that will be used by package recommendation engine 325 to recommend insurance plans to users. 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 package recommendation engine 325 correctly determines previous insurance consumption and recommends an appropriate insurance plan to the user.

The third party data parsing engine 340 may be configured to obtain data from the third party data provider 130 and parse the third party data. The third party data may include, but is not limited to, credit history information, liability information such as mortgage, car, or student loan, lease history for renters, cost of life information related to the geographic area in which the user resides, and/or other information that may assist package recommendation engine 325 in developing a comprehensive insurance plan for the user. The third party data parsing engine 340 may convert the raw data received from the third party data provider 130 into a standard schema for use by the CAAS 105. The third party data parsing engine 340 may also be configured to identify ambiguous data received from the third party data source 130 and attempt to clarify the ambiguous data. The data received from the third party source may not be explicitly associated with the user associated with the data, and the third party data parsing engine 340 may then analyze the data in an attempt to determine which, if any, of the obtained data is actually associated with the user. For example, a third party data associated query for a user may include loan information, but the query returns loan data for three persons similar to the user's name. The third party data parsing engine 340 may need to clarify the obtained information. The third party data parsing engine 340 may use fuzzy matching techniques to attempt to match loan data with third party data and/or data obtained from the user that is known to be associated with the user. The third party data parsing engine 340 may obtain information from the user via dynamic questions presented by the insurance questionnaire unit 330 described below. For example, with respect to loan information, a dynamic question or set of questions may be presented to the user to determine whether any of the loan information is actually associated with the user. Information found not to be associated with the user may be discarded. The fuzzy matching technique may produce a corresponding value that represents the degree to which the ambiguous data matches the known data associated with the user. The insurance questionnaire unit 330 may be configured to discard portions of ambiguous data having corresponding values less than the threshold as it is not relevant to the user.

The insurance questionnaire unit 330 may be configured to present a dynamically generated set of questions to the user to gather information from the user that may be used by the package recommendation engine 325 to recommend a package of insurance policies that meet the user's needs. The dynamically generated questions may be used to gather information such as, but not limited to, the user's medical history, past insurance consumption, financial profile information (liabilities, assets, liabilities), credit history, family information, psychological characteristics, interests, professions, wages, physical activities, and other information that may be used by package recommendation engine 325 to determine the user's needs and present an insurance plan meeting those needs. The insurance questionnaire unit 330 may also consider the standardized policy information, claim information, and prescription information provided by the policy resolution engine 315 and the claim and prescription resolution engine 320 in determining which information to request from the user. Package recommendation engine 325 may use past medical claim information to identify medical conditions experienced by a user or by an insured family member. Chronic diseases that may require continued treatment may be identified and insurance plans that provide coverage for those diseases may be recommended. Chronic diseases such as heart disease, cancer, chronic lung disease, kidney disease, alzheimer's disease and/or dementia-related chronic diseases and/or other medical conditions requiring long-term medical intervention and/or long-term care may be identified.

The insurance questionnaire unit 330 may obtain third party data from the third party data parsing engine 340, which may be used to generate further questions that may be presented to the user. The problem may be used to clarify information provided by a user and/or obtained from a third party data source. The insurance questionnaire unit 330 may be configured to generate questions to obtain information from the user that may be used to learn about the risk exposure of the user. The CAAS105 may use this information and the user's demographic information to provide a recommended insurance policy package that covers these risks in a manner that suits the user's specific needs. In addition, the user's response to the question may trigger the insurance questionnaire unit 330 to query additional third party data that may be processed by the third party data parsing engine 340. The dynamically generated questions may be used to further clarify information obtained from the user and/or from third party data sources. For example, if the third party information indicates that the user has a mortgage, an automobile loan, a student loan liability, and/or other types of liabilities, insurance questionnaire unit 330 may be configured to present subsequent questions to the user to determine how the user may handle the liabilities in some circumstances. For example, insurance questionnaire unit 330 may be configured to present questions about how long a user may be able to continuously pay a liability in the event of a loss of revenue and how much confidence the user has in his ability to continuously pay a liability. These and other types of questions may be used to infer financial resources of the user, such as available cash resources that the user may use to pay in emergency situations. Package recommendation engine 325 may use this information to recommend an insurance policy that considers the financial condition of the user to provide an insurance policy that can cover the loss of revenue. For example, if the user or insured family member is a business owner, a business outage insurance may be recommended to cover the revenue loss due to the risk of coverage by the policy. Package recommendation engine 325 may also supplement the disabled insurance policy for revenue loss due to insured persons or family members becoming inoperable due to medical conditions or injury.

The insurance questionnaire unit 330 may implement one or more predictive machine learning models that may be used to identify additional modalities that may be used for the package recommendation engine 325 to make recommendations to the user. The predictive model may analyze available demographic information provided by the user and/or collected from one or more third party data providers 130 to identify information that may be used to further understand the coverage needs of the user. The insurance questionnaire unit 330 may analyze the predictions to determine whether the user data information and/or third party data included in the information is predicted to be useful. The insurance questionnaire unit 330 may identify gaps in user-provided and/or third party information. The insurance questionnaire unit 330 may attempt to obtain information by querying the third party data sources 130 to resolve the gap in information and/or may present dynamically generated questions to the user to obtain information that may help fill in the gap in information that has been obtained from the user and/or from the third party data sources. The predictive model may be a machine learning model that is trained to identify relationships between types of data that may be relevant to recommending comprehensive insurance policy plans to a user. Other types of predictive models and/or algorithms may also be used to implement the insurance questionnaire unit 330.

Fig. 6A-6G, described in detail below, provide examples of user interfaces that may be provided to CAAS 105. These examples illustrate a series of questions that may be generated by the insurance questionnaire unit 330. The insurance questionnaire unit 330 may be configured to trigger the presentation of certain questions in response to the presence or absence of certain information in the data available to the insurance questionnaire unit 330.

Package recommendation engine 325 analyzes information received from policy resolution engine 315, claims and prescription resolution engine 320, insurance questionnaire unit 330, insurance quote unit 335, and one or more third party data providers 130 to generate recommended insurance plan packages for the user. Additional implementation details of package recommendation engine 325 are shown in fig. 4.

Fig. 4 is a diagram illustrating an example implementation of package recommendation engine 325 of CAAS 105. Package recommendation engine 325 may include a plan recommendation unit 405, a consumer-clustered machine learning model 410, a dynamic scenario unit 420, a plan purchasing unit 425, and a model update unit 430.

Package recommendation engine 325 may analyze user data from the various sources discussed above to recommend an integrated insurance plan that may include a combination of insurance policies, health savings accounts, supplemental insurance policies, and/or other insurance products that may be included as part of the integrated insurance plan. Recommendations may be generated on demand in response to requests from users, or automatically by CAAS105 in response to various events indicating risk exposure of users. Changes in the user's demographic information may trigger the CAAS105 to generate a new recommended insurance package for the user. Demographic information may be updated by the user and/or obtained from one or more third party data sources. For example, the plan recommendation engine may be configured to respond to changes in marital status, birth or care of children, purchases of new households, changes in work, and/or other events for which a new insurance plan may be desired to ensure that users have sufficient insurance coverage to reflect their needs for changes. Package recommendation engine 325 may also be configured to direct a user to obtain recommended coverage from one or more insurers in response to the user indicating that they wish to obtain coverage recommended by package recommendation engine 325.

The plan recommendation unit 405 may be configured to obtain claims, insurance policies, and user demographic information 440 to be analyzed to suggest an integrated insurance plan for the user. The claims, policy, and demographic 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 into standard patterns output by the claim and resolution engine 320. The claims, insurance policies, and demographics 440 may also include user demographics that may have been obtained by the insurance questionnaire unit 330.

The plan recommendation unit 405 can first analyze the claims, insurance policy, and demographic information 440 to generate a claim cluster prediction. The plan recommendation unit 405 may provide the consumption cluster prediction model 410 with information associated with the user. The consumption cluster prediction model 410 may be trained with demographic information, claim information, medical history information, financial profile information, credit history information, family information, psychological characteristics, interests, professions, wages, physical activities, and other information that may be used to group users into clusters with similar characteristics. The consumption cluster prediction model 410 may be configured to output predictions that the user belongs to a particular cluster associated with an expected medical expenditure over a predetermined period of time. Because many insurance policies are updated each year, the predetermined period of time may be one year in many implementations. However, in some implementations, the time period associated with the prediction may be different.

The predicted medical payout for the cluster may include the amount and type of money that is typically spent in the claim being filed. The predicted medical costs may then be used to create a comprehensive insurance plan for the user that includes a recommended insurance policy package based on the predicted medical costs. The integrated plan may include an insurance policy package, a health savings account, a supplemental insurance policy, and/or other insurance products that may be included as part of the integrated insurance plan. The predictions take into account many factors that can affect the risk exposure of the user and provide recommended packages that can best match the needs of the user. When making recommendations, the model takes into account a set of complex variables that would not be practical or even possible for the user to consider without such assistance. Thus, a technical benefit of the method is that the machine learning model may identify patterns in the user's insurance consumption and demographic information to recommend an integrated insurance plan that may be unobvious to the user.

The predictive model 410 may be initially trained with manually labeled training data, but the model may be refined based on feedback about the predictions from the model update unit 430 discussed below. The consumption cluster prediction model 410 may be implemented using various types of machine learning models for which training of the model may be improved.

The plan recommendation unit 405 may be configured to analyze the predicted medical expenditure for the user and recommend a policy package, a healthy savings account, a supplemental policy, and/or other insurance products that may cover the predicted medical expenditure. For example, if the predicted medical expenditure includes hospitalization caused by an accident, the recommended insurance policy package may include at least one insurance policy (e.g., an accident policy) covering the hospitalization. The integrated plan may then be customized by the plan recommendation unit 405 to meet the needs of the user.

The plan recommendation unit 405 may customize the recommended policy packages based on user demographics. The plan recommendation unit 405 may customize the recommended insurance policy packages based on the user's medical history, past insurance consumption, financial profile information (liabilities, assets, liabilities), credit history, family information, psychological characteristics, interests, professions, wages, physical activities, and other information for customizing the recommendation plan according to the user's needs. The plan recommendation unit 405 may use this information to identify a potential gap between the coverage provided by the recommended policy package and the needs of the user.

The following example illustrates how the plan recommendation unit 405 may identify such gaps in coverage and customize recommended policy packages to fill the gaps. The plan recommendation unit 405 may consider the marital status of the user and/or the number of caregivers in customizing the plan. For example, the amount of life insurance recommended to the user may be increased based on whether the user has been married and for the case where the user has more caretakers. Furthermore, the plan recommendation unit 405 may recommend a Health Maintenance Organization (HMO) instead of a Preferred Provider Organization (PPO) for users with more caregivers to reduce the self-paid expenditure associated with the PPO. The plan recommendation unit 405 may also consider the user's previous medical expenses when customizing recommended policy packages to the user. For example, if the user has a history of medical visits to an otorhinolaryngologist for ear-related problems in the past few years, the plan recommendation unit 405 may select a comprehensive plan that covers all or a large portion of the costs associated with such visits. The plan recommendation unit 405 may also consider the occupation of the user when making recommendations, as the risk of certain types of injuries and/or deaths may be greater for certain occupations. In addition, revenues of the user and/or the user's spouse may be considered in making the recommendation to ensure that the cost of the recommended policy does not exceed a threshold portion of available revenues. The plan recommendation unit 405 may reduce the cost of the recommended insurance policy packages by eliminating some types of coverage that may otherwise be recommended, by selecting cheaper plans, and/or by reducing the policy rights of one or more of the insurance policies. In another example, packages associated with predictions may recommend Healthy Savings Accounts (HSAs), but low or no reimbursement plans paid by employers may be provided to users, and inclusion of HSAs may be unnecessary. In another example, the plan recommendation unit 405 may recommend supplemental life insurance policies that are not included in the original recommended insurance policy package, where the coverage of the life insurance policy provided by the user's employer is less than the coverage required to repayment the user's mortgage loan and replace the user's revenue for a particular period of time. Supplemental life insurance policies may be recommended to cover the gap between the employer-provided life insurance policy and the desired coverage amount. The customization provided by the plan recommendation unit 325 is not limited to these examples. The plan recommendation unit 325 may consider other factors in addition to or instead of those discussed above when customizing recommendations for a user.

The dynamic scenario unit 420 is configured to generate an insurance recommendation report based on the policy packages recommended by the plan recommendation unit 405. The CAAS105 may cause the insurance recommendation report to be displayed on the user's client device 115. The insurance recommendation report provides detailed information about the comprehensive insurance plan recommended to the user.

An example insurance recommendation report is shown in fig. 6G and 10. The insurance recommendation report provides a list of insurance policies recommended by the plan recommendation unit 405. The insurance recommendation report may include the insurance provider from which the insurance policy may be obtained, the cost of the insurance policy, the insurance policy coverage information, and/or other information associated with the insurance policy. The insurance recommendation report may also include a dynamic scenario associated with each insurance policy recommended. The dynamic scenario provides a description (narrative) explaining why an insurance policy has been recommended to the user. The cost and/or savings associated with each policy may be described, as well as other information indicating why a particular policy has been recommended to the user. For example, a combination of a healthy payout account and a high-claim policy may be recommended to the user. The user may be predicted to present a minimum number of health claims in a year. Accordingly, higher reimbursement medical plans may be recommended, which may be less costly, but may protect the user from catastrophic losses. The user may also provide tax free funds to the HSA to offset the medical costs of the current year. These example scenarios illustrate the types of information that may be provided in the plan recommendation report so that the user knows why the recommendation was made. The content of the report is not limited to these specific examples.

The plan purchasing unit 425 may be configured to enable the user to purchase an insurance policy included in an insurance policy package recommended to the user. Some of the insurance policies may have been issued to the user and the user does not need to purchase. For example, a user may have a medical insurance policy provided by an existing employer that has been provided to the user by the user's employer. Furthermore, some of the insurance policies may not be purchased online. The plan procurement unit 425 may be configured to present instructions on a user interface of the CAAS 105. The plan procurement assistant 425 may also provide the ability for the user to electronically fill out forms and print forms to be sent to the insurer via the postal mail service. The plan purchase unit 425 may be configured to assist the user in obtaining forms to modify existing insurance policies, if necessary. For example, if the recommendation includes a change in registration from a Preferred Provider Organization (PPO) to a Health Maintenance Organization (HMO) for an insurance provided by the employer, the plan purchasing unit 425 may be configured to obtain a copy of the form required to make the change. The plan purchasing unit 425 may also notify the user of any restrictions on making such changes (e.g., changes in the status of the home or changes that must be made during a particular open registration). The plan purchasing unit 425 may receive a summary of the actions taken to obtain the recommended insurance policy.

Model update unit 430 may be configured to provide feedback to consumer cluster prediction model 410 to improve training of the model. The model update unit 430 may receive feedback directly from the user and/or from the plan recommendation unit 405. Feedback from the user may be obtained from the plan recommendation unit 405 in response to the user selecting to not select one or more insurance policies associated with the recommendation or rejecting the proposed insurance policy package altogether. Feedback may be used to further refine clusters predicted by consumer cluster prediction model 410.

Fig. 6A-6G are diagrams illustrating an example user interface of CAAS105 for collecting information for generating and for presenting policy package recommendations. The user interfaces shown in fig. 6A-6G 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 an insurance dashboard user interface 605. The insurance dashboard user interface 605 may be implemented by the claim concierge unit 255 of the insight layer 290 of the CAAS 105. The insurance dashboard user interface 605 includes a notification pane 625, a claim details pane 630, and a claim analysis pane 635. The example implementation of the insurance dashboard user interface 605 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), what time a particular service was performed, what service was performed, co-payment information, insurer information for the insurer to which 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 for various elements of 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 605 may be created by the package recommendation engine 325. User interface 610 shows the beginning of an example insurance plan questionnaire. User interface 610 illustrates a first dynamically generated question of a questionnaire. These questions may be generated to gather information from the user, which package recommendation engine 325 may analyze to provide insurance plan recommendations. The user may click on the "next" button to indicate to CAAS105 that the user wishes to proceed to the next question in the questionnaire shown in fig. 6C.

Fig. 6C shows the next question in the questionnaire on the user interface 610. The question shown in fig. 6C has been selected based on the user's response to the question shown in fig. 6B. In fig. 6B, the user indicates that they are engaged in an exercise, and in fig. 6C, the user is asked if the user is engaged in any of the list of exercises that may be considered "limit" exercises. The questionnaire includes these questions because participating in such an exercise may affect the insurance coverage that package recommendation engine 325 may recommend to the user. Fig. 6D shows additional problems related to past insurance consumption, and fig. 6E and 6F show additional problems related to a change in marital status of an insured. The user may advance the question by clicking on the "next" button, or may return to the previous question by clicking on the "back" button.

FIG. 6G illustrates an example user interface 640 that provides an example insurance recommendation report. Fig. 10 shows a complete report partially shown on the user interface shown in fig. 6G. The package recommendations may be generated by package recommendation engine 325. The recommendation pane 655 includes a list of insurance policies recommended to the user. Each entry includes dynamic context information that explains why the recommendation was made to the user. Dynamic scenario information is based on information collected from the user, information obtained from third party information sources, claims and/or prescription information indicating previous insurance consumption, and/or other data analyzed by package recommendation engine 325 to create a plan recommendation. The dynamic scenario binds the provided interpretation directly to the data. The dynamic scenario may include costs and/or savings associated with each of the policy recommendations. The plan may include multiple types of insurance policies that provide an integrated insurance plan that provides coverage for the user.

FIG. 7 illustrates a flow chart of an example process 700 for recommending a policy package to a user. The process 700 may be implemented by the CAAS105 discussed in the previous example.

Process 700 may include an operation 710 of obtaining an electronic copy of first demographic information associated with a user. The first demographic information may include demographic information provided by the user, demographic information obtained from one or more third party data sources, or both. As discussed in the previous examples, user demographic information may be collected from the user via the insurance questionnaire unit 330, from the third party data provider 130, or both. Demographic information may include various information about the user such as, but not limited to, age, gender, race, and/or other information that may be used to divide the population into clusters of people with similar characteristics. Demographic information may include other factors associated with the user such as, but not limited to, past insurance claims information, medical history information, financial profile information, credit history information, family information, psychological characteristics, interests, profession, wages, physical activities, and other information that may be used to group users into clusters of people with similar characteristics.

Process 700 may include operation 720: a plurality of questions are dynamically generated to obtain second demographic information of the user by identifying additional demographic information related to the user using a first machine learning model, wherein the additional demographic information is used to determine insurance coverage needs of the user, the first machine learning model is trained to receive first demographic information of the user as input, and to predict and output additional information demographic information related to the determined insurance coverage needs of the user based on the first demographic information. The insurance questionnaire unit 330 may analyze the first demographic information received from the user, the third party data provider 130, or both, to identify additional information that may be relevant to recommending a comprehensive insurance plan to the user. The insurance questionnaire unit 330 may identify gaps in the first demographic information and generate questions to present to the user to fill in these gaps. The process of collecting and analyzing demographic data and analyzing data obtained from the user, from the third party data source 130, or both, may be an iterative process that may be repeated multiple times as additional information about the user is obtained.

The process 700 may include an operation 730 of adding the second demographic information to the first demographic information to create accumulated demographic information of the user. Additional demographic information obtained for the user may be stored by the CAAS105 and used by the package recommendation engine 325 and/or other elements of the CAAS105 to provide various services to the user.

The process 700 may include an operation 740 of providing the accumulated demographic information as input to a second machine learning model and an operation 750 of analyzing the accumulated demographic information with the second machine learning model, wherein the first machine learning model is trained to divide people into clusters of people with similar demographics, wherein the first machine learning model is configured to analyze the accumulated demographic information associated with the user to predict the clusters associated with the user and output predicted medical spending information associated with the predicted clusters. The second machine learning model may be implemented by the cluster consumption training model 410 and may be trained to divide people into clusters of people with similar demographics. The second machine learning model may be configured to analyze the accumulated demographic data associated with the user to predict a cluster associated with the first user and output predicted healthcare expense information associated with the predicted cluster.

Process 700 may include operation 760: the predicted medical expense information output by the first machine learning model is provided to a recommendation engine to generate an integrated insurance plan including a plurality of insurance policies for the user based on the predicted medical expense information. The package recommendation engine 325 may be configured to generate an integrated insurance plan for the user based on the predicted medical consumption obtained from the machine learning model, as discussed in the previous examples.

Process 700 may include an operation 770 of customizing the integrated insurance plan based on demographic information associated with the user to generate a customized insurance policy package. Package recommendation engine 325 may customize the composite insurance plan based on the user's demographics, as discussed in the previous examples.

Process 700 may include an operation 780 of generating an insurance recommendation report presenting the customized insurance policy package to the user. In addition to dynamic scenario information (which provides an explanation of why each recommendation was made, bound to user information), dynamic scenario unit 420 may present a recommended insurance policy package. An example of such a report is shown in fig. 6G.

Process 700 may include an operation 790 of causing a user interface of a display of a computing device associated with a user to present an insurance recommendation report. Package recommendation engine 325 may cause user's client device 115 to display an insurance recommendation report. As discussed in the previous examples, the user may interact with CAAS105 via a native application associated with CAAS105 on client device 115 or via a web browser on client device 115. The user may be presented with a recommended policy package. In some implementations, the CAAS105 may be configured to provide a means for a user to obtain a recommended policy from an insurance company.

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 corresponding 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 that 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) to operate in some manner or to 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 be different 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 storage medium storing executable instructions that, when executed, cause the processor to perform operations comprising:

obtaining an electronic copy of demographic information associated with a user, wherein the demographic information includes first demographic information provided by the user, demographic information obtained from one or more third party data sources, or both;

Providing the first demographic information as input to a first machine learning model;

analyzing the first demographic information with the first machine learning model, wherein the first machine learning model is trained to divide people into clusters of people with similar demographics, wherein the first machine learning model is configured to analyze the first demographic information associated with the user to predict and output clusters associated with the user, and to output predicted medical expense information associated with the predicted clusters;

providing the predicted medical expenditure information to a recommendation engine to generate a comprehensive insurance plan including a plurality of insurance policies for the user based on the predicted medical expenditure information;

customizing the comprehensive insurance plan based on the first demographic information associated with the user to generate a customized insurance policy package;

generating an insurance recommendation report presenting the customized insurance policy package to the user; and

causing a user interface of a display of a computing device associated with the user to present the insurance recommendation report.

2. The data processing system of claim 1, wherein the predicted medical payout information includes a predicted amount spent on medical claims and a type of claim typically presented by a person associated with the predicted cluster.

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

dynamically generating a plurality of questions to obtain second demographic information of the user by identifying additional demographic information related to the user using a second machine learning model, wherein the additional demographic information is used to determine insurance coverage needs of the user, the second machine learning model is trained to receive the first demographic information of the user as input, and predict and output additional information demographic information related to determining insurance coverage needs of the user based on the first demographic information;

obtaining the second demographic information as a response to the plurality of questions; and

the second demographic information is combined with the first demographic information before the first demographic information is provided to the first machine learning model as input.

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

Submitting a query to one or more third party data providers to obtain at least a portion of the additional demographic information identified by the second machine learning model;

receiving third party data responsive to the query; and

at least a portion of the third party data is combined with the first demographic information submitted to the first machine learning model.

5. The data processing system of claim 1, wherein to generate the insurance recommendation report that presents the customized insurance policy package to the user, the computer-readable storage medium includes instructions configured to cause the processor to:

obtaining a description of each policy comprising the policy package;

generating a description indicating why each policy included in the policy package has been selected for the user; and

the insurance recommendation report is generated to present the description and the description of each insurance policy.

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

Causing a user interface of a display of a computing device associated with the user to present an insurance policy purchase user interface configured to guide the user to obtain one or more insurance policies included in the customized insurance policy package.

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

an insurance digest report is generated that includes actions that have been taken to obtain the one or more insurance policies and policy information for each of the obtained insurance policies.

8. A method implemented in a data processing system for recommending insurance plans, the method comprising:

obtaining an electronic copy of demographic information associated with a user, wherein the demographic information includes first demographic information provided by the user, demographic information obtained from one or more third party data sources, or both;

providing the first demographic information as input to a first machine learning model;

Analyzing the first demographic information with the first machine learning model, wherein the first machine learning model is trained to divide people into clusters of people with similar demographics, wherein the first machine learning model is configured to analyze the first demographic information associated with the user to predict and output clusters associated with the user, and to output predicted medical expense information associated with the predicted clusters;

providing the predicted medical expenditure information to a recommendation engine to generate a comprehensive insurance plan including a plurality of insurance policies for the user based on the predicted medical expenditure information;

customizing the comprehensive insurance plan based on the first demographic information associated with the user to generate a customized insurance policy package;

generating an insurance recommendation report presenting the customized insurance policy package to the user; and

causing a user interface of a display of a computing device associated with the user to present the insurance recommendation report.

9. The method of claim 8, wherein the predicted medical payout information includes a predicted amount spent on medical claims and a type of claim typically presented by a person associated with the predicted cluster.

10. The method of claim 8, further comprising:

dynamically generating a plurality of questions to obtain second demographic information of the user by identifying additional demographic information related to the user using a second machine learning model, wherein the additional demographic information is used to determine insurance coverage needs of the user, the second machine learning model is trained to receive the first demographic information of the user as input, and predict and output additional information demographic information related to determining insurance coverage needs of the user based on the first demographic information;

obtaining the second demographic information as a response to the plurality of questions; and

the second demographic information is combined with the first demographic information before the first demographic information is provided to the first machine learning model as input.

11. The method of claim 10, further comprising:

submitting a query to one or more third party data providers to obtain at least a portion of the additional demographic information identified by the second machine learning model;

Receiving third party data responsive to the query; and

at least a portion of the third party data is combined with the first demographic information submitted to the first machine learning model.

12. The method of claim 8, wherein generating the insurance recommendation report presenting the customized insurance policy package to the user further comprises:

obtaining a description of each policy comprising the policy package;

generating a description indicating why each policy included in the policy package has been selected for the user; and

the insurance recommendation report is generated to present the description and the description of each insurance policy.

13. The method of claim 12, further comprising:

causing a user interface of a display of a computing device associated with the user to present an insurance policy purchase user interface configured to guide the user to obtain one or more insurance policies included in the customized insurance policy package.

14. The data processing system of claim 13, further comprising:

an insurance digest report is generated that includes actions that have been taken to obtain the one or more insurance policies and policy information for each of the obtained insurance policies.

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

obtaining an electronic copy of first demographic information associated with a user, wherein the first demographic information includes demographic information provided by the user, demographic information obtained from one or more third party data sources, or both;

dynamically generating a plurality of questions to obtain second demographic information of the user by identifying additional demographic information related to the user using a first machine learning model, wherein the additional demographic information is used to determine insurance coverage needs of the user, the first machine learning model is trained to receive the first demographic information of the user as input, and predict and output additional information demographic information related to determining insurance coverage needs of the user based on the first demographic information;

adding the second demographic information to the first demographic information to create accumulated demographic information of the user;

Providing the accumulated demographic information as input to a second machine learning model;

analyzing the accumulated demographic information with the second machine learning model, wherein the second machine learning model is trained to divide people into clusters of people with similar demographics, wherein the second machine learning model is configured to analyze the accumulated demographic information associated with the user to predict and output clusters associated with the user, and to output predicted medical expenditure information associated with predicted clusters;

providing the predicted medical expenditure information to a recommendation engine to generate a comprehensive insurance plan including a plurality of insurance policies for the user based on the predicted medical expenditure information;

customizing the comprehensive insurance plan based on the accumulated demographic information associated with the user to generate a customized insurance policy package;

generating an insurance recommendation report presenting the customized insurance policy package to the user; and

causing a user interface of a display of a computing device associated with the user to present the insurance recommendation report.

16. The computer-readable storage medium of claim 15, wherein the predicted medical payout information includes a predicted amount spent on medical claims and a type of claim typically presented by a person associated with the predicted cluster.

17. The computer-readable storage medium of claim 15, comprising instructions configured to cause the processor to:

dynamically generating a plurality of questions to obtain second demographic information of the user by identifying additional demographic information related to the user using a second machine learning model, wherein the additional demographic information is used to determine insurance coverage needs of the user, the second machine learning model is trained to receive the first demographic information of the user as input, and predict and output additional information demographic information related to determining insurance coverage needs of the user based on the first demographic information;

obtaining the second demographic information as a response to the plurality of questions; and

the second demographic information is combined with the first demographic information before the first demographic information is provided to the first machine learning model as input.

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

Submitting a query to one or more third party data providers to obtain at least a portion of the additional demographic information identified by the second machine learning model;

receiving third party data responsive to the query; and

at least a portion of the third party data is combined with the first demographic information submitted to the first machine learning model.

19. The computer-readable storage medium of claim 15, wherein to generate the insurance recommendation report that presents the customized insurance policy package to the user, the computer-readable storage medium comprises instructions configured to cause the processor to:

obtaining a description of each policy comprising the policy package;

generating a description indicating why each policy included in the policy package has been selected for the user; and

the insurance recommendation report is generated to present the description and the description of each insurance policy.

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

Causing a user interface of a display of a computing device associated with the user to present an insurance policy purchase user interface configured to guide the user to obtain one or more insurance policies included in the customized insurance policy package.