Patent Application
20230145278
Processing user-specific data to determine user-specific benefits and obligations can be time consuming and complex as different parameters may affect the obligation ultimately required to be provided by a particular user. Accordingly, it would be advantageous to employ a rules engine to evaluate unique datasets to more accurately and more quickly determine benefits and obligations for specific users based on collected data sets associated with the specific users.
One embodiment relates to a system comprising a processor and a non-transitory computer-readable medium comprising computer-readable instructions stored thereon that when executed by the processor cause the processor to collect a first data set associated with a user by a user interface of a user device, collect a second data set, generate a new data structure using the first data set and the second data set where the new data structure comprises an electronic data interchange request for a third data set, transmit the electronic data interchange request to a remote third party computing system, receive an electronic data interchange response containing the third data set in response to the transmitted electronic data interchange request, determine one or more rules associated with at least one of a manufacturer of a device or a service provider, determine one or more rules associated with a benefit provider, generate a rules engine comprising the one or more rules associated with at least one of the manufacturer or the service provider and the one or more rules associated with the benefit provider that, when enabled, evaluate the third data set based on the first data set and the second data set, run the rules engine to evaluate the third data set using data from at least one of the first data set or the second data set as an input, determine an eligibility status of the user associated with the first data set for at least one of a product or a service provided by at least one of the manufacturer or the service provider based on the evaluation of the third data set by the rules engine, determine a service benefit parameter for the user associated with the first data set based on the evaluation of the third data set by the rules engine, determine an obligation parameter for the user based on the service benefit parameter and the third data set, and display the obligation parameter on the user interface of the user device.
Another embodiment relates to a method comprising collecting a first data set associated with a user by a user interface of a user device, collecting a second data set, generating a new data structure using the first data set and the second data set where the new data structure comprises an electronic data interchange request for a third data set, transmitting the electronic data interchange request to a remote third party computing system, receiving an electronic data interchange response containing the third data set in response to the transmitted electronic data interchange request, determining one or more rules associated with at least one of a manufacturer of a device or a service provider, determining one or more rules associated with a benefit provider, generating a rules engine comprising the one or more rules associated with at least one of the manufacturer or the service provider and the one or more rules associated with the benefit provider that, when enabled, evaluate the third data set based on the first data set and the second data set, running the rules engine to evaluate the third data set using data from at least one of the first data set or the second data set as an input, determining an eligibility status of the user associated with the first data set for at least one of a product or a service provided by at least one of the manufacturer or the service provider based on the evaluation of the third data set by the rules engine, determining a service benefit parameter for the user associated with the first data set based on the evaluation of the third data set by the rules engine, determining an obligation parameter for the user based on the service benefit parameter and the third data set, and displaying the obligation parameter on the user interface of the user device.
Another embodiment relates to a non-transitory computer-readable media comprising computer-readable instructions stored thereon that when executed by a processor cause the processor to collect a first data set, collect a second data set, generate a new data structure using the first data set and the second data set where the new data structure comprises an electronic data interchange request for a third data set, transmit the electronic data interchange request to a remote third party computing system, receive an electronic data interchange response containing the third data set in response to the transmitted electronic data interchange request, determine a service benefit parameter for the user associated with the first data set based on the third data set using a rules engine, identify a plurality of users that share at least one commonality with the user based on the first data set of the user, generate a message based on the service benefit parameter for the user, and provide the message to user devices associated with the plurality of users that share the at least one commonality with the user.
Following below are more detailed descriptions of various concepts related to, and implementations of, methods, apparatuses, and systems for determining an eligibility status of a user for a benefit and an obligation required to be provided by the user in exchange for a service or product provided to the user. The various concepts introduced above and discussed in greater detail below may be implemented in any number of ways, as the concepts described are not limited to any particular manner of implementation. Examples of specific implementations and applications are provided primarily for illustrative purposes.
Referring to the figures generally, various embodiments disclosed herein relate to systems and methods for evaluating user-specific data and determining an eligibility status of a user for a benefit and an obligation required to be provided by the user in exchange for a service or product provided to the user. The providing of an obligation estimation and benefit estimation to a user can be improved by cutting out a middle man (e.g., professionals, administrative staff, etc.) to directly provide the obligation estimation and benefit estimation to the user directly and immediately. A pricing calculator may automatically evaluate user-specific data (including the user's personal information and policy information) to provide an obligation estimation and benefit estimation directly to the user through a computer application (e.g., a webpage, a mobile app, etc.). In some embodiments, the computer application collects information about the user, analyzes the user's information to determine an obligation estimation and a benefit estimation, then provides the obligation estimation and benefit estimation directly to the user.
While it will be appreciated that the systems and method disclosed herein may be used to determine various types of eligibility statuses for receiving various benefits and for determining various obligations for a user, for ease of reference, examples will be provided specifically relating to determining an eligibility of a patient to receive coverage under an insurance policy for a medical service, and an obligation, or cost, owed by the patient for such service.
For example, insurance coverage may be estimated for medical procedures by analyzing a patient's insurance policy, but the estimation is usually not specific to the service being provided. For example, a typical insurance coverage estimator may determine that a patient has dental insurance that covers preventative dental procedures at 100% of the cost, minor procedures at 80% of the cost, and major procedures at 50% of the cost. However, to determine whether a specific service would be considered a “major procedure” or “a minor procedure” requires a healthcare provider to submit a specific procedure code to the insurance company, which then reviews the code and determines what category it falls into before returning the service categorization to the medical provider, who then presents it to a potential patient. This process may take one or more business days to complete using such typical methods. While waiting for such a process to be completed, a patient may become frustrated by not knowing exactly how much the medical procedure may cost and lose interest in receiving the service or medical device or choose a different healthcare professional to provide the service or medical device to them.
The data evaluation system disclosed herein remedies this problem by collecting patient data, sending patient data and a service codes code to an insurance clearing house, retrieving patient insurance policy information, determining the patient's insurance coverage for the medical service, and determining a cost estimation using a pricing calculator. Additionally, patient data collected by the pricing calculator may be used in the backend to effectively market medical services and devices to other similarly situated patients. For example, as disclosed in further detail below, upon determining that a patient is part of an insurance policy that covers orthodontic procedures, other similarly situated patients can be identified and contacted regarding their eligibility for receiving treatment.
As used herein, the term “medical procedure” is intended to include any medical service and/or medical device provided to a patient by a medical professional, such as a doctor, dentist, or orthodontist. The term “provider” may refer to any entity that provides a benefit to a member, such as an insurance provider that provides insurance coverage to its members. The term “medical provider” may refer to a medical professional that provides a medical procedure, and it may also refer to an entity or organization that provides a medical procedure and/or that may be associated with a network of medical professionals, such as a doctors, dentists, orthodontists, dental service organizations, a dental aligner manufacturer, or any other type of medical professional or entity that provides a medical procedure.
Referring now to
In one embodiment, the benefit estimation circuit 18 and the obligation estimation circuit 20 are embodied as machine or computer-readable media storing instructions that are executable by a processor, such as processor 14. As described herein and amongst other uses, the machine-readable media facilitates performance of certain operations to enable reception and transmission of data. For example, the machine-readable media may provide an instruction (e.g., command, etc.) to, e.g., acquire data. In this regard, the machine-readable media may include programmable logic that defines the frequency of acquisition of the data (or, transmission of the data). The computer readable media may include code, which may be written in any programming language including, but not limited to, Java or the like and any conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program code may be executed on one processor or multiple processors. In the latter scenario, the remote processors may be connected to each other through any type of network (e.g., CAN bus, etc.).
In another embodiment, the benefit estimation circuit 18 and the obligation estimation circuit 20 are embodied as hardware units, such as electronic control units. As such, the benefit estimation circuit 18 and the obligation estimation circuit 20 may be embodied as one or more circuitry components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc. In some embodiments, the benefit estimation circuit 18 and the obligation estimation circuit 20 may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOCs) circuits, microcontrollers, etc.), telecommunication circuits, hybrid circuits, and any other types of “circuit.” In this regard, the benefit estimation circuit 18 and the obligation estimation circuit 20 may include any type of component for accomplishing or facilitating achievement of the operations described herein. For example, a circuit as described herein may include one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR, etc.), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and so on). The benefit estimation circuit 18 and the obligation estimation circuit 20 may also include programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like. The benefit estimation circuit 18 and the obligation estimation circuit 20 may include one or more memory devices for storing instructions that are executable by the processor(s) of the benefit estimation circuit 18 and the obligation estimation circuit 20. The one or more memory devices and processor(s) may have the same definition as provided below with respect to the memory 16 and processor 14. In some hardware unit configurations and as described above, the benefit estimation circuit 18 and the obligation estimation circuit 20 may be geographically dispersed throughout separate locations in the pricing calculator 10. Alternatively and as shown, the benefit estimation circuit 18 and the obligation estimation circuit 20 may be embodied in or within a single unit/housing, which is shown as the pricing calculator 10.
In the example shown, the pricing calculator 10 includes the processing circuit 12 having a processor 14 and a memory 16. The processing circuit 12 may be configured to execute or implant the instructions, commands, and/or control processes described herein with respect to the benefit estimation circuit 18 and the obligation estimation circuit 20. The depicted configuration represents the benefit estimation circuit 18 and the obligation estimation circuit 20 as machine or computer-readable media. However, as mentioned above, this illustration is not meant to be limiting as the present disclosure contemplates other embodiments where the benefit estimation circuit 18 and the obligation estimation circuit 20, or at least one circuit of the benefit estimation circuit 18 and the obligation estimation circuit 20, is configured as a hardware unit. All such combinations and variations are intended to fall within the scope of the present disclosure.
The processor 14 may be implemented as one or more processors, one or more application specific integrated circuits (ASIC), one or more field programmable gate arrays (FPGAs), a digital signal processor (DSP), a group of processing components, or other suitable electronic processing components. The one or more processors may be shared by multiple circuits (e.g., the benefit estimation circuit 18 and the obligation estimation circuit 20 may comprise or otherwise share the same processor which, in some example embodiments, may execute instructions stored, or otherwise accessed, via different areas of memory). Alternatively or additionally, the one or more processors may be configured to perform or otherwise execute certain operations independent of one or more co-processors. In other example embodiments, two or more processors may be coupled via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. All such variations are intended to fall within the scope of the present disclosure. The memory 16 (e.g., RAM, ROM, Flash Memory, hard disk storage, etc.) may store data and/or computer code for facilitating the various processes described herein. The memory 16 may be communicably coupled to the processor 14 to provide computer code or instructions to the processor 14 for executing at least some of the processes described herein. Moreover, the memory 16 may be or include tangible, non-transient volatile memory or non-volatile memory. Accordingly, the memory 16 may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described herein.
The benefit estimation circuit 18 is configured to determine the coverage for a specialized medical procedure for a particular user. As shown in
Referring now to
The user interface 100 is configured to collect a user's information at interface portions 112 and 114. In some embodiments, the user interface 100 may include a page description 110 that describes the type of information the webpage is requesting and why the information is requested. For example, user interface 100 includes a description stating that the user may save money through their coverage. In some embodiments, the user may enter their provider at interface portion 112. In some embodiments, the user may enter their email address at interface portion 114. Once the user has entered their information (e.g., user's provider and email), the user can proceed to the second page of the series of user interfaces by selecting the continuation button 116. The second page of the series of user interfaces is described in more detail with respect to
Referring to
Referring to
Referring to
Referring to
Referring to
The user interface 700 is configured to collect a user's information at interface portions 712 and 714. In some embodiments, the user interface 700 may include a page description 710 that describes the type of information the webpage is requesting and why the information is requested. For example, user interface 700 includes a description describing that the user may save money through their coverage. In some embodiments, the user may enter their provider at interface portion 712. In some embodiments, the user may enter their email address at interface portion 714. Once the user has entered their information (e.g., user's provider and email), the user can proceed to the second page of the series of user interfaces by selecting the continuation button 716. The second page of the series of user interfaces is described in more detail with respect to FIG.8.
Referring to
Referring to
Referring to
Referring to
Referring to
Referring now to
At operation 1316, the pricing calculator 10 determines whether the user data has an associated configuration that has been pulled. If the user data does not have a configuration available to be pulled, the user's data is sent to a third party customer handling software 1328 and the process 1300 ends at operation 1336. In some embodiments, the information sent to the third party customer handling software (e.g., such as software provided by Salesforce) may be used for purposes of marketing the medical provider's services. For example, if the medical provider determines that an insurance policy associated with a certain employer covers treatments provided by the medical provider (e.g., dental aligner therapy for straightening teeth), the medical provider may infer that other employees employed by that employer have similar coverage and therefore present targeted advertisements to other employees employed by that employer. The advertisements may further be targeted to similarly situated employees of the employer, such as other employees of the employer of similar age (e.g., the same age, born in the same year, born within 2 years, above or below an age threshold such as 12 years of age or 16 years or age or 18 years of age, or 25 years of age) or other employees of the employer with similar professional titles (e.g. executives, support staff, associates, etc.) because employees at different professional levels may receive different benefits. The advertisements may further be targeted to family members of other employees of the employer, such as children of the employees or spouses or partners of the employees.
In some embodiments, potential user information used to target advertisements may be obtained from data collected on social media sites. For example, employee information including employer and professional title may be obtained from professional social media sites such as Linkedln. Additionally, family member information may be obtained from a variety of social media sites such as Facebook. Social media may also be used to distribute targeted advertisements for potential users. For example, a medical provider may purchase advertisements (e.g., promoted posts, banner advertisements, or any other type of advertisements) on a professional social media site targeting professionals employed by a specific employer. In another example, a medical provider may purchase advertisements on a social media site targeting family members of a certain employee or family members of a certain type of employee (e.g., an employee with the same or a similar level or type of position).
More specifically, data received from social media sites that sell user data (e.g., user name, user age, address, employer, familial status, etc.) to potential advertisers can be used by the medical provider to determine that a particular person works at a particular company that enrolls all their employees in an insurance plan that covers child (e.g., persons 14 years or younger, persons 16 years or younger, persons 18 years or younger) orthodontic procedures at 100% of cost. Further using the user data obtained from a social media site, the medical provider may determine that a particular person has two children under the age of 14. Given this information, the medical provider may create a targeted advertisement configured to inform that particular person that their child's orthodontic treatment may be covered at 100% with the medical provider. Additionally, this targeted advertisement may be displayed to that particular person through the social media site or through another application or website.
In another example, a social media site may also sell user data (e.g., user name, user age, address, employer, familial status, etc.) to potential advertisers. Using this user data, the medical provider may determine that a particular company enrolls all their executive-level employees in an insurance plan that covers all adult orthodontic procedures at 50%. The medical provider may create a targeted advertisement for all executive-level employees for the particular company that lets the employees know that they may qualify for 50% off an orthodontic procedure provided by the medical provider. The medical provider may also distribute this advertisement on the social media site, another social media site, or another website.
If the user data has a configuration available within the database, the process 1300 continues to operation 1318. At operation 1318, the pricing calculator 10 determines if the user's provider is an instant payor. In some embodiments, an instant payor may be defined as a provider that has partnered with medical provider. If the user is determined to not be an instant payor, the user's information is sent to a third party customer handling software 1328 and the process 1300 ends at operation 1336. If the user is determined to be an instant payor, the process 1300 continues to operation 1320.
At operation 1320, the pricing calculator 10 generates an X12 270 request that may be sent to an insurance network in order to determine insurance policy details for a particular user. In some embodiments, the X12 270 request may be defined as electronic data interchange (EDI) transaction in which private and confidential healthcare information for a user may be securely transmitted to an insurance network in order to estimate the coverage a user could have for a medical procedure. The X12 270 request is saved to the S3 database. The S3 database is a file storing database that stores both the X12 270 request generated at operation 1320 and the request response generated at operation 1340 for further review if necessary. For example, if a payor wishes to challenge their insurance coverage (e.g., the user indicates they have coverage for aligner treatment and have lifetime max remaining but they are nonetheless denied coverage), the medical provider may review the payor's X12 270 request and response to confirm the payor's coverage. Once the X12 270 request has been generated, the request is communicated to the insurance network 1324 at operation 1322 via an Application Programming Interface (e.g., via an API configured to handle an X12 EDI data exchange). At operation 1332, the pricing calculator 10 determines whether there has been an error response from the insurance network 1324. If an error is observed at operation 1332, then the pricing calculator 10 sets the X12 271 response to the X12 270 request to be a generic unknown X12 271 before proceeding to operation 1340. If no error response is observed at operation 1332, then the process 1300 continues directly to operation 1340. At operation 1340, the X12 271 response is parsed into an object structure. Typically, when the insurance network 1324 outputs an X12 271 response, it is of a complex format. Therefore, the pricing calculator 10 standardizes the X12 271 response into simpler and/or standardized format at operation 1340.
At operation 1342, the pricing calculator 10 retrieves the aligner purchase information for a particular user. In some embodiments, the aligner purchase information can include the price of the aligner purchase and the procedure code for the aligner purchase. In some embodiments, this purchase may be obtained from a medical provider's network. The medical provider's network may include the medical provider's website and all its related applications and pages. At operation 1344, the pricing calculator 10 determines a specific rules engine to use based on the particular rules associated with an instant payor and/or a medical provider. The rules engine is specific because it is related to a particular payor of a user seeking a particular medical procedure (e.g., a particular aligner purchase) covered by the payor. In some embodiments, the specific rules engine includes rules provided by the insurance policy, the medical services provider, or a combination of both. For example, the insurance policy may include a rule that the insurance network covers orthodontic procedures for minors at 100% and adult orthodontic procedures at only 50%. Additionally, the medical provider may have a rule that they do not provide medical services or procedures to children under a certain age. As another example, the medical provider may have rules regarding the type of insurance plans they accept, whether they accept users without insurance, whether they accept users without orthodontic coverage, whether they accept users with a waiting period in their insurance policy, and ensuring that the user's insurance policy is valid. At operation 1346, the pricing calculator 10 determines if a rules engine has been found. If a rules engine is not found, the user's information is sent to a third party customer handling software 1328 and the process 1300 ends at operation 1336. If a rules engine is found, then the pricing calculator 10 runs the specific rules found in the rules engine at operation 1348. In some embodiments, each rules engine can individually determine which rules to run. This may be accomplished via a plugin system in which specific rules are introduced into the rules engine. The plugin system uses the built in dependency injection system within .NET core software to inject one or more rules class files into the rules engine based on the specific payor. For example, multiple rules class files can be injected into the rules engine to enhance a specific instance of the payor's ability to determine medical coverage for aligners.
Once the rules engine finishes running at operation 1348, the pricing calculator 10 retrieves specific information about the user's coverage at operations 1350-1360. In some embodiments, at operation 1350, the pricing calculator 10 determines the user's deductible from the X12 271 response at operation 1350. At operation 1352, the pricing calculator 10 determines what portion of the user's lifetime max is remaining. At operation 1354, the pricing calculator 10 determines the user's co-insurance percent. At operation 1356, the pricing calculator 10 determines whether the user has already purchased the medical service or procedure. If the user has already purchased the medical service or procedure, then the pricing calculator 10 determines if the purchase was made between the plan dates of when the insurance policy was valid and if the purchase was made with an in-network provider at operations 1358 and 1360 respectively. The process 1300 then ends at operation 1362. If the user has not already purchased the medical service or procedure, then the process proceeds to operation 1362 where process 1300 ends and process 1400 begins.
Referring now to
At operation 1416, the pricing calculator 10 determines whether the user has an active dental insurance policy. If the user does not have an active dental insurance policy, then the pricing calculator 10 determines that the user is out of network and does not have any coverage at operation 1430. Then the pricing calculator 10 sets the lead status as complete at operation 1432 and updates the eligibility aggregate (i.e. the amount of the procedure covered by insurance) at operation 1438. The lead status refers to a state of a potential customer's purchase. For example, once a user indicates that they would be interested in purchasing a service or device (e.g., by clicking get started buttons 108 or 708), the pricing calculator 10 determines that there is a “new lead”. The new lead may have one or more statuses. For example, a new lead status may be “In Progress” which means the new lead is still being processed by the pricing calculator 10. In another example the new status may be “Complete — Pending Discount Code” that refers to a state where the pricing calculator has delivered results to the customer on screen, but requires the manual creation of the actual discount code. In another example the new status may be “Complete — Pending approval” that refers to a state where a discount has been manually created and applied and is pending final review by an inspector. As a final example, the new lead status may be “Complete” that refers to a state where the new lead has been fulfilled and delivered to the customer. In some embodiments, the eligibility aggregate may be saved in a database 1442. In some embodiments, the obligation estimation circuit 20 can pull this eligibility aggregate from the database in order to provide a total cost estimation to a user. In addition to storing the eligibility aggregate to the database 1442, the eligibility aggregate is also sent to a third party customer handling software at operation 1440. If the user does have an active dental policy at operation 1416, then pricing calculator 10 evaluates a number of conditionals at operations 1418-1426. More specifically, the conditional at operation 1418 determines if the user has orthodontic coverage. The conditional at operation 1420 determines if the user has out of network coverage. The conditional at operation 1422 determines how much funds the user has before reaching their lifetime maximum benefit. The conditional at operation 1424 determines if the user is within an appropriate age limit. The conditional at operation 1426 determines if the user is enrolled in a commercial plan. If the pricing calculator 10 determines that any of these conditionals is negative, then the process 1400 proceeds to operation 1430, which is described above.
In another embodiment, the rules engine may have already determined the outcome of one or more conditional statements at operations 1418-1426. In such an embodiment, the process 1400 can be improved to run more efficiently (e.g., faster and consuming less power) by being rearranged so that these conditionals would not be again evaluated, thus saving computer processing power and time. For example, the rules engine may have the age plugin enabled that confirms that the user is already within a certain age limit. Since the user's age has already been confirmed, the computer can save processing time and power by not determining the conditional at operation 1424. In this case, operations 1418-1426 would be replaced with the operations 1418A-1426A shown in
At operation 1500, the pricing calculator 10 determines if the user is verified. If the user is not verified, then the pricing calculator 10 sets the lead status to instant—verify at operation 1499. The verification process may require a medical provider and/or revenue cycle management agent to manually compare the patient's coverage eligibility as determined by the pricing calculator 10. If the user is verified, then the pricing calculator 10 sets the lead status to complete pending discount code at operation 1474. The “complete pending discount code” lead status refers to a state where the pricing calculator 10 has delivered results to the customer on screen, but requires the manual creation of the actual discount code based on the insurance coverage amount and the discount calculated as described above. The discount code may be created by the revenue cycle management agent. In some embodiments, the “complete pending discount code” lead status triggers the creation of the discount, either automatically or by the revenue cycle management agent. Regardless of whether the conditional at operation 1500 is positive or negative, the process 1400 proceeds to the conditional at operation 1476 which determines whether only a discount will be applied to the user's purchase. For example, the user may be eligible for only a discount if the user is in network but does not have any benefit coverage (e.g., the user has dental coverage but not orthodontics coverage). For example, if the status outcome is set to INNCoverageAndDiscountPrePurchase at 1468 or INNCoverageAndDiscountPostPurchase at 1470, the user is eligible for the full discount plus insurance cost. In another example, if the status outcome is set to InNetworkDiscountOnlyPostPurchase at 1472 or InNetworkDiscountOnlyPrePurchase at 1464, then the user is only eligible for the in network discount. If the user is only eligible for a discount, then the pricing calculator sets the user's discount to a non-orthodontic coverage discount. If the user is eligible to more than a discount, then the pricing calculator 10 sets the deductible to the user's deductible at 1480. The process 1400 then proceeds to calculate the total discount for the user at operations 1484 to 1498. At operation 1482, the pricing calculator 10 sets the discount to the network discount. Then at operation 1484, the pricing calculator 10 sets the net product price (NPP) of the medical procedure equal to the gross product price (GPP) minus the in network discount (IND) determined at operation 1482. Then at operation 1486, the pricing calculator 10 sets the net product price less deductible (NPPLD) to equal the NPP minus the deductible. Then at operation 1488, the pricing calculator 10 sets the max coverage (MIC) equal NPPLD multiplied by the co-insurance percent. At operation 1490, the pricing calculator 10 determines if the MIC is greater that the user's lifetime remaining coverage. If the MIC is greater than the user's lifetime remaining coverage, then the pricing calculator 10 sets the coverage with lifetime max (ICWLTM) equal to the user's lifetime remaining coverage at 1492. If the MIC is less than the user's lifetime remaining coverage, then the pricing calculator 10 sets the ICWLTM equal to the MIC at 1494. Then at operation 1496, the pricing calculator 10 sets the customer's out of pocket (COOP) equal to NPP minus ICWLTM. This is the total cost estimation that is provided to the user at interface portion 614 in
As explained above, if the conditional at operation 1408 is negative (i.e., the user has not already purchased the medical procedure) or the conditional at operation 1412 (i.e., the purchase dates fall within the plan dates), then the process 1400 proceeds to operation 1450. At operation 1450, the pricing calculator 10 determines if the user has an active dental policy. If the user does not have an active dental policy, then the process 1400 proceeds to operation 1504 where the pricing calculator 10 sets the user's coverage result to in network, no active dental plan. Then at operation 1502, the pricing calculator 10 sets the user's discount to zero percent and proceeds to operation 1438, which is described in more detail above. If the user does have an active dental insurance policy at operation 1450, the pricing calculator 10 evaluates a number of conditionals at operations 1452-1458. More specifically, the conditional at operation 1452 determines if the user has a commercial plan. The conditional at operation 1454 determines if the user has orthodontic coverage. The conditional at operation 1456 determines how much funds the user has before reaching their lifetime maximum benefit. The conditional at operation 1458 determines if the customer is within an appropriate age limit as determined by the rules engine process shown described with respect to
If no nulls were returned at operations 1452-1458, then the process proceeds to operation 1466 where the pricing calculator 10 determines whether the medical procedure has already been purchased. If the medical procedure has already been purchased, then the process proceeds to set the user's coverage result to in network coverage and discount post purchase at operation 1470. Then the process proceeds to operation 1500, which is explained above. If the medical procedure has not already been purchased, then the process proceeds to set the user's coverage result to in network coverage and discount pre-purchase at operation 1468. Then the process proceeds to operation 1500, which is explained above.
Though the operations detailed above with respect to processes 1300 and 1400 are described in a certain order, these descriptions are only meant to be exemplary. The operations of process 1300 and 1400 may be performed in different orders than they are described herein. Additionally, in some embodiments, one or more of the operations of process 1300 and 1400 may be omitted from being performed in process 1300 and 1400. In some embodiments, one or more processors, such as processor 14, performing process 1300 or 1400 can omit one or more of the operations of process 1300 or 1400, thereby saving computing resources by not expending unnecessary computing resources, and performing the overall process 1300 or 1400 more quickly and efficiently.
The embodiments described herein have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that provide the systems, methods and programs described herein. However, describing the embodiments with drawings should not be construed as imposing on the disclosure any limitations that may be present in the drawings.
It should be understood that no claim element herein is to be construed under the provisions of 35 U.S.C. § 112(f), unless the element is expressly recited using the phrase “means for.”
It is noted that terms such as “approximately,” “substantially,” “about,” or the like may be construed, in various embodiments, to allow for insubstantial or otherwise acceptable deviations from specific values. In various embodiments, deviations of 20 percent may be considered insubstantial deviations, while in certain embodiments, deviations of 15 percent may be considered insubstantial deviations, and in other embodiments, deviations of 10 percent may be considered insubstantial deviations, and in some embodiments, deviations of 5 percent may be considered insubstantial deviations. In various embodiments, deviations may be acceptable when they achieve the intended results or advantages, or are otherwise consistent with the spirit or nature of the embodiments.
Example computing systems and devices may include one or more processing units each with one or more processors, one or more memory units each with one or more memory devices, and one or more system buses that couple various components including memory units to processing units. Each memory device may include non-transient volatile storage media, non-volatile storage media, non-transitory storage media (e.g., one or more volatile and/or non-volatile memories), etc. In some embodiments, the non-volatile media may take the form of ROM, flash memory (e.g., flash memory such as NAND, 3D NAND, NOR, 3D NOR, etc.), EEPROM, MRAM, magnetic storage, hard discs, optical discs, etc. In other embodiments, the volatile storage media may take the form of RAM, TRAM, ZRAM, etc. Combinations of the above are also included within the scope of machine-readable media. In this regard, machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions. Each respective memory device may be operable to maintain or otherwise store information relating to the operations performed by one or more associated modules, units, and/or engines, including processor instructions and related data (e.g., database components, object code components, script components, etc.), in accordance with the example embodiments described herein.
It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. Such variations will depend on the machine-readable media and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure may be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps.
The foregoing description of embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from this disclosure. The embodiments were chosen and described in order to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and arrangement of the embodiments without departing from the scope of the present disclosure as expressed in the appended claims.
