Determining decision support outputs using user-specified analyte level criteria

Abstract

In one embodiment, a non-transitory computer-readable storage medium is provided that stores a program, the program including instructions that, when executed by at least one processor of a computing device, cause the at least one processor to perform operations including receiving sensor data generated by an analyte sensor configured to monitor at least one analyte, determining at least one analyte level criterion for the user for the at least one analyte, using a decision-support model to determine at least one decision-support output based on the at least one analyte level criterion, and providing the at least one decision-support output to the user.

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 / 385,581, filed November 30, 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 decision support outputs 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 is unable to effectively use the insulin that is present, blood glucose levels can rise above the normal range. A condition in which blood glucose levels are higher than normal is called "hyperglycemia." Chronic hyperglycemia can lead to many health problems, including cardiovascular disease, cataracts and other eye diseases, nerve damage (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). A condition in which blood glucose levels are lower than normal is 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 effectively regulated.

[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 decision support outputs using user-specific analyte level criteria 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, the more prominent features are described below. After reviewing this description, 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 stores a program, the program including instructions that, when executed by at least one processor of a computing device, cause the at least one processor to perform operations including receiving sensor data generated by an analyte sensor configured to monitor at least one analyte; determining at least one analyte level criterion for a user for the at least one analyte; determining at least one decision-support output based on the at least one analyte level criterion using a decision-support model; and providing the at least one decision-support output to the user.

[0011] In an embodiment of the first aspect, the at least one analyte level criterion is an optimal level range for the at least one analyte.

[0012] In another embodiment of the first aspect, the optimal level range comprises a high analyte threshold defining an upper limit for at least one analyte and a low analyte threshold defining a lower limit for at least one analyte.

[0013] In another embodiment of the first aspect, the operations further include receiving user input indicating a high analyte threshold and a low analyte threshold, wherein the high analyte threshold and the low analyte threshold are determined based on the user input.

[0014] In another embodiment of the first aspect, the optimal level range is determined by defining a time period threshold and, upon determining that the sensor data covers the time period threshold, generating a trend using the sensor data to determine a high analyte threshold and a low analyte threshold.

[0015] In another embodiment of the first aspect, the optimal level range is determined by defining a time period threshold and, upon determining that the sensor data does not cover the time period threshold, generating a trend using the sensor data of the cohort to determine a high analyte threshold and a low analyte threshold.

[0016] In another embodiment of the first aspect, the optimal level range is determined using a contextual multi-armed bandit algorithm.

[0017] In another embodiment of the first aspect, the at least one analyte level criteria is a risk tolerance profile of the user.

[0018] In another embodiment of the first aspect, the risk tolerance profile includes a high-level risk tolerance threshold that defines the user's willingness to risk having an analyte level above a recommended high analyte level range, and a low-level risk tolerance threshold that defines the user's willingness to risk having an analyte level below a recommended low analyte level range.

[0019] In another embodiment of the first aspect, the non-transitory computer-readable storage medium further includes instructions that, when executed by the at least one processor, cause the at least one processor to further receive user input indicating a user's risk tolerance level and determine a high-level risk threshold and a low-level risk threshold based on the user input.

[0020] In another embodiment of the first aspect, the user input includes the user's risk tolerance level for a plurality of ranges of recommended high analyte level ranges and a plurality of ranges of recommended low analyte level ranges.

[0021] In another embodiment of the first aspect, the user input includes an acceptable number of high and low analyte events.

[0022] In another embodiment of the first aspect, the user input includes an acceptable time range for a high analyte event and a low analyte event.

[0023] In another embodiment of the first aspect, the non-transitory computer-readable storage medium further includes instructions that, when executed by the at least one processor, cause the at least one processor to further determine a risk tolerance profile based on a contextual multi-armed bandit algorithm.

[0024] In another embodiment of the first aspect, the non-transitory computer-readable storage medium further includes instructions that, when executed by the at least one processor, cause the at least one processor to further determine, using the decision support model, at least one decision support output based on the at least one analyte level criterion by determining hyperparameters based on the optimal level ranges and running the decision support model using the hyperparameters.

[0025] In another embodiment of the first aspect, the non-transitory computer-readable storage medium further includes instructions that, when executed by the at least one processor, cause the at least one processor to further determine, using the decision support model, at least one decision support output based on the at least one analyte level criterion by determining hyperparameters based on the risk tolerance profile and running the decision support model using the hyperparameters.

[0026] In another embodiment of the first aspect, the decision support model includes a scoring sub-model and a decision making sub-model.

[0027] In another embodiment of the first aspect, the non-transitory computer-readable storage medium further includes instructions that, when executed by the at least one processor, cause the at least one processor to further determine at least one decision support output using the decision support model based on the at least one analyte level criterion by configuring a scoring sub-model to process the at least one analyte level criterion to determine at least one risk score for the user.

[0028] In another embodiment of the first aspect, the at least one risk score comprises a predicted likelihood that the user will experience a particular condition in a future time period.

[0029] In another embodiment of the first aspect, the non-transitory computer-readable storage medium further includes instructions that, when executed by the at least one processor, cause the at least one processor to further determine at least one decision support output using the decision support model by configuring a decision sub-model to select a decision support output for the user from a set of potential decision support outputs based on the at least one risk score.

[0030] In a second aspect, a method is provided for determining a decision support output using user-specific analyte level criteria, the method including: receiving, by a data analysis module (DAM), sensor data generated by an analyte sensor configured to monitor at least one analyte; determining, by the DAM, at least one analyte level criterion for the user for the at least one analyte; determining, by the DAM, at least one decision support output based on the at least one analyte level criterion using a decision support model; and providing, by the DAM, the at least one decision support output to the user.

[0031] In an embodiment of the second aspect, the at least one analyte level criterion is an optimal level range for the at least one analyte.

[0032] In another embodiment of the second aspect, the optimal level range comprises a high analyte threshold defining an upper limit for at least one analyte and a low analyte threshold defining a lower limit for at least one analyte.

[0033] In another embodiment of the second aspect, the method further includes receiving user input indicating a high analyte threshold and a low analyte threshold, wherein the high analyte threshold and the low analyte threshold are determined based on the user input.

[0034] In another embodiment of the second aspect, the optimal level range is determined by defining a time period threshold and, upon determining that the sensor data covers the time period threshold, generating a trend using the sensor data to determine a high analyte threshold and a low analyte threshold.

[0035] In another embodiment of the second aspect, the optimal level range is determined by defining a time period threshold and, upon determining that the sensor data does not cover the time period threshold, generating a trend using the sensor data of the cohort to determine a high analyte threshold and a low analyte threshold.

[0036] In another embodiment of the second aspect, the optimal level range is determined using a contextual multi-armed bandit algorithm.

[0037] In another embodiment of the second aspect, the at least one analyte level criteria is a risk tolerance profile of the user.

[0038] In another embodiment of the second aspect, the risk tolerance profile includes a high-level risk tolerance threshold that defines the user's willingness to risk having an analyte level above a recommended high analyte level range, and a low-level risk tolerance threshold that defines the user's willingness to risk having an analyte level below a recommended low analyte level range.

[0039] In another embodiment of the second aspect, the method further includes receiving user input indicating a user's risk tolerance level, and determining a high-level risk threshold and a low-level risk threshold based on the user input.

[0040] In another embodiment of the second aspect, the user input includes the user's risk tolerance level for a plurality of ranges of recommended high analyte level ranges and a plurality of ranges of recommended low analyte level ranges.

[0041] In another embodiment of the second aspect, the user input includes an acceptable number of high and low analyte events.

[0042] In another embodiment of the second aspect, the user input includes an acceptable time range for a high analyte event and a low analyte event.

[0043] In another embodiment of the second aspect, the method further includes determining the risk tolerance profile based on a contextual multi-armed bandit algorithm.

[0044] In another embodiment of the second aspect, the method further includes determining at least one decision support output using the decision support model based on the at least one analyte level criterion by determining hyperparameters based on the optimal level range and running the decision support model using the hyperparameters.

[0045] In another embodiment of the second aspect, the method further includes determining at least one decision support output based on the at least one analyte level criterion using the decision support model by determining hyperparameters based on the risk tolerance profile and running the decision support model using the hyperparameters.

[0046] In another embodiment of the second aspect, the decision support model includes a scoring sub-model and a decision making sub-model.

[0047] In another embodiment of the second aspect, the method further includes using the decision support model to determine at least one decision support output based on the at least one analyte level criterion by configuring a scoring sub-model to process the at least one analyte level criterion to determine at least one risk score for the user.

[0048] In another embodiment of the second aspect, the at least one risk score comprises a predicted likelihood that the user will experience a particular condition in a future time period.

[0049] In another embodiment of the second aspect, the method further includes determining at least one decision support output using the decision support model by configuring the decision making submodel to select a decision support output for the user from a set of potential decision support outputs based on the at least one risk score.

[0050] In a third aspect, a computing device for determining a decision support output using user-specific analyte level criteria is provided, the computing device including a network interface, a processor operably connected to the network interface, and memory storing a program including instructions that, when executed by the processor, cause the computing device to receive, using the network interface, sensor data generated by an analyte sensor configured to monitor at least one analyte, determine at least one analyte level criterion for the user for the at least one analyte, use a decision support model to determine at least one decision support output based on the at least one analyte level criterion, and provide the at least one decision support output to the user.

[0051] In an embodiment of the third aspect, the at least one analyte level criterion is an optimal level range for the at least one analyte.

[0052] In another embodiment of the third aspect, the optimal level range comprises a high analyte threshold defining an upper limit for at least one analyte and a low analyte threshold defining a lower limit for at least one analyte.

[0053] In another embodiment of the third aspect, the operations further include receiving a user input indicating a high analyte threshold and a low analyte threshold, wherein the high analyte threshold and the low analyte threshold are based on the user input.

[0054] In another embodiment of the third aspect, the optimal level range is determined by defining a time period threshold, and upon determining that the sensor data covers the time period threshold, generating a trend using the sensor data to determine a high analyte threshold and a low analyte threshold.

[0055] In another embodiment of the third aspect, the optimal level range is determined by defining a time period threshold and, upon determining that the sensor data does not cover the time period threshold, generating a trend using the sensor data of the cohort to determine a high analyte threshold and a low analyte threshold.

[0056] In another embodiment of the third aspect, the optimal level range is determined using a contextual multi-armed bandit algorithm.

[0057] In another embodiment of the third aspect, the at least one analyte level criteria is a risk tolerance profile of the user.

[0058] In another embodiment of the third aspect, the risk tolerance profile includes a high-level risk tolerance threshold that defines the user's willingness to risk having an analyte level above a recommended high analyte level range, and a low-level risk tolerance threshold that defines the user's willingness to risk having an analyte level below a recommended low analyte level range.

[0059] In another embodiment of the third aspect, the program includes further instructions that, when executed by the processor, cause the computing device to further receive user input indicating a user's risk tolerance level and determine a high-level risk threshold and a low-level risk threshold based on the user input.

[0060] In another embodiment of the third aspect, the user input includes the user's risk tolerance level for a plurality of ranges of recommended high analyte level ranges and a plurality of ranges of recommended low analyte level ranges.

[0061] In another embodiment of the third aspect, the user input includes an acceptable number of high and low analyte events.

[0062] In another embodiment of the third aspect, the user input includes an acceptable time range for the high analyte event and the low analyte event.

[0063] In another embodiment of the third aspect, the program includes further instructions that, when executed by the processor, cause the computing device to further determine the risk tolerance profile based on a contextual multi-armed bandit algorithm.

[0064] In another embodiment of the third aspect, the program includes further instructions that, when executed by the processor, cause the computing device to determine, using the decision support model, at least one decision support output based on the at least one analyte level criterion by determining hyperparameters based on the optimal level ranges and running the decision support model using the hyperparameters.

[0065] In another embodiment of the third aspect, the program includes further instructions that, when executed by the processor, cause the computing device to further determine, using the decision support model, at least one decision support output based on the at least one analyte level criterion by determining hyperparameters based on the risk tolerance profile and running the decision support model using the hyperparameters.

[0066] In another embodiment of the third aspect, the decision support model includes a scoring sub-model and a decision making sub-model.

[0067] In another embodiment of the third aspect, the program includes further instructions that, when executed by the processor, cause the computing device to further determine at least one decision support output using the decision support model based on the at least one analyte level criterion by configuring a scoring sub-model to process the at least one analyte level criterion to determine at least one risk score for the user.

[0068] In another embodiment of the third aspect, the at least one risk score comprises a predicted likelihood that the user will experience a particular condition in a future time period.

[0069] In another embodiment of the third aspect, the program includes further instructions that, when executed by the processor, cause the computing device to determine at least one decision support output using the decision support model by configuring the decision submodel to select a decision support output for the user from a set of potential decision support outputs based on the at least one risk score. [Brief explanation of the drawings]

[0070] [Figure 1A] 1 illustrates an example of a 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 chart illustrating a process for determining a decision support output using user-specific analyte level criteria, according to certain embodiments of the present disclosure. [Figure 4] 1 is a flow diagram illustrating a process for determining at least one analyte level criterion according to certain embodiments of the present disclosure. [Figure 5] 1 is a flow chart illustrating a process for determining an optimal analyte level range for a user according to certain embodiments of the present disclosure. [Figure 6] 1 is a flow diagram illustrating a process for determining a user's risk tolerance profile according to certain embodiments of the present disclosure. [Figure 7] 1 is a flow diagram illustrating a process for determining at least one decision support output using a decision support model based on at least one analyte level criterion according to certain embodiments of the present disclosure. [Figure 8] 1 is a flow diagram illustrating an example operational flow of a contextual multi-armed bandit (CMAB) algorithm, in accordance with certain embodiments of the present disclosure. [Figure 9] FIG. 1 is a block diagram illustrating a computing device configured to execute various processes for determining a decision support output using user-specific analyte level criteria, in accordance with certain embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0071] 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 collection of many 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.

[0072] Mobile health applications enable users to become more involved in their own healthcare by granting them access to and control of their health information, resulting in increased patient satisfaction and improved care and clinical outcomes. In particular, mobile health applications enable users to access, monitor, record, and update their health information regardless of physical constraints such as time and location. Commercially available mobile health applications offer features such as health information delivery, medication reminders, remote monitoring, and mobile analytics to improve users' health literacy, encourage users to take a more active role in managing their health or disease, promote adherence to treatment, and provide other types of decision-support guidance.

[0073] 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), mealtime and post-meal 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.

