Determining user-specific hyper-parameters for decision support model

Abstract

Systems, devices, and methods are provided for determining user-specific hyper-parameters for a decision support model. In one embodiment, there is provided a non-transitory computer-readable storage medium storing a program that includes instructions that, when executed by at least one processor of a computing device, cause the at least one processor to perform operations that include performing an initial exploration phase; executing a training stage; and performing the exploration-utilization stage by: dividing the users into an exploration subset and a utilization subset; determining at least one optimal hyper-parameter for each user in the utilization subset; determining at least one decision support output for each user in the utilization subset using the at least one optimal hyper-parameter; randomly assigning at least one hyper-parameter to each user in the exploration subset; and determining at least one decision support output for each user in the exploration subset using the at least one randomly assigned hyper-parameter.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit and priority of U.S. Provisional Application No. 63 / 386,352, filed on Dec. 7, 2022, which is assigned to the assignee of the present application and is hereby incorporated herein by reference in its entirety as if fully set forth below and for all applicable purposes. Background Art Technical Field

[0003] The present application generally relates to medical devices (e.g., analyte sensors), and more particularly to systems, devices, and methods for determining hyperparameters to improve patient health outcomes.

[0004] Description of Related Art

[0005] Diabetes is a metabolic disorder related to the body's production or use of insulin. Insulin is a hormone that allows the body to use glucose for energy or store glucose as fat.

[0006] When a person eats a meal containing carbohydrates, the food is processed by the digestive system, which produces glucose in the person's blood. Blood glucose can be used for energy or stored as fat. The body generally maintains blood glucose levels within a range that provides sufficient energy to support bodily functions and avoids problems that may occur when glucose levels are too high or too low. Regulation of blood glucose levels depends on the production and use of insulin, which regulates the movement of glucose into cells.

[0007] When the body does not produce enough insulin, or when the body cannot effectively use the insulin that is present, blood glucose levels may rise above the normal range. A state of having a higher-than-normal blood glucose level is called "hyperglycemia". Chronic hyperglycemia can lead to many health problems, such as cardiovascular disease, cataracts and other eye problems, nerve damage (neuropathy), and kidney damage. Hyperglycemia can also lead to acute problems, such as diabetic ketoacidosis, which is a state in which the body becomes overly acidic due to the presence of blood glucose and ketones produced when the body cannot use glucose. A state of having a lower-than-normal blood glucose level is called "hypoglycemia". Severe hypoglycemia can lead to acute critical conditions, which can cause seizures or death.

[0008] Diabetic patients can receive insulin to control blood glucose levels. For example, insulin can be received by manual injection with a needle. Wearable insulin pumps can also be used to receive insulin. Diet and exercise also affect blood glucose levels.

[0009] Diabetes conditions can be referred to as "type 1" and "type 2". In the presence of insulin, type 1 diabetes patients can usually use insulin, but due to problems with the insulin-producing beta cells in the pancreas, the body cannot produce sufficient amounts of insulin. Type 2 diabetes patients may produce some insulin, but there is "insulin resistance" due to the reduced sensitivity of the patients to insulin. As a result, even when insulin is present in the body, it cannot be used effectively by the patients' bodies to regulate blood sugar levels adequately.

[0010] This background is provided to introduce a brief context for the following detailed description and specific embodiments of the invention. This background is not intended to assist in determining the scope of the claimed subject matter, nor is it to be considered as limiting the claimed subject matter to specific embodiments that solve any or all of the disadvantages or problems presented above. Detailed Description of the Invention

[0011] Various embodiments of the inventive system, apparatus, and method for determining user-specific hyperparameters for a decision support model to improve patient health outcomes include several features, none of which alone is responsible for their desired properties. Without limiting the scope of this embodiment, its more prominent features will now be discussed below. After considering this discussion, and particularly after reading the section entitled "Detailed Description", the features of the inventive embodiments will be understood as to how they provide the advantages described herein.

[0012] In a first aspect, there is provided a non-transitory computer-readable storage medium storing a program including instructions that, when executed by at least one processor of a computing device, cause the at least one processor to perform operations including: performing an initial exploration phase by: randomly assigning at least one hyperparameter to each of a plurality of users; performing a training phase by: analyzing training data, where the training data includes context data and values associated with the randomly assigned at least one hyperparameter; and determining a relationship between the context data and the values associated with the randomly assigned at least one hyperparameter; and performing an exploration-exploitation phase by: dividing the plurality of users into a user exploration subset and a user exploitation subset; determining at least one optimal hyperparameter for each user in the user exploitation subset; using the at least one optimal hyperparameter to determine at least one decision support output for each user in the user exploitation subset; randomly assigning at least one hyperparameter to each user in the user exploration subset; and using the randomly assigned at least one hyperparameter to determine at least one decision support output for each user in the user exploration subset.

[0013] In an embodiment of the first aspect, the initial exploration phase is further performed by: using at least one randomly assigned hyperparameter to determine a decision support output for each user among a plurality of users; providing the decision support output to each user among the plurality of users; and receiving monitoring data for each user among the plurality of users, where the monitoring data provides information about at least one physiological condition.

[0014] In another embodiment of the first aspect, the training data further includes monitoring data, and the training phase is further performed by determining the relationship between the monitoring data, the context data, and the value associated with at least one randomly assigned hyperparameter.

[0015] In another embodiment of the first aspect, at least one optimal hyperparameter for each user in the utilization subset is determined by: assigning a plurality of experimental hyperparameters to each user in the utilization subset; determining at least one prediction result for each experimental hyperparameter among the plurality of experimental hyperparameters; determining a scalarized result for each experimental hyperparameter among the plurality of experimental hyperparameters; and determining at least one optimal hyperparameter based on the scalarized result.

[0016] In another embodiment of the first aspect, the operation further includes: performing a retraining phase by: analyzing the training data, where the training data includes context data, the value associated with the randomly assigned hyperparameters of the user exploration subset, and the monitoring data for the user exploration subset; and determining the relationship between the context data, the value associated with at least one randomly assigned hyperparameter of the user exploration subset, and the monitoring data for the user exploration subset.

[0017] In another embodiment of the first aspect, the exploration-exploitation phase is performed using a contextual multi-armed bandit algorithm.

[0018] In another embodiment of the first aspect, a policy assignment algorithm is used to determine at least one prediction result.

[0019] In a second aspect, a method for determining user-specific hyperparameters for a decision support model is provided, the method comprising: performing an initial exploration phase by: randomly assigning at least one hyperparameter to each of a plurality of users; performing a training phase by: analyzing training data, wherein the training data includes context data and values associated with the randomly assigned at least one hyperparameter; and determining a relationship between the context data and the values associated with the randomly assigned at least one hyperparameter; and performing an exploration-exploitation phase by: dividing the plurality of users into a user exploration subset and a user exploitation subset; determining at least one optimal hyperparameter for each user in the user exploitation subset; using the at least one optimal hyperparameter to determine at least one decision support output for each user in the user exploitation subset; randomly assigning at least one hyperparameter to each user in the user exploration subset; and using the randomly assigned at least one hyperparameter to determine at least one decision support output for each user in the user exploration subset.

[0020] In an implementation of the second aspect, the initial exploration phase is further performed by: using the randomly assigned at least one hyperparameter to determine a decision support output for each of the plurality of users; providing the decision support output to each of the plurality of users; and receiving monitoring data for each of the plurality of users, wherein the monitoring data provides information about at least one physiological condition.

[0021] In another implementation of the second aspect, the training data further includes monitoring data, and the training phase is further performed by determining a relationship between the monitoring data, the context data, and the values associated with the randomly assigned at least one hyperparameter.

[0022] In another implementation of the second aspect, at least one optimal hyperparameter for each user in the user exploitation subset is determined by: assigning a plurality of experimental hyperparameters to each user in the exploitation subset; determining at least one prediction result for each of the plurality of experimental hyperparameters; determining a scalarization result for each of the plurality of experimental hyperparameters; and determining at least one optimal hyperparameter based on the scalarization result.

[0023] In another implementation of the second aspect, the method further comprises: performing a retraining phase by: analyzing training data, wherein the training data includes context data, values associated with the randomly assigned hyperparameters of the user exploration subset, and monitoring data for the user exploration subset; and determining a relationship between the context data, the values associated with the randomly assigned at least one hyperparameter of the user exploration subset, and the monitoring data for the user exploration subset.

[0024] In another embodiment of the second aspect, a contextual multi-armed bandit algorithm is used to perform the exploration-exploitation phase.

[0025] In another embodiment of the second aspect, a policy assignment algorithm is used to perform the training phase.

[0026] In a third aspect, there is provided a computing device for determining user-specific hyperparameters for a decision support model, the computing device comprising: a network interface; a processor operatively connected to the network interface; a memory storing a program comprising instructions which, when executed by the processor, cause the computing device to: perform an initial exploration phase by: randomly assigning at least one hyperparameter to each of a plurality of users; perform a training phase by: analyzing training data, wherein the training data includes context data and values associated with the randomly assigned at least one hyperparameter; and determining a relationship between the context data and the values associated with the randomly assigned at least one hyperparameter; and perform an exploration-exploitation phase by: dividing the plurality of users into a user exploration subset and a user exploitation subset; determining at least one optimal hyperparameter for each user in the user exploitation subset; using the at least one optimal hyperparameter to determine at least one decision support output for each user in the user exploitation subset; randomly assigning at least one hyperparameter to each user in the user exploration subset; and using the randomly assigned at least one hyperparameter to determine at least one decision support output for each user in the user exploration subset.

[0027] In an embodiment of the third aspect, the initial exploration phase is further performed by: using the randomly assigned at least one hyperparameter, using the decision support model to determine a decision support output for each of the plurality of users; providing the decision support output to each of the plurality of users; and receiving monitoring data for each of the plurality of users, wherein the monitoring data provides information about at least one physiological condition.

[0028] In another embodiment of the third aspect, the training data further includes monitoring data, and the training phase is further performed by determining a relationship between the monitoring data, the context data, and the values associated with the randomly assigned at least one hyperparameter.

[0029] In another embodiment of the third aspect, the at least one optimal hyperparameter for each user in the user exploitation subset is determined by: assigning a plurality of experimental hyperparameters to each user in the exploitation subset; determining at least one prediction result for each of the plurality of experimental hyperparameters; determining a scalarized result for each of the plurality of experimental hyperparameters; and determining the at least one optimal hyperparameter based on the scalarized result.

[0030] In another implementation of the third aspect, the computing device is further configured to perform a retraining phase by: analyzing training data, where the training data includes context data, values associated with randomly assigned hyperparameters of a user exploration subset, and monitoring data of the user exploration subset; and determining relationships between the context data, the values associated with at least one randomly assigned hyperparameter of the user exploration subset, and the monitoring data of the user exploration subset.

[0031] In another implementation of the third aspect, a contextual multi-armed bandit algorithm is used to perform the exploration-exploitation phase. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1A Illustrates an example health monitoring and support system in accordance with certain embodiments of the present disclosure.

[0033] Figure 1B Illustrates a continuous analyte monitoring system in accordance with certain embodiments of the present disclosure.

[0034] Figure 2 Illustrates example inputs and example metrics generated based on the inputs in accordance with certain embodiments of the present disclosure.

[0035] Figure 3 Is a flowchart illustrating a process for determining a decision support output based on user-specific hyperparameters in accordance with certain embodiments of the present disclosure.

[0036] Figure 4 Is a flowchart illustrating a process for performing an initial exploration phase of a process for Figure 3 in accordance with certain embodiments of the present disclosure.

[0037] Figure 5 Is a flowchart illustrating a process for performing a training phase of a process for Figure 3 in accordance with certain embodiments of the present disclosure.

[0038] Figure 6 Is a flowchart illustrating a process for performing an exploration-exploitation phase of a process for Figure 3 in accordance with certain embodiments of the present disclosure.

