Determining user-specific hyperparameters for decision support models

Abstract

In one embodiment, a non-transitory computer-readable storage medium is provided that stores 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; performing a training phase; and performing an exploration-exploitation phase by dividing users into an exploration subset and an exploitation subset, determining at least one optimal hyperparameter for each user in the exploitation subset, using the at least one optimal hyperparameter to determine at least one decision-support output for each user in the exploitation subset, randomly assigning the at least one hyperparameter to each user in the exploration subset, and using the at least one randomly assigned hyperparameter to determine at least one decision-support output for each user in the exploration subset.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 386,352, filed December 7, 2022, which is assigned to the assignee of the present application and is hereby expressly incorporated herein in its entirety for all applicable purposes as fully set forth below. [Background technology]

[0002] FIELD OF THE INVENTION This application relates generally to medical devices (e.g., analyte sensors), and more particularly to systems, devices, and methods for determining hyperparameters to improve patient health outcomes.

[0003] Description of Related Art Diabetes is a metabolic disease related to the body's production or use of insulin, a hormone that allows the body to use glucose for energy or store it as fat.

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

[0005] When the body does not produce enough insulin or cannot effectively use the insulin that is present, blood glucose levels can rise above the normal range. Higher-than-normal blood glucose levels are called "hyperglycemia." Chronic hyperglycemia can lead to many health problems, including cardiovascular disease, cataracts and other eye diseases, neuropathy, and kidney damage. Hyperglycemia can also lead to acute problems, such as diabetic ketoacidosis (a condition in which the body becomes excessively acidic due to the presence of blood glucose and ketone bodies, which are produced when the body can no longer use glucose). Lower-than-normal blood glucose levels are called "hypoglycemia." Severe hypoglycemia can lead to an acute crisis that can result in seizures or death.

[0006] Diabetics can receive insulin to manage blood glucose levels. Insulin can be received, for example, via manual injection with a needle. Wearable insulin pumps can also be used to receive insulin. Diet and exercise also affect blood glucose levels.

[0007] Diabetes is sometimes referred to as "type 1" and "type 2." Patients with type 1 diabetes are typically able to use insulin when it is available, but because of problems with the insulin-producing beta cells in the pancreas, the body is unable to produce sufficient amounts of insulin. Patients with type 2 diabetes are able to produce some insulin, but reduced sensitivity to insulin causes the patient to become "insulin resistant." As a result, even though insulin is present in the body, the patient's body does not use it effectively and blood sugar levels are not regulated effectively.

[0008] This background is provided to introduce a brief context for the summary and detailed description that follow. This background is not intended as an aid in determining the scope of the claims, nor is it intended to limit the claims to implementations that solve any or all of the disadvantages or problems discussed above. Summary of the Invention [Means for solving the problem]

[0009] Various embodiments of the present systems, devices, and methods for determining user-specific hyperparameters for decision support models to improve patient health outcomes comprise several features, no single one of which is solely responsible for their desirable attributes. Without limiting the scope of the present embodiments, their more prominent features are discussed below. After reviewing this discussion, and particularly after reading the section entitled "Detailed Description of the Invention," it will be understood how the features of the present embodiments provide the advantages described herein.

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

[0011] In one embodiment of the first aspect, the initial exploration phase is further performed by determining a decision support output for each user of the plurality of users using at least one randomly assigned hyperparameter, providing the decision support output to each user of the plurality of users, and receiving monitoring data for each user of the plurality of users, the monitoring data providing information regarding at least one physiological condition.

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

[0013] In another embodiment of the first aspect, at least one optimal hyperparameter for each user of the utilization subset of users is determined by assigning a plurality of experimental hyperparameters to each user of the utilization subset, determining at least one predicted outcome for each experimental hyperparameter of the plurality of experimental hyperparameters, determining a scalarized outcome for each experimental hyperparameter of the plurality of experimental hyperparameters, and determining the at least one optimal hyperparameter based on the scalarized outcome.

[0014] In another embodiment of the first aspect, the operations further include performing a retraining phase by analyzing training data, the training data including context data, values ​​associated with randomly assigned hyperparameters of the exploration subset of users, and monitoring data for the exploration subset of users, and determining a relationship between the context data, values ​​associated with at least one randomly assigned hyperparameter of the exploration subset of users, and the monitoring data for the exploration subset of users.

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

[0016] In another embodiment of the first aspect, the at least one predicted outcome is determined using a tactical allocation algorithm.

[0017] In a second aspect, a method is provided 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 of a plurality of users; performing a training phase by analyzing training data, the training data including context data and a value associated with the at least one randomly assigned hyperparameter, and determining a relationship between the context data and the value associated with the at least one randomly assigned hyperparameter; and performing an exploration-exploitation phase by dividing the plurality of users into an exploration subset of users and an exploitation subset of users, determining at least one optimal hyperparameter for each user in the exploitation subset of users, and determining at least one decision-support output for each user in the exploitation subset of users using the at least one optimal hyperparameter; randomly assigning at least one hyperparameter to each user in the exploration subset of users, and using the at least one randomly assigned hyperparameter to determine at least one decision-support output for each user in the exploration subset of users.

[0018] In one embodiment of the second aspect, the initial exploration phase is further performed by determining a decision support output for each user of the plurality of users using at least one randomly assigned hyperparameter, providing the decision support output to each user of the plurality of users, and receiving monitoring data for each user of the plurality of users, the monitoring data providing information regarding at least one physiological condition.

[0019] In another embodiment 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 contextual data, and a value associated with the at least one randomly assigned hyperparameter.

[0020] In another embodiment of the second aspect, at least one optimal hyperparameter for each user of the utilization subset of users is determined by assigning a plurality of experimental hyperparameters to each user of the utilization subset, determining at least one predicted outcome for each experimental hyperparameter of the plurality of experimental hyperparameters, determining a scalarized outcome for each experimental hyperparameter of the plurality of experimental hyperparameters, and determining the at least one optimal hyperparameter based on the scalarized outcome.

[0021] In another embodiment of the second aspect, the method further includes performing a retraining phase by analyzing training data, the training data including context data, values ​​associated with randomly assigned hyperparameters of the exploration subset of users, and monitoring data for the exploration subset of users, and determining relationships between the context data, values ​​associated with at least one randomly assigned hyperparameter of the exploration subset of users, and the monitoring data for the exploration subset of users.

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

[0023] In another embodiment of the second aspect, the training phase is performed using a tactical allocation algorithm.

[0024] 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; and 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 assigning at least one hyperparameter to each user of a plurality of users; and analyzing training data, the training data including context data and a value associated with the at least one randomly assigned hyperparameter, and determining user-specific hyperparameters for the context data and the at least one randomly assigned hyperparameter. performing a training phase by determining a relationship between values ​​associated with the parameters; and performing an exploration-exploitation phase by dividing the plurality of users into an exploration subset of users and an exploitation subset of users, determining at least one optimal hyperparameter for each user in the exploitation subset of users, determining at least one decision-support output for each user in the exploitation subset of users using the at least one optimal hyperparameter, randomly assigning the at least one hyperparameter to each user in the exploration subset of users, and using the at least one randomly assigned hyperparameter to determine at least one decision-support output for each user in the exploration subset of users.

[0025] In one embodiment of the third aspect, the initial exploration phase is further performed by determining a decision support output for each user of the plurality of users using the decision support model using at least one randomly assigned hyperparameter, providing the decision support output to each user of the plurality of users, and receiving monitoring data for each user of the plurality of users, the monitoring data providing information regarding at least one physiological condition.

[0026] 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 contextual data, and a value associated with the at least one randomly assigned hyperparameter.

[0027] In another embodiment of the third aspect, at least one optimal hyperparameter for each user of the utilization subset of users is determined by assigning a plurality of experimental hyperparameters to each user of the utilization subset, determining at least one predicted outcome for each experimental hyperparameter of the plurality of experimental hyperparameters, determining a scalarized outcome for each experimental hyperparameter of the plurality of experimental hyperparameters, and determining the at least one optimal hyperparameter based on the scalarized outcome.

[0028] In another embodiment of the third aspect, the computing device is further configured to perform the retraining phase by analyzing the training data, the training data including contextual data, values ​​associated with randomly assigned hyperparameters of the exploration subset of users, and monitoring data of the exploration subset of users, and determining a relationship between the contextual data, values ​​associated with at least one randomly assigned hyperparameter of the exploration subset of users, and the monitoring data of the exploration subset of users.

[0029] In another embodiment of the third aspect, the exploration-exploitation phase is performed using a contextual multi-armed bandit algorithm. [Brief explanation of the drawings]