[0074] Mobile health applications can 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 may 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 may offer the potential to improve the quality of care while simultaneously reducing costs to the healthcare system.

[0075] 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 may provide many benefits, including improved access to information, reduced medical errors, improved quality of care, etc.

[0076] 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.

[0077] 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 and 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.). If 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 implementing 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. Thus, user engagement associated with such mobile health applications may decrease, thereby increasing user attrition rates.

[0078] One reason many health management applications fail to provide individualized or personalized decision support outputs is that such applications do not effectively utilize user-specific preferences or data regarding optimal analyte levels and / or analyte risk thresholds. For example, a user may have personal preferences regarding what the optimal glucose concentration range for the user is, the user's willingness to risk developing hyperglycemia, and the user's willingness to risk developing hypoglycemia. As another example, a user may have personal preferences regarding the optimal potassium concentration range, the user's willingness to risk developing hyperkalemia, and the user's willingness to risk developing hypokalemia. To provide individualized and / or personalized decision support outputs, mobile health applications should determine decision support outputs in a manner that effectively utilizes user-specific preferences regarding optimal analyte levels and / or analyte risk tolerance thresholds. Otherwise, the decision support outputs may be less effective in providing individualized or personalized guidance to users, resulting in increased user attrition from mobile health applications.

[0079] 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 measure and report analyte sensor outputs describing the user's monitored analyte levels. The user may then use a mobile health application configured to execute on a computing device (e.g., but not limited to, the user's display device, such as a smartphone) to receive the sensor outputs and provide a decision-support output to the user based on the sensor outputs and / or user-specific analyte level criteria. For example, the decision-support output may recommend one or more actions for the user to take (e.g., a recommended sleep pattern for the user), one or more alerts to the user regarding the user's predicted future physiological condition (e.g., an alert that the user is likely to experience hyperglycemia in the next eight hours), etc. In some embodiments, the sensor output may be transmitted to one or more computing devices, one or more servers, and / or one or more user databases. In some embodiments, the one or more user databases may be separate from the one or more servers. In some embodiments, the one or more user databases may be an integral part of the one or more servers.

