Determining decision support output using user-specific analyte level criteria

Abstract

Systems, devices, and methods are provided for determining a decision support output using user-specific analyte level criteria to improve a health outcome of a patient. In one embodiment, there is provided a non-transitory computer-readable storage medium storing a program, the program comprising instructions, the instructions, 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 at least one analyte for the user; 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.

Description

[0001] Cross - Reference to Related Applications

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

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

[0004] Description of Related Technologies

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

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

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

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

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

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

[0011] Various embodiments of the present invention systems, devices, and methods for using user-specific analyte level criteria to determine decision support outputs to improve patient health outcomes include several features, none of which alone is responsible for their desired properties. Without limiting the scope of this embodiment, its more prominent features will now be discussed below. After considering this discussion, particularly after reading the section entitled "Detailed Description", it will be understood how the features of the embodiments of the present invention provide the advantages described herein.

[0012] In a first aspect, there is provided a non-transitory computer-readable storage medium storing a program that includes instructions that, when executed by at least one processor of a computing device, cause the at least one processor to perform operations including: receiving sensor data generated by an analyte sensor configured to monitor at least one analyte; determining, for the user, at least one analyte level criterion 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.

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

[0014] In another embodiment of this first aspect, the optimal level range includes a high analyte threshold defining an upper boundary of the at least one analyte and a low analyte threshold defining a lower boundary of the at least one analyte.

[0015] In another embodiment of this first aspect, the operations further include: 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.

[0016] In another embodiment of this first aspect, the optimal level range is determined by: defining a threshold time period; and when determining that the sensor data covers the threshold time period, using the sensor data to generate a trend to determine the high-level analyte threshold and the low-level analyte threshold.

[0017] In another embodiment of this first aspect, the optimal level range is determined by: defining a threshold time period; and when determining that the sensor data does not cover the threshold time period, using the sensor data of the queue to generate a trend to determine the high-level analyte threshold and the low-level analyte threshold.

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

[0019] In another embodiment of this first aspect, the at least one analyte level criterion is the user's risk tolerance profile.

[0020] In another embodiment of this first aspect, the risk tolerance profile includes a high-level risk tolerance threshold and a low-level risk tolerance threshold. The high-level risk tolerance threshold defines the user's willingness to take risks for analyte levels that exceed the recommended high analyte level range, and the low-level risk tolerance threshold defines the user's willingness to take risks for analyte levels that are below the recommended low analyte level range.

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

[0022] In another embodiment of this first aspect, the user input includes the user's risk tolerance levels for multiple ranges of the recommended high analyte level range and multiple ranges of the recommended low analyte level range.

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

[0024] In another embodiment of this first aspect, the user input includes an acceptable time range for high-level analyte events and low-level analyte events.