[0030] [Figure 1A] 1 illustrates an exemplary health monitoring and assistance system, according to certain embodiments of the present disclosure. [Figure 1B] 1 illustrates a continuous analyte monitoring system according to certain embodiments of the present disclosure. [Figure 2] 1 illustrates example inputs and example metrics generated based on the inputs, according to certain embodiments of the present disclosure. [Figure 3] 1 is a flow diagram illustrating a process for determining decision support outputs based on user-specific hyperparameters, according to certain embodiments of the present disclosure. [Figure 4] 4 is a flow diagram illustrating a process for performing an initial search phase of the process of FIG. 3 in accordance with certain embodiments of the present disclosure. [Figure 5] 4 is a flow diagram illustrating a process for performing the training phase of the process of FIG. 3 in accordance with certain embodiments of the present disclosure. [Figure 6] 4 is a flow diagram illustrating a process for performing the exploration-exploitation phase of the process of FIG. 3 according to certain embodiments of the present disclosure. [Figure 7] 1 is a flow chart illustrating a process for determining decision support outputs for a utilization subset of users according to certain embodiments of the present disclosure. [Figure 8] 10 is a flow chart illustrating a process for determining a decision support output for a search subset of users according to certain embodiments of the present disclosure. [Figure 9] 1 is a flow chart illustrating an exemplary operational process for determining decision support outputs based on user-specific hyperparameters, in accordance with certain embodiments of the present disclosure. [Figure 10] FIG. 1 is a block diagram depicting a computing device configured to determine user-specific hyperparameters for use with a decision support model, according to certain embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0031] 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") are rapidly becoming renowned for their ability to support user-centered care. For example, managing diabetes can pose complex challenges to patients, clinicians, and caregivers, as a large constellation of factors can affect a patient's glucose levels and glucose trends. To assist patients in better managing 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. The widespread adoption of such health monitoring devices and the increased development and distribution of mobile health applications have improved health management, and more specifically, chronic disease management, in the healthcare field. 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, 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.

[0032] Mobile health applications enable users to become more involved in their own healthcare by granting them access to and control of their health information. In particular, mobile health applications allow users to access, monitor, record, and update their health information regardless of physical constraints such as time and location. In particular, various intervention applications have been developed to provide guidance that may assist patients, caregivers, healthcare providers, or other users in improving their lifestyles or clinical / patient outcomes by addressing various issues such as analyte management, exercise, and / or other health factors. As used herein, the term “analyte” refers to, but is not limited to, a substance or chemical constituent in a body or biological sample. For example, diabetes intervention applications may assist patients, caregivers, healthcare providers, or other users in overnight glucose management (e.g., reducing the incidence of hypoglycemic events or hyperglycemic excursions), prandial and post-prandial glucose management (e.g., using historical information and trends to improve glycemic control), hyperglycemic correction (e.g., increasing time in the target zone while avoiding hypoglycemic events due to over-correction), and / or hypoglycemic treatment (e.g., addressing hypoglycemia while avoiding “rebound” hyperglycemia), to name a few.

[0033] Mobile health applications may provide such assistance to users through some form of guidance. For example, guidance may include a graphical overview of the user's data over time or mobile notifications to the user, which may be provided to inform, alert, and / or recommend some action. As an example, an application may help users respond to their health status in real time by predicting events or trends and provide treatment recommendations to address emerging or potential events or trends in real time. This type of computed guidance and assistance may reduce the cognitive burden on the user. Some mobile health applications also allow data to be exported in various formats and shared with third parties and / or connect users directly with healthcare professionals for feedback, helping to improve patient-professional interactions. Thus, when utilized, mobile health applications offer the potential to improve the quality of care while simultaneously reducing costs to the healthcare system.

[0034] 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 administration of various treatments and medications, and mobile health and wellness monitoring. Portability is a central feature of these health monitoring devices. Thus, when utilized continuously, these devices can provide many benefits, including improved access to information, reduced medical errors, improved quality of care, etc.

[0035] To be an effective assistance tool, it may be desirable for a health monitoring device and / or application to continuously or frequently capture the user's attention and stimulate the user's interest so that they actively engage with the device and / or application. Engagement refers to the degree of interaction a user has with a technology, e.g., a device and / or application. Because health technologies, including health monitoring devices and mobile health applications, are voluntary-use systems, the degree of user engagement with these technologies is generally determined by the user's perceived quality of experience, the continued benefits of use, and / or consideration of viable alternatives to using the technology.

[0036] As discussed herein, unfortunately, health monitoring systems, such as health monitoring devices and / or mobile health applications designed to assist in the management of chronic diseases or health conditions, suffer from low user engagement and high user attrition rates. Reasons for low user engagement and / or high user attrition rates may include the inability of the health monitoring system to provide individualized or personalized decision-support output (e.g., information, recommendations, alerts, etc.). When a mobile health application fails to provide individualized and / or personalized decision-support output, users of the application may perceive the output as ineffective in enabling them to implement a holistic approach to managing their health (e.g., a disease, condition, health state, etc.). Furthermore, decision-support output that is not tailored to an individual (i.e., not “individualized”) may result in suboptimal health outcomes. In addition, decision-support output that is not tailored to a cohort of which an individual is a member (i.e., not “personalized”) may also result in suboptimal health outcomes. As used herein, a “cohort” may be a set of “similar” users with similar demographics, health history, and / or other characteristics that affect outcomes. Thus, user engagement associated with such mobile health applications may decrease, which may increase user attrition rates.

[0037] As described 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 user's monitored physiological state. The user may then use a software application configured to run on the user's display device to receive the sensor outputs. In certain embodiments, the application may utilize one or more decision support models to provide the user with decision support outputs based on the sensor outputs. For example, the decision support outputs may describe recommended actions for the user to take (e.g., recommended sleep patterns for the user) or recommended warnings to the user regarding the user's predicted future physiological state (e.g., a warning that the user is likely to experience hyperglycemia within the next eight hours).

[0038] The decision support model may be a user-aware 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 may include a scoring sub-model and a decision making sub-model. The scoring sub-model may be configured to determine one or more risk scores for the user, each risk score describing the predicted likelihood that the user will experience a particular condition (e.g., hyperglycemia or hypoglycemia) in a future period (e.g., the next 8 hours). The scoring sub-model may be a trained machine learning model characterized by one or more trained parameters. The decision making sub-model may be configured to select a decision support output for the user from a set of potential decision support outputs based on the risk score for the user.

[0039] The decision-making submodel may be characterized by one or more hyperparameters that define thresholds / states for one or more risk scores. Each potential decision-support output is associated with a respective subset of thresholds / states defined by the hyperparameters of the decision-making submodel. If the user's risk score meets the threshold / state associated with the potential decision-support output, the decision-making submodel selects the potential decision-support output to provide the decision-support output to the user.

[0040] An example of a decision support model is a sleep advisor model 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 a predicted likelihood that the user will experience hyperglycemia within a future period (e.g., the next 8 hours) and the hypoglycemia risk score describes a predicted likelihood that the user will experience hypoglycemia within the future period.

[0041] 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: a hyperglycemia risk threshold and a hypoglycemia risk threshold. For example, the set of potential sleep patterns may include an 8-hour sleep pattern and a 10-hour sleep pattern. In this example, if the user's hyperglycemia risk score meets a first threshold and the user's hypoglycemia risk score meets a second threshold, the 8-hour sleep pattern may be recommended to the user. If the user's hyperglycemia risk score meets a third threshold and the user's hypoglycemia risk score meets a fourth threshold, the 10-hour sleep pattern may be recommended to the user. These four thresholds may be defined by the hyperparameters of the decision-making sub-model of the sleep advisor model.

[0042] Another example of a decision support model is a hyperglycemia alert model configured to alert a user if the hyperglycemia alert model determines that the user is at risk for hyperglycemia in a future time period. In this example, the scoring sub-model of the hyperglycemia alert model is configured to determine a hyperglycemia risk score for the user based on sensor outputs associated with the user, while the decision-making sub-model of the hyperglycemia alert model is configured to determine that a hyperglycemia alert should be presented to the user if the user's hyperglycemia risk score meets (e.g., exceeds) a hyperglycemia risk threshold.

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

[0044] As the above example illustrates, a decision support model may be associated with a set of trained parameters and a set of adjustable / selectable hyperparameters. The above example further illustrates that a decision support model may have any number of hyperparameters, and the number of hyperparameters of a decision support model may be a function of the number of risk scores that the scoring sub-model of the decision support model determines for a user and the number of potential decision support outputs that can be assigned to a user by the decision support sub-model of the decision support model.

[0045] Selecting user-specific hyperparameters (also referred to herein as “optimal hyperparameters”) for a decision support model is important to ensure that the decision support output recommended by the model effectively responds to the user's needs. Without optimal hyperparameters, the decision support output recommended by the decision support model cannot consider the user's individualized or personalized needs as determined based on the user's health journey and the user's demographic characteristics. As explained above, providing users with ineffective decision support outputs ultimately leads to higher user attrition rates from health-related applications that enable users to monitor their physiological conditions to help them better manage their health. Accordingly, many existing health-related applications suffer from high user attrition rates and low user engagement rates resulting from an inability to provide individualized or personalized decision support outputs. In this context, personalization refers to determining a decision support output by a decision support model whose hyperparameters are optimized for the state of an individual user, while individualization refers to providing a decision support output by a decision support model whose hyperparameters are optimized for the state of a cohort of users (e.g., a cohort of users determined based on one or more demographic criteria, such as based on age).

[0046] Thus, embodiments herein provide a decision support model whose hyperparameters are determined specifically for a user, thereby enabling the decision support output to be user-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 users, such that the decision support output for each user is determined according to hyperparameters that are specifically assigned to one user and may differ from the hyperparameters assigned to other users. Determining and assigning per-user hyperparameters to users may be performed using a contextual multi-armed bandit (CMAB) algorithm, as further described below.

[0047] The multi-objective CMAB approach may provide various benefits, including, but not limited to, allowing a decision support model to optimize and assign hyperparameters for users as efficiently as possible. For example, the multi-objective CMAB approach avoids the need to "test" many different hyperparameter values ​​to see what works best for each individual user. Instead, the multi-objective CMAB approach involves training the algorithm to learn what the relationship is between user characteristics and optimal hyperparameter values ​​that result in optimal outcomes for the user. In particular embodiments, the multi-objective CMAB algorithm assigns one or more hyperparameters to users in a manner that both: (i) maximizes the likelihood that the decision support output generated based on the assigned hyperparameters will lead to two or more outcomes / objectives of interest (e.g., a first outcome / objective of preventing the user from having glucose levels below an optimal glucose range and a second outcome / objective of preventing the user from having glucose levels above the optimal glucose range), and (ii) explores new values ​​for the hyperparameters while leveraging already-detected relationships between the hyperparameters and the two or more outcomes / objectives of interest.