[0080] In certain embodiments, the computing device may utilize one or more decision support models in providing the decision support output to the user. The decision support model may be a user-enabled algorithm that determines the decision support output for the user based on various parameters, such as, but not limited to, sensor output and / or user-specific analyte level criteria. One example of a decision support model is a sleep advisor model configured to select a recommended sleep pattern for the user from a set of potential sleep patterns. Another example of a decision support model is a hyperglycemia alert model configured to alert the user if the hyperglycemia alert model determines that the user is at risk for hyperglycemia in a future time period (e.g., the next 8 hours). An additional example of a decision support model is a gradual transition model (also referred to herein as a “nudging” model) configured to provide the user with a series of recommended analyte levels over a series of future time periods to assist and encourage the user to gradually transition their analyte values ​​from a current analyte value range to an optimal analyte value range.

[0081] Certain embodiments described herein enable a decision support model to be used to determine a decision support output, and the operation of the decision support model is determined based on a set of analyte level criteria for a user. The analyte level criteria for a user may be one or more values ​​that describe aspects of an acceptable analyte level range (e.g., an acceptable glucose concentration range) for the user, and the values ​​may be selected specifically for the user (i.e., "individualized") or for a cohort that includes the user (i.e., "personalized"). Examples of analyte level criteria include a high analyte threshold (e.g., a hyperglycemia threshold), a low analyte threshold (e.g., a hypoglycemia threshold), a high risk tolerance threshold (e.g., a hyperglycemia risk tolerance threshold), and a low risk tolerance threshold (e.g., a hypoglycemia risk tolerance threshold).

[0082] The high analyte threshold may define the upper limit of the analyte level range recommended to the user. The low analyte threshold may define the lower limit of the analyte level range recommended to the user. The high risk tolerance threshold may define the user's willingness to risk having an analyte level above the user's recommended analyte level range. The low risk tolerance threshold may define the user's willingness to risk having an analyte level below the user's recommended analyte level range. In some embodiments, a user may have more than one high risk tolerance threshold and / or low risk tolerance threshold. For example, a user may have a first high risk tolerance threshold for a first analyte level range above the user's recommended analyte level range and a second high risk tolerance threshold for a second analyte level range above the user's recommended analyte level range. As another example, a user may have a first low risk tolerance threshold for a first analyte level range below the user's recommended analyte level range and a second low risk tolerance threshold for a second analyte level range below the user's recommended analyte level range.

[0083] To determine a decision-support output for a user, the computing device may be configured to first determine one or more analyte level criteria for the user. In some embodiments, the mobile health management application may determine the decision-support output using one or more decision-support models and the determined one or more analyte level criteria. Various techniques may exist for using the user's analyte level criteria in conjunction with the decision-support model to determine the decision-support output. For example, in a first technique, one or more analyte level criteria for the user may be used to determine user-specific hyperparameters for the decision-support model. The user-specific hyperparameters may be used by the decision-support model to determine the decision-support output for the particular user associated with the hyperparameters. Using this first technique, the decision-support model may be able to use different user-specific hyperparameters to determine the decision-support output for different users, thereby increasing the adaptability and predictive accuracy of the decision-support model. An example of a user-specific hyperparameter that can be determined based on analyte level criteria is a user-specific hyperglycemia threshold for a hyperglycemia warning model. The user-specific hyperglycemia threshold may be used by the hyperglycemia warning model to determine whether to warn the corresponding user about a potential future hyperglycemia. In this example, the hyperglycemia alert model is an example of a decision support model, the user-specific hyperglycemia threshold is an example of a user-specific hyperparameter determined based on analyte level criteria for the corresponding user, and the alert decision is an example of a decision support output determined for the corresponding user.

[0084] A second technique for using a user's analyte level criteria in conjunction with a decision support model may involve providing the analyte level criteria as model inputs to the decision support model to determine a decision support output for the user. For example, the user's analyte level criteria may be used to determine an optimal analyte level range for the user. Once the optimal analyte level range for the user is determined, that range may be provided as an input to a stepwise transition model. The stepwise transition model may use the optimal analyte range for the user to determine a set of recommended analyte levels for the user.

[0085] In both of the above-described techniques, analyte level criteria for the user may be integrated into the operational logic of the decision-support model to determine the decision-support output for the user. Because the embodiments described herein enable user-specific analyte level criteria to be integrated into the operational logic of the decision-support model, the resulting decision-support output is more likely to be responsive to the user's specific needs and, thereby, effective for the user. As discussed above, providing users with inefficient decision-support output leads to higher user attrition rates from mobile health applications. By enabling mobile health applications to provide more effective decision-support output, certain embodiments described herein are more likely to increase user engagement with those applications and, thereby, reduce user attrition from those applications.

[0086] Additionally, while the following description and examples are drawn to a glucose monitoring sensor capable of measuring glucose concentrations in a host, the system, device, and method embodiments described herein can be used in conjunction with any type of analyte sensor for any measurable analyte. The system, device, and method embodiments described herein may also 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 can help a user treat a particular disease or help improve the health of a user who has not necessarily been diagnosed with a disease.

[0087] Exemplary system having a decision support engine for determining decision support output using user-specified analyte level criteria - Patent Application 20070122997 1A illustrates an example 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 decision support outputs using user-specific analyte level criteria, and provide decision support to users associated with system 100. Each user of system 100, such as user 102, can 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. User 102 may, in certain embodiments, be a patient or, in some cases, a caregiver for a patient. In the 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 DAM 111), and a user database 110.

[0088] 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 can 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.

[0089] 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.

[0090] 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 acarboxylase. Prothrombin; 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 Sumin; 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, beta); 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, leprosy bacillus, Mycoplasma pneumoniae, myoglobin, Onchocerca volvulus, parainfluenza virus) Viruses, Plasmodium, Poliovirus, Pseudomonas aeruginosa, Respiratory Syncytial Virus, Rickettsia (Tsutsugigushi disease), Schistosoma mansoni, Toxoplasma gondii, Treponema pallidum, Trypanosoma cruzi / Langeri, 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.

[0091] 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.

[0092] 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, use user-specific analyte level criteria to determine decision support output, and provide decision support output, 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, use user-specific analyte level criteria to determine decision support output, and provide decision support output, such as, but not limited to, recommendations and / or guidance, to the user 102.

[0093] 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.

[0094] As described in more detail herein, the decision support engine 112 may use the user-specific analyte level criteria to determine a decision support output and provide the decision support output (e.g., decision support recommendations, etc.) to the user 102 via the application 106. For example, the decision support engine 112 may use the user-specific analyte level criteria to determine an individualized or personalized decision support output for the user by determining a set of analyte level criteria for the user 102 and running a decision support model based on the set of analyte level criteria to determine the decision support output. In certain embodiments, to determine an individualized decision support output for the user 102, the set of analyte level criteria may be determined specifically for the user 102. In some embodiments, to determine a personalized decision support output for the user, the set of analyte level criteria may be determined for a cohort that includes the user 102. As used herein, a "cohort" may be a set of "similar" users with similar demographics, health history, and / or other characteristics that affect the outcome. Furthermore, the decision support engine 112 may run a decision support model based on the set of analyte level criteria to determine the decision support output. To run a decision support model based on a set of analyte level criteria, the analyte level criteria may be used to determine at least one of the input data for the decision support model or the user-specific hyperparameters of the decision support model, as further described below.

[0095] In some embodiments, the decision support engine 112 may determine the decision support output using user-specific analyte level criteria 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.

[0096] 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) (hereinafter also referred to as “input data”) to determine one or more metrics 130 (hereinafter also referred to as “metric data”), which the decision support engine 112 can then use to determine a decision support output and provide to the user 102. 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.