[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, further cause the at least one processor to: determine the risk tolerance profile based on a contextual multi-armed bandit algorithm.

[0026] 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, further cause the at least one processor to: use the decision support model to determine the at least one decision support output based on the at least one analyte level criterion by: determining hyperparameters based on the optimal level range; and using the hyperparameters to execute the decision support 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, further cause the at least one processor to: use the decision support model to determine the 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 using the hyperparameters to execute the decision support model.

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

[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, further cause the at least one processor to: use the decision support model to determine the at least one decision support output based on the at least one analyte level criterion by: configuring the scoring sub-model to process the at least one analyte level criterion to determine at least one risk score of the user.

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

[0031] 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, further cause the at least one processor to: use the decision support model to determine at least one decision support output by: configuring the decision-making 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.

[0032] In a second aspect, a method for determining a decision support output using user-specific analyte level criteria is provided, the method comprising: 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 at least one analyte for the user; 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.

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

[0034] In another embodiment of this second aspect, the optimal level range includes a high analyte threshold defining an upper boundary of the at least one analyte and a low analyte threshold defining a lower boundary of the at least one analyte.

[0035] In another embodiment of this second aspect, the method further comprises: 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.

[0036] In another embodiment of this second aspect, the optimal level range is determined by: defining a threshold time period; and using the sensor data to generate a trend to determine the high analyte threshold and the low analyte threshold when it is determined that the sensor data covers the threshold time period.

[0037] In another embodiment of this second aspect, the optimal level range is determined by: defining a threshold time period; and using sensor data of a queue to generate a trend to determine the high analyte threshold and the low analyte threshold when it is determined that the sensor data does not cover the threshold time period.

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

[0039] In another embodiment of this second aspect, the at least one analyte level criterion is the user's risk tolerance profile.

[0040] In another embodiment of this second aspect, the risk tolerance profile includes a high-level risk tolerance threshold and a low-level risk tolerance threshold. The high-level risk tolerance threshold defines the user's willingness to take risks for analyte levels that exceed the recommended high analyte level range, and the low-level risk tolerance threshold defines the user's willingness to take risks for analyte levels that are below the recommended low analyte level range.

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

[0042] In another embodiment of this second aspect, the user input includes the user's risk tolerance levels for multiple ranges of the recommended high analyte level range and multiple ranges of the recommended low analyte level range.

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

[0044] In another embodiment of this second aspect, the user input includes an acceptable time range for high-level analyte events and low-level analyte events.

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

[0046] In another embodiment of this second aspect, the method further includes using the decision support model to determine the at least one decision support output based on the at least one analyte level criterion by: determining hyperparameters based on the optimal level range; and using the hyperparameters to execute the decision support model.

[0047] In another embodiment of this second aspect, the method further includes using the decision support model to determine the 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 using the hyperparameters to execute the decision support model.

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

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

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

[0051] In another embodiment of this second aspect, the method further includes: using the decision support model to determine the at least one decision support output by: configuring the 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.

[0052] In a third aspect, there is provided a computing device for determining a decision support output using user-specific analyte level criteria, the computing device including: a network interface; a processor operatively connected to the network interface; a memory storing a program including instructions that, when executed by the processor, cause the computing device to perform operations including: using the network interface to receive sensor data generated by an analyte sensor configured to monitor at least one analyte; determining, for the user, at least one analyte level criterion 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.

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

[0054] In another embodiment of this third aspect, the optimal level range includes a high analyte threshold defining an upper boundary of the at least one analyte and a low analyte threshold defining a lower boundary of the at least one analyte.

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

[0056] In another embodiment of this third aspect, the optimal level range is determined by: defining a threshold time period; and using the sensor data to generate a trend to determine the high analyte threshold and the low analyte threshold when it is determined that the sensor data covers the threshold time period.

[0057] In another embodiment of this third aspect, the optimal level range is determined by: defining a threshold time period; and when it is determined that the sensor data does not cover the threshold time period, then using sensor data from a queue to generate a trend to determine the high analyte threshold and the low analyte threshold.

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

[0059] In another embodiment of this third aspect, the at least one analyte level criterion is the user's risk tolerance profile.

[0060] In another embodiment of this third aspect, the risk tolerance profile includes a high-level risk tolerance threshold and a low-level risk tolerance threshold. The high-level risk tolerance threshold defines the user's willingness to take risks for analyte levels that exceed the recommended high analyte level range, and the low-level risk tolerance threshold defines the user's willingness to take risks for analyte levels that are below the recommended low analyte level range.

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

[0062] In another embodiment of this third aspect, the user input includes the user's risk tolerance levels for multiple ranges of the recommended high analyte level range and multiple ranges of the recommended low analyte level range.

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

[0064] In another embodiment of this third aspect, the user input includes an acceptable time range for high-level analyte events and low-level analyte events.

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

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

[0067] In another implementation of this third aspect, the program further includes instructions that, when executed by the processor, further cause the computing device to: use the decision support model to determine the 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 using the hyperparameters to execute the decision support model.

[0068] In another implementation of this third aspect, the decision support model includes a scoring submodel and a decision submodel.

[0069] In another implementation of this third aspect, the program further includes instructions that, when executed by the processor, further cause the computing device to: use the decision support model to determine the at least one decision support output based on the at least one analyte level criterion by: configuring the scoring submodel to process the at least one analyte level criterion to determine at least one risk score of the user.

[0070] In another implementation of this third aspect, the at least one risk score includes the predicted likelihood that the user will experience a specific condition in a future time period.

[0071] In another implementation of this third aspect, the program further includes instructions that, when executed by the processor, further cause the computing device to: use the decision support model to determine the at least one decision support output 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 DESCRIPTION OF THE DRAWINGS

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

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

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

[0075] Figure 3 Is a flowchart illustrating a process for using user-specific analyte level criteria to determine a decision support output in accordance with certain embodiments of the present disclosure.

[0076] Figure 4 Is a flowchart illustrating a process for determining at least one analyte level criterion in accordance with certain embodiments of the present disclosure.

[0077] Figure 5is a flowchart illustrating a process for determining an optimal analyte level range for a user in accordance with certain embodiments of the present disclosure.

[0078] Figure 6 is a flowchart illustrating a process for determining a risk tolerance profile for a user in accordance with certain embodiments of the present disclosure.

[0079] Figure 7 is a flowchart illustrating a process for determining at least one decision support output based on at least one analyte level criterion using a decision support model in accordance with certain embodiments of the present disclosure.

[0080] Figure 8 is a flowchart illustrating an exemplary operational process of a contextual multi-armed bandit (CMAB) algorithm in accordance with certain embodiments of the present disclosure.

[0081] Figure 9 is a block diagram depicting a computing device configured to perform 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

[0082] Portable and / or wearable health monitoring devices (also referred to herein as "health monitoring devices") and mobile health applications (also referred to herein as "applications") have rapidly gained popularity due to their ability to support user-centered care. For example, the management of diabetes can pose complex challenges for patients, clinicians, and caregivers because the convergence of many factors can affect a patient's glucose levels and glucose trends. To help patients better manage this condition, health monitoring devices (e.g., sensors and other types of monitoring and diagnostic devices) and various mobile health applications (e.g., diabetes intervention software applications) have been developed. In the healthcare field, the widespread adoption of health monitoring devices and the increasing development and distribution of mobile health applications have improved health management, and more specifically, chronic disease management. In particular, the use of mobile health applications in conjunction with these health monitoring devices represents a more scalable and potentially more cost-effective alternative to traditional interventions, thereby 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.

[0083] Mobile health applications enable users to be more involved in their own healthcare by authorizing them to access and control their health information, which results in better patient satisfaction and improved care and clinical outcomes. In particular, mobile health applications enable users to access, monitor, record, and update their health information without being restricted by physical constraints such as time and location. Commercially available mobile health applications provide functions such as delivering health information, medication reminders, remote monitoring, and mobile analytics to improve users' health literacy, encourage users to play a more active role in managing their health or disease, promote adherence to treatment, and provide other types of decision support guidance.

[0084] In particular, a variety of intervention applications have been developed to deliver guidance that can assist patients, caregivers, healthcare providers, or other users in improving their lifestyle or clinical / patient outcomes by addressing various challenges such as analyte control, exercise, and / or other health factors. As used herein, the term "analyte" refers to, but is not limited to, substances or chemical components in a bodily or biological sample. For example, a diabetes intervention application can assist patients, caregivers, healthcare providers, or other users in aspects such as nocturnal glucose control (e.g., reducing the incidence of hypoglycemic events or hyperglycemic fluctuations), in-meal and post-meal glucose control (e.g., using historical information and trends to enhance glycemic control), hyperglycemic correction (e.g., increasing the time in the target range while avoiding hypoglycemic events caused by overcorrection), and / or hypoglycemic treatment (e.g., addressing hypoglycemia while avoiding "rebound" hyperglycemia).

[0085] Mobile health applications can provide such assistance to users in the form of some type of guidance. For example, the guidance can include a graphical summary of the user's data over time or mobile notifications to the user, where the notifications are provided to inform, warn, and / or recommend an action to the user. As an example, the application can help the user respond to a health condition in real time by predicting events or trends and provide treatment recommendations to address ongoing or potential events or trends in real time. This type of computed guidance and support can reduce the cognitive burden on the user. Some mobile health applications also allow data to be output in various formats for sharing with third parties and / or enabling the user to directly contact healthcare professionals for feedback, which can support improved patient-professional dialogue. Thus, if utilized, mobile health applications can improve the quality of care while offering the potential to reduce the costs of the healthcare system.

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

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

[0088] As discussed herein, unfortunately, health monitoring systems (including health monitoring devices and / or mobile health applications) designed to support the management of chronic diseases or health conditions have suffered from low user engagement and high user attrition rates. The reasons for low user engagement and / or high user attrition rates can include the inability of health monitoring systems to provide individualized or personalized decision support outputs (e.g., information, recommendations, warnings, etc.). When a mobile health application fails to provide individualized and / or personalized decision support outputs, users of the application may find the output ineffective and they are unable to take a holistic approach to manage their health (e.g., diseases, conditions, fitness, etc.). In addition, decision support outputs that are not customized for an individual (i.e., not "individualized") may lead to sub-optimal health outcomes. Moreover, decision support outputs that are not customized for a cohort of which the individual is a member (i.e., not "personalized") may also lead to sub-optimal health outcomes. Thus, the user engagement associated with such mobile health applications can be reduced, and thereby the user attrition rate can increase.

[0089] 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 the user's optimal glucose concentration range, the user's willingness to enter hyperglycemia, and the user's willingness to enter hypoglycemia. As another example, a user may have personal preferences regarding the optimal potassium concentration range, the user's willingness to enter hyperkalemia, and the user's willingness to enter hypokalemia. To provide individualized and / or personalized decision support outputs, a mobile health application should determine the decision support output in a manner that effectively utilizes user-specific preferences regarding optimal analyte levels and / or analyte risk tolerance thresholds. Otherwise, the decision support output may be less effective in providing individualized or personalized guidance to the user, resulting in increased user churn from the mobile health application.

[0090] 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 that describe the monitored analyte levels of the user. The user may then use a mobile health application that is configured to execute on a computing device (e.g., the user's display device, such as, but not limited to, a smart phone, etc.) to receive the sensor output and provide a decision support output to the user based on the sensor output and / or user-specific analyte level criteria. For example, the decision support output may recommend one or more actions for the user to perform (e.g., a recommended sleep pattern for the user), recommend one or more warnings to the user regarding the user's predicted future physiological condition (e.g., a warning that the user may experience hyperglycemia in the next eight hours), etc. In some embodiments, the sensor output may be sent to one or more computing devices, one or more servers, and / or one or more user databases. In some embodiments, one or more user databases may be separate from one or more servers. In some embodiments, one or more user databases may be a component of one or more servers.

[0091] In some embodiments, a computing device may utilize one or more decision support models when providing decision support output to a user. A decision support model may be a user-facing algorithm that determines a user's decision support output based on various parameters such as, but not limited to, sensor outputs and / or user-specific analyte level criteria. An example of a decision support model is a sleep advisor model that is configured to select a recommended sleep pattern for a user from a set of potential sleep patterns. Another example of a decision support model is a hyperglycemic warning model that is configured to warn a user if the hyperglycemic warning model determines that the user is at risk of hyperglycemia during a future time period (e.g., during the next eight hours). An additional example of a decision support model is a gradual transition model (also referred to herein as a “nudge” model) that is configured to provide a user with a series of recommended analyte levels over a series of future time periods to assist and encourage the user to gradually transition the user's analyte value from a current analyte value range to an optimal analyte value range.

[0092] Certain embodiments described herein enable the use of a decision support model to determine a decision support output, the operation of which is determined based on a set of analyte level criteria for a user. A user's analyte level criteria may be one or more values that describe an aspect of an acceptable range of analyte levels for the user (e.g., an acceptable range of glucose concentrations), where the value 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 high-level analyte thresholds (e.g., hyperglycemic thresholds), low-level analyte thresholds (e.g., hypoglycemic thresholds), high-level risk tolerance thresholds (e.g., hyperglycemic risk tolerance thresholds), and low-level risk tolerance thresholds (e.g., hypoglycemic risk tolerance thresholds).

[0093] A high-level analyte threshold may define an upper boundary of a recommended analyte level range for a user. A low-level analyte threshold may define a lower boundary of a recommended analyte level range for a user. A high-level risk tolerance threshold may define a degree of willingness of a user to take risks for an analyte level that exceeds the recommended analyte level range of the user. A low-level risk tolerance threshold may define a degree of willingness of a user to take risks for an analyte level that is below the recommended analyte level range of the user. In some embodiments, a user may have more than one high-level risk tolerance threshold and / or low-level risk tolerance threshold. For example, a user may have a first high risk tolerance threshold for a first analyte level range that exceeds the recommended analyte level range of the user and a second high risk tolerance threshold for a second analyte level range that exceeds the recommended analyte level range of the user. As another example, a user may have a first low risk tolerance threshold for a first analyte level range and a second low risk tolerance threshold for a second analyte level range, the first low risk tolerance threshold falling below the recommended analyte level range for the user and the second low risk tolerance threshold falling below the recommended analyte level range for the user.

[0094] To determine a decision support output for a user, a computing device may be configured to first determine one or more analyte level criteria for the user. In some embodiments, a mobile health management application may use one or more decision support models and the determined one or more analyte level criteria to determine a decision support output. There may be various techniques for using a user's analyte level criteria in conjunction with a decision support model to determine a decision support output. For example, in a first technique, one or more analyte level criteria of a user may be used to determine user-specific hyperparameters of a decision support model. The user-specific hyperparameters may be used by the decision support model to determine a decision support output for a particular user associated with the hyperparameter. Using this first technique, a decision support model may be able to use different user-specific hyperparameters to determine decision support outputs for different users, thereby increasing the adaptability and prediction accuracy of the decision support model. An example of a user-specific hyperparameter that may be determined based on analyte level criteria is a user-specific hyperglycemia threshold for a hyperglycemia warning model. The hyperglycemia warning model may use the user-specific hyperglycemia threshold to determine whether to warn the corresponding user about the likelihood of future hyperglycemia. In this example, the hyperglycemia warning 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 warning determination is an example of a decision support output determined for the corresponding user.

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

[0096] In both of the above techniques, the user's analyte level criteria may be integrated into the operational logic of the decision support model to determine the user's decision support output. Because the embodiments described herein enable the integration of user-specific analyte level criteria 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 is thus effective for the user. As noted above, providing an ineffective decision support output to the user results in a higher user churn rate from the mobile health application. By enabling the mobile health application to provide a more effective decision support output, certain embodiments described herein may increase user engagement with those applications and thus reduce user churn from those applications.

[0097] In addition, although the description and examples below are directed to glucose monitoring sensors capable of measuring glucose concentration in a host, the systems, devices, and methods of the embodiments described herein may be used in conjunction with any type of analyte sensor for any measurable analyte. The systems, devices, and methods of the embodiments described herein may be used in conjunction with any health-related application provided to the user to improve the user's health. For example, a health-related application may assist a user in treating a disease or may simply help improve the health of a user who is not necessarily diagnosed with a disease.

[0098] An example system having a decision support engine for determining a decision support output using user - specific analyte level criteria Example System

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

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

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

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

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

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

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

[0106] As discussed in more detail herein, the decision support engine 112 can use 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 can use 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 executing a decision support model based on the set of analyte level criteria to determine the decision support output. In certain embodiments, the set of analyte level criteria can be specifically determined for the user 102 in order to determine an individualized decision support output for the user 102. In some embodiments, the set of analyte level criteria can be determined for a cohort including the user 102 in order to determine a personalized decision support output for the user. As used herein, a "cohort" can be a collection of "similar" users having similar demographics, health histories, and / or other characteristics that affect outcomes. Additionally, the decision support engine 112 can execute a decision support model based on the set of analyte level criteria to determine the decision support output. To execute a decision support model based on the set of analyte level criteria, the analyte level criteria can 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.

[0107] In some embodiments, the decision support engine 112 can use user-specific analyte level criteria to determine a decision support output based on information including but not limited to information included in the user profile 118 stored in the user database 110. In some embodiments, the user profile 118 can include information about the user collected from the application 106, as further described below.

[0108] In some embodiments, the DAM 111 of the decision support engine 112 may be configured to receive and / or process a set of inputs 127 (described in more detail below) (also referred to herein as "input data") to determine one or more metrics 130 (also referred to herein as "metric data"), which may then be used by the decision support engine 112 to determine a decision support output and provide the decision support output to the user 102. The inputs 127 may be stored in the user profile 118 in the user database 110. The DAM 111 may extract the inputs 127 from the user database 110 and calculate a plurality of metrics 130, which may then be stored in the user profile 118 as application data 126. Such metrics 130 may include health-related metrics.

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

[0110] In some embodiments, the application 106 may obtain demographic information 119, disease progression information 121, and / or drug information 122 from the user 102 or from other sources in the form of user input. In some embodiments, when some of this information changes, the application 106 may receive updates from the user 102 or from other sources. In some embodiments, the user profile 118 associated with the user 102 and other user profiles associated with other users are stored in the user database 110, which can be accessed by the application 106 and the decision support engine 112 via one or more networks (not shown). In some embodiments, the application 106 collects input 127 through user 102 input and / or multiple other sources, which include the analyte monitoring system 104, other applications running on the mobile device 107, and / or one or more other sensors and devices. In some embodiments, such sensors and devices include, but are not limited to, one or more of the following: 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 smartwatch), or any other sensors or devices that provide relevant information about the user 102. In some embodiments, the user profile 118 also stores application configuration information indicating the current configuration of the application 106 (including its features and settings).

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

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

[0113] Figure 1BIllustrates a continuous analyte monitoring system in accordance with certain embodiments of the present disclosure. FIG. 150 illustrates an example of an analyte monitoring system 104. In Figure 1B the example, the analyte monitoring system 104 is a glucose monitoring system. However, as described above, the analyte monitoring system 104 can be configured to measure any other analyte or combination of analytes. Figure 1B Illustrates a plurality of mobile devices 107a, 107b, 107c, and 107d (referred to individually as mobile device 107 and collectively as mobile devices 107). Note that Figure 1A the mobile device 107 can be any one of mobile devices 107a, 107b, 107c, or 107d. In other words, any one of mobile devices 107a, 107b, 107c, or 107d can be configured to execute the application 106. The analyte monitoring system 104 can be communicatively coupled to mobile devices 107a, 107b, 107c, and / or 107d.

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

[0137] to

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

[0137] to

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

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

[0116] 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 each other. The analyte sensor electronics module 138 may include hardware, firmware, and / or software that are capable of measuring and / or estimating the level of an analyte in a user's body via the analyte sensor 140 (which may be, for example, / include a glucose sensor). For example, the analyte sensor electronics module 138 may include one or more potentiostats, a power source for providing power to the analyte sensor 140, other components for signal processing and data storage, and a telemetry module for sending 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), the user database 110, the decision support engine 112, etc. The electronics may be attached to a printed circuit board (PCB) or platform, etc. within the analyte monitoring system 104 and may take various forms. For example, the electronics may take the form of an integrated circuit (IC), such as an application specific integrated circuit (ASIC), a microcontroller, a processor, and / or a state machine.

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

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

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

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

[0072] to

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

[0072] to

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

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

[0120] The mobile device 107 can include a customized or proprietary display device, such as an analyte display device 107b, which is particularly designed to display certain types of displayable sensor information (e.g., numerical values and / or arrows in certain embodiments) associated with analyte data received from the sensor electronics module 138. In certain embodiments, one of the mobile devices in the mobile device 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).

[0121] In Figure 2 are illustrated an example input and example metrics generated based on that input according to certain embodiments of the present disclosure. Figure 2 Illustrated are example input 127 on the left, application 106 and DAM 111 in the middle, and example metrics 130 on the right. In certain embodiments, the application 106 can obtain the input 127 through one or more channels (e.g., manual user input, sensors, various applications executed on the mobile device 107, etc.). The input 127 can be further processed by the DAM 111 to output a plurality of metrics, such as the metric 130, and features 1-N of the application 106 can similarly use these metrics to provide guidance to the user. In certain embodiments, the input 127 and the metric 130 can also be used by the DAM 111 and / or any computing device in the system 100 as context information to perform various actions, such as but not limited to identifying queues and / or defining various sub-queues within the user queue. Additionally, the DAM 111 and / or any computing device in the system 100 can use the input (e.g., input 127) and the metric (e.g., metric 130) to perform various processes for determining decision support outputs using user-specific analyte level criteria, as further described below. Any one of the inputs in the input 127 can be used to calculate any one of the metrics in the metric 130. In certain embodiments, each metric in the metric 130 can correspond to one or more values, e.g., discrete numerical values, ranges, or qualitative values (high / medium / low or stable / unstable).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0136] In some embodiments, the metric 130 determined or calculated by DAM 111 includes a clinical metric. Clinical metrics generally indicate the clinical state of the user with respect to one or more conditions of the user, such as diabetes. For example, in the case of diabetes, the clinical metric may be determined based on blood glucose measurements and may include 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 some embodiments, the clinical metric may also include one or more of an estimated A1C, glycemic variability, hypoglycemia, and / or a health indicator (the amount of time outside the target zone).