[0039] Figure 7 Is a flowchart illustrating a process for determining a decision support output for a user exploitation subset in accordance with certain embodiments of the present disclosure.

[0040] Figure 8 Is a flowchart illustrating a process for determining a decision support output for a user exploration subset in accordance with certain embodiments of the present disclosure.

[0041] Figure 9is a flowchart illustrating an exemplary operational process for determining a decision support output based on user-specific hyperparameters in accordance with certain embodiments of the present disclosure.

[0042] Figure 10 is a block diagram depicting a computing device configured to determine user-specific hyperparameters for use with a decision support model in accordance with certain embodiments of the present disclosure. DETAILED DESCRIPTION

[0043] Portable and / or wearable health monitoring devices (also referred to herein as “health monitoring devices”) and mobile health applications (also referred to herein as “applications”) have rapidly gained popularity due to their ability to support user-centered care. For example, the management of diabetes can pose complex challenges to patients, clinicians, and caregivers because the convergence of many factors can affect a patient's glucose levels and glucose trends. To help patients better manage this condition, health monitoring devices (e.g., sensors and other types of monitoring and diagnostic devices) and various mobile health applications (e.g., diabetes intervention software applications) have been developed. In the healthcare field, the widespread adoption of health monitoring devices and the increased development and distribution of mobile health applications have improved health management, and more specifically, chronic disease management. In particular, the use of mobile health applications in conjunction with these health monitoring devices represents a more scalable and potentially more cost-effective alternative to traditional interventions, thus providing a means to improve health and chronic disease management by expanding the reach of healthcare services and improving users' access to health-related information and interventions.

[0044] Mobile health applications enable users to participate more in their own medical care by authorizing users to access and control their health information. In particular, mobile health applications enable users to access, monitor, record and update their health information without being limited by physical constraints such as time and location. In particular, a variety of intervention applications have been developed to deliver guidance, which can assist patients, caregivers, health care providers or other users to improve lifestyles or clinical / patient outcomes by meeting a variety of challenges (such as analyte control, exercise and / or other health factors). As used herein, the term "analyte" refers to, but is not limited to, substances or chemical components in a body or biological sample. For example, a diabetes intervention application can assist patients, caregivers, health care providers or other users in nighttime glucose control (e.g., reducing the incidence of hypoglycemic events or hyperglycemic fluctuations), intraprandial and postprandial glucose control (e.g., using historical information and trends to strengthen blood sugar control), hyperglycemia correction (e.g., increasing the time in the target area while avoiding hypoglycemic events caused by overcorrection), and / or hypoglycemia treatment (e.g., solving hypoglycemia while avoiding "rebound" hyperglycemia).

[0045] Mobile health applications can provide such help to users in the form of some form of guidance. For example, guidance may include a graphical summary of user data over time or a mobile notification to the user, wherein a notification is provided to inform, warn and / or recommend a certain action to the user. As an example, the application can help the user respond to health conditions in real time by predicting events or trends, and provide treatment suggestions to solve ongoing or potential events or trends in real time. This type of calculated guidance and support can reduce the cognitive burden of the user. Some mobile health applications may also allow data to be output in various formats to share with third parties and / or enable users to directly contact health care professionals to obtain feedback, which can help improve patient-professional dialogue. Therefore, if utilized, mobile health applications can improve the quality of care while providing the potential to reduce the cost of the health care system.

[0046] Health monitoring devices enable real-time sensing and analysis of human physiological information for medical monitoring of various diseases and conditions, non-invasive medical care and management of various therapies and drugs, and mobile health and hygiene monitoring. Portability is a core feature of these health monitoring devices. Therefore, with continuous utilization, these devices can provide many benefits, including improved information access, reduced medical errors, improved quality of care, etc.

[0047] To be an effective support tool, it may be desirable for a health monitoring device and / or application to continuously or frequently attract a user's attention and stimulate the user's interest to actively engage with the device and / or application. Engagement indicates the degree of interaction of a user with technology (e.g., a device and / or application). Since health technologies (including health monitoring devices and mobile health applications) are voluntary use systems, the degree of user engagement with these technologies is typically determined by the quality of experience perceived by the user, the continuing benefits of use, and / or the consideration of viable alternatives to using the technology.

[0048] As discussed herein, unfortunately, health monitoring systems (including health monitoring devices and / or mobile health applications) designed to support the management of chronic diseases or health conditions have suffered from low user engagement and high user dropout rates. Reasons for low user engagement and / or high user dropout rates can include the failure of health monitoring systems to provide individualized or personalized decision support outputs (e.g., information, recommendations, warnings, etc.). When a mobile health application fails to provide individualized and / or personalized decision support outputs, users of the application may find the outputs ineffective and that they cannot take a holistic approach to managing their health (e.g., diseases, conditions, fitness, etc.). In addition, decision support outputs that are not customized for an individual (i.e., not "individualized") may lead to sub-optimal health outcomes. In addition, decision support outputs that are not customized for a cohort to which an individual is a member (i.e., not "personalized") may also lead to sub-optimal health outcomes. As used herein, a "cohort" can be a set of "similar" users having similar demographics, health histories, and / or other characteristics that affect outcomes. Accordingly, user engagement associated with such mobile health applications can be reduced, and thus the user dropout rate can increase.

[0049] As noted above, a user (also referred to herein as a "patient") may utilize one or more health monitoring devices, such as but not limited to one or more analyte sensors configured to report sensor outputs describing the physiological condition of the monitored user. The user may then use a software application configured to execute on the user's display device to receive the sensor outputs. In some embodiments, the application may utilize one or more decision support models to provide a decision support output to the user based on the sensor outputs. For example, the decision support output may describe an action recommended for the user to perform (e.g., a recommended sleep pattern for the user) or a warning regarding a predicted future physiological condition of the user (e.g., a warning that the user may experience hyperglycemia within the next eight hours).

[0050] A decision support model can be a user - oriented algorithm that determines a decision support output for a user based on sensor outputs associated with the user. In some embodiments, the decision support model can include a scoring sub - model and a decision - making sub - model. The scoring sub - model can be configured to determine one or more risk scores for the user, where each risk score describes the predicted likelihood that the user will experience a particular condition (e.g., hyperglycemia or hypoglycemia) within a future time period (e.g., within the next eight hours). The scoring sub - model can be a trained machine - learning model characterized by one or more training parameters. The decision - making sub - model can be configured to select a decision support output for the user from a set of potential decision support outputs based on the risk scores for the user.

[0051] The decision - making sub - model can be characterized by one or more hyperparameters that define thresholds / conditions for one or more of the risk scores. Each potential decision support output is associated with a corresponding subset of the thresholds / conditions defined by the hyperparameters of the decision - making sub - model. If the risk score of the user meets the thresholds / conditions associated with the potential decision support output, the decision - making sub - model selects the potential decision support output to provide to the user.

[0052] An example of a decision support model is a sleep advisor model that is configured to select a recommended sleep pattern for a user from a set of potential sleep patterns. In some embodiments, the scoring sub - model of the sleep advisor model is configured to determine at least one of a hyperglycemia risk score or a hypoglycemia risk score for the user based on sensor outputs associated with the user, where the hyperglycemia risk score describes the predicted likelihood that the user will experience hyperglycemia within a future time period (e.g., within the next eight hours), and the hypoglycemia risk score describes the predicted likelihood that the user will experience hypoglycemia within a future time period.

[0053] The decision - making sub - model of the sleep advisor model is characterized by a set of hyperparameters that define two thresholds for each potential sleep pattern in the set of potential sleep patterns: a hyperglycemia risk threshold and a hypoglycemia risk threshold. For example, the set of potential sleep patterns can include an 8 - hour sleep pattern and a 10 - hour sleep pattern. In this example, if the hyperglycemia risk score for the user meets a first threshold and the hypoglycemia risk score for the user meets a second threshold, the 8 - hour sleep pattern can be recommended to the user, while if the hyperglycemia risk score for the user meets a third threshold and the hypoglycemia risk score for the user meets a fourth threshold, the 10 - hour sleep pattern can be recommended to the user. These four thresholds can be defined by the hyperparameters of the decision - making sub - model of the sleep advisor model.

[0054] Another example of a decision support model is a hyperglycemic warning model that is configured to warn a user when the hyperglycemic warning model determines that the user is at risk of hyperglycemia during a future time period. In this example, the scoring sub-model of the hyperglycemic warning model is configured to determine a hyperglycemia risk score for the user based on sensor outputs associated with the user, and the decision sub-model of the hyperglycemic warning model is configured to determine that a hyperglycemic warning should be presented to the user when the hyperglycemia risk score for the user meets (e.g., is above) a hyperglycemia risk threshold.

[0055] In this example, the hyperglycemia risk threshold is an example of the only hyperparameter of the decision sub-model, and the two potential decision support outputs of the hyperglycemic warning model include a "warning" output and a "no warning" output, where the "warning" output is configured to cause the hyperglycemic warning to be presented to the user, and the "no warning" output is configured to prevent the hyperglycemic warning from being presented to the user. In another variant, if the risk of nocturnal hypoglycemia (or hyperglycemia) is predicted, the decision support output can be a bedtime carbohydrate consumption (or exercise / insulin) recommendation. These recommendations can have additional hyperparameters (above the risk threshold) related to the type / amount of the recommended carbohydrate consumption (or recommended exercise / insulin).

[0056] As illustrated by the above examples, a decision support model can be associated with a set of training parameters and a set of tunable / selectable hyperparameters. The above examples further illustrate that a decision support model can have any number of hyperparameters, and the number of hyperparameters of the decision support model can vary with the number of risk scores determined by the scoring sub-model of the decision support model for a user and the number of potential decision support outputs that can be assigned to the user by the decision sub-model of the decision support model.

[0057] Selecting user-specific hyperparameters (also referred to herein as "optimal hyperparameters") for a decision support model is important for ensuring that the decision support output recommended by the model effectively responds to the needs of the user. In the absence of optimal hyperparameters, the decision support output recommended by the decision support model fails to take into account the individualized or personalized needs of the user determined based on the user's health journey and the user's demographic characteristics. As described above, providing invalid decision support outputs to users leads to higher user churn rates from health-related applications, which enable monitoring of the user's physiological conditions to support better health status management for the user. Therefore, many existing health-related applications suffer from high user churn rates and low user engagement rates due to the inability to provide individualized or personalized decision support outputs. In this context, individualization refers to determining a decision support output by a decision support model whose hyperparameters have been optimized for the condition of an individual user, while personalization refers to providing a decision support output by a decision support model whose hyperparameters have been optimized for the condition of a user cohort (e.g., based on one or more demographic criteria, such as a user cohort determined based on age).

[0058] Therefore, the embodiments herein provide a decision support model whose hyperparameters have been specifically determined for a user, thereby allowing a decision support output to be specific and effective for the user. In other words, given a set of users, the decision support model uses different sets of hyperparameters to determine the decision support output for the user, so that the decision support output for each user is determined according to the hyperparameters that are specifically assigned to the user and may be different from the hyperparameters assigned to other users. A multi-objective contextual multi-armed bandit (CMAB) algorithm can be used to perform determination of user-specific hyperparameters and assign them to the user, as further described below.

[0059] Multi-objective CMAB methods can provide various benefits, including but not limited to allowing a decision support model to optimize and assign hyperparameters for a user as effectively as possible. For example, multi-objective CMAB methods avoid having to "test" many different hyperparameter values for each user to see what works best. Instead, multi-objective CMAB methods involve training an algorithm to learn the relationship between user characteristics and the optimal hyperparameter values that result in optimal outcomes for the user. In some embodiments, the multi-objective CMAB algorithm assigns one or more hyperparameters to a user in a manner designed to: (i) maximize the likelihood that the decision support output generated based on the assigned hyperparameters results in two or more outcomes / goals of interest (e.g., a first outcome / goal of preventing the user from having a glucose level below an optimal glucose range and a second outcome / goal of preventing the user from having a glucose level above the optimal glucose range), and (ii) explore new values for the hyperparameters while leveraging the already detected relationship between the hyperparameters and the two or more outcomes / goals of interest.