[0048] The systems, devices, and methods of the embodiments described herein can be used in conjunction 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 conjunction with any health-related application provided to a user to improve the user's health. For example, a health-related application may help a user treat a particular disease or help improve the health of a user who has not necessarily been diagnosed with a disease.

[0049] Exemplary system having a decision support engine for determining decision support outputs based on user-specific hyperparameters 1A illustrates an exemplary health monitoring and assistance system according to certain embodiments of the present disclosure. Health monitoring and assistance system 100 may be utilized to monitor a user's health, determine user-specific hyperparameters for a decision support model, and provide decision support to users associated with system 100. Each user of system 100, such as user 102, may interact with a mobile health application, such as mobile health application (“application”) 106 (e.g., a diabetes intervention application that provides decision support guidance), and / or a health monitoring device, such as analyte monitoring system 104 (e.g., a glucose monitoring system). User 102 may, in certain embodiments, be a patient or, in some cases, a caregiver for a patient. In embodiments described herein, the user is assumed to be a patient solely for simplicity, but is not so limited. As shown, system 100 may include analyte monitoring system 104, a mobile device 107 running application 106, a decision support engine 112 (including a Data Analysis Module (DAM) 111), and a user database 110.

[0050] The analyte monitoring system 104 may be configured to, for example, continuously generate analyte measurements for the user 102 and transmit the analyte measurements to the mobile device 107 for use by the application 106. In some embodiments, the analyte monitoring system 104 may transmit the analyte measurements to the mobile device 107 via a wireless connection (e.g., a Bluetooth connection). In particular embodiments, the mobile device 107 is a smartphone. However, in particular embodiments, the mobile device 107 may instead be any other type of computing device, such as a laptop computer, a smartwatch, a tablet, or any other computing device capable of running the application 106.

[0051] In particular examples, it is assumed that the analyte monitoring system 104 is a glucose monitoring system, although it should be noted that the analyte monitoring system 104 may operate to monitor one or more additional or alternative analytes. As discussed, the term "analyte" as used herein is a broad term and is given its ordinary and customary meaning to those of skill in the art (and is not limited to any special or customized meaning) and refers to, but is not limited to, a substance or chemical constituent in a body or a biological sample (e.g., bodily fluids, including blood, serum, plasma, interstitial fluid, cerebrospinal fluid, lymphatic fluid, ocular fluid, saliva, oral fluid, urine, feces, or exudates). Analytes may include naturally occurring substances, man-made substances, metabolites, and / or reaction products. In some embodiments, the analytes for measurement by the sensing regions, devices, and methods are albumin, alkaline phosphatase, alanine transaminase, aspartate aminotransferase, 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.

[0052] Other analytes considered include 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, and acarboxyproline. Thrombin; acylcarnitines; adenine phosphoribosyltransferase; adenosine deaminase; albumin; alpha-fetoprotein; amino acid profile (arginine (Krebs cycle), histidine / urocanic acid, homocysteine, phenylalanine / tyrosine, tryptophan); andrenostenedione; antipyrine; arabinitol enantiomers; arginase; benzoylecgonine (cocaine); biotinidase; biopterin; c-reactive protein; carnitine; carnosinase; CD4; ceruloplasia amine; chenodeoxycholic acid; chloroquine; cholesterol; cholinesterase; conjugated 1-β-hydroxycholic acid; cortisol; creatine kinase; creatine kinase MM isoenzyme; cyclosporine A; d-penicillamine; deethylchloroquine; dehydroepiandrosterone sulfate; DNA (acetylation polymorphisms, alcohol dehydrogenase, alpha 1-antitrypsin, cystic fibrosis, Duchenne / 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's 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 acids / acylglycines; free beta-human chorionic gonadotropin; free erythrocyte porphyrin;Free thyroxine (FT4); free triiodothyronine (free tri-iodothyronine, FT3); fumarylacetoacetase; galactose / gal-1-phosphate; galactose-1-phosphate uridyltransferase; gentamicin; glucose-6-phosphate dehydrogenase; glutathione; glutathione peroxidase; glycocholate; glycosylated hemoglobin; halofantrine; hemoglobin variants; hexosaminidase A; human erythrocyte carbonic anhydrase I; 17-alpha-hydroxyprogesterone; hypoxanthine phosphoribosyltransferase; immunoreactive trypsin; lactate; lead; lipoproteins ((a), B / A-1, β); lysozyme; mefloquine; netilmicin; phenobarbitone; phenytoin; phytanic acid / pristanic acid; progesterone; prolactin; prolidase; purine nucleoside phosphorylase; quinine; reverse triiodothyronine tri-iodothyronine, rT3); selenium; serum pancreatic lipase; sisomicin; somatomedin C; specific antibodies (adenovirus, antinuclear antibody, anti-zeta antibody, arbovirus, pseudorabies virus, dengue virus, guinea worm, Echinococcus granulosus, Entamoeba histolytica, enterovirus, giardiasis, Helicobacter pylori, hepatitis B virus, herpes virus, HIV-1, IgE (atopic disease), influenza virus, Leishmania donovani, Leptospirosis, measles / mumps / rubella, Mycobacterium leprae, Mycoplasma pneumoniae, myoglobin, Onchocerciasis volvulus, parainfluenza) Viruses, malaria parasites, poliovirus, Pseudomonas aeruginosa, respiratory syncytial virus, rickettsia (tsutsugamushi disease), Schistosoma mansoni, Toxoplasma gondii, Treponema pallidum, Trypanosoma cruzi / rangeli, vesicular stomatitis virus, Wuchereria bancrofti, yellow fever virus); specific antigens (hepatitis B virus, HIV-1); succinylacetone; sulfadoxine; theophylline; thyrotropin (TSH); thyroxine (T4); thyroxine-binding globulin; trace elements; transferrin; UDP-galactose-4-epimerase; urea; uroporphyrinogen I synthase; vitamin A; leukocytes;and zinc protoporphyrin. Salts, sugars, proteins, fats, vitamins, and hormones naturally present in blood or interstitial fluid can also constitute analytes in certain embodiments.

[0053] The analyte may be naturally occurring in a biological fluid, e.g., a metabolite, hormone, antigen, antibody, etc. Alternatively, the analyte may be introduced into the body, e.g., a contrast agent for imaging, a radioisotope, a chemical agent, a fluorocarbon-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, chlorohydrocarbons, hydrocarbons); cocaine (crack cocaine); stimulants (amphetamine, methamphetamine, Ritalin, Silurt, Preludine, Didrex, Prestate, Boranil, Sandrex, Pregin); depressants (barbiturates, methaqualone, valium tranquilizers such as benzodiazepines, ... Analytes such as neurochemicals and other chemicals produced in the body, such as ascorbic acid, uric acid, dopamine, noradrenaline, 3-methoxytyramine (3MT), 3,4-dihydroxyphenylacetic acid (DOPAC), homovanillic acid (HVA), 5-hydroxytryptamine (5HT), histamine, advanced glycation end products (AGEs), and 5-hydroxyindoleacetic acid (FHIAA), can also be analyzed.

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

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

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

[0057] In particular embodiments, the DAM 111 of the decision support engine 112 is configured to receive and / or process a set of inputs 127 (described in more detail below) (also referred to below as “input data”) to determine one or more metrics 130 (also referred to below as “metric data”), which the decision support engine 112 then uses to determine user-specific hyperparameters for the decision support model. The inputs 127 may be stored in a user profile 118 in the user database 110. The DAM 111 may fetch the inputs 127 from the user database 110 and calculate multiple metrics 130, which may be stored in the user profile 118 as application data 126. Such metrics 130 may include health-related metrics.

[0058] In certain embodiments, application 106 is configured to receive information about user 102 as input and store the information in user profile 118 for user 102 in user database 110. For example, application 106 may obtain and record demographic information 119, disease progression information 121, and / or medication information 122 for user 102 in user profile 118. In certain embodiments, demographic information 119 may include one or more of the user's age, body mass index (BMI), ethnicity, gender, etc. In certain embodiments, disease progression information 121 may include information about the user's 102 disease, such as, for diabetes, whether the user has type 1, type 2, pre-diabetes, or whether the user has gestational diabetes, etc. In certain embodiments, disease progression information 121 also includes length of time since diagnosis, level of disease control, level of adherence to disease management treatment, predicted pancreatic function, other types of diagnoses (e.g., heart disease, obesity), or health measures (e.g., heart rate, exercise, stress, sleep, etc.), etc. In certain embodiments, medication regimen information 122 may include information regarding the amount and type of medication taken by user 102, such as insulin or non-insulin diabetic and / or non-diabetic medications taken by user 102.

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

[0060] User database 110, in some embodiments, refers to a storage server that may operate in a public or private cloud. User database 110 may be implemented as any type of data store, such as a relational database, a non-relational database, a key-value data store, or a file system, including a hierarchical file system. In some example implementations, user database 110 is distributed. For example, user database 110 may comprise multiple distributed persistent storage devices. Furthermore, user database 110 may be replicated so that the storage devices are geographically distributed.

[0061] User database 110 may include other user profiles 118 associated with multiple other users serviced by health monitoring and decision support system 100. More specifically, similar to the actions performed with respect to user 102, actions performed with respect to these other users may utilize an analyte monitoring system, such as analyte monitoring system 104, and may interact with the same application 106, copies of which are running on the respective mobile devices of the other users 102. For such users, user profiles 118 are similarly created and stored in user database 110.

[0062] FIG. 1B illustrates a continuous analyte monitoring system according to certain embodiments of the present disclosure. FIG. 150 illustrates an example of an analyte monitoring system 104. In the example of FIG. 1B, the analyte monitoring system 104 is a glucose monitoring system. However, as described above, the analyte monitoring system 104 may be configured to measure any other analyte or combination of analytes. FIG. 1B illustrates several mobile devices 107a, 107b, 107c, and 107d (individually referred to as mobile device 107 and collectively referred to as mobile devices 107). Note that the mobile device 107 in FIG. 1A 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 may be configured to execute application 106. The analyte monitoring system 104 can be communicatively coupled to mobile devices 107a, 107b, 107c, and / or 107d.

[0063] By way of overview and example, analyte monitoring system 104 may be implemented as an encapsulated microcontroller that performs sensor measurements, generates analyte data (e.g., by calculating values ​​of continuous glucose monitoring system data), and engages in wireless communication (e.g., via Bluetooth and / or other wireless protocols) to transmit such data to a remote device, such as mobile device 107. Paragraphs

[0137] -

[0140] and Figures 3A, 3B, and 4 of U.S. Patent Application Publication No. 2019 / 0336053 further describe on-skin sensor assemblies that may, in certain embodiments, be used in connection with analyte monitoring system 104. Paragraphs

[0137] -

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

[0064] 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 hereinafter as "sensor output") or information, including algorithms associated with processing and / or calibrating the analyte sensor data / information. The analyte sensor electronics module 138 may be physically / mechanically connected to the analyte sensor 140 and may be integral with (i.e., non-releasably attached to) or releasably attached to the analyte sensor 140.