[0137] In some embodiments, the metric 130 determined or calculated by DAM 111 may include at least one analyte level criterion, as further described below. In some embodiments, the at least one analyte level criterion may include a range of optimal levels of the analyte and a risk tolerance profile of the user. As further described below, the optimal level range and risk tolerance profile of the user may be determined based on the input 127 (e.g., received user input, received healthcare provider input). In some embodiments, the optimal level range and risk tolerance profile of the user may be determined based on the metric 130, such as but not limited to the trend of historical analyte level data (e.g., glucose trend). In some embodiments, the optimal level range and risk tolerance profile of the user may be determined based on various algorithms that may utilize the input 127 and the metric 130, as further described below. The optimal level range and risk tolerance profile are described in more detail below.

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

[0139] An example process for determining a decision support output using user - specific analyte level criteria

[0140] Figure 3 is a flowchart illustrating process 300 for determining decision support outputs using user-specific analyte level criteria in accordance with certain embodiments of the present disclosure. In certain embodiments, process 300 may be executed by one or more computing devices, systems (e.g., health monitoring and support system 100), etc. For example, process 300 may use analyte monitoring system 104, application 106, user data 110, data analysis module 111, and / or Figure 1A other components of health monitoring and support system 100 as illustrated therein. In some embodiments, process 300 may include receiving (block 302) input data (e.g., input 127), 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 further described below, process 300 may include determining (block 304) at least one analyte level criterion and using one or more decision support models to determine (block 306) one or more decision support outputs based on the at least one analyte level criterion. Additionally, process 300 may include providing (308) one or more decision support outputs to the user.