[0060] The systems, devices, and methods of the embodiments described herein can be used in combination with any type of analyte sensor for any measurable analyte. Additionally, the systems, devices, and methods of the embodiments described herein can be used in combination with any health-related application provided to a user to improve the user's health. For example, a health-related application can help a user treat a disease or simply help improve the health of a user who is not necessarily diagnosed with a disease.

[0061] Example System with a Decision Support Engine for Determining Decision Support Output Based on User - Specific Hyperparameters

[0062] Figure 1A An example health monitoring and support system in accordance with certain embodiments of the present disclosure is illustrated. The health monitoring and support system 100 can be used to monitor a user's health, determine user-specific hyperparameters for a decision support model, and provide a decision support output to a user associated with the system 100. Each user of the system 100, such as user 102, can interact with a mobile health application, such as mobile health application ("app") 106 (e.g., a diabetes intervention app that provides decision support guidance) and / or a health monitoring device, such as analyte monitoring system 104 (e.g., a glucose monitoring system). In some embodiments, user 102 can be a patient or, in some cases, a caregiver of a patient. In the embodiments described herein, for simplicity only, it is assumed that the user is a patient, but this is not limiting. As shown, the system 100 can include an analyte monitoring system 104, a mobile device 107 that executes the app 106, a decision support engine 112 (including a data analysis module (DAM) 111), and a user database 110.

[0063] The analyte monitoring system 104 can be configured to generate, for example, on a continuous basis, analyte measurements for the user 102 and transmit these analyte measurements to the mobile device 107 for use by the application 106. In some embodiments, the analyte monitoring system 104 can transmit the analyte measurements to the mobile device 107 via a wireless connection (e.g., a Bluetooth connection). In certain embodiments, the mobile device 107 is a smart phone. However, in certain embodiments, the mobile device 107 can alternatively be any other type of computing device, such as a laptop computer, a smart watch, a tablet computer, or any other computing device capable of executing the application 106.

[0064] Note that while in some examples it is assumed that the analyte monitoring system 104 is a glucose monitoring system, the analyte monitoring system 104 is operable to monitor one or more additional or alternative analytes. As discussed, as used herein, the term "analyte" is a broad term and should be given its ordinary and customary meaning to one of ordinary skill in the art (and is not limited to a special or customized meaning), and without limitation refers to a substance or chemical component in a bodily or biological sample (e.g., a body fluid, including blood, serum, plasma, interstitial fluid, cerebrospinal fluid, lymph fluid, ocular fluid, saliva, oral fluid, urine, excrement, or exudate). Analytes can include naturally occurring substances, man-made substances, metabolites, and / or reaction products. In some embodiments, the analytes measured by the sensing regions, devices, and methods are albumin, alkaline phosphatase, alanine transaminase, aspartate transaminase, bilirubin, blood urea nitrogen, calcium, CO2, chloride, creatinine, glucose, gamma-glutamyl transpeptidase, hematocrit, lactate, lactate dehydrogenase, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, uric acid, metabolic markers, and drugs.

[0065] Other analytes are also contemplated, including but not limited to acetaminophen, dopamine, ephedrine, terbutaline, ascorbate, uric acid, oxygen, d-amino acid oxidase, plasma amine oxidase, xanthine oxidase, NADPH oxidase, alcohol oxidase, alcohol dehydrogenase, pyruvate dehydrogenase, diols, Ros, NO, bilirubin, cholesterol, triglycerides, gentisic acid, ibuprofen, L-dopa, methyldopa, salicylate, tetracycline, tolazamide, tolbutamide, carboxyprothrombin; acylcarnitine; adenine phosphoribosyltransferase; adenosine deaminase; albumin; alpha-fetoprotein; amino acid profile (arginine (Krebs cycle), histidine / urocanic acid, homocysteine, phenylalanine / tyrosine, tryptophan); androstenedione; antipyrine; arabinitol enantiomers; arginase; benzoylecgonine (cocaine); biotinidase; biopterin; c-reactive protein; carnitine; carnosinase; CD4; ceruloplasmin; chenodeoxycholic acid; chloroquine; cholesterol; cholinesterase; conjugated 1-beta-hydroxy-cholic acid; cortisol; creatine kinase; creatine kinase MM isoenzyme; cyclosporine A; d-penicillamine; deethylchloroquine; dehydroepiandrosterone sulfate; DNA (acetylase polymorphism, alcohol dehydrogenase, alpha1-antitrypsin, cystic fibrosis, Duchenne muscular dystrophy / Becker muscular dystrophy, glucose-6-phosphate dehydrogenase, hemoglobin A, hemoglobin S, hemoglobin C, hemoglobin D, hemoglobin E, hemoglobin F, D-Punjab, beta-thalassemia, hepatitis B virus, HCMV, HIV-1, HTLV-1, Leber hereditary optic neuropathy, MCAD, RNA, PKU, Plasmodium vivax, sex differentiation, 21-deoxycortisol); desbutylhalofantrine; dihydropteridine reductase; diphtheria / tetanus antitoxin; erythrocyte arginase; erythrocyte protoporphyrin; esterase D; fatty acid / acylglycine; free beta-human chorionic gonadotropin; free erythrocyte protoporphyrin; free thyroxine (FT4); free triiodothyronine (FT3); fumarylacetoacetase; galactose / gal-1-phosphate; galactose-1-phosphate uridyltransferase; gentamicin; glucose-6-phosphate dehydrogenase; glutathione; glutathione peroxidase; glycocholic acid; glycosylated hemoglobin; halofantrine; hemoglobin variants; hexosaminidase A; human erythrocyte carbonic anhydrase I; 17-alpha-hydroxyprogesterone; hypoxanthine phosphoribosyltransferase; immunoreactive trypsin; lactate; lead; lipoprotein ((a), B / A-1, beta); lysozyme; mefloquine; netilmicin; phenobarbital; phenytoin; phytanic acid / pristanic acid; progesterone; prolactin; prolinase; purine nucleoside phosphorylase; quinine; reverse triiodothyronine (rT3); selenium; serum pancreatic lipase; sisomicin; somatomedin C;Specific antibodies (adenovirus, antinuclear antibody, anti-zeta antibody, arbovirus, Omsk hemorrhagic fever virus, dengue virus, Dracunculus medinensis, Echinococcus granulosus, Entamoeba histolytica, enterovirus, Giardia, Helicobacter pylori, hepatitis B virus, herpes virus, HIV-1, IgE (atopic diseases), influenza virus, Leishmania donovani, Leptospira, measles / mumps / rubella, Mycobacterium leprae, Mycoplasma pneumoniae, myoglobin, Onchocerca volvulus, parainfluenza virus, Plasmodium falciparum, poliovirus, Pseudomonas aeruginosa, respiratory syncytial virus, Rickettsia (scrub typhus), Schistosoma mansoni, Toxoplasma gondii, Treponema pallidum, Trypanosoma cruzi / Trypanosoma rangeli, vesicular stomatitis virus, Wuchereria bancrofti, yellow fever virus); specific antigens (hepatitis B virus, HIV-1); succinylacetone; sulfadoxine; theophylline; thyroid stimulating hormone (TSH); thyroxine (T4); thyroxine binding globulin; trace elements; transferrin; UDP-galactose-4-epimerase; urea; uroporphyrinogen I synthase; vitamin A; white blood cells; and zinc protoporphyrin. In certain embodiments, salts, sugars, proteins, fats, vitamins, and hormones that are naturally present in blood or interstitial fluid can also constitute analytes.;

[0066] An analyte can be naturally present in a biological fluid, e.g., metabolites, hormones, antigens, antibodies, etc. Alternatively, an analyte can be introduced into the body, e.g., a contrast agent for imaging, a radioisotope, a chemical reagent, a perfluorocarbon-based synthetic blood, or a drug or pharmaceutical composition, including but not limited to insulin; ethanol; cannabis (marijuana, tetrahydrocannabinol, hashish); inhalants (nitrous oxide, amyl nitrite, butyl nitrite, chlorinated hydrocarbons, hydrocarbons); cocaine (crack cocaine); stimulants (amphetamine, methamphetamine, Ritalin, Cylert, Preludin, Didrex, PreState, Voranil, Sandrex, Plegine); sedatives (barbiturates, methaqualone, tranquilizers such as Valium, Librium, Miltown, Serax, carbutamide, potassium clorazepate); hallucinogens (phencyclidine, lysergic acid, mescaline, peyote, psilocybin); narcotics (heroin, codeine, morphine, opium, meperidine, Percocet, Percodan, Tussionex, fentanyl, Darvon, pentazocine, Lomotil); designer drugs (analogs of fentanyl, meperidine, amphetamine, methamphetamine, and phencyclidine, e.g., ecstasy); anabolic steroids; and nicotine. Metabolites of drugs and pharmaceutical compositions are also contemplated analytes. Analytes such as neurochemicals and other chemicals produced in the body can also be analyzed, e.g., ascorbic acid, uric acid, dopamine, norepinephrine, 3-methoxytyramine (3MT), 3,4-dihydroxyphenylacetic acid (DOPAC), homovanillic acid (HVA), serotonin (5HT), histamine, advanced glycation end products (AGEs), and 5-hydroxyindoleacetic acid (5HIAA).

[0067] The application 106 can be a mobile health application configured to receive and analyze analyte measurements from the analyte monitoring system 104. In some embodiments, the application 106 can transmit the analyte measurements received from the analyte monitoring system 104 to the user database 110 (and / or the decision support engine 112), and the user database (and / or the decision support engine 112) can store the analyte measurements in the user profile 118 of the user 102 for processing and analysis and for the decision support engine 112 to determine user-specific hyperparameters for the decision support model, and provide one or more decision support outputs to the user 102 via the application 106, such as but not limited to recommendations and / or guidance. In some embodiments, the application 106 can locally store the analyte measurements in the user profile 118 of the user 102 for processing and analysis and for the decision support engine 112 to determine user-specific hyperparameters for the decision support model, and provide decision support outputs to the user 102, such as but not limited to recommendations and / or guidance.

[0068] In certain embodiments, the decision support engine 112 refers to a collection of software instructions having one or more software modules, the one or more software modules including a data analysis module (DAM) 111. In some embodiments, the decision support engine 112 executes entirely on one or more computing devices in a private cloud or a public cloud. In some other embodiments, the decision support engine 112 executes partially on one or more local devices such as the mobile device 107 and partially on one or more computing devices in a private cloud or a public cloud. In some other embodiments, the decision support engine 112 executes entirely on one or more local devices such as the mobile device 107.

[0069] As discussed in more detail herein, the decision support engine 112 can determine user-specific hyperparameters for the decision support model and provide a decision support output (e.g., decision support recommendations, etc.) to the user 102 via the application 106. For example, the decision support engine 112 can determine user-specific hyperparameters for the decision support model by performing an initial exploration phase, a training phase, and an exploration-exploitation phase, as further described below. In some embodiments, the decision support engine 112 can determine user-specific hyperparameters for the decision support model based on information including but not limited to information included in the user profile 118 stored in the user database 110. In some embodiments, the user profile 118 can include information about the user collected from the application 106, as further described below.

[0070] In certain embodiments, the DAM 111 of the decision support engine 112 can be configured to receive and / or process a collection of inputs 127 (described in more detail below) (also referred to herein as “input data”) to determine one or more metrics 130 (also referred to herein as “metric data”), the one or more metrics which can then be used by the decision support engine 112 to determine user-specific hyperparameters for the decision support model. The inputs 127 can be stored in the user profile 118 in the user database 110. The DAM 111 can extract the inputs 127 from the user database 110 and calculate a plurality of metrics 130, which can then be stored as application data 126 in the user profile 118. Such metrics 130 can include health-related metrics.