[0097] 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. 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.

[0098] 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, a camera, a global positioning system (GPS), a 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.

[0099] 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 such that the storage devices are geographically distributed.

[0100] 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, the 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.

[0101] 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 discussed 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 can be configured to execute application 106. The analyte monitoring system 104 can be communicatively coupled to mobile devices 107a, 107b, 107c, and / or 107d.

[0102] 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.

[0103] 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-removably attached to) or removably attached to the analyte sensor 140.

[0104] 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 a variety of 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.

[0105] 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 further 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.

[0106] 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 Publication No. 2019 / 0336053. Paragraph

[0117] of U.S. Patent Application Publication 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 Application No. 9,445,445. Paragraphs

[0072] to

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

[0107] 1B , mobile device 107 may be configured to display (and / or alert) displayable sensor information (e.g., in a customized data package sent to a display device based on respective preferences) that may be transmitted by sensor electronics module 138. Mobile devices 107a, 107b, 107c, and / or 107d may each 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 user 102 and / or receiving input from user 102. In certain embodiments, 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 user 102 of 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 it is communicated from the sensor electronics module 138 (e.g., in a data package sent to a respective display device) without any anticipated additional processing required for calibration and / or real-time display of the sensor data.

[0108] 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).

[0109] 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 example metrics 130 on the right. In certain embodiments, application 106 obtains input 127 via one or more channels (e.g., manual user input, sensors, other applications running on mobile device 107, etc.). Input 127 may be further processed by DAM 111 to output multiple metrics, such as metric 130, which may in turn be used by features 1-N of application 106 to provide guidance to the user. In certain embodiments, input 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 a user cohort. Additionally, the inputs (e.g., inputs 127) and metrics (e.g., metrics 130) may be used by DAM 111 and / or any computing device within system 100 to perform various processes in determining decision support outputs using user-specific analyte level criteria, as described further below. Any of the inputs 127 may be used to calculate any of the metrics 130. In certain 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).

[0110] 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 the 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 (e.g., 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.

[0111] 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, fitness tracker, and / or patch. In particular embodiments, activity information may also be provided through manual input by user 102.

[0112] 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.

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

[0114] 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).

[0115] 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.

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

[0117] As mentioned 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 shown 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 indicate 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.

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

[0119] 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, an 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.

[0120] 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).

[0121] 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.

[0122] 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 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.

[0123] 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.

[0124] 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 values. 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).

[0125] In certain embodiments, metrics 130 determined or calculated by DAM 111 may include at least one analyte level criterion, as described further below. In some embodiments, the at least one analyte level criterion may include an optimal level range for the analyte and a user's risk tolerance profile. As described further below, the user's optimal level range and risk tolerance profile may be determined based on inputs 127 (e.g., received user input, received healthcare provider input). In some embodiments, the optimal level range and risk tolerance profile for the user may be determined based on metrics 130, such as, but not limited to, trends in historical analyte level data (e.g., glucose trends). In some embodiments, the user's optimal level range and risk tolerance profile may be determined based on various algorithms that may utilize inputs 127 and metrics 130, as described further below. Optimal level ranges and risk tolerance profiles are described in more detail below.

[0126] As described herein, the DAM 111 and / or application 106 may execute on one or more computing devices to perform various processes for determining a decision-support output using user-specific analyte level criteria. For example, such processes may include (1) determining at least one analyte level criterion for the user and (2) determining a decision-support output using a decision-support model based on the at least one analyte level criterion, as described further below. In some embodiments, determining at least one analyte level criterion for the user may include determining an optimal level range and / or determining a risk tolerance profile. In some embodiments, determining a decision-support output using a decision-support model based on the at least one analyte level criterion may include determining hyperparameters and / or running the decision-support model using at least one analyte, as described further below.

[0127] Exemplary Process for Determining Decision Support Output Using User-Specific Analyte Level Criteria 3 is a flow diagram illustrating a process 300 for determining a decision support output using user-specific analyte level criteria, according to certain embodiments of the present disclosure. In certain embodiments, process 300 may be performed by one or more computing devices, systems (e.g., health monitoring and assistance system 100), etc. For example, process 300 may be performed using analyte monitoring system 104, application 106, user data 110, data analysis module 111, and / or other components of health monitoring and assistance system 100 shown in FIG. 1A. In some embodiments, process 300 may include receiving input data (e.g., input 127) (block 302), such as, but not limited to, sensor data generated by one or more analyte sensors (e.g., continuous analyte sensor 140) configured to measure one or more analyte levels of a user. In some embodiments, the input data may include user input and / or healthcare provider input. As described further below, process 300 may include determining at least one analyte level criterion (block 304) and determining one or more decision-support outputs based on the at least one analyte level criterion using one or more decision-support models (block 306). Additionally, process 300 may include providing one or more decision-support outputs to a user (308).

[0128] Blocks 304 and 306 are described in more detail below with reference to subsequent Figures 4-7. As an example, block 304 of Figure 3 is described in more detail immediately below with reference to Figures 4-6. In particular, block 304 of Figure 3 is described in more detail with reference to blocks 402 and 404 of Figure 4. Next, block 402 of Figure 4 is described in more detail with reference to blocks 502-508 of Figure 5, and block 404 of Figure 4 is described in more detail with reference to blocks 602-606 of Figure 6. After block 304, block 306 of Figure 3 is described in more detail with reference to blocks 702 and 704 of Figure 7.

[0129] 1. Block 304: Determine at least one analyte level criterion for a user As described above with reference to FIG. 3 , process 300 may include determining at least one analyte level criteria (block 304). The analyte level criteria for user 102 may include at least one of a high analyte threshold, a low analyte threshold, one or more high-level risk tolerance thresholds, and one or more low-level risk tolerance thresholds. The high-level analyte threshold and the low-level analyte threshold may collectively define an optimal analyte level range for user 102. The high-level risk tolerance threshold and the low-level risk tolerance threshold may collectively define a risk tolerance profile for user 102. Various exemplary processes for determining optimal level ranges and risk tolerance profiles for user 102 are further described below with reference to FIG. 4. In particular, block 402 of FIG. 4 describes determining optimal analyte level ranges for the user, and block 404 of FIG. 4 describes determining a risk tolerance profile for the user. The optimal analyte level ranges and risk tolerance profiles are examples of analyte level criteria.

[0130] a. Block 402: Determine Optimal Analyte Level Range for User 4 is a flow diagram illustrating a process 400 for determining at least one analyte level criterion (block 304) according to certain embodiments of the present disclosure. In some embodiments, the process 400 for determining at least one analyte level criterion (block 304) may include determining an optimal level range for the user 102 (block 402) and / or determining a risk tolerance profile for the user 102 (block 404), as described further below. Various techniques can be used to determine the optimal analyte level range for the user (block 402).

[0131] 5 is a flow diagram illustrating a process 500 for determining an optimal analyte level range for a user (block 402) according to certain embodiments of the present disclosure. In some embodiments, process 500 may include determining an optimal analyte level range based on user input (e.g., input 127) received from user 102 (block 502) and / or determining an optimal analyte level range based on healthcare provider input received from a healthcare provider (block 504).

[0132] For example, a user 102 may provide input 127 indicating a high analyte threshold and a low analyte threshold (i.e., an optimal level range) in a dedicated user interface (UI) of a computing device (e.g., a mobile device 107). In some embodiments, to specify the high and low analyte thresholds, a user 102 may provide a selected text description of the user's preferred analyte level range (e.g., "narrow," "moderate," or "wide") via an application 106 running on the mobile device 107. The text description may then be mapped to an associated analyte level range (also referred to herein as an "analyte level criteria") by one or more computing devices on the system 100. For example, in embodiments in which the DAM 111 operates on the mobile device 107, the text description may be mapped to an associated analyte level range on the mobile device 107. In some embodiments, the text descriptions may be stored in user database 110 and mapped to associated analyte level ranges by user database 110 and / or by DAM 111 running on one or more servers in network communication with user database 110. As another example, a user may provide input indicating one or more personal health objectives (e.g., keeping the number of hyperglycemic events below a certain number). The computing device can then use the user's historical analyte level trends (e.g., historical glucose concentration trends) to map the objectives to optimal analyte level ranges for the user. In some embodiments, the historical analyte level trends may be metrics 130 or may be generated using one or more metrics 130. In some embodiments, the historical analyte level trends may be generated using one or more inputs 127 and / or a combination of inputs 127 and metrics 130. Additionally, the user's high and low analyte thresholds may be determined based on data transmitted to the computing device by the user's healthcare provider (block 504).