[0141] Hereinafter, blocks 304 and 306 are described in more detail with reference to the subsequent Figures 4 to 7 For example, hereinafter, block 304 is described in more detail by referring to Figures 4 to 6 Specifically, block 304 is described in more detail by referring to blocks 402 and 404 of Figure 3 Then, referring to Figure 4 block 304 of Figure 3 is described in more detail by referring to Figure 5The boxes 502 to 508 are described in more detail Figure 4 with respect to box 402, and reference is made to Figure 6 the boxes 602 to 606 for a more detailed description Figure 4 of box 404. After box 304, a more detailed description is then provided by reference to Figure 7 the boxes 702 and 704 for a more detailed description Figure 3 of box 306.

[0142] 1. Block 304: Determine at least one analyte level criterion for the user

[0143] As described above with reference to Figure 3 the process 300 may include determining (box 304) at least one analyte level criterion. The analyte level criterion for user 102 may include at least one of a high level analyte threshold, a low level 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 jointly define the optimal analyte level range for user 102. The high level risk tolerance thresholds and the low level risk tolerance thresholds may jointly define the risk tolerance profile for user 102. Various example processes for determining the optimal level range and risk tolerance profile for user 102 are described below with reference to Figure 4 In particular, Figure 4 box 402 describes determining the optimal analyte level range for the user, while Figure 4 box 404 describes determining the risk tolerance profile for the user. The optimal analyte level range and the risk tolerance profile are examples of analyte level criteria.