[0071] In some embodiments, application 106 is configured to take information related to user 102 as input and store such information in user profile 118 of user 102 in user database 110. For example, application 106 may obtain demographic information 119, disease progression information 121, and / or medication information 122 of user 102 and record such information in user profile 118. In some embodiments, demographic information 119 may include one or more of the user's age, body mass index (BMI), race, gender, etc. In some embodiments, disease progression information 121 may include information about the disease of user 102, such as for diabetes, whether the user is type I, type II, pre-diabetic, or whether the user has gestational diabetes. In some embodiments, disease progression information 121 further includes the duration since diagnosis, the degree of disease control, the compliance with disease management treatment, the predicted pancreatic function, other types of diagnoses (e.g., heart disease, obesity), or health metrics (e.g., heart rate, exercise, stress, sleep, etc.). In some embodiments, medication regimen information 122 may include information about the medications taken by user 102, such as the amount and type of insulin or non-insulin diabetes medications and / or non-diabetes medications taken by user 102.

[0072] In some embodiments, application 106 may obtain demographic information 119, disease progression information 121, and / or medication information 122 from user 102 or from other sources in the form of user input. In some embodiments, when some of such information changes, application 106 may receive updates from user 102 or from other sources. In some embodiments, user profile 118 associated with user 102 and other user profiles associated with other users are stored in user database 110, which can be accessed by application 106 and decision support engine 112 through one or more networks (not shown). In some embodiments, application 106 collects input 127 through user 102 input and / or multiple other sources, which include analyte monitoring system 104, other applications running on mobile device 107, and / or one or more other sensors and devices. In some embodiments, such sensors and devices include, but are not limited to, one or more of the following: insulin pumps, other types of analyte sensors, sensors or devices provided by mobile device 107 (e.g., accelerometer, camera, global positioning system (GPS), heart rate monitor, etc.), or other user accessories (e.g., smartwatch), or any other sensors or devices that provide relevant information about user 102. In some embodiments, user profile 118 further stores application configuration information indicating the current configuration of application 106 (including its features and settings).

[0073] In some embodiments, the user database 110 refers to a storage server that can operate in a public cloud or a private cloud. The user database 110 can be implemented as any type of data storage, such as a relational database, a non-relational database, a key-value data store, a file system including a hierarchical file system, etc. In some exemplary embodiments, the user database 110 is distributed. For example, the user database 110 can include multiple distributed persistent storage devices. In addition, the user database 110 can be replicated such that the storage devices are geographically dispersed.

[0074] The user database 110 can include other user profiles 118 associated with multiple other users served by the health monitoring and decision support system 100. More specifically, similar to the operations performed on user 102, the operations performed on these other users can utilize an analyte monitoring system such as the analyte monitoring system 104, and can also interact with the same application 106, a copy of which is executed on the respective mobile devices of the other users 102. For such users, user profiles 118 are similarly created and stored in the user database 110.

[0075] Figure 1B An example of a continuous analyte monitoring system according to certain embodiments of the present disclosure is illustrated. Diagram 150 illustrates an example of the analyte monitoring system 104. In Figure 1B the example, the analyte monitoring system 104 is a glucose monitoring system. However, as described above, the analyte monitoring system 104 can be configured to measure any other analyte or a combination of multiple analytes. Figure 1B Examples of multiple mobile devices 107a, 107b, 107c, and 107d (referred to individually as mobile device 107 and collectively as mobile devices 107) are illustrated. It should be noted that Figure 1A the mobile device 107 can be any one of mobile devices 107a, 107b, 107c, or 107d. In other words, any one of mobile devices 107a, 107b, 107c, or 107d can be configured to execute the application 106. The glucose monitoring system 104 can be communicatively coupled to mobile devices 107a, 107b, 107c, and / or 107d.

[0076] As an overview and example, the analyte monitoring system 104 can be implemented as a packaged microcontroller that performs sensor measurements, generates analyte data (e.g., by calculating the values of continuous glucose monitoring data), and participates in wireless communication (e.g., via Bluetooth and / or other wireless protocols) to send such data to a remote device, such as the mobile device 107. Paragraphs

[0137] to

[0140] of U.S. Patent Application Publication No. 2019 / 0336053 and Figure 3 A, Figure 3 B andFigure 4 Further described is a skin sensor assembly that can be used in conjunction with the analyte monitoring system 104 in certain embodiments. Paragraphs

[0137] to

[0140] of U.S. Patent Application Publication No. 2019 / 0336053 and Figure 3 A, Figure 3 B, and Figure 4 are incorporated herein by reference.

[0077] In certain embodiments, the analyte monitoring system 104 includes an analyte sensor electronics module 138 and a continuous analyte sensor 140 (e.g., a glucose sensor) associated with the analyte sensor electronics module 138. In certain embodiments, the analyte sensor electronics module 138 includes electronic circuitry associated with measuring and processing analyte sensor data (also referred to herein as "sensor output") or information, including algorithms associated with the processing and / or calibration of analyte sensor data / information. The analyte sensor electronics module 138 can be physically / mechanically connected to the analyte sensor 140 and can be integral with (e.g., non - releasably attached to) the analyte sensor 140 or releasably attached to the analyte sensor.

[0078] The analyte sensor electronics module 138 can also be electrically coupled to the analyte sensor 140 such that the components can be electromechanically coupled to each other. The analyte sensor electronics module 138 can include hardware, firmware, and / or software that enable the measurement and / or estimation of analyte levels in a user's body via the analyte sensor 140 (which can be / is a glucose sensor, for example). For example, the analyte sensor electronics module 138 can include one or more potentiostats, a power source for providing power to the analyte sensor 140, other components for signal processing and data storage, and a telemetry module for transmitting data from the sensor electronics module to various devices, the various devices including but not limited to one or more display devices (e.g., the user's mobile device 107), a user database 110, a decision support engine 112, etc. The electronics can be fixed to a printed circuit board (PCB) or platform, etc. within the analyte monitoring system 104 and can take various forms. For example, the electronics can take the form of an integrated circuit (IC), such as an application - specific integrated circuit (ASIC), a microcontroller, a processor, and / or a state machine.

[0079] The analyte sensor electronics module 138 can include sensor electronics configured to process sensor information, such as sensor data, and generate transformed sensor data and displayable sensor information. Examples of systems and methods for processing sensor analyte data are described in more detail herein and in U.S. Patent Nos. 7,310,544 and 6,931,327 and U.S. Patent Application Publications 2005 / 0043598, 2007 / 0032706, 2007 / 0016381, 2008 / 0033254, 2005 / 0203360, 2005 / 0154271, 2005 / 0192557, 2006 / 0222566, 2007 / 0203966, and 2007 / 0208245, all of which are incorporated herein by reference in their entirety.

[0080] The analyte sensor 140 is configured to measure the concentration or level of an analyte in the user 102. The term analyte is further defined in paragraph

[0117] of U.S. Application 2019 / 0336053. Paragraph

[0117] of U.S. Application 2019 / 0336053 is incorporated herein by reference. In some embodiments, the analyte sensor 140 includes a continuous analyte sensor, such as a subcutaneous, transdermal (e.g., percutaneous) or intravascular device. In some embodiments, the analyte sensor 140 can analyze multiple intermittent blood samples. The analyte sensor 140 can use any analyte measurement method, including enzymatic, chemical, physical, electrochemical, spectrophotometric, polarimetric, calorimetric, iontophoretic, radiometric, immunochemical, etc. Additional details related to continuous analyte sensors, such as continuous glucose sensors, are provided in paragraphs

[0072] to

[0076] of U.S. Patent No. 9,445,445. Paragraphs

[0072] to

[0076] of U.S. Patent No. 9,445,445 are incorporated herein by reference.

[0081] Further reference Figure 1B, the mobile device 107 may be configured to display (and / or alert) displayable sensor information that may be transmitted by the sensor electronics module 138 (e.g., in customized data packets that are transmitted to the display device based on their respective preferences). Each of the mobile devices 107a, 107b, 107c, and / or 107d may respectively include a display such as a touchscreen display 109a, 109b, 109c, and / or 109d for displaying (e.g., of the application 106) a graphical user interface to present sensor information and / or analyte data to the user 102 and / or receive input from the user 102. In certain embodiments, as an alternative or supplement to the touchscreen display, the mobile device 107 may include other types of user interfaces, such as a voice user interface, for communicating sensor information to the user 102 of the mobile device 107 and / or receiving user input. In certain embodiments, one, some, or all of the mobile devices 107 may be configured to display or otherwise communicate sensor information (e.g., in a data packet transmitted to the respective display device) without calibration and / or any additional expected processing required for real-time display of sensor data when the sensor information is transmitted from the sensor electronics module 138.

[0082] The mobile device 107 may include a customized or proprietary display device, such as the analyte display device 107b, which is particularly designed to display certain types of displayable sensor information (e.g., numerical values and / or arrows in certain embodiments) associated with analyte data received from the sensor electronics module 138. In certain embodiments, one of the mobile devices 107 includes a mobile phone, such as a smartphone using Android, iOS, or another operating system configured to display a graphical representation of continuous sensor data (e.g., including current and / or historical data).

[0083] In Figure 2 illustrates an example input and example metrics generated based on the input according to certain embodiments of the present disclosure. Figure 2Illustrates example input 127 on the left, application 106 and DAM 111 in the middle, and example metrics 130 on the right. In certain embodiments, application 106 may obtain input 127 through one or more channels (e.g., manual user input, sensors, various applications executed on mobile device 107, etc.). Input 127 may be further processed by DAM 111 to output multiple metrics, such as metric 130. In certain embodiments, input 127 and metric 130 may also be used by DAM 111 and / or any computing device in system 100 as context information to perform various actions, such as but not limited to identifying queues and / or defining various subgroups within a user queue. Additionally, DAM 111 and / or any computing device in system 100 may use the input (e.g., input 127) and metrics (e.g., metric 130) to perform various processes for determining user-specific hyperparameters for a decision support model, as further described below. Any one of the inputs in input 127 may be used to calculate any one of the metrics in metric 130. In certain embodiments, each metric in metric 130 may correspond to one or more values, e.g., discrete numerical values, ranges, or qualitative values (high / medium / low or stable / unstable).

[0084] In certain embodiments, input 127 includes food intake information. The food intake information may include information about one or more of meals, snacks, and / or beverages, such as one or more of size, content (carbohydrates, fats, proteins, etc.), order of intake, and time of intake. In certain embodiments, the food intake information may be provided by manual user input, by providing a photo through an application configured to identify food type and quantity, and / or by scanning a barcode or menu. In various examples, the meal size may be manually entered as one or more of calories, quantity (e.g., "three cookies"), menu item (e.g., "royal cheese"), and / or food exchange portions (1 fruit, 1 dairy). In some embodiments, a user's typical item or combination of meals for that time or environment may also be entered (e.g., breakfast at home on weekdays, brunch at a restaurant on weekends). In some examples, the meal information may be received through a convenient user interface provided by application 106.

[0085] In certain embodiments, input 127 includes activity information. For example, the activity information may be provided by an accelerometer sensor on a wearable device (e.g., a watch, a fitness tracker, and / or a patch). In certain embodiments, the activity information may also be provided by manual input from user 102.

[0086] In some embodiments, input 127 includes patient statistics such as one or more of age, height, weight, body mass index, body composition (e.g., percentage of body fat), build, body type, or other information. Patient statistics can be provided via a user interface, via handoff with an electronic source such as an electronic medical record, and / or from a measuring device. The measuring device can include one or more of a wireless (e.g., Bluetooth-enabled) scale and / or a camera, for example, which can communicate with mobile device 107 to provide patient data.