[0065] The analyte sensor electronics module 138 may also be electrically coupled to the analyte sensor 140 such that the components may be electromechanically coupled to one another. The analyte sensor electronics module 138 may include hardware, firmware, and / or software that enable measurement and / or estimation of the level of an analyte in a user via the analyte sensor 140 (e.g., which may be / may include a glucose sensor). For example, the analyte sensor electronics module 138 may include one or more potentiostats, a power supply for providing power to the analyte sensor 140, other components useful for signal processing and data storage, and a telemetry module for transmitting data from the sensor electronics module to 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 may be mounted on a printed circuit board (PCB), platform, or the like within the analyte monitoring system 104 and may take various forms. For example, the electronics may 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.

[0066] The analyte sensor electronics module 138 may 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, as well as in U.S. Pat. Nos. 7,310,544 and 6,931,327, and U.S. Patent Application Publication Nos. 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 entireties.

[0067] 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. Patent Application No. 2019 / 0336053. Paragraph

[0117] of U.S. Patent Application No. 2019 / 0336053 is incorporated herein by reference. In some embodiments, the analyte sensor 140 includes a continuous analyte sensor, such as a subcutaneous, transcutaneous (e.g., transdermal), 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, such as enzymatic, chemical, physical, electrochemical, spectrophotometric, polarimetric, calorimetric, iontophoretic, radiometric, or immunochemical method. Additional details regarding continuous analyte sensors, such as continuous glucose sensors, are provided in paragraphs

[0072] -

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

[0072] -

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

[0068] 1B , the mobile devices 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 packages transmitted to a display device based on their respective preferences). Each of the mobile devices 107a, 107b, 107c, and / or 107d may include a display, e.g., touchscreen display 109a, 109b, 109c, and / or 109d, respectively, for displaying a graphical user interface (e.g., application 106), for presenting sensor information and / or analyte data to the user 102 and / or for receiving input from the user 102. In certain embodiments, the mobile device 107 may include other types of user interfaces, such as a voice user interface, instead of or in addition to a touchscreen display for providing sensor information to the user 102 of the mobile device 107 and / or receiving user input. In particular embodiments, one, some, or all of the mobile devices 107 may be configured to display or otherwise communicate sensor information as communicated from the sensor electronics module 138 (e.g., in data packages sent to a respective display device) without any additional anticipated processing required for calibration and / or real-time display of the sensor data.

[0069] The mobile devices 107 may include custom or proprietary display devices, such as an analyte display device 107b, specifically designed to display a particular type of displayable sensor information (e.g., in certain embodiments, numerical values ​​and / or arrows) 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).

[0070] Exemplary inputs and exemplary metrics generated based on the inputs, according to certain embodiments of the present disclosure, are illustrated in FIG. 2. FIG. 2 illustrates exemplary inputs 127 on the left, application 106 and DAM 111 in the center, and exemplary metrics 130 on the right. In certain embodiments, application 106 obtains inputs 127 via one or more channels (e.g., manual user input, sensors, other applications running on mobile device 107, etc.). Inputs 127 may be further processed by DAM 111 to output multiple metrics, such as metric 130. In certain embodiments, inputs 127 and metrics 130 may also be used as context information by DAM 111 and / or any computing device in system 100 to take various actions, such as, but not limited to, identifying cohorts and / or defining various subgroups within user cohorts. Additionally, the inputs (e.g., inputs 127) and metrics (e.g., metrics 130) may be used by DAM 111 and / or any computing device in system 100 to perform various processes in determining user-specific hyperparameters for a decision support model, as described further below. Any of the inputs 127 may be used to calculate any of the metrics 130. In particular embodiments, each of the metrics 130 may correspond to one or more values, for example, a discrete value, a range, or a qualitative value (high / medium / low, or stable / unstable).

[0071] In certain embodiments, input 127 includes food consumption information. Food consumption information may include information about one or more of meals, snacks, and / or beverages, such as one or more of the amount, content (carbohydrates, fat, protein, etc.), order of consumption, and time of consumption. In certain embodiments, food consumption may be provided by a user through manual input, by providing a photograph through an application configured to recognize food types and amounts, and / or by scanning a barcode or menu. In various examples, meal amounts may be manually entered as one or more of calories, amount (e.g., "3 cookies"), menu items (e.g., "Royale with Cheese"), and / or food exchanges (1 fruit, 1 dairy product). In some examples, meals may also be entered along with the user's typical items or combinations for this time or context (e.g., weekday breakfast at home, weekend brunch at a restaurant). In some examples, meal information may be received through a convenient user interface provided by application 106.

[0072] In particular embodiments, input 127 includes activity information. Activity information may be provided by, for example, an acceleration sensor on a wearable device such as a watch, a fitness tracker, and / or a patch. In particular embodiments, activity information may also be provided through manual input by user 102.

[0073] In certain embodiments, input 127 includes patient demographics such as one or more of age, height, weight, body mass index, body composition (e.g., body fat percentage), build, body type, or other information. Patient demographics may be provided through a user interface, by interfacing with an electronic source such as an electronic medical record, and / or from a measurement device. The measurement device may include, for example, one or more of a wireless, e.g., Bluetooth-enabled, scale, and / or camera that may communicate with mobile device 107 to provide patient data.

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

[0075] In particular embodiments, input 127 includes information received from a sensor, such as a physiological sensor, which may detect one or more of heart rate, respiration, oxygen saturation, body temperature, etc. (e.g., to detect illness).

[0076] In certain embodiments, input 127 includes glucose information. Such information may be provided as an input, for example, through analyte monitoring system 104. In certain embodiments, blood glucose information may be received from one or more of a smart pill dispenser that tracks when a user takes medication, a blood ketone meter, laboratory-measured or estimated AlC, other measures of long-term management, or a sensor that measures peripheral neuropathy using a tactile response, such as by using the tactile features of a smartphone or specialized device.

[0077] In certain embodiments, input 127 includes a time, for example, the time of day or the time from a real-time clock.

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

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

[0080] In certain embodiments, metrics 130 determined or calculated by the DAM 111 include an insulin sensitivity metric (also referred to hereinafter as "insulin resistance"). The insulin sensitivity metric may be determined using historical data, real-time data, or a combination thereof and may be based on one or more inputs 127, such as, for example, one or more of food consumption information, blood glucose information, insulin administration information, resulting glucose levels, etc. In certain embodiments, the insulin on-board metric may be determined using insulin administration information and / or a known or learned (e.g., from patient data) insulin time-action profile that may account for both basal metabolic rate (e.g., insulin updates to maintain physical activity) and insulin use driven by activity or food consumption.

[0081] In certain embodiments, the metrics 130 determined or calculated by the DAM 111 include meal state metrics. The meal state metrics may indicate the user's state with respect to food consumption. For example, the meal state may indicate whether the user is in one of a fasting state, a pre-meal state, a fed state, a post-meal reaction state, or a stable state. In certain embodiments, the meal state may also indicate nourishment on board, such as meals, snacks, or beverages consumed, which may be determined from food consumption information, mealtime information, and / or digestibility information, which may be correlated to food type, amount, and / or order (e.g., which food / drink was eaten first).

[0082] In particular embodiments, the metrics 130 determined or calculated by the DAM 111 include health and illness metrics. The health and illness metrics may be determined, for example, from physiological sensors (e.g., temperature), activity sensors, or a combination thereof, based on one or more of user inputs (e.g., pregnancy information or known illness information). In particular embodiments, based on the values ​​of the health and illness metrics, for example, the user's state may be defined as one or more of healthy, sick, rested, or fatigued.