[0144] a. Block 402: Determine the optimal analyte level range for the user

[0145] Figure 4 is a flowchart illustrating a process 400 for determining (box 304) at least one analyte level criterion in accordance with certain embodiments of the present disclosure. In some embodiments, the process 400 for determining (box 304) at least one analyte level criterion may include determining (box 402) the optimal level range for user 102 and / or determining (box 404) the risk tolerance profile for user 102, as further described below. Various techniques may be used to determine (box 402) the optimal analyte level range for the user.

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

[0147] For example, user 102 may provide input 127 indicating a high-level analyte threshold and a low-level analyte threshold (i.e., the optimal level range) in a dedicated user interface (UI) of a computing device (e.g., mobile device 107). In some embodiments, to specify the high-level analyte threshold and the low-level analyte threshold, user 102 may provide a selected text description of his or her preferred analyte level range (e.g., "tight", "medium", or "wide") via an application 106 running on mobile device 107. The text description may then be mapped to an associated analyte level range (also referred to herein as "analyte level criteria") by one or more computing devices on system 100. For example, in an embodiment where DAM 111 runs on mobile device 107, the text description may be mapped to an associated analyte level range at mobile device 107. In some embodiments, the text description may be stored in user database 110 and mapped to an associated analyte level range by user database 110 and / or by DAM 111 running on one or more servers network-connected to user database 110. As another example, the user may provide input indicating one or more personal health goals (e.g., keeping the number of hyperglycemic events below a certain number). The computing device may then use the user's historical analyte level trend (e.g., historical glucose concentration trend) to map the goal to the user's optimal analyte level range. In some embodiments, the historical analyte level trend may be metric 130 or may be generated using one or more metrics 130. In some embodiments, one or more inputs 127 and / or a combination of input 127 and metrics 130 may be used to generate the historical analyte level trend. Additionally, the user's high-level analyte threshold and low-level threshold may be determined (block 504) based on data sent by the user's healthcare provider to the computing device.

[0148] Reference Figure 5, the process 500 for determining the optimal level range (block 402) may include determining (block 506) the optimal level range by analyzing historical analyte level data (e.g., metric 130). In some embodiments, determining (block 506) the optimal analyte level range based on historical analyte level data may be performed specifically based on a user or based on a cohort including the user. The determination of whether to use the historical analyte level data of the user or the cohort may be based on whether there is sufficient user-specific historical analyte level data available for user 102. For example, whether there is sufficient user-specific historical analyte level may be based on whether the user-specific historical analyte level covers at least a threshold time period. For example, the threshold time period may be a predetermined time period (e.g., 1 week, 1 month, etc.), or it may be a time period including sufficient data (e.g., blood glucose readings) to determine a trend (e.g., glucose trend).

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

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

[0151] Further reference Figure 5, process 500 for determining the optimal level range (box 402) may include determining (box 508) the optimal level range based on various algorithms and / or models, such as but not limited to multi-armed bandit algorithms, contextual multi-armed bandit (CMAB) algorithms, etc. For example, a CMAB model can be used to determine the optimal analyte level range for user 102 or a user cohort based on the contextual information provided as input. For example, the contextual information of a user may include demographic information 119, disease progression information 121, medication treatment information 122, inputs 127 (e.g., activities, patient statistics, insulin, blood glucose, etc.), metrics 130 (e.g., glucose level, disease stage, etc.), and so on.

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

[0153] b. Block 404: Determine the risk tolerance profile of the user

[0154] As described above, process 400 for determining (box 304) at least one analyte level criterion may include determining (box 402) the optimal level range for user 102 (as Figure 5 illustrated). Additionally, process 400 for determining (box 304) at least one analyte level criterion may include determining (box 404) the risk tolerance profile for user 102 (as Figure 6 illustrated). Various techniques can be used to determine the risk tolerance profile of a user.

[0155] Figure 6FIG. 600 is a flowchart illustrating a process 600 for determining (block 404) a risk tolerance profile of a user in accordance with certain embodiments of the present disclosure. Process 600 may include determining (block 602) a risk tolerance profile of user 102 based on user input received from the user (e.g., input 127). For example, user 102 may provide input 127 that describes the user's willingness to accept risks associated with analyte levels falling within various hypoglycemic and / or hyperglycemic ranges. To enable user 102 to provide input 127, a dedicated UI may display various analyte level ranges to user 102 and request that user 102 specify a risk tolerance level for each displayed range. Examples of analyte level ranges that may be displayed to user 102 include a low hyperglycemic range (e.g., 180 mg / dL to 190 mg / dL), a medium hyperglycemic range (e.g., 190 mg / dL to 220 mg / dL), and a high hyperglycemic range (e.g., 220 mg / dL or higher). Other examples of analyte level ranges that may be displayed to user 102 include a low hypoglycemic range (e.g., 60 mg / dL to 70 mg / dL), a medium hypoglycemic range (e.g., 50 mg / dL to 60 mg / dL), and a high hypoglycemic range (e.g., below 50 mg / dL).