[0087] In some embodiments, input 127 includes information related to the user's insulin administration. Such information can be received via a wireless connection on a smart pen, via user input, and / or from an insulin pump. Insulin administration information can include one or more of insulin volume, administration time, etc. Other configurations such as insulin action time or duration of insulin action can also be received as input.

[0088] In some embodiments, input 127 includes information received from a sensor such as a physiological sensor that can detect one or more of heart rate, respiration, oxygen saturation, or body temperature, etc. (e.g., to detect a disease).

[0089] In some embodiments, input 127 includes glucose information. Such information can be provided as input, for example, by an analyte monitoring system 104. In some embodiments, glucose information can be received from one or more of a smart drug dispenser that tracks when the user takes medication, a blood ketone meter, laboratory measurements or estimated Alc, other measurements of long-term control, or a sensor that measures peripheral neuropathy using a tactile response (such as by using the tactile characteristics of a smartphone or a professional device).

[0090] In some embodiments, input 127 includes time, such as the time of day, or time from a real-time clock.

[0091] As described above, in some embodiments, DAM 111 determines or calculates metric 130 based on input 127 associated with user 102. Figure 2 An example list of metrics 130 is illustrated. In some embodiments, metric 130 determined or calculated by DAM 111 includes metabolic rate. In some embodiments, the metabolic rate is a metric that can indicate or include basal metabolic rate (e.g., energy consumed at rest) and / or active metabolism (e.g., energy consumed during activities such as exercise or exertion). In some examples, basal metabolic rate and active metabolism can be tracked as separate metrics. In some embodiments, the metabolic rate can be calculated by DAM 111 based on one or more of the inputs in input 127 such as activity information, sensor input, time, user input, etc.

[0092] In some embodiments, the metric 130 determined or calculated by the DAM 111 includes an activity level metric. The activity level metric may indicate the user's activity level. In some embodiments, for example, the activity level metric is determined based on input from an activity sensor or other physiological sensor. In some embodiments, the activity level metric may be calculated by the DAM 111 based on one or more of the inputs 210 such as activity information, sensor input, time, user input, etc.

[0093] In some embodiments, the metric 130 determined or calculated by the DAM 111 includes an insulin sensitivity metric (also referred to herein as "insulin resistance"). Historical data, real-time data, or a combination thereof may be used, and the insulin sensitivity metric may be determined, for example, based on one or more of the inputs 127 such as food intake information, blood glucose information, insulin administration information, resulting glucose levels, etc. In some embodiments, insulin administration information and / or a known or (e.g., from patient data) known insulin time-action curve may be used to determine an insulin onboard metric, which may account for the basal metabolic rate (e.g., updating insulin to maintain body operations) and insulin use driven by activity or food intake.

[0094] In some embodiments, the metric 130 determined or calculated by the DAM 111 includes a meal status metric. In some embodiments, the meal status metric may indicate the state the user is in with respect to food intake. For example, the meal status may indicate whether the user is in a fasting state, pre-meal state, in-meal state, post-meal response state, or steady state. In some embodiments, the meal status may also indicate the nutrition of the meal (e.g., the meal, snack, or beverage consumed), and may be determined, for example, based on food intake information, meal time information, and / or digestibility information, which may be associated with the food type, quantity, and / or order (e.g., which food / beverage is consumed first).

[0095] In some embodiments, the metric 130 determined or calculated by the DAM 111 includes a health and disease metric. The health and disease metric may be determined, for example, based on one or more user inputs from physiological sensors (e.g., temperature), activity sensors, or a combination thereof (e.g., pregnancy information or known disease information). In some embodiments, based on the value of the health and disease metric, for example, the user's state may be defined as one or more of healthy, sick, resting, or tired.

[0096] In certain embodiments, the metric 130 determined or calculated by the DAM 111 includes a glucose level metric. The glucose level metric can be determined based on sensor information (e.g., blood glucose information obtained from the analyte monitoring system 104). In some examples, the glucose level metric can also be determined, for example, based on historical information about glucose levels in a particular situation (e.g., a combination of a given food intake, insulin, and / or activity). In certain embodiments, a blood glucose trend can be determined based on glucose levels over a period of time.

[0097] In certain embodiments, the metric 130 determined or calculated by the DAM 111 includes a disease stage. For example, the disease stage of a type II diabetes patient can include a prediabetes stage, an oral treatment stage, and a basal insulin treatment stage. In certain embodiments, the degree of blood glucose control (not shown) can also be determined as an outcome metric and can be based on, for example, one or more of glucose levels, changes in glucose levels, or insulin administration patterns.

[0098] In certain embodiments, the metric 130 determined or calculated by the DAM 111 includes a clinical metric. Clinical metrics generally indicate the clinical state of a user with respect to one or more conditions of the user, such as diabetes. For example, in the case of diabetes, clinical metrics can be determined based on blood glucose measurements and can include one or more of A1C, A1C trend, time in range, time below a threshold level, time above a threshold level, and / or other metrics derived from blood glucose values. In certain embodiments, clinical metrics can also include one or more of an estimated A1C, glucose variability, hypoglycemia, and / or a health indicator (amount of time outside of a target region).

[0099] As discussed herein, the DAM 111 and / or the application 106 can be implemented in one or more computing devices to perform various processes for determining user-specific hyperparameters for a decision support model. For example, such processes can include performing (1) an initial exploration phase, (2) a training phase, and (3) an exploration-exploitation phase, as further described below. For example, the initial exploration phase can be performed by assigning a random set of hyperparameters, determining and providing a decision support output, and monitoring a physiological condition by analyzing monitoring data. In certain embodiments, the monitoring data can include any data that provides information about the physiological condition of the user, including but not limited to the input 127 and other metrics 130.

[0100] As further described below, the training phase can be performed by applying training data to a result prediction model to determine a prediction result. In some embodiments, the training data can include input data of a user (e.g., context data, input 127, etc.), input data of hyperparameters (e.g., values associated with hyperparameters), and / or monitoring data. In certain embodiments, the context data can be personal (based on cohort data) or individual (based on specific user data).

[0101] Additionally, the exploration-exploitation phase is performed by partitioning a set of users into a user exploration subset and an exploitation subset. In certain embodiments, the exploration-exploitation phase can further include using an experimental set of hyperparameters to determine a decision support output for the user exploitation subset, determining one or more prediction results, and determining one or more scalarized results. In various embodiments, the exploration-exploitation phase can further include selecting and assigning an experimental set of hyperparameters with optimal scalarized results, and determining a decision support output using the optimal set of hyperparameters. Additionally, the computing device can monitor a user's physiological condition to observe a set of outcomes of interest that occur after the decision support output is provided to the user and / or after the user performs an action recommended by the decision support output (e.g., time above the optimal glucose range and time below the optimal glucose range). In certain embodiments, the (2) training phase (also referred to herein as the "retraining phase") and the (3) exploration-exploitation phase can be repeated to further refine user-specific hyperparameters for the decision support model. In such embodiments, the retention phase can be performed using data from a previous user exploration subset, as further described below.

[0102] Example Process for Determining Decision Support Output Based on User - Specific Hyperparameters

[0103] Figure 3 is a flowchart illustrating process 300 for determining a decision support output based on user-specific hyperparameters according to certain embodiments of the present disclosure. In various embodiments, the user-specific hyperparameters can include a set of hyperparameters for each user in a set of users. A multi-objective CMAB algorithm executed by a computing device can be used to determine the user-specific hyperparameters. The computing device can be part of a health monitoring and support system 100, such as a computing device that executes a decision support engine 112 or a backend server (not shown).

[0104] Refer to Figure 3, process 300 may include performing (block 302) an initial exploration phase, as further described below. During the initial exploration phase, the computing device assigns a random set of hyperparameters to each user, determines a decision support output using the random set of hyperparameters, and provides the decision support output to the user. The initial exploration phase may also include monitoring a physiological condition to observe one or more outcomes of interest (e.g., time above the optimal glucose range and time below the optimal glucose range) that occur after the decision support output is provided to the user or after the user performs an action recommended by the decision support output.

[0105] Additionally, process 300 may include performing (block 304) a training phase, as further described below. During the training phase, the computing device uses the monitoring data from the initial exploration phase to train an outcome prediction model (also referred to herein as a "policy assignment algorithm"). The outcome prediction model is a machine learning model configured to determine a set of predicted outcomes and a corresponding set of hyperparameters for a particular user. Each predicted outcome is an outcome that is predicted to occur when a decision support output determined based on the corresponding set of hyperparameters is provided to the user and / or when the user performs an action recommended by the decision support output. An example of an outcome predicted for a user and a corresponding set of hyperparameters includes the duration that the user is predicted to be above the optimal glucose range when a decision support output determined using the corresponding set of hyperparameters is provided to the user. Another example of a predicted outcome is the duration that the user is predicted to be below the optimal glucose range when a decision support output determined using the corresponding set of hyperparameters is provided to the user.

[0106] Furthermore, process 300 may also include performing (block 306) an exploration-exploitation phase. During the exploration-exploitation phase, the computing device divides the set of users into an exploitation subset and an exploration subset. With respect to the users in the exploitation subset, the computing device assigns an optimal set of hyperparameters to those users using the predicted outcome values determined by the outcome prediction model. With respect to the users in the exploration subset, the computing device continues to randomly assign hyperparameters to those users.

[0107] After assigning hyperparameters to each user, the computing device uses the assigned hyperparameters for each user to determine a decision support output for the user based on a decision support model. Additionally, the computing device provides the determined decision support output to the user and monitors the user's physiological condition to observe the set of outcomes of interest (e.g., time above the optimal glucose range and time below the optimal glucose range) that occur after the decision support output is provided to the user and / or after the user performs an action recommended by the decision support output.

[0108] Process 300 may also include determining whether to perform a retraining phase (block 308), for example, based on the resulting monitoring data. Determining whether to perform a retraining phase may include reviewing the monitoring data to see if the user's metrics (e.g., health / disease, glucose level, glucose trend, disease stage, etc.) have improved or deteriorated. For example, if a decision support output has been provided to the user based on user-specific hyperparameters, but the monitoring data indicates that the user's metrics have deteriorated, then process 300 may decide to perform a retention phase (block 308). In another example, if a decision support output has been provided to the user based on user-specific hyperparameters, but the monitoring data indicates that the user's metrics have not improved or have not improved sufficiently, then process 300 may decide to perform a retention phase (block 308). In some embodiments, process 300 may determine to retrain periodically (e.g., once a month, regardless of performance). In some embodiments, process 300 may determine to retrain periodically whenever the sample size of the hyperparameters explored by the user and the observed results reaches a threshold number (e.g., 10,000). In some embodiments, if it is observed that for a user subset, the predicted results for the optimal hyperparameters have started to deviate from the subsequently observed results by more than a threshold amount, then process 300 may determine to retrain.

[0109] If process 300 determines (block 308) to perform a retraining phase, then process 300 may repeat blocks 304 and 306. In subsequent iterations of block 304, the computing device continues to use data from the user exploration subset (e.g., randomly assigned hyperparameters, user context, and observed results) to retrain (block 304) the result prediction machine learning model. Additionally, in subsequent iterations of block 306, the computing device uses the retrained result prediction model to perform (block 306) the exploration-exploitation phase, including determining and providing a new decision support output to the user.

[0110] Hereinafter, blocks 302, 304, and 306 will be described in more detail with reference to subsequent Figures 4 to 8 In particular, block 302 will be described in more detail by referring to Figure 4 blocks 402 to 408 of Figure 3 In addition, block 304 will be described in more detail by referring to Figure 5 block 502 of Figure 3 In addition, block 306 will be described in more detail by referring to Figure 6 blocks 602 to 606 of Figure 3 Then, block 604 will be described in more detail by referring to Figure 7 blocks 702 to 710 of Figure 6 After block 604, then block 606 will be described in more detail by referring to Figure 8 blocks 802 and 804 of Figure 6 ​