[0133] 5, process 500 (block 402) for determining optimal level ranges may include determining optimal level ranges (block 506) by analyzing historical analyte level data (e.g., metric 130). In some embodiments, determining optimal analyte level ranges based on historical analyte level data (block 506) may be performed based on a user specifically or on a cohort that includes the user. The decision regarding whether to use historical analyte level data for a user or cohort may be based on whether there is sufficient user-specific historical analyte level data available for the user 102. For example, whether there is sufficient user-specific analyte level history available may be based on whether the user-specific analyte level history covers at least a threshold time period. For example, the threshold time period may be a predetermined time period (e.g., one week, one month, etc.) or may be a time period that includes sufficient data (e.g., blood glucose measurements) to determine a trend (e.g., glucose trend).

[0134] In some embodiments, if the user's 102 historical analyte level data covers at least the threshold period, the computing device uses trends in the user's 102 historical analyte level data to determine the user's 102 high and / or low analyte threshold. For example, the user's glucose level may be between 60 mg / dL and 160 mg / dL for approximately 90% of any given day. In such an example, the computing device may determine the user's high analyte threshold at the high end of the range (e.g., 160 mg / dL) or by a percentage above the high end of the range (e.g., 10% above 160 mg / dL). Similarly, the computing device may determine the user's low analyte threshold at the low end of the range (e.g., 70 mg / dL) or by a percentage below the low end of the range (e.g., 10% below 70 mg / dL).

[0135] If the historical analyte level data for user 102 does not cover the threshold for a period, the computing device determines the threshold using trends in the historical analyte level data for the cohort. For example, the glucose levels of the cohort may be between 70 mg / dL and 180 mg / dL for approximately 90% of any given day. In such an example, the computing device may determine the user's high analyte threshold at the high end of the cohort's range (e.g., 180 mg / dL) or a percentage above the high end of the cohort's range (e.g., 10% above 180 mg / dL). Similarly, the computing device may determine the user's low analyte threshold at the low end of the cohort's range (e.g., 60 mg / dL) or a percentage below the low end of the range (e.g., 10% below 60 mg / dL).

[0136] 5, the process 500 for determining optimal level ranges (block 402) may include determining optimal level ranges (block 508) based on various algorithms and / or models, such as, but not limited to, a multi-armed bandit algorithm, a contextual multi-armed bandit (CMAB) algorithm, etc. For example, a CMAB model may be utilized to determine optimal analyte level ranges for a user 102 or a cohort of users based on context information as input. For example, the user context information may include demographic information 119, disease progression information 121, medication information 122, inputs 127 (e.g., activity, patient demographics, insulin, blood glucose, etc.), metrics 130 (e.g., glucose level, disease stage, etc.), etc.

[0137] In some embodiments, the CMAB algorithm may be used to (i) divide a set of users or user cohorts into an exploration subset and a utilization subset using a search ratio, (ii) determine a randomized optimal analyte level range for each user or user cohort in the exploration subset, and (iii) determine an optimal predicted analyte level range for each user or user cohort in the utilization subset based on a machine learning model that uses contextual information of the users or user cohorts as input. In some embodiments, the search ratio may define the ratio of users or user cohorts that are assigned to the exploration subsets. In some embodiments, the search ratio may decrease over time. In some embodiments, the search ratio may be set to 0 after a predetermined period of time.

[0138] b. Block 404: Determine the User's Risk Tolerance Profile As described above, the process 400 for determining at least one analyte level criterion (block 304) may include determining an optimal level range (block 402) for the user 102 (as shown in FIG. 5). Additionally, the process 400 for determining at least one analyte level criterion (block 304) may include determining a risk tolerance profile (block 404) for the user 102 (as shown in FIG. 6). Various techniques can be used to determine the user's risk tolerance profile.

[0139] 6 is a flow diagram illustrating a process 600 for determining a user's risk tolerance profile (block 404) according to certain embodiments of the present disclosure. Process 600 may include determining a risk tolerance profile for a user 102 (block 602) based on user input (e.g., input 127) received from the user. For example, the user 102 may provide input 127 describing the user's willingness to risk having analyte levels that fall into various hypoglycemic and / or hyperglycemic ranges. To enable the user 102 to provide input 127, a dedicated UI may display various analyte level ranges to the user 102 and prompt the user 102 to specify a risk tolerance level for each displayed range. Examples of analyte level ranges that may be displayed to the user 102 include a low hyperglycemic range (e.g., 180 mg / dL to 190 mg / dL), a moderate hyperglycemic range (e.g., 190 mg / dL to 220 mg / dL), and a high hyperglycemic range (e.g., 220 mg / dL or greater). Other examples of analyte level ranges that may be displayed to the user 102 include a low hypoglycemic range (e.g., 60 mg / dL to 70 mg / dL), a moderate hypoglycemic range (e.g., 50 mg / dL to 60 mg / dL), and a high hypoglycemic range (e.g., less than 50 mg / dL).

[0140] After the user 102 provides input 127 specifying the risk tolerance level, the computing device (e.g., the mobile device 107) can then use the input 127 to determine one or more high-level risk tolerance thresholds and one or more low-level risk tolerance thresholds. For example, the computing device may determine a first high-level risk tolerance threshold for the low hyperglycemic range, a second high-level risk tolerance threshold for the moderate hyperglycemic range, and a third high-level risk tolerance threshold for the high hyperglycemic range. In addition, the computing device may determine a first low-level risk tolerance threshold for the low hypoglycemic range, a second low-level risk tolerance threshold for the moderate hypoglycemic range, and a third low-level risk tolerance threshold for the high hypoglycemic range. In this example, the six described risk tolerance thresholds may be determined based on the user-specified risk tolerance levels for the six analyte level ranges displayed to the user 102.

[0141] In other embodiments in which the risk tolerance profile is determined based on user input (block 602), the user 102 may provide input 127 describing an acceptable number of high analyte events (e.g., hyperglycemic events) and / or low analyte events (e.g., hypoglycemic events). For example, the user 102 may specify that they wish to keep the number of daily hyperglycemic events below a certain number. After the user 102 provides input 127 describing the acceptable number of high analyte events and / or low analyte events, the computing device may then determine the risk tolerance profile for the user 102 based on those inputs 127. For example, the computing device may determine one or more high-level risk tolerance thresholds for the user 102 based on the acceptable number of high analyte events provided by the user 102. As another example, the computing device may determine one or more low-level risk tolerance thresholds for the user 102 based on the acceptable number of low analyte events provided by the user 102.

[0142] In yet other embodiments in which the risk tolerance profile is determined based on user input (block 602), the user may provide input 127 describing an acceptable time range for high analyte events (e.g., hyperglycemic events) and / or low analyte events (e.g., hypoglycemic events). For example, the user 102 may specify that they wish to keep the time they experience hyperglycemia to less than 10 minutes per day. After the user 102 provides input 127 describing the acceptable time range for high analyte events and / or low analyte events, the computing device may then determine the risk tolerance profile for the user 102 based on these inputs 127 (block 602). For example, the computing device may determine one or more high-level risk tolerance thresholds for the user 102 based on the acceptable time range for high analyte events provided by the user 102 (block 602). As another example, the computing device may determine one or more low-level risk tolerance thresholds for the user 102 based on an acceptable time range for a low-level analyte event provided by the user 102 (block 602).