[0156] After user 102 provides input 127 specifying a risk tolerance level, the computing device (e.g., mobile device 107) may then use 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 medium hyperglycemic range, and a third high-level risk tolerance threshold for the high hyperglycemic range. Additionally, 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 medium hypoglycemic range, and a third low-level risk tolerance threshold for the high hypoglycemic range. In this example, six risk tolerance thresholds may be determined based on the user-specified risk tolerance levels for the six analyte level ranges displayed to user 102.

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

[0158] In yet other embodiments for determining (block 602) a risk tolerance profile based on user input, the user may provide input 127 that describes an acceptable time range for high-level analyte events (e.g., hyperglycemic events) and / or low-level analyte events (e.g., hypoglycemic events). For example, user 102 may specify that he or she wishes to keep the amount of time he or she experiences hyperglycemia to be less than 10 minutes per day. After user 102 provides input 127 that describes an acceptable time range for high-level analyte events and / or low-level analyte events, the computing device may then determine (block 602) the risk tolerance profile of user 102 based on those inputs 127. For example, the computing device may determine (block 602) one or more high-level risk tolerance thresholds for user 102 based on the acceptable time range for high-level analyte events provided by user 102. As another example, the computing device may determine (block 602) one or more low-level risk tolerance thresholds for user 102 based on the acceptable time range for low-level analyte events provided by user 102.

[0159] In yet other embodiments of determining (block 602) a risk tolerance profile based on user input, sliders (e.g., two sliders) may be presented to user 102 via a UI on a computing device (e.g., mobile device 107). For example, a first slider may enable user 102 to select a high-level risk tolerance threshold, and a second slider may enable user 102 to select a low-level risk tolerance threshold. If 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 of the low-level risk tolerance threshold. A trade-off model may be used to calculate the new selected value of the second slider, which may be configured to predict how a change in one risk threshold affects the other 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 range is associated with more time below range, or to what extent more time above range is associated with less time below range. In various embodiments, after user 102 selects a value for the high-level risk tolerance threshold using the first slider, the trade-off model may predict how that selection affects the value of the low-level risk tolerance threshold, and thus may determine the new selected value of the second slider. Similarly, if user 102 uses the second slider to select a value for the low-level risk tolerance threshold, the first slider may be updated to change the selected value of the high-level risk tolerance threshold to a value calculated by the trade-off model.

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

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

[0162] In some embodiments, a CMAB algorithm can be used to: (i) partition a set of users or user cohorts into an exploration subset and an exploitation subset using an exploration 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 exploitation subset based on the contextual information of the user or user cohort. In some embodiments, the exploration ratio can define the ratio of users or user cohorts assigned to the exploration subset. In some embodiments, the exploration ratio can decrease over time. In some embodiments, the exploration ratio can be set to zero after a predetermined time period.

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

[0164] 2. Block 306: Determine a decision support output based on at least one analyte level criterion using a decision support model

[0165] As referenced above Figure 3 described, process 300 may include determining (block 306) one or more decision support outputs using one or more decision support models based on at least one analyte level criterion. For example, at least one analyte level criterion determined in block 304 (e.g., a set of analyte level criteria for a user) can be used in combination with one or more decision support models to determine one or more decision support outputs for the user.

[0166] Figure 7FIG. 0 is a flowchart of process 700 for using a decision support model to determine (block 306) at least one decision support output based on at least one analyte level criterion, in accordance with certain embodiments of the present disclosure. Various techniques can be used to determine (block 306) a user's decision support output by using the user's analyte level criteria in conjunction with a decision support model. For example, in some embodiments, process 700 can include determining (block 702) one or more hyperparameters of the decision support model based on the analyte level criteria. In some embodiments, a hyperparameter of the decision support model can be a value that defines the operational logic of the decision support model. In some embodiments, hyperparameters can be considered part of the model input as well as the data used to train, validate, and test the model. In some embodiments, hyperparameters can be considered part of the decision support model definition itself, where one or more hyperparameters can be selected (or optimized) to define the decision support model. For example, a hyperparameter can be a hyperglycemic threshold hyperparameter for a hyperglycemic warning model. As another example, the user's analyte level criteria can be provided as model input to the decision support model to determine the user's decision support output.

[0167] Reference Figure 7 , process 700 can include executing (block 704) one or more decision support models using at least one analyte criterion. In some embodiments, executing (block 704) the decision support model can include determining the user's decision support output based on input data that includes the user 102's high-level analyte threshold, low-level analyte threshold, high-level risk tolerance threshold, and / or low-level risk tolerance threshold. In some embodiments, executing (block 704) the decision support model can include determining the user's decision support output by using: (i) the user 102's high-level analyte threshold and low-level analyte threshold (e.g., optimal level range) as input data; and / or (ii) the user 102's high-level risk tolerance threshold and low-level risk tolerance threshold (e.g., risk tolerance profile) as hyperparameters of the decision support model.

[0168] In some embodiments, the decision support model can include a scoring submodel and a decision submodel. The scoring submodel can be configured to process input data that includes at least one analyte level criterion of the user 102 to determine a set of risk scores for the user 102. Each determined risk score can describe the predicted likelihood that the user 102 will experience a particular condition (e.g., a high-level analyte condition such as hyperglycemia or a low-level analyte condition such as hypoglycemia) in a future time period (e.g., in the next eight hours). The scoring submodel can be a trained machine learning model characterized by one or more training parameters. In some embodiments, a training parameter can be a value that affects the operational logic of the decision support model and can be determined by training the decision support model.

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

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

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

[0172] 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 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, and if the user's hyperglycemia risk score meets a second high-level risk tolerance threshold and the user 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 the risk tolerance profile of the user 102, as described by the user's analyte level criteria. As illustrated by this example, when the decision support model determines the 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 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 user's analyte level criteria.

[0173] The specific implementations and examples described herein are merely exemplary, and various specific implementations suitable for the requirements of a particular application may be utilized in accordance with certain implementations described herein. For example, another variation is a model that outputs pre-bedtime carbohydrate consumption (or exercise / insulin) recommendations if the risk of overnight hypoglycemia (or hyperglycemia) is predicted. These recommendations may have additional hyperparameters (above the risk thresholds) related to the type / amount of exercise / carbohydrate / insulin recommended.