[0111] 1. Block 302: Perform an Initial Exploration Phase

[0112] As described above Figure 3 the process 300 may include performing (block 302) an initial exploration phase. Figure 4 is an example of a flowchart of a process 400 for performing (block 302) Figure 3 the initial exploration phase. The process 400 includes randomly assigning (block 402) one or more hyperparameters to each user. For example, the computing device randomly assigns a set of hyperparameters to each user. In some embodiments, to randomly assign hyperparameters to a user, the computing device randomly selects values from an acceptable range of hyperparameters. In some embodiments, to randomly assign hyperparameters to a user, the computing device first determines a queue-specific range for the hyperparameters based on the user's queue, and then randomly selects values from the queue-specific range. For example, the computing device may first determine that the hyperglycemic risk threshold for women between 20 and 30 years old should be between 0.2 and 0.7, and then randomly select a value from the range (0.2, 0.7) for a 25-year-old female user.

[0113] Reference Figure 4 and, the process 400 may include using at least one of the randomly assigned hyperparameters to determine (block 404) one or more decision support outputs for the user. For example, after the computing device randomly assigns a set of hyperparameters to the user, the computing device uses the randomly assigned set of hyperparameters to determine the decision support output for the user. As an example, the computing device may randomly assign a hyperglycemic risk threshold of 0.5 to the user. The computing device may use the hyperglycemic risk threshold as a hyperparameter of the decision sub-model of the hyperglycemic warning model to determine whether to warn the user that she is at risk of hyperglycemia in a future time period.

[0114] In some embodiments, the process 400 may include providing (block 406) the determined decision support output to the user. In the above example, if the hyperglycemic risk score determined by the scoring sub-model of the hyperglycemic warning model for the user is, for example, 0.6, the decision sub-model may determine that a hyperglycemic warning should be communicated to the user because 0.6 is greater than the threshold 0.5. In certain embodiments, the process 400 may include monitoring (block 408) the user's physiological condition to observe a set of outcomes of interest. For example, the computing device may provide a hyperglycemic warning and then monitor the user's glucose level. As another example, the computing device may provide recommendations to the user for exercise, drinking water, etc., and then monitor the user's glucose level after providing the recommendations and / or after the user has implemented the recommendations.

[0115] 2. Block 304: Perform a Training Phase

[0116] As described above Figure 3 the process 300 may include performing (block 304) a training phase. Figure 5 FIG. 500 is a flow diagram of a process 500 for performing (block 304) a training phase, illustrative of certain embodiments of the present disclosure. The training phase may be performed to initially train a result prediction model or retrain a previously trained result prediction model based on new monitoring data determined by monitoring a user's physiological condition. The result prediction model (also referred to herein as a "policy assignment algorithm") is a machine learning model configured to determine one or more prediction results (e.g., a set of prediction results) for a corresponding user if a decision support output determined by a decision support model according to a corresponding set of hyperparameters is provided to the corresponding user and / or if the corresponding user performs an action recommended by the decision support output.

[0117] Referring Figure 5 to, the process 500 may include analyzing (block 502) training data for relationships between context data, hyperparameters, and observations (e.g., monitoring data) for a user. For example, an output prediction model may receive training data such as, but not limited to, hyperparameters (e.g., randomly assigned hyperparameters), context data (e.g., user data such as age, demographic data, health history, etc.), and observations (e.g., monitoring data). In some embodiments, the input data (e.g., training data) for each execution of the result prediction model may include the user's input data (e.g., the context data of the corresponding user) and the input data of the hyperparameters (e.g., the values of the corresponding set of hyperparameters (also referred to herein as "hyperparameter values")). In some embodiments, the input data for each execution of the result prediction model may further include monitoring data (e.g., one or more results associated with one or more randomly assigned hyperparameters).

[0118] In certain embodiments, the training data may further include a set of training data entries, where each training data entry includes a set of context data associated with a corresponding user, data associated with a corresponding hyperparameter, and monitoring / observation results (e.g., monitoring data) obtained after a decision support output determined using the corresponding hyperparameter is provided to the user and / or after the user performs an action recommended by the described decision support output. In various embodiments, the training data for training the result prediction model may be generated by monitoring the user's physiological condition after providing a decision support output to the user, where the decision support output provided to the user may be determined using operations of an initial exploration phase (in an initial training context) or using operations of an exploration-exploitation phase (in a retraining context), where the retraining utilizes information from a user exploration subset.

[0119] 3. Block 306: Perform an Exploration - Exploitation Phase

[0120] As mentioned above Figure 3 As described, process 300 may include performing (block 306) an explore-exploit phase. In some embodiments, the explore-exploit phase may be performed using a multi-objective CMAB. During the explore-exploit phase, the user set may be divided into an explore subset and an exploit subset, and decision support outputs may be determined for the two user subsets.

[0121] Figure 6 6 is a flowchart illustrating a process 600 for performing (box 306) an exploration-exploitation phase according to certain embodiments of the present disclosure. Process 600 may include dividing (box 602) a set of users into an exploration subset and an exploitation subset. For example, the set of users is first randomly divided into an exploration subset and an exploitation subset according to an exploration ratio ε. In particular, the ε portion of the user is randomly selected and used to identify the exploration subset, and the remaining (1-ε) portion of the user is used to identify the exploitation subset. In some embodiments, after each retraining of the result prediction model, the magnitude of the exploration ratio ε is reduced. In some embodiments, after a predefined number of retrainings of the result prediction model, the magnitude of the exploration ratio ε is set to zero. In some embodiments, the magnitude of the reduction in the exploration ratio ε can be a function of the accuracy of the result model (which can improve over time). In addition, the exploration ratio ε can also have a lower limit of>0 to ensure that a certain degree of exploration is always performed, because the most effective exploration for the user can change over time.

[0122] During the exploration-exploitation phase, the multi-objective CMAB model can also determine decision support outputs for the user exploitation subset and the user exploration subset. Figure 6 Various example processes for determining decision support outputs for user exploration and exploitation subsets are further described. In particular, Figure 6 Block 604 of depicts determining a decision support output for the user utilization subset, while Figure 6 Block 606 of depicts determining a decision support output for the user exploration subset.

[0123] a. Block 604: Determine Decision Support Output for the Exploitation Subset

[0124] The process 600 for performing (block 306) the explore-exploit phase may also include determining (block 604) a decision support output for the user exploit subset. Various techniques may be used to determine (block 604) the decision support output for the user exploit subset. For example, after assigning a user to an exploit subset, the following operations may be performed to determine the decision support output for the user exploit subset.

[0125] Figure 7FIG. 604 is a flowchart illustrating a process 700 for determining (block 604) decision support outputs for users utilizing a subset. Process 700 may include assigning (block 702) multiple experimental hyperparameters (e.g., two or more sets of experimental hyperparameters) to each user in the utilization subset. In some embodiments, each potential set of hyperparameters that can be assigned to the decision support model is experimentally assigned to each user in the utilization subset. For example, if the decision support model is characterized by only one hyperparameter that can take on one of A potential values, all A potential values are experimentally assigned to the users. As another example, if the decision support model is characterized by two hyperparameters that can take on B and C potential values, respectively, all B*C pairings of the potential values for the two hyperparameters are experimentally assigned to the users. In some embodiments (e.g., when at least one hyperparameter has a continuous range), a subset of all potential sets of hyperparameters is randomly assigned to the users in the utilization subset. For example, if the decision support model is characterized by a hyperparameter that can take on values from a continuous range, a defined number of randomly selected values from the continuous range can be experimentally assigned to the users. In another example of a hyperparameter with a continuous range, intervals can be defined to select the continuous hyperparameter. For example, if the accepted values are [0.2 to 0.8], the interval can be 0.01, and the experimentally assigned values can be [0.20, 0.21, 0.22…0.79, 0.80]. Thus, at the end of this step, multiple sets of experimental hyperparameters are assigned to each user in the utilization subset.

[0126] Reference Figure 7, process 700 may include determining (block 704) a prediction result (e.g., a set of prediction results) for each experimental hyperparameter (e.g., for each set of experimental hyperparameters) using an output prediction model. For example, after a set of experimental hyperparameters has been assigned to a user, the result prediction model can be used to determine, for each set of experimental hyperparameters, a set of prediction results for the user. In some embodiments, input data for the user (e.g., context data) and input data for each of the sets of experimental hyperparameters (e.g., values associated with the experimental hyperparameters) are provided to the result prediction model to determine, for the sets of experimental hyperparameters, a set of prediction results for the user. For example, given that the user is female, 25 years old, and has a hyperglycemic risk threshold of 0.43 experimentally assigned to the user, the result prediction model can process context data associated with the user (e.g., age data, gender data, location data, and / or health history data) and the hyperglycemic risk threshold of 0.43 to determine: (i) the predicted time above the optimal glucose range if the decision support output determined using the hyperglycemic risk threshold of 0.43 is provided to the user, and (ii) the predicted time below the optimal glucose range if the decision support output determined using the hyperglycemic risk threshold of 0.43 is provided to the user. Thus, at the end of this step, a set of (e.g., two or more) prediction results is determined for each set of experimental hyperparameters assigned to the user.

[0127] In some embodiments, the output prediction model can determine one or more prediction results specific to the user and the corresponding hyperparameters. For example, during each execution, the result prediction model outputs a set of prediction results that is specific to the corresponding user and the corresponding set of hyperparameters. As further described above, training data including, but not limited to, context data for the corresponding user, the corresponding set of hyperparameters (e.g., values associated with the hyperparameters), and observations (e.g., monitoring data) can be used as input to train the result prediction model. The output data generated by each execution of the result prediction model includes one or more prediction results (e.g., a set of prediction results), such as a combination of the predicted time above the optimal glucose range and the predicted time below the optimal glucose range. For example, in an exemplary execution, the result prediction model processes context data for the corresponding user and the corresponding set of hyperparameters for the decision support model to determine: (i) the predicted time above the optimal glucose range if the decision support output generated by the decision support model based on the corresponding set of hyperparameters is provided to the corresponding user and / or if the corresponding user performs the action recommended by the described decision support output, and (ii) the predicted time above the optimal glucose range if the described decision support output is provided to the corresponding user and / or if the corresponding user performs the action recommended by the described decision support output.

[0128] Further reference is made to Figure 7 such that process 700 may further include determining (block 706) a scalarized result for each experimental hyperparameter (e.g., for each set of experimental hyperparameters) by combining prediction results (e.g., a set of prediction results). In some embodiments, after determining a set of prediction results for each set of experimental hyperparameters, the set of prediction results for the set of experimental hyperparameters is combined to determine a scalarized result for the set of experimental hyperparameters. In some embodiments, the set of prediction results for a set of experimental hyperparameters includes two or more prediction results, such as the predicted duration that a user will be above the optimal glucose range in the case where a decision support output determined using the corresponding set of hyperparameters is provided to the user, and the predicted duration that a user will be below the optimal glucose range in the case where the decision support output is provided to the user.

[0129] In some embodiments, the set of prediction results for a set of experimental hyperparameters is combined according to a predefined set of result weights to generate a scalarized result for the set of experimental hyperparameters. For example, the scalarized result for a hyperglycemic risk threshold of 0.43 may be determined based on the result of w1*o1 + w2*o2, where: (i) o1 is the predicted duration that a user will be above the optimal glucose range in the case where a decision support output determined using the hyperglycemic risk threshold of 0.43 is provided to the user, (ii) w1 is the result weight of o1, (iii) o2 is the predicted duration that a user will be below the optimal glucose range in the case where a decision support output determined using the hyperglycemic risk threshold of 0.43 is provided to the user, and (ii) w2 is the result weight of o2. In a further example, avoiding time below the range may be more important than avoiding time above the range. In this example, the CMAB model may set w1 and w2 to, for example, 0.2 and 0.8, respectively. In another example, avoiding time below the range may be equally important as avoiding time above the range. In this example, the CMAB model may set w1 = w2 = 0.5. Thus, at the end of this step, each set of experimental hyperparameters is associated with a single scalarized result.