[0083] In certain embodiments, the metrics 130 determined or calculated by the DAM 111 include a glucose level metric. The glucose level metric may be determined from sensor information (e.g., blood glucose information obtained from the analyte monitoring system 104). In some examples, the glucose level metric may also be determined, for example, based on historical information regarding glucose levels in particular situations, for example, taking into account a given combination of food consumption, insulin, and / or activity. In certain embodiments, a blood glucose trend may be determined based on glucose levels over a particular period of time.

[0084] In certain embodiments, the metrics 130 determined or calculated by the DAM 111 include a disease stage. For example, disease stages for type 2 diabetes may include a prediabetes stage, an oral treatment stage, and a basal insulin treatment stage. In certain embodiments, the degree of glycemic control (not shown) may also be determined as an outcome metric and may be based, for example, on one or more of glucose levels, glucose level variability, or insulin dosing patterns.

[0085] In certain embodiments, the metrics 130 determined or calculated by the DAM 111 include clinical metrics. Clinical metrics generally indicate the clinical state a user is in with respect to one or more of the user's conditions, such as diabetes. For example, in the case of diabetes, clinical metrics may be determined based on blood glucose measurements including one or more of A1C, A1C trend, time in range, time spent below a threshold level, time spent above a threshold level, and / or other metrics derived from blood glucose levels. In certain embodiments, clinical metrics may also include one or more of estimated A1C, blood glucose variability, hypoglycemia, and / or health indicators (amount of time out of target zone).

[0086] As discussed herein, the DAM 111 and / or application 106 may execute on one or more computing devices to perform various processes for determining user-specific hyperparameters for a decision support model. For example, such processes may include performing (1) an initial exploration phase, (2) a training phase, and (3) an exploration-exploitation phase, as described further below. For example, the initial exploration phase may be performed by assigning a random set of hyperparameters, determining and providing decision support outputs, and monitoring a physiological state through analysis of monitoring data. In particular embodiments, the monitoring data may include any data that provides information about a user's physiological state, including, but not limited to, inputs 127 and other metrics 130.

[0087] As described further below, the training phase may be performed by applying training data to an outcome prediction model to determine predicted outcomes. In some embodiments, the training data may include user input data (e.g., contextual data, inputs 127, etc.), hyperparameter input data (e.g., values ​​associated with hyperparameters), and / or monitoring data. In particular embodiments, the contextual data may be personal (based on cohort data) or individualized (based on specific user data).

[0088] Additionally, the exploration-exploitation phase may be performed by dividing the set of users into an exploration subset and an exploitation subset of users. In particular embodiments, the exploration-exploitation phase may also include determining a decision-support output for the exploitation subset of users using an experiment set of hyperparameters, determining one or more predicted outcomes, and determining one or more scalarized outcomes. In various embodiments, the exploration-exploitation phase may also include selecting and assigning an experiment set of hyperparameters having an optimal scalarized outcome, and determining a decision-support output using the optimal set of hyperparameters. Furthermore, the computing device may monitor the user's physiological state to observe a set of outcomes of interest (e.g., time above and time below an 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. In particular embodiments, (2) the training phase (also referred to herein as the “retraining phase”) and (3) the exploration-exploitation phase may be repeated to further improve the user-specific hyperparameters for the decision-support model. In such an embodiment, a retention phase may be performed using data from the user's previous search subset, as further described below.

[0089] Exemplary Process for Determining Decision Support Outputs Based on User-Specific Hyperparameters 3 is a flow diagram illustrating a 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 may include a set of hyperparameters for each user in the set of users. The user-specific hyperparameters may be determined using a multi-objective CMAB algorithm executed by a computing device. The computing device may be part of the health monitoring and assistance system 100, such as a computing device executing the decision support engine 112 or a back-end server (not shown).

[0090] 3 , process 300 may include performing an initial exploration phase (block 302), as described further 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 hyperparameter set, and provides the decision-support output to the user. The initial exploration phase may also include monitoring physiological conditions to observe one or more outcomes of interest (e.g., time above and time below an 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.

[0091] Additionally, process 300 may include performing a training phase (block 304), as described further 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 “tactical allocation algorithm”). The outcome prediction model is a machine learning model configured to determine a set of predicted outcomes and respective sets of hyperparameters for a particular user. Each predicted outcome is a result predicted to occur if the user is provided with a decision-support output determined based on the respective set of hyperparameters and / or if the user performs an action recommended by the decision-support output. One example of a predicted outcome for a user and the respective set of hyperparameters includes the predicted duration the user will be above the optimal glucose range if the user is provided with a decision-support output determined using the respective set of hyperparameters. Another example of a predicted outcome is the predicted duration the user will be below the optimal glucose range if the user is provided with a decision-support output determined using the respective set of hyperparameters.

[0092] Additionally, process 300 may also include performing an exploration-exploitation phase (block 306). During the exploration-exploitation phase, the computing device divides the set of users into an exploitation subset and an exploration subset. For 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. For users in the exploration subset, the computing device continues to randomly assign hyperparameters to those users.

[0093] After assigning hyperparameters to each user, the computing device determines a decision-support output for the user based on the decision-support model using each user's assigned hyperparameters. Further, the computing device provides the determined decision-support output to the user and monitors the user's physiological state to observe a set of outcomes of interest (e.g., time above and time below an 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.

[0094] 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 / illness, glucose level, glucose trend, disease stage, etc.) have improved or deteriorated. For example, if a decision-support output is provided to a user based on user-specific hyperparameters but the monitoring data indicates that the user's metrics have worsened, process 300 may determine to perform a retention phase (block 308). In another example, if a decision-support output is provided to a user based on user-specific hyperparameters but the monitoring data indicates that the user's metrics have not improved or have not improved sufficiently, process 300 may determine to perform a retention phase (block 308). In some embodiments, process 300 may determine to retrain periodically (e.g., monthly regardless of performance). In some embodiments, process 300 may decide to retrain periodically, whenever the sample size of the user's search set of hyperparameters and observations reaches a threshold number (e.g., 10,000). In some embodiments, process 300 may decide to retrain if it observes that, for the user's utilization subset, predicted outcomes for optimal hyperparameters begin to deviate from subsequent observations by more than a threshold amount.

[0095] If process 300 determines to perform a retraining phase (block 308), process 300 may repeat blocks 304 and 306. In subsequent iterations of block 304, the computing device proceeds to retrain the outcome prediction machine learning model (block 304) using data from the exploration subset of users (e.g., randomly assigned hyperparameter(s), user context, and observed outcomes). Further, in subsequent iterations of block 306, the computing device performs an exploration-exploitation phase using the retrained outcome prediction model, including determining and providing new decision support outputs to the user (block 306).

[0096] Blocks 302, 304, and 306 will be described in more detail below with reference to the following Figures 4 to 8. In particular, block 302 of Figure 3 will be described in more detail with reference to blocks 402 to 408 of Figure 4. Furthermore, block 304 of Figure 3 will be described in more detail with reference to block 502 of Figure 5. Furthermore, block 306 of Figure 3 will be described in more detail with reference to blocks 602 to 606 of Figure 6. In particular, block 604 of Figure 6 will be described in more detail with reference to blocks 702 to 710 of Figure 7. After block 604, block 606 of Figure 6 will be described in more detail with reference to blocks 802 and 804 of Figure 8.

[0097] 1. Block 302: Perform an initial discovery phase As described above with reference to FIG. 3, process 300 may include performing an initial exploration phase (block 302). FIG. 4 is a flow diagram illustrating a process 400 for performing the initial exploration phase (block 302) of FIG. 3 according to certain embodiments of the present disclosure. Process 400 includes randomly assigning one or more hyperparameters to each user (block 402). For example, a computing device randomly assigns a set of hyperparameters to each user. In some embodiments, to randomly assign hyperparameters to users, the computing device randomly selects values ​​from the hyperparameter's allowable range. In some embodiments, to randomly assign hyperparameters to users, the computing device first determines a cohort-specific range for the hyperparameter based on a cohort of users, and then randomly selects a value from the cohort-specific range. For example, the computing device may first determine that the hyperglycemia risk threshold for women aged 20-30 should be 0.2-0.7, and then randomly select a value from the range (0.2, 0.7) for a user who is a 25-year-old woman.

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

[0099] In some embodiments, process 400 may include providing the determined decision-support output to the user (406). In the above example, if the hyperglycemia risk score determined by the scoring sub-model of the hyperglycemia alert model for the user is, for example, 0.6, the decision-making sub-model may determine that a hyperglycemia alert should be communicated to the user because 0.6 is greater than the threshold of 0.5. In particular embodiments, process 400 may include monitoring the user's physiological condition (block 408) to observe a set of outcomes of interest. For example, the computing device may provide a hyperglycemia alert and then monitor the user's glucose level. As another example, the computing device may provide the user with a recommendation, such as to exercise or drink water, and then monitor the user's glucose level after providing the recommendation(s) and / or after the user implements the recommendation(s).

[0100] 2. Block 304: Run the training phase As described above with reference to FIG. 3 , process 300 may include performing a training phase (block 304). FIG. 5 is a flow diagram illustrating a process 500 for performing the training phase (block 304) according to certain embodiments of the present disclosure. The training phase may be performed to initially train an outcome prediction model based on new monitoring data determined by monitoring the user's physiological state, or to retrain an already trained outcome prediction model. The outcome prediction model (also referred to herein as a “tactical allocation algorithm”) is a machine learning model configured to determine one or more predicted outcomes (e.g., a set of predicted outcomes) for each user when the respective users are provided with a decision-support output determined by the decision-support model according to a respective set of hyperparameters and / or when the respective users perform an action recommended by the decision-support output.

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