[0174] In some embodiments, the decision support model may include a gradual transition model (also referred to as a "nudge" model). In various embodiments, the gradual transition model may be configured to determine a sequence of analyte levels to recommend to user 102 over a sequence of future time periods to assist and encourage the user to gradually transition his or her analyte values from a current analyte value range to an optimal analyte value range. In some embodiments, the gradual transition model is also configured to recommend a sequence of actions for user 102 to perform over a sequence of future time periods to assist and encourage user 102 to gradually transition his or her analyte values from a current analyte value range to an optimal analyte value range. In some embodiments, the gradual transition model may recommend different optimal analyte value ranges for different times of day. In some embodiments, the 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 user's 102 high-level analyte threshold and low-level analyte threshold as indicated by the user's 102 analyte level criteria.

[0175] The gradual transition model may be configured to iteratively guide 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 glucose ranges of 70 mg / dL to 220 mg / dL for the first month, 70 mg / dL to 200 mg / dL for the second month, 70 mg / dL to 180 mg / dL for the third month, and 70 mg / dL to 160 mg / dL for the fourth month. In some embodiments, to determine each recommended analyte level, the gradual transition model excludes those analyte levels whose risk scores fail to 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 level from a set of analyte levels whose hyperglycemic risk scores meet the user's 102 hyperglycemic risk tolerance threshold and whose hypoglycemic risk scores meet the user's 102 hypoglycemic risk tolerance threshold.

[0176] In some embodiments, a gradual transition model can determine the magnitude and timing of a recommended change in analyte level. To determine the magnitude and timing of a recommended change in analyte level, the gradual transition model can use the direction and magnitude of the most recent change in the user's analyte level to determine how aggressively to change the recommended analyte level for user 102. For example, a recent large improvement in glucose concentration measurements can be used to infer the momentum of user 102's behavior and determine a more aggressive recommended change in user 102's analyte level. In some embodiments, context data associated with user 102 (e.g., demographic data such as age data) can be used and the magnitude and timing of a recommended change in user 102's analyte level can be determined by leveraging a CMAB algorithm such as a multi-objective CMAB algorithm.

[0177] Figure 8 FIG. 800 is a flow chart illustrating an exemplary operational process 800 of a CMAB algorithm according to certain embodiments of the present disclosure. Process 800 can include allocating (step 1) a set of random hyperparameters to each user. For example, during an initial exploration, the CMAB algorithm can allocate a hyperglycemic threshold for each user (e.g., hyperglycemic threshold 1 = 180 mg / dL, hyperglycemic threshold 2 = 185 mg / dL, hyperglycemic threshold 3 = 190 mg / dL, hyperglycemic threshold 4 = 195 mg / dL, etc.). Process 800 can further include determining (step 2) a decision support output based on the allocated set of hyperparameters, observing the results associated with the decision support output, and training a result prediction model based on the observed data.

[0178] For example, for each user, the customer-facing algorithm can recommend a sequence of analyte levels over a sequence of future time periods based on the allocated hyperglycemic threshold. For example, for a user allocated hyperglycemic threshold 1, the sequence of analyte levels over a sequence of future time periods can be aggressive (e.g., week 1 glucose range 70 mg / dL to 220 mg / dL, week 2 glucose range 70 mg / dL to 200 mg / dL, week 3 glucose range 70 mg / dL to 180 mg / dL, and week 4 glucose range 70 mg / dL to 160 mg / dL). However, for a user allocated hyperglycemic threshold 4, the sequence of analyte levels over a sequence of future time periods can be less aggressive (e.g., month 1 glucose range 70 mg / dL to 220 mg / dL, month 2 glucose range 70 mg / dL to 200 mg / dL, month 3 glucose range 70 mg / dL to 180 mg / dL, and month 4 glucose range 70 mg / dL to 160 mg / dL).

[0179] In another example, for each user, the customer-facing algorithm may recommend a sequence of actions to be performed over a sequence of future time periods. For example, for a user assigned a high blood sugar 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 high blood sugar 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 may observe the results associated with the decision support output and train a result prediction model based on the observed data.

[0180] In addition, process 800 may include partitioning (step 3) the users into an exploration subset and an exploitation subset, and determining (step 4) the scaled results for the users in the exploitation subset by scaling the prediction results determined using the result prediction model. For example, the CMAB algorithm may place users in an exploration subgroup that will continue to be assigned random hyperparameters (e.g., one of high blood sugar thresholds 1 to 4). In addition, the CMAB algorithm may place users in an exploitation subgroup, and the users in the exploitation subgroup may be assigned hyperparameters based on the relationship between each user's context information and the learned context of the model (e.g., the user's age) and a certain hyperparameter value (e.g., one of high blood sugar thresholds 1 to 4) and the results. The learned relationship allows CMAB to predict results such as, but not limited to, the success rate of recommending a specific sequence of analyte levels over a series of future time periods, or the success rate of recommending a specific sequence of actions over a series of future time periods for a specific user. In certain embodiments, the prediction results may be represented by scalarized values, and CMAB may select the hyperparameter corresponding to the best scalarized value for the users in the exploitation subgroup. In other words, process 800 may include determining (step 5) the best set of hyperparameters for the users in the exploitation subset based on the scaled results and assigning the best set of hyperparameters to those users. In addition, process 800 may include randomly assigning (step 6) hyperparameters to the users in the exploration subset and using the data and the observed results to retrain the result prediction model. In certain embodiments, process 800 may repeat steps 2 to 6.

[0181] An example apparatus for determining a decision support output using user - specific analyte level criteria

[0182] Figure 9is a block diagram depicting an example computing device 900 configured to use user-specific analyte level criteria to determine a decision support output in accordance with certain embodiments disclosed herein. Although depicted as a single physical device, in embodiments, computing device 900 may be implemented using virtual devices and / or across multiple 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, 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 certain embodiments, non-volatile memory 910 is configured to store instructions (e.g., computer-executable code, device application 940) that, when executed by processor 905, cause processor 905 to perform the processes and / or operations described herein and illustrated in Figures 3 to 8 and / or operations illustrated therein. In certain embodiments, non-volatile memory 910 stores code for performing the functions of DAM 111, decision support engine 112, and / or application 106. Note that computing device 900 may be configured to perform the functions of only one of DAM 111, decision support engine 112, and / or application 106, in which case additional systems may be used to perform the functions of the other portions.