[0143] In yet other embodiments in which a risk tolerance profile is determined based on user input (block 602), sliders (e.g., two sliders) may be displayed to the user 102 via a UI on a computing device (e.g., a mobile device 107). For example, a first slider may allow the user 102 to select a high-level risk tolerance threshold, and a second slider may allow the user 102 to select a low-level risk tolerance threshold. If the user 102 selects a value for the high-level risk tolerance threshold using the first slider, the second slider may be updated to change the selected value for the low-level risk tolerance threshold. The newly selected value for the second slider may be calculated using a trade-off model that may be configured to predict how a change in one risk threshold affects another risk threshold. For example, in some embodiments, the trade-off model may be based on historical individual glucose data (if available), cohort glucose data (if available), or population-level glucose data. The trade-off model / analysis may determine to what extent less time above the range is associated with more time below the range, or conversely, to what extent more time above the range is associated with less time below the range. In various embodiments, after the user 102 selects a value for the high-level risk tolerance threshold using the first slider, the trade-off model may predict how the selection will affect the value of the low-level risk tolerance threshold and may determine a newly selected value for the second slider accordingly. Similarly, when the user 102 selects a value for the low-level risk tolerance threshold using the second slider, the first slider may be updated to change the selected value of the high-level risk tolerance threshold to the value calculated by the trade-off model.

[0144] 6, process 600 may also include determining a risk tolerance by analyzing historical analyte level data (block 604). For example, certain other techniques include determining a user's risk tolerance profile (block 604) based on trends in historical analyte level data (e.g., metric 130) for user 102 and / or a cohort that includes user 102. For example, historical analyte level data for user 102 may indicate that user 102 sometimes intervenes (e.g., with insulin) when his or her glucose level is between 190 mg / dL and 200 mg / dL, but always intervenes when his or her glucose level is between 201 mg / dL and 220 mg / dL. Based on these indicators in user 102's historical analyte level data, the computing device may determine a higher high-level risk threshold for the range of 201 mg / dL to 220 mg / dL than for the range of 190 mg / dL to 200 mg / dL.

[0145] 6, process 600 may also include determining a risk tolerance based on various algorithms or models (block 606), such as, but not limited to, a multi-armed bandit algorithm, a contextual multi-armed bandit (CMAB) algorithm, etc. For example, a CMAB algorithm may be used to determine a risk tolerance profile for a user or a cohort of users based on contextual information as input. For example, the user's contextual information may include demographic information 119, disease progression information 121, medication information 122, inputs 127 (e.g., activity, patient demographics, insulin, blood glucose, etc.), metrics 130 (e.g., glucose level, disease stage, etc.), etc.

[0146] In some embodiments, the CMAB algorithm may be used to (i) divide a set of users or user cohorts into an exploration subset and a utilization subset using a search ratio, (ii) determine a randomized risk tolerance profile for each user or user cohort in the exploration subset, and (iii) determine a risk tolerance profile for each user or user cohort in the utilization subset based on contextual information for the user or user cohort. In some embodiments, the search ratio may define the ratio of users or user cohorts that are assigned to the exploration subset. In some embodiments, the search ratio may decrease over time. In some embodiments, the search ratio may be set to 0 after a predetermined period of time.

[0147] As an example of assigning a randomized risk tolerance profile to each user or user cohort in the search subset, a first user or user cohort may be assigned a risk tolerance profile to keep the amount of time hyperglycemia is experienced to less than 10 minutes per day, and a second user or cohort may be assigned a risk profile to keep the amount of time hyperglycemia is experienced to less than 5 minutes per day.

[0148] 2. Block 306: Determine a decision support output using the decision support model based on at least one analyte level criterion. 3, process 300 may include determining one or more decision-support outputs using one or more decision-support models based on the at least one analyte level criterion (block 306). For example, the at least one analyte level criterion (e.g., a set of analyte level criteria for a user) determined in block 304 may be used in combination with one or more decision-support models to determine one or more decision-support outputs for the user.

[0149] FIG. 7 is a flow diagram illustrating a process 700 for determining at least one decision-support output using a decision-support model based on at least one analyte level criterion (block 306) according to certain embodiments of the present disclosure. Various techniques may be used to determine the user's decision-support output using the user's analyte level criterion in conjunction with the decision-support model (block 306). For example, in some embodiments, process 700 may include determining one or more hyperparameters of the decision-support model based on the analyte level criterion (block 702). In some embodiments, the hyperparameters of the decision-support model may be values ​​that define the operating logic of the decision-support model. In some embodiments, the hyperparameters may be considered part of the model input, along with data for training, validating, and testing the model. In some embodiments, the hyperparameters may be considered part of the decision-support model's definition itself, and one or more hyperparameters may be selected (or optimized) to define the decision-support model. For example, a hyperparameter may be a hyperglycemia threshold hyperparameter for a hyperglycemia warning model. As another example, the analyte level criterion for a user may be provided as a model input to the decision-support model to determine the decision-support output for the user.

[0150] 7, process 700 may include running one or more decision support models (block 704) using at least one analyte criterion. In some embodiments, running the decision support model (block 704) may include determining a decision support output for the user based on input data including a high-level analyte threshold, a low-level analyte threshold, a high-level risk tolerance threshold, and / or a low-level risk tolerance threshold for the user 102. In some embodiments, running the decision support model (block 704) may include determining a decision support output for the user by using (i) the high-level analyte threshold and the low-level analyte threshold (e.g., optimal level range) of the user 102 as input data and / or (ii) the high-level risk tolerance threshold and the low-level risk tolerance threshold (e.g., risk tolerance profile) of the user 102 as hyperparameters of the decision support model.

[0151] 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 process input data including at least one analyte level criterion for the user 102 to determine a set of risk scores for the user 102. Each determined risk score may describe the predicted likelihood that the user 102 will experience a particular condition (e.g., a high analyte condition such as hyperglycemia or a low analyte condition such as hypoglycemia) in a future time 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. In some embodiments, the trained parameters may be values ​​that influence the operating logic of the decision support model and may be determined by training the decision support model.

[0152] The decision submodel may be configured to select a decision support output for the user 102 from a set of potential decision support outputs based on the determined risk score for the user 102. In some embodiments, the decision submodel may be characterized by one or more hyperparameters that may define risk tolerance thresholds for one or more risk scores. Each potential decision support output may be associated with a respective subset of the risk tolerance thresholds that may be defined by the hyperparameters of the decision submodel. If the risk score of the user 102 meets the risk tolerance threshold associated with the potential decision support output, the decision submodel may select the potential decision support output and provide the decision support output to the user 102. In certain embodiments, the hyperparameters of the decision submodel may be determined based on at least one analyte criterion for the user.

[0153] For example, the scoring sub-model of the hyperglycemia alert model may be configured to determine a hyperglycemia risk score for the user 102, while the decision sub-model of the hyperglycemia alert model may be configured to determine that a hyperglycemia alert should be presented to the user 102 if the user's 102 hyperglycemia risk score meets (e.g., exceeds) a hyperglycemia risk tolerance threshold. In this example, input data to the scoring sub-model may include the user's 102 glucose concentration measurements and the user's 102 hyperglycemia threshold. Furthermore, the hyperglycemia risk tolerance threshold may be the only hyperparameter of the decision sub-model, and two potential decision support outputs of the hyperglycemia alert model include a "warning" output configured to cause a hyperglycemia alert to be presented to the user and a "no warning" output configured to prevent a hyperglycemia alert from being presented to the user. As this example shows, when the decision support model determines the decision support output for a user, both the input data for the scoring sub-model (in this case, the hyperglycemia threshold) and the hyperparameters for the decision making sub-model (in this case, the hyperglycemia risk tolerance threshold) can be defined by at least one analyte level criterion for the user, which is the hyperglycemia threshold and the hyperglycemia risk tolerance threshold.

[0154] As another example, a scoring sub-model of the sleep advisor model may be configured to determine a hyperglycemic risk score and a hypoglycemic risk score for the user 102. A decision sub-model of the sleep advisor model may be configured to select a sleep pattern from a set of potential sleep patterns for recommendation to the user 102. The sleep pattern may be selected when the risk score for the user 102 determined by the scoring sub-model meets both a hyperglycemic risk tolerance threshold and a hypoglycemic risk tolerance threshold for the selected sleep pattern. The decision sub-model may be characterized by a set of hyperparameters that define two risk tolerance thresholds for each of the potential sleep patterns: a high-level risk tolerance threshold and a low-level risk tolerance threshold.