[0102] In particular embodiments, the training data may also include a set of training data entries, each of which may include contextual data associated with a respective user, data associated with a respective hyperparameter(s), and a set of monitoring / observations (e.g., monitoring data) that occurred after a decision-support output determined using the respective hyperparameter(s) was provided to the user and / or after the user performed an action recommended by the described decision-support output. In various embodiments, the training data for training the outcome prediction model may result from monitoring the user's physiological state after the decision-support output is provided to the user, and the decision-support output provided to the user may be determined using an initial exploration phase of operations (in an initial training context) or an exploration-exploitation phase of operations (in a retraining context) where retraining utilizes data from an exploration subset of the user.

[0103] 3. Block 306: Perform the Exploration-Exploitation Phase As described above with reference to FIG. 3, process 300 may include performing an exploration-exploitation phase (block 306). In particular embodiments, the exploration-exploitation phase may be performed using a multi-purpose CMAB. During the exploration-exploitation phase, the set of users may be divided into an exploration subset and an exploitation subset, and decision support outputs may be determined for both subsets of users.

[0104] FIG. 6 is a flow diagram illustrating a process 600 for performing the exploration-exploitation phase (block 306) according to certain embodiments of the present disclosure. Process 600 may include dividing a set of users into an exploration subset and an exploitation subset (block 602). For example, the set of users is first randomly divided into an exploration subset and an exploitation subset according to a search ratio ε. In particular, a portion of ε users is randomly selected and used to identify the exploration subset, and the remaining (1-ε) portion of users is used to identify the exploitation subset. In some embodiments, the magnitude of the search ratio ε decreases after each retraining of the outcome prediction model. In some embodiments, the magnitude of the search ratio ε is set to 0 after a predefined number of retraining of the outcome prediction model. In certain embodiments, the magnitude of the decrease in the search ratio ε may be a function of outcome model accuracy (which may improve over time). In addition, the search ratio ε may also have a lower bound > 0 to ensure that some degree of exploration is always performed, since what works best for users may change over time.

[0105] During the exploration-exploitation phase, the multi-objective CMAB model may also determine decision-support outputs for the user's exploitation subset and the user's exploration subset. Various exemplary processes for determining decision-support outputs for the user's exploration and exploitation subsets are further described below with reference to Figure 6. In particular, block 604 of Figure 6 describes determining decision-support outputs for the user's exploitation subset, and block 606 of Figure 6 describes determining decision-support outputs for the user's exploration subset.

[0106] a. Block 604: Determine decision support output for utilization subset The process 600 for performing the exploration-exploitation phase (block 306) may also include determining decision-support outputs for the exploitation subset of users (block 604). Various techniques can be used to determine decision-support outputs for the exploitation subset of users (block 604). For example, after assigning users to exploitation subsets, the following operations may be performed to determine decision-support outputs for the exploitation subset users:

[0107] 7 is a flow diagram illustrating a process 700 for determining a decision-support output for an exploitation subset of users (block 604) according to certain embodiments of the present disclosure. Process 700 may include assigning multiple experimental hyperparameters (e.g., two or more sets of experimental hyperparameters) to each user of the exploitation subset (block 702). In some embodiments, all potential hyperparameter sets that can be assigned to the decision-support model are experimentally assigned to all users in the exploitation subset. For example, if a 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 users. As another example, if a decision-support model is characterized by two hyperparameters that can take on B and C potential values, respectively, all B potential values ​​for the two hyperparameters are experimentally assigned to users. * The C pairs are experimentally assigned to users. In some embodiments (e.g., when at least one hyperparameter has a continuous range), a subset of all potential hyperparameter sets is randomly assigned to users in the exploitation subset. For example, if the decision support model is characterized by hyperparameters that can take on values ​​from a continuous range, a defined number of values ​​randomly selected from the continuous range may be experimentally assigned to users. In a further example of a hyperparameter having a continuous range, an interval may be defined to select the continuous hyperparameter. For example, if the accepted value is [0.2 to 0.8], the interval may be 0.01, and the experimentally assigned value may 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 exploitation subset.

[0108] 7, process 700 may include using an output prediction model to determine a predicted outcome (e.g., a set of predicted outcomes) for each experimental hyperparameter (e.g., for each set of experimental hyperparameters) (block 704). For example, after a set of experimental hyperparameters has been assigned to a user, an outcome prediction model may be used to determine a set of predicted outcomes for the user with respect to each set of experimental hyperparameters. In particular embodiments, input data for the user (e.g., contextual data) and input data for each of the sets of experimental hyperparameters (e.g., values ​​associated with the experimental hyperparameters) are provided to the outcome prediction model to determine a set of predicted outcomes for the user with respect to the set of experimental hyperparameters. For example, given a user who is a 25-year-old female user and has an empirically assigned hyperglycemia risk threshold of 0.43, the outcome prediction model may process contextual data associated with the user (e.g., age data, gender data, location data, and / or health history data) and the 0.43 hyperglycemia risk threshold to determine (i) the predicted time the user will be above the optimal glucose range if the user is provided with a decision support output determined using a hyperglycemia risk threshold of 0.43, and (ii) the predicted time the user will be below the optimal glucose range if the user is provided with a decision support output determined using a hyperglycemia risk threshold of 0.43. Thus, at the end of this step, a set of (e.g., two or more) predicted outcomes is determined for each set of experimental hyperparameters assigned to the user.

[0109] In particular embodiments, the output prediction model may determine one or more predicted outcomes specific to a user and the respective hyperparameter(s). For example, during each run, the outcome prediction model outputs a set of predicted outcomes specific to both the respective user and the respective set of hyperparameters. As further described above, training data, including but not limited to the respective user's contextual data, the respective set of hyperparameters (e.g., values ​​associated with the hyperparameter(s)), and observations (e.g., monitoring data), may be used as inputs to train the outcome prediction model. The output data resulting from each run of the outcome prediction model includes one or more predicted outcomes (e.g., a set of predicted outcomes), such as a combination of predicted times above and below the optimal glucose range. For example, in an exemplary implementation, the outcome prediction model processes each user's contextual data and each set of hyperparameters for the decision support model to determine (i) a predicted time to exceed the optimal glucose range when the respective user is provided with a decision support output generated by the decision support model based on the respective set of hyperparameters and / or when the respective user performs an action recommended by the written decision support output, and (ii) a predicted time to exceed the optimal glucose range when the respective user is provided with the written decision support output and / or when the respective user performs an action recommended by the written decision support output.

[0110] 7, process 700 may also include determining a scalarized result for each experimental hyperparameter (e.g., for each set of experimental hyperparameters) by combining the predicted results (e.g., sets of predicted results) (block 706). In particular embodiments, after determining a set of predicted results for each set of experimental hyperparameters, the sets of predicted results for the sets of experimental hyperparameters are combined to determine a scalarized result for the set of experimental hyperparameters. In some embodiments, the set of predicted results for the set of experimental hyperparameters includes two or more predicted results, such as a predicted duration for which the user is above the optimal glucose range if a decision-support output determined using the respective sets of hyperparameters is provided to the user, and a predicted duration for which the user is below the optimal glucose range if the decision-support output is provided to the user.

[0111] In some embodiments, the set of predicted outcomes for the set of experimental hyperparameters are combined according to a set of predefined outcome weights to generate a scalarized outcome for the set of experimental hyperparameters. For example, the scalarized outcome for a hyperglycemic risk threshold of 0.43 is calculated by weighting w1 * o1+w2 *where (i) o1 is the predicted duration the user will be above the optimal glucose range if the user is provided with a decision support output determined using the hyperglycemic risk threshold of 0.43, (ii) w1 is the resulting weight of o1, (iii) o2 is the predicted duration the user will be below the optimal glucose range if the user is provided with a decision support output determined using the hyperglycemic risk threshold of 0.43, and (ii) w2 is the resulting 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 hyperparameter sets is associated with a single scalarized outcome.

[0112] 7, process 700 may also include determining at least one optimal hyperparameter based on the scalarized results (block 708). In some embodiments, the computing device may select and assign to each user the set of experimental hyperparameters with the optimal scalarized results. In particular embodiments, after determining the scalarized results for each set of experimental hyperparameters, the set of experimental hyperparameters with the optimal (e.g., lowest) scalarized results 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 scalarized result of 25 and a hyperglycemic risk threshold of 0.66 associated with a scalarized result of 20, the hyperglycemic risk threshold of 0.66 may be assigned to the user to minimize the predicted time outside the optimal glucose range when the CMAB model sets w1 = w2 = 0.5. With respect to any other selection of weights, the CMAB model minimizes the scalarized time outside the optimal glucose range (potentially weighting time above or below the range more heavily). Thus, at the end of this step, the exploitative subset users are assigned a single set of optimal hyperparameters.

[0113] 7, process 700 may also include determining, for each user, a decision-support output using at least one optimal hyperparameter (e.g., an optimal set of hyperparameters) (block 710). For example, after assigning an optimal set of hyperparameters to a user, the optimal set of hyperparameters is used by a decision-making sub-model of the decision-support model to determine a decision-support output for the user. For example, if the optimal set of hyperparameters for a user includes a hyperglycemia risk threshold of 0.66, and if the scoring sub-model of the decision-support model produces a score of 0.33 for the user, the computing device may determine a “no alert” output corresponding to not providing a hyperglycemia warning to the user because 0.33 is less than 0.66.