[0183] 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 having multiple processing cores, etc. Volatile memory 915 is typically included 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, caches, optical storage devices, network attached storage devices (NAS), or storage area networks (SAN).

[0184] In some embodiments, an I / O device 935 (such as a keyboard, monitor, etc.) may be connected via an I / O interface 920. Additionally, via a network interface 925, computing device 900 may be communicatively coupled to one or more other devices and components (such as user database 110). In certain 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 a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection. As illustrated, processor 905, non-volatile memory 910, volatile memory 915, network interface 925, and I / O interface 920 are communicatively coupled via one or more bus interconnects 930. In certain embodiments, computing device 900 is a server executing in a locally deployed data center or a cloud environment. In certain embodiments, computing device 900 is a user's mobile device.

[0185] In the illustrated embodiment, non-volatile memory 910 may include device application 940, which configures processor 905 to perform various processes and / or operations when determining decision support output 975 using user-specific analyte criteria, as described above. In some embodiments, device application 940 may perform the functions of DAM 111, decision support engine 112, and / or application 106. As referenced above Figures 3 to 8 as described, computing device 900 may be configured to determine and / or store at least one analyte level criterion 945. In some embodiments, at least one analyte level criterion 945 may include optimal level range data 950 and / or risk tolerance profile data 955, as further described above. Additionally, 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. Additionally, computing device 900 may be configured to receive and / or generate metric data 970 (e.g., metric 130), as described above. In certain embodiments, metric data 970 may include at least one analyte level criterion 945, which includes optimal level range data 950 and / or risk tolerance data 955.

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

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

[0188] In this document, as is common in patent documents, the terms "a" or "an" are used to include one or more than one, independent of any other instance or usage of "at least one" or "one or more". In this document, the term "or" is used to mean a non-exclusive or, such that "A or B" includes "A but not B", "B but not A", and "A and B", unless otherwise indicated. In this document, the terms "including" and "in which" are used as the plain English equivalents of the respective terms "comprising" and "wherein". Also, in the appended claims, the terms "including" and "comprising" are open-ended, i.e., a system, apparatus, article, composition, formulation, or process that includes elements in addition to those listed after such terms in the claims is still considered to fall within the scope of that claim. Further, in the appended claims, the terms "first", "second", "third", etc. are used only as labels and are not intended to impose numerical requirements on their objects.

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

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

[0191] The above description is intended to be illustrative, not restrictive. For example, the above examples (or one or more aspects thereof) can be used in combination with each other. Other implementations can be used by those skilled in the art, such as when reviewing the above description. The abstract is provided to comply with the requirements of 37 C.F.R. § 1.72(b) to enable the reader to quickly ascertain the nature of the technical disclosure. The abstract that is submitted should be understood not to be used to interpret or limit the scope or meaning of the claims. Also, in the above detailed description, various features can be grouped together to simplify the disclosure. This should not be construed as meaning that the disclosed features not claimed are necessary for any claim. Rather, the inventive subject matter can lie in less than all of the features of a particular disclosed implementation. Thus, the appended claims are hereby incorporated into the detailed description as examples or implementations, where each claim stands on its own as a separate implementation, and it is contemplated that these implementations can be combined with each other in various combinations or permutations. The scope of the present invention should be determined with reference to the appended claims and the full scope of equivalents to which those claims are entitled.

Claims

1. A non-transitory computer-readable storage medium storing a program, the program including instructions that, when executed by at least one processor of a computing device, cause the at least one processor to perform operations including the following: Receiving sensor data generated by an analyte sensor configured to monitor at least one analyte; Determining, for a user, at least one analyte level criterion 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.

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

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

4. The non-transitory computer-readable storage medium according to claim 3, wherein the operations further include: Receiving user input indicating the high-level analyte threshold and the low-level analyte threshold, wherein the high-level analyte threshold and the low-level analyte threshold are determined based on the user input.

5. The non-transitory computer-readable storage medium according to claim 3, wherein the optimal level range is determined by: Defining a threshold time period; and When determining that the sensor data covers the threshold time period, using the sensor data to generate a trend to determine the high-level analyte threshold and the low-level analyte threshold.

6. The non-transitory computer-readable storage medium according to claim 3, wherein the optimal level range is determined by: Defining a threshold time period; and When determining that the sensor data does not cover the threshold time period, using sensor data in a queue to generate a trend to determine the high-level analyte threshold and the low-level analyte threshold.

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

8. The non-transitory computer-readable storage medium according to claim 7, wherein the risk tolerance profile includes a high-level risk tolerance threshold and a low-level risk tolerance threshold, the high-level risk tolerance threshold defining the user's willingness to take risks for an analyte level having a high analyte level range exceeding the recommendation, and the low-level risk tolerance threshold defining the user's willingness to take risks for an analyte level having a low analyte level range below the recommendation.

9. A method for determining a decision support output using user-specific analyte level criteria, the method including: Receiving sensor data generated by an analyte sensor configured to monitor at least one analyte; Determining, for a user, at least one analyte level criterion 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.

10. The method according to claim 9, wherein the at least one analyte level criterion is the optimal level range of the at least one analyte.

11. The method according to claim 10, wherein the optimal level range includes a high analyte threshold defining the upper boundary of the at least one analyte and a low analyte threshold defining the lower boundary of the at least one analyte.

12. The method according to claim 11, the method further comprises: 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 according to claim 9, wherein the at least one analyte level criterion is the user's risk tolerance profile.

14. The method according to claim 13, wherein the risk tolerance profile includes a high level risk tolerance threshold and a low level risk tolerance threshold, the high level risk tolerance threshold defining the user's willingness to take risks for analyte levels exceeding the recommended high analyte level range, and the low level risk tolerance threshold defining the user's willingness to take risks for analyte levels below the recommended low analyte level range.

15. A computing device for determining a decision support output using user-specific analyte level criteria, the computing device comprises: 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: Use the network interface to receive 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.

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

17. The computing device according to claim 16, wherein the optimal level range includes a high analyte threshold defining the upper boundary of the at least one analyte and a low analyte threshold defining the lower boundary of the at least one analyte.

18. The computing device according to claim 17, wherein the computing device is 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 according to claim 15, wherein the at least one analyte level criterion is the user's risk tolerance profile.

20. The computing device according to claim 19, wherein the risk tolerance profile includes a high-level risk tolerance threshold and a low-level risk tolerance threshold, the high-level risk tolerance threshold defining the user's willingness to take risks with analyte levels that exceed the recommended high analyte level range, and the low-level risk tolerance threshold defining the user's willingness to take risks with analyte levels that are below the recommended low analyte level range.

Images