[0155] 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 high-level risk tolerance threshold and the user's 102's hypoglycemia risk score meets a first low-level risk tolerance threshold, the 8-hour sleep pattern may be recommended to the user 102; if the user's hyperglycemia risk score meets a second high-level risk tolerance threshold and the user's 102's hypoglycemia risk score meets a second low-level risk tolerance threshold, the 10-hour sleep pattern may be recommended to the user 102. The risk tolerance thresholds for the potential sleep patterns may be determined based on a risk tolerance profile for the user 102 described by the user's analyte-level criteria. As this example shows, when the decision support model determines a decision support output for the user 102, both the input data for the scoring sub-model (in this case, the hyperglycemia threshold and the hypoglycemia threshold) and the hyperparameters for the decision-making sub-model (in this case, the hyperglycemia risk tolerance threshold and the hypoglycemia risk tolerance threshold for the potential sleep patterns) may be defined by the analyte-level criteria for the user.

[0156] The implementations and examples described herein are merely illustrative, and various implementations appropriate to the requirements of a particular application may be utilized in accordance with particular embodiments described herein. For example, another variation is a model that outputs bedtime carbohydrate consumption (or exercise / insulin) recommendations when a risk of nocturnal hypoglycemia (or hyperglycemia) is predicted. These recommendations may have additional hyperparameters (in addition to the risk threshold) related to the recommended exercise / carbohydrate / insulin type / amount.

[0157] In some embodiments, the decision support model may include a gradual transition model (also referred to as a "nudging" model). In various embodiments, the gradual transition model may be configured to determine a series of analyte levels to recommend to the user 102 over a series of future time periods to help and encourage the user to gradually transition their analyte values ​​from their current analyte value range to an optimal analyte value range. In some embodiments, the gradual transition model is further configured to recommend a series of actions for the user 102 to perform over a series of future time periods to help and encourage the user 102 to gradually transition their analyte values ​​from their current analyte value range to the optimal analyte value range. In some embodiments, the gradual transition model may recommend different optimal analyte value ranges for different periods of a day. In some embodiments, input data to the gradual transition model may include data describing the user's 102 current analyte value range and data describing the user's 102 optimal analyte value range. The user's 102 current analyte value range may be determined by monitoring the user's 102 analyte concentration measurements over a period of time or may be set to a default range. The optimal analyte value range may be determined based on the high and low analyte thresholds of the user 102 as indicated by the analyte level criteria of the user 102 .

[0158] The gradual transition model may be configured to iteratively guide the user 102 from the user's 102 current analyte level range to the user's 102 optimal analyte level range. For example, the model may recommend a glucose range of 70 mg / dL to 220 mg / dL in the first month, 70 mg / dL to 200 mg / dL in the second month, 70 mg / dL to 180 mg / dL in the third month, and 70 mg / dL to 160 mg / dL in the fourth month. In some embodiments, to determine each recommended analyte level, the gradual transition model excludes analyte levels whose risk score does not meet the user's 102 risk tolerance profile, as indicated by the user's 102 analyte level criteria. For example, the gradual transition model may select the user's 102 recommended analyte levels from a set of analyte levels whose hyperglycemic risk score meets the user's 102 hyperglycemic risk tolerance threshold and whose hypoglycemic risk score meets the user's 102 hypoglycemic risk tolerance threshold.

[0159] In some embodiments, the gradual transition model may determine the magnitude and timing of a recommended change in analyte level. To determine the magnitude and timing of the recommended analyte level change, the gradual transition model may use the direction and amount of the user's recent change in analyte level to determine how aggressively to change the user's 102's recommended analyte level. For example, a recent significant improvement in glucose concentration measurements may be used to infer momentum in the user's 102 behavior and determine a more aggressive recommended change in the user's 102's analyte level. In some embodiments, the magnitude and timing of the recommended change in the user's 102's analyte level may be determined by utilizing a CMAB algorithm, such as the multi-purpose CMAB algorithm, using contextual data associated with the user 102 (e.g., demographic data such as age data).

[0160] 8 is a flow chart illustrating an example operational process 800 of the CMAB algorithm, according to certain embodiments of the present disclosure. Process 800 may include assigning a random set of hyperparameters to each user (step 1). For example, during initial exploration, the CMAB algorithm may assign each user a hyperglycemia threshold (e.g., hyperglycemia threshold 1 = 180 mg / dL, hyperglycemia threshold 2 = 185 mg / dL, hyperglycemia threshold 3 = 190 mg / dL, hyperglycemia threshold 4 = 195 mg / dL, etc.). Process 800 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.

[0161] For example, for each user, the custom algorithm may recommend a set of analyte levels over a set of future time periods based on the assigned hyperglycemic threshold. For example, for a user assigned a hyperglycemic threshold of 1, the set of analyte levels over a set of future time periods may be aggressive (e.g., glucose ranges of 70 mg / dL to 220 mg / dL in week 1, 70 mg / dL to 200 mg / dL in week 2, 70 mg / dL to 180 mg / dL in week 3, and 70 mg / dL to 160 mg / dL in week 4). However, for a user assigned a hyperglycemic threshold of 4, the series of analyte levels over a series of future time periods may be less aggressive (e.g., glucose ranges of 70 mg / dL to 220 mg / dL in month 1, 70 mg / dL to 200 mg / dL in month 2, 70 mg / dL to 180 mg / dL in month 3, and 70 mg / dL to 160 mg / dL in week 4).

[0162] In another example, for each user, the customer-facing algorithm can recommend a sequence of actions to perform over a series of future time periods. For example, for a user assigned a hyperglycemic threshold of 1, the sequence of actions may be aggressive (e.g., 5,000 steps per day in week 1, 6,000 steps per day in week 2, 7,000 steps per day in week 3, and 8,000 steps per day in week 4). However, for a user assigned a hyperglycemic threshold of 4, the sequence of actions may be less aggressive (e.g., 5,000 steps per day in week 1, 5,500 steps per day in week 2, 6,000 steps per day in week 3, and 6,500 steps per day in week 4). The CMAB algorithm can observe outcomes associated with the decision support output and train an outcome prediction model based on the observed data.

[0163] Further, process 800 may include dividing users into an exploration subset and a usage subset (step 3) and determining scaled outcomes for users in the usage subset by scaling the predicted outcomes determined using the outcome prediction model (step 4). For example, the CMAB algorithm may place users in an exploration subgroup that continues to be assigned a random hyperparameter (e.g., one of hyperglycemia thresholds 1-4). The CMAB algorithm may further place users in usage subgroups, and users in the usage subgroups may be assigned a hyperparameter, along with an outcome, based on each user's contextual information and the model's learned relationship between the context (e.g., the user's age) and a certain hyperparameter value (e.g., one of hyperglycemia thresholds 1-4). The learned relationship enables CMAB to predict outcomes such as, but not limited to, the success rate of recommending a particular sequence of analyte levels over a sequence of future time periods or the success rate of recommending a particular sequence of actions over a sequence of future time periods for a particular user. In particular embodiments, the predicted outcomes may be represented by scaled values, and the CMAB may select hyperparameters corresponding to the optimal scaled values ​​for the users in the usage subgroup. In other words, process 800 may include determining optimal hyperparameter sets for users in the usage subset based on the scaled outcomes (step 5) and assigning the optimal hyperparameter sets to those users. Furthermore, process 800 may include randomly assigning hyperparameters to users in the search subset (step 6) and retraining the outcome prediction model using this data and the observed outcomes. In particular embodiments, process 800 may repeat steps 2-6.

[0164] Exemplary Apparatus for Determining Decision Support Output Using User-Specific Analyte Level Criteria 9 is a block diagram illustrating an example of a computing device 900 configured to determine decision support outputs using user-specific analyte-level criteria, according to certain embodiments disclosed herein. While depicted as a single physical device, in embodiments, computing device 900 may be implemented using virtual devices and / or across several devices, such as in a cloud environment. As illustrated, computing device 900 includes one or more processors 905, non-volatile memory 910, volatile memory 915, a network interface 925, and one or more input / output (I / O) interfaces 920. In the illustrated embodiment, processor 905 retrieves and executes programming instructions stored in non-volatile memory 910 and / or volatile memory 915, and stores and retrieves data residing in non-volatile memory 910 and / or volatile memory 915. In particular embodiments, the non-volatile memory 910 is configured to store instructions (e.g., computer-executable code, device applications 940) that, when executed by the processor 905, cause the processor 905 to perform the processes and / or operations described herein and illustrated in Figures 3-8. In particular embodiments, the non-volatile memory 910 stores code for performing the functions of the DAM 111, the decision support engine 112, and / or the applications 106. It should be noted that the computing device 900 may be configured to perform only the functions of any one of the DAM 111, the decision support engine 112, and / or the applications 106, in which case additional systems may be used to perform the other functions.

[0165] Processor 905 generally represents a single central processing unit (CPU) and / or graphics processing unit (GPU), multiple CPUs and / or GPUs, a single CPU and / or GPU with multiple processing cores, etc. Volatile memory 915 is included generally to represent random access memory (RAM). Non-volatile memory 910 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).