[0114] b. Block 606: Determine decision support output for search subset The process 600 for performing the exploration-exploitation phase (block 306) may also include determining decision-support outputs for the exploration subset of users (block 606) (as illustrated in FIG. 8). Various techniques can be used to determine the decision-support outputs for the exploration subset of users. For example, after assigning users to the exploration subset, the following operations are performed to determine the decision-support outputs for the exploration subset users.

[0115] FIG. 8 is a flow diagram illustrating a process 800 for determining a decision support output for a search subset of users (block 606) according to certain embodiments of the present disclosure. Process 800 may include randomly assigning at least one hyperparameter to each user in the search subset of users (block 802). For example, a set of randomly selected hyperparameters is assigned to the users. In some embodiments, to assign random hyperparameters to users, the computing device first determines cohort-specific ranges for the hyperparameters based on a cohort of users and then randomly selects values ​​from the cohort-specific ranges. For example, the computing device may first determine that the hyperglycemia risk threshold for women aged 20-30 should be 0.2-0.7 and then randomly select a value from the range (0.2, 0.7) for a user who is a 25-year-old woman.

[0116] 8, process 800 may include determining a decision-support output for each user in the search subset using the randomly assigned at least one parameter (block 804). For example, after randomly assigning a set of hyperparameters to the users, the random set of hyperparameters is used by the decision-making sub-model of the decision-support model to determine a decision-support output for the user. For example, if the random set of hyperparameters for the user includes a hyperglycemia risk threshold of 0.23, and if the scoring sub-model of the decision-support model produces a score of 0.33 for the user, the computing device may determine a “warning” output corresponding to providing a hyperglycemia warning to the user because 0.33 is not less than 0.23.

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

[0118] Exemplary Operational Flowchart for Determining Decision Support Outputs Based on User-Specific Hyperparameters As described above, the customer-facing algorithm may execute a decision-support model. For example, the decision-support model may include utilizing user-specific hyperparameters to determine a decision-support output. In some embodiments, executing the decision-support model may include determining a decision-support output for the user by using (i) the optimal level range for the user 102 as input data and / or (ii) a risk tolerance profile based on hyperparameters, including the user-specific hyperparameters.

[0119] 9 is a flow chart illustrating an exemplary operational process for determining a decision support output based on user-specific hyperparameters, according to certain embodiments of the present disclosure. Specifically, a nocturnal hypoglycemia classifier with an adjustable probability threshold hyperparameter and Time Below Range (TbR) and Time Above Range (TaR) as outcomes of interest is further described below with reference to FIG. 9.

[0120] Process 900 may include assigning a random set of hyperparameters to each user (Step 1). For example, during an initial exploration phase, the CMAB model may test a 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 particular embodiments, the customer-facing algorithm may run the decision support model using the randomly assigned probability thresholds (i.e., random sets of hyperparameters) and observe the results, as further described above.

[0121] Process 900 may also include determining a decision-support output based on the assigned set of hyperparameters (step 2), observing outcomes associated with the decision-support output, and training an outcome prediction model based on the observed data. For example, the process may train a tactical allocation algorithm on this exploration phase data to learn relationships between parameters (probability thresholds), context (e.g., age and diabetes type), and the observed outcome(s) of interest (TbR and TaR).

[0122] 9, process 900 may include dividing users into exploitation subsets and exploitation sub-sets using the ε fractions (step 3), as further described above. For example, for the 1-ε fraction of users assigned to the exploitation arm of the MAB, the process may run the tactical allocation algorithm K times (with probability thresholds 0.1, 0.2, ..., 0.9) for each user to predict their TbR and TaR.