[0130] Further reference is made to Figure 7, Process 700 may further include determining (block 708) at least one optimal hyperparameter based on the scalarization result. In some embodiments, the computing device may select the set of experimental hyperparameters having the optimal scalarization result and assign it to each user. In certain embodiments, after determining the scalarization result for each set of experimental hyperparameters, the set of experimental hyperparameters having the optimal (e.g., lowest) scalarization result is selected and assigned to the user. For example, if the set of experimental hyperparameters includes a hyperglycemic risk threshold of 0.43 associated with a scalarization result of 25 and a hyperglycemic risk threshold of 0.66 associated with a scalarization result of 20, then when the CMAB model sets w1 = w2 = 0.5, the hyperglycemic risk threshold of 0.66 may be assigned to the user to minimize the prediction time outside the optimal glucose range. For any other choice of weights, the CMAB model minimizes the scalarization time outside the optimal glucose range (possibly weighting more heavily the time above or below the range). Thus, at the end of this step, a single optimal set of hyperparameters is assigned to the user using the subset.

[0131] Further reference Figure 7 , Process 700 may further include using at least one optimal hyperparameter (e.g., the optimal set of hyperparameters) to determine (block 710) the decision support output for each user. For example, after assigning the optimal set of hyperparameters to the user, the optimal set of hyperparameters is used by the decision submodel of the decision support model to determine the decision support output for the user. For example, if the optimal set of hyperparameters for the user includes a hyperglycemic risk threshold of 0.66 and if the scoring submodel of the decision support model has generated a score of 0.33 for the user, then because 0.33 drops below 0.66, the computing device may determine a "no warning" output corresponding to not providing the user with a hyperglycemic warning.

[0132] b. Block 606: Determine Decision Support Output for the Exploration Subset

[0133] The process 600 for performing (block 306) the exploration-exploitation phase may further include determining (block 606) the decision support output for the user exploration subset (as Figure 8 illustrated). Various techniques may be used to determine the decision support output for the user exploration subset. For example, after assigning the user to the exploration subset, the following operations are performed to determine the decision support output for the user exploration subset.

[0134] Figure 8FIG. 800 is a flow diagram illustrating a process 800 for determining (block 606) decision support outputs for a user exploration subset in accordance with certain embodiments of the present disclosure. Process 800 may include randomly assigning (block 802) at least one hyperparameter to each user in the user exploration subset. For example, a randomly selected set of hyperparameters may be assigned to a user. In some embodiments, to assign random hyperparameters to a user, a computing device first determines a queue-specific range for the hyperparameters based on the queue of the user, and then randomly selects a value from the queue-specific range. For example, the computing device may first determine that the hyperglycemic risk threshold for women between 20 and 30 years old should be between 0.2 and 0.7, and then randomly select a value from the range (0.2, 0.7) for a 25-year-old female user.

[0135] Further reference Figure 8 to, process 800 may include using the at least one randomly assigned parameter to determine (block 804) a decision support output for each user in the exploration subset. For example, after randomly assigning a set of hyperparameters to a user, the randomly assigned set of hyperparameters is used by a decision submodel of a decision support model to determine a decision support output for the user. For example, if the randomly assigned set of hyperparameters for a user includes a hyperglycemic risk threshold of 0.23, and if a scoring submodel of the decision support model has generated a score of 0.33 for the user, then because 0.33 has not dropped below 0.23, the computing device may determine a "warning" output corresponding to providing a hyperglycemic warning to the user.

[0136] Although the above describes specific classifications of steps for an initial exploration phase, a training phase, and an exploration-exploitation phase with respect to Figures 3 to 8 , embodiments in accordance with the present disclosure may utilize various other classifications of steps. For example, as Figure 9 shown and further described below, the process for determining user-specific hyperparameters for use with a decision support model may be classified as steps without being in any particular phase. Additionally, although specific steps are described as being performed by specific algorithms with respect to Figures 3 to 8 above, various other algorithms may be utilized to perform the various steps of embodiments in accordance with the present disclosure. For example, in some embodiments, determining and / or providing a decision support output based on hyperparameters and monitoring results may be performed by a customer-facing algorithm that executes a decision support model.

[0137] Exemplary Flowchart of Operations for Determining Decision Support Output Based on User - Specific Hyperparameters

[0138] As described above, a customer-facing algorithm can execute a decision support model. For example, the decision support model can include determining a decision support output using user-specific hyperparameters. In some embodiments, executing the decision support model can include determining a decision support output for a user by using: (i) an optimal level range of user 102 as input data, and / or (ii) a risk tolerance profile based on hyperparameters including user-specific hyperparameters.

[0139] Figure 9 is a flowchart illustrating an exemplary operational process for determining a decision support output based on user-specific hyperparameters in accordance with certain embodiments of the present disclosure. Specifically, a nocturnal hypoglycemia classifier having a tunable probability threshold hyperparameter and time below range (TbR) and time above range (TaR) as outcomes of interest is further described below with reference to Figure 9 is further described.

[0140] Process 900 can include assigning (step 1) a random set of hyperparameters to each user. For example, during an initial exploration phase, a CMAB model can test the nocturnal hypoglycemia classifier by measuring TbR and TaR for a range of K different probability thresholds (0.1, 0.2, …, 0.9). Users are randomly assigned one of these probability thresholds. In some embodiments, the customer-facing algorithm can use the randomly assigned probability threshold (i.e., a random set of hyperparameters) to execute the decision support model and observe the results, as further described above.

[0141] Process 900 can also include determining (step 2) a decision support output based on the assigned set of hyperparameters, observing the result associated with the decision support output, and training a result prediction model based on the observed data. For example, the process can train a policy assignment algorithm on this exploration phase data to learn the relationship between parameters (probability thresholds), context (e.g., age and diabetes type), and outcomes of interest (TbR and TaR).

[0142] Referring to Figure 9 , process 900 can include partitioning (step 3) users into an exploitation subset and an exploration subset using an ε fraction, as further described above. For example, for a 1 - ε fraction of the users assigned to the exploitation arm of the MAB, the process can run the policy assignment algorithm K times (probability thresholds 0.1, 0.2, …, 0.9) for each user to predict their TbR and TaR.

[0143] Additionally, process 900 may include determining (step 4) a scaled result for users in the subset by scaling the prediction results determined using the result prediction model. For example, for each predicted (TbR, TaR) for each user, the process may include applying a scalarization (e.g., 0.5*TbR + 0.5*TaR) to handle the trade-off between TbR and TaR. In this embodiment, a scalarization weight of 0.5 is used for TbR and TaR. Alternatively, the process may determine the weights via user input (e.g., users who do not value nocturnal hypoglycemia more than any other matter, those who generally do not care since they will be alerted and woken up, etc.). In another alternative, the process may determine the weights by queuing users according to the preferences or metrics to be weighted (e.g., User_Risk_Tolerance*TbR + (1 - User_Risk_Tolerance)*TaR). In yet another alternative, the process may set the weights to default values that the users can change themselves.

[0144] Further reference Figure 9 , process 900 may include determining (step 5) an optimal set of hyperparameters for users in the subset based on the scaled results and assigning the optimal set of hyperparameters to those users. For example, for each user in the user utilization subset, the process may pick a probability threshold that maximizes 0.5*TbR + 0.5*TaR and use that threshold to run the nocturnal hypoglycemia classifier for that patient. Additionally, process 900 may also include randomly assigning (step 6) hyperparameters to users in the exploration subset and using that data and observations to retrain the result prediction model. For example, the process may keep a fraction ε of the users randomly assigned to the user exploration subset and periodically use that data to retrain the policy assignment algorithm. In certain embodiments, process 900 may repeat steps 2-6.

[0145] Example Apparatus for Determining Decision Support Output Based on User - Specific Hyperparameters

[0146] Figure 10 is a block diagram depicting a computing device 1000 configured to determine user-specific hyperparameters for a decision support model according to certain embodiments disclosed herein. Although depicted as a single physical device, in an embodiment, computing device 1000 may be implemented using virtual devices and / or across multiple devices (such as in a cloud environment). Computing device 1000 may be a display device 107, a server, multiple servers, or any combination thereof.

[0147] As illustrated, computing device 1000 includes one or more processors 1005, non-volatile memory 1010, volatile memory 1015, network interface 1025, and one or more input / output (I / O) interfaces 1020. In the illustrated embodiment, processor 1005 retrieves and executes programming instructions stored in non-volatile memory 1010 and / or volatile memory 1015, and stores and retrieves data resident in non-volatile memory 1010 and / or volatile memory 1015. In some embodiments, non-volatile memory 1010 is configured to store instructions (e.g., computer-executable code, device application 1040) that, when executed by processor 1005, cause processor 1005 to perform the processes and / or operations described herein and illustrated in Figures 3 to 9 The code for performing the functions of DAM 111, decision support engine 112, and / or application 106 is stored in non-volatile memory 1010 in some embodiments. Note that computing device 1000 may be configured to perform the functions of only one of DAM 111, decision support engine 112, and / or application 106, in which case additional systems may be used to perform the functions of the others.

[0148] Processor 1005 generally represents a single central processing unit (CPU) and / or graphics processing unit (GPU), multiple CPUs and / or GPUs, a single CPU and / or GPU having multiple processing cores, etc. Volatile memory 1015 is typically included to represent random access memory (RAM). Non-volatile memory 1010 can be any combination of disk drives, flash-based storage devices, etc., and can include fixed and / or removable storage devices such as fixed disk drives, removable memory cards, cache memory, optical storage devices, network attached storage (NAS), or storage area network (SAN).

[0149] In some embodiments, an I / O device 1035 (such as a keyboard, a monitor, etc.) may be connected via an I / O interface 1020. Additionally, via a network interface 1025, the computing device 1000 may be communicatively coupled to one or more other devices and components such as a user database 110. In certain embodiments, the computing device 1000 is communicatively coupled to other devices via a network, which may include the Internet, a local network, etc. The network may include a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection. As illustrated, the processor 1005, the non-volatile memory 1010, the volatile memory 1015, the network interface 1025, and the I / O interface 1020 are communicatively coupled via one or more bus interconnects 1030. In certain embodiments, the computing device 1000 is a server executing in a locally deployed data center or a cloud environment. In certain embodiments, the computing device 1000 is a mobile device of a user.

[0150] In the illustrated embodiment, the non-volatile memory 1010 may include a device application 1040 that configures the processor 1005 to perform various processes and / or operations when determining user-specific hyperparameters 1085 for a decision support model, as described above. In some embodiments, the device application 1040 may perform the functions of the DAM 111, the decision support engine 112, and / or the application 106. As referenced above Figures 3 to 9As described above, the computing device 1000 may be configured to perform an initial exploration phase by assigning a random set 1086 of hyperparameters, determining and providing a decision support output 1055, and monitoring a physiological condition by receiving and / or analyzing monitoring data 1090 (e.g., input 127, metrics 130, etc.), as further described above. Additionally, the computing device 1000 may be configured to perform a training phase by receiving training data 1060 and / or inputting the training data into a result prediction model and using the result prediction model to determine a prediction result 1065, as further described above. In some embodiments, the training data 1060 may include input data of the user (e.g., context data), input data of the hyperparameters (e.g., values associated with the hyperparameters), and / or monitoring data 1090. Further, the computing device 1000 may be configured to perform an exploration-exploitation phase by partitioning a user set into an exploration subset 1080 and an exploitation subset 1070. In certain embodiments, the exploration-exploitation phase may further include using an experimental set 1087 of hyperparameters to determine a decision support output 1055 for the user exploitation subset, determining a prediction result 1065, and determining a scalarized result 1075, as further described above. In various embodiments, the exploration-exploitation phase may further include selecting and assigning an experimental set 1087 of hyperparameters having an optimal scalarized result, and determining a decision support output 1055 using an optimal set 1088 of hyperparameters, as further described above. In certain embodiments, the computing device 1000 may also receive and / or store input data 1045 (e.g., input 127). Additionally, the computing device 1000 may be configured to receive and / or generate monitoring data (e.g., input 127, metrics 130, etc.), as described above.