[0166] In some embodiments, I / O devices 935 (e.g., keyboard, monitor, etc.) can be connected via I / O interface 920. Additionally, via network interface 925, computing device 900 may be communicatively coupled to one or more other devices and components, such as user database 110. In particular embodiments, computing device 900 is communicatively coupled to other devices via a network, which may include the Internet, a local network, etc. The network may include wired connections, wireless connections, or a combination of wired and wireless connections. As shown, processor 905, non-volatile memory 910, volatile memory 915, network interface 925, and I / O interface 920 are communicatively coupled by one or more interconnection buses 930. In particular embodiments, computing device 900 is a server running in an on-premise data center or a cloud environment. In particular embodiments, computing device 900 is a user's mobile device.

[0167] In the illustrated embodiment, the non-volatile memory 910 may include a device application 940 that configures the processor 905 to perform various processes and / or operations in determining the decision support output 975 using the user-specific analyte criteria, as described above. In some embodiments, the device application 940 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-8 , the computing device 900 may be configured to determine and / or store at least one analyte level criterion 945. In some embodiments, the at least one analyte level criterion 945 may include optimal level range data 950 and / or risk tolerance profile data 955, as described further above. Additionally, the computing device 900 may be configured to receive and / or store input data 960 (e.g., input 127) and / or healthcare provider input data 965. Furthermore, the computing device 900 may be configured to receive and / or generate metric data 970 (e.g., metrics 130), as described above. In certain embodiments, metric data 970 may include at least one analyte level criteria 945 including optimal level range data 950 and / or risk tolerance data 955 .

[0168] 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) as 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.

[0169] 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.

[0170] As used herein, the terms "a" or "an" are used, as is common in patent documents, to include one or more than one, regardless of other instances or uses of "at least one" or "one or more." As used herein, the term "or" is used to refer to a non-exclusive inclusion, unless otherwise indicated, such that "A or B" includes "A but not B," "B but not A," or "A and B." As used herein, the terms "including" and "in which" are used as the plain English equivalents of the respective terms "comprising" and "wherein." Also, in the claims that follow, the terms "including" and "comprising" are open-ended, i.e., systems, devices, articles, compositions, formulations, or processes that include elements in addition to those recited after such terms in a claim are still deemed to be within the scope of that claim. Moreover, in the following claims, the terms "first," "second," and "third," etc., are used merely as labels and are not intended to impose numerical requirements on their objects.

[0171] Geometric terms such as "parallel," "perpendicular," "circular," and "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.

[0172] 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.

[0173] The above description is intended to be illustrative, not limiting. For example, the above examples (or one or more aspects thereof) could be used in combination with each other. Other embodiments may be used, such as by one 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 less 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.

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: receiving sensor data generated by an analyte sensor configured to monitor at least one analyte; determining at least one analyte level criterion of the user for the at least one analyte; determining at least one decision support output based on said at least one analyte level criterion using a decision support model; and providing the at least one decision support output to the user.

2. 10. The non-transitory computer-readable storage medium of claim 1, wherein the at least one analyte level criterion is an optimal level range for the at least one analyte.

3. 3. The non-transitory computer-readable storage medium of claim 2, wherein the optimal level range comprises a high analyte threshold defining an upper limit for the at least one analyte and a low analyte threshold defining a lower limit for the at least one analyte.

4. The operation is 4. The non-transitory computer-readable storage medium of claim 3, further comprising receiving user input indicating the high analyte threshold and the low analyte threshold, wherein the high analyte threshold and the low analyte threshold are determined based on the user input.

5. The optimum level range is: Defining a duration threshold; and upon determining that the sensor data covers the thresholds for the period, generating a trend using the sensor data to determine the high analyte threshold and the low analyte threshold.

6. The optimum level range is: Defining a duration threshold; and if the sensor data does not cover the thresholds for the period, generating a trend using sensor data of a cohort to determine the high analyte threshold and the low analyte threshold.

7. The non-transitory computer-readable storage medium of claim 1 , wherein the at least one analyte level criteria is a risk tolerance profile of the user.

8. 8. The non-transitory computer-readable storage medium of claim 7, wherein the risk tolerance profile includes a high-level risk tolerance threshold that defines the user's willingness to risk having an analyte level that exceeds a recommended high analyte level range, and a low-level risk tolerance threshold that defines the user's willingness to risk having the analyte level that is below a recommended low analyte level range.

9. 1. A method for determining a decision support output using user-specified analyte level criteria, the method comprising: receiving sensor data generated by an analyte sensor configured to monitor at least one analyte; determining at least one analyte level criterion of the user for the at least one analyte; determining at least one decision support output based on said at least one analyte level criterion using a decision support model; and providing said at least one decision support output to said user.

10. 10. The method of claim 9, wherein the at least one analyte level reference is an optimal level range for the at least one analyte.

11. 11. The method of claim 10, wherein the optimal level range comprises a high analyte threshold defining an upper limit for the at least one analyte and a low analyte threshold defining a lower limit for the at least one analyte.

12. 12. The method of claim 11, further comprising receiving user input indicating the high analyte threshold and the low analyte threshold, wherein the high analyte threshold and the low analyte threshold are determined based on the user input.

13. The method of claim 9 , wherein the at least one analyte level criteria is a risk tolerance profile of the user.

14. 14. The method of claim 13, wherein the risk tolerance profile includes a high-level risk tolerance threshold that defines the user's willingness to risk having an analyte level that exceeds a recommended high analyte level range, and a low-level risk tolerance threshold that defines the user's willingness to risk having the analyte level that is below a recommended low analyte level range.

15. 1. A computing device for determining a decision support output using user-specific analyte level criteria, the computing device comprising: A network interface; a processor operatively connected to the network interface; A memory storing a program including instructions that, when executed by the processor, cause the computing device to: receiving, using the network interface, sensor data generated by an analyte sensor configured to monitor at least one analyte; determining at least one analyte level criteria for the user for said at least one analyte; using a decision support model to determine at least one decision support output based on said at least one analyte level criterion; and a memory for causing the at least one decision support output to be provided to the user.

16. 16. The computing device of claim 15, wherein the at least one analyte level criterion is an optimal level range for the at least one analyte.

17. 17. The computing device of claim 16, wherein the optimal level range comprises a high analyte threshold defining an upper limit for the at least one analyte and a low analyte threshold defining a lower limit for the at least one analyte.

18. the computing device, 20. The computing device of claim 17, further configured to receive user input indicating the high analyte threshold and the low analyte threshold, wherein the high analyte threshold and the low analyte threshold are determined based on the user input.

19. The computing device of claim 15 , wherein the at least one analyte level criteria is a risk tolerance profile of the user.

20. 20. The computing device of claim 19, wherein the risk tolerance profile includes a high-level risk tolerance threshold that defines the user's willingness to risk having an analyte level that exceeds a recommended high analyte level range, and a low-level risk tolerance threshold that defines the user's willingness to risk having the analyte level that is below a recommended low analyte level range.

Images