[0123] Additionally, process 900 may include determining scaled outcomes for users in the utilization subset (step 4) by scaling the predicted outcomes determined using the outcome prediction model. For example, for each (TbR, TaR) predicted for each user, the process may perform a scalarization (e.g., 0.5) to address the tradeoff between TbR and TaR. * TbR+0.5 * In this example, scalarized weights of 0.5 are used for TbR and TaR. Alternatively, the process may determine the weights through user input (e.g., a user who values ​​not having nocturnal hypoglycemia above all else, people who generally don't care because alarms wake them up, etc.). In another alternative, the process may determine the weights by cohorting users by stated preferences or by varying the metric being weighted (e.g., User_Risk_Tolerance *TbR+(1-User_Risk_Tolerance) * In a further alternative, the process may set the weights as default values ​​that users can change themselves.

[0124] 9, process 900 may include determining optimal hyperparameter sets for users in the utilization subset based on the scaled results (step 5) and assigning the optimal hyperparameter sets to those users. For example, for each user in the utilization subset of users, the process may assign 0.5 * TbR+0.5 * The probability threshold that maximizes the TaR may be chosen and that threshold may be used to run the nocturnal hypoglycemia classifier for that patient. Furthermore, process 900 may include randomly assigning hyperparameters to users in the search subset (step 6) and using this data and observations to retrain the outcome prediction model. For example, the process may continue to randomly assign ε portions of users to the search subset of users and periodically use this data to retrain the tactical assignment algorithm. In certain embodiments, process 900 may repeat steps 2-6.

[0125] Exemplary Apparatus for Determining Decision Support Output Based on User-Specific Hyperparameters 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. While depicted as a single physical device, in embodiments, computing device 1000 may be implemented using virtual device(s) and / or across several devices, such as in a cloud environment. Computing device 1000 may be a display device 107, a server, multiple services, or any combination thereof.

[0126] As illustrated, computing device 1000 includes one or more processor(s) 1005, non-volatile memory 1010, volatile memory 1015, a 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 residing in non-volatile memory 1010 and / or volatile memory 1015. In particular embodiments, non-volatile memory 1010 is configured to store instructions (e.g., computer-executable code, device applications 1040) that, when executed by processor(s) 1005, cause the processor(s) 1005 to perform the processes and / or operations described herein and illustrated in FIGS. 3-9. In particular embodiments, non-volatile memory 1010 stores code for performing the functions of DAM 111, decision support engine 112, and / or application 106. It should be noted that computing device 1000 may be configured to perform only one function of DAM 111, decision support engine 112, and / or application 106, in which case additional system(s) may be used to perform the other functions.

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

[0128] In some embodiments, I / O devices 1035 (e.g., keyboard, monitor) can be connected via I / O interface(s) 1020. Additionally, via network interface 1025, computing device 1000 may be communicatively coupled to one or more other devices and components, such as user database 110. In particular embodiments, computing device 1000 is communicatively coupled to other devices via a network, which may include the Internet, local network(s), and the like. The network may include wired connections, wireless connections, or a combination of wired and wireless connections. As illustrated, processor(s) 1005, non-volatile memory 1010, volatile memory 1015, network interface 1025, and I / O interface(s) 1020 are communicatively coupled by one or more interconnection buses 1030. In particular embodiments, computing device 1000 is a server running in an on-premise data center or a cloud environment. In particular embodiments, computing device 1000 is a user's mobile device.

[0129] In the illustrated embodiment, the non-volatile memory 1010 may include a device application 1040 that configures the processor(s) 1005 to perform various processes and / or operations in determining user-specific hyperparameters 1085 for the 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 described above with reference to FIGS. 3-9 , the computing device 1000 may be configured to perform an initial exploration phase by assigning a random set of hyperparameters 1086, determining and providing decision support outputs 1055, and monitoring physiological conditions by receiving and / or analyzing monitoring data 1090 (e.g., inputs 127, metrics 130, etc.), as further described above. Additionally, the computing device 1000 may be configured to perform a training phase by receiving and / or inputting training data 1060 into an outcome prediction model and using the outcome prediction model to determine predicted outcomes 1065, as further described above. In some embodiments, the training data 1060 may include user input data (e.g., contextual data), hyperparameter input data (e.g., values ​​associated with hyperparameters), and / or monitoring data 1090. Additionally, the computing device 1000 may be configured to perform the exploration-exploitation phase by dividing the set of users into an exploration subset 1080 and an exploitation subset 1070. In particular embodiments, the exploration-exploitation phase may also include determining decision support outputs 1055 for the exploitation subset of users using an experiment set of hyperparameters 1087, determining predicted results 1065, and determining scalarized results 1075, as further described above.In various embodiments, the exploration-exploitation phase may also include selecting and assigning an experimental set 1087 of hyperparameters that have optimal scalarized results and determining decision support outputs 1055 using the optimal set 1088 of hyperparameters, as further described above. In particular embodiments, the computing device 1000 may also receive and / or store input data 1045 (e.g., inputs 127). Additionally, the computing device 1000 may be configured to receive and / or generate monitoring data (e.g., inputs 127, metrics 130, etc.), as described above.

[0130] Furthermore, although certain operations (e.g., the operations of Figures 3-9) and data are described with respect to Figure 10 as being performed and / or stored by particular computing devices described above, in certain embodiments, a combination of computing devices may be utilized instead.

[0131] Each of these non-limiting examples can stand alone or can be combined in various permutations or combinations with one or more of the other examples. The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, 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 in which only those elements shown or described are provided. Furthermore, the inventors also contemplate examples that use any combination or permutation of those elements (or one or more aspects thereof) shown or described with respect to a particular example (or one or more aspects thereof), or with respect to any other example (or one or more aspects thereof) shown or described herein.

[0132] In the event of a conflict of usage between this document and any document incorporated by reference, the usage in this document shall take precedence.

[0133] In this document, the terms "a" or "an" are used to include one or more than one, as is common in patent documents, regardless of other instances or uses of "at least one" or "one or more." In this document, the term "or" is used to refer to a non-exclusive, 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 "including" and "in which" are used as the plain English equivalents of "comprising" and "wherein," respectively. In this document, the term "set" or "set of" a particular item is used to refer to one or more of the particular items.

[0134] Also, in the following claims, the terms "including" and "comprising" are open-ended, i.e., systems, devices, articles, compositions, formulations, or processes that include elements in addition to those listed after such terms in a claim are still deemed to be within the scope of that claim. Furthermore, in the following claims, terms such as "first," "second," and "third" are used merely as labels and are not intended to impose numerical requirements on their objects.

[0135] Geometric terms such as "parallel," "perpendicular," "circular," or "square" are not intended to require absolute mathematical precision unless the context indicates otherwise. Instead, such geometric terms allow for variations due to manufacturing or equivalent functions. For example, if an element is described as "circular" or "approximately circular," components that are not exactly round (e.g., slightly elliptical or multi-sided polygonal) are still encompassed by this description.

[0136] Embodiments of the methods described herein may be at least partially machine or computer-implemented. Some embodiments may include a computer-readable or machine-readable medium encoded with instructions operable to configure an electronic device to perform the methods described in the embodiments. 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. This code may form part of a computer program product. Furthermore, in embodiments, 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 these tangible computer-readable media may include, but are not limited to, hard disks, removable magnetic disks, removable optical disks (e.g., compact disks and digital video disks), magnetic cassettes, memory cards or sticks, random access memory (RAM), read-only memory (ROM), etc.

[0137] The above 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 used, such as those of ordinary skill in the art upon reviewing the above description. The Abstract is provided to comply with 37 CFR §1.72(b) to enable the reader to quickly grasp the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or spirit of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. This should not be construed as intending that any unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter may lie in fewer than all features of a particular disclosed embodiment. Thus, the following claims are 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 such embodiments can be combined with each other in various combinations or permutations. The scope of the invention should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. [Explanation of symbols]

[0138] 100 Decision Support Systems 102 users 104 Analyte Monitoring System 106 Mobile Health Application ("Application") 107 Display Devices 107a, 107b, 107c Mobile Devices 109a, 109b, 109c Touchscreen Displays 110 User Database 111 Data Analysis Module (DAM) 112 Decision Support Engine 118 User Profile 119 Demographic Information 121 Disease progression information 122 Medication Treatment Information 126 Application Data 127 inputs 130 metric 138 Analyte Sensor Electronics Module 140 Continuous Analyte Sensor 210 Input 1000 computing devices 1005 processor 1010 Non-volatile memory 1015 Volatile Memory 1020 Output (input / output, I / O) interface 1025 network interfaces 1030 Interconnect Bus 1035 I / O devices 1040 Device Applications 1045 input data 1055 Decision Support Output 1060 training data 1065 Prediction Results 1070 Conjugated Subset 1075 results 1080 Exploration Subset 1085 User-specific hyperparameters 1086 sets 1087 Experiment Set 1088 sets 1090 Monitoring Data

Claims

1. 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: performing an initial search phase by randomly assigning at least one hyperparameter to each user of a plurality of users; analyzing training data, the training data including context data and values ​​associated with the at least one randomly assigned hyperparameter; and performing a training phase by determining a relationship between the context data and the value associated with the at least one randomly assigned hyperparameter; dividing the plurality of users into an exploration subset of users and an exploitation subset of users; determining at least one optimal hyperparameter for each user of the utilization subset of users; determining at least one decision support output for each user of the utilization subset of users using the at least one optimal hyperparameter; randomly assigning at least one hyperparameter to each user of the search subset of users; and performing an exploration-exploitation phase by determining at least one decision support output for each user in the exploration subset of users using the at least one randomly assigned hyperparameter.

2. The initial search phase determining a decision support output for each user of the plurality of users using the at least one randomly assigned hyperparameter; providing the decision support output to each user of the plurality of users; and 10. The non-transitory computer-readable storage medium of claim 1, further performed by receiving monitoring data for each user of the plurality of users, the monitoring data providing information for at least one physiological condition.

3. 3. The non-transitory computer-readable storage medium of claim 2, wherein the training data further includes the monitoring data, and the training phase is further performed by determining relationships between the monitoring data, the contextual data, and the value associated with the at least one randomly assigned hyperparameter.

4. The at least one optimal hyperparameter for each user of the utilization subset of users is: assigning a plurality of experimental hyperparameters to each user in the exploitation subset; determining at least one predicted outcome for each experimental hyperparameter of the plurality of experimental hyperparameters; determining a scalarized outcome for each experimental hyperparameter of the plurality of experimental hyperparameters; and and determining the at least one optimal hyperparameter based on the scalarized result.

5. The operation is analyzing training data, the training data including contextual data, values ​​associated with the randomly assigned hyperparameters for the search subset of users, and monitoring data for the search subset of users; and 5. The non-transitory computer-readable storage medium of claim 4, further comprising performing a retraining phase by determining a relationship between the contextual data, the value associated with the at least one randomly assigned hyperparameter for the search subset of users, and the monitoring data for the search subset of users.

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

7. The non-transitory computer-readable storage medium of claim 4 , wherein the at least one predicted outcome is determined using a tactical allocation algorithm.

8. 1. A method for determining user-specific hyperparameters for a decision support model, comprising: performing an initial search phase by randomly assigning at least one hyperparameter to each user of a plurality of users; analyzing training data, the training data including context data and values ​​associated with the at least one randomly assigned hyperparameter; and performing a training phase by determining a relationship between the context data and the value associated with the at least one randomly assigned hyperparameter; dividing the plurality of users into an exploration subset of users and an exploitation subset of users; determining at least one optimal hyperparameter for each user of the utilization subset of users; determining at least one decision support output for each user of the utilization subset of users using the at least one optimal hyperparameter; randomly assigning at least one hyperparameter to each user of the search subset of users; and performing an exploration-exploitation phase by determining at least one decision support output for each user in the exploration subset of users using the at least one randomly assigned hyperparameter.

9. The initial search phase determining a decision support output for each user of the plurality of users using the at least one randomly assigned hyperparameter; providing the decision support output to each user of the plurality of users; and 10. The method of claim 8, further performed by receiving monitoring data for each user of the plurality of users, the monitoring data providing information on at least one physiological condition.

10. 10. The method of claim 9, wherein the training data further includes the monitoring data, and the training phase is further performed by determining relationships between the monitoring data, the contextual data, and the value associated with the at least one randomly assigned hyperparameter.

11. The at least one optimal hyperparameter for each user of the utilization subset of users is: assigning a plurality of experimental hyperparameters to each user in the exploitation subset; determining at least one predicted outcome for each experimental hyperparameter of the plurality of experimental hyperparameters; determining a scalarized outcome for each experimental hyperparameter of the plurality of experimental hyperparameters; and 9. The method of claim 8, wherein the at least one optimal hyperparameter is determined based on the scalarized result.

12. analyzing training data, the training data including contextual data, values ​​associated with the randomly assigned hyperparameters for the search subset of users, and monitoring data for the search subset of users; and 12. The method of claim 11, further comprising performing a retraining phase by determining relationships between the contextual data, the values ​​associated with the at least one randomly assigned hyperparameter for the search subset of users, and the monitoring data for the search subset of users.

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

14. The method of claim 11 , wherein the at least one predicted outcome is determined using a tactical allocation algorithm.

15. 1. A computing device for determining user-specific hyperparameters for a decision support model, 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: performing an initial search phase by randomly assigning at least one hyperparameter to each user of a plurality of users; analyzing training data, the training data including context data and values ​​associated with the at least one randomly assigned hyperparameter; and performing a training phase by determining a relationship between the context data and the value associated with the at least one randomly assigned hyperparameter; dividing the plurality of users into an exploration subset of users and an exploitation subset of users; determining at least one optimal hyperparameter for each user of the utilization subset of users; determining at least one decision support output for each user of the utilization subset of users using the at least one optimal hyperparameter; randomly assigning at least one hyperparameter to each user of the search subset of users; and and a memory that causes a computing device to perform an exploration-exploitation phase by determining at least one decision support output for each user of the exploration subset of users using the at least one randomly assigned hyperparameter.

16. The initial search phase using the at least one randomly assigned hyperparameter to determine a decision support output for each user of the plurality of users using a decision support model; providing the decision support output to each user of the plurality of users; and 16. The computing device of claim 15, further performed by receiving monitoring data for each user of the plurality of users, the monitoring data providing information on at least one physiological condition.

17. 17. The computing device of claim 16, wherein the training data further includes the monitoring data, and wherein the training phase is further performed by determining relationships between the monitoring data, the contextual data, and the value associated with the at least one randomly assigned hyperparameter.

18. The at least one optimal hyperparameter for each user of the utilization subset of users is: assigning a plurality of experimental hyperparameters to each user in the exploitation subset; determining a predicted outcome for each experimental hyperparameter of the plurality of experimental hyperparameters; and determining a scalarized result for each experimental hyperparameter of the plurality of experimental hyperparameters; and 16. The computing device of claim 15, wherein the at least one optimal hyperparameter is determined based on the scalarized result.

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

20. the computing device: analyzing training data, the training data including contextual data, values ​​associated with the randomly assigned hyperparameters for the search subset of users, and monitoring data for the search subset of users; and 20. The computing device of claim 18, further configured to perform a retraining phase by determining at least one predicted outcome for each user of the exploration subset of users based on a relationship between the contextual data, the value associated with the at least one randomly assigned hyperparameter for the exploration subset of users, and the monitoring data for the exploration subset of users.

Images