[0151] In addition, although the above describes Figure 10 specific operations (e.g., Figures 3 to 9 the operations) and data as being performed and / or stored by a specific computing device, in certain embodiments, a combination of computing devices may alternatively be utilized.

[0152] Each of these non-limiting examples may exist independently or may be combined with one or more of the other examples in various arrangements or combinations. The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings illustrate, in an illustrative manner, specific embodiments in which the invention may be practiced. These embodiments are also referred to herein as "examples". Such examples may include elements in addition to those shown or described. However, the inventors also contemplate examples that provide only those elements shown or described. Additionally, the inventors also contemplate examples of any combination or arrangement of those elements shown or described with respect to a particular example (or one or more aspects thereof) or with respect to other examples (or one or more aspects thereof) shown or described herein.

[0153] In the event of any inconsistency in usage between this document and any document incorporated by reference herein, the usage in this document shall prevail.

[0154] In this document, as is common in patent documents, the terms "a" or "an" are used to include one or more than one, independent of any other instances or uses of "at least one" or "one or more". In this document, the term "or" is used to mean an inclusive or, such that "A or B" includes "A but not B", "B but not A", and "A and B", unless otherwise indicated. In this document, the terms "comprising" and "wherein" are used as plain equivalents of the respective terms "including" and "in which". In this document, the term "set" or "collection" of a particular item is used to refer to one or more than one of the particular item.

[0155] Moreover, in the appended claims, the terms "comprising" and "including" are open-ended, i.e., a system, apparatus, article, composition, formulation or process that includes elements other than those listed after such terms in the claims is still considered to fall within the scope of that claim. Further, in the appended claims, the terms "first", "second", "third", etc. are used only as labels and are not intended to impose numerical requirements on their objects.

[0156] Geometric terms, such as "parallel", "perpendicular", "circular" or "square", are not intended to require absolute mathematical precision, unless the context otherwise indicates. Rather, such geometric terms allow for variations due to manufacturing or equivalent functionality. For example, if an element is described as "circular" or "substantially circular", a component that is not precisely circular (e.g., a component that is slightly oval or a polygon with many sides) is still covered by that description.

[0157] The method examples described herein may be implemented, at least in part, by a machine or a computer. Some examples may include a computer-readable medium or a machine-readable medium encoded with instructions that are operable to configure an electronic device to perform the methods as described in the above examples. Specific implementations of such methods may include code, such as microcode, assembly language code, high-level language code, etc. Such code may include computer-readable instructions for performing various methods. The code may form part of a computer program product. Further, in one example, the code may be tangibly stored on one or more volatile, non-transitory or non-volatile tangible computer-readable media, such as during execution or at other times. Examples of such tangible computer-readable media may include, but are not limited to, hard disks, removable disks, removable optical disks (e.g., compact disks and digital video disks), magnetic tape cartridges, memory cards or sticks, random access memory (RAM), read-only memory (ROM), etc.

[0158] The foregoing description is intended to be illustrative, not limiting. For example, the above examples (or one or more aspects thereof) may be used in combination with each other. Other embodiments may be utilized by those of ordinary skill in the art upon reviewing the foregoing description. The abstract is provided to comply with 37 C.F.R. § 1.72(b) requirements, enabling the reader to quickly ascertain the nature of the technical disclosure. The abstract submitted should be understood not to be used for interpreting or limiting the scope or meaning of the claims. Also, in the foregoing detailed description, various features may be grouped together to simplify the disclosure. This should not be construed as an indication that any feature not claimed is essential to any claim. Rather, the inventive subject matter may lie in less than all of the features of a particular disclosed embodiment. Accordingly, the appended claims are hereby incorporated into the detailed description as examples or embodiments, with each claim standing on its own as a separate embodiment, and it is contemplated that these embodiments may be combined with each other in various combinations or permutations. The scope of the present invention should be determined with reference to the appended claims and the full scope of equivalents to which those claims are entitled.

Claims

1. A non-transitory computer-readable storage medium storing a program, the program including instructions that, when executed by at least one processor of a computing device, cause the at least one processor to perform operations, the operations including: Performing an initial exploration phase by: Randomly assigning at least one hyperparameter to each of a plurality of users; Performing a training phase by: Analyzing training data, where the training data includes context data and values associated with the randomly assigned at least one hyperparameter; and Determining a relationship between the context data and the values associated with the randomly assigned at least one hyperparameter; And Performing an exploration-exploitation phase by: Dividing the plurality of users into a user exploration subset and a user exploitation subset; Determining at least one optimal hyperparameter for each user in the user exploitation subset; Using the at least one optimal hyperparameter to determine at least one decision support output for each user in the user exploitation subset; Randomly assigning at least one hyperparameter to each user in the user exploration subset; And Using the randomly assigned at least one hyperparameter to determine at least one decision support output for each user in the user exploration subset.

2. The non-transitory computer-readable storage medium according to claim 1, wherein the initial exploration phase is further performed by: Using the randomly assigned at least one hyperparameter to determine a decision support output for each of the plurality of users; Providing the decision support output to each of the plurality of users; And Receiving monitoring data for each of the plurality of users, where the monitoring data provides information about at least one physiological condition.

3. The non-transitory computer-readable storage medium according to claim 2, wherein the training data further includes the monitoring data, and the training phase is further performed by: determining a relationship between the monitoring data, the context data, and the values associated with the randomly assigned at least one hyperparameter.

4. The non-transitory computer-readable storage medium according to claim 1, wherein the at least one optimal hyperparameter for each user in the user exploitation subset is determined by: Assigning a plurality of experimental hyperparameters to each user in the exploitation subset; Determining at least one prediction result for each of the plurality of experimental hyperparameters; Determining a scalarization result for each of the plurality of experimental hyperparameters; And Determining the at least one optimal hyperparameter based on the scalarization result.

5. The non-transitory computer-readable storage medium according to claim 4, wherein the operations further include: Performing a retraining phase by: Analyzing training data, where the training data includes context data, values associated with the randomly assigned hyperparameters of the user exploration subset, and monitoring data for the user exploration subset; And Determine the relationship between the context data, the values associated with the at least one hyperparameter randomly assigned to the user exploration subset, and the monitoring data for the user exploration subset.

6. The non-transitory computer-readable storage medium according to claim 1, wherein the exploration-exploitation phase is performed using a contextual multi-armed bandit algorithm.

7. The non-transitory computer-readable storage medium according to claim 4, wherein the at least one prediction result is determined using a policy assignment algorithm.

8. A method for determining user-specific hyperparameters for a decision support model, the method comprising: Performing an initial exploration phase by: Randomly assigning at least one hyperparameter to each user in a plurality of users; Performing a training phase by: Analyzing training data, wherein the training data includes context data and values associated with the at least one randomly assigned hyperparameter; and Determining the relationship between the context data and the values associated with the at least one randomly assigned hyperparameter; And Performing an exploration-exploitation phase by: Dividing the plurality of users into a user exploration subset and a user exploitation subset; Determining at least one optimal hyperparameter for each user in the user exploitation subset; Using the at least one optimal hyperparameter to determine at least one decision support output for each user in the user exploitation subset; Randomly assigning at least one hyperparameter to each user in the user exploration subset; And Using the at least one randomly assigned hyperparameter to determine at least one decision support output for each user in the user exploration subset.

9. The method according to claim 8, wherein the initial exploration phase is further performed by: Using the at least one randomly assigned hyperparameter to determine a decision support output for each user in the plurality of users; Providing the decision support output to each user in the plurality of users; And Receiving monitoring data for each user in the plurality of users, wherein the monitoring data provides information about at least one physiological condition.

10. The method according to claim 9, wherein the training data further includes the monitoring data, and the training phase is further performed by: determining the relationship between the monitoring data, the context data, and the values associated with the at least one randomly assigned hyperparameter.

11. The method according to claim 8, wherein the at least one optimal hyperparameter for each user in the user exploitation subset is determined by: Assigning a plurality of experimental hyperparameters to each user in the exploitation subset; Determining at least one prediction result for each of the plurality of experimental hyperparameters; Determining a scalarization result for each of the plurality of experimental hyperparameters; And Determining the at least one optimal hyperparameter based on the scalarization result.

12. The method according to claim 11, further comprising: Performing a retraining phase by: Analyze training data, where the training data includes context data, values associated with randomly assigned hyperparameters of the user exploration subset, and monitoring data for the user exploration subset; and Determine the relationships among the context data, the values associated with the randomly assigned at least one hyperparameter of the user exploration subset, and the monitoring data for the user exploration subset.

13. The method according to claim 8, wherein the exploration-exploitation phase is performed using a contextual multi-armed bandit algorithm.

14. The method according to claim 11, wherein the at least one prediction result is determined using a policy assignment algorithm.

15. A computing device for determining user-specific hyperparameters for a decision support model, the computing device comprising: A network interface; A processor operatively connected to the network interface; A memory storing a program including instructions that, when executed by the processor, cause the computing device to: Perform an initial exploration phase by: Randomly assign at least one hyperparameter to each user among a plurality of users; Perform a training phase by: Analyze training data, where the training data includes context data and values associated with the randomly assigned at least one hyperparameter; and Determine the relationship between the context data and the values associated with the randomly assigned at least one hyperparameter; and Perform an exploration-exploitation phase by: Partition the plurality of users into a user exploration subset and a user exploitation subset; Determine at least one optimal hyperparameter for each user in the user exploitation subset; Use the at least one optimal hyperparameter to determine at least one decision support output for each user in the user exploitation subset; Randomly assign at least one hyperparameter to each user in the user exploration subset; and Use the randomly assigned at least one hyperparameter to determine at least one decision support output for each user in the user exploration subset.

16. The computing device according to claim 15, wherein the initial exploration phase is further performed by: Using the randomly assigned at least one hyperparameter, use a decision support model to determine a decision support output for each user among the plurality of users; Provide the decision support output to each user among the plurality of users; and Receive monitoring data for each user among the plurality of users, where the monitoring data provides information about at least one physiological condition.

17. The computing device according to claim 16, wherein the training data further includes the monitoring data, and the training phase is further performed by: determining the relationship among the monitoring data, the context data, and the values associated with the randomly assigned at least one hyperparameter.

18. The computing device according to claim 15, wherein the at least one optimal hyperparameter for each user in the user exploitation subset is determined by: Assign multiple experimental hyperparameters to each user in the exploitation subset; Determine a prediction result for each of the multiple experimental hyperparameters; Determine a scalarization result for each of the multiple experimental hyperparameters; and Determine the at least one optimal hyperparameter based on the scalarization result.

19. The computing device according to claim 15, wherein the exploration-exploitation phase is performed using a contextual multi-armed bandit algorithm.

20. The computing device according to claim 18, wherein the computing device is further configured to: Perform a retraining phase by: Analyze training data, where the training data includes context data, values associated with randomly assigned hyperparameters of the user exploration subset, and monitoring data for the user exploration subset; and Determine at least one prediction result for each user in the user exploration subset based on the relationship between the context data, the values associated with the at least one randomly assigned hyperparameter of the user exploration subset, and the monitoring data for the user exploration subset.

Images